Simple Two-Way Active Measurement Protocol (STAMP) Extensions for Reflecting STAMP Packet Headers
draft-ietf-ippm-stamp-ext-hdr-01
| Document | Type | Active Internet-Draft (ippm WG) | |
|---|---|---|---|
| Authors | Rakesh Gandhi , Tianran Zhou , Zhenqiang Li | ||
| Last updated | 2024-10-14 | ||
| 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-01
IPPM Working Group R. Gandhi, Ed.
Internet-Draft Cisco Systems, Inc.
Intended status: Standards Track T. Zhou
Expires: 17 April 2025 Huawei
Z. Li
China Mobile
14 October 2024
Simple Two-Way Active Measurement Protocol (STAMP) Extensions for
Reflecting STAMP Packet Headers
draft-ietf-ippm-stamp-ext-hdr-01
Abstract
The 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 IP headers, IPv6 extension headers,
and MPLS Network Action Sub-Stacks for HBH and E2E active
measurements, for example, 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 17 April 2025.
Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved.
Gandhi, et al. Expires 17 April 2025 [Page 1]
Internet-Draft STAMP for Reflecting Headers October 2024
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
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 . . . . . . . . . . . . . . . . . . . . . 5
3.2. MPLS Data Plane . . . . . . . . . . . . . . . . . . . . . 7
3.3. Fixed Header . . . . . . . . . . . . . . . . . . . . . . 9
4. Use Case of Reflecting IOAM Data Fields . . . . . . . . . . . 11
4.1. Use Case of IOAM for IPv6 Data Plane . . . . . . . . . . 11
4.2. Use Case of IOAM for MPLS Data Plane . . . . . . . . . . 12
5. STAMP Extensions . . . . . . . . . . . . . . . . . . . . . . 12
5.1. Reflected IPv6 Extension Header Data STAMP TLV . . . . . 12
5.2. Reflected MNA Sub-Stack Data STAMP TLV . . . . . . . . . 13
5.3. Reflected Fixed Header Data STAMP TLV . . . . . . . . . . 14
5.4. One-Way Measurement Using Reflected Data STAMP TLVs . . . 14
6. Security Considerations . . . . . . . . . . . . . . . . . . . 15
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
8.1. Normative References . . . . . . . . . . . . . . . . . . 16
8.2. Informative References . . . . . . . . . . . . . . . . . 16
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
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.
Gandhi, et al. Expires 17 April 2025 [Page 2]
Internet-Draft STAMP for Reflecting Headers October 2024
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.
IPv6 packets may carry IPv6 extension headers containing IPv6 options
headers for Hop-By-Hop (HBH) and Destination Types as defined in
[RFC8200]. [RFC9486] defines option types for HBH and destination
options headers to carry IOAM data fields [RFC9197] for the IPv6 data
plane.
MPLS packets may carry MPLS Network Action (MNA) Sub-Stacks as
defined in [I-D.ietf-mpls-mna-hdr] based on the MNA 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 IP
headers, 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
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
Gandhi, et al. Expires 17 April 2025 [Page 3]
Internet-Draft STAMP for Reflecting Headers October 2024
MTU: Maximum Transmission Unit
STAMP: Simple Two-way Active Measurement Protocol
TLV: Type-Length-Value
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.
T1 is a transmit timestamp, and T4 is a receive timestamp added by
node S1. 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 the 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. The 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 agnostic to the STAMP test packets in
the payload.
Gandhi, et al. Expires 17 April 2025 [Page 4]
Internet-Draft STAMP for Reflecting Headers October 2024
3.1. IPv6 Data Plane
This document defines a new TLV option for STAMP, called "Reflected
IPv6 Extension Header Data" (value TBA1). When a STAMP Session-
Sender adds an IPv6 extension header such as an IPv6 Hop-By-Hop
options header or a Destination options header in the IPv6 header
[RFC8200], it also adds a "Reflected IPv6 Extension Header Data"
STAMP TLV in the Session-Sender test packet with the length set to
the IPv6 extension header (including IPv6 extension header bytes and
value field) length and the value field in the TLV initialized to
zeros, in order to receive a copy of that IPv6 extension header back
in the STAMP TLV. When adding multiple IPv6 extension headers in the
Session-Sender test packet, multiple corresponding "Reflected IPv6
Extension Header Data" TLVs are added, each one with the matching
length to the IPv6 extension header and in the same order.
An example STAMP test packet for the IPv6 data plane carrying the
IPv6 header and IPv6 extension headers and reflected IPv6 header data
in STAMP TLVs is shown in Figure 2.
Examples of IPv6 extension headers are: 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 IPv6
options header defined in [RFC9343], Routing Header for IPv6
including Segment Routing Header defined in [RFC8754], and any new
IPv6 extension header that is defined in the 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.
Gandhi, et al. Expires 17 April 2025 [Page 5]
Internet-Draft STAMP for Reflecting Headers October 2024
+--------------------------------------------------------+
| IPv6 Header |
+--------------------------------------------------------+
| IPv6 Extension Header-1 RFC 8200 |
+--------------------------------------------------------+
~ ... ~
+--------------------------------------------------------+
| IPv6 Extension Header-N RFC 8200 |
+--------------------------------------------------------+
| UDP Header |
+--------------------------------------------------------+
| STAMP Packet RFC 8972 |
+--------------------------------------------------------+
| Reflected IPv6 Extension Header-1 Data STAMP TLV (TBA1)|
+--------------------------------------------------------+
~ ... ~
+--------------------------------------------------------+
| Reflected IPv6 Extension Header-M Data STAMP TLV (TBA1)|
+--------------------------------------------------------+
Figure 2: Example STAMP Test Packet with Reflected IPv6 Extension
Header Data STAMP TLV
When the Session-Reflector receives a STAMP test packet with an IPv6
extension header and a STAMP TLV of "Reflected IPv6 Extension 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 Extension Header Data" TLV in the
Session-Reflector payload. When there are multiple IPv6 extension
headers in the received Session-Sender test packet, all IPv6
extension headers MUST be copied into the STAMP "Reflected IPv6
Extension Header Data" TLVs in the reply Session-Reflector test
packet in the same order.
The Session-Reflector adds the matching IPv6 option in the IPv6
header of the Session-Reflector test packets for the reverse
direction.
When the Session-Reflector receives a STAMP test packet with an IPv6
extension header but without a "Reflected IPv6 Extension Header Data"
STAMP TLV, the Session-Reflector does not copy the IPv6 extension
header into the reply Session-Reflector test packet.
When the Session-Sender test packets carry an IPv6 extension header
with an option-type that it does not require the Session-Reflector to
reflect in the Session-Reflector test packet, it does not add the
matching "Reflected IPv6 Extension Header Data" TLV in the Session-
Sender test packet.
Gandhi, et al. Expires 17 April 2025 [Page 6]
Internet-Draft STAMP for Reflecting Headers October 2024
If the Session-Reflector receives Session-Sender test packets with
non-zero values in the first 4 bytes in the "Reflected IPv6 Extension
Header Data" STAMP TLV, it MUST match the values in the corresponding
IPv6 extension header before copying data into the STAMP TLV. This
mechanism is employed in case of ambiguity when there are multiple
IPv6 extension headers with the same length and not all need to be
copied and reflected in the STAMP TLV.
The Session-Sender and Session-Reflector test packets are symmetric
in size, and hence the Session-Sender and Session-Reflector MUST
ensure that the resulting test packets do not exceed the IPv6 MTU
after adding the Reflected Data STAMP TLVs. If necessary, Reflected
Data STAMP TLVs can be removed to avoid violating the IPv6 MTU limit.
If, for any reason, the Session-Reflector does not use the received
Reflected IPv6 Extension Header Data STAMP TLV for reflecting data,
it MUST return the STAMP TLV as malformed, i.e., with the M flag set
in the STAMP TLV Flags using the procedure defined in [RFC8972].
Note that the use case where the IPv6 extension header length changes
in the Session-Sender test packets along the path is outside the
scope of this document. Also, 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 a
"Reflected MNA Sub-Stack Data" STAMP TLV in the Session-Sender test
packet with the length set to 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, in order to receive a copy of that MNA Sub-
Stack back in the STAMP TLV. 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 the matching length to the
MNA Sub-Stack and Ancillary Data and in the same order.
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.
Gandhi, et al. Expires 17 April 2025 [Page 7]
Internet-Draft STAMP for Reflecting Headers October 2024
An example STAMP test packet for the MPLS data plane carrying MNA
Sub-Stacks in the MPLS header and reflected MNA Sub-Stack data in
STAMP TLVs is shown in Figure 3.
+------------------------------------------------+
| MPLS Header |
+------------------------------------------------+
| MNA Sub-Stack-1 I-D.ietf-mpls-mna-hdr |
+------------------------------------------------+
~ ... ~
+------------------------------------------------+
| MNA Sub-Stack-N I-D.ietf-mpls-mna-hdr |
+------------------------------------------------+
| IP Header |
+------------------------------------------------+
| UDP Header |
+------------------------------------------------+
| STAMP Packet RFC 8972 |
+------------------------------------------------+
| Reflected MNA Sub-Stack-1 Data STAMP TLV (TBA2)|
+------------------------------------------------+
~ ... ~
+------------------------------------------------+
| Reflected MNA Sub-Stack-M Data STAMP TLV (TBA2)|
+------------------------------------------------+
Figure 3: Example STAMP Test Packet with Reflected MNA Sub-Stack
Data STAMP TLV
When the Session-Reflector receives a STAMP test packet with an MNA
and a STAMP TLV of "Reflected MNA Sub-Stack Data," the Session-
Reflector that supports this STAMP TLV MUST copy the entire MNA Sub-
Stack, including the Ancillary Data and header, into the "Reflected
MNA Sub-Stack Data" TLV in the 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 in the same order.
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.
When the Session-Reflector receives a STAMP test packet with an MNA
Sub-Stack but without a "Reflected MNA Sub-Stack Data" STAMP TLV, the
Session-Reflector does not copy the MNA Sub-Stack into the Session-
Reflector test packet.
Gandhi, et al. Expires 17 April 2025 [Page 8]
Internet-Draft STAMP for Reflecting Headers October 2024
When the Session-Sender test packets carry an MNA Sub-Stack that it
does not require the 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.
If the Session-Reflector receives Session-Sender test packets with
non-zero values in the first 8 bytes (excluding the Ancillary Data
field that may change) in the "Reflected MNA Sub-Stack Data" STAMP
TLV, it MUST match the values in the corresponding MNA Sub-Stack in
the MPLS header before copying data into the STAMP TLV. This
mechanism is employed in case of ambiguity when there are multiple
MNA Sub-Stacks in the MPLS header with the same length and not all
need to be copied and reflected in the STAMP TLV.
If, for any reason, the Session-Reflector does not use the received
Reflected MNA Sub-Stack Data STAMP TLV for reflecting data, it MUST
return the STAMP TLV as malformed, i.e., with the M flag set in the
STAMP TLV Flags using the procedure defined in [RFC8972].
Note that the use case where the MNA Sub-Stack length changes in the
Session-Sender test packets along the path is outside the scope of
this document. Also, 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.
3.3. Fixed Header
This document defines a new TLV option for STAMP, called "Reflected
Fixed Header Data" (value TBA3). The STAMP TLV can be used to
reflect any fixed size header received in the Session-Sender test
packet, including IPv4 and IPv6 headers. When a STAMP Session-Sender
adds an IP header, it also adds a "Reflected Fixed Header Data" STAMP
TLV in the Session-Sender test packet with the length set to the IP
header length and the value field in the TLV initialized to zeros, in
order to receive a copy of that IP header back in the STAMP TLV.
When adding multiple IP headers in the Session-Sender test packet,
multiple corresponding "Reflected Fixed Header Data" TLVs are added,
each one with the matching length to the IP header and in the same
order.
An example STAMP test packet carrying the IP header and reflected IP
header in STAMP TLVs is shown in Figure 4.
Gandhi, et al. Expires 17 April 2025 [Page 9]
Internet-Draft STAMP for Reflecting Headers October 2024
+----------------------------------------------+
| IP Header |
+----------------------------------------------+
| UDP Header |
+----------------------------------------------+
| STAMP Packet RFC 8972 |
+----------------------------------------------+
| Reflected Fixed Header Data STAMP TLV(TBA3) |
+----------------------------------------------+
Figure 4: Example STAMP Test Packet with Reflected Fixed Header
Data STAMP TLV
When the Session-Reflector receives a STAMP test packet with a STAMP
TLV of "Reflected Fixed Header Data," the Session-Reflector that
supports this STAMP TLV MUST copy the IP header into the "Reflected
Fixed Header Data" TLV in the Session-Reflector payload. When there
are multiple IP headers in the received Session-Sender test packet,
all IP headers MUST be copied into the "Reflected Fixed Header Data"
TLVs in the reply Session-Reflector test packet in the same order.
When the Session-Reflector receives a STAMP test packet with an IP
header but without a "Reflected Fixed Header Data" STAMP TLV, the
Session-Reflector does not copy the IP header into the reply Session-
Reflector test packet.
When the Session-Sender test packets carry an IP header that it does
not require the Session-Reflector to reflect in the Session-Reflector
test packet, it does not add the matching "Reflected Fixed Header
Data" TLV in the Session-Sender test packet.
If the Session-Reflector receives Session-Sender test packets with
non-zero values in the first 4 bytes in the "Reflected Fixed Header
Data" STAMP TLV, it MUST match the values in the corresponding IP
header before copying data into the STAMP TLV. This mechanism is
employed in case of ambiguity when there are multiple IP headers with
the same length and not all need to be copied and reflected in the
STAMP TLV.
The Session-Sender and Session-Reflector test packets are symmetric
in size, and hence the Session-Sender and Session-Reflector MUST
ensure that the resulting test packets do not exceed the IP MTU after
adding the Reflected Data STAMP TLVs. If necessary, Reflected Data
STAMP TLVs can be removed to avoid violating the IP MTU limit.
Gandhi, et al. Expires 17 April 2025 [Page 10]
Internet-Draft STAMP for Reflecting Headers October 2024
If, for any reason, the Session-Reflector does not use the received
"Reflected Fixed Header Data" STAMP TLV for reflecting data, it MUST
return the STAMP TLV as malformed, i.e., with the M flag set in the
STAMP TLV Flags using the procedure defined in [RFC8972].
4. 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 include per-hop information, such as
node ID, timestamp, queue depth, interface ID, interface load, etc.
The information collected can be used for monitoring ECMP paths,
proof-of-transit, 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. Use Case of IOAM for IPv6 Data Plane
[RFC9486] defines types for HBH and destination options headers and
is used to carry the IOAM option types defined in [RFC9197] for the
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 5. The
Session-Sender, midpoints, and Session-Reflector nodes process the
IOAM data fields as defined in [RFC9486]. Note that using the IOAM
option type "Incremental Trace Option-Type" is not supported by
[RFC9486].
+------------------------------------------------------+
| IPv6 Header |
+------------------------------------------------------+
| HBH IOAM IPv6 Options Header RFC 9486 |
+------------------------------------------------------+
| UDP Header |
+------------------------------------------------------+
| STAMP Packet RFC 8972 |
+------------------------------------------------------+
| Reflected IPv6 Extension Header Data STAMP TLV (TBA1)|
+------------------------------------------------------+
Figure 5: Example STAMP Test Packet with Reflected IPv6 Extension
Header Data TLV
Gandhi, et al. Expires 17 April 2025 [Page 11]
Internet-Draft STAMP for Reflecting Headers October 2024
4.2. Use Case of IOAM for MPLS Data Plane
[I-D.ietf-mpls-mna-hdr] defines the MNA Sub-Stack to carry various
Network Actions with Ancillary data. [I-D.gandhi-mpls-mna-ioam-dex]
defines extensions using MNA to carry various IOAM data fields as
Post-Stack Data (PSD) for the 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 6.
+-------------------------------------------------+
| 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 6: Example STAMP Test Packet with Reflected MNA Sub-Stack
Data TLV
5. STAMP Extensions
5.1. Reflected IPv6 Extension Header Data STAMP TLV
The "Reflected IPv6 Extension 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 Extension Header Data STAMP TLV Type is used for reflecting
various IPv6 extension headers, including HBH and Destination IPv6
options headers. The format of the Reflected IPv6 Extension Header
Data TLV is shown in Figure 7.
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 Extension Header Data |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Gandhi, et al. Expires 17 April 2025 [Page 12]
Internet-Draft STAMP for Reflecting Headers October 2024
Figure 7: Reflected IPv6 Extension Header Data STAMP 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 the 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 8.
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 8: Reflected MNA Sub-Stack Data STAMP 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 the 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 the MNA Sub-Stacks in the MPLS header.
Gandhi, et al. Expires 17 April 2025 [Page 13]
Internet-Draft STAMP for Reflecting Headers October 2024
5.3. Reflected Fixed Header Data STAMP TLV
The "Reflected Fixed 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 format of the "Reflected Fixed
Header Data" TLV is shown in Figure 9.
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=TBA3 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reflected Fixed Header Data |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Reflected Fixed Header Data STAMP TLV
The TLV fields are defined as follows:
Type: Type (value TBA3)
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.
For an IPv4 header, the length is set to 20, and for an IPv6 header,
the length is set to 60.
The Session-Reflector MUST return an error in the STAMP TLV Flags
when it determines that the length of the TLV does not match the
length of the corresponding IP header when processing in the same
order.
5.4. One-Way Measurement Using Reflected Data STAMP TLVs
In the case of one-way HBH and E2E measurements, the Session-
Reflector does not need to add IPv6 extension headers and MNA Sub-
Stacks in the reply Session-Reflector test packets matching the
received IPv6 extension headers and MNA Sub-Stacks, respectively.
In this document, the Sub-TLV "Extension Header Control" (Type TBA4)
is defined for the STAMP TLV Type "Reflected Test Packet Control TLV"
(Type TBA-ASYM) introduced in [I-D.ietf-ippm-asymmetrical-pkts].
Gandhi, et al. Expires 17 April 2025 [Page 14]
Internet-Draft STAMP for Reflecting Headers October 2024
When a Session-Sender test packet is received with the "Extension
Header Control" Sub-TLV, the 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.
In the absence of this Sub-TLV in the received Session-Sender test
packet, the Session-Reflector inserts new IPv6 extension headers
matching all received IPv6 extension headers (except the routing
extension headers specific to the Session-Sender test packets) in the
IPv6 header of the reply Session-Reflector test packet. Similarly,
the Session-Reflector inserts new MNA Sub-Stacks matching all
received MNA Sub-Stacks in the MPLS header of the reply Session-
Reflector test packet.
The IP headers, IPv6 extension headers, and MNA Sub-Stacks received
in the Session-Sender test packets are still reflected in STAMP TLVs
to the Session-Sender.
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 Extension
Header Data" TLV Type, a value for the "Reflected MNA Sub-Stack Data"
TLV Type, and "Reflected Fixed Header Data" TLV Type from the IETF
Review TLV range of the same registry.
+=======+======================================+===============+
| Value | Description | Reference |
+=======+======================================+===============+
| TBA1 | Reflected IPv6 Extension Header Data | This document |
+-------+--------------------------------------+---------------+
| TBA2 | Reflected MNA Sub-Stack Data | This document |
+-------+--------------------------------------+---------------+
| TBA3 | Reflected Fixed Header Data | This document |
+-------+--------------------------------------+---------------+
Table 1: STAMP TLV Types
Gandhi, et al. Expires 17 April 2025 [Page 15]
Internet-Draft STAMP for Reflecting Headers October 2024
IANA is requested to allocate a value for the Sub-TLV Type "Extension
Header Control" (Type TBA4) for the STAMP TLV Type "Reflected Test
Packet Control TLV" (Type TBA-ASYM) defined in
[I-D.ietf-ippm-asymmetrical-pkts].
+=======+==========================+===============+
| Value | Description | Reference |
+=======+==========================+===============+
| TBA4 | Extension Header Control | This document |
+-------+--------------------------+---------------+
Table 2: Sub-TLV Type for Reflected Test Packet
Control STAMP TLV
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>.
[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
Gandhi, et al. Expires 17 April 2025 [Page 16]
Internet-Draft STAMP for Reflecting Headers October 2024
[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>.
[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-
08, 30 August 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-mpls-
mna-hdr-08>.
[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-10, 6 August 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-mpls-
mna-fwk-10>.
Gandhi, et al. Expires 17 April 2025 [Page 17]
Internet-Draft STAMP for Reflecting Headers October 2024
[I-D.gandhi-mpls-mna-ioam-dex]
Gandhi, R., Brockners, F., Wen, B., Decraene, B., and H.
Song, "MPLS Network Actions for Transporting In Situ
Operations, Administration, and Maintenance (IOAM) Data
Fields and Direct Exporting", Work in Progress, Internet-
Draft, draft-gandhi-mpls-mna-ioam-dex-01, 26 June 2024,
<https://datatracker.ietf.org/doc/html/draft-gandhi-mpls-
mna-ioam-dex-01>.
Acknowledgments
The authors would like to thank Greg Mirsky, Xiao Min, Tal Mizrahi,
Cheng Li, Giuseppe Fioccola, 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
Tianran Zhou
Huawei
China
Email: zhoutianran@huawei.com
Zhenqiang Li
China Mobile
China
Email: li_zhenqiang@hotmail.com
Gandhi, et al. Expires 17 April 2025 [Page 18]