idnits 2.17.00 (12 Aug 2021) /tmp/idnits21897/draft-tkn-nsis-qosbinding-mipv6-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: ---------------------------------------------------------------------------- == 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 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 141 has weird spacing: '...t alone to pr...' == Line 142 has weird spacing: '...uilt on the w...' == Line 143 has weird spacing: '... [7] to overc...' == Line 193 has weird spacing: '...olution among...' == Line 210 has weird spacing: '...rements and t...' == (17 more instances...) -- 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 (January 15, 2002) is 7430 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: '9' is defined on line 910, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 917, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 924, but no explicit reference was found in the text Unexpected reference format, failed extracting the RFC number: [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC (Best Current Practice) 2119, March 1997. -- Possible downref: Non-RFC (?) normative reference: ref. '1' == Outdated reference: A later version (-03) exists of draft-ietf-mobileip-qos-requirements-01 ** Downref: Normative reference to an Informational draft: draft-ietf-mobileip-qos-requirements (ref. '2') -- No information found for draft-koodli-seamoby-ctv6 - is the name correct? -- Possible downref: Normative reference to a draft: ref. '3' == Outdated reference: draft-ietf-mobileip-ipv6 has been published as RFC 3775 ** Obsolete normative reference: RFC 2460 (ref. '5') (Obsoleted by RFC 8200) -- No information found for draft-ietf-mobileip-hmipv6 - is the name correct? -- Possible downref: Normative reference to a draft: ref. '6' -- Possible downref: Normative reference to a draft: ref. '7' -- Possible downref: Normative reference to a draft: ref. '8' ** Downref: Normative reference to an Informational RFC: RFC 2475 (ref. '11') ** Downref: Normative reference to an Informational RFC: RFC 1633 (ref. '12') Summary: 7 errors (**), 0 flaws (~~), 13 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NSIS Working Group Xiaoming Fu 3 Internet-Draft Holger Karl 4 Expires: July 16, 2002 Andreas Festag 5 Guenter Schaefer 6 Technical University Berlin 7 Changpeng Fan 8 Cornelia Kappler 9 Mirko Schramm 10 Siemens AG 11 January 15, 2002 13 QoS-Conditionalized Binding Update in Mobile IPv6 14 draft-tkn-nsis-qosbinding-mipv6-00.txt 16 Status of this Memo 18 This document is an Internet-Draft and is in full conformance with 19 all provisions of Section 10 of RFC2026. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at http:// 32 www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on July 16, 2002. 39 Copyright Notice 41 Copyright (C) The Internet Society (2002). All Rights Reserved. 43 Abstract 45 This draft presents a scheme for QoS support in Mobile IPv6. A QoS 46 hop-by-hop option piggybacked in the binding messages is used for QoS 47 signaling. A handoff takes place only upon the availability of 48 sufficient resources along the new transmission path. This QoS- 49 conditionalized scheme builds upon the hierarchical modbile IPv6 50 protocol and is especially fit for local mobility, where the 51 signaling overhead is reduced. It also enables the mobile node to 52 flexibly choose among a set of available access points so that the 53 mobile node can transmit packets through a route which offers 54 satisfying QoS. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 6 60 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 8 61 4. Format of QoS option . . . . . . . . . . . . . . . . . . . . 11 62 5. Detailed description of QoS-conditionalized binding 63 update procedure . . . . . . . . . . . . . . . . . . . . . . 13 64 5.1 Mobile node . . . . . . . . . . . . . . . . . . . . . . . . 13 65 5.2 Router . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 66 6. Comparison of our scheme with the requirements draft . . . . 15 67 6.1 Performance requirements . . . . . . . . . . . . . . . . . . 15 68 6.2 Interoperability requirements . . . . . . . . . . . . . . . 15 69 6.3 Exception condition requirements . . . . . . . . . . . . . . 15 70 6.4 Miscellaneous requirements . . . . . . . . . . . . . . . . . 16 71 6.5 Obvious requirements . . . . . . . . . . . . . . . . . . . . 16 72 7. Further discussion . . . . . . . . . . . . . . . . . . . . . 18 73 7.1 QoS control in entities unaware of the BU/BA options . . . . 18 74 7.2 Sending QoS-conditionalized binding messages via a 75 non-default route . . . . . . . . . . . . . . . . . . . . . 18 76 7.3 Signaling downstream QoS requirements . . . . . . . . . . . 18 77 7.4 Upgrading the level of QoS . . . . . . . . . . . . . . . . . 19 78 7.5 Possibility of changing from a hop-by-hop option to 79 destination option . . . . . . . . . . . . . . . . . . . . . 20 80 7.6 Handling intermediate reservations . . . . . . . . . . . . . 20 81 7.6.1 Optimistic reservation . . . . . . . . . . . . . . . . . . . 21 82 7.6.2 Postponed reservation . . . . . . . . . . . . . . . . . . . 21 83 7.7 Handling large signaling packets over the wireless link . . 21 84 8. Security considerations . . . . . . . . . . . . . . . . . . 23 85 9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . 24 86 References . . . . . . . . . . . . . . . . . . . . . . . . . 25 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 26 88 Full Copyright Statement . . . . . . . . . . . . . . . . . . 28 90 1. Introduction 92 With the advent of various radio access technologies and increasing 93 deployment of sophisticated applications in mobile end systems, IPv6- 94 based networks will increasingly have to support Quality of Service 95 (QoS) in mobile environments. Mobile IPv6 ensures correct routing of 96 packets to a mobile node when the mobile node changes its point of 97 attachment with the IPv6 network. However, it is also required to 98 provide proper QoS forwarding treatment to the mobile node's packet 99 streams at the changed route in the network due to node mobility in a 100 fast, flexible, and scalable way, so that QoS-sensitive IP services 101 can be supported over Mobile IPv6 [2]. A QoS scheme for Mobile IPv6 102 should (i) be able to localize the QoS (re-) establishment to the 103 affected parts of the packet path in the network, and (ii) in cases 104 where more than one access technology or access router (AR) is 105 available, it may be desirable for the MN to choose an appropriate AR 106 that can satisfy its QoS requirements among several potential new ARs 107 when the MN moves into such a region (especially since in vertical 108 handoff scenarios, choosing a "good" access router might be more 109 important than the mere speed of reestablishing a QoS path). In 110 these cases, a handoff should not be performed if the MN's QoS 111 requirement is not met; yet if the QoS can be met, handoff should be 112 performed as quickly as possible. 114 In reference [7] a new IPv6 option called "QoS option" is introduced. 115 One or more QoS objects are included as a hop-by-hop option in IPv6 116 packets carrying Binding Update (BU) and Binding Acknowledgement (BA) 117 messages. When one packet for this purpose traverses different 118 network domains in the end-to-end path, the QoS option is examined at 119 these intermediate network domains to trigger QoS support for the 120 MN's data packets. 122 The mechanism described in reference [7] outperforms RSVP [8][12] in 123 that its signaling overhead is decreased. However, it does not allow 124 to check whether the QoS requirements are satisfied along the new 125 route before performing the handoff. We therefore introduce a QoS- 126 conditionalized binding update. The node at which old and new paths 127 diverge ("switching router") makes the final decision whether or not 128 to update the binding, depending on the result of QoS checks. A 129 binding update will only take place (in the sense of modifying the 130 route) if all nodes along the route between the AR and the switching 131 router are capable of complying with the QoS request, otherwise, the 132 old route will still be used and a negative acknowledgement will be 133 returned to the MN. 135 Our scheme is based on the architecture of Hierarchical Mobile IPv6 136 (HMIPv6) [6] to localize the QoS-conditionalized bindings. In 137 HMIPv6, a new entity, the Mobility Anchor Point (MAP), is introduced 138 and a MN only needs to perform one Local BU through MAP when changing 139 its layer 3 access point within the MAP domain. Hence the MAP is a 140 reasonable place for the switching router. However HMIPv6 is not 141 able to express QoS requirements, let alone to provide feedback 142 regarding the success of such request. We built on the work 143 described in reference [7] to overcome these limitations. 145 In this scheme, a QoS hop-by-hop option is carried in the message 146 containing the BU option to the MAP - this message is called BU+QoS 147 message. Each node concerned with QoS management between the MN and 148 the MAP (including the MAP) will pass the QoS requirement represented 149 by the QoS option to internal QoS mechanisms and check its resource 150 availability. If resources are available locally, they are reserved 151 and the message will be forwarded along its route. If specified in 152 the BU+QoS message, reservations covering less than the desired 153 amount of resources are also be possible; the request in the BU+QoS 154 message is then updated accordingly. If resources are not 155 available, negative feedback will be provided to the MN. Upon 156 receiving the BU+QoS message, the MAP also checks resource 157 availability and, if successful, will update the binding status and 158 respond with a positive BA+QoS message, including the actual amount 159 of reserved resources, if different from the requested amount. 160 Otherwise, no binding update is performed and a negative BA+QoS 161 message is returned to the MN. 163 By way of this scheme, QoS (re-)establishment due to local handoffs 164 is managed locally and transparently to the CNs, while in the worst 165 case (global mobility) it is managed with Mobile IPv6 and [7]. Only 166 if all routers along the new path find that sufficient resources are 167 available will a handoff (switching from old to new path) take place. 168 In this sense, the handoff process is conditional on the availability 169 of QoS resources and our scheme can take advantage of HMIPv6. The 170 additional advantage, however, is that mobile nodes will only perform 171 a handoff to an AR that can fulfill the QoS requirement (if there are 172 multiple ARs to choose from; in case there is only a single AR able 173 to serve the mobile node, even best-effort service would likely be 174 acceptable, however, this is an application-level concern). 176 The rest of this document provides a detailed description of the QoS- 177 conditionalized binding update procedure(s) for Mobile IPv6. The 178 document is organized as follows: 180 o Section 2 gives the terminology used in the document. 182 o Section 3 gives an overview of the scheme. 184 o Section 4 gives the message format used for the scheme. 186 o Section 5 describes the scheme in more detail. 188 o Section 6 compares our scheme with the requirements for a QoS 189 solution for Mobile IP as described in [2]. 191 o Section 7 presents a few important issues brought up by our 192 scheme and gives the reasons for choosing a particular 193 solution among different possibilities within our scheme. 195 o Section 8 addresses the security considerations. 197 2. Terminology 199 This document uses the following terms in addition to those defined 200 in the Mobile IPv6 protocol [4] and Hierarchical Mobile IPv6 201 protocol [6]: 203 QoS option: A Hop-by-Hop option introduced in reference [7]. A 204 QoS option contains zero or more QoS objects in Type/Length/ 205 Value (TLV) format. 207 QoS object: An object introduced in reference [7]. 208 Essentially, QoS OBJECT is an extension of RSVP QoS and 209 FILTER_SPEC objects, and contains certain parameters 210 representing QoS requirements and traffic characteristics for 211 a QoS flow. 213 QoS entity: An entity responsible for QoS negotiation and 214 establishment. Examples are RSVP daemons in RSVP/IntServ, a 215 Bandwidth Broker in a DiffServ domain, or a Label Edge Router 216 in an MPLS domain. From the perspective of MIPv6, QoS 217 (re)establishment is treated transparently in QoS-capable 218 routers or hosts; the IPv6 nodes MAY ask QoS entities to check 219 the QoS requirements included in the QoS option, and afterwards 220 the latter SHOULD perform such a reservation and respond with 221 an acknowledgement possibly along with (possibly modified) QoS 222 parameters. 224 Switching router/MAP: The node at which old and new paths diverge 226 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 227 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 228 document are to be interpreted as described in RFC-2119 [1]. 230 Besides, the following acronyms and abbreviations are used in this 231 document: 233 MIP/MIPv6/HMIPv6: Mobile IP/Mobile IPv6/Hierarchical Mobile 234 IPv6 236 MAP: Mobility Anchor Point 238 MN: Mobile Node 240 CN: Correspondent Node 242 QoS: Quality-of-Service 244 CoA: Care-of-Address 245 RCoA/LCoA: Regional/On-Link CoA 247 HoA: Home Address 249 AR: Access Router 251 BU/BA: Binding Update/Binding Acknowledgement 253 ER: Edge Router of network domain 255 IR: Interior Router of network domain 257 MPLS: Multi-Protocol Label Switching 259 LSP: Label Switched Path 261 DiffServ: Differentiated Services 263 IntServ: Integrated Services 265 RSVP: Resource ReSerVation Protocol 267 Upstream(UP)/Downstream(DW) direction: From MN/Towards MN 269 3. Overview 271 The all-IP network is assumed to consist of routers which may also be 272 responsible for the management of QoS resources, in which case we 273 call them QoS entities. For the purpose of this paper, such a QoS 274 entity acts as a black box to which QoS requests for a certain path 275 can be sent, which checks resource availability (resources would 276 typically include link bandwidth, buffer space in the router, CPU 277 resources, etc.) along the particular part of the path it is 278 responsible for, and either grants the request (and reserves the 279 resources), denies it, or, optionally, grants a reduced version of 280 the request. Typically, such QoS entities may be located at least in 281 the access routers and the agents which perform binding updates, 282 additional entities are of course possible. How to implement such 283 QoS entities and how to enforce such reservations is beyond the scope 284 of this paper; here, the mechanisms of conditionalizing the binding 285 update is discussed. 287 Since most handoffs are assumed to be local, a QoS solution 288 minimizing the time for QoS (re)establishment may take the advantage 289 of the regional mobility solutions. Furthermore, Hierarchical Mobile 290 IPv6 (HMIPv6) protocol is assumed to be the regional mobility 291 solution within our work. 293 The operation of QoS-conditionalized binding update is as follows. A 294 QoS hop-by-hop option is carried in the message containing the BU 295 option to the MAP -- this message is called BU+QoS message. Each QoS 296 entity between the MN and the MAP (including the MAP) will pass the 297 QoS requirement represented by the QoS option to internal QoS 298 mechanisms and check its resource availability. If resources are 299 available locally, they are reserved and the message will be 300 forwarded along its route. If resources are not available, negative 301 feedback will be provided to the MN by means of an extended Binding 302 Acknowledgement (BA+QoS) message. If a BU+QoS message has reached 303 the switching MAP and passed the local QoS test as well, the binding 304 update will take place (the binding cache in the MAP is updated to 305 reflect the new LCoA) and a positive BA+QoS message is returned to 306 the MN. Otherwise, no handoff is performed and a negative BA+QoS 307 message is returned to the MN. When observing a negative BA+QoS 308 message, intermediate QoS entities can release reservations that 309 could not be granted further upstream. 311 ____________ 312 | | 313 | CN | 314 |____________| 315 /\ /\ /\ 316 / | \ 317 / _____\/_____ \ 318 / | | \ 319 / | MAP | \ 320 / |____________| \ 321 / /\ /\ \ \ 322 / / (2)\ \(3) \ 323 data / / BU+QoS\ \BA+QoS \ data 324 path1/ _______\/__ ___\_\/____ \path2 325 | | | | | | 326 | | AR1 | | AR2 | | 327 | |___________| |___________| | 328 | /\ /\ / | 329 \ \ (1)/ /(4) / 330 \ \ BU+QoS/ /BA+QoS / 331 \ \/_______/__\/ / 332 \ | | / 333 --> | MN | <-- 334 |____________| 335 <---------------> 336 Node Mobility 338 Figure 1 - An Example of a QoS-Conditionalized Binding Procedure 340 Figure 1 shows an example of a QoS-conditionalized binding update in 341 a MAP domain. In this figure, the MAP is the switching router, the 342 ARs and the MAP are the only nodes concerned with QoS control. 343 Suppose the data packets between the MN and the CN is sent through 344 AR1 and QoS-guarranteed. Now due to node mobility, a second AR, AR2, 345 is reacheable while AR1 is still available. The MN can then send a 346 so-called QoS-conditionalized Binding Update message (BU+QoS) toward 347 the MAP through AR2, and the MAP will reply with acknowledgement 348 message (BA+QoS). If both AR2 and the MAP are able to fulfil the QoS 349 requirements embedded in the BU+QoS message, the BA+QoS message will 350 be positive and the resources will be reserved in its transmission 351 path. Otherwise it will be negative and the resources will be 352 released. In general, the path between the switching router and the 353 AR may contain several MAPs, as well as DiffServ/MPLS domains and/or 354 IntServ nodes, or combinations of both. QoS entities in such nodes or 355 domains should make admission control decisions based on the QoS 356 option. The QoS Option is a hop-by-hop header extension option and 357 treated as described below. (As an optimization, the new AR could 358 obtain QoS information from the old AR via context transfer 359 protocols in order to save wireless bandwidth - see discussion in 360 Section 7.7.) 362 In HMIPv6, outside the MAP domain, destination address or source 363 address of any packet to and from MN is marked as the MAP's IP 364 address or MN's RCoA in the MAP domain, not the HoA or LCoA of the 365 MN. Hence, the CN is oblivious of the BA, and a QoS (re-) 366 establishment procedure due to handoff only happens inside the MAP 367 domain. here we only discuss the case of the basic mode of HMIPv6 368 and the treatment in the extended mode of HMIPv6 needs more 369 investigation. 371 4. Format of QoS option 373 1. The format of the QoS object (see Figure 2) follows [7]. 375 0 1 2 3 376 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 1 | Reserved | Object Length |QoS Requirement| 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 2 | Max Delay (16-bit integer) ms |Delay Jitter (16-bit integer)ms| 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 3 | Average Data Rate (32-bit IEEE floating point number) | 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 4 |Burstiness:Token Bucket Size(32-bit IEEE floating point number)| 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 5 | Peak Data Rate (32-bit IEEE floating point number) | 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 6 | Minimum Policed Unit (32-bit integer) | 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 7 | Maximum Packet Size (32-bit integer) | 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 8 | | 393 ~ Values of Packet Classification Parameters ~ 394 | | 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 Figure 2 - Composition of a QoS OBJECT 399 2. Format of QoS Option - follows [7], except that 3 bits of 400 "Reserved" bits are used to specify whether QoS requirement 401 indicated by this option can be met, how to include desired 402 and/or accepted QoS and up- and/or downstream QoS. (see 403 Figure 3): 405 1. If the "F" bit is set, this means "QoS can not be met", 406 otherwise "(up to current node) QoS can be met". 408 2. If the "D" bit is set, this means "only downstream QoS 409 are specified", otherwise "both upstream and downstream 410 QoS are specified. 412 3. If the "A" bit is set, this means "both acceptable QoS 413 and desired QoS are specified", otherwise "only 414 desired QoS is specified". 416 0 1 2 3 417 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 1 |0|0|1| Opt Type| Opt Data Len | 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 2 |F|D|A| Reserved| DW- Desired QoSObj {, UP- Desired QoSObj} ~ 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 3 | | 424 ~ {, DW- Accepted QoSObj}{, UP- Accepted QoSObj} in TLV format ~ 425 | | 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 Figure 3 - Composition of QoS OPTION 430 5. Detailed description of QoS-conditionalized binding update procedure 432 5.1 Mobile node 434 The MN in our scheme behaves different to the one in the HMIPv6 basic 435 mode when responding to a few events: detecting connectivity to a new 436 AR, loosing connectivity to an existing router, and the arrival of 437 BA+QoS. As a simplification, the processing here assumes that 438 whenever a new AR becomes available, a binding update to this AR 439 should be attempted. In reality, more sophisticated schemes may be 440 implemented (e.g., only sending BU+QoS messages when the link quality 441 to the old AR is deteriorating, keeping track of a list of 442 prospective ARs, etc.); also, immediately obtaining an IP address 443 from any new AR might not be cost-efficient, these are out of the 444 scope of this draft. Note that the treatment of acceptable/desirable 445 QoS is also not discussed here; the necessary modifications are 446 reasonably straightforward. 448 The MN detects the connectivity to a new AR either by listening to 449 Router Advertisements or performing Router Solicitation as specified 450 in [4]. After MN acquires new local IP address (LCoA), it should 451 compose a BU+QoS message and send it towards MAP (via new AR). 453 If the MN receives a BA+QoS message, it should check whether the "F" 454 bit is set in the QoS Option. If not set, the AR which this BA+QoS 455 message passing through should be set as the default route for future 456 data transmission. Otherwise no action is required: either still use 457 old AR, or go with no QoS guarantees. 459 To optimize the QoS-conditionalized binding update procedure, the MN 460 may maintain at least two lists of LCoA-AR-QoS pairs for which are 461 available in connectivity and for which the MN has received positive 462 BA+QoS messages. Once a BU+QoS message is responded with a negative 463 BA+QoS, the QoS requirements embedded in the next BU+QoS message may 464 differ from the previous one, e.g., the desired level of QoS could be 465 reduced. There are several possibilities of how the number of 466 available access routers could influence the setting of lowest 467 acceptable QoS. E.g., acceptable QoS could be a function of the 468 number of available ARs and/or the MN's speed. 470 5.2 Router 472 Upon receiving a BU+QoS message, a router should check whether the 473 "F" bit is set. If not set, it should ask QoS entity for resources. 474 If sufficient resources are not available, this router should set "F" 475 bit in QoS packet. If this router is the switching MAP, the MAP 476 should compose a BA+QoS packet from the BU+QoS packet, with "F" bit 477 set as in the BU+QoS packet and return the BA+QoS message to the MN. 479 If "F" bit is not set, the switching MAP should update the MN's 480 binding to the new LCoA. It may compose a negative BA+QoS message 481 and send it along the old path to release reservations. A MAP with 482 MAP functionalities, but is not the switching MAP, behaves like a 483 normal router. 485 Upon receiving a BA+QoS message, a router should check whether the 486 "F" bit is set. If set, it should ask QoS entity for releasing any 487 possibly reserved resources. Note that a router MUST NOT interpret 488 the QoS option inside a BA+QoS as request for new resources, even 489 when the "F" bit is not set. Rather, this QoS option is interpreted 490 as providing more up-to-date information about a flow for which 491 reservations have already been made. 493 Note that in order to correctly process the BA+QoS message, all 494 routers concerned with QoS management, such as MAPs, ARs, and 495 possibly DiffServ and MPLS edge routers (ER), as well as IntServ 496 nodes need to maintain state for each flow. However, this is not an 497 additional burden to these entities as they need to maintain this 498 same state anyway: MAPs must maintain the binding cache, and also the 499 AR has to keep information, including QoS information, for each MN. 500 ERs typically act as aggregation routers, i.e. they (as opposed to 501 interior routers) still know individual flows, just as IntServ nodes 502 do. Nevertheless, this constitutes an argument in favor of 503 restricting QoS control to AR and MAP. 505 There are two ways to release the resources that have been re- 506 served. One is to release them explicitly via a message carrying a 507 QoS option with "F" bit set. Another is to use soft-state for the 508 QoS reservations and to rely on time-out of the reservation along an 509 unused path. The timer of QoS option may differ from that for the BU 510 option; optimal choices for these values are unknown as of this 511 moment. 513 6. Comparison of our scheme with the requirements draft 515 In [2], a number of requirements are listed which a QoS solution for 516 Mobile IP has to satisfy. The following sections discuss how the 517 conditionalized binding update presented in this draft compares with 518 these requirements. 520 6.1 Performance requirements 522 A QoS solution 524 o MUST minimize the interruption in QoS at the time of handoff - 525 our scheme minimizes this interruption, because it provides the 526 possibility to check for and reserve resources simultaneously 527 with the binding update, and also allows for negotiating with 528 several ARs to find one that can meet the QoS required. 530 o MUST localize the QoS (re)programming to the affected parts of 531 the packet path in the network - satisfied with HMIPv6. 533 o MUST provide means to release any QoS state along the old path 534 that is not required after handoff - one possibility is to let 535 the MAP initiate the release request for the old path; the 536 other is timing-out: as BUs time out, the QoS state along the 537 old path will be released. 539 6.2 Interoperability requirements 541 A QoS solution 543 o MUST be interoperable with other mobility protocols related to 544 mobile IP. This is an open issue, however, the scheme as such 545 could be applicable to other mobility protocols as well. 547 o MUST be interoperable with heterogeneous QoS paradigms. As 548 discussed in Section 5 above, our scheme interoperates with 549 DiffServ, IntServ and MPLS. Since its task is just carrying 550 QoS information which is then used by QoS entities to do 551 whatever the QoS paradigm requires, it should in fact interwork 552 with any QoS paradigm. 554 6.3 Exception condition requirements 556 A QoS solution 558 o MUST provide means to handle a situation in which the old QoS 559 agreement cannot be supported after handoff - our scheme 560 informs the MN the old QoS requirements cannot be met via a 561 negative BA. The MN may initiate another BU with another AR or 562 the same AR with lowered QoS requirements or stay attached to 563 the old AR. 565 6.4 Miscellaneous requirements 567 A QoS solution 569 o SHOULD be able to support QoS along different potential paths, 570 such as route-optimized path between the MN and the CN, 571 triangle route via HA, temporary tunnels between old and new 572 access router. This is an open issue and requires additional 573 investigation. 575 o MAY provide information to link layer to support required QoS, 576 such as acceptable IP packet loss ratio for wireless link. Not 577 supported, extensions are conceivable. 579 6.5 Obvious requirements 581 A QoS solution MUST satisfy 583 o scalability: the major scalability concern in this scheme is 584 the need to maintain state in intermediate entities. However, 585 as most of the are MAP and hence must maintain binding update 586 mappings, they do keep state on a per-flow level anyway. 587 Hence, this scheme does not introduce any new scalability 588 problems. 590 o security - see Section 8 592 o conservation of wireless bandwidth - apart from obtaining a new 593 LCoA address from a new basestation/access router, wireless 594 bandwidth is used only to send BU+QoS and to receive BA+QoS. 595 It can, however, be decreased further by transferring context 596 from old AR to new AR as described in [3] and as discussed 597 later in Section 7.7 599 o low processing overhead on mobile terminals - MN need to insert 600 QoS object into BU and must be able to interpret negative BAs 601 (but compare discussion about the use of context transfer in 602 Section 7.7). 604 o hooks for authorization and accounting - needs further 605 investigation 607 o robustness against failure of any MIP-specific QoS component in 608 the network - since we use the QoS option in a context of HMIP, 609 if (one) MAP fails, the QoS option will be delivered further 610 without any treatment for QoS option (esp. if a destination 611 option for QoS option is used). This needs further 612 investigations. 614 7. Further discussion 616 7.1 QoS control in entities unaware of the BU/BA options 618 In our discussion, we distinguish two kinds of QoS-controlling 619 entities. Both of them are able to interpret the QoS object. While 620 one kind is capable of recognizing the BU/BA options in order to 621 decide what kind of message arrived, and are also capable of 622 generating (negative) BAs, the other kind of QoS-controlling entity 623 do not know about BUs and BAs. Such an entity bases its behavior 624 only on the QoS option along with the QoS objects, but cannot use the 625 BU/BA option to decide how to handle a message. In particular, it 626 must be able to distinguish a QoS option for a flow that has not yet 627 established any reservations at this particular entity from a flow 628 that already has a reservation. 630 As described in detail in Section 5, our mechanism works correctly 631 with both kinds of QoS-controlling entities. 633 7.2 Sending QoS-conditionalized binding messages via a non-default route 635 To minimize the latency of QoS re-establishment interval, the MN 636 should send the BU+QoS messages via the "trial" access router while 637 the previous access router is still used. In case a negative BA+QoS 638 is generated by the MAP it is also necessary to send via the non- 639 default route (towards the MN via the "trial" access router). IPv6 640 specification [5] doesn't specify this usage. To overcome this, 641 routing header may be used. The MN may add a routing header (the MAP 642 address as destination address) in its BU+QoS messages while setting 643 the destination address as the "trial" access router; and when 644 necessary, the MAP may send its negative BA+QoS messages towards the 645 MN. 647 7.3 Signaling downstream QoS requirements 649 One concern is how to include QoS requirement for downstream traffic 650 into a message carrying Binding options. In an end-to-end signaling 651 scenario, e.g., when using standard Mobile IP, the QoS information 652 for the downstream traffic can easily be provided by the CN. When 653 using a hierarchical architecture, however, the downstream traffic 654 information must still be available for the new path between the MAP 655 and the MN. Requesting this information from the CN would defeat the 656 purpose of using hierarchical mobility schemes in the first place. 657 On the other hand, making this information available in the router 658 might be feasible with some QoS paradigms that provide per-flow QoS, 659 yet QoS schemes that only work on aggregated traffic schemes should 660 not burden intermediate nodes with maintaining information about 661 individual traffic flows (rendering the entire idea of aggregate flow 662 treatment useless) - and this information would have to be present in 663 every router that would potentially be a MAP. 665 Hence, the downstream QoS description cannot be obtained from the CN, 666 neither can intermediate routers be expected to store this 667 information for every flow. Rather, the downstream traffic QoS 668 requirements should be provided along with the upstream requirements 669 in the BU+QoS message. The MN could know this information (e.g., 670 from some application-level negotiation of QoS) but how to get it is 671 out of the scope of this document. 673 The main disadvantage of this approach is that the BU packets become 674 larger. While this should not pose much of a problem in the wired 675 backbone network, it could be considered a serious drawback when the 676 BU+QoS message has to be communicated over the wireless link. There 677 are some possible remedies to this problem which will be discussed 678 later. 680 Therefore, it is reasonable to assume that the MN also specifies the 681 downstream QoS requirements in the BU+QoS (the MN should be capable 682 of providing this information, e.g., derived from application-level 683 negotiation protocols). While this does increase the amount of 684 protocol data of the solution proposed here, the possibility to 685 reduce state information in the network appears to be the outweighing 686 concern - mechanisms like transferring context from old to new AR 687 (e.g., [3], see discussions later) can additionally reduce wireless 688 bandwidth requirements. The treatment of up- and downstream QoS 689 information in the routers directly follows [7]. 691 7.4 Upgrading the level of QoS 693 Another concern is which level of QoS requirements is appropriate for 694 a MIPv6 QoS solution. When the MN requests (in preparation of a 695 handoff) a QoS along the new path that is larger than the one used on 696 the old path, the switching router alone can no longer decide whether 697 or not this request should be accepted (assuming that it would be 698 possible to provide this level of QoS on the new path). This 699 inability is partly caused by the need to contact the CN to check 700 whether it agrees as well, whether the CN's access network can 701 provide such an increased capacity (otherwise, upgrading the MN's 702 local reservation would make little sense), and it may also involve 703 inter-domain QoS (re-)negotiation out of the (highest) MAP domain. 704 Therefore, we suggest to consider during a handoff only the problem 705 of maintaining the currently used QoS (and possibly specifying an 706 acceptable lower limit) and to treat the problem of upgrading to 707 higher service levels separately (the main points involved here would 708 be authorization/charging, providing indication of the availability 709 of more resources to the application, and application-level QoS 710 renegotiation). 712 7.5 Possibility of changing from a hop-by-hop option to destination 713 option 715 The feature of hop-by-hop option for the QoS option obviously will be 716 a drawback for a fast handoff. Hence, a solution trying to use a 717 destination option may be favorable. If the AR is also a MAP, the MN 718 may specify a destination for the QoS option (destined to the AR) and 719 the AR may relay it as the destination option (destined to the next 720 hop MAP) again, and so forth. Then the QoS option can be carried as 721 a destination option in the whole QoS-conditionalized binding 722 procedure. 724 Using such a destination option is straightforward if the MAPs are 725 the only entities concerned with QoS control. Typically, at least 726 the AR would also perform QoS control without necessarily being a 727 MAP as well. An important case would be when the AR is the only QoS 728 control entity besides the MAPs. Here, the QoS option can be 729 transmitted from the MN to the (switching) MAP in a hop-by-hop way, 730 but it would be possible for the AR to change the QoS option from a 731 hop-by-hop option to a destination option, destined to the next 732 upstream MAP. Upon receiving this destination option and necessary 733 work regarding QoS management, a MAP between AR and the highest MAP 734 may encapsule the BU message again to destine it to the 735 hierarchically next higher MAP. When the highest MAP finally 736 receives the BU+QoS message, it will issue a BA+QoS message and 737 follow a reverse procedure (from destination option to a hop-by-hop 738 option). 740 7.6 Handling intermediate reservations 742 As the process of accepting a binding update is a distributed one in 743 which several routers can participate, it is necessary to further 744 specify in detail how this decision process should take place. 745 Specifying such distributed processing is further complicated by the 746 fact that multiple binding updates from different MNs could be 747 processed at the same routers with only small temporal offset. 749 The main issue is how a router handles a BU+QoS message that it could 750 serve, but that also has to be passed upstream onto other routes in 751 order to check whether they can also provide the requested QoS. In 752 general, this is a distributed commit problem and can be solved with 753 well-known techniques, requiring a number of message exchanges e.g., 754 [10]. Here we are interested in faster approaches that should 755 ideally work using only one round trip from MN to switching router 756 and back; sacrificing some optimality aspects is unavoidable in such 757 schemes. Two main schemes are conceivable: optimistic or postponed 758 reservation. 760 7.6.1 Optimistic reservation 762 An intermediate router considers the requested QoS as actually being 763 reserved, optimistically assuming that all other routers along the 764 way can also grant the request. Reserving the capacity is the 765 correct decision if all upstream routers can also grant the request. 766 If any upstream router cannot comply with the request, a NACK is 767 returned and the "lower" routers have to release the spuriously made 768 reservation. This optimistic reservation approach can be problematic 769 if a lower router made a reservation that will later be denied and 770 has had to reject other reservation requests that could have been 771 granted upstream. 773 However, if the round-trip time for BUs is short (which is 774 reasonable in an access network using HMIPv6) and if there is less 775 traffic (relative to the available capacity) towards the core than 776 there is at the edges of the network, this situation should be 777 rather improbable and might hence be regarded as an acceptable risk 778 (in typical networks, the bottlenecks are likely to be closer to the 779 edge than towards the core). 781 7.6.2 Postponed reservation 783 In order to circumvent the problems of optimistic reservations, one 784 possibility would be to postpone the actual reservation: when 785 receiving a BU, a router only checks the instantaneous availability 786 of resources, without actually reserving anything when forwarding the 787 BU. Actual reservation only takes place when positive 788 acknowledgements are returned from upstream routers. 790 The problem with such postponed reservations is that a BA+QoS might 791 not be able to actually reserve capacity because of overlapping BU/ 792 BA messages from different MNs. In such a case, the switching MAP 793 has incorrectly reserved capacity and, even worse, performed a 794 handoff to a path that is not QoS-guaranteed. This is a rather 795 serious drawback, and we hence propose to use an optimistic 796 reservation scheme. 798 7.7 Handling large signaling packets over the wireless link 800 At the beginning of an application, QoS information needs to be 801 transported over the wireless link in order to enable end-to-end 802 application-level negotiation of QoS requirements. However, as both 803 wireless communication capacity and processing power on mobile 804 terminals are precious resources, once this QoS information has been 805 established, it would be desirable to minimize the amount of QoS 806 information traversing the wireless link and the amount of processing 807 the MN has to perform. A number of different approaches exist for 808 this problem in general: compression schemes, moving protocol 809 functionality away from MNs onto proxies that reside in the wired 810 network; in the present context, context transfer schemes appear to 811 be particularly useful [3]. 813 In particular, it should be feasible to assume that the old AR has 814 the QoS requirement information for each of its MNs. When an MN 815 wishes to associate itself with a new AR, it could simply inform the 816 new AR of the old AR's identity as well as of its own address 817 (permanent and temporary address should work). The new AR then 818 fetches the QoS requirement description from the old AR and initiates 819 the BU process on behalf of the MN; acknowledgements would still have 820 to be provided eventually to the MN. 822 Alternatively, the binding update process could also be initiated by 823 the old AR. Here, the MN (or even the new AR) becomes aware of a new 824 address it wants to use. The MN asks the old AR to initiate a 825 binding update procedure for this new address. The old AR contacts 826 the corresponding new AR, providing QoS requirements, and the new AR 827 constructs a BU message to be sent in the usual fashion. As soon as 828 the BA arrives, the new AR informs the MN that the new address is no 829 valid and that this new link should now be used. Negative feedback 830 should be provided via the old AR. This scheme is particularly 831 attractive if the MN is not capable of maintaining two different link 832 layer bindings (i.e., communicate with both old and new AR 833 simultaneously). 835 Choosing between directly transmitting BU/QoS information and 836 transferring context from another AR depends on a number of factors 837 (delay, bandwidth and cost of both the wired and the wireless link 838 and the respective weights assigned to them). Additionally, applying 839 context transfer is orthogonal to different ways of initiating the 840 actual handoff (controlled by the MN, the old or the new AR). 841 However, this question requires additional investigations. 843 8. Security considerations 845 The QoS scheme described in this document raises the following 846 threats, mainly concerning the integrity of BU/BA and QoS options: 848 o An attacker might possibly try to forge or replay BU messages 849 with specific QoS options in the name of another entity in 850 order to either just harm that entity or to even gain economic 851 benefits as QoS reservations may imply some form of billing 852 consequences. 854 o An attacker might try to delay, delete, or modify passing 855 BU+QoS messages (especially, the QoS options), e.g. in order 856 to reduce the desired QoS specification of another entity which 857 might possibly affect its own QoS requests or the QoS requests 858 of a third entity it wants to support in a positive manner. 860 The above threats SHOULD be averted by protecting the integrity of 861 BU+QoS messages with some kind of cryptographic signature, e.g. as 862 it is done with Mobile IP registration messages. However, this 863 requires the availability of appropriate key material in the signing 864 and the checking entities. It is out of the scope of this 865 specification and for further study if this can be realized with a 866 hop-by-hop approach, that is every intermediate node that processes 867 BU+QoS messages or just the QoS options checks their integrity and 868 signs the outgoing BU+QoS / QoS options, or an end-to-end approach 869 which could, for example, require the last MAP to check the integrity 870 of the mobile node's original BU+QoS message and its QoS option(s). 872 9. Acknowledgement 874 The authors are grateful to Tianwei Chen, Axel Neumann, Hemant 875 Chaskar and Hesham Soliman for their valuable comments to an 876 earlier version of this draft. 878 References 880 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 881 Levels", RFC (Best Current Practice) 2119, March 1997. 883 [2] Chaskar(Ed.), H., "Requirements of a QoS Solution for Mobile 884 IP", Internet Draft, work in progress, draft-ietf-mobileip-qos- 885 requirements-01.txt, July 2001. 887 [3] Koodli, R. and C. Perkins, "Context Transfer Framework for 888 Seamless Mobility", Internet Draft, work in progress, draft- 889 koodli-seamoby-ctv6-00.txt, February 2001. 891 [4] Johnson, D. and C. Perkins, "Mobility Support in IPv6", 892 Internet Draft, work in progress, draft-ietf-mobileip-ipv6- 893 15.txt, November 2001. 895 [5] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) 896 Specification", RFC 2460, December 1998. 898 [6] Soliman, H., Castelluccia, C., El-Malki, K. and L. Bellier, 899 "Hierarchical MIPv6 mobility management", Internet Draft, work 900 in progress, draft-ietf-mobileip-hmipv6-04.txt, July 2001. 902 [7] Chaskar, H. and R. Koodli, "A Framework for QoS Support in 903 Mobile IPv6", Internet Draft, work in progress, draft-chaskar- 904 mobileip-qos-01.txt, March 2001. 906 [8] Thomas, M., "Analysis of Mobile IP and RSVP Interactions", 907 Internet Draft, work in progress, draft-thomas-seamoby-rsvp- 908 analysis-00.txt, Feburary 2001. 910 [9] Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource 911 ReSerVation Protocol (RSVP) -- Version 1 Functional 912 Specification", RFC 2205, September 1997. 914 [10] Lyon, J., Evans, K. and J. Klein, "Transaction Internet 915 Protocol Version 3.0", RFC 2371, July 1998. 917 [11] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. 918 Weiss, "An Architecture for Differentiated Services", RFC 2475, 919 December 1998. 921 [12] Braden, B., Clark, D. and S. Shenker, "Integrated Services in 922 the Internet Architecture: an Overview", RFC 1633, June 1994. 924 [13] Rosen, E., Viswanathan, A. and R. Callon, "Multiprotocol Label 925 Switching Architecture", RFC 3031, January 2001. 927 Authors' Addresses 929 Xiaoming Fu (corresponding author) 930 Technical University Berlin 931 Sekr.FT 5-2, Einsteinufer 25 932 Berlin 10587 933 Germany 935 Phone: +49-30-314-23827 936 EMail: fu@ee.tu-berlin.de 938 Holger Karl 939 Technical University Berlin 940 Sekr.FT 5-2, Einsteinufer 25 941 Berlin 10587 942 Germany 944 Phone: +49-30-314-23826 945 EMail: karl@ee.tu-berlin.de 947 Andreas Festag 948 Technical University Berlin 949 Sekr.FT 5-2, Einsteinufer 25 950 Berlin 10587 951 Germany 953 Phone: +49-30-314-79171 954 EMail: festag@ee.tu-berlin.de 956 Guenter Schaefer 957 Technical University Berlin 958 Sekr.FT 5-2, Einsteinufer 25 959 Berlin 10587 960 Germany 962 Phone: +49-30-314-23836 963 EMail: schaefer@ee.tu-berlin.de 964 Changpeng Fan 965 Siemens AG 966 ICM N MC ST3 967 Berlin 13623 968 Germany 970 Phone: +49-30-386-36361 971 EMail: changpeng.fan@icn.siemens.de 973 Cornelia Kappler 974 Siemens AG 975 ICM N MC ST3 976 Berlin 13623 977 Germany 979 Phone: +49-30-386-32894 980 EMail: cornelia.kappler@icn.siemens.de 982 Mirko Schramm 983 Siemens AG 984 ICM N MC ST3 985 Berlin 13623 986 Germany 988 Phone: +49-30-386-25068 989 EMail: mirko.schramm@icn.siemens.de 991 Full Copyright Statement 993 Copyright (C) The Internet Society (2002). All Rights Reserved. 995 This document and translations of it may be copied and furnished to 996 others, and derivative works that comment on or otherwise explain it 997 or assist in its implementation may be prepared, copied, published 998 and distributed, in whole or in part, without restriction of any 999 kind, provided that the above copyright notice and this paragraph are 1000 included on all such copies and derivative works. However, this 1001 document itself may not be modified in any way, such as by removing 1002 the copyright notice or references to the Internet Society or other 1003 Internet organizations, except as needed for the purpose of 1004 developing Internet standards in which case the procedures for 1005 copyrights defined in the Internet Standards process must be 1006 followed, or as required to translate it into languages other than 1007 English. 1009 The limited permissions granted above are perpetual and will not be 1010 revoked by the Internet Society or its successors or assigns. 1012 This document and the information contained herein is provided on an 1013 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1014 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1015 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1016 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1017 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1019 Acknowledgement 1021 Funding for the RFC Editor function is currently provided by the 1022 Internet Society.