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

Versions: 00 01

NetLMM Working Group                                          M. Liebsch
Internet-Draft                                                     L. Le
Expires: May 16, 2008                                   NEC Laboratories
                                                              J. Abeille
                                                 Cisco Technology Center
                                                       November 13, 2007


                Route Optimization for Proxy Mobile IPv6
                draft-abeille-netlmm-proxymip6ro-01.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   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.

   This Internet-Draft will expire on May 16, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007).












Liebsch, et al.           Expires May 16, 2008                  [Page 1]


Internet-Draft            Proxy Mobile IPv6 RO             November 2007


Abstract

   The IETF is specifying a protocol for network-based localized
   mobility management, which takes basic operation for registration,
   tunnel management and de-registration into account.  This document
   specifies a protocol for route optimization in networks, which
   support network-based mobility management.  The specified protocol
   focuses on efficient set up and maintenance of a route optimized path
   between two mobile nodes and suits complex mobility scenarios as well
   as networks with multiple mobility anchors.


Table of Contents

   1.  Requirements notation  . . . . . . . . . . . . . . . . . . . .  3
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Terminology and Functional Components  . . . . . . . . . . . .  6
   4.  Protocol Operation . . . . . . . . . . . . . . . . . . . . . .  7
     4.1.  General procedure  . . . . . . . . . . . . . . . . . . . .  7
     4.2.  Route Optimization - Direct Mode . . . . . . . . . . . . .  8
       4.2.1.  RO Setup Procedure . . . . . . . . . . . . . . . . . .  8
       4.2.2.  RO Handover Procedure  . . . . . . . . . . . . . . . . 10
     4.3.  Route Optimization - Proxy Mode  . . . . . . . . . . . . . 12
       4.3.1.  RO Setup Procedure . . . . . . . . . . . . . . . . . . 12
       4.3.2.  RO Handover Procedure  . . . . . . . . . . . . . . . . 14
   5.  Message Format . . . . . . . . . . . . . . . . . . . . . . . . 17
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 18
   7.  Normative References . . . . . . . . . . . . . . . . . . . . . 19
   Appendix A.  MAG-local Route Optimization  . . . . . . . . . . . . 20
   Appendix B.  Early State Activation (ESA) Policy . . . . . . . . . 21
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
   Intellectual Property and Copyright Statements . . . . . . . . . . 23



















Liebsch, et al.           Expires May 16, 2008                  [Page 2]


Internet-Draft            Proxy Mobile IPv6 RO             November 2007


1.  Requirements notation

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].














































Liebsch, et al.           Expires May 16, 2008                  [Page 3]


Internet-Draft            Proxy Mobile IPv6 RO             November 2007


2.  Introduction

   The NetLMM WG is specifying a protocol for network-based localized
   mobility management (NetLMM), taking basic support for registration,
   de-registration and handover into account in a first protocol
   release.  The specification of extensions and optimization is for
   further study and subject for either being incorporated into future
   versions of the protocol or specified in separate documents.  In
   scope of the base protocol specification is the set up and
   maintenance of a forwarding tunnel between an MN's Mobility Access
   Gateway (MAG) and its selected Local Mobility Anchor (LMA).  Data
   packets will always traverse the MN's MAG and its LMA, irrespective
   of the location of the MN's remote communication endpoint.  Even
   though two communicating MNs might be located close to each other or
   within the same local mobility domain, packets will traverse the MNs'
   LMA(s).

   This document specifies a protocol for route optimization in networks
   which enable mobility and reachability to nodes by means of network-
   based mobility management.  Even though the concept behind the
   proposed protocol is agnostic to the details of the NetLMM protocol,
   this document focuses on the operation of the protocol with Proxy
   MIPv6 [I-D.ietf-netlmm-proxymip6] as base protocol for network-based
   mobility.

   Control for route optimization in Mobile IPv6 is assigned to MNs and
   Correspondent Nodes (CNs).  MNs can send Binding Update (BU)
   signaling to a CN to create a binding between the MN's home address
   (HoA) and its care-of address (CoA) at the CN.  [RFC3775] specifies
   the Return Routability Test procedure between the CN and the MN to
   help validate an MN's binding, as a CN might not have a security
   association (SA) with the MN.  Key concept of PMIPv6 is to relocate
   the responsibility for maintaining a node's binding on the LMA from
   the client (MN) to the functional entity MAG, which is co-located
   with the infrastructure's access routers.  To create and update a
   binding at the MN's LMA, the MAG sends a Proxy BU (PBU) to the MN's
   LMA and receives the LMA's Proxy BACK (PBACK) on behalf of the MN.
   The binding establishes a valid tunnel for routing the MN's data
   packets from the MAG to the LMA (uplink) and from the LMA to the MAG
   (downlink).  Relocating full control for route optimization from the
   client to the MAG function according to the PMIPv6 architecture is
   possible, but might not be the optimal approach.  The set up and
   maintenance of a route optimized path in network-based mobility
   scenario is considered different from client-based mobility.  This
   document focuses on the establishment of a route optimized path
   between two nodes, which are attached to the network by means of
   PMIPv6.  The set up of an optimized route between an MN's MAG and a
   CN is not considered, as it reveals the address of the MN's MAG,



Liebsch, et al.           Expires May 16, 2008                  [Page 4]


Internet-Draft            Proxy Mobile IPv6 RO             November 2007


   which can be mapped to the MN's location.  Furthermore, it might be
   against an operator's policy to reveal address information of its
   infrastructure's network nodes.  The MIPv6 Return Routability Test
   procedure is not considered either, as the two MN's MAGs might share
   an SA to protect signaling between MAGs.  An alternative approach is
   proposed to avoid relying on an SA between MAGs.

   This protocol aims at efficient set up and maintenance of a route
   optimized path between two MNs' MAGs, while taking difficult mobility
   scenarios into account.  Such scenarios comprise the set up of route
   optimization between two MNs which are registered with different
   LMAs, and the maintenance of the route optimized path in case one or
   both terminals hand over.  To coordinate the set up and maintenance
   of the route optimized path efficiently, this protocol introduces the
   function Route Optimization Controller (RO controller), which is
   assigned to LMAs.  During the set up of the route optimized path, one
   LMA is dynamically selected as active RO controller.  In case the two
   MNs are registered with different LMAs, only one LMA, which has the
   active RO controller function assigned for the associated route
   optimized path, will coordinate the maintenance of the RO path and
   the establishment of the RO states on the MAG(s) upon handover.






























Liebsch, et al.           Expires May 16, 2008                  [Page 5]


Internet-Draft            Proxy Mobile IPv6 RO             November 2007


3.  Terminology and Functional Components

   o  RO - Route Optimization

   o  RO Communication - RO focus is on data exchange between two mobile
      nodes, MN1 and MN2, which are each registered in a NetLMM domain
      (This includes the case where MN1 and MN2 are registered in two
      different domains).  Route optimized traffic goes from MN1 to
      MAG1, then from MAG1 to MAG2 and from MAG2 to MN2 as well as vice
      versa without traversing any LMA.

   o  RO Association - An association between MAG1 and MAG2, between
      which RO is set up and maintained.  To set up an association,
      signaling will be used to create RO states at each MAG.  The
      association and state information can include MN profile data.

   o  RO Setup Trigger - This function is assigned to a network entity,
      which first detects that RO can be established between the MAGs of
      two communicating MNs.

   o  RO Update Trigger - When RO has been set up between MN1 and MN2
      and one of them or even both initiate a handover, RO states need
      to be updated or established.  The relevant RO update trigger
      function is assigned to an entity, which detects that RO states
      need to be updated.

   o  RO Controller - The relevant RO controller functional entity for a
      RO communication is selected the first time RO is set up between a
      pair of MNs.  In this protocol, the relevant active RO control
      function is assigned to either MN1's or MN2's mobility anchor.
      The entity which has been selected as active RO controller remains
      anchored as controlling entity for the duration of the route
      optimized communication and the lifetime of associated RO states.


















Liebsch, et al.           Expires May 16, 2008                  [Page 6]


Internet-Draft            Proxy Mobile IPv6 RO             November 2007


4.  Protocol Operation

4.1.  General procedure

   When MN1 initiates traffic towards MN2, the traffic is routed via
   MN1's MAG and LMA (Figure 1).  Either MN1's MAG or the LMA can detect
   that a route optimized path can be set up between the two MNs.  As an
   example, detection can be based on the two MNs' IP address or the
   associated MAGs' IP address.  Accordingly, either the MAG or the LMA
   takes over the role of the RO setup trigger.  In the following
   description, the LMA will serve as RO setup trigger.  During the set
   up phase of the route optimized path, either MN1's LMA (LMA1) or
   MN2's LMA (LMA2) will be selected as active RO controller for this
   particular RO association.  In case both MNs are registered with the
   same LMA, this single LMA will serve as RO controller.  The LMA,
   which has the active RO controller function assigned, coordinates the
   set up of the route optimized path and associated signaling with the
   relevant MAG(s).  After the route optimized path has been set up
   between the two MNs' MAGs, one or both MNs might hand over to a
   different MAG.  In that case, the LMA, which serves as active RO
   controller for this particular RO association, coordinates the re-
   establishment of the RO states on the relevant MAGs.


                             Internet Backbone
                            :                  :
                            :                  :
                            |                  |
                         +----+              +----+
                         |LMA1|--------------|LMA2|
                         +----+              +----+
                            |                  |
                            |                  |
                       +----+        +---------+----+
                       |             |              |
                    +----+         +----+         +----+
                    |MAG1|         |MAG2|         |MAG3|
                    +----+         +----+         +----+
                      :              :
                    +---+          +---+
                    |MN1|          |MN2|
                    +---+          +---+


     Figure 1: Reference architecture for route optimization in NetLMM

   The protocol supports two modes of operation, the Direct Mode and the
   Proxy Mode.  In Direct Mode, the two relevant MAGs can exchange



Liebsch, et al.           Expires May 16, 2008                  [Page 7]


Internet-Draft            Proxy Mobile IPv6 RO             November 2007


   signaling to set up and maintain RO states for a particular pair of
   MNs.  This might require these MAGs to share an SA to protect
   signaling messages.  Setting up SAs between MAGs for route
   optimization is different from an SA between neighbor access routers
   to allow protection of handover related signaling.  For route
   optimization, all relevant MAGs must share an SA, independent of
   whether or not they are geographically adjacent.  This might impact
   the amount of SA-related states on each MAG.  If this is not an
   issue, the protocol's Direct Mode allows MAGs to exchange signaling
   directly.  Alternatively, the Proxy Mode can be operated, where only
   LMAs exchange signaling with MAGs to set up and maintain RO states.
   Inter-MAG signaling is not required in a system which operates the
   Proxy Mode for route optimization.  This section describes the two
   modes separately, taking initial set up as well as maintenance of a
   route optimized path in case of a handover into account.
   Furthermore, description of both modes distinguish setting up a route
   optimized path between two MNs which are registered with the same LMA
   from a scenario where both MNs are registered with different LMAs.

   This document specifies the following new conceptual messages for
   route optimization.  All messages need to be acknowledged by means of
   an associated Ack message.  Ack messages carry a status code field.

   o  RO Initiate - This message is sent from an LMA to inform another
      entity (either an LMA or a MAG, depending on the scenario) that it
      has to initiate or continue a RO procedure.  By default, the
      receiving entity should create but not activate any forwarding
      states for the route optimized path.

   o  RO Setup - This message is sent from an LMA (in the proxy mode) or
      a MAG (in the direct mode) to a MAG to activate or update RO
      forwarding states for a particular RO association.

   o  RO Report - This message is used to inform about the result of
      setting up RO states on a MAG.

   An optional extension to this route optimization protocol solves
   possible issues with out of order packets when the communication path
   of an associated pair of MNs switches from non-route optimized to
   route optimized.  The associated extension is described in
   [I-D.jaehwoon-netlmm-flush].

4.2.  Route Optimization - Direct Mode

4.2.1.  RO Setup Procedure

   In all scenarios, MN1 initiates traffic to MN2.




Liebsch, et al.           Expires May 16, 2008                  [Page 8]


Internet-Draft            Proxy Mobile IPv6 RO             November 2007


   In Figure 2, both MNs are registered with the same LMA (LMA1).  The
   LMA detects, that route optimization can be set up, hence, serves as
   RO setup trigger [T].  As both MNs are registered with the same LMA,
   LMA1 serves as active RO controller (ROC).  The LMA sends the RO
   Initiate message to MAG2.  This message carries the ID and Home
   Network Prefix of MN1, the IP address of MAG1 as well as the ID of
   MN2.  After MAG2 has acknowledged the RO Initiate message, it sends
   the RO Setup message to MAG1, carrying the ID of MN1 and MN2, as well
   as the Home Network Prefix of MN2.  MAG1 acknowledges the RO Setup
   message.  RO states are now established on MAG1 and MAG2.  The result
   of the set up is reported to the RO controller by means of a RO
   Report message.

                +----+             +----+             +----+
                |MAG1|             |LMA1|             |MAG2|
                +----+             +----+             +----+
                  |                   |                  |
                  |                  [T]                 |
                  |                 (ROC)                |
                  |                   |                  |
                  |                   |-----RO Init----->|
                  |                   |<--RO Init Ack----|
                  |                   |                  |
                  |<---------------RO Setup--------------|
                  |--------------RO Setup Ack----------->|
                  |                   |                  |
                  |                   |<---RO Report-----|
                  |                   |--RO Report Ack-->|
                  |                   |                  |



        Figure 2: RO Direct Mode - One relevant LMA in the topology

   Figure 3 illustrates the set up of a route optimized path between two
   MNs which are registered with different LMAs.  MN1 is registered with
   LMA1, MN2 is registered with LMA2.  As MN1 initiates traffic, LMA1
   detects the possibility to set up a route optimized path for this
   communication [T], but does not know the IP address of MAG2.  It
   sends a RO Initiate message to LMA2, which carries information about
   MAG1's IP address, MN1's ID and Home Network Prefix as well as the
   Home Network Prefix of MN2.  During this message handshake between
   LMA1 and LMA2, one LMA can be selected as active RO controller for
   this particular RO association.  In this example, LMA2 is selected as
   RO controller.  Further set up of RO states is similar to Figure 2.
   The only difference is that LMA2 should inform LMA1, who triggered
   route optimization, of the procedure's result, which is done by means
   of the RO Report message.



Liebsch, et al.           Expires May 16, 2008                  [Page 9]


Internet-Draft            Proxy Mobile IPv6 RO             November 2007


        +----+            +----+            +----+            +----+
        |MAG1|            |LMA1|            |LMA2|            |MAG2|
        +----+            +----+            +----+            +----+
          |                 |                  |                |
          |                [T]                 |                |
          |                 |                (ROC)              |
          |                 |                  |                |
          |                 |------RO Init---->|                |
          |                 |<---RO Init Ack---|                |
          |                 |                  |----RO Init---->|
          |                 |                  |<--RO Init Ack--|
          |<-----------------------RO Set-----------------------|
          |----------------------RO Setup Ack------------------>|
          |                 |                  |<--RO Report----|
          |                 |                  |-RO Report Ack->|
          |                 |<----RO Report----|                |
          |                 |--RO Report Ack-->|                |
          |                 |                  |                |


       Figure 3: RO Direct Mode - Two relevant LMAs in the topology

4.2.2.  RO Handover Procedure

   This section specifies the signaling to maintain RO states in a
   handover case.  Figure 4 refers to the case where both MNs are
   registered with the same LMA (LMA1).  When LMA1 receives the Proxy BU
   (PBU) from MN1's new MAG1 (nMAG1), it knows that RO states at MAGs
   need to be updated (at MAG2) and established (at nMAG1).  As LMA1
   represents the RO trigger function as well as the active RO
   controller for this RO association, LMA1 can send the RO Initiate to
   nMAG1 to initiate the establishment of RO states.  RO states on pMAG1
   might expire or be explicitly deleted with MN1's Binding Update List
   (BUL) entry.  Whereas nMAG1 established the RO states, existing
   states in MAG2 are updated through this procedure.  The remaining
   procedure is according to Figure 2.















Liebsch, et al.           Expires May 16, 2008                 [Page 10]


Internet-Draft            Proxy Mobile IPv6 RO             November 2007


       +-----+            +-----+            +----+            +----+
       |nMAG1|            |pMAG1|            |LMA1|            |MAG2|
       +-----+            +-----+            +----+            +----+
         |                   |                 |                 |
         |                   |               (ROC)               |
         |                   |                [T]                |
         |----------------- PBU- ------------->|                 |
         |<----------------PBAck --------------|                 |
         |                   |                 |                 |
         |                   |                 |                 |
         |<----------------RO Init-------------|                 |
         |---------------RO Init Ack---------->|                 |
         |                   |                 |                 |
         |                   |                 |                 |
         |-------------------------RO Setup -------------------->|
         |<----------------------RO Setup Ack--------------------|
         |                   |                 |                 |
         |                   |                 |                 |
         |----------------RO Report----------->|                 |
         |<-------------RO Report Ack----------|                 |
         |                   |                 |                 |
         |                   |                 |                 |


     Figure 4: RO Direct Mode - One relevant LMA in the topology, MN1
                                 handover

   Figure 5 illustrates the case where MN1 and MN2 are registered with
   different LMAs.  Again, MN1 initiates a handover from pMAG1 to nMAG1,
   which results in nMAG1 sending a PBU to LMA1.  In this scenario, we
   assume that LMA2 serves as active RO controller, therefore LMA1 has
   to initiate the update procedure by means of sending a RO Initiate
   message to LMA2.  Even though LMA2 is under control of the RO setup
   and maintenance, it is preferable to send the RO Initiate from LMA1
   to nMAG1, as there might be no SA established between LMA2 and nMAG1
   and such cross-signaling should be avoided in any case.  Hence, LMA2
   controls LMA1 to send the RO Initiate to nMAG1 by means of the first
   RO Initiate/Ack message handshake.  LMA1 sends a RO Initiate message
   to nMAG1 to initiate the RO Setup handshake between nMAG1 and MAG2.
   The remaining procedure is similar to Figure 3, including the
   notification of the procedure's result to the RO controller by means
   of sending a RO Report message from LMA1 to LMA2.

   Note: in the case where the RO update trigger and active RO
   controller function are on the same LMA, this one does not send a RO
   Initiate message to the other LMA, but directly sends a RO Initiate
   message to its MAG.




Liebsch, et al.           Expires May 16, 2008                 [Page 11]


Internet-Draft            Proxy Mobile IPv6 RO             November 2007


    +-----+        +-----+       +----+           +----+         +----+
    |nMAG1|        |pMAG1|       |LMA1|           |LMA2|         |MAG2|
    +-----+        +-----+       +----+           +----+         +----+
       |              |             |                |              |
       |------------PBU------------>|              (ROC)            |
       |<----------PBAck -----------|                |              |
       |              |            [T]               |              |
       |              |             |----RO Init---->|              |
       |              |             |<--RO Init Ack--|              |
       |              |             |                |              |
       |<----------RO Init----------|                |              |
       |---------RO Init Ack------->|                |              |
       |              |             |                |              |
       |              |             |                |              |
       |------------------------RO Setup--------------------------->|
       |<---------------------RO Setup Ack--------------------------|
       |              |             |                |              |
       |              |             |                |              |
       |----------RO Report-------->|                |              |
       |<-------RO Report Ack-------|                |              |
       |              |             |                |              |
       |              |             |---RO Report--->|              |
       |              |             |<-RO Report Ack-|              |
       |              |             |                |              |
       |              |             |                |              |


     Figure 5: RO Direct Mode - Two relevant LMAs in the topology, MN1
                                 handover

4.3.  Route Optimization - Proxy Mode

   In this mode, MAGs do not exchange signaling directly.  A MAG
   exchanges signaling only with the LMA, which is associated with the
   attached MN.  As a consequence, LMAs will proxy signaling messages
   between MAGs to set up and update RO states.

4.3.1.  RO Setup Procedure

   The description in this section still assumes that MN1 initiates
   traffic with MN2.  The LMA serves as RO setup trigger and controller,
   as in Direct Mode.  According to Figure 6, the LMA sends a RO
   Initiate message to MAG2 to create RO states.  The RO Initiate
   message indicates to MAG2 that the message sender (LMA1) serves as
   proxy to set up the RO communication between MAG1 and MAG2.  The
   message contains MN2's ID, MN1's ID and Home Network Prefix, as well
   as MAG1's IP address.  MAG2 acknowledges the RO Initiate with the
   associated Ack message.  Subsequently, the LMA sends a RO Setup



Liebsch, et al.           Expires May 16, 2008                 [Page 12]


Internet-Draft            Proxy Mobile IPv6 RO             November 2007


   message to MAG1 to proxy the signaling between MAG2 and MAG1.  The
   message contains MN1's ID, MN2's ID and Home Network Prefix, as well
   as MAG2's IP address.  At the reception of the RO Setup message, MAG1
   creates and activates RO states for bi-directional route optimized
   path for this particular RO association between between MAG1 and
   MAG2.  At reception of the associated Ack message, the LMA sends a RO
   Setup message to MAG2 to indicate that MAG1's RO states have been
   established and activated, as well as to activate MAG2's RO states
   for a bi-directional route optimized path.

   Note: RO states are established on MAG2 after the reception of the RO
   Initiate message.  For secure and stable operation, RO states on MAG2
   should be activated only after the reception of the RO Setup message,
   which indicates the status of MAG1's RO states.


               +----+              +----+                +----+
               |MAG1|              |LMA1|                |MAG2|
               +----+              +----+                +----+
                 |                    |                     |
                 |                   [T]                    |
                 |                  (ROC)                   |
                 |                    |                     |
                 |                    |-------RO Init------>|
                 |                    |<----RO Init Ack-----|
                 |                    |                     |
                 |<-----RO Setup------|                     |
                 |----RO Setup Ack--->|                     |
                 |                    |                     |
                 |                    |------RO Setup------>|
                 |                    |<----RO Setup Ack----|
                 |                    |                     |

        Figure 6: RO Proxy Mode - One relevant LMA in the topology

   In the scenario with two LMAs (Figure 7), LMA1 serves as RO trigger,
   whereas LMA2 is selected as active RO controller for this particular
   RO association.  As LMA1 has no information about MN2's MAG2, it
   sends the RO Initiate message to LMA2 to request setting up RO
   between MAG1 and MAG2.  LMA2 establishes RO states at MAG2 by means
   of the RO Initiate message.

   As in the previous topology with a common LMA, MAG2 acknowledges the
   RO Initiate message.  LMA2 notifies LMA1 about the created RO states
   at MAG2 by means of a RO Report handshake.  The result causes LMA1 to
   proxy the RO Setup message, which is sent to MAG1.  MAG1 has now all
   RO states set up and activated, whereas MAG2 waits for the RO Setup
   from LMA2 to activate its states according to MAG1's status.



Liebsch, et al.           Expires May 16, 2008                 [Page 13]


Internet-Draft            Proxy Mobile IPv6 RO             November 2007


        +----+            +----+            +----+            +----+
        |MAG1|            |LMA1|            |LMA2|            |MAG2|
        +----+            +----+            +----+            +----+
          |                  |                 |                |
          |                 [T]              (ROC)              |
          |                  |                 |                |
          |                  |-----RO Init---->|                |
          |                  |<---RO Init Ack  |                |
          |                  |                 |                |
          |                  |                 |----RO Init---->|
          |                  |                 |<--RO Init Ack--|
          |                  |                 |                |
          |                  |<---RO Report----|                |
          |                  |--RO Report Ack->|                |
          |                  |                 |                |
          |<----RO Setup-----|                 |                |
          |---RO Setup Ack-->|                 |                |
          |                  |                 |                |
          |                  |                 |                |
          |                  |----RO Report--->|                |
          |                  |<-RO Report Ack--|                |
          |                  |                 |                |
          |                  |                 |----RO Setup--->|
          |                  |                 |<-RO Setup Ack--|
          |                  |                 |                |


        Figure 7: RO Proxy Mode - Two relevant LMAs in the topology

4.3.2.  RO Handover Procedure

   After MN's handover, nMAG1 notifies the LMA (LMA1) about MN1's
   arrival by means of the PBU message.  LMA1 recognizes that RO states
   for this particular RO association need to be established at nMAG1
   and updated on MAG2.  As LMA1 is assigned the function of the RO
   update trigger as well as the active RO controller, it coordinates
   maintenance of the route optimized path according to Figure 8.
   Signaling sequence between nMAG1, LMA1 and MAG2 is the same as for
   the set up of RO states (Figure 6)












Liebsch, et al.           Expires May 16, 2008                 [Page 14]


Internet-Draft            Proxy Mobile IPv6 RO             November 2007


       +-----+            +-----+            +----+            +----+
       |nMAG1|            |pMAG1|            |LMA1|            |MAG2|
       +-----+            +-----+            +----+            +----+
          |                  |                 |                 |
          |                  |               (ROC)               |
          |                  |                 |                 |
          |-----------------PBU--------------->|                 |
          |<---------------PBAck---------------|                 |
          |                  |                [T]                |
          |<--------------RO Init--------------|                 |
          |-------------RO Init Ack----------->|                 |
          |                  |                 |                 |
          |                  |                 |----RO Setup---->|
          |                  |                 |<--RO Setup Ack--|
          |                  |                 |                 |
          |<-------------RO Setup--------------|                 |
          |------------RO Setup Ack----------->|                 |
          |                  |                 |                 |
          |                  |                 |                 |


      Figure 8: RO Proxy Mode - One relevant LMA in the topology, MN1
                                 handover

   In the scenario, where MN1 and MN2 are tracked by different LMAs
   (Figure 9), LMA1 recognizes the need to update the RO association and
   serves as RO update trigger.  In this scenario, we assume that LMA2
   has been selected as active RO controller for this particular RO
   association, hence LMA1 sends a RO Initiate message to LMA2, which
   coordinates the update procedure.  After having received the RO
   Initiate Ack from LMA2, LMA1 can start the RO update procedure by
   means of sending a RO Initiate message to MAG1.  The remaining
   message sequence is according to Figure 9 and the same as for the RO
   setup procedure with two LMAs (Figure 7).

   Note: in the case where the RO update trigger and active RO
   controller function are on the same LMA, this one does not send a RO
   Initiate message to the other LMA, but directly sends a RO Initiate
   message to its MAG.












Liebsch, et al.           Expires May 16, 2008                 [Page 15]


Internet-Draft            Proxy Mobile IPv6 RO             November 2007


   +-----+        +-----+        +----+           +----+          +----+
   |nMAG1|        |pMAG1|        |LMA1|           |LMA2|          |MAG2|
   +-----+        +-----+        +----+           +----+          +----+
      |              |             |                |               |
      |------------PBU------------>|              (ROC)             |
      |<----------PBAck------------|                |               |
      |              |            [T]               |               |
      |              |             |-----RO Init--->|               |
      |              |             |<--RO Init Ack--|               |
      |              |             |                |               |
      |<---------RO Init-----------|                |               |
      |--------RO Init Ack-------->|                |               |
      |              |             |                |               |
      |              |             |----RO Report-->|               |
      |              |             |<-RO Report Ack-|               |
      |              |             |                |               |
      |              |             |                |---RO Setup--->|
      |              |             |                |<-RO Setup Ack-|
      |              |             |                |               |
      |              |             |<----RO Report--|               |
      |              |             |-RO Report Ack->|               |
      |              |             |                |               |
      |<---------RO Setup----------|                |               |
      |--------RO Setup Ack------->|                |               |
      |              |             |                |               |
      |              |             |                |               |


     Figure 9: RO Proxy Mode - Two relevant LMAs in the topology, MN1
                                 handover





















Liebsch, et al.           Expires May 16, 2008                 [Page 16]


Internet-Draft            Proxy Mobile IPv6 RO             November 2007


5.  Message Format

   To suit the format of the Proxy MIPv6 messages, the three
   differential messages RO Initiate, RO Setup and RO Report as well as
   the associated Ack messages are encoded according to the message data
   encoding rules for the Mobility Header (MH) as specified in
   [RFC3775].  Messages for RO are extensions to
   [I-D.ietf-netlmm-proxymip6] and identified by the MH Type.

   Parameters being carried by any of these messages are encoded as
   message options according to the type-length-value format specified
   in [RFC3775].  The following message option is specified for this
   protocol: MAG IP Address Option.

   Details about the message and message option format are t.b.d.

   Note: As an option to the RO protocol's direct mode, a Proxy BU
   message handshake can be used to substitute the RO Setup message
   handshake between MAGs.  In this case, the RO Initiate message from
   an LMA serves as trigger to release the PBU to establish RO states on
   MAGs according to the protocol operation described in Section 4.2.






























Liebsch, et al.           Expires May 16, 2008                 [Page 17]


Internet-Draft            Proxy Mobile IPv6 RO             November 2007


6.  Security Considerations

   Security threats for route optimization in network-based mobility
   management comprise the danger of unauthorized set up or redirect of
   an established forwarding path by a malicious node.  Signaling
   messages of this protocol between a MAG and an LMA as well as between
   LMAs must be authenticated by means of IPsec [RFC4301].  The use of
   IPsec between an LMA and a MAG follows [I-D.ietf-netlmm-proxymip6].

   Protection of signaling messages between an LMA and a MAG uses the
   mechanisms of Encapsulating Security Payload (ESP) [RFC4303] in
   transport mode with mandatory data origin authentication by means of
   a non-null payload authentication algorithm.  The use of encryption
   is optional.  The same requirements apply to signaling between LMAs
   as well as between MAGs.  In particular, if the network which
   interconnects two LMAs and/or two MAGs is not trusted, the use of
   encryption is recommended to support confidentiality protection
   between LMAs and between MAGs respectively.

   In case setting up a security association between MAGs appears
   difficult, the protocol's proxy mode allows secure operation without
   mandating such security association.

   In case RO is established between two MNs which are registered with
   different LMAs, the proposed RO protocol avoids direct signaling
   between one MN's LMA and the other MN's MAG.  Instead, MAGs exchange
   signaling only with LMAs which maintain a registration for attached
   MNs.  This avoids dependency on an existing security association
   between all possible MAG-LMA-pairs.






















Liebsch, et al.           Expires May 16, 2008                 [Page 18]


Internet-Draft            Proxy Mobile IPv6 RO             November 2007


7.  Normative References

   [I-D.ietf-netlmm-proxymip6]
              Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
              and B. Patil, "Proxy Mobile IPv6",
              draft-ietf-netlmm-proxymip6-07 (work in progress),
              November 2007.

   [I-D.jaehwoon-netlmm-flush]
              Lee, J., "Flushing Mechanism for Routing Optimization in
              PMIPv6", draft-jaehwoon-netlmm-flush-00 (work in
              progress), June 2007.

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

   [RFC3775]  Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
              in IPv6", RFC 3775, June 2004.

   [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
              Internet Protocol", RFC 4301, December 2005.

   [RFC4303]  Kent, S., "IP Encapsulating Security Payload (ESP)",
              RFC 4303, December 2005.



























Liebsch, et al.           Expires May 16, 2008                 [Page 19]


Internet-Draft            Proxy Mobile IPv6 RO             November 2007


Appendix A.  MAG-local Route Optimization

   In some scenarios, both MNs could be attached to the same MAG.  The
   MNs can be registered to the same LMA or two different LMAs.  In this
   case, the most efficient path is to route the traffic from MN1 to MN2
   directly via the MAG, without going through the LMA(s).

   Establishing this direct path could be done as part of the PMIP base
   operation as it has been discussed in the NetLMM Working Group.
   However, if it is so, and if one MN hands off, RO states would have
   to be installed after the handover.  We believe that it is more
   efficient and consistent to install the optimized path as part of a
   RO service and treat the handover case with the RO handover
   procedures described in Section 4.





































Liebsch, et al.           Expires May 16, 2008                 [Page 20]


Internet-Draft            Proxy Mobile IPv6 RO             November 2007


Appendix B.  Early State Activation (ESA) Policy

   In the procedures described in Section 4, the MAGs are provided with
   the relevant information needed to setup RO one after the other.
   Additionally, the MAG being contacted first only activates the states
   when it receives the notification of the success of the RO setup on
   the second MAG.  As an example, in Figure 2, the first MAG contacted,
   MAG2, activates the RO states after having received and processed the
   RO setup Ack from MAG1.  In a similar fashion, in Figure 6, MAG2
   activates the RO states after having received and processed the RO
   Setup from LMA1.

   This approach avoids to start using the RO path in the case where the
   RO setup failed on either MAG.  However, the setup of the RO path can
   be slightly optimized at the cost of suppressing this mechanism: the
   first MAG could create and activate the RO states without waiting for
   the notification concerning the second MAG.  We call this enhancement
   Early State Activation.

   As an example in Figure 2, MAG2 could activate the RO states after
   having received and processed the RO Initiate message from LMA1.  In
   a similar fashion in Figure 6, MAG2 could activate the RO states
   after having received and processed the RO Initiate message from
   LMA1.

   In case ESA is used, additional mechanisms need to be defined to
   handle RO setup failure.  Indeed, the second MAG contacted could be
   unable to create the states for some reason, while the RO states and
   forwarding would already be active on the other MAG.






















Liebsch, et al.           Expires May 16, 2008                 [Page 21]


Internet-Draft            Proxy Mobile IPv6 RO             November 2007


Authors' Addresses

   Marco Liebsch
   NEC Laboratories
   Kurfuersten-Anlage 36
   69115 Heidelberg,
   Germany

   Phone: +49 6221 4342146
   Email: liebsch@nw.neclab.eu


   Long Le
   NEC Laboratories
   Kurfuersten-Anlage 36
   69115 Heidelberg,
   Germany

   Phone: +49 6221 4342224
   Email: le@nw.neclab.eu


   Julien Abeille
   Cisco Technology Center
   Av. des Uttins 5
   1180 Rolle,
   Switzerland (FR)

   Phone: +41 21 822 1696
   Email: jabeille@cisco.com





















Liebsch, et al.           Expires May 16, 2008                 [Page 22]


Internet-Draft            Proxy Mobile IPv6 RO             November 2007


Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Liebsch, et al.           Expires May 16, 2008                 [Page 23]


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