idnits 2.17.00 (12 Aug 2021) /tmp/idnits18561/draft-shen-nsis-rsvp-mobileipv6-00.txt: ** The Abstract section seems to be numbered 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 document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 13 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 14 pages 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 abstract seems to contain references ([2], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 536 looks like a reference -- Missing reference section? '2' on line 541 looks like a reference -- Missing reference section? '3' on line 545 looks like a reference -- Missing reference section? '4' on line 549 looks like a reference Summary: 8 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Charles Qi Shen 3 draft-shen-nsis-rsvp-mobileipv6-00.txt Winston Seah 4 July 12, 2002 Anthony Lo 5 Expires: January 2003 ICR 6 Haihong Zheng 7 Marc Greis 8 Nokia 10 Mobility Extensions to RSVP in an RSVP-Mobile IPv6 Framework 11 13 STATUS OF THIS MEMO 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress". 28 To view the list Internet-Draft Shadow Directories, see 29 http://www.ietf.org/shadow.html. 31 1 Abstract 33 This memo first gives a brief review of a RSVP and Mobile IPv6 34 interoperation framework proposed in [1] and compared its features 35 with the Performance Requirements set forth by Requirements of a QoS 36 Solution for Mobile IP [2]. The subsequent part of the memo presents 37 specification details including message formats, processing rules and 38 algorithms that form the framework. The vast majority of these 39 specifications has been verified by a prototype implementation. It is 40 expected that this work could serve as a useful input in dealing with 41 NSIS protocol and mobility issue. 43 2 Terminology 45 MS - Mobile Sender A Mobile Node that is acting as a Flow 46 Sender. 48 MR - Mobile Receiver A Mobile Node that is acting as a Flow 49 Receiver. 51 SNCR - Sender Nearest Common Router the first common router on 52 the old path and new path after a handoff caused by MN 53 functioning as a MS. 55 RNCR - Receiver Nearest Common Router the first common router on 56 the old path and new path after a handoff caused by MN 57 functioning as a MR. 59 NCR - Nearest Common Router could be either a SNCR or a RNCR. 61 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 62 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 63 document are to be interpreted as described in RFC 2119. 65 3 Introduction 67 The increasing interest in supporting QoS sensitive applications in a 68 mobile environment has led to extensive work on interoperation of QoS 69 signaling and mobility mechanisms. Typically the issue is addressed 70 in the context of RSVP and Mobile IP . This memo is a follow-up of 71 our previous proposal on an Interoperation Framework for using RSVP 72 in an Mobile IPv6 network[1]. 74 In this memo, we first give a brief review of the framework and 75 evaluate it against the Requirement of a QoS Solution for Mobile IP 76 [2] that was formed after our framework proposal. Then we present the 77 specification details concerning New Message/Object Formats, 78 processing rules as well as (Nearest Common Router) NCR Decision 79 Algorithms which have been developed extensively since the previous 80 framework memo. 82 It is known that the IETF Next Step In Signaling (NSIS) WG has been 83 charted to look at a future resource signaling protocol and the NSIS 84 framework is well likely to cover the interaction with general 85 mobility mechanism as well. In view of the fact that, RSVP is 86 recommended to be used as a starting point for NSIS, and Mobile IP is 87 likely the pre-dominant mobility mechanism for IP macro-mobility, we 88 expect this work to be a useful input to the area of NSIS and 89 mobility interaction. In addition, we provide a separate discussion 90 on several issues related to general NSIS and mobility interaction in 91 [3]. The similar topic is also covered as part of a framework 92 proposal by Handcock et. al. [4]. 94 It is worth noting that, the vast majority of signaling logic and 95 processing rules disclosed herein have been verified by a prototype 96 implementation modified from the latest ISI RSVP release. 98 4 Framework and Requirements Review 99 The essential point of our framework[1] is to maintain a unique flow 100 identifier regardless of node mobility. To achieve this specifically 101 within the Mobile IP and RSVP context, we have chosen to use MN HAs 102 in RSVP SESSION object and RSVP SENDER_TEMPLATE object. While the 103 correct routing of signaling packets is ensured by using MN CoAs. 105 A brief review of our RSVP-Mobile IPv6 framework is given below. We 106 assume a generic scenario where both communication parties could be 107 mobile. So we will use the terms Mobile Sender (MS) and Mobile 108 Receiver (MR) instead of MN to reflect the situation more accurately, 109 wherever necessary. The illustration of framework operation in each 110 of the MR and MS case is divided into three signaling phases 111 according to different functionalities, although they indeed overlap 112 in terms of actual signaling timing. 114 4.1 Framework Review: Mobile Sender (MS) Case 116 4.1.1 Resource Establishment in the New Path 118 When the MS obtains a new care-of address upon handoff, it 119 immediately sends a PATH message containing its mobility information 120 (which is its new CoA) towards the CN. This PATH message triggers the 121 establishment of PATH state in the RSVP routers on the path until it 122 reaches the Sender Nearest Common Router (SNCR). The SNCR finds the 123 PATH message arriving with a previous hop address different from the 124 one stored in the path state, upon which it immediately replies with 125 a RESV message towards the MN using the new path. The reserved 126 resources between the SNCR and the CN can be reused. 128 4.1.2 Resource Release in the Obsoleted Path 130 In addition to the above, the SNCR sends a RESVTEAR message towards 131 the previous hop stored in the old path state. The RESVTEAR message 132 triggers the removal of the reserved resources on the old path which 133 are no longer needed. 135 4.1.3 Refresh Handling in the Common Path 137 The SNCR also forwards the received handoff PATH message to the next 138 hop in any case so as to update the mobility information in all RSVP 139 routers on the rest of the path. This is to ensure correct routing of 140 subsequent refresh messages. 142 4.2 Framework Review: Mobile Receiver (MR) Case 144 4.2.1 Resource Establishment in the New Path 146 When the MR obtained a new care-of address upon handoff, it is 147 required to inform the Receiver Nearest Common Router (RNCR) of its 148 mobility information in order to trigger a quick handoff PATH message 149 from the RNCR. This avoids waiting for a handoff PATH message from 150 the CN, which requires at least a round trip time between MR and CN. 151 This is achieved by the use of a new RSVP PATHREQ message. It may 152 optionally be piggybacked in a PATH message sent by the MN when it 153 acts as both MS and MR. In the following discussion, we assume the 154 former method, or a separate PATHREQ message is used. The PATHREQ 155 message which carries MR's mobility information (the new CoA) will be 156 sent toward the CN and will be examined by each intermediate RSVP 157 node until it reaches RNCR. The RNCR then triggers a Local Repair for 158 the receiver route change that is, the router sends a handoff PATH 159 message associated with the unique flow identifier, to the MN's new 160 care-of address. This serves to establish resource state in the new 161 path as soon as possible. 163 4.2.2 Resource Release in the Obsoleted Path 165 In addition to the above, RNCR also sends a PATHTEAR message towards 166 the MN's old care-of address. The PATHTEAR message triggers the 167 removal of the resources on the old path which are no longer needed. 169 4.2.3 Refresh Handling in the Common Path 171 RNCR also forwards the PATHREQ message to the next hop until it 172 reaches the CN so as to update the mobility information in all the 173 RSVP routers on the common path. This is to insure correct routing of 174 subsequent refresh messages. 176 4.3 Requirements Review: Evaluate the Framework Against Requirements 178 A quick examination of the Requirement of a QoS Solution for Mobile 179 IP [2] shows that the above framework addressed all three performance 180 requirements set forth, namely 182 o Minimize the interruption in QoS at the time of handover. 184 o Localize the QoS (re)establishment to the affected parts of 185 the packet path in the network. 187 o Releasing after handover the QoS state (if any) along the old 188 packet path. 190 The first and second requirements are addressed by the use of NCR in 191 establishing resource state within new path incurred by handoff. The 192 third requirement is met by explicitly issuing of corresponding state 193 teardown messages at the NCRs. In the following sections we present 194 specification details concerning New Message/Object Formats, NCR 195 Algorithms and Processing rules that form the above RSVP-Mobile IPv6 196 framework. 198 5 Formats of New RSVP Objects and Messages 200 5.1 Formats of SENDER_MOBILITY Object and RECEIVER_MOBILITY Object 202 New MOBILITY objects are defined in order to convey MN's mobility 203 information to RSVP. In the simplest case for Mobile IP, it contains 204 the MN's current care-of address. By including these new objects, the 205 RSVP process does not need to get the mobility information of the MN 206 from the IP header of the RSVP messages, the clear interface between 207 the IP layer and the RSVP process is maintained. 209 0 1 2 3 210 +-------------+-------------+-------------+-------------+ 211 | Length (bytes) | Class-Num | C-Type | 212 +-------------+-------------+-------------+-------------+ 213 | | 214 + + 215 | | 216 + Care-of Address + 217 | | 218 + + 219 | | 220 +-------------+-------------+-------------+-------------+ 221 | Flags | (Reserved) | Sequence Number | 222 +-------------+-------------+-------------+-------------+ 224 Flags: 8 bits 226 0x01: NCR Identified 228 When set, indicates that the NCR has been identified. 230 Figure 1: MOBILITY Object 232 In accordance with the simplex nature of RSVP, two types of MOBILITY 233 objects are defined, namely, SENDER_MOBILITY objects and 234 RECEIVER_MOBILITY objects. Figure 1 shows the format for the MOBILITY 235 object. The length field indicates the total object length in bytes. 237 The Class Num and the C-Type for the MOBILITY object would have to be 238 assigned by IANA. SENDER_MOBILITY objects and RECEIVER_MOBILITY 239 objects shall have different Class Nums. The contents of the MOBILITY 240 object contain: 242 o Mobility information which is MS or MR's current care-of 243 address. 245 o An NCR Flag bit which indicates whether the appropriate NCR 246 has been located. The bit carries an initial value of 0 and is 247 set to 1 by the NCR. 249 o A two-byte Sequence Number field which increases by one after 250 each handoff and thus indicates how up-to-date the mobility 251 information is. 253 5.2 Format of PATHREQ Message 255 The new PATHREQ message is defined to allow the MR to request a PATH 256 message from RNCR immediately after it performs a handoff. Figure 2 257 shows the format of a PATHREQ message, it contains: 259 o An RSVP common header, in which the message type for PATHREQ 260 message has to be assigned by IANA. 262 o A SESSION object containing the MR's home address. 264 o A SENDER_TEMPLATE object containing the MS's home address. 266 o A RECEIVER_MOBILITY object containing the MR's current care-of 267 address. 269 o A SENDER_MOBILITY object containing the MS's current care-of 270 address. 272 Inclusion of the above four objects makes RSVP aware of the care-of 273 address and home address of both MS and MR thus covers the most 274 complicated case where both communication parties are MNs and acts as 275 Sender and Receiver simultaneously. In case either party is 276 stationary, the corresponding MOBILITY object will not be applicable 277 and the home address above is replaced by the corresponding fixed 278 address. 280 6 Nearest Common Router (NCR) Decision Algorithm 282 The decision for NCRs is divided into two parts: SNCR and RNCR. 283 Generally, decision for SNCR is triggered by receiving of PATH 284 +-------------+-------------+-------------+-------------+ 285 | RSVP Common Header | 286 +-------------+-------------+-------------+-------------+ 287 | | 288 + + 289 | | 290 + SESSION object + 291 | | 292 + + 293 | | 294 +-------------+-------------+-------------+-------------+ 295 | | 296 + + 297 | | 298 + SENDER_TEMPLATE object + 299 | | 300 + + 301 | | 302 +-------------+-------------+-------------+-------------+ 303 | | 304 + + 305 | | 306 + RECEIVER_MOBILITY object + 307 | | 308 + + 309 | | 310 +-------------+-------------+-------------+-------------+ 311 | | 312 + + 313 | | 314 + SENDER_MOBILITY object + 315 | | 316 + + 317 | | 318 +-------------+-------------+-------------+-------------+ 320 Figure 2: PATHREQ Message 322 messages; decision for RNCR is triggered by receiving of PATHREQ 323 messages; RNCR and SNCR may be physically collocated in the same 324 router, or could be in two different network entities. 326 6.1 Decision Algorithm for Sender NCR (SNCR) 328 RSVP decides that it is the SNCR if all of the following conditions 329 are met. 331 o A PATH message which contains a SENDER_MOBILITY object is 332 received. 334 o The NCR Flag bit in the received SENDER_MOBILITY object is 335 Zero. 337 o There is a matching PSB found for the PATH message. 339 o The matching PSB does not include a SENDER_MOBILITY object or 340 the matching PSB contains a SENDER_MOBILITY object which has a 341 sequence number lower than that of the received 342 SENDER_MOBILITY object. 344 6.2 Decision Algorithm for Receiver NCR (RNCR) 346 RSVP decides that it is the RNCR if all of the following conditions 347 are met. 349 o A PATHREQ message which contains a RECEIVER_MOBILITY object is 350 received. 352 o The NCR Flag bit in the received RECEIVER_MOBILITY object is 353 Zero. 355 o There is a matching PSB found for the SESSION object in the 356 received PATHREQ message. 358 o The matching PSB does not include a RECEIVER_MOBILITY object 359 or the matching PSB contains a RECEIVER_MOBILITY object which 360 has a sequence number lower than that of the received 361 RECEIVER_MOBILITY object. 363 7 Processing Rules for PATHREQ Message and PATH Message with MOBILITY 364 Object 366 7.1 Processing Rule for New PATHREQ Message 368 The PATHREQ message is sent by a MR when it changes its care-of 369 address. The general processing rules when RSVP receives a PATHREQ 370 message are as follows: 372 o RSVP searches for PSBs in the opposite direction whose SESSION 373 object matches the corresponding object in the PATHREQ 374 message. 376 o If there are no matching PSBs, the PATHREQ message is simply 377 forwarded to the next RSVP node. The source address and 378 destination address of the forwarded PATHREQ message are 379 determined as follows: 381 - The source address is retrieved from RECEIVER_MOBILITY 382 object which contains the receiver's care-of address. 384 - The destination address is retrieved from SENDER_MOBILITY 385 object which contains the sender's care-of address, if it 386 exists. Otherwise, the destination address is retrieved from 387 SENDER_TEMPLATE object which contains the sender's fixed or 388 home address. 390 o Otherwise there are matching PSBs found. For each matching 391 PSB, 393 - If RECEIVER_MOBILITY information is found in the PSB and the 394 sequence number of that RECEIVER_MOBILITY is higher than 395 that of the received RECEIVER_MOBILITY object, discard the 396 received PATHREQ message. 398 - Otherwise, if RECEIVER_MOBILITY is not found in the PSB or 399 RECEIVER_MOBILITY is found in the PSB but with a lower 400 sequence number: 402 - The PSB is updated with the new RECEIVER_MOBILITY object. 404 - If SENDER_MOBILITY exists either or both in PSB or 405 PATHREQ, compare their sequence number, update PSB with 406 the newer SENDER_MOBILITY object if applicable. 408 - Check the NCR Flag bit in the received RECEIVER_MOBILITY 409 object: 411 - If the NCR Flag bit is 1, and the RSVP node is not the 412 sender, forward the PATHREQ message to the next RSVP 413 node using the same source and destination address 414 decision rules as stated above when there is no matching 415 PSB. 417 - If the Flag bit is 0, the RSVP node is identified as 418 RNCR. It does the following: 420 Sets the NCR Flag bit into 1; Constructs a handoff PATH 421 message that includes the RECEIVER_MOBILITY object, and 422 sends it to the receiver's current care-of address 423 obtained from the same RECEIVER_MOBILITY object; 424 Constructs a PATHTEAR message containing the old 425 RECEIVER_MOBILITY object, if exists, to the receiver's 426 old care-of address; If the RSVP node is not sender of 427 the flow, it further forwards the PATHREQ message to the 428 next RSVP node using the same source and destination 429 address construction rule as stated above when there is 430 no matching PSB. 432 7.2 New Processing Rules for PATH Message 434 To deal with node mobility, PATH messages shall carry MOBILITY 435 objects. If the MS performs a handoff, a SENDER_MOBILITY object will 436 be included in the PATH messages. If the MR performs a handoff and 437 reports it to the sender through PATHREQ message, the subsequent PATH 438 message will carry the RECEIVER_MOBILITY object. 440 The following states new/modified processing rules for PATH messages 441 in addition to existing rules specified in RFC 2209 due to the 442 introduction of new MOBILITY objects. 444 o When RSVP creates a new PSB for a new PATH message with 445 MOBILITY objects, the following rules apply in addition to/in 446 place of existing rules where applicable: 448 - If SENDER_MOBILITY object is included in the PATH message, 449 it is also copied to the newly created PSB. 451 - If RECEIVER_MOBILITY object is included in the PATH message, 452 it is also copied to the newly created PSB. 454 - When the PATH message is forwarded to the next RSVP node. 455 The source address and destination address of the forwarded 456 PATH message are determined as follows: 458 - The source address is retrieved from SENDER_MOBILITY 459 object which contains the sender's care-of address, if it 460 exists. Otherwise, the source address is retrieved from 461 SENDER_TEMPLATE object which contains the sender's fixed 462 or home address. 464 - The destination address is retrieved from 465 RECEIVER_MOBILITY object which contains the receiver's 466 care-of address, if it exists. Otherwise, the destination 467 address is retrieved from SESSION object which contains 468 the receiver's fixed or home address. 470 o Otherwise, if matching PSB is found, the following rules apply 471 in addition to/ in place of existing rules where applicable: 473 - First, if a RECEIVER_MOBILITY object is included in the PATH 474 message, the RSVP node determines whether it carries the 475 most updated information based on the sequence number of the 476 object. If the existing PSB contains no RECEIVER_MOBILITY 477 information or the received RECEIVER_MOBILITY information is 478 newer than the existing one, the PSB updates its 479 RECEIVER_MOBILITY information. 481 - Second, if a SENDER_MOBILITY object is included in the PATH 482 message, the RSVP node determines whether it carries the 483 most updated information based on the sequence number of the 484 object. If the received SENDER_MOBILITY is older than the 485 existing one in PSB, stops processing the PATH message and 486 discards it. Otherwise, if the existing PSB contains no 487 SENDER_MOBILITY information or the received SENDER_MOBILITY 488 information is newer than the existing one, 490 - The PSB updates its SENDER_MOBILITY information. 492 - The NCR Flag bit in the received SENDER_MOBILITY object is 493 checked. If it is not set, the RSVP node is identified as 494 SNCR. It does the following: 496 Sets the NCR Flag bit to 1; Sends a RESV message to the 497 previous hop which leads to the MS's current care-of 498 address; Sends a RESVTEAR message to the previous hop 499 which leads to the MS's old care-of address; If the RSVP 500 node is not receiver of the flow, it further forwards the 501 PATH message to the next RSVP node using the same source 502 and destination address decision rules as stated above 503 when there is no matching PSB. 505 - Otherwise the RSVP node is not SNCR. If the RSVP node is 506 not receiver of the flow, it forwards the PATH message to 507 the next RSVP node using the same source and destination 508 address decision rules as stated above when there is no 509 matching PSB. 511 8 Future Work 513 In traditional operation of RSVP, a flow identifier is virtually also 514 used as a reservation identifier. This seems to be fine in fixed 515 networks. In mobile environments however, it might sometimes be 516 desirable to separate these two, while the flow identifier could be 517 changing from time to time, the reservation identifier remains 518 constant all the time [3,4]. It should be noted that our proposed 519 framework does not in any sense exclude this possibility. More 520 specifically, in cases where the reservation identifier is defined 521 differently than the flow identifier, our use of HAs as reservation 522 identifier does not exclude the use of addresses other than HAs, such 523 as the CoAs as flow identifier. In this case, it is expected that the 524 signaling logic explained in this memo will still largely be 525 applicable, although certain modifications are likely to be needed. 526 The applicability of this approach in our framework is currently 527 under study. 529 9 Acknowledgments 531 We would like to thank Mr. Donglin Shi for helpful discussion during 532 the prototype implementation of this work. 534 10 Bibliography 536 [1] C. Q. Shen, W. Seah, A. Lo, H. Zheng, and M. Greis, "An 537 Interoperation Framework for Using RSVP in Mobile IPv6 Networks," 538 draft-shen-rsvp-mobileipv6-interop-00.txt , July 2001. Work in 539 Progress. 541 [2] H. Chaskar (Editor), "Requirements of a QoS Solution for Mobile 542 IP," draft-ietf-mobileip-qos-requirements-02.txt , June 2001. Work 543 in Progress. 545 [3] C. Q. Shen, "Several Framework Issues Regarding NSIS and 546 Mobility," draft-shen-nsis-mobility-fw-00.txt , July 2002. Work in 547 Progress. 549 [4] R. Hancock et.al., "Next Steps in Signaling: A Framework 550 Proposal," draft-hancock-nsis-fw-00.txt , June 2002. Work in 551 Progress. 553 11 Authors' addresses 555 Charles Qi Shen 556 Institute for Communications Research (ICR) 557 20 Science Park Road 558 #02-34/37, TeleTech Park 559 Singapore Science Park II 560 Singapore 117674 561 Phone: +65 6870-9358 562 Email: shenqi@icr.a-star.edu.sg 564 Winston Seah 565 Institute for Communications Research (ICR) 566 20 Science Park Road 567 #02-34/37, TeleTech Park 568 Singapore Science Park II 569 Singapore 117674 570 Phone: +65 6870-9163 571 Email: winston@icr.a-star.edu.sg 573 Anthony Lo 574 Institute for Communications Research (ICR) 575 20 Science Park Road 576 #02-34/37, TeleTech Park 577 Singapore Science Park II 578 Singapore 117674 580 Haihong Zheng 581 Nokia Research Center 582 6000 Connection Drive 583 Irving, TX 75039 584 USA 585 Phone: +1 972 894 4232 586 Email: haihong.zheng@nokia.com 588 Marc Greis 589 Nokia Research Center 590 6000 Connection Drive 591 Irving, TX 75039 592 USA 593 Phone: +1 972 374 0629 594 Email: marc.greis@nokia.com 596 12 Full Copyright Statement 598 "Copyright (C) The Internet Society (date). All Rights Reserved. This 599 document and translations of it may be copied and furnished to 600 others, and derivative works that comment on or otherwise explain it 601 or assist in its implementation may be prepared, copied, published 602 and distributed, in whole or in part, without restriction of any 603 kind, provided that the above copyright notice and this paragraph are 604 included on all such copies and derivative works. However, this 605 document itself may not be modified in any way, such as by removing 606 the copyright notice or references to the Internet Society or other 607 Internet organizations, except as needed for the purpose of 608 developing Internet standards in which case the procedures for 609 copyrights defined in the Internet Standards process must be 610 followed, or as required to translate it into languages other than 611 English. 613 The limited permissions granted above are perpetual and will not be 614 revoked by the Internet Society or its successors or assigns. This 615 document and the information contained herein is provided on an "AS 616 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 617 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 618 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL 619 NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY 620 OR FITNESS FOR A PARTICULAR PURPOSE. 622 Table of Contents 624 1 Abstract ............................................ 1 625 2 Terminology ......................................... 1 626 3 Introduction ........................................ 2 627 4 Framework and Requirements Review ................... 2 628 4.1 Framework Review: Mobile Sender (MS) Case ........... 3 629 4.1.1 Resource Establishment in the New Path .............. 3 630 4.1.2 Resource Release in the Obsoleted Path .............. 3 631 4.1.3 Refresh Handling in the Common Path ................. 3 632 4.2 Framework Review: Mobile Receiver (MR) Case ......... 3 633 4.2.1 Resource Establishment in the New Path .............. 3 634 4.2.2 Resource Release in the Obsoleted Path .............. 4 635 4.2.3 Refresh Handling in the Common Path ................. 4 636 4.3 Requirements Review: Evaluate the Framework 637 Against Requirements ........................................... 4 638 5 Formats of New RSVP Objects and Messages ............ 5 639 5.1 Formats of SENDER_MOBILITY Object and 640 RECEIVER_MOBILITY Object ....................................... 5 641 5.2 Format of PATHREQ Message ........................... 6 642 6 Nearest Common Router (NCR) Decision Algorithm ...... 6 643 6.1 Decision Algorithm for Sender NCR (SNCR) ............ 8 644 6.2 Decision Algorithm for Receiver NCR (RNCR) .......... 8 645 7 Processing Rules for PATHREQ Message and PATH 646 Message with MOBILITY Object ................................... 8 647 7.1 Processing Rule for New PATHREQ Message ............. 8 648 7.2 New Processing Rules for PATH Message ............... 10 649 8 Future Work ......................................... 11 650 9 Acknowledgments ..................................... 12 651 10 Bibliography ........................................ 12 652 11 Authors' addresses .................................. 12 653 12 Full Copyright Statement ............................ 13