idnits 2.17.1 draft-krishnamurthi-mobileip-buffer6-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == 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 Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 3 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? RFC 2119 keyword, line 128: '...cedures described in this document MAY...' RFC 2119 keyword, line 252: '... MAY request that buffered packets b...' RFC 2119 keyword, line 259: '... it nevertheless SHOULD NOT clear the ...' RFC 2119 keyword, line 261: '...ted. The router SHOULD return a negat...' RFC 2119 keyword, line 426: '...n access address MAY be a care-of addr...' (124 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 1225 has weird spacing: '...kia.com rob...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: If the router can perform the requested operation in part or in full, the router MUST not set the `E' bit in the BA. If a buffer was allocated due to the request, then the size of that buffer and its associated lifetime MUST be placed in the Status and Lifetime fields of the acknowledgment. If the router rejects the request or cannot fulfill it in any way, then the router MUST set the `E' bit a return an appropriate error value in the Status field indicating the reason for failure. -- 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. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. '2' == Outdated reference: A later version (-04) exists of draft-ietf-seamoby-context-transfer-problem-stat-00 ** Downref: Normative reference to an Informational draft: draft-ietf-seamoby-context-transfer-problem-stat (ref. '3') == Outdated reference: A later version (-24) exists of draft-ietf-mobileip-ipv6-13 -- Unexpected draft version: The latest known version of draft-koodli-mobileip-smoothv6 is -00, but you're referring to -02. -- Possible downref: Normative reference to a draft: ref. '5' ** Obsolete normative reference: RFC 2461 (ref. '6') (Obsoleted by RFC 4861) Summary: 8 errors (**), 0 flaws (~~), 5 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 mobileip Working Group Govind Krishnamurthi 2 INTERNET DRAFT Nokia Research Center 3 1 March 2001 Robert C. Chalmers 4 UC Santa Barbara 5 Charles E. Perkins 6 Nokia Research Center 8 Buffer Management for Smooth Handovers in IPv6 9 draft-krishnamurthi-mobileip-buffer6-01.txt 11 Status of This Memo 13 This document is an individual submission to the mobileip Working 14 Group of the Internet Engineering Task Force (IETF). Comments should 15 be submitted to the MOBILE-IP@STANDARDS.NORTELNETWORKS.COM mailing 16 list. 18 Distribution of this memo is unlimited. 20 This document is an Internet-Draft and is in full conformance with 21 all provisions of Section 10 of RFC2026. Internet-Drafts are working 22 documents of the Internet Engineering Task Force (IETF), its areas, 23 and its working groups. Note that other groups may also distribute 24 working documents as Internet-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 28 any 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: 32 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at: 34 http://www.ietf.org/shadow.html. 36 Abstract 38 Real-time applications like VoIP in mobile networks need smooth 39 handovers in order to minimize or eliminate packet loss as a mobile 40 node (MN) transitions between network links. This document defines 41 a buffering mechanism for IPv6 by which an MN can request that the 42 router on its current subnet buffers packets on its behalf while the 43 MN completes registration procedures with the router of a new subnet. 44 Once the registration is complete and the MN has a valid care-of 45 address in the new network, the buffered packets can be forwarded 46 from the previous router, thus reducing the possibility of packet 47 loss during the transition. 49 Contents 51 Status of This Memo i 53 Abstract i 55 1. Introduction 1 57 2. Terminology 2 59 3. Managed Buffering (MB) Overview 3 60 3.1. Handover Scenarios . . . . . . . . . . . . . . . . . . . 4 61 3.1.1. Mobile Controlled Network Assisted Handovers . . 5 62 3.1.2. Network Controlled Mobile Assisted Handovers . . 6 63 3.2. Conceptual Data Structures . . . . . . . . . . . . . . . 7 65 4. Protocol Extensions 9 66 4.1. Router Advertisement Modifications . . . . . . . . . . . 9 67 4.2. New Buffering SubOptions . . . . . . . . . . . . . . . . 10 68 4.2.1. Buffer Initialization SubOption . . . . . . . . . 10 69 4.2.2. Buffer Forward SubOption . . . . . . . . . . . . 11 70 4.2.3. Buffer Acknowledgment SubOption . . . . . . . . . 13 72 5. Requirements for IPv6 Nodes 15 73 5.1. Requirements for IPv6 Mobile Nodes . . . . . . . . . . . 15 74 5.2. Requirements for IPv6 Access Routers . . . . . . . . . . 15 76 6. Mobile Node Operation 16 77 6.1. Receiving Router Advertisements . . . . . . . . . . . . . 16 78 6.2. Initiating Buffer Management . . . . . . . . . . . . . . 16 79 6.3. Modifying Buffer Parameters . . . . . . . . . . . . . . . 17 80 6.4. Requesting Packet Forwarding . . . . . . . . . . . . . . 17 81 6.5. Ending Buffer Management . . . . . . . . . . . . . . . . 17 82 6.6. Receiving Buffer Acknowledgments . . . . . . . . . . . . 17 84 7. Router Operation 18 85 7.1. Advertising Buffer Management . . . . . . . . . . . . . . 18 86 7.2. Receiving Buffer Management SubOptions . . . . . . . . . 18 87 7.2.1. Common Operations . . . . . . . . . . . . . . . . 18 88 7.2.2. Receiving SubOptions from a Mobile Node . . . . . 19 89 7.2.3. Receiving SubOptions from Another Router . . . . 19 90 7.3. Sending Buffer Acknowledgments . . . . . . . . . . . . . 20 91 7.4. Initializing Buffer State . . . . . . . . . . . . . . . . 21 92 7.5. Forwarding Buffered Packets . . . . . . . . . . . . . . . 21 93 7.6. Unsolicited Forwarding of Buffered Packets . . . . . . . 22 94 7.7. Receiving Packets for a Mobile Node . . . . . . . . . . . 22 95 7.8. Deleting Buffered Packets . . . . . . . . . . . . . . . . 23 96 7.9. Freeing MB State . . . . . . . . . . . . . . . . . . . . 23 98 8. Protocol Constants 23 100 9. IANA Considerations 24 102 10. Security Considerations 24 104 11. Acknowledgments 24 106 Addresses 26 108 1. Introduction 110 For future generation mobile networks to be successful, they 111 should ensure that the transfer of real-time data is seamless and 112 glitch-free. The loss of packets during the transition between 113 networks should be minimal. It has been shown in current research 114 efforts that buffering packets improves the performance of Mobile 115 IP [2]. This document defines a buffering mechanism that attempts to 116 meet this goal for general smooth handovers for IPv6 nodes. 118 Figure 1 illustrates the basic handover scenario assumed throughout 119 this document. We propose the following: incoming packets to a 120 mobile node (MN) are buffered at the Previous Router (Prtr) while the 121 MN transitions to a new network. Once the MN completes registration 122 and obtains a valid IP address for the network associated with 123 the New Router (Nrtr), Prtr forwards the packets to the MN at its 124 new address. In the document, we address both mobile controlled 125 and network controlled handovers and their impact on the buffer 126 management protocol. 128 The buffer management procedures described in this document MAY 129 be performed in association with the delivery of a Binding Update 130 (BU) from the MN to a targeted mobility agent (i.e., a mobility 131 agent which is to manage that care-of address for the MN). By 132 associating the buffering request with the BU, the need for separate 133 acknowledgments is substantially reduced. If the access router is 134 unable to fulfill the MN's request then it will reply with a negative 135 acknowledgment. Otherwise, the MN will be assured that its message 136 was delivered to the access router when it receives the Binding 137 Acknowledgment from the mobility agent. Furthermore, the general 138 procedures for smooth handovers require the new access router to 139 retransmit messages until it is assured that the previous router has 140 received and acted on them. 142 $ MN +-----------+ 143 +-+ | Previous | < 144 | | ---------- | Router | ------ > ----\ 145 +-+ | (Prtr) | < \ 146 | | \ 147 | +-----------+ +--------+ 148 | | IP | Corr. | 149 | | Network |Node(CN)| 150 V | +--------+ 151 | / 152 $ MN +-----------+ / 153 +-+ | New | < / 154 | | ---------- | Router | ------ > ----/ 155 +-+ | (Nrtr) | < 156 | | 157 +-----------+ 159 Figure 1: Reference Scenario for Handovers 161 All Mobile Node addresses in this document refer to the mobile node's 162 care-of addresses, either at the new access router or the old access 163 router. The access routers may not even be aware of the home address 164 of the mobile node. It is anticipated that future specifications may 165 use the mobile node's NAI for identification purposes instead of the 166 mobile node's care-of address(es). 168 This document is based on the general smooth handover framework 169 presented in [5]. To that effect, the suboptions defined herein 170 implement the feature extensions discussed in the framework draft. 171 Furthermore, many issues covered in that draft, such as overall 172 packet formats and authentication, will not be re-addressed here. 174 In this document, we propose an extension to the IPv6 Router 175 Advertisement message [6] which allows a router to advertise its 176 ability to support MB. We also introduce three new suboptions, Buffer 177 Initialize, Buffer Forward and Buffer Acknowledgment, to be used 178 within the smooth handover framework. 180 2. Terminology 182 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 183 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL", and 184 "silently ignore" in this document are to be interpreted as described 185 in RFC 2119 [1]. 187 We define the following terms for use in this document. 189 Nrtr The new router to which the MN attaches after handover 191 Prtr The MN's default router ("previous router") prior to 192 handover 194 Naddr The mobile node's previous access address; for Mobile 195 IPv6, this would be the mobile node's care-of address on 196 the new access network. 198 Paddr The mobile node's previous access address; for Mobile 199 IPv6, this would be the mobile node's previous care-of 200 address. 202 MCNA Mobile Controlled Network Assisted (see section 3.1.1) 204 NDMA Network Controlled Mobile Assisted (see section 3.1.2) 206 SHIN message 207 Any message from the mobile node requesting transfer of 208 context from the mobile node's previous access address 209 (Paddr) to its new access address (Naddr), and defined in 210 [3]. 212 SHREP Message 213 The ICMP Smooth Handover Reply message, sent between 214 access routers, and defined in [3]. 216 SHREQ Message 217 The ICMP Smooth Handover Request message, sent between 218 access routers, and defined in [3]. 220 MB Managed Buffering 222 MN Mobile Node 224 BU Binding Update 226 BA Binding Acknowledgement 228 3. Managed Buffering (MB) Overview 230 A router which is enabled to perform buffering advertises its 231 capability to interested MNs using the proposed `B' bit in its router 232 advertisements (see Section 4.1). Once a MN receives a router 233 advertisement indicating that MB services are available, it may 234 request buffering with the Buffer Initialization suboption defined in 235 Section 4.2.1. The MN may request a specific buffer size or accept 236 the default size. The router may accept or decline this request 237 based on available resources, or it may allocate a smaller buffer if 238 necessary. The actual size of the buffer allocated is communicated 239 back to the MN through the Buffer Acknowledgment suboption described 240 in Section 4.2.3. 242 Buffering state is associated with a target address, the MN's access 243 IP address before it arrives at the new access network (i.e., Paddr). 244 Incoming packets destined for Paddr are buffered in addition to being 245 forwarded normally. When the buffer allocated to the MN is full, the 246 packets are replaced using an appropriate replacement policy. The 247 default replacement policy is for older packets to be dropped before 248 newer packets. Packets must be dropped atomically; partial packets 249 must never be delivered to the mobile node. 251 After establishing a link to a new access network, a mobile node 252 MAY request that buffered packets be forwarded to its new IP 253 access address (Naddr) with the Buffer Forward suboption defined in 254 Section 4.2.2. In response, the router tunnels to Naddr all packets 255 previously buffered for Paddr. When the lifetime of Paddr expires, 256 all associated buffering state will be freed. 258 If the router cannot accept new requests for buffering (say, due to 259 resource shortages), it nevertheless SHOULD NOT clear the `B' bit 260 in future router advertisements since handover operations may be 261 adversely affected. The router SHOULD return a negative reply to 262 initialization requests until resources are again available. 264 3.1. Handover Scenarios 266 The framework draft introduces two handover scenarios, Mobile 267 Controlled Network Assisted (MCNA) and Network Controlled Mobile 268 Assisted (NCMA). In MCNA handovers, the MN decides when it needs 269 to transition to a new access router, but for NCMA handovers the 270 network decides with possible inputs from the MN. The impact of 271 the two scenarios on buffer management is detailed further in the 272 following subsections. To help illustrate, typical signal flows for 273 each scenario are presented. These examples are not comprehensive. 274 Alternative messaging will be detailed in later sections. 276 In each scenario, assume that, in the past, the following actions 277 have occurred, whether or not in association with a previous 278 handover: 280 0a) Prtr sent a router advertisement (RA) with B=1. 282 0b) Prtr created buffering state associated with Paddr. 284 3.1.1. Mobile Controlled Network Assisted Handovers 286 In Mobile Controlled Network Assisted (MCNA) handovers, the MN uses 287 some indication, like the reception of Neighbor Advertisements, 288 or possibly some low-level information such as the Signal to 289 Interference Ratio (SIR) to decide whether it needs to change 290 its access router. If presented with multiple options for new 291 routers, the MN may decide on the new access router based on signal 292 strength or possible resource information passed with the router 293 advertisement. Once the MN transitions to a new access router, it is 294 the MN's responsibility to initiate buffer state at the new router 295 and to request forwarding of buffered packets from the previous 296 router. 298 An example of a typical signal flow for MB during an MCNA handover 299 follows (see Figure 2). The scenario assumes that both Prtr and Nrtr 300 support buffer management and that the MN will take advantage of the 301 MB services at both nodes. 303 $ MN +-----------+ 304 +-+ <--(0a:RA)--- | Previous | 305 | | -------------------------- | Router | 306 +-+ --(0b:SHIN+BI)--> | (Prtr) | 307 | +-----------+ 308 | ^ | | 309 | (2:SHREQ+BF)| | | 310 | | | |(4:fwd pkts) 311 | | | 312 V (3:SHREP+BA)| V 313 V 314 $ MN +-----------+ 315 +-+ -(1:SHIN+BI+BF)--> | New | 316 | | -------------------------- | Router | 317 +-+ <-(4:fwd pkts)- | (Nrtr) | 318 +-----------+ 320 Figure 2: MCNA Managed Buffering Signal Flow 322 Now, suppose that MN obtains a new access address, Naddr, on the 323 access network served by from router Nrtr. 325 1) MN sent a SHIN with two buffering suboptions to Nrtr: a 326 BI suboption with nonzero lifetime, causing Nrtr to create 327 buffering state associated with Naddr; and a Buffer Forward 328 (BF) suboption. 330 2) Nrtr sent a Smooth Handover Request (SHREQ) message to Prtr, 331 as defined in the framework draft, with the same Buffer 332 Forward (BF) suboption that it received from MN. 334 3) Prtr responds to Nrtr with a Smooth Handover Reply (SHREP) 335 message containing a Buffer Acknowledgment suboption. 337 4) Prtr forwards buffered packets associated with Paddr to MN at 338 Naddr. 340 3.1.2. Network Controlled Mobile Assisted Handovers 342 In NCMA handovers, elements in the network decide when a MN should 343 transition between two access routers. The advantage of this 344 scheme is that the Previous Router can supply the New Router with 345 current state for the MN before the handover actually occurs. The 346 initialization of buffering state and the forwarding of buffered 347 packets to the new access router may be performed without the 348 explicit request of the MN. However, the smooth handover framework 349 requires that the MN still request forwarding during a handover 350 to ensure that packets are forwarded correctly. To access any MB 351 features, in both MCNA and NCMA cases, the MN will issue a SHIN to 352 Nrtr if it receives a router advertisement with the appropriate bits 353 set. The SHIN message associates the previous access IP address 354 (Paddr) to the new access address (Naddr), as in the following 355 example. 357 Figure 3 illustrates a typical signal flow for MB during an NCMA 358 handover. The scenario assumes that both Prtr and Nrtr support MB 359 and that the MN will take advantage of the MB services at both nodes. 361 For NCMA, suppose that Prtr determines that MN needs to handover to 362 Nrtr. Then, the following actions occur. 364 1) Prtr prepares to transfer the buffered packets associated 365 with Paddr to Nrtr by sending an HI message containing a 366 BI suboption. Nrtr attempts to make a compatible buffer 367 allocation for MN. 369 2) Prtr forwards the packets buffered for Paddr to Nrtr using 370 an encapsulated header. Nrtr decapsulates each packet and 371 buffers it. Prtr continues to buffer newly arriving packets 372 destined for Paddr and forwards them directly to Nrtr. 374 $ MN +----------+ 375 +-+ <--(0a:RA)--- | Previous | 376 | | -------------------------- | Router | 377 +-+ --(0b:SHIN+BI)--> | (Prtr) | 378 | +----------+ 379 | | ^ 380 | | | 381 | (1:HI+BF)| |(5:HAck+BF+BA) 382 | (2:fwd pkts)| | 383 V | | 384 V | 385 $ MN +----------+ 386 +-+ -(3:SHIN+BI+BF)--> | New | 387 | | -------------------------- | Router | 388 +-+ <-(4:fwd pkts)- | (Nrtr) | 389 +----------+ 391 Figure 3: NCMA Buffer Management Signal Flow 393 3) MN sends a SHIN option with two buffering suboptions to Nrtr: 394 a BI suboption with nonzero lifetime, causing Nrtr to create 395 buffering state associated with Naddr; and a Buffer Forward 396 (BF) suboption. 398 4) Nrtr forwards buffered packets associated with Paddr to MN at 399 Naddr. 401 5) Nrtr sends a SHREQ message to Prtr with a Buffer 402 Acknowledgment (BA) suboption indicating that the HI message 403 was received and that forwarding was handled at Nrtr. 405 In some cases it may not be possible to transfer the buffers to the 406 New Router before the MN obtains a Naddr. For example, the Nrtr 407 and Prtr may not maintain a mutual trust, or Nrtr may not have the 408 necessary buffering capabilities. In such cases, the Previous Router 409 takes actions identical to the MCNA case. It waits to receive the 410 explicit Buffer Forward request from the MN, and then transfers the 411 packets directly to the MN's Naddr. 413 3.2. Conceptual Data Structures 415 This document uses the conceptual data structures listed in this 416 subsection to describe the operation of the MB protocol. A specific 417 MB implementation does not need to necessarily implement these data 418 structures as long as the external behavior is consistent with that 419 described in this document. 421 Access Address An IP address used by a mobile node to facilitate 422 network-layer access to a particular network. Such 423 an address may be, but is not necessarily, useful for 424 endpoint identification for application end-to-end data 425 communications with nodes on other networks. As an 426 example, an access address MAY be a care-of address, as 427 defined by Mobile IPv6. 429 Packet Buffer 430 The Packet Buffer maintains a list of IP packets 431 originally destined for the MN. 433 Target Address 434 The buffer management state must be associated with a 435 target address. This target address is the previous IP 436 access address (Paddr). 438 Forwarding Address 439 When a MN establishes a link to a new access network 440 served by a new access router, it will also acquire a 441 new access IP address (Naddr). The Forwarding Address 442 for the MN is set to Naddr and is used when forwarding 443 buffered packets. 445 New Router Address 446 The New Router Address stores the address of the new 447 access router being used by the MN after handover. This 448 address is used in the NCMA scenario where the Previous 449 Router forwards packets to the New Router and continues 450 to forward incoming packets for the MN. 452 Lifetime 453 State information for Managed Buffering MUST have an 454 associated lifetime. This lifetime MUST no less than 455 MB_SAVE_TIME, but otherwise MUST NOT be longer than the 456 lifetime of the router's entry for the mobile node's 457 access address. 459 Sequence Number 460 The maximum value of the Sequence Number field received 461 in previous Managed Buffering requests of a particular 462 type for a target address. The Sequence Number field is 463 8 bits long, and all comparisons between Sequence Number 464 Values MUST be performed modulo 2**8. 466 4. Protocol Extensions 468 The following protocol extensions are described: 470 - A buffer management extension to the IPv6 router advertisement 471 message. 473 - Three new buffering suboptions implementing the feature 474 extensions described in the framework draft. 476 4.1. Router Advertisement Modifications 478 This document proposes to modify the IPv6 Router Advertisement 479 message [6] with the addition of a single flag bit to indicate that 480 the router supports buffer management. This flag bit is referenced 481 in this document as the `B' bit. The new format for the Router 482 Advertisement message is shown in Figure 4. 484 0 1 2 3 485 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 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 | Type | Code | Checksum | 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 489 | Cur Hop Limit |M|O|H|B|Reservd| Router Lifetime | 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 | Reachable Time | 492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 493 | Retrans Timer | 494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 495 | Options ... | 496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 498 Figure 4: New Router Advertisement Format 500 This format represents the following changes over that originally 501 specified for Neighbor Discovery [6] and Mobile IPv6 [4]: 503 Buffer Management (B) 504 The Buffer Management (B) bit is set in a Router 505 Advertisement to indicate that the router 506 sending this advertisement supports Managed 507 Buffering services. 509 4.2. New Buffering SubOptions 511 This section defines the format for the three new buffering 512 suboptions proposed by this draft: Buffer Initialization, Buffer 513 Forward and Buffer Acknowledgment. Each suboption format conforms to 514 Section 5.5 of the MIPv6 draft [4]. 516 4.2.1. Buffer Initialization SubOption 518 The Buffer Initialization suboption is used to request that a router 519 begin buffering packets on behalf of a mobile node. The suboption 520 may be used by the Previous Router to initiate buffering at the New 521 Router on behalf of a mobile node in the case of a NCMA handover. A 522 mobile node MAY include the suboption with a Smooth Handover Initiate 523 (SHIN) destination option. The suboption MAY be associated with 524 any ICMP Handover message to request or supply buffered packets and 525 buffer state information. 527 The state is associated with a single target address. In the case 528 of a message originating from a MN, the target address is the source 529 IP address of the packet. In the case of a router-router handover 530 message, the target address of the MN MUST be supplied in the Paddr 531 field of the message. 533 The Buffer Initialization suboption is encoded in type-length-value 534 (TLV) format as seen in Figure 5. 536 0 1 2 3 537 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 538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 539 |SubOption Type | SubOption Len | Sequence Num | Buffer Size | 540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 541 |A| Reserved | Lifetime | 542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 544 Figure 5: Buffer Initialization SubOption Format 546 SubOption Type TBD 548 SubOption Len 8-bit unsigned integer. Length of the 549 suboption, in octets, excluding the SubOption 550 Type and SubOption Length fields. This field 551 MUST be set to 6. 553 Sequence Num The sequence number is assigned by the sender 554 and used by the receiving node to sequence 555 buffering requests. Each MB request sent by 556 a MN MUST use a sequence number greater than 557 the Sequence Number value sent in the previous 558 initialization request, if any, to the same 559 router (modulo 2**8, as defined in Section 3.2). 561 Buffer Size 8-bit unsigned integer. The MN MAY request 562 a size for the new buffer in units of 1,024 563 octets. If the value is 0xffff then the default 564 buffer size at the router will be used. 566 Acknowledge (A) The Acknowledge (A) bit is set by the sending 567 node to request an explicit acknowledgment in 568 response to this request. 570 Reserved This field is unused. It MUST be initialized to 571 zero by the sender and ignored by the receiver. 573 Lifetime 24-bit unsigned integer. The number of seconds 574 remaining before the MB state MUST be considered 575 expired. If not defined (a value of -1) then 576 the default lifetime at the router will be used. 577 If the MN does not need buffering, then this 578 field is set to zero. 580 4.2.2. Buffer Forward SubOption 582 The Buffer Forward suboption is used to request that buffered 583 packets be forwarded to the MN's new access address. The request is 584 associated with both a target address and a forwarding address. 586 The MN MAY include the suboption as part of a Smooth Handover 587 Initiate (SHIN) destination option. In this case, the target address 588 is defined in the Previous Access IP Address (Paddr) field of the 589 SHIN option, and the forwarding address is the source IP address of 590 the packet. 592 In the case of a request originating from the MN, the MN sends the 593 Paddr to the Prtr as part of the message, and the forwarding address 594 is the source IP address of the packet. A router MAY include the 595 Buffer Forward suboption with a Handover Request or Handover Initiate 596 message. For such messages, the target and forwarding addresses are 597 defined in the Paddr and Naddr fields, respectively. 599 The Buffer Forward suboption MAY include a list of unique identifiers 600 indicating which packets have already been received by the mobile 601 node. These packets therefore MUST be silently discarded, and MUST 602 NOT be forwarded to the mobile node. The identifier is calculated as 603 (MD5 (packet) mod 2**16). 605 The Buffer Forward suboption is encoded in type-length-value (TLV) 606 format as seen in Figure 6. 608 0 1 2 3 609 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 610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 611 |SubOption Type | SubOption Len | Sequence Num | Reserved | 612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 613 | Excluded Packet ID | Excluded Packet IDs, continued 614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 616 Figure 6: Buffer Forward SubOption Format 618 SubOption Type 619 TBD 621 SubOption Len 622 8-bit unsigned integer. Length of the 623 suboption, in octets, excluding the SubOption 624 Type and SubOption Length fields. This field 625 MUST be set to 2 plus the total length of all 626 Packet ID fields. 628 Sequence Num 629 The sequence number is assigned by the sender 630 and used by the receiving node to sequence 631 buffering requests. Each MB request sent by 632 a MN MUST use a sequence number greater than 633 the Sequence Number value sent in the previous 634 forwarding request, if any, to the same router 635 (modulo 2**8, as defined in Section 3.2). 637 Reserved This field is unused. It MUST be initialized to 638 zero by the sender and MUST be ignored by the 639 receiver. 641 Excluded Packet ID 642 The packet identifier is a 16-bit value that 643 uniquely identifies a packet received by the 644 MN that should not be forwarded. The actual 645 number of Excluded Packet ID fields present is 646 determined by the SubOption Len field. 648 4.2.3. Buffer Acknowledgment SubOption 650 The Buffer Acknowledgment suboption MAY be used to acknowledge the 651 receipt of a Buffer Initialization or Buffer Forward suboption. The 652 suboption MUST be returned to the sender with the sequence number of 653 the original request. The suboption MAY be associated with any of 654 the following Smooth Handover destination options: SHREQ, SHREP, or 655 SHACK. 657 The Buffer Acknowledgment suboption is encoded in type-length-value 658 (TLV) format as seen in Figure 7. 660 0 1 2 3 661 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 662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 663 |SubOption Type | SubOption Len | Sequence Num |I|F|E|R| Status| 664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 665 | Buffer Size | Lifetime | 666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 668 Figure 7: Buffer Acknowledgment SubOption Format 670 SubOption Type TBD 672 SubOption Len 8-bit unsigned integer. Length of the 673 suboption, in octets, excluding the SubOption 674 Type and SubOption Length fields. This field 675 MUST be set to 6. 677 Sequence Num The sequence number in the Buffer Acknowledgment 678 suboption is copied from the Sequence Number 679 field in the Buffer Initialization or Buffer 680 Forward suboption being acknowledged, for use by 681 the sender in matching this acknowledgment with 682 an outstanding buffering request. 684 Initialize (I) The Initialize (I) bit indicates that this 685 suboption is acknowledging a previous Buffer 686 Initialization request. 688 Forward (F) The Forward (F) bit indicates that this 689 suboption is acknowledging a previous Buffer 690 Forward request. 692 Error (E) The Error (E) bit indicates that the BA is 693 reporting an error. When this bit is set, the 694 Status field MUST be set to indicate the cause 695 of the error. 697 Reserved (R) This bit is unused. It MUST be initialized to 698 zero by the sender and MUST be ignored by the 699 receiver. 701 Buffer Size For successful requests, the Size field the 702 value indicates the granted buffer size or the 703 amount of data forwarded in units of 1,024 704 octets. 706 Status 4-bit unsigned integer. If greater than 0x0, 707 the value indicates the reason for failure in 708 processing the buffering request. 710 Lifetime 24-bit unsigned integer. The granted lifetime 711 in seconds. The value of this field is 712 undefined if the `E' bit indicates that the 713 request was unsuccessful. 715 The following values are currently defined for the Status field: 717 0 Success 719 4 Reason unspecified 721 5 Administratively prohibited 723 6 Insufficient resources 725 7 Buffering not supported 727 8 Buffering not enabled 729 9 Buffers already forwarded 731 10 Buffers empty 733 5. Requirements for IPv6 Nodes 735 Since signaling for buffering initialization and forwarding is 736 limited to MNs and their respective access routers, there are no 737 general requirements for all mobile nodes. Non-mobile correspondent 738 nodes (CN) and routers not directly supporting MNs do not have to 739 implement any of the suboptions or procedures outlined in this 740 document. 742 In order to make use of the Managed Buffering features specified 743 in this document, some new requirements must be implemented 744 by participating mobile nodes. This section summarizes those 745 requirements, identifying the functionality each requirement is 746 intended to support. 748 5.1. Requirements for IPv6 Mobile Nodes 750 For a participating MN to initiate buffering and request buffer 751 forwarding, it must fulfill the following requirements: 753 - Every participating MN MUST be able to receive and process the 754 `B' bit of router advertisements, as described in Section 6.1. 756 - Every participating MN MUST support sending the Buffer 757 Initialization and Buffer Forward suboptions, as specified in 758 Sections 6.2 and 6.4, and MUST be able to receive and process 759 Buffer Acknowledgment suboptions, as specified in Section 6.6. 761 - Every participating MN SHOULD be able to generate Excluded 762 Packet IDs from recently received packets, as described in 763 Section 4.2.2. 765 5.2. Requirements for IPv6 Access Routers 767 A participating IPv6 router offering buffering features to local MNs 768 must fulfill the following requirements: 770 - Every participating router MUST be able to buffer packets on 771 behalf of a mobile node, as described in Section 7.7. 773 - Every participating router MUST be able to advertise MB support 774 by setting the `B' bit in its router advertisements, as described 775 in Section 7.1. 777 - Every participating router MUST be able to send, receive 778 and process Buffer Initialization, Buffer Forward and Buffer 779 Acknowledgment suboptions, as specified in Sections 7.2 and 7.3. 781 - Every participating router MUST be able to tunnel packets to the 782 MN or New Router, as described in Sections 7.5 and 7.6. 784 - Every participating router SHOULD be able to generate Packet IDs 785 from buffered packets, as described in Section 4.2.2. 787 6. Mobile Node Operation 789 6.1. Receiving Router Advertisements 791 Upon receiving a router advertisement, if the `B' bit is not set then 792 the mobile node MUST NOT request MB services from the advertising 793 router. Otherwise, if the `B' bit is set, the mobile node MAY 794 request MB services according to the procedures outlined in the 795 following subsections. 797 6.2. Initiating Buffer Management 799 The MN MAY initiate managed buffering services at a particular router 800 if that router sets the `B' bit in its Router Advertisements, by 801 sending a Buffer Initialization suboption as part of some message 802 sent to the router. 804 - The Sequence Number field of the Buffer Initialization suboption 805 MUST contain a unique value greater (modulo 2**8) than the last 806 sequence number associated with a Buffer Initialization request 807 sent to this router. 809 - The Acknowledge (A) bit MAY be set. 811 - The Buffer Size field MAY indicate desired size of the buffer. 812 Unless specific applications require otherwise, the Buffer Size 813 field SHOULD be set to 0 which indicates that the router should 814 allocate a buffer of default size, as defined by the router's 815 configuration. 817 - The Lifetime field SHOULD contain the desired number of seconds 818 that the MB state (including the buffered packets) should remain 819 active at the router. The Lifetime field MAY be set to -1 which 820 indicates that the router should use a default lifetime, as 821 defined by the router's configuration. A value of zero for the 822 lifetime indicates that no buffering is needed. 824 6.3. Modifying Buffer Parameters 826 The MN MAY request that parameters of the MB state be modified by 827 re-issuing an initialization request. In this case, zero values 828 indicate that a field ( -1 for the Lifetime field) should not be 829 changed. 831 - To reduce or expand the size of an existing buffer, the MN 832 supplies a different size in the Buffer Size field. If the new 833 buffer size is smaller than the previous size, the router MAY 834 discard some of the packets already buffered. 836 - To modify the lifetime of the MB state, the MN supplies a new 837 value in the Lifetime field. 839 - The Sequence Number field MUST contain a unique value greater 840 than the last sequence number associated with a Buffer 841 Initialization request sent to this router. 843 6.4. Requesting Packet Forwarding 845 During a handover, if the MN has managed buffering initialized at 846 the Previous Router (either explicitly created by the MN or created 847 by an NCMA router on behalf of the MN), the MN SHOULD request that 848 the Previous Router forward any buffered packets to Naddr. The 849 Sequence Number field MUST contain a unique value greater than the 850 last sequence number associated with a Buffer Forward request sent to 851 the forwarding router. The Excluded Packet IDs field SHOULD uniquely 852 identify which packets should not be forwarded by the router, as 853 described in Section 4.2.2. 855 6.5. Ending Buffer Management 857 The mobile node MAY terminate managed buffering services at a 858 particular router by sending a Buffer Initialization suboption with 859 zero lifetime. The Sequence Number field MUST contain a unique 860 value greater than thelast sequence number associated with a Buffer 861 Initialization request sent to that router. 863 6.6. Receiving Buffer Acknowledgments 865 Upon receiving a Buffer Acknowledgment suboption, a MN MUST validate 866 the suboption according to the following tests: 868 - The SubOption Len field MUST conform to the length defined in 869 Section 4.2.3. 871 - The Sequence Number field MUST match an outstanding request made 872 by the MN. 874 If the suboption does not satisfy all of these tests, it MUST be 875 silently ignored by the MN and suboption processing SHOULD continue. 876 If additional suboptions are present, the mobile node SHOULD continue 877 to be process them. 879 7. Router Operation 881 7.1. Advertising Buffer Management 883 A router that has been enabled to provide MB services SHOULD 884 advertise that capability by setting the `B' bit (see Section 4.1) 885 in its router advertisement. If a router does not currently have 886 resources to allocate for buffering, however, the router MUST NOT 887 clear an already advertised `B' bit in future advertisements since 888 handover operations may be adversely affected. Rather, the router 889 SHOULD return a negative reply to initialization requests until 890 resources are again available. 892 7.2. Receiving Buffer Management SubOptions 894 A router MAY receive buffering suboptions from a MN or from another 895 router. This subsection defines the procedures common to both cases, 896 as well as procedures particular to each case individually. 898 7.2.1. Common Operations 900 Upon receiving a buffering suboption, as previously defined in this 901 document, the receiving router MUST validate the packet containing 902 the suboption according to the following tests: 904 - The option MUST provide valid IPv6 target and forwarding 905 addresses as required by the individual suboptions defined in 906 Sections 4.2.1 and 4.2.2. 908 - The SubOption Len field MUST conform to the length defined 909 for the appropriate suboption, as defined in Sections 4.2.1 910 through 4.2.3. 912 - The Sequence Number field MUST be greater than the Sequence 913 Number received in the previous MB message of equivalent type (if 914 any) for the target address. 916 Any packet not satisfying all of these tests MUST be silently ignored 917 by the receiving node, and further suboption processing SHOULD 918 continue. If the packet is valid according to the above tests, then 919 the suboption is processed according to the following procedures: 921 - If the suboption is received from the target address, then the 922 procedures outlined in Section 7.2.2 MUST be followed. 924 - Otherwise, the procedures outlined in Section 7.2.3 MUST be 925 followed. 927 - If the suboption is a Buffer Initialization or Forward request 928 and that request contains an `A' bit that is set or the request 929 could not be fulfilled in full or in part, the router MUST reply 930 with a Buffer Acknowledgment indicating success or the reason for 931 failure. 933 7.2.2. Receiving SubOptions from a Mobile Node 935 Upon receiving a buffering suboption from a MN, the router MUST 936 process the suboption according to the following procedures: 938 - If the suboption is a Buffer Initialization suboption, then the 939 router takes one of the two following actions based upon whether 940 the lifetime is zero: 942 * If the lifetime is nonzero, then the router MUST follow the 943 procedures in Section 7.4 using the source IPv6 address of 944 the packet as the target address. 946 * If the lifetime is zero, then the router SHOULD free any 947 buffering state associated with the target address. 949 - If the suboption is a Buffer Forward suboption, the router MUST 950 follow the procedure outlined in Section 7.5 using the Paddr 951 field of the SHIN as the target address and the source IP address 952 of the packet as the forwarding address. 954 - If the suboption is a Buffer Acknowledgment suboption, then the 955 router MUST silently ignore the suboption and SHOULD continue 956 processing subsequent suboptions. 958 7.2.3. Receiving SubOptions from Another Router 960 Upon receiving a buffering suboption from another router, the router 961 MUST process the suboption according to the following procedures: 963 - If the suboption is a Buffer Initialization suboption, then the 964 router takes one of the two following actions based upon whether 965 the lifetime is zero: 967 * If the lifetime is zero, then the router MUST follow the 968 procedures outlined in Section 7.4 using the Paddr field of 969 the SHREQ as the target address. 971 * If the lifetime is nonzero, then the router MUST silently 972 ignore the suboption and SHOULD continue processing 973 subsequent suboptions. 975 - If the suboption is a Buffer Forward suboption, then the router 976 MUST take one of the following actions: 978 * If the buffered packets have already been forwarded to the 979 New Router (see Section 7.6) and the router has received a 980 Buffer Acknowledgment to confirm that transfer either prior 981 to or within the current message, the router SHOULD ignore 982 the suboption. 984 * Otherwise, the router MUST follow the procedure outlined in 985 Section 7.5 using the Paddr field of the SHREQ as the target 986 address and the Naddr field as the forwarding address. 988 - If the suboption is a Buffer Acknowledgment suboption, then the 989 router MAY resubmit the request if the Status field indicates 990 that the request was wholly or partially unsuccessful, as defined 991 in Section 7.3. 993 7.3. Sending Buffer Acknowledgments 995 When a router receives a buffering suboption that requires an 996 acknowledgment, as described in the previous subsections, the 997 router SHOULD associate a Buffer Acknowledgment suboption with an 998 appropriate reply packet. Also, in the NCMA case, if a router 999 initializes buffering state on behalf of a MN without an explicit 1000 request, the router MUST alert the MN with a Buffer Acknowledgment. 1002 If the router can perform the requested operation in part or in 1003 full, the router MUST not set the `E' bit in the BA. If a buffer was 1004 allocated due to the request, then the size of that buffer and its 1005 associated lifetime MUST be placed in the Status and Lifetime fields 1006 of the acknowledgment. If the router rejects the request or cannot 1007 fulfill it in any way, then the router MUST set the `E' bit a return 1008 an appropriate error value in the Status field indicating the reason 1009 for failure. 1011 7.4. Initializing Buffer State 1013 The router MUST allocate buffer space for the MN unless the router 1014 does not currently support MB or sufficient resources are not 1015 currently available. If a buffer is allocated, the size SHOULD 1016 correspond to the value passed in the Buffer Size field and the 1017 lifetime SHOULD be equal to the value passed in the Lifetime field. 1019 If the buffer size requested by the MN, not the Previous Router, is 1020 larger than current resources allow or larger than the configured 1021 maximum for the router then the router MAY allocate a smaller 1022 buffer. If an initialization request from the Previous Router cannot 1023 be satisfied in full then the router MUST reply with a negative 1024 acknowledgment. In the case that the Buffer Size field is zero, then 1025 the router SHOULD allocate a buffer with a default size determined by 1026 the router's configuration. 1028 When buffering state is initialized, it MUST be associated with a 1029 primary target address. This target address SHOULD be the MN's 1030 Naddr on the local network. Furthermore, if the target address is 1031 also used as a care-of address, it SHOULD reside as an entry in 1032 the router's Binding Cache, as described for Mobile IPv6 [4]; the 1033 lifetime of the buffering state SHOULD be limited to the lifetime of 1034 that binding. 1036 If buffering state already exists for the target of an initialization 1037 request, the router should attempt to modify the MB state according 1038 to the new values of Buffer Size and Lifetime fields. Zero values 1039 (-1 for the Lifetime field) indicate no change is requested for a 1040 particular field. 1042 If resources are not available to increase the size of the buffer to 1043 the size requested, but a partial increase is possible, the router 1044 MAY choose to increase the buffer to some intermediate size. The 1045 buffered packets, however, MUST NOT be deleted when increasing the 1046 size of a buffer. If the requested size is smaller than the current 1047 size, the router SHOULD reduce the size of the current buffer using 1048 an appropriate replacement policy to drop existing packets that no 1049 longer fit within the new buffer. 1051 7.5. Forwarding Buffered Packets 1053 When a request to forward buffered packets is received, the router 1054 MUST forward any buffered packets associated with the target address. 1055 The packets are forwarded by encapsulating them within a new IPv6 1056 header using the forwarding address as the destination address. If 1057 no buffered packets exist for the target address, the router SHOULD 1058 reply with a negative acknowledgment. 1060 The Buffer Forward suboption may contain a list of Excluded 1061 Packet IDs that identify those packets which should not be forwarded. 1062 The router MUST compute an identifier for each packet in the buffer 1063 and forward the packet only if the computed ID does not match any one 1064 of the Excluded Packet IDs listed in the suboption. This computation 1065 SHOULD be done as soon as possible after the packet is buffered by 1066 the router. Since an unsolicited transfer of buffered packets does 1067 not allow the Previous Router to perform the filtering, the New 1068 Router SHOULD apply any filtering against the Excluded Packet IDs as 1069 soon as the mobile node is ready to receive the buffered packets. 1071 7.6. Unsolicited Forwarding of Buffered Packets 1073 In the case of an NCMA handover, a router MAY initiate state for the 1074 MN and forward existing packets to the New Router. In this case, 1075 the Previous Router router sends to the New Router a HI message 1076 containing a Buffer Initialization suboption with the `A' bit set. 1077 The New Router MAY respond immediately with a Buffer Acknowledgment 1078 suboption or delay the acknowledgement until the Buffer Forward 1079 suboption is received from the MN. 1081 If the Previous Router forwards packets to the New Router, the New 1082 Router MUST buffer these packets and wait for the MN to send a Buffer 1083 Forward suboption associated with a SHIN message before forwarding 1084 them as described in Section 7.5. The SHREQ message sent to the 1085 Previous Router SHOULD include a Buffer Acknowledgment suboption in 1086 response to the HI, unless it had been sent previously. 1088 Having forwarded the buffered packets to the New Router, the Previous 1089 Router MUST continue to buffer any new incoming packets destined for 1090 the target address and SHOULD continue to forward these packets to 1091 the New Router until one of the conditions outlined in Section 7.8 is 1092 met. 1094 7.7. Receiving Packets for a Mobile Node 1096 Once buffering state has been initialized for a target address, all 1097 incoming packets destined for the target address MUST be handled 1098 according to the following rules: 1100 - If the router has already received a Buffer Forward request from 1101 the MN then the router SHOULD forward the packet to the mobile 1102 node's new access address (Naddr). 1104 - Otherwise, the packet MUST be routed to the mobile node at its 1105 original access address, and one or both of the following actions 1106 MUST be performed: 1108 * The router MUST buffer the packet using the buffering state 1109 associated with the target address. 1111 * If the router has already forwarded the mobile node's packets 1112 to the New Router, it SHOULD forward incoming packets to the 1113 New Router. 1115 7.8. Deleting Buffered Packets 1117 Buffered packets MAY be deleted when any of the following events 1118 occur: 1120 - The buffer is full. The router SHOULD use an appropriate 1121 replacement policy, such as LRU, to remove a packet or packets 1122 from the buffer to make room for an incoming packet. 1124 - The packet has been forwarded to the MN's Naddr. 1126 - The packet has been forwarded to the New Router as part of a 1127 NCMA handover and either a BA has been received to confirm the 1128 transfer or the required period of BUFFER_SAVE_TIME has expired. 1130 - The buffer state is released according to the procedures 1131 described in Section 7.9. 1133 7.9. Freeing MB State 1135 Buffering state associated with a MN's target address MUST be deleted 1136 when one of the following events occurs: 1138 - The associated Lifetime expires. 1140 - A Buffer Initialization suboption is received from the MN with 1141 zero lifetime. 1143 - The router becomes a Home Agent for the target address (see [4]). 1145 8. Protocol Constants 1147 The following are the constants that are defined for the managed 1148 buffering protocol for smooth handovers. 1150 BUFFER_SAVE_TIME 10 seconds 1152 9. IANA Considerations 1154 The presented protocol requires the assignment of SubOption Type 1155 values for the three buffering suboptions defined. 1157 10. Security Considerations 1159 The suboptions specified in this document are delivered along 1160 with the Authentication suboption defined in [5]. Thus, packets 1161 buffered for a mobile node will not be purged without authorization 1162 that can be guaranteed to have originated from the mobile node for 1163 whom the packets were intended. In the NCMA case, a security and 1164 authentication association MUST be present between a mobile node, 1165 the access router(s) and the network element which performs NCMA 1166 handovers. 1168 11. Acknowledgments 1170 The authors wish to thank Jari Malinen, Rajeev Koodli and Hannu 1171 Flinck for discussion and review of this document. 1173 References 1175 [1] S. Bradner. Key words for use in RFCs to Indicate Requirement 1176 Levels. Request for Comments (Best Current Practice) 2119, 1177 Internet Engineering Task Force, March 1997. 1179 [2] R. Caceres and V.N. Padmanabhan. Fast and Scalable Hand-offs 1180 in Support of Mobile Internet Audio. Mobile Networks and 1181 Applications, 3(4):351--363, December 1998. 1183 [3] O. Levkowetz (ed.). Problem Description: Reasons For Doing 1184 Context Transfers Between Nodes in an IP Access Network(work in 1185 progress). draft-ietf-seamoby-context-transfer-problem-stat-00.txt, 1186 February 2001. 1188 [4] D. Johnson and C. Perkins. Mobility Support in IPv6 (work in 1189 progress). 1190 draft-ietf-mobileip-ipv6-13.txt, October 2000. 1192 [5] Rajeev Koodli and Charles E. Perkins. A Framework for 1193 Smooth Handovers with Mobile IPv6 (work in progress). 1194 Internet Draft, Internet Engineering Task Force. 1195 draft-koodli-mobileip-smoothv6-02.txt, November 2000. 1197 [6] T. Narten, E. Nordmark, and W. Simpson. Neighbor Discovery for 1198 IP Version 6 (IPv6). Request for Comments (Draft Standard) 2461, 1199 Internet Engineering Task Force, December 1998. 1201 Addresses 1203 The working group can be contacted via the current chairs: 1205 Basavaraj Patil Phil Roberts 1206 Nokia Corporation Motorola 1207 6000 Connection Drive 1501 West Shure Drive 1208 M/S M8-540 1209 Irving, Texas 75039 Arlington Heights, IL 60004 1210 USA USA 1211 Phone: +1 972-894-6709 Phone: +1 847-632-3148 1212 Fax : +1 972-894-5349 1213 EMail: Basavaraj.Patil@nokia.com EMail: QA3445@email.mot.com 1215 Questions about this memo can be directed to the authors: 1217 Govind Krishnamurthi Robert C. Chalmers 1218 Communications Systems Laboratory Department of Computer Science 1219 Nokia Research Center Univ. of California Santa Barbara 1220 5 Wayside Road 1221 Burlington, MA 01803 Santa Barbara, CA 93106 1222 USA USA 1223 +1 781 993 3627 +1 805 893 7520 1224 +1 781 993 1907 (fax) +1 805 893 6553 (fax) 1225 Govind.Krishnamurthi@nokia.com robertc@cs.ucsb.edu 1227 Charles E. Perkins 1228 Communications Systems Laboratory 1229 Nokia Research Center 1230 313 Fairchild Drive 1231 Mountain View, CA 94303 1232 USA 1233 +1 650 625 2986 1234 +1 650 625 2502 (fax) 1235 charliep@iprg.nokia.com