White Paper
Service Chaining in Carrier
Networks
Prepared by
Gabriel Brown
Senior Analyst, Heavy Reading
www.heavyreading.com
on behalf of
www.qosmos.com
February 2015
HEAVY READING | FEBRUARY 2015 | WHITE PAPER | SERVICE CHAINING IN CARRIER NETWORKS 2
Dynamic Services, Dynamic Networks Service chaining is an emerging set of technologies and processes that enable op-
erators to configure network services dynamically in software without having to
make changes to the network at the hardware level. By routing traffic flows accord-
ing to a "service graph," service chaining addresses the requirement for both opti-
mization of the network, through better utilization of resources; and monetization,
through the provisioning of services that are tailored to the customer context.
This white paper examines why dynamic service chaining is useful and how it ena-
bles operators to dynamically create services using appliance-based and virtual-
ized network functions (VNFs). It will analyze implementation options in carrier net-
works, specifically addressing the role of the classifier, packet-header options and
the importance of metadata.
Why "Network Ossification" Is a Problem
Service chaining is not a new idea. Insofar as network equipment is hardwired back-
to-back to create a processing path, chaining of network functions in hardware is
the de facto operating model. The challenge is that hardwired service chains are
difficult to deploy and change. They are characterized by hand-crafted complex-
ity, with lifecycles that are long and static. This leads to "network ossification."
In competitive markets, with rapid innovation at the application layer, this limits op-
erators' ability to address emerging use cases and business models. Ossification, in
effect, unnecessarily restricts the addressable market for telecom services – which
is obviously a problem for a sector with modest top-line revenue growth.
The issue today is that the application layer (the services used by consumers) is very
dynamic, with rapid evolution in end-user services, yet networks are static. To ad-
dress this, network operators want to accelerate the transition to software-centric,
programmable networks. Operators have seen what can be achieved within the
software-defined data center networking paradigm, and they want to adapt those
architectures and toolsets to bring these concepts to carrier networks.
Service Chaining Concepts
Software-configured service chaining provides the capability to dynamically in-
clude best-of-breed functions in a network processing path. The concept is shown
in Figure 1. Each circle represents a different service function (a.k.a. network func-
tion) that is connected to other services via a network. The arrows represent three
different service chains that comprise a particular set of service functions con-
nected in order. In the example, the configurations are shown as follows:
Service Chain 1 (blue) = S1, S2, S3 and S4
Service Chain 2 (red) = S1, S2, S5, S6 and S8
Service Chain 3 (green) = S1, S5, S6 and S7
In principle, a number of different topologies are possible. For example, service path
forking, service function sharing and bidirectional service chains will all be useful in
different scenarios. Service chains can be fine-grained or coarse-grained, depend-
ing on the use cases, and may be either highly dynamic or based on predefined
service templates.
HEAVY READING | FEBRUARY 2015 | WHITE PAPER | SERVICE CHAINING IN CARRIER NETWORKS 3
An important principle is that the "service graph" is decoupled from the network, so
the operator can configure a processing path to run across both physical and virtual
components. This abstraction is fundamental because it generates an architecture
that is applicable to physical, virtualized and hybrid network contexts, and therefore
makes the service chaining applicable to multiple operator types and use cases.
Relationship Between SDN, NFV & SFC
The service chain concept is inherent to software-centric networking technologies
such as NFV or SDN, and which in practice will be part of the implementation. Three
important ongoing initiatives are listed below. This is overlap between these initia-
tives, but they are all "policy-driven" and can in principle be used in combination:
Network Functions Virtualization (NFV): The ETSI specification documents re-
fer to the idea of a Forwarding Graph to connect VNFs deployed in se-
quence. To create and implement the graph, NFV Orchestration is critical.
Software-Defined Networking (SDN): There are already commercially de-
ployed service chain controllers that implement policies and services using
a logically centralized view of network resources. Multiple protocols are
defined for this, including NETCONF, XMPP, BGP and of course OpenFlow.
Service Function Chaining (SFC): An important emerging industry initiative
is the SFC work ongoing in the Internet Engineering Task Force (IETF). This
includes development an architecture that is increasingly influential as is
becoming the dominant terminology used to discuss service chaining.
Figure 1: Service Chain Concept
Source: Heavy Reading
HEAVY READING | FEBRUARY 2015 | WHITE PAPER | SERVICE CHAINING IN CARRIER NETWORKS 4
Service Chaining Use Cases This section identifies emerging use cases for service chaining and discusses the rel-
ative attractiveness to different types of operators.
Which Network Functions?
In principle, many (all?) types of network elements can be incorporated into a ser-
vice chain. In practice, Layer 3-7 functions that operate on top of an IP transport
network are the most likely candidates. This includes the classic middle-box func-
tions, such as Web proxies, traffic shapers, HTTP header enrichment, etc., and IP de-
vices such as enterprise access routers, WAN acceleration, firewalls and network
address translation (NAT). Figure 2 identifies many of these types of function and
categorizes them:
The functions that are likely to be included into service chains influence the use
cases, and vice versa. For example, video optimization is more likely to be used in
mobile operator networks than in wireline access. And fixed operators may not de-
ploy many VAS appliances in the data path (e.g., ad insertion), but would typically
use SBCs, web proxies and security functions behind, for example, a B-RAS/BNG.
The makeup of service chains will also change over time to include more Layer 2/3
functions. This will be dependent on the rate at which the tools to create and man-
age chains are made more robust, and the rate at which the functions themselves
can be made compatible with the relevant control-plane and metadata models.
Upgrading existing physical devices will take time and may not be economically
viable in some cases.
Use Cases
There are several emerging use cases for service chaining that are starting to be-
come reasonably well-understood across the industry. An important point is that
while the use cases are distinct, and the functions in the chain vary accordingly, the
architecture is, in principle, generic from an operator perspective: That is to say,
service chaining is a horizontal capability that can support many use cases.
Figure 2: Middle-Box Functions for Inclusion Into Service Chains
CATEGORY EXAMPLE FUNCTIONS
Packet
inspection IPFiX, firewalls, IPS, DDoS
Traffic
optimization Video transcoding, TCP optimization, traffic shaping, DPI
Protocol
proxies
Carrier-grade NAT, DNS cache, HTTP proxy/cache, SIP proxy,
TCP proxy, session border controllers, WebRTC gateways
Value-added
services (VAS)
Ad insertion, header enrichment, WAN acceleration,
advanced advertising, URL filtering, parental control
Source: Heavy Reading
HEAVY READING | FEBRUARY 2015 | WHITE PAPER | SERVICE CHAINING IN CARRIER NETWORKS 5
While operators like this flexibility (and some insist on viewing service chaining as plat-
form technology), most will select lead use cases for deployment, as this addresses
specific needs and offers a concrete objective to focus on. Figure 3 identifies some
promising use cases.
Figure 3: Emerging Service Chaining Use Cases
USE CASE DESCRIPTION BENEFITS DEPLOYMENT OUTLOOK
Mobile Core/
Gi-LAN
Ability to steer traffic from the
Gi/SGi interface through differ-
ent VAS appliances en route to
external networks
Ingress at the GGSN/P-GW/
PCEF or in external classifiers;
uses per-subscriber/service
policy from the PCRF
Easier and faster to add or
remove functions in the
data path (enables experi-
mentation)
Create per-subscriber or en-
terprise-specific services for
better monetization of mo-
bile data
Proprietary traffic steering,
with integrated control
plane, is already deployed
The first SDN-based GI-LAN
service chaining deploy-
ments are expected to
launch in 2015
Enterprise
WAN and
vCPE Services
Policy-based routing of user
groups, enterprise applications,
and cloud services through
appropriate network functions
Used for WAN services configu-
ration and/or behind CPE de-
vices, and virtual CPE instances
Services created via dash-
board without the need for
specialist manual configura-
tion of devices
Makes network service user-
programmable through a
portal; enables upsell oppor-
tunities beyond simple con-
nectivity
Controller-based SDN WAN
services using existing IP de-
vices are already deployed
Expect more extensive
WAN and data center
interconnect services to be
offered in 2015
Residential/
Consumer
Services
Starts with "standard" steering of
services such as VoIP, parental
control and traffic management
(e.g., DPI)
Evolves to offer follow-the-user
services across access types
(with policy)
Supports convergent ser-
vices and business models
across fixed and mobile
assets
Basic services already
offered; more advanced
follow-the-user services are
probably 4-5 years from
commercial offer
Data Center
Networking
(Inter and
Intra)
Intra-data-center networking –
e.g., for virtualized apps
Inter-data-center for service
chaining across locations or
"InterCloud" WAN services
Supports convergent ser-
vices and business models
across fixed and mobile
assets
Already part of more ad-
vanced virtual networking
services (e.g. NSX); used for
customer and application
segmentation
InterCloud-type services
under development
Source: Heavy Reading
HEAVY READING | FEBRUARY 2015 | WHITE PAPER | SERVICE CHAINING IN CARRIER NETWORKS 6
Service Function Chaining Architecture Service Function Chaining (SFC) is a new architecture under development in the IETF.
It is emerging as a very useful conceptual tool that will help the industry move toward
commercial implementation, and even if commercial service chaining deployments
are not technically an "SFC service," they will be influenced by this work.
The goal of SFC is to develop a set of architectural building blocks that will enable
network operators to create a service topology and instantiate a service function
path across the network. SFC thus covers placement of network functions, service
chain management, diagnostics and security models. The SFC architecture is outlined
in Figure 4.
At the ingress to the service chain, a classifier identifies and classifies traffic before
forwarding it into the processing path. The path itself is set up and managed by the
control plane (which can be implemented in different ways). Because SFC is bidirec-
tional, classifiers can also be deployed at the egress point to route return traffic ac-
cordingly. Service functions can be added or removed from the chain dynamically,
and in principle can also modify the path themselves based on metadata and policy
applied to the service in question. There are three important parts of the architecture:
Classifier: The ability to identify and then classify traffic in order to direct
flows into a service chain is critical. There are several ways to do this, from
simply directing any traffic to, or from, a particular destination to a particu-
lar service path, or a more sophisticated policy-driven scheme. In the SFC
architecture specifically, there is ongoing work regarding additional packet
header definitions: the Network Service Header (NSH) and Service Chain
Header (SCH). Both transport metadata for managing the chain.
Control Plane: The SFC control plane includes a topology server and a policy
decision point (PDP). The topology server talks to the ingress and egress nodes
(the classifiers) and locates service function nodes in the network. The PDP
communicates with the service functions over NETCONF and is a central
control/management plane entity used to maintain SFC policy tables.
NSH & SCH: The IETF working group is seeking to define a service-level data-
plane encapsulation format (i.e., a new packet header) that specifies the
sequence of service functions that make up a service chain, and which
chain the packet should enter. This new header format can also be used
to communicate context information between nodes that implement ser-
vice functions. This is discussed in more detail later.
Figure 4: SFC Architecture
Source: IETF
HEAVY READING | FEBRUARY 2015 | WHITE PAPER | SERVICE CHAINING IN CARRIER NETWORKS 7
Mapping to the Architecture to Network Environments
The high-level SFC architecture described above provides a template and termi-
nology that can be applied to service chaining in general. In practice, however,
the logical architecture will need to be mapped to existing network capabilities, as
shown in Figure 5.
The model includes the following functions necessary for the deployment and op-
eration of service chains in carrier networks:
The service functions themselves (S1, S2, S3, etc.); virtual or physical
The classifier (the ingress into the service chain)
The network layer; physical and virtual overlays
A control layer comprising a service chain descriptor, controller and policy
A management and orchestration platform
In practice, there are two broad approaches to implementation. The first could be
thought of as leveraging existing telco equipment and standards – for example,
deriving policy from a 3GPP PCRF and using PCEFs or TDFs as a classifier (perhaps
embedded in the P-GW) for service chain ingress. The second is more IT and data-
center-oriented – for example, using SDN controllers and VXLAN overlays.
In the longer term, the market assumption appears to be that the data-center-
oriented models will prevail in service provider networks; however, there are solu-
tions in development and deployment that use elements from both approaches (in
the Gi-LAN, for example). Moreover, if the abstraction from physical and virtual en-
vironments is maintained, it is conceivable (likely, even) that a "Network Controller"
or "Service Chain Controller" could be the bridge between the two worlds.
Figure 5: Generic Model for Network Service Chaining
Source: Heavy Reading
HEAVY READING | FEBRUARY 2015 | WHITE PAPER | SERVICE CHAINING IN CARRIER NETWORKS 8
Deployment of the Classifier Function The classifier has a critical role in identifying and classifying traffic flows, and then
forwarding them into the appropriate processing path. The implementation is criti-
cal because it is at the start of the chain where the "service graph" is applied.
The type of classifier that will be needed will vary between use cases and network
environments. For example, in a mobile network it could be a deep packet inspec-
tion (DPI) box, a load balancer, or packet gateway, depending on the existing as-
sets, when the operator expects to refresh equipment, etc. For services with rela-
tively low traffic volume (e.g., a single enterprise VPN), the classifier could be virtu-
alized and integrated with the hypervisor and vSwitch, whereas higher-throughput
services may utilize a physical device. On the performance question specifically,
the cut-over point will be determined by implementation preference and will
change over time.
Classifier Deployment Options
In practice, it appears likely that operators will use multiple types of classifiers. Mobile
is a good example in the sense that the idea of per-subscriber services are embed-
ded in industry thinking, and because there is widely deployed policy infrastructure
that can be used to determine, for example, if a subscriber should be directed to a
parental control service.
Figure 6 shows the results of a Heavy Reading survey that asked operators where
packet classification should be deployed in a Gi-LAN service chain. The chart in-
cludes only operators with mobile networks.
In this Gi-LAN context it is fairly clear that operators expect to use packet classifica-
tion techniques in multiple places. The 32 respondents to this question generated 82
Figure 6: Where in the Network Should Packet Classification (Embedded DPI) Reside in a Gi-LAN Service Chain?
Source: Heavy Reading's Service Chaining Operator Survey, 2015; n=32
HEAVY READING | FEBRUARY 2015 | WHITE PAPER | SERVICE CHAINING IN CARRIER NETWORKS 9
responses split between classification in the P-GW/PCEF (68 percent), integrated
into the NFV virtualization layer (64 percent), or in a standalone classifier (48 per-
cent). And note that the difference between a load balancer and a standalone
classifier is debatable in the sense that a load balancer acts (among other things)
as a classifier.
In general, operators think that classification will occur at different points in the net-
work depending on the operator and the use case, and that classification locations
may well change over time. For example, some will look to extend the 3GPP PCC
and PCEF architecture initially, and perhaps migrate to a SDN-type architecture
over time.
Gi-LAN Classifiers
In the quest for greater granularity and control of traffic, a range of flow identifica-
tion methods have been proposed. Some of the leading options are:
Network gateway: Perhaps the simplest solution is to determine service
flows according to IP address and packet classification information derived
from packet gateways, such as the P-GW or GGSN. This combined with pol-
icy information is a useful way to route traffic through a service complex.
An issue with this approach is that if the first hop after the gateway is a leg-
acy device, the chain would cease to be dynamic.
Service gateway: A gateway appliance deployed behind the EPC (or IP
edge) is emerging as a popular approach. Based on a specialist traffic
management platform of some kind – typically an edge router, DPI box or
load balancer – this equipment does not have the same session manage-
ment and mobility management requirements as a P-GW. This enables the
operator to decouple the service chain from mobile core or IP edge.
Load balancers and ADCs: This is a variation of the service gateway model.
Load balancers are posited as ideal platforms for flow classification be-
cause they have visibility of Layer 4-7 traffic and are proven to be scalable.
They are used to route traffic between servers in data centers, which is
sometimes referred to as the "cloud edge" in a telco network context.
SDN switches: High-performance SDN (OpenFlow?) switches in combina-
tion with policy data from the network are proposed as a way to segment
flows. The advantage is that once flow types are known in the switching
layer it should be relatively simple to create forwarding paths at scale. Phys-
ical switches and virtual switches may be used depending on performance
requirements.
Virtualized classifier: A classifier can be integrated into the hypervisor
vSwitch layer of a cloud networking environment. Such classifier instances
may not be high-capacity, but could be sufficient for many service/cus-
tomer categories, and moreover, scale can be achieved through multiple
virtual classifier instances.
The question of classifier scalability is an important one, and is an area that needs
further work. To dimension a classifier parameters such as the following will be im-
portant: Number of rules/policies, throughput required, number of hops in the chain
and the impact of service functions on the chain itself. A static chain, for example,
requires the classifier to do more work on the packet at ingress, whereas a more
dynamic environment cloud see flows redirected according to decisions imple-
mented by the service functions themselves.
HEAVY READING | FEBRUARY 2015 | WHITE PAPER | SERVICE CHAINING IN CARRIER NETWORKS 10
Role of Metadata & NSH Metadata is used to share information about the user's traffic with the network func-
tions that make up a processing path and is important to the service chaining con-
cept. There are many types of metadata that can be used in different ways in the
creation of services. The data-tagging choices operators make determine how ser-
vice information can be shared with inline networking functions.
Metadata Conveyance
Broadly speaking, metadata can be conveyed in packet headers, either explicitly
(such as GTP or MPLS or VXLAN or UDP), or derived from context (such an IP desti-
nation address); as an inline congruent flow; or as an out-of-band mechanisms
(such as IPFIX). Figure 7 shows the operators' preference for metadata conveyance
across these categories.
All three options receive support in the survey and it appears that a "mixed-econ-
omy" will prevail over the medium term. However, there is a clear preference for
"within each packet of each flow" (51 percent) which indicates the packet header
option is preferred. Note that the type of header is not specified.
The Network Services Header (NSH)
One emerging format is the Network Services Header proposed by the IETF. It com-
prises two key elements: (1) Data plane encapsulation to direct packets to the req-
uisite functions; and (2) per-packet/frame metadata to communicate service re-
quirements and network state between nodes.
In the SFC architecture, the classifier imposes an NSH header on the flow. The NSH
itself is agnostic to the network, and so can be used with VXLAN, LISP, NVGRE, over-
lays, etc. The forwarding information and metadata is contained within a base
header and four context headers, as shown in Figure 8. There is now a good con-
sensus on the basic structure of the header in the IETF, but there is still some remain-
ing discussion on the metadata that should be included and interpreted by the
"downstream" functions.
Figure 7: How Should Application ID and/or Metadata Be Conveyed for Service Chaining?
Source: Heavy Reading's Service Chaining Operator Survey, 2015; n=45
HEAVY READING | FEBRUARY 2015 | WHITE PAPER | SERVICE CHAINING IN CARRIER NETWORKS 11
Because it is agnostic to the underlying transport network type, there is potential to
use NSH in different environments. For example, it could be used in an SDN-based
forwarding plane to create services that traverse physical and virtual networks.
Adoption of NSHs
The concept of NSH is promising, and awareness of SFC technology is growing, but
it is still early days. While operators like the idea of service chaining based on packet
headers, Figure 9 shows that they are not clear what data-plane tagging tech-
niques they will use, with more than half of the operators surveyed saying they have
"not decided." Of those that have decided, there appears to decent support for
NSH, with 27 percent saying they will migrate to it over time, and 12 percent saying
they will wait for it to mature before going ahead with service chaining. In short,
although attractive in principle, the case for NSH still needs to be made.
Figure 8: NSH Header Insertion
Source: Vodafone, 2014
Figure 9: What Data-Plane Tagging Techniques Will Your Company Use for Service Chaining?
Source: Heavy Reading's Service Chaining Operator Survey, 2015; n=49
HEAVY READING | FEBRUARY 2015 | WHITE PAPER | SERVICE CHAINING IN CARRIER NETWORKS 12
One important issue is that new hearer formats such as NSH or SCH will require the
service functions themselves to be upgraded (if they are not natively compatible)
and this may be onerous. For this reason, operators will be cautious and may prefer
overlays such as VXLAN, NVGRE, etc. and/or underlays using DSCP, UDP, etc., to
segment traffic.
Initially, then, this favors using NSH (or SCH) in virtualized environments, which are
faster to update and easier to make NSH-compatible. In this type of scenario, the
classifier itself can be integrated in the hypervisor switching layer, as discussed above,
and in this way operators can achieve a fast and flexible deployment. Therefore,
we believe SFC will first be used commercially in virtualized cloud environments.
The intention is to also support NSH support in hardware appliances either as new
products, or via software updates, and over time into silicon to improve perfor-
mance. This will maintain the abstraction principle that is central to SFC and extend
the commercial life of existing equipment. There may also be a role for classifiers
that act as gateways to non-NSH-compatible appliances in the meantime, partic-
ularly where the service chain crosses a virtual/physical boundary.
A final point is that need for standardized interaction between service chain con-
trollers, NFV orchestrators, element management systems, policy servers and SDN-
based networking. SFC in isolation looks fairly simple, but in practice, integration into
a broader network services architecture is complex (obviously) and dependent on
the evolution of SDN and NFV. The good news is that this work is ongoing, and it is
helped by the fact that SFC is complementary to SDN and NFV, and arguably, helps
to maximize the value of those technologies in terms of providing operators with
rapid time-to-market and the ability to adapt the network to change.
HEAVY READING | FEBRUARY 2015 | WHITE PAPER | SERVICE CHAINING IN CARRIER NETWORKS 13
Background to This Paper
About the Author
Gabriel Brown
Senior Analyst, Heavy Reading
Gabriel covers the mobile network system architecture, including evolution of the RAN,
the mobile core, and service-layer platforms and applications. Key technologies in his
coverage area include LTE Advanced, small cells, Evolved Packet Core, carrier WiFi
and software-centric networking technologies such as NFV, SDN and service chain-
ing. Gabriel has covered mobile networking since 1998 through published research,
live events, operator surveys and custom consulting. Prior to joining Heavy Reading,
Gabriel was Chief Analyst for Light Reading Insider research service; before that, he
was editor of IP Wireline and Wireless Week at London's Euromoney Institutional In-
vestor. He is based in London and can be reached at [email protected].
About Heavy Reading
Heavy Reading (www.heavyreading.com), the research division of Light Reading,
offers deep analysis of emerging telecom trends to network operators, technology
suppliers and investors. Its product portfolio includes in-depth reports that address
critical next-generation technology and service issues, market trackers that focus
on the telecom industry's most critical technology sectors, exclusive worldwide surveys
of network operator decision-makers that identify future purchasing and deploy-
ment plans, and a rich array of custom and consulting services that give clients the
market intelligence needed to compete successfully in the global telecom industry.