Position Paper: Software-Defined Network Service
Chaining
Jeremias Blendin
∗, Julius R¨uckert
∗, Nicolai Leymann
§, Georg Schyguda
§, and David Hausheer
∗ ∗ Peer-to-Peer Systems Engineering Lab, Technische Universit¨at Darmstadt, GermanyEmail: {jblendin|rueckert|hausheer}@ps.tu-darmstadt.de
§Deutsche Telekom Technik GmbH, Fixed Mobile Engineering Deutschland, Darmstadt, Germany
Email: {n.leymann|g.schyguda}@telekom.de Abstract—Network service chaining allows composing services
out of multiple service functions. Traditional network service functions include, e.g., firewalls, TCP optimizers, web proxies, or higher layer applications. Network service chaining requires flexible service function deployment models. Related work facil-itating service chaining include, e.g., the network service header proposal discussed at the IETF or the complementary work on network function virtualization (NFV) at ETSI. This position paper presents a high-level concept and architecture to enable service chaining using Software Defined Networking (SDN), specifically OpenFlow in a telecommunication environment. The paper discusses required functionalities, challenges, and testbed aspects to implement and test such an approach. Finally, the set of implemented service functions and management interfaces are highlighted to demonstrate the approach as a proof of concept for a selection of relevant use cases.
I. INTRODUCTION
Network services such as traffic optimizers or firewalls play an important role in achieving the performance and security challenges present in fixed and mobile carrier networks. Today, network services are usually deployed as hardware appliances that are physically integrated in the network by attaching cabling. Network Function Virtualization (NFV) [2] enables network services to run in software on low cost off-the-shelf server hardware. Thereby, the NFV approach promises high flexibility and lower costs for network operators at the same time. Yet, the composition of network services, termed network service chaining [5], remains a challenging task as user and operator requirements are changing frequently and new service functions need to be deployed and resources scaled up quickly. Today, pre-configured service chains are typically deployed, purely consisting of statically configured and wired service functions. Static service chains are useful; however, they rely on fixed hardware and software configurations. More-over, changing existing chains requires time-intensive manual reconfigurations, making the approach often inflexible and hard to adapt to changing requirements. Furthermore, deployments of new network services are slowed down as existing functions inside a chain often cannot be easily reordered to implement different services [3].
Dynamic service chaining aims to improve this situation in two aspects: first, service chains can easily be created from existing service functions. Second, the network resources used to deliver a service function can be allocated dynamically during runtime. The former enables rapid deployments of new service models, therefore, increasing the ability to adapt to the customers’ needs. The latter enables load balancing and
allows using resources more efficiently. Resources for each service function can be dynamically allocated during runtime depending on the actual load. Network Service Headers (NSH) [10] is one approach to implement dynamic service chains. NSH relies on an additional network header which requires special interfaces to handle those headers and to implement the service chaining functionality. StEERING [14] is an alternative which relies on SDN/OpenFlow instead, but the approach doesn’t address the identification and handling of packets from service instances where packet header information are modified. Thus, the mapping of packets to service chains and users remains an open issue. Specifically, key challenges are the separation of flows related to different service chain instances within a service instance as well as the mapping of packets to service chain instances at the handover between the network and a service node. This is especially so in case of services which modify the header information (e.g. HTTP proxies). SIMPLE [9] is an approach that aims to address this problem by correlating packet headers before and after they are modified as they traverse a service function. This approach is rather complex as it requires a packet matching with a high accuracy.
In contrast, the SDN-based service chaining approach proposed in this paper avoids packet-based matching. At the same time, it allows to integrate unchanged network service software that is unaware of its operating environment. It does so by creating one dedicated service instance per service chain instance which is operated in an isolated network environment. The mapping of multiple users to a single service instance can be supported additionally, provided that the information required for user identification is preserved by the service func-tion. The proposed approach simplifies the deployment process as it minimizes network configuration changes required during deployment. Moreover, it enables deploying large numbers of service function instances with low overhead. The feasibility of the approach is shown by a proof-of-concept implementation using OpenFlow.
The remainder of this paper is organized as follows: Section II discusses the background of network service chain-ing. Moreover, Section III outlines the fundamental concepts proposed here, while Section IV presents the proposed ar-chitecture. In addition, Section V outlines first results from a proof-of-concept implementation. Finally, Section VI pro-vides an overview on related works, while Section VII draws preliminary conclusions and outlines future work.
II. BACKGROUND
NFV and dynamic network service chaining are still new and evolving topics. The terminology is not yet standard-ized completely, even more so for their implementations. An overview on the terminology used in this work is depicted in Figure 1. It is partially based on [11] and has been extended where necessary.
Fig. 1: High-Level Entity Relationship Model for Service Chaining
The basic concept is a service function, which defines in an abstract manner the treatment of packets related to network flows. Examples include firewalls, HTTP proxies or bandwidth limiters. A service instance is an operational soft- or hardware instance that is deployed in the network, delivering the treat-ment specified by the associated service function. Software service instances are deployed in services nodes. Besides pro-viding a runtime environment, service nodes comprise facilities for attaching service instances to the network. A service chain specifies a network service that is implemented through the applications of a series of service functions. Like a service function, it is an abstract specification that is implemented by service chain instances. Furthermore, service chain instances rely on service function instances and their interconnection for delivering a network service to a given user. A service chain instance embodies an instantiated service chain capable of delivering a concrete network service to a concrete user. While a service chain defines an order of abstract service functions, an active service chain instance requires the setup, parameterization, and availability of service instances needed to realize the service chain’s expected behavior to the user. Moreover, it declares the need of establishing the necessary traffic routes (flows) between the user, service instances, and the appropriate provider edge router. The traffic treatment a user’s traffic experiences is called network service. Its functionality can be either visible to or controllable by the customer, or enforced and assigned to particular users or user groups by the network operator. The network operator provides and administers a networking infrastructure and specifies the available network services to deliver to its customers. Finally, a user is a unique networked end-user device requesting access to different types of network services.
III. SERVICECHAININGCONCEPT
The interconnection of service instances, termed service chaining, works by mapping packets to service chains at the edges and forwarding them between service instances. The ser-vice chaining concept proposed here is based on OpenFlow and uses layer 2 addresses to identify service instances as discussed later. The basic approach for integration of per-user service instances in a service chain is depicted in Figure 2. The arrow
Service Instance OpenFlow switch Internet Client / mobile device egress link ingress link
other parts of the network are not shown packet flow
Fig. 2: Service integration into a service chain.
heads depict the direction of the packet flow, whereas sessions are initiated by the user’s device. Each service instance is connected to the network by two links and forwards traffic between these. This requirement can be fulfilled by virtually every network service. For example, an HTTP proxy requires only one interface, but works on systems with two interfaces as well. The ingress link faces in the direction of the user, while the egress link faces away from the user. These links are fundamental reference points for the chaining approach. By identifying the associated link and direction of traffic entering or leaving the OpenFlow network, it is mapped to a user, its service chain instance, and the direction of forwarding. Packets entering the OpenFlow network are modified to meet the forwarding requirements, i.e. packet headers must contain the required information for forwarding the packet to the next service function. Packets leaving the OpenFlow network are modified to meet the requirements of the service instance, i.e. they must contain appropriate layer 2 addresses. Moreover, the isolation of service instances is achieved by filtering network control protocol traffic such as ARP packets.
Linux namespaces1 have been applied here to make the use of one service instance per user feasible for ISP-scale ap-plications under Linux. Linux namespaces introduce a flexible and efficient virtualization approach. Instead of implementing a full-fledged virtualization environment or a completely virtual-ized operating system, several aspects of the operating system can be virtualized separately with Linux namespaces. This allows to mix-and-match the required virtualization features for each use case. Linux namespaces enable, e.g., user, process, and network namespaces. The latter is the fundamental feature that also Mininet [4] relies on. The ability to virtualize only required features ensures a high performance at a low overhead (see, e.g., [12]).
A. Forwarding and Flow Identification
The forwarding concept is inspired by the service chaining approach introduced in [14]. As depicted in Figure 3, layer 3 addressing is used for identification of users and classification of packets at the edges. The router connecting the mobile network to the Gi-LAN2 OpenFlow network is called ingress edge router or ingress router. The router that connects the Gi-LAN to the Internet is called egress edge router or egress router. OpenFlow network / Gi LAN Mobile devices Internet Service node Service node
Ingress edge router Egress edge router Packet classification
(by user IP address)
MAC address-based forwarding
Fig. 3: Overview on the forwarding concept.
Forwarding inside the OpenFlow network is strictly based on layer 2 addresses. While other fields of the packet header could be used for encoding the forwarding information, many existing OpenFlow switches support layer 2 header field rewrit-ing efficiently in hardware, which is often not the case for layer 3 fields. Reference points for the forwarding are the MAC address and port of both the ingress and the egress router. For each registered user, an OpenFlow rule matches the IP source address of incoming packets from the ingress router. The MAC address of the next service instance that the matching packets should pass is written to the MAC destination address field. Forwarding through the OpenFlow network is based on the destination MAC address. When a packet arrives at the last OpenFlow switch before the service instance, the destination MAC address is rewritten to the one required by the service instances and forwarded through the associated port. After the packet is processed by the service instance, it leaves the egress port of the service instance and enters the OpenFlow network again. The incoming port of the OpenFlow switch identifies the associated service chain instance of the packet. Again, the MAC address of the next service instance is written to the destination MAC address field and the packet is forwarded. After the last service instance processed the packet, the MAC address of the egress router is written to the destination MAC address field and the packet is forwarded. Processing packets of flows in the opposite direction is done accordingly. Packets incoming from the egress router are associated with a service chain instance by matching the destination IP address of the user.
While MAC addresses are used for identifying interfaces of service instances, the addresses are generally not learned by employing the well-known approach of a learning switch. Instead, the MAC address of each interface of each service
2Gi-LAN is the interconnection reference point between a mobile network
and the Internet.
instance are learned and disseminated by the chaining control system.
B. Service Instance Interface
Handling packets to and from service instances is done differently than in [14]. Forgoing the use of MAC address learning in the forwarding approach allows filtering of control traffic to and from service instances and thereby enables their isolation: they operate in a completely isolated network environment. Service instances are not able to communicate with other service instances or nodes in the network, the Address Resolution Protocol (ARP) and similar control pro-tocols are filtered. The isolation of the service instances is useful, as a coherent network addressing scheme that spans the whole service chaining system is not required. All service instances use identical IP addresses, which simplifies the deployment process. For example, every service instance can use 172.16.30.2/30 and next hop 172.16.30.1 for its ingress, as well as 172.16.30.4/30 and next hop 172.16.30.5 for its egress interface. MAC addresses are discovered and disseminated in the system as required by the control plane. Appropriate service instance network behavior is either implemented by statically configuring the routes and MAC addresses for the egress and ingress interfaces or by implementing a dynamic routing mechanism and ARP handling module in the adaption layer using OpenFlow.
Depending on the service function, the characteristics and requirements of service instances can vary. Five types of ser-vice instances are identified as outlined in Table I. The network behavior and information loss for each packet during the processing is different for each type and listed in the column ”User→Internet: modified fields” in Table I. The requirements for incoming traffic are listed in column ”In: requirements”. For illustration, the packet modifications that are applied on packets received by the OpenFlow switch from the instances egress interface are listed in column ”Egress out: applied modifications”. Corresponding modifications are applied to packets forwarded to and from the ingress interface. The service chaining system needs to know the service function type of each service instance. The column ”Sharing possible” indicates, whether a service instance of the corresponding service type could be shared by multiple users when using the flow identification scheme of the described system. Additional service function types could be added, the list is not exclusive. A traffic shaping service can be implemented based on layer 2 bridging. This forwarding mode ensures that passing packets are not altered in the service instance; this type is called L2. However, if an incoming packet is addressed at the MAC address of the switch, it is not forwarded but processed locally and subsequently dropped. Therefore, the type requires incoming traffic to not be addressed at the MAC address of one of the interfaces of the service instance; they are rewritten to the one of the edge router that should be passed next on the way to the destination. A firewall service can be implemented based on routing. Incoming packets are addressed at the layer 2 address of the incoming interface, filtered, and forwarded to the next hop as configured in the routing table. The layer 3 information remains unchanged, but both the source and destination MAC address are rewritten during the forwarding process; this type is called L3. For this service type, as
TABLE I: Overview on the types of service instances and their characteristics.
Type Forwarding In: requirements User→Internet: modified fields Egress out: applied modifications Sharing possible Example
L2 briding MACdst6= MACif none none yes Traffic shaper
L3 routing MACdst= MACif L2 src,dst L2src= MACingress edge, L2dst= MACnext instance yes Firewall
L4dst routing MACdst= MACif L2 src,dst; L3,L4 dst type L3 modifications yes Redirect
L4src routing MACdst= MACif L2 src,dst; L3,L4 src L3src= IPuser+ type L3 modifications no NAT
L7 proxying MACdst= MACif L2,L3,L4 src,dst type L4srcmodifications no HTTP proxy
well as for types L4src,dst and L7 the requirement is that the MAC address of the incoming packet matches the one of the incoming interface. However, when a packet leaves the service instance, it contains the wrong source and destination MAC address. The destination MAC address is rewritten after every service instance as required by the forwarding system; the source MAC address is rewritten to the one of the opposite edge router.
Redirection changes the destination IP address and layer 4 destination port, the corresponding type is called L4dst. No information that is relevant for the forwarding system is changed; hence no processing in addition to the one of type L3 is required. When using Network Address Translation (NAT), the layer 3 source address and layer 4 source port in the packet header are modified. This service instance type is called type L4src, while the service instance has to be treated like one of type L7. Service instances implementing an application layer function such as a web proxy are based on routing, too. In addition to that, the transport layer connection coming from the user’s device is terminated by the proxy and a new connection to the requested web server is created. Therefore, after being processed by the web proxy, the packets layer 2, 3, and 4 headers are changed; this service instance type is called L7. Packets leaving the egress port contain the correct destination IP address, but not the source IP address required by the forwarding system. Hence, the IP address of the user is written to the source address field.
IV. ARCHITECTURE
The system architecture is based on the OpenFlow ref-erence architecture [8] introduced by the Open Networking Foundation. As depicted in Fig. 4, the three major layers are the infrastructure layer, the control layer, and the application layer. While the infrastructure layer consists of the actual OpenFlow devices, the control layer contains the control-plane logic. However, the layer should not process application logic data but strictly network-related information. The Service Function Chaining Router (SFCR) module is located in this layer, while the business logic is located in the application layer, where the Service Function Chaining Controller (SFCC) module is located.
The high-level, modular architecture for the proposed SDN-based approach is depicted in Figure 5. The data flow is depicted as a double line, where connections originate at the mobile user, cross the wireless network as well as the Gi-LAN and are forwarded to the Internet. Service nodes are traversed if the selected network service requires the forwarding through the service instances that are hosted on them. Packets arriving from the Internet traverse the path in the reverse direction.
The Service Function Chaining Controller (SFCC) is the central controlling unit responsible for controlling all
sys-Application Layer Control Layer Infrastructure Layer OpenFlow Interface OpenFlow Application
...
SFCR Business Application...
SFCC API Access OpenFlow Protocol OpenFlow switchesFig. 4: Mapping of SFCR and SFCC to OpenFlow Reference Architecture
tem components, maintaining the system state, handling user (de-)registration, service instance allocation, and offering a high-level API as single interface to the service chaining system. The SFCC maintains a permanent connection to the SFCR and all available Service Node Controllers (SNC). The SNCs are responsible for managing one service node and the service instances which are operated there.
When a user connects to the wireless network, it is detected and registered with the SFCC. A default service chain instance is then being created for the new user, thus allocating the needed service instances and requesting the SFCR to install the appropriate network flow rules. After a disconnect event, the previously established service chain instance is destroyed by releasing all service instances and requesting the SFCR to remove the created flow rules. The SFCC offers a high
Mobile User Wireless Network / ingress router
Service Function Chaining Controller (SFCC) SFCR control Network data SFCC control Service Nodes Service Function Chain Router (SFCR) User registration Gi interface Internet Internet gateway / egress router Service Node Controller (SNC) SNC OpenFlow Network High-level API
Fig. 5: High-level architecture of components and their inter-actions.
and remove service chains during runtime. If a service chain is modified, e.g., by adding a service function, for each corresponding service chain instance an appropriate service instance is allocated and inserted. The SFCC orders the SFCR to update the service chain routing by sending information on the ingress and egress port of the service instance, the OpenFlow switch where it is connected, and the type of the service instance. The SFCR then looks up the packet processing that is required for this service instance type and installs the corresponding OpenFlow rules. The SFCR deals with network related abstractions, such as ports, layer 2, and layer 3 addresses only. Furthermore, as it is a passive, stateless component, it operates on commands by the SFCC only. For the OpenFlow devices it acts as a controller and implements chaining of service instances.
Each SNC runs on the service node it manages. It relies on an OpenFlow enabled software switch and multiple service instances. The SNC is responsible for the creation, usage, configuration, and destruction of service instances. Their im-plementation is based on standard Linux features such as traffic shaping and firewalling or other suitable software. Linux network namespaces are used to separate the network traffic of different instances. For each service instance the software switch provides two network ports, establishing a connection between both entities. For each service function that should be available on a given service node, multiple instances are started in advance. The strategy used for pre starting instances can be adapted to the operating environment.
The infrastructure layer consists of OpenFlow switches, both dedicated hardware devices and software switches run-ning on the service nodes. Ingress and egress routers are not required to be OpenFlow enabled. However, their MAC addresses and network ports through which they are connected need to be known to the SFCC, either through configuration or ARP snooping. The service chaining network is transparent to the edge routers. For these, the system is indistinguishable from a direct network link. The mobile network registers and de-registers its users and their IP address to the SFCC through its API.
V. FIRSTRESULTS
The service chaining system has been implemented as a proof of concept and deployed in an OpenFlow-based testbed. The SFCR is implemented as a component for the Floodlight OpenFlow controller3. The other components are designed as standalone programs, relying either on Java or Python for their implementation. Mininet [4] and custom scripts are used for creating service instances.
The infrastructure layer consists of NEC PF5240 OpenFlow switches [7], the ingress router is an Access Point (AP) running OpenWRT, the egress router is a server running Linux, which in addition to routing hosts some of the required websites. The service nodes utilize Mininet [4] and extensions for creating service instances running in Linux network spaces; switching is provided by Open vSwitch4 v1.9.0. The latter supports OpenFlow v1.0 only, therefore this OpenFlow version is used by the service chaining system.
3http://www.projectfloodlight.org/floodlight/ 4http://openvswitch.org/
The SFCC provides a high-level API for the service chain-ing approach. As a proof of concept, both an operator interface and a end-user interface have been implemented based on the SFCC API. They illustrate how the solution may be integrated in an operator’s environment and is further described in [13]. The service instance isolation proves to be advantageous for deployment of service instances of type L3, L4 and L7. Contrary to traditional deployments, neither an IP addressing scheme nor the assignment of unique IP addresses to each service instance is required. Each service instance of type L3 and higher is used with identical network configurations.
The deployed service instances are based on unmodified open source software, which is not aware of the characteristics of its operating environment. The deployment in combination with the service instance type adaptation and the service instance isolation proves to be trouble free. Besides Linux kernel features such as iptables for firewalling as well as redirection, and queueing features for traffic shaping, the usage of third party HTTP proxy software works without problems. Traffic, even when processed by an HTTP proxy is identified and mapped to the associated service in every case. Due to the start of service instances in advance, changing service chains only requires the modification of OpenFlow rules. Therefore, the system’s response time to such modifications is small. An additional advantage of the service instance isolation is its resilience against network misconfigurations. Only the service instances that are directly affected by the misconfiguration do fail. Due to the isolation, no other service instances are influenced.
Evaluated cases are redirection, traffic shaping, and enforc-ing a video quality for HTTP Live Streams (HLS). Redirection is used for implementing a landing page that enables user self-service. Traffic shaping limits the available bandwidth of each user and supports per uses settings. An open source HTTP proxy software5 is customized to modify HLS request headers to enforce the specified video quality. The system reacts to creating and modifying service chains as well as reordering the service functions with low latency. Changing the service quality for HLS video works reliably even for existing streaming sessions.
Based on the assumption of a one-to-one mapping of users to chain instances and therefore service instances, the number of OpenFlow rules increases with the number of users, service instances, and OpenFlow switches in the system. An upper bound for the number of OpenFlow rules in such a service chaining system can be derived as follows. For each user, two rules are required at both edge routers. For each service instance, two rules are required on its attached OpenFlow switch for each of its two interfaces, ingress and egress. Assuming that a user uses each available service function once, the upper bound for the required OpenFlow rules can be derived as follows:
#rules = 2 × #users × (2 + #service functions × #switches) Based on which the maximum number of rules per switch can be easily determined:
#rules = 2 × #users × (2 + #service instances)
Improvement in the rule efficiency is not the goal of this approach and is partly a result of the OpenFlow 1.0 based implementation. Therefore the reduction of the number of required rules is planned in future work. The implementation of the service instance isolation adapter with OpenFlow 1.3 should reduce the number of required rules significantly. Fur-thermore, some of the optimizations introduced by StEERING could be integrated in the approach. Finally, by employing a hierarchical L2 addressing scheme the number of rules can be reduced further on intermediate OpenFlow switches. With this scheme, each service node is assigned a range of virtual MAC addresses. Each service instance is identified in the system by one address from this range, reducing the number of OpenFlow rules for forwarding to the number of service nodes instead of the number of service instances.
VI. RELATED WORK
Network Service Headers (NSH) [10] are a related proach, which, amongst features for routing include an ap-proach for interfacing with service instances. Each packet is added an additional header, which could be used by ser-vice instances for traffic separation. However, this approach requires the network instances software to be aware of its runtime environment. By adding an additional network header to each packet passing through a service chain, an overlay network is created that implements the specified services chains. The approach relies on the proven overlay network concept; however, its main drawbacks are an increased over-head due to the additional over-header that is added to each packet. Furthermore, the approach relies on special nodes to handle the NSH headers and implement the service chaining functionality. Another approach is to implement a similar concept by reinterpreting existing header fields using flow based forwarding and SDN instead of introducing a new packet header. StEERING [14] introduces, amongst other features, an approach to optimize the OpenFlow rule usage by exploiting the OpenFlow pipeline feature. StEERING is geared towards a Gi-LAN scenario and focusses on resource efficiency and scalability. The OpenFlow pipeline feature is introduced in OpenFlow version 1.1, hence, is not available in the scenario this work is based on. However, the optimization feature could be integrated with the approach described in this paper. However, the handling and identification of packets received from and forwarded to service instances is not specified in detail. SIMPLE [9] describes an efficient routing mechanism for connecting service instances and an approach to load balancing service instances. SIMPLE explicitly considers the inclusion of legacy service instances. Therefore, one major contribution of the paper is an approach to tracking packets when processed by service functions that modify the header information. The approach relies on correlating packets before the processing by a service instance and afterwards which does not require modifications or even detailed knowledge of the service instance. However, the approach requires the system to collect packets for the correlation analysis. Furthermore, the approach is rather complex as it requires a packet matching with a high accuracy.
A number of approaches to highly efficient virtualized runtime environments other than using Linux virtualization exist. One example is Mirage OS [6] that is based on the XEN hypervisor. The feasibility for ISP scale applications of
one service instance per used has been demonstrated in [1]. However, these approaches introduce new APIs and cannot leverage today’s abundance of network software available for, e.g., the Linux operating system.
VII. PRELIMINARYCONCLUSION ANDFUTUREWORK
A novel approach to integrate network services into a service chaining system has been presented in this paper. The network isolation of service instances allows a simpli-fied deployment process that requires minimal per-instance configuration. The simplified deployment supports the one-to-one mapping of users to service instances, by which the issue of modified packet headers in service instances can be solved reliably. Furthermore, the isolation approach is able to prepare the packet flows for each service instance as required. By relying on an efficient virtualization approach based on standard Linux features the abundance of available Linux software can be leveraged by the proposed approach. A proof-of-concept implementation demonstrates the feasibility of the approach and the usefulness of its high level API.
ACKNOWLEDGMENT
This work has been supported in parts by Deutsche Telekom (D-Nets project) and the German DFG (CRC 1053, MAKI). The authors would like to thank all their colleagues and project partners and especially Victor-Philipp Negoescu and Sergej Melnikowitsch for their contributions.
REFERENCES
[1] R. Bifulco, T. Dietz, F. Huici, M. Ahmed, J. Martins, S. Niccolini, and H.-J. Kolbe, “Rethinking Access Networks with High Performance Virtual Software BRASes,” in EWSDN Workshop, 2013.
[2] M. Chiosi et al., “Network Functions Virtualisation (NFV),” European Telecommunications Standards Institute (ETSI), Oct. 2013.
[3] W. John, K. Pentikousis, G. Agapiou et al., “Research Directions in Network Service Chaining,” in IEEE SDN4FNS, 2013.
[4] B. Lantz, B. Heller, and N. McKeown, “A Network in a Laptop,” in ACM HotNets, 2010.
[5] N. Leymann, “Flexible Service Chaining. Requirements and Architec-tures.” in EWSDN. Presentation, 2013.
[6] A. Madhavapeddy and D. J. Scott, “Unikernels: Rise of the Virtual Library Operating System,” ACM Queue, vol. 11, no. 11, pp. 1–15, 2013.
[7] NEC, “ProgrammableFlow PF5240 Switch,” http://www.necam.com/ docs/?id=5ce9b8d9-e3f3-41de-a5c2-6bd7c9b37246.
[8] Open Networking Foundation, “Software-Defined Networking: The New Norm for Networks,” Apr. 2012.
[9] Z. A. Qazi, C.-C. Tu, L. Chiang, R. Miao, V. Sekar, and M. Yu, “SIMPLE-fying Middlebox Policy Enforcement using SDN,” in ACM SIGCOMM, 2013.
[10] P. Quinn, J. Guichard, R. Fernando et al., “Network Service Header,” Internet-Draft, draft-quinn-nsh-02.txt, IETF, Feb. 2014.
[11] P. Quinn and T. Nadeao, “Service Function Chaining Problem State-ment,” Internet-Draft, draft-quinn-sfc-problem-statement-03.txt, IETF, Dec. 2013.
[12] M. S. Rathore, M. Hidell, and P. Sj¨odin, “KVM vs LXC: Compar-ing Performance and Isolation of Hardware-assisted Virtual Routers,” American Journal of Networks and Communications, vol. 2, no. 4, pp. 88–96, 2013.
[13] J. R¨uckert, J. Blendin, N. Leymann, G. Schyguda, and D. Hausheer, “Demo: Software-Defined Network Service Chaining,” in EWSDN, 2014.
[14] Y. Zhang, N. Beheshti, L. Beliveau et al., “StEERING: A Software-defined Networking for Inline Service Chaining,” in IEEE ICNP, 2013.
