draft-ietf-spring-stamp-srpm-01.txt   draft-ietf-spring-stamp-srpm-02.txt 
SPRING Working Group R. Gandhi, Ed. SPRING Working Group R. Gandhi, Ed.
Internet-Draft C. Filsfils Internet-Draft C. Filsfils
Intended status: Informational Cisco Systems, Inc. Intended status: Informational Cisco Systems, Inc.
Expires: January 7, 2022 D. Voyer Expires: 17 March 2022 D. Voyer
Bell Canada Bell Canada
M. Chen M. Chen
Huawei Huawei
B. Janssens B. Janssens
Colt Colt
R. Foote R. Foote
Nokia Nokia
July 06, 2021 13 September 2021
Performance Measurement Using Simple TWAMP (STAMP) for Segment Routing Performance Measurement Using Simple TWAMP (STAMP) for Segment Routing
Networks Networks
draft-ietf-spring-stamp-srpm-01 draft-ietf-spring-stamp-srpm-02
Abstract Abstract
Segment Routing (SR) leverages the source routing paradigm. SR is Segment Routing (SR) leverages the source routing paradigm. SR is
applicable to both Multiprotocol Label Switching (SR-MPLS) and IPv6 applicable to both Multiprotocol Label Switching (SR-MPLS) and IPv6
(SRv6) data planes. This document describes procedures for (SRv6) data planes. This document describes procedures for
Performance Measurement in SR networks using the mechanisms defined Performance Measurement in SR networks using the mechanisms defined
in RFC 8762 (Simple Two-Way Active Measurement Protocol (STAMP)) and in RFC 8762 (Simple Two-Way Active Measurement Protocol (STAMP)) and
its optional extensions defined in RFC 8972 and further augmented in its optional extensions defined in RFC 8972 and further augmented in
draft-ietf-ippm-stamp-srpm. The procedure described is applicable to draft-ietf-ippm-stamp-srpm. The procedure described is applicable to
skipping to change at page 1, line 47 skipping to change at page 1, line 47
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 7, 2022. This Internet-Draft will expire on 17 March 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents (https://trustee.ietf.org/
(https://trustee.ietf.org/license-info) in effect on the date of license-info) in effect on the date of publication of this document.
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document. Code Components
to this document. Code Components extracted from this document must extracted from this document must include Simplified BSD License text
include Simplified BSD License text as described in Section 4.e of as described in Section 4.e of the Trust Legal Provisions and are
the Trust Legal Provisions and are provided without warranty as provided without warranty as described in the Simplified BSD License.
described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . . 3 2. Conventions Used in This Document . . . . . . . . . . . . . . 3
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3
2.3. Reference Topology . . . . . . . . . . . . . . . . . . . 4 2.3. Reference Topology . . . . . . . . . . . . . . . . . . . 4
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Example STAMP Reference Model . . . . . . . . . . . . . . 6 3.1. Example STAMP Reference Model . . . . . . . . . . . . . . 6
4. Delay Measurement for Links and SR Paths . . . . . . . . . . 7 4. Delay Measurement for Links and SR Paths . . . . . . . . . . 7
4.1. Session-Sender Test Packet . . . . . . . . . . . . . . . 7 4.1. Session-Sender Test Packet . . . . . . . . . . . . . . . 7
4.1.1. Session-Sender Test Packet for Links . . . . . . . . 8 4.1.1. Session-Sender Test Packet for Links . . . . . . . . 8
4.1.2. Session-Sender Test Packet for SR Paths . . . . . . . 8 4.1.2. Session-Sender Test Packet for SR Paths . . . . . . . 8
4.2. Session-Reflector Test Packet . . . . . . . . . . . . . . 10 4.2. Session-Reflector Test Packet . . . . . . . . . . . . . . 10
4.2.1. One-way Measurement Mode . . . . . . . . . . . . . . 11 4.2.1. One-Way Measurement Mode . . . . . . . . . . . . . . 11
4.2.2. Two-way Measurement Mode . . . . . . . . . . . . . . 11 4.2.2. Two-Way Measurement Mode . . . . . . . . . . . . . . 11
4.2.3. Loopback Measurement Mode . . . . . . . . . . . . . . 13 4.2.3. Loopback Measurement Mode . . . . . . . . . . . . . . 13
4.3. Delay Measurement for P2MP SR Policies . . . . . . . . . 14 4.3. Delay Measurement for P2MP SR Policies . . . . . . . . . 14
4.4. Additional STAMP Test Packet Processing Rules . . . . . . 15 4.4. Additional STAMP Test Packet Processing Rules . . . . . . 15
4.4.1. TTL . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.4.1. TTL . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.4.2. IPv6 Hop Limit . . . . . . . . . . . . . . . . . . . 16 4.4.2. IPv6 Hop Limit . . . . . . . . . . . . . . . . . . . 16
4.4.3. Router Alert Option . . . . . . . . . . . . . . . . . 16 4.4.3. Router Alert Option . . . . . . . . . . . . . . . . . 16
4.4.4. UDP Checksum . . . . . . . . . . . . . . . . . . . . 16 4.4.4. UDP Checksum . . . . . . . . . . . . . . . . . . . . 16
5. Packet Loss Measurement for Links and SR Paths . . . . . . . 16 4.4.5. Destination Node Address . . . . . . . . . . . . . . 16
6. Direct Measurement for Links and SR Paths . . . . . . . . . . 16 5. Packet Loss Measurement for Links and SR Paths . . . . . . . 17
7. Session State for Links and SR Paths . . . . . . . . . . . . 17 6. Direct Measurement for Links and SR Paths . . . . . . . . . . 17
8. ECMP Support for SR Policies . . . . . . . . . . . . . . . . 17 7. STAMP Session State for Links and SR Paths . . . . . . . . . 17
8. ECMP Support for SR Policies . . . . . . . . . . . . . . . . 18
9. Security Considerations . . . . . . . . . . . . . . . . . . . 18 9. Security Considerations . . . . . . . . . . . . . . . . . . . 18
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
11.1. Normative References . . . . . . . . . . . . . . . . . . 19 11.1. Normative References . . . . . . . . . . . . . . . . . . 19
11.2. Informative References . . . . . . . . . . . . . . . . . 19 11.2. Informative References . . . . . . . . . . . . . . . . . 20
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 22 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction 1. Introduction
Segment Routing (SR) leverages the source routing paradigm and Segment Routing (SR) leverages the source routing paradigm and
greatly simplifies network operations for Software Defined Networks greatly simplifies network operations for Software Defined Networks
(SDNs). SR is applicable to both Multiprotocol Label Switching (SR- (SDNs). SR is applicable to both Multiprotocol Label Switching (SR-
MPLS) and IPv6 (SRv6) data planes [RFC8402]. SR takes advantage of MPLS) and IPv6 (SRv6) data planes [RFC8402]. SR takes advantage of
the Equal-Cost Multipaths (ECMPs) between source and transit nodes, the Equal-Cost Multipaths (ECMPs) between source and transit nodes,
between transit nodes and between transit and destination nodes. SR between transit nodes and between transit and destination nodes. SR
Policies as defined in [I-D.ietf-spring-segment-routing-policy] are Policies as defined in [I-D.ietf-spring-segment-routing-policy] are
used to steer traffic through a specific, user-defined paths using a used to steer traffic through a specific, user-defined paths using a
stack of Segments. Built-in SR Performance Measurement (PM) is one stack of Segments. Built-in SR Performance Measurement (PM) is one
of the essential requirements to provide Service Level Agreements of the essential requirements to provide Service Level Agreements
(SLAs). (SLAs).
The Simple Two-way Active Measurement Protocol (STAMP) provides The Simple Two-Way Active Measurement Protocol (STAMP) provides
capabilities for the measurement of various performance metrics in IP capabilities for the measurement of various performance metrics in IP
networks [RFC8762] without the use of a control channel to pre-signal networks [RFC8762] without the use of a control channel to pre-signal
session parameters. [RFC8972] defines optional extensions for STAMP. session parameters. [RFC8972] defines optional extensions for STAMP.
[I-D.ietf-ippm-stamp-srpm] augments that framework to define STAMP [I-D.ietf-ippm-stamp-srpm] augments that framework to define STAMP
extensions for SR networks. extensions for SR networks.
This document describes procedures for Performance Measurement in SR This document describes procedures for Performance Measurement in SR
networks using the mechanisms defined in STAMP [RFC8762] and its networks using the mechanisms defined in STAMP [RFC8762] and its
optional extensions defined in [RFC8972] and further augmented in optional extensions defined in [RFC8972] and further augmented in
[I-D.ietf-ippm-stamp-srpm]. The procedure described is applicable to [I-D.ietf-ippm-stamp-srpm]. The procedure described is applicable to
skipping to change at page 4, line 37 skipping to change at page 4, line 37
SR: Segment Routing. SR: Segment Routing.
SRH: Segment Routing Header. SRH: Segment Routing Header.
SR-MPLS: Segment Routing with MPLS data plane. SR-MPLS: Segment Routing with MPLS data plane.
SRv6: Segment Routing with IPv6 data plane. SRv6: Segment Routing with IPv6 data plane.
SSID: STAMP Session Identifier. SSID: STAMP Session Identifier.
STAMP: Simple Two-way Active Measurement Protocol. STAMP: Simple Two-Way Active Measurement Protocol.
TC: Traffic Class. TC: Traffic Class.
TTL: Time To Live. TTL: Time To Live.
2.3. Reference Topology 2.3. Reference Topology
In the Reference Topology shown below, the STAMP Session-Sender R1 In the Reference Topology shown below, the STAMP Session-Sender S1
initiates a STAMP test packet and the STAMP Session-Reflector R3 initiates a STAMP test packet and the STAMP Session-Reflector R1
transmits a reply test packet. The reply test packet may be transmits a reply test packet. The reply test packet may be
transmitted to the STAMP Session-Sender R1 on the same path (same set 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 of links and nodes) or a different path in the reverse direction from
the path taken towards the Session-Reflector. the path taken towards the Session-Reflector.
The nodes R1 and R3 may be connected via a link or an SR path 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 [RFC8402]. The link may be a physical interface, virtual link, or
Link Aggregation Group (LAG) [IEEE802.1AX], or LAG member link. The Link Aggregation Group (LAG) [IEEE802.1AX], or LAG member link. The
SR path may be an SR Policy [I-D.ietf-spring-segment-routing-policy] SR path may be an SR Policy [I-D.ietf-spring-segment-routing-policy]
on node R1 (called head-end) with destination to node R3 (called on node S1 (called head-end) with destination to node R1 (called
tail-end). tail-end).
T1 T2 T1 T2
/ \ / \
+-------+ Test Packet +-------+ +-------+ Test Packet +-------+
| | - - - - - - - - - ->| | | | - - - - - - - - - ->| |
| R1 |=====================| R3 | | S1 |=====================| R1 |
| |<- - - - - - - - - - | | | |<- - - - - - - - - - | |
+-------+ Reply Test Packet +-------+ +-------+ Reply Test Packet +-------+
\ / \ /
T4 T3 T4 T3
STAMP Session-Sender STAMP Session-Reflector STAMP Session-Sender STAMP Session-Reflector
Reference Topology Reference Topology
3. Overview 3. Overview
For performance measurement in SR networks, the STAMP Session-Sender For performance measurement in SR networks, the STAMP Session-Sender
and Session-Reflector test packets defined in [RFC8762] are used. and Session-Reflector test packets defined in [RFC8972] are used.
The STAMP test packets require to be encapsulated to be transmitted The STAMP test packets require to be encapsulated to be transmitted
on a desired path under measurement. The base STAMP test packets can on a desired path under measurement. The base STAMP test packets can
be encapsulated using IP/UDP header and may use Destination UDP port be encapsulated using IP/UDP header and may use Destination UDP port
862 [RFC8762]. In this document, the STAMP packets using IP/UDP 862 [RFC8762]. In this document, the STAMP test packets using IP/UDP
header are considered for SR networks. header are considered for SR networks.
The STAMP test packets are used in one-way, two-way (i.e. round-trip) The STAMP test packets are used in one-way, two-way (i.e. round-trip)
and loopback measurement modes. Note that one-way and round-trip are and loopback measurement modes. Note that one-way and round-trip are
referred to in [RFC8762] and are further described in this document referred to in [RFC8762] and are further described in this document
because of the introduction of loopback measurement mode in SR because of the introduction of loopback measurement mode in SR
networks. The procedures defined in this document are also used to networks. The procedures defined in this document are also used to
infer packet loss in SR networks. infer packet loss in SR networks.
The STAMP test packets are transmitted on the same path as the data The STAMP test packets are transmitted on the same path as the data
skipping to change at page 6, line 38 skipping to change at page 6, line 38
/ \ / \
Destination UDP Port / \ Destination UDP Port Destination UDP Port / \ Destination UDP Port
Authentication Mode / \ Authentication Mode Authentication Mode / \ Authentication Mode
Key-chain / \ Key-chain Key-chain / \ Key-chain
Timestamp Format / \ Timestamp Format Timestamp Format / \ Timestamp Format
Packet Loss Type / \ Session-Reflector Mode Packet Loss Type / \ Session-Reflector Mode
Delay Measurement Mode / \ Delay Measurement Mode / \
v v v v
+-------+ +-------+ +-------+ +-------+
| | | | | | | |
| R1 |==========| R3 | | S1 |==========| R1 |
| | | | | | | |
+-------+ +-------+ +-------+ +-------+
STAMP Session-Sender STAMP Session-Reflector STAMP Session-Sender STAMP Session-Reflector
Figure 1: Example STAMP Reference Model Figure 1: Example STAMP Reference Model
A Destination UDP port number is selected as described in [RFC8762]. A Destination UDP port number MUST be selected as described in
The same Destination UDP port can be used for STAMP test sessions for [RFC8762]. The same Destination UDP port can be used for STAMP test
link and end-to-end SR paths. In this case, the Destination UDP port sessions for link and end-to-end SR paths. In this case, the
does not distinguish between link or end-to-end SR path measurements. Destination UDP port does not distinguish between link or end-to-end
SR path measurements.
Example of the Timestamp Format is Precision Time Protocol 64-bit Example of the Timestamp Format is Precision Time Protocol 64-bit
truncated (PTPv2) [IEEE1588] and Network Time Protocol (NTP). By truncated (PTPv2) [IEEE1588] and Network Time Protocol (NTP). By
default, the Session-Reflector replies in kind to the timestamp default, the Session-Reflector replies in kind to the timestamp
format received in the received Session-Sender test packet, as format received in the received Session-Sender test packet, as
indicated by the "Z" field in the Error Estimate field as described indicated by the "Z" field in the Error Estimate field as described
in [RFC8762]. in [RFC8762].
The Session-Reflector mode can be Stateful or Stateless as defined in The Session-Reflector mode can be Stateful or Stateless as defined in
[RFC8762]. [RFC8762].
Example of Delay Measurement Mode is one-way, two-way (i.e. round- Example of Delay Measurement Mode is one-way, two-way (i.e. round-
trip) and loopback mode as described in this document. trip) and loopback mode as described in this document.
Example of Packet Loss Type can be round-trip, near-end (forward) and Example of Packet Loss Type can be round-trip, near-end (forward) and
far-end (backward) packet loss as defined in [RFC8762]. far-end (backward) packet loss as defined in [RFC8762].
When using the authenticated mode for the STAMP test sessions, the When using the authenticated mode for the STAMP test sessions, the
matching Authentication Type (e.g. HMAC-SHA-256) and Key-chain are matching Authentication Type (e.g. HMAC-SHA-256) and Key-chain MUST
user-configured on STAMP Session-Sender and STAMP Session-Reflector be user-configured on STAMP Session-Sender and STAMP Session-
[RFC8762]. Reflector [RFC8762].
The controller shown in the example reference model is not intended The controller shown in the example reference model is not intended
for the dynamic signaling of the SR parameters for STAMP test for the dynamic signaling of the SR parameters for STAMP test
sessions between the STAMP Session-Sender and STAMP Session- sessions between the STAMP Session-Sender and STAMP Session-
Reflector. Reflector.
Note that the YANG data model defined in [I-D.ietf-ippm-stamp-yang] Note that the YANG data model defined in [I-D.ietf-ippm-stamp-yang]
can be used to provision the STAMP Session-Sender and STAMP Session- can be used to provision the STAMP Session-Sender and STAMP Session-
Reflector. Reflector.
4. Delay Measurement for Links and SR Paths 4. Delay Measurement for Links and SR Paths
4.1. Session-Sender Test Packet 4.1. Session-Sender Test Packet
The content of an example STAMP Session-Sender test packet using an The content of an example Session-Sender test packet using an UDP
UDP header [RFC0768] is shown in Figure 2. The payload contains the header [RFC0768] is shown in Figure 2. The payload contains the
STAMP Session-Sender test packet defined in [RFC8762]. Session-Sender test packet defined in Section 3 of [RFC8972].
+---------------------------------------------------------------+ +---------------------------------------------------------------+
| IP Header | | IP Header |
. Source IP Address = Session-Sender IPv4 or IPv6 Address . . Source IP Address = Session-Sender IPv4 or IPv6 Address .
. Destination IP Address=Session-Reflector IPv4 or IPv6 Address. . Destination IP Address=Session-Reflector IPv4 or IPv6 Address.
. Protocol = UDP . . Protocol = UDP .
. . . .
+---------------------------------------------------------------+ +---------------------------------------------------------------+
| UDP Header | | UDP Header |
. Source Port = As chosen by Session-Sender . . Source Port = As chosen by Session-Sender .
. Destination Port = User-configured Destination Port | 862 . . Destination Port = User-configured Destination Port | 862 .
. . . .
+---------------------------------------------------------------+ +---------------------------------------------------------------+
| Payload = Test Packet as specified in Section 3 of RFC 8972 | | Payload = Test Packet as specified in Section 3 of RFC 8972 |
. in Figure 1 and Figure 3 . . in Figure 1 and Figure 3 .
. . . .
+---------------------------------------------------------------+ +---------------------------------------------------------------+
Figure 2: Example Session-Sender Test Packet Figure 2: Example Session-Sender Test Packet
4.1.1. Session-Sender Test Packet for Links 4.1.1. Session-Sender Test Packet for Links
The STAMP Session-Sender test packet as shown in Figure 2 is The Session-Sender test packet as shown in Figure 2 is transmitted
transmitted over the link under delay measurement. The local and over the link under delay measurement. The local and remote IP
remote IP addresses of the link are used as Source and Destination addresses of the link are used as Source and Destination Addresses,
Addresses, respectively. For IPv6 links, the link local addresses respectively. For IPv6 links, the link local addresses [RFC7404] can
[RFC7404] can be used in the IPv6 header. The Session-Sender may use be used in the IPv6 header. The Session-Sender MAY use the local
the local Address Resolution Protocol (ARP) table, Neighbor Address Resolution Protocol (ARP) table, Neighbor Solicitation or
Solicitation or other bootstrap method to find the IP address for the other bootstrap method to find the IP address for the links and
links and refresh. SR encapsulation (e.g. adjacency SID of the link) refresh. SR encapsulation (e.g. adjacency SID of the link) can be
can be added for transmitting the STAMP test packets for links. added for transmitting the STAMP test packets for links.
4.1.2. Session-Sender Test Packet for SR Paths 4.1.2. Session-Sender Test Packet for SR Paths
The delay measurement for end-to-end SR path in an SR network is The delay measurement for end-to-end SR path in an SR network is
applicable to both end-to-end SR-MPLS and SRv6 paths including SR applicable to both end-to-end SR-MPLS and SRv6 paths including SR
Policies. Policies.
The STAMP Session-Sender (the head-end of the SR Policy) IPv4 or IPv6 The Session-Sender (the head-end of the SR Policy) IPv4 or IPv6
address MUST be used as the Source Address in the IP header of the address MUST be used as the Source Address in the IP header of the
test packet. The STAMP Session-Reflector (the SR Policy endpoint) STAMP test packet. The Session-Reflector (the SR Policy endpoint)
IPv4 or IPv6 address MUST be used as the Destination Address in the IPv4 or IPv6 address MUST be used as the Destination Address in the
IP header of the test packet. IP header of the STAMP test packet.
In the case of Color-Only Destination Steering, with IPv4 endpoint of In the case of Color-Only Destination Steering, with IPv4 endpoint of
0.0.0.0 or IPv6 endpoint of ::0 0.0.0.0 or IPv6 endpoint of ::0
[I-D.ietf-spring-segment-routing-policy], the loopback address from [I-D.ietf-spring-segment-routing-policy], the loopback address from
the range 127/8 for IPv4, or the loopback address ::1/128 for IPv6 the range 127/8 for IPv4, or the loopback address ::1/128 for IPv6
[RFC4291] is used as the Session-Reflector Address, respectively. [RFC4291] can be used as the Session-Reflector Address, respectively.
4.1.2.1. Session-Sender Test Packet for SR-MPLS Policies 4.1.2.1. Session-Sender Test Packet for SR-MPLS Policies
An SR-MPLS Policy may contain a number of Segment Lists (SLs). A An SR-MPLS Policy may contain a number of Segment Lists (SLs). A
STAMP Session-Sender test packet MUST be transmitted for each Segment Session-Sender test packet MUST be transmitted for each Segment List
List of the SR-MPLS Policy. The content of an example STAMP Session- of the SR-MPLS Policy. The content of an example Session-Sender test
Sender test packet for an end-to-end SR-MPLS Policy is shown in packet for an end-to-end SR-MPLS Policy is shown in Figure 3.
Figure 3.
0 1 2 3 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 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(1) | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
. . . .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 9, line 43 skipping to change at page 9, line 42
with Implicit NULL label. with Implicit NULL label.
The Path Segment Identifier (PSID) The Path Segment Identifier (PSID)
[I-D.ietf-spring-mpls-path-segment] of an SR-MPLS Policy can be [I-D.ietf-spring-mpls-path-segment] of an SR-MPLS Policy can be
carried in the MPLS header as shown in Figure 3, and can be used for carried in the MPLS header as shown in Figure 3, and can be used for
direct measurement as described in Section 6, titled "Direct direct measurement as described in Section 6, titled "Direct
Measurement for Links and SR Paths". Measurement for Links and SR Paths".
4.1.2.2. Session-Sender Test Packet for SRv6 Policies 4.1.2.2. Session-Sender Test Packet for SRv6 Policies
An SRv6 Policy may contain a number of Segment Lists. A STAMP An SRv6 Policy may contain a number of Segment Lists. A Session-
Session-Sender test packet MUST be transmitted for each Segment List Sender test packet MUST be transmitted for each Segment List of the
of the SRv6 Policy. An SRv6 Policy can contain an SRv6 Segment SRv6 Policy. An SRv6 Policy can contain an SRv6 Segment Routing
Routing Header (SRH) carrying a Segment List as described in Header (SRH) carrying a Segment List as described in [RFC8754]. The
[RFC8754]. The content of an example STAMP Session-Sender test content of an example Session-Sender test packet for an end-to-end
packet for an end-to-end SRv6 Policy is shown in Figure 4. SRv6 Policy is shown in Figure 4.
The SRv6 network programming is described in [RFC8986]. The The SRv6 network programming is described in [RFC8986]. The
procedure defined for Upper-Layer Header processing for SRv6 End SIDs procedure defined for Upper-Layer Header processing for SRv6 End SIDs
in Section 4.1.1 in [RFC8986] is used to process the IPv6/UDP header in Section 4.1.1 in [RFC8986] MUST be used to process the IPv6/UDP
in the received test packets on the Session-Reflector. header in the received test packets on the Session-Reflector.
+---------------------------------------------------------------+ +---------------------------------------------------------------+
| IP Header | | IP Header |
. Source IP Address = Session-Sender IPv6 Address . . Source IP Address = Session-Sender IPv6 Address .
. Destination IP Address = Destination IPv6 Address . . Destination IP Address = Destination IPv6 Address .
. Protocol = UDP . . Protocol = UDP .
. . . .
+---------------------------------------------------------------+ +---------------------------------------------------------------+
| SRH as specified in RFC 8754 | | SRH as specified in RFC 8754 |
. <PSID, Segment List> . . <PSID, Segment List> .
skipping to change at page 10, line 28 skipping to change at page 10, line 26
| UDP Header | | UDP Header |
. Source Port = As chosen by Session-Sender . . Source Port = As chosen by Session-Sender .
. Destination Port = User-configured Destination Port | 862 . . Destination Port = User-configured Destination Port | 862 .
. . . .
+---------------------------------------------------------------+ +---------------------------------------------------------------+
| Payload = Test Packet as specified in Section 3 of RFC 8972 | | Payload = Test Packet as specified in Section 3 of RFC 8972 |
. in Figure 1 and Figure 3 . . in Figure 1 and Figure 3 .
. . . .
+---------------------------------------------------------------+ +---------------------------------------------------------------+
Figure 4: Example Session-Sender Test Packet for SRv6 Policy Figure 4: Example Session-Sender Test Packet for SRv6 Policy
The Segment List (SL) may be empty and no SRH may be carried. The Segment List (SL) may be empty and no SRH may be carried.
The Path Segment Identifier (PSID) The Path Segment Identifier (PSID)
[I-D.ietf-spring-srv6-path-segment] of the SRV6 Policy can be carried [I-D.ietf-spring-srv6-path-segment] of the SRV6 Policy can be carried
in the SRH as shown in Figure 4 and can be used for direct in the SRH as shown in Figure 4 and can be used for direct
measurement as described in Section 6, titled "Direct Measurement for measurement as described in Section 6, titled "Direct Measurement for
Links and SR Paths". Links and SR Paths".
4.2. Session-Reflector Test Packet 4.2. Session-Reflector Test Packet
The STAMP Session-Reflector reply test packet uses the IP/UDP The Session-Reflector reply test packet uses the IP/UDP information
information from the received test packet as shown in Figure 5. from the received test packet as shown in Figure 5. The payload
contains the Session-Reflector test packet defined in Section 3 of
[RFC8972].
+---------------------------------------------------------------+ +---------------------------------------------------------------+
| IP Header | | IP Header |
. Source IP Address = Session-Reflector IPv4 or IPv6 Address . . Source IP Address = Session-Reflector IPv4 or IPv6 Address .
. Destination IP Address . . Destination IP Address .
. = Source IP Address from Received Test Packet . . = Source IP Address from Received Test Packet .
. Protocol = UDP . . Protocol = UDP .
. . . .
+---------------------------------------------------------------+ +---------------------------------------------------------------+
| UDP Header | | UDP Header |
skipping to change at page 11, line 25 skipping to change at page 11, line 25
. Destination Port = Source Port from Received Test Packet . . Destination Port = Source Port from Received Test Packet .
. . . .
+---------------------------------------------------------------+ +---------------------------------------------------------------+
| Payload = Test Packet as specified in Section 3 of RFC 8972 | | Payload = Test Packet as specified in Section 3 of RFC 8972 |
. in Figure 2 and Figure 4 . . in Figure 2 and Figure 4 .
. . . .
+---------------------------------------------------------------+ +---------------------------------------------------------------+
Figure 5: Example Session-Reflector Test Packet Figure 5: Example Session-Reflector Test Packet
4.2.1. One-way Measurement Mode 4.2.1. One-Way Measurement Mode
In one-way delay measurement mode, a reply test packet as shown in In one-way delay measurement mode, a reply test packet as shown in
Figure 5 is transmitted by the STAMP Session-Reflector, for both Figure 5 is transmitted by the Session-Reflector, for both links and
links and end-to-end SR Policies. The reply test packet may be end-to-end SR Policies. The reply test packet MAY be transmitted on
transmitted on the same path or a different path in the reverse the same path or a different path in the reverse direction.
direction.
The STAMP Session-Sender address may not be reachable via IP route The Session-Sender address may not be reachable via IP route from the
from the STAMP Session-Reflector. The STAMP Session-Sender in this Session-Reflector. The Session-Sender in this case MUST send its
case MUST send its reachability path information to the STAMP reachability path information to the Session-Reflector using the
Session-Reflector using the Return Path TLV defined in Return Path TLV defined in [I-D.ietf-ippm-stamp-srpm].
[I-D.ietf-ippm-stamp-srpm].
In this mode, as per Reference Topology, all timestamps T1, T2, T3, In this mode, as per Reference Topology, all timestamps T1, T2, T3,
and T4 are collected by the test packets. However, only timestamps and T4 are collected by the STAMP test packets. However, only
T1 and T2 are used to measure one-way delay as (T2 - T1). The one- timestamps T1 and T2 are used to measure one-way delay as (T2 - T1).
way delay measurement mode requires the clock on the Session-Sender The one-way delay measurement mode requires the clocks on the
and Session-Reflector to be synchronized. Session-Sender and Session-Reflector to be synchronized.
4.2.2. Two-way Measurement Mode 4.2.2. Two-Way Measurement Mode
In two-way (i.e. round-trip) delay measurement mode, a reply test In two-way (i.e. round-trip) delay measurement mode, a reply test
packet as shown in Figure 5 is transmitted by the STAMP Session- packet as shown in Figure 5 is transmitted by the Session-Reflector
Reflector on the same path in the reverse direction, e.g. on the on the same path in the reverse direction as the forward direction,
reverse direction link or associated reverse SR path e.g. on the reverse direction link or associated reverse SR path
[I-D.ietf-pce-sr-bidir-path]. [I-D.ietf-pce-sr-bidir-path].
For two-way delay measurement mode for links, the STAMP Session- For two-way delay measurement mode for links, the Session-Reflector
Reflector transmits the reply test packet on the same link where the MUST transmit the reply test packet on the same link where the test
test packet is received. The STAMP Session-Sender can request in the packet is received. The Session-Sender can request in the test
test packet to the STAMP Session-Reflector to transmit the reply test packet to the Session-Reflector to transmit the reply test packet
packet back on the same link using the Control Code Sub-TLV in the back on the same link using the Control Code Sub-TLV in the Return
Return Path TLV defined in [I-D.ietf-ippm-stamp-srpm]. Path TLV defined in [I-D.ietf-ippm-stamp-srpm].
For two-way delay measurement mode for end-to-end SR paths, the STAMP For two-way delay measurement mode for end-to-end SR paths, the
Session-Reflector transmits the reply test packet on a specific Session-Reflector MUST transmit the reply test packet on a specific
reverse path. The STAMP Session-Sender can request in the test reverse path. The Session-Sender can request in the test packet to
packet to the STAMP Session-Reflector to transmit the reply test the Session-Reflector to transmit the reply test packet back on a
packet back on a given reverse path using a Segment List sub-TLV in given reverse path using a Segment List sub-TLV in the Return Path
the Return Path TLV defined in [I-D.ietf-ippm-stamp-srpm]. TLV defined in [I-D.ietf-ippm-stamp-srpm].
In this mode, as per Reference Topology, all timestamps T1, T2, T3, In this mode, as per Reference Topology, all timestamps T1, T2, T3,
and T4 are collected by the test packets. All four timestamps are and T4 are collected by the test packets. All four timestamps are
used to measure two-way delay as ((T4 - T1) - (T3 - T2)). When clock used to measure two-way delay as ((T4 - T1) - (T3 - T2)). When clock
synchronization on the Session-Sender and Session-Reflector nodes is synchronization on the Session-Sender and Session-Reflector nodes is
not possible, the one-way delay can be derived using two-way delay not possible, the one-way delay can be derived using two-way delay
divided by two. divided by two.
4.2.2.1. Session-Reflector Test Packet for SR-MPLS Policies 4.2.2.1. Session-Reflector Test Packet for SR-MPLS Policies
The content of an example STAMP Session-Reflector reply test packet The content of an example Session-Reflector reply test packet
transmitted on the same path as the data traffic flow under transmitted on the same path as the data traffic flow under
measurement for two-way delay measurement of an end-to-end SR-MPLS measurement for two-way delay measurement of an end-to-end SR-MPLS
Policy is shown in Figure 6. Policy is shown in Figure 6.
0 1 2 3 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 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(1) | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
. . . .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Segment(n) | TC |S| TTL | | Segment(n) | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Test Packet as shown in Figure 5 | | Test Packet as shown in Figure 5 |
. . . .
+---------------------------------------------------------------+ +---------------------------------------------------------------+
Figure 6: Example Session-Reflector Test Packet for SR-MPLS Policy Figure 6: Example Session-Reflector Test Packet for SR-MPLS Policy
4.2.2.2. Session-Reflector Test Packet for SRv6 Policies 4.2.2.2. Session-Reflector Test Packet for SRv6 Policies
The content of an example STAMP Session-Reflector reply test packet The content of an example Session-Reflector reply test packet
transmitted on the same path as the data traffic flow under transmitted on the same path as the data traffic flow under
measurement for two-way delay measurement of an end-to-end SRv6 measurement for two-way delay measurement of an end-to-end SRv6
Policy with SRH is shown in Figure 7. Policy with SRH is shown in Figure 7.
The procedure defined for Upper-Layer Header processing for SRv6 End The procedure defined for Upper-Layer Header processing for SRv6 End
SIDs in Section 4.1.1 in [RFC8986] is used to process the IPv6/UDP SIDs in Section 4.1.1 in [RFC8986] MUST be used to process the IPv6/
header in the received reply test packets on the Session-Sender. UDP header in the received reply test packets on the Session-Sender.
+---------------------------------------------------------------+ +---------------------------------------------------------------+
| IP Header | | IP Header |
. Source IP Address = Session-Reflector IPv6 Address . . Source IP Address = Session-Reflector IPv6 Address .
. Destination IP Address = Destination IPv6 Address . . Destination IP Address = Destination IPv6 Address .
. Protocol = UDP . . Protocol = UDP .
. . . .
+---------------------------------------------------------------+ +---------------------------------------------------------------+
| SRH as specified in RFC 8754 | | SRH as specified in RFC 8754 |
. <Segment List> . . <Segment List> .
skipping to change at page 13, line 41 skipping to change at page 13, line 41
+---------------------------------------------------------------+ +---------------------------------------------------------------+
| Payload = Test Packet as specified in Section 3 of RFC 8972 | | Payload = Test Packet as specified in Section 3 of RFC 8972 |
. in Figure 2 and Figure 4 . . in Figure 2 and Figure 4 .
. . . .
+---------------------------------------------------------------+ +---------------------------------------------------------------+
Figure 7: Example Session-Reflector Test Packet for SRv6 Policy Figure 7: Example Session-Reflector Test Packet for SRv6 Policy
4.2.3. Loopback Measurement Mode 4.2.3. Loopback Measurement Mode
The STAMP Session-Sender test packets are transmitted in loopback The Session-Sender test packets are transmitted in loopback mode to
mode to measure loopback delay of a bidirectional circular path. In measure loopback delay of a bidirectional circular path. In this
this mode, the received Session-Sender test packets are not punted mode, the received Session-Sender test packets MUST NOT be punted out
out of the fast path in forwarding (i.e. to slow path or control- of the fast path in forwarding (i.e. to slow path or control-plane)
plane) at the STAMP Session-Reflector. In other words, the Session- at the Session-Reflector. In other words, the Session-Reflector does
Reflector does not process them and generate Session-Reflector test not process them and generate Session-Reflector test packets. This
packets. This is a new measurement mode, not defined by STAMP is a new measurement mode, not defined by the STAMP process in
process [RFC8762]. [RFC8762].
The STAMP Session-Sender MUST set the Destination UDP port to the UDP
port it uses to receive the reply STAMP test packets. Since the
Session-Reflector does not support the STAMP process, the loopback
function simply makes the necessary changes to the encapsulation
including IP and UDP headers to return the test packet to the
Session-Sender. The typical Session-Reflector test packet is not
used in this mode. The loopback function simply returns the received
Session-Sender test packet to the Session-Sender without STAMP
modifications defined in [RFC8762].
In case of SR-MPLS paths, the SR-MPLS header can contain the MPLS
label stack of the forward path or both forward and the reverse
paths. The IP header of the STAMP Session-Sender test packets MUST
set the Destination Address equal to the STAMP Session-Sender address
and the Source Address equal to the STAMP Session-Reflector address.
In case of SRv6 paths, the SRH can contain the Segment List of the
forward path or both forward and the reverse paths. In the former
case, an inner IPv6 header (after SRH and before UDP header) MUST be
added that contains the Destination Address equal to the STAMP
Session-Sender address and the Source Address equal to the STAMP
Session-Reflector address.
The Session-Sender may use the SSID field in the received reply test
packet or local configuration to identify its test session using the
loopback mode. In the received Session-Sender test packet at the
Session-Sender, the 'Session-Sender Sequence Number', 'Session-Sender
Timestamp', 'Session-Sender Error Estimate', and 'Session-Sender TTL'
fields are not present in this mode.
In this mode, as per Reference Topology, the test packet received In this mode, as per Reference Topology, the test packet received
back at the Session-Sender retrieves the timestamp T1 from the test back at the Session-Sender retrieves the timestamp T1 from the test
packet and adds the received timestamp T4 locally. Both these packet and adds the received timestamp T4 locally. Both these
timestamps are used to measure the loopback delay as (T4 - T1). The timestamps are used to measure the loopback delay as (T4 - T1). The
one-way delay can be derived using the loopback delay divided by two. one-way delay can be derived using the loopback delay divided by two.
In loopback mode, the loopback delay includes the processing delay on In loopback mode, the loopback delay includes the processing delay on
the Session-Reflector. The Session-Reflector processing delay the Session-Reflector. The Session-Reflector processing delay
component includes only the time required to loop the test packet component includes only the time required to loop the test packet
from the incoming interface to the outgoing interface in forwarding from the incoming interface to the outgoing interface in the
plane. forwarding plane.
4.2.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 reply test packets. Since the Session-
Reflector does not support the STAMP process, the loopback function
simply makes the necessary changes to the encapsulation including IP
and UDP headers to return the test packet to the Session-Sender. The
typical Session-Reflector test packet is not used in this mode. The
loopback function simply returns 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 test packet or local configuration to identify its
test session that uses the loopback mode. In the received Session-
Sender test packet at the Session-Sender, the 'Session-Sender
Sequence Number', 'Session-Sender Timestamp', 'Session-Sender Error
Estimate', and 'Session-Sender TTL' fields are not present in this
mode.
4.2.3.2. Loopback Measurement Mode for SR Policies
In case of SR-MPLS paths, the SR-MPLS header can contain the MPLS
label stack of the forward path or both forward and the reverse
paths. The IP header of the SR-MPLS Session-Sender test packets MUST
set the Destination Address equal to the Session-Sender address and
the Source Address equal to the Session-Reflector address.
In case of SRv6 paths, the SRH can contain the Segment List of the
forward path or both forward and the reverse paths. In the former
case, an inner IPv6 header (after SRH and before UDP header) MUST be
added that contains the Destination Address equal to the Session-
Sender address and the Source Address equal to the Session-Reflector
address.
4.3. Delay Measurement for P2MP SR Policies 4.3. Delay Measurement for P2MP SR Policies
The Point-to-Multipoint (P2MP) SR path that originates from a root The Point-to-Multipoint (P2MP) SR path that originates from a root
node terminates on multiple destinations called leaf nodes (e.g. node terminates on multiple destinations called leaf nodes (e.g.
P2MP SR Policy [I-D.ietf-pim-sr-p2mp-policy]). P2MP SR Policy [I-D.ietf-pim-sr-p2mp-policy]).
The procedures for delay and loss measurement described in this The procedures for delay and loss measurement described in this
document for end-to-end P2P SR Policies are also equally applicable document for end-to-end P2P SR Policies are also equally applicable
to the P2MP SR Policies. The procedure for one-way measurement is to the P2MP SR Policies. The procedure for one-way measurement is
defined as following: defined as following:
o The STAMP Session-Sender root node transmits test packets using * The Session-Sender root node transmits test packets using the
the Tree-SID defined in [I-D.ietf-pim-sr-p2mp-policy] for the P2MP Tree-SID defined in [I-D.ietf-pim-sr-p2mp-policy] for the P2MP SR-
SR-MPLS Policy as shown in Figure 8. The STAMP Session-Sender MPLS Policy as shown in Figure 8. The Session-Sender test packets
test packets may contain the replication SID as defined in may contain the replication SID as defined in
[I-D.ietf-spring-sr-replication-segment]. [I-D.ietf-spring-sr-replication-segment].
o The Destination Address MUST be set to the loopback address from * The Destination Address MUST be set to the loopback address from
the range 127/8 for IPv4, or the loopback address ::1/128 for the range 127/8 for IPv4, or the loopback address ::1/128 for
IPv6. IPv6.
o Each STAMP Session-Reflector leaf node MUST transmit its node * Each Session-Reflector leaf node MUST transmit its node address in
address in the Source Address of the reply test packets shown in the Source Address of the reply test packets shown in Figure 5.
Figure 5. This allows the STAMP Session-Sender root node to This allows the Session-Sender root node to identify the Session-
identify the STAMP Session-Reflector leaf nodes of the P2MP SR Reflector leaf nodes of the P2MP SR Policy.
Policy.
o The P2MP root node measures the delay for each P2MP leaf node * The P2MP root node measures the delay for each P2MP leaf node
individually. individually.
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tree-SID | TC |S| TTL | | Tree-SID | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
. . . .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Test Packet as shown in Figure 2 | | Test Packet as shown in Figure 2 |
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Example Session-Sender Test Packet with Tree-SID for SR- Figure 8: Example Session-Sender Test Packet with Tree-SID for
MPLS Policy SR-MPLS Policy
The considerations for two-way mode for P2MP SR Policy (e.g. for co- The considerations for two-way measurement mode (e.g. for co-routed
routed bidirectional SR-MPLS path) are outside the scope of this bidirectional SR-MPLS path) and loopback measurement mode for P2MP
document. SR-MPLS Policy are outside the scope of this document.
4.4. Additional STAMP Test Packet Processing Rules 4.4. Additional STAMP Test Packet Processing Rules
The processing rules described in this section are applicable to the The processing rules described in this section are applicable to the
STAMP test packets for links and end-to-end SR paths including SR STAMP test packets for links and end-to-end SR paths including SR
Policies. Policies.
4.4.1. TTL 4.4.1. TTL
The TTL field in the IPv4 and MPLS headers of the STAMP Session- The TTL field in the IPv4 and MPLS headers of the Session-Sender and
Sender and STAMP Session-Reflector test packet is set to 255 as per Session-Reflector test packet is set to 255 as per Generalized TTL
Generalized TTL Security Mechanism (GTSM) [RFC5082]. Security Mechanism (GTSM) [RFC5082].
4.4.2. IPv6 Hop Limit 4.4.2. IPv6 Hop Limit
The Hop Limit (HL) field in the IPv6 and SRH headers of the STAMP The Hop Limit (HL) field in the IPv6 and SRH headers of the Session-
Session-Sender and STAMP Session-Reflector test packet is set to 255 Sender and Session-Reflector test packet is set to 255 as per
as per Generalized TTL Security Mechanism (GTSM) [RFC5082]. Generalized TTL Security Mechanism (GTSM) [RFC5082].
4.4.3. Router Alert Option 4.4.3. Router Alert Option
The Router Alert IP option (RAO) [RFC2113] is not set in the STAMP The Router Alert IP option (RAO) [RFC2113] is not set in the STAMP
test packets for links and end-to-end SR paths. test packets for links and end-to-end SR paths.
4.4.4. UDP Checksum 4.4.4. UDP Checksum
For IPv4 test packets, where the hardware is not capable of re- For IPv4 test packets, where the hardware is not capable of re-
computing the UDP checksum or adding checksum complement [RFC7820], computing the UDP checksum or adding checksum complement [RFC7820],
the Session-Sender may set the UDP checksum value to 0 [RFC8085]. the Session-Sender can set the UDP checksum value to 0 [RFC8085].
For IPv6 test packets, where the hardware is not capable of re- For IPv6 test packets, where the hardware is not capable of re-
computing the UDP checksum or adding checksum complement [RFC7820], computing the UDP checksum or adding checksum complement [RFC7820],
the Session-Sender and Session-Reflector may use the procedure the Session-Sender and Session-Reflector can use the procedure
defined in [RFC6936] for the UDP checksum. defined in [RFC6936] for the UDP checksum for the UDP port being used
for STAMP.
4.4.5. Destination Node Address
The "Destination Node Address" TLV [I-D.ietf-ippm-stamp-srpm] MUST be
carried in the Session-Sender test packet to identify the intended
Session-Reflector, when using IPv4 Session-Reflector Address from
127/8 range, (e.g. when the STAMP test packet is encapsulated by a
tunneling protocol or an MPLS Segment List) or when using IPv6
Session-Reflector Address of ::1/128 (e.g. when the STAMP test packet
is encapsulated by an SRH).
5. Packet Loss Measurement for Links and SR Paths 5. Packet Loss Measurement for Links and SR Paths
The procedure described in Section 4 for delay measurement using The procedure described in Section 4 for delay measurement using
STAMP test packets can be used to detect (test) packet loss for links STAMP test packets can be used to detect (test) packet loss for links
and end-to-end SR paths. The Sequence Number field in the STAMP test and end-to-end SR paths. The Sequence Number field in the STAMP test
packet is used as described in Section 4 "Theory of Operation" where packet is used as described in Section 4 "Theory of Operation" where
Stateful and Stateless Session-Reflector operations are defined Stateful and Stateless Session-Reflector operations are defined
[RFC8762], to detect round-trip, near-end (forward) and far-end [RFC8762], to detect round-trip, near-end (forward) and far-end
(backward) packet loss. In the case of the loopback mode introduced (backward) packet loss. In the case of the loopback mode introduced
skipping to change at page 17, line 9 skipping to change at page 17, line 29
6. Direct Measurement for Links and SR Paths 6. Direct Measurement for Links and SR Paths
The STAMP "Direct Measurement" TLV (Type 5) defined in [RFC8972] can The STAMP "Direct Measurement" TLV (Type 5) defined in [RFC8972] can
be used in SR networks for data packet loss measurement. The STAMP be used in SR networks for data packet loss measurement. The STAMP
test packets with this TLV are transmitted using the procedures test packets with this TLV are transmitted using the procedures
described in Section 4 to collect the transmit and receive counters described in Section 4 to collect the transmit and receive counters
of the data flow for the links and end-to-end SR paths. of the data flow for the links and end-to-end SR paths.
The PSID carried in the received data packet for the traffic flow The PSID carried in the received data packet for the traffic flow
under measurement can be used to measure receive data packets (for under measurement can be used to measure receive data packets (for
receive traffic counter) for an end-to-end SR path on the STAMP receive traffic counter) for an end-to-end SR path on the Session-
Session-Reflector. The PSID in the received Session-Sender test Reflector. The PSID in the received Session-Sender test packet
packet header can be used to associate the receive traffic counter on header can be used to associate the receive traffic counter on the
the Session-Reflector for the end-to-end SR path. Session-Reflector to the end-to-end SR path.
The STAMP "Direct Measurement" TLV (Type 5) lacks the support to The STAMP "Direct Measurement" TLV (Type 5) lacks the support to
identify the Block Number of the Direct Measurement traffic counters, identify the Block Number of the Direct Measurement traffic counters,
which is required for Alternate-Marking Method [RFC8321] for accurate which is required for the Alternate-Marking Method [RFC8321] for
data packet loss metric. accurate data packet loss metric.
7. Session State for Links and SR Paths 7. STAMP Session State for Links and SR Paths
The STAMP test session state allows to know if the performance The STAMP test session state allows to know if the performance
measurement test is active. The threshold-based notification may not measurement test is active. The threshold-based notification may not
be generated if the delay values do not change significantly. For an be generated if the delay values do not change significantly. For an
unambiguous monitoring, the controller needs to distinguish the cases unambiguous monitoring, the controller needs to distinguish the cases
whether the performance measurement is active, or delay values are whether the performance measurement is active, or delay values are
not changing to cross threshold. not changing to cross threshold.
The STAMP test session state initially is declared active when one or The STAMP test session state initially is declared active when one or
more reply test packets are received at the STAMP Session-Sender. more reply test packets are received at the Session-Sender. The
The STAMP test session state is declared idle (or failed) when STAMP test session state is declared idle (or failed) when
consecutive N number of reply test packets are not received at the consecutive N number of reply test packets are not received at the
STAMP Session-Sender, where N is locally provisioned value. Session-Sender, where N is locally provisioned value. The failed
state also indicates that the connectivity verification to the
Session-Reflector has failed.
8. ECMP Support for SR Policies 8. ECMP Support for SR Policies
An SR Policy can have ECMPs between the source and transit nodes, An SR Policy can have ECMPs between the source and transit nodes,
between transit nodes and between transit and destination nodes. between transit nodes and between transit and destination nodes.
Usage of Anycast SID [RFC8402] by an SR Policy can result in ECMP Usage of Anycast SID [RFC8402] by an SR Policy can result in ECMP
paths via transit nodes part of that Anycast group. The test packets paths via transit nodes part of that Anycast group. The test packets
SHOULD be transmitted to traverse different ECMP paths to measure SHOULD be transmitted to traverse different ECMP paths to measure
end-to-end delay of an SR Policy. end-to-end delay of an SR Policy.
Forwarding plane has various hashing functions available to forward Forwarding plane has various hashing functions available to forward
packets on specific ECMP paths. The mechanisms described in packets on specific ECMP paths. The mechanisms described in
[RFC8029] and [RFC5884] for handling ECMPs are also applicable to the [RFC8029] and [RFC5884] for handling ECMPs are also applicable to the
delay measurement. delay measurement.
For SR-MPLS Policy, sweeping of MPLS entropy label [RFC6790] values For SR-MPLS Policy, sweeping of MPLS entropy label [RFC6790] values
can be used in Session-Sender test packets and Session-Reflector test can be used in Session-Sender test packets and Session-Reflector test
packets to take advantage of the hashing function in forwarding plane packets to take advantage of the hashing function in forwarding plane
to influence the ECMP path taken by them. to influence the ECMP path taken by them.
In IPv4 header of the STAMP Session-Sender test packets, sweeping of In IPv4 header of the Session-Sender test packets, sweeping of
Session-Reflector Address from the range 127/8 can be used to Session-Reflector Address from the range 127/8 can be used to
exercise ECMP paths. In this case, both the forward and the return exercise ECMP paths. In this case, both the forward and the return
paths MUST be SR-MPLS paths when using the loopback mode. paths MUST be SR-MPLS paths when using the loopback mode.
As specified in [RFC6437], Flow Label field in the outer IPv6 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. can also be used for sweeping to exercise different IPv6 ECMP paths.
The "Destination Node Address" TLV [I-D.ietf-ippm-stamp-srpm] MUST be
carried in the STAMP Session-Sender test packet to identify the
intended Session-Reflector, when using IPv4 Session-Reflector Address
from 127/8 range for a P2P SR Policy, when the STAMP test packet is
encapsulated by a tunneling protocol or an MPLS Segment List.
9. Security Considerations 9. Security Considerations
The performance measurement is intended for deployment in well- The usage of STAMP protocol is intended for deployment in limited
managed private and service provider networks. As such, it assumes domains [RFC8799]. As such, it assumes that a node involved in STAMP
that a node involved in a measurement operation has previously protocol operation has previously verified the integrity of the path
verified the integrity of the path and the identity of the far-end and the identity of the far-end Session-Reflector.
STAMP Session-Reflector.
If desired, attacks can be mitigated by performing basic validation If desired, attacks can be mitigated by performing basic validation
and sanity checks, at the STAMP Session-Sender, of the counter or and sanity checks, at the Session-Sender, of the counter or timestamp
timestamp fields in received measurement reply test packets. The fields in received measurement reply test packets. The minimal state
minimal state associated with these protocols also limits the extent associated with these protocols also limits the extent of measurement
of measurement disruption that can be caused by a corrupt or invalid disruption that can be caused by a corrupt or invalid packet to a
packet to a single test cycle. single test cycle.
Use of HMAC-SHA-256 in the authenticated mode protects the data Use of HMAC-SHA-256 in the authenticated mode protects the data
integrity of the test packets. SRv6 has HMAC protection integrity of the test packets. SRv6 can use the the HMAC protection
authentication defined for SRH [RFC8754]. Hence, test packets for authentication defined for SRH [RFC8754]. Cryptographic measures may
SRv6 may not need authentication mode. Cryptographic measures may be be enhanced by the correct configuration of access-control lists and
enhanced by the correct configuration of access-control lists and
firewalls. firewalls.
The security considerations specified in [RFC8762] and [RFC8972] also The security considerations specified in [RFC8762] and [RFC8972] also
apply to the procedures described in this document. apply to the procedures described in this document. Specifically,
the message integrity protection using HMAC, as defined in
Section 4.4 of [RFC8762] also apply to the procedure described in
this document.
The Security Considerations specified in [I-D.ietf-ippm-stamp-srpm] The Security Considerations specified in [I-D.ietf-ippm-stamp-srpm]
are also equally applicable to the procedures defined in this are also equally applicable to the procedures defined in this
document. document.
STAMP uses the well-known UDP port number that could become a target
of denial of service (DoS) or could be used to aid man-in-the-middle
(MITM) 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 in this document.
When using the procedures defined in [RFC6936], the security When using the procedures defined in [RFC6936], the security
considerations specified in [RFC6936] also apply. considerations specified in [RFC6936] also apply.
10. IANA Considerations 10. IANA Considerations
This document does not require any IANA action. This document does not require any IANA action.
11. References 11. References
11.1. Normative References 11.1. Normative References
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
DOI 10.17487/RFC0768, August 1980, DOI 10.17487/RFC0768, August 1980,
<https://www.rfc-editor.org/info/rfc768>. <https://www.rfc-editor.org/info/rfc768>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <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 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8762] Mirsky, G., Jun, G., Nydell, H., and R. Foote, "Simple [RFC8762] Mirsky, G., Jun, G., Nydell, H., and R. Foote, "Simple
Two-Way Active Measurement Protocol", RFC 8762, Two-Way Active Measurement Protocol", RFC 8762,
DOI 10.17487/RFC8762, March 2020, DOI 10.17487/RFC8762, March 2020,
<https://www.rfc-editor.org/info/rfc8762>. <https://www.rfc-editor.org/info/rfc8762>.
[RFC8972] Mirsky, G., Min, X., Nydell, H., Foote, R., Masputra, A., [RFC8972] Mirsky, G., Min, X., Nydell, H., Foote, R., Masputra, A.,
and E. Ruffini, "Simple Two-Way Active Measurement and E. Ruffini, "Simple Two-Way Active Measurement
Protocol Optional Extensions", RFC 8972, Protocol Optional Extensions", RFC 8972,
DOI 10.17487/RFC8972, January 2021, DOI 10.17487/RFC8972, January 2021,
<https://www.rfc-editor.org/info/rfc8972>. <https://www.rfc-editor.org/info/rfc8972>.
[I-D.ietf-ippm-stamp-srpm] [I-D.ietf-ippm-stamp-srpm]
Gandhi, R., Filsfils, C., Voyer, D., Chen, M., Janssens, Gandhi, R., Filsfils, C., Voyer, D., Chen, M., Janssens,
B., and R. Foote, "Simple TWAMP (STAMP) Extensions for B., and R. Foote, "Simple TWAMP (STAMP) Extensions for
Segment Routing Networks", draft-ietf-ippm-stamp-srpm-00 Segment Routing Networks", Work in Progress, Internet-
(work in progress), June 2021. Draft, draft-ietf-ippm-stamp-srpm-02, 9 September 2021,
<https://www.ietf.org/archive/id/draft-ietf-ippm-stamp-
srpm-02.txt>.
11.2. Informative References 11.2. Informative References
[IEEE1588] [IEEE1588] IEEE, "1588-2008 IEEE Standard for a Precision Clock
IEEE, "1588-2008 IEEE Standard for a Precision Clock
Synchronization Protocol for Networked Measurement and Synchronization Protocol for Networked Measurement and
Control Systems", March 2008. Control Systems", March 2008.
[RFC2113] Katz, D., "IP Router Alert Option", RFC 2113, [RFC2113] Katz, D., "IP Router Alert Option", RFC 2113,
DOI 10.17487/RFC2113, February 1997, DOI 10.17487/RFC2113, February 1997,
<https://www.rfc-editor.org/info/rfc2113>. <https://www.rfc-editor.org/info/rfc2113>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <https://www.rfc-editor.org/info/rfc4291>. 2006, <https://www.rfc-editor.org/info/rfc4291>.
skipping to change at page 20, line 24 skipping to change at page 21, line 10
[RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow,
"Bidirectional Forwarding Detection (BFD) for MPLS Label "Bidirectional Forwarding Detection (BFD) for MPLS Label
Switched Paths (LSPs)", RFC 5884, DOI 10.17487/RFC5884, Switched Paths (LSPs)", RFC 5884, DOI 10.17487/RFC5884,
June 2010, <https://www.rfc-editor.org/info/rfc5884>. June 2010, <https://www.rfc-editor.org/info/rfc5884>.
[RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme,
"IPv6 Flow Label Specification", RFC 6437, "IPv6 Flow Label Specification", RFC 6437,
DOI 10.17487/RFC6437, November 2011, DOI 10.17487/RFC6437, November 2011,
<https://www.rfc-editor.org/info/rfc6437>. <https://www.rfc-editor.org/info/rfc6437>.
[RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and
L. Yong, "The Use of Entropy Labels in MPLS Forwarding",
RFC 6790, DOI 10.17487/RFC6790, November 2012,
<https://www.rfc-editor.org/info/rfc6790>.
[RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement [RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement
for the Use of IPv6 UDP Datagrams with Zero Checksums", for the Use of IPv6 UDP Datagrams with Zero Checksums",
RFC 6936, DOI 10.17487/RFC6936, April 2013, RFC 6936, DOI 10.17487/RFC6936, April 2013,
<https://www.rfc-editor.org/info/rfc6936>. <https://www.rfc-editor.org/info/rfc6936>.
[RFC7404] Behringer, M. and E. Vyncke, "Using Only Link-Local [RFC7404] Behringer, M. and E. Vyncke, "Using Only Link-Local
Addressing inside an IPv6 Network", RFC 7404, Addressing inside an IPv6 Network", RFC 7404,
DOI 10.17487/RFC7404, November 2014, DOI 10.17487/RFC7404, November 2014,
<https://www.rfc-editor.org/info/rfc7404>. <https://www.rfc-editor.org/info/rfc7404>.
skipping to change at page 21, line 5 skipping to change at page 21, line 32
Measurement Protocol (TWAMP)", RFC 7820, Measurement Protocol (TWAMP)", RFC 7820,
DOI 10.17487/RFC7820, March 2016, DOI 10.17487/RFC7820, March 2016,
<https://www.rfc-editor.org/info/rfc7820>. <https://www.rfc-editor.org/info/rfc7820>.
[RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N.,
Aldrin, S., and M. Chen, "Detecting Multiprotocol Label Aldrin, S., and M. Chen, "Detecting Multiprotocol Label
Switched (MPLS) Data-Plane Failures", RFC 8029, Switched (MPLS) Data-Plane Failures", RFC 8029,
DOI 10.17487/RFC8029, March 2017, DOI 10.17487/RFC8029, March 2017,
<https://www.rfc-editor.org/info/rfc8029>. <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>.
[RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli, [RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli,
L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi,
"Alternate-Marking Method for Passive and Hybrid "Alternate-Marking Method for Passive and Hybrid
Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321, Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321,
January 2018, <https://www.rfc-editor.org/info/rfc8321>. January 2018, <https://www.rfc-editor.org/info/rfc8321>.
[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage
Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085,
March 2017, <https://www.rfc-editor.org/info/rfc8085>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/info/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., [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J.,
Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
(SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020,
<https://www.rfc-editor.org/info/rfc8754>. <https://www.rfc-editor.org/info/rfc8754>.
[RFC8799] Carpenter, B. and B. Liu, "Limited Domains and Internet
Protocols", RFC 8799, DOI 10.17487/RFC8799, July 2020,
<https://www.rfc-editor.org/info/rfc8799>.
[RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer,
D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 D., Matsushima, S., and Z. Li, "Segment Routing over IPv6
(SRv6) Network Programming", RFC 8986, (SRv6) Network Programming", RFC 8986,
DOI 10.17487/RFC8986, February 2021, DOI 10.17487/RFC8986, February 2021,
<https://www.rfc-editor.org/info/rfc8986>. <https://www.rfc-editor.org/info/rfc8986>.
[I-D.ietf-spring-segment-routing-policy] [I-D.ietf-spring-segment-routing-policy]
Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and
P. Mattes, "Segment Routing Policy Architecture", draft- P. Mattes, "Segment Routing Policy Architecture", Work in
ietf-spring-segment-routing-policy-11 (work in progress), Progress, Internet-Draft, draft-ietf-spring-segment-
April 2021. routing-policy-13, 28 May 2021,
<https://www.ietf.org/archive/id/draft-ietf-spring-
segment-routing-policy-13.txt>.
[I-D.ietf-spring-sr-replication-segment] [I-D.ietf-spring-sr-replication-segment]
Voyer, D., Filsfils, C., Parekh, R., Bidgoli, H., and Z. (editor), D. V., Filsfils, C., Parekh, R., Bidgoli, H.,
Zhang, "SR Replication Segment for Multi-point Service and Z. Zhang, "SR Replication Segment for Multi-point
Delivery", draft-ietf-spring-sr-replication-segment-04 Service Delivery", Work in Progress, Internet-Draft,
(work in progress), February 2021. draft-ietf-spring-sr-replication-segment-05, 20 August
2021, <https://www.ietf.org/archive/id/draft-ietf-spring-
sr-replication-segment-05.txt>.
[I-D.ietf-pim-sr-p2mp-policy] [I-D.ietf-pim-sr-p2mp-policy]
Voyer, D., Filsfils, C., Parekh, R., Bidgoli, H., and Z. (editor), D. V., Filsfils, C., Parekh, R., Bidgoli, H.,
Zhang, "Segment Routing Point-to-Multipoint Policy", and Z. Zhang, "Segment Routing Point-to-Multipoint
draft-ietf-pim-sr-p2mp-policy-02 (work in progress), Policy", Work in Progress, Internet-Draft, draft-ietf-pim-
February 2021. sr-p2mp-policy-03, 23 August 2021,
<https://www.ietf.org/archive/id/draft-ietf-pim-sr-p2mp-
policy-03.txt>.
[I-D.ietf-spring-mpls-path-segment] [I-D.ietf-spring-mpls-path-segment]
Cheng, W., Li, H., Chen, M., Gandhi, R., and R. Zigler, Cheng, W., Li, H., Chen, M., Gandhi, R., and R. Zigler,
"Path Segment in MPLS Based Segment Routing Network", "Path Segment in MPLS Based Segment Routing Network", Work
draft-ietf-spring-mpls-path-segment-04 (work in progress), in Progress, Internet-Draft, draft-ietf-spring-mpls-path-
April 2021. segment-05, 21 August 2021,
<https://www.ietf.org/archive/id/draft-ietf-spring-mpls-
path-segment-05.txt>.
[I-D.ietf-spring-srv6-path-segment] [I-D.ietf-spring-srv6-path-segment]
Li, C., Cheng, W., Chen, M., Dhody, D., and R. Gandhi, Li, C., Cheng, W., Chen, M., Dhody, D., Gandhi, R., and Y.
"Path Segment for SRv6 (Segment Routing in IPv6)", draft- Zhu, "Path Segment for SRv6 (Segment Routing in IPv6)",
ietf-spring-srv6-path-segment-00 (work in progress), Work in Progress, Internet-Draft, draft-ietf-spring-srv6-
November 2020. path-segment-02, 26 May 2021,
<https://www.ietf.org/archive/id/draft-ietf-spring-srv6-
path-segment-02.txt>.
[I-D.ietf-pce-sr-bidir-path] [I-D.ietf-pce-sr-bidir-path]
Li, C., Chen, M., Cheng, W., Gandhi, R., and Q. Xiong, Li, C., Chen, M., Cheng, W., Gandhi, R., and Q. Xiong,
"Path Computation Element Communication Protocol (PCEP) "Path Computation Element Communication Protocol (PCEP)
Extensions for Associated Bidirectional Segment Routing Extensions for Associated Bidirectional Segment Routing
(SR) Paths", draft-ietf-pce-sr-bidir-path-05 (work in (SR) Paths", Work in Progress, Internet-Draft, draft-ietf-
progress), January 2021. pce-sr-bidir-path-07, 12 July 2021,
<https://www.ietf.org/archive/id/draft-ietf-pce-sr-bidir-
path-07.txt>.
[I-D.ietf-ippm-stamp-yang] [I-D.ietf-ippm-stamp-yang]
Mirsky, G., Min, X., and W. S. Luo, "Simple Two-way Active Mirsky, G., Min, X., and W. S. Luo, "Simple Two-way Active
Measurement Protocol (STAMP) Data Model", draft-ietf-ippm- Measurement Protocol (STAMP) Data Model", Work in
stamp-yang-07 (work in progress), March 2021. Progress, Internet-Draft, draft-ietf-ippm-stamp-yang-09,
12 July 2021, <https://www.ietf.org/archive/id/draft-ietf-
ippm-stamp-yang-09.txt>.
[IEEE802.1AX] [IEEE802.1AX]
IEEE Std. 802.1AX, "IEEE Standard for Local and IEEE Std. 802.1AX, "IEEE Standard for Local and
metropolitan area networks - Link Aggregation", November metropolitan area networks - Link Aggregation", November
2008. 2008.
Acknowledgments Acknowledgments
The authors would like to thank Thierry Couture for the discussions The authors would like to thank Thierry Couture for the discussions
on the use-cases for Performance Measurement in Segment Routing. The on the use-cases for Performance Measurement in Segment Routing. The
 End of changes. 83 change blocks. 
238 lines changed or deleted 281 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/