Interested in learning more about network functions virtualization and network virtualization? Be sure to check out our pages on Network Service Chaining, Security Virtualization, and Micro-Segmentation & Visibility.
Subscriber aware service function chaining (SFC) refers to the ability to associate traffic with a customer while making appropriate traffic related networking decisions. Subscriber awareness in the network layer interconnecting virtual network elements benefits operators by
- Providing unprecedented visibility into the network across elements interconnected using the SDN fabric
- Enabling delivery of personalized services by leveraging functions in the network
- Increasing security by identifying and isolating flows as needed
Subscriber Awareness is not a new concept, but was difficult to implement till now. However this has changed with the advent of NFV and SDN. SFC is a more recent development and that too has gained interest due to virtualization. SFC addresses networking challenges created when middle-boxes like firewalls, spam filters, DPI elements, etc., are virtualized. Next generation SDN solutions designed for service provider networks today bring these concepts together. To understand the benefit of this it is essential to step back and look at the shortcomings of existing networking and middle box functions. Further it is best to look at this in the context of a use case. For this article we will consider the Gi-LAN use case.
Subscriber Aware Service Function Chaining in Gi-LAN
A major shortcoming in the IP networking infrastructure is that networks created are relatively static and optimized for traffic forwarding. While this was OK in the past, in today’s largely physical networks, it is very common for operators to deploy middle boxes for advanced services, such as firewalls; content filters and optimization mechanisms; deep packet inspection (DPI); caching; etc. These functions are usually deployed as appliances on proprietary hardware and installed in the data path at fixed locations in or at the edge of the carrier core network. As a major example of service chaining in operator networks, consider the Gi/SGi interface is the “reference point” defined by 3GPP between the mobile packet core and packet data networks (PDN). Typically functions deployed at this point are middle-boxes and do not use the traditional client-server, destination based forwarding paradigm of IP and Ethernet. Rather, traffic flows through them in a sequence. They are often implemented as logical or physical “rails” with all bearer traffic going through all of them.
Today, as pointed out by the SFC WG Problem Statement, middle box functions are deployed using network topologies that serve only to “insert” the service function (i.e., a link exists only to ensure that traffic traverses a service function). These “extra” links are not required from a native packet delivery perspective. As more service functions are required (often with strict ordering), topology changes are needed before and after each service function, resulting in complex network changes and device configuration. In such topologies, all traffic, (whether a service function needs to be applied or not), often passes through with the same strict order. The topological coupling limits placement and selection of service function) service functions are “fixed” in place by topology and, therefore, placement and service function selection taking into account network topology information is not viable. Moreover, altering the services traversed, or their order, based on flow direction is not possible.
Further, many middle-box functions such as firewall, NAT, TCP optimization, are flow state dependent. The flow state, which is derived in the initial traffic direction, such as a TCP SYN, must also be used to apply treatment in the opposite direction. Therefore, the same network element must process the bidirectional traffic for all flows that it is servicing. Maintaining this bidirectional requirement is critical to the functionality of these elements. In other words, several middle box functions have endpoint affinity.
In summary when designing (virtual or physical) networks for interconnection of a chain of middle boxes, two main factors to keep in mind are:
- Order of function traversal
- Bidirectional flows in order to provide service for all functions
These deployment considerations can make middle box networking very complex, especially in service provider networks given both the very large number of endpoints (subscribers) and the exploding traffic volumes. In this environment, designing, operating, and maintaining a network for middle boxes with high availability can prove particularly challenging,
These considerations lead to a network design depicted in Figure 1, where subscriber endpoints are first “routed/switched” onto manageable “rails” (something the elements and load balancers can accommodate).
Figure 1 – Typical setup of rails of middle boxes on Gi-LAN
In the architecture depicted in Figure 1, there is a distribution of networking information (or states) in several points. This becomes a useful consideration when we discuss the transition to NFV.
It should also be pointed out that the example here in Figure 1 only considers the traffic in one direction, however the networking needs to be setup in a bi-directional manner.
Subscriber aware service chaining by leveraging a mapping service (extension to the Network Virtualization Authority and LISP mapping) allows subscriber traffic flows to be identified individually and steering decisions are made about which function instances (of a middle-box) that will process based on that particular users traffic flow. The mapping layer maintains state (affinity) information, which was distributed inside of each physical load balancer in Figure 1. The Mapping Service nodes serve as a repository of data on endpoints (flows detected at ingress), virtual network functions, policy and management. They are interconnected via the overlay network and serve to federate the controllers into a single logical entity. At every function hop, the mapping service is used to steer traffic on a per subscriber basis to the next hop.
Figure 2 – Subscriber Aware Service Function Chaining
This architecture helps operators implement policy across the entire service chain with customization leading to better utilization of resources. Subscriber aware service chaining also makes it much easier to introduce new functions, hence improving the agility of new service rollout.