idnits 2.17.1 draft-ietf-mobileip-qos-requirements-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 17 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 22 has weird spacing: '... months and m...' == Line 29 has weird spacing: '... The list o...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (20 August 2001) is 8279 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2002 (ref. '1') (Obsoleted by RFC 3220) == Outdated reference: A later version (-24) exists of draft-ietf-mobileip-ipv6-13 == Outdated reference: A later version (-04) exists of draft-ietf-seamoby-cardiscovery-issues-00 ** Downref: Normative reference to an Informational draft: draft-ietf-seamoby-cardiscovery-issues (ref. '3') -- Possible downref: Normative reference to a draft: ref. '4' ** Downref: Normative reference to an Informational RFC: RFC 2998 (ref. '5') -- Possible downref: Normative reference to a draft: ref. '6' == Outdated reference: A later version (-11) exists of draft-ietf-mobileip-lowlatency-handoffs-v4-00 ** Downref: Normative reference to an Experimental draft: draft-ietf-mobileip-lowlatency-handoffs-v4 (ref. '8') -- No information found for draft-ietf-mobileip-fast-mipv6 - is the name correct? -- Possible downref: Normative reference to a draft: ref. '9' -- Possible downref: Normative reference to a draft: ref. '10' -- No information found for draft-ietf-mobileip-hmipv6 - is the name correct? -- Possible downref: Normative reference to a draft: ref. '11' -- No information found for draft-koodli-seamoby-ctv6 - is the name correct? -- Possible downref: Normative reference to a draft: ref. '12' Summary: 13 errors (**), 0 flaws (~~), 6 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IETF Mobile IP Working Group Hemant Chaskar 3 INTERNET-DRAFT Editor 4 Nokia Research Center 5 20 August 2001 7 Requirements of a QoS Solution for Mobile IP 9 draft-ietf-mobileip-qos-requirements-01.txt 11 Status of This Memo 13 This document is an Internet-Draft and is in full conformance 14 with all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or made obsolete by other 23 documents at any time. It is inappropriate to use Internet-Drafts 24 as reference material or to cite them other than as "work in 25 progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Copyright Notice 34 Copyright (c) The Internet Society (2001). All rights reserved. 36 Abstract 38 Mobile IP protocol ensures correct routing of packets to mobile 39 node as the mobile node changes its point of attachment with the 40 Internet. However, it is also required to provide proper QoS 41 forwarding treatment to mobile node's packet stream at the 42 intermediate nodes in the network, so that QoS-sensitive IP 43 services can be supported over Mobile IP. This document describes 44 requirements of an IP QoS mechanism for its satisfactory operation 45 with Mobile IP. 47 1 Introduction 49 Mobile IP is a technology that allows a "mobile node" (MN) to 50 change its point of attachment to the Internet while 51 communicating with the "correspondent node" (CN) using IP. The 52 formal description of Mobile IP can be found in [1, 2]. Mobile IP 53 primarily addresses the correct routing of packets to MN's current 54 point of attachment with the Internet. 56 It is also essential to provide proper Quality of Service (QoS) 57 forwarding treatment to the packets sent by or destined to MN 58 as they propagate along different routes in the network due to 59 node mobility. This document will identify the requirements that 60 Mobile IP places on an IP QoS mechanism. 62 1.1 Problem statement 64 When a MN using Mobile IP undergoes handover from one access 65 router to another, the path traversed by MN's packet stream in the 66 network may change. Such a change may be limited to a small 67 segment of the end-to-end path near the extremity, or it could 68 also have an end-to-end impact. Further, the packets belonging to 69 MN's ongoing session may start using the new care-of address after 70 handover. Hence, they may not be recognized by some forwarding 71 functions in the nodes even along that segment of the end-to-end 72 path that remains unaltered after handover. 73 Finally, handover may occur between the subnets that are under 74 different administrative control. 76 In the light of this scenario, it is essential to establish proper 77 QoS support for the MN's packet stream along the new packet path. 79 1.2 An approach for solving QoS problem in Mobile IP 81 There are four important steps involved in solving the QoS problem 82 for Mobile IP. They are as follows: (1) List the requirements that 83 Mobile IP places on the QoS mechanism, (2) Evaluate current IP QoS 84 solutions against the requirements, (3) Decide if current 85 solutions need to be extended, or if new ones need to be 86 defined, and (4) Depending on the result of step 3, define new 87 solutions or fix the old ones. 89 Of these, the first step, i.e. the requirements step, is addressed 90 in this draft. The last three steps are not dealt with here in 91 detail. However, so as to create useful insight into the Mobile IP 92 QoS problem, at times this document highlights the 93 shortcomings of some well known current proposals for 94 establishing QoS support for the packet stream in the network, 95 with respect to the requirements imposed by Mobile IP. 97 2 Terminology 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 101 this document are to be interpreted as described in RFC 2119. 103 3 Requirements of a QoS solution for Mobile IP 105 This section describes the requirements of a QoS solution for 106 Mobile IP. Conversely, note that only Mobile IP-specific 107 requirements are described here. We do not assume any particular 108 version (4 or 6) of IP while describing the requirements. 109 Solutions can be designed for IPv4 and IPv6 independently, or a 110 single solution can be designed to work with both versions. 112 In this document, we assume that the target access router for 113 MN's handover is already pinned down by other protocols. For 114 example, Seamoby working group has started work on candidate 115 access router discovery protocols [3]. Thus, any QoS-capability 116 specific negotiations that may affect the handover decision are 117 outside the scope of QoS solution as such, rather need to be 118 performed by candidate and target access router selection 119 protocols. 121 3.1 Performance requirements 123 1. Minimize the interruption in QoS at the time of handover: 125 At the time of handover, interruption in QoS would occur if the 126 packets sent by or destined to the MN arrive at the intermediate 127 node in the new packet path without that node having 128 information about their QoS forwarding requirement. Then, those 129 packets will receive default forwarding treatment. Such QoS 130 interruption MUST be minimized. A good metric for this performance 131 is the number of packets that may potentially get served with the "default" QoS at the 132 time of handover. The number of such packets MUST be minimized. 134 As an example, this performance metric is computed in [4] for the 135 case of end-to-end RSVP signaling [5] with Mobile IPv6. It is 136 shown there that when the end-to-end path of packets changes at 137 large after handover or when the care-of address changes after 138 handover, OPWA (One Pass With Advertisement) model of reservation 139 used by RSVP causes the latency of about one round-trip time 140 between the MN and the CN before QoS can be established along the 141 new packet path. In other words, the packets using the new care-of 142 address that would be released by the MN or the CN during one 143 round-trip time, after these nodes are ready to use the new 144 care-of address, may get default forwarding treatment at the 145 intermediate nodes. Such a latency in QoS programming may be 146 acceptable at the time of session initiation, but it is not 147 acceptable in the middle of an active session as would be the case 148 with handover. 150 2. Localize the QoS (re)establishment to the affected parts of the 151 packet path in the network: 153 In many cases, handover changes only a small segment of the 154 end-to-end path of MN's packet stream near the extremity. Then, 155 the QoS mechanism MUST limit the extent of QoS (re)establishment 156 to the affected segment of the end-to-end path only. 158 However, note that handover may sometimes cause the end-to-end 159 path of MN's packet stream in the network to change at large. This 160 may happen, for example, in the case of handover between different 161 administrative domains. If the QoS mechanism used to establish QoS 162 support for the MN's packet stream along the new packet path in 163 the network is based on the explicit end-to-end provisioning as 164 such, it MUST perform so at the time of such handover. 166 When the care-of address changes upon handover, it may be required 167 to perform some signaling even over the unchanged part of the 168 end-to-end path if the path contains any QoS mechanisms that use 169 IP address as a key to forwarding functions. Examples are 170 FILTER SPECs in the IntServ nodes or packet classifiers at the 171 edges of DiffServ networks. However, double provisioning of 172 resources over the unchanged part of the packet path 173 MUST be avoided. 175 Note that the QoS signaling protocol such as RSVP [6] can localize 176 the QoS signaling to the affected parts of the end-to-end path if 177 the care-of address does not change upon handover. However, if the 178 care-of address changes upon handover, RSVP as currently defined 179 [7] fails to localize the QoS signaling. In addition, it will 180 cause double reservations on the part of end-to-end path that 181 remains unchanged after handover. 183 3. Releasing after handover the QoS state (if any) along the old 184 packet path: 186 The QoS mechanism MUST provide some means (explicit or 187 timer-based) to release any QoS state along the old packet path 188 that is not required after handover. It is desirable that the 189 unwarranted QoS states, if any, along the old path are released as 190 quickly as possible at the time of handover. Note that, during 191 handover, the MN may not always get a chance to send explicit tear 192 down message along the old path because of the loss of link layer 193 connectivity with the old access router. 195 3.2 Interoperability requirements 197 1. Interoperability with mobility protocols: 199 A number of mobility protocols that are complementary to Mobile IP 200 are already defined or may be defined in future in IETF, 201 particularly in Mobile IP and Seamoby working groups. 202 Examples are Fast Handover [8, 9], Regional Registrations [10], 203 Hierarchical MIPv6 [11], Context Transfer [12] etc. The QoS 204 mechanism for Mobile IP SHOULD take advantage of these mobility 206 protocols for the optimized operation. However, the QoS scheme 207 MUST have provisions to accomplish its tasks even if one or more 208 of these mobility protocols are not used. 210 2. Interoperability with heterogeneous packet paths as 211 regards QoS paradigms: 213 The new path after handover, of the MN's packet stream, may 214 traverse network domains employing different QoS paradigms 215 compared to those along the old path. The QoS mechanism for 216 Mobile IP MUST be able to establish proper QoS forwarding 217 treatment for the MN's packet stream along the packet paths 218 deploying different QoS paradigms (best current practices), 219 in a manner consistent with the QoS mechanism deployed along 220 those paths. 222 As an illustration, suppose that the MN is currently attached to 223 an access router which is the edge router of a DiffServ network, 224 and that the packet classifier and traffic policer for the MN's 225 flows are presently programmed in this access router. Now, suppose 226 that the MN needs to be handed over to the access router which is 227 at the edge of an IntServ network. The new access network would 228 expect the exchange of RSVP messages so that proper QoS 229 forwarding treatment can be established for the MN's packet stream 230 in that access network. QoS mechanism for Mobile IP MUST have 231 provisions to handle such heterogeneity as regards the QoS 232 mechanisms deployed along different packet paths. 234 3.3 Miscellaneous requirements 236 1. QoS support along multiple packet paths: 238 After MN undergoes handover from one access router to another, 239 potentially, there could be multiple paths over which MN's packet 240 may propagate. Examples of these path are: route-optimized path 241 between the MN and its CN, triangle route via Home Agent (HA), 242 temporary tunnel between old and new access routers, reverse 243 tunnel from the new access router (Foreign Agent) to HA etc. A QoS 244 mechanism SHOULD be able to support QoS along the different 245 potential packet paths. However, whether all paths are supported 246 or only a subset of them is supported will be determined by 247 external mechanisms such as mobility management, policy, location 248 privacy requirement and so on. Further, the same QoS mechanism 249 may not be able to support all these paths. 251 2. Interactions with link-layer support for QoS: 253 The QoS mechanism MAY provide some information to the link 254 layers for them to support the required QoS. Since a vast number 255 of devices using Mobile IP will be connected to the Internet via 256 wireless links, QoS parameters relevant for wireless links, such 257 as error rate, MAY have to be included in the set of IP-level QoS 258 parameters to be possibly considered by the underlying link layer. 260 An example scenario will be two UDP streams requiring different 261 levels of error protection at the link layer. For such cases, an 262 IP-layer QoS mechanism may indicate some generic parameters such 263 as acceptable IP packet loss rate to link layers. 265 3.4. Standard requirements 267 The QoS solution for Mobile IP SHOULD satisfy standard 268 requirements such as scalability, security, conservation of 269 wireless bandwidth, low processing overhead on mobile terminals, 270 providing hooks for authorization and accounting, and robustness 271 against failures of any Mobile IP-specific QoS components in the 272 network. While it is not possible to set quantitative targets for 273 these desirable properties, the QoS solution MUST be evaluated 274 against these criteria. 276 4 Recommendation 278 In this document, we described the requirements of a QoS solution 279 for Mobile IP. The expectation is that the appropriate working 280 group will use this requirements document to provide a QoS 281 solution for Mobile IP. 283 5 Acknowledgment 285 I would like to acknowledge the participants of the mailing list 286 that was set up to discuss the above requirements. Their 287 contributions and active participation in the discussion on the 288 mailing list were very useful in the preparation of this document. 289 Special thanks are due to, in alphabetical order, Marc Greis 290 (Nokia), Glenn Morrow (Nortel), Phil Roberts (Megisto) and Michael 291 Thomas (Cisco) for their comments during the preparation of 292 this document. 294 6 References 296 [1] IP Mobility Support, C. Perkins (Editor), RFC 2002, October 1996. 298 [2] Mobility Support in IPv6, D. Johnson and C. Perkins, 299 draft-ietf-mobileip-ipv6-13.txt, 300 work in progress, November 2000. 302 [3] Issues in candidate access router discovery for seamless IP 303 handoffs, D. Trossen et. al., 304 draft-ietf-seamoby-cardiscovery-issues-00.txt, 305 work in progress, July 2001. 307 [4] A Framework for QoS Support in Mobile IPv6, H. Chaskar and 308 R. Koodli, draft-chaskar-mobileip-qos-01.txt, 309 work in progress, March 2001. 311 [5] A Framework for Integrated Services Operation over Diffserv 312 Networks, Yoram Bernet et. al., RFC 2998, November 2000. 314 [6] Analysis of Mobile IP and RSVP Interactions, Michael Thomas, 315 draft-thomas-seamoby-rsvp-analysis-00.txt, 316 work in progress, February 2001. 318 [7] Resource ReSerVation Protocol -- Version 1 Functional 319 Specification, R. Braden et. al., RFC 2750, September 1997. 321 [8] Low Latency Handoffs in Mobile IPv4, MIPv4 Handoffs Design Team, 322 draft-ietf-mobileip-lowlatency-handoffs-v4-00.txt, 323 work in progress, February 2001. 325 [9] Fast Handovers for Mobile IPv6, MIPv6 Handover Design Team, 326 draft-ietf-mobileip-fast-mipv6-01.txt, 327 work in progress, April 2001. 329 [10] Mobile IPv6 Regional Registrations, J. Malinen, Frank Le , and 330 C. Perkins, draft-malinen-mobileip-regreg6-01.txt, 331 work in progress, March 2001. 333 [11] Hierarchical MIPv6 Mobility Management, H. Soliman, 334 C. Castelluccia, K. El-Malki, and L. Bellier, 335 draft-ietf-mobileip-hmipv6-02.txt, 336 work in progress, February 2001. 338 [12] Context Transfer Framework for Seamless Mobility, R. Koodli and 339 C. Perkins, draft-koodli-seamoby-ctv6-00.txt, 340 work in progress, February 2001. 342 7 Addresses 344 The working group can be contacted via the current chairs: 346 Basavaraj Patil Phil Roberts 347 Nokia Corporation Megisto 348 6000 Connection Drive 20251 Century Blvd, Suite 120 349 Irving, Texas 75039, USA Germantown, MD 20874 350 Phone: +1 972-894-6709 Phone: +1 847-202-9314 351 EMail: Basavaraj.Patil@nokia.com EMail: proberts@MEGISTO.com 353 Questions about this memo can be directed to the editor: 355 Hemant Chaskar 356 Nokia Research Center 357 5 Wayside Road 358 Burlington, MA 01803, USA 359 Phone: +1 781-993-3785 360 EMail: hemant.chaskar@nokia.com 362 Appendix: Changes Made from 00 Version 364 Few editorial changes were made from 00 version based on the 365 working group feedback received on the Mobile IP mailing list. 367 1. A clarification is added at the beginning of Section 3, which 368 states that QoS-capability negotiations that may affect 369 handover decision are outside the scope of this document. 370 2. Section 3.1.2 was reworded for better clarity. 371 3. Section 3.2.2 was reworded for better clarity. 372 4. Section 3.4 is now called "Standard Requirements" rather than 373 "Obvious Requirements". 374 5. Section 4 is now called "Recommendation" rather than 375 "Concluding Remarks".