In-situ Space Flow Telemetry for IPv6 Limited Domains

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 20 January 2027.¶

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 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

IOAM records operational and telemetry information while a packet traverses a network path [RFC9197]. 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 [RFC8200] 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 [RFC9673].¶

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.¶

2. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

3. Terminology

ISFT

In-situ Space Flow Telemetry.¶

ISFT Domain

A limited domain [RFC8799] 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.¶

4. 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 [RFC6437].¶

5. Protocol Overview

ISFT processing has three stages:¶

1. 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.¶
2. 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.¶
3. 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.¶

6. 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.¶

  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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |       Namespace-ID     | O |  T  |          Flow-ID          |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                        Sequence Number                       |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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 Section 9.¶

T: 3 bits

Telemetry template. Values are defined in Section 7.¶

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.¶

7. 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 Section 8. 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.¶

8. 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.¶

  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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |            Node-ID            | in| eg|   tc    |     re      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                         In Timestamp                         |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                         Out Timestamp                        |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                         Transit Delay                        |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |          Queue Depth          |       Buffer Occupancy        |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                      Checksum Complement                      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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 [CCSDS320] [SANA-SCID].¶
• 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.¶

9. Collection Modes

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.¶

10. 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.¶

11. 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.¶

12. Node Processing Rules

13. Telemetry Export

Direct Export mode follows the same architectural idea as IOAM Direct Export [RFC9326]: 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.¶

14. 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.¶

15. 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.¶

16. 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.¶

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.¶

Authors' Addresses