Separation of Control and User Plane for Proxy Mobile IPv6
draft-ietf-netext-pmip-cp-up-separation-03.txt

Abstract

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.

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 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.

1. Introduction

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.

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 [I-D.wakikawa-req-mobile-cp-separation]. 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.

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)) 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 Figure 1, 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.


                  MAG                    LMA    
              +--------+              +--------+ 
+------+      | MAG-CP |--------------| LMA-CP |        _----_      
|  MN  |      |        |    PMIPv6    |        |      _(      )_   
|      |----  +--------+              +--------+  ===( Internet )
+------+          :                       :           (_      _)   
              +--------+              +--------+        '----'
              | MAG-UP |--------------| LMA-UP |   
              |        | GRE/IP-in-IP |        |    
              +--------+              +--------+ 
CP: Control Plane
UP: User Plane

Figure 1: Functional Separation of the Control and User Plane

[RFC6463] and [RFC6275] enable separating the control and user plane in the MAG. In particular, [RFC6463] defines the Alternate IPv4 Proxy Care of Address Option, and [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.

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 Figure 1.

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 [RFC5415], [RFC5812], [RFC5810], [I-D.matsushima-stateless-uplane-vepc]. Techniques from Software Defined Networking (SDN) [RFC7149] may also be applied.

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

: Generic Routing 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 supports user plane tunnels with the LMA.

3. Additional Fields in Conceptual Data Structures

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.

4. LMA User Plane Address Mobility Option

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.

The LMA User Plane Address mobility option has an alignment requirement of 8n+2. Its format is as shown in Figure 2:

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                    +
|                                                               |
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 2: LMA User Plane Address option format

Type

<IANA-1> 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 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 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 can 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 can 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 must be the IPv4 address carrying user-plane traffic.
When using IPv6 transport for the user-plane, the IP address field in the option must be the IPv6 address carrying user-plane traffic.

5. Protocol Configuration Variable

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.

Domain-wide-LMA-UPA-Support

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 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 a LMA is to include this option in a PBA only if the option is present in the PBU.

6. IANA Considerations

This document requires the following IANA actions.

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 4. 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 Section 4 with the assigned value and update this section accordingly.

7. Security Considerations

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 [RFC5213]. Therefore, it inherits security guidelines from [RFC5213].

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.

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.

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.

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.
[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.
[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.
[RFC5810]	Doria, A., Hadi Salim, J., Haas, R., Khosravi, H., Wang, W., Dong, L., Gopal, R. and J. Halpern, "Forwarding and Control Element Separation (ForCES) Protocol Specification", RFC 5810, March 2010.
[RFC5415]	Calhoun, P., Montemurro, M. and D. Stanley, "Control And Provisioning of Wireless Access Points (CAPWAP) Protocol Specification", RFC 5415, March 2009.
[RFC7149]	Boucadair, M. and C. Jacquenet, "Software-Defined Networking: A Perspective from within a Service Provider Environment", RFC 7149, March 2014.
[RFC5812]	Halpern, J. and J. Hadi Salim, "Forwarding and Control Element Separation (ForCES) Forwarding Element Model", RFC 5812, March 2010.
[I-D.matsushima-stateless-uplane-vepc]	Matsushima, S. and R. Wakikawa, "Stateless user-plane architecture for virtualized EPC (vEPC)", Internet-Draft draft-matsushima-stateless-uplane-vepc-02, February 2014.
[I-D.wakikawa-req-mobile-cp-separation]	Wakikawa, R., Matsushima, S., Patil, B., Chen, B., DJ, D. and H. Deng, "Requirements and use cases for separating control and user planes in mobile network architectures", Internet-Draft draft-wakikawa-req-mobile-cp-separation-00, November 2013.

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

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