SRv6—Building Next-Gen Programmable Network Infrastructure
By Yuanwen (Daisy) Sun | Segment routing is not a new concept in the networking industry and it has gained great popularity among service providers around the globe. While service providers are adopting it for the multiprotocol label switching (MPLS) data plane that is deployed extensively in existing networks, there is an increased interest to use segment routing with the IPv6 data plane for network programming (SRv6 network programming). The increased adoption of IPv6 makes it more natural to apply segment routing directly to the IPv6 data plane. There are many use cases that can benefit from the SRv6 network programming concept. Today, 5G is the main driver for fast-paced development of SRv6 standards to simplify the user plane and network plane. Japan service providers are leading the end user requirements for this use case.
Technology Overview
Segment routing uses a source-routing concept. Unlike traditional networks where the forwarding path needs to be setup and maintained by all nodes along the path, segment routing encodes the instruction, called a segment, into the packet itself, and the intermediate node forwards the packet based on these instructions. It removes state from the network and reduces signaling overhead, simplifying the overall network infrastructure.
The IPv6 flavor of segment routing allows user-defined functions to be associated with segments. By leveraging the segments encoded in the dedicated segment routing extension header (SRH), the IPv6 packet carrying the network instructions explicitly tells the network the path it should traverse and the functions to be executed at each SRv6 node. These functions may implement any computable behavior, enabling simplified network programming.
In SRv6, a segment routing identifier (SID) is an IPv6 address. It can be conceptually separated to two parts: locator and function. The locator is the route to the node performing the function. The function can be any possible function bound to SRv6 SID. There can be optional argument bits for a function associated to a SRv6 SID. The bit-length of locator, function, and argument is flexible and can be determined based on the network requirement.
IPv6 SID is encoded in the SRH, a new IPv6 routing header of type 4. Its format is shown in the following image. Segment left indicates the number of segments that are remaining. The segment list is encoded in the reverse order. The first segment contains the last segment of the SR policy.
The IETF SRv6 Network Programming draft defines a set of well-known functions that can be associated with a SID, including:
SRv6-based virtual private networks (VPNs) refer the use cases for SRv6 deployment. The creation of VPNs between provider edge (PE) routers leverage the SRv6 data plane and, more specifically, the END.DT (cross-connect to a VRF) and END.DX (cross-connect to a nexthop). The SRv6 VPN draft defines procedures and messages for BGP SRv6-based Layer 3 VPN and Ethernet VPN.
The following image illustrates how an L3VPN service is delivered over an SRv6 network and packet encapsulation at various nodes in the network:
L3VPN over SRv6 Illustration
The egress PE signals an SRv6-VPN SID with the VPN route. The ingress PE encapsulates the VPN packet in an outer IPv6 header where the destination address is an active SID in SRH. The underlay between the PEs only needs to support plain IPv6 forwarding. To provide best-effort VPN, only a single SID is needed (or no SRH for reduced encapsulation). To provide SRv6-VPN service in conjunction with an underlay service level agreement (SLA), the egress PE colors the VPN route with a color-extended community. The ingress PE encapsulates the VPN packet in an outer IPv6 header with an SRH that contains the SR-TE policy associated with the related SLA followed by the SRv6-VPN SID associated with the route. The nodes along the path will forward accordingly. SRv6 can be deployed only on the strategic nodes. The underlay nodes whose SRv6 SIDs are part of the SRH must support SRv6 data plane. Non SRv6-capable nodes just forward network traffic based on the IPv6 destination address (SID).
SRv6 standardization is progressing rapidly in the IETF SPRING working group and related specific protocol working groups. The latest revisions of some existing specifications are not backward compatible. It seems that the standards are now in a more stable state. We have seen some implementations from leading network equipment manufacturers (NEMs) to support the L3VPN over SRv6 use case. There are more use cases coming, such as EVPN over SRv6.
Test SRv6 with IxNetwork
SRv6 network programming requires multiple technologies that are working together to achieve the purpose of network programming. This includes the underlay network delivering based on SLAs and overlay applications to provide instruction for end-to-end services delivery. It also requires new hardware implementation to process and forward based on SRH header. A thorough test of each component and the integration of multiple components need to be conducted at multiple levels to ensure seamless operation. The performance also needs to be assessed for individual components and at the system level to optimize the overall network capacity and service delivery.
As a test tool provider, Keysight is actively engaged in cutting-edge technology development. We are working with leading NEMs and service providers to help in early development and trial cycles. With Keysight's IxNetwork SRv6 solution, customers can simulate SRv6 networks with many nodes to validate device under test (DUT) functions in different roles (ingress node, intermediate node, and egress node) and assess the performance for both control- and data-plane.
The IxNetwork SRv6 emulation includes both ISIS underlay and BGP VPN overlay. Traffic can be generated based on control-plane information to validate SRv6 forwarding. It also provides a flexible packet builder with a rich library of templates of protocol header encapsulation. Users can craft raw SRv6 (includes SRH) traffic streams with the build-in SRH header template to validate hardware implementation before any software integration.
The following is an illustration of testing ingress PE by using the topology from the previous section:
- DUT is ingress PE1. Keysight emulates P1, P2, and egress PE2 connected to PE1 in a ring topology. Ingress PE1 can reach egress PE2 through either P1 or P2. IxNetwork also emulates CEs connected to Ingress PE.
- Egress PE advertises VPNv4 routes with an SID bound to DT4 function, VPNv6 routes with an SID bound to DT6 function. It also colors the VPNv6 route yellow for underlay SLA.
- Emulated CE sends VPNv4 and VPNv6 traffic.
- Ingress PE1 encodes SRH with SID bound to END function (shortest path) for best-effort VPNv4 traffic, followed by VPNv4 SID learned from egress PE2.
- Ingress PE1 has an SR-TE policy learned from SDN controller to deliver VPNv6 traffic through underlay path colored yellow to meet SLA. It encodes SRH with SIDs of yellow path followed by VPNv6 SID learned from egress PE2.
- Validate ingress PE1 properly encodes and forwards the best-effort traffic and the SLA traffic.
- This can be scaled-up easily with many P and PE routers for scale and performance testing.
IxNetwork SRv6 Emulation
The preceding image is just an example of an SRv6 test. There are many test scenarios that need to be exercised for complete validation of SRv6 implementations. The good news is that Keysight can help you validate the SRv6 devices and SRv6 networks under realistic network condition. For more detailed specification of SRv6 support, see the IxNetwork SDN datasheet.