[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

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]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/