In-situ Space Flow Telemetry for IPv6 Limited Domains

In-situ Space Flow Telemetry for IPv6 Limited Domains Nanjing University

163 Xianlin Avenue Nanjing Jiangsu 210023 China 522024230088@smail.nju.edu.cn

Nanjing University

johnson.liu@nju.edu.cn

Nanjing University

zhaokanglian@nju.edu.cn

Nanjing University

leewf_cn@hotmail.com

Transport IP Performance Measurement IOAM IPv6 space network telemetry Space networks, including satellite networks, often operate with constrained bandwidth, processing capacity, storage, and energy, while also experiencing dynamic topology and frequent link changes. Existing in-situ Operations, Administration, and Maintenance (IOAM) mechanisms provide useful per-packet telemetry, but the packet overhead and field selection flexibility can be costly in such environments. This document specifies In-situ Space Flow Telemetry (ISFT), a compact telemetry profile for IPv6 limited domains. ISFT defines an 8-octet telemetry option header, a small set of telemetry templates for delay, loss, and congestion information, and processing behavior for encapsulating, transit, and decapsulating nodes. ISFT is intended for controlled domains such as space-network segments and MUST NOT be exposed as an Internet-wide protocol behavior.

Introduction IOAM records operational and telemetry information while a packet traverses a network path . IOAM is most useful when measurement packets need to follow the same forwarding treatment as user packets, or when active probe packets cannot reveal the same path and performance properties. Space networks have operating constraints that differ from many terrestrial deployments. Satellite nodes can have limited processing resources, limited storage, constrained energy budgets, narrow or intermittent links, and scheduled or mobility-driven topology changes. The resulting telemetry system needs to minimize per-packet overhead and simplify per-node processing while still preserving the measurements needed for delay, packet-loss, and congestion analysis. ISFT is specified for IPv6 packets in a limited domain. It intentionally avoids defining a new IPv6 extension header. In particular, this document does not place ISFT in IPv6 Hop-by-Hop Options; deployments that use Hop-by-Hop Options need to follow the processing model and operational guidance in . ISFT adapts the IOAM model to this environment by using:

a compact 8-octet ISFT Option Header that carries a namespace, an ISFT option type, a 3-bit telemetry template, a flow identifier, and a sequence number;
a fixed set of telemetry templates that cover node information, delay, loss, congestion, and common combinations of these signals;
domain-edge encapsulation and decapsulation so that ISFT state is contained inside an explicitly managed limited domain; and
optional use of the IPv6 Flow Label of an ISFT-domain packet to identify selected telemetry flows without parsing transport headers at every hop.

ISFT is not a replacement for RFC 9197 IOAM. It is a constrained profile and option-header format for deployments that value compact field encoding and simple template-based data selection over arbitrary per-field trace selection.

Requirements Language 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.

Terminology

ISFT: In-situ Space Flow Telemetry.
ISFT Domain: A limited domain in which ISFT-capable nodes are configured to process ISFT packets.
Encapsulating Node: An ISFT domain-edge node that selects a packet or flow for telemetry, inserts an ISFT Option Header, and sets domain-local ISFT state.
Transit Node: An ISFT-capable node inside the ISFT Domain that reads the ISFT Option Header and collects or exports telemetry according to the selected template and collection mode.
Decapsulating Node: An ISFT domain-edge node that removes ISFT information before the packet leaves the ISFT Domain.
Template: A 3-bit selector that identifies the telemetry data collected for a packet.

Applicability and Scope ISFT is applicable only in limited domains whose membership, boundary nodes, node identifiers, Flow Label behavior, and telemetry collectors are under common administrative control. ISFT packets MUST NOT be forwarded outside the ISFT Domain with an ISFT Option Header still present. ISFT can be deployed on native packets originated by ISFT-aware endpoints or on packets carried by a tunnel or adaptation layer whose ingress and egress are the ISFT domain edges. An ISFT encapsulating node MUST NOT insert an ISFT Option Header into the payload of an arbitrary end-to-end UDP or TCP packet unless the upper-layer endpoints or the tunnel endpoints have explicitly negotiated or been configured for ISFT. This requirement preserves transport and application semantics. If the IPv6 Flow Label is used as an ISFT flow marker, the ISFT encapsulating node MUST be the source of the IPv6 header whose Flow Label it sets. A node MUST NOT rewrite the Flow Label of an end-to-end IPv6 packet while leaving the original IPv6 source address unchanged. These restrictions are intended to align deployment with the IPv6 Flow Label specification .

Protocol Overview ISFT processing has three stages:

The encapsulating node classifies traffic. If a packet matches an operator-configured telemetry rule, the node selects a Flow-ID, a Template, and a collection mode, inserts the ISFT Option Header, and optionally maps the Flow-ID into the IPv6 Flow Label of the ISFT-domain packet.
Each transit node determines whether the packet is an ISFT packet by local domain configuration and, when enabled, by the IPv6 Flow Label value. The node reads the Template and collection mode, collects the selected metadata, and either exports it or appends it to the ISFT data area.
The decapsulating node collects its own selected metadata, removes the ISFT Option Header and any appended ISFT data, exports or forwards the final telemetry report as required by the mode, and forwards the restored packet outside the ISFT Domain.

ISFT Option Header Format The ISFT Option Header is 8 octets long. Its field layout follows the compact option-header format derived from the ISFT source material: a 7-bit Namespace-ID, a 2-bit ISFT Option Type, a 3-bit Template, a 20-bit Flow-ID, and a 32-bit Sequence Number.

ISFT Option Header

Namespace-ID: 7 bits: Domain-local namespace identifier. It scopes the ISFT measurement boundary and interpretation of telemetry values. The value is local to the ISFT Domain.
O: 2 bits: ISFT Option Type. Values identify the collection type and are defined in .
T: 3 bits: Telemetry template. Values are defined in .
Flow-ID: 20 bits: Domain-local identifier for the measured flow. In deployments that use the IPv6 Flow Label as an ISFT marker, this value is mapped to the 20-bit Flow Label of the ISFT-domain packet.
Sequence Number: 32 bits: Packet sequence number. The sequence number is used together with the Flow-ID to detect packet loss and reordering.

Telemetry Templates The Template field selects one of eight fixed telemetry combinations. The fixed combinations avoid per-field bit scanning in constrained data planes. Every ISFT metadata record includes the base node-information block defined in . The table lists the measurement information selected by each Template in addition to that base block. Loss-related templates use the Sequence Number carried in the ISFT Option Header. ISFT Template Values

Value	Name	Selected measurement information
000	Node	Base node-information block only
001	Delay	In Timestamp, Out Timestamp, Transit Delay
010	Loss	ISFT Sequence Number from the ISFT Option Header
011	Delay and Loss	Delay fields and the ISFT Sequence Number from the ISFT Option Header
100	Congestion	Queue Depth, Buffer Occupancy
101	Delay and Congestion	Delay fields, Queue Depth, Buffer Occupancy
110	Loss and Congestion	ISFT Sequence Number from the ISFT Option Header, Queue Depth, Buffer Occupancy
111	Delay, Loss, and Congestion	Delay fields, the ISFT Sequence Number from the ISFT Option Header, Queue Depth, Buffer Occupancy

Metadata Fields ISFT metadata is encoded in network byte order. Each telemetry record contains a base node-information block, followed by the fields required by the selected Template.

iSFT MD Format The figure shows the maximal ISFT metadata record layout. The first 32 bits form the base node-information block and are present in every metadata record. The remaining fields are included when required by the selected Template and local collection mode. Template-specific records omit fields that are not selected by T. The Transit Delay field is optional and is present only when the reporting node supports explicit forwarding-delay reporting.

Node-ID: 16 bits. Identifies a node uniquely within the telemetry namespace. In practical satellite systems, this field can be mapped to a spacecraft identifier. For CCSDS space data link usage, the Spacecraft Identifier (SCID) and the Transfer Frame Version Number (TFVN) together form a Global Spacecraft Identifier (GSCID), also used as the Master Channel Identifier (MCID). For frame versions 1 through 3, this is commonly a 2-bit TFVN concatenated with a 10-bit SCID, yielding a 12-bit GSCID/MCID. The SANA Spacecraft Identifier registry also records that version 4 (USLP) uses a 16-bit SCID and a 20-bit GSCID .
Ingress ID (in): 3 bits. Records the ingress interface on which the packet arrived at the reporting node.
Egress ID (eg): 3 bits. Records the egress interface on which the packet left the reporting node.
Traffic Class (tc): 6 bits. Supports traffic differentiation. This field reflects the priority of the original data packet and supports performance analysis across different service classes.
Reserved (re): 4 bits. Reserved for future extension without redesigning the metadata format. Senders MUST set this field to zero, and receivers MUST ignore it.
In Timestamp: 32 bits. Captures the packet arrival time at the node.
Out Timestamp: 32 bits. Captures the packet departure time from the node. Together with In Timestamp, this field supports precise per-hop and edge-to-edge delay calculation.
Transit Delay: 32 bits. Optional. When supported by the node, this field explicitly reports forwarding or queuing delay.
Queue Depth: 16 bits. Indicates instantaneous queue utilization at the reporting node.
Buffer Occupancy: 16 bits. Indicates shared-buffer usage at the reporting node.
Checksum Complement: 32 bits. Protects incremental telemetry data and helps ensure telemetry-information integrity.

Timestamp format and units for Queue Depth and Buffer Occupancy are namespace-specific operational parameters. A deployment MUST configure these parameters consistently for all nodes that process the same Namespace-ID. Packet loss and reordering analysis uses the Sequence Number carried in the ISFT Option Header together with the Flow-ID.

Collection Modes ISFT Collection Modes

Value	Mode	Behavior
00	Pre-allocated Trace-Option	The encapsulating node pre-allocates space for telemetry records after the ISFT Option Header. Participating nodes write their selected metadata into the pre-allocated data area according to a slot map configured for the Namespace-ID, selected Template, and ISFT Option Type.
01	Incremental Trace	Each participating node appends its metadata record after the ISFT Option Header, subject to MTU and local policy. The decapsulating node exports the collected trace and removes ISFT data.
10	Edge-to-Edge	Only the encapsulating and decapsulating nodes collect metadata. Transit nodes forward the packet without adding metadata.
11	Direct Export	Each participating node exports a telemetry report to one or more configured collectors. The data packet normally carries only the 8-octet ISFT Option Header.

In Pre-allocated Trace-Option mode, the amount of pre-allocated data area and the slot offset assigned to each participating node are namespace-local operational parameters. A node MUST write only to the slot assigned to its Node-ID for the packet's Namespace-ID and Template. A node that has no configured slot for the packet, or that determines that the packet does not contain the expected pre-allocated data area, MUST NOT write metadata to the packet and SHOULD report the condition according to local operational policy. This mode does not require an append operation at transit nodes.

Use of the IPv6 Flow Label Within an ISFT Domain, operators MAY configure a subset of the IPv6 Flow Label space to identify ISFT-selected flows. This allows transit nodes to recognize selected packets using fixed-position IPv6 header fields, avoiding repeated parsing of transport headers. The Flow Label value maps to the ISFT Flow-ID by local configuration or by copying the 20-bit Flow-ID value into the Flow Label of the ISFT-domain IPv6 header. A Flow Label value alone is not sufficient authorization to process ISFT. A node MUST process ISFT only when the packet is received on an interface and within a Namespace-ID configured for the ISFT Domain. A boundary node MUST clear or rewrite any ISFT-domain Flow Label semantics before forwarding the packet outside the ISFT Domain.

Encapsulation The ISFT Option Header is carried at the start of an ISFT-aware upper-layer payload or tunnel payload. For UDP, an ISFT-aware encapsulation can place the ISFT Option Header after the UDP header and before the tunnel or application data identified by the UDP destination port. For TCP, ISFT MUST be used only when the TCP application framing explicitly supports ISFT, or when TCP is used by a domain-local tunnel/adaptation function that removes ISFT before delivering data to a non-ISFT application. The encapsulating node is responsible for ensuring that the resulting packet fits the Path MTU of the ISFT Domain or for applying a domain policy that prevents fragmentation-related loss. A transit node in Incremental Trace mode MUST NOT append metadata if doing so would exceed the configured maximum ISFT packet size. This document does not request a new IPv6 extension header or a new UDP port. A future document can define an explicit UDP encapsulation and request any necessary IANA allocations.

Node Processing Rules

Encapsulating Node An encapsulating node that selects a packet for ISFT processing MUST:

determine the Namespace-ID, ISFT Option Type, Template, Flow-ID, and Sequence Number from local policy;
insert an ISFT Option Header using the format in ;
collect local metadata when required by the selected mode;
export local metadata or append it to the ISFT data area according to the selected mode; and
forward the packet only into the configured ISFT Domain.

Transit Node A transit node that receives an ISFT packet for a configured Namespace-ID MUST parse the ISFT Option Header. If the ISFT Option Type is unsupported, the node MUST ignore ISFT processing and forward or drop the packet according to local policy. If the Template is recognized and the selected mode requires transit processing, the node collects the indicated metadata and exports or appends it according to the selected mode.

Decapsulating Node A decapsulating node MUST remove the ISFT Option Header and any appended ISFT metadata before forwarding the packet outside the ISFT Domain. The node SHOULD export the final telemetry report before removal. If the node cannot remove ISFT information safely, it MUST NOT forward the packet outside the ISFT Domain unless local policy explicitly permits dropping the telemetry information by other means.

Telemetry Export Direct Export mode follows the same architectural idea as IOAM Direct Export : the in-flight packet triggers local telemetry collection and export, while the export packet format and collector protocol are deployment choices. This document does not define a collector transport or report envelope. Deployments SHOULD protect telemetry export traffic against spoofing, replay, and disclosure. Export reports SHOULD include at least the Namespace-ID, Flow-ID, node identity, Template, collection timestamp, and collected metadata.

Operational Considerations Operators need to configure ISFT Domain boundaries, Namespace-ID membership, Flow Label ranges, flow-selection rules, node identifiers, timestamp units, queue and buffer units, collector addresses, and MTU limits. In dynamic space networks, these parameters can be tied to scheduled topology epochs so that a collector can interpret telemetry records in the context of link availability and routing state. ISFT reduces the number of telemetry field combinations to eight fixed templates. This simplification improves implementation predictability but reduces flexibility compared to the IOAM Trace-Type bitmap defined by RFC 9197. Operators that need arbitrary field combinations SHOULD use standard IOAM data fields instead of ISFT templates.

IANA Considerations This document makes no IANA requests. If future revisions define a UDP encapsulation, a new IP protocol number, or a registry for ISFT option types or templates, those revisions will update this section with the required IANA actions.

Security Considerations ISFT exposes topology, timing, queue, buffer, and loss information. This information can reveal operational state and traffic patterns. ISFT therefore MUST be confined to a limited domain, and boundary nodes MUST prevent ISFT Option Headers and ISFT-domain Flow Label semantics from leaking outside that domain. Attackers that can inject ISFT packets could trigger unwanted telemetry export, consume processing resources, or poison measurements. Nodes MUST process ISFT only on configured domain interfaces and for configured Namespace-IDs. Telemetry export traffic SHOULD be authenticated and integrity protected. Confidentiality protection is RECOMMENDED when telemetry reports can reveal sensitive operational information. Using the IPv6 Flow Label as a domain-local telemetry marker creates a covert-channel and policy-bypass risk if the domain boundary is not enforced. Boundary filtering and explicit domain membership checks are REQUIRED.

Normative References Informative References CCSDS Spacecraft Identification Field Code Assignment Control Procedures Consultative Committee for Space Data Systems Corrigendum 1, July 2019. SANA Spacecraft Identifier Registry Space Assigned Numbers Authority

Acknowledgements This document is derived from an in-situ space flow telemetry method proposed for space-network measurement and monitoring. The authors thank the contributors and reviewers of the IOAM specifications whose work provides the basis for this profile.