draft-gandhi-spring-stamp-srpm-05.txt   draft-gandhi-spring-stamp-srpm-06.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: August 14, 2021 D. Voyer Expires: October 31, 2021 D. Voyer
Bell Canada Bell Canada
M. Chen M. Chen
Huawei Huawei
B. Janssens B. Janssens
Colt Colt
February 10, 2021 R. Foote
Nokia
April 29, 2021
Performance Measurement Using Simple TWAMP (STAMP) for Segment Routing Performance Measurement Using Simple TWAMP (STAMP) for Segment Routing
Networks Networks
draft-gandhi-spring-stamp-srpm-05 draft-gandhi-spring-stamp-srpm-06
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 draft-gandhi-ippm- its optional extensions defined in RFC 8972 and further augmented in
stamp-srpm. The procedure described is applicable to SR-MPLS and draft-gandhi-ippm-stamp-srpm. The procedure described is applicable
SRv6 data planes and is used for both links and end-to-end SR paths to SR-MPLS and SRv6 data planes and is used for both links and end-
including SR Policies. to-end SR paths including SR Policies.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 August 14, 2021. This Internet-Draft will expire on October 31, 2021.
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/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 27 skipping to change at page 2, line 27
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are 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. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Reference Topology . . . . . . . . . . . . . . . . . . . 4 2.2. Reference Topology . . . . . . . . . . . . . . . . . . . 4
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Example STAMP Reference Model . . . . . . . . . . . . . . 5 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 . . . . . . . . 7 4.1.1. Session-Sender Test Packet for Links . . . . . . . . 7
4.1.2. Session-Sender Test Packet for SR Paths . . . . . . . 7 4.1.2. Session-Sender Test Packet for SR Paths . . . . . . . 8
4.2. Session-Reflector Test Packet . . . . . . . . . . . . . . 9 4.2. Session-Reflector Test Packet . . . . . . . . . . . . . . 10
4.2.1. One-way Delay Measurement Mode . . . . . . . . . . . 10 4.2.1. One-way Measurement Mode . . . . . . . . . . . . . . 11
4.2.2. Two-way Delay Measurement Mode . . . . . . . . . . . 10 4.2.2. Two-way Measurement Mode . . . . . . . . . . . . . . 11
4.2.3. Round-trip Delay Measurement Mode . . . . . . . . . . 12 4.2.3. Loopback Measurement Mode . . . . . . . . . . . . . . 13
4.3. Delay Measurement for P2MP SR Policies . . . . . . . . . 13 4.3. Delay Measurement for P2MP SR Policies . . . . . . . . . 14
4.4. Additional STAMP Test Packet Processing Rules . . . . . . 14 4.4. Additional STAMP Test Packet Processing Rules . . . . . . 15
4.4.1. TTL . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.4.1. TTL . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.4.2. IPv6 Hop Limit . . . . . . . . . . . . . . . . . . . 14 4.4.2. IPv6 Hop Limit . . . . . . . . . . . . . . . . . . . 16
4.4.3. Router Alert Option . . . . . . . . . . . . . . . . . 15 4.4.3. Router Alert Option . . . . . . . . . . . . . . . . . 16
5. Packet Loss Measurement for Links and SR Paths . . . . . . . 15 4.4.4. UDP Checksum . . . . . . . . . . . . . . . . . . . . 16
6. Direct Measurement for Links and SR Paths . . . . . . . . . . 15 5. Packet Loss Measurement for Links and SR Paths . . . . . . . 16
7. Session Status for Links and SR Paths . . . . . . . . . . . . 15 6. Direct Measurement for Links and SR Paths . . . . . . . . . . 16
8. ECMP Support for SR Policies . . . . . . . . . . . . . . . . 15 7. Session State for Links and SR Paths . . . . . . . . . . . . 17
9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 8. ECMP Support for SR Policies . . . . . . . . . . . . . . . . 17
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 9. Security Considerations . . . . . . . . . . . . . . . . . . . 18
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
11.1. Normative References . . . . . . . . . . . . . . . . . . 17 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
11.2. Informative References . . . . . . . . . . . . . . . . . 17 11.1. Normative References . . . . . . . . . . . . . . . . . . 19
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 19 11.2. Informative References . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
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]. It eliminates the need for control protocol by networks [RFC8762] without the use of a control channel to pre-signal
using configuration and management model to provision and manage test session parameters. [RFC8972] defines optional extensions for STAMP.
sessions. [RFC8972] defines optional extensions for STAMP. [I-D.gandhi-ippm-stamp-srpm] augments that framework to define STAMP
[I-D.gandhi-ippm-stamp-srpm] defines STAMP extensions for SR extensions for SR networks.
networks.
The STAMP supports two modes of STAMP Session-Reflector: Stateless
and Stateful as described in Section 4 of [RFC8762]. In Stateless
mode, maintenance of each STAMP test session on Session-Reflector is
avoided. In SR networks, as the state is in the packet, the
signaling of the parameters and creating extra states in the network
are undesired. Hence, Stateless mode of Session-Reflector is
preferred in 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 optional extensions defined in [RFC8972] and further augmented in
[I-D.gandhi-ippm-stamp-srpm]. The procedure described is applicable [I-D.gandhi-ippm-stamp-srpm]. The procedure described is applicable
to SR-MPLS and SRv6 data planes and is used for both links and end- to SR-MPLS and SRv6 data planes and is used for both links and end-
to-end SR paths including SR Policies [RFC8402]. to-end SR paths including SR Policies [RFC8402].
2. Conventions Used in This Document 2. Conventions Used in This Document
2.1. Abbreviations 2.1. Abbreviations
BSID: Binding Segment ID. BSID: Binding Segment ID.
skipping to change at page 4, line 43 skipping to change at page 4, line 35
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.2. Reference Topology 2.2. Reference Topology
In the reference topology shown below, the STAMP Session-Sender R1 In the Reference Topology shown below, the STAMP Session-Sender R1
initiates a STAMP test packet and the STAMP Session-Reflector R3 initiates a STAMP test packet and the STAMP Session-Reflector R3
transmits a reply test packet. The reply test packet is transmitted transmits a reply test packet. The reply test packet may be
back to the STAMP Session-Sender R1 on the same path or a different transmitted to the STAMP Session-Sender R1 on the same path (same set
path in the reverse direction. of links and nodes) or a different path in the reverse direction from
the path taken towards the Session-Reflector.
The nodes R1 and R3 may be connected via a link or there exists 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
[I-D.ietf-spring-segment-routing-policy] on node R1 (called head-end) The nodes R1 and R3 may be connected via a link or an SR path
with destination to node R3 (called tail-end). [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 [I-D.ietf-spring-segment-routing-policy]
on node R1 (called head-end) with destination to node R3 (called
tail-end).
T1 T2 T1 T2
/ \ / \
+-------+ Test Packet +-------+ +-------+ Test Packet +-------+
| | - - - - - - - - - ->| | | | - - - - - - - - - ->| |
| R1 |=====================| R3 | | R1 |=====================| R3 |
| |<- - - - - - - - - - | | | |<- - - - - - - - - - | |
+-------+ 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 test packets For performance measurement in SR networks, the STAMP Session-Sender
defined in [RFC8762] and its optional extensions defined in [RFC8972] and Session-Reflector test packets defined in [RFC8762] are used.
and [I-D.gandhi-ippm-stamp-srpm] are used as described in this They are used in one-way, two-way (i.e. round-trip) and loopback
document. The procedures are used to measure one-way, two-way and measurement modes. Note that one-way and round-trip are referred to
round-trip delay as well as packet loss metrics in an SR network. in [RFC8762] and are further described in this document because of
the introduction of loopback measurement mode in SR networks. The
procedures defined in this document are also used to infer packet
loss in SR networks.
For performance delay and packet loss measurement, STAMP Session- The STAMP test packets are transmitted on the same path as the data
Sender test packets are transmitted in-band on the same path as the traffic flow under measurement to measure the delay and packet loss
data traffic flow under measurement to measure the delay and packet experienced by the data traffic flow.
loss experienced by the data traffic flow. It is also desired that
Session-Reflector reply test packets are transmitted in-band on the
same path in the reverse direction. This is achieved in SR networks
by using the STAMP extensions defined in
[I-D.gandhi-ippm-stamp-srpm].
A destination UDP port number is selected as described in [RFC8762]. Typically, the STAMP test packets are transmitted along an IP path
The same destination UDP port is used for link and end-to-end SR path between a Session-Sender and a Session-Reflector to measure delay and
STAMP test sessions. packet loss along that IP path. Matching the forward and reverse
direction paths for STAMP test packets, even for directly connected
nodes is 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.gandhi-ippm-stamp-srpm]. The STAMP Session-
Reflector uses the return path parameters for the reply test packet
from the received STAMP test packet, as described in
[I-D.gandhi-ippm-stamp-srpm]. This way signaling and maintaining
dynamic SR network state for the STAMP sessions on the Session-
Reflector are avoided.
The optional STAMP extensions defined in [RFC8972] are used for
direct measurement packet loss in SR networks.
3.1. Example STAMP Reference Model 3.1. Example STAMP Reference Model
An example of a STAMP reference model and typical measurement An example of a STAMP reference model with some of the typical
parameters including the destination UDP port for STAMP test session measurement parameters including the Reflector UDP port for STAMP
is shown in the following Figure 1: test session is shown in the following Figure 1:
+------------+ +------------+
| Controller | | Controller |
+------------+ +------------+
/ \ / \
Destination UDP Port / \ Destination UDP port Reflector UDP Port / \ Reflector UDP Port
Authentication Mode & Key / \ Authentication Mode & Key Authentication Mode / \ Authentication Mode
Delay Measurement Mode / \ Key-chain / \ Key-chain
Timestamp Format / \ Timestamp Format / \ Timestamp Format
Packet Loss Type / \ Packet Loss Type / \ Reflector Mode
/ \ Delay Measurement Mode / \
v v v v
+-------+ +-------+ +-------+ +-------+
| | | | | | | |
| R1 |==========| R3 | | R1 |==========| R3 |
| | | | | | | |
+-------+ +-------+ +-------+ +-------+
STAMP Session-Sender STAMP Session-Reflector STAMP Session-Sender STAMP Session-Reflector
Figure 1: Example STAMP Reference Model Figure 1: Example STAMP Reference Model
Example of the Timestamp Format is PTPv2 [IEEE1588] and NTP. Example A reflector UDP port number is selected as described in [RFC8762].
of Delay Measurement Mode is one-way, two-way and round-trip mode as The same reflector UDP port can be used for STAMP test sessions for
described in this document. Example of Packet Loss Type is round- link and end-to-end SR paths. In this case, the reflector UDP port
trip packet loss [RFC8762]. does not distinguish between link or end-to-end SR path measurements.
When using the authenticated mode for delay measurement, the matching Example of the Timestamp Format is Precision Time Protocol 64-bit
Authentication Type (e.g. HMAC-SHA-256) and Key are user-configured truncated (PTPv2) [IEEE1588] and Network Time Protocol (NTP). By
on STAMP Session-Sender and STAMP Session-Reflector [RFC8762]. default, the Session-Reflector replies in kind to the timestamp
format received in the received Session-Sender test packet, as
indicated by the "Z" field in the Error Estimate field as described
in [RFC8762].
The STAMP Session-Reflector R3 uses the timestamp format from the The Session-Reflector mode can be Stateful or Stateless as defined in
received STAMP test packet. In addition, the STAMP Session-Reflector [RFC8762].
R3 uses the parameters of the return path for the reply test packet
from the received STAMP test packet, as described in this document.
Note that the controller in the reference model is not intended for Example of Delay Measurement Mode is one-way, two-way (i.e. round-
signaling the SR parameters for STAMP test sessions between the STAMP trip) and loopback mode as described in this document.
Session-Sender and STAMP Session-Reflector. In addition, maintenance
of each STAMP test session on Session-Reflector and creating extra
state are avoided in an SR network.
The YANG data model defined in [I-D.ietf-ippm-stamp-yang] can be used Example of Packet Loss Type can be round-trip, near-end (forward) and
to provision the STAMP Session-Sender and STAMP Session-Reflector. far-end (backward) packet loss as defined in [RFC8762].
When using the authenticated mode for the STAMP test sessions, the
matching Authentication Type (e.g. HMAC-SHA-256) and Key-chain are
user-configured on STAMP Session-Sender and STAMP Session-Reflector
[RFC8762].
The controller shown in the example reference model is not intended
for the dynamic signaling of the SR parameters for STAMP test
sessions between the STAMP Session-Sender and STAMP Session-
Reflector.
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-
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 STAMP Session-Sender test packet using an
UDP header [RFC0768] is shown in Figure 2. The payload contains the UDP header [RFC0768] is shown in Figure 2. The payload contains the
STAMP Session-Sender test packet defined in [RFC8762]. STAMP Session-Sender test packet defined in [RFC8762].
+---------------------------------------------------------------+ +---------------------------------------------------------------+
| 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 Port | 862 . . Destination Port = User-configured Reflector Port | 862 .
. . . .
+---------------------------------------------------------------+ +---------------------------------------------------------------+
| Payload = Test Packet as specified in Section 4.2 of RFC 8762 | | Payload = Test Packet as specified in Section 4.2 of RFC 8762 |
. . . .
+---------------------------------------------------------------+ +---------------------------------------------------------------+
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 STAMP Session-Sender test packet as shown in Figure 2 is
transmitted over the link for delay measurement. The local and transmitted over the link under delay measurement. The local and
remote IP addresses of the link are used as Source and Destination remote IP addresses of the link are used as Source and Destination
Addresses. Addresses, respectively. For IPv6 links, the link local addresses
[RFC7404] can be used in the IPv6 header. The Session-Sender may use
the local Address Resolution Protocol (ARP) table, Neighbor
Solicitation or other bootstrap method to find the IP address for the
links and refresh. An IPv4 address from the range 127/8 or IPv6
loopback address ::1/128 [RFC4291] must not be used to IP route test
packets in a network.
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 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 IPv4 or IPv6 address is used as the Source The STAMP Session-Sender IPv4 or IPv6 address is used as the Source
Address. The SR Policy endpoint IPv4 or IPv6 address is used as the Address. The SR Policy endpoint IPv4 or IPv6 address is used as the
Destination Address. Destination Address.
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 is the range 127/8 for IPv4, or the loopback address ::1/128 for IPv6
used as the Destination Address, respectively. [RFC4291] is 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. A STAMP An SR-MPLS Policy may contain a number of Segment Lists (SLs). A
Session-Sender test packet is transmitted for each Segment List of STAMP Session-Sender test packet is transmitted for each Segment List
the SR-MPLS Policy. The content of an example STAMP Session-Sender of the SR-MPLS Policy. The content of an example STAMP Session-
test packet for an end-to-end SR-MPLS Policy is shown in Figure 3. Sender test packet for an end-to-end SR-MPLS Policy is shown in
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
. . . .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Segment(n) | TC |S| TTL | | Segment(n) | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PSID | TC |S| TTL | | PSID | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Test Packet as shown in Figure 2 | | Test Packet as shown in Figure 2 |
. . . .
+---------------------------------------------------------------+ +---------------------------------------------------------------+
Figure 3: Example Session-Sender Test Packet for SR-MPLS Policy Figure 3: Example Session-Sender Test Packet for SR-MPLS Policy
The Segment List (SL) can be empty in case of a single-hop SR-MPLS The Segment List can be empty in case of a single-hop SR-MPLS Policy
Policy 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 7. direct measurement as described in Section 6, titled "Direct
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 STAMP
Session-Sender test packet is transmitted for each Segment List of Session-Sender test packet is transmitted for each Segment List of
the SRv6 Policy. An SRv6 Policy can contain an SRv6 Segment Routing the SRv6 Policy. An SRv6 Policy can contain an SRv6 Segment Routing
Header (SRH) carrying a Segment List as described in [RFC8754]. The Header (SRH) carrying a Segment List as described in [RFC8754]. The
content of an example STAMP Session-Sender test packet for an end-to- content of an example STAMP Session-Sender test packet for an end-to-
end SRv6 Policy is shown in Figure 4. end SRv6 Policy is shown in Figure 4.
The SRv6 network programming is described in The SRv6 network programming is described in [RFC8986]. The
[I-D.ietf-spring-srv6-network-programming]. The procedure defined procedure defined for Upper-Layer Header processing for SRv6 End SIDs
for upper-layer header processing for SRv6 SIDs in in Section 4.1.1 in [RFC8986] is used to process the IPv6/UDP header
[I-D.ietf-spring-srv6-network-programming] is used to process the in the received test packets on the Session-Reflector.
IPv6/UDP 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 .
. . . .
+---------------------------------------------------------------+ +---------------------------------------------------------------+
| SRH as specified in RFC 8754 | | SRH as specified in RFC 8754 |
. <PSID, Segment List> . . <PSID, Segment List> .
. . . .
+---------------------------------------------------------------+ +---------------------------------------------------------------+
| IP Header | | IP Header |
. Source IP Address = Session-Sender IPv6 Address . . Source IP Address = Session-Sender IPv6 Address .
. Destination IP Address = Session-Reflector IPv6 Address . . Destination IP Address = Session-Reflector 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 Port | 862 . . Destination Port = User-configured Reflector Port | 862 .
. . . .
+---------------------------------------------------------------+ +---------------------------------------------------------------+
| Payload = Test Packet as specified in Section 4.2 of RFC 8762 | | Payload = Test Packet as specified in Section 4.2 of RFC 8762 |
. . . .
+---------------------------------------------------------------+ +---------------------------------------------------------------+
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 7. measurement as described in Section 6, titled "Direct Measurement for
Links and SR Paths".
4.2. Session-Reflector Test Packet 4.2. Session-Reflector Test Packet
The STAMP Session-Reflector reply test packet is transmitted using The STAMP Session-Reflector reply test packet uses the IP/UDP
the IP/UDP information from the received test packet. The content of information from the received test packet as shown in Figure 5.
an example STAMP Session-Reflector reply test packet is shown in
Figure 5.
+---------------------------------------------------------------+ +---------------------------------------------------------------+
| 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 |
. Source Port = As chosen by Session-Reflector . . Source Port = As chosen by Session-Reflector .
. Destination Port = Source Port from Received Test Packet . . Destination Port = Source Port from Received Test Packet .
. . . .
+---------------------------------------------------------------+ +---------------------------------------------------------------+
| Payload = Test Packet as specified in Section 4.3 of RFC 8762 | | Payload = Test Packet as specified in Section 4.3 of RFC 8762 |
. . . .
+---------------------------------------------------------------+ +---------------------------------------------------------------+
Figure 5: Example Session-Reflector Test Packet Figure 5: Example Session-Reflector Test Packet
4.2.1. One-way Delay 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 STAMP Session-Reflector, for both
links and SR Policies. The reply test packet may be transmitted on links and end-to-end SR Policies. The reply test packet may be
the same path or a different path in the reverse direction. transmitted on the same path or a different path in the reverse
direction.
The STAMP Session-Sender address may not be reachable via IP route The STAMP Session-Sender address may not be reachable via IP route
from the STAMP Session-Reflector. The STAMP Session-Sender in this from the STAMP Session-Reflector. The STAMP Session-Sender in this
case can send its reachability path information to the STAMP Session- case can send its reachability path information to the STAMP Session-
Reflector using the Return Path TLV defined in Reflector using the Return Path TLV defined in
[I-D.gandhi-ippm-stamp-srpm]. [I-D.gandhi-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 test packets. However, only timestamps
T1 and T2 are used to measure one-way delay as (T2 - T1). T1 and T2 are used to measure one-way delay as (T2 - T1). The one-
way delay measurement mode requires the clock on the Session-Sender
and Session-Reflector to be synchronized.
4.2.2. Two-way Delay Measurement Mode 4.2.2. Two-way Measurement Mode
In two-way delay measurement mode, a reply test packet as shown in In two-way (i.e. round-trip) delay measurement mode, a reply test
Figure 5 is transmitted by the STAMP Session-Reflector in-band on the packet as shown in Figure 5 is transmitted by the STAMP Session-
same path in the reverse direction, e.g. on the reverse direction Reflector on the same path in the reverse direction, e.g. on the
link or associated reverse SR path [I-D.ietf-pce-sr-bidir-path]. reverse direction link or associated reverse SR 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 STAMP Session-
Reflector needs to transmit the reply test packet in-band on the same Reflector needs to transmit the reply test packet on the same link
link where the test packet is received. The STAMP Session-Sender can where the test packet is received. The STAMP Session-Sender can
request in the test packet to the STAMP Session-Reflector to transmit request in the test packet to the STAMP Session-Reflector to transmit
the reply test packet back on the same link using the Control Code the reply test packet back on the same link using the Control Code
Sub-TLV in the Return Path TLV defined in Sub-TLV in the Return Path TLV defined in
[I-D.gandhi-ippm-stamp-srpm]. [I-D.gandhi-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 STAMP
Session-Reflector needs to transmit the reply test packet in-band on Session-Reflector needs to transmit the reply test packet on a
a specific reverse path. The STAMP Session-Sender can request in the specific reverse path. The STAMP Session-Sender can request in the
test packet to the STAMP Session-Reflector to transmit the reply test test packet to the STAMP Session-Reflector to transmit the reply test
packet back on a given reverse path using a Segment List sub-TLV in packet back on a given reverse path using a Segment List sub-TLV in
the Return Path TLV defined in [I-D.gandhi-ippm-stamp-srpm]. the Return Path TLV defined in [I-D.gandhi-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)). used to measure two-way delay as ((T4 - T1) - (T3 - T2)). When clock
synchronization on the Session-Sender and Session-Reflector nodes is
not possible, the one-way delay can be derived using two-way delay
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 STAMP Session-Reflector reply test packet
transmitted in-band 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
. . . .
skipping to change at page 11, line 45 skipping to change at page 13, line 8
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 STAMP Session-Reflector reply test packet
transmitted in-band 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 SIDs The procedure defined for Upper-Layer Header processing for SRv6 End
in [I-D.ietf-spring-srv6-network-programming] is also used to process SIDs in Section 4.1.1 in [RFC8986] is used to process the IPv6/UDP
the IPv6/UDP header in the received reply test packets on the header in the received reply test packets on the Session-Sender.
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 .
. . . .
+---------------------------------------------------------------+ +---------------------------------------------------------------+
| SRH as specified in RFC 8754 | | SRH as specified in RFC 8754 |
. <Segment List> . . <Segment List> .
. . . .
skipping to change at page 12, line 35 skipping to change at page 13, line 44
. Source Port = As chosen by Session-Reflector . . Source Port = As chosen by Session-Reflector .
. Destination Port = Source Port from Received Test Packet . . Destination Port = Source Port from Received Test Packet .
. . . .
+---------------------------------------------------------------+ +---------------------------------------------------------------+
| Payload = Test Packet as specified in Section 4.3 of RFC 8762 | | Payload = Test Packet as specified in Section 4.3 of RFC 8762 |
. . . .
+---------------------------------------------------------------+ +---------------------------------------------------------------+
Figure 7: Example Session-Reflector Test Packet for SRv6 Policy Figure 7: Example Session-Reflector Test Packet for SRv6 Policy
4.2.3. Round-trip Delay Measurement Mode 4.2.3. Loopback Measurement Mode
The STAMP Session-Sender test packets are sent in loopback mode to The STAMP Session-Sender test packets are transmitted in loopback
measure round-trip delay of a bidirectional path. The IP header of mode to measure loopback delay of a bidirectional circular path. In
the STAMP Session-Sender test packet contains the Destination Address this mode, the received Session-Sender test packets are not punted
equals to the STAMP Session-Sender address and the Source Address out of the fast path in forwarding (to slow path or control-plane) at
equals to the STAMP Session-Reflector address. Optionally, the STAMP the STAMP Session-Reflector. In other words, the Session-Reflector
Session-Sender test packet can carry the return path information does not process them and generate reply test packets.
(e.g. return path label stack for SR-MPLS) as part of the SR header.
This way, the received Session-Sender test packets are not punted out
of the fast path in forwarding (to slow path or control-plane) at the
STAMP Session-Reflector. Also, the Session-Reflector does not
process them and generate reply test packets.
As the reply test packet is not generated by the STAMP Session- The IP header of the STAMP Session-Sender test packet contains the
Reflector, the STAMP Session-Sender ignores the 'Session-Sender Destination Address equals to the STAMP Session-Sender address and
Sequence Number', 'Session-Sender Timestamp', 'Session-Sender Error the Source Address equals to the STAMP Session-Reflector address.
Estimate', and 'Session-Sender TTL' in the received test packet. The Session-Sender sets the Reflector UDP port that it uses to
receive the test packet. Optionally, the STAMP Session-Sender test
packet can carry the return path information (e.g. return path label
stack for SR-MPLS) as part of the SR header.
The Session-Sender can use the SSID field in the reply test packet
and/ or local configuration to know that the test session is using
the loopback mode. As the reply test packet is not generated by the
STAMP Session-Reflector, the STAMP Session-Sender ignores the
'Session-Sender Sequence Number', 'Session-Sender Timestamp',
'Session-Sender Error Estimate', and 'Session-Sender TTL' in the
received test packet. The Session-Sender sets these fields to 0 upon
transmission.
In this mode, as per Reference Topology, the timestamps T1 and T4 are In this mode, as per Reference Topology, the timestamps T1 and T4 are
collected by the test packets. Both these timestamps are used to collected by the test packets. Both these timestamps are used to
measure round-trip delay as (T4 - T1). measure loopback delay as (T4 - T1). When STAMP capability on the
Session-Reflector node is not possible, the one-way delay can be
derived using loopback delay divided by two. In this mode, the
responder node processing time component reflects only the time
required to loop the test packet from the incoming interface to the
outgoing interface in forwarding plane.
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 performance measurement described in this document The procedures for delay and loss measurement described in this
for P2P SR Policies are used for the P2MP SR Policies as listed document for end-to-end P2P SR Policies are also equally applicable
below. to the P2MP SR Policies. The procedure for one-way measurement is
defined as following:
o The STAMP Session-Sender root node transmits test packets using o The STAMP Session-Sender root node transmits test packets using
the Tree-SID defined in [I-D.ietf-pim-sr-p2mp-policy] for the P2MP the Tree-SID defined in [I-D.ietf-pim-sr-p2mp-policy] for the P2MP
SR-MPLS Policy as shown in Figure 8. The STAMP Session-Sender SR-MPLS Policy as shown in Figure 8. The STAMP Session-Sender
test packets may contain the replication SID as defined in test packets 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 is set to the loopback address from the o The Destination Address is set to the loopback address from the
range 127/8 for IPv4, or the loopback address ::1/128 for IPv6. range 127/8 for IPv4, or the loopback address ::1/128 for IPv6.
skipping to change at page 14, line 21 skipping to change at page 15, line 27
. . . .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 SR-
MPLS Policy MPLS Policy
The round-trip delay measurement for a P2MP SR-MPLS Policy can use The considerations for two-way mode for P2MP SR Policy (e.g. for co-
the Node SID of the Session-Sender in the MPLS header of the Session- routed bidirectional SR-MPLS path) are outside the scope of this
Sender test packet. 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 STAMP Session-
Sender and STAMP Session-Reflector reply test packets is set to 255, Sender and STAMP Session-Reflector test packets is set to 255, except
except in the following cases. in the following cases.
When using the Destination IPv4 Address from the range 127/8, the TTL When using the Session-Reflector IPv4 Address from the range 127/8,
field in the IPv4 header is set to 1. the TTL field in the IPv4 header is set to 1, for otherwise,
encapsulated packets.
For link delay, the TTL field in the STAMP test packet is set to 1 in For link delay, the TTL field in the STAMP test packet is set to 1 in
one-way and two-way delay measurement modes. one-way and two-way delay measurement modes.
4.4.2. IPv6 Hop Limit 4.4.2. IPv6 Hop Limit
The Hop Limit field in the IPv6 and SRH headers of the STAMP Session- The Hop Limit field in the IPv6 and SRH headers of the STAMP Session-
Sender and STAMP Session-Reflector reply test packets is set to 255, Sender and STAMP Session-Reflector test packets is set to 255, except
except in the following cases. in the following cases.
When using the Destination IPv6 Address of loopback address ::1/128, When using the Session-Reflector IPv6 Address of loopback address
the Hop Limit field in the IPv6 header is set to 1. ::1/128, the Hop Limit field in the IPv6 header is set to 1, for
otherwise, encapsulated packets.
For link delay, the Hop Limit field in the STAMP test packet is set For link delay, the Hop Limit field in the STAMP test packet is set
to 1 in one-way and two-way delay measurement modes. to 1 in one-way and two-way delay measurement modes.
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
For IPv4 test packets, where the hardware is not capable of re-
computing the UDP checksum or adding checksum complement [RFC7820],
the Session-Sender may 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 may use the procedure
defined in [RFC6936] for the UDP checksum.
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" of packet is used as described in Section 4 "Theory of Operation" where
[RFC8762], to detect forward, reverse and round-trip packet loss. Stateful and Stateless Session-Reflector operations are defined
[RFC8762], to detect round-trip, near-end (forward) and far-end
(backward) packet loss.
This method can be used for inferred packet loss measurement,
however, it does not provide accurate data packet loss metric.
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. The STAMP test packets with this TLV are be used in SR networks for data packet loss measurement. The STAMP
transmitted using the procedures described in Section 4 to collect test packets with this TLV are transmitted using the procedures
the transmit and receive counters of the data flow for the links and described in Section 4 to collect the transmit and receive counters
end-to-end SR paths. Note that in this case, the STAMP test packets of the data flow for the links and end-to-end SR paths.
may follow the same or a different path than the data flow under
direct measurement.
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
end-to-end SR path on the STAMP Session-Reflector. The PSID in the receive traffic counter) for an end-to-end SR path on the STAMP
received Session-Sender test packet header can be used to associate Session-Reflector. The PSID in the received Session-Sender test
the receive traffic counter on the Session-Reflector for the end-to- packet header can be used to associate the receive traffic counter on
end SR path. the Session-Reflector for the end-to-end SR path.
7. Session Status for Links and SR Paths The STAMP "Direct Measurement" TLV (Type 5) lacks the support to
identify the Block Number of the Direct Measurement traffic counters,
which is required for Alternate-Marking Method [RFC8321] for accurate
data packet loss metric.
The STAMP test session status allows to know if the performance 7. Session State for Links and SR Paths
measurement is active on the links and end-to-end SR paths. The
STAMP test session status initially is declared succeeded when one or The STAMP test session state allows to know if the performance
measurement test is active. The threshold-based notification may not
be generated if the delay values do not change significantly. For an
unambiguous monitoring, the controller needs to distinguish the cases
whether the performance measurement is active, or delay values are
not changing to cross threshold.
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 STAMP Session-Sender.
The STAMP test session status is declared failed when consecutive N The STAMP test session state is declared idle (or failed) when
number of reply test packets are not received at the STAMP Session- consecutive N number of reply test packets are not received at the
Sender, where N is locally provisioned value. STAMP Session-Sender, where N is locally provisioned value.
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
need to be transmitted to traverse different ECMP paths to measure need to be transmitted to traverse different ECMP paths to measure
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.
In IPv4 header of the STAMP Session-Sender test packets, sweeping of In IPv4 header of the STAMP Session-Sender test packets, sweeping of
Destination Address from the range 127/8 can be used to exercise Session-Reflector Address from the range 127/8 can be used to
particular ECMP paths. Note that in the loopback mode for round-trip exercise ECMP paths. In this case, both the forward and the return
delay measurement, both the forward and the return paths must be SR- paths must be SR-MPLS paths when using the loopback mode.
MPLS paths in this case.
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.gandhi-ippm-stamp-srpm] can The "Destination Node Address" TLV [I-D.gandhi-ippm-stamp-srpm] can
be carried in the STAMP Session-Sender test packet to identify the be carried in the STAMP Session-Sender test packet to identify the
intended destination node, for example, when using IPv4 Destination intended Session-Reflector, for example, in case of using IPv4
Address from the range 127/8. The STAMP Session-Reflector must not Session-Reflector Address from 127/8 range when the STAMP test packet
transmit reply test packet if it is not the intended destination node is encapsulated by a tunneling protocol or an MPLS Segment list. The
in the "Destination Node Address" TLV [I-D.gandhi-ippm-stamp-srpm]. STAMP Session-Reflector must not transmit reply test packet if it is
not the intended destination node in the "Destination Node Address"
TLV [I-D.gandhi-ippm-stamp-srpm].
9. Security Considerations 9. Security Considerations
The performance measurement is intended for deployment in well- The performance measurement is intended for deployment in well-
managed private and service provider networks. As such, it assumes managed private and service provider networks. As such, it assumes
that a node involved in a measurement operation has previously that a node involved in a measurement operation has previously
verified the integrity of the path and the identity of the far-end verified the integrity of the path and the identity of the far-end
STAMP 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
skipping to change at page 17, line 8 skipping to change at page 18, line 42
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 has HMAC protection
authentication defined for SRH [RFC8754]. Hence, test packets for authentication defined for SRH [RFC8754]. Hence, test packets for
SRv6 may not need authentication mode. Cryptographic measures may be SRv6 may not need authentication mode. Cryptographic measures may 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.
When using the procedures defined in [RFC6936], the security
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,
skipping to change at page 17, line 34 skipping to change at page 19, line 27
[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.gandhi-ippm-stamp-srpm] [I-D.gandhi-ippm-stamp-srpm]
Gandhi, R., Filsfils, C., Voyer, D., Chen, M., and B. Gandhi, R., Filsfils, C., Voyer, D., Chen, M., and B.
Janssens, "Simple TWAMP (STAMP) Extensions for Segment Janssens, "Simple TWAMP (STAMP) Extensions for Segment
Routing Networks", draft-gandhi-ippm-stamp-srpm-02 (work Routing Networks", draft-gandhi-ippm-stamp-srpm-03 (work
in progress), February 2021. in progress), April 2021.
[I-D.ietf-spring-srv6-network-programming]
Filsfils, C., Camarillo, P., Leddy, J., Voyer, D.,
Matsushima, S., and Z. Li, "SRv6 Network Programming",
draft-ietf-spring-srv6-network-programming-28 (work in
progress), December 2020.
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
Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <https://www.rfc-editor.org/info/rfc4291>.
[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>.
[RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement
for the Use of IPv6 UDP Datagrams with Zero Checksums",
RFC 6936, DOI 10.17487/RFC6936, April 2013,
<https://www.rfc-editor.org/info/rfc6936>.
[RFC7404] Behringer, M. and E. Vyncke, "Using Only Link-Local
Addressing inside an IPv6 Network", RFC 7404,
DOI 10.17487/RFC7404, November 2014,
<https://www.rfc-editor.org/info/rfc7404>.
[RFC7820] Mizrahi, T., "UDP Checksum Complement in the One-Way
Active Measurement Protocol (OWAMP) and Two-Way Active
Measurement Protocol (TWAMP)", RFC 7820,
DOI 10.17487/RFC7820, March 2016,
<https://www.rfc-editor.org/info/rfc7820>.
[RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., [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>.
[RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli,
L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi,
"Alternate-Marking Method for Passive and Hybrid
Performance Monitoring", RFC 8321, DOI 10.17487/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>.
[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>.
[RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer,
D., Matsushima, S., and Z. Li, "Segment Routing over IPv6
(SRv6) Network Programming", RFC 8986,
DOI 10.17487/RFC8986, February 2021,
<https://www.rfc-editor.org/info/rfc8986>.
[I-D.ietf-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", draft-
ietf-spring-segment-routing-policy-09 (work in progress), ietf-spring-segment-routing-policy-09 (work in progress),
November 2020. November 2020.
[I-D.ietf-spring-sr-replication-segment] [I-D.ietf-spring-sr-replication-segment]
Voyer, D., Filsfils, C., Parekh, R., Bidgoli, H., and Z. Voyer, D., Filsfils, C., Parekh, R., Bidgoli, H., and Z.
Zhang, "SR Replication Segment for Multi-point Service Zhang, "SR Replication Segment for Multi-point Service
Delivery", draft-ietf-spring-sr-replication-segment-02 Delivery", draft-ietf-spring-sr-replication-segment-04
(work in progress), October 2020. (work in progress), February 2021.
[I-D.ietf-pim-sr-p2mp-policy] [I-D.ietf-pim-sr-p2mp-policy]
Voyer, D., Filsfils, C., Parekh, R., Bidgoli, H., and Z. Voyer, D., Filsfils, C., Parekh, R., Bidgoli, H., and Z.
Zhang, "Segment Routing Point-to-Multipoint Policy", Zhang, "Segment Routing Point-to-Multipoint Policy",
draft-ietf-pim-sr-p2mp-policy-01 (work in progress), draft-ietf-pim-sr-p2mp-policy-02 (work in progress),
October 2020. February 2021.
[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",
draft-ietf-spring-mpls-path-segment-03 (work in progress), draft-ietf-spring-mpls-path-segment-04 (work in progress),
September 2020. April 2021.
[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., and R. Gandhi,
"Path Segment for SRv6 (Segment Routing in IPv6)", draft- "Path Segment for SRv6 (Segment Routing in IPv6)", draft-
ietf-spring-srv6-path-segment-00 (work in progress), ietf-spring-srv6-path-segment-00 (work in progress),
November 2020. November 2020.
[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", draft-ietf-pce-sr-bidir-path-05 (work in
progress), January 2021. progress), January 2021.
[I-D.ietf-ippm-stamp-yang] [I-D.ietf-ippm-stamp-yang]
Mirsky, G., Min, X., and W. Luo, "Simple Two-way Active Mirsky, G., Min, X., and W. Luo, "Simple Two-way Active
Measurement Protocol (STAMP) Data Model", draft-ietf-ippm- Measurement Protocol (STAMP) Data Model", draft-ietf-ippm-
stamp-yang-06 (work in progress), October 2020. stamp-yang-07 (work in progress), March 2021.
[IEEE802.1AX]
IEEE Std. 802.1AX, "IEEE Standard for Local and
metropolitan area networks - Link Aggregation", November
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
authors would also like to thank Greg Mirsky, Gyan Mishra, Xie authors would also like to thank Greg Mirsky, Gyan Mishra, Xie
Jingrong, and Mike Koldychev for reviewing this document and Jingrong, and Mike Koldychev for reviewing this document and
providing useful comments and suggestions. Patrick Khordoc and Radu providing useful comments and suggestions. Patrick Khordoc and Radu
Valceanu have helped improve the mechanisms described in this Valceanu have helped improve the mechanisms described in this
document. document.
skipping to change at line 891 skipping to change at page 23, line 4
Mach(Guoyi) Chen Mach(Guoyi) Chen
Huawei Huawei
Email: mach.chen@huawei.com Email: mach.chen@huawei.com
Bart Janssens Bart Janssens
Colt Colt
Email: Bart.Janssens@colt.net Email: Bart.Janssens@colt.net
Richard Foote
Nokia
Email: footer.foote@nokia.com
 End of changes. 77 change blocks. 
229 lines changed or deleted 338 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/