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]