| Internet-Draft | Using STAMP for Segment Routing | May 2025 |
| Gandhi, et al. | Expires 10 November 2025 | [Page] |
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 the 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.¶
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 10 November 2025.¶
Copyright (c) 2025 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.¶
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 an essential requirement 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 measuring 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. As a result, 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 frequency of STAMP test packets and the ability to provide faster measurement intervals. This document enhances the procedure for Performance Measurement using STAMP to improve the scalability 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 the "timestamp and forward network programming function."¶
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.¶
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.¶
TC: Traffic Class.¶
TSF: Timestamp and Forward.¶
TTL: Time-To-Live.¶
VPN: Virtual Private Network.¶
For performance measurement in SR networks, the STAMP Session-Sender and Session-Reflector use the STAMP test packets defined in [RFC8762] along with optional extensions defined in [RFC8972]. 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 an IPv6 Segment Routing Header (IPv6/SRH).¶
The STAMP test packets are transmitted in performance measurement modes of two-way, one-way, loopback, or loopback with "timestamp and forward network programming function" in SR networks. Note that the 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, which are new and 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 the delay and packet loss experienced by the data traffic flow 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 the 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 (i.e., the 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 measurement mode, this is achieved by adding both the forward direction path and return path in the SR-MPLS and IPv6/SRH encapsulation of the 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.¶
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 are transmitted to the STAMP Session-Sender S1 on the same path (i.e., the same set of links and nodes) or on 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 the 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 using either PTPv2 or NTPv4.¶
T1 T2
/ \
+-------+ Test Packet +-------+
| | - - - - - - - - - ->| |
| S1 |=====================| R1 |
| |<- - - - - - - - - - | |
+-------+ Reply Test Packet +-------+
\ /
T4 T3
STAMP Session-Sender STAMP Session-Reflector
The nodes S1 and R1 may be connected via a link or an SR path with an 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 "endpoint") 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.¶
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
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 is chosen for different STAMP sessions.¶
Session-Reflector mode is Stateful or Stateless, as described in Section 4 of [RFC8762]. Stateless Session-Reflector mode is applicable in two-way measurement mode only.¶
The SSID field in the STAMP test packets [RFC8972], along with local configuration, is 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 include 64-bit truncated Precision Time Protocol (PTPv2) [IEEE.1588] and 64-bit Network Time Protocol (NTPv4) [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's 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.¶
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].¶
+---------------------------------------------------------------+ | 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 = 17 (UDP) . . . +---------------------------------------------------------------+ | 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 . . . +---------------------------------------------------------------+
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 are used as the Source and Destination Addresses in the IP header of the Session-Sender test packets, respectively. For IPv6 links, the link-local address [RFC7404] can also be used in the IP 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, as defined in [RFC9534] is used to identify each member link associated with the STAMP session on the Session-Sender and Session-Reflector.¶
An SR-MPLS Policy Candidate-Path contains 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 are 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 include a 20-bit label value, an 8-bit Time-To-Live (TTL) value, a 3-bit Traffic-Class (TC) value, and a 1-bit End-Of-Stack (S) field.¶
The content of an example Session-Sender test packet for an SR-MPLS path using the SR-MPLS encapsulation of 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 | . . +---------------------------------------------------------------+
The head-end node address of the SR-MPLS Policy is used as the Source Address in the IP header of the Session-Sender test packet. The endpoint address of the SR-MPLS Policy is 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, where the endpoint is an unspecified address (the null endpoint is 0.0.0.0 for IPv4 or :: for IPv6 (all bits set to 0)) 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] is used as the Destination Address in the IP header of the Session-Sender test packets, respectively. In this case, the SR-MPLS encapsulation ensures that 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 the Segment List or for the Candidate-Path) is added in the Segment List of the STAMP test packets when the egress node supports the PSID allocation.¶
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.¶
For delay measurement of the L3 service over an SR-MPLS path, the SR-MPLS label stack of the data packets transmitted over the L3 service, including the L3VPN label (advertised by the Session-Reflector), is used to encapsulate the 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). . . +---------------------------------------------------------------+
An IP header, as shown in Figure 3, is added to the Session-Sender test packets after the SR-MPLS encapsulation. The Destination Address 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 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.¶
For delay measurement of the L2 service over an SR-MPLS path, the SR-MPLS label stack of the data packets transmitted over the L2 service, including the L2VPN label (advertised by the Session-Reflector), is used to encapsulate the 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 | . . +---------------------------------------------------------------+
The L2VPN label is added with a TTL value of 1 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.¶
In this document, two modes of encoding for the SRv6 data plane are defined for STAMP test packets: Insert-Mode and Encaps-Mode. In Insert-Mode, an SRH is inserted after the IPv6 header of the test packets. In Encaps-Mode, the test packets with an IP header are further encapsulated with an outer IPv6/SRH.¶
When the Session-Sender test packets are encoded in Encaps-Mode, the test packets are injected with the IP header and the outer IPv6/SRH encapsulation is added by the forwarding path that also encapsulates the data packets (when the SRv6 path is present in the data plane). This encoding mode requires the Session-Reflector to process two IP headers and a UDP header to locally punt the test packets to the slow path.¶
On the other hand, when the Session-Sender test packets are encoded in Insert-Mode, the test packets are injected with IPv6/SRH encapsulation, for example, when using explicitly configured SRv6 paths, those may not be present in the data plane. This encoding mode requires the Session-Reflector to process fewer headers to locally punt the test packets to the slow path. In this encoding mode, to ensure that the test packets reach the Session-Reflector, PSP is not used.¶
In both encoding modes, the timestamps are collected in the data plane, ensuring that the measured delay values are similar.¶
A Segment List of an SRv6 Policy optionally contains the node SID of the SRv6 Policy endpoint as the ultimate SID. Similarly, the L3/L2 service steered over the SRv6 Policy also ensures that the traffic reaches the endpoint of the SRv6 Policy. Thus, there are two incoming SRv6 SIDs for the Session-Reflector in the packet: the node SID for the endpoint and the SID for the L3/L2 service. As an optimization to avoid processing additional SIDs, the Session-Sender excludes the node SID of the endpoint when carrying an L3/L2 service SID in the packet's Segment List.¶
An SRv6 Policy Candidate-Path contains one or more Segment Lists [RFC9256]. For delay measurement of an SRv6 Policy, the Session-Sender test packets are 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 contains a number of SRv6 SIDs as defined in [RFC8986]. The Session-Sender test packets carry the Segment List in an IPv6 header and an SRv6 Segment Routing Header (SRH) [RFC8754].¶
The content of an example Session-Sender test packet for an SRv6 path using the IPv6/SRH encapsulation of the data traffic transmitted over the path is shown in Figure 7. The IPv6/SRH encapsulation is 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 (IPv6-Route) .
. .
+---------------------------------------------------------------+
| Routing Type = 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 = 17 (UDP) .
. .
+---------------------------------------------------------------+
| UDP Header as shown in Figure 3 |
. .
+---------------------------------------------------------------+
| Payload as shown in Figure 3 |
. .
+---------------------------------------------------------------+
Example 1: Encapsulation Using Insert-Mode Encoding
+---------------------------------------------------------------+
| IPv6 Header |
. Source IP Address = Session-Sender IPv6 Address .
. Destination IP Address = Segment List[Segments Left] .
. Next-Header = 43 (IPv6-Route) .
. .
+---------------------------------------------------------------+
| Routing Type = 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 = 41 (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: Encapsulation Using Encaps-Mode Encoding
In the outer IPv6/SRH header, the head-end node address of the SRv6 Policy is 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 contains 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, where the endpoint is an unspecified address (the null endpoint :: for IPv6 (all bits set to 0)) as defined in Section 8.8.1 of [RFC9256], the loopback address ::1/128 for IPv6 [RFC4291] is used as the Destination Address in the inner IPv6 header of the Session-Sender test packets. In this case, the Session-Sender ensures 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).¶
In the case of Penultimate Segment Popping (PSP), the IPv6/SRH encapsulation is removed by the penultimate node. In Insert-Mode, the Session-Sender ensures 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 the Segment List or for the Candidate-Path) is added in the Segment List of the STAMP test packets when the egress node supports the PSID allocation.¶
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 Addresses in the IPv6 header, respectively, for that SRv6 IGP Flex-Algo path under measurement.¶
For delay measurement of 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 instantiated on the Session-Reflector (for example, End.DT6 SID instance, End.DT4 SID instance, or End.DT46 instance, as defined in [RFC8986]), is used to encapsulate the 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 (IPv6-Route) .
. .
+---------------------------------------------------------------+
| Routing Type = 4 (SRH) |
. Segment List[0] = End.DT6/End.DT46 SID .
. <Remained Segment List of Forward Path> .
. Next-Header = 17 (UDP) .
. .
+---------------------------------------------------------------+
| UDP Header as shown in Figure 3 |
. .
+---------------------------------------------------------------+
| Payload as shown in Figure 3 |
. .
+---------------------------------------------------------------+
Example 1: Encapsulation Using Insert-Mode Encoding
+---------------------------------------------------------------+
| IPv6 Header |
. Source IP Address = Session-Sender IPv6 Address .
. Destination IP Address = Segment List[Segments Left] .
. Next-Header = 43 (IPv6-Route) .
. .
+---------------------------------------------------------------+
| Routing Type = 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: Encapsulation 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 (IPv6-Route) .
. .
+---------------------------------------------------------------+
| Routing Type = 4 (SRH) |
. Segment List[0] = End.DT6/End.DT46 SID .
. <Remained Segment List of Forward Path> .
. Next-Header = 41 (IPv6) .
. .
+---------------------------------------------------------------+
| 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: Encapsulation Using Encaps-Mode Encoding for IPv6
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.¶
For delay measurement of 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 instantiated on the Session-Reflector (for example, the End.DT2U SID instance defined in [RFC8986]), is used to encapsulate the Session-Sender test packets, as shown in Figure 9 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 (IPv6-Route) .
. .
+---------------------------------------------------------------+
| Routing Type = 4 (SRH) |
. Segment List[0] = End.DT2U SID .
. <Remained Segment List of Forward Path> .
. Next-Header = 17 (UDP) .
. .
+---------------------------------------------------------------+
| UDP Header as shown in Figure 3 |
. .
+---------------------------------------------------------------+
| Payload as shown in Figure 3 |
. .
+---------------------------------------------------------------+
Example 1: Encapsulation Using Insert-Mode Encoding
+---------------------------------------------------------------+
| IPv6 Header |
. Source IP Address = Session-Sender IPv6 Address .
. Destination IP Address = Segment List[Segments Left] .
. Next-Header = 43 (IPv6-Route) .
. .
+---------------------------------------------------------------+
| Routing Type = 4 (SRH) |
. Segment List[0] = End.DT2U SID .
. <Remained Segment List of Forward Path> .
. Next-Header = 41 (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: Encapsulation Using Encaps-Mode Encoding
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 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.¶
In two-way measurement mode, the Session-Reflector test packets SHOULD be transmitted on the same link or the same SR path (i.e., the same set of links and nodes) in the reverse direction to the Session-Sender to perform accurate two-way delay measurement.¶
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.¶
+---------------------------------------------------------------+ | 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 = 17 (UDP) . . . +---------------------------------------------------------------+ | 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 . . . +---------------------------------------------------------------+
The payload contains the Session-Reflector test packet defined in Section 3 of [RFC8972].¶
For links, the Session-Sender sets the "Reply Requested on the Same Link" flag in the Control Code Sub-TLV in the Return Path TLV defined in [RFC9503] to request the Session-Reflector to transmit the reply test packet on the same link in the reverse direction.¶
For SR paths, the Session-Sender uses the Segment List sub-TLV in the Return Path TLV defined in [RFC9503] to request the Session-Reflector to transmit the reply test packet on a specific SR return path. Examples of specific SR return paths include: on the reverse SR path associated with the forward direction SR path, the Binding SID of the reverse SR Policy, or the Prefix SID of the Session-Sender.¶
For SR IGP Flex-Algo paths, the Session-Sender uses the Segment List sub-TLV in the Return Path TLV defined in [RFC9503] to request the Session-Reflector to transmit the reply test packet on the same SR IGP Flex-Algo path in the reverse direction.¶
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 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 using either PTPv2 or NTPv4.¶
T1 T2
/ \
+-------+ Test Packet +-------+
| | - - - - - - - - - ->| |
| S1 |=====================| R1 |
| | | |
+-------+ +-------+
STAMP Session-Sender STAMP Session-Reflector
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.¶
The Stateful mode of the Session-Reflector [RFC8762] is used as the Session-Receiver in one-way measurement mode. The SSID field in the received Session-Sender test packets [RFC8972], along with local configuration, is used to identify the STAMP sessions that use one-way measurement mode on the Stateful Session-Reflector.¶
A different Destination UDP port is selected for one-way measurement mode than the UDP port that is used by the STAMP Session-Reflector for two-way measurement mode. When the same STAMP Session-Reflector UDP port is selected in one-way measurement mode, the Session-Sender requests in the test packets that the Session-Reflector not transmit reply test packets. For that, it uses the "No Reply Requested" flag in the Control Code Sub-TLV in the Return Path TLV defined in [RFC9503].¶
As shown in Figure 12, Reference Topology for loopback measurement mode, the STAMP Session-Sender S1 initiates a Session-Sender test packet to measure the loopback delay of a bidirectional path. At the STAMP Session-Reflector, the received Session-Sender test packets are not punted out of the fast path in the data plane (i.e., to the slow path or control plane) but are simply forwarded. In other words, the Session-Reflector does not perform STAMP functions or generate the Session-Reflector test packets.¶
T1
/
+-------+ Test Packet +-------+
| | - - - - - - - - - - | |
| S1 |====================|| R1 |
| |<- - - - - - - - - - | |
+-------+ Return Test Packet +-------+
\
T4
STAMP Session-Sender STAMP Session-Reflector
(Loopback,
Forward)
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 the 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, therefore, does not require timestamping capability.¶
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, setting the Destination Address equal to the Session-Sender address, as shown in Figure 13, to return the test packets to the Session-Sender.¶
+---------------------------------------------------------------+ | IP Header (Return Path) | . Source IP Address = Session-Sender IP Address . . Destination IP Address = Session-Sender IP Address . . IPv4 Protocol or IPv6 Next-header = 17 (UDP) . . . +---------------------------------------------------------------+ | 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 . . . +---------------------------------------------------------------+
The Session-Reflector does not perform the STAMP process, as the loopback function simply processes the encapsulation including the 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 SSID field in the received Session-Sender test packets [RFC8972], along with local configuration, is used to identify the STAMP sessions that use loopback measurement mode.¶
The Session-Sender sets the Destination UDP port to the UDP port it uses to receive the return the Session-Reflector test packets (other than Destination UDP port 862, which is used by the Session-Reflector). The same UDP port is used as both 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 are set to zero in the transmitted Session-Sender test packets and are ignored in the received test packets.¶
The Session-Sender test packets in loopback measurement mode for Ethernet links, as an example, are 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) | . . +---------------------------------------------------------------+
The IP header for the return path of the Session-Sender test packets is also added, and setting the Source and Destination Addresses 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 packet using the IP header for the return path to the Session-Sender.¶
In loopback measurement mode for SR-MPLS paths, the Session-Sender test packet carries either the Segment List of the forward direction path only or both the forward direction and return paths in the MPLS header, as specified in [RFC8403], as shown in Figure 15.¶
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Return Path Label[1] | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Return Path Label[n] | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Return Path PSID (optional)| TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Test Packet as shown in Figure 13 (Return Path) |
. .
+---------------------------------------------------------------+
Example 1: Encapsulation 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label[n] | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PSID (optional) | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Test Packet as shown in Figure 13 (Return Path) |
. .
+---------------------------------------------------------------+
Example 2: Encapsulation Using IP Return Path
In the case of an SR-MPLS Policy using Penultimate Hop Popping (PHP), the Session-Sender ensures 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, setting the Destination Address equal to the Session-Sender address.¶
The Session-Sender test packets, in the SR-MPLS label stack, carry the return path in addition to the forward direction path, as shown in Example 1 of Figure 15. For example, they carry the SR-MPLS label stack of the Segment List of the associated reverse Candidate-Path, the Binding SID label of the reverse SR-MPLS Policy, or the SR-MPLS Prefix SID label of the Session-Sender. The Binding SID of the reverse SR-MPLS Policy can be configured on the Session-Sender using an SDN controller, for example.¶
For SR-MPLS IGP Flex-Algo paths, the Session-Sender test packets carry the SR-MPLS Prefix SID label of the Session-Sender for the same SR-MPLS IGP Flex-Algo in the reverse direction.¶
The optional PSID added in the Session-Sender test packet is for the SR-MPLS return path and is allocated by the Session-Sender.¶
The Session-Sender test packets, in the MPLS header, carry only the SR-MPLS label stack of the forward direction path, as shown in Example 2 of Figure 15.¶
The Session-Reflector decapsulates the MPLS header and forwards the test packet using the IP header of the return path.¶
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.¶
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 encapsulate the Session-Sender test packets, as shown in Figure 16.¶
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Return Path Label[1] | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| L3VPN Label (Return Path) | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Test Packet as shown in Figure 13 (Return Path) |
. Source and Destination IP Address in L3VPN table .
. .
+---------------------------------------------------------------+
Example 1: Encapsulation 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) |
. Source and Destination IP Address in L3VPN table .
. .
+---------------------------------------------------------------+
Example 2: Encapsulation Using IP Return Path
The IP header for the return path of the Session-Sender test packets is added, setting 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.¶
The SR-MPLS label stack, except for 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.¶
The SR-MPLS label stack, including the L3VPN label (advertised by the Session-Reflector) for 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.¶
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 encapsulate the 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label[n] | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Return Path Label[1] | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| L2VPN Label (Return Path) | TC |1| TTL=1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Test Packet as shown in Figure 13 (Return Path) |
. .
+---------------------------------------------------------------+
Example: Encapsulation Using SR-MPLS Return Path
The IP header for the return path is added to the Session-Sender test packets, and setting the Destination Address equal to the Session-Sender address.¶
The SR-MPLS label stack, except for the L2VPN label (advertised by the Session-Reflector) for 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 to punt the test packet from the data plane to the CPU or slow path on the Session-Sender for STAMP processing.¶
The STAMP test packets that do not use the SR-MPLS return path are outside the scope of this document.¶
In loopback measurement mode for SRv6 paths, the Session-Sender test packet carries 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 (IPv6-Route) .
. .
+---------------------------------------------------------------+
| Routing Type = 4 (SRH) |
. Segment List[0] = Session-Sender IPv6 Address or .
. Last Segment of Segment List of Return Path.
. or Optional PSID of Return Path .
. <Remained Segment List for Return Path> .
. <Optional PSID of Forward Path> .
. <Remained Segment List for Forward Path> .
. Next-Header = 17 (UDP) .
. .
+---------------------------------------------------------------+
| UDP Header as shown in Figure 13 |
. .
+---------------------------------------------------------------+
| Payload as shown in Figure 13 |
. .
+---------------------------------------------------------------+
Example 1: Encapsulation 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 (IPv6-Route) .
. .
+---------------------------------------------------------------+
| Routing Type = 4 (SRH) |
. Segment List[0] = Session-Reflector IPv6 Address or .
. Last Segment of Segment List or .
. Optional PSID of Forward Path .
. <Remained Segment List of Forward Path> .
. Next-Header = 41 (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: Encapsulation Using Encaps-Mode Encoding
with IP Return Path
The Session-Sender ensures 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.¶
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 may carry the Segment List of the associated reverse Candidate-Path, the Binding SID of the reverse SRv6 Policy, or the SRv6 Prefix SID of the Session-Sender. The Binding SID of the reverse SRv6 Policy can be configured on the Session-Sender using an SDN controller, for example.¶
For SRv6 IGP Flex-Algo paths, the Session-Sender test packets carry the SRv6 Prefix SID of the Session-Sender for the same IGP Flex-Algo in the reverse direction.¶
The optional PSID is not added to the Session-Sender test packet.¶
Encaps-Mode with an SRv6 return path (example not shown in Figure 18) does not preclude carrying an inner IP header with the 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 is added to the Session-Sender test packets, and setting 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.¶
The optional PSID added to the Session-Sender test packet is for the SRv6 forward direction path and is allocated by the Session-Reflector.¶
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 encapsulate the 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 (IPv6-Route) .
. .
+---------------------------------------------------------------+
| Routing Type = 4 (SRH) |
. Segment List[0] = End.DT4/DT6/DT46 SID of Return Path .
. <Remained Segment List of Return Path> .
. <Remained Segment List of Forward Path> .
. Next-Header = 17 (UDP) .
. .
+---------------------------------------------------------------+
| UDP Header as shown in Figure 13 |
. .
+---------------------------------------------------------------+
| Payload as shown in Figure 13 |
. .
+---------------------------------------------------------------+
Example 1: Encapsulation 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 (IPv6-Route) .
. .
+---------------------------------------------------------------+
| Routing Type = 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: Encapsulation 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 (IPv6-Route) .
. .
+---------------------------------------------------------------+
| Routing Type = 4 (SRH) |
. Segment List[0] = End.DT6/DT46 SID of Forward Path .
. <Remained Segment List of Forward Path> .
. Next-Header = 41 (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: Encapsulation Using Encaps-Mode Encoding
with IPv6 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 for the L3VPN SRv6 SID instantiated on the Session-Reflector for 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.¶
Encaps-Mode with an SRv6 return path (example not shown in Figure 19) does not preclude carrying an inner IP header with the 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 to encapsulate the Session-Sender test packets to the Session-Reflector.¶
An inner IP header for the return path is also added to the Session-Sender test packets, setting 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.¶
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 (e.g., the End.DT2U SID instance defined in [RFC8986]), is used to encapsulate the 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 (IPv6-Route) .
. .
+---------------------------------------------------------------+
| Routing Type = 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 = 17 (UDP) .
. .
+---------------------------------------------------------------+
| UDP Header as shown in Figure 13 |
. .
+---------------------------------------------------------------+
| Payload as shown in Figure 13 |
. .
+---------------------------------------------------------------+
Example: Encapsulation Using Insert-Mode Encoding
with 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 for 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. Additionally, 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.¶
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.¶
As shown in Figure 21, Reference Topology for "loopback measurement mode with timestamp and forward", the 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 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)
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.¶
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 Network Action Length (NAL) is set to 0 for this network action as there is no additional data LSE added. 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 is added after the MNA Sub-Stack to receive the return test packet on a specific path, as described in the loopback measurement for SR-MPLS paths in this document. The IHS scope is set to "Select" in this case.¶
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|U|NASL=0 |NAL=0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Test Packet as shown in Figure 13 (Return Path) | . . +---------------------------------------------------------------+
When a Session-Reflector receives a test packet with the MNA Sub-Stack with Opcode MNA.TSF, it timestamps the test packet payload at a specific offset, 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 paths in this document.¶
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 the "Private Use Range 111-126." The timestamp format for 64-bit PTPv2 and NTPv4, to be added to the Session-Sender test packet payload, is also statically configured for MNA.TSF. The offset in the Session-Sender test packet payload (e.g., for unauthenticated mode with an offset of 16 bytes) is similarly statically configured for MNA.TSF.¶
The Session-Sender needs to know if the Session-Reflector is capable of processing 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.¶
[RFC8986] defines SRv6 Endpoint Behaviors for SRv6 nodes. A new SRv6 Endpoint Behavior is defined as the "Timestamp and Forward (TSF) network programming function" for STAMP test packets.¶
In the Session-Sender test packets for SRv6 paths, the Timestamp and Forward Endpoint Function (End.TSF) is carried with the target Segment Identifier (SID) in the 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.¶
+---------------------------------------------------------------+
| IPv6 Header |
. Source IP Address = Session-Sender IPv6 Address .
. Destination IP Address = Segment List[Segments Left] .
. Next-Header = 43 (IPv6-Route) .
. .
+---------------------------------------------------------------+
| Routing Type = 4 (SRH) |
. <Segment List for Return Path> .
. <Segment List for Forward Path including End.TSF SID> .
. Next-Header = 17 (UDP) .
. .
+---------------------------------------------------------------+
| UDP Header as shown in Figure 13 |
. .
+---------------------------------------------------------------+
| Payload as shown in Figure 13 |
. .
+---------------------------------------------------------------+
Example 1: Encapsulation 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 (IPv6-Route) .
. .
+---------------------------------------------------------------+
| Routing Type = 4 (SRH) |
. Segment List[0] = End.TSF SID .
. <Remained Segment List of Forward Path> .
. Next-Header = 41 (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: Encapsulation Using Encaps-Mode Encoding
with IP Return Path
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 the Timestamp and Forward Endpoint (End.TSF) for the target SID, which is local, it timestamps the test packet at a specific offset and then forwards the test packet as defined in the loopback measurement mode for SRv6 paths.¶
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 is not advertised into the routing protocols. The timestamp format for 64-bit PTPv2 and NTPv4, 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.¶
The Session-Sender needs to know if the Session-Reflector is capable of processing the Timestamp and Forward Endpoint Function to avoid dropping test packets. The signaling extension for this capability exchange or local configuration is outside the scope of this document.¶
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 round-trip packet loss measurement.¶
The STAMP "Direct Measurement" TLV (Type 5), defined in [RFC8972], is 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 data packets is used to measure received data packets (for the receive traffic counter) for the associated SR path on the Session-Reflector.¶
In the case of L3 and L2 services in SR networks, the associated SR-MPLS service labels or SRv6 service SIDs are 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.¶
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 use 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.¶
For SR-MPLS paths, different values of the MPLS entropy label [RFC6790] are used in the 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 are used to exercise different IPv4 ECMP paths taken by them, as described in Section 2.1 of [RFC8029].¶
As specified in [RFC6437], different values of the Flow Label field in the outer IPv6 header are also used to exercise different IPv6 ECMP paths.¶
The threshold-based notification for the delay and packet loss metrics are not generated if the delay and packet loss metrics are not changing significantly. For unambiguous monitoring, the controller needs 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 to determine whether 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 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 failure of the link, SR path, or L3/L2 service where the STAMP session was active.¶
The processing rules described in this section apply to the STAMP test packets for links, SR paths, and L3 and L2 services in SR networks.¶
The TTL field in the IPv4 and MPLS headers of the Session-Sender and Session-Reflector test packets is set to 255 as per the Generalized TTL Security Mechanism (GTSM) [RFC5082].¶
The Hop Limit (HL) field in all IPv6 headers of the Session-Sender and Session-Reflector test packets is set to 255 as per the Generalized TTL Security Mechanism (GTSM) [RFC5082].¶
The Router Alert IP option (RAO) [RFC2113] is not required in the Session-Sender and Session-Reflector test packets to punt the test packets using the Destination UDP port for STAMP.¶
The Flow Label field in the IPv6 header of the Session-Sender test packets is set to the value used by the data packets for the traffic flow on the SR path being measured by the Session-Sender.¶
The Session-Reflector uses the Flow Label value it received in the IPv6 header of the Session-Sender test packet in the reply test packet, which can be based on the local policy.¶
For IPv4 STAMP test packets, where the local processor, after adding the timestamp, is not capable of re-computing the UDP checksum or adding a checksum complement [RFC7820], the Session-Sender and Session-Reflector 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 a checksum complement [RFC7820], the Session-Sender and Session-Reflector use the procedure defined in [RFC6936] for the UDP checksum (with the value set to 0) for the UDP ports used for the STAMP sessions, and this can be based on the local policy.¶
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 paths:¶
* Cisco 8802 (based on 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)¶
The operational considerations described in Section 5 of [RFC8762] and the manageability considerations described in Section 9 of [RFC8402] are applicable to this specification.¶
When STAMP sessions are created for every Segment List of the SR Policies, the scalability of the number of STAMP sessions needs to be carefully considered.¶
The security considerations specified in [RFC8762], [RFC8972], and [RFC9503] also apply to the procedures described in this document.¶
The use of HMAC-SHA-256 in authenticated mode protects the data integrity of the STAMP test packets. The message integrity protection using HMAC, as defined in Section 4.4 of [RFC8762], can be used with the procedure described in this document.¶
STAMP uses a well-known UDP port number that could become a target of denial of service (DoS) attacks or could be used to aid on-path attacks. Thus, the security considerations and measures to mitigate the risk of such attacks, as 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.¶
This document does not require any IANA action.¶
The authors would like to thank Ianik Semco and Thierry Couture for their discussions on the use cases for Performance Measurement in Segment Routing. The authors would also like to thank Greg Mirsky, Gyan Mishra, Xie Jingrong, Zafar Ali, Boris Hassanov, Ruediger Geib, and Mike Koldychev for reviewing this document and providing useful comments and suggestions. Patrick Khordoc, Haowei Shi, Amila Tharaperiya Gamage, Pengyan Zhang, Ruby Lin, Senni Tan, and Radu Valceanu have helped improve the mechanisms described in this document.¶
The following people have substantially contributed to this document:¶
Daniel Voyer Cisco Systems, Inc. Email: davoyer@cisco.com¶
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¶