| Internet-Draft | Hybrid Two-Step | October 2026 |
| Mirsky, et al. | Expires 28 April 2027 | [Page] |
The adoption of network operation automation has brought new measurement methodology requirements. Among them is the ability to collect the instant network operational state as the packet is being processed by the network elements along its forwarding path through a network domain. That requirement can be addressed by using on-path telemetry, also called hybrid performance measurement according to RFC 7799. An on-path telemetry method allows operators to collect key information that reflects the operational state and the network performance a packet experiences through the forwarding path. IOAM, defined in RFC 9197 and RFC 9326, is an example of such a hybrid method. This document introduces a method complementary to on-path telemetry that causes the generation of network telemetry information. This document introduces Hybrid Two-Step (HTS), a method complementary to both passive and hybrid measurement approaches. HTS separates measuring or calculating the performance metric from collecting and transporting network operational state.¶
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 28 April 2027.¶
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.¶
Successful resolution of challenges of automated network operation, as part of overall service orchestration and automated network operation, relies on a timely collection of accurate information that reflects the state of network elements. Because performing the analysis and act upon the collected information requires considerable computing and storage resources, the network operational state information is unlikely to be processed by the network elements themselves but will be exported to big data systems for processing and storing. The process of generating, and collecting network operational state information also referred to in this document as network telemetry, and transporting it for post-processing should work equally well with data flows or injected in the network test packets. [RFC7799] describes a combination of elements of passive and active measurement as a hybrid measurement.¶
Several technical methods have been proposed to enable the collection of network operational state information instantaneous to the packet processing, among them [P4.INT] and [RFC9197]. The instantaneous, i.e., in the data packet itself, collection of telemetry information simplifies the process of attribution of telemetry information to the particular monitored flow. On the other hand, this collection method impacts the data packets, potentially changing their treatment by the network elements. Also, the amount of information the instantaneous method collects might be incomplete because of the limited space it can be allotted. Other proposals defined methods to collect telemetry information in a separate packet from each node traversed by the monitored data flow. [RFC9326] is an example of this approach to collecting telemetry information. These methods allow data collection from any arbitrary path and avoid directly impacting data packets. On the other hand, to unambiguously correlate telemetry information with the monitored flow requires explicit characteristic information about the monitored flow to be carried in the packet that carries telemetry information.¶
This document introduces Hybrid Two-Step (HTS) as a new method of telemetry collection that improves accuracy of a measurement by separating the act of measuring or calculating the performance metric from the collecting and transporting this information while minimizing the overhead of the generated load in a network.¶
HTS method extends the two-step mode of Residence Time Measurement (RTM) defined in [RFC8169] to on-path network operational state collection and transport. HTS instruments data packets of the monitored flow or specially constructed test packets that are already equipped with a shim of on-path telemetry protocol to use as an HTS Trigger packet, making the process of attribution of telemetry to the data flow simple.¶
RTM Residence Time Measurement [RFC8169]¶
ECMP Equal Cost Multipath [RFC2992]¶
HMAC Hashed Message Authentication Code [RFC2104]¶
HTS Hybrid Two-Step (Section 1)¶
MTU Maximum Transmission Unit [RFC1191]¶
NSH Network Service Header [RFC8300]¶
This document makes use of the following terms:¶
Characteristic information - the interpretation in this document follows the definition of "Characteristic" in Section 3.2 in [RFC9940].¶
HTS domain is an example of a "limited domain" as defined in [RFC8799]. HTS domain may be identical to an IOAM domain (see Section 3 of [RFC9197]) or a controlled domain where the Alternate-Marking Method is used to measure performance metrics (see Section 7.1 of [RFC9341]).¶
HTS ingress node, defined in Section 4.2, an HTS system that generates an HTS Trigger and HTS Follow-up packets.¶
HTS intermediate node, defined in Section 4.3, an HTS system that receives the HTS Trigger and HTS Follow-up packets,¶
HTS egress node, defined in Section 4.4, consumes HTS Trigger packet and terminates an HTS Follow-up packet.¶
Telemetry is information reflecting the operational state of network elements, including performance metrics, collected and transported for analysis.¶
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.¶
Performance measurement and network telemetry often require collecting operational state information - such as timestamps, queue occupancy, buffer utilization, interface load, or other metrics - at multiple points along a packet's forwarding path. Methods that embed telemetry directly into data packets simplify correlation with the monitored flow but may be limited by MTU constraints, may be incompatible with encrypted packets, and may introduce processing overhead that affects measurement accuracy.¶
For encrypted packets, inserting telemetry information directly into the data packet may be impossible or may degrade measurement accuracy because the packet cannot be safely modified while in transit. Accurate comparison of timestamps depends on the availability of time synchronization across the HTS domain.¶
In some networks, it is beneficial to collect telemetry at network elements other than the egress, depending on the performance metric and operational objective. For example, a head-end may optimize path selection based on upstream telemetry reflecting queue depth, buffer occupancy, or interface utilization.¶
These challenges motivate the HTS method, which separates the act of measuring or collecting telemetry from the act of transporting it. HTS handles both performance measurements and telemetry information using the same two‑step mechanism. An HTS Trigger initiates telemetry collection, and one or more HTS Follow-up packets carry the collected information. These phases are described in Section 4.¶
HTS measurement operates within an HTS domain consisting of an HTS Ingress node, zero or more HTS Intermediate nodes, and an HTS Egress node. HTS Trigger packets originate at the HTS Ingress node and are forwarded downstream through the HTS domain. HTS Follow‑up packets are generated by the HTS Egress node and sent upstream toward the HTS Ingress node.¶
A reference HTS topology is illustrated in Figure 1.¶
HTS telemetry is ultimately consumed by a Collector, which is a logical function responsible for receiving, correlating, and analyzing HTS measurement results. The Collector may be co‑located with the HTS Egress node or may reside on a remote system such as a controller, analytics engine, or network management system. The Collector is not part of the HTS domain and does not process HTS packets directly.¶
HTS Domain
-----------------------------------------------------
+---------+ +-------------+ +---------+
| Ingress | ---> |Intermediate | ---> | Egress |
+---------+ +-------------+ +---------+
| | |
| HTS Trigger | HTS Trigger | HTS Trigger
| HTS Follow-up | HTS Follow-up | HTS Follow-up
| (originates) | (adds telemetry) | (terminates)
-----------------------------------------------------
|
| Telemetry Export
v
+-------------+
| Collector |
+-------------+
The HTS Egress node terminates HTS Follow‑up packets, validates the HTS shim and Telemetry Data TLVs, and exports the resulting measurement information to the Collector. HTS Error Codes, when present, are generated only by the HTS Egress node and delivered to the Collector as part of the telemetry export. Intermediate nodes do not generate HTS Error Codes.¶
The HTS method consists of two phases:¶
HTS uses two packet types: HTS Trigger packets, which initiate telemetry collection, and HTS Follow-up packets, which carry the collected telemetry. The HTS Trigger and HTS Follow-up packets MUST traverse the same forwarding path within the HTS domain to ensure correct correlation of telemetry information.¶
Characteristic Information, in context of HTS, refers to the set of fields carried in an HTS Trigger and HTS Follow-up packet that uniquely identifies the monitored flow and ensures that both packets traverse the same forwarding path within the HTS domain.¶
For a given monitored flow, Characteristic Information MUST be invariant and MUST be identical in the HTS Trigger and all HTS Follow-up packets associated with that Trigger. HTS nodes MUST use this invariant information to correlate HTS Follow-up packets with the corresponding HTS Trigger packets.¶
Characteristic Information MUST preserve the forwarding behavior of the HTS Trigger packet and MUST NOT be modified by HTS nodes.¶
Below are some examples of Characteristic Information:¶
The exact composition of Characteristic Information is transport‑specific and outside the scope of this document, but all HTS nodes MUST treat it as immutable and use it to correlate HTS Trigger and Follow-up packets.¶
An HTS Trigger is a user data packet or specially constructed test packet instrumented to cause network elements to collect telemetry information. The Trigger packet includes characteristic information that allows HTS nodes to associate the Trigger with the monitored flow. The specific format of the Trigger depends on the telemetry framework used in the HTS domain.¶
When HTS is used in an IOAM domain, the Trigger packet carries an IOAM Option-Type set to the "IOAM Hybrid Two-Step Option-Type" value (TBA1) allocated by IANA (Section 7.1). The HTS Trace IOAM Header is shown in Figure 2.¶
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 | Flags |Extension-Flags|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IOAM-Trace-Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flow ID (Optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number (Optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The HTS Trigger includes HTS IOAM Header (shown in Figure 2) consists of:¶
These fields provide the characteristic information needed for HTS nodes to associate the HTS Trigger packet with the monitored flow.¶
In an Alternate‑Marking domain ([RFC9341], [RFC9342]), any packet in a flow that carries the marking information MAY serve as an HTS Trigger. The exact transport encapsulation of the HTS Trigger packet is specific to the Alternate‑Marking deployment and is outside the scope of this document. Regardless of the encapsulation, the HTS Trigger packet MUST carry characteristic information sufficient for HTS nodes to associate it with the monitored flow.¶
An HTS Follow-up packet carries telemetry information collected by HTS nodes along the path traversed by the HTS Trigger packet. The ingress network element (Figure 1) that originates the HTS Trigger packet also originates the corresponding HTS Follow-up packet. In upstream collection mode, an HTS Follow-up packet MAY be generated without a preceding Trigger, provided that the Follow-up packet includes Characteristic Information sufficient to identify the monitored flow.¶
An HTS Follow-up packet MUST carry the same Characteristic Information as the associated HTS Trigger packet. HTS nodes MUST treat this information as immutable and MUST use it to ensure that the HTS Follow-up packet traverses the same forwarding path as the HTS Trigger packet.¶
The Follow-up packet consists of the transport encapsulation determined by the Characteristic Information, followed by the HTS shim and one or more Telemetry Data TLVs. The HTS shim indicates the maximum allowed size of the Follow-up packet and the telemetry profile requested by the ingress node.¶
Only one outstanding Follow-up packet MAY exist per path at a node. If a node receives a new HTS Trigger packet while an HTS Follow-up packet for the same flow is still pending, the node MUST first originate the Follow-up packet for the earlier HTS Trigger before processing the new HTS Trigger packet.¶
The following sections describe the operation of HTS nodes in the downstream mode of collecting the telemetry information. In the upstream mode, the behavior of HTS nodes, in general, identical with the exception that the HTS Trigger packet does not precede the HTS Follow-up packet.¶
The HTS ingress node is the network element that originates HTS Trigger packets and the corresponding HTS Follow-up packets. The ingress node is responsible for constructing the HTS Trigger packet, initiating telemetry collection, and generating HTS Follow-up packets that carry telemetry collected along the forwarding path.¶
Upon originating an HTS Trigger, the ingress node MUST:¶
For each HTS Trigger packet, the HTS ingress node MUST originate a corresponding HTS Follow-up packet unless operating in upstream collection mode. The ingress node constructs the HTS Follow-up packet using the format shown in Figure 3. The Follow-up packet consists of the transport encapsulation determined by the Characteristic Information, followed by the HTS shim and one or more Telemetry Data TLVs. The ingress node MUST populate the HTS shim fields as described below and MUST ensure that the Follow-up packet carries the same Characteristic Information as the associated HTS Trigger.¶
The HTS ingress node MUST:¶
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Transport Network ~ | Encapsulation | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--- |Ver|HTS Shim L | Flags |Sequence Number| Error Code |HTS +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ S | HTS Max Length | h +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ i ~ Telemetry Data Profile ~ m +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--- | | ~ Telemetry Data TLVs ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields of the HTS shim are as follows:¶
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|F| Reserved |
+-+-+-+-+-+-+-+-+
Flags is eight-bits long. The format of the Flags field displayed in Figure 4.¶
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Reserved | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Value ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Telemetry Data TLV is a variable-length field. Multiple TLVs MAY be placed in an HTS packet. Additional TLVs may be enclosed within a given TLV, subject to the semantics of the (outer) TLV in question. Figure 5 presents the format of a Telemetry Data TLV, where fields are defined as the following:¶
All multibyte fields defined in this specification are in network byte order.¶
An HTS intermediate node is a network element that receives and forwards HTS Trigger packets and HTS Follow-up packets. Intermediate nodes collect telemetry data and contribute it to the Follow-up packet while ensuring that the packet remains within the MTU constraints of the path.¶
Intermediate nodes MUST NOT modify Characteristic Information and MUST use it to correlate Trigger and Follow-up packets.¶
Upon receiving an HTS Trigger packet, an intermediate node MUST:¶
Upon receiving an HTS Follow-up packet, an intermediate node MUST:¶
If the HTS Follow-up Timer expires before a Follow-up packet is received, the intermediate node MUST:¶
The HTS Egress node terminates synthetic HTS Trigger packets and forwards data packets used as HTS Trigger packets according to normal forwarding behavior. The Egress node is responsible for correlating synthetic HTS Trigger packets with the corresponding HTS Follow‑up packets, validating the HTS shim and Telemetry Data TLVs contained in HTS Follow‑up packets, generating HTS Error Codes when processing errors are detected, and exporting the resulting telemetry to the Collector. The Collector is a logical function that receives, correlates, and analyzes HTS measurement results. The Collector may be co‑located with the Egress node or may reside on a remote system such as a controller, analytics engine, or network management system. The Collector is not part of the HTS domain and does not process HTS packets directly.¶
HTS Error Codes are generated only by the HTS Egress node and are delivered to the Collector as part of the telemetry export. HTS Trigger packets do not carry HTS shim or Telemetry Data TLVs and cannot be malformed in an HTS‑specific sense.¶
When an HTS Trigger packet (synthetic or data‑packet) arrives at the Egress node, the node performs the following steps:¶
Synthetic Trigger packets and data‑packet Triggers do not carry HTS shim or Telemetry Data TLVs and cannot be malformed in an HTS‑specific sense.¶
HTS Follow‑up packets may arrive at the Egress node as a sequence of packets generated in response to a single HTS Trigger packet. Each Follow‑up packet contains the HTS shim, Telemetry Data TLVs, and optionally the HTS HMAC TLV. HTS Error Codes generated during HTS Follow‑up packet validation are defined in Section 7.2.4. The conditions under which each Error Code is generated are specified in this section. The Egress node processes each Follow‑up packet in the sequence as follows:¶
The HTS Collection Timer is started when the Egress node receives an HTS Trigger packet (synthetic or data‑packet). The timer is used to detect loss or excessive delay of HTS Follow‑up packets generated in response to that Trigger. Because multiple HTS Follow‑up packets may be generated for a single Trigger, the Egress node maintains the timer across the entire sequence of Follow‑up packets.¶
When an HTS Follow‑up packet is received, the Egress node MUST clear the HTS Collection Timer associated with the monitored flow identified by a locally unique Characteristic Information. If the Full flag in the Follow‑up packet is set, indicating that additional Follow‑up packets are expected, he Egress node MUST restart the HTS Collection Timer. If the Full flag is not set, the Follow‑up packet is the final packet in the sequence, and the Egress node MUST NOT restart the timer.¶
If the HTS Collection Timer expires before the final HTS Follow‑up packet in the sequence is received, the Egress node performs the following steps:¶
This section describes operational aspects of deploying HTS in a network. These considerations are informational and do not impose additional protocol requirements beyond those specified in Section 4.¶
HTS relies on the Trigger and Follow‑up packets traversing the same forwarding path. Operators MUST ensure that the Characteristic Information used in the Trigger and Follow‑up packets is sufficient to preserve forwarding behavior across the HTS domain.¶
Examples of fields that influence forwarding include:¶
Operators SHOULD verify that these fields are stable and predictable across the HTS domain. If forwarding behavior changes due to ECMP rebalancing, policy routing, or service‑function steering, HTS telemetry may be incomplete or inconsistent.¶
HTS Follow‑up packets grow as telemetry is added by intermediate nodes. Operators SHOULD ensure that:¶
If an intermediate node cannot append telemetry without exceeding HTS Max Length, it will set the Full flag and originate a new Follow‑up packet. Operators SHOULD monitor this condition, as frequent Full‑flag events may indicate insufficient MTU headroom or excessive telemetry volume.¶
HTS uses two types of timers:¶
Operators SHOULD configure timer values based on:¶
Timers that are too short may cause premature origination of Follow‑up packets. Timers that are too long may delay telemetry delivery.¶
The Telemetry Data Profile determines which telemetry elements are collected by HTS nodes. Operators SHOULD select a profile that balances:¶
Profiles that request high‑volume telemetry (e.g., queue depth, buffer occupancy, interface load) may require larger HTS Max Length values or more frequent Full‑flag events.¶
HTS nodes MUST validate Trigger and Follow‑up packets as described in Section 4. Mis‑injected or malformed packets may occur due to:¶
Operators SHOULD monitor for validation failures and investigate persistent anomalies. Egress nodes MUST discard invalid Follow‑up packets and SHOULD log such events for operational visibility.¶
HTS supports both upstream and downstream collection modes:¶
Operators SHOULD select the mode based on:¶
Upstream mode may reduce packet size on long paths, while downstream mode provides earlier visibility into telemetry collected by intermediate nodes.¶
HTS can be deployed in multicast networks, but operators should be aware that Trigger and Follow‑up packets behave differently in multicast forwarding trees.¶
An HTS Trigger packet follows the multicast distribution tree determined by the transport encapsulation and Characteristic Information. As a result:¶
HTS does not modify multicast forwarding behavior; the Trigger is replicated exactly as a normal multicast packet would be.¶
HTS Follow‑up packets do not follow multicast replication semantics. A Follow‑up packet is always unicast toward the HTS collector or toward the node that originated the Trigger, depending on the deployment mode.¶
As a result:¶
Network analytics should expect one train of Follow‑up packets per multicast branch, not one per Trigger.¶
Because each multicast branch produces a separate train of Follow‑up packets:¶
Each egress node in the multicast tree maintains its own HTS Collection Timer. Timer expirations may occur independently on different branches, especially when:¶
Operators should expect asynchronous Follow‑up arrivals from different multicast receivers.¶
Telemetry information may be used to drive network operation, closing the control loop for self-driving, self-healing networks. Thus, it is critical to provide a mechanism to protect the telemetry information collected using the HTS method.¶
This document defines an optional HTS HMAC TLV that provides integrity protection for HTS shim fields and Telemetry Data TLVs. The format of the HMAC sub-TLV is displayed in Figure 6.¶
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Authentic. Type| HMAC Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Digest |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where fields are defined as follows:¶
This specification defines the use of HMAC-SHA-256 truncated to 128 bits ([RFC4868]) in HTS. Future specifications may define the use in HTS of more advanced cryptographic algorithms or the use of digest of a different length. HMAC is calculated as defined in [RFC2104] over text as the concatenation of the Sequence Number field of the Follow-up packet (see Figure 3) and the preceding data collected in the Telemetry Data TLV. The digest then MUST be truncated to 128 bits and written into the Digest field. Distribution and management of shared keys are outside the scope of this document. In the HTS authenticated mode, the Authentication sub-TLV MUST be present in each Telemetry Data TLV. HMAC MUST be verified before using any data in the included Telemetry Data TLV. If HMAC verification fails, the system MUST stop processing corresponding Telemetry Data TLV and notify an operator. Specification of the notification mechanism is outside the scope of this document.¶
To authenticate the Follow-up packets, operators MAY use authentication mechanisms available in the transport encapsulation used to carry HTS. Examples include:¶
Operators SHOULD enable authentication when HTS packets traverse untrusted or multi‑tenant environments.¶
Characteristic Information determines the forwarding behavior of HTS Trigger and Follow‑up packets.¶
To prevent mis‑routing or mis‑injection, operators should use integrity mechanisms provided by the underlying transport encapsulation (e.g., IPsec AH/ESP, MACsec, NSH MD‑Type 1 authentication metadata). These mechanisms help ensure that Characteristic Information is not modified in transit.¶
HTS nodes perform validation of Characteristic Information as part of normal HTS packet processing (Section 4). Integrity protection at the transport layer complements this validation by preventing unauthorized modification of fields that influence forwarding behavior.¶
HTS does not define new integrity mechanisms for telemetry data. Telemetry Data TLVs MAY be protected by existing OAM integrity mechanisms, such as:¶
HTS nodes SHOULD be authenticated using mechanisms appropriate to the deployment environment, such as:¶
Authentication of HTS nodes ensures that Trigger and Follow‑up packets originate only from authorized devices.¶
This document requests IANA to make several allocations and create registries associated with HTS. HTS also defines a new IOAM Option-Type, which must be allocated from the existing IOAM Option Types registry established by [RFC9197]. HTS does not modify any other IOAM registries.¶
This document defines a new IOAM HTS Option-Type, which instructs IOAM-capable nodes to perform HTS processing when operating within an IOAM domain. The IOAM HTS Option-Type is an alternative IOAM behavior, similar in nature to IOAM‑Trace, IOAM‑DEX, and IOAM Proof‑of‑Transit.¶
IANA is requested to allocate a new value from the “IOAM Option Types” registry established by [RFC9197]. IANA is requested to allocate a new code point as listed in Table 1.¶
| Value | Name | Description | Reference |
|---|---|---|---|
| TBA1 | IOAM Hybrid Two-Step (HTS) Option-Type | Instructs IOAM nodes to apply HTS processing to the packet within the IOAM domain | This document |
IANA is requested to create "Hybrid Two-Step" registry group.¶
IANA is requested to create the HTS TLV Type registry in the "Hybrid Two-Step" registry group. All code points in the range 1 through 175 in this registry shall be allocated according to the "IETF Review" procedure specified in [RFC8126]. Code points in the range 176 through 239 in this registry shall be allocated according to the "First Come First Served" procedure specified in [RFC8126]. The remaining code points are allocated according to Table 2:¶
| Value | Description | Reference |
|---|---|---|
| 0 | Reserved | This document |
| 1 - 175 | Unassigned | This document |
| 176 - 239 | Unassigned | This document |
| 240 - 251 | Experimental | This document |
| 252 - 254 | Private Use | This document |
| 255 | Reserved | This document |
IANA is requested to create the HTS sub-TLV Type sub-registry as part of the HTS TLV Type registry. All code points in the range 1 through 175 in this registry shall be allocated according to the "IETF Review" procedure specified in [RFC8126]. Code points in the range 176 through 239 in this registry shall be allocated according to the "First Come First Served" procedure specified in [RFC8126]. The remaining code points are allocated according to Table 3:¶
| Value | Description | TLV Used | Reference |
|---|---|---|---|
| 0 | Reserved | None | This document |
| 1 | HMAC | Any | This document |
| 2 - 175 | Unassigned | This document | |
| 176 - 239 | Unassigned | This document | |
| 240 - 251 | Experimental | This document | |
| 252 - 254 | Private Use | This document | |
| 255 | Reserved | None | This document |
IANA is requested to create the HMAC Type sub-registry as part of the HTS TLV Type registry. All code points in the range 1 through 127 in this registry shall be allocated according to the "IETF Review" procedure specified in [RFC8126]. Code points in the range 128 through 239 in this registry shall be allocated according to the "First Come First Served" procedure specified in [RFC8126]. The remaining code points are allocated according to Table 4:¶
| Value | Description | Reference |
|---|---|---|
| 0 | Reserved | This document |
| 1 | HMAC-SHA-256 16 octets long | This document |
| 2 - 127 | Unassigned | This document |
| 128 - 239 | Unassigned | This document |
| 240 - 249 | Experimental | This document |
| 250 - 254 | Private Use | This document |
| 255 | Reserved | This document |
IANA is requested to create in the HTS registry group the new Error Codes registry as follows:¶
| Value | Name | Description | Reference |
|---|---|---|---|
| 0 | No Error | No error detected | This document |
| 1 | Invalid HTS Shim | HTS shim validation failed | This document |
| 2 | Invalid Telemetry Data TLV | TLV malformed, inconsistent, or unsupported | This document |
| 3 | HMAC Verification Failure | HMAC TLV present but authentication failed | This document |
| 4 | Follow‑up Not Received | HTS Collection Timer expired before final Follow‑up packet | This document |
| 5 | Local Processing Error | Internal Egress processing error | This document |
| 6 - 247 | Unassigned | This document | |
| 248-251 | Reserved for Experimental Use | This document | |
| 252-255 | Reserved for Private Use | This document |
HTS introduces new packet types (Trigger and Follow‑up) and new metadata (HTS shim, Telemetry Data TLVs, and optional HTS HMAC TLV). This section describes the security considerations associated with processing these packets and metadata. HTS does not modify the security properties of the underlying transport encapsulation.¶
Characteristic Information determines the forwarding behavior of HTS Trigger and Follow‑up packets.¶
If Characteristic Information is modified, mis‑routed, or mis‑injected, HTS packets may:¶
HTS nodes MUST validate Characteristic Information as described in Section 4. Packets whose Characteristic Information fails validation MUST be discarded. Operators SHOULD protect Characteristic Information using authentication or integrity mechanisms provided by the underlying transport encapsulation (e.g., IPsec AH/ESP, MACsec, NSH MD‑Type 1 authentication metadata).¶
HTS Follow‑up packets carry telemetry data contributed by intermediate nodes.¶
An attacker who modifies telemetry data or HTS shim fields could:¶
Operators SHOULD enable integrity protection when telemetry is used for security‑sensitive applications.¶
HTS defines an optional HTS HMAC TLV (Section 6.1) that provides integrity protection for HTS shim fields and Telemetry Data TLVs.¶
When present, HTS nodes MUST validate the HMAC TLV before processing the packet.¶
Packets whose HMAC validation fails MUST be discarded.¶
HTS telemetry may include information about:¶
This information may be sensitive in multi‑tenant or shared environments.¶
Operators SHOULD protect telemetry export channels (e.g., IPFIX, gRPC, NETCONF/RESTCONF) using authentication and encryption mechanisms appropriate to the deployment environment.¶
HTS does not define confidentiality mechanisms for telemetry data carried in Follow‑up packets.¶
Operators SHOULD rely on transport‑layer confidentiality mechanisms (e.g., IPsec ESP, MACsec, DTLS) when confidentiality is required.¶
Replay of HTS Follow‑up packets could cause:¶
HTS shim Sequence Numbers provide basic replay detection.¶
Egress HTS nodes and Collectors SHOULD discard Follow‑up packets whose Sequence Numbers are stale or inconsistent with previously received packets.¶
When the HTS HMAC TLV is used, replayed packets will fail HMAC validation if the HMAC includes a nonce or timestamp.¶
In multicast deployments:¶
Attackers could attempt to inject false Follow‑up packets from unauthorized multicast receivers.¶
Egress HTS nodes MUST validate Characteristic Information and HTS shim fields and MUST validate the HTS HMAC TLV when present before processing the Follow-up packets.¶
Operators SHOULD ensure that multicast receivers are authenticated and authorized to participate in HTS measurement.¶
HTS introduces additional packet processing at ingress, intermediate, and egress nodes.¶
An attacker could attempt to overload HTS nodes by:¶
HTS ingress nodes MUST provide a mechanism to rate‑limit HTS Trigger packets and SHOULD apply local policies to prevent excessive resource consumption.¶
Collectors SHOULD detect abnormal HTS packet rates and alert operators.¶
Authors express their gratitude and appreciation to Joel Halpern for the most helpful and insightful discussion on the applicability of HTS in a Service Function Chaining domain. Also, the authors thank Bjørn Ivar Teigen for the discussion about ensuring proper correlation between generated telemetry information and an HTS Follow-up packet. And a special thank you to Xiao Min for thorough review and thoughtful suggestions that helped in improving the document.¶