IP Performance Measurement H. Zhang Internet-Draft J. Liu Intended status: Standards Track K. Zhao Expires: 20 January 2027 W. Li Nanjing University 19 July 2026 In-situ Space Flow Telemetry for IPv6 Limited Domains draft-zhang-ippm-isft-space-flow-telemetry-00 Abstract 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. 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. Zhang, et al. Expires 20 January 2027 [Page 1] Internet-Draft ISFT July 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 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. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Applicability and Scope . . . . . . . . . . . . . . . . . . . 4 5. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4 6. ISFT Option Header Format . . . . . . . . . . . . . . . . . . 5 7. Telemetry Templates . . . . . . . . . . . . . . . . . . . . . 6 8. Metadata Fields . . . . . . . . . . . . . . . . . . . . . . . 7 9. Collection Modes . . . . . . . . . . . . . . . . . . . . . . 8 10. Use of the IPv6 Flow Label . . . . . . . . . . . . . . . . . 9 11. Encapsulation . . . . . . . . . . . . . . . . . . . . . . . . 10 12. Node Processing Rules . . . . . . . . . . . . . . . . . . . . 10 12.1. Encapsulating Node . . . . . . . . . . . . . . . . . . . 10 12.2. Transit Node . . . . . . . . . . . . . . . . . . . . . . 11 12.3. Decapsulating Node . . . . . . . . . . . . . . . . . . . 11 13. Telemetry Export . . . . . . . . . . . . . . . . . . . . . . 11 14. Operational Considerations . . . . . . . . . . . . . . . . . 11 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 16. Security Considerations . . . . . . . . . . . . . . . . . . . 12 17. Normative References . . . . . . . . . . . . . . . . . . . . 12 18. Informative References . . . . . . . . . . . . . . . . . . . 13 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 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. Zhang, et al. Expires 20 January 2027 [Page 2] Internet-Draft ISFT July 2026 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 Zhang, et al. Expires 20 January 2027 [Page 3] Internet-Draft ISFT July 2026 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: Zhang, et al. Expires 20 January 2027 [Page 4] Internet-Draft ISFT July 2026 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: 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 Section 9. T: 3 bits Telemetry template. Values are defined in Section 7. Zhang, et al. Expires 20 January 2027 [Page 5] Internet-Draft ISFT July 2026 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. +=======+============+===========================================+ | 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 | Delay fields and the ISFT Sequence Number | | | Loss | from the ISFT Option Header | +-------+------------+-------------------------------------------+ | 100 | Congestion | Queue Depth, Buffer Occupancy | +-------+------------+-------------------------------------------+ | 101 | Delay and | Delay fields, Queue Depth, Buffer | | | Congestion | Occupancy | +-------+------------+-------------------------------------------+ | 110 | Loss and | ISFT Sequence Number from the ISFT Option | | | Congestion | Header, Queue Depth, Buffer Occupancy | +-------+------------+-------------------------------------------+ | 111 | Delay, | Delay fields, the ISFT Sequence Number | | | Loss, and | from the ISFT Option Header, Queue Depth, | | | Congestion | Buffer Occupancy | +-------+------------+-------------------------------------------+ Table 1: ISFT Template Values Zhang, et al. Expires 20 January 2027 [Page 6] Internet-Draft ISFT July 2026 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: 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 [CCSDS320] [SANA-SCID]. * Ingress ID (in): 3 bits. Records the ingress interface on which the packet arrived at the reporting node. Zhang, et al. Expires 20 January 2027 [Page 7] Internet-Draft ISFT July 2026 * 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 +=======+===============+===========================================+ | Value | Mode | Behavior | +=======+===============+===========================================+ | 00 | Pre-allocated | The encapsulating node pre-allocates | | | Trace-Option | 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 | Zhang, et al. Expires 20 January 2027 [Page 8] Internet-Draft ISFT July 2026 | | | for the Namespace-ID, selected | | | | Template, and ISFT Option Type. | +-------+---------------+-------------------------------------------+ | 01 | Incremental | Each participating node appends its | | | Trace | 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. | +-------+---------------+-------------------------------------------+ Table 2: ISFT 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. Zhang, et al. Expires 20 January 2027 [Page 9] Internet-Draft ISFT July 2026 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 12.1. Encapsulating Node An encapsulating node that selects a packet for ISFT processing MUST: 1. determine the Namespace-ID, ISFT Option Type, Template, Flow-ID, and Sequence Number from local policy; 2. insert an ISFT Option Header using the format in Section 6; 3. collect local metadata when required by the selected mode; 4. export local metadata or append it to the ISFT data area according to the selected mode; and 5. forward the packet only into the configured ISFT Domain. Zhang, et al. Expires 20 January 2027 [Page 10] Internet-Draft ISFT July 2026 12.2. 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. 12.3. 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. 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. Zhang, et al. Expires 20 January 2027 [Page 11] Internet-Draft ISFT July 2026 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. 17. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, . Zhang, et al. Expires 20 January 2027 [Page 12] Internet-Draft ISFT July 2026 [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, "IPv6 Flow Label Specification", RFC 6437, DOI 10.17487/RFC6437, November 2011, . 18. Informative References [RFC8799] Carpenter, B. and B. Liu, "Limited Domains and Internet Protocols", RFC 8799, DOI 10.17487/RFC8799, July 2020, . [RFC9197] Brockners, F., Ed., Bhandari, S., Ed., and T. Mizrahi, Ed., "Data Fields for In Situ Operations, Administration, and Maintenance (IOAM)", RFC 9197, DOI 10.17487/RFC9197, May 2022, . [RFC9326] Song, H., Gafni, B., Brockners, F., Bhandari, S., and T. Mizrahi, "In Situ Operations, Administration, and Maintenance (IOAM) Direct Exporting", RFC 9326, DOI 10.17487/RFC9326, November 2022, . [RFC9673] Hinden, R. and G. Fairhurst, "IPv6 Hop-by-Hop Options Processing Procedures", RFC 9673, DOI 10.17487/RFC9673, October 2024, . [CCSDS320] Consultative Committee for Space Data Systems, "CCSDS Spacecraft Identification Field Code Assignment Control Procedures", CCSDS 320.0-M-7, Recommended Practice Issue 7, November 2017, . Corrigendum 1, July 2019. [SANA-SCID] Space Assigned Numbers Authority, "SANA Spacecraft Identifier Registry", . 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 Zhang, et al. Expires 20 January 2027 [Page 13] Internet-Draft ISFT July 2026 Huijie Zhang Nanjing University 163 Xianlin Avenue Nanjing Jiangsu, 210023 China Email: 522024230088@smail.nju.edu.cn Jun Liu Nanjing University Email: johnson.liu@nju.edu.cn Kanglian Zhao Nanjing University Email: zhaokanglian@nju.edu.cn Wenfeng Li Nanjing University Email: leewf_cn@hotmail.com Zhang, et al. Expires 20 January 2027 [Page 14]