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]