One document matched: draft-ietf-netext-pmip-cp-up-separation-03.xml
<?xml version="1.0"?>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc tocappendix="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc1701 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1701.xml'>
<!ENTITY rfc2003 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2003.xml'>
<!ENTITY rfc2119 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY rfc2473 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2473.xml'>
<!ENTITY rfc5213 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5213.xml'>
<!ENTITY rfc5844 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5844.xml'>
<!ENTITY rfc6275 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6275.xml'>
<!ENTITY rfc6463 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6463.xml'>
<!ENTITY rfc6459 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6459.xml'>
<!ENTITY rfc5810 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5810.xml'>
<!ENTITY rfc5415 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5415.xml'>
<!ENTITY rfc7149 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.7149.xml'>
<!ENTITY rfc5812 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5812.xml'>
<!ENTITY I-D.matsushima-stateless-uplane-vepc SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.matsushima-stateless-uplane-vepc.xml">
<!ENTITY I-D.wakikawa-req-mobile-cp-separation SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.wakikawa-req-mobile-cp-separation.xml">
<!ENTITY I-D.yokota-dmm-scenario SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.yokota-dmm-scenario.xml">
]>
<rfc category="std" ipr="trust200902" docName="draft-ietf-netext-pmip-cp-up-separation-03.txt">
<front>
<title abbrev="PMIPv6 CP-UP Split">
Separation of Control and User Plane for Proxy Mobile IPv6
</title>
<author initials="R." surname="Wakikawa" fullname="Ryuji Wakikawa">
<organization>Softbank Mobile</organization>
<address>
<postal>
<street>1-9-1,Higashi-Shimbashi,Minato-Ku</street>
<city>Tokyo 105-7322</city>
<country>Japan</country>
</postal>
<email>ryuji.wakikawa@gmail.com</email>
</address>
</author>
<author fullname="Rajesh S. Pazhyannur" initials="R.P" surname="Pazhyannur">
<organization>Cisco</organization>
<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose, CA 95134</city>
<region/>
<code/>
<country>USA</country>
</postal>
<email>rpazhyan@cisco.com</email>
</address>
</author>
<author initials="S" surname="Gundavelli" fullname="Sri Gundavelli">
<organization abbrev="">Cisco</organization>
<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>USA</country>
</postal>
<email>sgundave@cisco.com</email>
</address>
</author>
<author fullname="Charles E. Perkins" initials="C.P" surname="Perkins">
<organization>Futurewei Inc.</organization>
<address>
<postal>
<street>2330 Central Expressway</street>
<city>Santa Clara, CA 95050</city>
<region/>
<code/>
<country>USA</country>
</postal>
<email>charliep@computer.org</email>
</address>
</author>
<date year="2014" />
<area>Internet</area>
<workgroup>NETEXT WG</workgroup>
<!-- SECTION 0: Abstract -->
<abstract>
<t>
This document specifies a method to split the Control Plane (CP) and
User Plane (UP) for a Proxy Mobile IPv6 based network
infrastructure. 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 a
LMA to provide an alternate LMA address to
be used for the bi-directional user plane traffic between the
MAG and LMA. With this new option, a LMA will be able to use an
IP address for its user plane which is different than the IP
address used for the control plane.
</t>
</abstract>
</front>
<middle>
<!-- SECTION 1: Introduction -->
<section anchor="sec:introduction" title="Introduction">
<t>
A PMIPv6 infrastructure comprises two primary entities: LMA
(Local Mobility Anchor) and MAG (Mobile 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 (PBU)
and Proxy Binding Acknowledge (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 bi-directional tunnel between
the MAG and LMA. The user plane is responsible
for forwarding the mobile node's data traffic between the MAG and the
LMA over the bi-directional tunnel.
</t>
<t>
Widely deployed mobility management systems for wireless
communications require separation of IP end points for forwarding data
packets (the user plane) versus the mobility signaling (the control
plane). This separation brings more flexible deployment and
management of LMA and MAG(s) of Proxy Mobile IP as described
in <xref target="I-D.wakikawa-req-mobile-cp-separation"/>.
<!-- 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 (PMIPv6) requires that the
control plane functions of the LMA
to 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 data 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.
</t>
<t>
The control plane and user plane components (of the MAG and 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 the
MAG and 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))
<!-- CEP: WLC does not appear elsewhere in the document -->
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 and 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 <xref target="fig1"/>,
the LMA and MAG could have one control session established
for PMIPv6 control signaling, while maintaining separate connectivity
via GRE or IP-in-IP tunneling for forwarding data.
</t>
<figure anchor="fig1"
title="Functional Separation of the Control and User Plane">
<artwork>
<![CDATA[
MAG LMA
+--------+ +--------+
+------+ | MAG-CP |--------------| LMA-CP | _----_
| MN | | | PMIPv6 | | _( )_
| |---- +--------+ +--------+ ===( Internet )
+------+ : : (_ _)
+--------+ +--------+ '----'
| MAG-UP |--------------| LMA-UP |
| | GRE/IP-in-IP | |
+--------+ +--------+
CP: Control Plane
UP: User Plane
]]>
</artwork>
</figure>
<t>
<xref target="RFC6463"/> and <xref target ="RFC6275"/>
enable separating the control and user plane in the MAG. In particular,
<xref target="RFC6463"/> defines the Alternate IPv4 Proxy Care of
Address Option, and <xref target ="RFC6275"/> defines an Alternate
Care of Address for IPv6 address. The MAG may provide an Alternate
Care of Address in the PBU, and if the
LMA supports this option then a bi-directional tunnel is setup
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 address to the MAG.
</t>
<t>
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 <xref target="fig1"/>.
</t>
<t>
Note that the interface between the control and user plane is out
of scope in this document. It is required to setup a data path on the
user plane according to the control signaling on the control plane.
Several IETF working groups are addressing this interface as described
in <xref target="RFC5415"/>, <xref target="RFC5812"/>,
<xref target="RFC5810"/>,
<xref target="I-D.matsushima-stateless-uplane-vepc"/>.
Techniques from Software Defined
Networking (SDN) <xref target="RFC7149"/> may also be applied.
</t>
</section>
<!-- SECTION 2: CONVENTIONS & TERMINOLOGY -->
<section anchor="sec:conv_and_term" title="Conventions and Terminology">
<!--vspace blankLines="1" /-->
<!-- SECTION 2.1: CONVENTIONS -->
<section anchor="sec:conventions" title="Conventions">
<t>
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 <xref target="RFC2119"/>.
</t>
</section> <!-- conventions -->
<!-- SECTION 2.2: TERMINOLOGY -->
<section anchor="sec:terminology" title="Terminology">
<t>
3GPP terms can be found in <xref target="RFC6459"/>.
Other mobility related terms used in this document are to be interpreted
as defined in <xref target="RFC5213"/> and <xref target="RFC5844"/>.
Additionally, this document uses the following terms:
</t>
<t>
IP-in-IP
<list style="hanging"> <t>
IP-within-IP encapsulation <xref target="RFC2473"/>
<!-- <xref target="RFC2003"/> -->
</t> </list> </t>
<t>
GRE
<list style="hanging"> <t>
Generic Routing Encapsulation <xref target="RFC1701"/>
</t> </list> </t>
<t>
LMA Control Plane Address (LMA-CP)
<list style="hanging"> <t>
The IP address on the LMA that is provided to the MAG for
establishing control plane connections.
</t> </list> </t>
<t>
LMA User Plane Address (LMA-UP)
<list style="hanging"> <t>
The IP address on the LMA that is used for establishing user
plane tunnels with the mobile access gateway.
</t> </list> </t>
<t>
MAG Control Plane Address (MAG-CP)
<list style="hanging"> <t>
The IP address on the MAG that is provided to the LMA for
establishing control plane connections.
</t> </list> </t>
<t>
MAG User Plane Address (MAG-UP)
<list style="hanging"> <t>
The IP address on the MAG that supports user plane
tunnels with the LMA.
</t> </list> </t>
</section> <!-- Terminology -->
</section> <!-- Conventions & Terminology -->
<!-- 3. Additional Fields in Conceptual Data Structures -->
<section anchor="sec:conceptual"
title="Additional Fields in Conceptual Data Structures">
<t>
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.
<list style="symbols">
<t>The IP address of the LMA that carries user plane traffic.</t>
<t>The IP address of the LMA that handles control plane traffic.</t>
</list>
</t>
</section>
<!-- SECTION 4.0: Section: LMA-UPA Option -->
<section anchor="sec:dmnp_format"
title="LMA User Plane Address Mobility Option">
<t>
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 multiple instances of the LMA User Plane
Address mobility option present in the message, one for IPv4
and the other for IPv6 transport.
</t>
<t>
The LMA User Plane Address mobility option has an alignment
requirement of 8n+2. Its format is as shown in <xref target="fig2"/>:
</t>
<figure anchor="fig2" title="LMA User Plane Address option format">
<artwork><![CDATA[
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 +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>
Type
<list>
<t>
<IANA-1> To be assigned by IANA.
</t>
</list>
</t>
<t>
Length
<list>
<t>
8-bit unsigned integer indicating the length of the option in octets,
excluding the type and length fields.
</t>
</list>
</t>
<t>
Reserved
<list>
<t>
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.
</t>
</list>
</t>
<t>
LMA User Plane Address
<list>
<t>
Contains the 32-bit IPv4 address, or the 128-bit IPv6 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.
</t>
</list>
</t>
<t>
When including the LMA User Plane Address mobility option
in the PBU, the MAG must apply the following rules:
<list style="symbols">
<t> When using IPv4 transport for the user-plane, the IP address
field in the option can be either a zero-length field, or
a 4-octet field with ALL_ZERO value.
</t>
<t> When using IPv6 transport for the user-plane, the IP address
field in the option can be either a zero-length field, or
a 16-octet field with ALL_ZERO value.
</t>
</list>
</t>
<t>
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.
<list style="symbols">
<!-- CEP: Making a list seems quite redundant, but whatever! -->
<t>
When using IPv4 transport for the user-plane, the IP address
field in the option must be the IPv4 address carrying
user-plane traffic.
</t>
<t>
When using IPv6 transport for the user-plane, the IP address
field in the option must be the IPv6 address carrying
user-plane traffic.
</t>
</list>
</t>
</section>
<!-- SECTION 5: Protocol Configuration Variable -->
<section title="Protocol Configuration Variable" anchor="sec-pvars">
<t>
This specification defines the following configuration variable,
<!-- CEP: The entities are machines, and don't have any say in the matter.-->
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.
</t>
<t>
<list style='hanging'>
<t hangText="Domain-wide-LMA-UPA-Support">
<list>
<t>
This variable indicates whether or not all the mobility entities in
the PMIPv6 domain support the LMA User Plane Address mobility option.
</t>
<t>
When this variable on the MAG is set to zero (0), the MAG MUST
<!-- CEP: Here (and below), "explicitly" seems quite superfluous to me. -->
indicate whether it supports this feature, by
<!-- CEP: PBU and PBA were defined earlier, and used occasionally in the
previous revision. Now they are used wherever appropriate. -->
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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 a LMA is to include this option
in a PBA only if the option is present in the PBU.</t>
</list>
</t>
</list>
</t>
</section>
<!-- SECTION 6: IANA Considerations -->
<section anchor="sec:iana" title="IANA Considerations">
<t>
This document requires the following IANA actions.
</t>
<t>
<list style="symbols">
<t>
Action-1: This specification defines a new mobility header option,
LMA User Plane Address mobility option. The format of this option
is described in <xref target="sec:dmnp_format"/>. The type value
<IANA-1> for this mobility option is to be allocated from
the Mobility Options registry at
<http://www.iana.org/assignments/mobility-parameters>.
RFC Editor: Please replace <IANA-1> in
<xref target="sec:dmnp_format"/> with the assigned value and update
this section accordingly.
</t>
</list>
</t>
</section>
<!-- SECTION 7: Security Considerations -->
<section anchor="sec:secons" title="Security Considerations">
<t>
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 <xref target="RFC5213"/>. Therefore,
it inherits security guidelines from <xref target="RFC5213"/>.
</t>
<t>
The LMA-UP address provided within the LMA User Plane Address
mobility option MUST be a valid address under the administrative
control associated with the LMA functional block.
</t>
<t>
If the LMA-UP and the LMA-CP functions are hosted in different
entities, any control messages between these two entities containing
the LMA User Plane Address mobility option MUST be
protected by IPsec.
</t>
</section>
<!-- SECTION 8: Acknowledgements -->
<section anchor="sec:ack" title="Acknowledgements">
<t>
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.
</t>
</section>
</middle>
<back>
<!-- SECTION 9: Normative References -->
<references title="Normative References">
&rfc2119;
&rfc5213;
&rfc5844;
</references>
<!-- SECTION 10: Informative References -->
<references title="Informative References">
&rfc1701;
&rfc2473;
&rfc6275;
&rfc6463;
&rfc6459;
&rfc5810;
&rfc5415;
&rfc7149;
&rfc5812;
&I-D.matsushima-stateless-uplane-vepc;
&I-D.wakikawa-req-mobile-cp-separation;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 08:20:46 |