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

Versions: (draft-krishnan-netext-pmip-lr) 00 01 02 03 04 05 06 07 08 09 10 RFC 6705

Netext WG                                                    S. Krishnan
Internet-Draft                                                  Ericsson
Intended status: Standards Track                               R. Koodli
Expires: November 8, 2012                                  Cisco Systems
                                                             P. Loureiro
                                                                     NEC
                                                                   Q. Wu
                                                                  Huawei
                                                                A. Dutta
                                                                  NIKSUN
                                                             May 7, 2012


                Localized Routing for Proxy Mobile IPv6
                      draft-ietf-netext-pmip-lr-09

Abstract

   Proxy Mobile IPv6 (PMIPv6) is a network based mobility management
   protocol that enables IP mobility for a host without requiring its
   participation in any mobility-related signaling.  PMIPv6 requires all
   communications to go through the local mobility anchor.  As this can
   be suboptimal, localized routing (LR) allows mobile nodes attached to
   the same or different mobile access gateways to route traffic by
   using localized forwarding or a direct tunnel between the gateways.
   This document proposes initiation, utilization and termination
   mechanisms for localized routing between mobile access gateways
   within a proxy mobile IPv6 domain.  It defines two new signaling
   messages, Localized Routing Initiation (LRI) and Local Routing
   Acknowledgment (LRA), that are used to realize this mechanism.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

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

   This Internet-Draft will expire on November 8, 2012.




Krishnan, et al.        Expires November 8, 2012                [Page 1]

Internet-Draft          PMIPv6 Localized Routing                May 2012


Copyright Notice

   Copyright (c) 2012 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 Simplified BSD License.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Initiation of Localized Routing  . . . . . . . . . . . . . . .  5
     2.1.  MAG behavior . . . . . . . . . . . . . . . . . . . . . . .  5
     2.2.  LMA behavior . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Teardown of Localized Routing  . . . . . . . . . . . . . . . .  6
   4.  Conventions used in this document  . . . . . . . . . . . . . .  7
   5.  Scenario A11: Two MNs attached to the same MAG and LMA . . . .  8
     5.1.  Handover Considerations  . . . . . . . . . . . . . . . . . 10
   6.  Scenario A21: Two MNs attached to different MAGs but same
       LMA  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     6.1.  Handover Considerations  . . . . . . . . . . . . . . . . . 13
     6.2.  Tunneling between the MAGs . . . . . . . . . . . . . . . . 13
   7.  Scenario A12: Two MNs attached to the same MAG with
       different LMAs . . . . . . . . . . . . . . . . . . . . . . . . 15
     7.1.  Handover Considerations  . . . . . . . . . . . . . . . . . 16
   8.  Scenario A22: Two MNs attached to different MAGs with
       different LMAs . . . . . . . . . . . . . . . . . . . . . . . . 17
   9.  IPv4 support in Localized Routing  . . . . . . . . . . . . . . 18
   10. Message Formats  . . . . . . . . . . . . . . . . . . . . . . . 19
     10.1. Localized Routing Initiation (LRI) . . . . . . . . . . . . 19
     10.2. Localized Routing Acknowledgment (LRA) . . . . . . . . . . 20
   11. New Mobility Option  . . . . . . . . . . . . . . . . . . . . . 22
     11.1. MAG IPv6 Address . . . . . . . . . . . . . . . . . . . . . 22
   12. Configuration Variables  . . . . . . . . . . . . . . . . . . . 23
   13. Security Considerations  . . . . . . . . . . . . . . . . . . . 24
   14. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 25
   15. Authors  . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
   16. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 27
   17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
     17.1. Normative References . . . . . . . . . . . . . . . . . . . 28



Krishnan, et al.        Expires November 8, 2012                [Page 2]

Internet-Draft          PMIPv6 Localized Routing                May 2012


     17.2. Informative References . . . . . . . . . . . . . . . . . . 28
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29

















































Krishnan, et al.        Expires November 8, 2012                [Page 3]

Internet-Draft          PMIPv6 Localized Routing                May 2012


1.  Introduction

   Proxy Mobile IPv6 [RFC5213] describes the protocol operations to
   maintain reachability and session persistence for a Mobile Node (MN)
   without the explicit participation from the MN in signaling
   operations at the Internet Protocol (IP) layer.  In order to
   facilitate such network-based mobility, the PMIPv6 protocol defines a
   Mobile Access Gateway (MAG), which acts as a proxy for the Mobile
   IPv6 [RFC6275] signaling, and the Local Mobility Anchor (LMA) which
   acts similar to a Home Agent.  The LMA and the MAG establish a
   bidirectional tunnel for forwarding all data traffic belonging to the
   Mobile Nodes.  In the case where both endpoints are located in the
   same PMIPv6 domain, this can be suboptimal and results in higher
   delay and congestion in the network.  Moreover, it increases
   transport costs and traffic load at the LMA.

   To overcome these issues, localized routing can be used to allow
   nodes attached to the same or different MAGs to directly exchange
   traffic by using localized forwarding or a direct tunnel between the
   gateways.  [RFC6279] defines the problem statement for PMIPv6
   localized routing.  This document describes a solution for PMIPv6
   localized routing between two MNs in the same PMIPv6 domain.  The
   protocol specified here assumes that each MN is attached to a MAG and
   that each MN's MAG has established a binding for the attached MN at
   its selected LMA according to [RFC5213].  The protocol builds on the
   scenarios defined in [RFC6279].

























Krishnan, et al.        Expires November 8, 2012                [Page 4]

Internet-Draft          PMIPv6 Localized Routing                May 2012


2.  Initiation of Localized Routing

   Since the traffic to be localized passes through both the LMA and the
   MAGs, it is possible, at least in some scenarios, for either of them
   to initiate Localized Routing (LR).  In order to eliminate ambiguity,
   the protocol described in this document selects the initiator of the
   LR based on the following rules.

2.1.  MAG behavior

   The MAG MUST initiate LR if both the communicating MNs are attached
   to it and the MNs are anchored at different LMAs.  The MAG MUST NOT
   initiate LR in any other case.

2.2.  LMA behavior

   The LMA MUST initiate LR if both the communicating MNs are anchored
   to it.  The LMA MUST NOT initiate LR in any other case.

































Krishnan, et al.        Expires November 8, 2012                [Page 5]

Internet-Draft          PMIPv6 Localized Routing                May 2012


3.  Teardown of Localized Routing

   The use of localized routing is not persistent.  Localized routing
   has a defined lifetime as specified by the initiator, upon the expiry
   of which, the forwarding MUST revert to using bidirectional
   tunneling.  When localized routing ceases, the corresponding LRE
   entries MUST be removed.

   If the initiator of LR wishes to terminate localized routing before
   the expiry of the lifetime specified in the LRI message, it MUST do
   so by sending a new LRI message with the lifetime set to zero.








































Krishnan, et al.        Expires November 8, 2012                [Page 6]

Internet-Draft          PMIPv6 Localized Routing                May 2012


4.  Conventions used in this document

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

   This document also uses the terminology defined in Section 2 of
   [RFC6279].











































Krishnan, et al.        Expires November 8, 2012                [Page 7]

Internet-Draft          PMIPv6 Localized Routing                May 2012


5.  Scenario A11: Two MNs attached to the same MAG and LMA

   In this scenario, the two Mobile Nodes involved in communication are
   attached to a single MAG and both are anchored at the same LMA as
   shown in Figure 1.

                        Internet
                           :
                           |
                           |
                        +-----+
                        | LMA |
                        +-----+
                           |
                           |
                           |
                        +-----+
                        | MAG |
                        +-----+
                         :   :
                      +---+ +---+
                      |MN1| |MN2|
                      +---+ +---+

                                 Figure 1

   The LMA initiates a localized routing session by detecting traffic
   between two MNs attached to the same MAG.  The exact traffic
   identification mechanism is not specified in this document, and is
   left open for implementations and specific deployments.  An example
   trigger could be that an application-layer signaling entity detects
   the possibility of localized routing and notifies the LMA about the
   two end-points, and the LMA determines that the two end-points are
   attached to the same MAG.  Such a trigger mechanism offers localized
   routing at the granularity of an individual application session,
   providing flexibility in usage.  It is also possible that one of the
   mobility entities (LMA or MAG) could decide to initiate localized
   routing based on configured policy.  Please note that a MAG
   implementing the protocol specified in this specification will not
   dynamically initiate LR in the same LMA case (i.e. by sending an
   LRI), but can statically initiate LR based on the
   EnableMAGLocalRouting configuration variable specified in [RFC5213].









Krishnan, et al.        Expires November 8, 2012                [Page 8]

Internet-Draft          PMIPv6 Localized Routing                May 2012


   +----+      +----+      +----+          +----+
   |MN1 |      |MN2 |      |MAG1|          |LMA |
   +----+      +----+      +----+          +----+
     |           |           |               |
     |        data           |     data      |
     |<--------------------->|<------------->|
     |           |           |               |
     |           |    data   |     data      |
     |           |<--------->|<------------->|
     |           |           |          LR decision
     |           |           |  LRI(Opt1)    |
     |           |           |<--------------|
     |           |           |               |
     |           |           |  LRA(Opt2)    |
     |           |           |-------------->|
     |           |           |               |
     |        data           |               |
     |<--------------------->|               |
     |           |           |               |
     |           |   data    |               |
     |           |<--------->|               |
     |           |           |               |
     |           |           |               |

   Opt1: MN1-ID,MN1-HNP,MN2-ID,MN2-HNP
   Opt2: U=0,MN1-ID,MN1-HNP,MN2-ID,MN2-HNP

   where U is the flag defined in Section 9.1 and 9.2.

                                 Figure 2

   After detecting a possibility for localized routing, the LMA SHOULD
   construct a Localized Routing Initiation (LRI) message that is used
   to signal the intent to initiate localized routing and to convey
   parameters for the same.  This is a Mobility Header message and it
   MUST contain the MN-Identifier and the Home Network Prefix (as
   Mobility Header options) for each of the MNs involved.  The LMA MUST
   then send the LRI message to the MAG (MAG1) where the two MNs are
   attached as shown in Figure 2.

   The MAG (MAG1) MUST verify the attachment status of the two MNs
   locally by checking the binding cache.  The MAG MUST then verify if
   the EnableMAGLocalRouting flag is set to 1.  If it is not, the MAG
   has not been configured to allow localized routing and it MUST reject
   the LRI and MUST send an LRA with status code "Localized Routing Not
   Allowed".  Please note that this does not update behavior specified
   in [RFC5213] but merely implements the LMA enforcement specified in
   Section 6.10.3. of [RFC5213].  If MAG is configured to allow



Krishnan, et al.        Expires November 8, 2012                [Page 9]

Internet-Draft          PMIPv6 Localized Routing                May 2012


   localized routing it MUST then create Localized Routing Entries
   (LREs) for each direction of the communication between the two MNs.
   The exact form of the forwarding entries is left for the
   implementations to decide; however, they SHOULD contain the Home
   Network Prefix (HNP) corresponding to the destination IP address and
   a next-hop identifier (e.g. the layer 2 address of the next hop).
   These LREs MUST override the Binding Update List(BUL) entries for the
   specific HNPs identified in the LRI message.  Hence all traffic
   matching the HNPs is forwarded locally.

   If the MAG is unable to deliver packets using the LREs, it is
   possible that one of the MNs is no longer attached to the MAG.
   Hence, the MAG MUST fall back to using the BUL entry, and the LMA
   MUST forward the received packets using its Binding Cache Entry
   (BCE).

   After processing the LRI message the MAG MUST respond with a Local
   Routing Acknowledgment (LRA) message.  This Mobility Header message
   MUST also include the MN-ID and the HNP for each of the communicating
   MNs as well as an appropriate Status code indicating the outcome of
   LRI processing.  Status code 0 indicates localized routing was
   successfully offered by the MAG.  Any other value for Status code
   indicates the reason for the failure to offer localized routing
   service.  When Status code is 0, the LMA sets a flag in the BCE
   corresponding to the HNPs to record that localized routing is in
   progress for that HNP.

5.1.  Handover Considerations

   If one of the MNs, say MN1, detaches from the MAG and attaches to
   another MAG (say nMAG) the localized routing state needs to be re-
   established.  When the LMA receives the PBU from nMAG for MN1, it
   will see that localized routing is active for MN1.  It MUST hence
   initiate LR at nMAG and update the LR state of MAG.  After the
   handover completes, the localized routing will resemble Scenario A21.
   The pMAG MUST follow the forwarding rules described in Section 6.10.5
   of [RFC5213] and decide that it will no longer perform LR for MN1.














Krishnan, et al.        Expires November 8, 2012               [Page 10]

Internet-Draft          PMIPv6 Localized Routing                May 2012


6.  Scenario A21: Two MNs attached to different MAGs but same LMA

   The LMA may choose to support local forwarding to mobile nodes
   attached to two different MAGs within a single PMIPv6 domain.

                        Internet
                           :
                           |
                           |
                        +-----+
                        | LMA |
                        +-----+
                           |
                           |
                      +----+-----+
                      |          |
                   +----+     +----+
                   |MAG1|     |MAG2|
                   +----+     +----+
                     :           :
                   +---+       +---+
                   |MN1|       |MN2|
                   +---+       +---+

                                 Figure 3

   As earlier, the LMA initiates LR as a response to some trigger
   mechanism.  In this case, however, it MUST send two separate LRI
   messages to the two MAGs.  In addition to the MN-ID and the HNP
   options, each LRI message MUST contain the IP Address of the
   counterpart MAG.  When the MAG IP Address option is present, each MAG
   MUST create a local forwarding entry such that the packets for the MN
   attached to the remote MAG are sent over a tunnel associated with
   that remote MAG.  The tunnel between the MAGs is assumed to be
   established following the considerations mentioned in Section 6.2.
















Krishnan, et al.        Expires November 8, 2012               [Page 11]

Internet-Draft          PMIPv6 Localized Routing                May 2012


   +----+      +----+      +----+      +----+        +----+
   |MN1 |      |MN2 |      |MAG1|      |MAG2|        |LMA |
   +----+      +----+      +----+      +----+        +----+
     |           |           |           |             |
     |        data           |          data           |
     |<--------------------->|<----------------------->|
     |           |           |           |             |
     |           |         data          |    data     |
     |           |<--------------------->|<----------->|
     |           |           |           |             |
     |           |           |           |             |
     |           |           |       LRI(Opt1)         |
     |           |           |<------------------------|
     |           |           |           |             |
     |           |           |           |  LRI(Opt2)  |
     |           |           |           |<------------|
     |           |           |           |             |
     |           |           |        LRA(Opt3)        |
     |           |           |------------------------>|
     |           |           |           |             |
     |           |           |           |   LRA(Opt4) |
     |           |           |           |------------>|
     |           |           |           |             |
     |           |           |           |             |
     |           |           |           |             |
     |        data           |    data   |             |
     |<--------------------->|<--------->|             |
     |           |           |           |             |
     |           |         data          |             |
     |           |<--------------------->|             |
     |           |           |           |             |
     |           |           |           |             |

   Opt1: MN1-ID,MN1-HNP,MAG2-IPv6-Address
   Opt2: MN2-ID,MN2-HNP,MAG1-IPv6-Address
   Opt3: U=0,MN1-ID,MN1-HNP,MAG2-IPv6-Address
   Opt4: U=0,MN2-ID,MN2-HNP,MAG1-IPv6-Address

   where U is the flag defined in Section 9.1 and 9.2.

                                 Figure 4

   In this case, each MAG responds to the LRI with an LRA message.  All
   subsequent packets are routed between the MAGs locally, without
   traversing the LMA.  If one of the MAGs (say MAG1) responds with a
   successful LRA (Status value is zero) and the other (say
   MAG2)responds with an error (Status value is non-zero) LR will still
   be performed in one direction (MN1->MAG1->MAG2->MN2), but the packets



Krishnan, et al.        Expires November 8, 2012               [Page 12]

Internet-Draft          PMIPv6 Localized Routing                May 2012


   flowing the other way will take the LMA path
   (MN2->MAG2->LMA->MAG1->MN1).

   The protocol does not require any synchronization between the MAGs
   before local forwarding begins.  Each MAG begins its local forwarding
   independent of the other.

   No synchronization between MAGs is required because each MAG
   initiates LR in one direction.  After the LMA instructs MAG1 to
   initiate LR, packets from MN1 to MN2 will take the path
   MN1->MAG1->MAG2->MN2 while those from MN2 to MN1 will take the path
   MN2->MAG2->LMA->MAG1->MN1 until LMA instructs MAG2 to do so as well.
   At any instant a MAG will forward a packet either towards another MAG
   or its own LMA and hence there would be no duplication of packets.

6.1.  Handover Considerations

   If one of the MNs, say MN1, detaches from its current MAG (in this
   case MAG1) and attaches to another MAG (say nMAG1) the localized
   routing state needs to be re-established.  When the LMA receives the
   PBU from nMAG1 for MN1, it will see that localized routing is active
   for MN1.  The LMA MUST then initiate LR at nMAG1 and update the LR
   state of MAG2 to use nMAG1 instead of MAG1.

6.2.  Tunneling between the MAGs

   In order to support localized routing both MAGs SHOULD support the
   following encapsulation modes for the user packets, which are also
   defined for the tunnel between the LMA and MAG:

   o  IPv4-or-IPv6-over-IPv6 [RFC5844]

   o  IPv4-or-IPv6-over-IPv4 [RFC5844]

   o  IPv4-or-IPv6-over-IPv4-UDP [RFC5844]

   o  TLV-header UDP tunneling [RFC5845]

   o  Generic Routing Encapsulation (GRE) tunneling with or without GRE
      key(s) [RFC5845]

   MAG1 and the MAG2 MUST use the same tunneling mechanism for the data
   traffic tunneled between them.  The encapsulation mode to be employed
   SHOULD be configurable.  It is RECOMMENDED that:

   1.  As the default behavior, the inter-MAG tunnel uses the same
       encapsulation mechanism as that being used for the PMIPv6 tunnel
       between the LMA and the MAGs.  MAG1 and MAG2 automatically start



Krishnan, et al.        Expires November 8, 2012               [Page 13]

Internet-Draft          PMIPv6 Localized Routing                May 2012


       using the same encapsulation mechanism without a need for a
       special configuration on the MAGs or a dynamic tunneling
       mechanism negotiation between them.

   2.  Configuration on the MAGs can override the default mechanism
       specified in Option 1 above.  MAG1 and MAG2 MUST be configured
       with the same mechanism, and this configuration is most likely to
       be uniform throughout the PMIPv6 domain.  If the packets on the
       PMIPv6 tunnel cannot be uniquely mapped on to the configured
       inter-MAG tunnel, this scenario is not applicable, and Option 3
       below SHOULD directly be applied.

   3.  An implicit or explicit tunnel negotiation mechanism between the
       MAGs can override the default mechanism specified in Option 1
       above.  The employed tunnel negotiation mechanism is outside the
       scope of this document.



































Krishnan, et al.        Expires November 8, 2012               [Page 14]

Internet-Draft          PMIPv6 Localized Routing                May 2012


7.  Scenario A12: Two MNs attached to the same MAG with different LMAs

   In this scenario, both the MNs are attached to the same MAG, but are
   anchored at two different LMAs.  MN1 is anchored at LMA1 and MN2 is
   anchored at LMA2.  Note that the two LMAs are part of the same
   Provider Domain.


                        Internet
                  :                  :
                  +------------------+
                  |                  |
               +----+              +----+
               |LMA1|              |LMA2|
               +----+              +----+
                  |                  |
                  |                  |
                  +------------------+
                           |
                           |
                           |
                        +-----+
                        | MAG |
                        +-----+
                         :   :
                      +---+ +---+
                      |MN1| |MN2|
                      +---+ +---+

                                 Figure 5

   Hence, neither LMA has a means to determine that the two Mobile Nodes
   are attached to the same MAG.  Only the MAG can possibly determine
   that the two Mobile Nodes involved in communication are attached to
   it.  Therefore, the localized routing MUST be initiated by the MAG.

   The MAG sends an LRI message containing the MN-ID, HNP and the
   counterpart LMA address to each LMA.  Each LMA makes decision to
   support local forwarding independently, based on, among others,
   policy configuration for the counterpart LMA.  Each LMA MUST respond
   to the LRI message with an LRA message.  If the initiation of LR on
   the LMA was successful, the Status value in the received LRA would be
   set to zero.  After the MAG receives both the LRA messages each with
   Status value set to zero (success) from the two different LMAs, the
   MAG will conclude that it can provide local forwarding support for
   the two Mobile Nodes.





Krishnan, et al.        Expires November 8, 2012               [Page 15]

Internet-Draft          PMIPv6 Localized Routing                May 2012


   +----+      +----+      +----+      +----+        +----+
   |MN1 |      |MN2 |      |MAG |      |LMA1|        |LMA2|
   +----+      +----+      +----+      +----+        +----+
     |           |           |           |             |
     |        data           |   data    |    data     |
     |<--------------------->|<--------->|<----------->|
     |           |           |           |             |
     |           |   data    |          data           |
     |           |<--------->|<----------------------->|
     |           |           |           |             |
     |           |           |           |             |
     |           |           | LRI(Opt1) |             |
     |           |           |---------->|             |
     |           |           |           |             |
     |           |           |        LRI(Opt2)        |
     |           |           |------------------------>|
     |           |           |           |             |
     |           |           | LRA(Opt3) |             |
     |           |           |<----------|             |
     |           |           |           |             |
     |           |           |        LRA(Opt4)        |
     |           |           |<------------------------|
     |           |           |           |             |
     |           |           |           |             |
     |           |           |           |             |
     |        data           |           |             |
     |<--------------------->|           |             |
     |           |           |           |             |
     |           |    data   |           |             |
     |           |<--------->|           |             |
     |           |           |           |             |
     |           |           |           |             |

   Opt1: MN1-ID,MN1-HNP
   Opt2: MN2-ID,MN2-HNP
   Opt3: U=0,MN1-ID,MN1-HNP
   Opt4: U=0,MN2-ID,MN2-HNP

   where U is the flag defined in Section 9.1 and 9.2.

                                 Figure 6

7.1.  Handover Considerations

   If one of the MNs, say MN1, detaches from its current MAG (in this
   case MAG1) and attaches to another MAG (say nMAG1), the current MAG
   MUST immediately stop using the LRE and MUST send all packets
   originated by the other MN (MN2) towards its LMA (in this case LMA2).



Krishnan, et al.        Expires November 8, 2012               [Page 16]

Internet-Draft          PMIPv6 Localized Routing                May 2012


8.  Scenario A22: Two MNs attached to different MAGs with different LMAs

   This scenario will not be covered in this document since PMIPv6 does
   not define any form of inter-LMA communications.  When a supported
   scenario, such as Scenario A12, morphs into Scenario A22 the node
   that initiated the localized routing session MUST tear it down in
   order to prevent lasting packet loss.  This can result in transient
   packet loss when routing switches between the localized path into the
   normal path through the LMAs.  In applications that are loss
   sensitive, this can lead to observable service disruptions.  In
   deployments where Scenario A22 is possible, the use of localized
   routing is NOT RECOMMENDED when packet-loss-sensitive applications
   are in use.






































Krishnan, et al.        Expires November 8, 2012               [Page 17]

Internet-Draft          PMIPv6 Localized Routing                May 2012


9.  IPv4 support in Localized Routing

   PMIPv6 MNs can use an IPv4 HoA as described in [RFC5844].  In order
   to support the setup and maintenance of localized routes for these
   IPv4 HoAs in PMIPv6, MAGs MUST add the IPv4 HoAs into their LREs.
   The MAGs MUST also support encapsulation of IPv4 packets as described
   in [RFC5844].  The localized routing protocol messages MUST include a
   IPv4 HoA option in their signaling messages in order to support IPv4
   addresses for localized routing.

   If the transport network between the PMIPv6 entities involved in
   localized routing is IPv4-only, the LRI and LRA messages MUST be
   encapsulated similar to the PBU/PBA messages as specified in
   [RFC5844].  The encapsulation mode used SHOULD be identical to the
   one used to transport PBU and PBA messages.




































Krishnan, et al.        Expires November 8, 2012               [Page 18]

Internet-Draft          PMIPv6 Localized Routing                May 2012


10.  Message Formats

   The Localized routing messages use two new mobility header type (TBA1
   and TBA2).  The LRI message requests creation or deletion of
   localized routing state and the LRA message acknowledges the creation
   or deletion of such localized routing state.

10.1.  Localized Routing Initiation (LRI)

   The LRI messages uses a new mobility header type (TBA1).  The LMA
   sends an LRI message to a MAG to request local forwarding for a pair
   of MNs.  The MAG may also send this message to request the two LMAs
   for offering local forwarding as described in Section 7 .

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                       |           Sequence #          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         Reserved              |           Lifetime            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       .                                                               .
       .                        Mobility options                       .
       .                                                               .
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

       Reserved: This field is unused.  MUST be set zero.

       Lifetime: The requested time in seconds for which the sender
       wishes to have local forwarding. A value of 0xffff (all ones)
       indicates an infinite lifetime. When set to 0, indicates a
       request to stop localized routing.

       Mobility Options: MUST contain two separate MN-ID options,
       followed by one or more HNPs for each of the MNs.  For instance,
       for Mobile Nodes MN1 and MN2 with identifiers MN1-ID, MN2-ID and
       Home Network Prefixes MN1-HNP and MN2-HNP, the following tuple
       in the following order MUST be present: [MN1-ID, MN1-HNP],
       [MN2-ID, MN2-HNP].  The MN-ID and HNP options are the same as in
       [RFC5213].  MAY contain the remote MAG IPv6 address option,
       which is formatted identically to the HNP option, except that it
       uses a different Type code and the Prefix Length is always equal



Krishnan, et al.        Expires November 8, 2012               [Page 19]

Internet-Draft          PMIPv6 Localized Routing                May 2012


       to 128 bits (see Section 10.1).

   The LRI message SHOULD be re-transmitted if a corresponding LRA
   message is not received within LRA_WAIT_TIME time units, up to a
   maximum of LRI_RETRIES, each separated by LRA_WAIT_TIME time units.

10.2.  Localized Routing Acknowledgment (LRA)

   The LRA messages uses a new mobility header type (TBA2).  A MAG sends
   an LRA message to the LMA as a response to the LRI message.  An LMA
   may also send this message to a MAG as a response to the LRI message
   as described in Section 7 .







































Krishnan, et al.        Expires November 8, 2012               [Page 20]

Internet-Draft          PMIPv6 Localized Routing                May 2012


        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 #          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |U|  Reserved   |   Status      |           Lifetime            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       .                                                               .
       .                        Mobility options                       .
       .                                                               .
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


       Sequence Number: is copied from the sequence number field of the
       LRI message being responded to.

       'U' flag: When set to 1, the LRA message is sent unsolicited.
       The Lifetime field indicates a new requested value.  The MAG MUST
       wait for the regular LRI message to confirm that the request is
       acceptable to the LMA.

       Reserved: This field is unused.  MUST be set zero.

       Status:

          0: Success

          128: Localized Routing Not Allowed
          129: MN not attached

       Lifetime: The time in seconds for which the local forwarding is
       supported.  Typically copied from the corresponding field in the
       LRI message.

       Mobility Options: When Status code is 0, MUST contain the
       [MN-ID, HNP] tuples in the same order as in the LRI message.
       When Status code is not 0, MUST contain only those [MN-ID, HNP]
       tuples for which local forwarding is supported.  The MN-ID and
       HNP options are the same as in [RFC5213].










Krishnan, et al.        Expires November 8, 2012               [Page 21]

Internet-Draft          PMIPv6 Localized Routing                May 2012


11.  New Mobility Option

11.1.  MAG IPv6 Address

   The MAG IPv6 address mobility option contains the IPv6 address of a
   MAG involved in the localized routing.  The MAG IPv6 address option
   has an alignment requirement of 8n+4.

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |      Type     |   Length      |   Reserved    | Address Length|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +                                                               +
       |                                                               |
       +                       MAG IPv6 Address                        +
       |                                                               |
       +                                                               +
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Type
            TBA3

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

        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.

        Address Length

            This field MUST be set to 128.

        MAG IPv6 Address

            A 16 byte field containing the MAG's IPv6 Address.







Krishnan, et al.        Expires November 8, 2012               [Page 22]

Internet-Draft          PMIPv6 Localized Routing                May 2012


12.  Configuration Variables

   The LMA and the MAG must allow the following variables to be
   configurable.

   LRA_WAIT_TIME:  This variable is used to set the time interval in
      seconds between successive retransmissions of an LRI message.  The
      default value is 3 seconds.

   LRI_RETRIES:  This variable indicates the maximum number of times the
      initiator retransmits an LRI message before stopping.  The default
      value for this variable is 3.







































Krishnan, et al.        Expires November 8, 2012               [Page 23]

Internet-Draft          PMIPv6 Localized Routing                May 2012


13.  Security Considerations

   The protocol inherits the the threats to [RFC5213] that are
   identified in [RFC4832].  The protocol specified in this document
   uses the same security association as defined in [RFC5213] for use
   between the LMA and the MAG to protect the LRI and LRA messages.
   This document also assumes the pre-existence of a MAG-MAG security
   association if LR needs to be supported between them.  Support for
   integrity protection using IPsec is REQUIRED, but support for
   confidentiality is OPTIONAL.  The MAGs MUST perform ingress filtering
   on the MN sourced packets before encapsulating them into MAG-MAG
   tunnels in order to prevent address spoofing.







































Krishnan, et al.        Expires November 8, 2012               [Page 24]

Internet-Draft          PMIPv6 Localized Routing                May 2012


14.  IANA Considerations

   The Localized Routing Initiation, described in Section 10.1 and the
   Localized Routing Acknowledgment, described in Section 10.2 each
   require a Mobility Header Type (TBA1 and TBA2) from the Mobility
   Header Types registry at
   http://www.iana.org/assignments/mobility-parameters

   The MAG IPv6 Address requires a Mobility Option Type (TBA3) from the
   Mobility Options registry at
   http://www.iana.org/assignments/mobility-parameters








































Krishnan, et al.        Expires November 8, 2012               [Page 25]

Internet-Draft          PMIPv6 Localized Routing                May 2012


15.  Authors

   This draft merges ideas from five different drafts addressing the
   PMIP localized routing problem.  The authors of these drafts are
   listed below (in alphabetical order)

      Kuntal Chowdhury <kchowdhury@starentnetworks.com>

      Ashutosh Dutta <adutta@niksun.com>

      Rajeev Koodli <rkoodli@starentnetworks.com>

      Suresh Krishnan <suresh.krishnan@ericsson.com>

      Marco Liebsch <marco.liebsch@nw.neclab.eu>

      Paulo Loureiro <paulo.loureiro@nw.neclab.eu>

      Desire Oulai <desire.oulai@videotron.com>

      Behcet Sarikaya <sarikaya@ieee.org>

      Qin Wu <sunseawq@huawei.com>

      Hidetoshi Yokota <yokota@kddilabs.jp>


























Krishnan, et al.        Expires November 8, 2012               [Page 26]

Internet-Draft          PMIPv6 Localized Routing                May 2012


16.  Acknowledgments

   The authors would like to thank Sri Gundavelli, Julien Abeille, Tom
   Taylor, Kent Leung, Mohana Jeyatharan, Jouni Korhonen, Glen Zorn,
   Ahmad Muhanna, Zoltan Turanyi, Dirk von Hugo, Pete McCann, Xiansong
   Cui, Carlos Bernardos, Basavaraj Patil, Jari Arkko, Mary Barnes, Les
   Ginsberg, Russ Housley, Carl Wallace, Ralph Droms and Adrian Farrel
   for their comments and suggestions.











































Krishnan, et al.        Expires November 8, 2012               [Page 27]

Internet-Draft          PMIPv6 Localized Routing                May 2012


17.  References

17.1.  Normative References

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

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

   [RFC5844]  Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy
              Mobile IPv6", RFC 5844, May 2010.

   [RFC5845]  Muhanna, A., Khalil, M., Gundavelli, S., and K. Leung,
              "Generic Routing Encapsulation (GRE) Key Option for Proxy
              Mobile IPv6", RFC 5845, June 2010.

   [RFC6275]  Perkins, C., Johnson, D., and J. Arkko, "Mobility Support
              in IPv6", RFC 6275, July 2011.

17.2.  Informative References

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

   [RFC6279]  Liebsch, M., Jeong, S., and Q. Wu, "Proxy Mobile IPv6
              (PMIPv6) Localized Routing Problem Statement", RFC 6279,
              June 2011.






















Krishnan, et al.        Expires November 8, 2012               [Page 28]

Internet-Draft          PMIPv6 Localized Routing                May 2012


Authors' Addresses

   Suresh Krishnan
   Ericsson
   8400 Blvd Decarie
   Town of Mount Royal, Quebec
   Canada

   Phone: +1 514 345 7900 x42871
   Email: suresh.krishnan@ericsson.com


   Rajeev Koodli
   Cisco Systems

   Email: rkoodli@cisco.com


   Paulo Loureiro
   NEC

   Email: paulo.loureiro@nw.neclab.eu


   Qin Wu
   Huawei

   Email: Sunseawq@huawei.com


   Ashutosh Dutta
   NIKSUN

   Email: adutta@niksun.com

















Krishnan, et al.        Expires November 8, 2012               [Page 29]


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