Service Function Chaining Dataplane Elements in Mobile Networks
draft-aranda-sfc-dp-mobile-00

SFC                                                  P. Aranda Gutierrez
Internet-Draft                                                       TID
Intended status: Informational                              M. Gramaglia
Expires: October 6, 2016                                           IMDEA
                                                              DRL. Lopez
                                                                     TID
                                                             W. Haeffner
                                                                Vodafone
                                                           April 4, 2016

    Service Function Chaining Dataplane Elements in Mobile Networks
                     draft-aranda-sfc-dp-mobile-01

Abstract

   The evolution of the network towards 5G implies a challenge for the
   infrastructure.  The targeted services and the full deployment of
   virtualization in all segments of the network will need service
   function chains that previously resided in the(local and remote)
   infrastructure of the Network operators to extend to the radio access
   network (RAN).

   The objective of this draft is to provide a non-exhaustive but
   representative list of service functions in 4G and 5G networks.  We
   base on the problem statement [RFC7498] and architecture framework
   [RFC7665]  of the SFC working group, as well on the existing mobile
   networks use cases [I-D.ietf-sfc-use-case-mobility]  and the
   requirement gathering process of the ITU-R IMT 2020 [1] and different
   initiatives in Europe [2], Korea [3] and China [4] to anticipate
   network elements that will be needed in 5G networks.

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 October 6, 2016.

Aranda Gutierrez, et al. Expires October 6, 2016                [Page 1]
Internet-Draft  SFC Dataplane Elements in Mobile Networks     April 2016

Copyright Notice

   Copyright (c) 2016 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
     1.1.  Terminology and abbreviations . . . . . . . . . . . . . .   3
     1.2.  General scope of mobile service chains  . . . . . . . . .   3
     1.3.  Requirements for 5G networks  . . . . . . . . . . . . . .   4
       1.3.1.  Evolution of the end-to-end carrier network . . . . .   4
   2.  Mobile network overview . . . . . . . . . . . . . . . . . . .   5
     2.1.  Building blocks of 4G and 5G networks . . . . . . . . . .   5
       2.1.1.  Classification schemes for 5G networks  . . . . . . .   6
     2.2.  Control plane considerations  . . . . . . . . . . . . . .   6
     2.3.  Operator requirements . . . . . . . . . . . . . . . . . .   6
   3.  New concepts for network virtualization . . . . . . . . . . .   7
     3.1.  Decomposition and Allocation of VNF . . . . . . . . . . .   7
     3.2.  Combining Access and Core . . . . . . . . . . . . . . . .   8
     3.3.  Service-aware orchestration . . . . . . . . . . . . . . .   9
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  10
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  10
     7.2.  Informative References  . . . . . . . . . . . . . . . . .  10
     7.3.  URIs  . . . . . . . . . . . . . . . . . . . . . . . . . .  11
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12

1.  Introduction

   TODO: Intro

Aranda Gutierrez, et al. Expires October 6, 2016                [Page 2]
Internet-Draft  SFC Dataplane Elements in Mobile Networks     April 2016

1.1.  Terminology and abbreviations

   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 RFC2119 [RFC2119].

   Much of the terminology used in this document has been defined by
   either the 3rd Generation Partnership Project (3GPP) or by activities
   related to 5G networks like IMT2020 in ITU-R.  Some terms are defined
   here for convenience, in addition to those found in RFC6459
   [RFC6459].

   +-------+-----------------------------------------------------------+
   | UE    | User equipment like tablets or smartphones                |
   | eNB   | enhanced NodeB, radio access part of the LTE system       |
   | S-GW  | Serving Gateway, primary function is user plane mobility  |
   | P-GW  | Packet Gateway, actual service creation point, terminates |
   |       | 3GPP mobile network, interface to Packet Data Networks    |
   |       | (PDN)                                                     |
   | HSS   | Home Subscriber Server (control plane element)            |
   | MME   | Mobility Management Entity (control plane element)        |
   | GTP   | GPRS (General Packet Radio Service) Tunnel Protocol       |
   | S-IP  | Source IP address                                         |
   | D-IP  | Destination IP address                                    |
   | IMSI  | The International Mobile Subscriber Identity that         |
   |       | identifies a mobile subscriber                            |
   | (S)Gi | Egress termination point of the mobile network (SGi in    |
   |       | case of LTE, Gi in case of UMTS/HSPA). The internal data  |
   |       | structure of this interface is not standardized by 3GPP   |
   | PCRF  | 3GPP standardized Policy and Charging Rules Function      |
   | PCEF  | Policy and Charging Enforcement Function                  |
   | TDF   | Traffic Detection Function                                |
   | TSSF  | Traffic Steering Support Function                         |
   | IDS   | Intrusion Detection System                                |
   | FW    | Firewall                                                  |
   | ACL   | Access Control List                                       |
   | PEP   | Performance Enhancement Proxy                             |
   | IMS   | IP Multimedia Subsystem                                   |
   | LI    | Legal Intercept                                           |
   +-------+-----------------------------------------------------------+

                                  Table 1

1.2.  General scope of mobile service chains

   Current mobile access networks terminate at a mobile service creation
   point (called Packet Gateway) typically located at the edge of an
   operator IP backbone.  Within the mobile network, the user payload is

Aranda Gutierrez, et al. Expires October 6, 2016                [Page 3]
Internet-Draft  SFC Dataplane Elements in Mobile Networks     April 2016

   encapsulated in 3GPP specific tunnels terminating eventually at the
   P-GW.  In many cases application-specific IP traffic is not directly
   exchanged between the original mobile network, more specific the
   P-GW, and an application platform, but will be forced to pass a set
   of service functions.  Network operators use these service functions
   to differentiate their services.

   In order to cope with the stringent requirements of 5G networks (cf.
   Section 1.3), we expect a new architecture to appear.  This
   architecture will surely make extensive use of virtualisation up to
   the RAN.  We also expect that IP packets will need to be processed
   much earlier that in the current 3GPP architecture.  In this context,
   it is foreseeable that Service Function Chaining will play a
   substantial role when managing the chains network traffic will
   traverse.  We also expect new kinds of service functions specific to
   the radio access part to appear and that these new service functions
   will need to be managed by the SFC management infrastructure of the
   operator.

1.3.  Requirements for 5G networks

   As set forth by the 5G Infrastructure Public Private Partenrship
   (5GPPP) [5], the evolution of the infrastructure towards 5G should
   enable the following features in the mobile environment:

   o  Providing 1000 times higher wireless area capacity

   o  Saving up to 90% of energy per service provided

   o  Reducing the average service creation time cycle from 90 hours to
      90 minutes

   o  Facilitating very dense deployments of wireless communication
      links to connect over 7 trillion wireless devices serving over 7
      billion people

1.3.1.  Evolution of the end-to-end carrier network

   [SFC-Mobile-UC]  presents the structure of end-to-end carrier
   networks and focused on the Service Function Chaining use cases for
   mobile carrier networks, such as current 3GPP- based networks.  We
   recognise that other types of carrier networks that are currently
   deployed share similarities in the structure of the access networks
   and the service functions with mobile networks.  The evolution
   towards 5G networks will make the distinction between these different
   types of networks blur and eventually disappear.

Aranda Gutierrez, et al. Expires October 6, 2016                [Page 4]
Internet-Draft  SFC Dataplane Elements in Mobile Networks     April 2016

   5G networks are expected to massively deploy virtualisation
   technologies from the radio elements to the core of the network.  The
   four building blocks of the RAN, i.e. i) spectrum allocation or
   physical layer (PHY), i) Medium Access Control (MAC), iii) Radio Link
   Control (RLC) and iv) Packet Data Convergence, are candidates for
   virtualisation.

2.  Mobile network overview

   [SFC-Mobile-UC] provides an overview of mobile networks up to LTE
   (Long Term Evolution) networks.  As the specifications mature, we
   will provide the updates to the LTE architecture.

2.1.  Building blocks of 4G and 5G networks

   The major functional components of an LTE network are shown in
   Figure 2 and include user equipment (UE) like smartphones or tablets,
   the LTE radio unit named enhanced NodeB (eNB), the serving gateway
   (S-GW) which together with the mobility management entity (MME) takes
   care of mobility and the packet gateway (P-GW), which finally
   terminates the actual mobile service.  These elements are described
   in detail in [ts-23-401].  Other important components are the home
   subscriber system (HSS), the Policy and Charging Rule Function (PCRF)
   and the optional components: the Traffic Detection Function (TDF) and
   the Traffic Steering Support Function (TSSF), which are described in
   [ts-23-203].  The P-GW interface towards the SGi-LAN is called the
   SGi-interface, which is described in [ts-29-061].  The TDF resides on
   this interface.  Finally, the SGi-LAN is the home of service function
   chains (SFC), which are not standardized by 3GPP.

Aranda Gutierrez, et al. Expires October 6, 2016                [Page 5]
Internet-Draft  SFC Dataplane Elements in Mobile Networks     April 2016

   +--------------------------------------------+
   | Control Plane (C)      [HSS]               |  [OTT Appl. Platform]
   |                          |                 |             |
   |               +--------[MME]       [PCRF]--+--------+ Internet
   |               |          |            |    |        |    |
   |  [UE-C] -- [eNB-C] == [S-GW-C] == [P-GW-C] |        |    |
   +=====|=========|==========|============|====+  +-----+----+-------+
   |     |         |          |            |    |  |     |    |       |
   |  [UE-U] -- [eNB-U] == [S-GW-U] == [P-GW-U]-+--+----[SGi-LAN]     |
   |                                            |  |        |         |
   |                                            |  |        |         |
   |                                            |  | [Appl. Platform] |
   |                                            |  |                  |
   | User Plane (U)                             |  |                  |
   +--------------------------------------------+  +------------------+

                          Source [SFC-Mobile-UC]

   Figure 1: End to end context including all major components of an LTE
                                 network.

   Service Functions handle session flows between mobile user equipment
   and application platforms.  Control plane metadata supporting policy
   based traffic handling may be linked to individual service functions.
   In 5G networks, we expect the packet gateway (P-GW) to loose its
   central position and be integrated with functions in the RAN.  Radio
   Resource Control (RRC) in 5G network will be integrated into the
   Control Plane environment.

2.1.1.  Classification schemes for 5G networks

   TBD: We expect classification schemes for 5G networks to evolve as
   the standards appear.

2.2.  Control plane considerations

   TBD: We except the RRC to be integrated with the SFC Control plane in
   5G.

2.3.  Operator requirements

   4G mobile operators use service function chains to enable and
   optimize service delivery, offer network related customer services,
   optimize network behavior or protect networks against attacks and
   ensure privacy.  Service function chains are essential to their
   business.  Without these, mobile operators are not able to deliver

Aranda Gutierrez, et al. Expires October 6, 2016                [Page 6]
Internet-Draft  SFC Dataplane Elements in Mobile Networks     April 2016

   the necessary and contracted Quality of Experience (QoE) or even
   certain products to their customers.

   As set forth by the 5G-PPP [5GPPP], the evolution of the
   infrastructure towards 5G should enable the following features in the
   mobile environment:

   o  Providing 1000 times higher wireless area capacity

   o  Saving up to 90% of energy per service provided

   o  Reducing the average service creation time cycle from 90 hours to
      90 minutes

   o  Facilitating very dense deployments of wireless communication
      links to connect over 7 trillion wireless

   To meet these additional requirements, operators will need to make an
   extensive use of service chains and to extend their scope to
   functions in the Radio Access Network.

3.  New concepts for network virtualization

   Recently, mobile networks showed a clear trends towards
   virtualisation and softwarization.  Introducing them in the
   architecture of future 5G networks calls for the application of new
   networking concepts, like:

   o  The support for dynamical allocation of Network Functions (NFs) in
      network nodes

   o  The orchestration of Virtual Network Functions (VNFs) according to
      the requirements of the implemented service

   These concepts should be taken as fundamental principles for the
   design of the future 5G architecture.  In the next sections, we
   present some technical solutions that build upon them.

3.1.  Decomposition and Allocation of VNF

   The current 3GPP LTE mobile network architecture defines specific
   units that execute a well-defined set of functions.  This allocation
   is static and determined by the logical architecture of the deployed
   network.  For instance, radio functions are executed in the base
   stations, while mobility functions are located towards the core of
   the network.  However, according to the guidelines described above,
   the location process should depend on:

Aranda Gutierrez, et al. Expires October 6, 2016                [Page 7]
Internet-Draft  SFC Dataplane Elements in Mobile Networks     April 2016

   o  the specific requirements of the implemented service,

   o  the radio characteristics,

   o  the transport network capacity.

   The goal of new 5G architectures is to enable different
   instantiations of the protocol stack.  Then each of these instances
   can be physically located into different entities of the network:
   near the transmission point or in centralised data centers.  Network
   Functions should hence not be statically located, but their placement
   should be selected according to different criteria, namely:

   o  The increased utilization and reduced amount of resources
      introduced by centralizing RAN functions,

   o  The technology used in the backhaul,

   o  The capacity available in the backhaul,

   o  The specific requirements of the service in terms of latency,
      bandwidth and reliability, among others.

3.2.  Combining Access and Core

   Traditional architectures force a fixed topological relation between
   network functions, while in a virtualized architecture, as the one
   proposed above, these constraints are relaxed.  This difference is
   especially highlighted for access and core network functions.  While
   in a traditional architecture, these functions were usually executed
   in different parts of the network (e.g., the scheduler in the base
   station and a firewall in the centre of the network), a virtualised
   architecture blends the boundaries between access and core functions:
   their final location is decided on a functional basis.  For instance,
   services with strict latency requirements may be located close to the
   transmission points, while services that can exploit centralisation
   may be located in the core data centre.  The application of this
   concept may end up with access and core functions sharing the same
   network location.  This fact enables possible improvements, as
   detailed in the following example.  Currently, mobility and
   scheduling decisions are taken separately.  The mobility-related
   network functions are traditionally located in the core network and
   their decisions are taken before scheduling ones, which are taken
   subsequently, in the access network.  It is important to note that a
   decision about mobility cannot be modified at the scheduling level.
   With a fully virtualised architecture, the mobility and scheduler
   network functions may be co-located in the same network node,
   enabling a possible joint-optimization between mobility and

Aranda Gutierrez, et al. Expires October 6, 2016                [Page 8]
Internet-Draft  SFC Dataplane Elements in Mobile Networks     April 2016

   scheduling.  However, this is only one example of possible
   optimizations that can be achieved using this kind of approach.  The
   proposed approach reduces high latencies introduced by the
   traditional access-core deployment.  Therefore, further optimisation
   may be introduced as the impact of signalling protocols is reduced.

3.3.  Service-aware orchestration

   In order to achieve the advantages described above, there are some
   challenges that need to be addressed.  As new network softwarization
   techniques allow for the efficient resource sharing across different
   logical network instances on the same physical infrastructure (i.e.,
   one network share per service), different architectures should be
   supported simultaneously.  Moreover, the orchestration decision of
   where to locate a specific network function should be taken by
   considering the peculiarities of each service.  These challenges are
   illustrated by the following examples:

   o  Vehicular communications need low latency and sessionless
      connectivity.  Therefore, almost all the VNFs belonging to this
      service should be located close to the transmission point,
      including those traditionally located in the core network;

   o  Tactile Internet applications require both low latency and session
      continuity.  Therefore, most of the the network functions should
      be located close to the transmission point, but some control plane
      ones should be located in the core network;

   o  Broadband access users do not usually have strict latency
      requirements.  Thus, the network functions related to them may be
      located in the core network, efficiently exploiting the
      multiplexing gain enabled by this kind of deployment.

4.  Security Considerations

   Organizational security policies must apply to ensure the integrity
   of the SFC environment.

   SFC will very likely handle user traffic and user specific
   information in greater detail than the current service environments
   do today.  This is reflected in the considerations of carrying more
   metadata through the service chains and the control systems of the
   service chains.  This metadata will contain sensitive information
   about the user and the environment in which the user is situated.
   This will require proper considerations in the design, implementation
   and operations of such environments to preserve the privacy of the
   user and also the integrity of the provided metadata.

Aranda Gutierrez, et al. Expires October 6, 2016                [Page 9]
Internet-Draft  SFC Dataplane Elements in Mobile Networks     April 2016

5.  IANA Considerations

   This document has no actions for IANA.

6.  Acknowledgements

   This work has been partially performed in the scope of the
   SUPERFLUIDITY project, which has received funding from the European
   Union's Horizon 2020 research and innovation programme under grant
   agreement No.671566 (Research and Innovation Action).  This work has
   also been partially performed in the framework of the H2020-ICT-
   2014-2 project 5G NORMA.  The authors would like to acknowledge the
   contributions of their colleagues.  This information reflects the
   consortium's view, but the consortium is not liable for any use that
   may be made of any of the information contained therein.

7.  References

7.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC6459]  Korhonen, J., Ed., Soininen, J., Patil, B., Savolainen,
              T., Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation
              Partnership Project (3GPP) Evolved Packet System (EPS)",
              RFC 6459, DOI 10.17487/RFC6459, January 2012,
              <http://www.rfc-editor.org/info/rfc6459>.

   [RFC7498]  Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for
              Service Function Chaining", RFC 7498,
              DOI 10.17487/RFC7498, April 2015,
              <http://www.rfc-editor.org/info/rfc7498>.

   [RFC7665]  Halpern, J., Ed. and C. Pignataro, Ed., "Service Function
              Chaining (SFC) Architecture", RFC 7665,
              DOI 10.17487/RFC7665, October 2015,
              <http://www.rfc-editor.org/info/rfc7665>.

7.2.  Informative References

   [I-D.ietf-sfc-use-case-mobility]
              Haeffner, W., Napper, J., Stiemerling, M., Lopez, D., and
              J. Uttaro, "Service Function Chaining Use Cases in Mobile
              Networks", draft-ietf-sfc-use-case-mobility-05 (work in
              progress), October 2015.

Aranda Gutierrez, et al. Expires October 6, 2016               [Page 10]
Internet-Draft  SFC Dataplane Elements in Mobile Networks     April 2016

   [ts-23-003]
              3GPP, ""Numbering, addressing and identification"",  ,
              July 2015.

   [ts-23-203]
              3GPP, "Policy and charging control architecture",
              TS 29.203, July 2015.

   [ts-23-401]
              3GPP, "General Packet Radio Service (GPRS) enhancements
              for Evolved Universal Terrestrial Radio Access Network
              (E-UTRAN) access", 3GPP YS 23.401, July 2015.

   [ts-29-061]
              3GPP, "Interworking between the Public Land Mobile
              Network(PLMN) supporting packet based services and Packet
              Data Networks (PDN)", 3GPP TS 29.061, March 2015.

   [ts-29-212]
              3GPP, "3GPP Evolved Packet System (EPS); Evolved General
              Packet Radio Service (GPRS) Tunneling Protocol for Control
              plane (GTPv2-C); Stage 3", 3GPP TS , July 2015.

   [ts-29-274]
              3GPP, "3GPP Evolved Packet System (EPS); Evolved General
              Packet Radio Service (GPRS) Tunneling Protocol for Control
              plane (GTPv2-C); Stage 3", 3GPP 29.274, December 2013.

   [ts-29-281]
              3GPP, "General Packet Radio System (GPRS) Tunneling
              ProtocolUser Plane (GTPv1-U)", 3GPP TS , January 2015.

   [ts-33-210]
              3GPP, "3G security; Network Domain Security (NDS); IP
              network layer security", 3GPP TS 33.210, December 2012.

7.3.  URIs

   [1] http://www.itu.int/en/ITU-R/study-groups/rsg5/rwp5d/imt-
       2020/Pages/default.aspx

   [2] https://5g-ppp.eu

   [3] http://www.5gforum.org/#!eng/cvb1

   [4] http://www.imt-2020.cn/en/introduction

   [5] https://5g-ppp.eu

Aranda Gutierrez, et al. Expires October 6, 2016               [Page 11]
Internet-Draft  SFC Dataplane Elements in Mobile Networks     April 2016

Authors' Addresses

   Pedro A. Aranda Gutierrez
   Telefonica, I+D
   Zurbaran, 12
   Madrid  28010
   Spain

   Email: pedroa.aranda@telefonica.com

   Marco Gramaglia
   IMDEA Networks Institute
   Av. Mar Mediterraneo, 22
   Leganes  28911
   Spain

   Email: marco.gramaglia@imdea.org

   Diego R. Lopez
   Telefonica I+D
   Zurbaran, 12
   Madrid  28010
   Spain

   Email: diego@tid.es

   Walter Haeffner
   Vodafone D2 GmbH
   Ferdinand-Braun-Platz 1
   Duesseldorf  40549
   Germany

   Email: walter.haeffner@vodafone.com

Aranda Gutierrez, et al. Expires October 6, 2016               [Page 12]