[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

NETEXT Working Group                                             Q. Zhou
Internet-Draft                                                    Huawei
Intended status: Informational                                 S. Peters
Expires: July 2014                                             TU Berlin
                                                             F.Sivrikaya
                                                               TU Berlin
                                                                R. Sofia
                                                                COPELABS
                                                            January 2014


           LMA Coordination in a Dynamic LMA Environment
              draft-zhou-netext-lmac-dynamiclma-00.txt

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), 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 July 31, 2014.

Copyright Notice

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

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


Zhou, et al.            Expires July 31, 2014                   [Page 1]


Internet-Draft             LMA Coordination                 January 2014


   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.

Abstract

   This document describes local mobility anchor coordination
   functionality and corresponding mobility options for Proxy Mobile
   IPv6.  The mobility anchor coordination targets LMAs with a dynamic
   service provisioning behavior, and is achieved by Proxy Binding
   Update and a Proxy Binding Acknowledgement message exchange between a
   Local Mobility Anchor (LMA) and a Local Mobility Anchor Coordinator
   (LMAc).

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Conventions used in this document . . . . . . . . . . . . . .   3
   3.  Overview of LMA Coordination  . . . . . . . . . . . . . . . .   3
     3.1.  Operational Scenarios . . . . . . . . . . . . . . . . . .   5
   4.  Message Format  . . . . . . . . . . . . . . . . . . . . . . .   7
     4.1.  LMA Update mobility option  . . . . . . . . . . . . . . .   7
     4.2.  Existing mobility options reused. . . . . . . . . . . . .   9
   5.  General Operation . . . . . . . . . . . . . . . . . . . . . .   9
     5.1.  Overall Operation . . . . . . . . . . . . . . . . . . . .   9
     5.2.  LMA Operation   . . . . . . . . . . . . . . . . . . . . .  11
     5.3.  LMAc Operation  . . . . . . . . . . . . . . . . . . . . .  11
     5.4.  MAG Operation   . . . . . . . . . . . . . . . . . . . . .  11
   6.  Protocol Configuration Variables  . . . . . . . . . . . . . .  11
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
   9.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  12
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
     10.1. Normative References  . . . . . . . . . . . . . . . . . .  12
     10.2. Informative References  . . . . . . . . . . . . . . . . .  13
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  14

1.  Introduction

   A single-LMA environment may cause a single point of failure and
   bottleneck for mobility support. Thus, Proxy Mobile IPv6 (PMIPv6)
   specification supports the use of multiple LMAs in a PMIPv6 domain,
   but assumes that each LMA serves a preconfigured group of mobile
   nodes [RFC5213]. Dynamic LMA assignment is discussed in several


Zhou, et al.            Expires July 31, 2014                   [Page 2]


Internet-Draft             LMA Coordination                 January 2014


   documents; e.g. in [RFC 6463], runtime LMA assignment is proposed for
   the purpose of load sharing in a multi-LMA environment.

   In a network with flat architecture, e.g. a user-centric network
   [UCN], the MAG and LMA functions are implemented in the network
   elements that are potentially provided by the end users, and thus the
   offered services are made available according to users' preferences
   and in a dynamic fashion. As a consequence the number of available
   LMAs is not known at the time of deployment, which is implicitly
   assumed in [RFC 6463].

   In this proposal the LMAs that are currently offering their anchoring
   service to MNs, and which are thus available for dynamic selection,
   are coordinated in the PMIPv6 domain by a broker-like entity.

   This document specifies the required protocol extensions to PMIPv6 to
   exchange the LMA information, coordinate the LMA selection, and
   enable the dynamic provision of LMAs to the MAG, facilitated in a
   dynamic, multi-LMA environment.

2.  Conventions used in this document

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

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

   Local Mobility Anchor Coordinator (LMAc): An LMA which receives PBU
   messages includes the LMA availability and IP address of the LMA,
   selects the LMA for the MN, and sends the LMA information to the MAG.

3.  Overview of LMA Coordination

   As described in section 5.7 of [RFC5213], the PMIPv6 standard assumes
   the LMA to be assigned to a mobile node via a statically configured
   profile; other mechanisms are outside the scope of the standard.

   In [RFC 6463], runtime LMA assignment is proposed for the purpose of
   load sharing in multi-LMA environment, however, how the runtime LMA
   assignment functionality (rfLMA) obtains the information on the
   available target LMAs (r2LMAs) is not specified.


Zhou, et al.            Expires July 31, 2014                   [Page 3]


Internet-Draft             LMA Coordination                 January 2014


   This draft builds on [RFC6463], and we describe the dynamic
   assignment of LMAs to mobile nodes by a newly introduced entity
   referred to as Local Mobility Anchor Coordinator (LMAc).

   The LMAc is responsible for the coordination of available LMAs by
   receiving registration messages from LMAs, selecting an LMA for a
   specific MN, and sending the selected LMA to the MAG. The MAG finally
   triggers the standard PMIPv6 procedure. The LMAc is located in the
   PMIPv6 domain and communicates with MAG and LMA via PMIPv6.

   Given the mobility coordination performed by LMAc the availability
   and resource utilization information about LMAs is known to the
   network. Consequently, the LMA can be selected dynamically for the
   MNs when the MN attaches to the network, or in case the current LMA
   goes out of service.

   An example of such an LMA coordination scenario is shown in Figure 1,
   where a mobile node (MN) has attached to the MAG. Two LMAs (LMA1 and
   LMA2) provide the LMA functionality. In addition, the Local Mobility
   Anchor Coordination (LMAc) entity is also part of the PMIPv6 domain
   to coordinate the LMA selection.

             +-------------------------------+
            (    +-------+     +-------+      )
            (    |  LMA1 |     |  LMA2 |      )
            (    +-------+     +-------+      )
            (       || \          / ||        )
            (       ||  \        /  ||        )
            (       ||   \      /   ||        )
            (       ||   +-------+  || PMIPv6 )
            (       ||   | LMAc  |  || domain )
            (       ||   +-------+  ||        )
            (       ||       |      ||        )
            (       ||       |      ||        )
            (     +--------------------+      )
            (     |         MAG        |      )
            (     +--------------------+      )
             +---------------|----------------+
                             |
                          +------+
                          |  MN  |
                          +------+
                 Figure 1 Overview of LMAc

   LMA coordination also applies to a mobile network architecture that
   complies with the 3GPP Evolved Packet Core (EPC) specifications,


Zhou, et al.            Expires July 31, 2014                   [Page 4]


Internet-Draft             LMA Coordination                 January 2014


   where the P-GW plays the role of LMA. The Mobility Management Entity
   (MME) in 3GPP shall select the P-GW for the UE. MME is required to be
   aware the context of P-GWs, e.g. available resource in the P-GW, to
   select a better P-GW for the UE.

3.1. Operational Scenarios

   LMA coordination fits well in a user-centric network, where the MAG
   and LMA functions are implemented in user provided devices, which
   implies that the offered services are made available according to
   user's preferences and in a dynamic fashion. The LMAs that are
   currently offering their service to MNs, and that are available for
   dynamic selection are required to be known by the LMAc by means of a
   registration procedure. Subsequently the LMAc is able to select the
   most suitable anchor node out of the registered LMAs. The specific
   LMA selection algorithms performed by the LMAc are out of scope of
   this specification.

   There are two operational scenarios on LMA coordination considered in
   this draft: LMA selection on MN attachment, and LMA re-selection.

3.1.1. LMA Selection on MN Attachment

   Figure 2 details the procedure of LMA selection that is triggered
   when a MN attaches to a MAG that is part of the PMIPv6 domain managed
   by the LMAc. First, the LMA informs the LMAc of its availability and
   includes relevant contextual information, such as currently available
   resources for performing the anchoring service.

   The LMAc receives the LMA Register message from LMAs and maintains a
   list of the currently available LMAs. Upon MN attachment the MAG
   sends an LMA Request to LMAc and thereby requests the LMA for the MN.
   The LMAc performs the decision, selects the most suitable LMA for the
   MN, and sends it to the MAG in LMA Response message.




Zhou, et al.            Expires July 31, 2014                   [Page 5]


Internet-Draft             LMA Coordination                 January 2014



      +-----+       +-----+       +-----+       +------+       +------+
      |  MN |       | MAG |       | LMAc|       | LMA1 |       | LMA2 |
      +-----+       +-----+       +-----+       +------+       +------+
         |             |             |              |              |
         |             |             | LMA Register |              |
         |             |             |<-------------|              |
         |             |             |        LMA Register         |
         |             |             |<----------------------------|
         |MN Attachment|             |              |              |
         |------------>| LMA Request |              |              |
         |             |------------>|              |              |
         |             |             |              |              |
         |             | ========================== |              |
         |             | ||   LMA selection      || |              |
         |             | ========================== |              |
         |             |             |              |              |
         |             | LMA Response|              |              |
         |             |<------------|              |              |
         |             |             |              |              |
         |             |      Binding Request       |              |
         |             |--------------------------->|              |
         |             |     Binding Response       |              |
         |             |<---------------------------|              |
         |             |             |              |              |
         |             |<======PMIP tunnel ========>|              |
         |             |             |              |              |

                   Figure 2 LMA Selection on MN Attachment

3.1.2. LMA Re-Selection

   Figure 3 details the procedure of LMA re-selection when the current
   LMA stops offering its service: When MAG detects out-of-service
   status of current LMA, it sends LMA Request to LMAc, and requests the
   LMA for the MN, LMAc performs the decision and selects the LMA for
   the MN, and sends it to the MAG in LMA Response message.







Zhou, et al.            Expires July 31, 2014                   [Page 6]


Internet-Draft             LMA Coordination                 January 2014



      +-----+       +-----+       +-----+       +------+       +------+
      |  MN |       | MAG |       | LMAc|       | LMA1 |       | LMA2 |
      +-----+       +-----+       +-----+       +------+       +------+
         |             |             |              |              |
         |             |<========PMIP tunnel=======>|              |
         |             |             |              |              |
         |             |             |       LMA1 disappears       |
         |             |         Keep Alive         |              |
         |             |--------------------------->|              |
         |          TimeOut          |              |              |
         |             |             |              |              |
         |             | LMA Request |              |              |
         |             |------------>|              |              |
         |             |             |              |              |
         |             | ========================== |              |
         |             | ||   LMA selection      || |              |
         |             | ========================== |              |
         |             |             |              |              |
         |             | LMA Response|              |              |
         |             |<------------|              |              |
         |             |             |              |              |
         |             |              Binding Request              |
         |             |------------------------------------------>|
         |             |              Binding Response             |
         |             |<------------------------------------------|
         |             |             |              |              |
         |             |<===============PMIP tunnel ==============>|
         |             |             |              |              |

                          Figure 3 LMA Re-Selection

4. Message Format

   The messages exchanged between MAG and LMAc are the same as defined
   in Runtime LMA Assignment Support for Proxy Mobile IPv6 protocol
   message [RFC6463]. The MAG considers LMAc as the default LMA and
   sends a Proxy Binding Update to the LMAc, then retrieves a redirect-
   to LMA in Proxy Binding Acknowledgement if a better LMA is selected
   by LMAc.

   This section defines extensions to Proxy Mobile IPv6 [RFC5213] and to
   the Runtime LMA Assignment Support for Proxy Mobile IPv6 protocol
   message [RFC6463].

4.1. LMA Update mobility option








Zhou, et al.            Expires July 31, 2014                   [Page 7]


Internet-Draft             LMA Coordination                 January 2014


   A new mobility header option, LMA Update mobility option is defined
   for use with Proxy Binding Update from LMA to LMAc.  This option is
   used to register or deregister an LMA to the LMAc.

    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|R|     Reserved            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                  Optional IPv6 LMA Address                    |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Optional IPv4 LMA Address                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                 Figure 4 LMA Update Mobility Option


   o  Option Type: To be defined by IANA.

   o  Option Length: 8-bit unsigned integer, representing the length
      of the LMA Update mobility option in octets, excluding the
      Option Type and Length fields. If the 'K' flag is set and 'N'
      is unset, then the length MUST be 18.  If the 'K' flag is
      unset and 'N' is set, then the length MUST be 6.  Both the 'K'
      and 'N' flags cannot be set or unset simultaneously.

   o  'K' flag: This bit is set (1) if the 'Optional IPv6 LMA
      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 LMA
      Address' is included in the mobility option.  Otherwise, the
      bit is unset (0).

   o  'R' flag: This bit is set (1) when LMA registers to the LMAc,
      and is unset (0) when LMA deregisters to the LMAc.


Zhou, et al.            Expires July 31, 2014                   [Page 8]


Internet-Draft             LMA Coordination                 January 2014


   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 LMA Address: the unicast IPv6 address of the LMA.
      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]).

4.2. Existing mobility options reused.

   The existing mobility header option, Load Information Mobility Option
   (see [RFC6463]) can also be used for LMA Register in the Proxy
   Binding Update from LMA to LMAc, to report priority and key load
   information of a LMA to LMAc.

5. General Operation

5.1. Overall Operation

5.1.1. LMA Selection on MN Attachment

   The overall operation procedure of LMA selection on MN attachment is
   shown in Figure 5: There are three pairs of PBU/PBA messages. The
   first pair of PBU/PBA is between LMA and LMAc, to register LMA to the
   LMAc; the second pair of PBU/PBA is between MAG and LMAc, to select
   the LMA; and the third pair of PBU/PBA is between MAG and selected
   LMA, to setup the data tunnel for the MN.



Zhou, et al.            Expires July 31, 2014                   [Page 9]


Internet-Draft             LMA Coordination                 January 2014



      +-----+      +-----+       +-----+        +------+
      |  MN |      | MAG |       | LMAc|        |  LMA |
      +-----+      +-----+       +-----+        +------+
         |             |             |     PBU      |
  1)     |             |             |<-------------| LMA Registration
         |             |             |     PBA      |
  2)     |             |             |------------->| PBA to LMA
         |MN Attachment|             |              |
         |------------>|     PBU     |              |
  3)     |             |------------>|              | LMA Request
         |             |     PBA     |              |
  4)     |             |<------------|              | Selected LMA
         |             |             |              | contained
         |             |            PBU             |
  5)     |             |--------------------------->| PBU to LMA
         |             |            PBA             |
  6)     |             |<---------------------------| PBA and setup
         |             |             |              | data tunnel
         |             |<===========data===========>|
         |             |             |              |
                 Figure 5 LMA Selection Overall Procedure

5.1.2. LMA Re-Selection

      +-----+      +-----+       +-----+       +------+      +-----+
      |  MN |      | MAG |       | LMAc|       | LMA1 |      |LMA2 |
      +-----+      +-----+       +-----+       +------+      +-----+
         |            |             |              |            |
         |            |<===========data===========>|            |
         |            |             |              |            |
  1)     |            |             |       LMA1 disappears     |
         |            |            PBU             |            |
  2)     |            |--------------------------->|            |
         |            |             |              |            |
  3)     |         TimeOut          |              |            |
         |            |     PBU     |              |            |
  4)     |            |------------>|              |            |
         |            |     PBA     |              |            |
  5)     |            |<------------|              |            |
         |            |             |              |            |
         |            |             |     PBU      |            |
  6)     |            |---------------------------------------->|
         |            |             |     PBA      |            |
  7)     |            |<----------------------------------------|
         |            |             |              |            |
         |            |<==================data=================>|
         |            |             |              |            |

                    Figure 6 LMA Re-Selection Overall Procedure


Zhou, et al.            Expires July 31, 2014                  [Page 10]


Internet-Draft             LMA Coordination                 January 2014


   The overall operation procedure of LMA re-selection is shown in
   Figure 6: When LMA1 goes out-of-service, the MAG enters timeout after
   sending PBU to LMA1 and waiting for the PBA from LMA1; the MAG
   requests LMA from LMAc by sending PBU to LMAc, and gets the selected
   LMA in PBA from LMAc; the data tunnel for the MN is setup after the
   PBU/PBA message exchange between MAG and LMA2.

5.2. LMA Operation

   The LMA shall report its availability, IP address, priority and key
   load information to LMAc periodically.

5.3. LMAc Operation

   The LMAc shall receive the availability, IP address, priority and key
   load information from LMAs and maintain them in its database.

   The LMAc shall check the availability of the LMA by a timer to
   receive LMA Update from the LMA. If the timer expires prior to
   receiving an update message, the LMA is considered unavailable and it
   shall be removed from the database.

   The LMAc shall make the decision to select the available LMA for the
   MN based on priority and load information.

   The LMAc shall support LMA function in the Runtime LMA Assignment
   Support for Proxy Mobile IPv6 protocol message [RFC6463], to send the
   selected LMA to the MAG.

5.4. MAG Operation

   The MAG shall detect the LMA out-of-service when sending a PBU to
   LMA1 and a timeout occurs while waiting for the PBA from LMA1.

   The MAG shall support MAG function in the Runtime LMA Assignment
   Support for Proxy Mobile IPv6 protocol message [RFC6463], to receive
   the selected LMA from LMAc.

6. Protocol Configuration Variables

   The local mobility anchor MUST allow the following variables to be
   configured by the system management.  The configured values for these
   protocol variables MUST survive server reboots and service restarts.

   LMAUpdateReportTimer


Zhou, et al.            Expires July 31, 2014                  [Page 11]


Internet-Draft             LMA Coordination                 January 2014


       This variable specifies the time in seconds the local mobility
       anchor MUST report its availability to LMAc.

       The default value for this variable is 30 seconds.

   LMACoordinatorTimeout

       This variable specifies the time in seconds for the timer in LMAc
       to check the availability of the LMA, which is cleared to 0 when
       LMA Update is received from the LMA. If the timer reaches the
       timeout value, the LMA is considered unavailable, and it shall be
       removed from the database.

       The default value for this variable is 60 seconds.

7. Security Considerations

   The security considerations of PMIPv6 signaling described in RFC 5213
   and RFC 6463 apply to this document. This document assumes that the
   LMAs, LMAc and MAG that participate in LMA coordination have adequate
   prior agreement and trust relationships between each other.

8. IANA Considerations

   New mobility options for use with PMIPv6 are defined in the [RFC6275]
   "Mobility Options" registry.  The mobility options are defined in
   Section 4.

9. Acknowledgments

   The authors would like to thank all participants in EU FP7 User
   Centric Local Loop (ULOOP) project, www.uloop.eu.

10. References

10.1. Normative References

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

[RFC6463]   J. Korhonen, S. Gundavelli, H. YoKota, and X. Cui,
            "Runtime Local Mobility Anchor (LMA) Assignment Support
            for Proxy Mobile IPv6", RFC 6463, February 2012.

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


Zhou, et al.            Expires July 31, 2014                  [Page 12]


Internet-Draft             LMA Coordination                 January 2014


10.2. Informative References

[UCN]       P. Mendes, W. Moreira, C. Pereira, T. Jamal, A. Bogliolo,
            H. Haci, and H. Zhu, "Cooperative Networking in User-
            Centric Wireless Networks", ULOOP Project White Paper 05,
            September 2012.





























Zhou, et al.            Expires July 31, 2014                  [Page 13]


Internet-Draft             LMA Coordination                 January 2014


Authors' Addresses

   Qing Zhou
   Huawei Technologies Dusseldorf GmbH
   Carnotstr 4, Berlin, 10587
   Germany

   Email: zhouqing@huawei.com


   Sebastian Peters
   DAI Labor, Technische Universit?t Berlin
   Ernst-Reuter-Platz 7, Berlin, 10587
   Germany

   Email: Sebastian.Peters@dai-labor.de


   Fikret Sivrikaya
   DAI Labor, Technische Universit?t Berlin
   Ernst-Reuter-Platz 7, Berlin, 10587
   Germany

   Email: fikret.sivrikaya@dai-labor.de


   Rute Sofia
   COPELABS, University Lusofona Campus
   Building U, First Floor
   Campo Grande 388, Lisboa, 1749-024 Lisboa
   Portugal

   Email: rute.sofia@ulusofona.pt













Zhou, et al.            Expires July 31, 2014                  [Page 14]


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