NETEXT WG R. Wakikawa Internet-Draft Softbank Mobile Intended status: Standards Track R. Pazhyannur Expires: July 17, 2014 S. Gundavelli Cisco C. Perkins Futurewei Inc. January 13, 2014 Separation of Control and User Plane for Proxy Mobile IPv6 draft-ietf-netext-pmip-cp-up-separation-01.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 July 17, 2014. Copyright Notice Wakikawa, et al. Expires July 17, 2014 [Page 1] Internet-Draft PMIPv6 CP-UP Split January 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. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 7.1. Normative References . . . . . . . . . . . . . . . . . . . 7 7.2. Informative References . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Wakikawa, et al. Expires July 17, 2014 [Page 2] Internet-Draft PMIPv6 CP-UP Split January 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 July 17, 2014 [Page 3] Internet-Draft PMIPv6 CP-UP Split January 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 July 17, 2014 [Page 4] Internet-Draft PMIPv6 CP-UP Split January 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 exchnaged 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 July 17, 2014 [Page 5] Internet-Draft PMIPv6 CP-UP Split January 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 IPv4/IPv6 user plane address of the LMA. 4. IANA Considerations This document requires the following IANA action. o Action-1: This specification defines a new Mobility Header option, LMA User Plane Address mobility option. This mobility option is described in Section 3. The type value for this message needs to be allocated from the Mobility Header Types registry at http://www.iana.org/assignments/mobility-parameters. RFC Editor: Wakikawa, et al. Expires July 17, 2014 [Page 6] Internet-Draft PMIPv6 CP-UP Split January 2014 Please replace in Section 3 with the assigned value, and update this section accordingly. 5. 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. 6. Acknowledgements The authors would like to acknowledge all the discussions on this topic in the IETF netext Working Group. 7. References 7.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. 7.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., Wakikawa, et al. Expires July 17, 2014 [Page 7] Internet-Draft PMIPv6 CP-UP Split January 2014 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 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 July 17, 2014 [Page 8]