idnits 2.17.1 draft-ietf-mobileip-qos-requirements-00.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: ---------------------------------------------------------------------------- ** 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 (June 2001) is 8349 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) == Unused Reference: '6' is defined on line 310, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2002 (ref. '1') (Obsoleted by RFC 3220) == Outdated reference: A later version (-24) exists of draft-ietf-mobileip-ipv6-13 -- Possible downref: Normative reference to a draft: ref. '3' ** Downref: Normative reference to an Informational RFC: RFC 2998 (ref. '4') -- Possible downref: Normative reference to a draft: ref. '5' == 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. '7') -- No information found for draft-ietf-mobileip-fast-mipv6 - is the name correct? -- Possible downref: Normative reference to a draft: ref. '8' -- Possible downref: Normative reference to a draft: ref. '9' -- No information found for draft-ietf-mobileip-hmipv6 - is the name correct? -- Possible downref: Normative reference to a draft: ref. '10' -- No information found for draft-koodli-seamoby-ctv6 - is the name correct? -- Possible downref: Normative reference to a draft: ref. '11' Summary: 10 errors (**), 0 flaws (~~), 6 warnings (==), 11 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 Expires: November 2001 Nokia Research Center 4 June 2001 6 Requirements of a QoS Solution for Mobile IP 8 draft-ietf-mobileip-qos-requirements-00.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 protocol ensures correct routing of packets to mobile 38 node as the mobile node changes its point of attachment with the 39 Internet. However, it is also required to provide proper QoS 40 forwarding treatment to mobile node's packet stream at the 41 intermediate nodes in the network, so that QoS-sensitive IP 42 services can be supported over Mobile IP. This document describes 43 requirements of an IP QoS mechanism for its satisfactory operation 44 with Mobile IP. 46 1.0 Introduction 48 Mobile IP is a technology that allows a "mobile node" (MN) to 49 change its point of attachment to the Internet while 50 communicating with the "correspondent node" (CN) using IP. The 51 formal description of Mobile IP can be found in [1, 2]. Mobile IP 52 primarily addresses the correct routing of packets to MN's current 53 point of attachment with the Internet. 55 It is also essential to provide proper Quality of Service (QoS) 56 forwarding treatment to the packets sent by or destined to MN 57 as they propagate along different routes in the network due to 58 node mobility. This document will identify the requirements that 59 Mobile IP places on an IP QoS mechanism. 61 1.1 Problem statement 63 When a MN using Mobile IP undergoes handover from one access 64 router to another, the path traversed by MN's packet stream in the 65 network may change. Such a change may be limited to a small 66 segment of the end-to-end path near the extremity, or it could 67 also have an end-to-end impact. Further, the packets belonging to 68 MN's ongoing session may start using the new care-of address after 69 handover, and hence, may not be recognized by some forwarding 70 functions along the old path that use IP address as a key. 71 Finally, handover may occur between the subnets that are under 72 different administrative control. 74 In the light of this scenario, it is essential to establish proper 75 QoS support at the intermediate nodes in the new end-to-end path 76 of the MN's packet stream. 78 1.2 An approach for solving QoS problem in Mobile IP 80 There are four important steps involved in solving the QoS problem 81 for Mobile IP. They are as follows: (1) List the requirements that 82 Mobile IP places on the QoS mechanism, (2) Evaluate current IP QoS 83 solutions against the requirements, (3) Decide if current 84 solutions need to be extended, or if new ones need to be 85 defined, and (4) Depending on the result of step 3, define new 86 solutions or fix the old ones. 88 Of these, the first step, i.e. the requirements step, is addressed 89 in this draft. The last three steps are not dealt with here in 90 detail. However, so as to create useful insight into the Mobile IP 91 QoS problem, wherever relevant, this draft highlights the 92 shortcomings of some popular current practices (proposals) for 93 establishing QoS support along the packet path, in the light of 94 the requirements imposed by Mobile IP. 96 2 0 Terminology 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 100 this document are to be interpreted as described in RFC 2119. 102 3 0 Requirements of a QoS solution for Mobile IP 104 This section describes the requirements of a QoS solution for 105 Mobile IP. Conversely, note that only Mobile IP-specific 106 requirements are described here. We do not assume any particular 107 version (4 or 6) of IP while describing the requirements. 108 Solutions can be designed for IPv4 and IPv6 independently, or a 109 single solution can be designed to work with both versions. 111 3.1 Performance requirements 113 1. Minimize the interruption in QoS at the time of handover: 115 At the time of handover, interruption in QoS would occur if the 116 packets sent by or destined to the MN arrive at the intermediate 117 node in the new end-to-end packet path without that node having 118 information about their QoS forwarding requirement. Then, those 119 packets will receive default forwarding treatment. Such QoS 120 interruption MUST be minimized. A good metric for this performance 121 is the number of packets that get served with "default" QoS at the 122 time of handover. The number of such packets MUST be minimized. 124 As an example, this performance metric is computed in [3] for the 125 case of end-to-end RSVP signaling [4] with Mobile IPv6. It is 126 shown there that when the end-to-end path of packets changes at 127 large after handover or when the care-of address changes after 128 handover, OPWA (One Pass With Advertisement) model of reservation 129 used by RSVP causes the latency of about one round-trip time 130 between the MN and the CN before QoS can be established along the 131 new packet path. In other words, the packets using the new care-of 132 address that would be released by the MN or the CN during one 133 round-trip time, after these nodes are ready to use the new 134 care-of address, may get default forwarding treatment at the 135 intermediate nodes. Such a latency in QoS programming may be 136 acceptable at the time of session initiation, but is not 137 acceptable in the middle of an active session as would be the case 138 with handover. 140 2. Localize the QoS (re)establishment to the affected parts of the 141 packet path in the network: 143 In many cases, handover changes only a small segment of the 144 end-to-end path of MN's packet stream near the extremity. Then, 145 the QoS mechanism MUST limit the extent of QoS (re)establishment 146 to the affected segment of the end-to-end path only. Of course, if 147 the end-to-end path changes at large after handover, the QoS 148 mechanism MUST be able to address that in a manner that is 149 consistent with the QoS scheme(s) used along the new 150 end-to-end packet path. 152 Note that the QoS signaling protocol such as RSVP [5] can localize 153 the QoS signaling to the affected parts of the end-to-end path if 154 the care-of address does not change upon handover. However, if the 155 care-of address changes upon handover, RSVP as currently defined 156 fails to localize the QoS signaling [see 6]. In addition, it will 157 cause double reservations on the part of end-to-end path that 158 remains unchanged after handover. 160 When the care-of address changes upon handover, it may be 161 required to perform some signaling even over the unchanged part of 162 the end-to-end path if the path contains any QoS mechanisms that 163 use IP address as a key to forwarding functions. Examples are 164 FILTER SPECs in the IntServ nodes or packet classifiers at the 165 edges of DiffServ networks. However, double provisioning of 166 resources over the unchanged part of the packet path 167 MUST be avoided. 169 3. Releasing after handover the QoS state (if any) along the old 170 packet path: 172 The QoS mechanism MUST provide some means (explicit or 173 timer-based) to release any QoS state along the old packet path 174 that is not required after handover. It is desirable that the 175 unwarranted QoS states, if any, along the old path are released as 176 quickly as possible at the time of handover. Note that, during 177 handover, the MN may not always get a chance to send explicit tear 178 down message along the old path because of the loss of link layer 179 connectivity with the old access router. 181 3.2 Interoperability requirements 183 1. Interoperability with mobility protocols: 185 A number of mobility protocols that are complementary to Mobile IP 186 are already defined or may be defined in future in IETF, 187 particularly in Mobile IP and Seamless Mobility working groups. 188 Examples are Fast Handover [7, 8], Regional Registrations [9], 189 Hierarchical MIPv6 [10], Context Transfer [11] etc. The QoS 190 mechanism for Mobile IP SHOULD take advantage of these mobility 191 protocols for optimized operation. However, the QoS scheme MUST 192 have provisions to accomplish its tasks even if one or more of 193 these mobility protocols are not used. 195 2. Interoperability with heterogeneous end-to-end packet paths as 196 regards QoS paradigms: 198 The new end-to-end path of MN's packet stream may encounter 199 network domains employing a variety of QoS paradigms, such as 200 IntServ, DiffServ and MPLS. Each of the networks/routers along 201 this path may require a different kind of information about the 202 MN's packet stream, so that proper QoS forwarding treatment can 203 be established for the MN's packet stream. The QoS mechanism for 204 Mobile IP MUST be able to establish proper QoS forwarding 205 treatment for the MN's packet stream in these QoS-heterogeneous 206 network domains in the new end-to-end path. 208 As an illustration, suppose that the MN is currently attached to 209 an access router which is the edge router of a DiffServ network, 210 and that the packet classifier and traffic policer for the MN's 211 flows are somehow programmed in this access router. Further, 212 assume that the QoS policy in this access network takes care of 213 SLAs with other networks that it attaches to. Now, suppose that 214 the MN needs to be handed over to the access router which is at 215 the edge of an IntServ network. The new access network would 216 expect the exchange of RSVP messages so that proper QoS 217 forwarding treatment can be established for the MN's packet stream 218 in that access network. Here is another example of 219 cross-QoS-technology handover. Suppose that the MN is currently 220 attached to an access router that is a part of access network X 221 and is to be handed over to the access router that is a part of 222 access network Y. In network X, the access router acts as a proxy 223 (and possibly communicates with some QoS agent in the network) to 224 program (possibly end-to-end) QoS forwarding treatment for the 225 MN's packet stream. On the other hand, network Y expects the end 226 hosts attached to it to send explicit QoS request messages along 227 the data path. 229 The QoS solution for Mobile IP MUST be able to establish QoS 230 support for MN's packet stream over the packet paths that use 231 diverse (best current practices) end-to-end QoS mechanisms. 233 3.3 Miscellaneous requirements 235 1. QoS support along multiple paths: 237 After MN undergoes handover from one access router to another, 238 potentially, there could be multiple paths over which MN's packet 239 may propagate. Examples of these path are: route-optimized path 240 between the MN and its CN, triangle route via Home Agent (HA), 241 temporary tunnel between old and new access routers etc. A QoS 242 mechanism SHOULD be able to support QoS along the different 243 potential packet paths. However, whether all paths are supported 244 or only a subset of them is supported will be determined by 245 external mechanisms such as, say, mobility management, policy, 246 location privacy requirement etc. Further, the same QoS mechanism 247 may not be able to support all the three alternatives. 249 2. Interactions with link-layer support for QoS: 251 The QoS mechanism MAY provide some information to the link 252 layers for them to support the required QoS. Since a vast number 253 of devices using Mobile IP will be connected to the Internet via 254 wireless links, wireless link significant QoS parameters such as 255 error rate MAY have to be included in the set of QoS parameters to 256 be possibly considered and supported by the underlying link layer. 258 An example scenario will be two UDP streams requiring different 259 levels of error protection at the link layer. For such cases, an 260 IP-layer QoS mechanism may indicate some generic parameters such 261 as acceptable IP packet loss rate to link layers. 263 3.4. Obvious requirements 265 The QoS solution for Mobile IP SHOULD satisfy obvious requirements 266 such as scalability, security, conservation of wireless bandwidth, 267 low processing overhead on mobile terminals, providing hooks for 268 authorization and accounting, and robustness against failures of 269 any Mobile IP-specific QoS components in the network. While it is 270 not possible to set quantitative targets for these desirable 271 properties, the QoS solution MUST be evaluated against these 272 criteria. 274 4.0 Concluding Remarks 276 In this document, we described the requirements of a QoS solution 277 for Mobile IP. The expectation is that the appropriate working 278 group will use this requirements document to provide a QoS 279 solution for Mobile IP. 281 5.0 Acknowledgment 283 I would like to acknowledge the participants of the mailing list 284 that was set up to discuss the above requirements. Their 285 contributions and active participation in the discussion on the 286 mailing list were very useful in the preparation of this document. 287 Special thanks are due to, in alphabetical order, Marc Greis 288 (Nokia), Glenn Morrow (Nortel), Phil Roberts and Michael Thomas 289 (Cisco) for their comments during the preparation of this document. 291 6.0 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] A Framework for QoS Support in Mobile IPv6, H. Chaskar and 300 R. Koodli, draft-chaskar-mobileip-qos-01.txt, 301 work in progress, March 2001. 303 [4] A Framework for Integrated Services Operation over Diffserv 304 Networks, Yoram Bernet et. al., RFC 2998, November 2000. 306 [5] Analysis of Mobile IP and RSVP Interactions, Michael Thomas, 307 draft-thomas-seamoby-rsvp-analysis-00.txt, 308 work in progress, February 2001. 310 [6] Resource ReSerVation Protocol -- Version 1 Functional 311 Specification, R. Braden et. al., RFC 2750, September 1997. 313 [7] Low Latency Handoffs in Mobile IPv4, MIPv4 Handoffs Design Team, 314 draft-ietf-mobileip-lowlatency-handoffs-v4-00.txt, 315 work in progress, February 2001. 317 [8] Fast Handovers for Mobile IPv6, MIPv6 Handover Design Team, 318 draft-ietf-mobileip-fast-mipv6-01.txt, 319 work in progress, April 2001. 321 [9] Mobile IPv6 Regional Registrations, J. Malinen, Frank Le , and 322 C. Perkins, draft-malinen-mobileip-regreg6-01.txt, 323 work in progress, March 2001. 325 [10] Hierarchical MIPv6 Mobility Management, H. Soliman, 326 C. Castelluccia, K. El-Malki, and L. Bellier, 327 draft-ietf-mobileip-hmipv6-02.txt, 328 work in progress, February 2001. 330 [11] Context Transfer Framework for Seamless Mobility, R. Koodli and 331 C. Perkins, draft-koodli-seamoby-ctv6-00.txt, 332 work in progress, February 2001. 334 7.0 Addresses 336 The working group can be contacted via the current chairs: 338 Basavaraj Patil Phil Roberts 339 Nokia Corporation 340 6000 Connection Drive 20251 Century Blvd 341 M/S M8-540 Suite 120 342 Irving, Texas 75039, USA Germantown, MD 20874 343 Phone: +1 972-894-6709 Phone: +1 847-202-9314 344 EMail: Basavaraj.Patil@nokia.com EMail: proberts@MEGISTO.com 346 Questions about this memo can be directed to the authors: 348 Hemant Chaskar 349 Nokia Research Center 350 5 Wayside Road 351 Burlington, MA 01803, USA 352 Phone: +1 781-993-3785 353 EMail: hemant.chaskar@nokia.com