IPPM J. Yang Internet-Draft Y. Tian Intended status: Standards Track W. Cheng Expires: 24 December 2026 China Mobile J. Wang G. Zhang Centec 22 June 2026 Carrying a Network Slice Indicator in TWAMP and STAMP Probe Packets for SRv6 Networks draft-yang-ippm-twamp-srv6-slice-00 Abstract 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. 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." Yang, et al. Expires 24 December 2026 [Page 1] Internet-Draft TWAMP and STAMP for SRv6 Slices June 2026 This Internet-Draft will expire on 24 December 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 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Session-Sender Behavior . . . . . . . . . . . . . . . . . 4 3.2. Session-Reflector Behavior . . . . . . . . . . . . . . . 5 3.3. Measurement Correlation . . . . . . . . . . . . . . . . . 6 4. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Relationship to Other Work . . . . . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 8.2. Informative References . . . . . . . . . . . . . . . . . 8 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction 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 Yang, et al. Expires 24 December 2026 [Page 2] Internet-Draft TWAMP and STAMP for SRv6 Slices June 2026 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. 1.1. 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. 2. Terminology 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. Yang, et al. Expires 24 December 2026 [Page 3] Internet-Draft TWAMP and STAMP for SRv6 Slices June 2026 Slice Indicator A value carried in an SRv6 packet that identifies the network slice to which the packet belongs and selects the slice-specific forwarding resources applied to the packet. The encoding and the location of the slice indicator within the packet depend on the encoding scheme deployed in the network. This document is agnostic to that encoding and treats the slice indicator as an abstract value associated with a slice. 3. Procedures 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 Figure 1: Measurement Reference Model 3.1. Session-Sender Behavior 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. Yang, et al. Expires 24 December 2026 [Page 4] Internet-Draft TWAMP and STAMP for SRv6 Slices June 2026 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. 3.2. Session-Reflector Behavior 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: * A stateful Session-Reflector that is provisioned with the forwarding context of the slice MUST originate the response over the slice-specific resources of that slice, using the same slice indicator encoding as data traffic. * A stateless Session-Reflector MUST preserve the received slice indicator when it forms the response. Where the platform builds the response by reflecting the received encapsulation, the slice indicator is preserved by that reflection. Where the platform re- originates the response, the reflector MUST reproduce the received slice indicator in the encoding used by the slice, and MUST be provisioned with the corresponding forwarding context for the return path to be slice-accurate. Yang, et al. Expires 24 December 2026 [Page 5] Internet-Draft TWAMP and STAMP for SRv6 Slices June 2026 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. 3.3. Measurement Correlation 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. 4. Applicability 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. 5. Relationship to Other Work [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. Yang, et al. Expires 24 December 2026 [Page 6] Internet-Draft TWAMP and STAMP for SRv6 Slices June 2026 6. Security Considerations 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. 7. IANA Considerations This document has no IANA actions. 8. References 8.1. 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, . [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", RFC 5357, DOI 10.17487/RFC5357, October 2008, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., Matsushima, S., and D. Voyer, Ed., "IPv6 Segment Routing Header (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, . Yang, et al. Expires 24 December 2026 [Page 7] Internet-Draft TWAMP and STAMP for SRv6 Slices June 2026 [RFC8762] Mirsky, G., Jun, G., Nydell, H., and R. Foote, "Simple Two-Way Active Measurement Protocol", RFC 8762, DOI 10.17487/RFC8762, March 2020, . [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 (SRv6) Network Programming", RFC 8986, DOI 10.17487/RFC8986, February 2021, . 8.2. Informative References [I-D.ietf-6man-enhanced-vpn-vtn-id] Dong, J., Li, Z., Xie, C., and C. Ma, "Carrying Virtual Transport Network (VTN) Information in IPv6 Extension Header", Work in Progress, Internet-Draft, draft-ietf- 6man-enhanced-vpn-vtn-id-05, 2023, . [I-D.ietf-spring-srv6-encoding-network-sliceid] Cheng, W., "Encoding Network Slice Identification for SRv6", Work in Progress, Internet-Draft, draft-ietf- spring-srv6-encoding-network-sliceid-00, 2025, . [I-D.ietf-spring-stamp-srpm-srv6] Gandhi, R., Ed., Filsfils, C., Janssens, B., Chen, M., and R. Foote, "Performance Measurement Using Simple Two-Way Active Measurement Protocol (STAMP) for Segment Routing over the IPv6 (SRv6) Data Plane", Work in Progress, Internet-Draft, draft-ietf-spring-stamp-srpm-srv6-00, 2026, . [I-D.weng-ippm-srpm-path-consistency-over-srv6] Weng, S., Cheng, W., Lin, C., Min, X., and J. Li, "SRPM Path Consistency over SRv6", Work in Progress, Internet- Draft, draft-weng-ippm-srpm-path-consistency-over-srv6-08, 2024, . Yang, et al. Expires 24 December 2026 [Page 8] Internet-Draft TWAMP and STAMP for SRv6 Slices June 2026 [RFC8972] Mirsky, G., Min, X., Nydell, H., Foote, R., Masputra, A., and E. Ruffini, "Simple Two-Way Active Measurement Protocol Optional Extensions", RFC 8972, DOI 10.17487/RFC8972, January 2021, . [RFC9543] Farrel, A., Ed., Drake, J., Ed., Rokui, R., Homma, S., Makhijani, K., Contreras, L., and J. Tantsura, "A Framework for Network Slices in Networks Built from IETF Technologies", RFC 9543, DOI 10.17487/RFC9543, March 2024, . Acknowledgements The authors thank the members of the IPPM Working Group for their review and feedback. Authors' Addresses Jin Yang China Mobile Beijing 100053 China Email: yangjinwl@chinamobile.com Yuchi Tian China Mobile Beijing 100053 China Email: tianyuchi@chinamobile.com Weiqiang Cheng China Mobile Beijing 100053 China Email: chengweiqiang@chinamobile.com Junjie Wang Centec Suzhou 215000 China Yang, et al. Expires 24 December 2026 [Page 9] Internet-Draft TWAMP and STAMP for SRv6 Slices June 2026 Email: wangjj@centec.com Guoying Zhang Centec Suzhou 215000 China Email: zhanggy@centec.com Yang, et al. Expires 24 December 2026 [Page 10]