Internet DRAFT - draft-aranda-sfc-dp-mobile
draft-aranda-sfc-dp-mobile
SFC P. Aranda Gutierrez
Internet-Draft
Intended status: Experimental M. Gramaglia
Expires: January 2, 2018 UC3M
DRL. Lopez
TID
W. Haeffner
Vodafone
July 01, 2017
Service Function Chaining Dataplane Elements in Mobile Networks
draft-aranda-sfc-dp-mobile-04
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 be possible and
necessary to provide some traffic-specific services near the next
generation base stations where the radio is processed. Thus, service
function chains that currently reside in the infrastructure of the
Network operator (like, e.g. the Expeded Packet Gateway(EPG)) will be
extended 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 [1] and different
initiatives in Europe [2], Korea [3] and China [4] to anticipate
network elements that will be needed in 5G networks.
We then explore service-aware orchestration scenarios identifying
where different network functions can be deployed in a fully
virtualised future network, where both the core and the edge provide
advanced virtualisation capabilities.
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
Aranda Gutierrez, et al. Expires January 2, 2018 [Page 1]
Internet-Draft SFC Dataplane Elements in Mobile Networks July 2017
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 January 2, 2018.
Copyright Notice
Copyright (c) 2017 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 . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology and abbreviations . . . . . . . . . . . . . . 3
1.2. General scope of mobile service chains . . . . . . . . . 4
1.3. Requirements for 5G networks . . . . . . . . . . . . . . 5
1.3.1. Evolution of the end-to-end carrier network . . . . . 5
2. Mobile network overview . . . . . . . . . . . . . . . . . . . 5
2.1. Building blocks of 4G and 5G networks . . . . . . . . . . 6
2.1.1. Classification schemes for 5G networks . . . . . . . 7
2.2. Transport Network Considerations . . . . . . . . . . . . 7
2.3. Control plane considerations . . . . . . . . . . . . . . 7
2.4. Operator requirements . . . . . . . . . . . . . . . . . . 7
3. New concepts for virtualised mobile networks . . . . . . . . 8
3.1. Service-aware orchestration . . . . . . . . . . . . . . . 8
3.2. Combining Access and Core . . . . . . . . . . . . . . . . 10
4. Security Considerations . . . . . . . . . . . . . . . . . . . 10
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.1. Normative References . . . . . . . . . . . . . . . . . . 11
7.2. Informative References . . . . . . . . . . . . . . . . . 12
7.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Aranda Gutierrez, et al. Expires January 2, 2018 [Page 2]
Internet-Draft SFC Dataplane Elements in Mobile Networks July 2017
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction
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.
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].
Aranda Gutierrez, et al. Expires January 2, 2018 [Page 3]
Internet-Draft SFC Dataplane Elements in Mobile Networks July 2017
+-------+-----------------------------------------------------------+
| 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
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 than in the current 3GPP architecture. In this context,
Aranda Gutierrez, et al. Expires January 2, 2018 [Page 4]
Internet-Draft SFC Dataplane Elements in Mobile Networks July 2017
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 Partnership
(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.
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), ii) 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.
Aranda Gutierrez, et al. Expires January 2, 2018 [Page 5]
Internet-Draft SFC Dataplane Elements in Mobile Networks July 2017
2.1. Building blocks of 4G and 5G networks
The major functional components of an LTE network are shown in
Figure 1 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.
Aranda Gutierrez, et al. Expires January 2, 2018 [Page 6]
Internet-Draft SFC Dataplane Elements in Mobile Networks July 2017
2.1.1. Classification schemes for 5G networks
TBD: We expect classification schemes for 5G networks to evolve as
the standards appear.
2.2. Transport Network Considerations
The role of an enhanced SDN controller will become fundamental in the
context of cloudified RAN deployments. RAN functions, e.g. PHY,
Medium Access Control (MAC), RRM, located either at the edge or in
the core network need to be flexibly controlled according to their
functional split. This approach is also envisioned by e.g. 3GPP in
its Rel. 14.
A cRAN functional split takes place independently of other network
management functionalities, the integrated SDN controller manages the
transport network shall
o Jointly optimize RAN and Core network functions by leveraging on
its centralized network control capabilities.
o Steer user flows across different network functions according to
the functional split implemented in the network.
SFC techniques are expected to play a fundamental role in this
scenario.
2.3. Control plane considerations
TBD: We except the RRC to be integrated with the SFC Control plane in
5G.
2.4. 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
the necessary and contracted Quality of Experience (QoE) or even
certain products to their customers.
Operators are forced to high efficiency with respect to cost and
resources in deployment and operation to offer affordable services to
their customers and, as we discussed in Section 1.3, the 5G
Infrastructure Private-Public Partnership [6] has identified a set of
additional requirements as the key differentiators for future
networks. To meet these additional requirements, operators will need
Aranda Gutierrez, et al. Expires January 2, 2018 [Page 7]
Internet-Draft SFC Dataplane Elements in Mobile Networks July 2017
to make an extensive use of service chains and to extend their scope
to functions in the Radio Access Network.
3. New concepts for virtualised mobile networks
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.
3.1. Service-aware orchestration
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 the concurrent execution of different
instantiations of the protocol stack in the same nework
infrastructure, as envisioned by the network slicing 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
Aranda Gutierrez, et al. Expires January 2, 2018 [Page 8]
Internet-Draft SFC Dataplane Elements in Mobile Networks July 2017
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 :
o Vehicular communications need low latency and sessionless
connectivity. Therefore, almost all the NFs belonging to this
service should be located close to the transmission point,
including those traditionally located in the core network;
o Haptic Internet applications require both low latency and session
continuity. Therefore, most of the network functions should be
located close to the transmission point, but some control plane
ones should be located in the core network;
o Internet 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.
Aranda Gutierrez, et al. Expires January 2, 2018 [Page 9]
Internet-Draft SFC Dataplane Elements in Mobile Networks July 2017
3.2. Combining Access and Core
Traditional architectures force a fixed topological relation between
network functions, while in a virtualised 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 are 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-optimisation between
mobility and scheduling.
However, this is only one example of possible optimisations that can
be achieved using this kind of approach. The proposed approach
reduces high latencies introduced by the traditionally separated
deployment of access and core domains. 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.
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
Aranda Gutierrez, et al. Expires January 2, 2018 [Page 10]
Internet-Draft SFC Dataplane Elements in Mobile Networks July 2017
and operations of such environments to preserve the privacy of the
user and also the integrity of the provided metadata.
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>.
Aranda Gutierrez, et al. Expires January 2, 2018 [Page 11]
Internet-Draft SFC Dataplane Elements in Mobile Networks July 2017
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.
[fiveg] "The 5G Infrastructure Public Private Partnership",
<https://5g-ppp.eu/>.
[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.
Aranda Gutierrez, et al. Expires January 2, 2018 [Page 12]
Internet-Draft SFC Dataplane Elements in Mobile Networks July 2017
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
[6] fiveg
Authors' Addresses
Pedro A. Aranda Gutierrez
Email: paaguti@gmail.com
Marco Gramaglia
Universidad Carlos III de Madrid
Av. Universidad, 30
Leganes 28911
Spain
Email: mgramagl@it.uc3m.es
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 January 2, 2018 [Page 13]
