Skip to content

RFC 9800 - Compressed SRv6 Segment List Encoding

Field Value
Title Compressed SRv6 Segment List Encoding
Authors C. Filsfils, Z. Ali, C. Previdi, F. Clad, et al.
Date June 2025
Status Proposed Standard
Link datatracker.ietf.org/doc/rfc9800

Summary

RFC 9800 defines the Compressed SRv6 Segment List Encoding, commonly known as micro-SID (uSID). This mechanism addresses one of the primary concerns with SRv6: the overhead of 128-bit SIDs in the Segment Routing Header. By packing multiple compressed SIDs (C-SIDs) into a single 128-bit container, the encoding dramatically reduces SRH overhead, making SRv6 competitive with SR-MPLS in terms of per-packet encapsulation cost.

The specification defines two SRv6 SID flavors: NEXT-C-SID and REPLACE-C-SID. Both flavors use a container structure where multiple short SID values (typically 16 or 32 bits) are packed into standard 128-bit SRv6 SID slots. The key operation is "shift-and-lookup": when a node processes its C-SID, it shifts the remaining C-SIDs within the container and performs a lookup on the next one, avoiding the need to decrement Segments Left for every micro-segment.

The compression is transparent to transit nodes, which see only a standard IPv6 destination address. This means uSID can be deployed incrementally -- only SR-capable endpoints need to support the compressed encoding, while the rest of the network forwards packets using standard IPv6.

Key Sections

Section Topic Description
3 C-SID Container Format How compressed SIDs are packed into 128-bit slots
4 NEXT-C-SID Flavor Processing using the Next-Header chain for container advancement
5 REPLACE-C-SID Flavor Processing by replacing within the active container
6 C-SID Shift-and-Lookup Core forwarding operation for both flavors
7 Interworking Mixing compressed and uncompressed SIDs in the same SRH

C-SID Container Format

A single 128-bit SRv6 SID slot is divided into a Global Identifier Block (GIB) and a sequence of C-SIDs:

|<---------- 128 bits ---------->|
| GIB (variable) | C-SID1 | C-SID2 | C-SID3 | ... | padding |
Component Typical Size Purpose
GIB 32 bits Common block prefix shared by all uSIDs in the domain
C-SID 16 bits (default) Compressed node/function identifier
Container 128 bits One Segment List entry holding multiple C-SIDs

With a 32-bit GIB and 16-bit C-SIDs, a single 128-bit container holds up to 6 micro-segments.

NEXT-C-SID vs REPLACE-C-SID

Property NEXT-C-SID REPLACE-C-SID
Container advancement Decrements Segments Left to move to the next 128-bit container Replaces C-SIDs within the current container entry
SL decrement On container boundary only On container boundary only
Shift operation Shift C-SIDs left within the active container Same shift operation
Empty container detection Next C-SID position is all zeros Same
Interworking Can coexist with uncompressed SIDs Can coexist with uncompressed SIDs

Overhead Comparison

Encoding 4-Segment Path 8-Segment Path 12-Segment Path
Uncompressed SRv6 64 bytes (4 x 16B) 128 bytes (8 x 16B) 192 bytes (12 x 16B)
uSID (16-bit C-SIDs) 16 bytes (1 container) 32 bytes (2 containers) 32 bytes (2 containers)
SR-MPLS 16 bytes (4 x 4B) 32 bytes (8 x 4B) 48 bytes (12 x 4B)

Shift-and-Lookup Operation

When a uSID-capable node receives a packet:

  1. Extract its own C-SID from the current position in the active container
  2. Shift remaining C-SIDs left by one C-SID length within the container
  3. If the next C-SID position is all zeros (end of container), decrement Segments Left and move to the next container entry
  4. Write the updated container value into the IPv6 Destination Address
  5. Perform an IPv6 FIB lookup on the new Destination Address

Common Pitfalls

  • All nodes in a uSID domain must share the same GIB prefix and C-SID length. Mismatched configurations cause forwarding failures.
  • The "End of Container" condition (all-zeros in the next C-SID position) must be handled correctly. A C-SID value of 0 is reserved and must not be assigned to any node.
  • Mixing NEXT-C-SID and REPLACE-C-SID flavors within the same segment list is not supported. Choose one flavor per deployment.
  • Compressed and uncompressed SIDs can coexist in the same SRH, but the transition boundaries must be configured correctly.
  • Operators accustomed to SRv6 packet captures will see fewer Segment List entries than expected because multiple hops are packed into each container.

References

  1. RFC 9800 - Compressed SRv6 Segment List Encoding
  2. RFC 8754 - IPv6 Segment Routing Header (SRH)
  3. RFC 8986 - SRv6 Network Programming