service chaining in carrier networks

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

http://www.heavyreading.com/

http://www.companyurl.com/

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.


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


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



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



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

http://tools.ietf.org/html/draft-quinn-sfc-arch-04


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



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


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.


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?



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?



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.


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.

mailto:[email protected]

http://www.heavyreading.com/

service chaining in carrier networks

Sports

service path

dynamic service chaining

problem service chaining

service graph

network services

white paper service

different service chains

chaining of network