INT Area R. Wakikawa Internet-Draft Softbank Mobile Intended status: Informational S. Matsushima Expires: May 11, 2014 Softbank Telecom B. Patil Individual B. Chen Sprint D. Joachimpillai(DJ) Verizon Labs H. Deng China Mobile November 07, 2013 Requirements and use cases for separating control and user planes in mobile network architectures draft-wakikawa-req-mobile-cp-separation-00 Abstract Virtualization and cloud services have evolved significantly in the last few years. Additionally trends in virtualization like Network Function Virtualiztion and Softward Defined Networking are bound to have implications to mobile network architectures of cellular systems (3G/4G), WiFi and others. IETF has developed a number of mobility protocols that are used in the industry today. Mobility network architectures continue to evolve and it is likely that they will embrace virtualization and cloud services trends as well. The IETF can play a role in defining the mobility protocols that support architectures which leverage virtualization and cloud technologies. This document captures several use cases and requirements for a virtualized mobile network architecture. 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." Wakikawa, et al. Expires May 11, 2014 [Page 1] Internet-Draft Draft Specification November 2013 This Internet-Draft will expire on May 11, 2014. Copyright Notice Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Motivation: Virtualization . . . . . . . . . . . . . . . . . 3 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Potential of New Mobile Architecture . . . . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 8.2. Informative References . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction The concept of User- and control- plane are well-known in networking. Especially, the 3rd Generation Partnership Project (3GPP) employs this concept in their mobile network architecture. These two planes are conceptually decoupled in the 3GPP architecture. In the past, IETF has developed tunnel based mechanisms for mobile nodes such as Mobile IPv6 [RFC6275][RFC5555], Proxy Mobile IPv6 [RFC5213][RFC5844] and NEMO [RFC3963]. All the mobility protocols discussed in the past are summarized in [RFC6301]. Similarly, 3GPP has developed another tunnel protocol called GPRS Tunneling Protocol (GTP). These tunnel- based protocol creates a data path for a mobile node between the mobile node and an anchor point (s). There is a case where an access router terminates a tunnel instead of a mobile node (ex. Proxy Mobile IP). In the 3GPP architecture, a tunnel is established between Serving Gateway and PDN Gateway per a mobile node Wakikawa, et al. Expires May 11, 2014 [Page 2] Internet-Draft Draft Specification November 2013 by either Proxy Mobile IPv6 or GTP (at s5 interface). The signaling like Binding Update and user's packets are routed along a same path in Evolved Packet Core (EPC). Therefore, the control and the user planes of these mobility protocols are tightly related and cannot be clearly decoupled, although there are several implementation efforts. 2. Motivation: Virtualization The recent innovations and trends of Software Defined Networking (SDN) and NFV (Network Function Virtualization) promotes to decouple User and Control planes. SDN consists of two entities named a controller and a vSwitch. The controller is responsible for signaling exchange and the vSwitches handles data forwarding based on the states fed by the controller. There are various controller that user can program vSwitch dynamically to adjust and optimize networks on the fly. Controller are often implemented with Virtualization technology and run as a software on hypervisors. On the other hand, NFV is discussed at the ETSI NFV ISG and is introduced in [NFV-WHITEPAPER]. Operators build its network with variety of proprietary hardware appliances today. If they can get rid of these physical appliances and could shift to a cloud-based service, they will have a lot of benefits, specially CAPEX and OPEX reduction. This document assumes that SDN and NFV will impact our daily network operations and managements. Expected network functions are Mobility Management Entity (MME), Serving Gateway (SGW) PDN Gateway(PGW), etc. With NFV, EPC can be operated onto servers/hyper-visors. We name it virtualized-EPC (vEPC) in this document. NFV will bring networking functions currently run on dedicated hardware onto a cloud network. It is good timing to re-visit the basic architecture of mobility system. Although the tunneling-based protocols are sustaining mobile traffic, SDN and NFV can introduce a new architecture that truly decoupled user- and control planes. This document summarizes requirements of the new architecture and its potential use cases. Benefits of NFV are summarized below. Detailed explanation can be found in [NFV-WHITEPAPER]). As a potential drawback, today's eco- system of mobile appliances might be affected. However, we believe there are various approaches to enhance current eco-system and migrate to new mobility approach. o [Flexible Network Operations]: The control functions are no longer in appliances deployed widely in operator's network and can be run at hypervisor (cloud). It is easier to add and/ or delete functions from the services, because no physical construction is needed. Network operations will be much simpler and easier because complications of today's network are pushed to NFV (i.e. hypervisor). Wakikawa, et al. Expires May 11, 2014 [Page 3] Internet-Draft Draft Specification November 2013 o [Flexible Resource Managements]: The network functions can be run on hypervisor and are now less dependent on proprietary hardware. Adding additional resources is easier in hypervisor, while adding or replacing physical appliances require installation, construction, configuration, and even migration plan without service cutoff. NFV also brings multi-tenancy and allows a single platform for different services and users. The operator can optimize resources and costs to share a NFV platform for multiple customers (ex. MVNO customers) and services (ex. multiple APNs). o [Faster Speed of Time to Market]: When an operator wants a new function to its network and services, the operator needs to negotiate appliance vendors to implement the new functions or to find alternative equipment supporting the new function. It takes a longer time to convince the vendors, or to replace existing hardware. However, if functions can be implemented as a software, it is much faster to implement the functions on NFV. Even the operator may implement them and try the new functions by themselves. Field trial is also getting easier because of no physical installation or replacement. You may turn on a new function in NFV and observe how the new function behaves in your network. NFV can save preparation time and tuning time of the new function. o [Cost Optimization]: Last but not least, Cost is the most important motivation for operators to realize NFV. Operators can remove many of proprietary appliances from its network and replace them with industry standard servers, switches and routers. In addition, it is easy to scale up and down operator's services so that resources can be always tuned to the size of services. In addition, operational costs led by any physical hardware such as power supply, maintenance, installation, construction and replacement can be minimized or even removed. The network design can be simpler, because complicated functions could be handled by NFV. That simple operation may enable automatic configurations and prevent unnecessary trouble-shooting. As a result, CAPEX and OPEX can be always optimized and lowered. 3. Requirements What is a role of IETF to discuss mobility architecture? IETF is not the right place to discuss, for instance, how to achieve virtualization or NFV. An important IETF activity must be to decouple the control- and user- planes of mobility protocols. IETF also should design and standardize protocols as building block of the new mobility architecture. In doing so, the new mobility solutions can be easily designed and implemented with interoperability across multiple vendors and platforms. Otherwise, NFV solutions can be Wakikawa, et al. Expires May 11, 2014 [Page 4] Internet-Draft Draft Specification November 2013 easily fragmented due to many proprietary solutions for the protocol separations. As stated in [NFV-WHITEPAPER], interoperability is highly important. This section lists up requirements of the new mobility architecture. Separation of Control- and User- Planes Due to tight relationship of the control- and user- planes in today's mobile architecture, resource increase is always provisioned to both planes at once. It prevents flexible resource arrangement and introduces high capital investment and over-provisioned resources to one of planes. If NFV is deployed, it is expected that computing resources can be independently allocated to the control planes in a flexible manner. Flat Design for Distributed Operation Today's 3GPP architecture introduces PDN gateway (PGW) as a gateway to external networks like the Internet. PGW manages all traffic from and to UEs and could be a bottleneck and single point of failure of network connectivity. In addition, due to recent rapid traffic increase, it is important to perform traffic engineering and to offload traffic to multiple locations (ex. SGW, PGW, eNodeB). For enhancements of traffic engineering capability, more flat design with multiple gateways is expected so that traffic can be distributed to all these gateways. There were proposals how to enable flat design to (Proxy) Mobile IP such as [I-D.wakikawa-mext-haha-interop2008] in IETF. Distributed Mobility Management (DMM) Working Group has also discussed how to extend Mobile IP-based solutions to support traffic distribution in an optimal way by removing centrally deployed anchors that is like a Home Agent. Stateless in User Plane Ultimate goal of vEPC is to remove all mobility specific states from the forwarding nodes in the user-plane of vEPC. If we succeed in this, industry standard routers and switches can be used to forward mobile nodes traffic in the user plane of vEPC. A mobile node's specific states are kept in both an IP header of the mobile node's packets and a routing entry of the mobile node. Shared backbone for fixed and mobile convergence If User plane focus only on packet forwarding, the user plane can be shared for both fixed and mobile services. Most of mobile operators have wired services and could share the backbone. With recent state-of-arts of routing technology, Wakikawa, et al. Expires May 11, 2014 [Page 5] Internet-Draft Draft Specification November 2013 it is reasonable to assume that routing system can dynamically propagate networking state information available on Control plane. Thus, both mobile and fixed packets are routed only on the user plane. No special treatment is needed for packets of mobile nodes and vice verse. Packet Processing Support: DPI, Accounting, Firewall In the today's mobile system like EPC-based cellular system, mobile packets are inspected and examined for various services and accounting such as DPI, FireWall, NAT, AAA, and so on . This is one of the reason that all packets are processed in the control plane. However, these L4-L7 services are also expected to be virtualized along with NFV and SDN trends. In IETF, there is an effort of SFC (Service Function Chaining) to discuss this topics. A new mechanism or trigger to provide these network services to mobile packets are needed on the user plane. 4. Use Cases Use cases of the new mobility architecture are networks with local mobility support. Global mobility is not target of our activity. Global and local mobility are defined in [RFC3753]. Typical examples of local mobility network are cellular network (EPC: Evolved Packet Core), WiMAX, service provider WiFi and so on. Our use cases should meet the following characteristics. o A same provider conceptually provide access network (i.e. user plane) and mobility support (i.e. control plane). o A provider should be able to setup a route for the mobile node dynamically on the user plane according to the status on control plane. Network access and mobility management are conceptually provided by a same provider. That is to say that a mobile ndoe only moves in the provider's network, i.e. local mobility. 5. Potential of New Mobile Architecture [RFC6301] investigates the mobile architecture and classifies into 2 approaches such as Routing-Based and Mapping-Based Approaches, described in Figure 1. Both approaches do not take account of control and user planes separation. o Routing-based approach: Mobility is provided by dynamic routing. A mobile node keeps its IP address regardless of its point of attachments. Dynamic routing mechanism keeps track of a mobile Wakikawa, et al. Expires May 11, 2014 [Page 6] Internet-Draft Draft Specification November 2013 node's movements and updates routing tables so as to support continuous reachability. o Mapping-based approach: Mobility is achieved by a mapping between mobile node's identifier and dynamically assigned IP address at an attachment point. This mapping is managed in networks and updated every time a mobile node moves. Packets are first routed to the node managing the mapping and redirected to a mobile node according to the mapping. This redirection is often implemented by a tunneling mechanism. Mobile IP is the most famous protocol of this approach. _+---+_ _ _+---+_ _ _ _+------------+_ _ _ / | M | | L | / / | | / Control / | A | | M | / / | | / Plane /_ _| G |_ _ _| A |__/ /_ _| Routing |__/ | / | | / | | Network | | S | | P | vs. | | _| G |_ _ _| G |_ _ _ _| |_ _ _ / | W | | W | / / | | / User-plane / +---+ +---+ / / +------------+ / /_ _ _ _ _ _ _ _ _ _ / /_ _ _ _ _ _ _ _ __ / Mapping-based approach Routing-based approach 2 approaches of Mobile Architecture Figure 1 As we mentioned earlier, the most of mobility protocols deployed today uses the mapping-based approach. There is a good reason of adapting mapping and tunneling in mobility protocols , that is global mobility and signaling. A mobile node should be able to move anywhere on the Internet and be reachable from anyone on the Internet. There were routing based global mobility solutions like Boeing global mobility [Boeing-BGP] and WINMO [RFC6301]. In these proposals, BGP was used to propagate forwarding information of mobile nodes to the Internet. Whenever a mobile node changes its point of attachment, the route must be updated. Due to scalability and stability issues of the Internet, this solution was not recommended by IETF [Boeing-BGP]. However, as Boeing showed, it is doable to support global mobility by using BGP routing update. If scalability is not your concern, a routing based approach becomes a candidate of the mobility solution. While global mobility is important, today's "reality" is that your cell phones (i.e. UE or mobile node) are moving just within an Wakikawa, et al. Expires May 11, 2014 [Page 7] Internet-Draft Draft Specification November 2013 operator's network and fully controlled in your local managed domain (ex. EPC). If mobility support can be limited within an operator, we believe a routing based approach is feasible and practical for today's mobile system. If the concept of NFV and SDN were realized and deployed, we could have strong tools to split control and user planes. Figure 2 shows a possibility that nodes on the Control plane are virtualized in generic cloud environment, however user packets won't go through those virtualized nodes. Instead of dedicated proprietary equipment like MAG and LMA to process signaling of mobility support, virtualized software running on hypervisor will take care of signaling on the control plane. After signaling completion, the status is reflected as forwarding information to switches and routes in the user plane. The reflection can be implemented by routing or SDN solutions. As a result, packets to and from mobile nodes are no longer tunneled between MAG and LMA but they are directly routed on the user plane. Figure 2 could relax hyper-visor and data- path capacity requirements. The user plane will be agnostic from sessions and bearers states, of which are generated and maintained in the Control-plane. It forwards the packets based on a destination address of packets and routing entries injected by the control plane. _+---+_ _ _+---+_ _ _ / | M | | L | / Control-plane / | A | | M | NFV /_ _| G |_ _ _| A |__/ +---+ +---+ +-------------+ _| Routing |_ _ _ / | Network | / User-plane / +-------------+ Routing/SDN /_ _ _ _ _ _ _ _ _ _ _/ New Mobility architecture Figure 2 6. IANA Considerations This memo includes no request to IANA. 7. Security Considerations There are no security considerations specific to this document at this moment. Wakikawa, et al. Expires May 11, 2014 [Page 8] Internet-Draft Draft Specification November 2013 8. References 8.1. Normative References [I-D.vandevelde-idr-remote-next-hop] Velde, G., Patel, K., Rao, D., Raszuk, R., and R. Bush, "BGP Remote-Next-Hop", draft-vandevelde-idr-remote-next- hop-03 (work in progress), October 2012. [RFC5512] Mohapatra, P. and E. Rosen, "The BGP Encapsulation Subsequent Address Family Identifier (SAFI) and the BGP Tunnel Encapsulation Attribute", RFC 5512, April 2009. 8.2. Informative References [Boeing-BGP] Andrew, ., "Global IP Network Mobility using Border Gateway Protocol (BGP)", IAB Plenary IAB Plenary of IETF 62nd, March 2005. [I-D.ietf-softwire-map] Troan, O., Dec, W., Li, X., Bao, C., Matsushima, S., Murakami, T., and T. Taylor, "Mapping of Address and Port with Encapsulation (MAP)", draft-ietf-softwire-map-07 (work in progress), May 2013. [I-D.savolainen-stateless-pd] Savolainen, T. and J. Korhonen, "Stateless IPv6 Prefix Delegation for IPv6 enabled networks", draft-savolainen- stateless-pd-01 (work in progress), February 2010. [I-D.wakikawa-mext-haha-interop2008] Wakikawa, R., Shima, K., and N. Shigechika, "The Global HAHA Operation at the Interop Tokyo 2008", draft-wakikawa- mext-haha-interop2008-00 (work in progress), July 2008. [I-D.yokota-dmm-scenario] Yokota, H., Seite, P., Demaria, E., and Z. Cao, "Use case scenarios for Distributed Mobility Management", draft- yokota-dmm-scenario-00 (work in progress), October 2010. [NFV-WHITEPAPER] Network Operators, ., "Network Functions Virtualization, An Introduction, Benefits, Enablers, Challenges and Call for Action", SDN and OpenFlow SDN and OpenFlow World Congress, October 2012. Wakikawa, et al. Expires May 11, 2014 [Page 9] Internet-Draft Draft Specification November 2013 [RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 3753, June 2004. [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005. [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. [RFC5555] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and Routers", RFC 5555, June 2009. [RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy Mobile IPv6", RFC 5844, May 2010. [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support in IPv6", RFC 6275, July 2011. [RFC6301] Zhu, Z., Wakikawa, R., and L. Zhang, "A Survey of Mobility Support in the Internet", RFC 6301, July 2011. [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- Stack Lite Broadband Deployments Following IPv4 Exhaustion", RFC 6333, August 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. [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: Combination of Stateful and Stateless Translation", RFC 6877, April 2013. Authors' Addresses Ryuji Wakikawa Softbank Mobile 1-9-1,Higashi-Shimbashi,Minato-Ku Tokyo 105-7322 Japan Email: ryuji.wakikawa@gmail.com Wakikawa, et al. Expires May 11, 2014 [Page 10] Internet-Draft Draft Specification November 2013 Satoru Matsushima Softbank Telecom 1-9-1,Higashi-Shimbashi,Minato-Ku Tokyo 105-7322 Japan Email: satoru.matsushima@g.softbank.co.jp Basavaraj Patil Individual Email: bpatil1@gmail.com Bonnie Chen Sprint 6220 Sprint Parkway Overland Park, KS 66251 USA Email: Bonnie.Chen@Sprint.com Damascene Joachimpillai(DJ) Verizon Labs Email: damascene.joachimpillai@verizon.com Hui Deng China Mobile 53A, Xibianmennei Ave., Xuanwu District Beijing 100053 China Email: denghui02@gmail.com Wakikawa, et al. Expires May 11, 2014 [Page 11]