diff options
Diffstat (limited to 'doc/rfc/rfc3583.txt')
| -rw-r--r-- | doc/rfc/rfc3583.txt | 563 |
1 files changed, 563 insertions, 0 deletions
diff --git a/doc/rfc/rfc3583.txt b/doc/rfc/rfc3583.txt new file mode 100644 index 0000000..b5502e4 --- /dev/null +++ b/doc/rfc/rfc3583.txt @@ -0,0 +1,563 @@ + + + + + + +Network Working Group H. Chaskar, Ed. +Request for Comments: 3583 Nokia Research Center +Category: Informational September 2003 + + + Requirements of a Quality of Service (QoS) Solution for Mobile IP + +Status of this Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2003). All Rights Reserved. + +Abstract + + Mobile IP ensures correct routing of packets to a mobile node as the + mobile node changes its point of attachment to the Internet. + However, it is also required to provide proper Quality of Service + (QoS) forwarding treatment to the 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 for an IP QoS mechanism for its satisfactory operation + with Mobile IP. + + + + + + + + + + + + + + + + + + + + + + + + +Chaskar Informational [Page 1] + +RFC 3583 Mobile IP QoS Requirements September 2003 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 + 1.1. Problem Statement. . . . . . . . . . . . . . . . . . . . 2 + 1.2. An approach for solving QoS problem in Mobile IP . . . . 3 + 2. Terminology. . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 3. Requirements of a QoS solution for Mobile IP . . . . . . . . . 3 + 3.1. Performance requirements . . . . . . . . . . . . . . . . 4 + 3.2. Interoperability requirements. . . . . . . . . . . . . . 5 + 3.3. Miscellaneous requirements . . . . . . . . . . . . . . . 6 + 3.4. Standard requirements. . . . . . . . . . . . . . . . . . 7 + 4. Security Considerations. . . . . . . . . . . . . . . . . . . . 7 + 5. Recommendation . . . . . . . . . . . . . . . . . . . . . . . . 8 + 6. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 8 + 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 + 7.1. Normative References . . . . . . . . . . . . . . . . . . 8 + 7.2. Informative References . . . . . . . . . . . . . . . . . 8 + 8. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 9 + 9. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 10 + +1. 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, 6]. 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 an 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 a new care-of address after handover. Hence, they + may not be recognized by some forwarding functions in the nodes even + along that segment of the end-to-end path that remains unaltered + after handover. Finally, handover may occur between the subnets that + are under different administrative control. + + + + +Chaskar Informational [Page 2] + +RFC 3583 Mobile IP QoS Requirements September 2003 + + + In the light of this scenario, it is essential to establish proper + QoS support for the MN's packet stream along the new packet path. + +1.2. An approach for solving the 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 these 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 document. The last three steps are not dealt with here in + detail. However, so as to create useful insight into the Mobile IP + QoS problem, at times this document highlights the shortcomings of + some well known current proposals for establishing QoS support for + the packet stream in the network, when directly used with Mobile IP. + +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 BCP 14, RFC 2119 [2]. + +3. Requirements of a QoS solution for Mobile IP + + This section describes the requirements for a QoS solution for its + satisfactory operation with 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 the candidate access router + discovery protocols [7]. 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. + + + + + + + + +Chaskar Informational [Page 3] + +RFC 3583 Mobile IP QoS Requirements September 2003 + + +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 packet 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 [8] for the + case of end-to-end RSVP signaling [3] 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. + + However, note that handover may sometimes cause the end-to-end + path of MN's packet stream in the network to change at large. + This may happen, for example, in the case of handover between + different administrative domains. If the QoS mechanism used to + establish QoS support for the MN's packet stream along the new + packet path in the network is based on the explicit end-to-end + provisioning as such, it MUST perform so at the time of such + handover. + + + + + +Chaskar Informational [Page 4] + +RFC 3583 Mobile IP QoS Requirements September 2003 + + + 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. + + Note that the QoS signaling protocol such as RSVP [9] can localize + the QoS signaling 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 [4] 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 Seamoby working groups. Examples + are fast handover [10, 11], localized mobility management [12, + 13], context transfer [5] 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 packet paths as regards QoS + paradigms: + + The new path after handover, of the MN's packet stream, may + traverse network domains employing different QoS paradigms + compared to those along the old path. The QoS mechanism for + + + +Chaskar Informational [Page 5] + +RFC 3583 Mobile IP QoS Requirements September 2003 + + + Mobile IP SHOULD 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 a + manner consistent with the 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 presently programmed in this access router. 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. QoS mechanism for Mobile IP SHOULD + have provisions to handle such heterogeneity as regards the QoS + 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 routers, 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 mobility management, policy, location + privacy requirement and so on. Further, the same QoS mechanism + may not be able to support all these paths. + + 2. Interactions with wireless link-layer support for QoS: + + Since a vast number of devices using Mobile IP will be connected + to the Internet via wireless links, the QoS mechanism for Mobile + IP MAY provide some information to the wireless link layers for + them to support the required QoS. + + An example scenario that may benefit from such information is that + of the two UDP streams associated with the same media, but + requiring different levels of error protection at the wireless + link layer due to certain characteristics of their respective + encoding schemes. The packets of these two streams are equally + delay sensitive (so as to maintain playout synchronization at the + + + +Chaskar Informational [Page 6] + +RFC 3583 Mobile IP QoS Requirements September 2003 + + + receiver), and hence, may be treated equally (as regards queuing) + by IP layer. But they may need to be transmitted on wireless + channels of different error characteristics (say different FEC + coding or power levels). + + The QoS information included for the benefit of wireless link + layers SHOULD be such that it is meaningful both ways: to + applications that reside over IP so that they can choose the IP + service of certain QoS characteristics and to wireless link QoS + managers so that they can then map this information to the details + of lower layer mechanisms and their parameters. + + In the example scenario described above, such a QoS information + could be expressed as the acceptable loss rate of IP packets in + the UDP stream. This parameter enables the UDP application to + choose the IP service having QoS that matches its requirements, + and it also enables the wireless link QoS managers to choose the + right wireless channel to transmit the packets of this UDP stream. + +3.4. Standard requirements + + The QoS solution for Mobile IP SHOULD satisfy standard 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. Security Considerations + + The QoS (re)establishment triggered by node mobility MUST be guarded + against security attacks. Such attacks could be launched by + malicious nodes that spoof the QoS signaling to make it appear to the + intermediate nodes that the MN has undergone handover. Such an + attack could disrupt the QoS offered to MN's ongoing sessions as the + intermediate nodes may then tear down the QoS along some segments of + the true packet paths between MN and CN. The malicious nodes may + also request a reduced level of QoS or supply fake packet + classifiers, thereby affecting QoS over some segments (e.g., that do + not get affected by the spoofed handover) of the true packet paths + between MN and CN. Further, network resources may be wasted or used + in an unauthorized manner by the malicious nodes that spoof MN's + handover. To prevent this, QoS mechanism MUST provide means for + intermediate nodes to verify the authenticity of handover-induced QoS + (re)establishment. + + + + + +Chaskar Informational [Page 7] + +RFC 3583 Mobile IP QoS Requirements September 2003 + + +5. Recommendation + + In this document, we described the requirements for a QoS solution + for its satisfactory operation with Mobile IP. The expectation is + that the appropriate working group will use this requirements + document to provide a QoS solution for Mobile IP. + +6. 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, Brian Carpenter (IBM), Marc Greis + (Nokia), Glenn Morrow (Nortel), Phil Roberts (Megisto) and Michael + Thomas (Cisco) for their input during the preparation of this + document. + +7. References + +7.1. Normative References + + [1] Perkins, C., Ed., "IP mobility support for IPv4", RFC 3344, + August 2002. + + [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [3] Bernet, Y., Ford, P., Yavatkar, R., Baker, F., Zhang, L., Speer, + M., Braden, R., Davie, B., Wroclawski, J. and E. Felstaine, "A + Framework for Integrated Services Operation over Diffserv + Networks", RFC 2998, November 2000. + + [4] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S. and S. Jamin, + "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional + Specification", RFC 2205, September 1997. + + [5] Kempf, J., Ed., "Problem description: Reasons for performing + context transfers between nodes in an IP Access Network", RFC + 3374, September 2002. + +7.2. Informative References + + [6] Johnson, D., Perkins, C. and J. Arkko, "Mobility support in + IPv6", Work in Progress, May 2003. + + + + + + +Chaskar Informational [Page 8] + +RFC 3583 Mobile IP QoS Requirements September 2003 + + + [7] Trossen, D., et al., "Issues in Candidate Access Router + discovery for seamless IP handoffs", Work in Progress, October + 2002. + + [8] Chaskar, H. and R. Koodli, "QoS support in Mobile IP version 6", + IEEE Broadband Wireless Summit (Networld+Interop), May 2001. + + [9] Thomas, M., "Analysis of Mobile IP and RSVP interactions", Work + in Progress, February 2001. + + [10] MIPv4 Handoffs Design Team, "Low latency handoffs in Mobile + IPv4", Work in Progress, June 2002. + + [11] Koodli, R., Ed., "Fast handovers for Mobile IPv6", Work in + Progress, March 2003. + + [12] Williams, C., Ed., "Localized mobility management requirements", + Work in Progress, March 2003. + + [13] Soliman, H., et al., "Hierarchical MIPv6 mobility management + (HMIPv6)", Work in Progress, October 2002. + +8. Authors' Addresses + + The working group can be contacted via the current chair: + + John Loughney + Nokia Research Center + 11-13 Italahdenkatu + 00180 Helsinki + Finland + + EMail: john.loughney@nokia.com + + Questions about this memo can be directed to the editor: + + Hemant Chaskar + Nokia Research Center + 5 Wayside Road + Burlington, MA 01803, USA + + Phone: +1 781-993-3785 + EMail: hemant.chaskar@nokia.com + + + + + + + + +Chaskar Informational [Page 9] + +RFC 3583 Mobile IP QoS Requirements September 2003 + + +9. Full Copyright Statement + + Copyright (C) The Internet Society (2003). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assignees. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Chaskar Informational [Page 10] + |