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

Versions: (draft-korhonen-netext-redirect) 00 01 02 03 04 05 06 07 08 09 10 11 12 RFC 6463

Network Working Group                                   J. Korhonen, Ed.
Internet-Draft                                    Nokia Siemens Networks
Intended status: Standards Track                           S. Gundavelli
Expires: April 15, 2012                                            Cisco
                                                               H. Yokota
                                                                KDDI Lab
                                                                  X. Cui
                                                     Huawei Technologies
                                                        October 13, 2011


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

Abstract

   This document describes a runtime Local Mobility Anchor assignment
   functionality and corresponding mobility options for Proxy Mobile
   IPv6.  The runtime Local Mobility Anchor assignment takes place
   during a Proxy Binding Update and a Proxy Binding Acknowledgement
   message exchange between a Mobile Access Gateway and a Local Mobility
   Anchor.  The runtime Local Mobility Anchor assignment functionality
   defined in this specification can be used, for example, for load
   balancing purposes.

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 April 15, 2012.

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



Korhonen, et al.         Expires April 15, 2012                 [Page 1]

Internet-Draft           Runtime LMA Assignment             October 2011


   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 . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Requirements and Terminology . . . . . . . . . . . . . . . . .  4
     2.1.  Requirements . . . . . . . . . . . . . . . . . . . . . . .  4
     2.2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Proxy Mobile IPv6 Domain Assumptions . . . . . . . . . . . . .  5
   4.  Mobility Options . . . . . . . . . . . . . . . . . . . . . . .  5
     4.1.  Redirect-Capability Mobility Option  . . . . . . . . . . .  5
     4.2.  Redirect Mobility Option . . . . . . . . . . . . . . . . .  6
     4.3.  Load Information Mobility Option . . . . . . . . . . . . .  7
     4.4.  Alternate IPv4 Care-of Address Mobility Option . . . . . .  9
   5.  Runtime LMA Assignment . . . . . . . . . . . . . . . . . . . .  9
     5.1.  General Operation  . . . . . . . . . . . . . . . . . . . .  9
     5.2.  Mobile Access Gateway Operation  . . . . . . . . . . . . . 10
     5.3.  Local Mobility Anchor Operation  . . . . . . . . . . . . . 11
       5.3.1.  Collocated rfLMA and r2LMA Functions . . . . . . . . . 12
       5.3.2.  Separate rfLMA and r2LMA Functions (Proxy-MAG) . . . . 14
   6.  Handoff and Multi-Homing Considerations  . . . . . . . . . . . 18
   7.  Configuration Objects  . . . . . . . . . . . . . . . . . . . . 18
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 19
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 19
   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 20
     11.2. Informative References . . . . . . . . . . . . . . . . . . 20
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21














Korhonen, et al.         Expires April 15, 2012                 [Page 2]

Internet-Draft           Runtime LMA Assignment             October 2011


1.  Introduction

   This specification describes a runtime assignment of a Local Mobility
   Anchor (LMA) for Proxy Mobile IPv6 (PMIPv6) [RFC5213] protocol.  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.  MAGs and LMAs can also
   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 does not depend on the
   Domain Name System (DNS) or the Authentication, Authorization and
   Accounting (AAA) infrastructure for the assignment of the LMA where
   the mobile node is anchored to.  All MAGs and LMAs (either rfLMAs or
   r2LMAs, see Section 2.2) have to belong to the same PMIPv6 domain.

   There are number of reasons why the runtime LMA assignment is a
   useful addition to the PMIPv6 protocol.  Few identified ones are
   listed below:

   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 the LMA's as the serving LMA using for example, 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
      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 Mobile Node (MN) specific state information.



Korhonen, et al.         Expires April 15, 2012                 [Page 3]

Internet-Draft           Runtime LMA Assignment             October 2011


   o  Independence from DNS: DNS-based load balancing is a common
      practice.  However, keeping MAGs up-to-date with LMA load status
      using DNS is hard e.g., due to 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 with
      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 have an unique unicast IP address for
      each blade and a single anycast address for all blades.  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 blade through the
      initial PBU/PBA exchange, the subsequent communication continues
      using the unicast address.

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

2.2.  Terminology

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




Korhonen, et al.         Expires April 15, 2012                 [Page 4]

Internet-Draft           Runtime LMA Assignment             October 2011


   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 few assumptions within
   the PMIPv6 domain.

   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.

   Each LMA and MAG participating in the runtime LMA assignment is
   assumed to have required Security Associations (SA) pre-established.
   Dynamic negotiation of the SAs using e.g., IKEv2 [RFC5996] SHOULD be
   supported but is out of scope of this specification.


4.  Mobility Options

   In the following sections all presented values, bit fields and
   addresses are in network byte order.

4.1.  Redirect-Capability Mobility Option

   The Redirect-Capability mobility option has the alignment requirement
   of 4n.  There can be zero or one Redirect-Capability mobility option
   in the PBU.  The format of the Redirect-Capability mobility option is
   shown below:



Korhonen, et al.         Expires April 15, 2012                 [Page 5]

Internet-Draft           Runtime LMA Assignment             October 2011


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

   o  Reserved: This field is reserved for future use.  MUST be set to
      zero by the sender and ignored by the receiver.

   The Redirect-Capability option is used by the MAG to inform the LMA
   that is implements and has enabled the runtime LMA assignment
   functionality.

4.2.  Redirect Mobility Option

   The Redirect mobility option in the PBA MUST contain an unicast
   address of the r2LMA and the address family MUST be the same as the
   currently used transport between the MAG and the rfLMA.  There can
   zero or 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





Korhonen, et al.         Expires April 15, 2012                 [Page 6]

Internet-Draft           Runtime LMA Assignment             October 2011


   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.  Both 'K' and 'N' flags cannot be set or unset
      simultaneously.

   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 by the sender and ignored by the receiver.

   o  Optional IPv6 r2LMA Address: the unicast IPv6 address of the
      r2LMA.  This value is present when the corresponding PBU was
      sourced from an IPv6 address.

   o  Optional IPv4 r2LMA Address: the IPv4 address of the r2LMA.  This
      value is present when the corresponding PBU was sourced from an
      IPv4 address (for IPv4 transport, see [RFC5844]).

   The Redirect option is used by the LMA to inform the MAG that the
   runtime LMA assignment took place and the MAG has to update its
   Binding Update List Entry (BULE) for the mobility session.

4.3.  Load Information Mobility Option

   The Load Information mobility option can be included in any PBA and
   is used to report priority and key load information of a LMA to a MAG
   (or to a 'proxy-MAG').  The Load Information mobility option has the
   alignment requirement of 4n.  The format of the mobility option is
   shown below:












Korhonen, et al.         Expires April 15, 2012                 [Page 7]

Internet-Draft           Runtime LMA Assignment             October 2011


    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 |          Priority             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Sessions in Use                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Maximum Sessions                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Used Capacity                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Maximum Capacity                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     Load Information Mobility Option

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

   o  Option Length: 8-bit unsigned integer, representing the length of
      the Load Information mobility option in octets, excluding the
      Option Type and Length fields.  The length is set to 18.

   o  Priority: 16-bit unsigned integer, representing the priority of an
      LMA.  The lower value the higher priority.  The priority has only
      meaning among a group of LMAs under the same administration, for
      example, determined by a common LMA FQDN, a domain name or a
      realm.

   o  Sessions in Use: 32-bit unsigned integer, representing the number
      of parallel mobility sessions the LMA has in use.

   o  Maximum Sessions: 32-bit unsigned integer, representing the
      maximum number of parallel mobility sessions the LMA is willing to
      accept.

   o  Used Capacity: 32-bit unsigned integer, representing the used
      bandwidth/throughput capacity of the LMA in kilobytes per second.

   o  Maximum Capacity: 32-bit unsigned integer, representing the
      maximum bandwidth/throughput capacity in kilobytes per second the
      LMA is willing to accept.

   The session and capacity information can easily be used to calculate
   different load factors of the LMA.  A MAG (or a 'proxy-MAG') MAY use
   the priority and load information to internally maintain priority
   ordering of LMAs.





Korhonen, et al.         Expires April 15, 2012                 [Page 8]

Internet-Draft           Runtime LMA Assignment             October 2011


4.4.  Alternate IPv4 Care-of Address Mobility Option

   The Alternate IPv4 Care-of Address (A4CoA) mobility option has the
   alignment requirement of 4n+2.  The format of the 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 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Alternate IPv4 Care-of Address                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              Alternate IPv4 Care-of Address Mobility Option

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

   o  Option Length: 8-bit unsigned integer, representing the length of
      the Load Information mobility option in octets, excluding the
      Option Type and Length fields.  The length is set to 4.

   o  Alternate IPv4 Care-of Address: an IPv4 equivalent of the
      [RFC6275] Alternate Care-of Address option for IPv6.  In the
      context of PMIPv6 its semantic is equivalent to the Alternate
      Care-of Address option for IPv6.

   A MAG MAY include the Alternate IPv4 Care-of Address option in a PBU.
   An LMA that receives and implements the Alternate IPv4 Care-of
   Address option MUST echo the option as such back to the MAG in a
   reply PBA.


5.  Runtime LMA Assignment

5.1.  General Operation

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








Korhonen, et al.         Expires April 15, 2012                 [Page 9]

Internet-Draft           Runtime LMA Assignment             October 2011


    [MAG]   [rfLMA]  [r2LMA]
      |        |        |
   1) |--PBU-->|        | LMA assignment takes place in rfLMA.
      |        |        |
   2) |        | ~ ~ ~ >|\
      |        |        | + BCE gets created in r2LMA.
   3) |        |<~ ~ ~ ~|/
      |        |        |
   4) |<--PBA--|        | PBA contains r2LMA information.
      |        |        |
      |<=====data======>|
      |        |        |
   5) |-------PBU------>| Lifetime extension,
   6) |<------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 describes two:

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

   o  Separate rfLMA & r2LMA functions, where the rfLMA acts as a non-
      transparent 'proxy-MAG' to a r2LMA.  See Section 5.3.2 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.

5.2.  Mobile Access Gateway Operation

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




Korhonen, et al.         Expires April 15, 2012                [Page 10]

Internet-Draft           Runtime LMA Assignment             October 2011


   If the MAG supports the runtime LMA assignment and the functionality
   is also enabled (see EnableLMARedirectFunction configuration object
   in Section 7), then the MAG includes the Redirect-Capability mobility
   option in a PBU that establishes a new mobility session (i.e.
   Handoff Indicator Option in the PBU has the value of 1).  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 a
   time.

   If the MAG receives a PBA that contains the Redirect mobility option
   without first including the Redirect-Capability mobility option in
   the corresponding PBU, then the MAG MUST ignore the option and
   process the PBA as described in RFC 5213.

   If the MAG receives a PBA that contains the Redirect mobility option
   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 BULE to contain 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.  If the dynamic SA
      creation fails, the MAG SHOULD log the event.  The MAG MAY retry
      the dynamic creation of the SA, and if those also fail, the newly
      created BULE (and also the BUL in the r2LMA) will eventually
      timeout.  If the failure is persistent, it can be regarded as a
      system level configuration error.

   The MAG is not required to send a fresh PBU to the r2LMA after a
   successful runtime assignment.  The mobility session has already been
   established in the r2LMA.  The MAG MUST send all user traffic to the
   r2LMA address.  The MAG MUST send subsequent binding refresh PBUs
   (e.g., lifetime extension, handoff etc) to the r2LMA address.  If
   there is no existing tunnel between the MAG and the r2LMA unicast
   address, then the MAG creates one as described in Section 6.9.1 of
   [RFC5213].

5.3.  Local Mobility Anchor Operation

   The text in the following sections refers to an '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



Korhonen, et al.         Expires April 15, 2012                [Page 11]

Internet-Draft           Runtime LMA Assignment             October 2011


   'rfLMA' or the 'r2LMA'.

   If the runtime assignment functionality is enabled (see
   EnableLMARedirectFunction configuration object in Section 7) in the
   rfLMA but the LMA assignment is not going to take place for some
   reason, 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.  If the rfLMA is able to make the assignment
   to an r2LMA, it returns a PBA with the Redirect mobility option as
   defined below.  Otherwise, the rfLMA MUST act as a normal RFC 5213 or
   RFC 5844 defined LMA for the MAG.

   The rfLMA MUST only assign the MAG to a new r2LMA with which it knows
   the MAG has an SA or with which it knows the MAG can establish an SA
   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
   change the used transport IP address family during the runtime LMA
   assignment.

   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.

   Next we describe two deployment and implementation models for the
   runtime LMA assignment.  In Section 5.3.1, we describe a model where
   the rfLMA and r2LMA are collocated.  In Section 5.3.2 we describe a
   model where rfLMA acts as a non-transparent 'proxy MAG', and where
   the rfLMA and the r2LMA are separate.  There can be even more
   implementation options depending on the rfLMA and the r2LMA
   collocation properties, and how the inter-LMA communication is
   arranged.

5.3.1.  Collocated rfLMA and r2LMA Functions

   In this solution approach the rfLMA and the r2LMA are part of the
   same 'collocated LMA', and may even be using to the same physical
   network interface.  The rfLMA is reachable via an anycast or a
   loopback address of the LMA.  Each r2LMA is reachable via its unicast
   address.  Figure 2 illustrates example signaling flows for the
   solution.




Korhonen, et al.         Expires April 15, 2012                [Page 12]

Internet-Draft           Runtime LMA Assignment             October 2011


   The MAG-LMA SA is between the MAG and the rfLMA (i.e. the anycast or
   the loopback 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.

   The rfLMA becomes active when the runtime LMA assignment
   functionality is enabled (see EnableLMARedirectFunction configuration
   object in Section 7).  When the rfLMA receives a PBU destined to it,
   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 is no existing
   tunnel between the MAG and the r2LMA unicast address, then the r2LMA
   creates one as described in Section 5.3 of [RFC5213].  The r2LMA used
   for accepting and anchoring the mobility session MUST also have the
   runtime LMA assignment functionality enabled (see
   EnableLMARedirectAcceptFunction configuration object in Section 7).

   If the mobility session creation succeeded, then 'collocated LMA' in
   the rfLMA role sends a PBA to the MAG.  The PBA is sourced using the
   rfLMA (anycast or loopback) address.  The PBA MUST contain the r2LMA
   unicast address (IPv6 or IPv4) in the Redirect mobility option.

   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.

   If the PBU is received on the rfLMA address and there is no Redirect-
   Capability mobility option in the PBU, then the 'collocated LMA' MAY
   choose to be a LMA for the MAG (assuming the rfLMA address is not an
   anycast address).  Otherwise, the rfLMA 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.3).



















Korhonen, et al.         Expires April 15, 2012                [Page 13]

Internet-Draft           Runtime LMA Assignment             October 2011


         [MAG]                       [rfLMA  /r2LMA_1/r2LMA_2/r2LMA_3]
           |                             |       |       |       |
   MAG discovers rfLMA                   |       |       |       |
   BULE for rfLMA                        |       |       |       |
           |                             |       |       |       |
           |-- PBU --------------------->|       |       |       |
           |   src=MAG_Proxy-CoA,        |       |       |       |
           |   dst=rfLMA,                |       |       |       |
           |   Redirect-Capability, ..   |  r2LMA gets selected  |
           |                             BCE is created in r2LMA_2
           |                             |Tunnel setup in r2LMA_2|
           |                             |       |       |       |
           |<- PBA ----------------------|       |       |       |
           |   src=rfLMA,                |       |       |       |
           |   dst=MAG_Proxy-CoA,        |       |       |       |
           |   Redirect=r2LMA_2_address, |       |       |       |
           |   Load Info, ..             |       |       |       |
           |                             |       |       |       |
   BULE updated to r2LMA_2               |       |       |       |
      Tunnel setup                       |       |       |       |
           |                             |       |       |       |
           |<=========== MAG-r2LMA_2 tunnel ============>|       |
           |                             |       |       |       |
   Lifetime extension etc                |       |       |       |
           |                             |       |       |       |
           |-- PBU ------------------------------------->|       |
           |   src=MAG_Proxy-CoA,        |       |       |       |
           |   dst=r2LMA_2, ..           |       |       |       |
           |                             |       |       |       |
           |<- PBA --------------------------------------|       |
           |   src=r2LMA_2,              |       |       |       |
           |   dst=MAG_Proxy-CoA,        |       |       |       |
           |   Load Info, ..             |       |       |       |
           |                             |       |       |       |

               Figure 2: Collocated rfLMA and r2LMA example

5.3.2.  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.  The
   r2LMA can be any RFC 5213 or RFC 5844 compliant LMA without any
   knowledge of this specification when IPv6 transport is used.  In case
   of IPv4 transport the RFC 5844 compliant LMA MUST also implement the
   Alternate IPv4 Care-of Address option (see Section 4.4).  Figure 3
   illustrates example signaling flows for the solution.

   The rfLMA is actually a non-transparent 'proxy-MAG' (see [RFC2616]



Korhonen, et al.         Expires April 15, 2012                [Page 14]

Internet-Draft           Runtime LMA Assignment             October 2011


   for a generic definition of a non-transparent proxy, although for
   HTTP, but the idea also applies here) 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 protocol between the
   'proxy-MAG' and the r2LMA is the base RFC 5213 PMIPv6 protocol.

   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.

   When the rfLMA receives a PBU, and the PBU contains the Redirect-
   Capability mobility option, then the rfLMA in a 'proxy-MAG' role:

   o  Processes the PBU using the procedures described in RFC 5213
      except that no mobility session gets created.  Instead the rfLMA
      creates a proxy state based on the received PBU.

   o  The rfLMA assigns a r2LMA to the MAG.

   o  The rfLMA creates a new PBU', which includes all non-security
      related mobility options from the original PBU and an Alternate
      Care-of Address (ACoA) option containing the Proxy Care-of Address
      of the original MAG.  If the original PBU already included an
      Alternate Care-of Address option, then the content of the
      Alternate Care-of Address option in the PBU' MUST be the same as
      in the original PBU.

      Note, in case of IPv4 transport [RFC5844], the Alternate IPv4
      Care-of Address (A4CoA) option MUST be used and contain the IPv4
      Proxy Care-of Address of the original MAG.

   o  The rfLMA sends the new PBU' sourced from its 'proxy-MAG' IPv6 or
      IPv4 Proxy Care-of Address and destined to the r2LMA address using
      the procedures described in RFC 5213 (or RFC 5844 in case of IPv4
      transport).

   The r2LMA processed the received PBU' using the procedures described
   in RFC 5213 or RFC 5844.  In case of IPv4 transport, the r2LMA uses
   the IPv4 Proxy Care-of Address from the Alternate IPv4 Care-of
   Address option for the tunnel setup and the creation of the BCE.  The
   reply PBA' MUST be destined to the source address of the received
   PBU' i.e. the Care-of Address the 'proxy-MAG'.

   Once the rfLMA in a 'proxy-MAG' role receives a reply PBA' from the



Korhonen, et al.         Expires April 15, 2012                [Page 15]

Internet-Draft           Runtime LMA Assignment             October 2011


   r2LMA and the mobility session creation succeeded in the r2LMA, the
   rfLMA sends a PBA to the original MAG.  The PBA is sourced from the
   rfLMA address and destined to MAG (IPv6 or IPv4) Proxy Care-of
   Address.  The PBA MUST contain the r2LMA (IPv6 or IPv4) unicast
   address in the Redirect mobility option.  Other non-security related
   mobility options (including the Load Information option) are copied
   from the PBA' to the PBA as such.

   In the case of an error:

   o  The PBA' Status Value indicates that the mobility session creation
      failed in the r2LMA.  For example, the Status Value in the PBA' is
      set to 130 - Insufficient resources, or

   o  there was no PBA' response from the r2LMA, or

   o  the PBA' did not include the Alternate IPv4 Care-of Address option
      although it was included in the corresponding PBU' (when using
      IPv4 transport),

   then the rfLMA SHOULD assign the MAG to a new r2LMA and rerun the
   PBU' sending procedure described earlier for the new r2LMA.  The
   number and order of r2LMA reassignments attempts is controlled by the
   local policy and the amount of known r2LMAs in the rfLMA.  When the
   rfLMA in a 'proxy-MAG' role concludes the mobility session creation
   failed with r2LMA(s), the rfLMA MUST set the Status Value in the PBA
   as received from the latest contacted PBA' Status Value or to 130
   (Insufficient resources) in case of no responses from rfLMAs, and
   send the reply PBA to the MAG.  The PBA is sourced from the rfLMA
   address and destined to MAG Proxy Care-of Address.  Other possible
   non-security related mobility options (including the Load Information
   option) are copied from the PBA' to the PBA as such.

   Once the rfLMA has sent the reply PBA to the MAG, it can remove the
   proxy state.  Subsequent traffic between the MAG and the r2LMA will
   bypass the rfLMA (assuming the mobility session creation succeeded in
   the r2LMA).

   If the rfLMA receives a PBU with no Redirect-Capability mobility
   option in the PBU, then the PBU is processed as described in
   Section 5.3), i.e. the rfLMA may or may not act as a RFC 5213 or RFC
   5844 LMA to the MAG.









Korhonen, et al.         Expires April 15, 2012                [Page 16]

Internet-Draft           Runtime LMA Assignment             October 2011


     [MAG]                        [rfLMA]                      [r2LMA]
       |                             |                             |
   MAG discovers rfLMA               |                             |
   BULE for rfLMA                    |                             |
       |                             |                             |
       |-- PBU --------------------->|  rfLMA assigns a r2LMA and  |
       |   src=MAG_Proxy-CoA,        |  creates a proxy state      |
       |   dst=rfLMA,                |                             |
       |   Redirect-Capability, ..   |                             |
       |                             |-- PBU' -------------------->|
       |                             |   src=proxy-MAG_Proxy-CoA,  |
       |                             |   dst=r2LMA,                |
       |                             |   ACoA/A4CoA=MAG_Proxy-CoA, |
       |                             |   ..                        |
       |                             |             BCE created in r2LMA
       |                             |                     Tunnel setup
       |                             |       Proxy-CoA is MAG's address
       |                             |                             |
       |   rfLMA removes the         |<- PBA' ---------------------|
       |   proxy state               |   src=r2LMA,                |
       |                             |   dst=proxy-MAG_Proxy-CoA,  |
       |                             |   Load Info, ..             |
       |<- PBA ----------------------|                             |
       |   src=rfLMA,                |                             |
       |   dst=MAG_Proxy-CoA,        |                             |
       |   Redirect=r2LMA_address,   |                             |
       |   Load Info, ..             |                             |
       |                             |                             |
   BULE updated to r2LMA             |                             |
   Tunnel setup                      |                             |
       |                             |                             |
       |<===================== MAG-r2LMA tunnel ==================>|
       |                             |                             |
   Lifetime extension etc            |                             |
       |                             |                             |
       |-- PBU --------------------------------------------------->|
       |   src=MAG_Proxy-CoA, dst=r2LMA, ..                        |
       |                             |                             |
       |<- PBA ----------------------------------------------------|
       |   src=r2LMA, dst=MAG_Proxy-CoA, Load Info, ..             |
       |                             |                             |

         Figure 3: Separate rfLMA and r2LMA ('proxy-MAG') example








Korhonen, et al.         Expires April 15, 2012                [Page 17]

Internet-Draft           Runtime LMA Assignment             October 2011


6.  Handoff and Multi-Homing Considerations

   A MN can be multi-homed i.e. have network connectivity over multiple
   interfaces connected one or more accesses.  If PMIPv6-based handovers
   between multiple interfaces or accesses are desired then a single LMA
   should have a control over all possible multi-homed mobility sessions
   the MN has.  Once the MN has established one mobility session with
   one LMA, the subsequent mobility sessions of the same MN would be
   anchored to the LMA that was initially assigned.  If each mobility
   session over a different interface (and possibly a MAG) has no
   requirements for PMIPv6-based handovers between accesses or
   interfaces, then the rest of the considerations in this section do
   not apply.

   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.  Discovering the same r2LMA each time
   has an assumption that the MN has an identity that can always point
   to the same policy profile independent of the used access.

   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 Objects

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

   EnableLMARedirectFunction

      This configuration object 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 April 15, 2012                [Page 18]

Internet-Draft           Runtime LMA Assignment             October 2011


   EnableLMARedirectAcceptFunction

      This configuration object 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).

   Note that the MAG and LMA configuration objects from [RFC5213]
   Sections 9.1 and 9.2 do not apply for an LMA when in an rfLMA role.


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), 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
   [RFC6275] "Mobility Options" registry.  The mobility options are
   defined in Section 4:




Korhonen, et al.         Expires April 15, 2012                [Page 19]

Internet-Draft           Runtime LMA Assignment             October 2011


       Redirect-Capability Mobility Option is set to   TBD1
       Redirect Mobility Option is set to              TBD2
       Load Information Mobility Option is set to      TBD4
       Alternate IPv4 Care-of Address is set to        TBD5


10.  Acknowledgements

   The author would like to thank Basavaraj Patil, Domagoj Premec, Ahmad
   Muhanna, Vijay Devarapalli, Rajeev Koodli, Yungui Wang, Pete McCann
   and Qin Wu for their discussion on this document.  A special thank to
   Qian Li for her detailed feedback on the protocol details.


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.

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

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

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.

   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

   [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,
              "Mobility Header Home Agent Switch Message", RFC 5142,
              January 2008.

   [RFC5779]  Korhonen, J., Bournelle, J., Chowdhury, K., Muhanna, A.,



Korhonen, et al.         Expires April 15, 2012                [Page 20]

Internet-Draft           Runtime LMA Assignment             October 2011


              and U. Meyer, "Diameter Proxy Mobile IPv6: Mobile Access
              Gateway and Local Mobility Anchor Interaction with
              Diameter Server", RFC 5779, February 2010.

   [RFC5844]  Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy
              Mobile IPv6", RFC 5844, May 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 April 15, 2012                [Page 21]

Internet-Draft           Runtime LMA Assignment             October 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 April 15, 2012                [Page 22]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/