What Is 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.

G-SID

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

G-SID Container

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.

G-SID container

G-SRH

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.

G-SRH format

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.

COC Flavor

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.

SI location

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 [0] 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:

1. 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.
2. 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.
3. 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:

1. 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.
2. 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.
3. Similar to node N2, node N3 updates the IPv6 DA with 2001:DB8:A:4:2::1 and forwards the packet to node N4.
4. 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.
5. 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.
6. 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.
7. After receiving the data packet, nodes N7 and N8 both process the COC-flavored SID, update the DA, and forward the packet.
8. 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.
9. Node N10 performs subsequent processing according to the instruction bound to the VPN SID.