| Internet-Draft | SRv6 SID Compression for Satelite | January 2026 |
| Chen, et al. | Expires 1 August 2026 | [Page] |
This document defines a compression method for Segment Identifiers (SIDs) in Segment Routing over IPv6 (SRv6) specifically designed for satellite networks. By leveraging the topological location information of satellite nodes, a 128-bit SID is compressed into a 32-bit Compressed SID (C-SID). The method introduces a "SID Container" structure to support the co-existence of 128-bit SIDs and 32-bit C-SIDs within a single Segment List without modifying the SRv6 control plane or the fixed SRH header format defined in RFC 8754.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 1 August 2026.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
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) [RFC8754] 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 [CHEN-SAT-CSID] 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 [RFC8986].¶
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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
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 [RFC8754] 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:¶
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 Figure 1 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-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):¶
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 [RFC8754] 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 [RFC8754].¶
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.¶