Carrying a Network Slice Indicator in TWAMP and STAMP Probe Packets for SRv6 Networks
draft-yang-ippm-twamp-srv6-slice-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Jin Yang , Yuchi Tian , Weiqiang Cheng , Junjie Wang , Guoying Zhang | ||
| Last updated | 2026-06-22 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-yang-ippm-twamp-srv6-slice-00
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,
<https://www.rfc-editor.org/info/rfc2119>.
[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,
<https://www.rfc-editor.org/info/rfc5357>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[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,
<https://www.rfc-editor.org/info/rfc8754>.
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,
<https://www.rfc-editor.org/info/rfc8762>.
[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,
<https://www.rfc-editor.org/info/rfc8986>.
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,
<https://datatracker.ietf.org/doc/html/draft-ietf-6man-
enhanced-vpn-vtn-id-05>.
[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,
<https://datatracker.ietf.org/doc/html/draft-ietf-spring-
srv6-encoding-network-sliceid-00>.
[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, <https://datatracker.ietf.org/doc/html/draft-ietf-
spring-stamp-srpm-srv6-00>.
[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, <https://datatracker.ietf.org/doc/html/draft-weng-
ippm-srpm-path-consistency-over-srv6-08>.
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,
<https://www.rfc-editor.org/info/rfc8972>.
[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,
<https://www.rfc-editor.org/info/rfc9543>.
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]