SRv6 Segment Identifier Compression for Satelite Networks

Satelite networks face unique constraints such as limited onboard computing power and storage resources. When applying SRv6 to satellite constellations, long service paths or complex policies lead to significant Segment Routing Header (SRH) overhead, which reduces effective payload and increases the risk of MTU fragmentation. Existing compression schemes often rely on complex endpoint behaviors or rigid block planning, which are difficult to implement and maintain in dynamic satellite environments. This document proposes a lightweight compression method that maps satellite topological semantics (layer, orbit, and node index) directly into a 32-bit C-SID. This approach enhances network observability and efficiency while maintaining full compatibility with standard SRv6 data plane processing .

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

SID Container:: A 128-bit basic unit in the SRH Segment List used to carry either one 128-bit SID or multiple 32-bit C-SIDs.
C-SID:: Compressed Segment Identifier, 32 bits in length.
CSI (Compressed SID Index):: A field used to indicate the position of a C-SID within a SID Container.
C-Flag (Compression Flag):: A flag used to distinguish between C-SIDs and standard SIDs.

This document targets satellite constellation environments where SRv6 policies may traverse long paths and frequently change. The mechanism is designed to achieve the following goals:

Compatibility: Preserve the fixed SRH header format and standard SRv6 processing model.
No control-plane extension: Avoid modifications to SRv6 control plane signaling; only the segment list representation is optimized.
Topology awareness: Encode satellite topological semantics (layer, orbit, and node index) directly into the identifier.
Multi-scale orchestration: Allow interleaving of compressed 32-bit C-SIDs and regular 128-bit SIDs within a single Segment List.
Implementation simplicity: Use lightweight packing/decoding logic suitable for resource-constrained onboard platforms.

The Segment List in an SRH is reorganized into 128-bit units called SID Containers. A container operates in either Standard Mode (one 128-bit SID) or Compressed Mode (1 to 4 C-SIDs). A 32-bit C-SID carries satellite topological semantics and SRv6 behavior information. During forwarding, a node reads the active container indicated by Segment Left (SL) and decides whether to process a full SID or a C-SID based on a container flag bit. When a C-SID is encountered, it can be decoded to a 128-bit IPv6 address for forwarding, without changing the SRH base format.

A C-SID MUST be defined as a 32-bit field. The structure is as follows:

C-SID Format (CSI is 2 bits; C-Arguments is 8 bits) 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | C-Locator | C-Func | C-Args |CSI|F| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Bit numbering in follows the convention used in IETF bit diagrams where the leftmost bit is bit 0. The fields MUST be assigned as: C-Locator bits 0-15, C-Func bits 16-20, C-Args bits 21-28, CSI bits 29-30, and F bit 31.

C-Locator (16 bits):: Carries satellite topological information. It is divided into three sub-fields representing the layer index, orbit index, and in-orbit index of the node.
C-Function (5 bits):: Represents the segment behavior instructions mapped from the original SID .
C-Arguments (8 bits):: Carries behavior extension parameters.
CSI (2 bits):: Indicates the slot index within the SID Container.

11: Slot 1 (bits 0-31 of the container)
10: Slot 2
01: Slot 3
00: Slot 4 (bits 96-127)

C-Flag (1 bit): MUST be set to 1 if the unit is a C-SID; it MUST be set to 0 if it is a standard SID or padding.

The SRH Segment List is reorganized into 128-bit SID Containers. Each container MUST function in one of two modes:

Standard Mode: Carries a single 128-bit uncompressed SID. The lowest bit (C-Flag) of the container MUST be set to 0.
Compressed Mode: Carries 1 to 4 C-SIDs. The lowest bit (C-Flag) of the container MUST be set to 1.

This design allows for multi-scale identifier orchestration where C-SIDs and standard SIDs are interleaved within the same Segment List. If a container is not fully filled with 4 C-SIDs, the remaining bits SHOULD be set to zero as padding, with their C-Flags marked as 0.

When a satellite node processes an SRH, it SHOULD locate the current SID Container via the Segment Left (SL) pointer. The type is judged by the lowest bit (C-Flag):

If C-Flag == 0: Read as a standard SID. After processing, decrement SL by 1.
If C-Flag == 1: Read the C-SID.
- If CSI != 0: Process the C-SID and offset the internal reading pointer by 32 bits within the container.
- If CSI == 0: After processing, the container is exhausted. Decrement SL by 1 to point to the next container.

To facilitate forwarding, a 32-bit C-SID MUST be decoded into a 128-bit IPv6 destination address:

Prefix (48 bits): Taken from the common prefix of the satellite constellation (derived from the Source IP address).
C-Locator (16 bits): Appended to the prefix to form a 64-bit addressing prefix.
Behavioral Mapping (16 bits): C-SID bits C[15:0] MUST be mapped to bits 65-80 of the IPv6 address.
Final Flags: The C-Flag MUST be mapped to the lowest bit of the IPv6 address, with remaining bits set to zero.

No Protocol Extension: Works with existing SRH formats and SRv6 control plane protocols.
Topological Awareness: Directly correlates SIDs with satellite coordinates (layer/orbit/node).
High Efficiency: Eliminates the need to carry 128-bit Block prefixes in the first segment of compressed lists.

As satellite networks are vulnerable to link exposure, the integrity of the SID Container SHOULD be protected. Standard SRH security mechanisms SHOULD be applied .

Because C-SIDs embed topological semantics, deployments SHOULD consider the risk of topology disclosure on untrusted links.

Implementations SHOULD consider rate limiting and filtering to reduce scanning and probing risks in exposed environments.

This document requests no new allocations from IANA.

The authors thank the IETF SPRING working group and the satellite networking research community for discussions that motivated this work.