Understanding SRv6: Concepts, Standards, and Industry Progress in the New Era of IP Networking

This article is the first lecture in the “SRv6 Technology Classroom Series,” and subsequent updates on various dimensions of SRv6 technical details will follow. Feedback and corrections are welcome.

01 Basic Concepts of SRv6

Since SR MPLS is already widespread, it’s believed that everyone has a sufficient understanding of the basic concepts of Segment Routing. Here, we focus on the unique working principles and related concepts of SRv6.

1.1 SRv6 Segment

Unlike the Segment of SR MPLS, the Segment of SRv6 is 128 bits and is divided into three parts:

1. Locator: An identifier assigned to a network node within the network, used for routing and forwarding packets. Locators have two important properties, routability, and aggregation. In SRv6 SID, Locator is a variable length part to accommodate networks of different scales.

2. Function: An ID value assigned to the local forwarding instruction on the device, which can be used to express forwarding actions that the device needs to execute, similar to the opcode of a computer instruction. In SRv6 network programming, different forwarding behaviors are expressed by different function IDs. To some extent, function IDs are similar to MPLS labels, used to identify a V** forwarding instance, etc.

3. Args: Parameters needed for executing forwarding instructions at runtime, which may include flows, services, or any other related mutable information.

From the composition of the SRv6 SID, it has both routing and MPLS forwarding attributes, allowing it to combine the advantages of both forwarding technologies.

1.2 SRv6 Extension Header

To implement SRv6 forwarding in IPv6 packets, an SRv6 extension header (Routing Type 4) called the Segment Routing Header (SRH) is introduced, used for segment programming and combining to form an SRv6 path.

Figure 2 is the packet encapsulation format of SRv6. The green is the IPv6 header, the brown part is the SRH, and the blue is the payload.

IPv6 Next Header field value is 43, indicating that the following is an IPv6 routing extension header. Routing Type = 4, indicating it is the SRH routing extension header, with field explanations as follows:

1.3 SRv6 Three-Layer Programming Space

SRv6 has more powerful network programmability than SR-MPLS. The programmability of SRv6 is reflected in the SRH extension header. SRH contains a three-layer programming space:

The first part is the Segment List. As mentioned earlier, it can combine multiple segments to form an SRv6 path, similar to the MPLS label stack.

The second part is the 128-bit usage of the SRv6 SID. As is well known, MPLS label encapsulation is mainly divided into four segments, each of a fixed length (including a 20-bit label, 8-bit TTL, 3-bit Traffic Class, and 1-bit bottom of stack flag). A Segment in SRv6, being 128 bits long, can be flexibly divided into multiple segments, with each segment’s length also variable, providing flexible programmability.

The third part is the optional TLV (Type-Length-Value) immediately following the Segment List. While transmitting packets in the network, some non-standard information needs to be encapsulated in the forwarding plane, and they can be completed through the flexible combination of TLV in the SRH.

With the three-layer programming space, SRv6 possesses more powerful network programmability, better meeting different network path requirements.

1.4 SRv6 Packet Forwarding Process

Figure 4 shows an example of SRv6 forwarding. In this example, node R1 needs to forward to R6 through a specific path (via R2-R3, R4-R5 links), where R1, R2, R4, and R6 are SRv6-capable devices, while R3 and R5 do not support SRv6.

Step 1: Ingress Node Processing: R1 encapsulates the SRv6 path information in the SRH extension header, designates the END.X SID of R2 and R4, initializes SL = 2, and copies the SID A2::11 indicated by SL into the outer IPv6 header’s destination address. R1 forwards to R2 according to the route table based on the destination address of the outer IPv6 header.

Step 2: End Point Node Processing: After receiving the packet, R2 looks up the local Local SID table based on the outer IPv6 address A2::11, hits END.X SID, performs the instruction action of END.X SID: SL–, and copies the SID indicated by SL into the outer IPv6 destination address, then forwards according to the next hop associated with END.X.

Step 3: Transit Node Processing: R3 forwards based on A4::13 according to the IPv6 routing table without processing the SRH extension header. It only needs standard IPv6 forwarding capability.

Step 4: End Point Node Processing: After receiving the packet, R4 looks up the local Local SID table based on the outer IPv6 address A4::13, hits END.X SID, performs the instruction action of END.X SID: SL–, copies the SID indicated by SL into the outer IPv6 destination address, pops out the SRH extension header since SL = 0, and forwards according to the next hop associated with END.X.

Step 5: After popping out the SRH extension header, the packet becomes a normal IPv6 header, and since A6::1 is a standard IPv6 address, it forwards to R6 following standard IPv6 forwarding.

From the forwarding described above, for nodes supporting SRv6 forwarding, forwarding via specific links can be indicated by SID, while for nodes not supporting SRv6, it can traverse through normal IPv6 routing forwarding. This feature allows SRv6 to achieve incremental deployment in an IPv6 network quite well.

02 SRv6 Standards and Industrial Progress

2.1 SRv6 Standards Progress

The standardization work of SRv6 mainly focuses on the IETF SPRING (Source Packet Routing in Networking) working group, with its packet encapsulation format SRH (Segment Routing Header) and other standardization efforts in the 6MAN (IPv6 Maintenance) working group, and the standardization of relevant control protocol extensions, including IGP, BGP, PCEP, and V** within LSR, IDR, PCE, BESS working groups, respectively.

To date, the standardization of SRv6 is mainly divided into two parts:

The first part is the basic features of SRv6, including the SRv6 network programming framework, packet encapsulation format SRH, and supporting SRv6 with basic protocol extensions such as IGP, BGP/V**, BGP-LS, PCEP, mainly providing applications such as V**, TE, and FRR. All SRv6 basic feature documents are co-led by Huawei and Cisco, with the participation of operators such as Bell Canada, SoftBank, and Orange. All documents (except OSPFv3) have been accepted as working group documents, and the standard’s maturity has entered a new stage, especially the critical SRH encapsulation draft, which has been approved by IETF IESG, soon to become an RFC.

The second part concerns new SRv6 applications aimed at 5G and cloud, including network slicing, deterministic delay (DetNet), OAM, IOAM (In-situ OAM), SFC, SD-WAN, multicast/BIER, etc. These applications impose new requirements for network programming, needing to encapsulate new information in the forwarding plane. SRv6 can well meet these needs, fully demonstrating its unique advantages in network programmability. Current customer demand urgency varies for these applications, reflected in the differing progress of standardization and research. Overall, SRv6 for OAM, IOAM, and SFC standardization is progressing quickly, with multiple working group drafts, and network slicing is also a current standardization focus. The V**+slicing framework draft has been accepted as a working group document, and the use of SRv6 SID to indicate resource assurance service requirements at the forwarding plane is gradually gaining wide recognition.

2.2 SRv6 Industry Progress

The overall progress of the SRv6 industry is described in the SRv6 Implementation and Deployment Status draft (draft-matsushima-spring-SRv6-deployment-status).

1. SRv6 Product Implementation

Currently, major equipment manufacturers, test equipment, and commercial chips clearly support SRv6. Huawei’s full range of router products support SRv6, and Cisco’s ASR9000, ASR1000, NCS5500, NCS540 products also support SRv6. Test equipment manufacturers, such as Spirent and IXIA, support SRv6, and chip manufacturers HiSilicon, Broadcom, have also released commercially deployable chips and completed verification on mainstream equipment.

In addition, some open-source platforms also support SRv6, such as Linux Kernel, Linux Srext module, FD.io VPP, providing some functional processing for SRH. Open-source tools and applications like Wireshark, Tcpdump, Iptables, Nftables, Snort, etc., already support the processing of IPv6 packets containing SRH.

2. SRv6 Interoperability Testing

The European Advanced Networking Testing Center (EANTC: European Advanced Networking Test Center) successfully conducted multi-vendor interoperability testing of SRv6 in March this year, with results presented at the MPLS + SDN + NFV World Congress and published in an interoperability testing white paper. Companies such as Huawei, Cisco, Spirent, and IXIA participated in this interoperability testing, covering SRv6 V**, TI-LFA, OAM, and other interoperability test cases.

3. SRv6 Deployment

Globally, several operators have started SRv6 commercial deployments, including China Telecom, China Unicom, CERNET2, Japan’s SoftBank and LINE Corporation, Italy’s Iliad, and Uganda’s MTN.

In 2017, China promoted the large-scale deployment of IPv6, and after more than a year of construction, major operators’ IP networks all support IPv6, providing a solid foundation for large-scale SRv6 deployment providing new business opportunities. To date, China Telecom, China Unicom, CERNET2 have completed deployments at 7 jurisdictional points, with SRv6’s advantages of multi-domain large network capability, incremental deployment ease, and rapid business activation being fully demonstrated, acting as a positive demonstration role for industry innovation.

4. SRv6 Industry Forum

As SRv6 technology and standards continue to mature, the industry’s recognition and acceptance of SRv6 are increasing. To further gather industry consensus and promote SRv6 innovative applications, there have been multiple SRv6 industry conferences due to concerted industry efforts.

In April 2019, during the MPLS+SDN+NFV conference in Paris, France, the first SRv6 roundtable meeting was held, where industry experts had heated discussions around the value scenarios of SRv6 and ways to promote SRv6 innovation and deployment.

In June 2019, the Expert Committee for Promoting IPv6 Large-Scale Deployment hosted the first SRv6 industry salon, where participating experts shared the latest progress in SRv6 standard innovation, overall solutions, and current network deployment applications.

These industry activities have played an active role in promoting innovative SRv6 applications.

03 The Value and Significance of SRv6

Since the proposal of SRv6 network programming draft two and a half years ago, it has seen multiple commercial implementations and deployments, marking an unusual rapid development pace in the history of IP technology development. Throughout the process of promoting SRv6 innovation and standards over the past two years, extensive exchanges with industry experts have been made, reflecting on lessons from the history of internet development, leading to further understanding of the value and significance of SRv6.

One important lesson from IPv4 technology development is the issue of scalability. Initially, it was not foreseen the number of devices would connect to IP networks, triggering the development of IPv6 technology. An important lesson from IPv6 technology development is the problem of compatibility. At the time, the thought was simple: the 32-bit address space was insufficient, so it was expanded to 128 bits, but the 128-bit IPv6 address could not be compatible with the 32-bit IPv4 address, requiring an entire network upgrade to support IPv6, consequently leading to deployment difficulties. From this perspective, SRv6 can be compatible with IPv6 routing and forwarding and consider the advantages of MPLS forwarding through Function ID, ensuring smooth evolution from IPv6 networks.

In the past more than ten years, IP technology has achieved great success, unifying network bearer, which can be called the All IP 1.0 era. Throughout this process, MPLS played a crucial role. MPLS-based bearer technology is used for IP Core bearer, metropolitan bearer, mobile bearer, replacing multiple network technologies such as frame relay, ATM, TDM, achieving unification of network bearer technology. MPLS’ success relies on three important features: V**, TE, and FRR, so the development of SRv6 must first inherit these three feature advantages, and after more than two years of development, this goal has been basically achieved.

The success of All IP 1.0 also brought about some problems and challenges, mainly three aspects:

The first is the problem of the island of IP bearer networks. Although MPLS unified the bearer network, IP Core bearer network, metropolitan bearer network, and mobile bearer network are separate, so cross-domain V** and other complex technologies must be used to solve, leading to difficulties in end-to-end business deployment.

The second is limited programming space in IPv4 and MPLS encapsulation. Many new services now require more encapsulation in the forwarding plane, and now IETF has declared halting further IPv4 standards development, and the field of MPLS labels adopts a fixed length, the label stack’s network programmability is also relatively limited, posing significant challenges in meeting future business’ network programming needs.

The third is the decoupling of applications and network bearer, leading to challenges in optimizing the network itself and enhancing value. Currently, operators generally face the challenge of being pipelined, unable to gain corresponding benefits from value-added applications, and the lack of application information makes rough network scheduling and optimization, also causing resource waste. There have been attempts in the history of network technology development, but they have failed, such as ATM to desk technology. MPLS once tried to be able to enter the cloud, but actually failed to enter the data center, where VXLAN became the de facto standard.

Figure 5 IP Technology Development Generations

The advent of SRv6 actually undertakes the mission to solve these key issues:

The first is SRv6 compatibility with IPv6 routing and forwarding, easily realizing connections between different network domains based on IP reachability, without requiring additional signaling like MPLS or needing a full network upgrade.

The second is the ability of SRH to support more types of encapsulation, well meeting the diverse needs of new services.

The third is the affinity of SRv6 for IPv6, allowing seamless integration of IP bearer networks with IPv6-supported applications, bringing operators more possible value addition through network awareness applications.

Twenty years of IPv6 development has proven that merely relying on address space demand is insufficient to support its large-scale deployment, and the SRv6 technology’s rapid development practice illustrates how new business applications can better promote IPv6 development applications. With the development of 5G, IoT, cloud and other services, more network devices’ access demands for address expansion are also increasing, combining SRv6 with these demands will push the network into a new All IP era, achieving an intelligent and simplified network based on All IPv6.

Note: This official account allows reposting by other official accounts or online platforms, but any form of reposting must indicate “Article reposted from SDNLAB official account” related wording.