[Search] [txt|pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01                                                         
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]