mobileip Working Group Govind Krishnamurthi
INTERNET DRAFT Nokia Research Center
1 March 2001 Robert C. Chalmers
UC Santa Barbara
Charles E. Perkins
Nokia Research Center
Buffer Management for Smooth Handovers in IPv6
draft-krishnamurthi-mobileip-buffer6-01.txt
Status of This Memo
This document is an individual submission to the mobileip Working
Group of the Internet Engineering Task Force (IETF). Comments should
be submitted to the MOBILE-IP@STANDARDS.NORTELNETWORKS.COM mailing
list.
Distribution of this memo is unlimited.
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
Real-time applications like VoIP in mobile networks need smooth
handovers in order to minimize or eliminate packet loss as a mobile
node (MN) transitions between network links. This document defines
a buffering mechanism for IPv6 by which an MN can request that the
router on its current subnet buffers packets on its behalf while the
MN completes registration procedures with the router of a new subnet.
Once the registration is complete and the MN has a valid care-of
address in the new network, the buffered packets can be forwarded
from the previous router, thus reducing the possibility of packet
loss during the transition.
Krishnamurthi, Chalmers, Perkins Expires 1 September 2001 [Page i]
Internet Draft Buffering for Smooth Handovers in IPv6 1 March 2001
Contents
Status of This Memo i
Abstract i
1. Introduction 1
2. Terminology 2
3. Managed Buffering (MB) Overview 3
3.1. Handover Scenarios . . . . . . . . . . . . . . . . . . . 4
3.1.1. Mobile Controlled Network Assisted Handovers . . 5
3.1.2. Network Controlled Mobile Assisted Handovers . . 6
3.2. Conceptual Data Structures . . . . . . . . . . . . . . . 7
4. Protocol Extensions 9
4.1. Router Advertisement Modifications . . . . . . . . . . . 9
4.2. New Buffering SubOptions . . . . . . . . . . . . . . . . 10
4.2.1. Buffer Initialization SubOption . . . . . . . . . 10
4.2.2. Buffer Forward SubOption . . . . . . . . . . . . 11
4.2.3. Buffer Acknowledgment SubOption . . . . . . . . . 13
5. Requirements for IPv6 Nodes 15
5.1. Requirements for IPv6 Mobile Nodes . . . . . . . . . . . 15
5.2. Requirements for IPv6 Access Routers . . . . . . . . . . 15
6. Mobile Node Operation 16
6.1. Receiving Router Advertisements . . . . . . . . . . . . . 16
6.2. Initiating Buffer Management . . . . . . . . . . . . . . 16
6.3. Modifying Buffer Parameters . . . . . . . . . . . . . . . 17
6.4. Requesting Packet Forwarding . . . . . . . . . . . . . . 17
6.5. Ending Buffer Management . . . . . . . . . . . . . . . . 17
6.6. Receiving Buffer Acknowledgments . . . . . . . . . . . . 17
7. Router Operation 18
7.1. Advertising Buffer Management . . . . . . . . . . . . . . 18
7.2. Receiving Buffer Management SubOptions . . . . . . . . . 18
7.2.1. Common Operations . . . . . . . . . . . . . . . . 18
7.2.2. Receiving SubOptions from a Mobile Node . . . . . 19
7.2.3. Receiving SubOptions from Another Router . . . . 19
7.3. Sending Buffer Acknowledgments . . . . . . . . . . . . . 20
7.4. Initializing Buffer State . . . . . . . . . . . . . . . . 21
7.5. Forwarding Buffered Packets . . . . . . . . . . . . . . . 21
7.6. Unsolicited Forwarding of Buffered Packets . . . . . . . 22
7.7. Receiving Packets for a Mobile Node . . . . . . . . . . . 22
Krishnamurthi, Chalmers, Perkins Expires 1 September 2001 [Page ii]
Internet Draft Buffering for Smooth Handovers in IPv6 1 March 2001
7.8. Deleting Buffered Packets . . . . . . . . . . . . . . . . 23
7.9. Freeing MB State . . . . . . . . . . . . . . . . . . . . 23
8. Protocol Constants 23
9. IANA Considerations 24
10. Security Considerations 24
11. Acknowledgments 24
Addresses 26
1. Introduction
For future generation mobile networks to be successful, they
should ensure that the transfer of real-time data is seamless and
glitch-free. The loss of packets during the transition between
networks should be minimal. It has been shown in current research
efforts that buffering packets improves the performance of Mobile
IP [2]. This document defines a buffering mechanism that attempts to
meet this goal for general smooth handovers for IPv6 nodes.
Figure 1 illustrates the basic handover scenario assumed throughout
this document. We propose the following: incoming packets to a
mobile node (MN) are buffered at the Previous Router (Prtr) while the
MN transitions to a new network. Once the MN completes registration
and obtains a valid IP address for the network associated with
the New Router (Nrtr), Prtr forwards the packets to the MN at its
new address. In the document, we address both mobile controlled
and network controlled handovers and their impact on the buffer
management protocol.
The buffer management procedures described in this document MAY
be performed in association with the delivery of a Binding Update
(BU) from the MN to a targeted mobility agent (i.e., a mobility
agent which is to manage that care-of address for the MN). By
associating the buffering request with the BU, the need for separate
acknowledgments is substantially reduced. If the access router is
unable to fulfill the MN's request then it will reply with a negative
acknowledgment. Otherwise, the MN will be assured that its message
was delivered to the access router when it receives the Binding
Acknowledgment from the mobility agent. Furthermore, the general
procedures for smooth handovers require the new access router to
retransmit messages until it is assured that the previous router has
received and acted on them.
Krishnamurthi, Chalmers, Perkins Expires 1 September 2001 [Page 1]
Internet Draft Buffering for Smooth Handovers in IPv6 1 March 2001
$ MN +-----------+
+-+ | Previous | <
| | ---------- | Router | ------ > ----\
+-+ | (Prtr) | < \
| | \
| +-----------+ +--------+
| | IP | Corr. |
| | Network |Node(CN)|
V | +--------+
| /
$ MN +-----------+ /
+-+ | New | < /
| | ---------- | Router | ------ > ----/
+-+ | (Nrtr) | <
| |
+-----------+
Figure 1: Reference Scenario for Handovers
All Mobile Node addresses in this document refer to the mobile node's
care-of addresses, either at the new access router or the old access
router. The access routers may not even be aware of the home address
of the mobile node. It is anticipated that future specifications may
use the mobile node's NAI for identification purposes instead of the
mobile node's care-of address(es).
This document is based on the general smooth handover framework
presented in [5]. To that effect, the suboptions defined herein
implement the feature extensions discussed in the framework draft.
Furthermore, many issues covered in that draft, such as overall
packet formats and authentication, will not be re-addressed here.
In this document, we propose an extension to the IPv6 Router
Advertisement message [6] which allows a router to advertise its
ability to support MB. We also introduce three new suboptions, Buffer
Initialize, Buffer Forward and Buffer Acknowledgment, to be used
within the smooth handover framework.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL", and
Krishnamurthi, Chalmers, Perkins Expires 1 September 2001 [Page 2]
Internet Draft Buffering for Smooth Handovers in IPv6 1 March 2001
"silently ignore" in this document are to be interpreted as described
in RFC 2119 [1].
We define the following terms for use in this document.
Nrtr The new router to which the MN attaches after handover
Prtr The MN's default router ("previous router") prior to
handover
Naddr The mobile node's previous access address; for Mobile
IPv6, this would be the mobile node's care-of address on
the new access network.
Paddr The mobile node's previous access address; for Mobile
IPv6, this would be the mobile node's previous care-of
address.
MCNA Mobile Controlled Network Assisted (see section 3.1.1)
NDMA Network Controlled Mobile Assisted (see section 3.1.2)
SHIN message
Any message from the mobile node requesting transfer of
context from the mobile node's previous access address
(Paddr) to its new access address (Naddr), and defined in
[3].
SHREP Message
The ICMP Smooth Handover Reply message, sent between
access routers, and defined in [3].
SHREQ Message
The ICMP Smooth Handover Request message, sent between
access routers, and defined in [3].
MB Managed Buffering
MN Mobile Node
BU Binding Update
BA Binding Acknowledgement
3. Managed Buffering (MB) Overview
A router which is enabled to perform buffering advertises its
capability to interested MNs using the proposed `B' bit in its router
Krishnamurthi, Chalmers, Perkins Expires 1 September 2001 [Page 3]
Internet Draft Buffering for Smooth Handovers in IPv6 1 March 2001
advertisements (see Section 4.1). Once a MN receives a router
advertisement indicating that MB services are available, it may
request buffering with the Buffer Initialization suboption defined in
Section 4.2.1. The MN may request a specific buffer size or accept
the default size. The router may accept or decline this request
based on available resources, or it may allocate a smaller buffer if
necessary. The actual size of the buffer allocated is communicated
back to the MN through the Buffer Acknowledgment suboption described
in Section 4.2.3.
Buffering state is associated with a target address, the MN's access
IP address before it arrives at the new access network (i.e., Paddr).
Incoming packets destined for Paddr are buffered in addition to being
forwarded normally. When the buffer allocated to the MN is full, the
packets are replaced using an appropriate replacement policy. The
default replacement policy is for older packets to be dropped before
newer packets. Packets must be dropped atomically; partial packets
must never be delivered to the mobile node.
After establishing a link to a new access network, a mobile node
MAY request that buffered packets be forwarded to its new IP
access address (Naddr) with the Buffer Forward suboption defined in
Section 4.2.2. In response, the router tunnels to Naddr all packets
previously buffered for Paddr. When the lifetime of Paddr expires,
all associated buffering state will be freed.
If the router cannot accept new requests for buffering (say, due to
resource shortages), it nevertheless SHOULD NOT clear the `B' bit
in future router advertisements since handover operations may be
adversely affected. The router SHOULD return a negative reply to
initialization requests until resources are again available.
3.1. Handover Scenarios
The framework draft introduces two handover scenarios, Mobile
Controlled Network Assisted (MCNA) and Network Controlled Mobile
Assisted (NCMA). In MCNA handovers, the MN decides when it needs
to transition to a new access router, but for NCMA handovers the
network decides with possible inputs from the MN. The impact of
the two scenarios on buffer management is detailed further in the
following subsections. To help illustrate, typical signal flows for
each scenario are presented. These examples are not comprehensive.
Alternative messaging will be detailed in later sections.
In each scenario, assume that, in the past, the following actions
have occurred, whether or not in association with a previous
handover:
Krishnamurthi, Chalmers, Perkins Expires 1 September 2001 [Page 4]
Internet Draft Buffering for Smooth Handovers in IPv6 1 March 2001
0a) Prtr sent a router advertisement (RA) with B=1.
0b) Prtr created buffering state associated with Paddr.
3.1.1. Mobile Controlled Network Assisted Handovers
In Mobile Controlled Network Assisted (MCNA) handovers, the MN uses
some indication, like the reception of Neighbor Advertisements,
or possibly some low-level information such as the Signal to
Interference Ratio (SIR) to decide whether it needs to change
its access router. If presented with multiple options for new
routers, the MN may decide on the new access router based on signal
strength or possible resource information passed with the router
advertisement. Once the MN transitions to a new access router, it is
the MN's responsibility to initiate buffer state at the new router
and to request forwarding of buffered packets from the previous
router.
An example of a typical signal flow for MB during an MCNA handover
follows (see Figure 2). The scenario assumes that both Prtr and Nrtr
support buffer management and that the MN will take advantage of the
MB services at both nodes.
$ MN +-----------+
+-+ <--(0a:RA)--- | Previous |
| | -------------------------- | Router |
+-+ --(0b:SHIN+BI)--> | (Prtr) |
| +-----------+
| ^ | |
| (2:SHREQ+BF)| | |
| | | |(4:fwd pkts)
| | |
V (3:SHREP+BA)| V
V
$ MN +-----------+
+-+ -(1:SHIN+BI+BF)--> | New |
| | -------------------------- | Router |
+-+ <-(4:fwd pkts)- | (Nrtr) |
+-----------+
Figure 2: MCNA Managed Buffering Signal Flow
Now, suppose that MN obtains a new access address, Naddr, on the
access network served by from router Nrtr.
Krishnamurthi, Chalmers, Perkins Expires 1 September 2001 [Page 5]
Internet Draft Buffering for Smooth Handovers in IPv6 1 March 2001
1) MN sent a SHIN with two buffering suboptions to Nrtr: a
BI suboption with nonzero lifetime, causing Nrtr to create
buffering state associated with Naddr; and a Buffer Forward
(BF) suboption.
2) Nrtr sent a Smooth Handover Request (SHREQ) message to Prtr,
as defined in the framework draft, with the same Buffer
Forward (BF) suboption that it received from MN.
3) Prtr responds to Nrtr with a Smooth Handover Reply (SHREP)
message containing a Buffer Acknowledgment suboption.
4) Prtr forwards buffered packets associated with Paddr to MN at
Naddr.
3.1.2. Network Controlled Mobile Assisted Handovers
In NCMA handovers, elements in the network decide when a MN should
transition between two access routers. The advantage of this
scheme is that the Previous Router can supply the New Router with
current state for the MN before the handover actually occurs. The
initialization of buffering state and the forwarding of buffered
packets to the new access router may be performed without the
explicit request of the MN. However, the smooth handover framework
requires that the MN still request forwarding during a handover
to ensure that packets are forwarded correctly. To access any MB
features, in both MCNA and NCMA cases, the MN will issue a SHIN to
Nrtr if it receives a router advertisement with the appropriate bits
set. The SHIN message associates the previous access IP address
(Paddr) to the new access address (Naddr), as in the following
example.
Figure 3 illustrates a typical signal flow for MB during an NCMA
handover. The scenario assumes that both Prtr and Nrtr support MB
and that the MN will take advantage of the MB services at both nodes.
For NCMA, suppose that Prtr determines that MN needs to handover to
Nrtr. Then, the following actions occur.
1) Prtr prepares to transfer the buffered packets associated
with Paddr to Nrtr by sending an HI message containing a
BI suboption. Nrtr attempts to make a compatible buffer
allocation for MN.
2) Prtr forwards the packets buffered for Paddr to Nrtr using
an encapsulated header. Nrtr decapsulates each packet and
buffers it. Prtr continues to buffer newly arriving packets
destined for Paddr and forwards them directly to Nrtr.
Krishnamurthi, Chalmers, Perkins Expires 1 September 2001 [Page 6]
Internet Draft Buffering for Smooth Handovers in IPv6 1 March 2001
$ MN +----------+
+-+ <--(0a:RA)--- | Previous |
| | -------------------------- | Router |
+-+ --(0b:SHIN+BI)--> | (Prtr) |
| +----------+
| | ^
| | |
| (1:HI+BF)| |(5:HAck+BF+BA)
| (2:fwd pkts)| |
V | |
V |
$ MN +----------+
+-+ -(3:SHIN+BI+BF)--> | New |
| | -------------------------- | Router |
+-+ <-(4:fwd pkts)- | (Nrtr) |
+----------+
Figure 3: NCMA Buffer Management Signal Flow
3) MN sends a SHIN option with two buffering suboptions to Nrtr:
a BI suboption with nonzero lifetime, causing Nrtr to create
buffering state associated with Naddr; and a Buffer Forward
(BF) suboption.
4) Nrtr forwards buffered packets associated with Paddr to MN at
Naddr.
5) Nrtr sends a SHREQ message to Prtr with a Buffer
Acknowledgment (BA) suboption indicating that the HI message
was received and that forwarding was handled at Nrtr.
In some cases it may not be possible to transfer the buffers to the
New Router before the MN obtains a Naddr. For example, the Nrtr
and Prtr may not maintain a mutual trust, or Nrtr may not have the
necessary buffering capabilities. In such cases, the Previous Router
takes actions identical to the MCNA case. It waits to receive the
explicit Buffer Forward request from the MN, and then transfers the
packets directly to the MN's Naddr.
3.2. Conceptual Data Structures
This document uses the conceptual data structures listed in this
subsection to describe the operation of the MB protocol. A specific
MB implementation does not need to necessarily implement these data
Krishnamurthi, Chalmers, Perkins Expires 1 September 2001 [Page 7]
Internet Draft Buffering for Smooth Handovers in IPv6 1 March 2001
structures as long as the external behavior is consistent with that
described in this document.
Access Address An IP address used by a mobile node to facilitate
network-layer access to a particular network. Such
an address may be, but is not necessarily, useful for
endpoint identification for application end-to-end data
communications with nodes on other networks. As an
example, an access address MAY be a care-of address, as
defined by Mobile IPv6.
Packet Buffer
The Packet Buffer maintains a list of IP packets
originally destined for the MN.
Target Address
The buffer management state must be associated with a
target address. This target address is the previous IP
access address (Paddr).
Forwarding Address
When a MN establishes a link to a new access network
served by a new access router, it will also acquire a
new access IP address (Naddr). The Forwarding Address
for the MN is set to Naddr and is used when forwarding
buffered packets.
New Router Address
The New Router Address stores the address of the new
access router being used by the MN after handover. This
address is used in the NCMA scenario where the Previous
Router forwards packets to the New Router and continues
to forward incoming packets for the MN.
Lifetime
State information for Managed Buffering MUST have an
associated lifetime. This lifetime MUST no less than
MB_SAVE_TIME, but otherwise MUST NOT be longer than the
lifetime of the router's entry for the mobile node's
access address.
Sequence Number
The maximum value of the Sequence Number field received
in previous Managed Buffering requests of a particular
type for a target address. The Sequence Number field is
8 bits long, and all comparisons between Sequence Number
Values MUST be performed modulo 2**8.
Krishnamurthi, Chalmers, Perkins Expires 1 September 2001 [Page 8]
Internet Draft Buffering for Smooth Handovers in IPv6 1 March 2001
4. Protocol Extensions
The following protocol extensions are described:
- A buffer management extension to the IPv6 router advertisement
message.
- Three new buffering suboptions implementing the feature
extensions described in the framework draft.
4.1. Router Advertisement Modifications
This document proposes to modify the IPv6 Router Advertisement
message [6] with the addition of a single flag bit to indicate that
the router supports buffer management. This flag bit is referenced
in this document as the `B' bit. The new format for the Router
Advertisement message is shown in Figure 4.
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 | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cur Hop Limit |M|O|H|B|Reservd| Router Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reachable Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Retrans Timer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: New Router Advertisement Format
This format represents the following changes over that originally
specified for Neighbor Discovery [6] and Mobile IPv6 [4]:
Buffer Management (B)
The Buffer Management (B) bit is set in a Router
Advertisement to indicate that the router
sending this advertisement supports Managed
Buffering services.
Krishnamurthi, Chalmers, Perkins Expires 1 September 2001 [Page 9]
Internet Draft Buffering for Smooth Handovers in IPv6 1 March 2001
4.2. New Buffering SubOptions
This section defines the format for the three new buffering
suboptions proposed by this draft: Buffer Initialization, Buffer
Forward and Buffer Acknowledgment. Each suboption format conforms to
Section 5.5 of the MIPv6 draft [4].
4.2.1. Buffer Initialization SubOption
The Buffer Initialization suboption is used to request that a router
begin buffering packets on behalf of a mobile node. The suboption
may be used by the Previous Router to initiate buffering at the New
Router on behalf of a mobile node in the case of a NCMA handover. A
mobile node MAY include the suboption with a Smooth Handover Initiate
(SHIN) destination option. The suboption MAY be associated with
any ICMP Handover message to request or supply buffered packets and
buffer state information.
The state is associated with a single target address. In the case
of a message originating from a MN, the target address is the source
IP address of the packet. In the case of a router-router handover
message, the target address of the MN MUST be supplied in the Paddr
field of the message.
The Buffer Initialization suboption is encoded in type-length-value
(TLV) format as seen in Figure 5.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|SubOption Type | SubOption Len | Sequence Num | Buffer Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A| Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Buffer Initialization SubOption Format
SubOption Type TBD
SubOption Len 8-bit unsigned integer. Length of the
suboption, in octets, excluding the SubOption
Type and SubOption Length fields. This field
MUST be set to 6.
Krishnamurthi, Chalmers, Perkins Expires 1 September 2001 [Page 10]
Internet Draft Buffering for Smooth Handovers in IPv6 1 March 2001
Sequence Num The sequence number is assigned by the sender
and used by the receiving node to sequence
buffering requests. Each MB request sent by
a MN MUST use a sequence number greater than
the Sequence Number value sent in the previous
initialization request, if any, to the same
router (modulo 2**8, as defined in Section 3.2).
Buffer Size 8-bit unsigned integer. The MN MAY request
a size for the new buffer in units of 1,024
octets. If the value is 0xffff then the default
buffer size at the router will be used.
Acknowledge (A) The Acknowledge (A) bit is set by the sending
node to request an explicit acknowledgment in
response to this request.
Reserved This field is unused. It MUST be initialized to
zero by the sender and ignored by the receiver.
Lifetime 24-bit unsigned integer. The number of seconds
remaining before the MB state MUST be considered
expired. If not defined (a value of -1) then
the default lifetime at the router will be used.
If the MN does not need buffering, then this
field is set to zero.
4.2.2. Buffer Forward SubOption
The Buffer Forward suboption is used to request that buffered
packets be forwarded to the MN's new access address. The request is
associated with both a target address and a forwarding address.
The MN MAY include the suboption as part of a Smooth Handover
Initiate (SHIN) destination option. In this case, the target address
is defined in the Previous Access IP Address (Paddr) field of the
SHIN option, and the forwarding address is the source IP address of
the packet.
In the case of a request originating from the MN, the MN sends the
Paddr to the Prtr as part of the message, and the forwarding address
is the source IP address of the packet. A router MAY include the
Buffer Forward suboption with a Handover Request or Handover Initiate
message. For such messages, the target and forwarding addresses are
defined in the Paddr and Naddr fields, respectively.
The Buffer Forward suboption MAY include a list of unique identifiers
indicating which packets have already been received by the mobile
Krishnamurthi, Chalmers, Perkins Expires 1 September 2001 [Page 11]
Internet Draft Buffering for Smooth Handovers in IPv6 1 March 2001
node. These packets therefore MUST be silently discarded, and MUST
NOT be forwarded to the mobile node. The identifier is calculated as
(MD5 (packet) mod 2**16).
The Buffer Forward suboption is encoded in type-length-value (TLV)
format as seen in Figure 6.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|SubOption Type | SubOption Len | Sequence Num | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Excluded Packet ID | Excluded Packet IDs, continued
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Buffer Forward SubOption Format
SubOption Type
TBD
SubOption Len
8-bit unsigned integer. Length of the
suboption, in octets, excluding the SubOption
Type and SubOption Length fields. This field
MUST be set to 2 plus the total length of all
Packet ID fields.
Sequence Num
The sequence number is assigned by the sender
and used by the receiving node to sequence
buffering requests. Each MB request sent by
a MN MUST use a sequence number greater than
the Sequence Number value sent in the previous
forwarding request, if any, to the same router
(modulo 2**8, as defined in Section 3.2).
Reserved This field is unused. It MUST be initialized to
zero by the sender and MUST be ignored by the
receiver.
Excluded Packet ID
The packet identifier is a 16-bit value that
uniquely identifies a packet received by the
MN that should not be forwarded. The actual
Krishnamurthi, Chalmers, Perkins Expires 1 September 2001 [Page 12]
Internet Draft Buffering for Smooth Handovers in IPv6 1 March 2001
number of Excluded Packet ID fields present is
determined by the SubOption Len field.
4.2.3. Buffer Acknowledgment SubOption
The Buffer Acknowledgment suboption MAY be used to acknowledge the
receipt of a Buffer Initialization or Buffer Forward suboption. The
suboption MUST be returned to the sender with the sequence number of
the original request. The suboption MAY be associated with any of
the following Smooth Handover destination options: SHREQ, SHREP, or
SHACK.
The Buffer Acknowledgment suboption is encoded in type-length-value
(TLV) format as seen in Figure 7.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|SubOption Type | SubOption Len | Sequence Num |I|F|E|R| Status|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Buffer Size | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Buffer Acknowledgment SubOption Format
SubOption Type TBD
SubOption Len 8-bit unsigned integer. Length of the
suboption, in octets, excluding the SubOption
Type and SubOption Length fields. This field
MUST be set to 6.
Sequence Num The sequence number in the Buffer Acknowledgment
suboption is copied from the Sequence Number
field in the Buffer Initialization or Buffer
Forward suboption being acknowledged, for use by
the sender in matching this acknowledgment with
an outstanding buffering request.
Initialize (I) The Initialize (I) bit indicates that this
suboption is acknowledging a previous Buffer
Initialization request.
Krishnamurthi, Chalmers, Perkins Expires 1 September 2001 [Page 13]
Internet Draft Buffering for Smooth Handovers in IPv6 1 March 2001
Forward (F) The Forward (F) bit indicates that this
suboption is acknowledging a previous Buffer
Forward request.
Error (E) The Error (E) bit indicates that the BA is
reporting an error. When this bit is set, the
Status field MUST be set to indicate the cause
of the error.
Reserved (R) This bit is unused. It MUST be initialized to
zero by the sender and MUST be ignored by the
receiver.
Buffer Size For successful requests, the Size field the
value indicates the granted buffer size or the
amount of data forwarded in units of 1,024
octets.
Status 4-bit unsigned integer. If greater than 0x0,
the value indicates the reason for failure in
processing the buffering request.
Lifetime 24-bit unsigned integer. The granted lifetime
in seconds. The value of this field is
undefined if the `E' bit indicates that the
request was unsuccessful.
The following values are currently defined for the Status field:
0 Success
4 Reason unspecified
5 Administratively prohibited
6 Insufficient resources
7 Buffering not supported
8 Buffering not enabled
9 Buffers already forwarded
10 Buffers empty
Krishnamurthi, Chalmers, Perkins Expires 1 September 2001 [Page 14]
Internet Draft Buffering for Smooth Handovers in IPv6 1 March 2001
5. Requirements for IPv6 Nodes
Since signaling for buffering initialization and forwarding is
limited to MNs and their respective access routers, there are no
general requirements for all mobile nodes. Non-mobile correspondent
nodes (CN) and routers not directly supporting MNs do not have to
implement any of the suboptions or procedures outlined in this
document.
In order to make use of the Managed Buffering features specified
in this document, some new requirements must be implemented
by participating mobile nodes. This section summarizes those
requirements, identifying the functionality each requirement is
intended to support.
5.1. Requirements for IPv6 Mobile Nodes
For a participating MN to initiate buffering and request buffer
forwarding, it must fulfill the following requirements:
- Every participating MN MUST be able to receive and process the
`B' bit of router advertisements, as described in Section 6.1.
- Every participating MN MUST support sending the Buffer
Initialization and Buffer Forward suboptions, as specified in
Sections 6.2 and 6.4, and MUST be able to receive and process
Buffer Acknowledgment suboptions, as specified in Section 6.6.
- Every participating MN SHOULD be able to generate Excluded
Packet IDs from recently received packets, as described in
Section 4.2.2.
5.2. Requirements for IPv6 Access Routers
A participating IPv6 router offering buffering features to local MNs
must fulfill the following requirements:
- Every participating router MUST be able to buffer packets on
behalf of a mobile node, as described in Section 7.7.
- Every participating router MUST be able to advertise MB support
by setting the `B' bit in its router advertisements, as described
in Section 7.1.
- Every participating router MUST be able to send, receive
and process Buffer Initialization, Buffer Forward and Buffer
Acknowledgment suboptions, as specified in Sections 7.2 and 7.3.
Krishnamurthi, Chalmers, Perkins Expires 1 September 2001 [Page 15]
Internet Draft Buffering for Smooth Handovers in IPv6 1 March 2001
- Every participating router MUST be able to tunnel packets to the
MN or New Router, as described in Sections 7.5 and 7.6.
- Every participating router SHOULD be able to generate Packet IDs
from buffered packets, as described in Section 4.2.2.
6. Mobile Node Operation
6.1. Receiving Router Advertisements
Upon receiving a router advertisement, if the `B' bit is not set then
the mobile node MUST NOT request MB services from the advertising
router. Otherwise, if the `B' bit is set, the mobile node MAY
request MB services according to the procedures outlined in the
following subsections.
6.2. Initiating Buffer Management
The MN MAY initiate managed buffering services at a particular router
if that router sets the `B' bit in its Router Advertisements, by
sending a Buffer Initialization suboption as part of some message
sent to the router.
- The Sequence Number field of the Buffer Initialization suboption
MUST contain a unique value greater (modulo 2**8) than the last
sequence number associated with a Buffer Initialization request
sent to this router.
- The Acknowledge (A) bit MAY be set.
- The Buffer Size field MAY indicate desired size of the buffer.
Unless specific applications require otherwise, the Buffer Size
field SHOULD be set to 0 which indicates that the router should
allocate a buffer of default size, as defined by the router's
configuration.
- The Lifetime field SHOULD contain the desired number of seconds
that the MB state (including the buffered packets) should remain
active at the router. The Lifetime field MAY be set to -1 which
indicates that the router should use a default lifetime, as
defined by the router's configuration. A value of zero for the
lifetime indicates that no buffering is needed.
Krishnamurthi, Chalmers, Perkins Expires 1 September 2001 [Page 16]
Internet Draft Buffering for Smooth Handovers in IPv6 1 March 2001
6.3. Modifying Buffer Parameters
The MN MAY request that parameters of the MB state be modified by
re-issuing an initialization request. In this case, zero values
indicate that a field ( -1 for the Lifetime field) should not be
changed.
- To reduce or expand the size of an existing buffer, the MN
supplies a different size in the Buffer Size field. If the new
buffer size is smaller than the previous size, the router MAY
discard some of the packets already buffered.
- To modify the lifetime of the MB state, the MN supplies a new
value in the Lifetime field.
- The Sequence Number field MUST contain a unique value greater
than the last sequence number associated with a Buffer
Initialization request sent to this router.
6.4. Requesting Packet Forwarding
During a handover, if the MN has managed buffering initialized at
the Previous Router (either explicitly created by the MN or created
by an NCMA router on behalf of the MN), the MN SHOULD request that
the Previous Router forward any buffered packets to Naddr. The
Sequence Number field MUST contain a unique value greater than the
last sequence number associated with a Buffer Forward request sent to
the forwarding router. The Excluded Packet IDs field SHOULD uniquely
identify which packets should not be forwarded by the router, as
described in Section 4.2.2.
6.5. Ending Buffer Management
The mobile node MAY terminate managed buffering services at a
particular router by sending a Buffer Initialization suboption with
zero lifetime. The Sequence Number field MUST contain a unique
value greater than thelast sequence number associated with a Buffer
Initialization request sent to that router.
6.6. Receiving Buffer Acknowledgments
Upon receiving a Buffer Acknowledgment suboption, a MN MUST validate
the suboption according to the following tests:
- The SubOption Len field MUST conform to the length defined in
Section 4.2.3.
Krishnamurthi, Chalmers, Perkins Expires 1 September 2001 [Page 17]
Internet Draft Buffering for Smooth Handovers in IPv6 1 March 2001
- The Sequence Number field MUST match an outstanding request made
by the MN.
If the suboption does not satisfy all of these tests, it MUST be
silently ignored by the MN and suboption processing SHOULD continue.
If additional suboptions are present, the mobile node SHOULD continue
to be process them.
7. Router Operation
7.1. Advertising Buffer Management
A router that has been enabled to provide MB services SHOULD
advertise that capability by setting the `B' bit (see Section 4.1)
in its router advertisement. If a router does not currently have
resources to allocate for buffering, however, the router MUST NOT
clear an already advertised `B' bit in future advertisements since
handover operations may be adversely affected. Rather, the router
SHOULD return a negative reply to initialization requests until
resources are again available.
7.2. Receiving Buffer Management SubOptions
A router MAY receive buffering suboptions from a MN or from another
router. This subsection defines the procedures common to both cases,
as well as procedures particular to each case individually.
7.2.1. Common Operations
Upon receiving a buffering suboption, as previously defined in this
document, the receiving router MUST validate the packet containing
the suboption according to the following tests:
- The option MUST provide valid IPv6 target and forwarding
addresses as required by the individual suboptions defined in
Sections 4.2.1 and 4.2.2.
- The SubOption Len field MUST conform to the length defined
for the appropriate suboption, as defined in Sections 4.2.1
through 4.2.3.
- The Sequence Number field MUST be greater than the Sequence
Number received in the previous MB message of equivalent type (if
any) for the target address.
Krishnamurthi, Chalmers, Perkins Expires 1 September 2001 [Page 18]
Internet Draft Buffering for Smooth Handovers in IPv6 1 March 2001
Any packet not satisfying all of these tests MUST be silently ignored
by the receiving node, and further suboption processing SHOULD
continue. If the packet is valid according to the above tests, then
the suboption is processed according to the following procedures:
- If the suboption is received from the target address, then the
procedures outlined in Section 7.2.2 MUST be followed.
- Otherwise, the procedures outlined in Section 7.2.3 MUST be
followed.
- If the suboption is a Buffer Initialization or Forward request
and that request contains an `A' bit that is set or the request
could not be fulfilled in full or in part, the router MUST reply
with a Buffer Acknowledgment indicating success or the reason for
failure.
7.2.2. Receiving SubOptions from a Mobile Node
Upon receiving a buffering suboption from a MN, the router MUST
process the suboption according to the following procedures:
- If the suboption is a Buffer Initialization suboption, then the
router takes one of the two following actions based upon whether
the lifetime is zero:
* If the lifetime is nonzero, then the router MUST follow the
procedures in Section 7.4 using the source IPv6 address of
the packet as the target address.
* If the lifetime is zero, then the router SHOULD free any
buffering state associated with the target address.
- If the suboption is a Buffer Forward suboption, the router MUST
follow the procedure outlined in Section 7.5 using the Paddr
field of the SHIN as the target address and the source IP address
of the packet as the forwarding address.
- If the suboption is a Buffer Acknowledgment suboption, then the
router MUST silently ignore the suboption and SHOULD continue
processing subsequent suboptions.
7.2.3. Receiving SubOptions from Another Router
Upon receiving a buffering suboption from another router, the router
MUST process the suboption according to the following procedures:
Krishnamurthi, Chalmers, Perkins Expires 1 September 2001 [Page 19]
Internet Draft Buffering for Smooth Handovers in IPv6 1 March 2001
- If the suboption is a Buffer Initialization suboption, then the
router takes one of the two following actions based upon whether
the lifetime is zero:
* If the lifetime is zero, then the router MUST follow the
procedures outlined in Section 7.4 using the Paddr field of
the SHREQ as the target address.
* If the lifetime is nonzero, then the router MUST silently
ignore the suboption and SHOULD continue processing
subsequent suboptions.
- If the suboption is a Buffer Forward suboption, then the router
MUST take one of the following actions:
* If the buffered packets have already been forwarded to the
New Router (see Section 7.6) and the router has received a
Buffer Acknowledgment to confirm that transfer either prior
to or within the current message, the router SHOULD ignore
the suboption.
* Otherwise, the router MUST follow the procedure outlined in
Section 7.5 using the Paddr field of the SHREQ as the target
address and the Naddr field as the forwarding address.
- If the suboption is a Buffer Acknowledgment suboption, then the
router MAY resubmit the request if the Status field indicates
that the request was wholly or partially unsuccessful, as defined
in Section 7.3.
7.3. Sending Buffer Acknowledgments
When a router receives a buffering suboption that requires an
acknowledgment, as described in the previous subsections, the
router SHOULD associate a Buffer Acknowledgment suboption with an
appropriate reply packet. Also, in the NCMA case, if a router
initializes buffering state on behalf of a MN without an explicit
request, the router MUST alert the MN with a Buffer Acknowledgment.
If the router can perform the requested operation in part or in
full, the router MUST not set the `E' bit in the BA. If a buffer was
allocated due to the request, then the size of that buffer and its
associated lifetime MUST be placed in the Status and Lifetime fields
of the acknowledgment. If the router rejects the request or cannot
fulfill it in any way, then the router MUST set the `E' bit a return
an appropriate error value in the Status field indicating the reason
for failure.
Krishnamurthi, Chalmers, Perkins Expires 1 September 2001 [Page 20]
Internet Draft Buffering for Smooth Handovers in IPv6 1 March 2001
7.4. Initializing Buffer State
The router MUST allocate buffer space for the MN unless the router
does not currently support MB or sufficient resources are not
currently available. If a buffer is allocated, the size SHOULD
correspond to the value passed in the Buffer Size field and the
lifetime SHOULD be equal to the value passed in the Lifetime field.
If the buffer size requested by the MN, not the Previous Router, is
larger than current resources allow or larger than the configured
maximum for the router then the router MAY allocate a smaller
buffer. If an initialization request from the Previous Router cannot
be satisfied in full then the router MUST reply with a negative
acknowledgment. In the case that the Buffer Size field is zero, then
the router SHOULD allocate a buffer with a default size determined by
the router's configuration.
When buffering state is initialized, it MUST be associated with a
primary target address. This target address SHOULD be the MN's
Naddr on the local network. Furthermore, if the target address is
also used as a care-of address, it SHOULD reside as an entry in
the router's Binding Cache, as described for Mobile IPv6 [4]; the
lifetime of the buffering state SHOULD be limited to the lifetime of
that binding.
If buffering state already exists for the target of an initialization
request, the router should attempt to modify the MB state according
to the new values of Buffer Size and Lifetime fields. Zero values
(-1 for the Lifetime field) indicate no change is requested for a
particular field.
If resources are not available to increase the size of the buffer to
the size requested, but a partial increase is possible, the router
MAY choose to increase the buffer to some intermediate size. The
buffered packets, however, MUST NOT be deleted when increasing the
size of a buffer. If the requested size is smaller than the current
size, the router SHOULD reduce the size of the current buffer using
an appropriate replacement policy to drop existing packets that no
longer fit within the new buffer.
7.5. Forwarding Buffered Packets
When a request to forward buffered packets is received, the router
MUST forward any buffered packets associated with the target address.
The packets are forwarded by encapsulating them within a new IPv6
header using the forwarding address as the destination address. If
no buffered packets exist for the target address, the router SHOULD
reply with a negative acknowledgment.
Krishnamurthi, Chalmers, Perkins Expires 1 September 2001 [Page 21]
Internet Draft Buffering for Smooth Handovers in IPv6 1 March 2001
The Buffer Forward suboption may contain a list of Excluded
Packet IDs that identify those packets which should not be forwarded.
The router MUST compute an identifier for each packet in the buffer
and forward the packet only if the computed ID does not match any one
of the Excluded Packet IDs listed in the suboption. This computation
SHOULD be done as soon as possible after the packet is buffered by
the router. Since an unsolicited transfer of buffered packets does
not allow the Previous Router to perform the filtering, the New
Router SHOULD apply any filtering against the Excluded Packet IDs as
soon as the mobile node is ready to receive the buffered packets.
7.6. Unsolicited Forwarding of Buffered Packets
In the case of an NCMA handover, a router MAY initiate state for the
MN and forward existing packets to the New Router. In this case,
the Previous Router router sends to the New Router a HI message
containing a Buffer Initialization suboption with the `A' bit set.
The New Router MAY respond immediately with a Buffer Acknowledgment
suboption or delay the acknowledgement until the Buffer Forward
suboption is received from the MN.
If the Previous Router forwards packets to the New Router, the New
Router MUST buffer these packets and wait for the MN to send a Buffer
Forward suboption associated with a SHIN message before forwarding
them as described in Section 7.5. The SHREQ message sent to the
Previous Router SHOULD include a Buffer Acknowledgment suboption in
response to the HI, unless it had been sent previously.
Having forwarded the buffered packets to the New Router, the Previous
Router MUST continue to buffer any new incoming packets destined for
the target address and SHOULD continue to forward these packets to
the New Router until one of the conditions outlined in Section 7.8 is
met.
7.7. Receiving Packets for a Mobile Node
Once buffering state has been initialized for a target address, all
incoming packets destined for the target address MUST be handled
according to the following rules:
- If the router has already received a Buffer Forward request from
the MN then the router SHOULD forward the packet to the mobile
node's new access address (Naddr).
- Otherwise, the packet MUST be routed to the mobile node at its
original access address, and one or both of the following actions
MUST be performed:
Krishnamurthi, Chalmers, Perkins Expires 1 September 2001 [Page 22]
Internet Draft Buffering for Smooth Handovers in IPv6 1 March 2001
* The router MUST buffer the packet using the buffering state
associated with the target address.
* If the router has already forwarded the mobile node's packets
to the New Router, it SHOULD forward incoming packets to the
New Router.
7.8. Deleting Buffered Packets
Buffered packets MAY be deleted when any of the following events
occur:
- The buffer is full. The router SHOULD use an appropriate
replacement policy, such as LRU, to remove a packet or packets
from the buffer to make room for an incoming packet.
- The packet has been forwarded to the MN's Naddr.
- The packet has been forwarded to the New Router as part of a
NCMA handover and either a BA has been received to confirm the
transfer or the required period of BUFFER_SAVE_TIME has expired.
- The buffer state is released according to the procedures
described in Section 7.9.
7.9. Freeing MB State
Buffering state associated with a MN's target address MUST be deleted
when one of the following events occurs:
- The associated Lifetime expires.
- A Buffer Initialization suboption is received from the MN with
zero lifetime.
- The router becomes a Home Agent for the target address (see [4]).
8. Protocol Constants
The following are the constants that are defined for the managed
buffering protocol for smooth handovers.
BUFFER_SAVE_TIME 10 seconds
Krishnamurthi, Chalmers, Perkins Expires 1 September 2001 [Page 23]
Internet Draft Buffering for Smooth Handovers in IPv6 1 March 2001
9. IANA Considerations
The presented protocol requires the assignment of SubOption Type
values for the three buffering suboptions defined.
10. Security Considerations
The suboptions specified in this document are delivered along
with the Authentication suboption defined in [5]. Thus, packets
buffered for a mobile node will not be purged without authorization
that can be guaranteed to have originated from the mobile node for
whom the packets were intended. In the NCMA case, a security and
authentication association MUST be present between a mobile node,
the access router(s) and the network element which performs NCMA
handovers.
11. Acknowledgments
The authors wish to thank Jari Malinen, Rajeev Koodli and Hannu
Flinck for discussion and review of this document.
References
[1] S. Bradner. Key words for use in RFCs to Indicate Requirement
Levels. Request for Comments (Best Current Practice) 2119,
Internet Engineering Task Force, March 1997.
[2] R. Caceres and V.N. Padmanabhan. Fast and Scalable Hand-offs
in Support of Mobile Internet Audio. Mobile Networks and
Applications, 3(4):351--363, December 1998.
[3] O. Levkowetz (ed.). Problem Description: Reasons For Doing
Context Transfers Between Nodes in an IP Access Network(work in
progress). draft-ietf-seamoby-context-transfer-problem-stat-00.txt,
February 2001.
[4] D. Johnson and C. Perkins. Mobility Support in IPv6 (work in
progress).
draft-ietf-mobileip-ipv6-13.txt, October 2000.
[5] Rajeev Koodli and Charles E. Perkins. A Framework for
Smooth Handovers with Mobile IPv6 (work in progress).
Internet Draft, Internet Engineering Task Force.
draft-koodli-mobileip-smoothv6-02.txt, November 2000.
Krishnamurthi, Chalmers, Perkins Expires 1 September 2001 [Page 24]
Internet Draft Buffering for Smooth Handovers in IPv6 1 March 2001
[6] T. Narten, E. Nordmark, and W. Simpson. Neighbor Discovery for
IP Version 6 (IPv6). Request for Comments (Draft Standard) 2461,
Internet Engineering Task Force, December 1998.
Krishnamurthi, Chalmers, Perkins Expires 1 September 2001 [Page 25]
Internet Draft Buffering for Smooth Handovers in IPv6 1 March 2001
Addresses
The working group can be contacted via the current chairs:
Basavaraj Patil Phil Roberts
Nokia Corporation Motorola
6000 Connection Drive 1501 West Shure Drive
M/S M8-540
Irving, Texas 75039 Arlington Heights, IL 60004
USA USA
Phone: +1 972-894-6709 Phone: +1 847-632-3148
Fax : +1 972-894-5349
EMail: Basavaraj.Patil@nokia.com EMail: QA3445@email.mot.com
Questions about this memo can be directed to the authors:
Govind Krishnamurthi Robert C. Chalmers
Communications Systems Laboratory Department of Computer Science
Nokia Research Center Univ. of California Santa Barbara
5 Wayside Road
Burlington, MA 01803 Santa Barbara, CA 93106
USA USA
+1 781 993 3627 +1 805 893 7520
+1 781 993 1907 (fax) +1 805 893 6553 (fax)
Govind.Krishnamurthi@nokia.com robertc@cs.ucsb.edu
Charles E. Perkins
Communications Systems Laboratory
Nokia Research Center
313 Fairchild Drive
Mountain View, CA 94303
USA
+1 650 625 2986
+1 650 625 2502 (fax)
charliep@iprg.nokia.com
Krishnamurthi, Chalmers, Perkins Expires 1 September 2001 [Page 26]