| Internet-Draft | TWAMP and STAMP for SRv6 Slices | June 2026 |
| Yang, et al. | Expires 24 December 2026 | [Page] |
Network Slices realized over Segment Routing over IPv6 (SRv6) networks use slice-specific forwarding resources that are selected by a slice indicator carried in the IPv6 packet. For two-way active measurement results to reflect the conditions experienced by traffic within a given network slice, the probe packets generated by the Two-Way Active Measurement Protocol (TWAMP) and the Simple Two-Way Active Measurement Protocol (STAMP) need to be forwarded over the same slice-specific resources as the data traffic they are intended to characterize.¶
This document specifies how a slice indicator is carried in TWAMP and STAMP probe packets so that those packets are forwarded through the resources of a target slice, and it defines the corresponding Session-Sender and Session-Reflector behavior. The procedures are independent of the specific encoding used to carry the slice indicator in the SRv6 data plane.¶
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 24 December 2026.¶
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.¶
A Network Slice, as defined in [RFC9543], provides connectivity between a set of endpoints together with specific commitments on network resources. In networks that use Segment Routing over IPv6 (SRv6) [RFC8754] [RFC8986], a network slice can be realized by partitioning forwarding resources (for example queues, scheduling, bandwidth, and candidate paths) and by associating each packet with a slice through a slice indicator carried in the IPv6 packet.¶
Several encodings have been defined for carrying a slice indicator in SRv6 packets. These include carrying the indicator in a Hop-by-Hop Options header [I-D.ietf-6man-enhanced-vpn-vtn-id] and carrying it within the SRv6 SID [I-D.ietf-spring-srv6-encoding-network-sliceid]. The procedures defined in this document operate on the slice indicator as an abstract value and apply regardless of which of these encodings is deployed in a particular network.¶
The Two-Way Active Measurement Protocol (TWAMP) [RFC5357] and the Simple Two-Way Active Measurement Protocol (STAMP) [RFC8762] are used to measure round-trip delay, delay variation, and packet loss between two endpoints. When these protocols are used in an SRv6 network that supports network slices, a probe packet that does not carry the slice indicator of the slice under test may be forwarded using default resources rather than the slice-specific resources. In that case the measurement characterizes the default forwarding behavior and not the slice, and the result does not represent the experience of data traffic in the slice. Carrying the slice indicator in the probe packets is therefore necessary for the measurement to be representative of the slice.¶
Procedures for performing STAMP-based measurement over SR paths, including SRv6 SR Policies, are specified in [I-D.ietf-spring-stamp-srpm-srv6]. The present document is complementary to that work: it specifies how the slice indicator, which is orthogonal to the SR path itself, is set and preserved across the measurement so that the probe receives the slice-specific forwarding treatment. The relationship to related work is described in Section 5.¶
The procedures in this document carry MUST-level requirements on the construction of probe packets at the Session-Sender and Session-Reflector. The document is therefore on the Standards Track.¶
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.¶
This document uses the terminology defined in [RFC9543] for network slices, in [RFC8754] and [RFC8986] for SRv6, and in [RFC5357] and [RFC8762] for two-way active measurement. The following term is used throughout this document.¶
Figure 1 illustrates the measurement reference model. The Session-Sender (R1) sends a probe query that carries the slice indicator of the target slice through the SRv6 network to the Session-Reflector (R5). The reflected response carries the same slice indicator so that both directions traverse the slice-specific resources. The timestamps t1 through t4 are collected as in [RFC5357] and [RFC8762].¶
t1 t2
/ \
+------+ Query (with slice indicator) +------+
| |================================>| |
| R1 | slice-specific resources | R5 |
| |<================================| |
+------+ Response (with slice indicator)+------+
\ /
t4 t3
Session- Session-
Sender Reflector
When the Session-Sender is configured to measure a specific network slice, it MUST associate the measurement session with that slice and MUST include the slice indicator of the target slice in every probe query packet that it transmits for the session. The slice indicator MUST be encoded in the same location and format that data traffic for the slice uses, so that intermediate nodes apply the same slice-specific forwarding treatment to the probe as to data traffic.¶
The SRv6 encapsulation of the probe packet, comprising the outer IPv6 header and any Segment Routing Header (SRH) [RFC8754], MUST correspond to the forwarding path selected for the target slice, so that the probe and the data traffic of the slice are subject to the same path and the same per-hop resource selection.¶
When a Session-Sender maintains measurement sessions for more than one slice, it MUST maintain independent measurement state, including delay, delay variation, and loss counters, for each slice.¶
The Session-Reflector processes a received probe query according to the procedures of TWAMP [RFC5357] or STAMP [RFC8762]. The slice indicator is not part of the session identification: session matching uses the means already defined by those protocols, such as the IP and UDP header fields for TWAMP or the Session-Sender identification for STAMP. A Session-Reflector MUST NOT rely on the slice indicator to demultiplex measurement sessions.¶
When constructing the reflected response, the Session-Reflector MUST set the slice indicator of the response to the value received in the corresponding query, and MUST apply the same encoding that data traffic of that slice uses, so that the response traverses the slice-specific resources on the return path. The slice indicator received in the query MUST NOT be changed in the response.¶
A Session-Reflector can be stateful or stateless (Section 4 of [RFC8762]). The behavior in the preceding paragraph applies to both, with the following distinction:¶
If a Session-Reflector receives a probe query whose slice indicator identifies a slice in which the reflector does not participate, or that it cannot map to a known slice forwarding context, the reflector MUST NOT represent the response as having received slice-specific treatment that it did not apply. In that case the reflector SHOULD either be configured to reflect the response on best-effort resources with the received slice indicator preserved, or be configured to discard the query; the choice SHOULD be controllable by the operator. A reflector that discards such a query MAY log the event, subject to rate limiting.¶
On receiving a reflected response, the Session-Sender MUST associate the resulting measurement with the slice identified by the slice indicator of the session. This allows per-slice delay, delay variation, and loss to be computed and reported independently for each slice under test.¶
The procedures in this document apply to TWAMP Light (Appendix I of [RFC5357]), to the full TWAMP architecture of [RFC5357], and to STAMP [RFC8762] and its optional extensions [RFC8972]. They apply for any slice indicator encoding, provided that the slice indicator is preserved on the path between the Session-Sender and the Session-Reflector and is acted upon by the intermediate nodes that implement the slice.¶
[I-D.ietf-spring-stamp-srpm-srv6] specifies how STAMP probe packets are constructed and processed for SR paths in the SRv6 data plane, including the use of SR Policies. That document determines the path that a probe follows. This document is concerned with a different and orthogonal property: the slice indicator that selects the slice-specific resources along whatever path is used. The two mechanisms are intended to be used together. A probe constructed according to [I-D.ietf-spring-stamp-srpm-srv6] can carry a slice indicator as specified here.¶
[I-D.weng-ippm-srpm-path-consistency-over-srv6] describes the use of TWAMP and STAMP to verify path consistency over SRv6 by binding a measurement to a specific SR Policy segment list. Binding to a segment list constrains the path; carrying a slice indicator selects the resources of a slice. These are independent objectives and may coexist: a measurement may be bound both to a segment list and to a slice. This document does not modify the procedures of that work.¶
The security considerations of TWAMP [RFC5357], STAMP [RFC8762], the STAMP optional extensions [RFC8972], and SRv6 [RFC8754] apply to the procedures in this document.¶
The slice indicator is carried in the clear in the SRv6 packet and is visible to nodes on the path. Exposure of the slice indicator may reveal the existence and structure of the network slices in use. Operators SHOULD consider whether the slice structure is sensitive in their deployment when deciding where measurement is performed and who is permitted to observe it.¶
A probe that carries the slice indicator of a slice for which the sender is not authorized could be used to measure that slice. Access control at slice ingress SHOULD prevent unauthorized traffic, including probe traffic, from being associated with a slice. To prevent injection or modification of probe packets, the TWAMP authenticated mode [RFC5357] and the STAMP HMAC TLV [RFC8972] SHOULD be used.¶
This document has no IANA actions.¶
The authors thank the members of the IPPM Working Group for their review and feedback.¶