Internet Engineering Task Force Mohamed Khalil INTERNET-DRAFT Haseeb Akhtar Emad Qaddoura Date: October, 1999 Nortel Networks Expires: April, 2000 Charles E. Perkins Nokia Research Center Alberto E. Cerpa University of Southern California Buffer Management for Mobile IP Status of this memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract Security and Smooth handoff with minimal data loss and delay are desirable goals of any mobile network. To minimize data loss while changing FAs, a MN can request the previous FA to allocate buffers for storing its (MN's) data. This buffered data is then forwarded to the MN when it registers with the new FA. This approach may Khalil, et al. Expires April 2000 [Page 1] Internet-Draft Buffer Data 16 October 1999 decrease the window of data loss and delay during handoff. Additionally, it may be necessary for the MN to authenticate the new FA before allowing it (the new FA) to receive data from the previous FA. This draft outlines a buffering protocol that minimizes the potential loss of data while the MN changes its subnetwork point of attachment. This draft also provides a way for the MN to verify the new FA during the handoff, if and when that is needed. Table of Contents 1.0 Introduction 2.0 Terminology 3.0 Basic Scenarios 3.1 Mobile Assisted Handoff 3.2 System Assisted Handoff 3.3 Previous FA Notification Extension Handoff 4.0 Messages and Extensions 4.1 Buffer Control Request Message 4.2 Buffer Control Response Message 4.3 Buffer Size Extension 4.4 Buffer Lease Time Extension 4.5 IP Filter Extension 4.6 Authentication Extension 5.0 Mobile Node Considerations 6.0 Foreign Agent Considerations 7.0 Buffer Management 7.1 Storing Data 7.2 Buffer Allocation 7.3 Forwarding Data 7.4 Buffer Deletion 8.0 References 9.0 Authors' Address 1. Introduction Security and Smooth handoff with minimal data loss and delay are desirable goals of any mobile network. Route Optimization in Mobile IP [1] attempts to solve some of the issues related to smooth handoff. That document, however, does not address the problem of buffering data packets while a Mobile Node (MN) changes its subnetwork point of attachment, i.e., moves to a new FA (Foreign Agent). To minimize data loss while changing FAs, a MN can request the previous FA to allocate buffers for storing its (MN's) data. This buffered data is then forwarded to the MN when it registers Khalil, et al. Expires April 2000 [Page 2] Internet-Draft Buffer Data 16 October 1999 with the new FA. This approach may decrease the window of data loss and delay during handoff. Additionally, it may be necessary for the MN to authenticate the new FA before allowing it (the new FA) to receive data from the previous FA. In such cases, the new FA is authenticated by the MN's Home Agent (HA) during the handoff. This draft outlines a buffering protocol that minimizes the potential loss of data while the MN changes its subnetwork point of attachment. This draft also provides a way for the MN to verify the new FA during the handoff, if and when that is needed. 2. Terminology The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [3]. 3. Basic Scenarios This section describes the basic scenarios during handoff. There are three types of handoff that are mentioned here. The first one is called Mobile Assisted Handoff (MAH). In MAH, the Mobile Node (MN) discovers that it needs to move to a new FA and initiates the handoff. The second one is called System Assisted Handoff (SAH). In this mode, the new FA initiates the handoff after the MN sends a Registration Request. The third type of handoff discussed in this document is called Previous FA Notification Extension Handoff (PFANEH). In PFANEH, the MN starts the handoff process after entering the new FA. It is assumed that there is a security association between new FA and previous FA while performing PFANEH. 3.1. Mobile Assisted Handoff The following shows the message flow between the MN and the the FA during a Mobile Assisted Handoff. Khalil, et al. Expires April 2000 [Page 3] Internet-Draft Buffer Data 16 October 1999 |----| |-----------| |-----------| | MN | | New FA | |Previous FA| |----| |-----------| |-----------| | | | (a) Buffer Control Request |------------------------------->| |(Start buffering) | | | | (b) Buffer Control Response |<-------------------------------| (OPTIONAL message) | | | | | | (c) Registration Request |------------->| | | | | (d) Registration Reply |<-------------| | |(Successful) | | | | | (e) Buffer Control Request |------------------------------->| (OPTIONAL message) |(Forward data)| | | | | (f) Buffer Control Response |<-------------------------------| (OPTIONAL message) |(OK) | | | | | Figure (1): Buffer Management for Mobile Assisted Handoff The following is a brief description of Figure (1). (a) Buffer Control Request message is sent to the previous FA as soon as MN discovers that it needs to move to a new FA. The previous FA starts to buffer data that are destined for the MN. (b) The previous FA returns OPTIONAL Buffer Control Response message to the MN. (c) The MN moves to new FA and sends a Registration Request. (d) The new FA registers the MN and returns a successful Registration Reply message. (e) The MN sends Buffer Control Request message to the previous FA requesting it to forward the buffered data. (f) The previous FA returns OPTIONAL Buffer Control Response message to the MN. During MAH, if a MN looses its direct communication (over the air) with the previous FA and fails to receive an expected Buffer Khalil, et al. Expires April 2000 [Page 4] Internet-Draft Buffer Data 16 October 1999 Control Response message, the MN then MUST change to either SAH or PFNEH mode (as described below) upon entering the new FA. 3.2. System Assisted Handoff The following shows the message flow between the MN and the FA during a System Assisted Handoff. |----| |-----------| |-----------| | MN | | New FA | |Previous FA| |----| |-----------| |-----------| | | | (a) Registration Request |------------->| | (with Buffer Control | | | Request extension and | | | Previous FA | | | Notification extension)| | | | | | (b) Binding Update | |---------------->| (with Buffer Control | |(Start buffering)| Request extension) | | | | | | (c) Binding Acknowledgement | |<----------------| (with OPTIONAL Buffer | |(OK) | Control Response | | | extension) | | | | | | (d) Binding Acknowledgement |<-------------| | (with OPTIONAL Buffer |(OK) | | Control Response | | | extension) | | | | | | (e) Registration Reply |<-------------| | |(Successful) | | | | | (f) Buffer Control Request |------------------------------->| |(Forward data)| | | | | (g) Buffer Control Response |<-------------------------------| (OPTIONAL message) |(OK) | | | | | Figure (2): Buffer Management for System Assisted Handoff Khalil, et al. Expires April 2000 [Page 5] Internet-Draft Buffer Data 16 October 1999 The following is a brief description of Figure (2). (a) The MN moves to a new FA and sends a Registration Request with Buffer Control Request extension and Previous FA Notification extension. (b) The new FA sends a Binding Update message with Buffer Control Request extension to the previous FA (detailed in the Previous FA Notification extension). At this point, the previous FA should start to buffer data (according to the specifications provided by the Buffer Control Request) that are destined for the MN. (c) The previous FA sends OPTIONAL Binding Acknowledgement message with Buffer Control Response extension to the new FA. (d) The new FA forwards the OPTIONAL Binding Acknowledgement message with Buffer Control Response extension to the MN. (e) The new FA registers the MN and returns a successful Registration Reply message. (f) The MN sends Buffer Control Request message to the previous FA requesting it to forward the buffered data. (g) The previous FA returns OPTIONAL Buffer Control Response message to the MN. During SAH, if a MN receives a successful Registration Reply before an expected Binding Acknowledgment from the previous FA, the MN MUST wait for the Binding Acknowledgement message prior to executing (f). 3.3. Previous FA Notification Extension Handoff The following shows the message flow between the MN and the the FA during a handoff that uses Previous Foreign Agent Notification extension. Khalil, et al. Expires April 2000 [Page 6] Internet-Draft Buffer Data 16 October 1999 |----| |-----------| |-----------| | MN | | New FA | |Previous FA| |----| |-----------| |-----------| | | | (a) Registration Request |------------------------------->| (with Buffer Control |(Start buffering) | Request extension) | | | | | | (b) Registration Reply |<-------------------------------| (with OPTIOINAL Buffer |(Successful) | | Control Response | | | extension) | | | | | | (c) Registration Request |------------->| | (with two Buffer Control|(Start | | Request extensions and | buffering and| | Previous FA | request | | Notification extension)| previous FA | | | to forward | | | data to MN) | | | | | (d) Binding Update | |---------------->| (with Buffer Control | |(Forward data) | Request extension) | | | | | | | | | (e) Registration Reply |<-------------| | (with OPTINAL Buffer |(Successful) | | Control Response | | | extension) | | | | | | Figure (3): Buffer Management for Previous FA Notification Extension Handoff The following is a brief description of Figure (3). (a) The MN sends a Registration Request to the FA (shown as previous FA here) at the initial registration with Buffer Control Request extension. FA allocates a buffer for the MN. The MN could have sent a Buffer Control Request message (as illustrated in section 4.1) to the FA any time after the registration to initiate the buffering. In this example, the Buffer Control Request message is added as an extension to the Registration Request message only for the purpose of better illustration. Khalil, et al. Expires April 2000 [Page 7] Internet-Draft Buffer Data 16 October 1999 (b) The FA (shown as previous FA here) sends a Registration Reply with OPTIONAL Buffer Control Response extension to the MN. (c) The MN moves to a new subnetwork point of attachment and sends a Registration Request message to the new FA with Previous FA Notification extension. It also adds two Buffer Control Request extensions. One for the new FA (with B = 1) to start buffering for the MN and the other for the previous FA (with F = 1) so that it can forward the data to the MN (see section 4.0) Both of these extensions MAY include other relevant information (IP Filter Extension, for example) pertaining to buffer management. Note also that the Buffer Control Request extension is included with the Registration Request message only for the convenience of illustration. (d) The new FA creates a buffer for the MN and continues to buffer its data. This buffer is created according to the specification provided in the Buffer Control Request extension that was sent with the B bit set (B = 1). The FA also sends a Binding Update to the previous FA with the Previous FA Notification extension as well as the Buffer Control Request extension that was sent with the F bit set (F = 1). The previous FA starts to forward data to MN as soon as it receives the Binding Update message (according to the specifications provided in the Buffer Control Request extension). (e) The new FA registers the MN and returns a successful Registration Reply message with the OPTIONAL Buffer Control Response extension. 4. Message and Extension Formats In this section we will describe the formats of messages and extensions that are used for buffer allocation and management. 4.1. Buffer Control Request Message This message is sent from the MN to the FA to allocate and manage data buffers for the MN. This message MAY be an individual message Khalil, et al. Expires April 2000 [Page 8] Internet-Draft Buffer Data 16 October 1999 or MAY be added as an extension to Registration Request and Binding Update. This message MAY be sent by the MN during registration as an extension to the Registration Request, after the registration as an independent message, or prior to (or as soon as) the discovery of handoff as an independent message. This message MAY also be sent by a new FA to a previous FA as an extension to Binding Update message. This message MUST be implemented by both the FA and the MN for all of the scenarios (MAH, SAH and PFNEH) mentioned above. The structure of this message is shown below. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type |A|B|F|I|K|L|D| reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MN-IP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Identification + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TBD A This flag indicates whether or not the FA should allocate a buffer for the MN. A = 0, allocate a buffer of default size (as decided by the FA). A = 1, allocate a buffer of size defined in the Buffer Size extension (see section 4.3). Buffer Size extension MUST be included if this option (A = 1) is selected. B This flag indicates whether or not the FA should start buffering data that are destined for the MN. This MUST NOT be set simultaneously with the F bit. B = 0, do not buffer data. B = 1, start to buffer data. D This flag indicates whether or not the FA should stop buffering, deliver all the packets buffered so far and then finally delete the buffer previously allocated for the MN. D = 0, do not stop buffering or delete MN's buffer. D = 1, stop, deliver all packets buffered so far to the MN and then delete MN's buffer. Khalil, et al. Expires April 2000 [Page 9] Internet-Draft Buffer Data 16 October 1999 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. I This flag indicates whether or not the Buffer Control Request message has the Identification field. I = 0, Identification field is not included. I = 1, Identification field is included. K This flag indicates whether or not the FA should send an acknowledgement (Buffer Control Response) message to the MN. K = 0, FA should not send any acknowledgement message. K = 1, FA should send an acknowledgement message. Appropriate extensions MUST be added if the FA can not allocate the buffer resources requested by the MN. L This flag indicates the type of the buffer. L = 0, a fixed length buffer. L = 1, a variable length buffer. MN IP Address MN's home IP address. Identification An optional 64-bit number, constructed by the MN as specified in RFC 2002 [2]. It is used for identifying the response to Buffer Control Request message. It is also used as protection a from replay attacks. It's included in the message if the I flag is set (I = 1). 4.2. Buffer Control Response Message This message is sent from the FA to the MN in response to Buffer Control Request message. This message MAY be an individual message or MAY be added as an extension to Registration Reply and Binding Acknowledgement. The implementation of this message is OPTIONAL for both the FA and the MN. The structure of this message is shown below. Khalil, et al. Expires April 2000 [Page 10] Internet-Draft Buffer Data 16 October 1999 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | A | reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sender IP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Identification + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TBD A This flag indicates if the buffer specifications provided by the MN (in the Buffer Control Request message) is rejected, accepted or partially accepted by the FA. The partial acceptance of the buffer specifications MAY occur if the FA's system resource can not accommodate all the requirements requested by the MN. If this option is selected, the available buffer resources of the FA MUST be sent by the appropriate extensions (e.g. Buffer Size Extension or Buffer Lease Time extension) to the MN. A = 0, FA accepts the buffer specifications. A = 1, FA partially accepts the buffer specifications. New specifications are sent with the appropriate extensions. A = 2, FA rejects the buffer specifications. Sender IP Address IP address of the FA. Identification A 64-bit number, constructed by the MN [2] and sent in Buffer Control Request or Registration Request message. It is used for identifying the response to Buffer Control Request or Registration Request message. It is also used as a protection from replay attacks. 4.3. Buffer Size Extension This extension defines the size of the buffer that should be allocated for the MN by the FA or the size of the buffer that is offered by FA to the MN. Khalil, et al. Expires April 2000 [Page 11] Internet-Draft Buffer Data 16 October 1999 The Buffer Size Extension is defined as follows: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TBD Length Length of this extension in number of bytes. Size The size of the buffer required by the MN or the size of the buffer offered by the FA to the MN. This size increases in increment(s) of 1KB. 4.4. Buffer Lease Time Extension This extension defines the lease time of the buffer that should be allocated to the MN by the FA or the lease time of the buffer that is offered by FA to the MN. The Buffer Lease Time Extension is defined as follows: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lease Time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TBD Length Length of this extension in number of bytes. 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. Khalil, et al. Expires April 2000 [Page 12] Internet-Draft Buffer Data 16 October 1999 4.5. IP Filter Extension This extension is used to filter (discard) the data packets destined for the MN based on their source IP addresses and the packet Identification field. The IP Filter Extension is defined as follows: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | IP Count |C| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP address 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP address N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP Index 1 | ID Count | IP ID 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP ID 2 | IP ID 3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP ID M-1 | IP ID M | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP Index K | ID Count | IP ID 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP ID 2 | IP ID 3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP ID M-1 | IP ID M | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TBD Length Length of this extension in number of bytes. IP Count The number of IP addresses listed in this extension. Khalil, et al. [Page 13] Internet-Draft Buffer Data 16 October 1999 C This flag indicates whether or not the FA should buffer packets that has the same or different source IP addresses listed in this extension. This flag SHOULD be checked only for those IP addresses that do not include any IP Identification(s) in this extension. C = 0, buffer or forward packets that have the same IP addresses as listed in this extension. C = 1, buffer or forward packets that do not have the same IP addresses as listed in this extension. IP Address(s) The IP address(s) included in this extension. ID Count The number of IP identifications included for a particular IP address. IP Index This field uniquely identifies an IP address from the list of the IP addresses included in this extension. The value of this field corresponds to the sequence number (starting at zero) in which a particular IP address is listed. For example, if this field contains zero (0), then it identifies the first IP address listed in this extension. Hence, all IP IDs corresponding to that IP address are included in this tuple , where n is the number of IP IDs for this particular IP address. Similarly, if an IP Index field contains two (2), then all the IP IDs listed followed the tuple correspond to the third IP address listed in this extension. 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. If any IP address listed in the this extension is not identified by the IP Index field, then all of those IP addresses MUST be completely filtered (based on the C flag). IP ID The IP identification(s) included for the IP address identified by an IP Index. If the very last IP ID happens to be in the lower 16 bytes (IP ID M-1 in the above Khalil, et al. [Page 14] Internet-Draft Buffer Data 16 October 1999 figure), then the upper 16 bytes MUST be padded. 4.6. Authentication Extension The authentication extension is used to authenticate Buffer Control Request and Buffer Control Response messages, only if they are sent independently (that is, they are not sent as extensions to Registration Request or Binding Update). It has the same format and default algorithm support requirements as the Authentication Extensions (MN-FA, MN-HA, HA-FA) defined in the base Mobile IP [2]. The authenticator value is computed, as before, from the stream of bytes including the shared secret key, UDP payload, all prior extensions, and the type and length of this extension, but not including the authenticator field itself nor the UDP header. 5. Mobile Node Considerations The MN MAY send the Buffer Control Request to the FA as a separate message or as an extension to Registration Request message. The MN MAY receive the Buffer Control Response from the FA as a separate message or as an extension to the Registration Reply and Binding Acknowledgement messages. The MN MUST explicitly notify the FA (via the IP Filter extension) if the buffering needs to be discriminated based on the source IP address and/or the IP Identification field. The MN MAY add two Buffer Control Request extensions to a single Registration Request message while sending it to a FA. This situation MAY occur when a MN needs to notify a new FA to allocate a buffer and at the same time, the MN needs to notify the previous FA (via the new FA) to forward buffered data. The MN MUST also include a Previous FA Notification extension to this Registration Request message. In this case, MN MUST set the B bit (B = 1) in the Buffer Control Request message that is destined for the new FA. The MN MUST also set the F bit(F = 1) in the Buffer Control Request message that is destined for the previous FA. 6. Foreign Agent Considerations The MN MAY send the Buffer Control Request to a FA as a separate message or as an extension to Registration Request message. The FA Khalil, et al. [Page 15] Internet-Draft Buffer Data 16 October 1999 MAY send Buffer Control Request to another FA as a separate message or as an extension to Binding Update message. The MN MAY send the Buffer Control Response to a FA as a separate message or as an extension to the Registration Reply message. The FA MAY receive two Buffer Control extensions in a single Registration Request message from a MN. This Registration Request MUST also include a Previous FA Notification extension. The MN MUST put these three extensions in the following order: First, the Buffer Control Request extension for the new FA. Second, the Previous FA Notification extension. And, third, the Buffer Control Request extension for the previous FA. The FA MUST allocate the buffer resources for the MN according to the specifications provided by the Buffer Control Request that has its B bit set (B = 1). The FA MUST send the other Buffer Control Request that has its F bit set (F = 1) to the previous FA (detailed in the Previous FA Notification extension [1]) as an extension to the Binding Update message. The FA MUST use the MN's lifetime sent with the Registration Request [2] as the default lease time of the buffer unless otherwise specified. 7. Buffer Management 7.1. Storing Data The data stored in the buffer is managed according to the type of buffer mentioned in the L field of the Buffer Contrl Request message. If the length of the buffer is fixed (L = 0) then the data is stored in the buffer using the FIFO (First In First Out) policy. If and when the buffer gets full, data at the front of the buffer (the oldest data) is discarded to make room for new data inserted at the end of the buffer. If the length of the buffer is variable (L = 1) and the buffer is full then the system will try to expand the size of the buffer to accommodate the new coming data. If the expansion is impossible then the data at the front of the buffer is discarded to make room for new data. Khalil, et al. [Page 16] Internet-Draft Buffer Data 16 October 1999 7.2. Buffer Allocation One of the following cases occurs during buffer allocation, that is, the MN sends Buffer Control Request message to the FA with the A bit set (A = 1): 1 - If no buffer is allocated for the MN then the allocation of buffer is handled as follows: - If the K is set to 0 (zero) and the MN includes the Buffer Size extension and/or Buffer Lease Time Extension, then the buffer is allocated according to the size and the lease time mentioned in these extensions. - If, however, the FA is unable to accommodate the specifications (size, lease time etc.) requested by the MN, the default values are then used to allocate the buffer. - If either one or all of these extensions are not included then the FA's default values are used to allocate the buffer. - If the K flag is set to 1 (one) and the MN's requested buffer specifications (included in the Buffer Size extension and/or Buffer Lease Time extension) can not be accommodated by the FA, then it (the FA) MUST suggest its own buffer specifications (size, lease time etc.) to the MN through the Buffer Control Response message using the appropriate extensions. At the same time, the FA MUST allocate those suggested buffer resources for the MN. - If the new buffer specifications (size, lease time etc.) sent by the FA is not acceptable to the MN then it (the MN) MAY send a new Buffer Control Request message to the FA with the new specifications. - If the FA receives a Buffer Control Request message with both A and B flags set to 1 (one), the allocation of the buffer is done first followed by the start of buffering of all the appropriate packets that are destined for the MN. 2 - If the FA receives a Buffer Control Request message for a MN that has already allocated buffer, the FA then re- allocates the buffer according the most recent Buffer Control Request message. Khalil, et al. [Page 17] Internet-Draft Buffer Data 16 October 1999 7.3. Forwarding Data Upon receiving a Buffer Control Request message with F = 1 and D = 1, the FA MUST delete the buffer allocated to the MN after forwarding the entire buffer. Future packets received after this message are lost. Upon receiving a Buffer Control Request message with F = 1 and D = 0, the FA MUST delete the buffer allocated to the MN after forwarding the entire buffer. Future packets received after this message are immediately (without being buffered) forward to the MN. The filtering rules (if any) specified while allocating the buffer MUST be kept in place. The forwarding will continue until the lease time expires. 7.4. Buffer Deletion The buffer will be implicitly deleted if the lease time expires. It will be explicitly deleted if the MN sends a Buffer Control Request message with the D flag set to 1 (one). 8. References [1] Charlie E. Perkins and David B. Johnson, Route Optimization in Mobile IP, draft-ietf-mobileip-optim-08.txt, February 1999. (work in progress). [2] Charlie Perkins (Editor), IP Mobility Support, RFC 2002, October 1996. [3] Bradner, S., "Key words for use in RFCs to Indicate Requirements Levels", BCP 14, RFC 2119, March 1997. 9. Authors' Addresses Questions about this memo can be directed to: Mohamed M khalil 2221 Lakeside Blvd. Richardson TX 75082-4399 Phone : 972 685-0564 Fax : 972 685-3207 email : mkhalil@nortelnetworks.com Khalil, et al. [Page 18] Internet-Draft Buffer Data 16 October 1999 Haseeb Akhtar 2221 Lakeside Blvd. Richardson TX 75082-4399 Phone : 972 684-8850 Fax : 972 685-3207 email : haseeb@nortelnetworks.com Emad A. Qaddoura 2221 Lakeside Blvd. Richardson TX 75082-4399 Phone : 972 684-2705 Fax : 972 685-3207 email : emadq@nortelnetworks.com Charles E. Perkins Nokia Research Center Nokia Corporation 313 Fairchild Dr. Mountain View, CA 94043 Phone : 650-625-2986 Fax : 650-691-2170 email : charliep@iprg.nokia.com Web : http://www.iprg.nokia.com/~charliep Alberto E. Cerpa University of Southern California Department of Computer Science 941 W. 37th Place, SAL 300 Los Angeles, CA 90089-0781 USA Phone : (310) 822-1511 x8161 mobile: (213) 841-2326 Fax : (310) 823-6714 email : cerpa@usc.edu Web : http://www-scf.usc.edu/~cerpa Khalil, et al. [Page 19] Internet-Draft Buffer Data 16 October 1999 Khalil, et al. [Page 20]