What Is G-SRv6?
Generalized Segment Routing over IPv6 (G-SRv6) is compatible with SRv6 and supports multiple types of SIDs with different lengths, which are called Generalized SIDs (G-SIDs). By encoding G-SIDs of the compression type, G-SRv6 reduces the segment list (also called SID list) overhead by up to 75%, thereby reducing the SRv6 header overhead. In addition, G-SRv6 supports hybrid programming based on both 128-bit SRv6 SIDs and compressed SIDs. As such, only certain nodes need to be upgraded on demand in order to deploy G-SRv6 on a network, achieving a smooth upgrade and evolution from SRv6 to G-SRv6.
Why Do We Need G-SRv6?
Problems Caused by the High Overhead of SRv6 Headers
SRv6 is a next-generation IP transport protocol designed based on source routing. Its rich network programming capabilities well meet new network service requirements. Segment Routing Header (SRH) is a key extension for SRv6 implementation. In encapsulation mode, an SRv6 ingress encapsulates an outer IPv6 header and an SRH into a packet before forwarding the packet. This can increase header overhead. If there are a large number of SRv6 SIDs, the SRH length increases further. As a result, the following problems may occur:
Lowered Transmission Efficiency
The high overhead of SRv6 headers reduces the available payload size in each packet, lowering the transmission efficiency.
As shown in the following figure, Segment Routing (SR) mainly applies to two data planes: MPLS and IPv6. Segment Routing with MPLS (SR-MPLS) adopts SR in the MPLS data plane, whereas SRv6 adopts SR in the IPv6 data plane. SRv6 uses 128-bit IPv6 addresses as SIDs, whereas SR-MPLS uses 32-bit MPLS labels as SIDs. This means that an SRv6 SID is four times the length of an SR-MPLS SID.
Two data planes of SR
In SRv6-based data forwarding, the ingress encapsulates packets with an outer IPv6 header and an SRH carrying segment lists. On large-scale networks, if a forwarding path needs to be specified hop by hop, many SRv6 SIDs will be encapsulated. For example, in scenarios where packets are forwarded over an End-to-End (E2E) strict explicit path, the number of SRv6 SIDs used may exceed 5 or even reach 10. If 10 SRv6 SIDs are used, the total length of the IPv6 header is 208 bytes, comprised of 40 bytes for the IPv6 basic header, 8 bytes for the fixed header, and 160 bytes (10 SIDs x 16 bytes) for the segment list. The following figure shows the SRv6 header overhead in this case.
SRv6 header overhead when 10 SRv6 SIDs are used
As the total length of a packet is limited, an excessively long packet header increases the transmission overhead. As such, the proportion of IPv6 payload in SRv6 packets decreases, lowering the transmission efficiency.
Incompatibility with Legacy Devices on Existing Networks
Compatibility with devices on existing networks is essential for the success of new protocols. However, the SID stack is too deep due to the high overhead of SRv6 headers, resulting in poor compatibility with such devices.
To support SRv6, existing devices require software and hardware upgrades. Software upgrades involve adding support for SRv6-related control protocols, such as extending IGPs and BGP to support SRv6, and have a controllable impact on live networks. In contrast, hardware upgrades are extremely challenging and usually require huge investments.
In addition to bringing more semantics to IPv6 addresses, SRv6 introduces some new mechanisms, such as SRH and forwarding-plane Type Length Value (TLV) encapsulation. Although these mechanisms enhance network programming capabilities, they also impose higher requirements on the processing capabilities of hardware devices. To implement high-performance packet processing and forwarding, hardware-based processing is typically needed for SRHs and TLVs. In addition, to support more refined traffic engineering and functions such as Service Function Chaining (SFC) and In-situ Operations, Administration, and Maintenance (IOAM), hardware devices must be capable of processing more SRv6 SIDs.
The following figure illustrates the initial assessment of SRv6 requirements on the SID stack processing capability of network devices. From this figure, we can see that the SRH is not required in the L3VPN over SRv6 BE scenario. To support L3VPN over SRv6 BE + TI-LFA, a device should be capable of processing an SRv6 SID stack with about four SIDs. A device may need to be capable of processing up to 10 SIDs to support L3VPN over SRv6 TE Policy, and even more in order to support SRv6 SFC and IOAM.
Initial assessment of SRv6 requirements on the SID stack processing capability of network devices
As the number of SIDs increases, the depth of the SID stack in SRv6 packets may exceed the depth that hardware can read each time, meaning that the hardware must perform a second read. This impacts the forwarding performance. Furthermore, due to SRv6 imposing high requirements on hardware for packet processing, some legacy devices on existing networks cannot support in-depth packet header replication. As a result, these devices require hardware upgrades, preventing existing networks from being smoothly upgraded to SRv6.
High Risk of Exceeding the MTU
Due to the high overhead of SRv6 headers, the packet header size may exceed the Maximum Transmission Unit (MTU).
SRv6 has a unique advantage in supporting new technologies such as TI-LFA and midpoint protection. Using SRv6 explicit paths as post-failure repair paths, these technologies enhance fault protection capabilities on IP networks and are therefore essential to building deterministic IP networks. However, SRv6 protection usually involves adding one to three 16-byte (128-bit) SIDs to the original packet data. This is necessary to force packet forwarding along the specified path but further increases the SRv6 packet length (as shown in the following figure).
SRv6 packet length change
Typically, only the source and destination IPv6 nodes parse IPv6 extension headers. As such, only the source IPv6 node performs IPv6 MTU-based packet fragmentation when originating IPv6 packets, and transit nodes do not perform such fragmentation when forwarding these packets. If the length of an IPv6 packet is greater than the IPv6 MTU of a device's outbound interface, the device discards the packet and performs path MTU discovery. Because SRv6 uses IPv6 as the data plane protocol, the risk of exceeding the MTU severely affects SRv6.
Why Is G-SRv6 a More Efficient SRv6 Technology?
G-SRv6 is an SRv6-compatible evolution solution that inherits multiple SRv6 advantages — such as source routing, native IPv6, programmability, and protocol simplification — and addresses concerns about excessively long SRv6 headers. As a more efficient SRv6 technology, G-SRv6 plays an important role in promoting SRv6 deployment. In contrast to SRv6, G-SRv6 offers the following technical benefits:
Improved Transmission Efficiency
As shown in the following figure, using 32-bit compressed SIDs enables G-SRv6 to reduce the segment list overhead by up to 75%, significantly improving network transmission efficiency. For example, if transmitting a data block consumes 10 GB of traffic in SRv6, it may consume only 7 GB of traffic in G-SRv6. In scenarios sensitive to transmission efficiency — such as a Software Defined Wide Area Network (SD-WAN) scenario — G-SRv6 helps reduce costs significantly.
SRv6 header overhead when 10 SRv6 SIDs are used
Enhanced Forwarding Performance
In SRv6 forwarding, the main forwarding action is to read the active SID in the segment list to which the Segments Left (SL) field points and copy the SID to the Destination Address (DA) field in the IPv6 header. With G-SRv6, the entire segment list becomes shorter, decreasing the SID stack depth for hardware to read SIDs in the segment list and eliminating the need for hardware to perform a second read. For example, in a 10-SID-based forwarding test performed on a Huawei device, the forwarding rate of SRv6 is 400 Mpps, whereas that of G-SRv6 can reach 620 Mpps. This means that the forwarding performance is improved by 55%. Because G-SRv6 imposes lower requirements on device hardware capabilities, some legacy devices on existing networks can support G-SRv6 through software upgrades. As such, this avoids the costs associated with hardware upgrades and facilitates the smooth upgrade of networks.
Reduced Risk of Exceeding the MTU
In G-SRv6 scenarios, one to three 32-bit compressed SIDs may be added if TI-LFA protection is used. The added length in this case is significantly shorter than that in SRv6 scenarios, substantially reducing the risk of exceeding the MTU.
How Is G-SRv6 Implemented?
How is G-SRv6 implemented based on SRv6? Next, let's use the basic concepts and packet forwarding process of G-SRv6 to describe its implementation and demonstrate its good compatibility with SRv6.
In SRv6, a SID is a 128-bit IPv6 address and currently consists of five parts, as shown in the following figure.
SRv6 SID format
In an SRv6 domain, SRv6 SIDs are allocated from the same address block. As such, they share the same address prefix (called common prefix), for example, 2001:DB8:1:1::/64. Both the End and End.X SIDs (which are used to represent nodes and links, respectively) typically have their Arguments field set to the default value 0 and their Padding field also set to 0. Therefore, the only differences between one 128-bit SRv6 SID and another are currently the Node ID and Function ID fields.
G-SRv6 removes redundant information from the segment lists of SIDs and allows the SIDs to carry only the variable Node ID and Function ID fields, thereby achieving compression. Unlike SRv6, G-SRv6 does not need to update the IPv6 DA field with a 128-bit SID during forwarding. Instead, it needs to update this field with only the changed node and function IDs in order to generate a new IPv6 DA. This is the basic implementation of G-SRv6 compression, which is shown in the following figure. In the current G-SRv6 solution, Generalized SIDs (G-SIDs) are used to directly represent compressed SIDs. G-SIDs are named as such because they can represent not only compressed SIDs but also 128-bit SRv6 SIDs and other SIDs.
Basic implementation of G-SRv6 compression
To be compatible with the SRH, G-SIDs need to be arranged to align with 128 bits in the SRH. That is, four 32-bit G-SIDs or eight 16-bit G-SIDs need to be arranged in a 128-bit unit. If the length is less than 128 bits, 0s are used to pad it to 128 bits. Therefore, the G-SRv6 solution defines G-SID containers to indicate 128-bit units. Each G-SID container is a 128-bit value and can contain a common SRv6 SID or multiple G-SIDs (for example, one to four 32-bit G-SIDs), as shown in the following figure.
After G-SIDs are introduced, multiple types of SIDs can be encoded into an SRv6 SRH — called a G-SRH in this case. Although a G-SRH shares the same format as an SRH, its segment list supports hybrid encoding of both 128-bit SRv6 SIDs and 32-bit G-SIDs. The following figure shows the G-SRH format, in which the original 128-bit SID is changed to a G-SID container that can carry one SRv6 SID or multiple G-SIDs.
The following figure shows an example where a 128-bit SRv6 SID and multiple 32-bit G-SIDs are all encoded into the segment list of a G-SRH.
G-SRv6 segment list encoding
In G-SRv6, a path can consist of an SRv6 compression sub-path and an SRv6 sub-path, both of which are encoded using their respective SIDs.
- SRv6 compression sub-path: is encoded using a series of compressible G-SIDs, among which the first G-SID is a 128-bit compressible SRv6 SID and the following G-SIDs are 32-bit compressed SIDs. The first G-SID carries complete 128-bit information including the common prefix and is used to construct a complete and routable SID.
- SRv6 sub-path: is encoded using 128-bit G-SIDs, that is, SRv6 SIDs.
All G-SIDs are organized in the segment list based on 128 bits. As such, padding is required if a G-SID contains less than 128 bits.
Currently, SRv6 updates the DA field in the IPv6 header with the active SID to which the SL field points. After G-SIDs are encoded into the G-SRH, the SID updated each time may be a 32-bit G-SID rather than a 128-bit SID. For this reason, the action of updating 32-bit G-SIDs needs to be defined.
To indicate the processing of compressed SRv6 SIDs, G-SRv6 defines the COC flavor. This flavor is bound to a SID and signifies that a node receiving such a SID must update the DA field with the next 32-bit G-SID in the segment list.
Because a G-SID container may contain multiple G-SIDs, the SID Index (SI) field is added to locate the next G-SID in the container. This field occupies the two least significant bits of the Arguments field in the G-SRv6 header's DA field. To facilitate hardware implementation and future extension, 128-bit SRv6 SIDs (without padding) can be used to ensure that the SI field occupies the two least significant bits among the 128 bits, as shown in the following figure.
When a compressed SID is generated, space must be reserved for the SI field, of which the initial value is 0. During forwarding, an SI in the DA field is valid only when the SID in this field is compressible. In this case, the SL field indicates the active G-SID container in the G-SRH, and the SI field indicates the location of a G-SID in the G-SID container. Similar to SIDs being sequenced in descending order in the segment list (Segment List  indicates the last hop, whereas Segment List [n] indicates the first hop), G-SIDs are also sequenced in this order. For example, the SI value of 3 points to the G-SID occupying the 32 least significant bits of the G-SID container, whereas the SI value of 0 points to the G-SID occupying the 32 most significant bits of the G-SID container.
In G-SRv6, a SID with the COC flavor instructs the corresponding node to update the DA field in the IPv6 header with the next 32-bit G-SID in the G-SRH before packet forwarding. Because the G-SRv6 compression process is triggered by the COC flavor and operations are limited only to the SID with the COC flavor, the processing of existing SIDs and SRHs is not affected.
The following figure shows an example for segment list encoding in a G-SRH that contains a compressed SID list and a 128-bit VPN SID.
The following rules are defined for encoding an SRv6 compression path in the segment list:
- The start of the SRv6 compression path is indicated by a 128-bit SID with the COC flavor. This SID carries complete SID information (including the common prefix), which can be used together with subsequent G-SIDs to completely restore the next SID.
- All the G-SIDs in the middle of the compression path have the COC flavor, indicating that each subsequent G-SID is a 32-bit one.
- The last G-SID of the compression path does not have the COC flavor. It forms a complete SID along with other parts in the DA field. Regarding the SID as a 128-bit SRv6 SID, the corresponding node updates the IPv6 DA field with the next 128-bit SRv6 SID, implementing the change from a 32-bit G-SID to a standard SRv6 SID.
These rules support hybrid encoding of common SRv6 SIDs and compressed SIDs, facilitating network evolution and upgrade from SRv6 to G-SRv6.
Example for segment list encoding in a G-SRH
Packet Forwarding Process
This example uses the scenario where a packet needs to traverse both SRv6 compression and non-compression domains to illustrate the G-SRv6-based packet forwarding process.
On the network shown in the following figure, assume that a packet needs to be forwarded from node N0 to node N10, and only node N5 does not support compression. As such, N5's SID 2001:DB8:A1::5:1 is completely encoded in the segment list. As an End.DT4 VPN SID, node N10's SID 2001:DB8:A:10:10:: is also completely encoded into the segment list as a 128-bit SID. In this case, the SIDs of nodes N1, N2, N3, N6, N7, and N8 all carry the COC flavor, which indicates that the next SID is a compressed SID. The following figure shows the encoded segment list.
Forwarding in hybrid programming mode
The forwarding process is as follows:
- After receiving a data packet, node N1 detects that the DA 2001:DB8:A:1:1:: is a local End.X SID with the COC flavor. In this case, the SL and SI values in the SRH are 5 and 0, respectively. As such, N1 decrements the SL value by 1, initializes the SI value to 3, copies the G-SID 2:1 pointed by the SI to the IPv6 DA field, and then forwards the packet to the next node N2 based on the new IPv6 DA, which is 2001:DB8:A:2:1::3.
- After receiving the data packet, node N2 detects that the DA 2001:DB8:A:2:1::3 is a local End.X SID with the COC flavor. The SL and SI values have become 4 and 3, respectively. In this case, N2 decrements the SI value by 1, copies the G-SID 3:1 pointed by the SI in the G-SRH to the DA field, and then forwards the packet to the next node based on the new DA, which is 2001:DB8:A:3:1::2.
- Similar to node N2, node N3 updates the IPv6 DA with 2001:DB8:A:4:2::1 and forwards the packet to node N4.
- After receiving the data packet, node N4 detects that the DA 2001:DB8:A:4:2::1 is a local End.X SID. As such, N4 decrements the SL value by 1 (4 – 1 = 3), copies 2001:DB8:A1::5:1 to the DA field, and then forwards the packet.
- As a common SRv6 node, node N5 performs SRv6 forwarding actions on the received data packet: updating the IPv6 DA to 2001:DB8:A:6:1:: and forwarding the packet to the next node.
- After receiving the data packet, node N6 detects that the DA 2001:DB8:A:6:1:: is a local End.X SID with the COC flavor. At this stage, the SL and SI values in the SRH are 2 and 0, respectively. In this case, N6 decrements the SL value by 1, initializes the SI value to 3, copies the G-SID 7:1 pointed by the SI to the DA field, and then forwards the packet to the next node based on the new DA, which is 2001:DB8:A:7:1::3.
- After receiving the data packet, nodes N7 and N8 both process the COC-flavored SID, update the DA, and forward the packet.
- Similar to node N4, after receiving the data packet, node N9 detects that the SID in the DA is a local End.X SID without the COC flavor. As such, N9 decrements the SL value by 1, copies the VPN SID pointed by the SL to the DA field, and then forwards the packet to node N10.
- Node N10 performs subsequent processing according to the instruction bound to the VPN SID.
G-SRv6 Application on Intelligent Cloud-Networks
Intelligent cloud-networks are new service networks oriented to the cloud era, enabling computing power to be scheduled between clouds and networks, providing abundant computing power for numerous industries, and helping enterprises achieve digital transformation.
As shown in the following figure, the target network architecture of Huawei's intelligent cloud-network solution for carriers primarily consists of three parts: intelligent cloud metro network, intelligent cloud backbone network, and intelligent management and control layer.
- The intelligent cloud metro network uses the spine-leaf architecture, facilitating the extended access of access points.
- On the intelligent cloud backbone network, network and cloud PEs are deployed in full-mesh mode, achieving one-hop service path reachability and facilitating the extended access of various clouds and intelligent cloud metro networks.
- The intelligent management and control layer implements intelligent network management and service O&M, and presents network capabilities to enterprise users through northbound interfaces.
G-SRv6 application in Huawei's intelligent cloud-network solution
G-SRv6 seamlessly connects different ASs on an intelligent cloud-network, changing segment-by-segment networking to E2E networking and enabling one-hop service access to the cloud. Leveraging the programmability of G-SRv6 and intelligent controllers, the network can implement latency-based intelligent traffic steering and imperceptible service path switching. Furthermore, G-SRv6 TI-LFA can be used on the entire network to implement fault recovery within 50 ms regardless of the fault location.
Focusing mainly on carriers' IP RANs, PON metro networks, new slice-based cloud private networks, and cloud backbone networks, Huawei's intelligent cloud-network solution can be applied to six major types of services listed in the following figure, helping meet the differentiated access requirements of customers and implement fixed and mobile convergence.
Because many services listed in the preceding figure need to traverse multiple network areas and have high SLA requirements, G-SRv6 can be used in the corresponding scenarios. Specifically:
- Existing IP RANs mainly involve the cloudification of existing IP RAN enterprise services and 5G 2B FMC private line services. On IP RANs, there are many legacy devices, which may be unable to effectively process a deep SRv6 SID stack. In this case, G-SRv6 can be used to reduce the SRv6 SID stack depth, lowering the requirements for device hardware capabilities and promoting smooth evolution of the networks.
- For slice-based cloud private networks, the minimum slice granularity may currently reach 100 Mbps and decrease even further in the future. Because bandwidth resources are valuable, G-SRv6 can be used to minimize the packet header overhead and improve the packet transmission efficiency, thereby helping users reduce associated fees.
- Metro networks mainly involve the fixed broadband cloudification acceleration services of public, education, government, and enterprise users. Such services have strict requirements on latency, which involves both network transmission and device processing. In this case, network slicing technology can be used to reserve resources so that the network transmission latency does not exceed the specified threshold, and G-SRv6 can be used to improve the packet forwarding performance and reduce the device processing latency.
- Author： Zhang Yuting
- Updated on： 2023-01-03
- Views： 1315
- Average rating：