idnits 2.17.1 draft-ietf-mobileip-qos-requirements-02.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. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 21 has weird spacing: '... months and m...' == Line 28 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 (10 February 2002) is 8111 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: Non-RFC (?) normative reference: 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' ** Downref: Normative reference to an Informational draft: draft-ietf-seamoby-context-transfer-problem-stat (ref. '12') Summary: 13 errors (**), 0 flaws (~~), 6 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IETF Mobile IP Working Group Hemant Chaskar 2 INTERNET-DRAFT Editor 3 Nokia Research Center 4 10 February 2002 6 Requirements of a QoS Solution for Mobile IP 8 draft-ietf-mobileip-qos-requirements-02.txt 10 Status of This Memo 12 This document is an Internet-Draft and is in full conformance 13 with all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or made obsolete by other 22 documents at any time. It is inappropriate to use Internet-Drafts 23 as reference material or to cite them other than as "work in 24 progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Copyright Notice 33 Copyright (c) The Internet Society (2001). All rights reserved. 35 Abstract 37 Mobile IP ensures correct routing of packets to mobile node as the 38 mobile node changes its point of attachment to the Internet. 39 However, it is also required to provide proper QoS forwarding 40 treatment to mobile node's packet stream at the intermediate nodes 41 in the network, so that QoS-sensitive IP services can be supported 42 over Mobile IP. This document describes requirements for an IP QoS 43 mechanism for its satisfactory operation with Mobile IP. 45 1 Introduction 47 Mobile IP is a technology that allows a "mobile node" (MN) to 48 change its point of attachment to the Internet while 49 communicating with the "correspondent node" (CN) using IP. The 50 formal description of Mobile IP can be found in [1, 2]. Mobile IP 51 primarily addresses the correct routing of packets to MN's current 52 point of attachment with the Internet. 54 It is also essential to provide proper Quality of Service (QoS) 55 forwarding treatment to the packets sent by or destined to MN as 56 they propagate along different routes in the network due to node 57 mobility. This document will identify the requirements that Mobile 58 IP places on an IP QoS mechanism. 60 1.1 Problem statement 62 When an MN using Mobile IP undergoes handover from one access 63 router to another, the path traversed by MN's packet stream in the 64 network may change. Such a change may be limited to a small 65 segment of the end-to-end path near the extremity, or it could 66 also have an end-to-end impact. Further, the packets belonging to 67 MN's ongoing session may start using a new care-of address after 68 handover. Hence, they may not be recognized by some forwarding 69 functions in the nodes even along that segment of the end-to-end 70 path that remains unaltered after handover. Finally, handover may 71 occur between the subnets that are under different 72 administrative control. 74 In the light of this scenario, it is essential to establish proper 75 QoS support for the MN's packet stream along the new packet path. 77 1.2 An approach for solving QoS problem in Mobile IP 79 There are four important steps involved in solving the QoS problem 80 for Mobile IP. They are as follows: (1) List the requirements that 81 Mobile IP places on the QoS mechanism, (2) Evaluate current IP QoS 82 solutions against these requirements, (3) Decide if current 83 solutions need to be extended, or if new ones need to be defined, 84 and (4) Depending on the result of step 3, define new solutions or 85 fix the old ones. 87 Of these, the first step, i.e. the requirements step, is addressed 88 in this draft. The last three steps are not dealt with here in 89 detail. However, so as to create useful insight into the Mobile IP 90 QoS problem, at times this document highlights the shortcomings of 91 some well known current proposals for establishing QoS support for 92 the packet stream in the network, when directly used with 93 Mobile IP. 95 2 Terminology 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 99 this document are to be interpreted as described in RFC 2119. 101 3 Requirements of a QoS solution for Mobile IP 103 This section describes the requirements for a QoS solution for its 104 satisfactory operation with Mobile IP. Conversely, note that only 105 Mobile IP-specific requirements are described here. We do not 106 assume any particular version (4 or 6) of IP while describing the 107 requirements. Solutions can be designed for IPv4 and IPv6 108 independently, or a single solution can be designed to work with 109 both versions. 111 In this document, we assume that the target access router for 112 MN's handover is already pinned down by other protocols. For 113 example, Seamoby working group has started work on the candidate 114 access router discovery protocols [3]. Thus, any QoS-capability 115 specific negotiations that may affect the handover decision are 116 outside the scope of QoS solution as such, rather need to be 117 performed by candidate and target access router selection 118 protocols. 120 3.1 Performance requirements 122 1. Minimize the interruption in QoS at the time of handover: 124 At the time of handover, interruption in QoS would occur if the 125 packets sent by or destined to the MN arrive at the intermediate 126 node in the new packet path without that node having information 127 about their QoS forwarding requirement. Then, those packets will 128 receive default forwarding treatment. Such QoS interruption MUST 129 be minimized. A good metric for this performance is the number of 130 packets that may potentially get served with the "default" QoS at 131 the time of handover. The number of such packets MUST be minimized. 133 As an example, this performance metric is computed in [4] for the 134 case of end-to-end RSVP signaling [5] with Mobile IPv6. It is 135 shown there that when the end-to-end path of packets changes at 136 large after handover or when the care-of address changes after 137 handover, OPWA (One Pass With Advertisement) model of reservation 138 used by RSVP causes the latency of about one round-trip time 139 between the MN and the CN before QoS can be established along the 140 new packet path. In other words, the packets using the new care-of 141 address that would be released by the MN or the CN during one 142 round-trip time, after these nodes are ready to use the new 143 care-of address, may get default forwarding treatment at the 144 intermediate nodes. Such a latency in QoS programming may be 145 acceptable at the time of session initiation, but it is not 146 acceptable in the middle of an active session as would be the case 147 with handover. 149 2. Localize the QoS (re)establishment to the affected parts of the 150 packet path in the network: 152 In many cases, handover changes only a small segment of the 153 end-to-end path of MN's packet stream near the extremity. Then, 154 the QoS mechanism MUST limit the extent of QoS (re)establishment 155 to the affected segment of the end-to-end path only. 157 However, note that handover may sometimes cause the end-to-end 158 path of MN's packet stream in the network to change at large. This 159 may happen, for example, in the case of handover between different 160 administrative domains. If the QoS mechanism used to establish QoS 161 support for the MN's packet stream along the new packet path in 162 the network is based on the explicit end-to-end provisioning as 163 such, it MUST perform so at the time of such handover. 165 When the care-of address changes upon handover, it may be required 166 to perform some signaling even over the unchanged part of the 167 end-to-end path if the path contains any QoS mechanisms that use 168 IP address as a key to forwarding functions. Examples are 169 FILTER SPECs in the IntServ nodes or packet classifiers at the 170 edges of DiffServ networks. However, double provisioning of 171 resources over the unchanged part of the packet path 172 MUST be avoided. 174 Note that the QoS signaling protocol such as RSVP [6] can localize 175 the QoS signaling to the affected parts of the end-to-end path if 176 the care-of address does not change upon handover. However, if the 177 care-of address changes upon handover, RSVP as currently defined 178 [7] fails to localize the QoS signaling. In addition, it will 179 cause double reservations on the part of end-to-end path that 180 remains unchanged after handover. 182 3. Releasing after handover the QoS state (if any) along the old 183 packet path: 185 The QoS mechanism MUST provide some means (explicit or 186 timer-based) to release any QoS state along the old packet path 187 that is not required after handover. It is desirable that the 188 unwarranted QoS states, if any, along the old path are released as 189 quickly as possible at the time of handover. Note that, during 190 handover, the MN may not always get a chance to send explicit tear 191 down message along the old path because of the loss of link layer 192 connectivity with the old access router. 194 3.2 Interoperability requirements 196 1. Interoperability with mobility protocols: 198 A number of mobility protocols that are complementary to Mobile IP 199 are already defined or may be defined in future in IETF, 200 particularly in Mobile IP and Seamoby working groups. 201 Examples are Fast Handover [8, 9], Regional Registrations [10], 202 Hierarchical MIPv6 [11], Context Transfer [12] etc. The QoS 203 mechanism for Mobile IP SHOULD take advantage of these mobility 204 protocols for the optimized operation. However, the QoS scheme 205 MUST have provisions to accomplish its tasks even if one or more 206 of these mobility protocols are not used. 208 2. Interoperability with heterogeneous packet paths as 209 regards QoS paradigms: 211 The new path after handover, of the MN's packet stream, may 212 traverse network domains employing different QoS paradigms 213 compared to those along the old path. The QoS mechanism for Mobile 214 IP SHOULD be able to establish proper QoS forwarding treatment for 215 the MN's packet stream along the packet paths deploying different 216 QoS paradigms (best current practices), in a manner consistent 217 with the QoS mechanism deployed along those paths. 219 As an illustration, suppose that the MN is currently attached to 220 an access router which is the edge router of a DiffServ network, 221 and that the packet classifier and traffic policer for the MN's 222 flows are presently programmed in this access router. Now, suppose 223 that the MN needs to be handed over to the access router which is 224 at the edge of an IntServ network. The new access network would 225 expect the exchange of RSVP messages so that proper QoS 226 forwarding treatment can be established for the MN's packet stream 227 in that access network. QoS mechanism for Mobile IP SHOULD have 228 provisions to handle such heterogeneity as regards the QoS 229 mechanisms deployed along different packet paths. 231 3.3 Miscellaneous requirements 233 1. QoS support along multiple packet paths: 235 After MN undergoes handover from one access router to another, 236 potentially, there could be multiple paths over which MN's packet 237 may propagate. Examples of these path are: route-optimized path 238 between the MN and its CN, triangle route via Home Agent (HA), 239 temporary tunnel between old and new access routers, reverse 240 tunnel from the new access router (Foreign Agent) to HA etc. A QoS 241 mechanism SHOULD be able to support QoS along the different 242 potential packet paths. However, whether all paths are supported 243 or only a subset of them is supported will be determined by 244 external mechanisms such as mobility management, policy, location 245 privacy requirement and so on. Further, the same QoS mechanism 246 may not be able to support all these paths. 248 2. Interactions with link-layer support for QoS: 250 The QoS mechanism MAY provide some information to the link 251 layers for them to support the required QoS. Since a vast number 252 of devices using Mobile IP will be connected to the Internet via 253 wireless links, QoS parameters relevant for wireless links, such 254 as error rate, MAY have to be included in the set of IP-level QoS 255 parameters to be possibly considered by the underlying link layer. 257 An example scenario will be two UDP streams requiring different 258 levels of error protection at the link layer. For such cases, an 259 IP-layer QoS mechanism may indicate some generic parameters such 260 as acceptable IP packet loss rate to link layers. 262 3.4. Standard requirements 264 The QoS solution for Mobile IP SHOULD satisfy standard 265 requirements such as scalability, security, conservation of 266 wireless bandwidth, low processing overhead on mobile terminals, 267 providing hooks for authorization and accounting, and robustness 268 against failures of any Mobile IP-specific QoS components in the 269 network. While it is not possible to set quantitative targets for 270 these desirable properties, the QoS solution MUST be evaluated 271 against these criteria. 273 4 Recommendation 275 In this document, we described the requirements for a QoS solution 276 for its satisfactory operation with Mobile IP. The expectation is 277 that the appropriate working group will use this requirements 278 document to provide a QoS solution for Mobile IP. 280 5 Acknowledgment 282 I would like to acknowledge the participants of the mailing list 283 that was set up to discuss the above requirements. Their 284 contributions and active participation in the discussion on the 285 mailing list were very useful in the preparation of this document. 286 Special thanks are due to, in alphabetical order, Marc Greis 287 (Nokia), Glenn Morrow (Nortel), Phil Roberts (Megisto) and Michael 288 Thomas (Cisco) for their input during the preparation of 289 this document. 291 6 References 293 [1] IP mobility support, C. Perkins (Editor), RFC 2002, October 1996. 295 [2] Mobility support in IPv6, D. Johnson and C. Perkins, 296 draft-ietf-mobileip-ipv6-13.txt, 297 work in progress, November 2000. 299 [3] Issues in Candidate Access Router discovery for seamless IP 300 handoffs, D. Trossen et. al., 301 draft-ietf-seamoby-cardiscovery-issues-00.txt, 302 work in progress, July 2001. 304 [4] QoS support in Mobile IP version 6, H. Chaskar and R. Koodli, 305 IEEE Broadband Wireless Summit (Networld+Interop), May 2001. 307 [5] A Framework for Integrated Services operation over Diffserv 308 networks, Y. Bernet et. al., RFC 2998, November 2000. 310 [6] Analysis of Mobile IP and RSVP interactions, M. Thomas, 311 draft-thomas-seamoby-rsvp-analysis-00.txt, 312 work in progress, February 2001. 314 [7] Resource ReSerVation Protocol -- Version 1 Functional 315 Specification, R. Braden et. al., RFC 2750, September 1997. 317 [8] Low latency handoffs in Mobile IPv4, MIPv4 Handoffs Design Team, 318 draft-ietf-mobileip-lowlatency-handoffs-v4-00.txt, 319 work in progress, February 2001. 321 [9] Fast handovers for Mobile IPv6, MIPv6 Handover Design Team, 322 draft-ietf-mobileip-fast-mipv6-01.txt, 323 work in progress, April 2001. 325 [10] Mobile IPv6 Regional Registrations, J. Malinen, Frank Le, and 326 C. Perkins, draft-malinen-mobileip-regreg6-01.txt, 327 work in progress, March 2001. 329 [11] Hierarchical MIPv6 mobility management, H. Soliman, 330 C. Castelluccia, K. El-Malki, and L. Bellier, 331 draft-ietf-mobileip-hmipv6-02.txt, 332 work in progress, February 2001. 334 [12] Problem description: Reasons for performing context transfers 335 between nodes in an IP Access Network, edited by J. Kempf, 336 draft-ietf-seamoby-context-transfer-problem-stat-04.txt, 337 work in progress, May 2002. 339 7 Addresses 341 The working group can be contacted via the current chairs: 343 Basavaraj Patil Phil Roberts 344 Nokia Corporation Megisto 345 6000 Connection Drive 20251 Century Blvd, Suite 120 346 Irving, Texas 75039, USA Germantown, MD 20874 347 Phone: +1 972-894-6709 Phone: +1 847-202-9314 348 EMail: Basavaraj.Patil@nokia.com EMail: proberts@MEGISTO.com 350 Questions about this memo can be directed to the editor: 352 Hemant Chaskar 353 Nokia Research Center 354 5 Wayside Road 355 Burlington, MA 01803, USA 356 Phone: +1 781-993-3785 357 EMail: hemant.chaskar@nokia.com 359 Appendix: Changes Made from 00 Version 361 Few editorial changes were made from 00 version based on the 362 working group feedback received on the Mobile IP mailing list. 364 1. A clarification is added at the beginning of Section 3, which 365 states that QoS-capability negotiations that may affect 366 handover decision are outside the scope of this document. 367 2. Section 3.1.2 was reworded for better clarity. 368 3. Section 3.2.2 was reworded for better clarity. 369 4. Section 3.4 is now called "Standard Requirements" rather than 370 "Obvious Requirements". 371 5. Section 4 is now called "Recommendation" rather than 372 "Concluding Remarks". 374 Changes Made from 01 Version 376 The following changes were made from 01 version in response to 377 IESG comments. 379 1. Requirement 3.2(2) is changed from MUST to SHOULD. 380 2. IESG was concerned about the references to too many individual 381 submissions in the 01 version. Now, individual submission 382 references 4 and 12 in 01 version are replaced by a reference 383 to IEEE conference paper and Seamoby WG document, respectively. 384 However, no alternatives could be found for 6, 10 and 11. 385 Nevertheless the content in these individual submissions is 386 important to understand certain requirements. Hence, these 387 references are not removed.