IETF Mobile IP Working Group Hemant Chaskar INTERNET-DRAFT Editor
Expires: November 2001Nokia Research Center June20 August 2001 Requirements of a QoS Solution for Mobile IP draft-ietf-mobileip-qos-requirements-00.txtdraft-ietf-mobileip-qos-requirements-01.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 (2001). All rights reserved. Abstract Mobile IP protocol ensures correct routing of packets to mobile node as the mobile node changes its point of attachment with the Internet. However, it is also required to provide proper QoS forwarding treatment to mobile node's packet stream at the intermediate nodes in the network, so that QoS-sensitive IP services can be supported over Mobile IP. This document describes requirements of an IP QoS mechanism for its satisfactory operation with Mobile IP. 1.01 Introduction Mobile IP is a technology that allows a "mobile node" (MN) to change its point of attachment to the Internet while communicating with the "correspondent node" (CN) using IP. The formal description of Mobile IP can be found in [1, 2]. Mobile IP primarily addresses the correct routing of packets to MN's current point of attachment with the Internet. It is also essential to provide proper Quality of Service (QoS) forwarding treatment to the packets sent by or destined to MN as they propagate along different routes in the network due to node mobility. This document will identify the requirements that Mobile IP places on an IP QoS mechanism. 1.1 Problem statement When a MN using Mobile IP undergoes handover from one access router to another, the path traversed by MN's packet stream in the network may change. Such a change may be limited to a small segment of the end-to-end path near the extremity, or it could also have an end-to-end impact. Further, the packets belonging to MN's ongoing session may start using the new care-of address after handover, and hence,handover. Hence, they may not be recognized by some forwarding functions in the nodes even along that segment of the oldend-to-end path that use IP address as a key.remains unaltered after handover. Finally, handover may occur between the subnets that are under different administrative control. In the light of this scenario, it is essential to establish proper QoS support atfor the intermediate nodes inMN's packet stream along the new end-to-end path of the MN'spacket stream.path. 1.2 An approach for solving QoS problem in Mobile IP There are four important steps involved in solving the QoS problem for Mobile IP. They are as follows: (1) List the requirements that Mobile IP places on the QoS mechanism, (2) Evaluate current IP QoS solutions against the requirements, (3) Decide if current solutions need to be extended, or if new ones need to be defined, and (4) Depending on the result of step 3, define new solutions or fix the old ones. Of these, the first step, i.e. the requirements step, is addressed in this draft. The last three steps are not dealt with here in detail. However, so as to create useful insight into the Mobile IP QoS problem, wherever relevant,at times this draftdocument highlights the shortcomings of some popularwell known current practices (proposals)proposals for establishing QoS support alongfor the packet path,stream in the light ofnetwork, with respect to the requirements imposed by Mobile IP. 2 0Terminology 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. 3 0Requirements of a QoS solution for Mobile IP This section describes the requirements of a QoS solution for Mobile IP. Conversely, note that only Mobile IP-specific requirements are described here. We do not assume any particular version (4 or 6) of IP while describing the requirements. Solutions can be designed for IPv4 and IPv6 independently, or a single solution can be designed to work with both versions. In this document, we assume that the target access router for MN's handover is already pinned down by other protocols. For example, Seamoby working group has started work on candidate access router discovery protocols . Thus, any QoS-capability specific negotiations that may affect the handover decision are outside the scope of QoS solution as such, rather need to be performed by candidate and target access router selection protocols. 3.1 Performance requirements 1. Minimize the interruption in QoS at the time of handover: At the time of handover, interruption in QoS would occur if the packets sent by or destined to the MN arrive at the intermediate node in the new end-to-endpacket path without that node having information about their QoS forwarding requirement. Then, those packets will receive default forwarding treatment. Such QoS interruption MUST be minimized. A good metric for this performance is the number of packets that may potentially get served with the "default" QoS at the time of handover. The number of such packets MUST be minimized. As an example, this performance metric is computed in  for the case of end-to-end RSVP signaling  with Mobile IPv6. It is shown there that when the end-to-end path of packets changes at large after handover or when the care-of address changes after handover, OPWA (One Pass With Advertisement) model of reservation used by RSVP causes the latency of about one round-trip time between the MN and the CN before QoS can be established along the new packet path. In other words, the packets using the new care-of address that would be released by the MN or the CN during one round-trip time, after these nodes are ready to use the new care-of address, may get default forwarding treatment at the intermediate nodes. Such a latency in QoS programming may be acceptable at the time of session initiation, but it is not acceptable in the middle of an active session as would be the case with handover. 2. Localize the QoS (re)establishment to the affected parts of the packet path in the network: In many cases, handover changes only a small segment of the end-to-end path of MN's packet stream near the extremity. Then, the QoS mechanism MUST limit the extent of QoS (re)establishment to the affected segment of the end-to-end path only. Of course, ifHowever, note that handover may sometimes cause the end-to-end path changes at large after handover,of MN's packet stream in the QoS mechanism MUST be ablenetwork to address thatchange at large. This may happen, for example, in a manner that is consistent withthe case of handover between different administrative domains. If the QoS scheme(s)mechanism used to establish QoS support for the MN's packet stream along the new end-to-endpacket path. Note that the QoS signaling protocol such as RSVP  can localize the QoS signaling to the affected parts of the end-to-endpath ifin the care-of address does not change upon handover. However, ifnetwork is based on the care-of address changes upon handover, RSVPexplicit end-to-end provisioning as currently defined fails to localize the QoS signaling [see 6]. In addition,such, it will cause double reservations onMUST perform so at the parttime of end-to-end path that remains unchanged aftersuch handover. When the care-of address changes upon handover, it may be required to perform some signaling even over the unchanged part of the end-to-end path if the path contains any QoS mechanisms that use IP address as a key to forwarding functions. Examples are FILTER SPECs in the IntServ nodes or packet classifiers at the edges of DiffServ networks. However, double provisioning of resources over the unchanged part of the packet path MUST be avoided. 3. Releasing after handoverNote that the QoS state (if any) alongsignaling protocol such as RSVP  can localize the old packet path: TheQoS mechanism MUSTsignaling to the affected parts of the end-to-end path if the care-of address does not change upon handover. However, if the care-of address changes upon handover, RSVP as currently defined  fails to localize the QoS signaling. In addition, it will cause double reservations on the part of end-to-end path that remains unchanged after handover. 3. Releasing after handover the QoS state (if any) along the old packet path: The QoS mechanism MUST provide some means (explicit or timer-based) to release any QoS state along the old packet path that is not required after handover. It is desirable that the unwarranted QoS states, if any, along the old path are released as quickly as possible at the time of handover. Note that, during handover, the MN may not always get a chance to send explicit tear down message along the old path because of the loss of link layer connectivity with the old access router. 3.2 Interoperability requirements 1. Interoperability with mobility protocols: A number of mobility protocols that are complementary to Mobile IP are already defined or may be defined in future in IETF, particularly in Mobile IP and Seamless MobilitySeamoby working groups. Examples are Fast Handover [7, 8],[8, 9], Regional Registrations ,, Hierarchical MIPv6 ,, Context Transfer  etc. The QoS mechanism for Mobile IP SHOULD take advantage of these mobility protocols for the optimized operation. However, the QoS scheme MUST have provisions to accomplish its tasks even if one or more of these mobility protocols are not used. 2. Interoperability with heterogeneous end-to-endpacket paths as regards QoS paradigms: The new end-to-endpath after handover, of the MN's packet streamstream, may encountertraverse network domains employing a variety of QoS paradigms, such as IntServ, DiffServ and MPLS. Each of the networks/routers along this path may require adifferent kind of information about the MN's packet stream, so that properQoS forwarding treatment can be established forparadigms compared to those along the MN's packet stream.old path. The QoS mechanism for Mobile IP MUST be able to establish proper QoS forwarding treatment for the MN's packet stream along the packet paths deploying different QoS paradigms (best current practices), in these QoS-heterogeneous network domains ina manner consistent with the new end-to-end path.QoS mechanism deployed along those paths. As an illustration, suppose that the MN is currently attached to an access router which is the edge router of a DiffServ network, and that the packet classifier and traffic policer for the MN's flows are somehowpresently programmed in this access router. Further, assume that the QoS policy in this access network takes care of SLAs with other networks that it attaches to.Now, suppose that the MN needs to be handed over to the access router which is at the edge of an IntServ network. The new access network would expect the exchange of RSVP messages so that proper QoS forwarding treatment can be established for the MN's packet stream in that access network. Here is another example of cross-QoS-technology handover. Suppose that the MN is currently attached to an access router that is a part of access network X and is to be handed over to the access router that is a part of access network Y. In network X, the access router acts as a proxy (and possibly communicates with some QoS agent in the network) to program (possibly end-to-end) QoS forwarding treatment for the MN's packet stream. On the other hand, network Y expects the end hosts attached to it to send explicitQoS request messages along the data path. The QoS solutionmechanism for Mobile IP MUST be ablehave provisions to establish QoS support for MN's packet stream overhandle such heterogeneity as regards the packet paths that use diverse (best current practices) end-to-endQoS mechanisms.mechanisms deployed along different packet paths. 3.3 Miscellaneous requirements 1. QoS support along multiple packet paths: After MN undergoes handover from one access router to another, potentially, there could be multiple paths over which MN's packet may propagate. Examples of these path are: route-optimized path between the MN and its CN, triangle route via Home Agent (HA), temporary tunnel between old and new access routersrouters, reverse tunnel from the new access router (Foreign Agent) to HA etc. A QoS mechanism SHOULD be able to support QoS along the different potential packet paths. However, whether all paths are supported or only a subset of them is supported will be determined by external mechanisms such as, say,as mobility management, policy, location privacy requirement etc.and so on. Further, the same QoS mechanism may not be able to support all the three alternatives.these paths. 2. Interactions with link-layer support for QoS: The QoS mechanism MAY provide some information to the link layers for them to support the required QoS. Since a vast number of devices using Mobile IP will be connected to the Internet via wireless links, wireless link significantQoS parameters relevant for wireless links, such as error raterate, MAY have to be included in the set of IP-level QoS parameters to be possibly considered and supportedby the underlying link layer. An example scenario will be two UDP streams requiring different levels of error protection at the link layer. For such cases, an IP-layer QoS mechanism may indicate some generic parameters such as acceptable IP packet loss rate to link layers. 3.4. ObviousStandard requirements The QoS solution for Mobile IP SHOULD satisfy obviousstandard requirements such as scalability, security, conservation of wireless bandwidth, low processing overhead on mobile terminals, providing hooks for authorization and accounting, and robustness against failures of any Mobile IP-specific QoS components in the network. While it is not possible to set quantitative targets for these desirable properties, the QoS solution MUST be evaluated against these criteria. 4.0 Concluding Remarks4 Recommendation In this document, we described the requirements of a QoS solution for Mobile IP. The expectation is that the appropriate working group will use this requirements document to provide a QoS solution for Mobile IP. 5.05 Acknowledgment I would like to acknowledge the participants of the mailing list that was set up to discuss the above requirements. Their contributions and active participation in the discussion on the mailing list were very useful in the preparation of this document. Special thanks are due to, in alphabetical order, Marc Greis (Nokia), Glenn Morrow (Nortel), Phil Roberts (Megisto) and Michael Thomas (Cisco) for their comments during the preparation of this document. 6.06 References  IP Mobility Support, C. Perkins (Editor), RFC 2002, October 1996.  Mobility Support in IPv6, D. Johnson and C. Perkins, draft-ietf-mobileip-ipv6-13.txt, work in progress, November 2000.  Issues in candidate access router discovery for seamless IP handoffs, D. Trossen et. al., draft-ietf-seamoby-cardiscovery-issues-00.txt, work in progress, July 2001.  A Framework for QoS Support in Mobile IPv6, H. Chaskar and R. Koodli, draft-chaskar-mobileip-qos-01.txt, work in progress, March 2001.  A Framework for Integrated Services Operation over Diffserv Networks, Yoram Bernet et. al., RFC 2998, November 2000.  Analysis of Mobile IP and RSVP Interactions, Michael Thomas, draft-thomas-seamoby-rsvp-analysis-00.txt, work in progress, February 2001.  Resource ReSerVation Protocol -- Version 1 Functional Specification, R. Braden et. al., RFC 2750, September 1997.  Low Latency Handoffs in Mobile IPv4, MIPv4 Handoffs Design Team, draft-ietf-mobileip-lowlatency-handoffs-v4-00.txt, work in progress, February 2001.  Fast Handovers for Mobile IPv6, MIPv6 Handover Design Team, draft-ietf-mobileip-fast-mipv6-01.txt, work in progress, April 2001.  Mobile IPv6 Regional Registrations, J. Malinen, Frank Le , and C. Perkins, draft-malinen-mobileip-regreg6-01.txt, work in progress, March 2001.  Hierarchical MIPv6 Mobility Management, H. Soliman, C. Castelluccia, K. El-Malki, and L. Bellier, draft-ietf-mobileip-hmipv6-02.txt, work in progress, February 2001.  Context Transfer Framework for Seamless Mobility, R. Koodli and C. Perkins, draft-koodli-seamoby-ctv6-00.txt, work in progress, February 2001. 7.07 Addresses The working group can be contacted via the current chairs: Basavaraj Patil Phil Roberts Nokia Corporation Megisto 6000 Connection Drive 20251 Century Blvd M/S M8-540Blvd, Suite 120 Irving, Texas 75039, USA Germantown, MD 20874 Phone: +1 972-894-6709 Phone: +1 847-202-9314 EMail: Basavaraj.Patil@nokia.com EMail: proberts@MEGISTO.com Questions about this memo can be directed to the authors:editor: Hemant Chaskar Nokia Research Center 5 Wayside Road Burlington, MA 01803, USA Phone: +1 781-993-3785 EMail: firstname.lastname@example.org Appendix: Changes Made from 00 Version Few editorial changes were made from 00 version based on the working group feedback received on the Mobile IP mailing list. 1. A clarification is added at the beginning of Section 3, which states that QoS-capability negotiations that may affect handover decision are outside the scope of this document. 2. Section 3.1.2 was reworded for better clarity. 3. Section 3.2.2 was reworded for better clarity. 4. Section 3.4 is now called "Standard Requirements" rather than "Obvious Requirements". 5. Section 4 is now called "Recommendation" rather than "Concluding Remarks".