SRv6 has many use cases, with service chaining as one of the leading ones.
In fact, many operators are moving away from the static and rigid service chains based on VLANs and MPLS to more flexible methods such as segment routing.
Nevertheless, this topic is essential as 5G and NFV require a more flexible, dynamic, and agile way of service chaining, which SRv6 can implement easily.
So it is essential to understand service chaining in SRv6.
This article attempts to explain SRv6-based service chaining in simple language. It starts with an overview of Service function chaining and then explains the concept with an example of how packets are forwarded in such a chain.
What is Service Function Chaining ( SFC)?
Service Function Chain (SFC), as the name shows, is a sequence of service functions connected in the traffic path. Each function does a specific job, such as load balancing, firewall, IDS, etc. Usually, they are co-located as traffic pass through these functions one by one.
An example of service chaining is shown in the figure below. The traffic in this service chain passes through a firewall, then an IDS, and finally a NAT function.
Fig: What is a service chain
As you may have probably guessed, such kinds of service chains are neither efficient nor flexible. Modifying such chains is difficult as it needs physical re-wiring. Tagging-based methods such as VLANs and MPLS can bring some flexibility, such as running multiple service chains on the same physical box but still, all traffic pass through every box whether the traffic is processed by that box or not.
A better architecture is proposed by IETF that includes Network Service header (NSH) along with Service forwarding function ( SFF), which enables flexible network service chains.
SFC Architecture:
The Internet Engineering Task Force (IETF) has introduced a new method for implementing service function changing (RFC 8300), which uses Network Services Headers (NSH).
NSH is an SFC forwarding protocol; it ensures traffic is forwarded to a specific service function. It consists of a header added to the traffic before it passes through the service chain.
SFC architecture, according to RFC 7665, is shown below. It includes classifier, Service Function Forwarders (SFFs), SFC Proxies, and Service Functions (SFs).
Fig: SFC Architecture ( RFC 7665)
The following describes the role of each:
Classifier: It classifies traffic by adding relevant NSH headers to the packets.
Service function forwarder (SFF): responsible for routing traffic to one of the services
Service Function (SF): This is the actual service function such as firewall, Deep Packet Inspection (DPI), IDS, etc.
SFC Proxy: if the service function doesn’t handle NSH, then the SFC proxy can help process NSH and is needed before the service function.
SRv6 Service Chaining
It will be good to discuss how SRv6 implements service chaining using the IETF SFC architecture.
It is possible to use the NSH method combined with SRv6 in such a way that the NSH header is used for service identification and SRv6 for the transport part. However, this requires additional protocol headers as well as keeping the NSH state maintained in every node.
Advantages of SRv6 for Service Chaining
A better method is to use SRv6 as a standalone method for service chaining and take advantage of its stateless nature. Considering SRv6 can assign a SID identifier list to packets, this means that using SRv6 does not require NSH or a specific classifier, as any SRv6 node can work as a classifier. In short, SRv6 can provide service chaining in a much simpler and lighter way for the network.
In SR, the forwarding path can be easily inserted by the ingress router using a sequence of SID labels. A different set of SID labels can indicate different service chains. An SDN controller can dynamically insert the SID labels on the type of traffic and the desired service chains.
An SRH ( Segment routing header) is shown for SRv6. The SID labels indicate different service functions. These SID labels can be dynamically assigned to a different kind of traffic to make two service chains in this example.
On the left side, a packet is assigned based on different SIDs to a service chain IDS > FW > DPI, and a second packet on the right side is assigned to a service chain FW > DPI
Service Aware versus Service unware functions:
Service functions can be classified into two types. They are either SR aware or SR unaware. An SR-aware function can read and process SRv6 packets. In contrast, an SR unaware function does not know about the SR and operates solely based on the IPv6 header. One such example is a legacy service function that was initially designed to work with the network that did not support SR. Such kind of SR unaware functions will require an SFC proxy in the middle to strip off headers and send just a payload to the service function.
An example will clarify this:
SFC forwarding example in SRv6
In this example, it is desired to pass the traffic through two Service functions-SF1 and SF2. However, SF1 is SR-unaware, while SF2 is SR-aware. Here is how packet forwarding will work. ( It is recommended to go through our foundation blog titled “SRv6 Tutorial-An Easy Guide to how SRv6 works?” for a quick refresher on how SRv6 traffic is forwarded)
Fig: SRv6 SFC packet forwarding example
1. S1 acts as a classifier of SFC. In step 1, S1 adds two headers- an IPv6 header(IPH) and an SR header (SRH). SR packet header defines the service chain path, i.e., SFF1, SFF_Proxy:: SFI, SFF2, SF2.
SFF1 will be at the bottom of the stack as it is the next segment. As SF1 is SR unaware, so it will not be part of the SIDs stack. However, to solve the SF1 reachability problem, we added an SFC proxy between SFF1 and SF1. SFC_Proxy::SF1 means that SF1 is not directly reachable but can be reached through SFC_Proxy. Segments Left (SL) is set to 3, which is one less than the number of segments, and at every segment, it is decremented by 1.
2. Once the packet reaches SFF1, the latter finds the DA as its own SID, so it will change the DA to SFC_Proxy::SFI and send it to SFC Proxy The SFC proxy will strip off the headers for IP and SRH and send the payload to SR unaware node SF1. Once SF1 processes the packet, it will send the packet back to SFF1
3. SFF1 will add IPv6 and SRv6 headers and also set SFF2 as the next destination
4. SFF2 will receive the packet and send it onwards to SF2 by changing the DA to SF2. SF2 is SR aware and will have no problem processing the packet and sending it back to SFF2. But as SL=0, so SF2 will remove the SR header and send it as an IPv6 packet to SF2. SF2 will remove the IPv6 header and send the payload to the end user.
This completes the service chain.
SRv6 service function chaining on a P4 programmable switch brings more benefits.
Running SRv6 service function chaining over the P4 programable switch (such as Intel Tofino), which has a stateless nature, brings even more benefits than using SRv6 over an IP router.
An example of one such platform is Lanner’s HTCA Platform, which has a small footprint, is geared for edge application, and uses Intel Tofino-based P4 programmable switch power supply.
When combined with the partner‘s NoviFlow‘s NoviFabric, Lanner’s HTCA becomes a powerful service chaining platform for edge applications.
NoviFabric can work as an SRv6 proxy, so if VNFs do not support SRv6, they can still be service chained.
Edge needs to run several applications, including switching, routers, packet brokers, and RAN but also security services like DDoS, firewall, IDS, etc.
Running all these applications at once can cause scalability issues. That is where Intel’s Tofino programmable switches can help by offloading some of the workloads from the blades.
NoviFabric uses SRv6 for stateless service chaining of security functions and adds packet brokering, load balancing, and networking telemetry within the same switch blades without requiring dedicated compute resources.
Fig: Noviflow Novifabric on Lanner white box ( Ref: Noviflow )
The result is a high-performance, easy-to-use, and all-in-one MEC platform that would require multiple functions and boxes if they were not combined into one device. It can significantly reduce CAPEX and OPEX costs for telecom companies.
About Lanner white box solutions:
Lanner is a leading manufacturer of white box solutions, and UCPEs, suitable for telecom applications like Software Defined Networking (SDN), Network Functions Virtualization (NFV) SD-WAN, Radio Access Networks (RAN), core, edge, orchestration, security, etc. Lanner operates in the US through its subsidiary Whitebox Solutions ( whiteboxsolution.com).
Lanner offers pre-validated VNFS from its partner ecosystems that help accelerate time to market for network operators.
