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]