Separation of Control and User Plane for Proxy Mobile IPv6
Softbank Mobile1-9-1, Higashi-Shimbashi, Minato-KuTokyo105-7322Japanryuji.wakikawa@gmail.comCisco170 West Tasman DriveSan JoseCA95134United Statesrpazhyan@cisco.comCisco170 West Tasman DriveSan JoseCA95134United Statessgundave@cisco.comFuturewei Inc.2330 Central ExpresswaySanta ClaraCA95050United Statescharliep@computer.org
Internet
NETEXT WGControl and User Plane SplitControl and User Plane SeparationLMA User-Plane Address Mobility Option
This document specifies a method to split the control plane (CP) and
user plane (UP) for a network
infrastructure based on Proxy Mobile IPv6 (PMIPv6).
Existing specifications allow a mobile access
gateway (MAG) to separate its control and user
plane using the Alternate Care-of Address mobility option for
IPv6 or Alternate IPv4 Care-of Address option for
IPv4. However, the current specification does not
provide any mechanism allowing the local mobility anchor (LMA) to
perform an analogous functional split. To remedy that shortcoming,
this document specifies a mobility option enabling an
LMA to provide an alternate LMA address to
be used for the bidirectional user-plane traffic between the
MAG and LMA. With this new option, an LMA will be able to use an
IP address for its user plane that is different than the IP
address used for the control plane.
A Proxy Mobile IPv6 (PMIPv6) infrastructure comprises two primary entities: LMA
(local mobility anchor) and MAG (mobile access gateway).
The interface between the MAG and LMA consists of the control plane
and user plane. The control plane is responsible for signaling
messages between the MAG and LMA, such as the Proxy Binding Update (PBU)
and Proxy Binding Acknowledgement (PBA) 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 a bidirectional tunnel between
the MAG and LMA. The user plane is used
for carrying the mobile node's IP traffic between the MAG and the
LMA over the bidirectional tunnel.
Widely deployed mobility management systems for wireless
communications require separation of IP transport for forwarding user-plane
and control-plane traffic. This separation offers more flexible deployment options
for LMA and MAG entities in Proxy Mobile IPv6, as described
in .
To meet this requirement would also require that the
control-plane functions of the LMA
be addressable at a different IP address than
the IP address assigned for the user plane. However, PMIPv6
does not currently specify a mechanism for allowing the LMA to
separate the control plane from the user plane. The LMA is currently
required to associate the IP address of the tunnel source with the
target IP address for the control messages received from the MAG.
The control-plane and user-plane components of a MAG or LMA are
typically co-located in the same
physical entity. However, there are situations where it is desirable
to have the control and user plane of
a MAG or LMA in separate physical entities. For example, in a WLAN
(Wireless LAN) network, it may be desirable to have the
control-plane component of the MAG reside on the Access Controller (also
sometimes referred to as Wireless LAN Controller (WLC))
while the user-plane component of the MAG resides on the WLAN
Access Point. This enables all the control-plane messages to
the LMA to be centralized while the user plane would be distributed
across the multiple Access Points. Similarly, there is a need for
either the control-plane or user-plane component of the LMA to be
separated according to different scaling requirements or, in other
cases, the need to centralize the control plane in one geographical location
while distributing the user-plane
component across multiple locations.
For example, as illustrated in ,
the LMA and MAG could have one control session established
for PMIPv6 control signaling while maintaining separate connectivity
via Generic Routing Encapsulation (GRE) or IP-in-IP tunneling for forwarding user-plane traffic.
and
enable separating the control and user plane in the MAG. In particular,
defines the Alternate IPv4 Care-of
Address option, and defines an Alternate
Care-of Address option for IPv6. The MAG may provide an Alternate
Care-of Address in the PBU, and if the
LMA supports this option, then a bidirectional tunnel is set up
between the LMA address and the MAG's Alternate Care-of Address.
However, these documents do not specify a corresponding option for
the LMA to provide an alternate tunnel endpoint address to the MAG.
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 bidirectional tunnel between
the MAG and LMA, as shown in .
The LMA control-plane and the LMA user-plane functions are typically deployed on the same IP
node, and in such a scenario, the interface between these functions is internal to the implementation.
Deployments may also choose to deploy the LMA control-plane and the LMA user-plane functions on
separate IP nodes. In such deployment models, there needs to be a protocol interface between these
two functions, but that is outside the scope of this document. Possible options
for such an interface
include OpenFlow ,
Forwarding and Control Element Separation (ForCES) , use of routing infrastructure ,
and vendor-specific approaches. This specification does not mandate a specific protocol interface and
views this interface as a generic interface relevant more broadly for
many other protocol systems in addition to Proxy Mobile IPv6.
When the LMA control-plane and the LMA user-plane functions are deployed
on separate IP nodes, the requirement related to user-plane address
anchoring (specified in Section 5.6.2 of and Section 3.1.3 of ) must
be met by the node hosting the LMA user-plane functionality. The
LMA user-plane node must be a topological anchor point for the IP
address/prefixes allocated to the mobile node.
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 .
3GPP terms can be found in .
Other mobility-related terms used in this document are to be interpreted
as defined in and .
Additionally, this document uses the following terms:
IP-in-IP
IP-within-IP Encapsulation .
GRE
Generic Routing Encapsulation .
UDP Encapsulation
Encapsulation mode based on UDP transport specified in .
LMA Control-Plane Address (LMA-CPA)
The IP address on the LMA that is used for sending and
receiving control-plane traffic from the MAG.
LMA User-Plane Address (LMA-UPA)
The IP address on the LMA that is used for sending and
receiving user-plane traffic from the MAG.
MAG Control-Plane Address (MAG-CPA)
The IP address on the MAG that is used for sending and receiving
control-plane traffic from the LMA.
MAG User-Plane Address (MAG-UPA)
The IP address on the MAG that is used for sending and receiving
user-plane traffic from the LMA. This address is also referred
to as the Alternate Care-of Address.
To support the capability specified in this document, the conceptual
Binding Update List entry data structure maintained by the LMA and the
MAG is extended with the following additional fields:
The IP address of the LMA that carries user-plane traffic.The IP address of the LMA that handles control-plane traffic.
The LMA User-Plane Address mobility option is a new mobility header
option defined for use with PBU and PBA messages exchanged between
the LMA and the MAG. This option is used for notifying the MAG about
the LMA's user-plane IPv6 or IPv4 address. There can be zero, one, or
two instances of the LMA User-Plane Address mobility option present in
the message. When two instances of the option are present, one instance
of the option must be for IPv4 transport, and the other instance must be
for IPv6 transport.
The LMA User-Plane Address mobility option has an alignment
requirement of 8n+2. Its format is as shown in :
Type
59
Length
An 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 zero (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 address of the
LMA user plane. When the LMA User-Plane Address mobility
option is included in a PBU message, this
field can be a zero-length field, or it can have a value of
ALL_ZERO, with all bits in the 32-bit IPv4 address or the 128-bit
IPv6 address set to zero.
When including the LMA User-Plane Address mobility option
in the PBU, the MAG must apply the following rules:
When using IPv4 transport for the user plane, the IP address field
in the option MUST be either a zero-length field or a 4-octet
field with ALL_ZERO value.
When using IPv6 transport for the user plane, the IP address field
in the option MUST be either a zero-length field or a 16-octet
field with ALL_ZERO value.
When the LMA includes the LMA User-Plane Address mobility option in
the PBA, the IP address field in the option MUST
be set to the LMA's IPv4 or IPv6 address carrying user-plane traffic.
When using IPv4 transport for the user plane, the IP address field
in the option is the IPv4 address carrying user-plane
traffic.
When using IPv6 transport for the user plane, the IP address field
in the option is the IPv6 address carrying user-plane
traffic.
The encapsulation mode that will be chosen for the user plane between the MAG and the LMA has to
based on the considerations specified in and .
This specification defines the following configuration variable,
which must be configurable (e.g., by the system management)
on the LMA and MAG mobility entities. The configured value for
this protocol variable MUST survive server reboots and service
restarts and MUST be the same for every LMA and MAG in the
network domain supporting PMIPv6.
This variable indicates whether or not all the mobility entities in
the PMIPv6 domain support the LMA User-Plane Address mobility option.
When this variable on the MAG is set to zero (0), the MAG MUST
indicate whether or not it supports this feature by
including the LMA User-Plane Address mobility option in the PBU.
If the option is not present in the PBU,
the LMA SHALL disable this feature
for the mobility session corresponding to the PBU.
Setting this variable to one (1) on the MAG indicates that
there is domain-wide support for this feature and the MAG is not
required to include the LMA User-Plane Address mobility option in
the PBA. In this case, the MAG MAY choose not to include the
LMA User-Plane Address mobility option in the PBU.
When this variable on the LMA is set to zero (0), the LMA MUST NOT
include the LMA User-Plane Address mobility option in the PBA
unless the MAG has indicated support for this feature by including
the LMA User-Plane Address mobility option in the PBU message.
Setting this variable to one (1) on the LMA indicates that
there is domain-wide support for this feature and the LMA SHOULD
choose to include this LMA User-Plane Address mobility option in
the PBA even if the option is not present in the PBU message.
On both the LMA and the MAG, the default value for this variable
is zero (0). This implies that
the default behavior of a MAG is to include this option in the
PBU, and the default behavior of an LMA is to include this option
in a PBA only if the option is present in the PBU.This specification defines a new mobility header option -- the
LMA User-Plane Address mobility option. The format of this option
is described in . The Type value
59 for this mobility option has been allocated by IANA in the
"Mobility Options" registry at
<http://www.iana.org/assignments/mobility-parameters>.
The Proxy Mobile IPv6 specification requires the
signaling messages between the MAG and the LMA to be protected using end-to-end
security association(s) offering integrity and data origin authentication.
The Proxy Mobile IPv6 specification also requires IPsec to be a mandatory-to-implement security mechanism.
This document specifies an approach where the control-plane and user-plane functions of the
MAG and LMA are separated and hosted on different IP nodes. In such deployment models,
the nodes hosting those respective control-plane functions still have to meet
the security requirement listed above; specifically, the Proxy Mobile IPv6 signaling messages exchanged between these
entities MUST be protected using end-to-end security association(s) offering integrity and
data origin authentication. Furthermore, IPsec is a mandatory-to-implement security mechanism
for the nodes hosting the control-plane function of the MAG and
LMA. Additional documents may specify alternative security mechanisms for
securing Proxy Mobile IPv6 signaling messages. The mobility entities
in a Proxy Mobile IPv6 domain can enable a specific security mechanism
based on either (1) static configuration or (2) dynamic negotiation
(using any standard security negotiation protocols).
As per the Proxy Mobile IPv6 specification, the use of IPsec for protecting the mobile node's
user-plane traffic is optional. This specification keeps the same requirement and therefore
requires the nodes hosting the user-plane functions of the MAG and the LMA to have IPsec as a
mandatory-to-implement security mechanism but make the use of IPsec optional for user-plane
traffic protection.
The LMA User-Plane Address mobility option defined in this
specification is for use in PBU and PBA messages. This option is
carried like any other mobility header
option as specified in . Therefore,
it inherits security guidelines from .
The IP address of the LMA user plane (the LMA-UPA), provided
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 user-plane and the LMA control-plane functions are hosted in different
entities, any control messages between these two entities containing
the LMA User-Plane Address mobility option MUST be
protected using end-to-end security association(s) offering
integrity and data origin authentication.
Key words for use in RFCs to Indicate Requirement LevelsHarvard University1350 Mass. Ave.CambridgeMA 02138- +1 617 495 3864sob@harvard.eduProxy Mobile IPv6IPv4 Support for Proxy Mobile IPv6Security Architecture for the Internet ProtocolGeneric Routing Encapsulation (GRE)NetSmiths, Ltd.2025 Lincoln HighwayEdisonNJ08817USstan@netsmiths.comcisco Systems, Inc.1525 O'Brien DriveMenlo ParkCA94025UStli@cisco.comcisco Systems, Inc.1525 O'Brien DriveMenlo ParkCA94025USdino@cisco.comcisco Systems, Inc.1525 O'Brien DriveMenlo ParkCA94025USpst@cisco.comGeneric Packet Tunneling in IPv6 SpecificationLucent Technologies Inc.300 Baker AveConcordMA01742-2168USA+1 978 287 2842aconta@lucent.comCisco Systems170 West Tasman DrSan JoseCA95132-1706USA+1-408-527-8213deering@cisco.comMobility Support in IPv6Runtime Local Mobility Anchor (LMA) Assignment Support for Proxy Mobile IPv6IPv6 in 3rd Generation Partnership Project (3GPP) Evolved Packet System (EPS)Forwarding and Control Element Separation (ForCES) Protocol SpecificationBasic Transition Mechanisms for IPv6 Hosts and RoutersStateless user-plane architecture for virtualized EPC (vEPC)Requirements and use cases for separating control and user planes in mobile network architecturesOpenFlow Switch Specification, Version 1.4.0Open Networking Foundation The authors of this document thank the NetExt Working Group for the
valuable feedback on different versions of this specification. In
particular, the authors want to thank John Kaippallimalil, Sridhar
Bhaskaran, Nirav Salot, Bruno Landais, Brian Carpenter, Pete Resnick,
Stephen Farrell, and Brian Haberman for their valuable comments and
suggestions to improve this specification.