NETEXT WG R. Wakikawa
Internet-Draft Softbank Mobile
Intended status: Standards Track R. Pazhyannur
Expires: August 18, 2014 S. Gundavelli
Cisco
C. Perkins
Futurewei Inc.
February 14, 2014
Separation of Control and User Plane for Proxy Mobile IPv6
draft-ietf-netext-pmip-cp-up-separation-02.txt
Abstract
This document describes splitting of Control Plane (CP) and User
Plane (UP) for a Proxy Mobile IPv6 based network infrastructure.
Existing specifications allow a MAG to perform splitting of its
control and user plane using Alternate Care of address mobility
option for IPv6, or Alternate IPv4 Care of Address option for IPv4.
However, the current specification does not have semantics for
allowing the LMA to perform such functional split. To realize this
requirement, this specification defines a mobility option that
enables a local mobility anchor to provide an alternate LMA address
to be used for the bi-directional tunnel between the MAG and LMA.
With this extension, a local mobility anchor will be able to use an
IP address for its user plane which is different than the IP address
used for the control plane.
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 August 18, 2014.
Copyright Notice
Wakikawa, et al. Expires August 18, 2014 [Page 1]
Internet-Draft PMIPv6 CP-UP Split February 2014
Copyright (c) 2014 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
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4
2.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
3. LMA User Plane Address Mobility Option . . . . . . . . . . . . 5
4. Protocol Considerations . . . . . . . . . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
6. Protocol Configuration Variables . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
9.1. Normative References . . . . . . . . . . . . . . . . . . . 9
9.2. Informative References . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
Wakikawa, et al. Expires August 18, 2014 [Page 2]
Internet-Draft PMIPv6 CP-UP Split February 2014
1. Introduction
Widely deployed mobility management systems for wireless
communications require isolation between the path for forwarding data
packets (the user plane) and the control plane signaling for mobility
management. To meet this requirement, Proxy Mobile IPv6 requires
that the control plane functions of the local mobility anchor (LMA)
to be addressable at a different IP address than the IP address
assigned for the user plane. However, the current specification does
not have semantics for allowing the LMA to perform such functional
split. The LMA is required to associate the IP address of the tunnel
source with the target IP address of the control messages received
from the MAG.
A PMIPv6 infrastructure comprises two primary entities: LMA and MAG
(Mobility Access Gateway). The interface between MAG and LMA
consists of the control plane and user plane. The control plane is
responsible for signaling messages between MAG and LMA such as the
Proxy Binding Update and Proxy Binding Acknowledge messages to
establish a mobility binding. In addition, the control plane
components in the MAG and LMA are also responsible for setting up and
tearing down of the bi-directional tunnel between the MAG and LMA.
The user plane is responsible for forwarding the mobile node's IP
packets between the MAG and the LMA over the bi-directional tunnel.
The control plane and user plane components (of the MAG and LMA) are
typically co-located in the same physical entity. However, there are
deployments where it is desirable to have the control and user plane
of the MAG and LMA in separate physical entities. For example, in a
WLAN (Wireless LAN) deployment, it may be desirable to have the
control plane component of the MAG to be on Access Controller (also
sometimes referred to as Wireless LAN Controller) while the user
plane component of the MAG resides on the WLAN Access Point. This
would enable all the signaling messages to the LMA to be centralized
while the user plane would be distributed across the multiple Access
Points. Similarly the control plane and user plane component of the
LMA may be split according to different scaling requirements, or the
need to centralize the control plane in one geo-location while
distributing the user plane component across multiple geo-locations.
[RFC6463] and [RFC6275] enable splitting the control and user plane
in the MAG. Specifically, [RFC6463] defines the Alternate IPv4 Proxy
Care of Address Option while [RFC6275] defines an Alternate Care of
Address for IPv6 address. The MAG can provide an Alternate Care of
Address in the Proxy Binding Update (PBU) and if the LMA supports
this option then a bidirectional tunnel is setup between the LMA
address and the MAG's alternate Care of address. However, there is
no corresponding option for the LMA to provide an alternate address
Wakikawa, et al. Expires August 18, 2014 [Page 3]
Internet-Draft PMIPv6 CP-UP Split February 2014
to the MAG.
CP: Control Plane
UP: User Plane
+------------+ +------------+
| MAG | | LMA |
| +--------+ | | +--------+ |
+------+ | | MAG-CP |-|-------------|-| LMA-CP | | _----_
| MN | | | | | PMIPv6 | | | | _( )_
| |-----| +--------+ | | +--------+ |===( Internet )
+------+ | : | | : | (_ _)
| +--------+ | | +--------+ | '----'
| | MAG-UP |-|-------------|-| LMA-UP | |
| | | |GRE/IP-in-IP | | | |
| +--------+ | | +--------+ |
+------------+ +------------+
Figure 1: Functional Split of the Control and User Plane
This specification therefore defines a new mobility option that
enables a local mobility anchor to provide an alternate LMA address
to be used for the bi-directional tunnel between the MAG and LMA.
2. Conventions and Terminology
2.1. Conventions
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].
2.2. Terminology
3GPP terms can be found in [RFC6459]. Other mobility related terms
used in this document are to be interpreted as defined in [RFC5213]
and [RFC5844]. Additionally, this document uses the following terms:
IP-in-IP
IP-within-IP encapsulation [RFC2473]
GRE
Wakikawa, et al. Expires August 18, 2014 [Page 4]
Internet-Draft PMIPv6 CP-UP Split February 2014
Generic Record Encapsulation [RFC1701]
LMA Control Plane Address (LMA-CP)
The IP address on the LMA that is provided to the MAG for
establishing control plane connections.
LMA User Plane Address (LMA-UP)
The IP address on the LMA that is used for establishing user plane
tunnels with the mobile access gateway.
MAG Control Plane Address (MAG-CP)
The IP address on the MAG that is provided to the LMA for
establishing control plane connections.
MAG User Plane Address (MAG-UP)
The IP address on the MAG that is supports user plane tunnels with
the LMA.
3. LMA User Plane Address Mobility Option
A new mobility header option, LMA User Plane Address mobility option
is defined for use with Proxy Binding Update and Proxy Binding
Acknowledgement messages exchanged between the LMA and the MAG. This
option is used for notifying the LMA's user plane IPv6 or IPv4
address. There can be multiple instances of the LMA User Plane
Address mobility option present in the message, one for IPv4 and the
other for IPv6 transport.
The LMA User Plane Address mobility option has an alignment
requirement of 8n+2. Its format is as follows:
Wakikawa, et al. Expires August 18, 2014 [Page 5]
Internet-Draft PMIPv6 CP-UP Split February 2014
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
. .
+ LMA User Plane Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
To be assigned by IANA.
Length
8-bit unsigned integer indicating the length of the option in
octets, excluding the type and length fields.
Reserved
This field is unused in this specification. The value MUST be set
to 0 by the sender and MUST be ignored by the receiver.
LMA User Plane Address
Contains the 32-bit IPv4 address, or the 128-bit IPv6 of the LMA.
When this option is included in a Proxy Binding Update message as
a capability hint, this field can be a zero length field, or it
can be a ALL_ZERO value with all bits in the 32-bit IPv4 address,
or the 128-bit IPv6 address set to a value of zero.
4. Protocol Considerations
o If the protocol configuration variable, Domain-wide-LMA-UPA-
Support, is set to a value of (0), the MAG is required to
explicitly indicate to LMA on its support-capability for this
Wakikawa, et al. Expires August 18, 2014 [Page 6]
Internet-Draft PMIPv6 CP-UP Split February 2014
feature. Not including this option in the Proxy Binding Update
will result in LMA disabling this feature for this MAG.
o If the protocol configuration variable, Domain-wide-LMA-UPA-
Support, is set to a value of (1), the MAG is not required to
explicitly indicate to LMA on its support-capability for this
feature. The MAG may choose not to include the LMA User Plane
Address mobility option in the Proxy Binding Update.
o The MAG when including the LMA User Plane Address mobility option
in the Proxy Binding Update has to the apply the following
considerations:
* When using IPv4 transport for the user-plane, the IP address
field in the option can be either a zero-length field, or it
can be 4-octet field with ALL_ZERO value.
* When using IPv6 transport for the user-plane, the IP address
field in the option can be either a zero-length field, or it
can be 16-octet field with ALL_ZERO value.
o When the LMA is configured to provide an alternate IP address to
be used for the bi-directional tunnel between the MAG and LMA, it
must apply the following considerations.
* If the protocol configuration variable, Domain-wide-LMA-UPA-
Support, is set to a value of (0) and if the received Proxy
Binding Update did not include the LMA User Plane Address
mobility option, then the LMA MUST disable this feature for
that MAG. The LMA MUST NOT include the LMA User Plane Address
mobility Option in the Proxy Binding Acknowledgement.
* If the protocol configuration variable, Domain-wide-LMA-UPA-
Support, is set to a value of (1), or if the LMA User Plane
Address mobility option is present in the received Proxy
Binding Update, then the LMA should include the LMA User Plane
Address mobility Option in the Proxy Binding Acknowledgement.
The IP address field in the option must be set to the IPv4 or
IPv6 address used for the user-plane.
+ When using IPv4 transport for the user-plane, the IP address
field in the option must be the IPv4 address used for the
user-plane.
+ When using IPv6 transport for the user-plane, the IP address
field in the option must be the IPv6 address used for the
user-plane.
Wakikawa, et al. Expires August 18, 2014 [Page 7]
Internet-Draft PMIPv6 CP-UP Split February 2014
5. IANA Considerations
This document requires the following IANA actions.
o Action-1: This specification defines a new mobility header option,
LMA User Plane Address mobility option. The format of this option
is described in Section 3. The type value <IANA-1> for this
mobility option needs to be allocated from the Mobility Options
registry at <http://www.iana.org/assignments/mobility-parameters>.
RFC Editor: Please replace <IANA-1> in Section 3 with the assigned
value and update this section accordingly.
6. Protocol Configuration Variables
This specification defines the following configuration variable. The
mobility entities, LMA and MAG must allow this variable to be
configured by the system management. The configured values for this
protocol variable must survive server reboots and service restarts.
Domain-wide-LMA-UPA-Support
This variables indicates if all the mobility entities in the
Proxy Mobile IPv6 domain have support for the feature specified
in this document.
When this variable on the MAG is set to a value of (0), the MAG
must explicitly indicate its support-capability for this
feature by including the LMA User Plane Address mobility Option
in the Proxy Binding Acknowledgement. If the option is not
present in the Proxy Binding Update, the local mobility anchor
will not enable this feature for that mobility session.
When this variable on the MAG is set to a value of (1), it is
an indication that there is domain-wide support for this
feature and the MAG is not required to explicitly indicate its
support-capability for this feature by including the LMA User
Plane Address mobility Option in the Proxy Binding
Acknowledgement.
When this variable on the LMA is set to a value of (0), the LMA
MUST NOT include the LMA User Plane Address mobility Option in
the Proxy Binding Acknowledgement unless the MAG has explicitly
indicated its support-capability for this feature by including
the LMA User Plane Address mobility option in the Proxy Binding
Update.
Wakikawa, et al. Expires August 18, 2014 [Page 8]
Internet-Draft PMIPv6 CP-UP Split February 2014
When this variable on the LMA is set to a value of (1), it is
an indication that there is domain-wide support for this
feature and the LMA MAY choose to include this LMA User Plane
Address mobility Option in the Proxy Binding Acknowledgement
even if the option is not present in the Proxy Binding Update
message.
7. Security Considerations
The LMA User Plane Address mobility Option defined in this
specification is for use in Proxy Binding Acknowledgement message.
This option is carried like any other mobility header option as
specified in [RFC5213]. Therefore, it inherits security guidelines
from [RFC5213].
The LMA-UP provided as data within the LMA User Plane Address
mobility Option MUST be a valid address under the administrative
control associated with the LMA functional block.
If the LMA-UP and the LMA-CP functions are hosted in different
entities, any signaling between these two entities MUST be protected
by IPsec security association.
8. Acknowledgements
The authors of this document thank the NetExt Working Group for the
valuable feedback to different versions of this specification. In
particular the authors want to thank John Kaippallimalil, Sridhar
Bhaskaran, Nirav Salot and Bruno landais for their valuable comments
and suggestions to improve this specification.
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.
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
[RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy
Mobile IPv6", RFC 5844, May 2010.
Wakikawa, et al. Expires August 18, 2014 [Page 9]
Internet-Draft PMIPv6 CP-UP Split February 2014
9.2. Informative References
[RFC1701] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic
Routing Encapsulation (GRE)", RFC 1701, October 1994.
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in
IPv6 Specification", RFC 2473, December 1998.
[RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support
in IPv6", RFC 6275, July 2011.
[RFC6459] Korhonen, J., Soininen, J., Patil, B., Savolainen, T.,
Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation
Partnership Project (3GPP) Evolved Packet System (EPS)",
RFC 6459, January 2012.
[RFC6463] Korhonen, J., Gundavelli, S., Yokota, H., and X. Cui,
"Runtime Local Mobility Anchor (LMA) Assignment Support
for Proxy Mobile IPv6", RFC 6463, February 2012.
Authors' Addresses
Ryuji Wakikawa
Softbank Mobile
1-9-1,Higashi-Shimbashi,Minato-Ku
Tokyo 105-7322
Japan
Email: ryuji.wakikawa@gmail.com
Rajesh S. Pazhyannur
Cisco
170 West Tasman Drive
San Jose, CA 95134,
USA
Email: rpazhyan@cisco.com
Wakikawa, et al. Expires August 18, 2014 [Page 10]
Internet-Draft PMIPv6 CP-UP Split February 2014
Sri Gundavelli
Cisco
170 West Tasman Drive
San Jose, CA 95134
USA
Email: sgundave@cisco.com
Charles E. Perkins
Futurewei Inc.
2330 Central Expressway
Santa Clara, CA 95050,
USA
Email: charliep@computer.org
Wakikawa, et al. Expires August 18, 2014 [Page 11]