Performance Measurement Using Simple Two-Way Active Measurement Protocol (STAMP) for Segment Routing Networks
draft-ietf-spring-stamp-srpm-13
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 "Active".
|
|
|---|---|---|---|
| Authors | Rakesh Gandhi , Clarence Filsfils , Daniel Voyer , Mach Chen , Richard "Footer" Foote | ||
| Last updated | 2024-03-04 (Latest revision 2024-02-27) | ||
| Replaces | draft-gandhi-spring-stamp-srpm, draft-gandhi-spring-enhanced-srpm | ||
| 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-13
SPRING Working Group R. Gandhi, Ed.
Internet-Draft C. Filsfils
Intended status: Informational Cisco Systems, Inc.
Expires: 5 September 2024 D. Voyer
Bell Canada
M. Chen
Huawei
R. Foote
Nokia
4 March 2024
Performance Measurement Using Simple Two-Way Active Measurement Protocol
(STAMP) for Segment Routing Networks
draft-ietf-spring-stamp-srpm-13
Abstract
Segment Routing (SR) leverages the source routing paradigm. SR is
applicable 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 and its optional
extensions defined in RFC 8972 and further augmented in RFC 9503.
The procedure described is used for links, end-to-end SR paths
(including SR Policies and SR Flexible Algorithm IGP 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 5 September 2024.
Gandhi, et al. Expires 5 September 2024 [Page 1]
Internet-Draft Using STAMP for Segment Routing March 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
2.3. Reference Topology . . . . . . . . . . . . . . . . . . . 6
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Example STAMP Reference Model . . . . . . . . . . . . . . 8
4. Delay Measurement in SR Networks . . . . . . . . . . . . . . 9
4.1. Session-Sender Test Packet . . . . . . . . . . . . . . . 9
4.1.1. Session-Sender Test Packet for Links . . . . . . . . 10
4.1.2. Session-Sender Test Packet for SR-MPLS Policies . . . 11
4.1.3. Session-Sender Test Packet for SRv6 Policies . . . . 12
4.1.4. Session-Sender Test Packet for SR Flexible Algorithm
IGP Path . . . . . . . . . . . . . . . . . . . . . . 14
4.1.5. Session-Sender Test Packet for P2MP SR Policies . . . 15
4.1.6. Session-Sender Test Packet for Layer-3 Service over SR
Path . . . . . . . . . . . . . . . . . . . . . . . . 15
4.1.7. Session-Sender Test Packet for Layer-2 Service over SR
Path . . . . . . . . . . . . . . . . . . . . . . . . 18
4.2. Session-Reflector Test Packet . . . . . . . . . . . . . . 20
4.2.1. One-Way Measurement Mode . . . . . . . . . . . . . . 21
4.2.2. Two-Way Measurement Mode . . . . . . . . . . . . . . 22
5. Loopback Measurement Mode in SR Networks . . . . . . . . . . 23
5.1. Loopback Measurement Mode STAMP Packet Processing . . . . 24
5.2. Loopback Measurement Mode for Links . . . . . . . . . . . 24
5.3. Loopback Measurement Mode for SR-MPLS Paths . . . . . . . 26
5.3.1. Return SR-MPLS Path . . . . . . . . . . . . . . . . . 26
5.3.2. Return IP/UDP Path . . . . . . . . . . . . . . . . . 27
5.4. Loopback Measurement Mode for SRv6 Paths . . . . . . . . 27
5.4.1. Return SRv6 Path . . . . . . . . . . . . . . . . . . 29
5.4.2. Return IP/UDP Path . . . . . . . . . . . . . . . . . 29
Gandhi, et al. Expires 5 September 2024 [Page 2]
Internet-Draft Using STAMP for Segment Routing March 2024
5.5. Loopback Measurement Mode for Layer-3 Service over SR
Path . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.5.1. Loopback Measurement Mode for Layer-3 Service over
SR-MPLS Path . . . . . . . . . . . . . . . . . . . . 30
5.5.2. Loopback Measurement Mode for Layer-3 Service over SRv6
Path . . . . . . . . . . . . . . . . . . . . . . . . 31
5.6. Loopback Measurement Mode for Layer-2 Service over SR
Path . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.6.1. Loopback Measurement Mode for Layer-2 Service over
SR-MPLS Path . . . . . . . . . . . . . . . . . . . . 32
5.6.2. Loopback Measurement Mode for Layer-2 Service over SRv6
Path . . . . . . . . . . . . . . . . . . . . . . . . 32
6. Loopback Measurement Mode with Timestamp and Forward Function
in SR Networks . . . . . . . . . . . . . . . . . . . . . 33
6.1. Loopback Measurement Mode with Timestamp and Forward
Function for SR-MPLS Paths . . . . . . . . . . . . . . . 34
6.1.1. Timestamp and Forward Network Action Assignment . . . 35
6.1.2. Node Capability for MNA Sub-Stack with Opcode
MNA.TSF . . . . . . . . . . . . . . . . . . . . . . . 35
6.2. Loopback Measurement Mode with Timestamp and Forward
Function for SRv6 Paths . . . . . . . . . . . . . . . . . 36
6.2.1. Timestamp and Forward Endpoint Function Assignment . 38
6.2.2. Node Capability for Timestamp and Forward Endpoint
Function . . . . . . . . . . . . . . . . . . . . . . 38
7. Packet Loss Measurement in SR Networks . . . . . . . . . . . 38
8. Direct Measurement in SR Networks . . . . . . . . . . . . . . 38
9. ECMP Measurement in SR Networks . . . . . . . . . . . . . . . 39
10. STAMP Session State . . . . . . . . . . . . . . . . . . . . . 39
11. Additional STAMP Test Packet Processing Rules . . . . . . . . 40
11.1. TTL . . . . . . . . . . . . . . . . . . . . . . . . . . 40
11.2. IPv6 Hop Limit . . . . . . . . . . . . . . . . . . . . . 40
11.3. Router Alert Option . . . . . . . . . . . . . . . . . . 40
11.4. IPv6 Flow Label . . . . . . . . . . . . . . . . . . . . 40
11.5. UDP Checksum . . . . . . . . . . . . . . . . . . . . . . 41
12. Implementation Status . . . . . . . . . . . . . . . . . . . . 41
13. Security Considerations . . . . . . . . . . . . . . . . . . . 41
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 42
15.1. Normative References . . . . . . . . . . . . . . . . . . 42
15.2. Informative References . . . . . . . . . . . . . . . . . 43
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 46
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47
Gandhi, et al. Expires 5 September 2024 [Page 3]
Internet-Draft Using STAMP for Segment Routing March 2024
1. Introduction
Segment Routing (SR) leverages the source routing paradigm and
greatly simplifies network operations for Software Defined Networks
(SDNs). SR is applicable to both Multiprotocol Label Switching (SR-
MPLS) and IPv6 (SRv6) data planes [RFC8402]. SR takes advantage of
the Equal-Cost Multipaths (ECMPs) between source and transit nodes,
between transit nodes and between transit and destination nodes. SR
Policies as defined in [RFC9256] are used to steer traffic through a
specific, user-defined paths using a stack of Segments. A
comprehensive SR Performance Measurement (PM) toolset is one of the
essential requirements to measure network performance to provide
Service Level Agreements (SLAs).
The Simple Two-Way Active Measurement Protocol (STAMP) provides
capabilities for the measurement of various performance metrics in IP
networks [RFC8762] without the use of a control channel to pre-signal
session parameters. [RFC8972] defines optional extensions, in the
form of TLVs, for STAMP. [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] and its optional extensions
defined in [RFC8972] and further augmented in [RFC9503]. The
procedure described is used for links, end-to-end SR paths [RFC8402]
(including SR Policies [RFC9256] and SR Flexible Algorithm (Flex-
Algo) IGP 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 data plane and return test packets
need to be generated. This limits the scale for number test sessions
and the ability to provide faster measurement interval. This
document enhances the procedure for Performance Measurement using
STAMP to improve the scale for number of sessions and the interval
for measurement of SR paths, for both SR-MPLS and SRv6 data planes by
using timestamp and forward network programming function.
2. Conventions Used in This Document
Gandhi, et al. Expires 5 September 2024 [Page 4]
Internet-Draft Using STAMP for Segment Routing March 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.
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.
Gandhi, et al. Expires 5 September 2024 [Page 5]
Internet-Draft Using STAMP for Segment Routing March 2024
TSF: Timestamp and Forward.
TTL: Time To Live.
VPN: Virtual Private Network.
2.3. Reference Topology
As shown in Figure 1, Reference Topology, the STAMP Session-Sender S1
initiates a STAMP Session-Sender test packet and the STAMP Session-
Reflector R1 transmits a reply STAMP test packet. The reply STAMP
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.
The T1 is a transmit timestamp, and T4 is a receive timestamp added
by node S1. The T2 is a receive timestamp, and T3 is a transmit
timestamp added by node R1.
The nodes S1 and R1 may be connected via a link or an SR path
[RFC8402]. The link may be a physical interface, virtual link, or
Link Aggregation Group (LAG) [IEEE802.1AX], or LAG member. The SR
path may be an SR Policy [RFC9256] on node S1 (called "head-end")
with destination to node R1 (called "tail-end") or SR Flex-Algo IGP
path [RFC9350].
T1 T2
/ \
+-------+ Test Packet +-------+
| | - - - - - - - - - ->| |
| S1 |=====================| R1 |
| |<- - - - - - - - - - | |
+-------+ Reply Test Packet +-------+
\ /
T4 T3
STAMP Session-Sender STAMP Session-Reflector
Figure 1: Reference Topology for One-Way and Two-Way Measurement
Modes
Gandhi, et al. Expires 5 September 2024 [Page 6]
Internet-Draft Using STAMP for Segment Routing March 2024
3. Overview
For performance measurement in SR networks, the STAMP Session-Sender
and Session-Reflector can use the base test packets defined
[RFC8762]. However, the STAMP test packets defined in [RFC8972] are
preferred in SR environment because of the optional extensions. The
STAMP test packets are encapsulated using IP/UDP header and use the
Destination UDP port 862 [RFC8762], by default. In this document,
the STAMP test packets using IP/UDP header are considered for SR
networks, where the STAMP test packets are further encapsulated with
an SR-MPLS or SRv6 header. The STAMP test packets MUST carry the
same IP/SR encapsulation as used by the data packets on the SR path
under measurement.
The STAMP test packets are transmitted in measurement mode one-way,
two-way, loopback, or loopback with timestamp and forward function in
SR networks. Note that one-way and two-way measurement modes are
referred to in [RFC8762] and are further described for SR networks in
this document.
The procedure defined in [RFC8762] is used to measure packet loss
based on the transmission and reception of the STAMP test packets.
The optional STAMP extensions defined in [RFC8972] are used for
direct measurement of packet loss in SR networks. The measurement
modes defined in this document are also applicable to measure packet
loss in SR networks.
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.
Typically, the STAMP test packets are transmitted along an IP path
between a Session-Sender and a Session-Reflector to measure delay and
packet loss along that IP path. Matching forward direction and
return paths for STAMP test packets, even for directly connected
nodes are not guaranteed.
If it is 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, it is achieved by
using the optional STAMP extensions for SR-MPLS and SRv6 networks
specified in [RFC9503]. The STAMP Session-Reflector uses the return
path parameters for the reply test packet from the received Session-
Sender test packet, as described in [RFC9503].
Gandhi, et al. Expires 5 September 2024 [Page 7]
Internet-Draft Using STAMP for Segment Routing March 2024
3.1. Example STAMP Reference Model
An example of a STAMP Reference Model with some of the typical
measurement parameters for STAMP test sessions is shown in Figure 2.
+------------+
| Controller |
+------------+
Performance Measurement Mode / \
Destination UDP Port / \ Destination UDP Port
Authentication Mode / \ Authentication Mode
Keychain / \ Keychain
Timestamp Format / \ Timestamp Format
Protocol Mode / \ Protocol Mode
Metric Type / \
v v
+-------+ +-------+
| | | |
| S1 |==========| R1 |
| | | |
+-------+ +-------+
STAMP Session-Sender STAMP Session-Reflector
Figure 2: Example STAMP Reference Model
A Destination UDP port number MUST be selected for STAMP function as
described in [RFC8762]. The same Destination UDP port can be used
for STAMP test sessions for links, end-to-end SR paths, and L3 and L2
services in SR networks. In this case, the Destination UDP port does
not distinguish between the link, end-to-end SR path, or L3 and L2
service STAMP test sessions. The Source UDP port is chosen by the
Session-Sender. The same or different UDP Source port can be used
for different STAMP test sessions and for STAMP test sessions for
links, end-to-end SR paths, and L3 and L2 services in SR networks.
Examples of the Timestamp Format is Precision Time Protocol 64-bit
truncated (PTPv2) [IEEE1588] and Network Time Protocol (NTP). By
default, the Session-Reflector replies in kind to the timestamp
format received in the received 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 Performance Measurement Mode are one-way, two-way,
loopback, and loopback with timestamp and forward function as
described in this document for SR networks.
Gandhi, et al. Expires 5 September 2024 [Page 8]
Internet-Draft Using STAMP for Segment Routing March 2024
Examples of Delay Metric Type are one-way delay, round-trip delay,
near-end (forward direction) and far-end (backward direction) delay
as defined in [RFC8762], and loopback delay as defined in this
document.
Examples of Packet Loss Metric Type are round-trip, near-end (forward
direction) and far-end (backward direction) packet loss as defined in
[RFC8762].
When using the authentication mode for the STAMP test sessions, the
matching Authentication Type (e.g., HMAC-SHA-256) and Keychain MUST
be configured on STAMP Session-Sender and STAMP Session-Reflector
[RFC8762].
In case of One-Way Protocol Mode (default protocol mode is Two-Way),
Session-Reflector does not transmit reply test packet.
The controller shown in Figure 2 is used for provisioning STAMP test
sessions on Session-Sender and Session-Reflector. Note that the YANG
data model defined for STAMP in [I-D.ietf-ippm-stamp-yang] can be
used to provision the Session-Sender and Session-Reflector and also
for streaming telemetry of the operational data.
4. Delay Measurement in SR Networks
4.1. Session-Sender Test Packet
The content of an example Session-Sender test packet using an IP and
UDP header [RFC0768] is shown in Figure 3. The payload contains the
Session-Sender test packet defined in Section 3 of [RFC8972] as
transmitted in an IP network. Note that [RFC8972] updates the
Session-Sender test packet defined in [RFC8762] with optional STAMP
Session Identifier (SSID). The SR encapsulation of the STAMP test
packet is further described later in this document.
Gandhi, et al. Expires 5 September 2024 [Page 9]
Internet-Draft Using STAMP for Segment Routing March 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 Figure 1 and Figure 3 .
. .
+---------------------------------------------------------------+
Figure 3: Example Session-Sender Test Packet
4.1.1. 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 addresses [RFC7404] can
be used in the IPv6 header. An SR encapsulation (e.g., containing
local adjacency SID of the link) can also be added for transmitting
the Session-Sender test packets for links.
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 for transmitting STAMP packets.
Note that the Session-Sender test packet is further encapsulated with
a Layer-2 header containing Session-Reflector MAC address as the
Destination MAC address and 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] is used to identify the member link.
Gandhi, et al. Expires 5 September 2024 [Page 10]
Internet-Draft Using STAMP for Segment Routing March 2024
4.1.2. Session-Sender Test Packet for SR-MPLS Policies
An SR-MPLS Policy Candidate-Path can contain one or more Segment
Lists. Each SR-MPLS Segment List contains a list of 32-bit Label
Stack Entry (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. A Session-Sender test packet MUST be transmitted
using each Segment List of the SR-MPLS Policy Candidate-Path for
delay measurement.
The content of an example Session-Sender test packet for an SR-MPLS
Policy using the same SR-MPLS encapsulation as the data traffic 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Segment(1) | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Segment(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.
The Segment List can be empty in the case of a single-hop SR path
with Implicit NULL label. The Session-Reflector may need to receive
Session-Sender test packets with no MPLS header, for example, when
using Penultimate Hop Popping (PHP). In both these cases, the
Destination Address in IP header ensures the test packet reaches the
Session-Reflector.
Gandhi, et al. Expires 5 September 2024 [Page 11]
Internet-Draft Using STAMP for Segment Routing March 2024
In the case of SR-MPLS Policy with Color-Only Destination Steering,
with endpoint as unspecified address (the null endpoint is 0.0.0.0
for IPv4 or :: for IPv6 (all bits set to the 0 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
endpoint of the SR Policy (for example, by adding the Prefix SID of
the SR-MPLS Policy endpoint in the Segment List if required).
The Path Segment Identifier (PSID) [RFC9545] of an SR-MPLS Policy
(either for Segment List or for Candidate-Path) can be added in the
Segment List of the STAMP test packets as shown in Figure 4, and can
be used for direct measurement as described in Section 8, "Direct
Measurement in SR Networks".
4.1.3. Session-Sender Test Packet for SRv6 Policies
An SRv6 Policy Candidate-Path can contain one or more Segment Lists.
Each Segment List can contain a number of SRv6 SIDs as defined in
[RFC8986]. A Session-Sender test packet MUST be transmitted using
each Segment List of the SRv6 Policy Candidate-Path for delay
measurement. A packet can contain an outer IPv6 header and SRv6
Segment Routing Header (SRH) carrying a Segment List as described in
[RFC8754].
The content of an example Session-Sender test packet for an SRv6
Policy using the same IPv6/SRH encapsulation as the data traffic is
shown in Figure 5.
Gandhi, et al. Expires 5 September 2024 [Page 12]
Internet-Draft Using STAMP for Segment Routing March 2024
+---------------------------------------------------------------+
| IP Header |
. Source IP Address = Session-Sender IPv6 Address .
. Destination IP Address = Segment List[Segments Left] .
. Next-Header = 43, Routing Type = SRH (4) .
. .
+---------------------------------------------------------------+
| SRH as specified in RFC 8754 |
. <PSID (optional), Segment List> .
. 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 Figure 1 and Figure 3 .
. .
+---------------------------------------------------------------+
Example 1: Without Using Inner IPv6 Header
+---------------------------------------------------------------+
| IP Header |
. Source IP Address = Session-Sender IPv6 Address .
. Destination IP Address = Session-Reflector IPv6 Address | .
. Segment List[Segments Left] .
. Next-Header = 43, Routing Type = SRH (4) .
. .
+---------------------------------------------------------------+
| SRH as specified in RFC 8754 |
. <PSID (optional), Segment List> .
. Next-Header = 43 (IPv6) .
. .
+---------------------------------------------------------------+
| Test Packet as shown in Figure 3 |
+---------------------------------------------------------------+
Example 2: Using Inner IPv6 Header
Figure 5: Example Session-Sender Test Packet for SRv6 Path
The head-end node address of the SRv6 Policy MUST be used as the
Source Address in the IPv6 header of the Session-Sender test packet.
Gandhi, et al. Expires 5 September 2024 [Page 13]
Internet-Draft Using STAMP for Segment Routing March 2024
The Segment List of the SRv6 Policy Candidate-Path can be empty. In
this case, the endpoint address of the SRv6 Policy is used as the
Destination Address in the IPv6 header of the Session-Sender test
packet.
Note that the Session-Sender test packets can be transmitted with or
without adding the inner IP header with Source Address of the
Session-Sender and Destination Address of the Session-Reflector after
the IPv6/SRH. In case of Penultimate Segment Popping (PSP), where
IPv6/SRH encapsulation is removed on the penultimate node, Inner IP
header MUST be added for the test packets to reach the Session-
Reflector node. When inner IP header is not added, the Session-
Sender MUST ensure that the Session-Sender test packets using the
Segment List reach the Session-Reflector (for example, by adding the
Prefix SID or IPv6 address of the SR Policy endpoint in the Segment
List if required).
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] MUST be used to process the IPv6/
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 in the Segment List
of the STAMP test packets as shown in Figure 5 and can be used for
direct measurement as described in Section 8, "Direct Measurement in
SR Networks".
4.1.4. Session-Sender Test Packet for SR Flexible Algorithm IGP Path
The delay measurement procedure for end-to-end SR paths is also
applicable to SR-MPLS and SRv6 Flex-Algo IGP paths.
Flex-Algo in IGP in SR networks [RFC9350] has Prefix SIDs advertised
by the nodes for each Flex-Algo. The STAMP test packets for delay
measurement MUST be transmitted on the Flex-Algo path using the same
SR encapsulation as the data traffic under measurement.
For delay measurement of an SR-MPLS Flex-Algo IGP path, the Session-
Sender test packets MUST carry the Flex-Algo Prefix SID of the
Session-Reflector for that Flex-Algo IGP path in the MPLS header.
Gandhi, et al. Expires 5 September 2024 [Page 14]
Internet-Draft Using STAMP for Segment Routing March 2024
For delay measurement of an SRv6 Flex-Algo IGP path, the Session-
Sender test packets MUST carry the Flex-Algo Prefix SIDs of the
Session-Sender and Session-Reflector for that Flex-Algo IGP path as
the Source Address and Destination Address in the IPv6 header,
respectively.
4.1.5. Session-Sender Test Packet for P2MP SR Policies
The delay measurement procedure for end-to-end SR-MPLS and SRv6
Policies is equally applicable to the P2MP SR-MPLS and SRv6 Policies.
The Point-to-Multipoint (P2MP) SR path that originates from a root
node terminates on multiple destinations called leaf nodes (e.g.,
P2MP SR Policy [I-D.ietf-pim-sr-p2mp-policy] Candidate-Path). The
Session-Sender root node MUST transmit the Session-Sender test
packets using the Segment Lists and that may contain replication SIDs
[RFC9524] for delay measurement.
The Source Address in the Session-Sender test packets MUST be set to
the address of the root-node of the P2MP SR-MPLS and SRv6 Policy.
For P2MP SR-MPLS path, the Destination Address in the Session-Sender
test packets MUST be set to a loopback address from the range 127/8
for IPv4, or the loopback address ::1/128 for IPv6. The SR
encapsulation MUST ensure the Session-Sender test packets reach the
leaf nodes of the P2MP SR Policy.
The Session-Reflector on the leaf node MUST add its address as Source
Address in the Session-Reflector test packet. The P2MP root node
measures the delay and packet loss for each leaf node independently
using the Source Address of the leaf node from the received Session-
Reflector reply test packets.
The [I-D.mirsky-ippm-asymmetrical-pkts] defines extensions for using
STAMP for performance measurement in multicast environment. Those
extensions also apply to the performance measurement for P2MP SR
Policies.
4.1.6. Session-Sender Test Packet for Layer-3 Service over SR Path
The delay measurement procedure defined in this document for end-to-
end SR path is also applicable to L3 services in an SR network for
both SR-MPLS and SRv6 data planes.
Gandhi, et al. Expires 5 September 2024 [Page 15]
Internet-Draft Using STAMP for Segment Routing March 2024
4.1.6.1. Session-Sender Test Packet for Layer-3 Service over SR-MPLS
Path
For delay measurement of end-to-end L3 service over SR-MPLS path, the
same SR-MPLS label stack as the data packets of the L3 service
including the L3VPN SR-MPLS 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Segment(1) | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| L3VPN Segment | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Test Packet as shown in Figure 3 |
. Destination IP Address in L3VPN table .
. .
+---------------------------------------------------------------+
Figure 6: Example Session-Sender Test Packet for L3 Service over
SR-MPLS Path
An IP header (as shown in Figure 3) MUST be added in the Session-
Sender test packets after the SR-MPLS encapsulation. The Destination
Address of the Session-Reflector added in the IP header MUST be
reachable via the IP table lookup associated with the L3VPN SR-MPLS
label added.
4.1.6.2. Session-Sender Test Packet for Layer-3 Service over SRv6 Path
For delay measurement of end-to-end L3 service over SRv6 path, the
same IPv6/SRH encapsulation as the data packets of 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, defined in [RFC8986]) is used to transmit Session-Sender
test packets as shown in Figure 7.
Gandhi, et al. Expires 5 September 2024 [Page 16]
Internet-Draft Using STAMP for Segment Routing March 2024
+---------------------------------------------------------------+
| IP Header |
. Source IP Address = Session-Sender IPv6 Address .
. Destination IP Address = Segment List[Segments Left] .
. Next-Header = 43, Routing Type = SRH (4) .
. .
+---------------------------------------------------------------+
| SRH as specified in RFC 8754 |
. <Segment List including End.DT4/DT6/DT46 SID> .
. 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 Figure 1 and Figure 3 .
. .
+---------------------------------------------------------------+
Example 1: Without Using Inner IP Header
+---------------------------------------------------------------+
| IP Header |
. Source IP Address = Session-Sender IPv6 Address .
. Destination IP Address = Segment List[Segments Left] .
. Next-Header = 43, Routing Type = SRH (4) .
. .
+---------------------------------------------------------------+
| SRH as specified in RFC 8754 |
. <Segment List including End.DT4/DT6/DT46 SID> .
. Next-Header = 43 (IPv6) .
. .
+---------------------------------------------------------------+
| IP Header |
. Source IP Address = Session-Sender IPv4 or IPv6 Address .
. Destination IP Address=Session-Reflector IPv4 or IPv6 Address.
. in L3VPN table .
. IPv4 Protocol or IPv6 Next-header = UDP (17) .
. .
+---------------------------------------------------------------+
| UDP Header |
. Source Port = Chosen by Session-Sender .
. Destination Port = User-configured Destination Port | 862 .
. .
+---------------------------------------------------------------+
Gandhi, et al. Expires 5 September 2024 [Page 17]
Internet-Draft Using STAMP for Segment Routing March 2024
| Payload = Test Packet as specified in Section 3 of RFC 8972 |
. in Figure 1 and Figure 3 .
. .
+---------------------------------------------------------------+
Example 2: Using Inner IP Header
Figure 7: Example Session-Sender Test Packet for L3 Service over
SRv6 Path
An optional inner IP header MAY be added in the Session-Sender test
packets after the IPv6/SRH encapsulation. The Destination Address of
the Session-Reflector added in the inner IP header MUST be reachable
via the IPv4 or IPv6 table lookup associated with the L3VPN SRv6 SID
added.
4.1.7. Session-Sender Test Packet for Layer-2 Service over SR Path
The delay measurement procedure defined in this document for end-to-
end SR path is also applicable to L2 services in an SR network for
both SR-MPLS and SRv6 data planes.
4.1.7.1. Session-Sender Test Packet for Layer-2 Service over SR-MPLS
Path
For delay measurement of end-to-end L2 service over SR-MPLS path, the
same SR-MPLS label stack as the data packets of the L2 service
including the L2VPN SR-MPLS label (advertised by the Session-
Reflector) is used to transmit Session-Sender test packets as shown
in Figure 8.
The L2VPN SR-MPLS label is added with a TTL value of 1 in order to
punt the Session-Sender test packet from data plane to CPU or slow
path on Session-Reflector for STAMP processing.
Gandhi, et al. Expires 5 September 2024 [Page 18]
Internet-Draft Using STAMP for Segment Routing March 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Segment(1) | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| L2VPN Segment | TC |1| TTL=1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Test Packet as shown in Figure 3 |
. .
+---------------------------------------------------------------+
Figure 8: Example Session-Sender Test Packet for L2 Service over
SR-MPLS Path
An IP header as shown in Figure 3 MUST be added in the Session-Sender
test packets after the MPLS header. It contains the Source Address
of the Session-Sender and Destination Address of the Session-
Reflector.
4.1.7.2. Session-Sender Test Packet for Layer-2 Service over SRv6 Path
For delay measurement of end-to-end L2 service over SRv6 path, the
same IPv6/SRH encapsulation as the data packets of 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.
Gandhi, et al. Expires 5 September 2024 [Page 19]
Internet-Draft Using STAMP for Segment Routing March 2024
+---------------------------------------------------------------+
| IP Header |
. Source IP Address = Session-Sender IPv6 Address .
. Destination IP Address = Segment List[Segments Left] .
. Next-Header = 43, Routing Type = SRH (4) .
. .
+---------------------------------------------------------------+
| SRH as specified in RFC 8754 |
. <Segment List including End.DT2U SID> .
. 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 Figure 1 and Figure 3 .
. .
+---------------------------------------------------------------+
Figure 9: Example Session-Sender Test Packet for L2 Service over
SRv6 Path
4.2. Session-Reflector Test Packet
The Session-Reflector decapsulates the outer IP header (if present)
and the SR header (SR-MPLS header or IPv6/SRH if present) from the
received Session-Sender test packets. The Session-Reflector reply
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 5 September 2024 [Page 20]
Internet-Draft Using STAMP for Segment Routing March 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 Figure 2 and Figure 4 .
. .
+---------------------------------------------------------------+
Figure 10: Example Session-Reflector Test Packet
The payload contains the Session-Reflector test packet defined in
Section 3 of [RFC8972].
4.2.1. One-Way Measurement Mode
In one-way measurement mode, a reply test packet with the contents as
shown in Figure 10 is transmitted by the Session-Reflector, for
links, end-to-end SR paths and L3 and L2 services in SR networks.
The Session-Reflector reply test packet can be transmitted in the
reverse direction on the same path as the forward direction or a
different path than the forward direction to the Session-Sender.
In this mode, as per Reference Topology, all timestamps T1, T2, T3,
and T4 are collected by the STAMP test packets. However, only
timestamps T1 and T2 are used to measure one-way delay as (T2 - T1).
Note that the delay value (T2 - T1) is referred to as near-end
(forward direction) one-way delay and the delay value (T4 - T3) is
referred to as far-end (backward direction) one-way delay. The one-
way measurement mode requires the clocks on the Session-Sender and
Session-Reflector to be synchronized.
Gandhi, et al. Expires 5 September 2024 [Page 21]
Internet-Draft Using STAMP for Segment Routing March 2024
4.2.1.1. One-Way Protocol Mode
In one-way protocol mode, Session-Reflector does not generate and
transmit reply test packet upon receiving Session-Sender test packet.
The Session-Sender can request in the test packet to the Session-
Reflector to not transmit the reply test packet using the "No Reply
Requested" flag in the Control Code Sub-TLV in the Return Path TLV
defined in [RFC9503]. Alternatively, Session-Reflector can be
provisioned with protocol mode as one-way or using a different
destination UDP port. In this case, only timestamps T1 and T2 are
collected by the STAMP Session-Sender test packets and one-way delay
value (T2 - T1) is measured by the Session-Reflector.
4.2.2. Two-Way Measurement Mode
In two-way measurement mode, a reply test packet as shown in
Figure 10 SHOULD be transmitted by the Session-Reflector on the same
path in the reverse direction as the forward direction, e.g., on the
same link in the reverse direction or on the reverse SR path
associated with the forward SR path [I-D.ietf-pce-sr-bidir-path], or
reverse SR Flex-Algo IGP path associated with the forward SR Flex-
Algo IGP path, or over same L3 and L2 service in the reverse
direction.
In two-way measurement mode for links, the Session-Sender may request
in the test packet to the Session-Reflector to transmit the reply
test packet back on the same link in the reverse direction, for
example, in an ECMP environment. 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.
In two-way measurement mode for end-to-end SR paths, the Session-
Sender may request in the test packet to the Session-Reflector to
transmit the reply test packet back on a specific return SR path, for
example, in an ECMP environment. It can use a Segment List sub-TLV
in the Return Path TLV defined in [RFC9503] for this request.
In two-way measurement mode for SR Flex-Algo IGP paths, the Session-
Sender may request in the test packet to the Session-Reflector to
transmit the reply test packet back on the same SR Flex-Algo IGP
paths in the reverse direction using Segment List sub-TLV in the
Return Path TLV defined in [RFC9503].
Gandhi, et al. Expires 5 September 2024 [Page 22]
Internet-Draft Using STAMP for Segment Routing March 2024
In two-way measurement mode for L3 services, the Session-Reflector
can derive the L3 service in the reverse direction using the L3VPN
SID received in the Session-Sender test packets to transmit the
Session-Reflector test packets. 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.
In two-way measurement mode for L2 services, the Session-Reflector
can derive the L2 service in the reverse direction using the L2VPN
SID received in the Session-Sender test packets to transmit the
Session-Reflector test packets.
In this mode, as per Reference Topology, all timestamps T1, T2, T3,
and T4 are collected by the STAMP test packets. All four timestamps
are used to measure round-trip delay as ((T4 - T1) - (T3 - T2)).
5. Loopback Measurement Mode in SR Networks
The Session-Sender test packets are transmitted in loopback
measurement mode to measure loopback delay of a bidirectional
circular path. In this mode, the received Session-Sender test
packets MUST NOT be punted out of the fast path in data plane (i.e.,
to slow path or control-plane) at the Session-Reflector. In other
words, the Session-Reflector does not process them and generate
Session-Reflector test packets. This is a new measurement mode, not
defined by the STAMP process in [RFC8762].
T1
/
+-------+ Test Packet +-------+
| | - - - - - - - - - - | |
| S1 |====================|| R1 |
| |<- - - - - - - - - - | |
+-------+ Return Test Packet +-------+
\ Loopback
T4
STAMP Session-Sender
Figure 11: Reference Topology for Loopback Measurement Mode
In this mode, as shown in Figure 11, Reference Topology for Loopback
Measurement Mode, the Session-Sender test packet received back at the
Session-Sender retrieves the timestamp T1 from the test packet and
collects the receive timestamp T4 locally. Both these timestamps are
used to measure the loopback delay as (T4 - T1). The loopback delay
includes the STAMP test packet processing delay on the Session-
Gandhi, et al. Expires 5 September 2024 [Page 23]
Internet-Draft Using STAMP for Segment Routing March 2024
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.
5.1. Loopback Measurement Mode STAMP Packet Processing
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 UDP Destination port 862 which is used by the STAMP Session-
Reflector). The same UDP port can be used as the Source UDP port in
the Session-Sender test packet.
The Session-Reflector does not support the STAMP process, hence 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 defined in [RFC8762].
The Session-Sender can use the STAMP Session ID (SSID) field in the
received STAMP test packet or local configuration to identify its
STAMP test session that uses the loopback measurement mode. In this
mode, 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.
5.2. Loopback Measurement Mode for Links
In loopback measurement mode for links, an inner IP header for the
return path is added in the Session-Sender test packets as shown in
Figure 12 and it MUST set the Destination Address equal to the
Session-Sender address.
Gandhi, et al. Expires 5 September 2024 [Page 24]
Internet-Draft Using STAMP for Segment Routing March 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 Figure 1 and Figure 3 .
. .
+---------------------------------------------------------------+
Figure 12: Example Session-Sender Return Test Packet in Loopback
Measurement Mode
The Session-Sender test packets in loopback measurement mode may be
transmitted with a Layer-2 header for the forward path as shown in
Figure 13, containing Session-Reflector MAC address as the
Destination Address and Session-Sender MAC address as the Source MAC
address of Ethernet links. An SR encapsulation (e.g., containing
adjacency SID of the link) can also be added for the forward path
after the Layer-2 header.
+---------------------------------------------------------------+
| L2 MAC Header (Forward Path) |
. Source Address = Session-Sender MAC Address .
. Destination Address = Session-Reflector MAC Address .
. Ether-Type = 0x0800 (IPv4) Or 0x86DD (IPv6) .
. .
+---------------------------------------------------------------+
| Test Packet as shown in Figure 12 (Return Path) |
. .
+---------------------------------------------------------------+
Figure 13: Example Session-Sender Test Packet in Loopback
Measurement Mode for Ethernet Link
Gandhi, et al. Expires 5 September 2024 [Page 25]
Internet-Draft Using STAMP for Segment Routing March 2024
5.3. Loopback Measurement Mode for SR-MPLS Paths
An SR-MPLS path uses an MPLS header for carrying a Segment List in
MPLS label stack. In the case of loopback measurement mode for SR-
MPLS paths, the Session-Sender test packet can either carry the
Segment List of the forward SR-MPLS path only or both the forward and
the return SR-MPLS paths in MPLS header as shown in Figure 14.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Segment(1) | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Segment(n) | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PSID (optional) | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Test Packet as shown in Figure 12 (Return Path)|
. .
+---------------------------------------------------------------+
Figure 14: Example Session-Sender Test Packet in Loopback
Measurement Mode for SR-MPLS Path
In the case of 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 of the
SR-MPLS Policy endpoint in the Segment List of the forward path if
required).
5.3.1. Return SR-MPLS Path
To receive the return Session-Sender test packet on a specific SR-
MPLS path in an ECMP environment, the SR-MPLS label stack needs to
carry the specific return SR-MPLS path, in addition to the forward
direction SR-MPLS path. For example, it can carry the corresponding
SR-MPLS label stack of the Segment List of the reverse SR-MPLS Policy
Candidate-Path [I-D.ietf-pce-sr-bidir-path] or the Binding SID of the
reverse SR-MPLS Policy or the SR-MPLS Prefix Segment Identifier of
the Session-Sender. For SR-MPLS Flex-Algo IGP paths, it MUST carry
the matching SR-MPLS Flex-Algo Prefix SID label of the Session-
Sender.
Gandhi, et al. Expires 5 September 2024 [Page 26]
Internet-Draft Using STAMP for Segment Routing March 2024
The IP header of the Session-Sender test packets MUST set the
Destination Address equal to the Session-Sender address as shown in
Figure 12.
In this case, the optional PSID added in the Session-Sender test
packet is allocated by the Session-Sender.
5.3.2. Return IP/UDP Path
In the case of loopback measurement mode for SR-MPLS paths, the MPLS
header can carry the SR-MPLS label stack of the forward SR path only.
The IP header for the return path of the Session-Sender test packets
MUST set the Destination Address equal to the Session-Sender address
as shown in Figure 12 to forward the packet to the Session-Sender.
The Session-Reflector decapsulates the MPLS header and forwards the
packet using the IP header for the return path.
In this case, the optional PSID added in the Session-Sender test
packet is allocated by the Session-Reflector.
5.4. Loopback Measurement Mode for SRv6 Paths
An SRv6 path uses an IPv6 header and SRv6 Segment Routing Header
(SRH) for carrying a Segment List as described in [RFC8754]. In the
case of loopback measurement mode for SRv6 paths, the Session-Sender
test packet can either carry the Segment List of the forward SRv6
path only or both the forward and the return SRv6 paths in IPv6/SRH
as shown in Figure 15.
Gandhi, et al. Expires 5 September 2024 [Page 27]
Internet-Draft Using STAMP for Segment Routing March 2024
+---------------------------------------------------------------+
| IP Header |
. Source IP Address = Session-Sender IPv6 Address .
. Destination IP Address = Segment List[Segments Left] .
. Next-Header = 43, Routing Type = SRH (4) .
. .
+---------------------------------------------------------------+
| SRH as specified in RFC 8754 |
. <PSID (optional), Segment List> .
. <Segment List for Return Path> .
. 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 Figure 1 and Figure 3 .
. .
+---------------------------------------------------------------+
Example 1: Using SRv6 Return Path
+---------------------------------------------------------------+
| IP Header |
. Source IP Address = Session-Sender IPv6 Address .
. Destination IP Address = Session-Reflector IPv6 Address | .
. Segment List[Segments Left] .
. Next-Header = 43, Routing Type = SRH (4) .
. .
+---------------------------------------------------------------+
| SRH as specified in RFC 8754 |
. <PSID (optional), Segment List> .
. Next-Header = 43 (IPv6) .
. .
+---------------------------------------------------------------+
| Test Packet as shown in Figure 12 (Return Path) |
. .
+---------------------------------------------------------------+
Example 2: Using IP/UDP Return Path
Figure 15: Example Session-Sender Test Packet in Loopback
Measurement Mode for SRv6 Path
Gandhi, et al. Expires 5 September 2024 [Page 28]
Internet-Draft Using STAMP for Segment Routing March 2024
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 if required).
5.4.1. Return SRv6 Path
To receive the return Session-Sender test packet on a specific SRv6
path in an ECMP environment, the SRv6 Segment List needs to carry the
specific return SRv6 path, in addition to the forward direction SRv6
path. For example, it can carry the corresponding Segment List of
the reverse SRv6 Policy Candidate-Path [I-D.ietf-pce-sr-bidir-path]
or the Binding SID of the reverse SRv6 Policy or the SRv6 Prefix
Segment Identifier of the Session-Sender. For SRv6 Flex-Algo IGP
paths, it MUST carry the matching SRv6 Flex-Algo Prefix SID of the
Session-Sender.
An inner IP header MAY be added in the Session-Sender test packet and
that has the Destination Address equal to the Session-Sender address
as shown in Figure 12.
In this case, the optional PSID added in the Session-Sender test
packet is allocated by the Session-Sender.
5.4.2. Return IP/UDP Path
In the case of loopback measurement mode for SRv6 paths, the Session-
Sender test packet can contain the Segment List of the forward SRv6
path only.
An inner IP header for return path MUST be added in the Session-
Sender test packets that has the Destination Address equal to the
Session-Sender address as shown in Figure 12 to forward the packet to
the Session-Sender.
The Session-Reflector decapsulates the outer IPv6/SRH headers and
forwards the packet using the inner IP header for the return path.
In this case, the optional PSID added in the Session-Sender test
packet is allocated by the Session-Reflector.
5.5. Loopback Measurement Mode for Layer-3 Service over SR Path
The loopback measurement mode is also applicable to L3 services in SR
networks for both SR-MPLS and SRv6 data planes.
Gandhi, et al. Expires 5 September 2024 [Page 29]
Internet-Draft Using STAMP for Segment Routing March 2024
It is desired that the STAMP test packets traverse the same path in
the forward and reverse direction of the L3 service in loopback
measurement mode.
5.5.1. Loopback Measurement Mode for Layer-3 Service over SR-MPLS Path
In loopback measurement mode for L3 service over SR-MPLS path, the
same SR-MPLS label stack as the data packets of the L3 service
including the L3VPN SR-MPLS label (advertised by the Session-
Reflector) is used to transmit 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Segment(1) | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| L3VPN Segment | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Test Packet as shown in Figure 12 (Return Path) |
. Destination IP Address in L3VPN table .
. .
+---------------------------------------------------------------+
Figure 16: Example Session-Sender Test Packet in Loopback
Measurement Mode for L3 Service over SR-MPLS Path
An IP header for return path MUST be added in the Session-Sender test
packets that has the Destination Address equal to the Session-Sender
address as shown in Figure 12 to forward the packet to the Session-
Sender. In this case, the Destination Address added in the IP header
for the return path MUST be reachable via the IP table lookup
associated with the L3VPN SR-MPLS label added.
The Session-Reflector decapsulates the MPLS header and forwards the
packet using the IP header for the return path (after adding SR-MPLS
encapsulation for the reverse direction L3 service).
Gandhi, et al. Expires 5 September 2024 [Page 30]
Internet-Draft Using STAMP for Segment Routing March 2024
5.5.2. Loopback Measurement Mode for Layer-3 Service over SRv6 Path
In loopback measurement mode for L3 service over SRv6 path, the same
IPv6/SRH encapsulation as the data packets of the L3 service
including the L3VPN SRv6 SID instantiated on the Session-Reflector
(for example, End.DT6 SID instance, End.DT4 SID instance, etc.
defined in [RFC8986]) is used to transmit Session-Sender test packets
as shown in Figure 17.
+---------------------------------------------------------------+
| IP Header |
. Source IP Address = Session-Sender IPv6 Address .
. Destination IP Address = Segment List[Segments Left] .
. Next-Header = 43, Routing Type = SRH (4) .
. .
+---------------------------------------------------------------+
| SRH as specified in RFC 8754 |
. <Segment List including End.DT4/DT6/DT46 SID> .
. Next-Header = 43 (IPv6) .
. .
+---------------------------------------------------------------+
| Test Packet as shown in Figure 12 (Return Path) |
. Destination IP Address in L3VPN table .
. .
+---------------------------------------------------------------+
Figure 17: Example Session-Sender Test Packet in Loopback
Measurement Mode for L3 Service over SRv6 Path
An inner IP header for return path MUST be added in the Session-
Sender test packets that has the Destination Address equal to the
Session-Sender address as shown in Figure 12 to forward the packet to
the Session-Sender. 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 added.
The Session-Reflector decapsulates the outer IPv6/SRH and forwards
the packet using the inner IP header for the return path (after
adding IPv6/SRv6 encapsulation for the reverse direction L3 service).
5.6. Loopback Measurement Mode for Layer-2 Service over SR Path
The loopback measurement mode is also applicable to L2 services in an
SR network for both SR-MPLS and SRv6 data planes.
As L2 service uses co-routed bidirectional connection, it is desired
that the STAMP test packets traverse the same path in the forward and
reverse direction of the L2 service in loopback measurement mode.
Gandhi, et al. Expires 5 September 2024 [Page 31]
Internet-Draft Using STAMP for Segment Routing March 2024
5.6.1. Loopback Measurement Mode for Layer-2 Service over SR-MPLS Path
In loopback measurement mode for L2 service over SR-MPLS path, the
same SR-MPLS label stack (except the L2VPN SR-MPLS label advertised
by the Session-Reflector) as the data packets of the L2 service in
the forward path and the same SR-MPLS label stack and the L2VPN SR-
MPLS label (advertised by the Session-Sender) for the return path of
the L2 service is used to transmit Session-Sender test packets as
shown in Figure 18.
The L2VPN SR-MPLS label is added with a TTL value of 1 in order to
punt the Session-Sender test packet from data plane to CPU or slow
path on Session-Sender for STAMP processing.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Segment(1) | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| L2VPN Segment (Reverse Direction) | TC |1| TTL=1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Test Packet as shown in Figure 12 (Return Path) |
. .
+---------------------------------------------------------------+
Figure 18: Example Session-Sender Test Packet in Loopback
Measurement Mode for L2 Service over SR-MPLS Path
An IP header for return path MUST be added in the Session-Sender test
packets that has the Destination Address equal to the Session-Sender
address as shown in Figure 12.
5.6.2. Loopback Measurement Mode for Layer-2 Service over SRv6 Path
In loopback measurement mode for L2 service over SRv6 path, the same
IPv6/SRH encapsulation (except the L2VPN SRv6 SID instantiated by the
Session-Reflector) as the data packets of the L2 service in the
forward path and the same IPv6/SRH encapsulation and the L2VPN SRv6
SID instantiated on the Session-Sender (for example, End.DT2U SID
instance defined in [RFC8986]) for the return path of the L2 service
is used to transmit the Session-Sender test packets as shown in
Figure 19.
Gandhi, et al. Expires 5 September 2024 [Page 32]
Internet-Draft Using STAMP for Segment Routing March 2024
+---------------------------------------------------------------+
| IP Header |
. Source IP Address = Session-Sender IPv6 Address .
. Destination IP Address = Segment List[Segments Left] .
. Next-Header = 43, Routing Type = SRH (4) .
. .
+---------------------------------------------------------------+
| SRH as specified in RFC 8754 |
. <Segment List including End.DT2U SID (Reverse Direction)> .
. 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 Figure 1 and Figure 3 .
. .
+---------------------------------------------------------------+
Figure 19: Example Session-Sender Test Packet in Loopback Mode
for L2 Service over SRv6 Path
6. Loopback Measurement Mode with Timestamp and Forward Function in SR
Networks
This document defines a new STAMP measurement mode, called "loopback
measurement mode with timestamp and forward" that uses network
programming function. In this mode, the timestamps T1, T2, and T4,
all in data plane, are collected by the Session-Sender test packet as
shown in Figure 20. The network programming function is used to
optimize the "operations of punt test packet and generate return test
packet" on the Session-Reflector, as timestamping is implemented in
fast path in data plane. This helps to achieve higher number of
STAMP test session scale and faster measurement interval.
The Session-Sender adds 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 fast
path in data plane without punting the test packet (e.g., to slow
path or control-plane). The network programming function carried by
the test packet enables the Session-Reflector to add the receive
timestamp (T2) at the specific offset in the payload of the test
packet.
Gandhi, et al. Expires 5 September 2024 [Page 33]
Internet-Draft Using STAMP for Segment Routing March 2024
T1 T2
/ \
+-------+ Test Packet +-------+
| | - - - - - - - - - - - | |
| S1 |======================|| R1 |
| |<- - - - - - - - - - - | |
+-------+ Return Test Packet +-------+
\ Loopback
T4
STAMP Session-Sender STAMP Session-Reflector
(Timestamp,
and Forward)
Figure 20: Reference Topology for Loopback Measurement Mode with
Timestamp and Forward Function
For an end-to-end SR path including SR Policy, STAMP Session-Sender
test packets are transmitted in loopback measurement mode with
timestamp and forward function as described in the following sub-
sections.
6.1. Loopback Measurement Mode with Timestamp and Forward Function for
SR-MPLS Paths
The MPLS Network Action (MNA) Sub-Stack defined in
[I-D.ietf-mpls-mna-hdr] is used for SR-MPLS data plane for "timestamp
and forward" network programming function for the 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 Timestamp and Forward network action.
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 21, to collect "Receive Timestamp" field in the payload of the
test packet. The Ingress-to-Egress (I2E), Hop-By-Hop (HBH), Select
scope (IHS) is set to "I2E" when return path is IP/UDP. The Network
Action Sub-Stack Length (NASL) is set to 0 when there is no Label
Stack Entry (LSE) after the MNA.TSF Opcode in the MNA Sub-Stack. The
U flag is set to skip the network action and forward the packet (and
not drop the packet).
The Label Stack for the return SR-MPLS path can be added after the
MNA Sub-Stack to receive the return test packet on a specific path.
The Ingress-to-Egress (I2E), Hop-By-Hop (HBH), Select scope (IHS) is
set to "Select" in this case.
Gandhi, et al. Expires 5 September 2024 [Page 34]
Internet-Draft Using STAMP for Segment Routing March 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Segment(1) | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Segment(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 12 (Return Path) |
. .
+---------------------------------------------------------------+
Figure 21: Example Session-Sender Test Packet in Loopback
Measurement Mode with TSF for SR-MPLS Paths
When a Session-Reflector receives a packet with MNA Sub-Stack with
Opcode MNA.TSF, after timestamping the packet in STAMP payload at the
specific offset, the Session-Reflector pops the MNA Sub-Stack (after
completing any other network actions) and forwards the packet as
defined in the loopback measurement mode for SR-MPLS paths.
6.1.1. Timestamp and Forward Network Action Assignment
New MPLS Network Action Opcode is defined called "Timestamp and
Forward Network Action, MNA.TSF". The MNA.TSF Opcode is statically
configured on the STAMP 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 in the STAMP payload is statically
configured for MNA.TSF. The offset in the STAMP payload (e.g., for
unauthenticated mode with offset 16 bytes) is also statically
configured for MNA.TSF.
6.1.2. Node Capability for MNA Sub-Stack with Opcode MNA.TSF
The STAMP 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 are outside the scope of this document.
Gandhi, et al. Expires 5 September 2024 [Page 35]
Internet-Draft Using STAMP for Segment Routing March 2024
6.2. Loopback Measurement Mode with Timestamp and Forward Function for
SRv6 Paths
The [RFC8986] defines SRv6 Endpoint Behaviours for SRv6 nodes. A new
SRv6 Endpoint Behaviour is defined for "Timestamp and Forward (TSF)"
network programming function for the 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 22, to
collect "Receive Timestamp" field in the payload of the test packet.
Gandhi, et al. Expires 5 September 2024 [Page 36]
Internet-Draft Using STAMP for Segment Routing March 2024
+---------------------------------------------------------------+
| IP Header |
. Source IP Address = Session-Sender IPv6 Address .
. Destination IP Address = Segment List[Segments Left] .
. Next-Header = 43, Routing Type = SRH (4) .
. .
+---------------------------------------------------------------+
| SRH as specified in RFC 8754 |
. <Segment List including End.TSF SID> .
. <Segment List for Return Path> .
. 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 Figure 1 and Figure 3 .
. .
+---------------------------------------------------------------+
Example 1: Using SRv6 Return Path
+---------------------------------------------------------------+
| IP Header |
. Source IP Address = Session-Sender IPv6 Address .
. Destination IP Address = Session-Reflector IPv6 Address | .
. Segment List[Segments Left] .
. Next-Header = 43, Routing Type = SRH (4) .
. .
+---------------------------------------------------------------+
| SRH as specified in RFC 8754 |
. <Segment List including End.TSF SID> .
. Next-Header = 43 (IPv6) .
. .
+---------------------------------------------------------------+
| Test Packet as shown in Figure 12 (Return Path) |
. .
+---------------------------------------------------------------+
Example 2: Using IP/UDP Return Path
Figure 22: Example Session-Sender Test Packet in Loopback
Measurement Mode with TSF for SRv6 Paths
Gandhi, et al. Expires 5 September 2024 [Page 37]
Internet-Draft Using STAMP for Segment Routing March 2024
When a Session-Reflector receives a packet with Timestamp and Forward
Endpoint (End.TSF) for the target SID, which is local, after
timestamping the test packet at the specific offset, the Session-
Reflector forwards the packet as defined in the loopback measurement
mode for SRv6 paths.
6.2.1. Timestamp and Forward Endpoint Function Assignment
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 STAMP Session-Reflector node. The End.TSF is
statically configured on the STAMP Session-Reflector node and not
advertised into the routing protocols. The timestamp format for
64-bit PTPv2 and NTP to be added in the STAMP payload is statically
configured for End.TSF. The offset in the STAMP payload (e.g., for
unauthenticated mode with offset 16 bytes) is also statically
configured for End.TSF.
6.2.2. Node Capability for Timestamp and Forward Endpoint Function
The STAMP Session-Sender needs to know if the Session-Reflector can
process the Timestamp and Forward Endpoint Function to avoid dropping
test packets. The signaling extension for this capability exchange
or local configuration are outside the scope of this document.
7. Packet Loss Measurement in SR Networks
The procedure described in Section 4 and Section 5 for delay
measurement in SR networks using STAMP test packets is used similarly
for round-trip, near-end (forward direction) and far-end (backward
direction) inferred packet loss measurement in SR networks. This
provides only an approximate view of the data packet loss.
In case of loopback measurement mode, and loopback measurement mode
with timestamp and forward function, only the round-trip packet loss
measurement is applicable.
8. 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 procedures
described in Section 4 for delay measurement 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.
Gandhi, et al. Expires 5 September 2024 [Page 38]
Internet-Draft Using STAMP for Segment Routing March 2024
The PSID carried in the received data packet for the traffic flow
under measurement can be used to measure receive data packets (for
receive traffic counter) for an end-to-end SR path on the Session-
Reflector. The PSID in the received Session-Sender test packet
header can be used to associate the receive traffic counter to the
end-to-end 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, can be used for receive traffic counters.
In case of loopback measurement mode, and loopback measurement mode
with timestamp and forward function, the direct measurement is not
applicable.
9. ECMP Measurement in SR Networks
An SR Policy can have ECMPs between the source and transit nodes,
between transit nodes and between transit and destination nodes.
Usage of Anycast SID [RFC8402] by an SR Policy can result in ECMP
paths via transit nodes part of that Anycast group. The STAMP test
packets need to be transmitted to traverse different ECMP paths to
measure end-to-end delay of an SR Policy.
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 Policy, sweeping of MPLS entropy label [RFC6790] values
can be used in Session-Sender test packets and Session-Reflector
reply test packets to take advantage of the hashing function in data
plane to influence the ECMP path taken by them.
In IPv4 header of the Session-Sender test packets and Session-
Reflector reply test packets sweeping of Destination Address from the
range 127/8 can be used to exercise ECMP paths taken by them when
using MPLS header.
As specified in [RFC6437], Flow Label field in the outer IPv6 header
can also be used for sweeping to exercise different IPv6 ECMP paths.
10. 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 an unambiguous monitoring, the
controller may need to distinguish the cases whether the session is
active, but delay and packet loss metrics are not changing
significantly crossing the threshold or the session has failed.
Gandhi, et al. Expires 5 September 2024 [Page 39]
Internet-Draft Using STAMP for Segment Routing March 2024
The STAMP test session state monitoring allows to know if the
performance measurement test is active, idle or failed. The STAMP
test session state is notified as idle when Session-Sender is not
transmitting test packets. The STAMP test session state is initially
notified as active when Session-Sender is transmitting test packets
and as soon as one or more reply test packets are received at the
Session-Sender. The STAMP test session state is notified as failed
when consecutive N number of reply test packets are not received at
the Session-Sender after the 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 test session on
the Session-Sender also indicates the connectivity (i.e., liveness)
failure of the link, SR path or the L3/L2 service where the STAMP
session was active.
11. Additional STAMP Test Packet Processing Rules
The processing rules described in this section are applicable to the
STAMP test packets for links, end-to-end SR paths, and L3 and L2
services in SR networks.
11.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 Generalized
TTL Security Mechanism (GTSM) [RFC5082].
11.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
Generalized TTL Security Mechanism (GTSM) [RFC5082].
11.3. Router Alert Option
The Router Alert IP option (RAO) [RFC2113] MUST NOT be set in the
STAMP test packets to be able to punt the test packets using the UDP
ports for STAMP.
11.4. IPv6 Flow Label
The Flow Label field in the IPv6 header of the STAMP test packet 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 STAMP test packet IPv6 header in the STAMP reply test packet, and
it can be based on the local configuration on the Session-Reflector.
Gandhi, et al. Expires 5 September 2024 [Page 40]
Internet-Draft Using STAMP for Segment Routing March 2024
11.5. UDP Checksum
For IPv4 test packets, where the local processor 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 test packets, where the local processor 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.
12. 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)
13. 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.
Gandhi, et al. Expires 5 September 2024 [Page 41]
Internet-Draft Using STAMP for Segment Routing March 2024
The procedures defined in this document is intended for deployment in
a single network administrative domain. As such, the Session-Sender
address, Session-Reflector address, and forward 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 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.
14. IANA Considerations
This document does not require any IANA action.
15. References
15.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>.
[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>.
[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>.
Gandhi, et al. Expires 5 September 2024 [Page 42]
Internet-Draft Using STAMP for Segment Routing March 2024
[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., Filsfils, C., Chen, M., Janssens, B., and R.
Foote, "Simple Two-Way Active Measurement Protocol (STAMP)
Extensions for Segment Routing Networks", RFC 9503,
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, January 2024,
<https://www.rfc-editor.org/info/rfc9534>.
[I-D.ietf-mpls-mna-hdr]
Rajamanickam, J., Ed., Gandhi, R., Ed., Zigler, R., Song,
H., and K. Kompella, "MPLS Network Action Sub-Stack
Solution", Work in Progress, Internet-Draft, draft-ietf-
mpls-mna-hdr-04, October 2023,
<https://www.ietf.org/archive/id/draft-ietf-mpls-mna-hdr-
04.txt>.
15.2. Informative References
[IEEE1588] IEEE, "1588-2008 IEEE Standard for a Precision Clock
Synchronization Protocol for Networked Measurement and
Control Systems", March 2008.
[RFC2113] Katz, D., "IP Router Alert Option", RFC 2113,
DOI 10.17487/RFC2113, February 1997,
<https://www.rfc-editor.org/info/rfc2113>.
Gandhi, et al. Expires 5 September 2024 [Page 43]
Internet-Draft Using STAMP for Segment Routing March 2024
[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>.
[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>.
[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>.
[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>.
Gandhi, et al. Expires 5 September 2024 [Page 44]
Internet-Draft Using STAMP for Segment Routing March 2024
[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>.
[RFC9256] Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and
P. Mattes, "Segment Routing Policy Architecture",
RFC 9256, 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, February
2023, <https://www.rfc-editor.org/info/rfc9350>.
[RFC9524] Voyer, D., Ed., Filsfils, C., Parekh, R., Bidgoli, H., and
Z. Zhang, "Segment Routing Replication for Multipoint
Service Delivery", RFC 9524, February 2024,
<https://www.rfc-editor.org/info/rfc9524>.
[RFC9545] Cheng, W., Li, H., Li, C., Gandhi, R., and R. Zigler,
"Path Segment in MPLS-Based Segment Routing Network",
RFC 9545, February 2024,
<https://www.rfc-editor.org/info/rfc9545>.
[I-D.ietf-pim-sr-p2mp-policy]
Voyer, D., Ed., Filsfils, C., Parekh, R., Bidgoli, H., and
Z. Zhang, "Segment Routing Point-to-Multipoint Policy",
Work in Progress, Internet-Draft, draft-ietf-pim-sr-p2mp-
policy-07, 11 October 2023,
<https://www.ietf.org/archive/id/draft-ietf-pim-sr-p2mp-
policy-07.txt>.
Gandhi, et al. Expires 5 September 2024 [Page 45]
Internet-Draft Using STAMP for Segment Routing March 2024
[I-D.ietf-spring-srv6-path-segment]
Li, C., Cheng, W., Chen, M., Dhody, D., and Y. Zhu, "Path
Segment for SRv6 (Segment Routing in IPv6)", Work in
Progress, Internet-Draft, draft-ietf-spring-srv6-path-
segment-07, 19 October 2023,
<https://www.ietf.org/archive/id/draft-ietf-spring-srv6-
path-segment-07.txt>.
[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-13, 13 February 2024,
<https://www.ietf.org/archive/id/draft-ietf-pce-sr-bidir-
path-13.txt>.
[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://www.ietf.org/archive/id/draft-ietf-ippm-stamp-
yang-12.txt>.
[I-D.mirsky-ippm-asymmetrical-pkts]
Mirsky, G., Ruffini, E., Nydell, H., and R. Foote,
"Performance Measurement with Asymmetrical Packets in
STAMP", Work in Progress, Internet-Draft, draft-mirsky-
ippm-asymmetrical-pkts-04, 20 February 2024,
<https://www.ietf.org/archive/id/draft-mirsky-ippm-
asymmetrical-pkts-04.txt>.
[IEEE802.1AX]
IEEE Std. 802.1AX, "IEEE Standard for Local and
metropolitan area networks - Link Aggregation", November
2008.
Acknowledgments
The authors would like to thank Thierry Couture and Ianik Semco 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
Lin and Radu Valceanu have helped improve the mechanisms described in
this document.
Gandhi, et al. Expires 5 September 2024 [Page 46]
Internet-Draft Using STAMP for Segment Routing March 2024
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
Richard Foote
Nokia
Email: footer.foote@nokia.com
Gandhi, et al. Expires 5 September 2024 [Page 47]