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

Dynamic Services, Dynamic Networks Service chaining is an emerging set of technologies and processes that enable operators to configure network services dynamically in software without having to make changes to the network at the hardware level. By routing traffic flows according to a "service graph," service chaining addresses the requirement for both optimization 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 enables operators to dynamically create services using appliance-based and virtualized network functions (VNFs). It will analyze implementation options in carrier networks, 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 backto-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 complexity, with lifecycles that are long and static. This leads to "network ossification." In competitive markets, with rapid innovation at the application layer, this limits operators' 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 address 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 include 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 function) that is connected to other services via a network. The arrows represent three different service chains that comprise a particular set of service functions connected 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, depending 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 2

Figure 1: Service Chain Concept Source: Heavy Reading 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 initiatives, but they are all "policy-driven" and can in principle be used in combination: Network Functions Virtualization (NFV): The ETSI specification documents refer to the idea of a Forwarding Graph to connect VNFs deployed in sequence. To create and implement the graph, NFV Orchestration is critical. Software-Defined Networking (SDN): There are already commercially deployed 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. HEAVY READING FEBRUARY 2015 WHITE PAPER SERVICE CHAINING IN CARRIER NETWORKS 3

Service Chaining Use Cases This section identifies emerging use cases for service chaining and discusses the relative attractiveness to different types of operators. Which Network Functions? In principle, many (all?) types of network elements can be incorporated into a service 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 functions, such as Web proxies, traffic shapers, HTTP header enrichment, etc., and IP devices 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: Figure 2: Middle-Box Functions for Inclusion Into Service Chains CATEGORY Packet inspection Traffic optimization Protocol proxies Value-added services (VAS) EXAMPLE FUNCTIONS IPFiX, firewalls, IPS, DDoS Video transcoding, TCP optimization, traffic shaping, DPI Carrier-grade NAT, DNS cache, HTTP proxy/cache, SIP proxy, TCP proxy, session border controllers, WebRTC gateways Ad insertion, header enrichment, WAN acceleration, advanced advertising, URL filtering, parental control Source: Heavy Reading 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 deploy 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 manage 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 become 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. HEAVY READING FEBRUARY 2015 WHITE PAPER SERVICE CHAINING IN CARRIER NETWORKS 4

While operators like this flexibility (and some insist on viewing service chaining as platform 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 different 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 experimentation) Create per-subscriber or enterprise-specific services for better monetization of mobile data Proprietary traffic steering, with integrated control plane, is already deployed The first SDN-based GI-LAN service chaining deployments 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 configuration and/or behind CPE devices, and virtual CPE instances Services created via dashboard without the need for specialist manual configuration of devices Makes network service userprogrammable through a portal; enables upsell opportunities beyond simple connectivity Controller-based SDN WAN services using existing IP devices 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 services 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 services and business models across fixed and mobile assets Already part of more advanced 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 5

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. Figure 4: SFC Architecture Source: IETF 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 bidirectional, classifiers can also be deployed at the egress point to route return traffic accordingly. 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 particular 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 dataplane 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 service functions. This is discussed in more detail later. HEAVY READING FEBRUARY 2015 WHITE PAPER SERVICE CHAINING IN CARRIER NETWORKS 6

Mapping to the Architecture to Network Environments The high-level SFC architecture described above provides a template and terminology 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. Figure 5: Generic Model for Network Service Chaining Source: Heavy Reading The model includes the following functions necessary for the deployment and operation 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 datacenter-oriented for example, using SDN controllers and VXLAN overlays. In the longer term, the market assumption appears to be that the data-centeroriented models will prevail in service provider networks; however, there are solutions in development and deployment that use elements from both approaches (in the Gi-LAN, for example). Moreover, if the abstraction from physical and virtual environments is maintained, it is conceivable (likely, even) that a "Network Controller" or "Service Chain Controller" could be the bridge between the two worlds. HEAVY READING FEBRUARY 2015 WHITE PAPER SERVICE CHAINING IN CARRIER NETWORKS 7

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 critical 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 inspection (DPI) box, a load balancer, or packet gateway, depending on the existing assets, when the operator expects to refresh equipment, etc. For services with relatively low traffic volume (e.g., a single enterprise VPN), the classifier could be virtualized 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 embedded 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 includes only operators with mobile networks. 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 In this Gi-LAN context it is fairly clear that operators expect to use packet classification techniques in multiple places. The 32 respondents to this question generated 82 HEAVY READING FEBRUARY 2015 WHITE PAPER SERVICE CHAINING IN CARRIER NETWORKS 8

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 percent). 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 network 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 identification 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 policy 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 legacy 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 management 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 because 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 combination 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. Physical 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/customer 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 important: 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 implemented by the service functions themselves. HEAVY READING FEBRUARY 2015 WHITE PAPER SERVICE CHAINING IN CARRIER NETWORKS 9

Role of Metadata & NSH Metadata is used to share information about the user's traffic with the network functions that make up a processing path and is important to the service chaining concept. 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 service 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 destination 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. 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 All three options receive support in the survey and it appears that a "mixed-economy" 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 comprises two key elements: (1) Data plane encapsulation to direct packets to the requisite functions; and (2) per-packet/frame metadata to communicate service requirements 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, overlays, 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 consensus on the basic structure of the header in the IETF, but there is still some remaining discussion on the metadata that should be included and interpreted by the "downstream" functions. HEAVY READING FEBRUARY 2015 WHITE PAPER SERVICE CHAINING IN CARRIER NETWORKS 10

Figure 8: NSH Header Insertion Source: Vodafone, 2014 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 techniques 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 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 11

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 performance. 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, particularly where the service chain crosses a virtual/physical boundary. A final point is that need for standardized interaction between service chain controllers, NFV orchestrators, element management systems, policy servers and SDNbased 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 12

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 chaining. 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 Investor. He is based in London and can be reached at brown@heavyreading.com. 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 deployment 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. HEAVY READING FEBRUARY 2015 WHITE PAPER SERVICE CHAINING IN CARRIER NETWORKS 13