Internet DRAFT - draft-sarikaya-dmm-cloud-mm
draft-sarikaya-dmm-cloud-mm
Network Working Group B. Sarikaya
Internet-Draft Huawei USA
Intended status: Standards Track October 15, 2012
Expires: April 18, 2013
Mobility Management Protocols for Cloud-Like Architectures
draft-sarikaya-dmm-cloud-mm-00.txt
Abstract
Telecommunication networks are being virtualized and are moving into
the cloud networks. This brings the need to redesign the mobility
protocols of Mobile and Proxy Mobile IPv6. This document defines
mobility management protocols for virtualized networks. Control and
data plane separation is achieved by separating Home Agent and Mobile
Access Gateway functionalities into the control and data planes.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 18, 2013.
Copyright Notice
Copyright (c) 2012 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 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
Sarikaya Expires April 18, 2013 [Page 1]
Internet-Draft VMs for Mobility Management October 2012
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Control and Data Plane Separation for MIPv6 . . . . . . . . . 5
4. Authentication in Control and Data Plane Separation . . . . . 6
5. Control and Data Plane Separation for PMIPv6 . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
9.1. Normative References . . . . . . . . . . . . . . . . . . . 9
9.2. Informative references . . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11
Sarikaya Expires April 18, 2013 [Page 2]
Internet-Draft VMs for Mobility Management October 2012
1. Introduction
Mobile IPv6 defines client based mobility support to the mobile nodes
and is defined in [RFC6275]. There are several extensions to Mobile
IPv6 such as multiple Care-of Address registration for multi-homed
mobile nodes [RFC5648], flow mobility [RFC6089] and Dual Stack Mobile
IPv6 [RFC5555]. Mobile IPv6 is based on a centralized mobility
anchoring architecture at the home agent (HA).
Proxy Mobile IPv6 defines network based mobility support to the
mobile nodes and is defined in [RFC5213]. PMIPv6 operation involves
a a Mobile Access Gateway handling mobility of the mobile node and
registering the mobile node with the Local Mobility Anchor (LMA)
which receives and sends MN traffic into the Internet. LMA operation
is compatible with the home agent of MIPv6. IPv4 support for PMIPv6
is defined in [RFC5844] and flow mobility extensions in
[I-D.ietf-netext-pmipv6-flowmob].
Centralized mobility anchoring has several drawbacks such as single
point of failure, routing in a non optimal route, overloading of the
centralized data anchor point due to the data traffic increase, low
scalability of the centralized route and context management
[I-D.ietf-dmm-requirements].
Architecture of a cloud network is shown in Figure 1, see also
[I-D.rekhter-nvo3-vm-mobility-issues]. Top of Rack Switch (ToR) is a
switch in a cloud network that is connected to the servers. The
servers host virtual machines. A cloud network has one or more Data
Center Border Routers (BR) or edge routers that connects the cloud
network to the Internet including other cloud network or storage
networks. Storage network is usually part of the same cloud network
and it is connected to the BR using Fiber Channel (fc) links.
Control and data plane separation is stated as a requirement for the
distributed mobility management. Mobile IPv6 control plane is used
for registration and handover signaling and for establishing security
association, e.g. IPSec SAs. Data plane is used for data transfer
from the corresponding nodes (CN) to MN and from MN to CNs.
Typically control plane traffic is much ligther than the data plane
traffic and control plane traffic has stronger latency requirements.
Control plane data plane separation requires signaling between the
control and data plane functional entities.
Sarikaya Expires April 18, 2013 [Page 3]
Internet-Draft VMs for Mobility Management October 2012
I N T E R N E T
| |
_____________________________________________________________
| | | Data |
| ------ ------ fc Center |
| | BR | | BR |-----------------| |
| ------ ------ | |
| |_____________| _____|________ |
| ( Data Center ) | | |
| ( Network ) |Storage Center| |
| (___________) |_____________ | |
| | | |
---- ---- |
| | | |
| ------------ ----- |
| | ToR Switch | | ToR | |
| ------------ -----
| | | |
| | ---------- | ---------- |
| |--| Server | |--| Server | |
| | | | | ---------- |
| | | ---- | | |
| | | | VM | | | ---------- |
| | | ----- | --| Server | |
| | | | VM | | ---------- |
| | | ----- | |
| | | | VM | | |
| | | ---- | |
| | ---------- |
| |-- Other servers |
-------------------------------------------------------------
Figure 1: Architecture of Cloud
2. Terminology
This document uses the terminology defined in [RFC6275] and
[RFC5213].
Sarikaya Expires April 18, 2013 [Page 4]
Internet-Draft VMs for Mobility Management October 2012
3. Control and Data Plane Separation for MIPv6
| ------------+----------. |
| / Binding Cache and \ |
| | Security Associations | |
| \ / |
| ------------------------- |
| /
\ | /
+--------------+ / `-.
\ | VM | / +--------------+
| HA Data | / | HA Control |
\ |Plane Function| / |Plane Function|
+--------------+ / +--------------+
\ \\ \
----------------- \\ '
+-----+ +--\--+
| MN |---move----> | MN |
+-----+ +-----+
Figure 2: Architecture of MIPv6 Control and Data Planes
Control and data plane separation can be achieved by dividing HA into
two functional entities: control plane functional entity and data
plane functional entity as shown in Figure 2. These functional
entities can be hosted on different physical entities. These two
entities must share a common database. The database contains the
binding cache and the security association information such as IPSec
keys.
HA Data Plane function can be implemented as virtual machine (VM) in
a cloud network. Binding cache and security associations will be
stored in the storage center of the cloud entwork that VMs can easily
access. HA Control Plane function is geographically more distributed
than HA data Plane function and is placed closer to the mobile nodes
in order to meet the latency requirements.
MN first communicates with the control plane function to establish
security association. Address configuration and binding registration
follows. Next MN receives/sends data packets using the data plane
function closest to the link MN is attached.
When MN moves MN does handover signaling with the control plane
function which updates the binding cache based on this move. Control
plane function informs the new data plane function of this binding
cache update and then MN starts to receive and send data to the new
data plane function. MN MUST keep HA control plane function address
in cache so that it can conduct handover signaling with it.
Sarikaya Expires April 18, 2013 [Page 5]
Internet-Draft VMs for Mobility Management October 2012
When MN boots, it goes through authentication and security
association establishment. Next MN sends a binding update. MN does
these steps with HA control plane function. MN sends Binding Update
message to HA control plane function and receives a Binding
Acknowledgement message and in this message MN MUST receive HA data
plane function address.
HA data plane function address can be provided by HA control plane
function to MN in Alternate Home Agent Tunnel Address option defined
in [I-D.perkins-netext-hatunaddr] of BA message [RFC6275]. MN starts
tunneling data packets and sends them to Alternate Home Agent Tunnel
Address. Also MN receives data packets tunneled from Alternate Home
Agent Tunnel Address.
Control and data plane separation does not require protocol
extensions except the sharing of binding cache and security
associations database. How this sharing can be accomplished is left
out of scope with this specification.
4. Authentication in Control and Data Plane Separation
Currently, MN and HA create security associations (SA) based on the
home address using IKEv2 as the key exchange protocol. When MN moves
SAs are reestablished when MN gets a new care-of address. After SA
is established, MN and HA use Encapsulating Security Payload (ESP)
encapsulation for Binding Updates and Binding Acknowledgements
[RFC4877].
IKEv2 enables the use of EAP authentication and provides EAP
transport between MN as the peer and HA as the authenticator. EAP
authentication is done using one of the EAP methods such as EAP-AKA
[RFC4187].
MN is authorized as a valid user using EAP authentication. IKEv2
public key signature authentication with certificates is used to
authenticate the home agent and derive keys to be used in exchanging
BU/BA securely. MN can use the same identity, e.g. MN-NAI during
both EAP and IKEv2 authentication.
On the other hand MN goes through the access authentication when it
first connects to the network. A typical access authentication
protocol is AKA. MSK derived from this authentication serves as the
session key in accessing the air interface.
There is an overlap between the access and user authentications
sometimes done using the same protocol, e.g. AKA. Full EAP method
execution may take several round trips, some times five or more round
Sarikaya Expires April 18, 2013 [Page 6]
Internet-Draft VMs for Mobility Management October 2012
trips and slow down the user access to the Internet. This is
especially an important consideration in Distributed Mobility
Management since MN may connect to several home agents instead of
staying anchored at one home agent.
In order to reduce the number of round trips EAP authenticaton can be
combined with reauthentication. Reauthentication is EAP method
dependent. EAP-AKA reauthentication takes only one round trip
[RFC4187]. MN must go through an EAP-AKA reauthentication before
when MN was connected to the previous HA. During reauthentication
reauthentication ID is generated. MN MUST use its reauthentication
ID during IKEv2 EAP authentication with the new home agent. This
ensures that EAP-AKA authentication takes only one round trip. MN
continues to use its reauthentication ID in subsequent
reauthentication runs with the same HA.
5. Control and Data Plane Separation for PMIPv6
| ------------+----------. |
| / Binding Cache and \ |
| | Security Associations | |
| \ / |
| ------------------------- |
| /
\ | /
+--------------+ / `-.
\ | VM | / +--------------+ +--------------+
| LMA | / | MAG Control | | MAG Data |
\ | | / |Plane Function| |Plane Function|
+--------------+ / +--------------+ +--------------+
\ \\ \
----------------- \\ '
+-----+ +--\--+
| MN |---move----> | MN |
+-----+ +-----+
Figure 3: Architecture of PMIPv6 Control and Data Planes
Control and data plane separation can be achieved by dividing MAG
into two functional entities: MAG control plane functional entity and
MAG data plane functional entity as shown in Figure 3. LMA stays the
same. LMA can be implemented as virtual machine (VM) in a cloud
network. Binding cache and security associations will be stored in
the storage center of the cloud entwork that VMs can easily access.
MAG Control Plane function together with MAG Data Plane function is
geographically distributed and is placed closer to the mobile nodes
Sarikaya Expires April 18, 2013 [Page 7]
Internet-Draft VMs for Mobility Management October 2012
in order to meet the latency requirements.
MN first communicates with the MAG control plane function to
establish security association. Address configuration follows. Next
MN receives/sends data packets using the LMA closest to the link MN
is attached from MAG Data Plane function.
When MN moves MN does handover signaling with the control plane
function which MAG control plane function updates the binding cache
based on this move. MAG control plane function informs the MAG data
plane function of this binding cache update and then MN starts to
receive and send data to the new data plane function. MN MUST keep
MAG control plane function address which is the same in the domain
for all MNs in its cache.
When MN boots, it goes through authentication and security
association establishment. Next MAG control plane function sends a
proxy binding update to the LMA. MAG control plane function sends
Proxy Binding Update message to the LMA and receives a Proxy Binding
Acknowledgement message and in this message MAG control plane
function MUST receive (possibly new) LMA address.
LMA address can be provided to MAG control plane function in
Alternate Home Agent Tunnel Address option defined in
[I-D.perkins-netext-hatunaddr] of PBA message [RFC5213]. MAG control
plane function passes the LMA address to MAG data plane function.
When MAG data plane function receives data packets from MN, it
encapsulates the packets and sends them to Alternate Home Agent
Tunnel Address. Also when packets are received from Alternate Home
Agent Tunnel Address MAG data plane function decapsulates the packet
and then send it to the MN.
Alternate Home Agent Tunnel Address option in Proxy Mobile IPv6 is
much less useful because MAG data plane function could be
preconfigured with the LMA address value that happens to be
topologically closest LMA.
6. Security Considerations
TBD.
7. IANA Considerations
TBD.
Sarikaya Expires April 18, 2013 [Page 8]
Internet-Draft VMs for Mobility Management October 2012
8. Acknowledgements
TBD.
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
"Dynamic Updates in the Domain Name System (DNS UPDATE)",
RFC 2136, April 1997.
[RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support
in IPv6", RFC 6275, July 2011.
[RFC5026] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6
Bootstrapping in Split Scenario", RFC 5026, October 2007.
[RFC5555] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and
Routers", RFC 5555, June 2009.
[RFC5648] Wakikawa, R., Devarapalli, V., Tsirtsis, G., Ernst, T.,
and K. Nagami, "Multiple Care-of Addresses Registration",
RFC 5648, October 2009.
[RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy
Mobile IPv6", RFC 5844, May 2010.
[I-D.ietf-netext-pmipv6-flowmob]
Bernardos, C., "Proxy Mobile IPv6 Extensions to Support
Flow Mobility", draft-ietf-netext-pmipv6-flowmob-04 (work
in progress), July 2012.
[RFC6089] Tsirtsis, G., Soliman, H., Montavont, N., Giaretta, G.,
and K. Kuladinithi, "Flow Bindings in Mobile IPv6 and
Network Mobility (NEMO) Basic Support", RFC 6089,
January 2011.
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
[RFC4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with
IKEv2 and the Revised IPsec Architecture", RFC 4877,
April 2007.
Sarikaya Expires April 18, 2013 [Page 9]
Internet-Draft VMs for Mobility Management October 2012
[RFC4187] Arkko, J. and H. Haverinen, "Extensible Authentication
Protocol Method for 3rd Generation Authentication and Key
Agreement (EAP-AKA)", RFC 4187, January 2006.
9.2. Informative references
[I-D.ietf-dmm-requirements]
Chan, A., "Requirements for Distributed Mobility
Management", draft-ietf-dmm-requirements-02 (work in
progress), September 2012.
[I-D.rekhter-nvo3-vm-mobility-issues]
Rekhter, Y., Henderickx, W., Shekhar, R., Fang, L.,
Dunbar, L., and A. Sajassi, "Network-related VM Mobility
Issues", draft-rekhter-nvo3-vm-mobility-issues-03 (work in
progress), October 2012.
[I-D.perkins-netext-hatunaddr]
Perkins, C., "Alternate Tunnel Source Address for LMA and
Home Agent", draft-perkins-netext-hatunaddr-00 (work in
progress), May 2012.
Sarikaya Expires April 18, 2013 [Page 10]
Internet-Draft VMs for Mobility Management October 2012
Author's Address
Behcet Sarikaya
Huawei USA
5340 Legacy Dr. Building 175
Plano, TX 75074
Phone: +1 469 277 5839
Email: sarikaya@ieee.org
Sarikaya Expires April 18, 2013 [Page 11]
