idnits 2.17.1 draft-mkhalil-mobileip-buffer-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 == The page length should not exceed 58 lines per page, but there was 19 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 20 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 document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 27 has weird spacing: '... It is inapp...' == Line 172 has weird spacing: '...ith the previ...' == Line 502 has weird spacing: '... of the buffe...' == Line 709 has weird spacing: '...for new data....' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == 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: F This flag indicates whether or not the FA should forward data stored in the buffer to the MN. This MUST not be set simultaneously with either B or K flag. F = 0, do not forward the data. F = 1, forward the data. == 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: Lease Time The lease time of the buffer required by the mobile node or the lease time of the buffer offered by the mobile agent to the mobile node. The lease time is counted in seconds. The value 0XFFFFFFFF is a reserved to indicate infinite time and it MUST not be used. == 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 a particular IP address does not have any IP IDs, then the sequence number of that IP address MUST not be present in the list of IP Index fields. For example, if the second IP Address listed does not have any IP IDs then any IP Index with value one (1) MUST not be present in this extension. -- 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) == Outdated reference: A later version (-11) exists of draft-ietf-mobileip-optim-08 -- Possible downref: Normative reference to a draft: ref. '1' ** Obsolete normative reference: RFC 2002 (ref. '2') (Obsoleted by RFC 3220) Summary: 5 errors (**), 0 flaws (~~), 12 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Mohamed Khalil 2 INTERNET-DRAFT Haseeb Akhtar 3 Emad Qaddoura 4 Date: October, 1999 Nortel Networks 5 Expires: April, 2000 6 Charles E. Perkins 7 Nokia Research Center 9 Alberto E. Cerpa 10 University of 11 Southern California 13 Buffer Management for Mobile IP 15 Status of this memo 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six 26 months and may be updated, replaced, or obsoleted by other 27 documents at any time. It is inappropriate to use Internet-Drafts 28 as reference material or to cite them other than as "work in 29 progress." 31 The list of current Internet-Drafts can be accessed at 32 http://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 Abstract 39 Security and Smooth handoff with minimal data loss and delay are 40 desirable goals of any mobile network. To minimize data loss while 41 changing FAs, a MN can request the previous FA to allocate buffers 42 for storing its (MN's) data. This buffered data is then forwarded 43 to the MN when it registers with the new FA. This approach may 44 decrease the window of data loss and delay during handoff. 46 Additionally, it may be necessary for the MN to authenticate the 47 new FA before allowing it (the new FA) to receive data from the 48 previous FA. 50 This draft outlines a buffering protocol that minimizes the 51 potential loss of data while the MN changes its subnetwork point of 52 attachment. This draft also provides a way for the MN to verify the 53 new FA during the handoff, if and when that is needed. 55 Table of Contents 56 1.0 Introduction 57 2.0 Terminology 58 3.0 Basic Scenarios 59 3.1 Mobile Assisted Handoff 60 3.2 System Assisted Handoff 61 3.3 Previous FA Notification Extension Handoff 62 4.0 Messages and Extensions 63 4.1 Buffer Control Request Message 64 4.2 Buffer Control Response Message 65 4.3 Buffer Size Extension 66 4.4 Buffer Lease Time Extension 67 4.5 IP Filter Extension 68 4.6 Authentication Extension 69 5.0 Mobile Node Considerations 70 6.0 Foreign Agent Considerations 71 7.0 Buffer Management 72 7.1 Storing Data 73 7.2 Buffer Allocation 74 7.3 Forwarding Data 75 7.4 Buffer Deletion 76 8.0 References 77 9.0 Authors' Address 79 1. Introduction 81 Security and Smooth handoff with minimal data loss and delay are 82 desirable goals of any mobile network. Route Optimization in Mobile 83 IP [1] attempts to solve some of the issues related to smooth 84 handoff. That document, however, does not address the problem of 85 buffering data packets while a Mobile Node (MN) changes its 86 subnetwork point of attachment, i.e., moves to a new FA (Foreign 87 Agent). To minimize data loss while changing FAs, a MN can request 88 the previous FA to allocate buffers for storing its (MN's) data. 89 This buffered data is then forwarded to the MN when it registers 90 with the new FA. This approach may decrease the window of data loss 91 and delay during handoff. 93 Additionally, it may be necessary for the MN to authenticate the 94 new FA before allowing it (the new FA) to receive data from the 95 previous FA. In such cases, the new FA is authenticated by the MN's 96 Home Agent (HA) during the handoff. This draft outlines a buffering 97 protocol that minimizes the potential loss of data while the MN 98 changes its subnetwork point of attachment. This draft also 99 provides a way for the MN to verify the new FA during the handoff, 100 if and when that is needed. 102 2. Terminology 104 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 106 this document are to be interpreted as described in RFC 2119 [3]. 108 3. Basic Scenarios 110 This section describes the basic scenarios during handoff. There 111 are three types of handoff that are mentioned here. The first one 112 is called Mobile Assisted Handoff (MAH). In MAH, the Mobile Node 113 (MN) discovers that it needs to move to a new FA and initiates the 114 handoff. The second one is called System Assisted Handoff (SAH). In 115 this mode, the new FA initiates the handoff after the MN sends a 116 Registration Request. The third type of handoff discussed in this 117 document is called Previous FA Notification Extension Handoff 118 (PFANEH). In PFANEH, the MN starts the handoff process after 119 entering the new FA. It is assumed that there is a security 120 association between new FA and previous FA while performing PFANEH. 122 3.1. Mobile Assisted Handoff 124 The following shows the message flow between the MN and the the FA 125 during a Mobile Assisted Handoff. 127 |----| |-----------| |-----------| 128 | MN | | New FA | |Previous FA| 129 |----| |-----------| |-----------| 130 | | | 131 (a) Buffer Control Request |------------------------------->| 132 |(Start buffering) | 133 | | | 134 (b) Buffer Control Response |<-------------------------------| 135 (OPTIONAL message) | | | 136 | | | 137 (c) Registration Request |------------->| | 138 | | | 139 (d) Registration Reply |<-------------| | 140 |(Successful) | | 141 | | | 142 (e) Buffer Control Request |------------------------------->| 143 (OPTIONAL message) |(Forward data)| | 144 | | | 145 (f) Buffer Control Response |<-------------------------------| 146 (OPTIONAL message) |(OK) | | 147 | | | 149 Figure (1): Buffer Management for Mobile Assisted Handoff 151 The following is a brief description of Figure (1). 153 (a) Buffer Control Request message is sent to the previous FA as 154 soon as MN discovers that it needs to move to a new FA. The 155 previous FA starts to buffer data that are destined for the MN. 157 (b) The previous FA returns OPTIONAL Buffer Control Response 158 message to the MN. 160 (c) The MN moves to new FA and sends a Registration Request. 162 (d) The new FA registers the MN and returns a successful 163 Registration Reply message. 165 (e) The MN sends Buffer Control Request message to the previous 166 FA requesting it to forward the buffered data. 168 (f) The previous FA returns OPTIONAL Buffer Control Response 169 message to the MN. 171 During MAH, if a MN looses its direct communication (over the air) 172 with the previous FA and fails to receive an expected Buffer 173 Control Response message, the MN then MUST change to either SAH or 174 PFNEH mode (as described below) upon entering the new FA. 176 3.2. System Assisted Handoff 178 The following shows the message flow between the MN and the FA 179 during a System Assisted Handoff. 181 |----| |-----------| |-----------| 182 | MN | | New FA | |Previous FA| 183 |----| |-----------| |-----------| 184 | | | 185 (a) Registration Request |------------->| | 186 (with Buffer Control | | | 187 Request extension and | | | 188 Previous FA | | | 189 Notification extension)| | | 190 | | | 191 (b) Binding Update | |---------------->| 192 (with Buffer Control | |(Start buffering)| 193 Request extension) | | | 194 | | | 195 (c) Binding Acknowledgement | |<----------------| 196 (with OPTIONAL Buffer | |(OK) | 197 Control Response | | | 198 extension) | | | 199 | | | 200 (d) Binding Acknowledgement |<-------------| | 201 (with OPTIONAL Buffer |(OK) | | 202 Control Response | | | 203 extension) | | | 204 | | | 205 (e) Registration Reply |<-------------| | 206 |(Successful) | | 207 | | | 208 (f) Buffer Control Request |------------------------------->| 209 |(Forward data)| | 210 | | | 211 (g) Buffer Control Response |<-------------------------------| 212 (OPTIONAL message) |(OK) | | 213 | | | 215 Figure (2): Buffer Management for System Assisted Handoff 217 The following is a brief description of Figure (2). 219 (a) The MN moves to a new FA and sends a Registration Request 220 with Buffer Control Request extension and Previous FA 221 Notification extension. 223 (b) The new FA sends a Binding Update message with Buffer Control 224 Request extension to the previous FA (detailed in the Previous 225 FA Notification extension). At this point, the previous FA 226 should start to buffer data (according to the specifications 227 provided by the Buffer Control Request) that are destined for 228 the MN. 230 (c) The previous FA sends OPTIONAL Binding Acknowledgement 231 message with Buffer Control Response extension to the new FA. 233 (d) The new FA forwards the OPTIONAL Binding Acknowledgement 234 message with Buffer Control Response extension to the MN. 236 (e) The new FA registers the MN and returns a successful 237 Registration Reply message. 239 (f) The MN sends Buffer Control Request message to the previous 240 FA requesting it to forward the buffered data. 242 (g) The previous FA returns OPTIONAL Buffer Control Response 243 message to the MN. 245 During SAH, if a MN receives a successful Registration Reply before 246 an expected Binding Acknowledgment from the previous FA, the MN 247 MUST wait for the Binding Acknowledgement message prior to 248 executing (f). 250 3.3. Previous FA Notification Extension Handoff 252 The following shows the message flow between the MN and the the FA 253 during a handoff that uses Previous Foreign Agent Notification 254 extension. 256 |----| |-----------| |-----------| 257 | MN | | New FA | |Previous FA| 258 |----| |-----------| |-----------| 259 | | | 260 (a) Registration Request |------------------------------->| 261 (with Buffer Control |(Start buffering) | 262 Request extension) | | | 263 | | | 264 (b) Registration Reply |<-------------------------------| 265 (with OPTIOINAL Buffer |(Successful) | | 266 Control Response | | | 267 extension) | | | 268 | | | 269 (c) Registration Request |------------->| | 270 (with two Buffer Control|(Start | | 271 Request extensions and | buffering and| | 272 Previous FA | request | | 273 Notification extension)| previous FA | | 274 | to forward | | 275 | data to MN) | | 276 | | | 277 (d) Binding Update | |---------------->| 278 (with Buffer Control | |(Forward data) | 279 Request extension) | | | 280 | | | 281 | | | 282 (e) Registration Reply |<-------------| | 283 (with OPTINAL Buffer |(Successful) | | 284 Control Response | | | 285 extension) | | | 286 | | | 288 Figure (3): Buffer Management for Previous FA Notification Extension 289 Handoff 291 The following is a brief description of Figure (3). 293 (a) The MN sends a Registration Request to the FA (shown as 294 previous FA here) at the initial registration with Buffer 295 Control Request extension. FA allocates a buffer for the MN. 297 The MN could have sent a Buffer Control Request message (as 298 illustrated in section 4.1) to the FA any time after the 299 registration to initiate the buffering. In this example, the 300 Buffer Control Request message is added as an extension to the 301 Registration Request message only for the purpose of better 302 illustration. 304 (b) The FA (shown as previous FA here) sends a Registration 305 Reply with OPTIONAL Buffer Control Response extension to the 306 MN. 308 (c) The MN moves to a new subnetwork point of attachment and 309 sends a Registration Request message to the new FA with 310 Previous FA Notification extension. It also adds two Buffer 311 Control Request extensions. One for the new FA (with B = 1) to 312 start buffering for the MN and the other for the previous FA 313 (with F = 1) so that it can forward the data to the MN (see 314 section 4.0) 316 Both of these extensions MAY include other relevant information 317 (IP Filter Extension, for example) pertaining to buffer 318 management. Note also that the Buffer Control Request extension 319 is included with the Registration Request message only for the 320 convenience of illustration. 322 (d) The new FA creates a buffer for the MN and continues to 323 buffer its data. This buffer is created according to the 324 specification provided in the Buffer Control Request extension 325 that was sent with the B bit set (B = 1). 327 The FA also sends a Binding Update to the previous FA with the 328 Previous FA Notification extension as well as the Buffer 329 Control Request extension that was sent with the F bit set (F = 330 1). 332 The previous FA starts to forward data to MN as soon as it 333 receives the Binding Update message (according to the 334 specifications provided in the Buffer Control Request 335 extension). 337 (e) The new FA registers the MN and returns a successful 338 Registration Reply message with the OPTIONAL Buffer Control 339 Response extension. 341 4. Message and Extension Formats 343 In this section we will describe the formats of messages and 344 extensions that are used for buffer allocation and management. 346 4.1. Buffer Control Request Message 348 This message is sent from the MN to the FA to allocate and manage 349 data buffers for the MN. This message MAY be an individual message 350 or MAY be added as an extension to Registration Request and Binding 351 Update. This message MAY be sent by the MN during registration as 352 an extension to the Registration Request, after the registration as 353 an independent message, or prior to (or as soon as) the discovery 354 of handoff as an independent message. This message MAY also be sent 355 by a new FA to a previous FA as an extension to Binding Update 356 message. This message MUST be implemented by both the FA and the MN 357 for all of the scenarios (MAH, SAH and PFNEH) mentioned above. 359 The structure of this message is shown below. 361 0 1 2 3 362 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 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 | Type |A|B|F|I|K|L|D| reserved | 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 | MN-IP Address | 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 | | 369 + Identification + 370 | | 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 Type TBD 375 A This flag indicates whether or not the FA should allocate a 376 buffer for the MN. 377 A = 0, allocate a buffer of default size (as decided by the 378 FA). 379 A = 1, allocate a buffer of size defined in the Buffer Size 380 extension (see section 4.3). Buffer Size extension MUST be 381 included if this option (A = 1) is selected. 383 B This flag indicates whether or not the FA should start 384 buffering data that are destined for the MN. This MUST NOT 385 be set simultaneously with the F bit. 386 B = 0, do not buffer data. 387 B = 1, start to buffer data. 389 D This flag indicates whether or not the FA should stop 390 buffering, deliver all the packets buffered so far and then 391 finally delete the buffer previously allocated for the MN. 392 D = 0, do not stop buffering or delete MN's buffer. 393 D = 1, stop, deliver all packets buffered so far to the MN 394 and then delete MN's buffer. 396 F This flag indicates whether or not the FA should forward 397 data stored in the buffer to the MN. This MUST not be set 398 simultaneously with either B or K flag. 399 F = 0, do not forward the data. 400 F = 1, forward the data. 402 I This flag indicates whether or not the Buffer Control 403 Request message has the Identification field. 404 I = 0, Identification field is not included. 405 I = 1, Identification field is included. 407 K This flag indicates whether or not the FA should send an 408 acknowledgement (Buffer Control Response) message to the 409 MN. 410 K = 0, FA should not send any acknowledgement message. 411 K = 1, FA should send an acknowledgement message. 412 Appropriate extensions MUST be added if the FA can not 413 allocate the buffer resources requested by the MN. 415 L This flag indicates the type of the buffer. 416 L = 0, a fixed length buffer. 417 L = 1, a variable length buffer. 419 MN IP Address 420 MN's home IP address. 422 Identification 423 An optional 64-bit number, constructed by the MN as 424 specified in RFC 2002 [2]. It is used for identifying the 425 response to Buffer Control Request message. It is also used 426 as protection a from replay attacks. It's included in the 427 message if the I flag is set (I = 1). 429 4.2. Buffer Control Response Message 431 This message is sent from the FA to the MN in response to Buffer 432 Control Request message. This message MAY be an individual message 433 or MAY be added as an extension to Registration Reply and Binding 434 Acknowledgement. The implementation of this message is OPTIONAL for 435 both the FA and the MN. 437 The structure of this message is shown below. 439 0 1 2 3 440 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 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 | Type | A | reserved | 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 | Sender IP Address | 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 | | 447 + Identification + 448 | | 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 451 Type TBD 453 A This flag indicates if the buffer specifications provided 454 by the MN (in the Buffer Control Request message) is 455 rejected, accepted or partially accepted by the FA. The 456 partial acceptance of the buffer specifications MAY occur 457 if the FA's system resource can not accommodate all the 458 requirements requested by the MN. If this option is 459 selected, the available buffer resources of the FA MUST be 460 sent by the appropriate extensions (e.g. Buffer Size 461 Extension or Buffer Lease Time extension) to the MN. 462 A = 0, FA accepts the buffer specifications. 463 A = 1, FA partially accepts the buffer specifications. New 464 specifications are sent with the appropriate 465 extensions. 466 A = 2, FA rejects the buffer specifications. 468 Sender IP Address 469 IP address of the FA. 471 Identification 472 A 64-bit number, constructed by the MN [2] and sent in 473 Buffer Control Request or Registration Request message. It 474 is used for identifying the response to Buffer Control 475 Request or Registration Request message. It is also used as 476 a protection from replay attacks. 478 4.3. Buffer Size Extension 480 This extension defines the size of the buffer that should be 481 allocated for the MN by the FA or the size of the buffer that is 482 offered by FA to the MN. 484 The Buffer Size Extension is defined as follows: 486 0 1 2 3 487 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 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 489 | Type | Length | size | 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 Type TBD 494 Length Length of this extension in number of bytes. 496 Size The size of the buffer required by the MN or the size 497 of the buffer offered by the FA to the MN. This size 498 increases in increment(s) of 1KB. 500 4.4. Buffer Lease Time Extension 502 This extension defines the lease time of the buffer that should be 503 allocated to the MN by the FA or the lease time of the buffer that 504 is offered by FA to the MN. 506 The Buffer Lease Time Extension is defined as follows: 507 0 1 2 3 508 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 509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 510 | Type | Length | reserved | 511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 512 | Lease Time | 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 515 Type TBD 517 Length Length of this extension in number of bytes. 519 Lease Time 520 The lease time of the buffer required by the mobile 521 node or the lease time of the buffer offered by 522 the mobile agent to the mobile node. The lease time is 523 counted in seconds. The value 0XFFFFFFFF is 524 a reserved to indicate infinite time and it MUST not be 525 used. 527 4.5. IP Filter Extension 529 This extension is used to filter (discard) the data packets 530 destined for the MN based on their source IP addresses and the 531 packet Identification field. 533 The IP Filter Extension is defined as follows: 534 0 1 2 3 535 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 536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 537 | Type | Length | IP Count |C| Reserved | 538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 539 | IP address 0 | 540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 541 . . 542 . . 543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 544 | IP address N | 545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 546 | IP Index 1 | ID Count | IP ID 1 | 547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 548 | IP ID 2 | IP ID 3 | 549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 550 . . 551 . . 552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 553 | IP ID M-1 | IP ID M | 554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 555 . . 556 . . 557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 558 | IP Index K | ID Count | IP ID 1 | 559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 560 | IP ID 2 | IP ID 3 | 561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 562 . . 563 . . 564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 565 | IP ID M-1 | IP ID M | 566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 568 Type TBD 570 Length Length of this extension in number of bytes. 572 IP Count The number of IP addresses listed in this extension. 574 C This flag indicates whether or not the FA should buffer 575 packets that has the same or different source IP addresses 576 listed in this extension. This flag SHOULD be checked only 577 for those IP addresses that do not include any IP 578 Identification(s) in this extension. 579 C = 0, buffer or forward packets that have the same 580 IP addresses as listed in this extension. 581 C = 1, buffer or forward packets that do not have the same 582 IP addresses as listed in this extension. 584 IP Address(s) 585 The IP address(s) included in this extension. 587 ID Count The number of IP identifications included for a particular 588 IP address. 590 IP Index This field uniquely identifies an IP address from the 591 list of the IP addresses included in this extension. The 592 value of this field corresponds to the sequence number 593 (starting at zero) in which a particular IP address is 594 listed. 596 For example, if this field contains zero (0), then it 597 identifies the first IP address listed in this extension. 598 Hence, all IP IDs corresponding to that IP address are 599 included in this tuple , where n is the number of IP IDs for this 601 particular IP address. Similarly, if an IP Index field 602 contains two (2), then all the IP IDs listed followed the 603 tuple 604 correspond to the third IP address listed in this 605 extension. 607 If a particular IP address does not have any IP IDs, then 608 the sequence number of that IP address MUST not be present 609 in the list of IP Index fields. For example, if the second 610 IP Address listed does not have any IP IDs then any IP 611 Index with value one (1) MUST not be present in this 612 extension. 614 If any IP address listed in the this extension is not 615 identified by the IP Index field, then all of those IP 616 addresses MUST be completely filtered (based on the C 617 flag). 619 IP ID The IP identification(s) included for the IP address 620 identified by an IP Index. If the very last IP ID happens 621 to be in the lower 16 bytes (IP ID M-1 in the above 622 figure), then the upper 16 bytes MUST be padded. 624 4.6. Authentication Extension 626 The authentication extension is used to authenticate Buffer Control 627 Request and Buffer Control Response messages, only if they are sent 628 independently (that is, they are not sent as extensions to 629 Registration Request or Binding Update). 631 It has the same format and default algorithm support requirements 632 as the Authentication Extensions (MN-FA, MN-HA, HA-FA) defined in 633 the base Mobile IP [2]. 635 The authenticator value is computed, as before, from the stream of 636 bytes including the shared secret key, UDP payload, all prior 637 extensions, and the type and length of this extension, but not 638 including the authenticator field itself nor the UDP header. 640 5. Mobile Node Considerations 642 The MN MAY send the Buffer Control Request to the FA as a separate 643 message or as an extension to Registration Request message. The MN 644 MAY receive the Buffer Control Response from the FA as a separate 645 message or as an extension to the Registration Reply and Binding 646 Acknowledgement messages. 648 The MN MUST explicitly notify the FA (via the IP Filter extension) 649 if the buffering needs to be discriminated based on the source IP 650 address and/or the IP Identification field. 652 The MN MAY add two Buffer Control Request extensions to a single 653 Registration Request message while sending it to a FA. This 654 situation MAY occur when a MN needs to notify a new FA to allocate 655 a buffer and at the same time, the MN needs to notify the previous 656 FA (via the new FA) to forward buffered data. The MN MUST also 657 include a Previous FA Notification extension to this Registration 658 Request message. In this case, MN MUST set the B bit (B = 1) in the 659 Buffer Control Request message that is destined for the new FA. The 660 MN MUST also set the F bit(F = 1) in the Buffer Control Request 661 message that is destined for the previous FA. 663 6. Foreign Agent Considerations 665 The MN MAY send the Buffer Control Request to a FA as a separate 666 message or as an extension to Registration Request message. The FA 667 MAY send Buffer Control Request to another FA as a separate message 668 or as an extension to Binding Update message. 670 The MN MAY send the Buffer Control Response to a FA as a separate 671 message or as an extension to the Registration Reply message. 673 The FA MAY receive two Buffer Control extensions in a single 674 Registration Request message from a MN. This Registration Request 675 MUST also include a Previous FA Notification extension. The MN MUST 676 put these three extensions in the following order: 678 First, the Buffer Control Request extension for the new FA. 679 Second, the Previous FA Notification extension. And, third, the 680 Buffer Control Request extension for the previous FA. 682 The FA MUST allocate the buffer resources for the MN according to 683 the specifications provided by the Buffer Control Request that has 684 its B bit set (B = 1). The FA MUST send the other Buffer Control 685 Request that has its F bit set (F = 1) to the previous FA (detailed 686 in the Previous FA Notification extension [1]) as an extension to 687 the Binding Update message. 689 The FA MUST use the MN's lifetime sent with the Registration 690 Request [2] as the default lease time of the buffer unless 691 otherwise specified. 693 7. Buffer Management 695 7.1. Storing Data 697 The data stored in the buffer is managed according to the type of 698 buffer mentioned in the L field of the Buffer Contrl Request 699 message. If the length of the buffer is fixed (L = 0) then the data 700 is stored in the buffer using the FIFO (First In First Out) policy. 701 If and when the buffer gets full, data at the front of the buffer 702 (the oldest data) is discarded to make room for new data inserted 703 at the end of the buffer. 705 If the length of the buffer is variable (L = 1) and the buffer is 706 full then the system will try to expand the size of the buffer to 707 accommodate the new coming data. If the expansion is impossible 708 then the data at the front of the buffer is discarded to make room 709 for new data. 711 7.2. Buffer Allocation 713 One of the following cases occurs during buffer allocation, that 714 is, the MN sends Buffer Control Request message to the FA with the 715 A bit set (A = 1): 717 1 - If no buffer is allocated for the MN then the allocation of 718 buffer is handled as follows: 720 - If the K is set to 0 (zero) and the MN includes 721 the Buffer Size extension and/or Buffer Lease Time Extension, 722 then the buffer is allocated according to the size and the 723 lease time mentioned in these extensions. 725 - If, however, the FA is unable to accommodate the 726 specifications (size, lease time etc.) requested by the 727 MN, the default values are then used to allocate the 728 buffer. 730 - If either one or all of these extensions are not 731 included then the FA's default values are used to allocate 732 the buffer. 734 - If the K flag is set to 1 (one) and the MN's requested 735 buffer specifications (included in the Buffer Size extension 736 and/or Buffer Lease Time extension) can not be accommodated 737 by the FA, then it (the FA) MUST suggest its own buffer 738 specifications (size, lease time etc.) to the MN through the 739 Buffer Control Response message using the appropriate 740 extensions. At the same time, the FA MUST allocate those 741 suggested buffer resources for the MN. 743 - If the new buffer specifications (size, lease time etc.) 744 sent by the FA is not acceptable to the MN then it (the MN) 745 MAY send a new Buffer Control Request message to the FA with 746 the new specifications. 748 - If the FA receives a Buffer Control Request message with 749 both A and B flags set to 1 (one), the allocation of the 750 buffer is done first followed by the start of buffering of 751 all the appropriate packets that are destined for the MN. 753 2 - If the FA receives a Buffer Control Request message for 754 a MN that has already allocated buffer, the FA then re- 755 allocates the buffer according the most recent Buffer Control 756 Request message. 758 7.3. Forwarding Data 760 Upon receiving a Buffer Control Request message with F = 1 and D = 761 1, the FA MUST delete the buffer allocated to the MN after 762 forwarding the entire buffer. Future packets received after this 763 message are lost. 765 Upon receiving a Buffer Control Request message with F = 1 and D = 766 0, the FA MUST delete the buffer allocated to the MN after 767 forwarding the entire buffer. Future packets received after this 768 message are immediately (without being buffered) forward to the MN. 769 The filtering rules (if any) specified while allocating the buffer 770 MUST be kept in place. The forwarding will continue until the lease 771 time expires. 773 7.4. Buffer Deletion 775 The buffer will be implicitly deleted if the lease time expires. It 776 will be explicitly deleted if the MN sends a Buffer Control Request 777 message with the D flag set to 1 (one). 779 8. References 781 [1] Charlie E. Perkins and David B. Johnson, Route Optimization in 782 Mobile IP, draft-ietf-mobileip-optim-08.txt, February 1999. 783 (work in progress). 785 [2] Charlie Perkins (Editor), IP Mobility Support, RFC 2002, 786 October 1996. 788 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirements 789 Levels", BCP 14, RFC 2119, March 1997. 791 9. Authors' Addresses 793 Questions about this memo can be directed to: 795 Mohamed M khalil 796 2221 Lakeside Blvd. 797 Richardson TX 75082-4399 798 Phone : 972 685-0564 799 Fax : 972 685-3207 800 email : mkhalil@nortelnetworks.com 801 Haseeb Akhtar 802 2221 Lakeside Blvd. 803 Richardson TX 75082-4399 804 Phone : 972 684-8850 805 Fax : 972 685-3207 806 email : haseeb@nortelnetworks.com 808 Emad A. Qaddoura 809 2221 Lakeside Blvd. 810 Richardson TX 75082-4399 811 Phone : 972 684-2705 812 Fax : 972 685-3207 813 email : emadq@nortelnetworks.com 815 Charles E. Perkins 816 Nokia Research Center 817 Nokia Corporation 818 313 Fairchild Dr. 819 Mountain View, CA 94043 820 Phone : 650-625-2986 821 Fax : 650-691-2170 822 email : charliep@iprg.nokia.com 823 Web : http://www.iprg.nokia.com/~charliep 825 Alberto E. Cerpa 826 University of Southern California 827 Department of Computer Science 828 941 W. 37th Place, SAL 300 829 Los Angeles, CA 90089-0781 USA 830 Phone : (310) 822-1511 x8161 831 mobile: (213) 841-2326 832 Fax : (310) 823-6714 833 email : cerpa@usc.edu 834 Web : http://www-scf.usc.edu/~cerpa