| SFC | P. Aranda Gutierrez |
| Internet-Draft | TID |
| Intended status: Informational | M. Gramaglia |
| Expires: December 15, 2016 | IMDEA |
| DRL. Lopez | |
| TID | |
| W. Haeffner | |
| Vodafone | |
| June 13, 2016 |
Service Function Chaining Dataplane Elements in Mobile Networks
draft-aranda-sfc-dp-mobile-02
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).
In this draft we provide a non-exhaustive but representative list of service functions in 4G and 5G networks, and explore different scenarios for service-aware orchestration.
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 and different initiatives in Europe, Korea and China to anticipate network elements that will be needed in 5G networks.
We then explore service-aware orchestration scenarios identifying where different network functions con be deployed in a fully virtualised future network, where both the core and the edge provide advanced virtualisation capabilities.
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 December 15, 2016.
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.
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).
Existing mobile networks use cases presented to the working group and the requirement gathering process of the ITU-R IMT 2020 and different initiatives in Europe, Korea and China to anticipate network elements that will be needed in 5G networks allow us to define use cases for this next generation mobile networks. Once on the pillars of them will be service-aware orchestration. We present scenarios identifying where different network functions con be deployed in a fully virtualised future network, where both the core and the edge provide advanced virtualisation capabilities. These scenarios will allow us to derive Service Function Chaining (SFC)-specific requirements.
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 |
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 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.
As set forth by the 5G Infrastructure Public Private Partenrship (5GPPP), the evolution of the infrastructure towards 5G should enable the following features in the mobile environment:
[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.
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.
[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.
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.
+--------------------------------------------+ | 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.
TBD: We expect classification schemes for 5G networks to evolve as the standards appear.
TBD: We except the RRC to be integrated with the SFC Control plane in 5G.
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 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:
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.
Virtualisation and softwarization will be among the key technology introduced in the design of future 5G Network architecture. They allow to decouple the binding between hardware and software components in a flexible way. While used in conjunction with SFC, future mobile network may support the dynamical allocation of Network Functions (NFs) in network nodes and their orchestration according to the requirements of the implemented service. These concepts will be the building blocks of the future 5G architecture. Current efforts in the definition of SFC mostly focus on Core Network functions. We believe that the cloudification of RAN functions will increase the flexiblity needed to support very demanding and heterogeneous services envisioned by future 5G Networks, and hence the definition of the SFC Dataplane elements must also take into account functions once considered monolithically embedded in the eNB. In the next sections, we present some technical solutions that leverage on these novel concepts.
The current 3GPP LTE Mobile Network architecture offers a low flexibility. Even by applying SFC techniques, specific network functions are executed in well-defined units (e.g., eNB and P-GW functions are carried out in dedicated hardware). Moreover, those network equipment are usually physically located in precise locations. This static approach burdens the flexibility needed by future 5G Networks.
Softwarization and Virtualisation techniques allow for the flexible deployment of functions in the network. Therefore, the placement and execution of network functions should not be driven by topological constraints, but rather on QoS ones such as the specific requirements of the implemented service (e.g., latency, bandwidth and reliability, among others), the radio characteristics and the transport network capacity.
This approach enables enables the concurrent execution of different instantiations of the protocol stack in the same nework infrastructure, as envisioned by the network slicing [REF NGMN Description of Network Slicing Concepts] concepts. SFC is set to be a fundamental technology in this framework, allowing the dynamic deployment of different chains across many network slices spanning different cloud infrastructure arrangements. Hence, network functions can be physically located into different zones of the network: near the transmission point (edge cloud) or in centralised data centers (central cloud). The choice on the orchestration of such network functions will hence happen on a per-service basis.
Edge Cloud Central Cloud +--------------------Vehicular Communications----------------------+ | +----+ +----+ +----+ +----+ +----+ | | | DR | | CR | | DC | | CC | | CC | | | +----+ +----+ +----+ +----+ +----+ | +------------------------------------------------------------------+ +--------------------Haptic Internet-------------------------------+ | +----+ +----+ +----+ +----+ | | | DR | | CR | | DC | | CC | | | +----+ +----+ +----+ +----+ | +------------------------------------------------------------------+ +--------------------Internet Access-------------------------------+ | +----+ +----+ +----+ +----+ +----+ | | | DR | | DR | | CR | | DC | | CC | | | +----+ +----+ +----+ +----+ +----+ | +------------------------------------------------------------------+ DR: data plane RAN CR: control plane RAN DC: data plane Core CC: control plane Core
Source [SFC-Mobile-UC]
Figure 2: Service-aware orchestration of network functions.
In order to achieve a service aware orchestration described above, there are some challenges that need to be addressed. They are illustrated by the following examples :
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 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. SFC is expected to play a fundamental role in this picture, allowing the flexible chaining of network functions.
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.
This document has no actions for IANA.
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.
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |
| [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, DOI 10.17487/RFC6459, January 2012. |
| [RFC7498] | Quinn, P. and T. Nadeau, "Problem Statement for Service Function Chaining", RFC 7498, DOI 10.17487/RFC7498, April 2015. |
| [RFC7665] | Halpern, J. and C. Pignataro, "Service Function Chaining (SFC) Architecture", RFC 7665, DOI 10.17487/RFC7665, October 2015. |