NETEXT Working Group                                      A. Dutta (Ed.)
Internet-Draft                                                    S. Das
Expires: April 23, 2010                                        Telcordia
                                                               H. Yokota
                                                               KDDI Labs
                                                                T. Chiba
                                                                 KDDILab
                                                          H. Schulzrinne
                                                          Columbia Univ.
                                                        October 20, 2009


          ProxyMIP Extension for Inter-MAG Route Optimization
                      draft-dutta-netext-pmipro-00

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and 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 April 23, 2010.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.



Dutta (Ed.), et al.      Expires April 23, 2010                 [Page 1]


Internet-Draft           PMIP Route Optimization            October 2009


Abstract

   This draft describes a light weight route optimization technique that
   helps to optimize the media path between two communicating nodes when
   Proxy MIP is used as the mobility protocol.  This routing
   optimization technique is most useful when the two communicating
   hosts are away from home and need to communicate with each other
   using an optimized path.  It takes advantage of the data packet
   between LMA and MAG to set up the optimized data path between the
   communicating hosts.  This route optimization technique is applicable
   to both the intra-LMA and inter-LMA scenarios.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Applicable Scenarios for Route Optimization  . . . . . . . . .  7
   4.  Route Optimization Techniques  . . . . . . . . . . . . . . . . 11
     4.1.  Intra-LMA route optimization . . . . . . . . . . . . . . . 11
       4.1.1.  Initial State  . . . . . . . . . . . . . . . . . . . . 11
       4.1.2.  Route Optimization after handoff . . . . . . . . . . . 14
     4.2.  Inter-LMA route optimization . . . . . . . . . . . . . . . 17
       4.2.1.  Initial state  . . . . . . . . . . . . . . . . . . . . 17
       4.2.2.  Route optimization after handoff . . . . . . . . . . . 19
   5.  Message Format . . . . . . . . . . . . . . . . . . . . . . . . 21
     5.1.  Correspondent Binding Update Message . . . . . . . . . . . 21
     5.2.  Correspondent Binding Acknowledgement  . . . . . . . . . . 22
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 23
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 24
   8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 25
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 26
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 26
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27
















Dutta (Ed.), et al.      Expires April 23, 2010                 [Page 2]


Internet-Draft           PMIP Route Optimization            October 2009


1.  Introduction

   Wireless Service Providers (WISPs) strive to provide secured and
   seamless connectivity to the roaming users.  When a mobile is
   subjected to repeated handoff, quality of existing communication gets
   degraded due to delay and packet loss.  There are several transition
   events during the handoff, such as discovery, configuration,
   authentication, security association, binding update and media
   redirection that contribute to the handoff delay and the associated
   packet loss.  This specific route optimization technique reduces the
   delay due to media delivery by reducing the media traversal path
   between the communicating hosts.

   In order to reduce the delay due to binding update and associated
   one-way-delay of the media, when a mobile's movement is confined to a
   specific domain, various local mobility management protocols have
   been designed.  These include Cellular IP, HAWAII, IDMP, HMIPv6 etc.
   NETLMM working group within IETF has recommended a set of goals and
   host requirements to support localized mobility [RFC4830], [RFC4831],
   [RFC4832].  Based on these goals, IETF has currently designed Proxy
   MIPv6 protocol [RFC5213] that helps to reduce the delay due to long
   binding update.  It takes much of the burden away from the mobile and
   puts it on the wired access routers within the network that are
   called Media Access Gateway (MAG).  MAG is equipped with proxy
   mobility agent (PMA) that sends the binding update to the home agents
   on behalf of the mobiles.  Each mobile is anchored with a certain MAG
   until it hands off to a new MAG.  The PMIPv6-based mobility protocol
   is preferred when mobility is confined within a domain and wireless
   service providers do not want to overload the mobile nodes stack by
   setting up a tunnel between the mobile and the LMA.  A tunnel is not
   desirable on the mobile node because it adds extra processing and
   bandwidth constraints to the wireless hop.

   Although Proxy Mobile IP provides optimization compared to other
   global mobility protocols, it still needs improvement in certain
   areas such as route optimization.  Route optimization reduces the
   delay due to media delivery between the two communicating mobiles by
   reducing the traversal distance of the media packets between the
   communicating hosts.  Some of the requirements for route optimization
   are mentioned in [I-D.jeong-netlmm-pmipv6-roreq].  There are also few
   proposals that have discussed route optimization for Proxy MIPv6,
   [I-D.abeille-netlmm-proxymip6ro] and [I-D.qin-netlmm-pmipro].  These
   mechanisms either depend on the MIPv6 route optimization procedures
   or introduce a heavy weight route setup procedure to obtain the
   desired optimization.  In this draft we describe a lightweight route
   optimization technique for PMIP that will further improve the
   effectiveness of PMIP for both intra-domain and inter-domain
   movement.  This technique takes advantage of the data packet and sets



Dutta (Ed.), et al.      Expires April 23, 2010                 [Page 3]


Internet-Draft           PMIP Route Optimization            October 2009


   up the route optimization between the mobile hosts.


















































Dutta (Ed.), et al.      Expires April 23, 2010                 [Page 4]


Internet-Draft           PMIP Route Optimization            October 2009


2.  Terminology


   Binding Cache Entry:  A binding cache in the network entity that
      provides the route information about a communicating node.  BCE
      can exist either within an LMA or in the MAG.


   Route Optimization:  Route optimization is a mechanism by which the
      data path is from CN to MN is optimized.


   Proxy Binding Update:  A procedure to update the identifier of the
      mobile by a third party.  In the context of PMIPv6, MAG sends the
      binding update to LMA on behalf of the mobile.


   Local Mobility Agent (LMA):  Local mobility agent is the local home
      agent that is responsible to maintain the binding cache of the
      mobile when the mobile's movement is confined to a domain.  LMA
      actually does the job of a Home Agent, and thus can be used
      interchangeably in the document.


   Media Access Gateway:  MAG is the first hop access router that is
      equipped with the Proxy Mobility Agent (PMA).  MAG sends the proxy
      binding update on behalf of the mobile.  MAG stores the binding
      cache entry created by Correspondent Binding Update (CBU) message,
      so that it can forward the traffic to the neighboring MAG without
      sending it to HA (LMA).  MAG has been used interchangeably with
      AGW in the document.


   Access Gateway (AGW):  AGW is the first hop access router that is
      equipped with the Proxy Mobility Agent (PMA).  AGW sends the proxy
      binding update on behalf of the mobile.  AGW been used
      interchangeably with MAG in this draft.


   Proxy Mobility Agent (PMA):  PMA is the proxy mobility agent that
      resides in each of the access routers that are within a mobility
      domain.  PMA helps to send proxy binding update to LMA on behalf
      of the mobile.








Dutta (Ed.), et al.      Expires April 23, 2010                 [Page 5]


Internet-Draft           PMIP Route Optimization            October 2009


   Correspondent Binding  Update:

      Binding update message that updates the route in the neighboring
      MAGs for route optimization.  This CBU update can be between the
      LMA and MAG or between the MAGs.  This helps to update the route
      cache on the AGWs, so that they can route the packet based on
      mobile's destination.


   Correspondent Binding  Cache:

      Correspondent Binding Cache (CBC) is formed at the MAGs when
      Correspondent Binding Update (CBU) message is received from the
      LMA or other MAG.  CBC usually has associated timer that helps it
      to expire after a while.




































Dutta (Ed.), et al.      Expires April 23, 2010                 [Page 6]


Internet-Draft           PMIP Route Optimization            October 2009


3.  Applicable Scenarios for Route Optimization

   In this section, two PMIP-based scenarios are described where the
   route optimization technique can be applied.  This can primarily be
   divided as Intra-LMA and Inter-LMA.  The proposed route optimization
   technique can be applied to both of these scenarios.

   Figure 1 shows a general PMIP architecture with all the PMIPv6
   components.  In this case the MAGs do not need to be adjacent to each
   other but can be connected to a core network and thus can be few hops
   away.  Similarly, MAG and LMA also do not need to be adjacent.  Route
   optimization technique offers the best advantage when the LMA is far
   way from the communicating hosts.






































Dutta (Ed.), et al.      Expires April 23, 2010                 [Page 7]


Internet-Draft           PMIP Route Optimization            October 2009


                             +-----------+
                             |           |
                             |   LMA     |
                             |           |
                             +-----|-----+
                                   |
                                   |
                                   |
                                   |
                                   |
                              -----|-----
                           ///           \\\
                         //                 \\
                         |                   |
                        |      BACKBONE      |
                         |      Network      |
                         /\                 \/
                        /  \\\           /// \
                       /      -----|-----     \
                      /            |           \
                     /             |            \
                    /              |             \
                   /               |              \
                  /                |               \
           +-----------+     +----------+      +---------+
           |           |     |          |      |         |
           |    MAG1   |     |  MAG2    |      |MAG3     |
           |           |     |          |      |         |
           +-----------+     +----------+      +---------+



              +-----+        +------+          +-------+
              |     |        |      |          |       |
              | MN1 |        | MN2  |--------->| MN2   |
              +-----+        +------+          +-------+


                       Figure 1: Intra LMA Scenario

   Figure 2 shows a scenario where both the mobiles are in two different
   PMIP domains.  MAG1, MAG2, MAG3 are under LMA1 and MAG4, MAG5 and
   MAG6 are under LMA2.  In this case, route optimization needs to take
   place when the mobile is in under MAG4 and then it makes a movement
   to MAG5.






Dutta (Ed.), et al.      Expires April 23, 2010                 [Page 8]


Internet-Draft           PMIP Route Optimization            October 2009


                              -------
                           ///       \\\
                          |             |
                          /   Core      \
                        // \\\       /// \\
     PMIP domain 1     /      -------      \       PMIP domain 2
                     //                     \
                    /                        \\
                  //                           \
            +----/----+                     +---\-----+
            |         |                     |         |
            |         |                     |         |
            |  LMA1   |                     | LMA2    |
            |         |                     |         |
            +----|----+                     +----|----+
                 |                               |
                 |                               |
                 |                               |
                 |                               |
                 |                               |
               --|----                          -|-----
            ///       \\\                   ///       \\\
           |   Core      |------------------|   Core      |
           |             |                  |             |
            \\\       ///                    \\\       ///
              /---|---\                        /---|---\
             /    |    \                      /    |    \
            /     |     \                    /     |     \
           /      |      \                  /      |      \
          /       |       \                /       |       \
      +------+  +-----+   +-----+       +-----+  +-----+  +----+
      |      |  |     |   |     |       |     |  |     |  |    |
      | MAG1 |  |MAG2 |   |MAG3 |       |MAG4 |  |MAG5 |  |MAG6|
      +------+  +-----+   +-----+       +-----+  +-----+  +----+

                                        +----+     +----+
        +----+                          |    |     |    |
        |    |                          |MN2 +---->|MN2 |
        | MN1|                          +----+     +----+
        +----+




                       Figure 2: Inter LMA scenario

   In the next section, the route optimization technique and associated
   flows are described for the hosts when they operate within a single



Dutta (Ed.), et al.      Expires April 23, 2010                 [Page 9]


Internet-Draft           PMIP Route Optimization            October 2009


   and multiple PMIP domains.


















































Dutta (Ed.), et al.      Expires April 23, 2010                [Page 10]


Internet-Draft           PMIP Route Optimization            October 2009


4.  Route Optimization Techniques

   In this section, a light weight route optimization technique for
   PMIPv6 is described that can be applied it to both Intra-LMA and
   Inter-LMA scenarios.  This route optimization technique takes
   advantage of the initial data packet to set the route optimization
   without the need for any additional route setup procedures.

4.1.  Intra-LMA route optimization

   In this section intra-LMA scenarios are described.  Route
   optimizations for data between MN1 and MN2 in both directions are
   illustrated.

4.1.1.  Initial State

   In this section several call flows for intra-LMA route optimization
   are discussed.

4.1.1.1.  Route Optimization from MN1 to MN2

   Figure 3 shows the flows associated with the route optimization when
   a single LMA is used.  It shows the route optimization scenario when
   the mobile is in the initial stage and has not moved.  Initially, MN1
   is under MAG1 and MN2 is under MAG2, but MN2 moves to MAG3 when the
   communication session is active.

























Dutta (Ed.), et al.      Expires April 23, 2010                [Page 11]


Internet-Draft           PMIP Route Optimization            October 2009


         +-----+      +-----+      +-----+      +-----+       +-----+
         |     |      |     |      |     |      |     |       |     |
         | MN1 |      | MN2 |      |MAG1 |      |MAG2 |       | LMA |
         +--+--+      +--+--+      +--+--+      +--+--+       +--+--+
            | network attachment      |   ProxyBU(MN1,MAG1)      |
            |<----------------------->|<------------------------>|
            |            |            |            |             |
            |            |   network attachment    |             |
            |            |<----------------------->|------------>|
            |            |            |            |             |
            |            |            |            |             |
            |     data(MN1->MN2)      |            |             |
            |------------+----------->|            |             |
            |            |            |            |             |
            |            |            |    data(MN1->MN2)        |
            |            |            |------------------------->|
            |            |            |            |             |
            |            |            |  CB update(MN2, MAG2)    |
            |            |            |<-------------------------|
            |            |            |            |             |
            |            |            |            |data(MN1->MN2)
            |            |            |            |<------------|
            |            |            |            |             |
            |            |     data(MN1->MN2)      |             |
            |            |<------------------------|             |
            |            |            |            |             |
            |    data (MN1->MN2)      |            |             |
            |------------------------>|            |             |
            |            |            |            |             |
            |            |            |data(MN1->MN2)            |
            |            |            |----------->|             |
            |            |            |            |             |
            |            |      data(MN1->MN2)     |             |
            |            |<------------------------|             |
            |            |            |            |             |
            |            |            |            |             |

         Figure 3: Route optimization in Single LMA:Initial State

   Path optimization from MN1 to MN2 are described here.  Before the
   handover takes place, MN1 attaches to MAG1 (MAG1) and then the Proxy
   Mobility Agent within MAG1 sends a binding update to the LMA on
   behalf of MN1.  Similarly, MN2 connects to MAG2 (PMA2), that triggers
   the proxy-BU to the LMA on behalf of MN2.  We then show the
   optimization procedure.  First packet from MN1 to MN2 is tunneled to
   the LMA.  As soon as the LMA gets this packet, it knows how to
   forward packet to MAG2, but at the same time, it also sends a CB
   Update (CBU) to MAG1 notifying that MAG2 is the PMA for MN2.  On



Dutta (Ed.), et al.      Expires April 23, 2010                [Page 12]


Internet-Draft           PMIP Route Optimization            October 2009


   receiving the CBU, MAG1 keeps a cache that maps MAG2 with MN2.  Thus,
   any subsequent packet from MN1 destined to MN2 gets intercepted by
   MAG1 and is forwarded to MAG2, instead of being forwarded to the LMA.
   Trajectory of the optimized packet looks like, MN1->MAG1->MAG2->MN2
   instead of MN1->MAG1->LMA->MAG2->MN2, thus optimizing the media route
   between MN1 and MN2.

4.1.1.2.  Optimization from MN2 to MN1

   Similarly, Figure 4 shows the path optimization from MN2 to MN1 when
   the MN2 is in the initial stage and has not handed over yet.  This
   illustrates how this route optimization technique can be applied to
   optimize media traffic in either direction.






































Dutta (Ed.), et al.      Expires April 23, 2010                [Page 13]


Internet-Draft           PMIP Route Optimization            October 2009


         +-----+      +-----+      +-----+      +-----+       +------+
         |     |      |     |      |     |      |     |       |      |
         | MN1 |      | MN2 |      |MAG1 |      |MAG2 |       |  LMA |
         +--+--+      +--+--+      +--+--+      +--+--+       +---+--+
            |            |            |            |              |
            |            |     data(MN2->MN1)      |              |
            |            |------------------------>|              |
            |            |            |            |data(MN2->MN1)|
            |            |            |            |------------->|
            |            |            |            |              |
            |            |            |           CB update(MN1,MAG1)
            |            |            |            |<-------------|
            |            |            |            |              |
            |            |            |      data(MN2->MN1)       |
            |            |            |<--------------------------|
            |     data (MN2->MN1)     |            |              |
            |<------------------------|            |              |
            |           |             |            |              |
            |           |             |            |              |
            |           |     data(MN2->MN1)       |              |
            |           +------------------------->|              |
            |           |             |            |              |
            |           |             |            |              |
            |           |             |data(MN2->MN1)             |
            |           |             |<-----------|              |
            |           |             |            |              |
            |      data(MN2->MN1)     |            |              |
            |<------------------------|            |              |
            |           |             |            |              |
            |           |             |            |              |


               Figure 4: Route optimization from MN2 to MN1

4.1.2.  Route Optimization after handoff

   In this section, we illustrate how the route optimization takes place
   after the mobile moves to another AGW (MAG3) under the same LMA
   (LMA1).  We consider the media delivery from both MN1 to MN2 and
   vice-versa.

4.1.2.1.  Route optimization from MN1 to MN2

   In this section, we show how the media route is optimized from MN1 to
   MN2, after MN2 moves from its current location.






Dutta (Ed.), et al.      Expires April 23, 2010                [Page 14]


Internet-Draft           PMIP Route Optimization            October 2009


       +-----+    +-----+    +-----+    +-----+    +-----+    +-----+
       |     |    |     |    |     |    |     |    |     |    |     |
       | MN1 |    | MN2 |    |MAG1 |    |MAG2 |    |MAG3 |    | LMA |
       +--+--+    +--+--+    +--+--+    +--+--+    +--+--+    +--+--+
          |          |  network attachment (handover) | proxy-BU |
          |          |<------------------------------>|--------->|
          |          |          |          |          |          |
          |          |          |          |      CB update(MN2,MAG3)
          |          |          |          |<--------------------|
          |          |          |          |          |          |
          |  data(MN1 -> MN2)   |          |          |          |
          |-------------------->|          |          |          |
          |          |          |          |          |          |
          |          |          |data(MN1->MN2)       |          |
          |          |          |--------->|          |          |
          |          |          |          |          |          |
          |          |          |CB update(MN2,MAG3)  |          |
          |          |          |<---------|          |          |
          |          |          |          |          |          |
          |          |          |          |data(MN1->MN2)       |
          |          |          |          |--------->|          |
          |          |          |          |          |          |
          |          |          data(MN1->MN2)        |          |
          |          |<-------------------------------|          |
          |          |          |          |          |          |
          |    data(MN1->MN2)   |          |          |          |
          |-------------------->|          |          |          |
          |          |          |          |          |          |
          |          |          |   data(MN1->MN2)    |          |
          |          |          |-------------------->|          |
          |          |          |          |          |          |
          |          |         data(MN1->MN2)         |          |
          |          |<-------------------------------|          |
          |          |          |          |          |          |
          |          |          |          |          |          |

          Figure 5: Single LMA: Route  Optimization after handoff

   Figure 5 shows the flow when MN2 makes a handover from MAG2 to MAG3.
   It shows the route optimization procedure and optimized route from
   MN1 to MN2 after MN2 hands over to a new PMA such as MAG3.  In this
   case, MN2 attaches with MAG3 and sends a proxy BU to LMA.  At that
   point, LMA immediately sends a Correspondent Binding Update to MAG2,
   since the LMA has the knowledge of MAG2.  MAG2 in turn sends a proxy
   BU to MAG1 telling that MN2 is under MAG3.  Thus, both MAG1 and MAG2
   are made aware of the fact that MN2 is currently connected to MAG3.
   During this procedure if any data from MN1 destined to MN2 arrives at
   MAG1, MAG1 forwards it to MAG2 which in turn forwards it to MAG3.



Dutta (Ed.), et al.      Expires April 23, 2010                [Page 15]


Internet-Draft           PMIP Route Optimization            October 2009


   MAG3 finally forwards it MN2.  But once the route optimization
   procedure is over, any data destined from MN1 to MN2 gets intercepted
   by MAG1 and then directly gets forwarded to MAG3 which forwards it
   again to MN2.

4.1.2.2.  Route Optimization from MN2 to MN1

   In this section, we show how data path is optimized between MN2 and
   MN1 after the MN2 has handed over to MAG3 during communication
   session.


       +-----+    +-----+    +-----+    +-----+    +-----+    +-----+
       |     |    |     |    |     |    |     |    |     |    |     |
       | MN1 |    | MN2 |    |MAG1 |    |MAG2 |    |MAG3 |    | LMA |
       +--+--+    +--+--+    +--+--+    +--+--+    +--+--+    +--+--+
          |          |          |          |          |          |
          |          |          |          |          |          |
          |          |          |data (MN2->MN1)      |          |
          |          |------------------------------->|          |
          |          |          |          |          data(MN2->MN1)
          |          |          |          |          |--------->|
          |          |          |          |          |          |
          |          |          |          |       CB update(MN1,MAG1)
          |          |          |          |          |<---------|
          |          |          |          |          |          |
          |          |          |          |          |          |
          |          |          |data (MN2->MN1)      |          |
          |          |          |<-------------------------------|
          |  data(MN2->MN1)     |          |          |          |
          |<--------------------|          |          |          |
          |          |          |          |          |          |
          |          |          |data (MN2->MN1)      |          |
          |          |------------------------------->|          |
          |          |          |          |          |          |
          |          |          |     data(MN2->MN1)  |          |
          |          |          |<--------------------|          |
          |data (MN2->MN1)      |          |          |          |
          |<--------------------|          |          |          |
          |          |          |          |          |          |


               Figure 6: Call Flow  for data path MN2 to MN1

   Figure 6 shows the route optimization procedure when the data is
   destined from MN2 to MN1 after the handover.  After the route
   optimization is over, data from MN2 destined to MN1 gets picked up by
   MAG3 which finally sends to the MAG1 to be delivered to MN1.  During



Dutta (Ed.), et al.      Expires April 23, 2010                [Page 16]


Internet-Draft           PMIP Route Optimization            October 2009


   the route optimization procedure, however the first packet gets
   routed via LMA and is subjected to little delay.  These techniques
   thus avoid the route from LMA to AGWs (MAGs) and forward the traffic
   from one AGW (MAG) to another AGW (MAG).  However the first packet is
   not subjected to route optimization.

4.2.  Inter-LMA route optimization

4.2.1.  Initial state

   In this section, we describe the route optimization procedure when
   the communicating mobiles are under two different LMA domains.
   Figure 7 shows a typical inter-LMA handoff procedure.  Initially, the
   mobile is anchored at MAG1 (MAG1) that is under LMA1, and MN2 is
   anchored at MAG4 which is under LMA2.  First packet from MN1 to MN2
   traverses via LMA1 and LMA2, and gets delivered to MN2.  When the
   first packet is traversed, LMA2 sends Correspondent Binding Update
   message to LMA1, LMA1 in turn sends it back to MAG1 to update the
   binding cache entry.  At this point MAG1 keeps a cache entry for MN2.
   Thus any subsequent packet does not travel via LMA1 and LMA2 any more
   but is forwarded from MAG1 to MAG4 where the mobile resides.  Thus,
   any further data packet during this communication session is
   optimized until the mobile moves away from MAG4.




























Dutta (Ed.), et al.      Expires April 23, 2010                [Page 17]


Internet-Draft           PMIP Route Optimization            October 2009


       +-----+    +-----+    +-----+    +-----+   +-----+    +-----+
       |     |    |     |    |     |    |     |   |     |    |     |
       | MN1 |    |MAG1 |    |LMA1 |    | MN2 |   | MAG4|    | LMA2|
       +--+--+    +--+--+    +--+--+    +--+--+   +--+--+    +--+--+
          |          |          |          |         |          |
          |Network   |          |          |         |          |
          |Attachment|          |          |         |          |
          |<-------->|          |          |         |          |
          |          |Proxy-BU(MN1,MAG1)   |Network  |          |
          |          |--------->|          |Attachment          |
          |          |          |          |<------->|          |
          |          |          |          |        Proxy-BU(MN2,MAG2)
          |          |          |          |         |--------->|
          |          |          |          |         |          |
          |   data (MN1->MN2)   |          |         |          |
          |-------------------->|          |         |          |
          |          |          |          |         |          |
          |          |          |          |data (MN1->MN2)     |
          |          |          |------------------------------>|
          |          |          |          |         |          |
          |          |          |          |         |data(MN1->MN2)
          |          |          |          |         |<---------|
          |          |          |          |         |          |
          |          |          |          |data(MN1->MN2)      |
          |          |          |          |<--------|          |
          |          |          |          |         |          |
          |          |          |    CB update (MN2,MN1,MAG4)   |
          |          |          |<------------------------------|
          |          |          |          |         |          |
          |          |CB update(MN2,MAG4)  |         |          |
          |          |<---------|          |         |          |
          |          |          |          |         |          |
          |data(MN1->MN2)       |          |         |          |
          |--------->|          |          |         |          |
          |          |          |          |         |          |
          |          |          |data(MN1->MN2)      |          |
          |          |------------------------------>|          |
          |          |         |          |          |          |
          |          |         |          |data(MN1->MN2)       |
          |          |         |          |<---------|          |
          |          |         |          |          |          |
          |          |         |          |          |          |

          Figure 7: Inter-LMA route  optimization before handoff







Dutta (Ed.), et al.      Expires April 23, 2010                [Page 18]


Internet-Draft           PMIP Route Optimization            October 2009


4.2.2.  Route optimization after handoff

   This section shows the route optimization procedure after the mobile
   has handed over to MAG5 that is under LMA2.  Figure 8 shows the call
   flow of the route optimization procedure.  As soon as the mobile gets
   connected to MAG5, LMA2 gets notified and it sends a CB update to
   MAG4 notifying that the mobile is under MAG5.  Thus the first packet
   after the handover still flows from MAG1 to MAG4 that forwards this
   packet to MAG5, MAG5 in turn delivers the packet to MN2.  As it is
   shown the path is not optimized.  At this time, MAG4 notifies MAG1
   about the existence of MN2 under its attachment.  Thus, any
   subsequent packet from MN1 and MN2 flows using the route optimized
   path, MN1->MAG1->MAG5->MN2.






































Dutta (Ed.), et al.      Expires April 23, 2010                [Page 19]


Internet-Draft           PMIP Route Optimization            October 2009


    +-----+   +-----+   +-----+   +-----+   +-----+   +-----+   +-----+
    |     |   |     |   |     |   |     |   |     |   |     |   |     |
    | MN1 |   | MAG1|   |LMA1 |   |MN2  |   |MAG4 |   |MAG5 |   |LMA2 |
    +--+--+   +--+--+   +--+--+   +--+--+   +--+--+   +--+--+   +--+--+
       |         |         |         |         |         |         |
       |         |         |         |         |         |         |
       |         |         |         |Network Attachment (handover)|
       |         |         |         |------------------>|         |
       |         |         |         |         |         |         |
       |         |         |         |         |         |Proxy-BU |
       |         |         |         |         |         |-------->|
       |         |         |         |         |         |         |
       |         |         |         |         | CB update(MN2,MAG5)
       |         |         |         |         |<------------------|
       |         |         |         |         |         |         |
       |data(MN1->MN2)     |         |         |         |         |
       |-------->|         |         |         |         |         |
       |         |        data (MN1->MN2)      |         |         |
       |         |---------------------------->|         |         |
       |         |         |         |         |         |         |
       |         |         |         |         |data(MN1->MN2)     |
       |         |         |         |         |-------->|         |
       |         |         |         |         |         |         |
       |         | CB update(MN2,MAG5,MN1)     |         |         |
       |         |<----------------------------|         |         |
       |         |         |         |         |         |         |
       |         |         |         | data (MN1->MN2)   |         |
       |         |         |         |<------------------|         |
       |         |         |         |         |         |         |
       |data(MN1->MN2)     |         |         |         |         |
       |-------->|         |         |         |         |         |
       |         |         |  data(MN1->MN2)   |         |         |
       |         |-------------------------------------->|         |
       |         |         |         |         |         |         |
       |         |         |         |   data(MN1->MN2)  |         |
       |         |         |         |<------------------|         |
       |         |         |         |         |         |         |
       |         |         |         |         |         |         |

           Figure 8: Inter-LMA route  optimization after handoff

   It is to be noted that Inter-LMA CBU needs to carry the IP address of
   the source and destination hosts in addition to the address of source
   MAG.  This is needed as the LMA1 needs to determine which MAG it
   needs to send the CBU back.  Thus, new mobility option type needs to
   be added to the CBU message.





Dutta (Ed.), et al.      Expires April 23, 2010                [Page 20]


Internet-Draft           PMIP Route Optimization            October 2009


5.  Message Format

   In this section, we describe the message format for the Correspondent
   Binding Update (CBU) message.

5.1.  Correspondent Binding Update Message

   In order to make the optimization technique light weight and
   compatible with the existing Binding Update messages, a slight
   extension of the existing Proxy Binding Update method is proposed to
   take care of route optimization.  In order to differentiate
   Correspondent Binding Update (CBU) message from the regular Proxy
   Binding Update (PBU), a new flag "C" is suggested to be added in the
   existing BU message.  Also, Inter-LMA CBU needs to include additional
   addresses such as the source address, destination address and
   destination MAG address.  Thus, new mobility option may type need to
   be defined to carry these IP address prefix (MN-Prefix, CN-Prefix)
   and MAG address.  Alternatively, MAG address may be contained in
   Alternate care-of-Address option.  These prefixes may also be sent
   using HNP option as well.  A sample message format is shown in figure
   9.


       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

                                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                      |              Sequence #       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
       |A|H|L|K|M|R|P|C|  Reserved    |           Lifetime            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
       |                                                              |
       .                                                              .
       .                   Mobility options                           .
       .                                                              .
       .                                                              .
       |                                                              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-


                       Figure 9: CBU Message Format

   A new flag (C) is included in the Proxy Binding Update message format
   to indicate that this is Corresponding Binding Update message.







Dutta (Ed.), et al.      Expires April 23, 2010                [Page 21]


Internet-Draft           PMIP Route Optimization            October 2009


5.2.  Correspondent Binding Acknowledgement

   In order to acknowledge the CBU, the Correspondent Binding
   Acknowledgement (CBA) message is used.  The message format is
   identical to the PBA message, but a new flag (C) is included to
   distinguish from the PBA.  A sample binding update message is shown
   in Figure 10.



   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
                                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                   |   Status      |K|R|P|C|Resv'd |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Sequence #            |           Lifetime            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   .                                                               .
   .                        Mobility options                       .
   .                                                               .
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                       Figure 10: CBA Message Format

























Dutta (Ed.), et al.      Expires April 23, 2010                [Page 22]


Internet-Draft           PMIP Route Optimization            October 2009


6.  Security Considerations

   The CB update (CBU) messages need to be secured.  Since mobile's
   movement is constrained within a domain, these route optimization
   update messages can use the existing security mechanism that is in
   place as part of ProxyMIP deployment.  It is assumed that there is
   standard security mechanism in place between the MAGs (Media Access
   Gateway) and between MAG and LMA.  Thus, the CB update messages can
   be protected accordingly.










































Dutta (Ed.), et al.      Expires April 23, 2010                [Page 23]


Internet-Draft           PMIP Route Optimization            October 2009


7.  IANA Considerations

   TBD
















































Dutta (Ed.), et al.      Expires April 23, 2010                [Page 24]


Internet-Draft           PMIP Route Optimization            October 2009


8.  Acknowledgments

   Authors acknowledge the useful discussion with Dana Chee.
















































Dutta (Ed.), et al.      Expires April 23, 2010                [Page 25]


Internet-Draft           PMIP Route Optimization            October 2009


9.  References

9.1.  Normative References

   [RFC5213]  Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
              and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.

9.2.  Informative References

   [I-D.jeong-netlmm-pmipv6-roreq]
              Jeong, S., Vogt, C., Wakikawa, R., Liebsch, M., Sugimoto,
              S., and B. Sarikaya, "Problem Statement and Requirements
              for Route Optimization in PMIPv6",
              draft-jeong-netlmm-pmipv6-roreq-01 (work in progress),
              November 2007.

   [I-D.qin-netlmm-pmipro]
              Sarikaya, B., Qin, X., Huang, A., and W. Wu, "PMIPv6 Route
              Optimization Protocol", draft-qin-netlmm-pmipro-00 (work
              in progress), February 2008.

   [I-D.abeille-netlmm-proxymip6ro]
              Liebsch, M., Le, L., and J. Abeille, "Route Optimization
              for Proxy Mobile IPv6",
              draft-abeille-netlmm-proxymip6ro-01 (work in progress),
              November 2007.

   [RFC4832]  Vogt, C. and J. Kempf, "Security Threats to Network-Based
              Localized Mobility Management (NETLMM)", RFC 4832,
              April 2007.

   [RFC4831]  Kempf, J., "Goals for Network-Based Localized Mobility
              Management (NETLMM)", RFC 4831, April 2007.

   [RFC4830]  Kempf, J., "Problem Statement for Network-Based Localized
              Mobility Management (NETLMM)", RFC 4830, April 2007.















Dutta (Ed.), et al.      Expires April 23, 2010                [Page 26]


Internet-Draft           PMIP Route Optimization            October 2009


Authors' Addresses

   Ashutosh Dutta
   Telcordia Technologies
   1 Telcordia Drive
   Piscataway, NJ  08854
   USA

   Phone: +1 732 699 3130
   Email: adutta@research.telcordia.com


   Subir Das
   Telcordia Technologies
   1 Telcordia Drive
   Piscataway, NJ  08854
   USA

   Phone: +1 732 699 2483
   Email: subir@research.telcordia.com


   Hidetoshi Yokota
   KDDI Labs
   2-1-15 Ohara
   Fujimono, Saitama  356-8502
   Japan

   Phone:
   Email: yokota@kddilabs.jp


   Tsunehiko Chiba
   KDDILab
   2-1-15 Ohara
   Fujimino, Saitama  356-8502
   Japan

   Phone:
   Email: t-chiba@kddilabs.jp











Dutta (Ed.), et al.      Expires April 23, 2010                [Page 27]


Internet-Draft           PMIP Route Optimization            October 2009


   Henning Schulzrinne
   Columbia University
   Department of Computer Science
   450 Computer Science Building
   New York, NY  10027
   USA

   Phone: +1 212 939 7004
   Email: hgs@cs.columbia.edu










































Dutta (Ed.), et al.      Expires April 23, 2010                [Page 28]