Network Function Chaining

To achieve consistent terminology in this thesis and avoid confusion we refer to the concept discussed in this section as network function chaining. The term network service chaining is often used in literature to denote the same concept. However, it predates the widespread adoption of NFV in academia, and was, e.g., used in our original publications [Ble+14;Ble+15a]. We use the newer NFV terminology to discuss the relevant components. The terminology is oriented on the terminology of the ETSI [ETSI18]. It is adapted for readability in this context and restricted to the relevant terms.

Network services can be created through the combination of VNFs. To achieve that, network traffic has to be identified at the edges of the data center to become subject of

5.2 ��������� ��� ��� ����� 87

a network service. Then, the traffic is forwarded through a chain of VNF instances to implement the service. In this context, the traffic routing between the VNF instances does not rely on traditional routing or switching. Instead, depending on the network service’s requirements for network traffic, it is forwarded in arbitrary patterns at the discretion of the network service designer. This traffic forwarding scheme is called network function chaining.

Edge Data Center

NFVI NFVI

Data center edge switch Data center edge switch

Packet classification (by subscriber IP address)

MAC address-based forwarding

ISP Core Network Subscriber

NFVINFVI NFVINFVI NFVINFVI

NFVINFVI

!

Figure 5.2: Network function chaining scenario (adapted from [Ble+14]).

An example of an edge data center that uses NFV is depicted in Figure5.2. The ISP in the depicted example provides a mobile Internet access service to its subscribers. The service includes, besides a subscriber gateway function , a firewall and a deep packet inspection function . The security network service is implemented by forwarding the customer’s traffic first through a subscriber gateway VNF instance to establish the subscriber’s plan that includes, e.g., enforcing a traffic volume limit. Then, the traffic is forwarded through a firewall VNF instance to block unwanted connections from the Internet and through a deep packet inspection VNF instance to prevent that, e.g., voice over IP (VoIP) is used over the data connection as many mobile operators do today. The first VNF instance is configured to the specific needs of the customer and is, therefore, a dedicated VNF instance that is operated only for a specific customer. Both, the firewall and the deep packet inspection VNF instances, are not specific to one subscriber. The mobile network access service used in the example is created by a network function chain, which defines an order of VNFs the traffic traverses. The specific chain that is implemented in the data center for a specific customer is termed network function chain instance.

The traffic of the customer is identified by one of the ISP’s edge switches. It is tagged there and then forwarded through the VNF instances as required by the network service. All services in the edge data center that use NFV rely on the network function chaining application. Therefore, in the edge data center network’s control plane, the network function chaining operates at the highest priority. The only other control

plane application with the same priority is the fabric application that provides basic connectivity.

Different approaches to implementing network function chaining exist, with different performance and usage characteristics. One central aspect of network function chaining is the identification of network packets after a VNF has processed them. The issue is caused by the fact that in many of today’s architectures, a single VNF is designed to service many network function chain instances at the same time. Therefore, an identification mechanism is required to identify packets of a specific network function chain instance after they have been processed and the packets’ contents have been potentially modified.

Many existing approaches exist on how to approach this issue. Network service headers introduce a new network protocol that is used by intermediate switches, virtual switches, and VNF instances to keep track on the traffic flows, their affiliation, and their path through the available VNF instances [RFC8300]. However, the design requires the implementation of a new, complex network protocol on every component in the system.

The protocol is not available today in all devices, e.g., it is not supported by OpenFlow.

StEERING [Zha+13] is a function chaining approach that was specifically introduced and optimized for OpenFlow. However, it does not address the packet identification problem stated above. SIMPLE [Qaz+13] addresses the issue, and while the proposed solution seems promising, it is complex to implement. Therefore, we propose to use network interfaces for traffic identification [Ble+14]. Network functions signal the function chain instance, as well as the direction a packet is forwarded in that chain instance, by sending packets out a specific network interface.

While the approach solves the described problem elegantly, it requires the modification of many flow entries in case of an NFV infrastructure device failure. This is caused by the fact that for every VNF instance, a set of flow entries must be installed on the NFV infrastructure device to which the subscribers of the failed device are moved to. The number of flow entry additions can lead to a performance bottleneck of the flow table memory interface of the virtual switches the subscribers are moved to. The income of ISPs often directly depends to the availability of their network access service. Therefore, moving the network function chain instances for the subscribers affected by the failure to a new NFV infrastructure server is time critical.

We will investigate the performance bottleneck characteristics, and the information required by the network function chaining control plane application. Furthermore, a strategy for mitigating the performance bottleneck is investigated. Specifically, we identify the data center ToR switch that connects the virtual switch of the VNF infrastructure device to the data center fabric as having a low flow entry addition load. Therefore, we investigate the efficiency of applying mitigation strategy 3 to the network function chaining application. We do so by shifting a part of the flow entry addition load from the virtual switch to the ToR switch to decrease the total failover time and thereby increase the application’s reliability.

5.2 ��������� ��� ��� ����� 89