Network Working Group                                   J. Korhonen, Ed.
Internet-Draft                                    Nokia Siemens Networks
Intended status: Standards Track                           S. Gundavelli
Expires: April 10, 2010                                            Cisco
                                                               H. Yokota
                                                                KDDI Lab
                                                                  X. Cui
                                                                  Huawei
                                                         October 7, 2009


          Runtime LMA Assignment Support for Proxy Mobile IPv6
                 draft-korhonen-netext-redirect-04.txt

Status of this Memo

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

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on April 10, 2010.

Copyright Notice

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

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




Korhonen, et al.         Expires April 10, 2010                 [Page 1]


Internet-Draft       LMA Redirect Support for PMIPv6        October 2009


Abstract

   This document describes a redirect functionality and corresponding
   mobility options for Proxy Mobile IPv6.  The redirect functionality
   allows a dynamic runtime assignment of a Local Mobility Anchor and
   redirecting the mobility session to the assigned Local Mobility
   Anchor.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Requirements and Terminology . . . . . . . . . . . . . . . . .  5
     2.1.  Requirements . . . . . . . . . . . . . . . . . . . . . . .  5
     2.2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Proxy Mobile IPv6 Domain Assumptions . . . . . . . . . . . . .  6
   4.  Mobility Options . . . . . . . . . . . . . . . . . . . . . . .  7
     4.1.  Redirect-Capability Mobility Option  . . . . . . . . . . .  7
     4.2.  Redirect Mobility Option . . . . . . . . . . . . . . . . .  8
   5.  Runtime LMA Assignment Operation . . . . . . . . . . . . . . . 10
     5.1.  Common Mobile Access Gateway Operation . . . . . . . . . . 10
     5.2.  Common Local Mobility Anchor Operation . . . . . . . . . . 10
     5.3.  Mobility Session Created During the Redirection  . . . . . 11
       5.3.1.  General Operation  . . . . . . . . . . . . . . . . . . 11
       5.3.2.  Mobile Access Gateway Considerations . . . . . . . . . 12
       5.3.3.  Local Mobility Anchor Considerations . . . . . . . . . 13
     5.4.  Mobility Session Created After the Redirection . . . . . . 14
       5.4.1.  General Operation  . . . . . . . . . . . . . . . . . . 14
       5.4.2.  Mobile Access Gateway Considerations . . . . . . . . . 14
       5.4.3.  Local Mobility Anchor Considerations . . . . . . . . . 15
     5.5.  Redirection Example  . . . . . . . . . . . . . . . . . . . 15
       5.5.1.  Redirection During the Initial PBU/PBA Exchange  . . . 16
       5.5.2.  Redirection During Mid-session PBU/PBA Exchange  . . . 17
   6.  Multi-Homing Considerations  . . . . . . . . . . . . . . . . . 18
   7.  Configuration Variables  . . . . . . . . . . . . . . . . . . . 19
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 20
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 21
   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 23
     11.2. Informative References . . . . . . . . . . . . . . . . . . 23
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24









Korhonen, et al.         Expires April 10, 2010                 [Page 2]


Internet-Draft       LMA Redirect Support for PMIPv6        October 2009


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).  Hereafter the terms 'runtime assignment' and 'redirection'
   are used interchangeably throughout this specification.  The runtime
   assignment takes place during a Proxy Binding Update (PBU) and a
   Proxy Binding Acknowledgement (PBA) messages exchange between a
   Mobile Access Gateway (MAG) and a LMA.  The runtime assignment
   functionality defined in this specification can be used, for example,
   for load balancing purposes during the initial PBU/PBA messages
   exchange.  However, other use cases are also possible.  In case of
   load balancing, the runtime assignment approach is just one
   implementation option.  MAGs and LMAs can implement other solutions
   that are, for example, completely transparent at PMIPv6 protocol
   level and do not depend on the functionality defined in this
   specification.

   The runtime 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 assignment is an 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 redirection 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



Korhonen, et al.         Expires April 10, 2010                 [Page 3]


Internet-Draft       LMA Redirect Support for PMIPv6        October 2009


      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 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.  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.  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.  Although
      [RFC4291] now allows using anycast addresses as source addresses,
      it does not make much sense using anycast addresses for the MAG to
      the LMA communication after the initial PBU/PBA exchange.  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.

















Korhonen, et al.         Expires April 10, 2010                 [Page 4]


Internet-Draft       LMA Redirect Support for PMIPv6        October 2009


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:

   rfLMA

      The LMA which receives the PBU from a MAG and decides to redirect
      the IP mobility session to the target LMA (r2LMA).

   r2LMA

      The LMA to which a MAG was redirected to.

   Redirection Domain

      A group of LMAs that consist of at least one rfLMA and one or more
      r2LMAs.  A rfLMA is allowed to redirect mobility sessions only to
      r2LMAs that belong to the same redirection domain.
























Korhonen, et al.         Expires April 10, 2010                 [Page 5]


Internet-Draft       LMA Redirect Support for PMIPv6        October 2009


3.  Proxy Mobile IPv6 Domain Assumptions

   The redirection functionality has several assumptions on the PMIPv6
   domain.  They are discussed here as they have impact on PMIPv6
   deployment.

   Each functional LMA, whether that is a separate LMA in a cluster or
   an individual blade in a chassis, participating to the redirection
   MUST be reachable at an unicast IP address.  The rfLMA and the r2LMA
   MUST have a prior agreement and an established trust relationship to
   perform the redirection.  In this case, the rfLMA and the r2LMA are
   said to belong to the same 'redirection domain'.

   The rfLMA MUST NOT redirect the mobility session to a r2LMA that is
   not able to accept the redirected mobility session.  That is, the
   redirection functionality is not enabled in the r2LMA, or the r2LMA
   does not belong to the same redirection domain as the rfLMA, or the
   r2LMA is down or otherwise unreachable.  How the rfLMA learns and
   knows of other r2LMAs in the redirection domain, is not covered by
   this specification.

   Each LMA and MAG participating to the redirection is assumed to have
   required Security Associations (SA) already set up in advance.
   Dynamic negotiation of the SAs using e.g., IKEv2 [RFC4306] MAY be
   supported but is out of scope of this specification.  However, it
   should be noted that if anycast addresses are used within the PMIPv6
   domain to contact the rfLMA, then manual keying of the SAs may be
   required [RFC4303].

   The redirection functionality negotiation during the PBU/PBA exchange
   is stateless.  The LMA MUST NOT include the Redirect mobility option
   in the PBA and perform the redirection, unless the MAG indicated the
   redirection 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 redirection functionality.  The MAG MUST
   NOT conclude LMA's redirection functionality support based on the
   absence of the Redirect mobility option in the PBA.













Korhonen, et al.         Expires April 10, 2010                 [Page 6]


Internet-Draft       LMA Redirect Support for PMIPv6        October 2009


4.  Mobility Options

   The Redirect mobility options allow a LMA to inform a MAG of a
   redirection to a new LMA during a PBU/PBA exchange.  MAGs and LMAs
   that implement the Redirect mobility option MUST support the
   redirection functionality during the initial PBU/PBA exchange that
   creates a new mobility session.  MAGs and LMAs that implement the
   Redirect mobility option MAY support the redirection of an
   established mobility session.

4.1.  Redirect-Capability Mobility Option

   A PBU message MAY contain the Redirect-Capability mobility option as
   an indication to a LMA that a MAG supports the redirection
   functionality.  When this option is included, the MAG may be
   redirected to another LMA, and the redirected to LMA may
   simultaneously create a Binding Cache Entry (BCE).  Hence, the MAG
   including this option MUST be able to support both redirection, and
   redirection with BCE creation.  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 |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.

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

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







Korhonen, et al.         Expires April 10, 2010                 [Page 7]


Internet-Draft       LMA Redirect Support for PMIPv6        October 2009


4.2.  Redirect Mobility Option

   The LMA MAY include the Redirect mobility option in a PBA only if the
   MAG indicated support for the redirection functionality and the
   mobility session was redirected from a LMA to another.  The Redirect
   mobility option in the PBA MUST contain an unicast IPv6 address of
   the r2LMA.  The Redirect mobility option in the PBA MAY contain an
   IPv4 address of the r2LMA.  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 |D|        Reserved             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                      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 the IPv4 LMA Address is included in the
      option, the Option Length MUST be set to 22.  Otherwise, the
      Option Length MUST be set to 18.

   o  'D' flag: This bit is set to one (1) if the mobility session (and
      the corresponding Binding Cache Entry) is already created in the
      r2LMA.  Otherwise, the bit is set to zero (0).

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

   o  IPv6 r2LMA Address: the unicast IPv6 address of the r2LMA.





Korhonen, et al.         Expires April 10, 2010                 [Page 8]


Internet-Draft       LMA Redirect Support for PMIPv6        October 2009


   o  Optional IPv4 r2LMA Address: the IPv4 address of the r2LMA.  This
      value is present if the r2LMA IPv4 address is available.

















































Korhonen, et al.         Expires April 10, 2010                 [Page 9]


Internet-Draft       LMA Redirect Support for PMIPv6        October 2009


5.  Runtime LMA Assignment Operation

5.1.  Common Mobile Access Gateway Operation

   The base PMIPv6 protocol [RFC5213] operation is such that a MAG sends
   a PBU to an LMA which results in a BCE being created at the LMA and a
   PBA sent back (from the LMA) to the MAG, which in turn creates an
   entry in the Binding Update List (BUL).  The semantics of the base
   protocol operation are extended with the redirection feature by
   having the rfLMA forward the PBU sent by a MAG to the r2LMA (which
   creates the BCE) and the PBA which is routed back to the sending MAG
   through rfLMA, causing the MAG to create a BUL which points to r2LMA.
   The semantics in the case where the rfLMA does not forward the PBU
   but instead returns a PBA to the MAG which includes the Redirect
   Mobility option which has the address of the r2LMA are also extended
   from the base protocol operation.

   Backwards compatibility is maintained in a deployment wherein some
   MAGs may have the ability to support redirection while others do not.
   This is accomplished by the use of the Redirect-Capability Mobility
   Option being included in the PBU sent by the MAG.  An LMA which has
   the capability to redirect a MAG to a target r2LMA on receiving a PBU
   from a legacy MAG can only respond with a PBA which does not include
   any r2LMA address.

   When the redirection functionality is enabled, then the MAG MAY
   include the Redirect-Capability mobility option in any PBU.  The
   Redirect-Capability mobility option in the PBU is also an indication
   to a LMA that the MAG supports the redirection functionality and is
   prepared to be redirected.  The redirection 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
   the corresponding PBU, then the MAG MUST treat the PBA as if the
   binding update failed and log the event.

5.2.  Common Local Mobility Anchor Operation

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

   If the redirection functionality is enabled in the LMA but the
   redirection 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



Korhonen, et al.         Expires April 10, 2010                [Page 10]


Internet-Draft       LMA Redirect Support for PMIPv6        October 2009


   PBA with Status Value set to NOT_LMA_FOR_THIS_MAG error code.
   Otherwise, the rfLMA MUST act as a normal RFC 5213 defined LMA for
   the MAG.

   The rfLMA MUST only redirect the MAG to 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 redirect the MAG to a r2LMA that the
   rfLMA and the r2LMA do not have a prior redirection agreement and an
   established trust relationship for the redirection.  These SA related
   knowledge issues and trust relationships are deployment specific in a
   PMIPv6 domain and in a redirection 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 redirection domain.

   The rfLMA MUST NOT redirect a MAG using IPv6 transport to 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 redirecting a MAG using IPv4
   transport to a r2LMA supporting only IPv6 transport.

   As a result of a successful redirection, the PBA MUST contain the
   Redirect mobility option with a valid r2LMA Address, the 'D' flag
   reflecting the r2LMA status, and the PBA Status Value indicating
   either success or redirection.

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

5.3.  Mobility Session Created During the Redirection

5.3.1.  General Operation

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








Korhonen, et al.         Expires April 10, 2010                [Page 11]


Internet-Draft       LMA Redirect Support for PMIPv6        October 2009


     MAG     rfLMA    r2LMA
      |        |        |
   1) |--PBU-->|  ~ ~ ~ | (redirection takes place, BCE gets created in
   2) |<--PBA--| ~ ~ ~  |  r2LMA, PBA contains r2LMA information and
      |        |        |  'D' flag is set to 1
   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 redirection 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.  The interaction
   between the rfLMA and the r2LMA in the redirection domain is not
   defined in this specification.  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, and whether the
   rfLMA and the r2LMA implement an interface that is interoperable
   among multiple LMA vendors.  One potential example solution is
   discussed in Section 5.5.

5.3.2.  Mobile Access Gateway Considerations

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

   If the MAG receives a PBA that contains the Redirect mobility option
   with the 'D' flag set to one (1) 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  Check if there is a SA between the MAG and the r2LMA.  If this
      check fails, then the MAG MUST treat the PBA as if the binding
      update failed and log the event.  This situation should not happen
      and is an indication of incorrectly configured or malfunctioning
      redirection domain.

   o  If there was no SA between the MAG and the r2LMA and the above
      bullet described PBA handling was done, then the MAG MAY still
      resend the PBU to the same rfLMA without including the Redirect-
      Capability mobility option.  However, the MAG SHOULD choose
      another rfLMA to contact, if just possible.




Korhonen, et al.         Expires April 10, 2010                [Page 12]


Internet-Draft       LMA Redirect Support for PMIPv6        October 2009


   If the redirection was successful, the MAG updates the BUL to
   correspond the r2LMA Address included in the received Redirect
   mobility option.  There is no need to resend any PBUs to the r2LMA
   after a successful redirection.  The mobility session has already
   been established in the r2LMA as indicated by the 'D' flag with value
   one (1) in the Redirection mobility option.  The MAG MUST send
   subsequent binding refreshing PBUs and user traffic to the new r2LMA
   Address.  If the MAG includes the Redirect-Capability mobility option
   in subsequent PBUs, the LMA MAY redirect the MAG again.  For the
   subsequent mid-session redirections it is assumed that the r2LMA also
   has the rfLMA functionality.  [ED: discuss the setting of the Handoff
   Indicator option value in this case and what happens if the HNP/
   IPv4-HoA changes.]

5.3.3.  Local Mobility Anchor Considerations

   If the redirection functionality is enabled in the LMA and the
   received PBU contains the Redirect-Capability mobility option, then
   the rfLMA MAY redirect the MAG to a new r2LMA.  In the case of
   redirection, the PBA returned to the MAG MUST always include the
   unicast IPv6 address of the r2LMA in the Redirect mobility option
   with the 'D' flag set to one (1) and the Status Value set to a value
   indicating success.  If the r2LMA has IPv4 support enabled, then the
   PBA returned to the MAG SHOULD include the IPv4 address of the r2LMA
   in the Redirect mobility option.  If the rfLMA did not redirect the
   MAG to a new r2LMA or the redirection failed, then the PBA MUST NOT
   contain the Redirect mobility option.

   If the redirection was successful, the mobility session MUST be
   established in the r2LMA.  The actual PBU processing that creates the
   mobility session and the corresponding BCE takes place in the r2LMA.
   However, depending on the LMA's implementation of the PMIPv6 security
   framework, the security processing (such as IPsec) of the PBU may
   take place in the rfLMA before the PBU is transferred from the rfLMA
   to the r2LMA.  Whenever the redirection processing has involved the
   r2LMA, the PBA sent by the rfLMA to the MAG MUST reflect the
   information the r2LMA would include in its PBA (such as mobility
   options, Status Value and so on).  The only exceptions are possible
   security related options that the rfLMA MAY need to modify or remove.
   The rfLMA is always allowed to add more mobility options to the PBA.

   During the redirection process, the rfLMA MAY need to maintain a
   temporary MAG-rfLMA-r2LMA state and may even act as a "proxy MAG" to
   the r2LMA.  This, however, depends on the collocation properties of
   the rfLMA and the r2LMA, and how the rfLMA interact with the r2LMA.
   The interaction may happen as a PBU/PBA packet forwarding in a
   conventional sense or as an inter-blade communication using some LMA
   architecture specific communication method.  Once the redirection has



Korhonen, et al.         Expires April 10, 2010                [Page 13]


Internet-Draft       LMA Redirect Support for PMIPv6        October 2009


   completed successfully from the rfLMA point of view and it has sent
   the PBA to the MAG, the rfLMA can remove all state information
   regarding the recent redirection.

5.4.  Mobility Session Created After the Redirection

5.4.1.  General Operation

   During the redirection the PBA is returned from the LMA Address where
   the PBU was sent to i.e., from the rfLMA.  After the redirection, 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 redirection flow sequence is shown in Figure 2.


     MAG     rfLMA    r2LMA
      |        |        |
   1) |--PBU-->|        | (redirection takes place, PBA contains r2LMA
   2) |<--PBA--|        |   information, 'D' flag is set to 0 )
      |        |        |
   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
                            redirection domain

   The assumption in the signaling flow steps 1) and 2) shown in
   Figure 2 is that the MAG is only redirected to 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 Considerations

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

   o  The 'D' flag in the received Redirection mobility option is set to
      zero (0).  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 Status Value in the received PBA MUST have been set
      to the value TBD.  The MAG was only assigned with a new r2LMA
      Address information.



Korhonen, et al.         Expires April 10, 2010                [Page 14]


Internet-Draft       LMA Redirect Support for PMIPv6        October 2009


   o  Check if there is a SA between the MAG and the r2LMA.  If this
      check fails, then the MAG MUST either treat the PBA as if the
      binding update failed and log the event, or initiate dynamic
      creation of the SA between the MAG and the r2LMA (note that the
      dynamic creation of the SA is outside of the scope of this
      specification).

   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 redirection has completed.
      The initial PBU sent to the r2LMA SHOULD NOT contain the Redirect-
      Capability mobility option in order to avoid possible immediate
      new redirection.

5.4.3.  Local Mobility Anchor Considerations

   If the redirection functionality is enabled in the LMA and the
   received PBU contains the Redirect-Capability mobility option, then
   the rfLMA MAY redirect the MAG to a new r2LMA.  In the case of
   redirection, the PBA returned to the MAG MUST always include the
   unicast IPv6 address of the r2LMA in the Redirect mobility option
   with the 'D' flag set to zero (0) and the Status Value MUST be set to
   the value TBD.  If the r2LMA has IPv4 support enabled, then the PBA
   returned to the MAG SHOULD include the IPv4 address of the r2LMA in
   the Redirect mobility option.  If the rfLMA did not redirect the MAG
   to a new r2LMA or the redirection failed, then the PBA MUST NOT
   contain the Redirect mobility option.

5.5.  Redirection Example

   This section gives a high level example of one possible "Mobility
   Session Created During the Redirection" solution discussed in
   Section 5.3.  The example shows how the complete procedure for a LMA
   redirection takes place in a PMIPv6 domain and eventually ends up to
   a creation of a mobility session between a MAG and a r2LMA.  Note
   that this section is only for example purposes, not for specifying
   the rfLMA to the r2LMA interaction.

   During the redirection PBU/PBA exchange, the mobility session and the
   corresponding BCE gets created in the r2LMA before the rfLMA sends
   the PBA back to the MAG (see the dotted lines between the rfLMA and
   the r2LMA in steps 1) and 2) in Figure 1).  The mobility session can
   only be created in the r2LMA that belongs to the same redirection
   domain as the rfLMA.  The example solution described here has the
   assumption that the rfLMA also has limited MAG functionality, and the
   rfLMA and r2LMAs have required SAs established, if needed.





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


Internet-Draft       LMA Redirect Support for PMIPv6        October 2009


5.5.1.  Redirection During the Initial PBU/PBA Exchange

   Here we describe the redirection during the initial PBU/PBA exchange.
   Error cases are excluded for the brevity.

   o  A MAG discovers a LMA Address in a PMIPv6 domain using some
      mechanism and that LMA happens to be a rfLMA in some redirection
      domain.

   o  The MAG creates and sends a PBU to the rfLMA as defined in
      Section 5.3.2 of this specification.

   o  The rfLMA receives the PBU from a MAG.  The PBU contains relevant
      mobility options to enable redirection such as the Redirect-
      Capability mobility option.

   o  The rfLMA does the security processing on the PBU as described in
      RFC 5213.  The rfLMA selects an appropriate r2LMA for the mobility
      session under the conditions described in Section 5.3.3 of this
      specification and creates a temporary MAG-rfLMA-r2LMA state.  The
      rfLMA has to maintain this state until the redirection process
      completes from its point of view.

   o  The rfLMA overwrites the source address of the PBU with its own
      address and also overwrites the destination address of the PBU
      with the r2LMA Address.  Furthermore, the rfLMA includes the
      Alternate Care-of Address mobility option containing the MAG
      Address into the PBU (if it was not already present) and also
      removes the Redirect-Capability mobility option from the PBU.
      After this, the rfLMA forwards the PBU to the r2LMA.

   o  The r2LMA receives the PBU, processes it and creates the mobility
      session with the MAG as defined in RFC 5213.  After successfully
      processing the PBU the r2LMA forwards a PBA to the rfLMA as
      defined in RFC 5213.

   o  The rfLMA receives the PBA from the r2LMA and processes it
      according to the information it has concerning the temporary MAG-
      rfLMA-r2LMA state.  This step involves the rfLMA overwriting the
      source and destination addresses of the PBA according to the
      temporary state information (the source address of the PBA will be
      the rfLMA Address and the destination address of the PBA will be
      the MAG Address).  The rfLMA includes the Redirect mobility option
      with the appropriate r2LMA address information and 'D' flag set to
      1 into the PBA.  After this the rfLMA sends the PBA to the MAG.

   o  The MAG receives the PBA from the rfLMA and processes it as
      defined in RFC 5213 and additionally in Section 5.3.2 of this



Korhonen, et al.         Expires April 10, 2010                [Page 16]


Internet-Draft       LMA Redirect Support for PMIPv6        October 2009


      specification.

   In addition to the above steps, the rfLMA and the r2LMAs, and a group
   of r2LMAs may e.g. exchange additional status, context and load
   information between each other.  How this information exchange is
   done, is out of scope of this example and the specification.
   Furthermore, how and based on what criteria the rfLMA selects an
   appropriate r2LMA is also out of scope of this example and the
   specification.

5.5.2.  Redirection During Mid-session PBU/PBA Exchange

   Here we briefly discuss the mid-session redirection during a re-
   registration or a handover triggered PBU/PBA exchange.  From the MAG
   point of view the actual procedural steps for mid-session redirection
   are the same as described in Section 5.5.1.  There are few notable
   differences on the LMA side though.

   o  The previous r2LMA cannot redirect the mobility session to a new
      r2LMA during the re-registration or the handover PBU/PBA exchange
      unless it also implements rfLMA functionality.  The lack of rfLMA
      functionality in the r2LMA implicitly prohibits mid-session
      redirection using the solution defined in this specification.

   o  The previous r2LMA cannot redirect the mobility session to a new
      r2LMA during the re-registration or the handover PBU/PBA exchange
      unless the previous r2LMA is able to transfer the "mobility
      session context" to the new r2LMA.  Otherwise, the new r2LMA would
      receive a PBU with Handoff Indicator set to other than "Attachment
      over a new interface" and there would not be a matching BCE.  This
      is an undefined situation and would most likely result the
      mobility session to be terminated.  [ED: add more details here].
      Note that a possible context transfer between LMAs is out of scope
      of this specification.

















Korhonen, et al.         Expires April 10, 2010                [Page 17]


Internet-Draft       LMA Redirect Support for PMIPv6        October 2009


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
























Korhonen, et al.         Expires April 10, 2010                [Page 18]


Internet-Draft       LMA Redirect Support for PMIPv6        October 2009


7.  Configuration Variables

   This specification defines three configuration variables that control
   the redirection functionality within a PMIPv6 domain.

   EnableLMARedirectFunction

      This configuration variable is available in both a MAG and in a
      rfLMA.  When set to 1 (i.e., enabled), the PMIPv6 node enables the
      redirection functionality.  The default value is 0 (i.e.,
      disabled).

   EnableLMARedirectAcceptFunction

      This configuration variable is available in a r2LMA.  When set to
      1 (i.e., enabled), the r2LMA is able to accept redirected mobility
      sessions from a rfLMA.  The default value is 0 (i.e., disabled).


































Korhonen, et al.         Expires April 10, 2010                [Page 19]


Internet-Draft       LMA Redirect Support for PMIPv6        October 2009


8.  Security Considerations

   The security considerations of PMIPv6 signaling described in RFC 5213
   apply to this document.  An incorrectly configured LMA may cause
   unwanted redirection attempts to non-existing LMAs or to other LMAs
   that do not have and will not have a SA with the redirected MAG.  At
   the same time, a falsely redirected MAG will experience failed
   binding updates or 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 redirection have adequate prior agreement and trust
   relationship between each other.

   If the SAs between MAGs and LMAs are manually keyed (as it might be
   needed by the 'direct redirection answer' scenario), then the anti-
   replay service of ESP protected PMIPv6 traffic cannot typically be
   provided.  This is, however, deployment specific for a PMIPv6 domain.

   If a PMIPv6 domain deployment with a redirection requires that a
   rfLMA has to modify a received PBU in any way e.g., by changing the
   destination IP address field of the outer IP header, then the
   security mechanism (such as possible authentication options) used to
   protect the PBU must not cover the outer IP header on those parts
   that might get modified.  Alternatively, the rfLMA can do all
   required security mechanism processing on the received PBU and remove
   those security related options from the PBU that would cause the
   security check to fail on the r2LMA.
























Korhonen, et al.         Expires April 10, 2010                [Page 20]


Internet-Draft       LMA Redirect Support for PMIPv6        October 2009


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

   This document defines the following new Status value for use in PBA
   messages.  The value is to be allocated from the same number space,
   as defined in Section 6.1.8 of [RFC3775].  The allocated value MUST
   be greater than 128 indicating that the PBU was rejected by the LMA:

       NOT_LMA_FOR_THIS_MAG                  is set to TBD3




































Korhonen, et al.         Expires April 10, 2010                [Page 21]


Internet-Draft       LMA Redirect Support for PMIPv6        October 2009


10.  Acknowledgements

   The author would like to thank Basavaraj Patil and Domagoj Premec for
   their reviews and comments on the initial versions of this document.
   The authors also thank Yungui Wang and Qin Wu for their comments and
   discussion on this document.













































Korhonen, et al.         Expires April 10, 2010                [Page 22]


Internet-Draft       LMA Redirect Support for PMIPv6        October 2009


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.

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

   [RFC4306]  Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
              RFC 4306, December 2005.

   [RFC5142]  Haley, B., Devarapalli, V., Deng, H., and J. Kempf,
              "Mobility Header Home Agent Switch Message", RFC 5142,
              January 2008.

















Korhonen, et al.         Expires April 10, 2010                [Page 23]


Internet-Draft       LMA Redirect Support for PMIPv6        October 2009


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


   Xiangsong Cui
   Huawei

   Email: Xiangsong.Cui@huawei.com


















Korhonen, et al.         Expires April 10, 2010                [Page 24]