Service function chaining (SFC) is one of the essential functions in a service provider environment. Traffic in data centers passes through various middlebox functions like firewall, Intrusion Detection System (IDS), Deep Packet Inspection (DPI), Network Address Translation (NAT) that process packets and thus form a chain of services. Hence the name service function chaining or service chaining.
The service function set in a service chain depends on the service context and thus forms a virtual network.
However, today’s service chains are inflexible, rigid, and difficult to modify, as we explain in the next section.
We show you how operators implement the service chains today, their pros and cons, and contend that the latest way of using SRv6 is the most efficient and optimum way to implement service chains (virtual networks).
Further, implementing SRv6 on P4 programmable switches such as Tofino-based white box can provide an all-in-one solution with additional value-added functions beyond service chaining that general-purpose switch ASIC cannot offer.
However, to appreciate SRv6-based service chaining, we need first to understand the traditional way of service chaining.
While there are many methods of service chaining, we describe the popular three methods.
Method 1: Traditional Inline Service Chains
The traditional and easier way to implement a service chain is the “inline” method which is also called the “bump-in-the-wire” method. The middleboxes sit one after the other “inline” in the traffic path. Operators often use VLANs or other overlay technologies like MPLS to keep the traffic separate among multiple logical service chains.
This method is a straightforward and quick method for a service provider to implement the service chains and is thus popular among the operators.
Though it is not an efficient way:
First, the traffic passes through all the middleboxes even though certain packets may not need processing at a particular middlebox stage. So this can quickly run into scalability issues as all the middleboxes need to be scaled simultaneously; thus the solution is not CAPEX friendly.
Second and most importantly, the service chain is static by nature. Changing the order of the middleboxes is operationally complex. Network operators are hesitant to change the service chains for fear of misconfiguration or outage.
Thus, once a service chain is implemented, it remains the same for a longer time.
Service Chaining using inline Method
|
Inline-Service Chaining |
Pros | Cons |
| ● Initial rollout is easy. | ● Static configurations.
● Changing service chains is complex ● Scalability issue because all traffic pass through every function |
Method 2: Service Function Chaining using NSH ( Network Services Header)
IETF introduced a new way to implement Service function chaining ( RFC 8300) using NSH (Network Services Header). Which solves the “static” problem of the service chains as described in method 1 above.
NSH is an SFC forwarding protocol; it ensures that traffic is traversed to a particular service function. It includes a network header inserted into the traffic before traffic is passed to the service chain.
A simple architecture below shows new functions.
Service chaining using NSH
Classifier: Determines which traffic requires services and classifies them by adding relevant NSH header to the packets.
Service Function forwarder ( SFF): Responsible for delivering traffic to one of the connected service
SFC Proxy: If the service function does not support NSH ( Network service header), the SFC proxy in front of it can process the NSH on behalf of it.
Thanks to the flexibility of NSH, operators can easily create and change service chains as per business requirements instead of the fixed sequence static service chains of the earlier method.
Also, the SFC proxy ensures that any non-NSH-aware function can be a part of the service chain as the SFC proxy faces the service chain and not the service function ( IDS in this example).
Moreover, NSH is independent of transport. It can be carried in MPLS, Ethernet, and GRE, etc.
|
NSH-based Service Chaining |
Pros | Cons |
| ● Transport Agnostic
● Flexible service chains |
● May need an SFC proxy for legacy service functions that do not support NSH
● SFF are stateful. Keeps per path state of the service function. Stateful functions are comparatively less scalable than stateless functions |
Method 3: SRv6-based Service Chaining
SRv6 is the latest and most efficient way of Network service chaining.
Segment Routing (SR) is an architecture based on source-based routing, which can be used with MPLS or IPV6. It steers packets through an ordered list of segments. In other words, the source router chooses a path and encodes it in the packet header, like an ordered list of segments.
In the case of SRv6, these segments are identified by 128 bits IPV6 addresses, also called Segment ID ( SID). Currently, work is in progress in IETF to define a shorter version of SID called uCID with a length of 16 bits.
Segment routing is stateless, therefore, lightweight, and thus beneficial. The router does not need to keep the state of the service chains. The state is in the packet itself.
An SRv6 capable router can interpret the SIDs and route the packets accordingly.
As shown below, the two different chains are created easily through the desired sequence of SIDs. The classifier and SFF are nothing but SRv6 capable routers.
If the Service function is SRv6 aware, it can become natively part of the chain. If SRv6 is unaware, an SR proxy will be needed in front of the service function to route the traffic to that service function.
Service chaining using SRv6
|
SRv6 based Service Chaining |
Pros | Cons |
| ● Stateless service chains; thus, highly scalable
● Flexible service chains |
● Needs SFC proxy for legacy service functions that do not support SRv6 |
SRv6 service chaining on P4 programmable switch brings further benefits.
While SRv6 is a preferable option for service chaining because of its stateless nature, running it over the P4 programmable switch ( such as Intel Tofino) can bring even more benefits.
One such example is Lanner’s HTCA Platform, which is a highly compact and edge-friendly platform. It offers different types of compute and switch blades, including a P4 programmable switch blade based on Intel Tofino.
Lanner’s HTCA, when combined with the partner’s NoviFlow’s NoviFabric, becomes a powerful service chaining platform for edge applications.
Edge needs to run multiple applications like switching, load balancers, packet broker, RAN, Core apps, etc. In addition, to meet security requirements, traffic needs to pass through security service functions like DDoS, Firewall, IDS, etc
Running all these applications on compute can result in scalability issues. That is where Intel’s Tofino programmable switch can come to the rescue by offloading some of the workloads to the switch blade.
NoviFrabric utilizes SRv6 for stateless service chaining of security functions, as well as takes the power of programmable switching to add packet brokerage, load balancing, and network telemetry within the same switch blade without requiring dedicated compute resources.
Lanner’s white box with Noviflow’s NoviFabric ( Ref: NoviFlow)
The result is a highly compact, feature-rich, and all-in-one MEC platform that would otherwise need multiple functions and boxes. This can tremendously save CAPEX and OPEX for telco operators.
About Lanner:
Lanner is a leading manufacturer of white box solutions and uCPE suitable for telecom applications like SDN, NFV SD-WAN, RAN, Core, Edge, Orchestration, security, etc. Lanner operates in the US through its subsidiary Whitebox Solutions ( whiteboxsolution.com).
Lanner provides pre-validated VNFs from its ecosystem of partners that accelerate time to market for service providers.
