IETF Mobile IP Working Group H. Chaskar INTERNET-DRAFT R. Koodli Expires: May 2001 Nokia Research Center November 2000 A Framework for QoS Support in Mobile IPv6 draft-chaskar-mobileip-qos-00.txt Status of This Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or made obsolete by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (c) The Internet Society (2000). All rights reserved. Abstract This document describes a framework for providing QoS support in Mobile IPv6. As the Mobile Node changes its point of attachment with the Internet, the intermediate network domains traversed by its packets may change. It is required to program appropriate QoS support for the MN's packets in these network domains, so that the performance of QoS-sensitive applications running on the MN is maintained at desired level. To achieve this, we introduce a new IPv6 option called "QoS Object." Depending on the context, the QoS Object is included as a Destination Option or a Hop-by-Hop Option in IPv6 packets carrying Binding Update and Binding Acknowledgment messages. When included as a Hop-by-Hop Option, QoS Object triggers certain QoS procedures at the intermediate network domains. In this document, we describe these QoS procedures for the cases of best-effort, MPLS, DiffServ and IntServ domains, which practically cover all the cases of QoS enabled network domains that would be available in near future. Chaskar, Koodli [Page i] INTERNET-DRAFT QoS Support in Mobile IPv6 November,2000 Contents Status of This Memo i Abstract i 1. Introduction 1 2. Terminology 1 3. QoS Object: A New Option for Mobile IPv6 2 4. Inclusion of QoS Object Option Along With Binding Messages 3 4.1 Transactions between the MN and the HA . . . . . . . . 3 4.2 Transactions between the MN and the CN . . . . . . . . 4 5. Processing of QoS Object at Intermediate Network Domains 5 5.1. Processing at (the edge of) MPLS domain . . . . . . . . 5 5.2. Processing at (the edge of) DiffServ domain . . . . . . 6 5.3. Processing at (the edge of) IntServ domain . . . . . . 7 6. Concluding Remarks 8 7. References 9 8. Addresses 10 Chaskar, Koodli [Page ii] INTERNET-DRAFT QoS Support in Mobile IPv6 November,2000 1. Introduction The provisions in Mobile IPv6 [1] discussed so far, do not have any mechanism to inform the routers or network domains in the path between the Home Agent (HA) and the Mobile Node (MN), and between the Correspondent Node (CN) and the MN, about the quality of service (QoS) requirement of packet streams belonging to the MN. Note that these intermediate routers or network domains traversed by the MN's packets may change as the MN changes its point of attachment. Thus, for example, the packets belonging to MNĘs video teleconference may get the same forwarding treatment as those belonging to its FTP session at the intermediate network domains, in the absence of such QoS information. Further, it is not possible for the routers or network domains in the end to end path to exercise admission control and enforce admission policy, in the absence of QoS and traffic volume information about MN's packet streams. For example, some intermediate bottleneck network domain may not wish to admit high bandwidth video-on-demand packet stream of the MN. Motivated by this problem and the fact that IP QoS and traffic engineering mechanisms, such as Multiprotocol Label Switching (MPLS) [2], Differentiated Services (DiffServ) [3] and Integrated Services (IntServ) [4], will be available in near future, we describe a framework to bring QoS negotiation capabilities to Mobile IPv6. This framework is based on the use of new IPv6 option called "QoS Object." QoS Object is included, depending on the context, either as a Destination Option or as a Hop-by-Hop Option along with the packets carrying Binding Update and Binding Acknowledgment options. The basic idea is to include QoS Object as a Hop-by-Hop option along with the binding message that travels in the same direction (HA to MN, CN to MN or MN to CN) as that of MN's QoS-sensitive packet stream. As this packet traverses different network domains in the end to end path, the QoS Object is examined at these network domains to program QoS support for the MN's data packets. In general, only the edge routers of these network domains examine the QoS Object, while the routers internal to the domains either ignore it or they do not see it in cases such as label based forwarding of MPLS. Hence, it does not put additional processing burden on the internal (core) routers. Section 3 describes the composition of QoS Object option. The semantics of inclusion of QoS Object option in packets carrying binding messages is described in Section 4. Section 5 describes the processing that the QoS Object invokes at the edges of MPLS, DiffServ and IntServ domains. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119[1]. Chaskar, Koodli [Page 1] INTERNET-DRAFT QoS Support in Mobile IPv6 November,2000 3. QoS Object: A New Option for Mobile IPv6 The composition of QoS Object option is shown in Figure 1. This option is included in IPv6 packets carrying Binding update and Binding Acknowledgment, either as a Destination Option or a Hop-by-Hop Option, as described in Section 4. We require as many QoS Objects as the number of unidirectional QoS-sensitive packet streams between the MN and the CN, while binding messages are used on a per-host basis. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1 |0|0|1| Opt Type| Opt Data Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2 |QoS Requirement(16-bit integer)| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3 | Average Data Rate (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4 |Burstiness:Token Bucket Size(32-bit IEEE floating point number)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5 | Peak Data Rate (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6 | Minimum Policed Unit (32-bit integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7 | Maximum Packet Size (32-bit integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8 | Flags (Future use) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 9 | | + Values of Packet Classification Parameters + 10 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Composition of QoS Object option - The "QoS Requirement" field describes the QoS requirement of the MN's packet stream. An example is the QoS specification in terms of traffic classes, such as conversational, streaming, interactive and background, as in the UMTS QoS classes specification [5]. Each of these classes will be assigned a unique integer value. - The next five fields constitute the "Traffic Volume" information. These fields indicate the amount of traffic that the MN's packet stream will generate. The parameters that are used to describe the Traffic Volume are taken from RSVP SENDER_TSPEC object [6]. - Finally, "Packet Classification" information fields describe the values of packet header fields that can be used to identify the packets of the MN's packet stream at the (edges of) intermediate network domains. Typically, the parameters such as, source and Chaskar, Koodli [Page 2] INTERNET-DRAFT QoS Support in Mobile IPv6 November,2000 destination IP addresses, TCP and UDP port numbers, and IPv6 flow label, are used for packet classification purposes. Note that the values of source and destination IP addresses to be used for packet classification can be always inferred from the header of the packet carrying QoS Object itself (see Section 4 also). However, values of parameters such as TCP/UDP port numbers and IPv6 flow labels may be required to be explicitly carried in the QoS Object to indicate which packet stream of the MN the given QoS Object corresponds to. This is because, binding messages are sent on a per-host basis while QoS Object is for each packet stream. The Flags field is kept for future use. The intent is to use it to specify if certain packet classification parameters in the above list are to be explicitly ignored. Now, we describe semantics of the inclusion of QoS Object option in packets carrying binding messages to the HA and the CN. 4. Inclusion of QoS Object Option Along with Binding Messages The basic idea here is to include the QoS Object as a Hop-by-Hop Option along with the binding message that travels between the MN and the HA or between the MN and the CN in the same direction as the MN's QoS-sensitive packet stream. The QoS Object can then inform the intermediate network domains about the QoS requirement of the relevant packet stream. This information will be used by these intermediate network domains to program appropriate QoS support for the data packets of the packet stream that will arrive subsequent to this binding message. 4.1 Transactions between the MN and the HA With respect to the HA, the only relevant direction of MN's data traffic is from the HA to the MN and there is no traffic in the opposite direction. Hence, QoS support needs to be negotiated only in a direction from the HA to the MN. This is achieved by including the QoS Object option along with the binding messages sent to the HA as follows: 1. MN includes the QoS Object as a Destination Option along with the Binding Update that is sent to the HA. This Binding Update is sent with Acknowledgment bit set to one, indicating that the HA is required to acknowledge this Binding Update. 2. HA verifies the QoS Object in Destination Option and includes it, with possible modification, as a Hop-by-Hop Option along with the packet carrying Binding Acknowledgment. 3. The relevant routers (see Section 5) at the intermediate network domains traversed by Binding Acknowledgment examine the QoS Object option to determine the QoS requirement of the MN's packet streams that will flow from the HA to the MN, subsequent to this Binding Acknowledgment. The Traffic Volume fields in the Chaskar, Koodli [Page 3] INTERNET-DRAFT QoS Support in Mobile IPv6 November,2000 QoS Object will indicate the amount of traffic that the MN's packet streams will bring to the network domain, and the Packet Classification information fields in the QoS Object will indicate the values of fields in the packet headers that can be used to identify the packets of MN's packet streams. This information is used by the routers to: i. Take admission control decision, and ii. Program forwarding treatment that needs to be offered to the packets of MN's packet streams at the network domain under consideration. This is further described in Section 5. 4.2 Transactions between the MN and the CN Whenever, MN changes its point of attachment to the Internet, it may also send Binding Update to CN for the sake of route optimization of downlink traffic. For the sake of QoS negotiation with the intermediate network domains, MN creates QoS Objects and includes them with the Binding Update, as described below. With respect to the CN, the direction of MN's data traffic can be from the CN to the MN (downlink) as well as from the MN to the CN (uplink). As stated earlier, one QoS Object corresponds to one unidirectional QoS-sensitive packet stream. The transactions with the CN are as follows: 1. The uplink QoS Object is included as a Hop-by-Hop Option and the downlink QoS Object is included as a Destination Option along with the Binding Update that is sent to the CN. This Binding Update is sent with Acknowledgment bit set to one, indicating that the CN is required to acknowledge this Binding Update. 2. The relevant routers (see Section 5) at the intermediate network domains, traversed by Binding Update examine the uplink QoS Object to determine the QoS requirement of the packets that will flow from MN to CN, subsequent to this Binding Update. As mentioned earlier, the routers make use of the information in the uplink QoS Object to perform admission control and program packet forwarding treatment. 3. Upon receiving the Binding Update, the CN verifies the downlink QoS Object in the Destination Option and includes it, with possible modifications, as a Hop-by-Hop Option along with the packet carrying Binding Acknowledgment. 4. The relevant routers (see Section 5) at the intermediate network domains, traversed by Binding Acknowledgment examine the downlink QoS Object to determine the QoS requirement of the packets that will flow from CN to MN, subsequent to this Binding Chaskar, Koodli [Page 4] INTERNET-DRAFT QoS Support in Mobile IPv6 November,2000 Acknowledgment. As mentioned earlier, the routers make use of the information in the downlink QoS Object to perform admission control and program packet forwarding treatment. In certain cases, by virtue of admission control, some network domain in the end to end path may not wish to accommodate all the traffic indicated by the Traffic Volume field in the QoS Object with the requested QoS as indicated by the QoS Requirement field. The relevant router at that network domain can then modify the fields in the QoS Object so that they are in conformance with the QoS support that this domain is capable of. 5. Processing of QoS Object at Intermediate Network Domains When QoS Object in included as a Hop-by-Hop Option in IPv6 packet, the intermediate routers examine this option. Typically, there are multiple and possibly heterogeneous (as regards QoS mechanism employed) network domains between the MN and the HA, and between the MN and the CN. Here, a network domain is defined as a collection of network nodes (routers) that implements a particular QoS mechanism independently and under the same control plane. There are Edge Routers (ER) at the edge of these domains and Internal Routers (IR) within the domains. Each of these domains may be best-effort domain or may employ QoS mechanisms such as MPLS, DiffServ or IntServ. The case of best-effort domain is trivial as the routers (edge and internal) belonging to such domain simply ignore the QoS Object. This leaves us with the interesting case of QoS-enabled domains. 5.1 Processing at (the edge of) MPLS domain In an MPLS domain [2], when a set of data units (IP packets) traverses a common path through the network domain, a Label Switched Path (LSP) can be established using MPLS signaling protocols. This set is then called as belonging to the same Forwarding Equivalence Class (FEC). At the ingress Label Switch Router (LSR), each packet in this set is assigned a label that corresponds to the relevant FEC and it is transmitted downstream. At each LSR along the LSP, the label is used to forward the packet to the next hop. Label-based forwarding paradigm enhances scalability of packet forwarding engines as they are relieved of routing table lookup as well as due to reduction in the size of forwarding database by virtue of label merging capability of MPLS. Further, MPLS is a very useful tool for traffic engineering [7]. When IPv6 packet containing QoS Object as a Hop-by-Hop Option, arrives at the ER (also called as ingress LSR) of MPLS domain, the ER determines, based on the destination address of the packet and the QoS Object in the Hop-by-Hop Option, the FEC to which the packets of the corresponding stream belong. FEC in turn translates to the LSP that the subsequent packets of this stream Chaskar, Koodli [Page 5] INTERNET-DRAFT QoS Support in Mobile IPv6 November,2000 should traverse through that domain. Such LSPs for different traffic classes are typically pre-established by the service provider between different ingress-egress router pairs, during traffic engineering phase. The ER then creates "FEC Mapping Context" that will map the subsequent packets of the MNĘs packet stream under consideration to this FEC or LSP. The Packet Classification information fields in the QoS Object are used to identify the subsequent packets of this packet stream at the ER. Due to this FEC Mapping Context, appropriate label is attached to the subsequent packets of the MNĘs packet stream under consideration at the ER. These packets then traverse thus determined LSP, while transiting through the network domain under consideration. Note that such Mapping Context is required for any traffic (not only Mobile IPv6 traffic) that is to be forwarded using label-based paradigm. Hence, the edge LSRs at MPLS domain already have this functionality. The ER then forwards the packet containing the QoS Object to the destination ER of the same LSP, over the same LSP or over some other LSP. Forwarding this packet on LSP as well, achieves the desirable result that the IRs in the domain do not have to examine the QoS Object option. Precisely, due to label-based forwarding paradigm they do not even see the IP header. 5.2 Processing at (the edge of) DiffServ domain The DiffServ QoS architecture [3] is based on a model where traffic entering a network domain is classified and possibly conditioned at the boundaries of the network domain, and assigned to different behavior aggregates. Each behavior aggregate is identified by a unique DiffServ Code Point (DSCP). DSCP is included in the IP header of the packet at the ER of the domain. DiffServ proposes differentiation in the queuing and forwarding treatment received by packets at the routers in the network domain, on the basis of DSCPs included in their headers at the ER of the domain. IETF has standardized two groups of behavior aggregates, namely expedited forwarding or EF (one instance or class) and assured forwarding or AF (four instances or classes each containing three drop-precedence levels). When IPv6 packet containing QoS Object as a Hop-by-Hop Option, arrives at the ER of DiffServ domain, the ER determines, using QoS Object in the Hop-by-Hop Option, the forwarding treatment that the subsequent packets of this stream should get within the corresponding network domain. In particular, the QoS Requirement field in the QoS Object indicates the behavior aggregate that the packets of MNĘs packet stream should be assigned to. Further, the Traffic Volume fields enable the ER to exercise admission control, and possibly, initialize the parameters for traffic conditioner for the MNĘs packet streams. The ER also programs "Classifier Context" that would mark the subsequent data packets of the MNĘs packet streams with appropriate DSCPs relevant for Chaskar, Koodli [Page 6] INTERNET-DRAFT QoS Support in Mobile IPv6 November,2000 that domain. Packet Classification information fields in the QoS Object are used to identify the subsequent packets of this stream. Finally, note that the packet classification and traffic conditioning functionality is required at the ER of DiffServ domain for any traffic (not only Mobile IPv6 traffic). If DiffServ is used in conjunction with MPLS [8], subsequent forwarding of the packet containing QoS Object through that domain is as described in Section 5.1, i. e., over LSP. Else, the packet containing QoS Object is forwarded through the network domain in a hop-by-hop fashion. IRs in the network domain simply ignore the QoS Object. Note that, in the latter case, since IRs are employing hop-by-hop forwarding of packets, their architecture is already tailored to perform hop-by-hop processing of packets. Hence, accessing (and later ignoring) QoS Object does not put additional burden on these routers. 5.3 Processing at (the edge of) IntServ domain IntServ QoS mechanism defines service classes, such as guaranteed service and controlled-load service, that if supported by the routers in the network domain can provide the data flow with certain QoS commitments. The level of QoS provided by these classes is programmable on a per-flow basis. The QoS requests can be passed to the routers in the network domain using a reservation protocol called RSVP. The requests dictate the level of resources, such as bandwidth and buffer space, that must be reserved along with the transmission scheduling behavior that must be installed in the routers to provide the desired QoS commitment for the data flow. IntServ QoS mechanism has not gained much popularity due to its poor scalability. Nonetheless, we cover this case here for the sake of completeness. When IPv6 packet containing QoS Object arrives at the ER of IntServ domain, the ER initiates resource reservation process as described in [4]. In particular, it first determines, based on the destination address of this IPv6 packet, the egress ER for this domain. Based on basic IntServ paradigm (RSVP messaging), in the present context, there are a number of alternatives to perform resource reservation in the network domain. Here we describe one illustrative example. The ingress ER sends PATH message to thus determined egress ER. It uses Traffic Volume and Packet Classification information fields in the QoS Object to construct Sender_TSpec and Sender_Template for the PATH message. It includes (a version of) QoS Requirement field in the Destination Option of IPv6 packet carrying the PATH message. Note that the destination address for packet carrying PATH message is the egress ER. This would inform the egress ER about the required QoS support so that it can compare it with the performance calculated based on the available resources and other parameters recorded by the IRs in, say, AdSpec Chaskar, Koodli [Page 7] INTERNET-DRAFT QoS Support in Mobile IPv6 November,2000 of PATH message. If sufficient resources are available to support the required QoS, the egress ER sends RESV towards the ingress ER. Upon, the receipt of RESV at the ingress ER, ingress ER forwards the IPv6 packet containing QoS Object along the same path. The IRs on this path simply ignore the QoS Object Hop-by-Hop Option. By virtue of the resource reservation just established, subsequent packets of the MN's will get the desired QoS as they are forwarded along the path over which resources are just reserved. 6. Concluding Remarks We described a solution for end to end QoS negotiation for applications running on Mobile IPv6. The solution is based on the inclusion of QoS Object in packets carrying binding messages between the MN and the HA and between the MN and the CN. We described the processing of QoS Object when included as a hop-by-hop option for the cases of best-effort, MPLS, DiffServ and IntServ domains, and showed that the solution integrates elegantly with these QoS mechanisms. For the deployment of the proposed QoS solution for Mobile IPv6, two important steps are required. The first is standardization of the fields of QoS Object option. The other is implementation of a routine in the edge routers of network domains that would interpret the QoS Object and communicate with the QoS control plane in that network domain. Note that the support for hop-by-hop options is already a requirement in IPv6 specification [9]. The QoS solution described in this document works for the general case where the intermediate network domains traversed by the MNĘs packets change as a result of change in point of attachment of the MN with the Internet. However, certain local optimizations to this solution are possible. For example, it is possible to store QoS Object at the router where the MN attaches to the Internet. When the MN changes its point of attachment to another router, the QoS Object can be relocated from the old router to the new router as a part of context transfer procedure. When the MN sends Binding Update from the new point of attachment, instead of including the detailed QoS Object, it can include the QoS Object with a particular bit pattern in the QoS Requirement field indicating that the router has to fill in the details of QoS Object in this packet. Such an extension to the basic solution will reduce the wireless bandwidth consumption. Further, certain optimizations are possible if regionalized mobility management schemes, such as regional registration, are employed. These are the topics of future study. Chaskar, Koodli [Page 8] INTERNET-DRAFT QoS Support in Mobile IPv6 November,2000 7. References [1] D. Johnson and C. Perkins. Mobility Support in IPv6. Internet Draft, Internet Engineering Task Force. draft-ietf-mobileip-ipv6-12.txt. April 2000. [2] E. Rosen, A. Viswanathan, and R. Callon. Multiprotocol Label Switching Architecture. Internet Draft, Internet Engineering Task Force. draft-ietf-mpls-arch-06.txt. July 2000. [3] S. Blake et. al. An Architecture for Differentiated Services. Request for Comments (Informational) 2475. December 1998. [4] R. Braden and L. Zhang. Resource ReSerVation Protocol (RSVP): Version 1 Functional Specification. Request for Comments (Standards track) 2205. September 1997. [5] 3GPP Technical Specification 23.107, Version 3.2.0: QoS Concept and Architecture, March 2000. [6] J. Wroclawski. The Use of RSVP with IETF Integrated Services. Request for Comments 2210 (Standards Track). September 1997. [7] D. Awduche et. al. Requirements for Traffic Engineering Over MPLS. Request for Comments (Informational) 2702. September 1997. [8] F. Faucheur et. al. MPLS Support of Differentiated Services. Internet Draft, Internet Engineering Task Force. draft-ietf-mpls-diff-ext-07.txt. August 2000. [9] S. Deering and R. Hinden. Internet Protocol, Version 6 (IPv6). Request for Comments 2460. December 1998. Chaskar, Koodli [Page 9] INTERNET-DRAFT QoS Support in Mobile IPv6 November,2000 8. Addresses The working group can be contacted via the current chairs: Basavaraj Patil Phil Roberts Nokia Corporation Motorola 6000 Connection Drive 1501 West Shure Drive M/S M8-540 Irving, Texas 75039 Arlington Heights, IL 60004 USA USA Phone: +1 972-894-6709 Phone: +1 847-632-3148 Fax : +1 972-894-5349 EMail: Basavaraj.Patil@nokia.com EMail: QA3445@email.mot.com Questions about this memo can be directed to the authors: Hemant Chaskar Communication Systems Laboratory Nokia Research Center 5 Wayside Road Burlington, MA 01803, USA Phone: +1 781-993-3785 EMail: hemant.chaskar@nokia.com Rajeev Koodli Communication Systems Laboratory Nokia Research Center 313 Fairchild Drive Mountain View, CA 94043, USA Phone: +1 650-625-2359 EMail: rajeev.koodli@nokia.com Chaskar, Koodli [Page 10]