]> Cisco Systems, Inc.

Canada rgandhi@cisco.com

Cisco Systems, Inc.

cfilsfil@cisco.com

Bell Canada

daniel.voyer@bell.ca

Huawei

mach.chen@huawei.com

Colt

Bart.Janssens@colt.net

Nokia

footer.foote@nokia.com

SPRING Working Group Segment Routing (SR) leverages the source routing paradigm. SR is applicable to both Multiprotocol Label Switching (SR-MPLS) and IPv6 (SRv6) data planes. This document describes procedures for Performance Measurement in SR networks using the mechanisms defined in RFC 8762 (Simple Two-Way Active Measurement Protocol (STAMP)) and its optional extensions defined in RFC 8972 and further augmented in draft-ietf-ippm-stamp-srpm. The procedure described is applicable to SR-MPLS and SRv6 data planes and is used for both links and end-to-end SR paths including SR Policies.

Introduction Segment Routing (SR) leverages the source routing paradigm and greatly simplifies network operations for Software Defined Networks (SDNs). SR is applicable to both Multiprotocol Label Switching (SR-MPLS) and IPv6 (SRv6) data planes . SR takes advantage of the Equal-Cost Multipaths (ECMPs) between source and transit nodes, between transit nodes and between transit and destination nodes. SR Policies as defined in are used to steer traffic through a specific, user-defined paths using a stack of Segments. A comprehensive SR Performance Measurement (PM) toolset is one of the essential requirements to measure network performance to provide Service Level Agreements (SLAs). The Simple Two-Way Active Measurement Protocol (STAMP) provides capabilities for the measurement of various performance metrics in IP networks without the use of a control channel to pre-signal session parameters. defines optional extensions, in the form of TLVs, for STAMP. augments that framework to define STAMP extensions for SR networks. This document describes procedures for Performance Measurement in SR networks using the mechanisms defined in STAMP and its optional extensions defined in and further augmented in . The procedure described is applicable to SR-MPLS and SRv6 data planes and is used for both links and end-to-end SR paths including SR Policies .

Conventions Used in This Document

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in when, and only when, they appear in all capitals, as shown here.

Abbreviations BSID: Binding Segment ID. DM: Delay Measurement. ECMP: Equal Cost Multi-Path. HL: Hop Limit. HMAC: Hashed Message Authentication Code. LM: Loss Measurement. MPLS: Multiprotocol Label Switching. NTP: Network Time Protocol. OWAMP: One-Way Active Measurement Protocol. PM: Performance Measurement. PSID: Path Segment Identifier. PTP: Precision Time Protocol. SHA: Secure Hash Algorithm. SID: Segment ID. SL: Segment List. SR: Segment Routing. SRH: Segment Routing Header. SR-MPLS: Segment Routing with MPLS data plane. SRv6: Segment Routing with IPv6 data plane. SSID: STAMP Session Identifier. STAMP: Simple Two-Way Active Measurement Protocol. TC: Traffic Class. TTL: Time To Live.

Reference Topology In the Reference Topology shown below, the STAMP Session-Sender S1 initiates a STAMP test packet and the STAMP Session-Reflector R1 transmits a reply STAMP test packet. The reply test packet may be transmitted to the STAMP Session-Sender S1 on the same path (same set of links and nodes) or a different path in the reverse direction from the path taken towards the Session-Reflector. The nodes S1 and R1 may be connected via a link or an SR path . The link may be a physical interface, virtual link, or Link Aggregation Group (LAG) , or LAG member link. The SR path may be an SR Policy on node S1 (called head-end) with destination to node R1 (called tail-end). | | | S1 |=====================| R1 | | |<- - - - - - - - - - | | +-------+ Reply Test Packet +-------+ \ / T4 T3 STAMP Session-Sender STAMP Session-Reflector Reference Topology ]]>

Overview For performance measurement in SR networks, the STAMP Session-Sender and Session-Reflector can use the base test packets defined . The test packets defined in , however, are preferred because of the extensions being used in SR environments. The STAMP test packets MUST be encapsulated to be transmitted on a desired path under measurement. The STAMP test packets are encapsulated using IP/UDP header and may use Destination UDP port 862 . In this document, the STAMP test packets using IP/UDP header are considered for SR networks, where the STAMP test packets are further encapsulated with an SR header. 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 referred to in 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 measure packet loss in SR networks. The procedure defined in is used to measure packet loss based on the transmission and reception of the STAMP test packets. The optional STAMP extensions defined in are used for direct measurement of packet loss in SR networks. The STAMP test packets are transmitted on the same path as the data traffic flow under measurement to measure the delay and packet loss experienced by the data traffic flow. Typically, the STAMP test packets are transmitted along an IP path between a Session-Sender and a Session-Reflector to measure delay and packet loss along that IP path. Matching 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 . The STAMP Session-Reflector uses the return path parameters for the reply test packet from the received STAMP test packet, as described in . This way signaling and maintaining dynamic SR network state for the STAMP sessions on the Session-Reflector are avoided.

Example STAMP Reference Model An example of a STAMP reference model with some of the typical measurement parameters including the Destination UDP port for STAMP test session is shown in the following Figure 1:

Example STAMP Reference Model

A Destination UDP port number MUST be selected as described in . The same Destination UDP port can be used for STAMP test sessions for link and end-to-end SR paths. In this case, the 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 truncated (PTPv2) and Network Time Protocol (NTP). By default, the Session-Reflector replies in kind to the timestamp format received in the received Session-Sender test packet, as indicated by the "Z" field in the Error Estimate field as described in . The Session-Reflector mode can be Stateful or Stateless as defined in . Example of Delay Measurement Mode is one-way, two-way (i.e. round-trip) and loopback mode as described in this document. Example of Packet Loss Type can be round-trip, near-end (forward) and far-end (backward) packet loss as defined in . When using the authenticated mode for the STAMP test sessions, the matching Authentication Type (e.g. HMAC-SHA-256) and Key-chain MUST be user-configured on STAMP Session-Sender and STAMP Session-Reflector . 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 can be used to provision the STAMP Session-Sender and STAMP Session-Reflector.

Delay Measurement for Links and SR Paths

Session-Sender Test Packet The content of an example Session-Sender test packet using an UDP header is shown in Figure 2. The payload contains the Session-Sender test packet defined in Section 3 of as transmitted in an IP network. The SR encapsulation of the STAMP test packet is further described later in this document.

Example Session-Sender Test Packet

Session-Sender Test Packet for Links The Session-Sender test packet as shown in Figure 2 is transmitted over the link under delay measurement. The local and remote IP addresses of the link are used as Source and Destination Addresses, respectively. For IPv6 links, the link local addresses 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. SR encapsulation (e.g. adjacency SID of the link) can be added for transmitting the STAMP test packets for links.

Session-Sender Test Packet for SR Paths 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 Policies. 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 STAMP test packet. The Session-Reflector (the SR Policy endpoint) IPv4 or IPv6 address MUST be used as the Destination Address in the IP header of the STAMP test packet. In the case of Color-Only Destination Steering, with IPv4 endpoint of 0.0.0.0 or IPv6 endpoint of ::0 , the loopback address from the range 127/8 for IPv4, or the loopback address ::1/128 for IPv6 can be used as the Session-Reflector Address, respectively.

Session-Sender Test Packet for SR-MPLS Policies An SR-MPLS Policy may contain a number of Segment Lists (SLs). A Session-Sender test packet MUST be transmitted for each Segment List of the SR-MPLS Policy. The content of an example Session-Sender test packet for an end-to-end SR-MPLS Policy is shown in Figure 3.

Example Session-Sender Test Packet for SR-MPLS Policy

The Segment List can be empty in case of a single-hop SR-MPLS Policy with Implicit NULL label. The Path Segment Identifier (PSID) of an SR-MPLS Policy can be carried in the MPLS header as shown in Figure 3, and can be used for direct measurement as described in Section 6, titled "Direct Measurement for Links and SR Paths".

Session-Sender Test Packet for SRv6 Policies An SRv6 Policy may contain a number of Segment Lists. Each Segment List may contain a number of SRv6 SIDs as defined in and . A Session-Sender test packet MUST be transmitted for each Segment List of the SRv6 Policy. An SRv6 Policy may contain an SRv6 Segment Routing Header (SRH) carrying a Segment List as described in . The content of an example Session-Sender test packet for an end-to-end SRv6 Policy using an SRH is shown in Figure 4. The SRv6 network programming is described in . The procedure defined for Upper-Layer Header processing for SRv6 End SIDs in Section 4.1.1 in MUST be used to process the IPv6/UDP header in the received test packets on the Session-Reflector.

Example Session-Sender Test Packet for SRv6 Policy . . Next-Header = UDP (17) . . . +---------------------------------------------------------------+ | UDP Header | . Source Port = As chosen by Session-Sender . . Destination Port = User-configured Destination Port | 862 . . . +---------------------------------------------------------------+ | Payload = Test Packet as specified in Section 3 of RFC 8972 | . in Figure 1 and Figure 3 . . . +---------------------------------------------------------------+ ]]>

The Segment List (SL) may be empty and no SRH is carried in that case. The Path Segment Identifier (PSID) of the SRV6 Policy can be carried in the SRH as shown in Figure 4 and can be used for direct measurement as described in Section 6, titled "Direct Measurement for Links and SR Paths".

Session-Reflector Test Packet The Session-Reflector reply test packet uses the IP/UDP information from the received test packet as shown in Figure 5. The payload contains the Session-Reflector test packet defined in Section 3 of .

Example Session-Reflector Test Packet

One-Way Measurement Mode In one-way delay measurement mode, a reply test packet as shown in Figure 5 is transmitted by the Session-Reflector, for both links and end-to-end SR Policies. The reply test packet MAY be transmitted on the same path or a different path in the reverse direction. The Session-Sender address may not be reachable via IP route from the Session-Reflector. The Session-Sender in this case MUST send its reachability path information to the Session-Reflector using the Return Path TLV defined in . In this mode, as per Reference Topology, all timestamps T1, T2, T3, and T4 are collected by the STAMP test packets. However, only timestamps T1 and T2 are used to measure one-way delay as (T2 - T1). The one-way delay measurement mode requires the clocks on the Session-Sender and Session-Reflector to be synchronized.

Two-Way Measurement Mode In two-way (i.e. round-trip) delay measurement mode, a reply test packet as shown in Figure 5 SHOULD be transmitted by the Session-Reflector on the same path in the reverse direction as the forward direction, e.g. on the reverse direction link or associated reverse SR path . For two-way delay measurement mode for links, the Session-Reflector MUST transmit the reply test packet on the same link where the test packet is received when the Control Code Sub-TLV is included in the test packet. The Session-Sender can request in the test packet to the Session-Reflector to transmit the reply test packet back on the same link using the Control Code Sub-TLV in the Return Path TLV defined in . For two-way delay measurement mode for end-to-end SR paths, the Session-Reflector MUST transmit the reply test packet on a specific reverse path when the Return Path TLV is included in the test packet. The Session-Sender can request in the test packet to the Session-Reflector to transmit the reply test packet back on a given reverse path using a Segment List sub-TLV in the Return Path TLV defined in . In this mode, as per Reference Topology, all timestamps T1, T2, T3, 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 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.

Session-Reflector Test Packet for SR-MPLS Policies The content of an example Session-Reflector reply test packet transmitted on the same path as the data traffic flow under measurement for two-way delay measurement of an end-to-end SR-MPLS Policy is shown in Figure 6.

Example Session-Reflector Test Packet for SR-MPLS Policy

Session-Reflector Test Packet for SRv6 Policies The content of an example Session-Reflector reply test packet transmitted on the same path as the data traffic flow under measurement for two-way delay measurement of an end-to-end SRv6 Policy using an SRH is shown in Figure 7. The procedure defined for Upper-Layer Header processing for SRv6 End SIDs in Section 4.1.1 in MUST be used to process the IPv6/UDP header in the received reply test packets on the Session-Sender.

Example Session-Reflector Test Packet for SRv6 Policy . . Next-Header = UDP (17) . . . +---------------------------------------------------------------+ | UDP Header | . Source Port = As chosen by Session-Reflector . . Destination Port = Source Port from Received Test Packet . . . +---------------------------------------------------------------+ | Payload = Test Packet as specified in Section 3 of RFC 8972 | . in Figure 2 and Figure 4 . . . +---------------------------------------------------------------+ ]]>

Loopback Measurement Mode The Session-Sender test packets are transmitted in loopback mode to measure loopback delay of a bidirectional circular path. In this mode, the received Session-Sender test packets MUST NOT be punted out of the fast path in forwarding (i.e. to slow path or control-plane) at the Session-Reflector. In other words, the Session-Reflector does not process them and generate Session-Reflector test packets. This is a new measurement mode, not defined by the STAMP process in . In this mode, as per Reference Topology, the test packet received back at the Session-Sender retrieves the timestamp T1 from the test packet and adds the received timestamp T4 locally. Both these 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. In loopback mode, the loopback delay includes the processing delay on the Session-Reflector. The Session-Reflector processing delay component includes only the time required to loop the test packet from the incoming interface to the outgoing interface in the forwarding plane.

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

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 only 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. In case of SRv6 paths, the SRH can contain the Segment List of the forward path only or both forward and the reverse paths. In the former case, an inner IPv6 header (after SRH and before the UDP header) MUST be added that contains the Destination Address equal to the Session-Sender address.

Delay Measurement for P2MP SR Policies The Point-to-Multipoint (P2MP) SR path that originates from a root node terminates on multiple destinations called leaf nodes (e.g. P2MP SR Policy ). The procedures for delay and loss measurement described in this document for end-to-end P2P SR Policies are also equally applicable to the P2MP SR Policies. The procedure for one-way measurement is defined as following:

• The Session-Sender root node transmits test packets using the Tree-SID defined in for the P2MP SR-MPLS Policy as shown in Figure 8. The Session-Sender test packets may contain the replication SID as defined in .
• The Destination Address MUST be set to the loopback address from the range 127/8 for IPv4, or the loopback address ::1/128 for IPv6.
• Each Session-Reflector leaf node MUST transmit its node address in the Source Address of the reply test packets shown in Figure 5. This allows the Session-Sender root node to identify the Session-Reflector leaf nodes of the P2MP SR Policy.
• The P2MP root node measures the delay for each P2MP leaf node individually.

Example Session-Sender Test Packet with Tree-SID for SR-MPLS Policy

The considerations for two-way measurement mode (e.g. for co-routed bidirectional SR-MPLS path) and loopback measurement mode for P2MP SR-MPLS Policy are outside the scope of this document.

Additional STAMP Test Packet Processing Rules The processing rules described in this section are applicable to the STAMP test packets for links and end-to-end SR paths including SR Policies.

TTL The TTL field in the IPv4 and MPLS headers of the Session-Sender and Session-Reflector test packet is set to 255 as per Generalized TTL Security Mechanism (GTSM) .

IPv6 Hop Limit The Hop Limit (HL) field in the IPv6 and SRH headers of the Session-Sender and Session-Reflector test packet is set to 255 as per Generalized TTL Security Mechanism (GTSM) .

Router Alert Option The Router Alert IP option (RAO) is not set in the STAMP test packets for links and end-to-end SR paths.

UDP Checksum For IPv4 test packets, where the hardware is not capable of re-computing the UDP checksum or adding checksum complement , the Session-Sender can set the UDP checksum value to 0 . For IPv6 test packets, where the hardware is not capable of re-computing the UDP checksum or adding checksum complement , the Session-Sender and Session-Reflector can use the procedure defined in for the UDP checksum for the UDP port being used for STAMP.

Destination Node Address The "Destination Node Address" TLV 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).

Packet Loss Measurement for Links and SR Paths The procedure described in Section 4 for delay measurement using 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 packet is used as described in Section 4 "Theory of Operation" where Stateful and Stateless Session-Reflector operations are defined , to detect round-trip, near-end (forward) and far-end (backward) packet loss. In the case of the loopback mode introduced in this document, only the round-trip packet loss is applicable. This method can be used for inferred packet loss measurement, however, it provides only approximate view of the data packet loss.

Direct Measurement for Links and SR Paths The STAMP "Direct Measurement" TLV (Type 5) defined in can be used in SR networks for data packet loss measurement. The STAMP test packets with this TLV are transmitted using the procedures described in Section 4 to collect the transmit and receive counters of the data flow for the links and end-to-end SR paths. In the case of the loopback mode introduced in this document, the direct measurement is not applicable. The PSID carried in the received data packet for the traffic flow under measurement can be used to measure receive data packets (for receive traffic counter) for an end-to-end SR path on the Session-Reflector. The PSID in the received Session-Sender test packet header can be used to associate the receive traffic counter on the Session-Reflector to the end-to-end SR path. 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 the Alternate-Marking Method for accurate data packet loss metric.

STAMP Session State for Links and SR Paths The STAMP test session state allows to know if the performance measurement test is active or idle. 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 a threshold. The STAMP test session state initially is declared active when one or more reply test packets are received at the Session-Sender. The STAMP test session state is declared idle (or failed) when consecutive N number of reply test packets are not received at the Session-Sender, where N is locally provisioned value. The failed state of the STAMP test session on the Session-Sender also indicates that the connectivity verification to the Session-Reflector has failed.

ECMP Support for SR Policies An SR Policy can have ECMPs between the source and transit nodes, between transit nodes and between transit and destination nodes. Usage of Anycast SID by an SR Policy can result in ECMP paths via transit nodes part of that Anycast group. The test packets SHOULD be transmitted to traverse different ECMP paths to measure end-to-end delay of an SR Policy. Forwarding plane has various hashing functions available to forward packets on specific ECMP paths. The mechanisms described in and for handling ECMPs are also applicable to the delay measurement. For SR-MPLS Policy, sweeping of MPLS entropy label values can be used in Session-Sender test packets and Session-Reflector test packets to take advantage of the hashing function in forwarding plane to influence the ECMP path taken by them. In IPv4 header of the Session-Sender test packets, sweeping of Session-Reflector Address from the range 127/8 can be used to exercise ECMP paths. In this case, both the forward and the return paths MUST be SR-MPLS paths when using the loopback mode. As specified in , Flow Label field in the outer IPv6 header can also be used for sweeping to exercise different IPv6 ECMP paths.

Security Considerations The usage of STAMP protocol is intended for deployment in limited domains . As such, it assumes that a node involved in STAMP protocol operation has previously verified the integrity of the path and the identity of the far-end Session-Reflector. If desired, attacks can be mitigated by performing basic validation and sanity checks, at the Session-Sender, of the counter or timestamp fields in received measurement reply test packets. The minimal state associated with these protocols also limits the extent of measurement disruption that can be caused by a corrupt or invalid packet to a single test cycle. Use of HMAC-SHA-256 in the authenticated mode protects the data integrity of the test packets. SRv6 can use the the HMAC protection authentication defined for SRH . Cryptographic measures may be enhanced by the correct configuration of access-control lists and firewalls. The security considerations specified in and also apply to the procedures described in this document. Specifically, the message integrity protection using HMAC, as defined in Section 4.4 of also apply to the procedure described in this document. The Security Considerations specified in are also equally applicable to the procedures defined in this document. STAMP uses the well-known UDP port number that could become a target of denial of service (DoS) or could be used to aid man-in-the-middle (MITM) attacks. Thus, the security considerations and measures to mitigate the risk of the attack documented in Section 6 of equally apply to the procedures in this document. When using the procedures defined in [RFC6936], the security considerations specified in also apply.

IANA Considerations This document does not require any IANA action.

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Load balancing is a powerful tool for engineering traffic across a network. This memo suggests ways of improving load balancing across MPLS networks using the concept of "entropy labels". It defines the concept, describes why entropy labels are useful, enumerates properties of entropy labels that allow maximal benefit, and shows how they can be signaled and used for various applications. This document updates RFCs 3031, 3107, 3209, and 5036. [STANDARDS-TRACK] RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document describes the Simple Two-way Active Measurement Protocol (STAMP), which enables the measurement of both one-way and round-trip performance metrics, like delay, delay variation, and packet loss. This document describes optional extensions to Simple Two-way Active Measurement Protocol (STAMP) that enable measurement of performance metrics. The document also defines a STAMP Test Session Identifier and thus updates RFC 8762. Cisco Systems, Inc. Cisco Systems, Inc. Bell Canada Huawei Colt Nokia Segment Routing (SR) leverages the source routing paradigm. SR is applicable to both Multiprotocol Label Switching (SR-MPLS) and IPv6 (SRv6) forwarding planes. This document specifies RFC 8762 (Simple Two-Way Active Measurement Protocol (STAMP)) extensions for SR networks, for both SR-MPLS and SRv6 forwarding planes by augmenting the optional extensions defined in RFC 8972. Informative References IEEE This memo describes a new IP Option type that alerts transit routers to more closely examine the contents of an IP packet. [STANDARDS-TRACK] This specification defines the addressing architecture of the IP Version 6 (IPv6) protocol. The document includes the IPv6 addressing model, text representations of IPv6 addresses, definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, and an IPv6 node's required addresses. This document obsoletes RFC 3513, "IP Version 6 Addressing Architecture". [STANDARDS-TRACK] The use of a packet's Time to Live (TTL) (IPv4) or Hop Limit (IPv6) to verify whether the packet was originated by an adjacent node on a connected link has been used in many recent protocols. This document generalizes this technique. This document obsoletes Experimental RFC 3682. [STANDARDS-TRACK] One desirable application of Bidirectional Forwarding Detection (BFD) is to detect a Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) data plane failure. LSP Ping is an existing mechanism for detecting MPLS data plane failures and for verifying the MPLS LSP data plane against the control plane. BFD can be used for the former, but not for the latter. However, the control plane processing required for BFD Control packets is relatively smaller than the processing required for LSP Ping messages. A combination of LSP Ping and BFD can be used to provide faster data plane failure detection and/or make it possible to provide such detection on a greater number of LSPs. This document describes the applicability of BFD in relation to LSP Ping for this application. It also describes procedures for using BFD in this environment. [STANDARDS-TRACK] This document specifies the IPv6 Flow Label field and the minimum requirements for IPv6 nodes labeling flows, IPv6 nodes forwarding labeled packets, and flow state establishment methods. Even when mentioned as examples of possible uses of the flow labeling, more detailed requirements for specific use cases are out of the scope for this document. The usage of the Flow Label field enables efficient IPv6 flow classification based only on IPv6 main header fields in fixed positions. [STANDARDS-TRACK] This document provides an applicability statement for the use of UDP transport checksums with IPv6. It defines recommendations and requirements for the use of IPv6 UDP datagrams with a zero UDP checksum. It describes the issues and design principles that need to be considered when UDP is used with IPv6 to support tunnel encapsulations, and it examines the role of the IPv6 UDP transport checksum. The document also identifies issues and constraints for deployment on network paths that include middleboxes. An appendix presents a summary of the trade-offs that were considered in evaluating the safety of the update to RFC 2460 that changes the use of the UDP checksum with IPv6. In an IPv6 network, it is possible to use only link-local addresses on infrastructure links between routers. This document discusses the advantages and disadvantages of this approach to facilitate the decision process for a given network. The One-Way Active Measurement Protocol (OWAMP) and the Two-Way Active Measurement Protocol (TWAMP) are used for performance monitoring in IP networks. Delay measurement is performed in these protocols by using timestamped test packets. Some implementations use hardware-based timestamping engines that integrate the accurate transmission time into every outgoing OWAMP/TWAMP test packet during transmission. Since these packets are transported over UDP, the UDP Checksum field is then updated to reflect this modification. This document proposes to use the last 2 octets of every test packet as a Checksum Complement, allowing timestamping engines to reflect the checksum modification in the last 2 octets rather than in the UDP Checksum field. The behavior defined in this document is completely interoperable with existing OWAMP/TWAMP implementations. This document describes a simple and efficient mechanism to detect data-plane failures in Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs). It defines a probe message called an "MPLS echo request" and a response message called an "MPLS echo reply" for returning the result of the probe. The MPLS echo request is intended to contain sufficient information to check correct operation of the data plane and to verify the data plane against the control plane, thereby localizing faults. This document obsoletes RFCs 4379, 6424, 6829, and 7537, and updates RFC 1122. The User Datagram Protocol (UDP) provides a minimal message-passing transport that has no inherent congestion control mechanisms. This document provides guidelines on the use of UDP for the designers of applications, tunnels, and other protocols that use UDP. Congestion control guidelines are a primary focus, but the document also provides guidance on other topics, including message sizes, reliability, checksums, middlebox traversal, the use of Explicit Congestion Notification (ECN), Differentiated Services Code Points (DSCPs), and ports. Because congestion control is critical to the stable operation of the Internet, applications and other protocols that choose to use UDP as an Internet transport must employ mechanisms to prevent congestion collapse and to establish some degree of fairness with concurrent traffic. They may also need to implement additional mechanisms, depending on how they use UDP. Some guidance is also applicable to the design of other protocols (e.g., protocols layered directly on IP or via IP-based tunnels), especially when these protocols do not themselves provide congestion control. This document obsoletes RFC 5405 and adds guidelines for multicast UDP usage. This document describes a method to perform packet loss, delay, and jitter measurements on live traffic. This method is based on an Alternate-Marking (coloring) technique. A report is provided in order to explain an example and show the method applicability. This technology can be applied in various situations, as detailed in this document, and could be considered Passive or Hybrid depending on the application. Segment Routing (SR) leverages the source routing paradigm. A node steers a packet through an ordered list of instructions, called "segments". A segment can represent any instruction, topological or service based. A segment can have a semantic local to an SR node or global within an SR domain. SR provides a mechanism that allows a flow to be restricted to a specific topological path, while maintaining per-flow state only at the ingress node(s) to the SR domain. SR can be directly applied to the MPLS architecture with no change to the forwarding plane. A segment is encoded as an MPLS label. An ordered list of segments is encoded as a stack of labels. The segment to process is on the top of the stack. Upon completion of a segment, the related label is popped from the stack. SR can be applied to the IPv6 architecture, with a new type of routing header. A segment is encoded as an IPv6 address. An ordered list of segments is encoded as an ordered list of IPv6 addresses in the routing header. The active segment is indicated by the Destination Address (DA) of the packet. The next active segment is indicated by a pointer in the new routing header. This memo explains the motivation and describes the reassignment of well-known ports for the One-Way Active Measurement Protocol (OWAMP) and the Two-Way Active Measurement Protocol (TWAMP) for control and measurement. It also clarifies the meaning and composition of these Standards Track protocol names for the industry. This memo updates RFCs 4656 and 5357, in terms of the UDP well-known port assignments, and it clarifies the complete OWAMP and TWAMP protocol composition for the industry. Segment Routing can be applied to the IPv6 data plane using a new type of Routing Extension Header called the Segment Routing Header (SRH). This document describes the SRH and how it is used by nodes that are Segment Routing (SR) capable. There is a noticeable trend towards network behaviors and semantics that are specific to a particular set of requirements applied within a limited region of the Internet. Policies, default parameters, the options supported, the style of network management, and security requirements may vary between such limited regions. This document reviews examples of such limited domains (also known as controlled environments), notes emerging solutions, and includes a related taxonomy. It then briefly discusses the standardization of protocols for limited domains. Finally, it shows the need for a precise definition of "limited domain membership" and for mechanisms to allow nodes to join a domain securely and to find other members, including boundary nodes. This document is the product of the research of the authors. It has been produced through discussions and consultation within the IETF but is not the product of IETF consensus. The Segment Routing over IPv6 (SRv6) Network Programming framework enables a network operator or an application to specify a packet processing program by encoding a sequence of instructions in the IPv6 packet header. Each instruction is implemented on one or several nodes in the network and identified by an SRv6 Segment Identifier in the packet. This document defines the SRv6 Network Programming concept and specifies the base set of SRv6 behaviors that enables the creation of interoperable overlays with underlay optimization. Cisco Systems, Inc. Cisco Systems, Inc. Alibaba Bell Canada Broadcom Arrcus, Inc. Nokia Barefoot Networks Marvell China Mobile Futurewei The SRv6 "micro segment" (SRv6 uSID or uSID for short) instruction is a straightforward extension of the SRv6 Network Programming model: * The SRv6 Control Plane is leveraged without any change * The SRH dataplane encapsulation is leveraged without any change * Any SID in the SID list can carry micro segments * Based on the Compressed SRv6 Segment List Encoding in SRH Cisco Systems Cisco Systems Bell Canada British Telecom Microsoft Segment Routing (SR) allows a headend node to steer a packet flow along any path. Intermediate per-path states are eliminated thanks to source routing. The headend node steers a flow into an SR Policy. The packets steered into an SR Policy carry an ordered list of segments associated with that SR Policy. This document details the concepts of SR Policy and steering into an SR Policy. Bell Canada Cisco Systems, Inc. Cisco Systems, Inc. Nokia Juniper Networks This document describes the SR Replication segment for Multi-point service delivery. A SR Replication segment allows a packet to be replicated from a Replication Node to downstream nodes. Bell Canada Cisco Systems, Inc. Cisco Systems, Inc. Nokia Juniper Networks This document describes an architecture to construct a Point-to- Multipoint (P2MP) tree to deliver Multi-point services in a Segment Routing domain. A SR P2MP tree is constructed by stitching a set of Replication segments together. A SR Point-to-Multipoint (SR P2MP) Policy is used to define and instantiate a P2MP tree which is computed by a PCE. China Mobile China Mobile Huawei Cisco Systems, Inc. Broadcom A Segment Routing (SR) path is identified by an SR segment list. Only the complete segment list can identify the end-to-end SR path, and a sub-set of segments from the segment list cannot distinguish one SR path from another as they may be partially congruent. SR path identification is a pre-requisite for various use-cases such as Performance Measurement (PM), bidirectional paths correlation, and end-to-end 1+1 path protection. In SR for MPLS data plane (SR-MPLS), the segment identifiers are stripped from the packet through label popping as the packet transits the network. This means that when a packet reaches the egress of the SR path, it is not possible to determine on which SR path it traversed the network. This document defines a new type of segment that is referred to as Path Segment, which is used to identify an SR path in an SR-MPLS network. When used, it is inserted by the ingress node of the SR path and immediately follows the last segment identifier in the segment list of the SR path. The Path Segment is preserved until it reaches the egress node for SR path identification and correlation. Huawei Technologies China Mobile Huawei Technologies Huawei Technologies China Telecom Segment Routing (SR) allows for a flexible definition of end-to-end paths by encoding an ordered list of instructions, called "segments". The SR architecture can be implemented over an MPLS data plane as well as an IPv6 data plane. Currently, Path Segment has been defined to identify an SR path in SR-MPLS networks, and is used for various use-cases such as end-to- end SR Path Protection and Performance Measurement (PM) of an SR path. This document defines the Path Segment to identify an SRv6 path in an IPv6 network. Huawei Technologies Huawei Technologies China Mobile Cisco Systems, Inc. ZTE Corporation The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Clients (PCCs) requests. Segment routing (SR) leverages the source routing and tunneling paradigms. The Stateful PCEP extensions allow stateful control of Segment Routing Traffic Engineering (TE) Paths. Furthermore, PCEP can be used for computing SR TE paths in the network. This document defines PCEP extensions for grouping two unidirectional SR Paths (one in each direction in the network) into a single associated bidirectional SR Path. The mechanisms defined in this document can also be applied using a stateful PCE for both PCE- initiated and PCC-initiated LSPs or when using a stateless PCE. ZTE Corp. ZTE Corp. Ericsson This document specifies the data model for implementations of Session-Sender and Session-Reflector for Simple Two-way Active Measurement Protocol (STAMP) mode using YANG. IEEE Std. 802.1AX

Acknowledgments The authors would like to thank Thierry Couture for the discussions on the use-cases for Performance Measurement in Segment Routing. The authors would also like to thank Greg Mirsky, Gyan Mishra, Xie Jingrong, and Mike Koldychev for reviewing this document and providing useful comments and suggestions. Patrick Khordoc and Radu Valceanu have helped improve the mechanisms described in this document.