Internet Engineering Task Force Mohamed Khalil
INTERNET-DRAFT Haseeb Akhtar
<draft-mkhalil-mobileip-buffer-00.txt> 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 <IP Index = 0, ID Count = n, IP ID1
... IP IDn>, 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 <IP Index = 2, ID Count = n, IP ID1 ... IP IDn>
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]