Network Function Virtualization – Service Chaining
There are many different perspectives on Network Function Virtualization (NFV) and Software Defined Networking (SDN). It really depends on who you ask and what side they lay on – server or network departments in either the service provider, data centre or branch. I personally view SDN to be in the data centre/WAN and NFV anywhere at the network edge? While the use case for NFV varies from enterprise, service provider and branch requirements, it’s really about simplifying management and orchestration. NFV enables you to bring network services that used to be at the customer edge to the nearest POP or data centre to run on a virtualization environment. For example, a newly installed CPE obtains its configuration from a PnP server, a tunnel (VXLAN, GRE, LISP, IPSec or Layer 2) can be created to local POP consisting of, for example, vCPE, vFW or vESE virtual services. MP-BGP is then used across the SP WAN for route propagation to the data centre.
The whole idea of enabling on-demand service and chaining application flows is a key driver for NFV. NFV will have the ultimate impact of how managed services are provided and it will transform networking as we know it. A big use case for NFV is virtual managed services; the managed service landscape is changing.
Network Function Virtualization – Service Chaining
Service chains are policy constructs that provide the ability to forward packets through a series of service nodes. Services nodes may be firewalls, load balancers, intrusion detection devices, and virtual email security agents. For example, let’s say we want to add a stateful packet engine to an application flow. In a traditional case, we would usually have to implement a physical or virtual firewall as the default gateway. All traffic leaving the host will follow its default gateway and traffic gets inspected. This type of design is a typical topology dependent service chain. What if you need to go one step further and add a number of service devices to the chain? for example, an IPS or load balancer. This will soon become a complicated design and complexity comes at a cost in the sense of troubleshooting and maintenance.
Current service chaining is static and bound to topology for insertion and policy selection. One of the major drawbacks is that network service deployments are tightly coupled to the network topology. This limits network agility, especially in a virtual environment. They are typically built through manual configuration prone to human error. Existing technologies used for service chaining are policy based routing (PBR) and VLAN stitching. They lack end-to-end service visibility and troubleshooting is complicated. PBR is configured per box, per flow, and autonomous routing protocols do not understand it. PBR breaks routing. If you have to run traffic through some network service, you usually build that chain statically but in a data centre that is using a lot of multi-tenancy and is highly segmented you need to route traffic in a much more flexible way. Traditionally, implementing network services and security policies into an application network has been complex. Implementing service nodes into an application path, independent of location has been a challenge for many data centre and cloud providers.
The concept of service chaining was originally seen in the Nexus 1000V virtual switch. It implements a service chaining technology, known as vPath. vPath provides traffic interception and re-routes to the required service node. It originally lacked in the sense that it could only service chain one service at a time and for one type of device, the Virtual Security Gateway (VSG). It was later expanded to service multiple workloads between multiple service hops. While vPath was a success, it could only work with virtual nodes. A solution was needed to enable physical and virtual nodes to be in the virtual chaining path.
Network Service Header (NSH)
Cisco has developed the Network Service Header (NSH). It creates a dedicated service plane to be independent of the underlying transport networks. It is inserted by a node into encapsulated packets or frames, usually at ingress and describes a series of service nodes a packet should be routed. It also adds additional metadata about the packet. The packets are then encapsulated in an outer header for transport. The traffic is sent via an overlay to the Service Function Forwarder (SFF) that looks at the service path header, which tells it what service need to be applied at the particular chain. NSH requires NSH aware nodes i.e front end service nodes, but it doesn’t require any change to the transport network. The SFF is an NSH aware forwarder in front of the service node.
The SFF only needs to know how to do a simple lookup and ask for a location. The locator can be delivered via SDN controller ODL, LISP, and BGP. Because the control and data plane is decoupled, it is simplified. The abstraction between control and data plane allows you to build more complicated (scale and topology) service chains with NSH rather than using flows. It creates a flexible service plan. While the need for service chaining is not debatable, there has been some criticism about NSH, Greg and Ethan have a very good podcast debating the need for Network Service Header.