[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

Internet Engineering Task Force                               Dana Blair
INTERNET-DRAFT                                              Alex Tweedly
                                                          Michael Thomas
                                                        Jonathan Trostle
                                                         Michael Ramalho
                                                           Cisco Systems


File: draft-blair-rt-mobileipv6-seamoby-00.txt             November 2000
                                                      Expires: June 2000

                          Realtime Mobile IPv6 Framework

Status of this Memo

  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, its and 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

  This draft develops terminology, an architectural framework, a list of
  objectives, and a proposed solution for Realtime Mobile IPv6.
  Realtime Mobile IPv6 seeks to deliver realtime application data to
  IPv6 capable Mobile Nodes while minimizing the impact of handoff on
  realtime applications.

1. Introduction

The convergence of wireless networking and IP networking requires
solutions for transporting realtime application data to mobile devices.
Current IP mobility solutions tend to focus primarily on best effort
data transport to and from a mobile device.  To support realtime
applications, security, admission control, and QoS need to be examined
concurrently with mobility to facilitate smooth transitions from one
access link to another while minimizing the impact on realtime
applications.

This draft assumes IPv6 because the proliferation of mobile devices
will require the use of IPv6 addresses to support the number of attached
devices.  Without the larger IPv6 address space, the end-to-end
transparent Internet model will be broken up and made much more complex
by the use of private IP addressing and result in the inclusion of

Network Address Translators, Application Layer Gateways, and Protocol
Translators.  Also, use of private IP addressing is not practical when
the end device functions as an application server such as Voice over IP.

1.1 Problem Description

Mobility solutions require that packets be redirected to the current
location of a mobile device.  The Mobile IPv6 Binding Update [MIPv6] is
sufficient to accomplish this for best effort traffic.  However,
realtime applications require coordination of admission control,
security associations, and Quality of Service guarantees to minimize
packet loss and jitter to satisfy the expectations of realtime
applications.

Considered independently, admission control, Security Associations,
Quality of Service signaling, and Binding Updates could significantly
delay the transition from one access link to another, thus degrading the
performance of realtime applications.

This draft develops terminology, an architectural framework, a list of
objectives, and a proposed solution for Realtime Mobile IPv6.

2. Terminology

Subscripted Elements

  In this draft we will have occasion to reference the "present" element
  of a given type and the "next" element of that same type with indices
  "n" and "n+1", respectively.  For example, we will reference the first
  access link (AL) as AL1, the next as AL2, and so on.  We will use
  this indexing methodology as shorthand for any element (e.g., ALn+1,
  ARn, vPDPn.  We do not intend that the actual "present" index "n" to
  be identical across element type (e.g., the present ALn could be AL9,
  while the present vPDPn could be vPDP2).

The sample network diagram of Figure 1 below is used to illustrate the
terminology used in this draft. This figure will be used to describe
the operation of the proposed handoff mechanisms by means of the
specific network topology example shown in this figure.



















    +--------------------------+
    | HN                       |
    |                          |
    |  +----+  +----+  +-----+ |        +-----+  +-----+
    |  |HA  |  |HKDC|  | hPDP| |        |cNode|  |AKDC |
    |  |    |  |    |  |     | |        |     |  |     |
    |  +----+  +----+  +-----+ |        +-----+  +-----+
    +--------------------------+

                 +-----+
                   |vPDP |
                   +-----+

    +------------------------------+    +-----------------+
    |  TD1                         |    |  TD2            |
    |   +----+            +----+   |    |      +----+     |
    |   | AR1|            | AR2|   |    |      | AR3|     |
    |   |    |            |    |   |    |      |    |     |
    |   +----+            +----+   |    |      +----+     |
    |      |                 |     |    |        |        |
    +------|-----------------|-----+    +--------|--------+
           \                 |                   /
             \               | AL2             /  AL3
               \  AL1        |               /
                 \        +----+           /
                   \------| MN |---------/
                          +----+

Figure 1: Sample Network Diagram showing AR1 and AR2 in a particular
trust domain and AR3 in a different trust domain.
Common Terms

  Mobile Node (MN)

    Device which supports IPv6 mobility according to [MIPv6].
    A MN may be a host or a router.

  Home Agent (HA)

    Device that supports the Home Agent function described in [MIPv6].

  Correspondent Node

    A peer node with which a mobile node is communicating. Defined in
    [MIPv6].

  Home Address (hAddr)

    An IP address assigned to a MN as defined in [MIPv6].

  Care-of-Address (CoA)

    An IP address assigned to a MN as defined in [MIPv6]

    New CoA (NCoA) means that CoA on ALn+1 is different than CoA on ALn.
    Same CoA (SCoA) means that CoA on ALn+1 is the same as CoA on ALn.


  Access Router (AR)

    An IP router between an Access Network and one or more access links.

  Access Network (AN)

    An IP network which includes one or more Access Routers.

  Policy Decision Point (PDP)

    A network service that is responsible for handling policy decisions
    (e.g. access authorization, qos authorization, etc.) and also
    billing and settlement issues.  Defined in [COPS1]

    Home PDP (hPDP) is the policy decision point used by the
    Home Network.

    Visited (vPDP) is the policy decision point used by the visited
    network.

Key Distribution Center (KDC)

    A network service that supplies tickets and temporary session keys.
    Defined in [KRB1].

    The Home KDC (HKDC) provides security credentials for the MN to
    register with the Home Agent.

  Trust Domain (TD)

    A set of access routers within a particular network that have direct
    trust relationships between all ARs in that set. In the figure above
    TD1 is comprised by the set {AR1, AR2} and TD2 is the set {AR3}..

  Access Link (AL)

    A link layer connection between MN and AR.  Multiple Access Routers
    may share the same access link.  An AL consists one downlink or
    one uplink or both.

    Downlink communication flows from AR to MN.

    Uplink communication flows from MN to AR.

  Handoff Trigger

    A Handoff Trigger initiates a Handoff Decision.  The MN or an
    element within the AN may create a Handoff Trigger.  The result of
    the handoff decision may create a Handoff Command.

    Example sources of a Handoff Trigger are MN detects a stronger
    signal for a different AL, or AN detects that a MN is moving and a
    new AL would provider better transmission.  Many other sources of
    Handoff Trigger exists.

    This draft does not discuss events that result in a Handoff Trigger.


Handoff Decision

    A Handoff Decision is an algorithm which decides whether or not to
    issue a Handoff Command based on one or more Handoff Triggers.

    This draft does not propose algorithms for the Handoff Decision.

  Handoff Command

    The Handoff Command initiates a Handoff Sequence.  The MN or an
    element within the AN may issue a Handoff Command.  The Handoff
    Trigger and Handoff Command may be created by different network
    components or the same network component.

  Handoff Sequence

    A Handoff Sequence is a series of steps executed by various network
    components to attempt a handoff.  A Handoff Sequence may be
    successful in establishing ALn+1.  However, establishment of ALn+1
    does not guarantee communication with a cNode.  Since IP is
    connectionless, a Handoff Sequence cannot rely on IP or link layer
    indications to verify that the MN can communicate with a cNode over
    ALn+1.

    The solutions section of this draft contains an abstract Handoff
    Sequence proposal.   Detailed Handoff Sequences are in the appendix.


  Initialization Sequence

    An Initialization Sequence is a series of steps executed by various
    network components to establish communication over an AL for the
    first time.

  Wake-up Sequence

    A Wake-up Sequence is a series of steps executed by various network
    components to establish an AL while a MN is in sleep mode.  Sleep
    mode means the device is in a lower power state with no uplink, and
    a limited downlink capability.

  Handoff Delay

    Handoff delay is the time between when the handoff command is issued
    and when ALn+1 is established.

  Handoff Types

    Make-Before-Break Downlink Handoff (MBBDH)

      ALn+1 downlink is established before removing ALn downlink.
      Duration of simultaneous ALn and ALn+1 downlink connections is
      not bounded.

    Make-Before-Break Uplink Handoff (MBBUH)

      ALn+1 uplink is established before removing ALn uplink.  Duration

      of simultaneous ALn and ALn+1 uplink connections is not bounded.

    Break-Before-Make Downlink Handoff (BBMDH)

      The MN stops receiving on ALn before being able to receive on
      ALn+1.

    Break-Before-Make uplink Handoff (BBHDH)

      The MN stops transmitting on ALn before being able to transmit on
      ALn+1.

Handoff Control

  Handoff Control may be performed by various network elements.  Any
  Handoff Sequence should be analyzed to determine which control
  methods are used.  Some control methods may be preferable depending
  access network technology or administration preference.

  Mobile Controlled

    A MN may create any number of access links without a-prior
    knowledge of any other access link.  The MN generates the Handoff
    Trigger, performs the Handoff Decision, and issues
    the Handoff Command.

  Mobile Assisted

    The MN generates the Handoff Trigger, the network performs the
    Handoff Decision and issues a Handoff Command to the MN.

  Network Assisted

    The network generates a Handoff Trigger.  If the network
    performs the Handoff Decision, the network issues a Handoff
    Command to the MN.  If the MN performs the Handoff Decision, the
    MN issues a Handoff Command to itself.

  Network Controlled.

    The network generates the Handoff Trigger, performs the Handoff
    Decision, and issues the Handoff Command.  The MN must execute a
    Handoff Sequence to maintain an AL.

3. Objectives

Items to consider when analyzing a Handoff Sequence.

3.1 Handoff Objectives

Minimize Handoff Delay

Minimize packet drops during Handoff Delay

  Realtime applications have a relatively low tolerance for packet
  drops.  Packet drops are more likely during BBMDH and BBMUH.


Minimize packet latency

Minimize misadaptations of adaptive jitter buffers due to handoff.

Link Layer Handoff Independence

  A Realtime Mobile IPv6 Handoff Sequence must not depend on any
  particular link layer handoff mechanisms but may exploit layer 2
  information.

Handoff link failure behavior

  A Realtime Mobile IPv6 Handoff Sequence should consider behavior when
  ALn+1 cannot be established during the Handoff Sequence.

Handoff addressing, either SCoA or NCoA, is an important consideration
when analyzing or creating a Handoff Sequence.  For example, SCoA does
not require MN re-registration but may not be possible between Trusted
Domains.

Handoff Control is an important policy consideration of some access
networks. For example, A Handoff Sequence may not be acceptable for a
given access network or network policy if the sequence is not Network
Assisted or Network Controlled.


3.2  Security

Fast smooth handoffs must take into account access networks which
require both authentication and authorization of mobile users in order
to gain access to best effort traffic as well as any other services
such as enhanced quality of service, etc.

User authentication may be done directly on the access
network or via proxied authentication through a third party where the
access network provider and the third party have a trust relationship.
The latter arrangement allows for a settlement model where a mobile node
does not need to have a direct arrangement with the visited service
provider, but instead is authenticated with the third party, but
settled between the third party and the access service provider.

The initial authentication and authorization state should be captured by
the access service provider router in a way which allows the
authorization state to be forwarded to other access routers within the
same Trust Domain.  This allows access routers the option of not needing
to perform authentication or authorization back to the authoritative
authorization source.  The advantage of caching this authorization state
at the edges is that potentially expensive round trips to the
authorizing source can be avoided.

The MN should consider requiring mutual authentication.  Mutual
authentication prevents an intruder from pretending to be an AR and
gathering credentials from the MN.

3.3  Quality of Service

The handoff mechanism should consider the re-establishment of QoS

instantiated in ALn when handing off to Aln+1.  This should
include either intserv or signaled diffserv techniques.

4. Handoff Behavior

The following is an abstraction of events that may be required before
and during handoff.  Not all steps are required for all handoff nor are
they necessarily executed in the sequence presented.  A Handoff Sequence
will define a set of steps and protocols required to attempt a handoff.

4.1 Initialization Events

The Initialization Events allow a MN to establish connectivity with one
or more cNodes before attempting to handoff.  Although Initialization
Events are not part of a Handoff Sequence some parts of initialization
may be reused during a Handoff Sequence to simplify operation within
the MN.

  1. Obtain credentials to allow use of the visited network, if
     necessary.

  2. Obtain access to and through a visited network.  Use credentials
     from 1., if needed.

  3. Obtain credentials to allow MN to register with the Home Agent.

  4. Obtain credentials to be used when establishing Quality of Service
     for application flows, if necessary.

  5. Establish security association with the Home Agent using
     credentials from 3.

  6. Mobile Node registers with the Home Agent as defined in [MIPv6].

  7. Establish zero or more application flows over the first access
     link, AL1, to one ore more cNodes.  QoS credentials from 4. may be
     used to authorize Quality of Service via a PDP for a specific
     application flow.

4.2 Handoff Events

The Handoff Events allow a MN to attempt to move packet forwarding and
receiving from ALn to ALn+1.  Some events may not be required, or may
not be executed in the order presented when applied to a Handoff
Sequence.

  1. Obtain credentials, if necessary, to allow use of ALn+1.

  2. Obtain access to and through the visited network. If necessary, use
     credentials from 1.

  3. QoS signaling for 0 or more application flows.  If necessary, use
     QoS credentials obtained during initialization.

  4. Establish tunneling and/or forwarding from ARn to MN using ALn+1.



  5. If New CoA (NCoA), MN re-registers with Home Agent as defined in
     [MIPv6].

  6. If NCoA and if desired, MN notifies cNodes NCoA.

  7. If possible, Remove ALn when it is no longer needed.

4.3 Application of Handoff Objectives.

4.3.1 Minimize Handoff Delay

  Authorization state transfer may be pulled from ARn to ARn+1 or pushed
  from ARn to ARn+1.

  Minimize the number of required transactions before MN may send and
  receive packet to and from a cNode over ALn+1.

  Minimize the number of home roundtrip transactions required before MN
  may send or receive a packet to or from a cNode over ALn+1.

  Minimize the size of all packets transmitted and received before MN
  may send or receive a packet to or from a cNode over ALn+1.

4.3.2 Minimize Packet Drops

  Limit packet drops by forwarding packets from ARn to MN over ALn+1.

4.3.3 Minimize packet latency

  For NCoA handoff, re-register with HA and cNodes as soon as possible.

  For SCoA handoff, minimize the delay of forwarding path convergence.

4.3.4 Security

  If ALn and ALn+1 are on different routers, ARn and ARn+1, then:

    A. ARn and ARn+1 may have a pre-established trust relationship,
       or
    B. ARn and ARn+1 may be able to create a dynamic trust relationship,
       or
    C. ARn and ARn+1 will never have a trust relationship.

4.3.5 Quality of Service

Maintain quality of service by establishing acceptable QoS over ALn+1.
QoS credentials may be needed.

5. References

  [MIPv6] David B. Johnson, Charles Perkins, "Mobility Support in IPv6",
          draft-ietf-mobileip-ipv6-12.txt, April 2000.

  [KRB1]  Kohl, J., Neuman, c., "The Kerberos Network Authentication
          Service (V5)", RFC 1510, September 1993.

  [COPS1] Durham, D., Boyle, J., Cohen, R., Herzog, S., Rajan, R.,
          Sastry, A., "The COPS (Common Open Policy Service) Protocol",
          RFC 2748, January 2000.

  [COPS2] Herzog, S., Boyle, J., Cohen, R., Durham, D., Rajan, R.,
          Sastry, A., "COPS usage for RSVP", RFC 2749, January 2000.

  [RSVP1] Herzog, S., "RSVP Extensions for Policy Control", RFC 2750,
          January 2000.

  [RSVP2] Baker, F., Lindell, B., Talwar, M., "RSVP Cryptographic
          Authentication", RFC 2747, January 2000.

Authors Information

Dana Blair - dblair@cisco.com
Alex Tweedly - agt@cisco.com
Michael Thomas - thomasm@cisco.com
Jonathon Trostle - jtrostle@cisco.com
Michael Ramalho - mramalho@cisco.com






























Appendix A:  Make Before Break Handoff Sequence using RSVP, Kerberos,
             and COPS.

This is Handoff Sequence is a work in progress. No reader should assume
that this is complete or covers all required handoff scenarios.

Authorizing PDP (aPDP) is a policy decision point, which is trusted
    by the hPDP.

Authorizing KDC provides credentials and authorizes use of the Home KDC

Access Service Request is a message which initiates handoff.

INITIALIZATION SEQUENCE

The MN is hard-configured with Home Address and prefix length, and
    either shared secret with the Home Agent, Authorizing KDC, or
    certificate.

  1.  Obtain sufficient access over AL1 to reach Authorizing KDC (AKDC).

      The AKDC may be separate from the Home Network.

  2.  Obtain ticket for Authorizing Policy Decision Point (APDP) from
      AKDC.

      One of the requirements of any successful scheme is the need for
      authentication and authorization for the large number of mobile
      hosts. This requires a scalable authentication mechanism. The
      prime candidates are Kerberos V5 [RFC 1510] and public key based
      mechanisms.

      The desire to achieve fast handoff, assuming relatively limited
      computing power on the mobile hosts, argue against any
      scheme involving public key computations in the handoff phase.
      Furthermore, the revocation checking that is required for most
      existing public key based mechanisms would cause additional
      delays.  Therefore the scheme discussed proposes Kerberos for
      authentication.  Kerberos still allows for some of the main
      benefits of a public key based approach since Kerberos includes
      extensions for public key authentication. At the same time, the
      speed of Kerberos secret key authentication is leveraged during
      the handoff.

  3.  Obtain sufficient access over AL1 to contact Home KDC (HKDC).

  4.  Obtain ticket from HKDC for HA.

5. Using Home Agent Discovery defined in [MIPv6], find the address
the HA which the MN will use.

HANDOFF SEQUENCE

  6.  Access Service Request (ASR)

      The Access Service request is sent from MN to AR1.
        The ASR contains the following:

      - description of the qos signaling mechanism in use
      - some description of the type/level of service being requested
        (e.g. RSVP flowspec)
      - flag whether tunneling is desired.  A MN-AR1 key may be needed
        if tunneling is desired.
      - address and ticket for PDP
      - address and BU for the HA.

      If the MN has an application which uses RSVP, then RSVP [RSVP1] is
      proposed as the ASR for a variety of reasons.
      A layer three admission control mechanism is needed to provide
      both a means to access the network as well as a means of signaling
      that a handoff operation is desired.  If enhanced quality of
      service is required for some flows, as may be the case with
      real time applications, a common admission control scheme for
      both basic network access and admission of quality of service
      flows is desirable. Modeling best effort traffic as a subset
      of all qualities of service leads to the possibility of using
      RSVP as the signaling protocol.

      RSVP also has some other advantageous properties.  RSVP already
      has the means of carrying credentials in the form of policy
      objects [RSVP2] which can be sent to a remote policy decision
      point. RSVP already has the concept of soft state. Soft state in
      the context of mobility is quite important as there needs to be
      some means of clearing stale state in interior network elements
      without explicit signaling.

      RSVP's major advantage, however, comes when it is used with
      enhanced quality of service flows.  Since it is likely that
      real time traffic in some important situations will require
      explicit admission control to deal with scarce bandwidth, a
      fast, smooth handoff cannot be considered complete until the
      quality of service on the new access router and beyond is
      installed. While RSVP messages could be sent in addition to an
      ASR, a single message which requests the flow at the attachment
      point along with the necessary credentials would be more
      economical. The message could also carry the request for any
      forward tunneling desired for a smooth handoff.

      Additions to RSVP would include a handoff object and changes
      to support Best Effort, non-flow based admission control.

  6a. Authorization

  6a-1. AR1 determines whether it can make the authorization decision on
        its own. If AR1 cannot authorize on its own, continue with 6a-2.

  6a-2. AR1 takes the level of service request, and hPDP info, and
        forwards those to its own PDP, the visited PDP1 (vPDP1).  The
        vPDP1 may then decide it can authorize (or deny) service.
        Otherwise, continue with 6a-3.

        COPS [COPS1] is proposed as the admission control policy
        protocol. COPS and RSVP are well integrated via RFC 2749. As for
        RSVP, a single admission control mechanism for both best effort
        and enhanced quality of service is desirable. COPS has been

        specifically designed for enhanced quality of service admission
        control and could be easily extended, if needed, to support
        admission of best effort traffic. As with RSVP, COPS has the
        desirable property of allowing for policy objects which can be
        used for authentication of a MN.  Also, COPS supports cascaded
        policy decision points to allow a visited PDP to authorize with
        a home PDP.

  6a-3. vPDP1 forwards the credential to hPDP for a decision, and/or
        settlement/billing decision between PDPs or via 3rd party
        broker, or other means.

  The result whether local to AR1 or from vPDP1 is a boolean decision
  to allow access of MN through AR1.

  6b. If tunneling is desired, get new key for MN/AR1

      If necessary, vPDP1 sends to hPDP the ticket and address for MN,
      type/level of service, etc.  6a may have already done this through
      interaction with the hPDP.  However if not, this step
      is required.

      hPDP replies to vPDP1 with a new credential for use between MN
      and AR1.

  6a and 6b may occur in parallel. However, 6c and 6d must wait for a
  successful result from 6a to reach AR1.

  6c. QoS signaling

  If using RSVP - send the RSVP packet towards HA.
  If no QoS signaling, then AR1 simply imposes DiffServ policing if
  needed.

  6d. Send Binding Update (BU) [MIPv6] to HA.

  The BU may be attached as a routing header on the ASR or imbedded in
  an object within the ASR.  If the BU is embedded in an object within
  the ASR, the BU must be in the form of a complete IP packet including
  IPSEC encapsulation.

  If the BU is in an embedded object, AR1 extracts the BU and sends it
  on to HA.

  End of 6: The MN may now communicate with the HA including proper
            level of QoS assuming RSVP was successful.

  As long as the neither MN nor the AN requires a handoff, no more steps
  are required.

  7. MN attempts to handoff to AR2.

  The Handoff Trigger may occur because MN heard a beacon from AR2
  and decided AL2 was a better connection, or because the network
  containing AR1 determined that the MN should moved to AL1.  There are
  many other possibilities as well.


  7a. MN acquires suitable local address by either stateless or stateful
      address configuration.  This may be either SCoA or NCoA.

  8. MN sends an ASR to AR2.

    The ASR is sent from MN to AR2, contains:
    - QoS : description of the qos signaling mechanism in use
    - QoS : description of the type/level of service being requested
      (e.g. RSVP flowspec)
    - Security : flag whether tunneling back to AR1 is desired (i.e. is
      a MN-AR2 key needed)
    - Security : one or more tuples of
         < vPDP, ticket vPDP, address/name of hPDP, ticket hPDP >
    - Mobility : [if New-CoA] address and embedded (authenticated) BU
      for the HA.
    - Mobility : [optional] address and BU for the previous AR

Note that this allows multiple tuples of PDP address + ticket. These
will be considered in turn, with AR2 deciding whether or not to trust
the vPDPn-1.  Thus, if MN has recently been accessing the network via
AR1, and has successfully established a key for use with AR1, then MN
may (will?, must?) make the first tuple be <AR1, hPDP, ticket from 1a>,
and the second tuple be <*, hPDP, ticket from 1a>.

Thus in the authorization step AR2 will consider each of these tuples
for a possible authorization decision in turn.

Otherwise, this should be just same as the sub-steps of 2 above, with
the addition of (optionally) AR2 sending a BU to AR1. Also, if using
Same-Coa, AR2 will kick off the routing update / convergence.

Note - if RSVP is the protocol to be used here, it most likely is
addressed to HA, but will be intercepted by AR2, and the following steps
taken before the packet is allowed to continue on its way to HA.  But
if it is some new "Access Service Request", then it can simply be
destined to AR2.

Therefore :

  8a. Authorization

  8a-1. AR2 determines whether it can make the authorization decision
        on its own. If AR2 does not authorize on its own, continue with
        8a-2.

  8a-2. AR2 tries first PDP address + PDP ticket tuple where the PDP
        address is the address of AR1.  If AR2 trusts AR1, then AR2
        will treat AR1 as a vPDP by asking AR1 to authorize the Access
        Service Request.

        AR1 may then decide it can authorize (or deny) service, based on
        having previously done so. Otherwise, continue with ..

  8a-3. AR2 tries second PDP address + PDP ticket tuple where PDP
        address may be *.

The vPDP specified is null (blank), so AR2 uses his own, normal vPDP.

AR2 forwards hPDP info to vPDP2, and vPDP2 forwards the credential to
hPDP for a decision, and/or settlement/billing decision between PDPs or
via 3rd part broker, or other means.

  8b. If tunneling is desired, get new key for MN/AR2

  vPDP sends to hPDP the ticket and address for MN, type/level of
  service, etc.  In general, step 8a above would include doing this, but
  in the case where it did not, they need to be send on to hPDP anyway.

  hPDP replies to vPDP with a new credential for use between MN and AR2.
  This used the pre-existing trust between vPDP2-hPDP and between
  MN-hPDP to generate this new credential. vPDP2 sends this on to AR2
  and to MN.

  8a and 8b may occur in parallel.  8c and 8d must wait for a successful
  result from 8a to reach AR2.

  8c. QoS Signaling

  If using RSVP - send the RSVP packet towards HA.
  If no QoS signaling, then AR2 simply imposes DiffServ policing, if
  required.

  8d. If the optional BU for AR1 is included, AR2 sends the BU, which
      was IPSEC encapsulated using the key derived in 6b, to AR1.  MN is
      responsible for the construction of this BU, and therefore MN
      determines whether SCoA or NCoA is used.

      For SCoA, the BU will cause AR1 to tunnel to AR2 where AR2 will
      forward the packet to MN.

      For NCoA, the BU will cause AR1 to tunnel directly to CoA2

      Note that AR2 or AR1 omit or reject this step if either AR2 or AR1
      determines that this step violates network policy.

  8e. MN sends BU to HA.

      AR2 extracts the embedded BU and sends this on to HA.

  8f. If SCoA, then AR2 (and also AR1 based on step 4d) will initiate
      routing convergence to reflect the new attachment point for the
      CoA.

All subsequent handoffs (e.g. ALn+1 to ALn+2) occur in like manner
beginning with step 7.











Appendix B:  Handoff Sequence using Kerberos and Radius/Diameter

This Handoff Sequence is a work in progress.  No reader should assume
that this is complete or covers all required handoff scenarios.

1. INITIALIZATION SEQUENCE

Initially, the MN obtains a ticket granting ticket (TGT) using either a
password or X.509 certificate in an AS exchange with a KDC in its home
realm using IAKERB [IAKERB]. Subsequently, the MN mutually authenticates
with the AR in order to obtain network access using IAKERB.
An IPSEC SA is also established with the user's home agent.  The IPSEC
SA key management protocol could be IKE or any of the IPSEC key management
protocols.

2. HANDOFF SEQUENCE

The proposal in this appendix specifies the use of Kerberos [3] for
providing authentication, key establishment, and authorization for
Mobile IPv6 [2,5] fast handoffs.

ARn detects the network prefix of the ARn+1.  ARn sends a Neighbor
Discovery Redirect Message (ND Redirect) over ALn with a list of network prefixes for ARn+1. Upon receipt of this message, the MN configures a
new CoA.

We define new suboptions for the ND Redirect Message to include
a negotiation flag, and the NR principal name and realm. The negotiation
flag indicates whether to pass security state from the PR, which we call
local authentication, or local authentication followed by global
authentication (which may include an exchange with a Kerberos KDC
server), or global authentication. The MN then sends a Previous Router
Notification Message to
the ARn which uses the IPSEC AH header and is keyed using the existing
security association between the MN and the PR; this message informs the
PR of the MN's new CoA. We define a new suboption for this message that
includes a negotiation flag (the MN will choose a flag that is the same
or more strict than the negotiation flag value sent to it from the PR in
the Notification Message), and a suboption for including a Kerberos
message.

The value of the negotiation flag that was sent from the MN to the ARn
will help determine what steps occur next. If local authentication was
selected, then the ARn will pass secret cryptographic key information as
well as other state information to ARn+1, using an encrypted channel
between ARn and the ARn+1. This data will be sent

in an unsolicited message (message TBD) from ARn to ARn+1.  The MN
established ALn+1 to ARn+1.
The MN and ARn+1 will exchange ND solicitation and advertisement
messages over ALn+1 prior to exchange of application data. The MN and
the ARn will use the shared secret keys to establish IPSEC SA's between
themselves after the initial handoff operations.

If the value of the negotiation flag that was sent from the MN to ARn+1
was local authentication followed by global authentication, then the
same steps as in the local case occur, except subsequently (after
application data is flowing), Kerberos mutual authentication with
additional key establishment occurs. We have defined new suboptions for
the Neighbor Discovery Solicitation
and Advertisement [8] for inclusion of Kerberos messages to achieve
global authentication. Two ND solicitation and advertisement exchanges
will be needed to encapsulate the three Kerberos messages in this case.

If the negotiation flag value that was sent by the MN is global
authentication, then the Previous Router Notification message will
contain a ticket granting ticket (TGT) as described in the minimal
messages subprotocol from IAKERB [4]. A typical exchange in this case
would be:

                         ND Redirect (with prefixes)
              ARn -------------------------------------------> MN
                    suboption with principal name, realm
                    suboption with global authentication flag


                    Previous Router Notification (with new CoA)
                ARn <------------------------------------------- MN
                    suboption with global authentication flag
                    suboption with TGT


                    Layer 2 Establishment
                MN -------------------------------------------> ARn+1


                    ND Solicit
                MN <------------------------------------------- ARn+1
                    suboption with encapsulated Kerberos AP_REQ


                    ND Advertisement
                MN -------------------------------------------> ARn+1
                    suboption with encapsulated Kerberos AP_REP


                            application data flow
                MN <------------------------------------------> ARn+1



                Figure 1: Global Authentication for Fast Handoffs



Before forwarding the AP_REQ to the MN, ARn+1 will send a message to its
local AAA server with authorization data from the Kerberos service
ticket extension. The reply from the local AAA server will contain
the updated and massaged authorization data. ARn+1 will cache the
authorization data and use it once the MN has authenticated to ARn+1.
The protocol between ARn+1 and the local AAA server could be either
Radius or Diameter. Upon receipt of the AP_REQ from the ARn+1, the MN
will perform the normal Kerberos validation steps. In addition, the
service principal identifier component of the client principal name
in the ticket MUST be equal to mobileip. If not, the MN will fail
the request by sending a KRB_ERROR message to the NR with the error
code KRB_ERR_GENERIC.

Note that the AP_REQ will have the mutual authentication flag set. Thus,
the MN is required to authenticate to the ARn+1 which it does by sending
the AP_REP message to the ARn+1.

Subsequently, the MN sends any BCU's to its home agent (HA) and
correspondent nodes (CN's). The MN may also send a router solicitation
message to the ARn+1
with a new suboption asking for the reverse ticket (IAKERB [4]) and list
of adjacent realms to be sent back in the router advertisement. The
reverse ticket is constructed by the ARn+1 and is targeted at the ARn+1
from the MN. It allows fast subsequent authentications from the MN to
the ARn+1.  The list of adjacent realms can be used by the MN to
precache crossrealm TGT's targeted at adjacent realms (as a background
task). This performance optimization allows subsequent global
authentications for adjacent realms to skip exchanges
with the remote user's KDC. Instead, a local KDC will be used.

Kerberos authentication uses the subprotocols from IAKERB [4]. In
particular, the minimal messages subprotocol (which uses user-user authentication) is used
for the global authentication exchange (illustrated in Figure 1).
Precaching  can use either standard Kerberos or standard IAKERB. Initial
logon (which occurs before the first roam) should use standard IAKERB
exchanges with an
IAKERB proxy. As a result of initial logon, the MN user will obtain an
initial TGT, as well as a service ticket targeted at the initial access
router which acts as an IAKERB proxy. Initial logon can use public key certificates as described in pkinit [9].

For a break before make case, the MN may have to establish layer 2 with
the ARn+1 without the benefit of the ND Redirect and Previous Router
Notification messages. In this case, the security data from the ND
Redirect message (in the above figure) will be placed in the router
advertisement message sent from the ARn+1 to the MN in response to the
MN's router solicitation
message. The MN then sends a ND solicitation with the authentication
flag and optionally, the TGT, if global authentication has been
selected. In the global authentication case, the ARn+1 responds with a ND advertisement that includes the AP_REQ message. In this case the flow
becomes:


                    Layer 2 Establishment
                MN -------------------------------------------> ARn+1



                    Router Solicitation
                MN -------------------------------------------> ARn+1
                    negotiation flag suboption, TGT suboption


                    Router Advertisement
                MN <------------------------------------------- ARn+1
                    negotiation flag suboption, and optionally,
                    suboption with encapsulated Kerberos AP_REQ


                    ND Solicitation
                MN  ------------------------------------------->ARn+1
                    suboption with Kerberos AP_REP message (if
                    global authentication has been negotiated)

                    ND Advertisement
                MN  <------------------------------------------ ARn+1

                            application data flow
                MN <------------------------------------------> ARn+1



                Figure 2: Global Authentication: Break Before Make

3. Neighbor Discovery Solicitation, Advertisement, Redirect Suboptions,
and Previous Router Notification Suboption.

The following suboption contains the principal name and realm:

      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      |    Length     |   Kerberos Principal Name ... /
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Kerberos Principal Realm  ...                              /
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Fields:

         Type            Message type. To be assigned.

         Length          8-bit unsigned  integer.  The  length in  bytes
                         of the option (including the type and length
                         fields).

         Principal Name  Kerberos Principal Name

         Principal Realm Kerberos Principal Realm


The following suboption contains the negotiation flag:



      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      |    Length     |L|B|G|       Reserved          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Fields:

         Type            Message type. To be assigned.

         Length          8-bit unsigned  integer.  The  length in  bytes
                         of the option (including the type and length
                         fields).

         Flags           L - local authentication
                         B - local authentication followed by global
                             authentication
                         G - global authentication

                 The requestor sets one of the above flags and the
                 responder sends the same suboption with either the
                 same flag or a more strict flag. The flags increase
                 in strictness from L to B to G. We note that an
                 attacker can cause at most a denial of service attack
                 by manipulating these flags in transit.

The following suboption contains a Kerberos protocol message:

      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      |    Length     |     Kerberos Message ...      /
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
     |                                                               /
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Fields:

         Type            Message type. To be assigned.

         Length          8-bit unsigned  integer.  The  length in  bytes
                         of the option (including the type and length
                         fields).

         Kerberos        Kerberos protocol message as defined in [3]
         Message


Any of the above suboptions can be included in any of the neighbor
discovery solicitation, advertisement, or redirect messages, as well as
the previous router notification message. The principal name/realm
suboption and the negotiation flag suboption can also occur in a router advertisement message.

4. Router Solicitation and Advertisement Options

The following router solicitation message suboption is used to request

that the access router return a list of adjacent realms in its router
advertisement. The access router may also return a Kerberos message
suboption with a reverse ticket.


     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      |    Length     |        Reserved               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Fields:

         Type            Message type. To be assigned.

         Length          8-bit unsigned  integer.  The  length in  bytes
                         of the option (including the type and length
                         fields).


The following router advertisement message suboption is used to return
a list of adjacent realms in the router advertisement:

     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      |    Length     |        Realm 1...             /
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     /    Realm 2...                                                 /
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     /    ... Realm n...                                             /
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Fields:

         Type            Message type. To be assigned.

         Length          8-bit unsigned  integer.  The  length in  bytes
                         of the option (including the type and length
                         fields).

         Realm i         The realm name of the ith geographically
                         adjacent Kerberos realm.


The following router solicitation message suboption is used to request
that the access router return the principal name/realm suboption and
the negotiation flag suboption (as described above). It is used in
break before make handoff cases.


     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      |    Length     |        Reserved               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


     Fields:

         Type            Message type. To be assigned.

         Length          8-bit unsigned  integer.  The  length in  bytes
                         of the option (including the type and length
                         fields).


5. Authorization

We propose the following approach to authorization for the global case
(in the local case, authorization state is passed from the previous
router to the new router).

The NR's KDC will map authorization data in the user's Kerberos ticket to
local authorization attributes which will be placed in a ticket extension
of the issued ticket.

Here we propose a new Kerberos authorization data type:

AD-MOBILEIP-ATTRIBUTES     TBD

The data is the ASN.1 OCTET STRING encoding of the following:


     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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |           Length              |     Alg ID    |   Signature   /
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     /           TLV's                                               /
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


     Fields:

         Length          8-bit unsigned  integer.  The  length in  bytes
                         of the option (including the type and length
                         fields).

         AlgID           Algorithm Identifier

         Signature       Digital signature over TLV's.

         TLV's           Authorization attributes in TLV form

We also propose a new ticket extension type:

TE-MOBILEIP-ATTRIBUTES  9

[1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
     Levels", BCP 14, RFC 2119, March 1997.

[2]  Deering, S., Hinden, R., "Internet Protocol, Version 6 (IPv6)
     Specification", RFC 2460, December 1998.


[3]  Kohl, J., Neuman, C., "The Kerberos Network Authentication Service
     (V5)", RFC 1510, September 1993.

[4]  Swift, M., Trostle, J., "Initial Authentication and Pass Through
     Authentication Using Kerberos V5 and the GSS-API (IAKERB)",
     Internet draft (work in progress), draft-ietf-cat-iakerb-04.txt,
     July 2000.

[5]  Johnson, D. and Perkins, C., "Mobility Support in IPv6", Internet
     draft (work in progress), draft-ietf-mobileip-ipv6-12.txt, April
     2000.

[8]  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.

[9]  Tung, B., Neuman, C., Hur, M., Medvinsky, A., Medvinsky, S., Wray,
     J., Trostle, J., "Public Key Cryptography for Initial
     Authentication in Kerberos", Internet draft (work in progress),
     draft-ietf-cat-kerberos-pk-init-11.txt, April 2000.






































Appendix C

This appendix shows a fully integrated RSVP/COPS/Kerberos
solution. It is very similar to Appendix A, and will be
merged at a later date.

Abbreviations:

PO: RSVP/COPS policy object
TR: Ticket Relay Object: an object which relays a shared
    secret back to the initiator and relay initiator. This
    subject deserves a great deal more discussion, and will
    be added in future versions of this draft.
HO: Handoff Object: an object which requests a handoff to
    occur between AR1 and AR2 with optional forward tunneling
    from AR1 to AR2. If handoff objects desire forward tunneling,
    they must contain an embedded handoff object
EBU: Embedded Binding Update: an embedded binding update
     is a normal IPv6 mobility binding update message which
     is encapsulated in a wrapper which proves MN's identity
     as well as proving freshness, etc. EBU's may be embedded
     in RSVP and COPS messages.
tick[XXX]: a Kerberos ticket for which the server half of
    the ticket is encrypted in XXX's key. MN is always assumed
    to be in the client half of the ticket.

Initial Access

When the mobile node initially desires access, it must go through
a full initial access flow. This flow assumes that MN does not
have any valid Kerberos tickets cached. If it does, it may omit
the interactions with the appropriate KDC's.

The goal of this flow is to just obtain best effort access from
AR1. As such, the RSVP request is directed at AR1.

 MN        AR1         AR2      vPDP        aPDP     aKDC      hKDC   hA
========================================================================

  <=========>
    L2 estab

  ----------------------------------------------------->
    AS-REQ to get service ticket for aPDP

  <-----------------------------------------------------
    AS-REP w/ tick[aPDP]

  --------------------------------------------------------------->
    AS-REQ to get service ticket for hA

  <---------------------------------------------------------------
    AS-REP w/ tick[hA]

  --------->
    RSVP PATH w/ PO(tick[aPDP])


            -------------------->
    COPS REQ w/ PO(tick[aPDP])

                                ---------------------->
    COPS REQ w/ PO(tick[aPDP])

                                <---------------------
    COPS DEC w/ TR(tick[vPDP])

           <--------------------
    COPS DEC w/ TR(tick[AR1])

  <--------
    RSVP RESV w/ TR(tick[MN])

  ~
  MN is now admitted at AR1 and shares a secret with AR1 from the TR
  ~

 MN        AR1         AR2      vPDP        aPDP     aKDC      hKDC   hA
========================================================================

  --------------------------------------------------------------------->
    KINK CREATE SA w/ tick[hA]

  <---------------------------------------------------------------------
    KINK REPLY

  --------------------------------------------------------------------->
    BU

  <---------------------------------------------------------------------
    BU ACK

  ~
  The home agent's binding cache is now updated with forward tunneling
  established.

  Note: if the MN is already in possession of valid tickets to the aPDP
  or hA, the AS-REQ and AS-REP's in the flow can be omitted.
  ~

Intra Trust Domain Fast/Smooth Handoff

 It is assumed that AR1 and AR2 have a pre-existing security
 association.
 If they do not, a security association between the two would need to be
 established using normal IPsec keying mechanisms.

 This flow assumes that the MN is capable of transmitting and receiving
 on AR2. It may or may not still have connectivity to AR1. It is also
 assumed that AR1 and AR2 are with in the same trust domain where AR1
 can act as a PDP for AR2.





 MN        AR1         AR2      vPDP        aPDP     aKDC      hKDC   hA
========================================================================

  <=========>
    L2 estab

  ----------------------->
    RSVP PATH w/ PO(tick[hPDP]), PO(tick[AR1]), HO(AR1, AR2, EBU (AR1))

            <------------
    COPS REQ w/ PO(tick[AR1]), HO(AR1, AR2, EBU(AR1))

            ------------>
    COPS DEC w/ TR(tick [AR2]), EBU(ACK)

  <-----------------------
    RSVP RESV w/ TR(tick [MN])

 ~
  At this point, AR1 will forward any packets destined for MN's old
  CoA to AR2 and as such any packets in flight will still reach MN.

  The following two steps only occur if the MN's CoA changed
 ~
  --------------------------------------------------------------------->
    BU
  <---------------------------------------------------------------------
    BU ACK

Intra Trust Domain Fast/Smooth Handoff to a cNode with QoS

 This flow describes a fast/smooth handoff with a cNode with an
 established QoS flow. It is assumed that cNode and MN already
 have established keys between them. How they are initially
 established is outside of the scope of this document.

 It is assumed that AR1 and AR2 have a pre-existing security
 association.
 If they do not, a security association between the two would need to be
 established using normal IPsec keying mechanisms.

 This flow assumes that the MN is capable of transmitting and receiving
 on AR2. It may or may not still have connectivity to AR1. It is also
 assumed that AR1 and AR2 are with in the same trust domain where AR1
 can act as a PDP for AR2.

 MN        AR1         AR2      vPDP        aPDP     aKDC      hKDC   cN
========================================================================

  <=========>
    L2 estab

  ----------------------->
    RSVP PATH PO(tick[hPDP]), PO(tick[AR1]), HO(AR1, AR2, EBU (AR1)),
              EBU(CN)



            <------------
    COPS REQ w/ PO(tick[AR1]), HO(AR1, AR2, EBU(AR1))

            ------------>
    COPS DEC w/ TR(tick [AR2]), EBU(ACK)

 ~
  At this point, AR1 will forward any packets destined for MN's old
  CoA to AR2 and as such any packets in flight will still reach MN.
 ~

                        ----------------------------------------------->
    RSVP PATH w/ PO(tick[hPDP]), PO(tick[AR1]), EBU(CN)

 ~
  At this point, the cNode would receive the new binding and
  know that it would need to adjust any reservations toward
  MN as well. These RSVP messages are not shown here.
 ~

                        <----------------------------------------------
    RSVP RESV from cNode EBU(ACK)

  <-----------------------
    RSVP RESV w/ TR(tick [MN]), EBU(ACK)



Inter Trust Domain Handoff

In the case where AR1 and AR2 do not trust another domain's
cached policy decisions, it will necessitate another authoritative
policy decision. Note that the MN is at liberty to send as many
policy objects as it feels may be needed to expedite the decision.
Also: if the MN has local credentials it may send them as well
which would also result in a fast though not necessarily smooth
handoff.

Note that this flow is nearly identical to the initial access
flow. The only difference is that the MN sends a PO and HO for AR1.
Because AR2 and AR1 are not within the same trust domain, AR2
ignores that policy object since it is not a trusted PDP.

 MN        AR1         AR2      vPDP        aPDP     aKDC      hKDC   hA
========================================================================

  <=========>
    L2 estab

  ----------------------->
    RSVP PATH w/ PO(tick[hPDP]), PO(tick[AR1]), HO(AR1, AR2, EBU)

                        --------->
    COPS REQ w/ PO(tick[aPDP])

                                -------------->
    COPS REQ w/ PO(tick[aPDP])


                                <--------------
    COPS DEC w/ TR(tick[vPDP])

                        <---------
    COPS DEC w/ TR(tick[AR2])

  <-----------------------
    RSVP RESV w/ TR(tick[MN])

  --------------------------------------------------------------------->
    BU

  <---------------------------------------------------------------------
    BU ACK

 ~
  At this point, AR1 will forward any packets destined for MN's old
  CoA to AR2 and as such any packets in flight will still reach MN.

  The following two steps only occur if the MN's CoA changed
 ~
  --------------------------------------------------------------------->
    BU
  <---------------------------------------------------------------------
    BU ACK


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/