Network Working Group                                   J. Korhonen, Ed.
Internet-Draft                                    Nokia Siemens Networks
Intended status: Standards Track                           S. Gundavelli
Expires: September 12, 2011                                        Cisco
                                                               H. Yokota
                                                                KDDI Lab
                                                                  X. Cui
                                                     Huawei Technologies
                                                          March 11, 2011


          Runtime LMA Assignment Support for Proxy Mobile IPv6
                   draft-ietf-netext-redirect-07.txt

Abstract

   This document describes a runtime Local Mobility Anchor assignment
   functionality and corresponding mobility options for Proxy Mobile
   IPv6.

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 September 12, 2011.

Copyright Notice

   Copyright (c) 2011 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



Korhonen, et al.       Expires September 12, 2011               [Page 1]


Internet-Draft           Runtime LMA Assignment               March 2011


   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 . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Requirements and Terminology . . . . . . . . . . . . . . . . .  4
     2.1.  Requirements . . . . . . . . . . . . . . . . . . . . . . .  4
     2.2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Proxy Mobile IPv6 Domain Assumptions . . . . . . . . . . . . .  5
   4.  Mobility Options . . . . . . . . . . . . . . . . . . . . . . .  6
     4.1.  Redirect-Capability Mobility Option  . . . . . . . . . . .  6
     4.2.  Redirect Mobility Option . . . . . . . . . . . . . . . . .  7
   5.  Runtime LMA Assignment . . . . . . . . . . . . . . . . . . . .  8
     5.1.  Common Mobile Access Gateway Operation . . . . . . . . . .  8
     5.2.  Common Local Mobility Anchor Operation . . . . . . . . . .  9
     5.3.  Mobility Session Created During the Runtime Assignment . . 10
       5.3.1.  General Operation  . . . . . . . . . . . . . . . . . . 10
       5.3.2.  Mobile Access Gateway Operation  . . . . . . . . . . . 11
       5.3.3.  Local Mobility Anchor Operation for Collocated
               rfLMA and r2LMA Functions  . . . . . . . . . . . . . . 11
       5.3.4.  Local Mobility Anchor Operation for Separate rfLMA
               and r2LMA Functions (Proxy-MAG)  . . . . . . . . . . . 12
     5.4.  Mobility Session Created After the Runtime Assignment  . . 13
       5.4.1.  General Operation  . . . . . . . . . . . . . . . . . . 13
       5.4.2.  Mobile Access Gateway Operation  . . . . . . . . . . . 14
       5.4.3.  Local Mobility Anchor Operation  . . . . . . . . . . . 14
   6.  Multi-Homing Considerations  . . . . . . . . . . . . . . . . . 15
   7.  Configuration Variables  . . . . . . . . . . . . . . . . . . . 15
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 16
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 16
   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 17
     11.2. Informative References . . . . . . . . . . . . . . . . . . 17
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18













Korhonen, et al.       Expires September 12, 2011               [Page 2]


Internet-Draft           Runtime LMA Assignment               March 2011


1.  Introduction

   This document describes the Redirect-Capability and the Redirect
   mobility options, and the corresponding functionality for a runtime
   assignment of the Local Mobility Anchor (LMA) for Proxy Mobile IPv6
   (PMIPv6).  The runtime LMA assignment takes place during a Proxy
   Binding Update (PBU) and a Proxy Binding Acknowledgement (PBA)
   message exchange between a Mobile Access Gateway (MAG) and a LMA.
   The runtime LMA assignment functionality defined in this
   specification can be used, for example, for load balancing purposes
   during the initial PBU/PBA message exchange.  The MAGs and LMAs can
   implement other load balancing mechanisms that are completely
   transparent at PMIPv6 protocol level and do not depend on the
   functionality defined in this specification.

   The runtime LMA assignment functionality described in this
   specification does not depend on information provisioned to external
   entities, such as the Domain Name System (DNS) or the Authentication,
   Authorization and Accounting (AAA) infrastructure.  The trust
   relationship and coordination management between LMAs within a PMIPv6
   domain is deployment specific and not described in this
   specification.

   There are number of reasons, why the runtime LMA assignment is a
   useful addition to the PMIPv6 protocol.  The following list describes
   some identified ones:

   o  LMAs with multiple IP addresses: a cluster of LMAs or a blade
      architecture LMA may appear to the routing system as multiple LMAs
      with separate unicast IP addresses.  A MAG can initially select
      any of those LMA IP addresses as the LMA Address using e.g., DNS-
      and AAA-based solutions.  However, MAG's initial selection may be
      suboptimal from the LMA point of view and immediate runtime
      assignment to a "proper LMA" would be needed.  The LMA could use
      [RFC5142] based approach but that would imply unnecessary setting
      up of a mobility session in a "wrong LMA" with associated backend
      support system interactions, involve additional signaling between
      the MAG and the LMA, and re-establishing mobility session to the
      new LMA again with associated signaling.

   o  Bypassing a load balancer: a cluster of LMAs or a blade
      architecture LMA may have a load balancer in front of them or
      integrated in one of the LMAs.  The load balancer would represent
      multiple LMAs during the LMA discovery phase and only its IP
      address would be exposed to the MAG hiding possible individual LMA
      or LMA blade IP addresses from the MAG.  However, if all traffic
      must always go through the load balancer it becomes quickly a
      bottleneck.  Therefore, a PMIPv6 protocol level support for



Korhonen, et al.       Expires September 12, 2011               [Page 3]


Internet-Draft           Runtime LMA Assignment               March 2011


      bypassing the load balancer after the initial PBU/PBA exchange
      would greatly help scalability.  Also bypassing the load balancer
      as soon as possible allows implementing load balancers that do not
      maintain any MN specific state information.

   o  Independence from DNS: DNS-based load balancing is a common
      practise.  However, keeping MAGs up-to-date with LMA load status
      using DNS is hard e.g., due caching and unpredictable zone update
      delays [RFC6097].  Generally, LMAs constantly updating [RFC2136]
      zone's master DNS server might not feasible in a large PMIPv6
      domain due to increased load on the master DNS server and
      additional background signaling.  Furthermore, MAGs may do (LMA)
      destination address selection decisions that are not in-line what
      the DNS administrator actually wanted [RFC3484].

   o  Independence from AAA: AAA-based solutions have basically the same
      arguments as DNS-based solutions above.  It is also typical that
      AAA-based solutions offload the initial LMA selection to the DNS
      infrastructure [RFC5779].  The AAA infrastructure does not return
      an IP address or a Fully Qualified domain Name (FQDN) to a single
      LMA, rather a FQDN representing a group of LMAs.

   o  Support for IPv6 anycast addressing [RFC4291]: the current PMIPv6
      specification does not specify how the PMIPv6 protocol should
      treat anycast addresses assigned to mobility agents.  For example,
      a blade architecture LMA may appear to the routing system as
      multiple LMAs with separate unicast IP addresses and with one or
      more "grouping" anycast addresses.  A MAG could then initially
      send a PBU to an anycast LMA address and receive a PBA from an
      anycast LMA address.  Once the MAG receives the unicast address of
      the runtime assigned LMA through the initial PBU/PBA exchange,
      then the MAG must start using the unicast address for the mobility
      session.

   As a summary, the DNS/AAA based approaches cannot be used to select
   an "appropriate" LMA at runtime.  Therefore, this specification
   defines a solution that is applicable for bladed/cluster LMA
   implementations where the IP address known to the MAG is not the best
   LMA of choice at runtime.


2.  Requirements and Terminology

2.1.  Requirements

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



Korhonen, et al.       Expires September 12, 2011               [Page 4]


Internet-Draft           Runtime LMA Assignment               March 2011


2.2.  Terminology

   In addition to the terminology defined in [RFC5213], the following
   terminology is also used:

   rfLMA

      An LMA which receives a PBU from a MAG and decides to assign an IP
      mobility session with a new target LMA (r2LMA).

   r2LMA

      The LMA assigned to a MAG as a result of the runtime LMA
      assignment.

   Runtime Assignment Domain

      A group of LMAs that consist of at least one rfLMA and one or more
      r2LMAs.  A rfLMA is allowed to assign MAGs only with r2LMAs that
      belong to the same runtime assignment domain.  The rfLMA and one
      or more r2LMAs may consist of multiple blades in a single network
      element, multiple physical network elements, or multiple LMAs
      distributed geographically.


3.  Proxy Mobile IPv6 Domain Assumptions

   The runtime LMA assignment functionality has several assumptions on
   the PMIPv6 domain.  They are discussed here as they have an impact on
   PMIPv6 deployment.

   Each LMA in a runtime assignment domain MUST be reachable at an
   unicast IP address.  The rfLMA and the r2LMA MUST have a prior
   agreement, adequate means to secure their inter-LMA communication and
   an established trust relationship to perform the runtime LMA
   assignment.

   The rfLMA MUST NOT assign a MAG with a r2LMA, if the rfLMA knows the
   r2LMA cannot accept a mobility session from the MAG.  That is, the
   runtime assignment functionality specified in this document is not
   enabled in the r2LMA, or the r2LMA does not belong to the same
   runtime assignment domain as the rfLMA, or the r2LMA is down or
   otherwise unreachable.  How the rfLMA learns and knows the
   capabilities of other r2LMAs in the runtime assignment domain, is not
   covered by this specification.

   Each LMA and MAG participating in the runtime LMA assignment is
   assumed to have required Security Associations (SA) already set up in



Korhonen, et al.       Expires September 12, 2011               [Page 5]


Internet-Draft           Runtime LMA Assignment               March 2011


   advance.  Dynamic negotiation of the SAs using e.g., IKEv2 [RFC5996]
   SHOULD be supported but is out of scope of this specification.

   The LMA MUST NOT include the Redirect mobility option in the PBA and
   perform the runtime LMA assignment, unless the MAG indicated the
   runtime LMA assignment functionality support in the corresponding PBU
   using the Redirection-Capability mobility option.  The LMA MUST NOT
   include the Redirect mobility option unsolicited even if the MAG had
   earlier indicated support for the runtime LMA assignment
   functionality.  MAGs and LMAs implementing the runtime LMA assignment
   functionality MUST support the runtime LMA assignment during the
   initial PBU/PBA exchange which creates a new mobility session.  A
   mid-session LMA assignment may make use of [RFC5142]


4.  Mobility Options

4.1.  Redirect-Capability Mobility Option

   If the runtime LMA assignment functionality is supported and also
   enabled, then the MAG SHOULD include the Redirect-Capability mobility
   option in a PBU that establishes a new mobility session.  When this
   option is included, the MAG may be assigned with another LMA, and the
   assigned LMA may simultaneously create a Binding Cache Entry (BCE).
   Hence, the MAG including this option MUST be able to support runtime
   LMA assignment with and without a creation of a BCE in the runtime
   assigned LMA.  The Redirect-Capability mobility option has the
   alignment requirement of 4n.  There can zero or one Redirect-
   Capability mobility option in the PBU.  The format of the Redirect-
   Capability mobility option is shown below:


    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Option Type   | Option Length |S|F|      Reserved             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Redirect-Capability Mobility Option

   o  Option Type: 8-bit identifier set to TBD1.

   o  Option Length: 8-bit unsigned integer, representing the length of
      the Redirect-Capability mobility option in octets, excluding the
      Option Type and Length fields.  The Option Length MUST be set to
      2.





Korhonen, et al.       Expires September 12, 2011               [Page 6]


Internet-Draft           Runtime LMA Assignment               March 2011


   o  'S' flag: This bit is set (1) if the MAG supports IPv6 transport.
      Otherwise, the bit is unset (0).

   o  'F' flag: This bit is set (1) if the MAG supports IPv4 transport.
      Otherwise, the bit is unset (0).

   o  Reserved: This field is reserved for future use.  MUST be set to
      zero.

   Both 'S' and 'F' flags MUST NOT be unset at the same time.

4.2.  Redirect Mobility Option

   The LMA MUST include the Redirect mobility option in a PBA only if
   the MAG indicated support for the runtime LMA assignment
   functionality and runtime LMA assignment took place.  The Redirect
   mobility option in the PBA MUST contain at least one unicast address
   of the r2LMA.  There can at most one Redirect mobility option in the
   PBA.

   The Redirect mobility option has the alignment requirement of 4n.
   The format of the Redirect mobility option is shown below:


    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Option Type   | Option Length |K|N|      Reserved             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                  Optional IPv6 r2LMA Address                  |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Optional IPv4 r2LMA Address                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                         Redirect Mobility Option

   o  Option Type: 8-bit identifier set to TBD2.

   o  Option Length: 8-bit unsigned integer, representing the length of
      the Redirect mobility option in octets, excluding the Option Type
      and Length fields.  If 'K' flag is set and 'N' is unset, then the
      length MUST be 18.  If 'K' flag is unset and 'N' is set, then the
      length MUST be 6.  If both 'K' and 'N' flags are set, then the
      length MUST be 22.



Korhonen, et al.       Expires September 12, 2011               [Page 7]


Internet-Draft           Runtime LMA Assignment               March 2011


   o  'K' flag: This bit is set (1) if the 'Optional IPv6 r2LMA Address'
      is included in the mobility option.  Otherwise, the bit is unset
      (0).

   o  'N' flag: This bit is set (1) if the 'Optional IPv4 r2LMA Address'
      is included in the mobility option.  Otherwise, the bit is unset
      (0).

   o  Reserved: This field is reserved for future use.  MUST be set to
      zero.

   o  Optional IPv6 r2LMA Address: the unicast IPv6 address of the
      r2LMA.  This value is present if the r2LMA IPv6 address is
      available and the 'S' flag was set in the corresponding Redirect-
      Capability mobility option.

   o  Optional IPv4 r2LMA Address: the IPv4 address of the r2LMA.  This
      value is present if the r2LMA IPv4 address is available and the
      'F' flag was set in the corresponding Redirect-Capability mobility
      option.

   Both 'K' and 'N' flags MUST NOT be unset at the same time.


5.  Runtime LMA Assignment

5.1.  Common Mobile Access Gateway Operation

   In the base PMIPv6 protocol [RFC5213] a MAG sends a PBU to an LMA,
   which results in a BCE creation at the LMA and the LMA sending a PBA
   sent back to the MAG.  The MAG in turn creates an entry in its
   Binding Update List (BUL).  This specification extends the base
   protocol with the runtime LMA assignment functionality.

   Backwards compatibility is maintained in a deployment wherein some
   MAGs may have the ability to support runtime LMA assignment while
   others do not.  This is accomplished by the use of the Redirect-
   Capability mobility option that a MAG includes in the PBU.  If the
   runtime LMA assignment functionality is supported and also enabled,
   then the MAG SHOULD include the Redirect-Capability mobility option
   in a PBU that establishes a new mobility session.  The Redirect-
   Capability mobility option in the PBU is also an indication to an LMA
   that the MAG supports the runtime LMA assignment functionality and is
   prepared to be assigned with a different LMA.  The runtime LMA
   assignment concerns always one mobility session at time.

   If the MAG receives a PBA that contains the Redirect mobility option
   without first including the Redirect-Capability mobility option in



Korhonen, et al.       Expires September 12, 2011               [Page 8]


Internet-Draft           Runtime LMA Assignment               March 2011


   the corresponding PBU, then the MAG MUST ignore the option and treat
   the of the PBA as described in RFC 5213.

5.2.  Common Local Mobility Anchor Operation

   The text in the following sections refers to a 'LMA' when it means
   the combination of the rfLMA and the r2LMA i.e., the entity where
   runtime LMA assignment is possible.  When the text points to a
   specific LMA role during the runtime assignment, it uses either the
   'rfLMA' or the 'r2LMA'.

   If the runtime assignment functionality is enabled in the LMA but the
   LMA assignment is not going to take place for a reason or other, and
   the rfLMA is not willing to serve (or capable of) as a normal RFC
   5213 LMA for the MAG, then the rfLMA MUST reject the PBU and send
   back a PBA with Status Value set to 130 (Insufficient resources)
   error code.  Otherwise, the rfLMA MUST act as a normal RFC 5213
   defined LMA for the MAG.

   The rfLMA MUST only assign the MAG with a new r2LMA that it knows the
   MAG has a SA with or the MAG and the r2LMA are able to create it
   dynamically.  The rfLMA MUST NOT assign the MAG with a r2LMA that the
   rfLMA and the r2LMA do not have a prior agreement and an established
   trust relationship for the runtime LMA assignment.  These SA related
   knowledge issues and trust relationships are deployment specific in a
   PMIPv6 domain and in a runtime assignment domain, and out of scope of
   this specification.  Possible context transfer and other coordination
   management between the rfLMA and the r2LMA, are again deployment
   specific for LMAs in a runtime assignment domain.

   The rfLMA MUST NOT assign a MAG using IPv6 transport with a new r2LMA
   using IPv4 transport, if the MAG does not indicate support for IPv4
   in the Redirect-Capability mobility option, as there is no guarantee
   that the MAG supports switching from IPv6 transport to IPv4
   transport.  The same also applies for assigning a MAG using IPv4
   transport with a r2LMA supporting only IPv6 transport.

   As a result of a successful runtime LMA assignment, the PBA MUST
   contain the Redirect mobility option with a valid r2LMA unicast
   address and the PBA Status Value indicating success.

   In general the r2LMA may be a normal RFC 5213 LMA without any runtime
   LMA assignment functionality.  The r2LMA may also include rfLMA
   functionality in which case the consideration described in the
   following sections for the rfLMA apply.  If the runtime LMA
   assignment functionality is implemented but not enabled in a LMA,
   then the LMA MUST ignore the Redirect-Capability mobility option
   received in a PBU and act as a LMA defined in RFC 5213.



Korhonen, et al.       Expires September 12, 2011               [Page 9]


Internet-Draft           Runtime LMA Assignment               March 2011


5.3.  Mobility Session Created During the Runtime Assignment

5.3.1.  General Operation

   During the runtime LMA assignment, the PBA is returned from the LMA
   Address where the PBU was sent to i.e., from the rfLMA.  After the
   runtime LMA assignment all PMIPv6 communication continues directly
   between the MAG and the r2LMA.  The overall runtime LMA assignment
   flow sequence is shown in Figure 1.


     MAG     rfLMA    r2LMA
      |        |        |
   1) |--PBU-->|  ~ ~ ~ | (LMA assignment takes place, BCE gets created
   2) |<--PBA--| ~ ~ ~  |  in r2LMA, PBA contains r2LMA information and
      |        |        |  Status Value set to
      |        |        |  Accepted_and_Redirected_with_Binding)
   3) |<=====data======>|
      |        |        |
   4) |-------PBU------>| (lifetime extension,
   5) |<------PBA-------|  de-registration, etc.)
      |        |        |

   Figure 1: Runtime LMA assignment from rfLMA to r2LMA and setting up a
     mobility session in the r2LMA within a runtime assignment domain

   The assumption in the signaling flow step 1) shown in Figure 1 is
   that the mobility session gets created in the r2LMA, although the
   rfLMA is responsible for interfacing with the MAG.  There are several
   possible solutions for the rfLMA and the r2LMA interaction depending
   on e.g. the collocation properties of the rfLMA and the r2LMA.  This
   specification briefly describes two:

   o  Collocated rfLMA & r2LMA functions, where the 'rfLMA side of the
      LMA' is reachable via an anycast address.  See Section 5.3.3 for
      further details.

   o  Separate rfLMA & r2LMA functions, where both are reachable via a
      unicast address and the rfLMA acts as a 'proxy-MAG'.  See
      Section 5.3.4 for further details.

   There are other possible implementations of the rfLMA and the r2LMA.
   At the end, as long as the protocol between the MAG and the rfLMA
   follows this specification , the collocation or inter-communication
   properties of the rfLMA and the r2LMA do not matter.






Korhonen, et al.       Expires September 12, 2011              [Page 10]


Internet-Draft           Runtime LMA Assignment               March 2011


5.3.2.  Mobile Access Gateway Operation

   In addition to MAG operations described in Section 5.1, the following
   considerations has to taken into account during the runtime LMA
   assignment.

   If the MAG receives a PBA that contains the Redirect mobility option
   and the Status Value set to TBD3
   (Accepted_and_Redirected_with_Binding), and the MAG had included the
   Redirect-Capability mobility option in the corresponding PBU, then
   the MAG MUST perform the following steps in addition to the normal
   RFC 5213 PBA processing:

   o  The MAG updates its BUL to correspond the r2LMA address included
      in the received Redirect mobility option.

   o  If there is no SA between the MAG and the r2LMA, the MAG SHOULD
      initiate a dynamic creation of the SA between the MAG and the
      r2LMA as described in Section 4 of RFC 5213.

   There is no need to resend any PBUs to the r2LMA after a successful
   runtime assignment.  The mobility session has already been
   established in the r2LMA as indicated by the Status Value TBD3
   (Accepted_and_Redirected_with_Binding).  The MAG MUST send subsequent
   binding refreshing PBUs and user traffic to the new r2LMA address.

5.3.3.  Local Mobility Anchor Operation for Collocated rfLMA and r2LMA
        Functions

   In this solution approach the rfLMA and the r2LMA are actually the
   same 'collocated LMA', and may even be tied to the same physical LMA
   network interface.  The rfLMA is reachable via an anycast address and
   the r2LMA is reachable via the unicast address of the LMA.  The MAG-
   LMA SA is between the MAG and the rfLMA (i.e. the anycast address of
   the LMA).  How this SA has been set up is out of scope of this
   specification but a manual SA configuration is one possibility.

   If the runtime LMA assignment functionality is enabled in the LMA,
   then the rfLMA becomes active and the LMA is also reachable via the
   anycast address.  When the rfLMA receives a PBU destined to its
   anycast address, and the PBU contains the Redirect-Capability
   mobility option, then the 'collocated LMA' MUST create a mobility
   session in a r2LMA role using the procedures described in RFC 5213.
   If there in no existing tunnel between the MAG and the r2LMA unicast
   address, then the r2LMA creates one.

   If the mobility session creation succeeded, the 'collocated LMA' in a
   rfLMA role sends a PBA to the MAG.  The PBA is sourced using the



Korhonen, et al.       Expires September 12, 2011              [Page 11]


Internet-Draft           Runtime LMA Assignment               March 2011


   rfLMA anycast address.  The PBA MUST contain the r2LMA unicast
   address (IPv6, IPv4 or both) in the Redirect mobility option and the
   Status Value set to TBD3 (Accepted_and_Redirected_with_Binding).

   If the PBU is received on the r2LMA unicast address, then the PBU is
   processed as described in RFC 5213 and the response PBA MUST NOT
   contain the Redirect mobility option.  The 'collocated LMA' MAY
   refuse to serve the MAG on the reception of the initial PBU as
   mentioned in Section 5.2.

   If the PBU is received on the rfLMA anycast address and there is no
   Redirect-Capability mobility option in the PBU, then the 'collocated
   LMA' MUST reject the PBU and send back a PBA in a rfLMA role with
   Status Value set to 130 (Insufficient resources) error code (as
   mentioned in Section 5.2).

5.3.4.  Local Mobility Anchor Operation for Separate rfLMA and r2LMA
        Functions (Proxy-MAG)

   In this solution approach the rfLMA and the r2LMA are two isolated
   functions, and may even be physically separate networking nodes.
   Both the rfLMA and the r2LMA are reachable via a unicast address.
   The r2LMA can be any RFC 5213 compliant LMA without any knowledge of
   this specification.

   The rfLMA is actually a 'proxy-MAG' which shows up as an LMA
   implementing this specification towards the MAG, and as a base RFC
   5213 compliant MAG to the r2LMA.  This type of operation is also
   referred as 'chaining' in other contexts.

   The MAG-LMA SA is between the MAG and the rfLMA, and RFC 5213 SA
   considerations apply fully.  The MAG has no knowledge of the 'proxy-
   MAG'-r2LMA SA.  RFC 5213 considerations regarding the SA between the
   'proxy-MAG' and the r2LMA apply fully.  It is also possible that
   'proxy-MAG'-r2LMA security is arranged using other means than IPsec,
   for example using layer-2 VPNs.  The 'proxy-MAG'-r2LMA communication
   could even be some inter-blade remote call procedure in a blade
   architecture LMA.

   When the rfLMA receives a PBU, and the PBU contains the Redirect-
   Capability mobility option, then the rfLMA:

   o  Processes the PBU using the procedures described in RFC 5213
      except that no mobility session gets created.  Instead the rfLMA
      creates a MAG-rfLMA-r2LMA proxy state (including the mobility
      option information received in the PBU),





Korhonen, et al.       Expires September 12, 2011              [Page 12]


Internet-Draft           Runtime LMA Assignment               March 2011


   o  Assigns a r2LMA to the MAG,

   o  Creates a new PBU', which includes all non-security related
      mobility options from the original PBU and the Alternate Care-of
      Address option containing the address of the original MAG,

   o  Sends a new PBU' sourced from its 'proxy-MAG' address to the r2LMA
      using the procedures described in RFC 5213.

   The r2LMA processed the received PBU' using the procedures described
   in RFC 5213.

   Once the rfLMA in a 'proxy-MAG' role receives a reply PBA' from the
   r2LMA and the mobility session creation succeeded in the r2LMA, the
   rfLMA sends a PBA to the MAG.  The PBA is sourced using the rfLMA
   address.  The PBA MUST contain the r2LMA unicast address (IPv6, IPv4
   or both) in the Redirect mobility option and the Status Value set to
   TBD3 (Accepted_and_Redirected_with_Binding).  Note that the Status
   Value received from PBA' gets replaced by the rfLMA.

   If the PBA' indicates that the mobility session creation failed in
   the r2LMA, then the rfLMA MUST set the Status Value in the PBA as
   received from the PBA' Status Value.

   Once the rfLMA has sent the reply PBA to the MAG, it can remove the
   MAG-rfLMA-r2LMA proxy state.  Subsequent traffic between the MAG and
   the r2LMA will bypass the rfLMA.

   If the rfLMA receives a PBU with no Redirect-Capability mobility
   option in the PBU, then the proceeds as mentioned in Section 5.2),
   i.e. may or may not act as a RFC 5213 LMA to the MAG.

5.4.  Mobility Session Created After the Runtime Assignment

5.4.1.  General Operation

   During the runtime LMA assignment the PBA is returned from the LMA
   Address where the PBU was sent to i.e., from the rfLMA.  After the
   runtime LMA assignment, the MAG has to initiate another PBU/PBA
   exchange with the r2LMA and after that all PMIPv6 communication
   continues between the MAG and the r2LMA.  The overall runtime LMA
   assignment flow sequence is shown in Figure 2.









Korhonen, et al.       Expires September 12, 2011              [Page 13]


Internet-Draft           Runtime LMA Assignment               March 2011


     MAG     rfLMA    r2LMA
      |        |        |
   1) |--PBU-->|        | (assignment takes place, PBA contain
   2) |<--PBA--|        |  r2LMA information, Status Value set
      |        |        |  to Rejected_but_Redirected)
      |        |        |
   3) |-------PBU------>| (BCE gets created in r2LMA)
   4) |<------PBA-------|
      |        |        |
   5) |<=====data======>|
      |        |        |
   6) |-------PBU------>| (lifetime extension,
   7) |<------PBA-------|  de-registration, etc.)
      |        |        |

   Figure 2: Runtime LMA assignment from rfLMA to r2LMA within a runtime
                             assignment domain

   The assumption in the signaling flow steps 1) and 2) shown in
   Figure 2 is that the MAG is only assigned with the r2LMA.  The
   mobility session creation with the r2LMA requires a new PBU/PBA
   exchange with the r2LMA using the normal RFC 5213 procedures.

5.4.2.  Mobile Access Gateway Operation

   The MAG operation is exactly the same as described in Section 5.1 and
   Section 5.3.2 except for two aspects:

   o  The Status Value in the received PBA is set to TBD4
      (Rejected_but_Redirected).  This indicates to the MAG that there
      is no mobility session (i.e.  BCE) created in the r2LMA and not in
      the rfLMA either.  The MAG was only assigned with a new r2LMA
      Address information.

   o  The MAG MUST initiate a new PBU/PBA exchange with the r2LMA in
      order to establish a mobility session.  Only after a successful
      PBU/PBA exchange with the r2LMA, the runtime assignment has
      completed.  The PBU sent to the r2LMA MUST NOT contain the
      Redirect-Capability mobility option in order to avoid immediate
      new runtime LMA assignment.

5.4.3.  Local Mobility Anchor Operation

   If the runtime LMA assignment functionality is enabled in the LMA and
   the received PBU contains the Redirect-Capability mobility option,
   then the rfLMA MAY assign the MAG with a new r2LMA.  In the case of
   runtime LMA assignment, the PBA returned to the MAG MUST always
   include the unicast IP address (IPv6, IPv4 or both) of the r2LMA in



Korhonen, et al.       Expires September 12, 2011              [Page 14]


Internet-Draft           Runtime LMA Assignment               March 2011


   the Redirect mobility option and the Status Value set to TBD4
   (Rejected_but_Redirected).  If the rfLMA did not assign the MAG with
   a new r2LMA or the runtime assignment failed, then the PBA MUST NOT
   contain the Redirect mobility option and the PBA is processed
   according to RFC 5213.


6.  Multi-Homing Considerations

   A MN can be multi-homed.  A single LMA entity should have the control
   over all possible multi-homed mobility sessions the MN has.  All
   mobility sessions a multi-homed MN may have SHOULD be anchored in the
   single LMA entity.  Therefore, once the MN has established one
   mobility session with one LMA, the subsequent mobility sessions of
   the same MN SHOULD be anchored to the LMA that was initially
   assigned.

   One possible solution already supported by this specification is
   applying the runtime LMA assignment only for the very first initial
   attach a multi-homed MN does towards a PMIPv6 domain.  After the
   initial attach, the assigned r2LMA Address has been stored in the
   policy profile.  For the subsequent mobility sessions of the multi-
   homed MN, the same assigned r2LMA Address would be used and there is
   no need to contact the rfLMA.

   MAGs have a control over selectively enabling and disabling the
   runtime assignment of the LMA.  If the multi-homed MN is attached to
   a PMIPv6 domain via multiple MAGs, the assigned r2LMA Address should
   be stored in the remote policy store and downloaded as a part of the
   policy profile download to a MAG.  Alternatively, MAGs can share
   policy profile information using other means.  In both cases, the
   actual implementation of the policy profile information sharing is
   specific to a PMIPv6 deployment and out of scope of this
   specification.


7.  Configuration Variables

   This specification defines three configuration variables that control
   the runtime LMA assignment functionality within a PMIPv6 domain.

   EnableLMARedirectFunction

      This configuration variable is available in both a MAG and in a
      rfLMA.  When set to TRUE (i.e., enabled), the PMIPv6 node enables
      the runtime LMA assignment functionality.  The default value is
      FALSE (i.e., disabled).




Korhonen, et al.       Expires September 12, 2011              [Page 15]


Internet-Draft           Runtime LMA Assignment               March 2011


   EnableLMARedirectAcceptFunction

      This configuration variable is available in a r2LMA.  When set to
      TRUE (i.e., enabled), the r2LMA is able to accept runtime LMA
      assignment mobility sessions from a rfLMA.  The default value is
      FALSE (i.e., disabled).


8.  Security Considerations

   The security considerations of PMIPv6 signaling described in RFC 5213
   apply to this document.  An incorrectly configured LMA may cause
   unwanted runtime LMA assignment attempts to non-existing LMAs or to
   other LMAs that do not have and will not have a SA with the MAG.
   Consequently, the MAG will experience failed binding updates or
   unsuccessful creation of mobility sessions.  An incorrectly
   configured LMA may also cause biased load distribution within a
   PMIPv6 domain.  This document also assumes that the LMAs that
   participate to runtime LMA assignment have adequate prior agreement
   and trust relationship between each other.

   If the SAs between MAGs and LMAs are manually keyed (as it may be
   needed by the scenario described in Section 5.3), then the anti-
   replay service of ESP protected PMIPv6 traffic cannot typically be
   provided.  This is, however, deployment specific to a PMIPv6 domain.

   If a PMIPv6 domain deployment with a runtime LMA assignment requires
   that a rfLMA has to modify a PBU/PBA in any way e.g., by changing the
   source and destination IP address or any other field of the
   encapsulating IP packet, then the security mechanism (such as
   possible authentication options) used to protect the PBU/PBA MUST NOT
   cover the outer IP packet on those parts that might get modified.
   Alternatively, the rfLMA can do all required security processing on
   the PBU/PBA, and the communication between the rfLMA and the r2LMA
   would be unprotected at the PMIPv6 protocol level.  In this case the
   runtime assignment domain MUST implement adequate level of security
   using other means, such as layer-2 VPNs.


9.  IANA Considerations

   Two new mobility options for the use with PMIPv6 are defined in the
   [RFC3775] "Mobility Options" registry.  The mobility options are
   defined in Section 4:

       Redirect-Capability Mobility Option is set to   TBD1
       Redirect Mobility Option is set to              TBD2




Korhonen, et al.       Expires September 12, 2011              [Page 16]


Internet-Draft           Runtime LMA Assignment               March 2011


   This document defines the following new Status values for use in PBA
   messages.  The values are to be allocated from the same number space,
   as defined in Section 6.1.8 of [RFC3775].

   The value below MUST be less than 128 indicating that the PBU was
   accepted by the LMA:

       Accepted_and_Redirected_with_Binding is set to  TBD3

   The value below MUST be greater than 128 indicating that the PBU was
   rejected by the LMA:

       Rejected_but_Redirected is set to               TBD4


10.  Acknowledgements

   The author would like to thank Basavaraj Patil, Domagoj Premec, Ahmad
   Muhanna, Vijay Devarapalli, Rajeev Koodli, Yungui Wang and Qin Wu for
   their discussion on this document.


11.  References

11.1.  Normative References

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

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

11.2.  Informative References

   [RFC2136]  Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
              "Dynamic Updates in the Domain Name System (DNS UPDATE)",
              RFC 2136, April 1997.

   [RFC3484]  Draves, R., "Default Address Selection for Internet
              Protocol version 6 (IPv6)", RFC 3484, February 2003.

   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 4291, February 2006.

   [RFC5142]  Haley, B., Devarapalli, V., Deng, H., and J. Kempf,



Korhonen, et al.       Expires September 12, 2011              [Page 17]


Internet-Draft           Runtime LMA Assignment               March 2011


              "Mobility Header Home Agent Switch Message", RFC 5142,
              January 2008.

   [RFC5779]  Korhonen, J., Bournelle, J., Chowdhury, K., Muhanna, A.,
              and U. Meyer, "Diameter Proxy Mobile IPv6: Mobile Access
              Gateway and Local Mobility Anchor Interaction with
              Diameter Server", RFC 5779, February 2010.

   [RFC5996]  Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
              "Internet Key Exchange Protocol Version 2 (IKEv2)",
              RFC 5996, September 2010.

   [RFC6097]  Korhonen, J. and V. Devarapalli, "Local Mobility Anchor
              (LMA) Discovery for Proxy Mobile IPv6", RFC 6097,
              February 2011.


Authors' Addresses

   Jouni Korhonen (editor)
   Nokia Siemens Networks
   Linnoitustie 6
   FI-02600 Espoo
   FINLAND

   Email: jouni.nospam@gmail.com


   Sri Gundavelli
   Cisco
   170 West Tasman Drive
   San Jose, CA  95134
   USA

   Email: sri.gundavelli@cisco.com


   Hidetoshi Yokota
   KDDI Lab
   2-1-15 Ohara, Fujimino
   Saitama,  356-8502
   Japan

   Email: yokota@kddilabs.jp







Korhonen, et al.       Expires September 12, 2011              [Page 18]


Internet-Draft           Runtime LMA Assignment               March 2011


   Xiangsong Cui
   Huawei Technologies
   KuiKe Bld., No.9 Xinxi Rd.
   Shang-Di Information Industry Base
   Hai-Dian District, Beijing, P.R. China, 100085

   Email: Xiangsong.Cui@huawei.com












































Korhonen, et al.       Expires September 12, 2011              [Page 19]