Simple Two-Way Active Measurement Protocol (STAMP) Extensions for Reflecting STAMP Packet Extension Headers
draft-ietf-ippm-stamp-ext-hdr-00
| Document | Type | Active Internet-Draft (ippm WG) | |
|---|---|---|---|
| Authors | Rakesh Gandhi , Tianran Zhou | ||
| Last updated | 2024-05-30 | ||
| Replaces | draft-gandhi-ippm-stamp-ext-hdr | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | WG Document | |
| Document shepherd | (None) | ||
| IESG | IESG state | I-D Exists | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ietf-ippm-stamp-ext-hdr-00
IPPM Working Group R. Gandhi, Ed.
Internet-Draft Cisco Systems, Inc.
Intended status: Standards Track T. Zhou
Expires: 1 December 2024 Huawei
30 May 2024
Simple Two-Way Active Measurement Protocol (STAMP) Extensions for
Reflecting STAMP Packet Extension Headers
draft-ietf-ippm-stamp-ext-hdr-00
Abstract
Simple Two-Way Active Measurement Protocol (STAMP) and its optional
extensions can be used for Edge-To-Edge (E2E) active measurement. In
Situ Operations, Administration, and Maintenance (IOAM) data fields
can be used for recording and collecting Hop-By-Hop (HBH) and E2E
operational and telemetry information. This document extends STAMP
to reflect IPv6 extension headers and MPLS Network Action Sub-Stacks,
for example, for hop-by-hop and edge-to-edge active measurements,
including using IOAM data fields.
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 1 December 2024.
Copyright Notice
Copyright (c) 2024 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
Gandhi & Zhou Expires 1 December 2024 [Page 1]
Internet-Draft STAMP for Reflecting Headers May 2024
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. Conventions Used in This Document . . . . . . . . . . . . . . 3
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3
2.3. STAMP Reference Topology . . . . . . . . . . . . . . . . 4
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. IPv6 Data plane . . . . . . . . . . . . . . . . . . . . . 4
3.2. MPLS Data plane . . . . . . . . . . . . . . . . . . . . . 6
4. Example Use-Case of Reflecting IOAM Data Fields . . . . . . . 8
4.1. Example Use-Case of IOM for IPv6 Data plane . . . . . . . 8
4.2. Example Use-Case of IOM for MPLS Data plane . . . . . . . 9
5. STAMP Extensions . . . . . . . . . . . . . . . . . . . . . . 9
5.1. Reflected IPv6 Header Data STAMP TLV . . . . . . . . . . 10
5.2. Reflected MNA Sub-Stack Data STAMP TLV . . . . . . . . . 10
5.3. One-Way Measurement with Reflected Data STAMP TLV . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . 12
8.2. Informative References . . . . . . . . . . . . . . . . . 13
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction
The Simple Two-Way Active Measurement Protocol (STAMP) provides
capabilities for the measurement of various performance metrics in IP
networks [RFC8762] without the use of a control channel to pre-signal
session parameters. [RFC8972] defines optional extensions, in the
form of TLVs for STAMP. The STAMP test packets are transmitted along
a path between a Session-Sender and a Session-Reflector to measure
Edge-To-Edge (E2E) performance delay and packet loss along that path.
In Situ Operations, Administration, and Maintenance (IOAM) is used
for recording and collecting operational and telemetry information
while the packet traverses a path between two points in the network.
The IOAM data fields are defined in [RFC9197]. Currently, there is
no adopted method defined to reflect the collected IOAM data fields
back to the Sender where the Sender can use that information to
support the hop-by-hop and edge-to-edge measurement use-cases.
Gandhi & Zhou Expires 1 December 2024 [Page 2]
Internet-Draft STAMP for Reflecting Headers May 2024
IPv6 packets can carry IPv6 extension headers such as IPv6 options
headers of Hop-By-Hop (HBH) and Destination Types as defined in
[RFC8200]. [RFC9486] defines types for HBH and destination options
headers to carry IOAM data fields [RFC9197] for IPv6 data plane.
MPLS packets can carry MPLS Network Action (MNA) Sub-Stack as defined
in [I-D.ietf-mpls-mna-hdr] using the framework defined in
[I-D.ietf-mpls-mna-fwk].
It may be desired to record and collect HBH and E2E operational and
telemetry information using active measurement packets between two
nodes in a network. This is achieved by augmenting STAMP [RFC8762]
by using optional STAMP extensions defined in [RFC8972] to reflect
IPv6 extension headers and MNA Sub-Stacks as specified in this
document. The procedure defined in this document leverages the
existing implementations on the midpoint nodes with IPv6 and MPLS
data planes without any additional requirements.
2. Conventions Used in This Document
2.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.2. Abbreviations
AMM: Alternate Marking Method
ECMP: Equal Cost Multi-Path
E2E: Edge-To-Edge
HBH: Hop-By-Hop
IOAM: In Situ Operations, Administration, and Maintenance
MNA: Multiprotocol Label Switching Network Action
OAM: Operations, Administration, and Maintenance
STAMP: Simple Two-way Active Measurement Protocol
Gandhi & Zhou Expires 1 December 2024 [Page 3]
Internet-Draft STAMP for Reflecting Headers May 2024
2.3. STAMP Reference Topology
In the "STAMP Reference Topology" shown in Figure 1, the STAMP
Session-Sender S1 initiates a Session-Sender test packet and the
STAMP Session-Reflector R1 transmits a reply Session-Reflector test
packet. Node M1 is a midpoint node that does not perform any STAMP
processing.
The T1 is a transmit timestamp, and T4 is a receive timestamp added
by node S1. The T2 is a receive timestamp, and T3 is a transmit
timestamp added by node R1.
T1 T2
/ \
+-------+ Test Packet +-------+ +-------+
| | - - - - - - - - | | - - - - - - - - ->| |
| S1 |=================| M1 |===================| R1 |
| |<- - - - - - - - | | - - - - - - - - - | |
+-------+ +-------+ Reply Test Packet +-------+
\ /
T4 T3
STAMP Session-Sender STAMP Session-Reflector
Figure 1: STAMP Reference Topology
3. Overview
[RFC8972] defines optional extensions for STAMP. The optional
extensions are added in base STAMP test packet defined in [RFC8762]
in the form of TLVs. As specified in [RFC8972], both Session-Sender
and Session-Reflector test packets are symmetric in size when
including all optional TLVs. Session-Reflector reflects all received
STAMP TLVs from the Session-Sender test packets.
As specified in [RFC8762], STAMP test packets are transmitted with
IP/UDP headers. As midpoint nodes do not process the UDP headers in
the packets, midpoint nodes are agnostics to the STAMP test packets
in the payload.
3.1. IPv6 Data plane
This document defines a new TLV option for STAMP, called "Reflected
IPv6 Header Data" (value TBA1). When a STAMP Session-Sender adds an
IPv6 extension header such as IPv6 Hop-By-Hop options header or a
Destination options header in IPv6 header [RFC8200], it also adds
"Reflected IPv6 Header Data" STAMP TLV in the Session-Sender test
packet with length of the IPv6 extension header (including IPv6
Gandhi & Zhou Expires 1 December 2024 [Page 4]
Internet-Draft STAMP for Reflecting Headers May 2024
extension header bytes and value field) in the TLV initialized to
zeros, in order to receive the IPv6 extension header back. When
adding multiple IPv6 extension headers in the Session-Sender test
packet, multiple corresponding "Reflected IPv6 Header Data" TLVs are
added, each one with matching length with the IPv6 extension header
and in the same order.
An example STAMP test packet for IPv6 data plane carrying IPv6
extension headers in IPv6 header and reflected IPv6 header data in
STAMP TLVs is shown in Figure 2.
Examples of IPv6 extension header can be: IOAM data fields IPv6
options header defined in [RFC9486], Performance and Diagnostic
Metrics (PDM) IPv6 options header defined in [RFC8250], Maximum Path
MTU IPv6 options header defined in [RFC9268], Alternate Marking
Method (AMM) IPv6 options header defined in [RFC9343], Segment
Routing Header defined in [RFC8754], and any new IPv6 extension
header defined in future.
As the procedure defined in this document leverages the existing
implementations on the midpoint nodes for the IPv6 extension headers,
no additional requirements are specified when carrying these IPv6
extension headers in STAMP. The IPv6 extension header is processed
by the nodes using the same procedures specified in the document that
defined the IPv6 extension header.
+----------------------------------------------+
| IPv6 Header |
+----------------------------------------------+
| IPv6 Extension Header1 RFC 8200 |
+----------------------------------------------+
~ ... ~
+----------------------------------------------+
| IPv6 Extension HeaderN RFC 8200 |
+----------------------------------------------+
| UDP Header |
+----------------------------------------------+
| STAMP Packet RFC 8972 |
+----------------------------------------------+
| Reflected IPv6 Header1 Data STAMP TLV (TBA1) |
+----------------------------------------------+
~ ... ~
+----------------------------------------------+
| Reflected IPv6 HeaderN Data STAMP TLV (TBA1) |
+----------------------------------------------+
Figure 2: Example STAMP Test Packet with Reflected IPv6 Header Data
Gandhi & Zhou Expires 1 December 2024 [Page 5]
Internet-Draft STAMP for Reflecting Headers May 2024
When Session-Reflector receives STAMP test packet with IPv6 extension
header and STAMP TLV of "Reflected IPv6 Header Data", the Session-
Reflector that supports this STAMP TLV, MUST copy the entire IPv6
extension header including the option type header into the STAMP
"Reflected IPv6 Header Data" TLV in Session-Reflector payload. When
there are multiple IPv6 extension headers in the received Session-
Sender test packet, all IPv6 extension headers MUST be copied in the
STAMP "Reflected IPv6 Header Data" TLVs in the reply Session-
Reflector test packet in the same order.
For two-way measurement, the Session-Reflector adds the matching IPv6
option in the IPv6 header of the Session-Reflector test packets for
the reverse direction.
When Session-Reflector receives STAMP test packet with IPv6 extension
header but without "Reflected IPv6 Header Data" STAMP TLV, the
Session-Reflector does not copy the IPv6 extension header into the
reply Session-Reflector test packet.
When Session-Sender test packets carry an IPv6 extension header with
option-type that it does not require Session-Reflector to reflect in
the Session-Reflector test packet, it does not add the matching
"Reflected IPv6 option Data" TLV in the Session-Sender test packet.
Note that the use-case where IPv6 extension header length changes in
the Session-Sender test packets along the path is outside the scope
of this document.
Note that the use-case where IPv6 extension headers are added or
removed in the Session-Sender test packets along the path is outside
the scope of this document.
3.2. MPLS Data plane
This document also defines a new TLV option for STAMP, called
"Reflected MNA Sub-Stack Data" (value TBA2). When a STAMP Session-
Sender adds an MNA Sub-Stack in the test packet, it also adds
"Reflected MNA Sub-Stack Data" STAMP TLV in the Session-Sender test
packet with length of the MNA Sub-Stack length (NASL) (including In-
Stack Ancillary Data (ISD) and Post-Stack Ancillary Data (PSD) and
MNA label LSE) and the value field in the TLV initialized to zeros.
When adding multiple MNA Sub-Stacks in the Session-Sender test
packet, multiple "Reflected MNA Sub-Stack Data" TLVs MUST be added,
each one with matching length with the MNA Sub-Stack and Ancillary
Data and in the same order.
Gandhi & Zhou Expires 1 December 2024 [Page 6]
Internet-Draft STAMP for Reflecting Headers May 2024
As the procedure defined in this document leverages the existing
implementations on the midpoint nodes for the MNA Sub-Stacks, no
additional requirements are specified when carrying MNA Sub-Stacks in
STAMP. The MNA Sub-Stack is processed by the nodes using the same
procedures specified in the document that defined the MNA Sub-Stack.
An example STAMP test packet for MPLS data plane carrying MNA Sub-
Stacks in MPLS header and reflected MNA Sub-Stacks data in STAMP TLVs
is shown in Figure 3.
+------------------------------------------------+
| MPLS Header |
+------------------------------------------------+
| MNA Sub-Stack1 I-D.ietf-mpls-mna-hdr |
+------------------------------------------------+
~ ... ~
+------------------------------------------------+
| MNA Sub-StackN I-D.ietf-mpls-mna-hdr |
+------------------------------------------------+
| IP Header |
+------------------------------------------------+
| UDP Header |
+------------------------------------------------+
| STAMP Packet RFC 8972 |
+------------------------------------------------+
| Reflected MNA Sub-Stack1 Data STAMP TLV (TBA2) |
+------------------------------------------------+
~ ... ~
+------------------------------------------------+
| Reflected MNA Sub-StackN Data STAMP TLV (TBA2) |
+------------------------------------------------+
Figure 3: Example STAMP Test Packet with Reflected MNA Sub-Stack Data
When Session-Reflector receives STAMP test packet with MNA and STAMP
TLV of "Reflected MNA Sub-Stack Data", the Session-Reflector that
supports this STAMP TLV, MUST copy the entire MNA Sub-Stack,
Ancillary Data including the header into the "Reflected MNA Sub-Stack
Data" TLV in Session-Reflector payload. When there are multiple MNA
Sub-Stacks in the Session-Sender test packet, all MNA Sub-Stacks
including Ancillary Data MUST be copied in the STAMP TLVs and MUST
add all MNA Sub-Stacks including Ancillary Data in the Session-
Reflector test packet and in the same order.
For two-way measurement, the Session-Reflector adds the matching MNA
Sub-Stacks and Ancillary Data in the MPLS header of the Session-
Reflector test packet for the reverse direction.
Gandhi & Zhou Expires 1 December 2024 [Page 7]
Internet-Draft STAMP for Reflecting Headers May 2024
When Session-Reflector receives STAMP test packet with MNA Sub-Stack
but without "Reflected MNA Sub-Stack Data" STAMP TLV, the Session-
Reflector does not copy the MNA Sub-Stack into the Session-Reflector
test packet.
When Session-Sender test packets carry an MNA Sub-Stack that it does
not require Session-Reflector to reflect in the Session-Reflector
test packet, it does not add the matching Reflected MNA Sub-Stack
Data TLV in the Session-Sender test packet.
Note that the use-case where MNA Sub-Stack length changes in the
Session-Sender test packets along the path is outside the scope of
this document.
Note that the use-case where MNA Sub-Stacks are added or removed in
the Session-Sender test packets along the path is outside the scope
of this document.
4. Example Use-Case of Reflecting IOAM Data Fields
In Situ Operations, Administration, and Maintenance (IOAM) is used
for recording and collecting operational and telemetry information
while the packet traverses a path between two points in the network.
The IOAM data fields are defined in [RFC9197]. Examples of data
recorded by IOAM Trace Options includes per-hop information, e.g.,
node ID, timestamp, queue depth, interface ID, interface load, etc.
The information collected can be used, for example, monitoring ECMP
paths, proof-of-transit (POT) and troubleshooting failures in the
network. The procedure and STAMP extensions defined in this document
can be used to reflect the collected IOAM data fields back to the
Sender where the Sender can use that information to support the hop-
by-hop and edge-to-edge measurement use-cases.
4.1. Example Use-Case of IOM for IPv6 Data plane
[RFC9486] defines types for HBH and destination options headers and
are used to carry the IOAM option-types defined in [RFC9197] for IPv6
data plane. The STAMP Session-Sender and Session-Reflector test
packets carry the IPv6 options headers with IOAM option-types for
recording and collecting HBH and E2E operational and telemetry
information for active measurement as shown in Figure 4. The
Session-Sender, midpoints, and Session-Reflector nodes process the
IOAM data fields as defined in [RFC9486]. Note that using IOAM
option-type "Incremental Trace Option-Type" is not supported by
[RFC9486].
Gandhi & Zhou Expires 1 December 2024 [Page 8]
Internet-Draft STAMP for Reflecting Headers May 2024
+-----------------------------------------------+
| IPv6 Header |
+-----------------------------------------------+
| HBH IOAM IPv6 Options Header RFC 9486 |
+-----------------------------------------------+
| UDP Header |
+-----------------------------------------------+
| STAMP Packet RFC 8972 |
+-----------------------------------------------+
| Reflected IPv6 Header Data STAMP TLV (TBA1) |
+-----------------------------------------------+
Figure 4: Example STAMP Test Packet with Reflected IPv6 Header
Data TLV
4.2. Example Use-Case of IOM for MPLS Data plane
[I-D.ietf-mpls-mna-hdr] defines MNA Sub-Stack to carry various
Network Actions with Ancillary data. [I-D.gandhi-mpls-ioam] defines
extensions using MNA to carry various IOAM data fields as Post-Stack
Data (PSD) for MPLS data plane. The STAMP Session-Sender and
Session-Reflector test packets carry the MNA Sub-Stack for recording
and collecting HBH and E2E operational and telemetry information for
active measurement as shown in Figure 5.
+-------------------------------------------------+
| MPLS Header |
+-------------------------------------------------+
| HBH IOAM MNA Sub-Stack RFC 9197 |
+-------------------------------------------------+
| IP Header |
+-------------------------------------------------+
| UDP Header |
+-------------------------------------------------+
| STAMP Packet RFC 8972 |
+-------------------------------------------------+
| Reflected MNA Sub-Stack Data STAMP TLV (TBA2) |
+-------------------------------------------------+
Figure 5: Example STAMP Test Packet with Reflected MNA Sub-Stack
Data TLV
5. STAMP Extensions
Gandhi & Zhou Expires 1 December 2024 [Page 9]
Internet-Draft STAMP for Reflecting Headers May 2024
5.1. Reflected IPv6 Header Data STAMP TLV
The "Reflected IPv6 Header Data" STAMP TLV is carried by Session-
Sender and Session-Reflector test packets. STAMP test packets may
carry multiple TLVs of this type. The same Reflected IPv6 Header
Data STAMP TLV is used for reflecting IPv6 extension headers
including HBH and Destination IPv6 options headers. The format of
the Reflected IPv6 Header Data TLV is shown 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|STAMP TLV Flags| Type=TBA1 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reflected IPv6 Header Data |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Reflected IPv6 Header Data TLV
The TLV fields are defined as follows:
Type : Type (value TBA1)
STAMP TLV Flags : The STAMP TLV Flags follow the procedures described
in [RFC8972].
Length : A two-octet field equal to the length of the Data in octets.
The Session-Reflector MUST return an error in STAMP TLV Flags when it
determines that the length of the TLV does not match the length of
the corresponding IPv6 extension header in the IPv6 header.
5.2. Reflected MNA Sub-Stack Data STAMP TLV
The "Reflected MNA Sub-Stack Data" STAMP TLV is carried by Session-
Sender and Session-Reflector test packets. STAMP test packets may
carry multiple TLVs of this type. The format of the Reflected MNA
Sub-Stack Data TLV is shown in Figure 7.
Gandhi & Zhou Expires 1 December 2024 [Page 10]
Internet-Draft STAMP for Reflecting Headers May 2024
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|STAMP TLV Flags| Type=TBA2 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reflected MNA Sub-Stack Data |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Reflected MNA Sub-Stack Data TLV
The TLV fields are defined as follows:
Type : Type (value TBA2)
STAMP TLV Flags : The STAMP TLV Flags follow the procedures described
in [RFC8972].
Length : A two-octet field equal to the length of the Data in octets.
The Session-Reflector MUST return an error in STAMP TLV Flags when it
determines that the length of the TLV does not match the length of
the corresponding MNA Sub-Stack when processing in the same order as
MNA Sub-Stacks in the MPLS header.
5.3. One-Way Measurement with Reflected Data STAMP TLV
In case of one-way measurement, Session-Reflector does not need to
add IPv6 extension headers and MNA Sub-Stacks in the reply Session-
Reflector test packets for HBH and E2E measurements. The IPv6
extension headers and MNA Sub-Stacks received in the Session-Sender
test packets still need to be reflected to the Session-Sender.
In this document, new Sub-TLV "Extension Header Control" (Type TBA3)
is defined for the STAMP TLV Type "Reflected Test Packet Control TLV"
(Type TBA4) defined in [I-D.ietf-ippm-asymmetrical-pkts].
When Session-Sender test packet is received with "Extension Header
Control" Sub-TLV, Session-Reflector does not add the received IPv6
extension headers in the IPv6 header and MNA Sub-Stacks in the MPLS
header of the reply Session-Reflector STAMP test packet.
Gandhi & Zhou Expires 1 December 2024 [Page 11]
Internet-Draft STAMP for Reflecting Headers May 2024
Session-Reflector copies the IPv6 extension headers and MNA Sub-
Stacks from the received Session-Sender test packet into the
corresponding Reflected Data STAMP TLVs (Type TBA1 and TBA2) in the
Session-Reflector test packet. In this case, symmetric STAMP test
packet payload size is maintained in both directions, however, the
symmetric header size of the STAMP test packets is not maintained.
6. Security Considerations
The security considerations specified in [RFC8762], [RFC8972],
[RFC8200], and [I-D.ietf-mpls-mna-hdr] apply to the procedure and
extensions defined in this document. In addition, the security
considerations specified in [RFC9197] also apply when using the IPv6
options headers defined in that document.
7. IANA Considerations
IANA has created the "STAMP TLV Types" registry for [RFC8972]. IANA
is requested to allocate a value for the "Reflected IPv6 Header Data"
TLV Type and a value for the "Reflected MNA Sub-Stack Data" TLV Type
from the IETF Review TLV range of the same registry.
+=======+==============================+===============+
| Value | Description | Reference |
+=======+==============================+===============+
| TBA1 | Reflected IPv6 Header Data | This document |
+-------+------------------------------+---------------+
| TBA2 | Reflected MNA Sub-Stack Data | This document |
+-------+------------------------------+---------------+
Table 1: STAMP TLV Types
IANA is requested to allocate a value for Sub-TLV Type "Extension
Header Control" (Type TBA3) for STAMP TLV Type "Reflected Test Packet
Control TLV" (Type TBA4) defined in
[I-D.ietf-ippm-asymmetrical-pkts].
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>.
Gandhi & Zhou Expires 1 December 2024 [Page 12]
Internet-Draft STAMP for Reflecting Headers May 2024
[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>.
[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>.
[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>.
[I-D.ietf-ippm-asymmetrical-pkts]
Mirsky, G., Ruffini, E., Nydell, H., and R. F. Foote,
"Performance Measurement with Asymmetrical Packets in
STAMP", Work in Progress, Internet-Draft, draft-ietf-ippm-
asymmetrical-pkts-01, 20 May 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-ippm-
asymmetrical-pkts-01>.
8.2. Informative References
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>.
[RFC8250] Elkins, N., Hamilton, R., and M. Ackermann, "IPv6
Performance and Diagnostic Metrics (PDM) Destination
Option", RFC 8250, DOI 10.17487/RFC8250, September 2017,
<https://www.rfc-editor.org/info/rfc8250>.
[RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J.,
Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
(SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020,
<https://www.rfc-editor.org/info/rfc8754>.
[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, <https://www.rfc-editor.org/info/rfc9197>.
Gandhi & Zhou Expires 1 December 2024 [Page 13]
Internet-Draft STAMP for Reflecting Headers May 2024
[RFC9486] Bhandari, S., Ed. and F. Brockners, Ed., "IPv6 Options for
In Situ Operations, Administration, and Maintenance
(IOAM)", RFC 9486, DOI 10.17487/RFC9486, September 2023,
<https://www.rfc-editor.org/info/rfc9486>.
[RFC9268] Hinden, R. and G. Fairhurst, "IPv6 Minimum Path MTU Hop-
by-Hop Option", RFC 9268, DOI 10.17487/RFC9268, August
2022, <https://www.rfc-editor.org/info/rfc9268>.
[RFC9343] Fioccola, G., Zhou, T., Cociglio, M., Qin, F., and R.
Pang, "IPv6 Application of the Alternate-Marking Method",
RFC 9343, DOI 10.17487/RFC9343, December 2022,
<https://www.rfc-editor.org/info/rfc9343>.
[I-D.ietf-mpls-mna-hdr]
Rajamanickam, J., Gandhi, R., Zigler, R., Song, H., and K.
Kompella, "MPLS Network Action (MNA) Sub-Stack Solution",
Work in Progress, Internet-Draft, draft-ietf-mpls-mna-hdr-
05, 1 May 2024, <https://datatracker.ietf.org/doc/html/
draft-ietf-mpls-mna-hdr-05>.
[I-D.ietf-mpls-mna-fwk]
Andersson, L., Bryant, S., Bocci, M., and T. Li, "MPLS
Network Actions (MNA) Framework", Work in Progress,
Internet-Draft, draft-ietf-mpls-mna-fwk-08, 7 May 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-mpls-
mna-fwk-08>.
[I-D.gandhi-mpls-ioam]
Gandhi, R., Brockners, F., Wen, B., Decraene, B., and H.
Song, "MPLS Network Action for Transporting In Situ OAM
Data Fields", Work in Progress, Internet-Draft, draft-
gandhi-mpls-ioam-12, 17 March 2024,
<https://datatracker.ietf.org/doc/html/draft-gandhi-mpls-
ioam-12>.
Acknowledgments
The authors would like to thank Greg Mirsky, Xiao Min, Tal Mizrahi,
Cheng Li, and Jie Dong for reviewing this document and providing
useful comments and suggestions.
Authors' Addresses
Rakesh Gandhi (editor)
Cisco Systems, Inc.
Canada
Email: rgandhi@cisco.com
Gandhi & Zhou Expires 1 December 2024 [Page 14]
Internet-Draft STAMP for Reflecting Headers May 2024
Tianran Zhou
Huawei
China
Email: zhoutianran@huawei.com
Gandhi & Zhou Expires 1 December 2024 [Page 15]