Network Working Group H. Chen Internet-Draft J. Liu Intended status: Standards Track W. Li Expires: 1 August 2026 K. Zhao Nanjing University 28 January 2026 SRv6 Segment Identifier Compression for Satelite Networks draft-chen-spring-satellite-csid-00 Abstract 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. Status of This Memo 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 Notice 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 Chen, et al. Expires 1 August 2026 [Page 1] Internet-Draft SRv6 SID Compression for Satelite January 2026 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . 3 5. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4 6. Protocol Specification . . . . . . . . . . . . . . . . . . . 4 6.1. C-SID Structure and Encoding . . . . . . . . . . . . . . 4 6.2. SID Container and Multi-scale Orchestration . . . . . . . 5 6.3. Forwarding and Decoding Logic . . . . . . . . . . . . . . 5 6.3.1. Identification and Reading . . . . . . . . . . . . . 5 6.3.2. Decoding to IPv6 Address . . . . . . . . . . . . . . 5 6.3.3. Operational Advantages . . . . . . . . . . . . . . . 6 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 7.1. Privacy and Topology Exposure . . . . . . . . . . . . . . 6 7.2. Address Scanning . . . . . . . . . . . . . . . . . . . . 6 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 10. Normative References . . . . . . . . . . . . . . . . . . . . 6 11. Informative References . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction 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]. Chen, et al. Expires 1 August 2026 [Page 2] Internet-Draft SRv6 SID Compression for Satelite January 2026 2. Conventions Used in This Document 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. 3. Terminology 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. 4. Design Goals 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. Chen, et al. Expires 1 August 2026 [Page 3] Internet-Draft SRv6 SID Compression for Satelite January 2026 5. Protocol Overview 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. 6. Protocol Specification 6.1. C-SID Structure and Encoding 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| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: C-SID Format (CSI is 2 bits; C-Arguments is 8 bits) 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-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 [RFC8986]. 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 Chen, et al. Expires 1 August 2026 [Page 4] Internet-Draft SRv6 SID Compression for Satelite January 2026 * 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. 6.2. SID Container and Multi-scale Orchestration The SRH Segment List is reorganized into 128-bit SID Containers. Each container MUST function in one of two modes: 1. Standard Mode: Carries a single 128-bit uncompressed SID. The lowest bit (C-Flag) of the container MUST be set to 0. 2. 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. 6.3. Forwarding and Decoding Logic 6.3.1. Identification and Reading 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. 6.3.2. Decoding to IPv6 Address 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). Chen, et al. Expires 1 August 2026 [Page 5] Internet-Draft SRv6 SID Compression for Satelite January 2026 * 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. 6.3.3. Operational Advantages * 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. 7. Security Considerations 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]. 7.1. Privacy and Topology Exposure Because C-SIDs embed topological semantics, deployments SHOULD consider the risk of topology disclosure on untrusted links. 7.2. Address Scanning Implementations SHOULD consider rate limiting and filtering to reduce scanning and probing risks in exposed environments. 8. IANA Considerations This document requests no new allocations from IANA. 9. Acknowledgements The authors thank the IETF SPRING working group and the satellite networking research community for discussions that motivated this work. 10. Normative References Chen, et al. Expires 1 August 2026 [Page 6] Internet-Draft SRv6 SID Compression for Satelite January 2026 [RFC2119] RFC Editor, "Key words for use in RFCs to Indicate Requirement Levels", March 1997, . [RFC8174] RFC Editor, "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", May 2017, . [RFC8754] RFC Editor, "IPv6 Segment Routing Header (SRH)", March 2020, . [RFC8986] RFC Editor, "Segment Routing over IPv6 (SRv6) Network Programming", February 2021, . 11. Informative References [CHEN-SAT-CSID] Chen, H., "SRv6 Segment Identifier Compression for Satelite Networks", 2026. Unpublished work provided by the authors. Authors' Addresses Hongyan Chen Nanjing University 163 Xianlin Avenue, Qixia District Nanjing Jiangsu, 210023 China Email: chenhongyan6176@163.com Jun Liu Nanjing University Nanjing Jiangsu, China Email: Johnson.liu@nju.edu.cn Wenfeng Li Nanjing University Nanjing Jiangsu, China Email: wenfeng@nju.edu.cn Chen, et al. Expires 1 August 2026 [Page 7] Internet-Draft SRv6 SID Compression for Satelite January 2026 Kanglian Zhao Nanjing University Nanjing Jiangsu, China Email: zhaokanglian@nju.edu.cn Chen, et al. Expires 1 August 2026 [Page 8]