One document matched: draft-haeffner-sfc-use-case-mobility-00.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 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'>
-->
<rfc ipr='trust200902' docName='draft-haeffner-sfc-use-case-mobility-00'>
<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 13-19</street>
<city>Amsterdam</city>
<code>1101 CH</code>
<country>NL</country>
</postal>
<email>jenapper@cisco.com</email>
</address>
</author>
<date day='29' month='January' year='2014' />
<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 and
framework statements 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 ensure a fair distribution of
network resources according to agreed service policies, enhance the
performance of service delivery, take care of security and privacy
or support application and business support platforms. 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>
</abstract>
</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="Device">A physical or virtualized function.</t>
<t hangText="< payload | IP header >">IP packet.</t>
<t hangText="UE">User equipment like tablets or
smartphones.</t>
<t hangText="S-IP">Source IP address.</t>
<t hangText="D-IP">Destination IP address.</t>
<t hangText="IMSI">The International Mobile Subscriber
Identity that identifies a mobile subscriber.</t>
<t hangText="SGi, 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>
</list>
</t>
</section>
<section title='General scope of mobile service chains'>
<t>Mobile access networks terminate at a mobile service creation
point (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 specific 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 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>
</section>
<section title='General scope of mobile service chains'>
<t>Important use cases classes for service function chains
generically include:
<list style='numbers'>
<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 based on 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 CG-NAT/PAT, 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>
<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.</t>
<section title='Building blocks of 3GPP mobile networks'>
<t>The major functional components of a LTE network are shown in
<xref target='fig_lte_net' /> and include user equipment (UE) like smartphones or
tablets, the LTE radio unit named eNB (enhanced NodeB), 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 SGi-interface, which is described in <xref target='TS.29.061' />
and 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='Major components of an LTE network.'>
<preamble>End to end context including all major components of a
LTE network. The actual 3GPP mobile network includes the
elements from the user equipment [UE] to the packet gateway
[P-GW].</preamble>
<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) | | |
+--------------------------------------------+ +--- IP Backbone --+
|<----------- 3GPP Mobile Network ---------->|
</artwork>
</figure>
<t>The radio-based IP traffic between the UE and the eNB is
encrypted according 3GPP standards. Between eNB, S-GW, P-GW
user IP packets as well as control plane 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. For more details see
<xref target='TS.29.281' /> and <xref target='TS.29.274' />.</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.</t>
</section>
<section title='General scope 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 and leaves the Packet Gateway
away 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). The set of all available service
functions (physical or virtualized) which can be used to
establish different service 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.</t>
<t>The (S)Gi-LAN service functions may use subscriber and
service related metadata delivered from mobile control plane
functions like PCRF to process the flows according to service
related policies.</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 and 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 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 an unique interface-ID of the egress P-GW
interfaces where the service chains for application 1, 2 and 3
are attached.</t>
<t>Service functions typically observe, alter or even terminate
and reestablish application session flows between mobile user
equipment and application platforms.</t>
<figure anchor='fig_sfc_topo' title='Typical service chain topology.'>
<preamble>Typical service function
chain topologies as seen in many of today’s mobile networks.
Control plane metadata supporting policy based traffic handling
may be linked to individual service functions SFn. Because in
this example the P-GW classifies service chains we consider the
P-GW being a component of the service chaining environment.</preamble>
<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>
</section>
<section anchor='sec_common_class' title='The most common classification scheme'>
<t>Mobile user equipment like smartphones, tablets or other
mobile devices address use Access Point Names (APNs) to address
a service network or service platform. APNs are DNS host names
and comparable to FQDN host names. While a 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 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).</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:</t>
<texttable anchor='table_apn_vf'>
<preamble>Vodafone Germany:</preamble>
<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'>
<preamble>Deutsche Telekom/T-Mobile:</preamble>
<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>
<t>More sophisticated classifications are feasible using 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., HTC one); IMSI (country, carrier, user);</t>
<t hangText="GTP tunnel endpoint:">eNB-Identifier; time;</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>
</section>
</section>
<section title='Example use cases specific to mobile networks'>
<t>Because HTTP via TCP port 80 (or TCP port 443 for HTTPS) is by
far the most common Internet traffic class, 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 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. 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>
<t>The first application in the service chain caches web content
to help reduce Round Trip Times (RTT) and therefore contribute
to improved web page load times. This is generally more
important for mobile service providers than reducing Internet
peering costs. Similar arguments hold for cached video content.
We avoid potential large jitter imported from the Internet.</t>
<figure anchor='fig_sfc_http' title='Service function chain for HTTP traffic over TCP port 80.'>
<preamble>Service function chain to
control, steer and manipulate HTTP traffic over TCP port 80. An
example for non HTTP:80 traffic is 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.</preamble>
<artwork>
[Cache]
|
[P-GW]---[LB]-----------[PEP]--[LB]--[FW]---[NAT]---[Internet]
| HTTP:80 |
| |
| |
| non HTTP:80 |
+---------------------+
</artwork>
</figure>
<t>A second application is video optimization. Video content
from the Internet may not fit in 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 Quality of Experience.</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>Our PEP environment for video optimization consists of three
basic service functions 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>
<figure anchor='fig_http_call_flow' title='Flow diagram between UE and video optimization PEP.'>
<preamble>In <xref target='fig_http_call_flow' /> we show the detailed 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 must not
necessarily reflect every existing vendor-specific proprietary
implementation.</preamble>
<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>
<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 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
initially if the load balancer can classify the traffic and
initiate service chain selection, or the traffic can be
reclassified at the load balancer if it 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 title='Requirements from use case'>
<t>This use case imposes the following requirements on a
service function chaining (SFC) solution:
<list style='format REQ%d.' counter='Requirements'>
<t>SFC solutions MUST support service
functions that differentially steer traffic.</t>
<t>SFC solutions MUST support service
functions that terminate or originate sessions.</t>
<t>SFC solutions SHOULD allow traffic
to, from, and between service functions that are remote
to the original service chain.</t>
<t>SFC solutions MUST support service
functions that change payload and IP header data of
traffic.</t>
<t>SFC solutions SHOULD allow service
functions to be members of multiple service chains.</t>
<t>SFC solutions SHOULD allow the dynamic adaptation to
changing network and computing loads by adding or
removing edges in the graph.</t>
</list>
</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. Therefore
content servers often experience large TCP window sizes. In
fixed networks, end-to-end TCP window size mismatches do not
have that much negative impact on data flows.</t>
<t>On the other hand, mobile networks show a different behavior.
While the (S)Gi-side of the network typically exhibits low
latency, low packet loss, high bandwidth and minimal
congestion, the Radio Access Network (RAN) tends to have higher
latency, packet loss, and congestion. Therefore mobile devices
normally experience much smaller TCP window sizes.</t>
<t>One way to mitigate these different environments, i.e., the
LAN and the mobile wireless part, is to use split TCP. However,
this leads to the case that the mobile wireless part can
experience a different TCP window size than the fixed LAN
part.</t>
<t>In mobile networks, these TCP window size mismatches may
result in poor end-to-end throughput and bad user
experience.</t>
<t>Therefore mobile operators very 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></t>
<figure anchor='fig_tcp_opt' title='Optimizing TCP parameterization in a mobile network.'>
<preamble>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.</preamble>
<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 4.1.</t>
</section>
<section title='Additional requirements from use case'>
<t>This use case imposes the following additional
requirements on a Service Function Chaining solution.
<list style='format REQ%d.' counter='Requirements'>
<t>SFC solutions MUST support service
functions that can adapt TCP traffic to the local networking needs.</t>
</list>
</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 Diameter-based Gx interface. Diameter
is specified in <xref target='RFC6733' /> and Gx in [3GPP].</t>
<t>Service functions within the SGi/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 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 may
result in a further dedicated (S)Gi-LAN service chain.</t>
<section title='Granularity of the classification scheme'>
<t>Often the coarse grained classification according 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 as example 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 product introductions or product
modifications. This very often ends in a mix of static IP
links, policy based routing or individual VRF
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
network layer leads to no flexibility with respect to
reusing, adding, removing service nodes, and reprogramming
service chains.</t>
<t>High complexity to manage or maintain evolutionary grown
“handcrafted” connectivity models.</t>
<t>Basic implementation paradigm based on APNs (that is
service types) only and</t>
<t>Granularity down to user/service level by individual
injections of context-related metadata.</t>
<t>No natural information exchange on network status
between services and network. This would be fine to
manage finite network resources based on subscriber
profiles more easily.</t>
<t>Practically impossible to implement automated service
provisioning and delivery platform.</t>
<t>Scaling up flows or service chains with service or
subscriber related metadata may not work.</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 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 as shown in <xref target='fig_sfc_create' />. Details of the architecture
and design are 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, the architecture and design should
allow and support also remote service functions if
applicable.</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 this data will be
injected by the mobile control plane, commonly by the
PCRF via a Diameter-based 3GPP Gx interface.</t>
<t>Service chain behavior and output should additionally
depend on actual network conditions. For example, the selection
of a video compression format could dependent on the actual
load of the mobile network segment a mobile user is attached
to.</t>
<t>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 metadata
information is carried by extensions to the user IP packet may
be more appropriate, provided these extensions do not increase the original payload size too much.</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>TBD.</t>
</section>
<section title='IANA Considerations'>
<t>This document has no actions for IANA.</t>
</section>
<section title='Acknowledgments'>
<t>We thank Peter Bosch and Martin Stiemerling for valuable
discussions and contributions.</t>
</section>
</middle>
<back>
<references title='Normative References'>
&rfc2119;
</references>
<references title='Informative References'>
<!--
<reference anchor='ref_sfc_problem_statement'>
<front>
<title>Service Function Chaining Problem Statement</title>
<author initials='P.' surname='Quinn'
fullname='Paul Quinn' role=editor>
<organization>
Cisco Systems, Inc.
</organization>
</author>
<author initials='T.' surname='Nadeau'
fullname='Thomas Nadeau' role=editor>
<organization>
Juniper Networks
</organization>
</author>
<date month='December' year='2013' />
</front>
<seriesInfo name='I-D' value='' />
</reference>
-->
<!--
<reference anchor='ref_sfc_framework'> [draft-boucadair-sfc-framework-00]
<front>
<title>Service Function Chaining: Framework & Architecture</title>
<author initials='M.' surname='Boucadair'
fullname='Mohamed Boucadair' role=editor>
<organization>
France Telecom
</organization>
</author>
<date month='October' year='2013' />
</front>
<seriesInfo name='I-D' value='' />
</reference>
-->
&rfc6459;
&rfc6733;
<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.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>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 12:05:58 |