One document matched: draft-ietf-sfc-use-case-mobility-04.xml
<?xml version='1.0' ?>
<!DOCTYPE rfc SYSTEM 'rfc2629.dtd' [
<!ENTITY rfc2119 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY rfc6459 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6459.xml'>
<!ENTITY rfc6733 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6733.xml'>
<!ENTITY rfc7498 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.7498.xml'>
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="3"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<!--
<!ENTITY ts23003 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml5/reference.3GPP.23.003.xml'>
<!ENTITY ts23203 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml5/reference.3GPP.23.203.xml'>
<!ENTITY ts23401 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml5/reference.3GPP.23.401.xml'>
<!ENTITY ts29601 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml5/reference.3GPP.29.061.xml'>
<!ENTITY ts29274 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml5/reference.3GPP.29.274.xml'>
<!ENTITY ts29281 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml5/reference.3GPP.29.281.xml'>
<!ENTITY ts29212 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml5/reference.3GPP.29.212s.xml'>
-->
<rfc category="info" ipr='trust200902' docName='draft-ietf-sfc-use-case-mobility-04'>
<front>
<title abbrev='SFC Use Cases in Mobility'>Service Function Chaining Use Cases in Mobile Networks</title>
<author initials='W.' surname='Haeffner'
fullname='Walter Haeffner'>
<organization>Vodafone</organization>
<address>
<postal>
<street>Vodafone D2 GmbH</street>
<street>Ferdinand-Braun-Platz 1</street>
<city>Duesseldorf</city>
<code>40549</code>
<country>DE</country>
</postal>
<phone>+49 (0)172 663 7184</phone>
<email>walter.haeffner@vodafone.com</email>
</address>
</author>
<author initials='J.' surname='Napper'
fullname='Jeffrey Napper'>
<organization>Cisco Systems</organization>
<address>
<postal>
<street>Cisco Systems, Inc.</street>
<street>Haarlerbergweg 17-19</street>
<city>Amsterdam</city>
<code>1101 CH</code>
<country>NL</country>
</postal>
<email>jenapper@cisco.com</email>
</address>
</author>
<author initials='M.' surname='Stiemerling'
fullname='Martin Stiemerling'>
<organization>NEC</organization>
<address>
<postal>
<street>NEC Europe Ltd.</street>
<street>Kurfuersten-Anlage 36</street>
<city>Heidelberg</city>
<code>69181</code>
<country>DE</country>
</postal>
<email>mls.ietf@gmail.com</email>
</address>
</author>
<author fullname="Diego R. Lopez" initials="D. R." surname="Lopez">
<organization>Telefonica I+D</organization>
<address>
<postal>
<street>Don Ramon de la Cruz, 82</street>
<city>Madrid</city>
<region></region>
<code>28006</code>
<country>ES</country>
</postal>
<phone>+34 913 129 041</phone>
<email>diego@tid.es</email>
</address>
</author>
<author fullname="Jim Uttaro" initials="J." surname="Uttaro">
<organization>AT&T</organization>
<address>
<postal>
<street>200 South Laurel Ave</street>
<city>Middletown</city>
<region>NJ</region>
<code>07748</code>
<country>US</country>
</postal>
<email>uttaro@att.com</email>
</address>
</author>
<date day='19' month='July' year='2015' />
<area>Routing</area>
<workgroup>Service Function Chaining</workgroup>
<keyword>Internet-Draft</keyword>
<abstract>
<t>This document provides some exemplary use cases for service
function chaining in mobile service provider networks. The
objective of this draft is not to cover all conceivable service
chains in detail. Rather, the intention is to localize and explain
the application domain of service chaining within mobile networks
as far as it is required to complement the problem statement <xref target='RFC7498' /> and
architecture framework <xref target='ietf-sfc-arch' /> of the working group.</t>
<t>Service function chains typically reside in a LAN segment which
links the mobile access network to the actual application platforms
located in the carrier’s datacenters or somewhere else in the
Internet. Service function chains (SFC) ensure a fair distribution of
network resources according to agreed service policies, enhance the
performance of service delivery or take care of security and privacy.
SFCs may also include Value Added Services (VAS). Commonly, SFCs are
typical middle box based services.</t>
<t>General
considerations and specific use cases are presented in this
document to demonstrate the different technical requirements of
these goals for service function chaining in mobile service
provider networks.</t>
<t>The specification of service function chaining for mobile
networks must take into account an interaction between service
function chains and the 3GPP Policy and Charging Control (PCC)
environment.</t>
</abstract>
<note title='Requirements Language'>
<t>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
<xref target='RFC2119' />.</t>
</note>
</front>
<middle>
<section anchor='sec_intro' title='Introduction'>
<section title='Terminology and abbreviations'>
<t>Much of the terminology used in this document has been
defined by the 3rd Generation Partnership Project (3GPP), which
defines standards for mobile service provider networks.
Although a few terms are defined here for convenience, further
terms can be found in <xref target='RFC6459' />.
<list style='hanging'>
<t hangText="UE">User equipment like tablets or
smartphones</t>
<t hangText="eNB">enhanced NodeB, radio access part
of the LTE system</t>
<t hangText="S-GW">Serving Gateway, primary
function is user plane mobility</t>
<t hangText="P-GW">Packet Gateway, actual service creation point,
terminates 3GPP mobile network, interface to Packet
Data Networks (PDN)</t>
<t hangText="HSS">Home Subscriber Server (control
plane element)</t>
<t hangText="MME">Mobility Management Entity (control
plane element)</t>
<t hangText="GTP">GPRS (General Packet Radio Service)
Tunnel Protocol</t>
<t hangText="S-IP">Source IP address</t>
<t hangText="D-IP">Destination IP address</t>
<t hangText="IMSI">International Mobile Subscriber
Identity that identifies a mobile subscriber</t>
<t hangText="(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</t>
<t hangText="PCRF">3GPP standardized Policy and Charging
Rules Function</t>
<t hangText="PCEF">Policy and Charging Enforcement Function</t>
<t hangText="IDS">Intrusion Detection System</t>
<t hangText="FW">Firewall</t>
<t hangText="ACL">Access Control List</t>
<t hangText="PEP">Performance Enhancement Proxy</t>
<t hangText="IMS">IP Multimedia Subsystem</t>
<t hangText="LI">Lawful Interception</t>
</list>
</t>
</section>
<section title='General scope of mobile service chains'>
<t>Mobile access networks terminate at a mobile service creation
point (called Packet Gateway) typically located at the edge of an
operator IP backbone. From the user equipment (UE) up to the
Packet Gateway (P-GW) everything is fully standardized by the
3rd Generation Partnership Project (3GPP) e.g., in <xref target='TS.23.401' />. 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 specifically the P-GW, and an application platform, but will be forced
to pass a set of service functions. Those application platforms are, for
instance, a web server environment, a video platform, a social networking platform or some
other multimedia platform. Network operators use these service functions to
differentiate their services to their subscribers. Service
function chaining is thus integral to the business model of
operators.</t>
<t>Important use case classes for service function chains
generally include:
<list style='symbols'>
<t>functions to protect the carrier network and the privacy
of its users(IDS, FW, ACL, encryption, decryption,
etc.),</t>
<t>functions that ensure the contracted quality of
experience using e.g., performance enhancement proxies
(PEP) like video optimizers, TCP optimizers or functions
guaranteeing fair service delivery built upon policy based
QoS mechanisms,</t>
<t>functions like HTTP header enrichment that may be used to
identify and charge subscribers real time,</t>
<t>functions like Carrier Grade NAT (CG-NAT) and NAPT, which are required solely for
technical reasons, and</t>
<t>functions like parental control or malware detection that
may be a cost option of a service offer.</t>
</list>
</t>
</section>
<section title='General structure of end-to-end carrier networks'>
<t>Although this memo is focused on the Service Function Chaining use cases for mobile carrier networks, such as 3GPP-based ones, a number of other, different carrier networks exists that share similarities in the structure of the access networks and the service functions with mobile networks.</t>
<t><xref target='fig_carrier_net' /> shows a simplified schematic view of 4 different access service networks to indicate similarities with respect to Service Functions and their Chaining.</t>
<t>These service networks consist of access-specific user equipment, a dedicated access network, a related service creation point and finally a (LAN) infrastructure hosting Service Functions which eventually interconnect to application platforms in the Internet or in the carrier’s own datacenter (DC).
From top to down, there is a 3GPP mobile network terminating at the P-GW, an xDSL network with its PPP tunnels terminating at a BNG (Broadband Network Gateway), a FTTH network terminating at an OLT (Optical Line Terminal) and finally a CATV (cable TV) network terminating at a CMTS (Cable Modem Termination System).</t>
<figure anchor='fig_carrier_net' title='Various end-to-end carrier networks and service functions sorted into categories 1, 2 and 3.'>
<artwork>
Access Service Functions
Services +---------------------------+
+--+ *~~~~~~~* +-----+ |+--1---+ +--2---+ +--3---+|| +---------+
|UE|--| 3GGP |---| P-GW|--|| NAT | | MWD | | TCP || |Internal |
+--+ *~~~~~~~* +-----+ || . | | . | | Opt. ||-|Appl. |
|| FW | | Par. | | . || |Platforms|
+--+ *~~~~~~~* +-----+ || . | | Ctrl | | Video || |(e.g.IMS)|
|UE|--| xDSL |---| BNG |--|| LB | | . | | Opt. || +---------+
+--+ *~~~~~~~* +-----+ || . | | LI | | . ||
|| DPI | | . | | Head. ||
+--+ *~~~~~~~* +-----+ || . | | . | | Enr. || +---------+
|UE|--| FTTH |---| OLT |--|| . | | | | . || | |
+--+ *~~~~~~~* +-----+ || | | | | . || | |
|| | | | | ||-|Internet |
+--+ *~~~~~~~* +-----+ || | | | | || | |
|UE|--| CATV |---| CMTS|--|| | | | | || | |
+--+ *~~~~~~~* +-----+ |+------+ +------+ +-------+| +---------+
+---------------------------+
</artwork>
</figure>
<t>Category 1 of service functions like NAT or DPI may be used by all of these service networks mainly just (but not exclusively) for technical reasons. The same is true for category 2, Value Added Services (VAS) like parental control, malware detection and elimination (MWD) or Lawful Interception (LI). TCP optimization is basically seen in mobile networks only. The same may be true for video optimizers or HTTP header enrichment; i.e., category 3 as a rule mainly belongs to mobile networks only.</t>
<t>In our view, 3GPP-based mobile networks seem to have the largest demand for service functions and service function chains. Service Function Chains used in other access networks are very likely a subset of what one can expect in 3GPP-based mobile networks.</t>
<t>Typical data center use cases are described in <xref target='ietf-sfc-dc-use-cases' />. Some technical aspects for the handling of long-lived flows are discussed in <xref target='ietf-sfc-long-lived-flow-use-cases' />.</t>
</section>
</section>
<section title='Mobile network overview'>
<t>For simplicity we only describe service function chaining in the
context of LTE (Long Term Evolution) networks. But indeed our
service chaining model also applies to earlier generations of
mobile networks, such as purely UMTS-based mobile networks.</t>
<section title='Building blocks of 3GPP mobile LTE networks'>
<t>The major functional components of an LTE network are shown in
<xref target='fig_lte_net' /> 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 <xref target='TS.23.401' />. Other important components are the home subscriber
system (HSS) and the policy and charging rule function (PCRF), which are described in <xref target='TS.23.203' />.
The P-GW interface towards the SGi-LAN is called the SGi-interface, which is described in <xref target='TS.29.061' />.
Finally, the SGi-LAN is the home of service function chains
(SFC), which are not standardized by 3GPP.</t>
<figure anchor='fig_lte_net' title='End to end context including all major components of an LTE network. The actual 3GPP mobile network includes the elements from the user equipment [UE] to the packet gateway [P-GW]. Labels ending with –C denote control plane functionality and ending with –U user plane functionality, respectively.'>
<artwork>
+--------------------------------------------+
| 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) | | |
+--------------------------------------------+ +------------------+
|<---------- 3GPP Mobile Network -------->| |<-- IP Backbone ->|
</artwork>
</figure>
<t>The radio-based IP traffic between the UE and the eNB is
encrypted according to 3GPP standards. Between eNB, S-GW and P-GW
user IP packets are
encapsulated in 3GPP-specific tunnels. In some mobile carrier
networks the 3GPP-specific tunnels between eNB and S-GW are
even additionally IPSec-encrypted. More precisely, IPSec
originates/terminates at the eNB and on the other side at an
IPSec-GW often placed just in front of the S-GW. For more details see
<xref target='TS.29.281' />, <xref target='TS.29.274' />
and <xref target='TS.33.210' />.</t>
<t>Service function chains act on user plane IP traffic only.
But the way these act on user traffic may depend on subscriber,
service or network specific control plane metadata (see <xref target='sec_class_schemes' /> for a discussion of metadata in the context of this document).</t>
</section>
<section title='Overview of mobile service chains'>
<t>The original user IP packet, including the Source-IP-Address
(S-IP) of the UE and the Destination-IP-Address (D-IP) of the
addressed application platform (or any host in the Internet in general), leaves the Packet Gateway
from the mobile network via the so-called Gi-interface (3G
service, e.g., UMTS), respectively SGi-interface (4G service,
e.g., LTE). Between this (S)Gi-interface and the actual
application platform the user generated upstream IP packets and
the corresponding downstream IP packets are typically forced to
pass an ordered set of service functions, loosely called a
Service Function Chain (SFC).</t>
<t>The set of all available service
functions (physical or virtualized) which can be used to
establish different Service Function Chains for different services is
often called a Gi-LAN for 2G/3G services and SGi-LAN for 4G
services.</t>
<t>The (S)Gi-interface towards the (S)Gi-LAN itself is discussed
in <xref target='TS.29.061' />, but service function
chaining is not specified by 3GPP. A study on typical exemplary SFC
use cases and potential requirements has been performed by 3GPP
recently <xref target='TR.22.808' />.</t>
<t>The (S)Gi-LAN service functions can use subscriber and
service related metadata delivered from the mobile control
plane, such as the PCRF, or from the user plane, e.g., via HTTP
Header Enrichment to process the flows according to
service related policies. Some service functions may even use
network performance data describing the actual momentary state
of a network segment.</t>
<t>If a network operator utilizes HTTP Header Enrichment, care must be taken that privacy is ensured by some mechanism especially when IP service flows leave the operator's network towards a third party (see <xref target='sec_he_security' />).</t>
<t>In short, the (S)Gi-LAN service area is presently used by
mobile service providers to differentiate their services to
their subscribers and reflect the business model of mobile
operators.</t>
<t>For different applications (e.g., Appl. 1,2,3) upstream and
downstream user plane IP flows will be forced to pass a
sequence of service functions which is called a Service Function Chain
specific to a given application. In the simple example sketched
in <xref target='fig_sfc_topo' />, the service chains for applications 1, 2 and 3 may
be just classified by a unique interface-ID of the egress P-GW
interfaces where the service chains for application 1, 2 and 3
are attached.</t>
<figure anchor='fig_sfc_topo' title='Typical service chain topology.'>
<artwork>
+------------------------------------------------------------------+
| Control Plane Environment [HSS] [MME] [PCRF] [others] |
+------------------------------------------------|-----------------+
+--------------------+
+---------------------------|--------------------|-----------------+
| User Plane Environment | | |
| | /------(S)Gi-LAN --+-----\ |
| | | | |
| | | +---[SF1]-[SF3]–[SF5]---[Appl. 1] |
| | | / | |
| [UE]---[eNB]===[S-GW]===[P-GW]-----[SF2]–[SF4]–[SF6]--------+ |
| | \ | | |
| | +---[SF7]–[SF8]–[SF9]-----+ | |
| | | | | |
| \------------------------/ | | |
| | | |
+----------------------------------------------------------|--|----+
| |
OTT Internet Applications
| |
[Appl. 2] [Appl. 3]
</artwork>
</figure>
<t>Service functions typically observe, alter or even terminate
and re-establish application session flows between mobile user
equipment and application platforms. Control plane metadata supporting policy based traffic handling
may be linked to individual service functions SFn. Because in
<xref target='fig_sfc_topo' /> the P-GW classifies service chains, we consider the
P-GW as a component of the service chaining environment. However,
more sophisticated classification schemes are possible and discussed later.</t>
<t>Care must be taken in classifying and directing flows in different directions (upstream versus downstream) or different flows from the same subscriber when Service Functions observe or alter session flows. Such functions can maintain local state that is necessary to the correct functioning of session flows or to enforcing the policies of the service provider (e.g., fair-use policies). Such stateful service functions can require steering both upstream and downstream directions of a flow through a single service function instance (e.g., from a set of identical service function instances deployed for scale) or for steering all flows with a common criteria (e.g., belonging to the same subscriber) through such a single service function instance.</t>
</section>
<section anchor='sec_common_class' title='The most common classification scheme'>
<t>Mobile user equipment like smartphones, tablets or other
mobile devices use Access Point Names (APNs) to address
a service network or service platform. APNs are DNS host names
comparable to FQDN (Fully Qualified Domain Name) host names. While an FQDN refers to an
Internet IP address, an APN (loosely speaking) specifies a P-GW
IP address. These APNs are used to distinguish certain user
groups and their traffic, e.g., there can be an APN for a
mobile service offered to the general public while enterprise
customers get their own APN. For APN details see <xref target='TS.23.003' />.</t>
<t>Operators often associate a designated Virtual LAN ID (VLAN-ID) with an APN. A
VLAN-ID n then may classify the service function chain n (SFC
n) related to an application platform n (Appl. n), as shown in the following <xref target='fig_assoc_chain' />.</t>
<figure anchor='fig_assoc_chain' title='Association of a service chain to an application platform.'>
<artwork>
+----------+
| |
| IF-1 O [APN 1 => VLAN-ID 1] ---- [SFC 1] ---- [Appl. 1]
| |
=====| P-GW O . . . .
| |
| IF-n O [APN n => VLAN-ID n] ---- [SFC n] ---- [Appl. n]
| |
+----------+
</artwork>
</figure>
<t>Examples for an APN are, e.g.:</t>
<texttable anchor='table_apn_vf' title='Example APN for Vodafone Germany'>
<ttcol align='left' /> <ttcol align='left' />
<c>APN:</c> <c>web.vodafone.de</c>
<c>User Name:</c> <c>not required</c>
<c>Password:</c> <c>not required</c>
</texttable>
<texttable anchor='table_apn_dt' title='Example APN for Deutsche Telekom/T-Mobile'>
<ttcol align='left' /> <ttcol align='left' />
<c>APN:</c> <c>internet.telekom</c>
<c>User Name:</c> <c>t-mobile</c>
<c>Password:</c> <c>tm</c>
</texttable>
</section>
<section title='More sophisticated classification schemes' anchor='sec_class_schemes'>
<t>More sophisticated classifications are feasible using metadata that is UE
related, subscriber and service related, as well as network
related metadata. Typical metadata and their sources are:
<list style='hanging'>
<t hangText="UE:">terminal type (e.g., vendor), IMSI (country, carrier, user)</t>
<t hangText="GTP tunnel endpoint:">eNB-Identifier, time, and many more</t>
<t hangText="PCRF:">subscriber info, APN (service name), QoS, policy rules</t>
</list>
</t>
<t>Mobile operator defined subscriber, service or network
specific policies are typically encoded in the 3GPP-based
Policy and Charging Rules Function (PCRF), see <xref target='TS.23.203' />. For
instance, a PCRF may encode the rules that apply to pre-paid
and post-paid users, users with a classification of gold,
silver, or bronze, or even as detailed as describing rules that
apply to “gold users, wishing to download a video file, while
these subscribers are subjected to a fair-usage policy”. It is
up to the mobile service providers to encode the precise
mappings between its subscriber classes and the associated
service chains.</t>
<t>The Traffic Detection Function (TDF)
is part of the 3GPP PCC (Policy and Charging Control Architecture,
<xref target='TS.23.203' />). Such a TDF inspects the user
traffic after leaving the P-GW function (see <xref target='fig_assoc_chain' />). The TDF can be
used to classify traffic originating from an APN into more
detailed services. This could be used to classify traffic into
different Service Functions.</t>
<figure anchor='fig_tdf' title='3GPP Traffic Detection Function (TDF) for classification. The Policy and Charging Enforcement Function (PCEF) enforces policies received from the PCRF and, in the other direction, provides the PCRF with subscriber and access information via Gx interface.'>
<artwork>
+-------------------------+
| PCRF |
+----+--------------+-----+
| |
Gx-IF Sd-IF
| |
+----+-----+ +----+-----+
==========O [PCEF] | | O--------[SFC 1] ---- [Appl. 1]
| | | O--------[SFC 2] ---- [Appl. 2]
==========O P-GW O-–-O [TDF] O--------[SFC 3] ---- [Appl. 3]
| | | O--------[SFC 4] ---- [Appl. 4]
==========O | | O--------[SFC n] ---- [Appl. n]
+----------+ +----------+
* *
3GPP Bearer SGi SGi
</artwork>
</figure>
<t>The TDF will typically observe the traffic on all protocol layers. On application flow start and stop, the TDF provides feedback to the PCRF for further actions to be taken on a particular flow. The PCRF can request that the TDF apply application and detection controls to application flows including charging and usage monitoring. The TDF can also act without any interaction with the PCRF taking care of gating (firewalling), traffic redirection, bandwidth management or charging.</t>
<t>In general, there are many possibilities to specify classification in mobile networks. 3GPP considers three approaches <xref target='TR.23.718' />:
<list style='symbols'>
<t>Classification in the P-GW using Gx interface</t>
<t>Classification by a stand-alone classifier using Sd interface</t>
<t>Dual Classifier solution; A Traffic Classifier Function (TCF)
within the P-GW for upstream and a downstream TCF (dTCF)for
downstream traffic supported by a St interface.</t>
</list>
</t>
</section>
</section>
<section title='Example use cases specific to mobile networks'>
<t>HTTP via TCP port 80 (or TCP port 443 for HTTPS) is by
far the most common Internet traffic class. Therefore, we discuss two
typical examples of an associated service function chaining model
in some more detail.</t>
<t>The models presented below are simplified compared to real life
service function chain implementations because we do not discuss
differentiated traffic handling based on different subscriber-specific service level agreements and price plans or even actual network load conditions.</t>
<section anchor='sec_svc_chain_http' title='Service chain model for Internet HTTP services'>
<t>With the increase of Internet traffic in mobile networks,
mobile operators have started to introduce Performance
Enhancement Proxies (PEPs) to optimize network resource
utilization. PEPs are more or less integrated platforms that
ensure the best possible Quality of Experience (QoE). Their
service functions include but are not limited to Deep Packet
Inspection (DPI), web and video optimizations, subscriber and
service policy controlled dynamic network adaption, analytics
and management support.</t>
<t>A simple service function chain model for mobile Internet
upstream and downstream traffic is shown in <xref target='fig_sfc_http' /> below. The
function chain includes Load Balancers (LB), which split HTTP
over TCP port 80 away from the rest of the Internet traffic.
Beside basic web content, this traffic class includes more and
more video. To act on this traffic type we force this traffic
to pass Performance Enhancement Proxies (PEPs). The firewall function
(FW) protects the carrier network from the outside and Network
Address Translation (NAT) maps the private IP address space
dedicated to user equipment to a public IP address.</t>
<figure anchor='fig_sfc_http' title='Service function chain for HTTP traffic over TCP port 80.'>
<artwork>
[Cache]
|
[P-GW]---[LB]-----------[PEP]--[LB]--[FW]---[NAT]---[Internet]
| HTTP:80 |
| |
| |
| non HTTP:80 |
+---------------------+
</artwork>
</figure>
<t>The first application in this Service Chain example caches web content
to help reduce Round Trip Times (RTT) and therefore contributes
to improved web page load times. Optimizing RTT and thereby improving Quality of Experience (QoE) is generally more
important for mobile service providers than reducing Internet
peering costs. Similar arguments hold for cached video content.
We also avoid potential large jitter imported from the Internet.</t>
<t>An
example for non HTTP port 80 traffic in <xref target='fig_sfc_http' /> is UDP-encapsulated IPsec traffic, which is
dedicated to port 10000. Note that in a real environment not
only port 80 but for example additional traffic via port 8080,
25 for SMTP, 110 for POP3 or 143 for IMAP may be forced to pass
a service chain.</t>
<t>A second application is video optimization. Video content
from the Internet may not fit to the size of mobile device
displays or simply would overload the mobile network when used
natively. Therefore mobile operators adapt internet-based video
content to ensure the best QoE.</t>
<t>Video content optimization very often is also an additional
premium-related component in service offers and price
plans.</t>
<figure anchor='fig_pep_video' title='Service functions required for video optimization.'>
<preamble>A typical PEP environment for video optimization consists of three
basic service functions as shown in <xref target='fig_pep_video' />: a steering proxy which is
able to redirect HTTP traffic, a DPI-based controller which
checks for video content and an optimizer which transcodes
videos to an appropriate format on the fly in real time.</preamble>
<artwork>
[PEP for video] ==>> [Steering Proxy]---[DPI Contr.]---[Optimizer]
</artwork>
</figure>
<t>In <xref target='fig_http_call_flow' /> we show one possible way for HTTP flows and their
redirection in some more detail. The intention here is to show
every elementary functional step in a chain as a separate
physical or virtualized item, but this state diagram does not
necessarily reflect every existing vendor-specific proprietary
implementation.</t>
<t>Specifically, the Steering Proxy includes a TCP proxy and an ICAP (Internet Content Adaptation Protocol) client which communicates with an ICAP server residing in the controller function which is supported by a L7 DPI.</t>
<t>The video optimization process acts on the downstream flow only.</t>
<figure anchor='fig_http_call_flow' title='Flow diagram between UE and video optimization PEP.'>
<artwork>
[UE]----[Steering Proxy]----[DPI Contr.]----[Optimizer]----[Content]
|-- HTTP GET ->|-------------- HTTP GET ----------------------->|
|<------------- HTTP Response -------------------|
|-- Is it Video? ->|
|<-- Video found --|
|<--- HTTP ----|
Redirect
|-- HTTP GET ->|-----HTTP GET ---------------->|
|-- HTTP GET -->|
Video
|<--- HTTP -----|
Response
Orig. Video
{Optimize}
|<------- HTTP Response --------|
Transcoded Video
|-- Is it Video? ->|
|<-- Video found --|
|<--- HTTP ----|
Response
Transcoded Video
</artwork>
</figure>
<t>In such an application scenario one may have reclassification or off-loading on the fly.</t>
<t>Assume a video is streamed within a 4G LTE radio cell. The video optimizer would then apply a transcoding scheme appropriate to the abilities of the 4G network. If one is now leaving the 4G cell and entering a 3G radio cell, the network conditions will most probably become different and the video optimizer has to use another transcoding scheme to keep a certain QoE. This requires that the video optimizer service function is aware of the Radio Access Technology (RAT) in use. One may transfer RAT type from the P-GW (or Gateway GPRS Support Node (GGSN) in case of 3G traffic) via an Authorization, Authentication and Accounting (AAA) Proxy to the service function chain. The RAT information will then be embedded in an appropriate Radius message. Other 3GPP steering mechanisms may apply as well.</t>
<t>If for example the 4G network has sufficient bandwidth, one could also think of another, different use case. The rule could be that only 3G video streams are forced to pass the video optimizer while all 4G video traffic will be bypassed. Bypassing certain Service Functions is also known as off-loading.</t>
<t>Additionally, network utilization information can be used to trigger the behavior of the service function. The degree of video compression applied could depend on the actual current network load.</t>
<t>Last but not least the behavior of the video optimizer service function (or any other service function) could additionally depend on the user-specific service contract (price plan, gold, silver, bronze) or on individual on demand requests.</t>
<section title='Weaknesses of current approaches'>
<t>This use case model highlights the weakness of current service
deployments in the areas of traffic selection, reclassification, and
multi-vendor support. Traffic in this example is classified after the P-GW and
separated into separate flows based on whether it is (in this
example) TCP traffic destined to port 80. This classification could
be done by the load balancer (see <xref target='fig_sfc_http' />) if it initiates the service chain selection, or the traffic can be reclassified
at the load balancer if the traffic is already embedded in a Service Chain
(e.g., when combined with other functions such as the TCP
optimization in the following use case). Multi-vendor support is
needed because every element in the use case can be provided by
a different vendor: load-balancer, HTTP proxy, firewall and NAT.</t>
</section>
</section>
<section title='Service chain for TCP optimization'>
<t>The essential parameters influencing TCP behavior are
latency, packet loss and available throughput.</t>
<t>Content servers are mostly attached to fixed networks. These
are characterized by high bandwidth and low latency. On the other side, Radio Access Networks (RANs) tend to have higher latency, packet loss and congestion.</t>
<t>The fixed network part will typically get a TCP Rx/Tx buffer size different to that on the radio network side because buffer sizes are typically set proportional to the latency (rule of thumb: 2 x latency x bandwidth).</t>
<t>TCP cannot handle such disparate end-to-end situations very well. One way to mitigate this problem is to use split TCP. However, even without congestion, packet losses on the mobile network side may result in time outs and finally cause the content server on the fixed network side to stall.</t>
<t>Therefore mobile operators often use TCP optimization
proxies in the data path. These proxies monitor latency and
throughput real-time and dynamically optimize TCP parameters
for each TCP connection to ensure a better transmission
behavior.</t>
<t>A rudimentary service chain setup for TCP optimization is
shown in <xref target='fig_tcp_opt' />. Examples of non-TCP flows
are UDP/RTP voice or video traffic.</t>
<figure anchor='fig_tcp_opt' title='Optimizing TCP parameterization in a mobile network.'>
<artwork>
[P-GW]---[LB]----------[TCP Opt.]---[LB]---[FW]---[NAT]---[Internet]
| TCP |
| |
| non-TCP |
+--------------------------+
</artwork>
</figure>
<section title='Weaknesses of current approaches'>
<t>This use case highlights weaknesses of current service
deployments in the areas of traffic selection,
reclassification and multi-vendor support as in the
previous use case presented in <xref target='sec_svc_chain_http' />.</t>
</section>
</section>
<section title='HTTP header enrichment in mobile networks'>
<section title='HTTP header enrichment in legacy mobile data networks'>
<t>In legacy mobile networks WAP (Wireless Application Protocol) gateways mediated between traditional mobile phones and the Internet translating HTML web content into a WML (Wireless Markup Language) and vice versa. By functionality, WAP-GWs fit also in the SFC category.</t>
<t>Traditionally WAP-GWs use HTTP header enrichment to insert subscriber related data into WAP and HTTP request headers in real time. These data were (are) used to identify and charge subscribers on third party web sites.</t>
</section>
<section title='HTTP header enrichment in modern mobile data networks'>
<t>Today, in 3G and 4G mobile networks HTTP header enrichment is done by the Gateway GPRS Support Node (GGSN)/P-GW or a dedicated transparent HTTP optimizer as most of the data traffic on a mobile network no longer passes a WAP-GW.</t>
<t>Information typically added to the header includes:
<list style='symbols'>
<t>Charging Characteristics</t>
<t>Charging ID</t>
<t>Subscriber ID</t>
<t>GGSN or PGW IP address</t>
<t>Serving Gateway Support Node (SGSN) or SGW IP address</t>
<t>International Mobile Equipment Identity (IMEI)</t>
<t>International Mobile Subscriber Identity (IMSI)</t>
<t>Mobile Subscriber ISDN Number (MSISDN)</t>
<t>UE IP address</t>
</list>
</t>
</section>
<section title='HTTP header enrichment security condiderations' anchor='sec_he_security'>
<t>In today's networks HTTP header enrichment is commonly used across operator and ISP boundaries. In such cases one must implement security mechanisms, e.g., solutions which are based on a one-time, session-based key exchanged between user equipment and third party over the top (OTT) service platforms.</t>
</section>
</section>
</section>
<section title='Remarks on QoS in mobile networks'>
<t>As indicated in <xref target='fig_sfc_topo' />, service functions may be linked to the
control plane to take care of additional subscriber or service
related metadata. In many cases the source of metadata would be the
PCRF and the link would be a Gx or Diameter-based Sd reference point. Diameter
is specified in <xref target='RFC6733' /> and Gx in <xref target='TS.29.212' />.</t>
<t>Service functions within the (S)Gi-LAN are less focused on the
explicit QoS steering of the actual mobile wireless network. QoS in
mobile networks is based on the 3GPP “Bearer” concept. A Bearer is
the essential traffic separation element enabling traffic
separation according to different QoS settings and represents the
logical transmission path between the User Equipment (UE) and the
Packet Gateway (P-GW).</t>
</section>
<section title='Weaknesses of current implementations'>
<t>In many operator environments every new service introduction can
result in a further dedicated (S)Gi-LAN service chain because
service chaining has been deployed historically in an ad hoc manner.</t>
<t>It typically requires placement of new functions in the operator’s data center, changing the actual wiring to include any new or changed service function, configuration of the functions and network equipment, and finally testing of the new configuration to ensure that everything has been properly setup.</t>
<section title='Granularity of the classification scheme'>
<t>Often the coarse grained classification according to APNs is not
fine enough to uniquely select a service function chain or a
processing scheme within a service function chain required to
support the typical user-, service- or network- related
policies which the operator likes to apply to a specific user
plane flow.</t>
<t>It is very likely that an APN, such as shown in
<xref target='sec_common_class' />, is carrying an extremely diverse set of user
traffic. This can range from HTTP web traffic to real-time
traffic.</t>
</section>
<section title='Service chain implementations'>
<t>In many carrier networks service chain LANs grow
incrementally according to product introductions or
modifications. This very often ends in a mix of static IP
links, policy based routing or individual VRF (Virtual Routing and Forwarding)
implementations, etc. to enforce the required sequence of
service functions. Major weak points seen in many carrier
networks are:
<list style='symbols'>
<t>Very static service chain instances, hard-wired on
the network layer leads to no flexibility with respect to
reusing, adding, and removing service nodes and reprogramming
service chains.</t>
<t>Evolutionary grown “handcrafted” connectivity models
require high complexity to manage or maintain.</t>
<t>Basic implementation paradigm is based on APNs (that
is service types) only, which requires individual injections
of context-related metadata to obtain granularity down to
user/service level.</t>
<t>There is currently no natural (or standardized)
information exchange on network status between services
and the network, complicating management of network
resources based on subscriber profiles.</t>
<t>It is currently practically impossible to implement
an automated service provisioning and delivery
platform.</t>
<t>Scaling up flows or service chains with service or
subscriber related metadata is extremely difficult.</t>
</list>
</t>
</section>
</section>
<section title='Operator requirements'>
<t>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.</t>
<section title='Simplicity of service function chain instantiation'>
<t>Because product development cycles are very fast in mobile
markets, mobile operators are asking for service chaining
environments which allow them to instantly create or modify
service chains in a very flexible and very simple way. The
creation of service chains should be embedded in the business
and operation support layers of the company and on an abstract
functional level, independent of any network underlay. No
knowledge about internetworking technology should be required
at all. The mapping of the functional model of a service chain
onto the actual underlay network should be done by a
provisioning software package similar to that shown in <xref target='fig_sfc_create' />. Details of the architecture
and design are the subject of forthcoming standards and proprietary
implementation details.</t>
<figure anchor='fig_sfc_create' title='Creation and provisioning system for service function chains.'>
<artwork>
+------------------------------------------------------------------+
| Creation of an abstract service function chain |
+------------------------------------------------------------------+
|
V
+------------------------------------------------------------------+
| +----------------------------------------------------+ |
| | Service function chain compiler | |
| +----------------------------------------------------+ |
| | |
| V |
| +----------------------------------------------------+ |
| | Mediation device | |
| +----------------------------------------------------+ |
+------------------------------------------------------------------+
|
V
+------------------------------------------------------------------+
| Physical network underlay |
+------------------------------------------------------------------+
</artwork>
</figure>
<t>Service functions can be physical or virtualized. In the near
future the majority of mobile service functions will typically
reside in the local cloud computing environment of a mobile
core location. Nevertheless, first trials have shown that (virtualized) Service Function interconnects via WAN links require careful latency considerations.</t>
<t>Last but not least, any implementation must take into account that in the migration phase a mixed infrastructure including virtual machines, classical hardware "boxes" and bare metal based systems (i.e., computes without using virtualization) must be supported.</t>
</section>
<section title='Extensions'>
<t>A service function chain should be generalized by a directed
graph where the vertices (nodes) represent an elementary
service function. This model allows branching
conditions at the vertices. Branching in a graph could then be
triggered by typical 3GPP specified mobile metadata (see <xref target='sec_common_class' />) and allow for more sophisticated steering
methods in a service chain. Typically these data will be
injected by the mobile control plane, commonly but not exclusively by the
PCRF via a Diameter-based 3GPP Sd reference point.</t>
<t>Service chain behavior and output should additionally
depend on actual network conditions. For example, the selection
of a video compression format could depend on the actual
load of the mobile network segment a mobile user is attached
to. That is to say that classification of flows may allow very
dynamic inputs while specification of such inputs from a 3GPP
network will need to be done by 3GPP or another standards body.</t>
<t>Although necessary metadata can be obtained from the PCRF, to
avoid Diameter signaling storms in the (S)Gi-LAN,
individual service functions should probably not be attached
individually to the control plane. A mechanism where such metadata
are carried by a metadata header can reduce requests to the PCRF,
provided these extensions do not increase the original payload size too much.</t>
</section>
<section title='Reflections on Metadata'>
<t>At the moment we see just two types of metadata classes. Metadata which are static and related to subscriber and service policies typically reside in the control plane environment and dynamic metadata, which may reflect time and location dependent status somewhere in the network or other service platforms, e.g., load conditions or relevant network technology indicators. It may be useful to have proper interfaces to inject these metadata into the Service Function Chain domain.</t>
<t>Summarized, metadata may by injected into individual Service Chain Functions:
<list style='symbols'>
<t>asynchronously from the control plane environment by means of individual standardized interfaces,</t>
<t>synchronously, piggypacked with the user IP packet:
<list style='symbols'>
<t>by means of a to-be-defined metadata header</t>
<t>or carried with http header enrichments within the user payload.</t>
</list>
</t>
</list>
</t>
</section>
<section title='Delimitations'>
<t>A clear separation between service chaining functionality and
3GPP bearer handling is required. This may be subject of
forthcoming studies.</t>
</section>
</section>
<section title='Security Considerations'>
<t>Organizational security policies must apply to ensure the integrity of the SFC environment.</t>
<t>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.</t>
</section>
<section title='IANA Considerations'>
<t>This document has no actions for IANA.</t>
</section>
<section title='Acknowledgments'>
<t>We thank Peter Bosch, Carlos Correia, Dave Dolson, Linda Dunbar,
Alla Goldner, Wim Hendericks, Dirk von Hugo, Konstantin Livanos, Praveen Muley,
Ron Parker, and Nirav Salot for valuable discussions and contributions.</t>
<t>Thanks also to Takeshi Usui for pointing out the current 3GPP work on traffic classification.</t>
<t>We especially thank Narseo Vallina Rodriguez (ICSI Berkeley University) for multiple discussions on HTTP header extensions and network security. </t>
</section>
</middle>
<back>
<references title='Normative References'>
&rfc2119;
</references>
<references title='Informative References'>
&rfc6459;
&rfc6733;
&rfc7498;
<reference anchor='TR.22.808'>
<front>
<title>Study on Flexible Mobile Service Steering (FMSS)</title>
<author fullname='3GPP' />
<date month='September' year='2014' />
</front>
<seriesInfo name='3GPP TR' value='22.808 13.0.0' />
<format type='HTML' target='http://www.3gpp.org/DynaReport/22808.htm' />
</reference>
<reference anchor='TR.23.718'>
<front>
<title>Architecture Enhancement for Flexible Mobile Service Steering</title>
<author fullname='3GPP' />
<date month='May' year='2015' />
</front>
<seriesInfo name='3GPP TR' value='23.718 v0.4.0 (work in progress)' />
</reference>
<reference anchor='TS.23.003'>
<front>
<title>Numbering, addressing and identification</title>
<author fullname='3GPP' />
<date month='December' year='2013' />
</front>
<seriesInfo name='3GPP TS' value='23.003 12.1.0' />
<format type='HTML' target='http://www.3gpp.org/DynaReport/23003.htm' />
</reference>
<reference anchor='TS.23.203'>
<front>
<title>Policy and charging control architecture</title>
<author fullname='3GPP' />
<date month='December' year='2013' />
</front>
<seriesInfo name='3GPP TS' value='23.203 12.3.0' />
<format type='HTML' target='http://www.3gpp.org/DynaReport/23203.htm' />
</reference>
<reference anchor='TS.23.401'>
<front>
<title>General Packet Radio Service (GPRS) enhancements for
Evolved Universal Terrestrial Radio Access Network
(E-UTRAN) access</title>
<author fullname='3GPP' />
<date month='December' year='2013' />
</front>
<seriesInfo name='3GPP TS' value='23.401 12.3.0' />
<format type='HTML' target='http://www.3gpp.org/DynaReport/23401.htm' />
</reference>
<reference anchor='TS.29.061'>
<front>
<title>Interworking between the Public Land Mobile Network
(PLMN) supporting packet based services and Packet Data
Networks (PDN)</title>
<author fullname='3GPP' />
<date month='December' year='2013' />
</front>
<seriesInfo name='3GPP TS' value='29.061 12.4.0' />
<format type='HTML' target='http://www.3gpp.org/DynaReport/29061.htm' />
</reference>
<reference anchor='TS.29.212'>
<front>
<title>Policy and Charging Control (PCC); Reference points</title>
<author fullname='3GPP' />
<date month='January' year='2015' />
</front>
<seriesInfo name='3GPP TS' value='29.212 13.0.0' />
<format type='HTML' target='http://www.3gpp.org/DynaReport/29212.htm' />
</reference>
<reference anchor='TS.29.274'>
<front>
<title>3GPP Evolved Packet System (EPS); Evolved General Packet Radio Service (GPRS) Tunnelling Protocol for Control plane (GTPv2-C); Stage 3</title>
<author fullname='3GPP' />
<date month='December' year='2013' />
</front>
<seriesInfo name='3GPP TS' value='29.274 12.3.0' />
<format type='HTML' target='http://www.3gpp.org/DynaReport/29274.htm' />
</reference>
<reference anchor='TS.29.281'>
<front>
<title>General Packet Radio System (GPRS) Tunnelling Protocol User Plane (GTPv1-U)</title>
<author fullname='3GPP' />
<date month='March' year='2013' />
</front>
<seriesInfo name='3GPP TS' value='29.281 11.6.0' />
<format type='HTML' target='http://www.3gpp.org/DynaReport/29281.htm' />
</reference>
<reference anchor='TS.33.210'>
<front>
<title>3G security; Network Domain Security (NDS); IP network layer security</title>
<author fullname='3GPP' />
<date month='December' year='2012' />
</front>
<seriesInfo name='3GPP TS' value='33.210 12.2.0' />
<format type='HTML' target='http://www.3gpp.org/DynaReport/33210.htm' />
</reference>
<reference anchor='ietf-sfc-arch'>
<front>
<title>Service Function Chaining (SFC) Architecture</title>
<author surname='Halpern' initials='J.'/>
<author surname='Pignataro' initials='C.'/>
<date month='June' year='2015' />
</front>
<seriesInfo name='I-D' value='draft-ietf-sfc-architecture-09 (work in progress)' />
</reference>
<reference anchor='ietf-sfc-dc-use-cases'>
<front>
<title>Service Function Chaining Use Cases In Data Centers</title>
<author surname='Kumar' initials='S.'/>
<author surname='Tufail' initials='M.'/>
<author surname='Majee' initials='S.'/>
<author surname='Captari' initials='C.'/>
<author surname='Homma' initials='S.'/>
<date month='January' year='2015' />
</front>
<seriesInfo name='I-D' value='draft-ietf-sfc-dc-use-cases-02 (work in progress)' />
</reference>
<reference anchor='ietf-sfc-long-lived-flow-use-cases'>
<front>
<title>SFC Long-lived Flow Use Cases</title>
<author surname='Krishnan' initials='R.'/>
<author surname='Ghanwani' initials='A.'/>
<author surname='Halpern' initials='J.'/>
<author surname='Kini' initials='S.'/>
<author surname='Lopez' initials='D. R.'/>
<date month='February' year='2015' />
</front>
<seriesInfo name='I-D' value='draft-ietf-sfc-long-lived-flow-use-cases-03 (work in progress)' />
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 16:18:05 |