Internet DRAFT - draft-zhou-netext-lmac-dynamiclma
draft-zhou-netext-lmac-dynamiclma
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]
