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]