Performance Measurement Using Simple TWAMP (STAMP) for Segment Routing Networks
draft-ietf-spring-stamp-srpm-09
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 | 2023-08-07 (Latest revision 2023-05-30) | ||
| Replaces | draft-gandhi-spring-stamp-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-09
SPRING Working Group R. Gandhi, Ed.
Internet-Draft C. Filsfils
Intended status: Informational Cisco Systems, Inc.
Expires: 8 February 2024 D. Voyer
Bell Canada
M. Chen
Huawei
R. Foote
Nokia
7 August 2023
Performance Measurement Using Simple TWAMP (STAMP) for Segment Routing
Networks
draft-ietf-spring-stamp-srpm-09
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/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 8 February 2024.
Gandhi, et al. Expires 8 February 2024 [Page 1]
Internet-Draft Using Simple TWAMP for Segment Routing August 2023
Copyright Notice
Copyright (c) 2023 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 . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . . 4
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4
2.3. Reference Topology . . . . . . . . . . . . . . . . . . . 5
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Example STAMP Reference Model . . . . . . . . . . . . . . 6
4. Delay Measurement in SR Networks . . . . . . . . . . . . . . 8
4.1. Session-Sender Test Packet . . . . . . . . . . . . . . . 8
4.1.1. Session-Sender Test Packet for Links . . . . . . . . 9
4.1.2. Session-Sender Test Packet for SR-MPLS Policies . . . 9
4.1.3. Session-Sender Test Packet for SRv6 Policies . . . . 11
4.1.4. Session-Sender Test Packet for P2MP SR Policies . . . 12
4.1.5. Session-Sender Test Packet for SR Flexible Algorithm
IGP Path . . . . . . . . . . . . . . . . . . . . . . 13
4.1.6. Session-Sender Test Packet for L3 Service over SR
Path . . . . . . . . . . . . . . . . . . . . . . . . 13
4.1.7. Session-Sender Test Packet for L2 Service over SR
Path . . . . . . . . . . . . . . . . . . . . . . . . 14
4.2. Session-Reflector Test Packet . . . . . . . . . . . . . . 15
4.2.1. One-Way Measurement Mode . . . . . . . . . . . . . . 15
4.2.2. Two-Way Measurement Mode . . . . . . . . . . . . . . 16
4.3. Loopback Measurement Mode . . . . . . . . . . . . . . . . 18
4.3.1. Loopback Measurement Mode STAMP Packet Processing . . 19
4.3.2. Loopback Measurement Mode for Links . . . . . . . . . 20
4.3.3. Loopback Measurement Mode for SR-MPLS Paths . . . . . 21
4.3.4. Loopback Measurement Mode for SRv6 Paths . . . . . . 22
4.3.5. Loopback Measurement Mode for L3 Service over SR
Path . . . . . . . . . . . . . . . . . . . . . . . . 24
4.3.6. Loopback Measurement Mode for L2 Service over SR
Path . . . . . . . . . . . . . . . . . . . . . . . . 25
5. Packet Loss Measurement in SR Networks . . . . . . . . . . . 26
Gandhi, et al. Expires 8 February 2024 [Page 2]
Internet-Draft Using Simple TWAMP for Segment Routing August 2023
6. Direct Measurement in SR Networks . . . . . . . . . . . . . . 26
7. ECMP Measurement in SR Networks . . . . . . . . . . . . . . . 27
8. STAMP Session State . . . . . . . . . . . . . . . . . . . . . 27
9. Additional STAMP Test Packet Processing Rules . . . . . . . . 28
9.1. TTL . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
9.2. IPv6 Hop Limit . . . . . . . . . . . . . . . . . . . . . 28
9.3. Router Alert Option . . . . . . . . . . . . . . . . . . . 28
9.4. IPv6 Flow Label . . . . . . . . . . . . . . . . . . . . . 28
9.5. UDP Checksum . . . . . . . . . . . . . . . . . . . . . . 29
10. Implementation Status . . . . . . . . . . . . . . . . . . . . 29
11. Security Considerations . . . . . . . . . . . . . . . . . . . 29
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 30
13.1. Normative References . . . . . . . . . . . . . . . . . . 30
13.2. Informative References . . . . . . . . . . . . . . . . . 31
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 34
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34
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. [I-D.ietf-ippm-stamp-srpm] augments that
framework to define STAMP extensions for SR networks.
This document describes procedures for Performance Measurement in SR
networks using the mechanisms defined in STAMP [RFC8762] and its
optional extensions defined in [RFC8972] and further augmented in
[I-D.ietf-ippm-stamp-srpm]. 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.
Gandhi, et al. Expires 8 February 2024 [Page 3]
Internet-Draft Using Simple TWAMP for Segment Routing August 2023
2. Conventions Used in This Document
2.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2.2. Abbreviations
ECMP: Equal Cost Multi-Path.
HMAC: Hashed Message Authentication Code.
L2: Layer-2.
L3: Layer-3.
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.
TTL: Time To Live.
VPN: Virtual Private Network.
Gandhi, et al. Expires 8 February 2024 [Page 4]
Internet-Draft Using Simple TWAMP for Segment Routing August 2023
2.3. Reference Topology
In the Reference Topology shown below, the STAMP Session-Sender S1
initiates a STAMP test packet and the STAMP Session-Reflector R1
transmits a reply STAMP test packet. The reply test packet may be
transmitted to the STAMP Session-Sender S1 on the same path (same set
of links and nodes) or a different path in the reverse direction from
the path taken towards the Session-Reflector. The T1 is a transmit
timestamp and T4 is a receive timestamp, both added by node S1 in the
STAMP test packet. The T2 is a receive timestamp and T3 is a
transmit timestamp, both added by node R1 in the STAMP test packet.
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 link. 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
Reference Topology
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.
Gandhi, et al. Expires 8 February 2024 [Page 5]
Internet-Draft Using Simple TWAMP for Segment Routing August 2023
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.
Gandhi, et al. Expires 8 February 2024 [Page 6]
Internet-Draft Using Simple TWAMP for Segment Routing August 2023
+------------+
| 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/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/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/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].
Gandhi, et al. Expires 8 February 2024 [Page 7]
Internet-Draft Using Simple TWAMP for Segment Routing August 2023
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
Gandhi, et al. Expires 8 February 2024 [Page 8]
Internet-Draft Using Simple TWAMP for Segment Routing August 2023
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.
Gandhi, et al. Expires 8 February 2024 [Page 9]
Internet-Draft Using Simple TWAMP for Segment Routing August 2023
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 2 |
. .
+---------------------------------------------------------------+
Figure 3: Example Session-Sender Test Packet for SR-MPLS Path
The head-end node address of the SR-MPLS Policy MUST be used as the
Source Address in the IP header of the Session-Sender test packet.
The endpoint address of the SR-MPLS Policy MUST be used as the
Destination Address in the IP header of the Session-Sender test
packet.
In the case of 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".
Gandhi, et al. Expires 8 February 2024 [Page 10]
Internet-Draft Using Simple TWAMP for Segment Routing August 2023
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.
Gandhi, et al. Expires 8 February 2024 [Page 11]
Internet-Draft Using Simple TWAMP for Segment Routing August 2023
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.
Gandhi, et al. Expires 8 February 2024 [Page 12]
Internet-Draft Using Simple TWAMP for Segment Routing August 2023
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 L3 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 L3 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 L3 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.
Gandhi, et al. Expires 8 February 2024 [Page 13]
Internet-Draft Using Simple TWAMP for Segment Routing August 2023
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 L2 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 L2 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 L2 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.
Gandhi, et al. Expires 8 February 2024 [Page 14]
Internet-Draft Using Simple TWAMP for Segment Routing August 2023
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/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.
Gandhi, et al. Expires 8 February 2024 [Page 15]
Internet-Draft Using Simple TWAMP for Segment Routing August 2023
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.
Gandhi, et al. Expires 8 February 2024 [Page 16]
Internet-Draft Using Simple TWAMP for Segment Routing August 2023
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.
Gandhi, et al. Expires 8 February 2024 [Page 17]
Internet-Draft Using Simple TWAMP for Segment Routing August 2023
+---------------------------------------------------------------+
| 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.
4.3. Loopback Measurement Mode
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)".
Gandhi, et al. Expires 8 February 2024 [Page 18]
Internet-Draft Using Simple TWAMP for Segment Routing August 2023
T1
/
+-------+ Test Packet +-------+
| | - - - - - - - - - - | |
| S1 |====================|| R1 |
| |<- - - - - - - - - - | |
+-------+ Return Test Packet +-------+
\ Loopback
T4
STAMP Session-Sender
Reference Topology for Loopback
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.
4.3.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].
Gandhi, et al. Expires 8 February 2024 [Page 19]
Internet-Draft Using Simple TWAMP for Segment Routing August 2023
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.
4.3.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.
Gandhi, et al. Expires 8 February 2024 [Page 20]
Internet-Draft Using Simple TWAMP for Segment Routing August 2023
+---------------------------------------------------------------+
| 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.
4.3.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
Gandhi, et al. Expires 8 February 2024 [Page 21]
Internet-Draft Using Simple TWAMP for Segment Routing August 2023
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).
4.3.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.
4.3.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.
4.3.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.
Gandhi, et al. Expires 8 February 2024 [Page 22]
Internet-Draft Using Simple TWAMP for Segment Routing August 2023
+---------------------------------------------------------------+
| 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).
4.3.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.
4.3.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.
Gandhi, et al. Expires 8 February 2024 [Page 23]
Internet-Draft Using Simple TWAMP for Segment Routing August 2023
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.
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.
4.3.5. Loopback Measurement Mode for L3 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.
4.3.5.1. Loopback Measurement Mode for L3 Service over SR-MPLS Path
In loopback mode 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".
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.
Note that the Session-Sender test packets can be 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. In this case, the Destination Address added in the
inner 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 IP header (for
the forward path if present) and forwards the packet using the inner
IP header for the return path that follows in the packet.
4.3.5.2. Loopback Measurement Mode for L3 Service over SRv6 Path
In loopback mode 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".
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.
Gandhi, et al. Expires 8 February 2024 [Page 24]
Internet-Draft Using Simple TWAMP for Segment Routing August 2023
Note that the Session-Sender test packets can be 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. 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, SR header
and IP header (for the forward path if present) and forwards the
packet using the inner IP header for the return path that follows in
the packet.
4.3.6. Loopback Measurement Mode for L2 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.
4.3.6.1. Loopback Measurement Mode for L2 Service over SR-MPLS Path
In loopback mode 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".
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.
Note that the Session-Sender test packets can be 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.
The Session-Reflector decapsulates the MPLS header, L2 header and IP
header (for the forward path if present) and forwards the packet
using the inner IP header for the return path that follows in the
packet.
4.3.6.2. Loopback Measurement Mode for L2 Service over SRv6 Path
In loopback mode 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".
Gandhi, et al. Expires 8 February 2024 [Page 25]
Internet-Draft Using Simple TWAMP for Segment Routing August 2023
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.
Note that the Session-Sender test packets can be 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,
L2 header and IP header (for the forward path if present) and
forwards the packet using the inner IP header for the return path
that follows in the packet.
5. Packet Loss Measurement in SR Networks
The procedure described in Section 4 for delay measurement in SR
networks using STAMP test packets can also be used for packet loss
measurement in SR networks. The Sequence Number field in the STAMP
test packet can be used as described in Section 4 "Theory of
Operation" in [RFC8762], to detect round-trip, near-end (forward
direction) and far-end (backward direction) packet loss in SR
networks. This method is used for inferred packet loss measurement
that provides only an approximate view of the data packet loss.
In the case of the loopback mode introduced in this document, only
the round-trip packet loss detection is applicable.
6. 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.
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/L2
services in SR networks, the associated SR-MPLS service labels or
SRv6 service SIDs, can be used for receive traffic counters.
Gandhi, et al. Expires 8 February 2024 [Page 26]
Internet-Draft Using Simple TWAMP for Segment Routing August 2023
In the case of the loopback mode introduced in this document, the
direct measurement is not applicable.
7. 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
forwarding 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.
8. STAMP Session State
The STAMP test session state monitoring allows to know if the
performance measurement test is active or idle. The threshold-based
notification for delay and packet loss may not be generated if the
delay and packet loss values do not change significantly. For an
unambiguous monitoring, the controller needs to distinguish the cases
whether the performance measurement is active, or delay and packet
loss values are not changing significantly to cross the threshold.
Gandhi, et al. Expires 8 February 2024 [Page 27]
Internet-Draft Using Simple TWAMP for Segment Routing August 2023
The STAMP test session state is initially notified as active as soon
as one or more reply test packets are received at the Session-Sender.
The STAMP test session state is notified as idle (or 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 that the connectivity verification to the
Session-Reflector has failed.
9. 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/L2 services
in SR networks.
9.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].
9.2. IPv6 Hop Limit
The Hop Limit (HL) field in the IPv6 header of the Session-Sender and
Session-Reflector test packets MUST be set to 255 as per Generalized
TTL Security Mechanism (GTSM) [RFC5082].
9.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.
9.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 traffic flow on the SR path
being measured by the Session-Sender.
The Session-Reflector SHOULD return the same 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 policy on the Session-
Reflector.
Gandhi, et al. Expires 8 February 2024 [Page 28]
Internet-Draft Using Simple TWAMP for Segment Routing August 2023
9.5. UDP Checksum
For IPv4 test packets, where the hardware 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 hardware 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 STAMP sessions.
10. Implementation Status
Editorial note: Please remove this section prior to publication.
The following routing platforms running IOS-XR operating system have
participated in an interop testing for one-way, two-way and loopback
measurement modes:
* Cisco 8802 (based Cisco Silicon One Q200)
* Cisco ASR9904 with Lightspeed linecard and Tomahawk linecard
* Cisco NCS5508 (based on Broadcom Jericho2 platform)
* Cisco NCS5500 (based on Broadcom Jericho1 platform)
11. Security Considerations
The security considerations specified in [RFC8762] and [RFC8972] also
apply to the procedures described in this document.
The Security Considerations specified in [I-D.ietf-ippm-stamp-srpm]
are also applicable to the procedures defined 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. SRv6 STAMP test
packets can use the HMAC protection authentication defined for SRH in
[RFC8754].
Gandhi, et al. Expires 8 February 2024 [Page 29]
Internet-Draft Using Simple TWAMP for Segment Routing August 2023
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.
When using the procedures defined in [RFC6936], the security
considerations specified in [RFC6936] also apply.
The procedures defined in this document is intended for deployment in
a single network operator domain. As such, the Session-Sender
address, Session-Reflector address, and IP and SR 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 IP and SR
forward and return paths used to transmit STAMP test packets.
12. IANA Considerations
This document does not require any IANA action.
13. References
13.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>.
Gandhi, et al. Expires 8 February 2024 [Page 30]
Internet-Draft Using Simple TWAMP for Segment Routing August 2023
[RFC8972] Mirsky, G., Min, X., Nydell, H., Foote, R., Masputra, A.,
and E. Ruffini, "Simple Two-Way Active Measurement
Protocol Optional Extensions", RFC 8972,
DOI 10.17487/RFC8972, January 2021,
<https://www.rfc-editor.org/info/rfc8972>.
[I-D.ietf-ippm-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>.
13.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>.
Gandhi, et al. Expires 8 February 2024 [Page 31]
Internet-Draft Using Simple TWAMP for Segment Routing August 2023
[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>.
[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>.
Gandhi, et al. Expires 8 February 2024 [Page 32]
Internet-Draft Using Simple TWAMP for Segment Routing August 2023
[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-16, 31 July 2023,
<https://www.ietf.org/archive/id/draft-ietf-spring-sr-
replication-segment-16.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-10, 31 July 2023,
<https://www.ietf.org/archive/id/draft-ietf-spring-mpls-
path-segment-10.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-11, 8 March 2023,
<https://www.ietf.org/archive/id/draft-ietf-pce-sr-bidir-
path-11.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
Gandhi, et al. Expires 8 February 2024 [Page 33]
Internet-Draft Using Simple TWAMP for Segment Routing August 2023
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.
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, Amit Dhamija, 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.
Contributors
The following people have substantially contributed to this document:
Bart Janssens
Colt
Email: Bart.Janssens@colt.net
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
Gandhi, et al. Expires 8 February 2024 [Page 34]
Internet-Draft Using Simple TWAMP for Segment Routing August 2023
Email: mach.chen@huawei.com
Richard Foote
Nokia
Email: footer.foote@nokia.com
Gandhi, et al. Expires 8 February 2024 [Page 35]