Performance Measurement Using Simple TWAMP (STAMP) for Segment Routing Networks

Internet-Draft	Using Simple TWAMP for Segment Routing	September 2023
Gandhi, et al.	Expires 14 March 2024	[Page]

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 the mechanisms defined in RFC 8762 (Simple Two-Way Active Measurement Protocol (STAMP)) and its optional extensions defined in RFC 8972 and further augmented in draft-ietf-ippm-stamp-srpm. 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.¶

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 used in one-way, round-trip (also referred to as two-way in this document) and loopback delay measurement modes in SR networks. Note that one-way and round-trip measurement modes are referred to in [RFC8762] and are further described in this document because of the introduction of loopback measurement mode in SR networks.¶

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 and reverse direction paths for STAMP test packets, even for directly connected nodes are not guaranteed.¶

It may be desired in SR networks that the same path (same set of links and nodes) between the Session-Sender and Session-Reflector be used for the STAMP test packets in both directions. This is achieved by using the optional STAMP extensions for SR-MPLS and SRv6 networks specified in [I-D.ietf-ippm-stamp-srpm]. The STAMP Session-Reflector uses the return path parameters for the reply test packet from the received Session-Sender test packet, as described in [I-D.ietf-ippm-stamp-srpm].¶

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 1.¶


                            +------------+
                            | Controller |
                            +------------+
                                /    \
  Destination UDP Port         /      \      Destination UDP Port
  Authentication Mode         /        \     Authentication Mode
      Keychain               /          \        Keychain
  Timestamp Format          /            \   Timestamp Format
  Packet Loss Type         /              \
  Delay Measurement Mode  /                \
                         v                  v
                     +-------+          +-------+
                     |       |          |       |
                     |   S1  |==========|   R1  |
                     |       |          |       |
                     +-------+          +-------+

              STAMP Session-Sender  STAMP Session-Reflector

Figure 1: 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 dynamically chosen by the Session-Sender. The same or different UDP Source port can be used 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].¶

Examples of Delay Measurement Mode can be one-way, two-way (i.e., round-trip) and loopback mode as described in this document.¶

Examples of Packet Loss Type can be 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].¶

The controller shown in the "Example STAMP Reference Model" is intended for provisioning the STAMP test sessions and not intended for the dynamic signaling of the SR parameters for the STAMP test sessions between the 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 2. 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.¶

 +---------------------------------------------------------------+
 | 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 = Dynamically 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 2: Example Session-Sender Test Packet

4.1.1. Session-Sender Test Packet for Links

The Session-Sender test packet as shown in Figure 2 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 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 MAC Destination Address and Session-Sender MAC address as the MAC Source Address for Ethernet links.¶

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 3.¶

The head-end node address of the SR-MPLS Policy MUST be used as the Source Address in the IP header of the Session-Sender test packet. The endpoint address of the SR-MPLS Policy MUST be used as the Destination Address in the IP header of the Session-Sender test packet.¶

In the case of 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 Segment List can be empty in the case of a single-hop SR-MPLS Policy Candidate-Path with Implicit NULL label.¶

The Session-Reflector may receive Session-Sender test packets with no MPLS header, for example, when using Penultimate Hop Popping (PHP).¶

The Path Segment Identifier (PSID) [I-D.ietf-spring-mpls-path-segment] 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 3, and can be used for direct measurement as described in Section 6, titled "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 4.¶

 +---------------------------------------------------------------+
 | 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 = UDP (17)                                       .
 .                                                               .
 +---------------------------------------------------------------+
 | UDP Header                                                    |
 .  Source Port = Dynamically 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 4: 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.¶

The Segment List of the SRv6 Policy Candidate-Path can be empty. In this case, the endpoint address of the SRv6 Policy MUST be 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 without adding the IP header with Source Address of the Session-Sender and Destination Address of the Session-Reflector after the SRH. 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 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 4 and can be used for direct measurement as described in Section 6, titled "Direct Measurement for Links and SR Paths".¶

4.1.4. Session-Sender Test Packet for P2MP SR Policies

The procedure for delay measurement described 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 that may contain replication SIDs [I-D.ietf-spring-sr-replication-segment] 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. In this case, the SR-MPLS encapsulation MUST ensure the Session-Sender test packets reach the leaf nodes of the SR-MPLS Policy.¶

The P2MP root node measures the delay for each leaf node independently using the Source Address of the leaf node from the received Session-Reflector reply test packets.¶

4.1.5. Session-Sender Test Packet for SR Flexible Algorithm IGP Path

The delay measurement of end-to-end SR paths in an SR network is applicable to both 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 MUST be transmitted on the Flex-Algo path using the same encapsulation as the data traffic for delay measurement.¶

For delay measurement of an SR-MPLS Flex-Algo IGP path, the Session-Sender test packets MUST carry the Flex-Algo Prefix SID Label of the Session-Reflector for that Flex-Algo IGP path in the MPLS header.¶

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.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 L3VPN services in an SR network for both SR-MPLS and SRv6 data planes.¶

4.1.6.1. Session-Sender Test Packet for Layer-3 Service over SR-MPLS Path

For delay measurement of end-to-end L3VPN service over SR-MPLS path, the same SR-MPLS label stack (as shown in Figure 3) as the data packets of the L3VPN service including the L3VPN service SR-MPLS label is used to transmit Session-Sender test packets.¶

An IP header (as shown in Figure 2) MUST be added in the Session-Sender test packets after the SR-MPLS encapsulation. The Destination Address on the Session-Reflector added in the IP header MUST be reachable via the IP table lookup associated with the L3VPN service SR-MPLS label.¶

4.1.6.2. Session-Sender Test Packet for Layer-3 Service over SRv6 Path

For delay measurement of end-to-end L3VPN service over SRv6 path, the same IPv6/SRH encapsulation (as shown in Figure 4) as the data packets of the L3VPN service including the L3VPN service SRv6 SID (for example, End.DT6 SID instance, End.DT4 SID instance, etc. defined in [RFC8986]) is used to transmit Session-Sender test packets.¶

An inner IP header (as shown in Figure 2) MUST be added in the Session-Sender test packets after the IPv6/SRH encapsulation. The Destination Address on the Session-Reflector added in the inner IP header MUST be reachable via the IPv4 or IPv6 table lookup associated with the L3VPN service SRv6 SID.¶

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 L2VPN 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 L2VPN service over SR-MPLS path, the same SR-MPLS label stack (as shown in Figure 3) as the data packets of the L2VPN service including the L2VPN service SR-MPLS label is used to transmit Session-Sender test packets.¶

An L2 header (added after the SR-MPLS encapsulation) MUST be added in the Session-Sender test packets that contains the MAC Source Address of the Session-Sender and MAC Destination Address of the Session-Reflector. The MAC Destination Address added in the L2 header MUST be reachable via the MAC L2 table lookup associated with the L2VPN service SR-MPLS label.¶

An IP header (as shown in Figure 2) MUST be added in the Session-Sender test packets after the L2 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 L2VPN service over SRv6 path, the same IPv6/SRH encapsulation (as shown in Figure 4) as the data packets of the L2VPN service including the L2VPN service SRv6 SID (for example, End.DT2U SID instance defined in [RFC8986]) is used to transmit Session-Sender test packets.¶

An L2 header (added after the IPv6/SRH encapsulation) MUST be added in the Session-Sender test packets that contains the MAC Source Address of the Session-Sender and MAC Destination Address of the Session-Reflector. The MAC Destination Address added in the L2 header MUST be reachable via the MAC L2 table lookup associated with the L2VPN service SRv6 SID.¶

An inner IP header (as shown in Figure 2) can be added in the Session-Sender test packets after the L2 header. It contains the Source Address of the Session-Sender and Destination Address of the Session-Reflector.¶

4.2. Session-Reflector Test Packet

The Session-Reflector decapsulates the outer IP header (if present) and the SR header (SR-MPLS header or 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 5.¶

 +---------------------------------------------------------------+
 | 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 5: 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 delay measurement mode, a reply test packet with the contents as shown in Figure 5 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 delay measurement mode requires the clocks on the Session-Sender and Session-Reflector to be synchronized.¶

4.2.2. Two-Way Measurement Mode

In two-way (i.e., round-trip) delay measurement mode, a reply test packet as shown in Figure 5 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].¶

In two-way delay measurement mode for links, the Session-Sender can 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 Control Code Sub-TLV in the Return Path TLV defined in [I-D.ietf-ippm-stamp-srpm] for this request.¶

In two-way delay measurement mode for end-to-end SR paths, the Session-Sender can request in the test packet to the Session-Reflector to transmit the reply test packet back on a specific reverse SR path, for example, in an ECMP environment or in SR Flex-Algo IGP environment. It can use a Segment List sub-TLV in the Return Path TLV defined in [I-D.ietf-ippm-stamp-srpm] for this request.¶

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 two-way delay as ((T4 - T1) - (T3 - T2)). When clock synchronization on the Session-Sender and Session-Reflector nodes is not available, the one-way delay (as an average of forward and reverse direction delay) can be derived using two-way delay divided by two.¶

4.2.2.1. Session-Reflector Test Packet for SR-MPLS Policies

The content of an example Session-Reflector reply test packet transmitted for two-way delay measurement of an end-to-end SR-MPLS Policy using the same SR-MPLS encapsulation as the data traffic in the reverse direction is shown in Figure 6.¶

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                Segment(1)             | TC  |S|      TTL      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 .                                                               .
 .                                                               .
 .                                                               .
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                Segment(n)             | TC  |S|      TTL      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                PSID (optional)        | TC  |S|      TTL      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                Test Packet as shown in Figure 5               |
 .                                                               .
 +---------------------------------------------------------------+

Figure 6: Example Session-Reflector Test Packet for SR-MPLS Path

4.2.2.2. Session-Reflector Test Packet for SRv6 Policies

The content of an example Session-Reflector reply test packet transmitted for two-way delay measurement of an end-to-end SRv6 Policy using the same IPv6/SRH encapsulation as the data traffic in the reverse direction is shown in Figure 7.¶

 +---------------------------------------------------------------+
 | IP Header                                                     |
 .  Source IP Address                                            .
 .       = Destination IPv6 Address from Received Test Packet    .
 .  Destination IP Address                                       .
 .       = Source IPv6 Address from Received Test Packet OR      .
 .         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 = Destination Port from Received Test Packet     .
 .  Destination Port = Source Port from Received Test Packet     .
 .                                                               .
 +---------------------------------------------------------------+
 | Payload = Test Packet as specified in Section 3 of RFC 8972   |
 .           in Figure 2 and Figure 4                            .
 .                                                               .
 +---------------------------------------------------------------+

Figure 7: Example Session-Reflector Test Packet for SRv6 Path

The procedure defined for Upper-Layer Header processing for SRv6 End SIDs in Section 4.1.1 in [RFC8986] MUST be used to process the IPv6/UDP header in the received Session-Reflector reply test packets on the Session-Sender.¶

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 forwarding (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]. In this mode, the only STAMP TLV defined in [RFC8972] is applicable is "Extra Padding TLV (Value 1)".¶

                       T1
                      /
             +-------+     Test Packet     +-------+
             |       | - - - - - - - - - - |       |
             |   S1  |====================||   R1  |
             |       |<- - - - - - - - - - |       |
             +-------+  Return Test Packet +-------+
                      \                    Loopback
                       T4

         STAMP Session-Sender

              Reference Topology for Loopback Mode

In this mode, as per Reference Topology for Loopback, 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 one-way delay (as an average of forward and reverse direction delay) can be derived using the loopback delay divided by two. 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 forwarding plane. The Session-Reflector does not timestamp the Session-Sender test packets and 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-Sender test packets (other than the UDP 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 may use the STAMP Session ID (SSID) field in the received reply STAMP test packet or local configuration to identify its STAMP test session that uses the loopback mode. At the Session-Sender, the 'Session-Sender Sequence Number', 'Session-Sender Timestamp', 'Session-Sender Error Estimate', and 'Session-Sender TTL' fields in the received STAMP test packets MUST be ignored in this mode.¶

5.2. Loopback Measurement Mode for Links

In the case of loopback mode for links, an inner IP header for the return path is added in the Session-Sender test packets as shown in Figure 8 in the Session-Sender test packets and it MUST set the Destination Address equal to the Session-Sender address.¶

 +---------------------------------------------------------------+
 | 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 = Dynamically 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 8: Example Session-Sender Return Test Packet in Loopback

The Session-Sender test packets for the links in loopback mode may be transmitted optionally with an outer IP header as shown in Figure 9. An SR encapsulation (e.g., containing adjacency SID of the link) can also be added for transmitting the Session-Sender test packets for links.¶

 +---------------------------------------------------------------+
 | IP Header (Forward Path)                                      |
 .  Source IP Address = Session-Sender IP Address                .
 .  Destination IP Address = Session-Reflector IP Address        .
 .  IPv4 Protocol = IPv4 (4) or IPv6 Next header = IPv6 (41)     .
 .                                                               .
 +---------------------------------------------------------------+
 |                Test Packet as shown in Figure 8               |
 .                                                               .
 +---------------------------------------------------------------+

Figure 9: Example Session-Sender Test Packet in Loopback for Link

Note that the Session-Sender test packet is further encapsulated with a Layer-2 header containing Session-Reflector MAC address as the Destination Address and Session-Sender MAC address as the MAC Source Address for Ethernet links.¶

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 mode for SRv6 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 reverse SR-MPLS paths in MPLS header as shown in Figure 10.¶

 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 8               |
 .                                                               .
 +---------------------------------------------------------------+

Figure 10: Example Session-Sender Test Packet in Loopback 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. Reverse 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 reverse direction 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.¶

The IP header of the Session-Sender test packets MUST set the Destination Address equal to the Session-Sender address as shown in Figure 8.¶

5.3.2. Reverse IP/UDP Path

In the case of loopback 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 8 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 that follows in the packet.¶

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 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 reverse SRv6 paths in IPv6/SRH as shown in Figure 11.¶

 +---------------------------------------------------------------+
 | 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>                              .
 .                                                               .
 +---------------------------------------------------------------+
 |                Test Packet as shown in Figure 8               |
 .                                                               .
 +---------------------------------------------------------------+

Figure 11: Example Session-Sender Test Packet in Loopback for SRv6 Path

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. Reverse 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 reverse direction 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 can be added in the Session-Sender test packet that has the Destination Address equal to the Session-Sender address as shown in Figure 8.¶

5.4.2. Reverse IP/UDP Path

In the case of loopback mode for SRv6 paths, the Session-Sender test packet can contain the Segment List of the forward SRv6 path only.¶

The Session-Reflector decapsulates the outer IPv6 and SR headers and forwards the packet using the inner IP header for the return path that follows in the packet.¶

5.5. Loopback Measurement Mode for Layer-3 Service over SR Path

The loopback measurement mode is also applicable to L3VPN services in an SR network for both SR-MPLS and SRv6 data planes.¶

5.5.1. Loopback Measurement Mode for Layer-3 Service over SR-MPLS Path

For L3VPN service over SR-MPLS path, Session-Sender test packets are generated as described in Section titled "Session-Sender Test Packet for L3 Service over SR-MPLS Path". In loopback mode, the Session-Sender test packets are transmitted without adding the IP header for the forward path, with Source Address of the Session-Sender and Destination Address of the Session-Reflector after the MPLS header.¶

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 8 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 service SR-MPLS label in the reverse direction.¶

The Session-Reflector decapsulates the MPLS header and forwards the packet using the IP header for the return path that follows in the packet.¶

5.5.2. Loopback Measurement Mode for Layer-3 Service over SRv6 Path

For L3VPN service over SRv6 path, Session-Sender test packets are generated as described in Section titled "Session-Sender Test Packet for L3 Service over SRv6 Path". In loopback mode, the Session-Sender test packets are transmitted without adding the IP header for the forward path, with Source Address of the Session-Sender and Destination Address of the Session-Reflector after the IPv6/SRH.¶

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 8 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 service SRv6 SID in the reverse direction.¶

The Session-Reflector decapsulates the outer IPv6 header and SR header (if present) and forwards the packet using the inner IP header for the return path that follows in the packet.¶

5.6. Loopback Measurement Mode for Layer-2 Service over SR Path

The loopback measurement mode is also applicable to L2VPN services in an SR network for both SR-MPLS and SRv6 data planes.¶

5.6.1. Loopback Measurement Mode for Layer-2 Service over SR-MPLS Path

For L2VPN service over SR-MPLS path, Session-Sender test packets are generated as described in Section titled "Session-Sender Test Packet for L2 Service over SR-MPLS Path". In loopback mode, the Session-Sender test packets are transmitted without adding the IP header for the forward path, with Source Address of the Session-Sender and Destination Address of the Session-Reflector after the MPLS header.¶

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 8 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 L2VPN service SR-MPLS label in the reverse direction.¶

The Session-Reflector decapsulates the MPLS header and L2 header and forwards the packet using the inner IP header for the return path that follows in the packet.¶

5.6.2. Loopback Measurement Mode for Layer-2 Service over SRv6 Path

For L2VPN service over SRv6 path, Session-Sender test packets are generated as described in Section titled "Session-Sender Test Packet for L2 Service over SRv6 Path". In loopback mode, the Session-Sender test packets are transmitted without adding the IP header for the forward path, with Source Address of the Session-Sender and Destination Address of the Session-Reflector after the IPv6/SRH.¶

The Session-Reflector decapsulates the outer IPv6 header, SR header and L2 header and forwards the packet using the inner IP header for the return path that follows in the packet.¶

6. Enhanced Loopback Measurement Mode in SR Networks

This document defines a new STAMP measurement mode, called enhanced loopback mode, that is loopback mode enabled with network programming function. In this mode, both transmit (T1) and receive (T2) timestamps in data plane are collected by the Session-Sender test packets as shown in Figure 1. The network programming function optimizes the "operations of punt test packet and generate return test packet" on the Session-Reflector as timestamping is implemented in forwarding fast path in hardware. 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 forwarding fast path in hardware 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.¶

                         T1                  T2
                        /                     \
               +-------+      Test Packet      +-------+
               |       | - - - - - - - - - - - |       |
               |   S1  |======================||  R1   |
               |       |<- - - - - - - - - - - |       |
               +-------+   Return Test Packet  +-------+
                        \                      Loopback
                         T4

             STAMP Session-Sender     STAMP Session-Reflector
                                             (Timestamp,
                                              and Forward)

              Reference Topology for Enhanced Loopback Mode

Figure 12: Enhanced Loopback Mode Enabled with Network Programming Function

For an end-to-end SR path including SR Policy, STAMP Session-Sender test packets are transmitted in enhanced loopback mode, enabled with network programming function for timestamp and forward the packet as described in the following sub-sections.¶

6.1. Enhanced Loopback Measurement Mode for SR-MPLS Paths

The enhanced loopback measurement mode for SR-MPLS paths is described below.¶

MPLS Network Action (MNA) Sub-Stack defined in [I-D.ietf-mpls-mna-hdr] is used for SR-MPLS data plane to enable network programming function of "timestamp and forward" for the received test packet. 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 Policies, the MNA Sub-Stack with Opcode MNA.TSF is added in the MPLS header as shown in Figure 13, 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 and set to "Select" when the return path is SR-MPLS. 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 reverse direction SR-MPLS path can be added after the MNA Sub-Stack (not shown in the Figure 13) to receive the return test packet on a specific path.¶

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 using the next label or IP header in the packet (just like the data packets for the normal traffic).¶

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 (value 16)) 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.¶

6.2. Enhanced Loopback Measurement Mode for SRv6 Paths

The enhanced loopback measurement mode for SRv6 paths is described below.¶

The [RFC8986] defines SRv6 Endpoint Behaviours for SRv6 nodes. A new Timestamp and Forward Endpoint Behaviour is defined for Segment Routing Header (SRH) [RFC8754] to enable "Timestamp and Forward (TSF)" function for the received test packets.¶

In the Session-Sender test packets for SRv6 Policies, Timestamp and Forward Endpoint Function (End.TSF) is carried with the target Segment Identifier (SID) in SRH [RFC8754] as shown in Figure 14, to collect "Receive Timestamp" field in the payload of the test packet. The Segment List for the reverse direction path can be added after the target SID to receive the return test packet on a specific path. When a Session-Reflector receives a packet with Timestamp and Forward Endpoint (End.TSF) for the target SID, which is local, after timestamping the packet at the specific offset, the Session-Reflector forwards the packet using the next SID in the SRH or inner IPv6 header in the packet (just like the data packets for the normal traffic).¶

  +---------------------------------------------------------------+
  | 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>                                            .
  .     <SRv6 Endpoint End.TSF>                                   .
  .                                                               .
  +---------------------------------------------------------------+
  | IP Header                                                     |
  .  Source IP Address = Session-Sender IPv6 Address              .
  .  Destination IP Address = Session-Sender IPv6 Address         .
  .  Next-Header = UDP (17)                                       .
  .                                                               .
  +---------------------------------------------------------------+
  | UDP Header                                                    |
  .  Source Port = Dynamically 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 14: Example STAMP Test Packet with Endpoint Function for TSF for SRv6

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 (value 16)) 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.¶

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>.
[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>.
[I-D.ietf-ippm-stamp-srpm]: Gandhi, R., Filsfils, C., Chen, M., Janssens, B., and R. Foote, "Simple TWAMP (STAMP) Extensions for Segment Routing Networks", Work in Progress, Internet-Draft, draft-ietf-ippm-stamp-srpm-18, 4 August 2023, <https://www.ietf.org/archive/id/draft-ietf-ippm-stamp-srpm-18.txt>.
[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-03, September 2023, <https://www.ietf.org/archive/id/draft-ietf-mpls-mna-hdr-03.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>.
[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>.
[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>.
[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>.
[I-D.ietf-spring-sr-replication-segment]: (editor), D. V., Filsfils, C., Parekh, R., Bidgoli, H., and Z. Zhang, "SR Replication Segment for Multi-point Service Delivery", Work in Progress, Internet-Draft, draft-ietf-spring-sr-replication-segment-19, 28 August 2023, <https://www.ietf.org/archive/id/draft-ietf-spring-sr-replication-segment-19.txt>.
[I-D.ietf-pim-sr-p2mp-policy]: (editor), D. V., 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-06, 13 April 2023, <https://www.ietf.org/archive/id/draft-ietf-pim-sr-p2mp-policy-06.txt>.
[I-D.ietf-spring-mpls-path-segment]: Cheng, W., Li, H., Li, C., Gandhi, R., and R. Zigler, "Path Segment in MPLS Based Segment Routing Network", Work in Progress, Internet-Draft, draft-ietf-spring-mpls-path-segment-11, 29 August 2023, <https://www.ietf.org/archive/id/draft-ietf-spring-mpls-path-segment-11.txt>.
[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-06, 4 May 2023, <https://www.ietf.org/archive/id/draft-ietf-spring-srv6-path-segment-06.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-12, 9 September 2023, <https://www.ietf.org/archive/id/draft-ietf-pce-sr-bidir-path-12.txt>.
[I-D.ietf-ippm-stamp-yang]: Mirsky, G., Min, X., and W. S. Luo, "Simple Two-way Active Measurement Protocol (STAMP) Data Model", Work in Progress, Internet-Draft, draft-ietf-ippm-stamp-yang-11, 13 March 2023, <https://www.ietf.org/archive/id/draft-ietf-ippm-stamp-yang-11.txt>.
[IEEE802.1AX]: IEEE Std. 802.1AX, "IEEE Standard for Local and metropolitan area networks - Link Aggregation", November 2008.