Internet DRAFT - draft-wu-netext-local-ro

draft-wu-netext-local-ro






Network Working Group                                              Q. Wu
Internet-Draft                                               B. Sarikaya
Intended status: Standards Track                                  Huawei
Expires: August 16, 2010                               February 12, 2010


    An Extension to Proxy Mobile IPv6 for Local Routing Optimization
                      draft-wu-netext-local-ro-05

Abstract

   This document extends local routing in Proxy Mobile IPv6 (PMIPv6) and
   defines a localized routing optimization protocol between Mobility
   Access Gateways within a single provider domain.  The protocol
   supports operation over IPv4 transport networks, IPv4 home address
   mobility and handover.  The Local mobility anchor initiated and
   mobile access gateway initiated local routing are allowed to setup
   local routing path between the mobile and correspondent node by
   sending messages to the corresponding mobile access gateway or local
   mobility anchor.  If the MN & CN are anchored with two different LMAs
   then the MN-LMA must discover which LMA the CN is registered with
   before an optimized local routing path can be established.  Mobile
   Access Gateways create and refresh bindings using proxy binding
   update and acknowledgement messages.

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.  This document may not be modified,
   and derivative works of it may not be created, and it may not be
   published except as an Internet-Draft.

   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.




Wu & Sarikaya            Expires August 16, 2010                [Page 1]

Internet-Draft      PMIPv6 Local Routing Optimization      February 2010


   This Internet-Draft will expire on August 16, 2010.

Copyright Notice

   Copyright (c) 2010 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
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the BSD License.



































Wu & Sarikaya            Expires August 16, 2010                [Page 2]

Internet-Draft      PMIPv6 Local Routing Optimization      February 2010


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  PMIP6 Local Routing OptimizationScenario Analysis  . . . . . .  5
   4.  Local Routing Optimization Protocol Overview . . . . . . . . .  6
     4.1.  MAG-initiated Local Routing Optimization . . . . . . . . .  7
       4.1.1.  Handover Considerations  . . . . . . . . . . . . . . .  9
     4.2.  LMA-initiated Local Routing Optimization . . . . . . . . . 10
       4.2.1.  Handover Considerations  . . . . . . . . . . . . . . . 11
   5.  Processing Considerations  . . . . . . . . . . . . . . . . . . 12
     5.1.  Mobile Access Gateway Considerations . . . . . . . . . . . 12
     5.2.  Local Mobility Anchor Considerations . . . . . . . . . . . 15
   6.  IPv4 Support . . . . . . . . . . . . . . . . . . . . . . . . . 17
     6.1.  IPv4 HoA Support . . . . . . . . . . . . . . . . . . . . . 17
     6.2.  IPv4 Transport Support . . . . . . . . . . . . . . . . . . 17
   7.  Inter-LMA Local Routing Considerations . . . . . . . . . . . . 18
     7.1.  MAG-initiated Inter-LMA Local Routing  . . . . . . . . . . 18
   8.  Conceptual Data Structure Extensions . . . . . . . . . . . . . 19
     8.1.  Binding Update List Extensions . . . . . . . . . . . . . . 19
     8.2.  Binding Cache Entry Extensions . . . . . . . . . . . . . . 20
     8.3.  Routing Table Entry Extensions . . . . . . . . . . . . . . 20
   9.  Local Routing Optimization Message Format  . . . . . . . . . . 21
     9.1.  Local Routing Optimization Mobility Option . . . . . . . . 21
     9.2.  The Local Routing Optimization Request (LROREQ) Message  . 22
     9.3.  Local Routing Optimization Response Message (LRORSP) . . . 23
     9.4.  MN-CNs Pair Mobility Option  . . . . . . . . . . . . . . . 24
   10. Security Considerations  . . . . . . . . . . . . . . . . . . . 26
   11. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 27
   12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27
   13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
     13.1. Normative References . . . . . . . . . . . . . . . . . . . 27
     13.2. Informative References . . . . . . . . . . . . . . . . . . 27
   Appendix A.  Future Extension  . . . . . . . . . . . . . . . . . . 28
     A.1.  LMA Route Optimization Start Message . . . . . . . . . . . 28
       A.1.1.  LMA Route Optimization Start Request Message . . . . . 28
       A.1.2.  LMA Route Optimization Start Response Message  . . . . 29
     A.2.  LMA Initiated Inter-LMA Local Routing  . . . . . . . . . . 30
       A.2.1.  IPv4 Support Consideration . . . . . . . . . . . . . . 31
     A.3.  LMA Initiated operation for Inter-LMA Local Routing  . . . 31
   Appendix B.  Change Notes  . . . . . . . . . . . . . . . . . . . . 32
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33









Wu & Sarikaya            Expires August 16, 2010                [Page 3]

Internet-Draft      PMIPv6 Local Routing Optimization      February 2010


1.  Introduction

   Proxy Mobile IPv6 (PMIP6) [RFC5213] allows the Mobility Access
   Gateway (MAG) to optimize packet delivery by locally routing packets
   within one MAG instead of reverse tunneling them to the mobile node's
   Local Mobility Anchor (LMA).  However, it does not address the
   optimization of routing between two Mobile Access Gateways sharing
   the same LMA or registered to different Local Mobility Anchors; nor
   does it define how local routing optimization capability is detected,
   the entity that initiates local routing optimization, or how to
   determine whether local routing optimization is permitted.

   This document defines local routing optimization mobility messages
   and options for PMIPv6 that are intended to assist the Mobile Access
   Gateways to negotiate and setup a local routing path between each
   other.  The new local routing optimization mobility options allow the
   LMA and the MAG to discover whether local routing is allowed and, if
   som what form it may take.  The local routing optimization protocol
   can be initiated by either of the PMIPv6 managed nodes and provides a
   flexible negotiation mechanism for local routing.

   As RFC 5213 [RFC5213] warns, use of local routing may affect
   accounting and traffic policies relating to the mobile node, LMA
   routing policies, and security policies.  The general aim of the
   proposals in this document is to provide better manageability of
   local routing services and local routing service provisioning from
   the point of view of both operators and service providers within one
   Provider domain.


2.  Terminology

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

   The document uses the terminology specified in RFC 5213 [RFC5213]and
   RFC 3775 [RFC3775] In addition, this document defines the following
   terms:

   Local routing (LR)

      When local routing is active, traffic between the MN and the CN
      does not pass through the LMA and is routed directly between the
      MAG(s) to which the MN and CN are attached.  Local routing may
      only take place between Mobile Access Gateways within a single
      provider domain.




Wu & Sarikaya            Expires August 16, 2010                [Page 4]

Internet-Draft      PMIPv6 Local Routing Optimization      February 2010


   Local Routing Optimization Request (LROREQ):

      A message initiated by the MAG or LMA to which the Mobile Node is
      attached requesting the MAG or LMA to which the Mobile Node or the
      Correspondent Node is attached to establish a local routing path
      between the MN and CN.

   Local Routing Optimization Response (LRORSP):

      A reply message from a MAG or LMA confirming the local routing
      optimization results.


3.  PMIP6 Local Routing OptimizationScenario Analysis

   Figure 1 shows the reference architecture for PMIP6 local routing
   optimization.  In this architecture, local communication between
   PMIPv6 managed nodes (i.e., MAGs) is constrained within a single
   Provider domain, as described in [I-D.ietf-netext-pmip6-lr-ps].  In
   the architecture, LMA1 and LMA2 may be the same LMA.

                              +---------+
                  ============|LMA1/LMA2|============
                 //           +---------+            \\
                 ||                                  ||
                 ||                                  ||
                 ||                             +-----------+
            +-----------+                       | IPv4/IPv6 |
            | IPv4/IPv6 |                       |  Network  |
            |  Network  |                       +-----------+
            +-----------+                            ||
                 ||                                  ||
                 ||           +-----------+          ||
              +------+        |IPv4/IPv6  |        +------+
              | MAG1 |=============================| MAG2 |
              +------+        | Network   |        +------+
                |  |          +-----------+          |  |
          +-----+  +-----+                     +-----+  +-----+
          |              |                     |              |
        +----+        +-----+               +-----+         +-----+
        | MN |        | CN1 |               | CN2 |         | CN3 |
        +----+        +-----+               +-----+         +-----+

     {IPv4-MN-HoA1} {IPv4-CN1-HoA2}     {IPv4-CN2-HoA3} {IPv6-CN3-HoA4}
     {IPv6-MN-HoA1}                   {IPv6-CN2-HoA3}

         Figure 1: Reference Architecture for PMIP6 Local Routing




Wu & Sarikaya            Expires August 16, 2010                [Page 5]

Internet-Draft      PMIPv6 Local Routing Optimization      February 2010


   Depending on how MN and CN are distributed into different provider
   domains, three typical scenarios need to be considered as follows:


   Scenario 1: Intra-MAG local routing

      In this scenario, both the MN and CN are attached to the same MAG
      and are anchored with the same LMA or different LMAs.

   Scenario 2: Intra-LMA local routing

      In this scenario, the MN and CN are attached to different MAGs and
      are anchored with the same LMA.

   Scenario 3: Inter-LMA local routing

      In this scenario, the MN and CN are attached to different MAGs and
      are anchored with different LMAs.

   In all three scenarios, the MN is allowed to roam within the domain
   in which its anchoring LMA is located or move from one domain to
   another.  The CN should stay with the MN in the same domain; e.g.,
   the MN moves to the visited domain to which the CN belongs.  Another
   example is if the MN and CN move to the same visited domain to which
   MN's LMA or CN's LMA does not belong.


4.  Local Routing Optimization Protocol Overview

   The protocol specified here focuses on intra-MAG local routing and
   intra-LMA local routing and assumes that

   o  the MAGs are situated in one Provider domain

   o  MN and CN are anchored with the same LMA.

   o  The MAG has the capability to perceive intra-MAG local routing
      (i.e., the MAG can detect whether the mobile node and
      correspondent node are attached to the same MAG).

   o  The LMA has the capability to perceive intra-LMA local routing
      (i.e., the LMA can detect whether the MAGs to which the MN and CN
      are attached belong to the same or different LMAs).

   The decision to enable/disable detection of local routing should be
   based on the policy configured on the MAG or LMA.  The trigger for
   detection of local routing may come from uplink or downlink datagram
   forwarding or from the application layer.  The specific details on



Wu & Sarikaya            Expires August 16, 2010                [Page 6]

Internet-Draft      PMIPv6 Local Routing Optimization      February 2010


   how this is achieved are beyond of the scope of this document.
   Depending on how local routing is initiated, local routing
   optimization can be categorized into:

   o  MAG-initiated local routing optimization

   o  LMA-initiated local routing optimization

4.1.  MAG-initiated Local Routing Optimization

   When the MAG is triggered and enabled to detect local routing, the
   MAG can detect whether the MN and CN are attached to the same MAG by
   looking at the source and destination address of outgoing packets and
   checking the binding update list of the MN and CN.

   If, upon receiving a packet from the MN or the CN, the MAG perceives
   that the MN and CN are both attached to the same MAG, it can initiate
   local routing optimization by asking the LMA to check the value of
   the Intra-MAG LocalRouting flag (defined in Section 8.1).  If the MAG
   detects that the MN and CN are not attached to the same MAG but wants
   to check whether intra-LMA routing is allowed (i.e., the MN and CN
   are attached to different MAGs but anchored to the same LMA), it also
   can initiate LR by sending a message to the LMA.  The message may be
   a Binding Update message which contains the Local Routing
   Optimization Mobility Option (Section 9.1) and Home Network Prefix
   Option [RFC5213] for the correspondent node or a newly defined local
   routing optimization message.  It will be used to negotiate with the
   LMA to verify whether local routing is allowed and determine what
   local routing optimization is supported between the mobile node and
   correspondent node.  If the LMA can not determine whether local
   routing optimization is supported, it may ask AAA server to make
   decision, and the AAA server may be used to authorize the use of
   localized routing service for the MN.  If LR is not authorized, the
   LMA will respond to the MAG that local routing optimization is not
   available.  Otherwise, the LMA will set the Intra-MAG LocalRouting or
   Intra-LMA LocalRouting flag on the MAG by sending a successful
   response message with the Local Routing Optimization Indication (LRI)
   field of the Local Routing Optimization Mobility Option set
   appropriately.  If the LMA can validate the Correspondent Node's Home
   Network Prefix (HNP), the LMA may notify the MN's MAG of the MAG
   address associated with the CN's HNP using the MN-CNs Pair Mobility
   Option (Section 9.4) in the same response message.  In the intra-MAG
   local routing case, the MN-CNs Pair Mobility Option can be omitted
   from the response message.  The LMA may also set its own LocalRouting
   flag to indicate local routing is in use and correlate it with the
   binding cache entries corresponding to the MN and CN.  Note that
   setting the local routing flag is helpful for avoiding duplication of
   local routing behavior initiated from the MAG and triggering the MAG



Wu & Sarikaya            Expires August 16, 2010                [Page 7]

Internet-Draft      PMIPv6 Local Routing Optimization      February 2010


   to setup a local routing path.  Distinguishing between different
   local routing types on the MAG helps the LMA to build the response
   message efficiently.  For example, when Local Routing Optimization
   (LRI) field of the Local Routing Optimization Mobility Option is set
   to the value of one, it means that MAG already knows that the MN and
   CN are attached to the same MAG by checking binding update list,
   therefore it is unnecessary to include the CN's MN-CNs Pair Mobility
   Option; when the LRI field is not set to one, the MN-CNs Pair
   Mobility Option MUST be included in the response message from LMA,
   since only the LMA knows the address of the MAG to which the CN is
   attached.

   After the successful initiation of local routing optimization, if the
   MN and CN attach to different MAGs (e.g., MAG1 and MAG2) and the
   intra-LMA LocalRouting flag on MAG is set to value one, MAG1 may send
   a PBU message to MAG2 setting the lifetime of the binding of the MN
   at MAG2.  Similarly, if the intra-LMA LocalRouting flag is set to
   value one on MAG2, MAG2 sends a PBU message to MAG1.  This PBU
   message sets the lifetime of the binding of CN at MAG1.  Each PBU
   MUST be acknowledged with a PBA.  With the PBU/PBA exchange, the
   local data path between MAGs is established and the binding caches
   associated with MN and CN are set up.  A PBU-PBA exchange is repeated
   to extend the lifetime of the binding.  Subsequently the routing
   table entry can be setup based on the binding caches established on
   the MAGs.  The PBU/PBA signaling is protected using IPsec
   Encapsulation security payload [RFC4303] in transport mode with
   mandatory integrity protection.

   For data traffic, either of the MAGs can lookup the routing table
   entry associated with the MN or CN and identify the tunnel to the
   right MAG in terms of the destination address of an outgoing data
   packet.  If MN and CN attach to the same MAG, the traffic from the MN
   will go directly to the CN via the MAG.  If MN and CN attach to
   different MAGs and register to the same LMA, the traffic from MN will
   be forwarded directly by the MAG associated with the MN to the MAG
   associated with the CN.















Wu & Sarikaya            Expires August 16, 2010                [Page 8]

Internet-Draft      PMIPv6 Local Routing Optimization      February 2010


         +--+      +------+       +-----+        +------+      +--+
         |MN|      | MAG1 |       | LMA |        | MAG2 |      |CN|
         ++-+      +--+---+       +--+--+        +--+---+      +-++
          Attach to MAG1             |              |Attach to MAG2
          |---------->|              |              <------------+
          | Datagram  |  PBU'/LROREQ |              |            |
          |==========>|(MN-CN Pair)  |              |            |
          |           |------------->|              |            |
          |           |          +---+-----+        |            |
          |           |          |BCE Check|        |            |
          |          PBA'/LRORSP +---------+        |            |
          |           |   [MAG2]     |              |            |
          |           |<------------ |              |            |
          |   +-------+---------+    |              |            |
          |   |Enable Intra-LMA/|    |              |            |
          |   |intra-MAG Routing|    |              |            |
          |   +-------+---------+    |              |            |
          |          Bidirectional PBU/PBA between MAGs          |
          |           |<--------------------------->|            |
          |    +-------------+       |        +-------------+    |
          |    |Setup Binding|       |        |Setup Binding|    |
          |    |and Tunnel   |       |        | and Tunnel  |    |
          |    +-------------+       |        +-------------+    |
          | Datagram  |           Datagram          |  Datagram  |
          |==========>|============================>|===========>|
          | Datagram  |           Datagram          |  Datagram  |
          |<==========|<=============|==============|<===========|
          |           |              |              |            |
          |           |              |              |            |

            Figure 2: MAG-initiated Local Routing Optimization

4.1.1.  Handover Considerations

   When the MN moves from the old MAG (e.g., pMAG1) in the previous
   access network to a new MAG (e.g., nMAG1) in the new access network,
   context information (including the MAG addresses of all the CNs which
   are communicating with MN) for the MN in pMAG1 may be transferred to
   nMAG1.  The Context Request Option [I-D.ietf-mipshop-pfmipv6] can be
   reused to carry the context information from pMAG1 to nMAG1. nMAG1
   can use this data to send PBU messages to each of the MAGs connected
   to a CN with which the MN was in communication via the provisional
   secure data path, updating the binding in each MAG with which the MN
   was in communication and re-establishing an optimal local routing
   path between the MN and its CNs.






Wu & Sarikaya            Expires August 16, 2010                [Page 9]

Internet-Draft      PMIPv6 Local Routing Optimization      February 2010


            +-----+          +---------+           +---------+
            |pMAG1|          |nMAG1(MN)|           | MAG2(CN)|
            +--+--+          +---+-----+           +---+-----+
               |                 |                     |
               |    HI/HACK      |                     |
               |<--------------->|                     |
               |Predictive/Reactive                    |
               |                 |Bidirectional PBU/PBA|
               |                 |<------------------> |
               |                 |                     |
               |          +------+------+        +-----+-------+
               |          |UpdateBinding|        |UpdateBinding|
               |          | and Tunnel  |        | and Tunnel  |
               |          +------+------+        +-----+-------+
               |                 |      Datagram       |
               |                 |<===================>|


           Figure 3: MAG-initiated Local Routing During Handover

4.2.  LMA-initiated Local Routing Optimization

   When the LMA is triggered and enabled to detect local routing, the
   LMA can detect whether the MN and CN are registered to the same LMA
   by looking at the source and destination address of outgoing and
   incoming packets and checking the binding update list of MN and CN.

   Upon receiving a packet from the MN or CN and detecting that the MN
   and CN are registered to the same LMA, it may set its intra-LMA
   LocalRouting flag, correlating it with the binding cache entries
   associated with the MN and CN.  And then LMA initiates local routing
   optimization to determine the value of Intra-LMA LocalRouting flag
   (defined in Section 8.1) on the MAG, i.e., notify or enforce the
   value of intra-LMA LocalRouting flag on the MAG associated with the
   MN by means of a LROREQ/LRORSP message exchange.  It will be used to
   help LMA to determine whether the local routing optimization is
   allowed.  If local routing optimization is allowed, then LMA will be
   responsible for enforcing local optimization on the MAG.  The AAA
   server serving the LMA may be used to authorize the use of localized
   routing service for the MN.  IF LR is not authorized,the LMA will
   respond to the MAG with failure information indicating that intra-LMA
   routing optimization is not allowed, otherwise, it will notify the
   MAG to set the intra-LMA LocalRouting flag.  The other procedures are
   same as those described in Section 4.1.







Wu & Sarikaya            Expires August 16, 2010               [Page 10]

Internet-Draft      PMIPv6 Local Routing Optimization      February 2010


         +--+      +------+       +-----+        +------+      +--+
         |MN|      | MAG1 |       | LMA |        | MAG2 |      |CN|
         ++-+      +--+---+       +--+--+        +--+---+      +-++
          Attach to MAG1             |              |Attach to MAG2
          |---------->|      +-------+----------+   <------------+
          |           |      |   BCE Check      |   |            |
          |           |      |Perceive MAG1 and |   |            |
          |           |      |MAG2 register to  |   |            |
          |           |      |the same LMA      |   |            |
          |           |      +-------+----------+   |            |
          |           |   LROREQ     |              |            |
          |           |   (MAG2)     |              |            |
          |           |<------------ |              |            |
          |   +-------+---------+    |              |            |
          |   |Enable Intra-LMA/|    |              |            |
          |   |    Routing      |    |              |            |
          |   +-------+---------+    |              |            |
          |               LRORSP     |              |            |
          |           |------------->|              |            |
          |          Bidirectional PBU/PBA between MAGs          |
          |           |<--------------------------->|            |
          |     +-------------+      |        +-------------+    |
          |     |Setup Binding|      |        |Setup Binding|    |
          |     | and Tunnel  |      |        | and Tunnel  |    |
          |     +-----+-------+      |        +-----+-------+    |
          | Datagram  |           Datagram          |  Datagram  |
          |==========>|============================>|===========>|
          | Datagram  |           Datagram          |  Datagram  |
          |<==========|<============================|<===========|

            Figure 4: LMA Initiated Local routing optimization

4.2.1.  Handover Considerations

   If the MN moves from the old MAG (e.g., pMAG1) in the previous access
   network to the new MAG (e.g., nMAG1) in a new access network, nMAG1
   may update the binding cache entry associated with MN at the LMA by
   sending a normal PBU message.  At the same time, the LMA may refresh
   the binding update list associated with the MN and update the binding
   of each MAG with which MN was in communication via the established
   local route optimization path by sending a LROREQ message to each
   MAG.  Also pMAG1 can use a procedure similar to that described in
   Section 4.1.1 to transfer MN's registration entry at pMAG1 to nMAG1.








Wu & Sarikaya            Expires August 16, 2010               [Page 11]

Internet-Draft      PMIPv6 Local Routing Optimization      February 2010


          +-----+    +---------+    +----------+     +---------+
          |pMAG1|    |nMAG1(MN)|    |LMA(MN,CN)|     | MAG2(CN)|
          +--+--+    +---+-----+    +----+-----+     +---+-----+
             |           |  Normal PBU   |               |
             |           |-------------->|               |
             |           |               |               |
             |           |  Normal PBA   |               |
             |           |<------------- |    LROREQ     |
             |           |               |-------------->|
             |           |               |               |
             |           |               |    LRORSP     |
             |           |               |<------------- |
             |           Bidirectional PBU/PBA between MAGs
             |           |<----------------------------->|
             |    +------+------+        |         +-----+-------+
             |    |UpdateBinding|        |         |UpdateBinding|
             |    | and Tunnel  |        |         | and Tunnel  |
             |    +------+------+     Datagram     +-----+-------+
             |           |<=============================>|
             |           |               |               |

    Figure 5: LMA-initiated Local Routing Optimization During Handover


5.  Processing Considerations

5.1.  Mobile Access Gateway Considerations

   When the MAG sends a LROREQ or PBU to the LMA, it may include the
   Routing Optimization Mobility and MN-CNs Pair Mobility Options in a
   binding update message or create a new routing optimization request
   message to include these two options:

   o  The Routing Optimization Mobility Option is used to negotiate what
      kind of local routing optimization is available.  If intra-MAG
      local routing is allowed, the LRI field in the Routing
      Optimization Mobility Option is set to one (1).  If the intra-MAG
      local routing is not available but the MAG would like to check
      whether intra-LMA local routing is allowed, the MAG will set the
      LRI field of the Routing Optimization Mobility Option to value 0
      in the PBU or LROREQ message to the LMA, because the mobile node's
      MAG does not know whether traffic between MN and CN can be locally
      routed within one LMA.

   o  The MN-CNs Pair Mobility Option is used for the LMA to verify the
      validity of the local routing optimization path end points (in the
      intra-MAG local routing scenario) or to request the LMA to
      determine the proxy CoA-Address of the Crrespondent Node for local



Wu & Sarikaya            Expires August 16, 2010               [Page 12]

Internet-Draft      PMIPv6 Local Routing Optimization      February 2010


      routing optimization (in the intra-LMA local routing scenario).
      In the case of intra-MAG local routing, MAG should fill the MN-CNs
      Pair Mobility Option with MN HNP, MN Proxy CoA, CN HNP and CN
      Proxy CoA.  In the case of intra-LMA local routing, the MAG only
      fills MN-CN pairs mobility option with MN's HNP, MN's Proxy CoA
      and CN's HNP.

   When the MAG receives a binding acknowledgement message containing
   the Routing Optimization Mobility Option or routing optimization
   response message it will check the validity of all the fields,
   including whether the sequence number value in the acknowledge/
   response message is identical to the sequence number value in the
   corresponding request and whether the MN-CNs Pair Mobility Option is
   present.  If the message is valid, the MAG will extract the LRI field
   from the Routing Optimization Mobility Option or routing optimization
   response message and check the value.  If the LRI field is zero, it
   indicates the LMA does not support local routing optimization and the
   MAG should set the intra-MAG LocalRouting flag to zero in the binding
   update list extension; if the LRI field is one, it indicates that the
   LMA allows local routing in one MAG and bypass the LMA and MAG should
   set intra-MAG LocalRouting flag to value one in the binding update
   list extension.  If the LRI field is two, it indicates LMA has found
   the Correspondent Node's MAG address in terms of the HNP of the CN.
   In this case, the MAG should extract the Correspondent Node's MAG
   address from the initial binding acknowledgement or routing
   optimization response message and store it in a binding update list
   extension with the Correspondent Node's HNP and set the intra-LMA
   LocalRouting flag in the binding update list extension.

   In LMA-initiated local routing, upon receiving a LROREQ message from
   the LMA, the MAG extracts MN HNP from MN-CNs Pair Mobility Option and
   searches the binding update list for a matching IPv6 home network
   prefix in the list of prefixes it stores for each mobile node that
   the MAG is serving.  If a match is found, the MAG MUST send a PBU
   message to the MAG of the Correspondent Node.  PBU message lifetime
   is set to the lifetime value in LROREQ message.  Destination address
   is the same as Proxy CoA field in the CN part of MN-CNs Pairs
   Mobility Option included in LROREQ message.  The MAG MUST send a PBU
   message to the MAG of each Correspondent Node if the LROREQ message
   contains more than one CN in the MN-CNs Pair Mobility Option.  For
   each PBU message sent to a MAG, a new binding update list entry MUST
   be created if it has not already been created before, e.g. refresh
   PBU.  The fields in this entry are set as follows:

   o  Mobile Node information fields like MN-Identifier, link-layer
      identifier, home network prefixes, etc., are copied from the entry
      that was created during the initial PBU procedure.




Wu & Sarikaya            Expires August 16, 2010               [Page 13]

Internet-Draft      PMIPv6 Local Routing Optimization      February 2010


   o  The IPv6 address of the LMA serving the attached mobile node is
      replaced with the Proxy-CoA of the MAG to which the PBU was sent
      and Proxy-CoA field in the Correspondent Node part of the MN-CN RO
      Option is copied to this field.  The IP address of the
      Correspondent Node to which MN is communicating is set to the Home
      Network Prefix field of the Correspondent Node part of the MN-CNs
      Pair Mobility Option.  If the P bit is set in the MN-CNs Pair
      Mobility Option, this field is set to the IPv4 HoA field in the
      Correspondent Node part of MN-CNs Pair Mobility Option.

   o  The initial value of the Binding Lifetime field is set to the
      Lifetime field in the LROREQ message.

   o  A configuration variable called EnableLMALocalRouting is defined
      at the MAGs to indicate whether or not the MAG is allowed to
      enable local routing of the traffic exchanged between a visiting
      MN that is locally connected to one of the interfaces of the
      mobile access gateway and a CN that is locally connected to one of
      the interfaces of another mobile access gateway that is connected
      to the same LMA.  Any LROREQ message received from LMA with
      lifetime greater than zero enables the local routing at this MAG
      and the MAG that receives LROREQ first time MUST set
      EnableLMALocalRouting to 1.

   When the Intra-MAG LocalRouting flag or Intra-LMA LocalRouting flag
   are set on the MAGs, one MAG may send a Proxy Binding Update message
   to another MAG to establish a corresponding binding cache associated
   with the MN and CN.  Upon receiving a Proxy Binding Update message,
   the MAG checks if the LocalRouting flag is set to value one.  If the
   LocalRouting flag is not set to value one, the MAG MUST reject the
   request and send a Proxy Binding Acknowledgement message with the
   status field set to 129 (administratively prohibited).

   Upon accepting a Proxy Binding Update request, the MAG MUST create a
   Binding Cache entry.  The Source address in the Proxy Binding Update
   is copied to the Proxy CoA field of the binding cache entry.  The
   Mobile Node data (MN-Identifier, link-layer identifier, link-local
   address, home network prefixes, etc.) are copied from the
   corresponding fields of the proxy binding update.

   Upon accepting a Proxy Binding Update request for the first time from
   another MAG, the MAG MUST establish a bi-directional tunnel between
   the two MAGs.  The tunnel endpoints are the Proxy-CoA of the
   receiving Mobile Access Gateway and the Proxy-CoA of the Mobile
   Access Gateway that sent the PBU, which can be obtained from the
   source address of the PBU message.  This tunnel SHOULD be deleted
   when there are no Mobile Nodes sharing it or when a Mobile Access
   Gateway receives a PBU message from another MAG with lifetime set to



Wu & Sarikaya            Expires August 16, 2010               [Page 14]

Internet-Draft      PMIPv6 Local Routing Optimization      February 2010


   zero or when the MAG receives a LROREQ message from the corresponding
   LMA with the lifetime set to zero.

   In case of handover or detachment, if the MAG cannot detect the
   presence of the mobile node on the connected link, the MAG SHOULD
   terminate the binding of the MN by sending a PBU message to all CN's
   MAGs that has established bindings.  The MAG sends a PBU message to
   each MAG with lifetime set to zero.  Proxy-CoA of the MAG field in
   each Binding update list entry determines the MAG address.  If IPv4
   transport is used, IPv4-Proxy-CoA is used.  The MAG MUST also remove
   each Binding Update List entry on all CN's MAGs created for that MN.

   In order to re-establish the bindings of the MN that is involved in
   local routing, i.e. with binding update list entries on the new MAG
   other than the home (local mobility anchor registration), the
   previous MAG MAY use a context transfer procedure to transfer the
   local routing state to the new MAG.  Each entry in the binding update
   list for this MN other than the LMA entry can be transferred.  After
   handover is completed, the new MAG MUST send PBU messages to the MAG
   (Proxy-CoA or IPv4-Proxy-CoA) associated with each Correspondent
   Node.  Another way to re-establish the bindings of the MN is to have
   the new MAG trigger the LMA to notify all the CN's MAGs to update
   binding update list on all CN's MAGs created for that MN.

   For the data traffic between the MN and CN, on receiving a packet
   from a MN connected to its access link, to a destination (i.e., CN)
   that is directly connected or not directly connected to the same
   access link, the MAG will check whether source/destination address
   pairs in the routing table entry matches the source/destination
   address in the outgoing data packet and identify the tunnel to the
   right destination MAG.  If the source address and destination address
   in the packet match one of source/destination address pairs in the
   routing entry, the packet must be tunneled to the Proxy CoA
   corresponding to the destination address in the tunnel interface.
   For the packet from a Mobile Node connected to its access link to a
   destination that is also directly connected to the same access link,
   the packet must go directly via the MAG.

5.2.  Local Mobility Anchor Considerations

   In the case of MAG initiating local routing, upon receiving a PBU or
   routing optimization request message, the LMA will check the LRI
   field in the Routing Optimization Mobility Option or routing
   optimization message.  If the LRI field is set to value one, the LMA
   will check whether there exist a binding cache list for the CN and
   whether the MN's proxy CoA address is same as the CN's proxy CoA
   address.  If LRI field is zero and the Correspondent Node's home
   network prefix is included, the LMA will check whether there exists a



Wu & Sarikaya            Expires August 16, 2010               [Page 15]

Internet-Draft      PMIPv6 Local Routing Optimization      February 2010


   binding cache list for CN in terms of the correspondent node's home
   network prefix.  If one does, the LMA will fill the MN-CNs Pair
   Mobility Option with the Proxy CoA and HNP of the CN and respond to
   the MAG with LRI field set to value two.  Otherwise, the LMA will
   respond to the MAG with the LRI field set to zero to indicate the MAG
   that local routing optimization is not available.

   In the case of LMA-initiated local routing, the LMA may be
   responsible for perceiving intra-LMA routing and correlate MN with CN
   in the binding update list.  Upon perceiving that intra-LMA local
   routing is allowed between the MN and CN, the LMA fills the MN-CNs
   Pair Mobility Option with MN HNP, MN Proxy CoA, CN HNP, CN Proxy CoA
   and includes it in the Local Routing Optimization Request
   message(LROREQ).  In the message, the LRI field set to value two.
   Then the LMA receives routing optimization reply message from the
   corresponding MAG.

   The LMA MUST send a LROREQ message to either or both of MAGs where MN
   and CN are located.  If CN (or MN) is not connected to the same LMA,
   the LROREQ message MUST be sent to only to the MAG that is connected
   to the LMA.  The LROREQ message MUST contain at least one pair of MN-
   CNs Pair Mobility Options.  If the MN is communicating with more than
   one CN which is regitered with the same LMA, the LMA MUST include
   more than one CN in the MN-CNs Pair Mobility Option if local routing
   will be enabled.  Before the LROREQ is sent to a MAG, the LMA MUST
   place the MN address information which is connected to this MAG first
   in MN-CNs Pair Mobility Option.

   The LMA MAY set the Lifetime field in the LROREQ message to a non-
   zero value.  Any non-zero lifetime value enables two MAG to start
   local routing optimization for MN-CN traffic.  The lifetime values
   sent to two MAG MUST be the same.

   The LMA MAY stop the local routing optimization operation any time it
   wishes.  In that case LMA MUST set the Lifetime field in LROREQ
   message to zero.  After receiving a LRORSP message from the MAG with
   a matching sequence number field, the LMA-MAG tunnel needs to be re-
   established separately for each MAG.

   The LMA sets the sequence number field in LROREQ message to a nonzero
   integer.  This initial sequence number is incremented by one for the
   next LROREQ message sent.  The LMA MUST receive a LRORSP message with
   the same sequence number as in the corresponding LROREQ message
   previously sent.  This message is acknowledged with a LROREQ message.
   If no acknowledgement is received, the LMA MUST retransmit the LROREQ
   message.





Wu & Sarikaya            Expires August 16, 2010               [Page 16]

Internet-Draft      PMIPv6 Local Routing Optimization      February 2010


6.  IPv4 Support

   IPv4 support is needed in two cases:

   o  The MN is IPv4 enabled and receives an IPv4 home address and

   o  The transport network between the LMA and the MAG is an IPv4
      network

   In both two cases, the encapsulation mode as described in
   [I-D.ietf-netlmm-pmip6-ipv4-support] is transparent to the MAG
   concerned before setting up the localized routing path.  This may
   result in data packets being dropped by the egress/ingress tunnel end
   points, i.e., the MAGs.

   Therefore local route optimization can be supported only if the
   encapsulated mode is aware or default configured during setting up
   the localized routing path.

6.1.  IPv4 HoA Support

   If the MN is IPv4-enabled and receives an IPv4 home address, both the
   MN and the CN configure global IPv4 home addresses by exchanging PBU/
   PBA between the MAG and the LMA as explained in
   [I-D.ietf-netlmm-pmip6-ipv4-support].

   The LMA MUST include the IPv4 IPv4-MN-HoA in local routing
   optimization messages for both MN and CN.  The LMA MAY include the
   Home Network Prefix in PBA if the MN or CN has been assigned one.
   Both local routing optimization request and local routing
   optimization response messages are IPv6 messages and are transported
   over the LMA-MAG tunnel in the same fashion as the PBU and PBA
   messages.

   The PBU and PBA exchanged between the MAGs are IPv6 messages and are
   transported as unencapsulated IPv6 messages between MAGs.  For
   simplification, we can assume the MAGs in communication are using the
   default encapsulation mode.  Data traffic between the MAGs after
   local routing is established is transported in the IPv6 inner packet
   as IPv4 payload.

6.2.  IPv4 Transport Support

   If IPv4 transport is used between the MAG and the LMA, the LROREQ,
   LRORSP, PBU and PBA messages are transported as IPv6 messages using
   IPv4 or IPv4-UDP-ESP encapsulation
   [I-D.ietf-netlmm-pmip6-ipv4-support].  IPv4-UDP and IPv4-UDP-TLV
   modes are not used because no NAT boxes are supported in this local



Wu & Sarikaya            Expires August 16, 2010               [Page 17]

Internet-Draft      PMIPv6 Local Routing Optimization      February 2010


   routing optimization protocol.  IPv4 data packets are transported in
   an IPv4 packet or encapsulated in IPv4-UDP-ESP encapsulation.


7.  Inter-LMA Local Routing Considerations

   In this section we concentrate on the case where the MN and CN are
   served by two different LMAs in the same Provider domain, which is
   not covered by Section 4and Section 5.

7.1.  MAG-initiated Inter-LMA Local Routing

   If the MAG to which the MN and CN are attached is registered to
   different LMAs, it needs to initiate local routing optimization to
   the different LMAs respectively.  The message exchange for the
   protocol is shown in Figure 6.  LR is triggered at one of the MAGs
   (e.g., MAG1) when a datagram is received on its upstream interface
   whose destination address is a CN for which LMA2 has a binding cache
   entry.  MAG1 requests the address of LMA2 from LMA1 by sending a
   LROREQ message containing the HNP of the CN.  LMA1 processes the
   LROREQ message and looks up the address of LMA2 based on the HNP or
   HoA of the CN.  There is one possible way to achieve this goal:

   o  LMA1 can exchange with a AAA server to retrieve the address of
      LMA2.  LMA1 sends the address of the CN and requests the address
      of the LMA to which the CN is anchored.  The AAA server responds,
      sending the address of LMA2 to LMA1.  See [I-D.wu-dime-pmip6-lr]
      for further details.

   Note that LMA2 address discovery is only performed once, i.e., when
   LMA1 does not know LMA2 address at the first time.  If discovery is
   successful, the address of LMA2 will be correlated with the HNP of
   the CN in the Mobile Nodes's binding update list for future use.

   Upon retrieving the address of LMA2, LMA1 then delivers it to MAG1 by
   means of an LRORSP message.  MAG1 then sends LROREQ message
   containing a MN-CNs Pair Mobility Option (defined in Section 9.4) to
   LMA2.  Note that MN-CNs Pair Mobility Option does not contain the CN
   Proxy CoA.  LMA2 processes the LROREQ message and looks up MAG2
   address based on CN HNP or HoA extracted from the message.  If the
   lookup is successful, LMA2 responds to the MAG1 with the address of
   the MAG to which the CN is attached (i.e., the address of MAG2).
   MAG1 and MAG2 exchange PBU/PBA messages to establish binding cache
   list between each other and the direct path between MAG1 and MAG2
   will be set up.






Wu & Sarikaya            Expires August 16, 2010               [Page 18]

Internet-Draft      PMIPv6 Local Routing Optimization      February 2010


         +------+        +----------+    +---------+       +------+
         | MAG1 |        | LMA1(MN) |    | LMA2(CN)|       | MAG2 |
         +---+--+        +----+-----+    +----+----+       +---+--+
             |                |LMA2 Discovery |                |
             |                |----->         |                |
             |                |               |                |
             |    LROREQ(CN)  |               |                |
             |--------------->|               |                |
             |                |               |                |
             |   LRORSP(LMA2) |               |                |
             |<---------------+               |                |
             |        LROREQ(MN,MAG1,CN)      |                |
             |------------------------------->|                |
             |         LRORSP(CN,MAG2)        |                |
             |<-------------------------------|                |
             |                |               |                |
             |<------------MAGs Exchange PBU/PBA-------------->|
             |                |               |                |


              Figure 6: MAG Initiated Inter-LMA Local routing

   Editor's Note:
      LMA-initiated Inter-LMA local routing is described in the Appendix
      for future extension.  In LMA-initiated Inter-LMA local routing,
      the setup of a local routing path depends on LMA-LMA
      communication.


8.  Conceptual Data Structure Extensions

8.1.  Binding Update List Extensions

   Every Mobile Access Gateway maintains a Binding Update List.  Each
   Entry in the Binding Update List represents a mobile node's mobility
   binding with its Local Mobility Anchor, as described in Section 6.1
   of the PMIPv6 specification [RFC5213].  This specification extends
   the Binding Update List Entry data structure with the following
   additional fields:

   Intra-MAG LocalRouting Flag
      This flag indicates whether media delivery optimization is allowed
      by locally routing packets within one MAG.  The flag is set to the
      value 1 if local media delivery optimization is allowed and 0 if
      it is not.






Wu & Sarikaya            Expires August 16, 2010               [Page 19]

Internet-Draft      PMIPv6 Local Routing Optimization      February 2010


   Intra-LMA LocalRouting Flag
      This flag indicates whether media delivery optimization is allowed
      by locally routing packets from one MAG to another within one LMA.
      The flag is set to the value 1 if local media delivery
      optimization is allowed and 0 if it is not.

   Inter-LMA LocalRouting Flag
      This flag indicates whether media delivery optimization is allowed
      by locally routing packets from a MAG served by one LMA to another
      MAG served by a different LMA.  The flag is set to the value 1 if
      local media delivery optimization is allowed and 0 if it is not.

8.2.  Binding Cache Entry Extensions

   Every Local Mobility Anchor MUST maintain a Binding Cache Entry for
   each currently registered mobile node.  To support LR, the Binding
   Cache Entry data structure needs to be extended with the following
   additional fields:

   Intra-LMA LocalRouting Flag
      This flag indicates whether media delivery optimization is allowed
      by locally routing packets from one MAG to another within one LMA.
      The flag is set to the value 1 if local media delivery
      optimization is allowed and 0 if it is not.

   Inter-LMA LocalRouting Flag
      This flag indicates whether media delivery optimization is allowed
      by locally routing packets from a MAG served by one LMA to another
      MAG served by a different LMA.  The flag is set to the value 1 if
      local media delivery optimization is allowed and 0 if it is not.

8.3.  Routing Table Entry Extensions

   Every mobile access gateway and local mobility anchor MUST maintain a
   Routing Table entry for each currently registered mobile node:


   o  The Home Address assigned to the Correspondent Node

   o  The Home Address assigned to the Mobile Node

   o  The tunnel interface assigned to the data path between the Mobile
      Node and the Correspondent Node








Wu & Sarikaya            Expires August 16, 2010               [Page 20]

Internet-Draft      PMIPv6 Local Routing Optimization      February 2010


9.  Local Routing Optimization Message Format

9.1.  Local Routing Optimization Mobility Option


      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Type = TBD   |   Length      |    Reserved               |LRI|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

           Figure 7: Local Routing Optimization Mobility Option

   Type:

      TBD

   Length:

      8-bit unsigned integer indicating the length of the option in
      octets, excluding the Type and Length fields.  This field MUST be
      set to 2.

   Reserved (R):

      This 8-bit field is unused for now.  The value MUST be initialized
      to 0 by the sender and MUST be ignored by the receiver.

   Local Routing Optimization Indication (LRI):

      00:

         Routing optimization state is unknown or routing optimization
         is not available.

      01:

         The value of Intra-MAG LocalRouting

      10:

         The value of Intra-LMA LocalRouting

      11:

         The value of Inter-LMA LocalRouting





Wu & Sarikaya            Expires August 16, 2010               [Page 21]

Internet-Draft      PMIPv6 Local Routing Optimization      February 2010


9.2.  The Local Routing Optimization Request (LROREQ) Message

   The Local Routing Optimization Request message is used by one PMIP6
   managed node (LMA or MAG) to negotiate with another PMIP6 managed
   node (MAG or LMA) whether and what local routing is allowed.

      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 #          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |R|LRI|B|  Reserved             |           Lifetime            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     ~                        Mobility options                       ~
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

           Figure 8: Local Routing Optimization Request Message

   Sequence Number:

      A monotonically increasing integer.  Set by a sending node in a
      request message, and used to match a reply to the request.

   'R' flag:

      Set to 0, this flag indicates a routing optimization request
      message.

   Bulk Localized Routing Flag (B):

      If the Bulk Localized Routing Flag (B) is set to 1, then the
      LROREQ message is a message requesting the MAG or LMA to establish
      local routing optimization paths between the MN and multiple CNs
      which are communicating with the MN; the MN-CNs Pair Mobility
      Option will be used to carry one MN and more than one CN.  If the
      bulk localized routing flag is set to 0, then the LROREQ message
      is a message requesting the MAG or LMA to establish a local
      routing optimization path between one MN and CN.

   Local Routing Optimization Indication (LRI):

      00:

         Routing optimization state is unknown or routing optimization
         is not available




Wu & Sarikaya            Expires August 16, 2010               [Page 22]

Internet-Draft      PMIPv6 Local Routing Optimization      February 2010


      01:

         The value of Intra-MAG LocalRouting

      10:

         The value of Intra-LMA LocalRouting

      11:

         The value of Inter-LMA LocalRouting

   Lifetime:

      The requested period in seconds for which the sender wishes local
      routing to be active.

9.3.  Local Routing Optimization Response Message (LRORSP)

   The Local Routing Optimization Response message is used to
   acknowledge the receipt of a Local Routing optimization Request
   message (described in Section 9.2).

      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 #          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |R|LRI|B|     Reserved          |           Lifetime            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     ~                        Mobility options                       ~
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

           Figure 9: Local Routing Optimization Response Message

   Sequence Number:

      A monotonically increasing integer.  Set by a sending node in a
      request message, and used to match a reply to the request.

   'R' flag:

      Set to 0, indicates it is an routing optimization request message.
      Set to 1, indicates it is an routing optimization response
      message.




Wu & Sarikaya            Expires August 16, 2010               [Page 23]

Internet-Draft      PMIPv6 Local Routing Optimization      February 2010


   Bulk Localized Routing Flag (B):

      If the Bulk Localized Routing Flag (B) is set to 1, then the
      LROREQ message is a message requesting the MAG or LMA to establish
      local routing optimization paths between the MN and multiple CNs
      which are communicating with the MN; the MN-CNs Pair Mobility
      Option will be used to carry one MN and more than one CN.  If the
      bulk localized routing flag is set to 0, then the LROREQ message
      is a message requesting the MAG or LMA to establish a local
      routing optimization path between one MN and CN.

   Local Routing Optimization Indication (LRI):

      00:

         Routing optimization state is unknown or routing optimization
         is not available

      01:

         The value of Intra-MAG LocalRouting

      10:

         The value of Intra-LMA LocalRouting

      11:

         The value of Inter-LMA LocalRouting

   Lifetime:

      The requested period in seconds for which the sender wishes local
      routing to be active.

   Mobility Options:

      The Local Routing Optimization Mobility Option described in
      Section 9.1 and MN-CNs Pair Mobility Option described in
      Section 9.4 can be included.

9.4.  MN-CNs Pair Mobility Option

   The MN-CNs Pair Mobility Option is defined for use with the Local
   Route Optimization Request Section 9.2 and Local Route Optimization
   Response Section 9.3 messages exchanged between the LMA and MAGs.
   This option is used by the PMIP6 managed node to enable local routing
   for MN to CNs path from the destination MAG that receives the request



Wu & Sarikaya            Expires August 16, 2010               [Page 24]

Internet-Draft      PMIPv6 Local Routing Optimization      February 2010


   message towards CNs connected a different MAG.  The addresses of the
   target Correspondent Nodes are given in the option.  The option MUST
   be used in pairs including one MN, one or many CNs in communication
   with MN.  The order is important.  The LMA places the data for the MN
   first in the MN-CNs Pair Mobility Option.

      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |      Type     |   Length      |P| Reserved    |Prefix Length  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     +                                                               +
     |                                                               |
     +                  Home Network Prefix                          +
     |                                                               |
     +                                                               +
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     +                                                               +
     |                                                               |
     +                      Proxy CoA                                +
     |                                                               |
     +                                                               +
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                     IPv4   HoA                                |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                   IPv4 Proxy CoA                              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 10: MN-CNs Pair Mobility Option

   P Flag:

      The 'P' flag is set for IPv4 support.  When set, the IPv4 HoA and
      IPv4 Proxy CoA fields MUST be included for the MN or CN.

   Reserved:

      This 7-bit field is unused for now.  The value MUST be initialized
      to 0 by the sender and MUST be ignored by the receiver.

   Prefix Length:

      8-bit unsigned integer indicating the prefix length of the IPv6
      prefix contained in the option.




Wu & Sarikaya            Expires August 16, 2010               [Page 25]

Internet-Draft      PMIPv6 Local Routing Optimization      February 2010


   Home Network Prefix:

      A sixteen-byte field containing the mobile or corresponding node's
      IPv6 Home Network Prefix.

   Proxy CoA:

      A sixteen-byte field containing the global address configured on
      the egress interface of the mobile access gateway to which the
      mobile or corresponding node is connected.

   IPv4 HoA:

      Optional 32-bit field containing the IPv4 home address of the
      mobile or corresponding node.

   IPv4 Proxy CoA:

      Optional 32-bit field containing the IPv4 address that is
      configured on the egress-interface of the mobile access gateway.


10.  Security Considerations

   The protocol specified in this document can use the security
   association between the LMA and the MAG to create security
   associations between MAGs to which MN and CN attach in the intra-LMA
   local routing scenario.  As regarding the intra-MAG local routing
   scenario, integrity protection can be considered and confidentiality
   using IPsec is not necessary.

   In the handover case, the security association between the new MAG
   and a particular LMA should be pre-established when the MN arrives at
   the new MAG.  A particular LMA can be any LMA serving the MN or CN.
   MAG initiated inter-LMA local routing may depend on the security
   association between MN's new MAG and CN's LMA during handover.

   In order to setup a local routing path, MN's MAG may exchange PBU/PBA
   with CN's MAG.  CN's MAG needs to know that the prefix extracted from
   the MN-CNs Pair Mobility Option in the PBU is owned by the MN and
   that the MN's MAG is actually proxying this prefix.  Prefix ownership
   validation may be required during PBU/BPA exchange to ensure that a
   valid routing state can be created on the CN's MAG.  It is the same
   case when CN's MAG exchanges PBU/PBA with MN's MAG.







Wu & Sarikaya            Expires August 16, 2010               [Page 26]

Internet-Draft      PMIPv6 Local Routing Optimization      February 2010


11.  IANA Considerations

   TBD.


12.  Acknowledgements

   The authors would like to thank Tom Taylor, Kent Leung, Sri
   Gundavelli, Jouni Korhonen, Mohana Jeyatharan, for their comments on
   this draft.  Speically thanks to Glen Zorn for providing useful
   reviews.


13.  References

13.1.  Normative References

   [I-D.ietf-mipshop-pfmipv6]
              Yokota, H., Chowdhury, K., Koodli, R., Patil, B., and F.
              Xia, "Fast Handovers for Proxy Mobile IPv6",
              draft-ietf-mipshop-pfmipv6-12 (work in progress),
              December 2009.

   [I-D.ietf-netlmm-pmip6-ipv4-support]
              Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy
              Mobile IPv6", draft-ietf-netlmm-pmip6-ipv4-support-17
              (work in progress), September 2009.

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

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

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

13.2.  Informative References

   [I-D.ietf-netext-pmip6-lr-ps]
              Liebsch, M., Jeong, S., and W. Wu, "PMIPv6 Localized
              Routing Problem Statement",
              draft-ietf-netext-pmip6-lr-ps-02 (work in progress),
              January 2010.




Wu & Sarikaya            Expires August 16, 2010               [Page 27]

Internet-Draft      PMIPv6 Local Routing Optimization      February 2010


   [I-D.wu-dime-pmip6-lr]
              Wu, W. and G. Zorn, "AAA Support for PMIP6 mobility
              entities Locating and Discovery during localized routing",
              draft-wu-dime-pmip6-lr-01 (work in progress),
              October 2009.


Appendix A.  Future Extension

A.1.  LMA Route Optimization Start Message

A.1.1.  LMA Route Optimization Start Request Message


      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                     |       Sequence Number         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |         Reserved              |            Lifetime           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     .                                                               .
     .                        Mobility options                       .
     .                                                               .
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         Figure A.1.1. LMA Route Optimization Start Request Message


   A new MH type should be assigned by IANA.

   Sequence Number
      16-bit unsigned integer.  The LMA uses this field to match a
      returned LMAROStartRsp message.  The LMA also uses this field to
      identify each new pairs of MN-CN to start local routing if the LMA
      received LMAStartRORsp message.

   Reserved
      This field is unused.  It SHOULD be initialized to zero by the
      sender and MUST be ignored by the receiver.

   Lifetime
      16-bit unsigned integer.  If non-zero, this fields indicates the
      initial lifetime of the MN to CN route optimization binding.  If
      there are several MN-CN pairs, the same lifetime applies to each
      pair.




Wu & Sarikaya            Expires August 16, 2010               [Page 28]

Internet-Draft      PMIPv6 Local Routing Optimization      February 2010


   Mobility Options
      As defined in section 6.1.7 of RFC 3775 [RFC3775].

   This document defines a new mobility option: MN-CN RO option in
   Section 9.4.  The sending LMA sends a pair of MN-RO Options.  LMA
   sets Home Network Prefix value of the first MN-RO Option to HNP for
   MN and Proxy-CoA value to Proxy-CoA1.  The LMA sets Home Network
   Prefix value of the second MN-RO Option to HNP of CN and Proxy-CoA
   value to zero.

A.1.2.  LMA Route Optimization Start Response Message

                                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                     |       Sequence Number         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |         Reserved              |            Lifetime           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     .                                                               .
     .                        Mobility options                       .
     .                                                               .
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        Figure A.1.2. LMA Route Optimization Start Response Message

   A new MH type should be assigned by IANA.

   Status  An 8-bit unsigned integer indicating the disposition of
      LMAROStartReq message by the receiving LMA.  Values less than 128
      indicate that ROStartReq message was accepted by the LMA.  Values
      greater than 128 indicate that LMAROStartReq message was rejected
      by LMA.


      Sequence number and Lifetime fields are as defined above for
      LMAROStartReq message.


   Mobility Options  contain pairs of MN-CN RO Option as defined in
      Section 9.4.  The LMA must copy this field from LMAROStartReq
      message when status field contains a value indicating success.
      The LMA MUST search its binding cache for the Home Network Prefix
      value of CN and find the corresponding MAG address, e.g.  Proxy-
      CoA2.  Th LMA MUST replace MAG address field set to zero by the
      sending LMA with Proxy- CoA2.






Wu & Sarikaya            Expires August 16, 2010               [Page 29]

Internet-Draft      PMIPv6 Local Routing Optimization      February 2010


A.2.  LMA Initiated Inter-LMA Local Routing

   The message exchange for the protocol is shown in Figure A.2.  Inter-
   LMA Local routing is triggered at one of the LMAs, e.g.  LMA1 when a
   datagram is received on its upstream interface whose destination
   address is a MN, e.g.  MN1 for which LMA1 has a binding cache entry.
   From the binding cache entry, LMA1 determines the MAG address, e.g.
   MAG1 (Proxy-CoA1).  LMA1 checks the source address to find out if the
   datagram is coming from a MN located in the same Provider domain and
   if yes, its MAG address, e.g.  MAG2 (Proxy-CoA2).  There are several
   ways for doing this and the exact means is out of scope with the
   document.  Below we will mention two different ways.

   (a)  LMAs in the same Provider domain are configured with a table
        containing a list of /48, /32, etc. prefixes and the
        corresponding LMA address for all the LMAs in the domain.  LMA1
        searches this table doing a longest prefix match based on the
        prefix part of the source address of MN2 and finds the
        corresponding LMA2 address.

   (b)  LMA1 can exchange with the AAA server to retrieve LMA2 address.
        LMA1 sends MN2 address and asks LMA address this MN is attached
        to.  LMA1 receives LMA2 address and MAG address (Proxy-CoA2)
        from AAA server, e.g.DIAMETER server.

   LMA1 sends LMAROStartRequest message to LMA2.  LMAROStartRequest
   message contains MN1 and MN2 address and MAG1 address (Proxy-CoA1).
   MAG2 address is set to zero.  LMA2 searches its BCE for MN2 and
   determines MAG2 address (Proxy-CoA2).  LMA2 sends LMAROStartResponse
   message to LMA1.  LMAROStartResponse message contains MN1 and MN2
   address and MAG1 address (Proxy-CoA1) and MAG2 address (Proxy-CoA2).

   LMA1 sends LROREQ message to MAG1 at Proxy-CoA1.  LROREQ message
   contains MN address and Proxy- CoA1 and CN address, e.g.  MN2 and
   Proxy-CoA2.  LMA2 sends LROREQ message to MAG2 at Proxy-CoA2.  LROREQ
   message contains CN address, e.g.  MN2 and Proxy-CoA2 and MN address,
   e.g.  MN1 and Proxy-CoA1.  LROREQ messages enable both MAGs to modify
   their Binding Update Lists.  The two MAGs respond LROREQ with LRORSP
   messages.

   The two MAGs, MAG1 and MAG2 exchange PBU/PBAs as described in
   Section 4.









Wu & Sarikaya            Expires August 16, 2010               [Page 30]

Internet-Draft      PMIPv6 Local Routing Optimization      February 2010


         +------+        +----------+    +---------+       +------+
         | MAG1 |        | LMA1(MN) |    |LMA2(CN) |       | MAG2 |
         +---+--+        +----+-----+    +----+----+       +---+--+
             |                |               |                |
             |                | LMAROStartReq |                |
             |                |-------------->|                |
             |                |               |                |
             |                | LMARoStartRsp |                |
             |                |<------------- |                |
             |     LROREQ     |               |     LROREQ     |
             |<---------------|               |--------------->|
             |                |               |                |
             |     LRORSP     |               |     LRORSP     |
             |--------------->|               |<-------------- |
             |                |               |                |
             |<--------------MAGs exchange PBU/PBA------------>|
             |                |               |                |
             |                |               |                |
             Figure A.2. LMA Initiated Inter-LMA Local routing


A.2.1.  IPv4 Support Consideration

   IPv4 support presented in Section 6 also applies here.  In addition,
   we discuss IPv4 support issues related to LMAROStartRequest and
   LMAStartResponse messages.  LMAROStartRequest and LMAStartResponse
   messages are IPv6 messages.  These messages are transported in IPv6
   because LMAs support IPv6 and there is IPv6 transport established
   among LMAs in the same Provider domain.

A.3.  LMA Initiated operation for Inter-LMA Local Routing

   Local mobility anchor MUST send LMAROStartReq message to another
   local mobility anchor in the same Provider domain.  LMAROStartReq
   message MUST contain at least one pair of MN-CN RO Option.  Local
   mobility anchor MUST place the mobile node address information which
   is connected to this local mobility anchor first in MN-CN RO Option.

   Local mobility anchor MAY set lifetime field in LMAROStartReq message
   to a non zero value.  Any nonzero lifetime value enables the
   receiving local mobility anchor to start local routing optimization
   for MN-CN traffic by sending LROReq message to the mobility access
   gateway to which CN is connected as the local mobility anchor
   determines by searching its binding cache.

   After receiving LRORes from the mobile access gateway, the local
   mobility anchor MUST send LMAROStartRes to the originating local
   mobility anchor.  LMAROStartRes MUST contain MN-CN Option RO pair in



Wu & Sarikaya            Expires August 16, 2010               [Page 31]

Internet-Draft      PMIPv6 Local Routing Optimization      February 2010


   which the first contains MN and its mobility access gateway address
   info which is copied from LMAROStartReq message and the second
   contains CN address which is copies from LMAROStartReq and its
   mobility access gateway address which this local mobility gateway
   provides.

   Local mobility anchor MAY set lifetime field in LMAROStartRes to the
   same value as LMAROStartReq lifetime field value.  Local mobility
   anchor MAY set lifetime field in LMAROStartRes to a different value.
   The lifetime field in LMAROStartRes becomes the final value and local
   mobility anchor MUST set lifetime value in LROReq message that it
   sends to MN's mobility access gateway.

   In case the simplified route optimization involves two local mobility
   gateways, the initiating local mobility anchor MAY stop the route
   optimization any time it wishes.  The initiating local mobility
   anchor MUST send LMAROStartReq message to the destination local
   mobility anchor with lifetime field set to zero.  The destination
   local mobility anchor sends LMAROStartRes with lifetime set to zero.
   Both local mobility anchors send LROReq messages to the corresponding
   mobility access gateways with lifetime set to zero.  Both local
   mobility anchors reestablish the tunnel with mobility access gateways
   for MN and CN, respectively.

   Local mobility anchor sets the sequence number field in LMAROStartReq
   message to a nonzero integer.  This initial sequence number is
   incremented by one for the next LMAROStartReq message sent.  Local
   mobility anchor MUST receive LMAROStartRes message with the same
   sequence number as in LMAROStartReq message previously sent.  This
   message acknowledges LMAROStartReq message.  If no ack is received
   local mobility anchor MUST retransmit LMAROStartReq message.  In a
   normal mode of operation local mobility anchor has one outstanding
   LMAROStartReq messages because they are sent to the other local
   mobility anchor in the same Provider domain.


Appendix B.  Change Notes

   Changes in version 04.


   o  Move LMA Initiated inter-LMA local routing to appendix A

   o  Some Editorial Revision.

   o  Additional text about MAG operation and LMA operation in section 5
      and appendix A.3.




Wu & Sarikaya            Expires August 16, 2010               [Page 32]

Internet-Draft      PMIPv6 Local Routing Optimization      February 2010


   o  Remove NAT Aspect and private IPv4 aspect in this document.

   o  Additional text about Routing Table extension and Bulk localized
      routing Flag.

   Changes in version 05.


   o  Some Editorial changes.

   o  Consistent with I-D.ietf-netext-pmip6-lr-ps on terminology using

   o  Incorporate prefix ownsership validation into the section of
      "security consideration".


Authors' Addresses

   Qin Wu
   Huawei Technologies Co.,Ltd
   Site B, Floor 12F, Huihong Mansion, No.91 Baixia Rd.
   Nanjing, Jiangsu  21001
   China

   Phone: +86-25-84565892
   Email: Sunseawq@huawei.com


   Behcet Sarikaya
   Huawei Technologies Co.,Ltd
   1700 Alma Drive, Suite 500
   Plano, TX  75075
   USA

   Email: sarikaya@ieee.org
















Wu & Sarikaya            Expires August 16, 2010               [Page 33]