SDN has also contributed to the virtualization of the network infrastructure, pro-viding the foundation to isolate, abstract, and share the network resources. On the other hand, NFV has been proposed to innovate in the service delivery by using standard computing virtualization technology to consolidate in commodity hardware (i.e., standard high volume servers, storage, and switches) the functions previously performed by specific hardware appliances. Virtualized Network Functions (VNFs) composing a service chain represent the basic elements to achieve the complete vir-tualization of service delivery and are commonly based on computing resources. The interconnection of VNFs, or traffic steering, is a challenging goal for the underlying network infrastructure. The migration of VNFs and dynamic composition of services make this task even harder than in legacy networks. Adapting the use of resources to the actual demand is one of the main outcomes from a virtualized infrastructure, providing elasticity of resources instead of over provisioning
SDN and NFV are complementary technologies, and each one can leverage off the other to improve the flexibility and simplicity of networks and service delivery over them. Initially, NFV has been introduced as a stand-alone project as well as an SDN-agnostic initiative. SDN was tought to modify the network behaviour flexibly, whereas the NFV initiative had the direction to enable to deploy network functions, from proprietary middleboxes to commodity hardware (i.e., standard high-volume servers, storage, and switches). However, SDN and NFV are complementary
tech-21 2.4 SDN & NFV & SFC
nologies, and each one can leverage off the other to improve the flexibility and simplicity of networks and service delivery over them [38]. Therefore, the research community is moving towards SDN-enabled NFV solutions. SDN-enabled NFV so-lutions are particularly relevant when speaking about Service Function Chaining.
In such cases, NFV solutions are used to deploy the network functions. However, SDN techniques are required, in order to efficiently steer the traffic towards the right service chain.
Chapter 3
Single-domain Service Function Chains
3.1 Introduction
As introduced in Section 1, network operators deploy network functions to enforce their policies and to provide additional services on top of plain connectivity [39].
Content caching, Network Address Translation (NAT), TCP optimization, video transcoding, HTTP header enrichment, are examples of such services. Despite their ubiquitous usage [40], network functions deployment is still performed by modifying the network topology. That is, network functions are hard-wired on the network traffic’s path. The inflexibility and complexity of this approach are not acceptable when network functions are implemented by means of software running in virtual machines, as envisioned in the case of Network Function Virtualization (NFV) [41].
In fact, hard-wiring would hinder the benefits brought by the possibility of dy-namically deploying virtual network functions (VNFs) on general purpose servers.
Therefore, there is a growing interest in Service Function Chain (SFC) systems [42], which enable the flexible deployment of network functions while guaranteeing their configurable and dynamic chaining.
In general, a SFC system assigns a network flow entering the managed network to a chain of functions, and steers the flow through the functions of such chain, according to the chain’s functions ordering [43]. A number of challenges arise when addressing the design of a SFC system. First, assigning a network flow to its chain requires
Chapter 3 Single-domain Service Function Chains 24
network traffic classification, an operation that is critical for the system scalability since it should be performed for all the handled traffic. Second, traffic forwarding should be performed according to the chain the traffic belongs to, instead of following the typical forwarding approach, e.g., based on IP routing. Third, network flows are usually bi-directional, that is, there is an upstream and a downstream direction and a network function, e.g., a firewall, may need to handle both of them. This requires to perform a coordinated classification of upstream and downstream flows, and the enforcement of symmetric paths for the two directions. Finally, network functions may have dynamic and opaque behaviors that modify the network traffic in unknown ways, which may introduce a need for traffic reclassification or even make the traffic unclassifiable [44].
To address these challenges, a number of SFC systems have been already pro-posed [44–48]. However, they usually target green field or long term deployments.
In fact, they require a number of changes either in the network hardware [44] or in the network functions [48], or in both [45]. In other cases, they require modifications to the network architecture [46]. Ready to deploy solutions, which don’t require such changes, may instead not handle all the aforementioned challenges. For example, some SFC systems are unable to deal with opaque network functions actions [44,47].
Regardless of the adopted solutions, the proposed systems address SFC in a general way, supporting a broad range of deployment scenarios without considering their specific properties and constraints. That is, they usually adopt a “one-size-fits-all”
approach. While we recognize the intrinsic value of such a general solution, we also notice that not all the deployment scenarios share the same set of requirements, with the final result of SFC systems that provide unnecessary features for the specific sce-narios in which they are deployed. At the same time, such systems usually fail to satisfy a critical requirement of many today’s production deployments, i.e., the SFC
25 3.1 Introduction
solution should introduce minimum impact on the legacy infrastructures [49,50].
We argue that it is possible to simplify the implementation of a SFC system, by carefully tailoring the SFC solution to its specific deployment scenario. Our main contribution is to demonstrate that this statement holds true for the practical case of implementing SFC in mobile networks. To this aim, we present the design and implementation of CATENAE, a system that supports SFC in today’s mobile net-works without introducing new protocols, without changing the legacy infrastructure and without changing network functions behavior. CATENAE leverages the unique properties of a mobile network’s scenario to provide the desired functions chaining features, including the handling of opaque network functions’ actions. Traffic for-warding is performed by rewriting network packets’ header to steer network flows from one function to the next one in the chain. Rewriting rules are configured using SDN software switches, which are anyway deployed at the servers hosting VNFs [51].
Flow re-classification after a VNFs is done by creating per-VNF VLAN topologies, using an approach conceptually similar to [52]. By implementing a proof of concept prototype, we demonstrate that CATENAE does not add per-packet processing overheads, it integrates nicely with legacy network management systems and it is fully compatible with legacy network infrastructures and functions while supporting millions of network flows.
3.1.1 Contributions
This chapter is structured as follows:
• Section 3.2introduces background information on the mobile networks where CATENAE is deployed, and introduces related work;
Chapter 3 Single-domain Service Function Chains 26
• Section 3.3 presents the CATENAE’s design, describing its architecture and deployment options;
• Section 3.4 describes the design of the classifiers employed to assign network traffic to service function chains;
• Section 3.5 presents the CATENAE’s traffic steering method and provides a concrete example of the method applied to a network scenario;
• Section3.6 reports the results of our prototype evaluation;
• Section3.7discusses our design in the light of the evaluation results and further describes differences with related work.
We conclude this chapter in Section3.8.