Performance Measurement Using Simple Two-Way Active Measurement Protocol (STAMP) for Segment Routing Networks
draft-ietf-spring-stamp-srpm-16
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
|
|
|---|---|---|---|
| Authors | Rakesh Gandhi , Clarence Filsfils , Daniel Voyer , Mach Chen , Richard "Footer" Foote | ||
| Last updated | 2024-10-14 (Latest revision 2024-04-24) | ||
| Replaces | draft-gandhi-spring-stamp-srpm, draft-gandhi-spring-enhanced-srpm | ||
| Replaced by | draft-ietf-spring-stamp-srpm-mpls, draft-ietf-spring-stamp-srpm-srv6 | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| 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-spring-stamp-srpm-16
SPRING Working Group R. Gandhi, Ed.
Internet-Draft C. Filsfils
Intended status: Informational Cisco Systems, Inc.
Expires: 17 April 2025 D. Voyer
Bell Canada
M. Chen
Huawei
R. Foote
Nokia
14 October 2024
Performance Measurement Using Simple Two-Way Active Measurement Protocol
(STAMP) for Segment Routing Networks
draft-ietf-spring-stamp-srpm-16
Abstract
Segment Routing (SR) leverages the source routing paradigm and
applies to both Multiprotocol Label Switching (SR-MPLS) and IPv6
(SRv6) data planes. This document describes procedures for
Performance Measurement in SR networks using Simple Two-Way Active
Measurement Protocol (STAMP) defined in RFC 8762, along with its
optional extensions defined in RFC 8972 and further augmented in RFC
9503. The described procedure is used for links and SR paths
(including SR Policies and SR IGP Flexible Algorithm paths), as well
as Layer-3 and Layer-2 services in SR networks, and is applicable to
both SR-MPLS and SRv6 data planes.
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.
Gandhi, et al. Expires 17 April 2025 [Page 1]
Internet-Draft Using STAMP for Segment Routing October 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
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 . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions Used in This Document . . . . . . . . . . . . . . 4
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 5
2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 5
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Two-Way Measurement Mode in SR Networks . . . . . . . . . . . 7
4.1. Example STAMP Reference Model . . . . . . . . . . . . . . 8
4.2. Session-Sender Test Packet . . . . . . . . . . . . . . . 9
4.3. Session-Sender Test Packet for Links . . . . . . . . . . 10
4.4. Session-Sender Test Packet for SR-MPLS Data Plane . . . . 10
4.4.1. Session-Sender Test Packet for SR-MPLS Paths . . . . 10
4.4.2. Session-Sender Test Packet for Layer-3 Services over
SR-MPLS Path . . . . . . . . . . . . . . . . . . . . 12
4.4.3. Session-Sender Test Packet for Layer-2 Services over
SR-MPLS Path . . . . . . . . . . . . . . . . . . . . 13
4.5. Session-Sender Test Packet for SRv6 Data Plane . . . . . 13
4.5.1. Session-Sender Test Packet for SRv6 Paths . . . . . . 14
4.5.2. Session-Sender Test Packet for Layer-3 Services over
SRv6 Path . . . . . . . . . . . . . . . . . . . . . . 16
4.5.3. Session-Sender Test Packet for Layer-2 Services over
SRv6 Path . . . . . . . . . . . . . . . . . . . . . . 19
4.6. Session-Reflector Test Packet . . . . . . . . . . . . . . 21
5. One-Way Measurement Mode in SR Networks . . . . . . . . . . . 23
5.1. Example STAMP Reference Model in One-Way Measurement
Mode . . . . . . . . . . . . . . . . . . . . . . . . . . 23
6. Loopback Measurement Mode in SR Networks . . . . . . . . . . 24
6.1. Example STAMP Reference Model in Loopback Measurement
Mode . . . . . . . . . . . . . . . . . . . . . . . . . . 24
6.2. Loopback Measurement Mode for Links . . . . . . . . . . . 26
6.3. Loopback Measurement Mode for SR-MPLS Data Plane . . . . 26
6.3.1. Loopback Measurement Mode for SR-MPLS Paths . . . . . 26
Gandhi, et al. Expires 17 April 2025 [Page 2]
Internet-Draft Using STAMP for Segment Routing October 2024
6.3.2. Loopback Measurement Mode for Layer-3 Services over
SR-MPLS Path . . . . . . . . . . . . . . . . . . . . 28
6.3.3. Loopback Measurement Mode for Layer-2 Services over
SR-MPLS Path . . . . . . . . . . . . . . . . . . . . 30
6.4. Loopback Measurement Mode for SRv6 Data Plane . . . . . . 31
6.4.1. Loopback Measurement Mode for SRv6 Paths . . . . . . 31
6.4.2. Loopback Measurement Mode for Layer-3 Services over
SRv6 Path . . . . . . . . . . . . . . . . . . . . . . 33
6.4.3. Loopback Measurement Mode for Layer-2 Services over
SRv6 Path . . . . . . . . . . . . . . . . . . . . . . 36
7. Loopback Measurement Mode with Timestamp and Forward Function
in SR Networks . . . . . . . . . . . . . . . . . . . . . 37
7.1. Loopback Measurement Mode with Timestamp and Forward
Function for SR-MPLS Data Plane . . . . . . . . . . . . . 38
7.1.1. Timestamp and Forward Network Action Assignment . . . 39
7.1.2. Node Capability for MNA Sub-Stack with Opcode
MNA.TSF . . . . . . . . . . . . . . . . . . . . . . . 39
7.2. Loopback Measurement Mode with Timestamp and Forward
Function for SRv6 Data Plane . . . . . . . . . . . . . . 40
7.2.1. Timestamp and Forward Endpoint Function Assignment . 42
7.2.2. Node Capability for Timestamp and Forward Endpoint
Function . . . . . . . . . . . . . . . . . . . . . . 42
8. Packet Loss Measurement in SR Networks . . . . . . . . . . . 42
9. Direct Measurement in SR Networks . . . . . . . . . . . . . . 43
10. ECMP Measurement in SR Networks . . . . . . . . . . . . . . . 43
11. STAMP Session State . . . . . . . . . . . . . . . . . . . . . 44
12. Additional STAMP Test Packet Processing Rules . . . . . . . . 44
12.1. TTL . . . . . . . . . . . . . . . . . . . . . . . . . . 44
12.2. IPv6 Hop Limit . . . . . . . . . . . . . . . . . . . . . 44
12.3. Router Alert Option . . . . . . . . . . . . . . . . . . 45
12.4. IPv6 Flow Label . . . . . . . . . . . . . . . . . . . . 45
12.5. UDP Checksum . . . . . . . . . . . . . . . . . . . . . . 45
13. Implementation Status . . . . . . . . . . . . . . . . . . . . 45
14. Operational and Manageability Considerations . . . . . . . . 46
15. Security Considerations . . . . . . . . . . . . . . . . . . . 46
16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46
17. References . . . . . . . . . . . . . . . . . . . . . . . . . 46
17.1. Normative References . . . . . . . . . . . . . . . . . . 47
17.2. Informative References . . . . . . . . . . . . . . . . . 48
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 50
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 51
Gandhi, et al. Expires 17 April 2025 [Page 3]
Internet-Draft Using STAMP for Segment Routing October 2024
1. Introduction
Segment Routing (SR), as specified in [RFC8402], leverages the source
routing paradigm and applies to both Multiprotocol Label Switching
(SR-MPLS) and IPv6 (SRv6) data planes. SR takes advantage of Equal-
Cost Multipaths (ECMPs) between source and transit nodes, between
transit nodes, and between transit and destination nodes. SR
Policies, defined in [RFC9256], are used to steer traffic through
specific, user-defined paths using a list of segments.
A comprehensive SR Performance Measurement toolset is one of the
essential requirements for measuring network performance to provide
Service Level Agreements (SLAs).
The Simple Two-Way Active Measurement Protocol (STAMP), as specified
in [RFC8762], provides capabilities for the measurement of various
performance metrics in IP networks without the use of a control
channel to pre-signal session parameters. [RFC8972] defines optional
extensions, in the form of TLVs, for STAMP. [RFC9503] augments that
framework to define STAMP extensions for SR networks.
This document describes procedures for Performance Measurement in SR
networks using STAMP defined in [RFC8762], along with its optional
extensions defined in [RFC8972] and augmented in [RFC9503]. The
described procedure is used for links and SR paths [RFC8402]
(including SR Policies [RFC9256] and SR IGP Flexible Algorithm (Flex-
Algo) paths [RFC9350]), as well as Layer-3 (L3) and Layer-2 (L2)
services in SR networks, and is applicable to both SR-MPLS and SRv6
data planes.
STAMP requires protocol support on the Session-Reflector to process
the received test packets, and hence the received test packets need
to be punted from the fast path in the data plane, and return test
packets need to be generated. This limits the scale for the number
of STAMP sessions and the ability to provide faster measurement
intervals. This document enhances the procedure for Performance
Measurement using STAMP to improve the scale for the number of STAMP
sessions and the interval for measurement of SR paths for both SR-
MPLS and SRv6 data planes by defining new measurement modes: one-way,
loopback, and loopback with "timestamp and forward network
programming function".
2. Conventions Used in This Document
Gandhi, et al. Expires 17 April 2025 [Page 4]
Internet-Draft Using STAMP for Segment Routing October 2024
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.
HMAC: Hashed Message Authentication Code.
I2E: Ingress-To-Egress.
IHS: Ingress-To-Egress, Hop-By-Hop or Select Scope.
L2: Layer-2.
L3: Layer-3.
LSE: Label Stack Entry.
MBZ: Must be Zero.
MNA: MPLS Network Action.
MPLS: Multiprotocol Label Switching.
PSID: Path Segment Identifier.
SHA: Secure Hash Algorithm.
SID: Segment ID.
SR: Segment Routing.
SRH: Segment Routing Header.
SR-MPLS: Segment Routing with MPLS data plane.
SRv6: Segment Routing with IPv6 data plane.
SSID: STAMP Session Identifier.
STAMP: Simple Two-Way Active Measurement Protocol.
Gandhi, et al. Expires 17 April 2025 [Page 5]
Internet-Draft Using STAMP for Segment Routing October 2024
TC: Traffic Class.
TSF: Timestamp and Forward.
TTL: Time-To-Live.
VPN: Virtual Private Network.
3. Overview
For performance measurement in SR networks, the STAMP Session-Sender
and Session-Reflector can use the base STAMP test packets defined
[RFC8762]. However, the STAMP test packets defined in [RFC8972] are
preferred in the SR environment because of the optional extensions.
The STAMP test packets are encapsulated using an IP/UDP header
[RFC8762]. In this document, the STAMP test packets using the IP/UDP
header are used for SR networks, where the STAMP test packets are
further encapsulated with an SR-MPLS header or IPv6 Segment Routing
Header (IPv6/SRH).
The STAMP test packets are transmitted in performance measurement
mode of two-way, one-way, loopback, or loopback with "timestamp and
forward network programming function" in SR networks. Note that two-
way measurement mode is referred to in STAMP process in [RFC8762] and
is further described for SR networks in this document. The other
measurement modes are new, described for SR networks in this
document, are not defined by the STAMP process in [RFC8762].
The STAMP test packets are transmitted on the same path as the data
traffic flow under measurement to measure delay and packet loss
experienced by the data traffic flow by using the same SR
encapsulation as the data traffic flow. The STAMP test packets carry
the same SR-MPLS and IPv6/SRH headers as the data packets transmitted
on the SR path and on the L3 and L2 service for the traffic flow
under measurement.
Typically, STAMP reply test packets are transmitted along an IP path
between Session-Reflector and Session-Sender. Matching forward
direction path and return path for STAMP test packets, even for
directly connected nodes are not guaranteed. It may be desired in SR
networks that the same path (same set of links and nodes) between the
Session-Sender and Session-Reflector be used for the STAMP test
packets in both directions, for example, in an ECMP environment.
This is achieved by using the optional STAMP extensions for SR-MPLS
and SRv6 networks specified in [RFC9503] in two-way measurement mode.
The STAMP Session-Reflector uses the return path parameters for the
reply test packet from the STAMP extensions in the received Session-
Sender test packet, as described in [RFC9503]. In loopback
Gandhi, et al. Expires 17 April 2025 [Page 6]
Internet-Draft Using STAMP for Segment Routing October 2024
measurement mode, this is achieved by adding both forward direction
path and return path in the SR-MPLS and IPv6/SRH encapsulation of the
STAMP Session-Sender test packets.
The performance measurement procedure defined in this document is
used to measure both delay and packet loss in SR networks based on
the transmission and reception of STAMP test packets. The optional
STAMP extensions defined in [RFC8972] are used for direct measurement
in SR networks.
4. Two-Way Measurement Mode in SR Networks
As shown in Figure 1, Reference Topology for two-way measurement
mode, the STAMP Session-Sender S1 initiates a STAMP Session-Sender
test packet, and the STAMP Session-Reflector R1 generates and
transmits a reply test packet. The reply test packet may be
transmitted to the STAMP Session-Sender S1 on the same path (same set
of links and nodes) or a different path in the reverse direction from
the path taken towards the Session-Reflector R1.
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. All four timestamps are used by the Session-Sender
to measure round-trip delay as ((T4 - T1) - (T3 - T2)). Timestamps
T1 and T2 are used by the Session-Sender to measure one-way delay as
(T2 - T1), also referred to as near-end (forward direction) delay.
Note that the delay value (T4 - T3) measured by the Session-Sender is
referred to as far-end (backward direction) one-way delay.
The one-way delay requires the clocks on the Session-Sender and
Session-Reflector to be synchronized.
T1 T2
/ \
+-------+ Test Packet +-------+
| | - - - - - - - - - ->| |
| S1 |=====================| R1 |
| |<- - - - - - - - - - | |
+-------+ Reply Test Packet +-------+
\ /
T4 T3
STAMP Session-Sender STAMP Session-Reflector
Figure 1: Reference Topology for Two-Way Measurement Mode
Gandhi, et al. Expires 17 April 2025 [Page 7]
Internet-Draft Using STAMP for Segment Routing October 2024
The nodes S1 and R1 may be connected via a link or an SR path with
SR-MPLS or SRv6 data plane [RFC8402]. The link may be a physical
interface, a virtual link, or a Link Aggregation Group (LAG)
[IEEE802.1AX], or a LAG member. The SR path may be an SR Policy
[RFC9256] on node S1 (called the "head-end") with the destination to
node R1 (called the "tail-end") or an SR IGP Flex-Algo path
[RFC9350]. A Layer-3 (L3) or Layer-2 (L2) VPN service may be carried
over the SR path.
4.1. Example STAMP Reference Model
An example STAMP Reference Model, as defined in [RFC8972] with some
of the typical measurement parameters for a STAMP session, is shown
in Figure 2.
+------------+
| SDN |
| Controller |
+------------+
/ \
Performance Measurement Mode / \ Stateful or Stateless
Destination UDP Port / \ Destination UDP Port
Authentication Mode / \ Authentication Mode
Keychain / \ Keychain
Timestamp Format / \ Timestamp Format
Metric Type / \
SSID / \
v v
+-------+ +-------+
| | STAMP | |
| S1 |==========| R1 |
| | Session | |
+-------+ +-------+
STAMP Session-Sender STAMP Session-Reflector
Figure 2: Example STAMP Reference Model
The Performance Measurement mode is two-way in this example.
The Destination UDP port number is selected for the STAMP function as
described in [RFC8762]. By default, Destination UDP port 862 is
selected for STAMP sessions [RFC8762] for links, SR paths, and L3 and
L2 services.
The Source UDP port is chosen by the Session-Sender. The same or
different Source UDP ports can be chosen for different STAMP
sessions.
Gandhi, et al. Expires 17 April 2025 [Page 8]
Internet-Draft Using STAMP for Segment Routing October 2024
Session-Reflector mode can be Stateful or Stateless, as described in
Section 4 of [RFC8762]. Stateless mode may be desired in two-way
measurement mode.
The SSID field in the STAMP test packets [RFC8972] and local
configuration are used to identify the STAMP sessions that use two-
way measurement mode.
When using the authentication mode for the STAMP sessions, the
matching Authentication Type (e.g., HMAC-SHA-256) and Keychain are
configured on the Session-Sender and Session-Reflector [RFC8762].
Examples of the Timestamp Format are 64-bit truncated Precision Time
Protocol (PTPv2) [IEEE.1588] and 64-bit Network Time Protocol (NTP)
[RFC5905]. By default, the Session-Reflector replies in kind to the
timestamp format received in the Session-Sender test packet, as
indicated by the "Z" flag in the Error Estimate field, as described
in [RFC8762], and it can be based on the Session-Reflector
capability.
Examples of Delay Metrics are one-way delay, round-trip delay, near-
end (forward direction) and far-end (backward direction) delay as
defined in [RFC8762].
Examples of Packet Loss Metric Type are round-trip, near-end (forward
direction) and far-end (backward direction) packet loss as defined in
[RFC8762].
A Software-Defined Networking (SDN) controller can be used for the
configuration and management of STAMP sessions, as described in
[RFC8762]. The controller can also receive streaming telemetry of
operational data. The YANG data model for STAMP, defined in
[I-D.ietf-ippm-stamp-yang], can be used to configure Session-Senders
and Session-Reflectors and to stream the telemetry of operational
data.
4.2. Session-Sender Test Packet
The content of an example Session-Sender test packet transmitted is
shown in Figure 3. The payload containing the Session-Sender test
packet, as defined in Section 3 of [RFC8972], is transmitted with IP
and UDP header [RFC0768].
Gandhi, et al. Expires 17 April 2025 [Page 9]
Internet-Draft Using STAMP for Segment Routing October 2024
+---------------------------------------------------------------+
| IP Header |
. Source IP Address = Session-Sender IPv4 or IPv6 Address .
. Destination IP Address=Session-Reflector IPv4 or IPv6 Address.
. IPv4 Protocol or IPv6 Next-header = UDP (17) .
. .
+---------------------------------------------------------------+
| UDP Header |
. Source Port = Chosen by Session-Sender .
. Destination Port = User-configured Destination Port | 862 .
. .
+---------------------------------------------------------------+
| Payload = Test Packet as specified in Section 3 of RFC 8972 |
. in Figures 1 and 3 .
. .
+---------------------------------------------------------------+
Figure 3: Example Session-Sender Test Packet
4.3. Session-Sender Test Packet for Links
The Session-Sender test packet, as shown in Figure 3, is transmitted
over the link for delay measurement. The local and remote IP
addresses of the link MUST be used as Source and Destination
Addresses in the IP header of the Session-Sender test packets,
respectively. For IPv6 links, the link-local address [RFC7404] can
be used in the IPv6 header.
The Session-Sender can use the local Address Resolution Protocol
(ARP) table or any other similar method to obtain the IP and MAC
addresses for the links when transmitting STAMP packets.
Note that the Session-Sender test packet is further encapsulated with
a Layer-2 header containing the Session-Reflector MAC address as the
Destination MAC address and the Session-Sender MAC address as the
Source MAC address for Ethernet links.
For LAG member links, the STAMP extension for the Micro-Session ID
TLV defined in [RFC9534] can be used to identify the member link.
4.4. Session-Sender Test Packet for SR-MPLS Data Plane
4.4.1. Session-Sender Test Packet for SR-MPLS Paths
An SR-MPLS path may be an SR-MPLS Policy [RFC9256] or an SR-MPLS IGP
Flex-Algo path [RFC9350].
Gandhi, et al. Expires 17 April 2025 [Page 10]
Internet-Draft Using STAMP for Segment Routing October 2024
A Candidate-Path of an SR-MPLS Policy may contain one or more Segment
Lists (i.e., a stack of MPLS labels) [RFC9256]. For delay
measurement of an SR-MPLS Policy, the Session-Sender test packets
MUST be transmitted for every Segment List of the Candidate-Path of
the SR-MPLS Policy, by creating a separate STAMP session for each
Segment List.
Each SR-MPLS Segment List contains a list of 32-bit Label Stack
Entries (LSE) that includes a 20-bit label value, 8-bit Time-To-Live
(TTL) value, 3-bit Traffic-Class (TC) value, and 1-bit End-Of-Stack
(S) field.
The content of an example Session-Sender test packet for an SR-MPLS
path using the same SR-MPLS encapsulation as the data traffic
transmitted over the path is shown in Figure 4.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label[1] (top of stack) | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label[n] | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PSID (optional) | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Test Packet as shown in Figure 3 |
. .
+---------------------------------------------------------------+
Figure 4: Example Session-Sender Test Packet for SR-MPLS Path
The head-end node address of the SR-MPLS Policy MUST be used as the
Source Address in the IP header of the Session-Sender test packet.
The endpoint address of the SR-MPLS Policy MUST be used as the
Destination Address in the IP header of the Session-Sender test
packet.
In the case of Penultimate Hop Popping (PHP), the MPLS header is
removed by the penultimate node. In this case, the Destination
Address in the IP header ensures that the test packets reach the
Session-Reflector at the SR-MPLS Policy endpoint.
In the case of an SR-MPLS Policy with Color-Only Destination
Steering, with the endpoint as an unspecified address (the null
endpoint is 0.0.0.0 for IPv4 or :: for IPv6 (all bits set to the 0
Gandhi, et al. Expires 17 April 2025 [Page 11]
Internet-Draft Using STAMP for Segment Routing October 2024
value)) as defined in Section 8.8.1 of [RFC9256], the loopback
address from the range 127/8 for IPv4 or the loopback address ::1/128
for IPv6 [RFC4291] can be used as the Destination Address in the IP
header of the Session-Sender test packets, respectively. In this
case, the SR-MPLS encapsulation MUST ensure the Session-Sender test
packets reach the SR Policy endpoint (for example, by adding the
Prefix SID label of the SR-MPLS Policy endpoint in the Segment List).
The Path Segment Identifier (PSID) [RFC9545] of an SR-MPLS Policy
(either for Segment List or for Candidate-Path) can be added to the
Segment List of the STAMP test packets and can be used for direct
measurement as described in Section 9, "Direct Measurement in SR
Networks."
Each IGP Flex-Algo in SR-MPLS networks [RFC9350] has Prefix SID
labels advertised by the nodes. For delay measurement of SR-MPLS IGP
Flex-Algo paths, the Session-Sender test packets carry the Flex-Algo
Prefix SID label(s) of the Session-Sender and Session-Reflector in
the MPLS header for that IGP Flex-Algo path under measurement.
4.4.2. Session-Sender Test Packet for Layer-3 Services over SR-MPLS
Path
For delay measurement of the L3 service over an SR-MPLS path, the
same SR-MPLS label stack as the data packets transmitted over the L3
service, including the L3VPN label (advertised by the Session-
Reflector), is used to transmit Session-Sender test packets, as shown
in Figure 5.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label[1] (top of stack) | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| L3VPN Label | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Test Packet as shown in Figure 3 |
. Destination IP Address in L3VPN table .
. Source IP Address in L3VPN table(reverse direction).
. .
+---------------------------------------------------------------+
Figure 5: Example Session-Sender Test Packet for L3 Service over
SR-MPLS Path
Gandhi, et al. Expires 17 April 2025 [Page 12]
Internet-Draft Using STAMP for Segment Routing October 2024
An IP header, as shown in Figure 3, is added to the Session-Sender
test packets after the SR-MPLS encapsulation. The Destination
Address added in the IP header MUST be reachable via the IP table
lookup associated with the L3VPN label added for the L3 service on
the Session-Reflector. The Source Address added in the IP header of
the Session-Sender test packets MUST be reachable via the IP table
lookup associated with the L3 service in the reverse direction.
4.4.3. Session-Sender Test Packet for Layer-2 Services over SR-MPLS
Path
For delay measurement of the L2 service over an SR-MPLS path, the
same SR-MPLS label stack as the data packets transmitted over the L2
service, including the L2VPN label (advertised by the Session-
Reflector), is used to transmit Session-Sender test packets, as 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label[1] (top of stack) | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| L2VPN Label | TC |1| TTL=1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Test Packet as shown in Figure 3 |
. .
+---------------------------------------------------------------+
Figure 6: Example Session-Sender Test Packet for L2 Service over
SR-MPLS Path
The L2VPN label is added with a TTL value of 1 in order to punt the
Session-Sender test packet from the data plane to the CPU or slow
path on the Session-Reflector for STAMP processing.
An IP header, as shown in Figure 3, is added to the Session-Sender
test packets after the MPLS header. It contains the Session-Sender
Address as the Source Address and the Session-Reflector Address as
the Destination Address.
4.5. Session-Sender Test Packet for SRv6 Data Plane
Gandhi, et al. Expires 17 April 2025 [Page 13]
Internet-Draft Using STAMP for Segment Routing October 2024
4.5.1. Session-Sender Test Packet for SRv6 Paths
An SRv6 path may be an SRv6 Policy [RFC9256] or an SRv6 IGP Flex-Algo
path [RFC9350].
A Candidate-Path of an SRv6 Policy may contain one or more Segment
Lists [RFC9256]. For delay measurement of an SRv6 Policy, the
Session-Sender test packets MUST be transmitted for every Segment
List of the Candidate-Path of the SRv6 Policy, by creating a separate
STAMP session for each Segment List.
Each Segment List can contain a number of SRv6 SIDs as defined in
[RFC8986]. The Session-Sender test packets carry the Segment List in
an IPv6 header and SRv6 Segment Routing Header (SRH) [RFC8754].
The content of an example Session-Sender test packet for an SRv6 path
using the same IPv6/SRH encapsulation as the data traffic transmitted
over the path is shown in Figure 7. The IPv6/SRH encapsulation can
be encoded in Insert-Mode or Encaps-Mode. In Insert-Mode, an SRH is
inserted after the IPv6 header of the test packets, as shown in
Example 1 of Figure 7. In Encaps-Mode, the test packets are
encapsulated in an outer IPv6 header with an SRH, as shown in Example
2 of Figure 7.
+---------------------------------------------------------------+
| IPv6 Header |
. Source IP Address = Session-Sender IPv6 Address .
. Destination IP Address = Segment List[Segments Left] .
. Next-Header = 43, Routing Type = SRH (4) .
. .
+---------------------------------------------------------------+
| SRH |
. Segment List[0] = Session-Reflector IPv6 Address or .
. Last Segment of Segment List or .
. Optional PSID .
. <Remained Segment List of Forward Path> .
. Next-Header = UDP (17) .
. .
+---------------------------------------------------------------+
| UDP Header as shown in Figure 3 |
. .
+---------------------------------------------------------------+
| Payload as shown in Figure 3 |
. .
+---------------------------------------------------------------+
Example 1: Using Insert-Mode Encoding
Gandhi, et al. Expires 17 April 2025 [Page 14]
Internet-Draft Using STAMP for Segment Routing October 2024
+---------------------------------------------------------------+
| IPv6 Header |
. Source IP Address = Session-Sender IPv6 Address .
. Destination IP Address = Segment List[Segments Left] .
. Next-Header = 43, Routing Type = SRH (4) .
. .
+---------------------------------------------------------------+
| SRH |
. Segment List[0] = Session-Reflector IPv6 Address or .
. Last Segment of Segment List or .
. Optional PSID .
. <Remained Segment List of Forward Path> .
. Next-Header = 43 (IPv6) or 4 (IPv4) .
. .
+---------------------------------------------------------------+
| IP Header as shown in Figure 3 |
. .
+---------------------------------------------------------------+
| UDP Header as shown in Figure 3 |
. .
+---------------------------------------------------------------+
| Payload as shown in Figure 3 |
. .
+---------------------------------------------------------------+
Example 2: Using Encaps-Mode Encoding
Figure 7: Example Session-Sender Test Packet for SRv6 Path
In the outer IPv6/SRH header, the head-end node address of the SRv6
Policy MUST be used as the Source Address and the next Segment in the
Segment List is used as the Destination Address. When the Segment
List of the Candidate-Path of the SRv6 Policy is empty, the endpoint
address of the SRv6 Policy is added as the Destination Address.
In Encaps-Mode for IPv6, an inner IPv6 header added MUST contain the
endpoint address of the SRv6 Policy as the Destination Address and
the head-end node address of the SRv6 Policy as the Source Address.
In the case of an SRv6 Policy with Color-Only Destination Steering,
with the endpoint as an unspecified address (the null endpoint :: for
IPv6 (all bits set to the 0 value)) as defined in Section 8.8.1 of
[RFC9256], the loopback address ::1/128 for IPv6 [RFC4291] can be
used as the Destination Address in the inner IPv6 header of the
Session-Sender test packets. In this case, the Session-Sender MUST
ensure that the Session-Sender test packets using the Segment List
reach the Session-Reflector at the SRv6 Policy endpoint (for example,
by adding the Prefix SID or the IPv6 address of the SRv6 Policy
endpoint in the Segment List).
Gandhi, et al. Expires 17 April 2025 [Page 15]
Internet-Draft Using STAMP for Segment Routing October 2024
In the case of Penultimate Segment Popping (PSP), the IPv6/SRH
encapsulation is removed by the penultimate node. In Insert-Mode,
the Session-Sender MUST ensure that the Session-Sender test packets
using the Segment List reach the Session-Reflector at the SRv6 Policy
endpoint (for example, by adding the Prefix SID or the IPv6 address
of the SRv6 Policy endpoint in the Segment List).
The SRv6 network programming is described in [RFC8986]. The
procedure defined for Upper-Layer (UL) Header processing for SRv6 End
SIDs in Section 4.1.1 of [RFC8986] is used to process the UDP header
in the received Session-Sender test packets on the Session-Reflector.
The Path Segment Identifier (PSID)
[I-D.ietf-spring-srv6-path-segment] of the SRv6 Policy (either for
Segment List or for Candidate-Path) can be added to the Segment List
of the STAMP test packets and can be used for direct measurement as
described in Section 9, "Direct Measurement in SR Networks."
Each IGP Flex-Algo in SRv6 networks [RFC9350] has Prefix SIDs
advertised by the nodes. For delay measurement of SRv6 IGP Flex-Algo
paths, the Session-Sender test packets carry the SRv6 Flex-Algo
Prefix SIDs of the Session-Sender and Session-Reflector as the Source
Address and Destination Address in the IPv6 header, respectively, for
that SRv6 IGP Flex-Algo path under measurement.
4.5.2. Session-Sender Test Packet for Layer-3 Services over SRv6 Path
For delay measurement of the L3 service over an SRv6 path, the same
IPv6/SRH encapsulation as the data packets transmitted over the L3
service, including the L3VPN SRv6 SID instantiated on the Session-
Reflector (for example, End.DT6 SID instance, End.DT4 SID instance,
End.DT46 instance, as defined in [RFC8986]), is used to transmit
Session-Sender test packets, as shown in Figure 8 for both encoding
modes: Insert-Mode and Encaps-Mode.
+---------------------------------------------------------------+
| IPv6 Header |
. Source IP Address = Session-Sender IPv6 Address .
. Destination IP Address = Segment List[Segments Left] .
. Next-Header = 43, Routing Type = SRH (4) .
. .
+---------------------------------------------------------------+
| SRH |
. Segment List[0] = End.DT6/End.DT46 SID .
. <Remained Segment List of Forward Path> .
. Next-Header = UDP (17) .
. .
+---------------------------------------------------------------+
Gandhi, et al. Expires 17 April 2025 [Page 16]
Internet-Draft Using STAMP for Segment Routing October 2024
| UDP Header as shown in Figure 3 |
. .
+---------------------------------------------------------------+
| Payload as shown in Figure 3 |
. .
+---------------------------------------------------------------+
Example 1: Using Insert-Mode Encoding
+---------------------------------------------------------------+
| IPv6 Header |
. Source IP Address = Session-Sender IPv6 Address .
. Destination IP Address = Segment List[Segments Left] .
. Next-Header = 43, Routing Type = SRH (4) .
. .
+---------------------------------------------------------------+
| SRH |
. Segment List[0] = End.DT4/End.DT46 SID .
. <Remained Segment List of Forward Path> .
. Next-Header = 4 (IPv4) .
. .
+---------------------------------------------------------------+
| IPv4 Header as shown in Figure 3 |
. Destination IPv4 Address in L3VPN table .
. Source IPv4 Address in L3VPN table (reverse direction) .
. .
+---------------------------------------------------------------+
| UDP Header as shown in Figure 3 |
. .
+---------------------------------------------------------------+
| Payload as shown in Figure 3 |
. .
+---------------------------------------------------------------+
Example 2: Using Encaps-Mode Encoding for IPv4
+---------------------------------------------------------------+
| IPv6 Header |
. Source IP Address = Session-Sender IPv6 Address .
. Destination IP Address = Segment List[Segments Left] .
. Next-Header = 43, Routing Type = SRH (4) .
. .
+---------------------------------------------------------------+
| SRH |
. Segment List[0] = End.DT6/End.DT46 SID .
. <Remained Segment List of Forward Path> .
. Next-Header = 43 (IPv6) .
. .
Gandhi, et al. Expires 17 April 2025 [Page 17]
Internet-Draft Using STAMP for Segment Routing October 2024
+---------------------------------------------------------------+
| IPv6 Header as shown in Figure 3 |
. Destination IPv6 Address in L3VPN table .
. Source IPv6 Address in L3VPN table (reverse direction) .
. .
+---------------------------------------------------------------+
| UDP Header as shown in Figure 3 |
. .
+---------------------------------------------------------------+
| Payload as shown in Figure 3 |
. .
+---------------------------------------------------------------+
Example 3: Using Encaps-Mode Encoding for IPv6
Figure 8: Example Session-Sender Test Packet for L3 Service over
SRv6 Path
In Insert-Mode, an SRH is inserted after the IPv6 header of the STAMP
test packets, as shown in Example 1 of Figure 8.
In Encaps-Mode, the STAMP test packets are encapsulated in an outer
IPv6 header with an SRH, as shown in Examples 2 and 3 of Figure 8.
In both modes, the Session-Sender address is added as the Source
Address and the Session-Reflector address is added as the Destination
Address in the outer IPv6 header.
In Encaps-Mode, an inner IP header is added to the Session-Sender
test packets after the IPv6/SRH encapsulation.
The IPv6 Destination Address added in the inner IPv6 header MUST be
reachable via the IPv6 table lookup associated with the L3VPN SRv6
SID added. Similarly, the IPv4 Destination Address added in the
inner IPv4 header MUST be reachable via the IPv4 table lookup
associated with the L3VPN SRv6 SID added.
The IPv6 Source Address added in the inner IPv6 header MUST be
reachable via the IPv6 table lookup for the L3 service in the reverse
direction to return the reply test packets over that L3 service.
Similarly, the IPv4 Source Address added in the inner IPv4 header
MUST be reachable via the IPv4 table lookup for the L3 service in the
reverse direction.
Gandhi, et al. Expires 17 April 2025 [Page 18]
Internet-Draft Using STAMP for Segment Routing October 2024
4.5.3. Session-Sender Test Packet for Layer-2 Services over SRv6 Path
For delay measurement of the L2 service over an SRv6 path, the same
IPv6/SRH encapsulation as the data packets transmitted over the L2
service, including the L2VPN SRv6 SID instantiated on the Session-
Reflector (for example, End.DT2U SID instance defined in [RFC8986]),
is used to transmit Session-Sender test packets, as shown in Figure 9
for both encoding modes: Insert-Mode and Encaps-Mode.
Gandhi, et al. Expires 17 April 2025 [Page 19]
Internet-Draft Using STAMP for Segment Routing October 2024
+---------------------------------------------------------------+
| IPv6 Header |
. Source IP Address = Session-Sender IPv6 Address .
. Destination IP Address = Segment List[Segments Left] .
. Next-Header = 43, Routing Type = SRH (4) .
. .
+---------------------------------------------------------------+
| SRH |
. Segment List[0] = End.DT2U SID .
. <Remained Segment List of Forward Path> .
. Next-Header = UDP (17) .
. .
+---------------------------------------------------------------+
| UDP Header as shown in Figure 3 |
. .
+---------------------------------------------------------------+
| Payload as shown in Figure 3 |
. .
+---------------------------------------------------------------+
Example 1: Using Insert-Mode Encoding
+---------------------------------------------------------------+
| IPv6 Header |
. Source IP Address = Session-Sender IPv6 Address .
. Destination IP Address = Segment List[Segments Left] .
. Next-Header = 43, Routing Type = SRH (4) .
. .
+---------------------------------------------------------------+
| SRH |
. Segment List[0] = End.DT2U SID .
. <Remained Segment List of Forward Path> .
. Next-Header = 43 (IPv6) .
. .
+---------------------------------------------------------------+
| IPv6 Header as shown in Figure 3 |
. Hop Limit = 1 .
. .
+---------------------------------------------------------------+
| UDP Header as shown in Figure 3 |
. .
+---------------------------------------------------------------+
| Payload as shown in Figure 3 |
. .
+---------------------------------------------------------------+
Example 2: Using Encaps-Mode Encoding
Gandhi, et al. Expires 17 April 2025 [Page 20]
Internet-Draft Using STAMP for Segment Routing October 2024
Figure 9: Example Session-Sender Test Packet for L2 Service over
SRv6 Path
In both encoding modes, the Session-Sender address is added as the
Source Address and the Session-Reflector address is added as the
Destination Address in the outer IPv6 header.
In Insert-Mode, an SRH is inserted after the IPv6 header of the STAMP
test packets, as shown in Example 1 of Figure 9.
In Encaps-Mode, in addition to the outer IPv6/SRH encapsulation, an
inner IPv6 header is added, as shown in Example 2 of Figure 9, with a
Hop Limit value of 1 in order to punt the Session-Sender test packets
from the data plane to the CPU or slow path on the Session-Reflector
for STAMP processing. The inner IPv6 header contains the Session-
Sender address as the Source Address and the Session-Reflector
address as the Destination Address.
4.6. Session-Reflector Test Packet
In two-way measurement mode, reply test packets are transmitted by
the Session-Reflector on the same or a different path in the reverse
direction for the STAMP sessions for links, SR paths, and L3 and L2
services. It may be desired that the Session-Reflector test packets
are transmitted on the return path that is the same as the forward
direction path in SR networks.
The Session-Reflector decapsulates the SR header (SR-MPLS header or
IPv6/SRH) from the received Session-Sender test packets. The
Session-Reflector test packet is generated using the information from
the IP/UDP header of the received Session-Sender test packet, as
shown in Figure 10.
Gandhi, et al. Expires 17 April 2025 [Page 21]
Internet-Draft Using STAMP for Segment Routing October 2024
+---------------------------------------------------------------+
| IP Header |
. Source IP Address .
. = Destination IP Address from Session-Sender Test Packet .
. Destination IP Address .
. = Source IP Address from Session-Sender Test Packet .
. IPv4 Protocol or IPv6 Next-header = UDP (17) .
. .
+---------------------------------------------------------------+
| UDP Header |
. Source Port .
. = Destination Port from Session-Sender Test Packet .
. Destination Port .
. = Source Port from Session-Sender Test Packet .
. .
+---------------------------------------------------------------+
| Payload = Test Packet as specified in Section 3 of RFC 8972 |
. in Figures 2 and 4 .
. .
+---------------------------------------------------------------+
Figure 10: Example Session-Reflector Test Packet
The payload contains the Session-Reflector test packet defined in
Section 3 of [RFC8972].
For links, the Session-Sender may request in the test packet for the
Session-Reflector to transmit the reply test packet on the same link
in the reverse direction. It can use the "Reply Requested on the
Same Link" flag in the Control Code Sub-TLV in the Return Path TLV
defined in [RFC9503] for this request.
For SR paths, the Session-Sender may request in the test packet for
the Session-Reflector to transmit the reply test packet on a specific
SR return path. For example, the reverse SR path associated with the
forward direction SR path [I-D.ietf-pce-sr-bidir-path], or the
Binding SID of the reverse SR Policy, or the Prefix SID of the
Session-Sender. It can use the Segment List sub-TLV in the Return
Path TLV defined in [RFC9503] for this request.
For SR IGP Flex-Algo paths, the Session-Sender may request in the
test packet for the Session-Reflector to transmit the reply test
packet on the same SR IGP Flex-Algo path in the reverse direction
using the Segment List sub-TLV in the Return Path TLV defined in
[RFC9503].
Gandhi, et al. Expires 17 April 2025 [Page 22]
Internet-Draft Using STAMP for Segment Routing October 2024
5. One-Way Measurement Mode in SR Networks
As shown in Figure 11, Reference Topology for one-way measurement
mode, the STAMP Session-Sender S1 initiates a Session-Sender test
packet. The STAMP Session-Reflector does not generate and transmit
reply test packets upon receiving Session-Sender test packets.
T1 is a transmit timestamp added by node S1, and T2 is a receive
timestamp added by node R1. Timestamps T1 and T2 are used by the
Session-Reflector to measure one-way delay as (T2 - T1).
The one-way delay requires the clocks on the Session-Sender and
Session-Reflector to be synchronized.
T1 T2
/ \
+-------+ Test Packet +-------+
| | - - - - - - - - - ->| |
| S1 |=====================| R1 |
| | | |
+-------+ +-------+
STAMP Session-Sender STAMP Session-Reflector
Figure 11: Reference Topology for One-Way Measurement Mode
5.1. Example STAMP Reference Model in One-Way Measurement Mode
In one-way measurement mode, for links, SR paths, and L3 and L2
services, the Session-Sender test packets, as defined in Section 4
for STAMP sessions, are transmitted.
Stateful mode of the Session-Reflector [RFC8762] is used as Session-
Receiver in one-way measurement mode. The SSID field in the received
Session-Sender test packets and local configuration can be used to
identify the STAMP sessions that use one-way measurement mode on the
Stateful Session-Reflector.
A different Destination UDP port can be selected for one-way
measurement mode than the STAMP Session-Reflector UDP port used for
two-way measurement mode. By default, Destination UDP port 861
[RFC4656] can be used in one-way measurement mode.
In the case of using the same STAMP Session-Reflector UDP port in
one-way measurement mode, the Session-Sender can request in the test
packets for the Session-Reflector to not transmit reply test packets,
by using the "No Reply Requested" flag in the Control Code Sub-TLV in
the Return Path TLV defined in [RFC9503].
Gandhi, et al. Expires 17 April 2025 [Page 23]
Internet-Draft Using STAMP for Segment Routing October 2024
6. Loopback Measurement Mode in SR Networks
As shown in Figure 12, Reference Topology for loopback measurement
mode, STAMP Session-Sender S1 initiates a Session-Sender test packet
to measure the loopback delay of a bidirectional circular path. At
the STAMP Session-Reflector, the received Session-Sender test packets
MUST NOT be punted out of the fast path in the data plane (i.e., to
the slow path or control plane) but simply forwarded. In other
words, the Session-Reflector does not perform STAMP functions or
generate Session-Reflector test packets.
T1
/
+-------+ Test Packet +-------+
| | - - - - - - - - - - | |
| S1 |====================|| R1 |
| |<- - - - - - - - - - | |
+-------+ Return Test Packet +-------+
\
T4
STAMP Session-Sender STAMP Session-Reflector
(Loopback,
Forward)
Figure 12: Reference Topology for Loopback Measurement Mode
The Session-Sender retrieves the timestamp T1 from the received
Session-Sender test packet and collects the receive timestamp T4
locally. Both timestamps T1 and T4 are used to measure loopback
delay as (T4 - T1). The loopback delay includes the STAMP test
packet processing delay on the Session-Reflector component. The
Session-Reflector processing delay component includes only the time
required to loop the STAMP test packet from the incoming interface to
the outgoing interface in the data plane. The Session-Reflector does
not timestamp the test packets and hence does not need timestamping
capability.
6.1. Example STAMP Reference Model in Loopback Measurement Mode
The Session-Sender test packets are encapsulated with the forward
direction SR path and transmitted to the Session-Reflector, as
defined in Section 4 for STAMP sessions. An IP header is added for
the return path in the Session-Sender test packets that MUST set the
Destination Address equal to the Session-Sender address, as shown in
Figure 13, to return the test packets to the Session-Sender.
Gandhi, et al. Expires 17 April 2025 [Page 24]
Internet-Draft Using STAMP for Segment Routing October 2024
+---------------------------------------------------------------+
| IP Header (Return Path) |
. Source IP Address = Session-Sender IP Address .
. Destination IP Address = Session-Sender IP Address .
. IPv4 Protocol or IPv6 Next-header = UDP (17) .
. .
+---------------------------------------------------------------+
| UDP Header |
. Source Port = Chosen by Session-Sender .
. Destination Port = Source Port .
. .
+---------------------------------------------------------------+
| Payload = Test Packet as specified in Section 3 of RFC 8972 |
. in Figures 1 and 3 .
. .
+---------------------------------------------------------------+
Figure 13: Example Session-Sender Return Test Packet in Loopback
Measurement Mode
The Session-Reflector does not perform the STAMP process, as the
loopback function simply processes the encapsulation including IP and
SR headers (but does not process the UDP header) to forward the
received Session-Sender test packet to the Session-Sender without
STAMP modifications, as defined in [RFC8762].
The Session-Sender can use the SSID field in the received Session-
Sender test packets and local configuration to identify the STAMP
sessions that use loopback measurement mode.
The Session-Sender MUST set the Destination UDP port to the UDP port
it uses to receive the return Session-Reflector test packets (other
than the Destination UDP ports 862 and 861, which are used by the
Session-Reflector). The same UDP port can be used as the Destination
and Source UDP port in the Session-Sender test packets, as shown in
Figure 13.
At the Session-Sender, the 'Session-Sender Sequence Number',
'Session-Sender Timestamp', 'Session-Sender Error Estimate', and
'Session-Sender TTL' fields MUST be set to zero in the transmitted
Session-Sender test packets and MUST be ignored in the received test
packets.
Gandhi, et al. Expires 17 April 2025 [Page 25]
Internet-Draft Using STAMP for Segment Routing October 2024
6.2. Loopback Measurement Mode for Links
The Session-Sender test packets in loopback measurement mode for
Ethernet links, as an example, is transmitted with a Layer-2 header
for the forward direction path. The Layer-2 header contains the link
MAC address on the Session-Reflector as the Destination Address and
the link MAC address on the Session-Sender as the Source MAC address,
as shown in Figure 14.
+---------------------------------------------------------------+
| L2 MAC Header (Forward Path) |
. Source Address = Link MAC Address on Session-Sender .
. Destination Address = Link MAC Address on Session-Reflector .
. Ether-Type = 0x0800 (IPv4) Or 0x86DD (IPv6) .
. .
+---------------------------------------------------------------+
| Test Packet as shown in Figure 13 (Return Path) |
. .
+---------------------------------------------------------------+
Figure 14: Example Session-Sender Test Packet in Loopback
Measurement Mode for Ethernet Link
The IP header for the return path of the Session-Sender test packets
is also added, and it MUST set the Source and Destination Address
equal to the link address on the Session-Sender to return the test
packet to the Session-Sender.
The Session-Reflector decapsulates the Layer-2 header and forwards
the test packets using the IP header for the return path to the
Session-Sender.
6.3. Loopback Measurement Mode for SR-MPLS Data Plane
6.3.1. Loopback Measurement Mode for SR-MPLS Paths
In loopback measurement mode for SR-MPLS paths, the Session-Sender
test packet can carry either the Segment List of the forward
direction path only or both the forward direction and the return
paths in the MPLS header, as shown in Figure 15.
Gandhi, et al. Expires 17 April 2025 [Page 26]
Internet-Draft Using STAMP for Segment Routing October 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label[1] (top of stack) | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label[n] | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PSID (optional) | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Test Packet as shown in Figure 13 (Return Path) |
. .
+---------------------------------------------------------------+
Figure 15: Example Session-Sender Test Packet in Loopback
Measurement Mode for SR-MPLS Path
An SR-MPLS path may be an SR-MPLS Policy [RFC9256] or an SR-MPLS IGP
Flex-Algo path [RFC9350].
In the case of an SR-MPLS Policy using Penultimate Hop Popping (PHP),
the Session-Sender MUST ensure that the STAMP test packets reach the
SR-MPLS Policy endpoint (for example, by adding the Prefix SID label
of the SR-MPLS Policy endpoint in the Segment List of the forward
direction path).
The IP header for the return path of the Session-Sender test packets
is added, and it MUST set the Destination Address equal to the
Session-Sender address.
6.3.1.1. SR-MPLS Return Path
The Session-Sender test packets, in the SR-MPLS label stack, carry
the return path, in addition to the forward direction path. For
example, they carry the SR-MPLS label stack of the Segment List of
the associated reverse Candidate-Path [I-D.ietf-pce-sr-bidir-path] or
the Binding SID label of the reverse SR-MPLS Policy or the SR-MPLS
Prefix SID label of the Session-Sender.
For SR-MPLS IGP Flex-Algo paths, Session-Sender test packets can
carry the SR-MPLS Prefix SID label of the Session-Sender for the same
SR-MPLS IGP Flex-Algo in the reverse direction.
In this case, the optional PSID is not added to the Session-Sender
test packet.
Gandhi, et al. Expires 17 April 2025 [Page 27]
Internet-Draft Using STAMP for Segment Routing October 2024
6.3.1.2. IP Return Path
The Session-Sender test packets, in the MPLS header, carry the SR-
MPLS label stack of the forward direction path only.
The Session-Reflector decapsulates the MPLS header and forwards the
test packet using the IP header for the return path.
In this case, the optional PSID added in the Session-Sender test
packet is for the SR-MPLS forward direction path and is allocated by
the Session-Reflector.
6.3.2. Loopback Measurement Mode for Layer-3 Services over SR-MPLS Path
In loopback measurement mode for the L3 service over an SR-MPLS path,
the SR-MPLS label stack of the data packets transmitted over the L3
service is used to transmit Session-Sender test packets, as shown in
Figure 16.
Gandhi, et al. Expires 17 April 2025 [Page 28]
Internet-Draft Using STAMP for Segment Routing October 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label[1] (top of stack) | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| L3VPN Label (Return Path) | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Test Packet as shown in Figure 13 (Return Path) |
. Destination IP Address in L3VPN table .
. .
+---------------------------------------------------------------+
Example 1: Using SR-MPLS Return Path
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label[1] (top of stack) | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| L3VPN Label(Forward Path) | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Test Packet as shown in Figure 13 (Return Path) |
. Destination IP Address in L3VPN table .
. .
+---------------------------------------------------------------+
Example 2: Using IP Return Path
Figure 16: Example Session-Sender Test Packet in Loopback
Measurement Mode for L3 Service over SR-MPLS Path
The IP header for the return path of the Session-Sender test packets
is added, and it MUST set the Destination Address equal to the
Session-Sender address. The Destination Address added in the IP
header for the return path MUST be reachable via the IP table lookup
associated with the L3VPN label added in the test packets.
Gandhi, et al. Expires 17 April 2025 [Page 29]
Internet-Draft Using STAMP for Segment Routing October 2024
6.3.2.1. SR-MPLS Return Path
The SR-MPLS label stack, except the L3VPN label (advertised by the
Session-Reflector) of the forward direction L3 service, is added in
the Session-Sender test packets. In addition, the SR-MPLS label
stack, including the L3VPN label for the reverse direction L3
service, is also added in the Session-Sender test packets.
6.3.2.2. IP Return Path
The SR-MPLS label stack, including the L3VPN label (advertised by the
Session-Reflector) of the forward direction L3 service, is added to
the Session-Sender test packets.
The Session-Reflector decapsulates the MPLS header and forwards the
Session-Sender test packet using the IP header for the return path
(after adding SR-MPLS encapsulation for the reverse direction L3
service).
6.3.3. Loopback Measurement Mode for Layer-2 Services over SR-MPLS Path
In loopback measurement mode for the L2 service over an SR-MPLS path,
the SR-MPLS label stack of the data packets transmitted over the L2
service is used to transmit Session-Sender test packets, as shown in
Figure 17.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label[1] (top of stack) | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| L2VPN Label (Return Path) | TC |1| TTL=1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Test Packet as shown in Figure 13 (Return Path) |
. .
+---------------------------------------------------------------+
Example: Using SR-MPLS Return Path
Figure 17: Example Session-Sender Test Packet in Loopback
Measurement Mode for L2 Service over SR-MPLS Path
The IP header for the return path MUST be added to the Session-Sender
test packets, and it must set the Destination Address equal to the
Session-Sender address.
Gandhi, et al. Expires 17 April 2025 [Page 30]
Internet-Draft Using STAMP for Segment Routing October 2024
6.3.3.1. SR-MPLS Return Path
The SR-MPLS label stack, except the L2VPN label (advertised by the
Session-Reflector) of the forward direction L2 service, is added to
the Session-Sender test packets. In addition, the SR-MPLS label
stack, including the L2VPN label for the reverse direction L2
service, is added to the Session-Sender test packet with a TTL value
of 1 in order to punt the test packet from the data plane to the CPU
or slow path on the Session-Sender for STAMP processing.
6.3.3.2. IP Return Path
The STAMP test packets not using the SR-MPLS return path are outside
the scope of this document.
6.4. Loopback Measurement Mode for SRv6 Data Plane
6.4.1. Loopback Measurement Mode for SRv6 Paths
In loopback measurement mode for SRv6 paths, the Session-Sender test
packet can carry either the Segment List of the forward direction
path only, using Encaps-Mode encoding, or both the forward direction
and return paths in IPv6/SRH, using Insert-Mode encoding, as shown in
Figure 18.
+---------------------------------------------------------------+
| IPv6 Header |
. Source IP Address = Session-Sender IPv6 Address .
. Destination IP Address = Segment List[Segments Left] .
. Next-Header = 43, Routing Type = SRH (4) .
. .
+---------------------------------------------------------------+
| SRH |
. Segment List[0] = Session-Sender IPv6 Address or .
. Last Segment of Segment List of Return Path.
. <Remained Segment List for Return Path> .
. <PSID (optional), Segment List for Forward Path> .
. Next-Header = UDP (17) .
. .
+---------------------------------------------------------------+
| UDP Header as shown in Figure 13 |
. .
+---------------------------------------------------------------+
| Payload as shown in Figure 13 |
. .
+---------------------------------------------------------------+
Example 1: Using Insert-Mode Encoding with SRv6 Return Path
Gandhi, et al. Expires 17 April 2025 [Page 31]
Internet-Draft Using STAMP for Segment Routing October 2024
+---------------------------------------------------------------+
| IPv6 Header |
. Source IP Address = Session-Sender IPv6 Address .
. Destination IP Address = Segment List[Segments Left] .
. Next-Header = 43, Routing Type = SRH (4) .
. .
+---------------------------------------------------------------+
| SRH |
. Segment List[0] = Session-Reflector IPv6 Address or .
. Last Segment of Segment List or .
. Optional PSID .
. <Remained Segment List of Forward Path> .
. Next-Header = 43 (IPv6) or 4 (IPv4) .
. .
+---------------------------------------------------------------+
| IP Header as shown in Figure 13 (Return Path) |
. .
+---------------------------------------------------------------+
| UDP Header as shown in Figure 13 |
. .
+---------------------------------------------------------------+
| Payload as shown in Figure 13 |
. .
+---------------------------------------------------------------+
Example 2: Using Encaps-Mode Encoding with IP Return Path
Figure 18: Example Session-Sender Test Packet in Loopback
Measurement Mode for SRv6 Path
An SRv6 path may be an SRv6 Policy [RFC9256] or an SRv6 IGP Flex-Algo
path [RFC9350].
The Session-Sender MUST ensure that the Session-Sender test packets
using the Segment List reach the SRv6 Policy endpoint (for example,
by adding the Prefix SID or IPv6 address of the SRv6 Policy endpoint
in the Segment List) in both encoding modes.
6.4.1.1. SRv6 Return Path
For the SRv6 return path, the Session-Sender test packets are encoded
in Insert-Mode, as shown in Example 1 in Figure 18.
The Session-Sender test packets, in the SRv6 Segment List, carry the
return path, in addition to the forward direction path. For example,
they carry the Segment List of the associated reverse Candidate-Path
[I-D.ietf-pce-sr-bidir-path] or the Binding SID of the reverse SRv6
Policy or the SRv6 Prefix SID of the Session-Sender.
Gandhi, et al. Expires 17 April 2025 [Page 32]
Internet-Draft Using STAMP for Segment Routing October 2024
For SRv6 IGP Flex-Algo paths, the Session-Sender test packets can
carry the SRv6 Prefix SID of the Session-Sender for the same IGP
Flex-Algo in the reverse direction.
In this case, the optional PSID is not added to the Session-Sender
test packet.
The Encaps-Mode with an SRv6 return path (example not shown in
Figure 18), carrying an inner IP header with the IP return path can
also be used.
6.4.1.2. IP Return Path
For the IP return path, the Session-Sender test packets are encoded
in Encaps-Mode, as shown in Example 2 in Figure 18.
The Session-Sender test packets carry the Segment List of the SRv6
forward direction path only.
An inner IP header for the return path MUST be added to the Session-
Sender test packets, and it must set the Destination Address equal to
the Session-Sender address to return the test packet to the Session-
Sender.
The Session-Reflector decapsulates the IPv6/SRH headers and forwards
the test packet using the inner IP header for the return path.
In this case, the optional PSID added to the Session-Sender test
packet is for the SRv6 forward direction path and is allocated by the
Session-Reflector.
6.4.2. Loopback Measurement Mode for Layer-3 Services over SRv6 Path
In loopback measurement mode for the L3 service over an SRv6 path,
the IPv6/SRH encapsulation of the data packets transmitted over the
L3 service, including the L3VPN SRv6 SID (for example, End.DT6 SID
instance, End.DT4 SID instance, etc., as defined in [RFC8986]), is
used to transmit Session-Sender test packets, as shown in Figure 19.
+---------------------------------------------------------------+
| IPv6 Header |
. Source IP Address = Session-Sender IPv6 Address .
. Destination IP Address = Segment List[Segments Left] .
. Next-Header = 43, Routing Type = SRH (4) .
. .
+---------------------------------------------------------------+
| SRH |
. Segment List[0] = End.DT4/DT6/DT46 SID of Return Path .
Gandhi, et al. Expires 17 April 2025 [Page 33]
Internet-Draft Using STAMP for Segment Routing October 2024
. <Remained Segment List of Return Path> .
. <Remained Segment List of Forward Path> .
. Next-Header = UDP (17) .
. .
+---------------------------------------------------------------+
| UDP Header as shown in Figure 13 |
. .
+---------------------------------------------------------------+
| Payload as shown in Figure 13 |
. .
+---------------------------------------------------------------+
Example 1: Using Insert-Mode Encoding with SRv6 Return Path
+---------------------------------------------------------------+
| IPv6 Header |
. Source IP Address = Session-Sender IPv6 Address .
. Destination IP Address = Segment List[Segments Left] .
. Next-Header = 43, Routing Type = SRH (4) .
. .
+---------------------------------------------------------------+
| SRH |
. Segment List[0] = End.DT4/DT46 SID of Forward Path .
. <Remained Segment List of Forward Path> .
. Next-Header = 4 (IPv4) .
. .
+---------------------------------------------------------------+
| IPv4 Header as shown in Figure 13 (Return Path) |
. Destination IPv4 Address in L3VPN table .
+---------------------------------------------------------------+
| UDP Header as shown in Figure 13 |
. .
+---------------------------------------------------------------+
| Payload as shown in Figure 13 |
. .
+---------------------------------------------------------------+
Example 2: Using Encaps-Mode Encoding with IPv4 Return Path
+---------------------------------------------------------------+
| IPv6 Header |
. Source IP Address = Session-Sender IPv6 Address .
. Destination IP Address = Segment List[Segments Left] .
. Next-Header = 43, Routing Type = SRH (4) .
. .
+---------------------------------------------------------------+
| SRH |
. Segment List[0] = End.DT6/DT46 SID of Forward Path .
Gandhi, et al. Expires 17 April 2025 [Page 34]
Internet-Draft Using STAMP for Segment Routing October 2024
. <Remained Segment List of Forward Path> .
. Next-Header = 43 (IPv6) .
. .
+---------------------------------------------------------------+
| IPv6 Header as shown in Figure 13 (Return Path) |
. Destination IPv6 Address in L3VPN table .
+---------------------------------------------------------------+
| UDP Header as shown in Figure 13 |
. .
+---------------------------------------------------------------+
| Payload as shown in Figure 13 |
. .
+---------------------------------------------------------------+
Example 3: Using Encaps-Mode Encoding with IPv6 Return Path
Figure 19: Example Session-Sender Test Packet in Loopback
Measurement Mode for L3 Service over SRv6 Path
6.4.2.1. SRv6 Return Path
For the SRv6 return path, the Session-Sender test packets are encoded
in Insert-Mode, as shown in Example 1 in Figure 19.
The SRv6 Segment List, except the L3VPN SRv6 SID instantiated on the
Session-Reflector of the forward direction L3 service, is added to
the IPv6/SRH encapsulation of the Session-Sender test packet. In
addition, the SRv6 Segment List, including the L3VPN SRv6 SID
instantiated on the Session-Sender for the reverse direction L3
service, is also added to the IPv6/SRH encapsulation to return the
test packet to the Session-Sender from the Session-Reflector.
The Encaps-Mode with an SRv6 return path (example not shown in
Figure 19), carrying an inner IP header with the IP return path can
also be used.
6.4.2.2. IP Return Path
For the IP return path, the Session-Sender test packets are encoded
in Encaps-Mode, as shown in Examples 2 and 3 in Figure 19.
The SRv6 Segment List, including the L3VPN SRv6 SID instantiated on
the Session-Reflector for the forward direction L3 service, is added
to the IPv6/SRH encapsulation to transmit the Session-Sender test
packet to the Session-Reflector.
Gandhi, et al. Expires 17 April 2025 [Page 35]
Internet-Draft Using STAMP for Segment Routing October 2024
An inner IP header for the return path MUST also be added to the
Session-Sender test packets, and it must set the Destination Address
equal to the Session-Sender address to forward the test packet to the
Session-Sender from the Session-Reflector. In this case, the
Destination Address added in the inner IP header for the return path
MUST be reachable via the IPv4 or IPv6 table lookup associated with
the L3VPN SRv6 SID on the Session-Reflector.
The Session-Reflector decapsulates the IPv6/SRH and forwards the
Session-Sender test packet using the inner IP header for the return
path (after adding IPv6/SRH encapsulation for the reverse direction
L3 service).
6.4.3. Loopback Measurement Mode for Layer-2 Services over SRv6 Path
In loopback measurement mode for the L2 service over an SRv6 path,
the IPv6/SRH encapsulation of the data packets transmitted over the
L2 service, including the L2VPN SRv6 SID (for example, End.DT2U SID
instance defined in [RFC8986]), is used to transmit Session-Sender
test packets, as shown in Figure 20.
+---------------------------------------------------------------+
| IPv6 Header |
. Source IP Address = Session-Sender IPv6 Address .
. Destination IP Address = Segment List[Segments Left] .
. Next-Header = 43, Routing Type = SRH (4) .
. .
+---------------------------------------------------------------+
| SRH |
. Segment List[0] = End.DT2U SID of Return Path .
. <Remained Segment List of Return Path> .
. <Remained Segment List of Forward Path> .
. Next-Header = UDP (17) .
. .
+---------------------------------------------------------------+
| UDP Header as shown in Figure 13 |
. .
+---------------------------------------------------------------+
| Payload as shown in Figure 13 |
. .
+---------------------------------------------------------------+
Example: Using Insert-Mode Encoding with SRv6 Return Path
Figure 20: Example Session-Sender Test Packet in Loopback Mode
for L2 Service over SRv6 Path
Gandhi, et al. Expires 17 April 2025 [Page 36]
Internet-Draft Using STAMP for Segment Routing October 2024
6.4.3.1. SRv6 Return Path
For the SRv6 return path, the Session-Sender test packets are encoded
in Insert-Mode, as shown in Figure 20.
The SRv6 Segment List, except the L2VPN SRv6 SID instantiated on the
Session-Reflector for the forward direction L2 service, is added to
the IPv6/SRH encapsulation of the Session-Sender test packet. In
addition, the SRv6 Segment List, including the L2VPN SRv6 SID
instantiated on the Session-Sender for the reverse direction L2
service, is also added to the IPv6/SRH encapsulation to return the
test packet to the Session-Sender from the Session-Reflector.
6.4.3.2. IP Return Path
For the IP return path, the Session-Sender test packets are encoded
in Encaps-Mode. However, this mode is outside the scope of this
document.
7. Loopback Measurement Mode with Timestamp and Forward Function in SR
Networks
As shown in Figure 21, Reference Topology for "loopback measurement
mode with timestamp and forward," STAMP Session-Sender S1 initiates a
Session-Sender test packet in loopback measurement mode with a
network programming function. The network programming function is
used to optimize the "operations of punt test packet and generate
return test packet" on the STAMP Session-Reflector, as timestamping
is implemented in the fast path in the data plane. This helps to
achieve a higher number of STAMP sessions and faster measurement
intervals.
T1 T2
/ \
+-------+ Test Packet +-------+
| | - - - - - - - - - - | |
| S1 |====================|| R1 |
| |<- - - - - - - - - - | |
+-------+ Return Test Packet +-------+
\
T4
STAMP Session-Sender STAMP Session-Reflector
(Loopback,
Timestamp and Forward)
Figure 21: Reference Topology for Loopback Measurement Mode with
Timestamp and Forward Function
Gandhi, et al. Expires 17 April 2025 [Page 37]
Internet-Draft Using STAMP for Segment Routing October 2024
The Session-Sender retrieves the timestamps T1 and T2 from the
received Session-Sender test packet and collects the receive
timestamp T4 locally. Timestamps T1 and T2 are used by the Session-
Sender to measure one-way delay as (T2 - T1). Timestamps T1 and T4
are used by the Session-Sender to measure loopback delay as (T4 -
T1).
The Session-Sender adds the transmit timestamp (T1) in the payload of
the Session-Sender test packet. The Session-Reflector adds the
receive timestamp (T2) in the payload of the received test packet in
the fast path in the data plane without punting the test packet
(e.g., to the slow path or control plane) for STAMP packet
processing. The network programming function carried by the test
packet enables the Session-Reflector to add the "receive timestamp"
(T2) at a specific offset in the payload of the test packet.
7.1. Loopback Measurement Mode with Timestamp and Forward Function for
SR-MPLS Data Plane
The MPLS Network Action (MNA) Sub-Stack defined in
[I-D.ietf-mpls-mna-hdr] is used for SR-MPLS paths for the "timestamp
and forward network programming function" for STAMP test packets.
The MNA Sub-Stack carries the MNA Label (bSPL value TBA1) as defined
in [I-D.ietf-mpls-mna-hdr]. A new MNA Opcode (value MNA.TSF) is
defined for the network action for the "Timestamp and Forward network
programming function."
In the Session-Sender test packets for SR-MPLS paths, the MNA Sub-
Stack with Opcode MNA.TSF is added in the MPLS header, as shown in
Figure 22, to collect the timestamp in the "Receive Timestamp" field
in the payload of the test packet from the Session-Reflector. The
Ingress-to-Egress (I2E), Hop-By-Hop (HBH), Select scope (IHS) is set
to "I2E" when the return path is IP/UDP. The Network Action Sub-
Stack Length (NASL) is set to 0 when there is no LSE after the
MNA.TSF Opcode in the MNA Sub-Stack. The U flag is set to skip the
network action and forward the test packet (and not drop the packet).
The SR-MPLS label stack of the return path can be added after the MNA
Sub-Stack to receive the return test packet on a specific path, as
described in loopback measurement for SR-MPLS path in this document.
The IHS scope is set to "Select" in this case.
Gandhi, et al. Expires 17 April 2025 [Page 38]
Internet-Draft Using STAMP for Segment Routing October 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label[1] (top of stack) | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label[n] | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MNA Label (value TBA1) | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|7-bit MNA.TSF| 0x0 |R|IHS|S| RES |U|NASL=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Test Packet as shown in Figure 13 (Return Path) |
. .
+---------------------------------------------------------------+
Figure 22: Example Session-Sender Test Packet in Loopback
Measurement Mode with TSF for SR-MPLS Paths
When a Session-Reflector receives a test packet with the MNA Sub-
Stack with Opcode MNA.TSF, after timestamping the test packet payload
at a specific offset, the Session-Reflector pops the MNA Sub-Stack
(after completing any other network actions) and forwards the test
packet as defined in the loopback measurement mode for SR-MPLS path
in this document.
7.1.1. Timestamp and Forward Network Action Assignment
A new MPLS Network Action Opcode is defined called "Timestamp and
Forward Network Action, MNA.TSF." The MNA.TSF Opcode is statically
configured on the Session-Reflector node with a value from "Private
Use from Range 111-126." The timestamp format for 64-bit PTPv2 and
NTP to be added to the Session-Sender test packet payload is
statically configured for MNA.TSF. The offset in the Session-Sender
test packet payload (e.g., for unauthenticated mode with offset 16
bytes) is also statically configured for MNA.TSF.
7.1.2. Node Capability for MNA Sub-Stack with Opcode MNA.TSF
The Session-Sender needs to know if the Session-Reflector can process
the MNA Sub-Stack with Opcode MNA.TSF to avoid dropping the test
packets. The signaling extension for this capability exchange or
local configuration is outside the scope of this document.
Gandhi, et al. Expires 17 April 2025 [Page 39]
Internet-Draft Using STAMP for Segment Routing October 2024
7.2. Loopback Measurement Mode with Timestamp and Forward Function for
SRv6 Data Plane
[RFC8986] defines SRv6 Endpoint Behaviors for SRv6 nodes. A new SRv6
Endpoint Behavior is defined for "Timestamp and Forward (TSF) network
programming function" for STAMP test packets.
In the Session-Sender test packets for SRv6 paths, Timestamp and
Forward Endpoint Function (End.TSF) is carried with the target
Segment Identifier (SID) in SRH [RFC8754], as shown in Figure 23, for
both Insert-Mode and Encaps-Mode encoding, to collect timestamps in
the "Receive Timestamp" field in the payload of the test packet from
the Session-Reflector.
Gandhi, et al. Expires 17 April 2025 [Page 40]
Internet-Draft Using STAMP for Segment Routing October 2024
+---------------------------------------------------------------+
| IPv6 Header |
. Source IP Address = Session-Sender IPv6 Address .
. Destination IP Address = Segment List[Segments Left] .
. Next-Header = 43, Routing Type = SRH (4) .
. .
+---------------------------------------------------------------+
| SRH |
. <Segment List for Return Path> .
. <Segment List for Forward Path including End.TSF SID> .
. Next-Header = UDP (17) .
. .
+---------------------------------------------------------------+
| UDP Header as shown in Figure 13 |
. .
+---------------------------------------------------------------+
| Payload as shown in Figure 13 |
. .
+---------------------------------------------------------------+
Example 1: Using Insert-Mode Encoding with SRv6 Return Path
+---------------------------------------------------------------+
| IPv6 Header |
. Source IP Address = Session-Sender IPv6 Address .
. Destination IP Address = Segment List[Segments Left] .
. Next-Header = 43, Routing Type = SRH (4) .
. .
+---------------------------------------------------------------+
| SRH |
. Segment List[0] = End.TSF SID .
. <Remained Segment List of Forward Path> .
. Next-Header = 43 (IPv6) or 4 (IPv4) .
. .
+---------------------------------------------------------------+
| IP Header as shown in Figure 13 (Return Path) |
. .
+---------------------------------------------------------------+
| UDP Header as shown in Figure 13 |
. .
+---------------------------------------------------------------+
| Payload as shown in Figure 13 |
. .
+---------------------------------------------------------------+
Example 2: Using Encaps-Mode Encoding with IP Return Path
Gandhi, et al. Expires 17 April 2025 [Page 41]
Internet-Draft Using STAMP for Segment Routing October 2024
Figure 23: Example Session-Sender Test Packet in Loopback
Measurement Mode with TSF for SRv6 Paths
The Session-Sender test packets are encoded in Insert-Mode for the
SRv6 return path and in Encaps-Mode for the IP return path, as
defined in the loopback measurement mode for SRv6 paths in this
document.
When a Session-Reflector receives a test packet with Timestamp and
Forward Endpoint (End.TSF) for the target SID, which is local, after
timestamping the test packet at a specific offset, the Session-
Reflector forwards the test packet as defined in the loopback
measurement mode for SRv6 paths.
7.2.1. Timestamp and Forward Endpoint Function Assignment
A new SRv6 Endpoint Behavior is defined called "Endpoint Behavior
bound to SID with Timestamp and Forward (End.TSF)." The End.TSF is a
node SID instantiated at the Session-Reflector node. The End.TSF is
statically configured on the Session-Reflector node and not
advertised into the routing protocols. The timestamp format for
64-bit PTPv2 and NTP to be added to the Session-Sender test packet
payload is statically configured for End.TSF. The offset in the
Session-Sender test packet payload (e.g., for unauthenticated mode
with an offset of 16 bytes) is also statically configured for
End.TSF.
7.2.2. Node Capability for Timestamp and Forward Endpoint Function
The Session-Sender needs to know if the Session-Reflector can process
the Timestamp and Forward Endpoint Function to avoid dropping the
test packets. The signaling extension for this capability exchange
or local configuration is outside the scope of this document.
8. Packet Loss Measurement in SR Networks
The procedure described in Section 4, for delay measurement in SR
networks using STAMP test packets, also allows for round-trip, near-
end (forward direction), and far-end (backward direction) inferred
packet loss measurement in SR networks. This, however, provides only
an approximate view of the data packet loss.
The loopback measurement mode and loopback measurement mode with the
timestamp and forward network programming function allow only the
round-trip packet loss measurement.
Gandhi, et al. Expires 17 April 2025 [Page 42]
Internet-Draft Using STAMP for Segment Routing October 2024
9. Direct Measurement in SR Networks
The STAMP "Direct Measurement" TLV (Type 5) defined in [RFC8972] can
be used in SR networks for data packet loss measurement. The STAMP
test packets with this TLV are transmitted using the procedure
described in Section 4 for delay measurement in SR networks using
STAMP test packets to collect the Session-Sender transmit counters
and Session-Reflector receive and transmit counters of the data
packet flows for direct measurement.
The PSID carried in the received data packet for the traffic flow
under measurement can be used to measure received data packets (for
the receive traffic counter) for an SR path on the Session-Reflector.
In the case of L3 and L2 services in SR networks, the associated SR-
MPLS service labels and SRv6 service SIDs can be used to measure
received data packets (for receive traffic counters) on the Session-
Reflector.
In loopback measurement mode and loopback measurement mode with the
timestamp and forward network programming function, direct
measurement is not applicable.
10. ECMP Measurement in SR Networks
An SR path, for example, a Segment List of an SR Policy, can have
ECMPs between the source and transit nodes, between transit nodes,
and between transit and destination nodes. The usage of node SID
[RFC8402] by an SR path can result in ECMP paths. In addition, the
usage of Anycast SID [RFC8402] by an SR path can result in ECMP paths
via transit nodes that are part of that Anycast group. The STAMP
test packets need to be transmitted to traverse different ECMP paths
to measure the delay of an SR path.
The forwarding plane has various hashing functions available to
forward packets on specific ECMP paths. The mechanisms described in
[RFC8029] and [RFC5884] for handling ECMPs are also applicable to
delay measurement.
For SR-MPLS paths, different values of the MPLS entropy label
[RFC6790] can be used in Session-Sender and Session-Reflector test
packets to take advantage of the hashing function in the data plane
to influence the ECMP path taken by them.
In the IPv4 header of the Session-Sender and Session-Reflector test
packets, different values of the Destination Address from the range
127/8 can be used to exercise different IPv4 ECMP paths taken by
them.
Gandhi, et al. Expires 17 April 2025 [Page 43]
Internet-Draft Using STAMP for Segment Routing October 2024
As specified in [RFC6437], different values of the Flow Label field
in the outer IPv6 header can also be used to exercise different IPv6
ECMP paths.
11. STAMP Session State
The threshold-based notification for delay and packet loss metrics
may not be generated if the delay and packet loss metrics are not
changing significantly. For unambiguous monitoring, the controller
may need to distinguish whether the STAMP session is active but delay
and packet loss metrics are not significantly crossing the
thresholds, or if the STAMP session has failed and is not
transmitting or receiving test packets.
The STAMP session state monitoring allows knowing if the performance
measurement test is active, idle, or failed. The STAMP session state
is notified as idle when the Session-Sender is not transmitting test
packets. The STAMP session state is initially notified as active
when the Session-Sender is transmitting test packets and as soon as
one or more reply test packets are received at the Session-Sender.
The STAMP session state is notified as failed when consecutive N
number of reply test packets are not received at the Session-Sender
after the STAMP session state is notified as active, where N
(consecutive packet loss count) is a locally provisioned value. In
this case, the failed state of the STAMP session on the Session-
Sender also indicates the connectivity (i.e., liveness) failure of
the link, SR path, or L3/L2 service where the STAMP session was
active.
12. Additional STAMP Test Packet Processing Rules
The processing rules described in this section are applicable to the
STAMP test packets for links, SR paths, and L3 and L2 services in SR
networks.
12.1. TTL
The TTL field in the IPv4 and MPLS headers of the Session-Sender and
Session-Reflector test packets MUST be set to 255 as per the
Generalized TTL Security Mechanism (GTSM) [RFC5082].
12.2. IPv6 Hop Limit
The Hop Limit (HL) field in all IPv6 headers of the Session-Sender
and Session-Reflector test packets MUST be set to 255 as per the
Generalized TTL Security Mechanism (GTSM) [RFC5082].
Gandhi, et al. Expires 17 April 2025 [Page 44]
Internet-Draft Using STAMP for Segment Routing October 2024
12.3. Router Alert Option
The Router Alert IP option (RAO) [RFC2113] MUST NOT be set in the
Session-Sender and Session-Reflector test packets to be able to punt
the test packets using the Destination UDP port for STAMP.
12.4. IPv6 Flow Label
The Flow Label field in the IPv6 header of the Session-Sender test
packets is set to the value that is used by the data packets for the
traffic flow on the SR path being measured by the Session-Sender.
The Session-Reflector SHOULD use the Flow Label value it received in
the IPv6 header of the Session-Sender test packet in the reply test
packet, and it can be based on the local configuration on the
Session-Reflector.
12.5. UDP Checksum
For IPv4 STAMP test packets, where the local processor, after adding
the timestamp, is not capable of re-computing the UDP checksum or
adding checksum complement [RFC7820], the Session-Sender and Session-
Reflector can set the UDP checksum value to 0 [RFC8085].
For IPv6 STAMP test packets, where the local processor, after adding
the timestamp, is not capable of re-computing the UDP checksum or
adding checksum complement [RFC7820], the Session-Sender and Session-
Reflector can use the procedure defined in [RFC6936] for the UDP
checksum (with value set to 0) for the UDP ports used for the STAMP
sessions, and it can be based on the local policy.
13. Implementation Status
Editorial note: Please remove this section prior to publication.
The following Cisco routing platforms running IOS-XR operating system
have participated in an interop testing for one-way, two-way and
loopback measurement modes for SR-MPLS and SRv6:
* Cisco 8802 (based Cisco Silicon One Q200)
* Cisco ASR9904 with Lightspeed linecard and Tomahawk linecard
* Cisco NCS5500 (based on Broadcom Jericho1 platform)
* Cisco NCS5700 (based on Broadcom Jericho2 platform)
Gandhi, et al. Expires 17 April 2025 [Page 45]
Internet-Draft Using STAMP for Segment Routing October 2024
14. Operational and Manageability Considerations
The operational considerations described in Section 5 of [RFC8762]
and manageability considerations described in Section 9 of [RFC8402]
are applicable to this specification.
15. Security Considerations
The security considerations specified in [RFC8762], [RFC8972], and
[RFC9503] also apply to the procedures described in this document.
Use of HMAC-SHA-256 in the authenticated mode protects the data
integrity of the STAMP test packets. The message integrity
protection using HMAC defined in Section 4.4 of [RFC8762] can be used
with the procedure described in this document.
STAMP uses the well-known UDP port number that could become a target
of denial of service (DoS) or could be used to aid on-path attacks.
Thus, the security considerations and measures to mitigate the risk
of the attack documented in Section 6 of [RFC8545] equally apply to
the procedures described in this document.
The procedures defined in this document are intended for deployment
in a single network administrative domain. As such, the Session-
Sender address, Session-Reflector address, and forward direction and
return paths are provisioned by the operator for the STAMP session.
It is assumed that the operator has verified the integrity of the
forward direction and return paths of the STAMP test packets.
When using the procedures defined in [RFC6936], the security
considerations specified in [RFC6936] also apply.
The security considerations specified in [I-D.ietf-mpls-mna-hdr] are
also applicable to the procedures for the SR-MPLS data plane defined
in this document.
SRv6 STAMP test packets can use the HMAC protection authentication
defined for SRH in [RFC8754].
The security considerations specified in [RFC8986] are also
applicable to the procedures for the SRv6 data plane defined in this
document.
16. IANA Considerations
This document does not require any IANA action.
17. References
Gandhi, et al. Expires 17 April 2025 [Page 46]
Internet-Draft Using STAMP for Segment Routing October 2024
17.1. Normative References
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
DOI 10.17487/RFC0768, August 1980,
<https://www.rfc-editor.org/info/rfc768>.
[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>.
[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>.
[RFC9503] Gandhi, R., Ed., Filsfils, C., Chen, M., Janssens, B., and
R. Foote, "Simple Two-Way Active Measurement Protocol
(STAMP) Extensions for Segment Routing Networks",
RFC 9503, DOI 10.17487/RFC9503, October 2023,
<https://www.rfc-editor.org/info/rfc9503>.
[RFC9534] Li, Z., Zhou, T., Guo, J., Mirsky, G., and R. Gandhi,
"Simple Two-Way Active Measurement Protocol Extensions for
Performance Measurement on a Link Aggregation Group",
RFC 9534, DOI 10.17487/RFC9534, January 2024,
<https://www.rfc-editor.org/info/rfc9534>.
[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-
Gandhi, et al. Expires 17 April 2025 [Page 47]
Internet-Draft Using STAMP for Segment Routing October 2024
08, 30 August 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-mpls-
mna-hdr-08>.
17.2. Informative References
[IEEE.1588]
IEEE, "1588-2008 IEEE Standard for a Precision Clock
Synchronization Protocol for Networked Measurement and
Control Systems", March 2008.
[IEEE802.1AX]
IEEE Std. 802.1AX, "IEEE Standard for Local and
metropolitan area networks - Link Aggregation", November
2008.
[RFC2113] Katz, D., "IP Router Alert Option", RFC 2113,
DOI 10.17487/RFC2113, February 1997,
<https://www.rfc-editor.org/info/rfc2113>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <https://www.rfc-editor.org/info/rfc4291>.
[RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M.
Zekauskas, "A One-way Active Measurement Protocol
(OWAMP)", RFC 4656, DOI 10.17487/RFC4656, September 2006,
<https://www.rfc-editor.org/info/rfc4656>.
[RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C.
Pignataro, "The Generalized TTL Security Mechanism
(GTSM)", RFC 5082, DOI 10.17487/RFC5082, October 2007,
<https://www.rfc-editor.org/info/rfc5082>.
[RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow,
"Bidirectional Forwarding Detection (BFD) for MPLS Label
Switched Paths (LSPs)", RFC 5884, DOI 10.17487/RFC5884,
June 2010, <https://www.rfc-editor.org/info/rfc5884>.
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
"Network Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
<https://www.rfc-editor.org/info/rfc5905>.
[RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme,
"IPv6 Flow Label Specification", RFC 6437,
DOI 10.17487/RFC6437, November 2011,
<https://www.rfc-editor.org/info/rfc6437>.
Gandhi, et al. Expires 17 April 2025 [Page 48]
Internet-Draft Using STAMP for Segment Routing October 2024
[RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and
L. Yong, "The Use of Entropy Labels in MPLS Forwarding",
RFC 6790, DOI 10.17487/RFC6790, November 2012,
<https://www.rfc-editor.org/info/rfc6790>.
[RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement
for the Use of IPv6 UDP Datagrams with Zero Checksums",
RFC 6936, DOI 10.17487/RFC6936, April 2013,
<https://www.rfc-editor.org/info/rfc6936>.
[RFC7404] Behringer, M. and E. Vyncke, "Using Only Link-Local
Addressing inside an IPv6 Network", RFC 7404,
DOI 10.17487/RFC7404, November 2014,
<https://www.rfc-editor.org/info/rfc7404>.
[RFC7820] Mizrahi, T., "UDP Checksum Complement in the One-Way
Active Measurement Protocol (OWAMP) and Two-Way Active
Measurement Protocol (TWAMP)", RFC 7820,
DOI 10.17487/RFC7820, March 2016,
<https://www.rfc-editor.org/info/rfc7820>.
[RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N.,
Aldrin, S., and M. Chen, "Detecting Multiprotocol Label
Switched (MPLS) Data-Plane Failures", RFC 8029,
DOI 10.17487/RFC8029, March 2017,
<https://www.rfc-editor.org/info/rfc8029>.
[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage
Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085,
March 2017, <https://www.rfc-editor.org/info/rfc8085>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/info/rfc8402>.
[RFC8545] Morton, A., Ed. and G. Mirsky, Ed., "Well-Known Port
Assignments for the One-Way Active Measurement Protocol
(OWAMP) and the Two-Way Active Measurement Protocol
(TWAMP)", RFC 8545, DOI 10.17487/RFC8545, March 2019,
<https://www.rfc-editor.org/info/rfc8545>.
[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>.
Gandhi, et al. Expires 17 April 2025 [Page 49]
Internet-Draft Using STAMP for Segment Routing October 2024
[RFC9256] Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov,
A., and P. Mattes, "Segment Routing Policy Architecture",
RFC 9256, DOI 10.17487/RFC9256, July 2022,
<https://www.rfc-editor.org/info/rfc9256>.
[RFC9350] Psenak, P., Ed., Hegde, S., Filsfils, C., Talaulikar, K.,
and A. Gulko, "IGP Flexible Algorithm", RFC 9350,
DOI 10.17487/RFC9350, February 2023,
<https://www.rfc-editor.org/info/rfc9350>.
[RFC9545] Cheng, W., Ed., Li, H., Li, C., Ed., Gandhi, R., and R.
Zigler, "Path Segment Identifier in MPLS-Based Segment
Routing Networks", RFC 9545, DOI 10.17487/RFC9545,
February 2024, <https://www.rfc-editor.org/info/rfc9545>.
[I-D.ietf-spring-srv6-path-segment]
Li, C., Cheng, W., Chen, M., Dhody, D., and Y. Zhu, "Path
Segment Identifier (PSID) in SRv6 (Segment Routing in
IPv6)", Work in Progress, Internet-Draft, draft-ietf-
spring-srv6-path-segment-11, 18 September 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-spring-
srv6-path-segment-11>.
[I-D.ietf-pce-sr-bidir-path]
Li, C., Chen, M., Cheng, W., Gandhi, R., and Q. Xiong,
"Path Computation Element Communication Protocol (PCEP)
Extensions for Associated Bidirectional Segment Routing
(SR) Paths", Work in Progress, Internet-Draft, draft-ietf-
pce-sr-bidir-path-14, 11 August 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-pce-sr-
bidir-path-14>.
[I-D.ietf-ippm-stamp-yang]
Mirsky, G., Min, X., Luo, W. S., and R. Gandhi, "Simple
Two-way Active Measurement Protocol (STAMP) Data Model",
Work in Progress, Internet-Draft, draft-ietf-ippm-stamp-
yang-12, 5 November 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-ippm-
stamp-yang-12>.
Acknowledgments
The authors would like to thank Ianik Semco and Thierry Couture for
the discussions on the use cases for Performance Measurement in
Segment Routing. The authors would also like to thank Greg Mirsky,
Gyan Mishra, Xie Jingrong, and Mike Koldychev for reviewing this
document and providing useful comments and suggestions. Patrick
Khordoc, Haowei Shi, Amila Tharaperiya Gamage, Pengyan Zhang, Ruby
Gandhi, et al. Expires 17 April 2025 [Page 50]
Internet-Draft Using STAMP for Segment Routing October 2024
Lin, and Radu Valceanu have helped improve the mechanisms described
in this document.
Contributors
The following people have substantially contributed to this document:
Bart Janssens
Colt
Email: Bart.Janssens@colt.net
Navin Vaghamshi
Reliance
Email: Navin.Vaghamshi@ril.com
Moses Nagarajah
Telstra
Email: Moses.Nagarajah@team.telstra.com
Amit Dhamija
Arrcus
India
Email: amitd@arrcus.com
Authors' Addresses
Rakesh Gandhi (editor)
Cisco Systems, Inc.
Canada
Email: rgandhi@cisco.com
Clarence Filsfils
Cisco Systems, Inc.
Email: cfilsfil@cisco.com
Daniel Voyer
Bell Canada
Email: daniel.voyer@bell.ca
Mach(Guoyi) Chen
Huawei
Email: mach.chen@huawei.com
Gandhi, et al. Expires 17 April 2025 [Page 51]
Internet-Draft Using STAMP for Segment Routing October 2024
Richard Foote
Nokia
Email: footer.foote@nokia.com
Gandhi, et al. Expires 17 April 2025 [Page 52]