Mobile IP Working Group Govind Krishnamurthi
INTERNET DRAFT Nokia Research Center
13 July 2000 Robert C. Chalmers
UC Santa Barbara
Charles E. Perkins
Nokia Research Center
Buffer Management for Smooth HandOvers in Mobile IPv6
draft-krishnamurthi-mobileip-buffer6-00.txt
Status of This Memo
This document is a submission by the mobile-ip 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
An important issue to consider when supporting real-time applications
like VoIP in mobile networks is the capability to provide smooth
handoffs. A critical requirement for smooth handoffs is to minimize
packet loss as a mobile node (MN) transitions between network links.
This document defines a buffering mechanism for Mobile 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 30 December 2000 [Page i]
Internet Draft Buffer Management for Mobile IPv6 13 July 2000
Contents
Status of This Memo i
Abstract i
1. Introduction 1
2. Terminology 2
3. Managed Buffering (MB) Overview 2
3.1. Protocol Overview . . . . . . . . . . . . . . . . . . . . 2
3.2. Handoff Scenarios . . . . . . . . . . . . . . . . . . . . 3
3.2.1. MCNA Handoffs . . . . . . . . . . . . . . . . . . 3
3.2.2. NCMA Handoffs . . . . . . . . . . . . . . . . . . 5
3.3. Conceptual Data Structures . . . . . . . . . . . . . . . 6
4. Protocol Extensions 7
4.1. Router Advertisement Modifications . . . . . . . . . . . 7
4.2. New Buffering SubOptions . . . . . . . . . . . . . . . . 8
4.2.1. Buffer Initialization SubOption . . . . . . . . . 8
4.2.2. Buffer Forward SubOption . . . . . . . . . . . . 10
4.2.3. Buffer Acknowledgment SubOption . . . . . . . . . 11
5. Requirements for Mobile IPv6 Nodes 13
5.1. Requirements for IPv6 Mobile Nodes . . . . . . . . . . . 13
5.2. Requirements for Mobile IPv6 Access Routers . . . . . . . 14
6. Mobile Node Operation 14
6.1. Receiving Router Advertisements . . . . . . . . . . . . . 14
6.2. Initializing Buffer Management . . . . . . . . . . . . . 14
6.3. Changing Buffer Sizes . . . . . . . . . . . . . . . . . . 15
6.4. Requesting Packet Forwarding . . . . . . . . . . . . . . 15
6.5. Ending Buffer Management . . . . . . . . . . . . . . . . 16
6.6. Receiving Buffer Acknowledgments . . . . . . . . . . . . 16
7. Router Operation 16
7.1. Advertising Buffer Management . . . . . . . . . . . . . . 16
7.2. Receiving Buffer Management SubOptions . . . . . . . . . 16
7.2.1. Common Operations . . . . . . . . . . . . . . . . 17
7.2.2. Receiving SubOptions from a Mobile Node . . . . . 17
7.2.3. Receiving SubOptions from Another Router . . . . 18
7.3. Sending Buffer Acknowledgments . . . . . . . . . . . . . 19
7.4. Initializing Buffer State . . . . . . . . . . . . . . . . 19
7.5. Forwarding Buffered Packets . . . . . . . . . . . . . . . 20
7.6. Unsolicited Forwarding Buffered Packets . . . . . . . . 20
Krishnamurthi, Chalmers, Perkins Expires 30 December 2000 [Page ii]
Internet Draft Buffer Management for Mobile IPv6 13 July 2000
7.7. Receiving Packets for a Mobile Node . . . . . . . . . . . 20
7.8. Deleting Buffered Packets . . . . . . . . . . . . . . . . 21
7.9. Freeing Buffer State . . . . . . . . . . . . . . . . . . 21
8. IANA Considerations 21
9. Security Considerations 21
Addresses 23
Krishnamurthi, Chalmers, Perkins Expires 30 December 2000 [Page iii]
Internet Draft Buffer Management for Mobile IPv6 13 July 2000
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 Mobile IPv6
(MIPv6)[3]. Figure 1 illustrates the basic handoff scenario assumed
throughout this document.
We propose the following: incoming packets to a 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 CoA 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 handoffs and their impact on the
buffer management protocol. An Internet Draft for buffer management in
Mobile IPv4 is presented in [4].
$ MN +-----------+
+-+ | Previous | <
| | ---------- | Router | ------ > ----\
+-+ | (Prtr) | < \
| | \
| +-----------+ +--------+
| | IP | Corr. |
| | Network |Node(CN)|
V | +--------+
| /
$ MN +-----------+ /
+-+ | New | < /
| | ---------- | Router | ------ > ----/
+-+ | (Nrtr) | <
| |
+-----------+
Figure 1: Reference Scenario for Handoffs
The buffer management procedures described in this document are
typically (but not always) performed in association with the delivery
of a Binding Update from the mobile node to the targeted mobility agent
(i.e., a mobility agent which is to manage that care-of address for the
mobile node). The need for acknowledgments is substantially reduced.
Krishnamurthi, Chalmers, Perkins Expires 30 December 2000 [Page 1]
Internet Draft Buffer Management for Mobile IPv6 13 July 2000
If the access router is unable to fulfill the MN's request then it will
reply with a negative acknowledgment. Otherwise, the mobile node will
be assured that its message was delivered to the access router when it
receives the Binding Acknowledgment from the targeted mobility agent.
The general procedures for smooth handoffs require the new access router
to retransmit messages until it is assured that the previous router has
received and acted on them.
2. Terminology
The key words "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[1].
3. Managed Buffering (MB) Overview
This document is based on the general smooth handoff 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 handoff framework.
3.1. Protocol Overview
A router which is enabled to perform buffering advertises its
capability to interested MNs using the proposed `B' bit in its
router 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 primary
care-of address (CoA1). Incoming packets destined for CoA1 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 such as Least Recently Used (LRU).
Krishnamurthi, Chalmers, Perkins Expires 30 December 2000 [Page 2]
Internet Draft Buffer Management for Mobile IPv6 13 July 2000
When the MN completes a handoff, it may request that buffered packets
be forwarded to its new CoA (CoA2) with the Buffer Forward suboption
defined in Section 4.2.2. In response, the router tunnels to CoA2 all
packets previously buffered for CoA1. If the lifetime of CoA1 expires,
all associated buffering state will be freed.
If due to resource shortages the router cannot accept new
requests for buffering, it should not clear the `B' bit in future
router advertisements since handoff operations may be adversely
affected. Rather, the router should simply return a negative reply to
initialization requests until resources are again available.
3.2. Handoff Scenarios
The framework draft introduces two handoff scenarios, Mobile
Controlled Network Assisted (MCNA) and Network Controlled Mobile
Assisted (NCMA). In MCNA, the MN decides when it needs to handoff to a
new access router, and in NCMA, the network decides with possible inputs
from the MN about handoffs. The impact that the two scenarios have on
buffer management are 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.
3.2.1. MCNA Handoffs
In MCNA, the MN uses some criteria like 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, it may decide on
the new access router based on available resource information passed
as destination options of the router advertisement. For mobile node
controlled handoffs, the MN must initiate buffer state and explicitly
request forwarding of buffered packets.
An example of a typical signal flow for MB during an MCNA handoff
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.
Assume that, in the past, the following actions have occurred,
perhaps in association with an earlier smooth handoff:
1) Prtr sends a router advertisement (RA) with B=1.
Krishnamurthi, Chalmers, Perkins Expires 30 December 2000 [Page 3]
Internet Draft Buffer Management for Mobile IPv6 13 July 2000
2) MN sends a Smooth Handoff Initialize (SHIN) destination
option with a Buffer Initialization (BI) suboption to Prtr,
and Prtr creates buffering state associated with CoA1.
Now, suppose that MN obtains a new care-of address, CoA2 with default
router Nrtr.
3) MN sends a SHIN with two buffering suboptions to Nrtr: a
BI suboption with the `C' bit set causing Nrtr to create
buffering state associated with CoA2, and a Buffer Forward
(BF) suboption.
4) Nrtr sends a Smooth Handoff Request (SHREQ) message to Prtr,
as defined in the framework draft, with the same Buffer
Forward (BF) suboption it received from MN.
5) Prtr responds to Nrtr with a Smooth Handoff Reply (SHREP)
message with a Buffer Acknowledgment suboption.
6) Prtr forwards buffered packets associated with CoA1 to MN at
CoA2.
$ MN +-----------+
+-+ <--(1:RA)--- | Previous |
| | -------------------------- | Router |
+-+ --(2:SHIN+BI)--> | (Prtr) |
| |
| +-----------+
| ^ | | |
| (4:SHREQ+BF)| | | |
| | | | |(6:fwd pkts)
| | | |
V (5:SHREP+BA)| | V
V |
$ MN +-----------+
+-+ --(3:SHIN+BI+BF)--> | New |
| | -------------------------- | Router |
+-+ <-(6:fwd pkts)- | (Nrtr) |
| |
+-----------+
Figure 2: MCNA MB Signal Flow
Krishnamurthi, Chalmers, Perkins Expires 30 December 2000 [Page 4]
Internet Draft Buffer Management for Mobile IPv6 13 July 2000
3.2.2. NCMA Handoffs
In NCMA, the routers in the network decide when a MN hands off and
to which new access router. The advantage in this scheme is that the
Previous-Router can supply the New-Router with current state for the MN
before the handoff actually occurs.
The initialization of buffering state and the forwarding of buffered
packets may be performed without the explicit request of the MN.
However, the smooth handoff framework requires that the MN still
request forwarding during a handoff 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 old CoA,
CoA1, to the new CoA, CoA2, as in the following example.
Figure 3) illustrates a typical signal flow for MB during an NCMA
handoff. The scenario assumes that both Prtr and Nrtr support MB and
that the MN will take advantage of the MB services at both nodes.
Assume that, in the past, the following actions have occurred,
perhaps in association with an earlier smooth handoff:
1) Prtr sends a router advertisement (RA) with B=1.
2) MN sends a Smooth Handoff Initialize (SHIN) destination
option with a Buffer Initialization (BI) suboption to Prtr,
or Prtr may allocate default buffering state associated with
CoA1.
Now, suppose that Prtr determines that MN needs to handoff to Nrtr.
Then, the following actions occur.
3) Prtr prepares to transfer the buffered packets associated
with CoA1 to Nrtr by sending an unsolicited Smooth Handoff
Reply (SHREP) message containing a BI suboption. Nrtr
attempts to make a compatible buffer allocation for MN.
4) R1 forwards the packets buffered for CoA1 to R2 using an
encapsulated header. R2 decapsulates each packet and buffers
it. R1 continues to buffer newly arriving packets destined
for CoA1 and forwards them directly to R2.
5) MN sends a SHIN option with two buffering suboptions to Nrtr:
a BI suboption with the `C' bit set causing Nrtr to create
buffering state associated with CoA2, and a Buffer Forward
(BF) suboption.
Krishnamurthi, Chalmers, Perkins Expires 30 December 2000 [Page 5]
Internet Draft Buffer Management for Mobile IPv6 13 July 2000
6) Nrtr forwards buffered packets associated with CoA1 to MN at
CoA2.
$ MN +-----------+
+-+ <--(1:RA)--- | Previous |
| | -------------------------- | Router |
+-+ --(2:SHIN+BI)--> | (Prtr) |
| |
| +-----------+
| |
| |
| (3:SHREP+BF) (4:fwd pkts)
| |
V |
V
$ MN +-----------+
+-+ --(5:SHIN+BI+BF)--> | New |
| | -------------------------- | Router |
+-+ <-(6:fwd pkts)- | (Nrtr) |
| |
+-----------+
Figure 3: NCMA Buffer Management Signal Flow
In some cases it may not be possible to transfer the buffers to the
New-Router before the MN obtains a new CoA. 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 new CoA.
3.3. 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
structures as long as the external behavior is consistent with that
described in this document.
Packet Buffer
The Packet Buffer maintains a list of IP packets
originally destined for the MN.
Krishnamurthi, Chalmers, Perkins Expires 30 December 2000 [Page 6]
Internet Draft Buffer Management for Mobile IPv6 13 July 2000
Target Address
The buffer management state must be associated with
a target address. That target address MUST have an
associated lifetime which limits the validity of the
target address and subsequently the MB state. Extensions
or reductions in the lifetime of the target address
implicitly extend or reduce the lifetime of the MB state
accordingly. It is RECOMMENDED that this target address
be equivalent to the CoA binding defined by Mobile IPv6
and the associated lifetime be that of the binding cache
entry for the CoA.
Forwarding Address
When a MN hands off to a new access router, it will also
acquire a new CoA. The Forwarding Address maintains this
new CoA for the MN 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 handoff.
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.
Sequence Number
The maximum value of the Sequence Number field received
in previous MB requests for a target address. The
Sequence Number field is 16 bits long, and all
comparisons between Sequence Number Values MUST be
performed modulo 2**16.
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
Krishnamurthi, Chalmers, Perkins Expires 30 December 2000 [Page 7]
Internet Draft Buffer Management for Mobile IPv6 13 July 2000
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[3]:
Buffer Management (B)
The Buffer Management (B) bit is set in a Router
Advertisement to indicate that the router
sending this advertisement supports MB services.
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[3].
4.2.1. Buffer Initialization SubOption
The Buffer Initialization suboption is used by a MN to request that a
router begin buffering packets on its behalf. The suboption may also be
used by the Previous-Router to initiate buffering at the New-Router on
behalf of the MN in the case of a NCMA handoff.
Originating from the MN, the suboption MAY be associated with a
Smooth Handoff Initiate (SHIN) destination option. Originating from
Krishnamurthi, Chalmers, Perkins Expires 30 December 2000 [Page 8]
Internet Draft Buffer Management for Mobile IPv6 13 July 2000
a router, the suboption MAY be associated with an unsolicited Smooth
Handoff Reply (SHREP) message.
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 message, the
target address of the MN MUST be supplied in the Previous CoA field of
the unsolicited SHREP 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 |A|C|T| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number | Buffer Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
Acknowledge (A) The Acknowledge (A) bit is set by the sending
node to request an explicit acknowledgment in
response to this request.
Create (C) The Create (C) bit is set by the sending node to
request buffering be started. If this bit is
not set, then any buffering associated with the
target address will be stopped.
Transfer (T) The default value of the Transfer bit is 1,
indicating transfer of buffers to the New-Router
during NCMA handoffs. The Transfer (T) bit
MAY be set to 0 by the MN to indicate that the
buffering state associated with the target
address MUST not be forwarded to the New-Router
during NCMA handoffs.
Krishnamurthi, Chalmers, Perkins Expires 30 December 2000 [Page 9]
Internet Draft Buffer Management for Mobile IPv6 13 July 2000
Reserved This field is unused. It MUST be initialized to
zero by the sender and MUST be ignored by the
receiver.
Sequence Number 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
MB request, if any, to the same router (modulo
2**16, as defined in Section 3.3).
Buffer Size The MN MAY request a size for the new buffer in
units of 1,024 octets. If not defined (a value
of zero) then the default buffer size at the
router will be used.
4.2.2. Buffer Forward SubOption
The Buffer Forward suboption is used by a MN or the New-Router or
Previous-Router to request that a router forward buffered packets to the
MN's new CoA.
Originating from the MN, the suboption MAY be associated with a
Smooth Handoff Initiate (SHIN) destination option. Originating from a
router, the suboption MAY be associated with a Smooth Handoff Request
(SHREQ) message.
The request is associated with both a target address and a forwarding
address. In the case of the request originating from the MN, the
target address is defined in the Previous CoA field of the SHIN option,
and the forwarding address is the source IP address of the packet.
For a router-router message, the target and forwarding addresses are
defined in the Previous CoA and New CoA fields of the SHREQ message,
respectively.
The Buffer Forward suboption MAY include a list of unique identifiers
which indicate which packets should not be forwarded. If identifiers
are included, the receiving router SHOULD NOT forward any packets
associated with those identifiers. A 16-bit checksum over the entire
packet is RECOMMENDED for use as the identifier.
The Buffer Forward suboption is encoded in type-length-value (TLV)
format as seen in Figure 6.
Krishnamurthi, Chalmers, Perkins Expires 30 December 2000 [Page 10]
Internet Draft Buffer Management for Mobile IPv6 13 July 2000
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 Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet ID | Packet ID
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 4 plus the total length of all
Packet ID fields.
Reserved This field is unused. It MUST be initialized to
zero by the sender and MUST be ignored by the
receiver.
Sequence Number 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
MB request, if any, to the same router (modulo
2**16, as defined in Section 3.3).
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 number
of 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 a Smooth Handoff
Initiate (SHIN) destination option, a Smooth Handoff Reply (SHREP)
message or a Smooth Handoff Acknowledgment (SHACK) message.
Krishnamurthi, Chalmers, Perkins Expires 30 December 2000 [Page 11]
Internet Draft Buffer Management for Mobile IPv6 13 July 2000
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 | Status | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number | Buffer Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
Status 8-bit unsigned integer indicating the status of
the buffering request. Values of the Status
field less than 128 indicate success. The
following such Status values are defined:
0 Buffering initialized
1 Buffering initialized with limited buffer
2 Buffers forwarded
3 Buffering initialized and forwarded
Values of the Status field greater than or equal
to 128 indicate failure to process the buffering
request. The following such Status values are
currently defined:
128 Reason unspecified
130 Administratively prohibited
131 Insufficient resources
132 Buffering not supported
133 Buffering not enabled
134 Buffers empty
Krishnamurthi, Chalmers, Perkins Expires 30 December 2000 [Page 12]
Internet Draft Buffer Management for Mobile IPv6 13 July 2000
Reserved This field is unused. It MUST be initialized to
zero by the sender and MUST be ignored by the
receiver.
Sequence Number 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.
Buffer Size The granted buffer size in 1,024 octets.
The value of this field is undefined if the
Status field indicates that the request was
unsuccessful.
5. Requirements for Mobile 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 IPv6 nodes. Non-mobile correspondent nodes
(CN) and routers not directly supporting MNs do not have to implement
any of the suboptions or procedures out-lined in this document.
In order to make use of the MB features specified in this document,
some new requirements must be implemented by participating Mobile IPv6
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 support the functionality defined by
the framework draft.
- 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 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 Packet IDs from
recently received packets, as described in Section 4.2.2.
Krishnamurthi, Chalmers, Perkins Expires 30 December 2000 [Page 13]
Internet Draft Buffer Management for Mobile IPv6 13 July 2000
5.2. Requirements for Mobile IPv6 Access Routers
A participating Mobile IPv6 router offering buffering features to
local MNs must fulfill the following requirements:
- Every participating router MUST support the functionality defined
by the framework draft.
- 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.
- Every participating router MUST be able to buffer packets on
behalf of a MN, as described in Section 7.7.
- 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 MN MUST NOT request MB services from the advertising router.
Otherwise, if the `B' bit is set, the MN MAY request MB services
according to the procedures outlined in the following subsections.
If the MN does not initially request MB services in response to this
advertisement, then it SHOULD wait until another advertisement is
received with the `B' bit set before requesting new MB services from a
router.
6.2. Initializing Buffer Management
The MN MAY initiate MB services at a particular router if that
router supports MB. The initialization MUST be requested with a Buffer
Initialization suboption associated with a SHIN Destination Option.
The use of the SHIN option MUST conform to the procedures specified
in the framework draft. Furthermore, the Buffer Initialization
suboption MUST abide by the following restrictions:
Krishnamurthi, Chalmers, Perkins Expires 30 December 2000 [Page 14]
Internet Draft Buffer Management for Mobile IPv6 13 July 2000
- The suboption MUST appear in the part of the SHIN that is only
accessed by the New-Router.
- The Acknowledge (A) bit MAY be set.
- The Create (C) bit MUST be set.
- The Transfer (T) bit SHOULD be set.
- The Sequence Number field MUST contain a unique value greater
than the last sequence number sent to this router.
- The Buffer Size field SHOULD contain the desired size of the
initialized buffer. It MAY be set to zero which indicates that
the router should allocate a buffer of default size, as defined
by the router's configuration.
6.3. Changing Buffer Sizes
The MN MAY request that the size of an existing buffer be reduced or
expanded by re-issuing an initialization request, as described in the
previous subsection, with a different size in the Buffer Size field.
If the new buffer size is smaller than the previous size, the MN MUST
NOT expect the router to retain any specific subset of packets already
buffered.
6.4. Requesting Packet Forwarding
During a handoff, if the MN has MB 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 its new CoA. The forwarding MUST
be requested with a Buffer Forward suboption associated with a
SHIN Destination Option destined for either the Previous-Router or
New-Router. If the New-Router supports MB then the SHIN option SHOULD
be sent to the New-Router.
The use of the SHIN option MUST conform to the procedures specified
in the framework draft. Furthermore, the Buffer Forward suboption MUST
abide by the following restrictions:
- If sent with a Buffer Initialization suboption, the Buffer
Forward suboption MUST appear in the part of the SHIN that is
accessed by both the new and previous routers. Otherwise, it
MUST appear in the part only accessed by the New-Router.
Krishnamurthi, Chalmers, Perkins Expires 30 December 2000 [Page 15]
Internet Draft Buffer Management for Mobile IPv6 13 July 2000
- The Sequence Number field MUST contain a unique value greater
than the last sequence number sent to the forwarding router.
- The Packet ID fields 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 MN MAY end MB services at a particular router by sending a Buffer
Initialization suboption in a SHIN option with the `C' bit not set.
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.
- 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.
7. Router Operation
7.1. Advertising Buffer Management
A router that has been enabled to provide MB services MUST 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 the `B'
bit in its advertisements since handoff 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, as described in the framework draft. This subsection defines
the procedures common to both cases, as well as procedures particular to
each case individually.
Krishnamurthi, Chalmers, Perkins Expires 30 December 2000 [Page 16]
Internet Draft Buffer Management for Mobile IPv6 13 July 2000
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 packet MUST conform to the standard defined in the framework
document.
- The suboption MUST be associated with one of the Smooth Handoff
Destination Options (SHIN, SHREQ, or SHREP).
- The associated 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 (if any) for the
target address.
Any packet not satisfying all of these tests MUST be silently ignored
by the MB protocol 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 associated with a SHIN, then the procedures
outlined in Section 7.2.2 MUST be followed.
- If the suboption is associated with a SHREQ or SHREP, then 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 SHOULD
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:
Krishnamurthi, Chalmers, Perkins Expires 30 December 2000 [Page 17]
Internet Draft Buffer Management for Mobile IPv6 13 July 2000
- If the suboption is a Buffer Initialization SubOption, then the
router takes one of the two following actions based upon whether
the `C' bit is set:
* If the `C' bit is set, then the router MUST follow the
procedures outlined in Section 7.4 using the source IPv6
address of the packet as the target address.
* If the `C' bit is not set, 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 Previous
CoA 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:
- If the suboption is a Buffer Initialization SubOption, then the
router takes one of the two following actions based upon whether
the `C' bit is set:
* If the `C' bit is set, then the router MUST follow the
procedures outlined in Section 7.4 using the Previous CoA
field of the SHREQ as the target address.
* If the `C' bit is not set, then the router MUST silently
ignore the suboption and SHOULD continue processing
subsequent suboptions.
- If the suboption is a Buffer Forward SubOption and the buffered
packets have already been forwarded to the New-Router, the router
SHOULD ignore the suboption. Otherwise, the router MUST follow
the procedure outlined in Section 7.5 using the Previous CoA
field of the SHREQ as the target address and the New CoA field of
the SHREQ 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.
Krishnamurthi, Chalmers, Perkins Expires 30 December 2000 [Page 18]
Internet Draft Buffer Management for Mobile IPv6 13 July 2000
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 return a value less than 128 in the Status field. If a
buffer was allocated due to the request, then the size of that buffer
MUST be placed in the Buffer Size field of the acknowledgment. If the
router rejects the request or cannot fulfill it in any way, then the
router MUST return a value greater than or equal to 128 in the Status
field indicating the reason for failure.
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.
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. Following the framework draft, it is
RECOMMENDED that this target address be the MN's primary CoA on the
local network. It is further RECOMMENDED that the target address reside
as an entry in the router's Binding Cache, as described in the MIPv6
draft, and that the lifetime of the buffering state 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 resize the buffer according to the
value of Buffer Size field. If available 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
Krishnamurthi, Chalmers, Perkins Expires 30 December 2000 [Page 19]
Internet Draft Buffer Management for Mobile IPv6 13 July 2000
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.
The Buffer Forward suboption may contain a list of Packet IDs that
identify which packets should not be forwarded. If this list exists,
then the router SHOULD compute an identifier for each packet in the
buffer and forward the packet only if the computed ID does not match one
of the Packet IDs listed in the suboption. Since unsolicited transfer
of buffered packets does not allow the previous router to perform
the filtering, the new router MUST apply any filtering against the
Packet IDs contained in the SHIN as soon as that message is received
from the mobile node.
7.6. Unsolicited Forwarding Buffered Packets
In the case of an NCMA transfer, if the `T' bit associated with
the last Buffer Initialization request processed for a target address
is set, then a router MAY initiate state for the MN and forward
existing packets to the New-Router. In this case, the router sends an
unsolicited SHREP message with a Buffer Initialization suboption with
the `A' and `T' bits set.
If the Previous-Router forwards packets to the New-Router, the
New-Router MUST buffer these packets and wait for the mobile node to
send a SHIN message before forwarding them as described in Section 7.5.
If the Previous-Router forwards the packets associated with the
target address before the mobile node requests them, it 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 out-lined 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 with a destination address equal to the target address
Krishnamurthi, Chalmers, Perkins Expires 30 December 2000 [Page 20]
Internet Draft Buffer Management for Mobile IPv6 13 July 2000
MUST be duplicated. One copy MUST be forwarded to the MN using the
original destination address, and the other is either buffered and
possibly forwarded according to the following rules:
- The router MUST buffer the packet using the buffering state
associated with the target address.
- If the router has already forwarded the MN'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.
- All buffered packets have been forwarded to the MN's new CoA or
the New-Router and the required period of CONTEXT_SAVE_TIME has
expired, as defined in the framework draft.
- The buffer state is released according to the procedures
described in Section 7.9.
7.9. Freeing Buffer State
Buffering state associated with a MN's target address SHOULD be
deleted when one of the following events occurs:
- The associated Target Address binding expires.
- A Buffer Initialization suboption is received from the MN with
the `C' bit reset.
8. IANA Considerations
The presented protocol requires the assignment of SubOption Type
values for the three buffering suboptions defined.
9. Security Considerations
The suboptions specified in this document are delivered along with
the Authentication suboption defined in [5]. Thus, packets buffered
Krishnamurthi, Chalmers, Perkins Expires 30 December 2000 [Page 21]
Internet Draft Buffer Management for Mobile IPv6 13 July 2000
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.
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] D. Johnson and C. Perkins. Mobility Support for IPv6.
draft-ietf-mobileip-ipv6-12.txt, April 2000.
[4] M. Khalil, H. Akhtar, E. Qaddoura, C. Perkins, and A. Cerpa.
Buffer Management for Mobile IP (work in progress).
draft-mkhalil-mobileip-buffer-00.txt, October 1999.
[5] R. Koodli and C. Perkins. A Framework for Smooth Hand-overs in
IP Mobile Networks (work in progress).
draft-ietf-koodli-smoothv6-00.txt, July 2000.
[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 30 December 2000 [Page 22]
Internet Draft Buffer Management for Mobile IPv6 13 July 2000
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
Communications Systems Laboratory
Nokia Research Center
5 Bayside Road
Burlington, MA 01803
USA
+1 781 993 3627
+1 781 993 1907 (fax)
Govind.Krishnamurthi@nokia.com
Robert C. Chalmers
Department of Computer Science
University of California, Santa Barbara
Santa Barbara, CA 93106
USA
+1 805 893 2777
+1 805 893 6553 (fax)
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 691 2170 (fax)
charliep@iprg.nokia.com
Krishnamurthi, Chalmers, Perkins Expires 30 December 2000 [Page 23]