Performance Measurement Using RFC 6374 for Segment Routing Networks with MPLS Data Plane
Internet-Draft draft-ietf-mpls-rfc6374-sr-06
Rakesh Gandhi, Ed.
Cisco Systems, Inc.
Canada
rgandhi@cisco.com
Clarence Filsfils
Cisco Systems, Inc.
cfilsfil@cisco.com
Daniel Voyer
Bell Canada
daniel.voyer@bell.ca
Stefano Salsano
Universita di Roma "Tor Vergata"
Italy
stefano.salsano@uniroma2.it
Mach(Guoyi) Chen
Huawei
mach.chen@huawei.com
23 August 2022
MPLS Working Group
Segment Routing (SR) leverages the source routing paradigm. RFC 6374 specifies protocol mechanisms to enable the efficient and accurate measurement of packet loss, one-way and two-way delay, as well as related metrics such as delay variation in MPLS networks. This document utilizes these mechanisms for Performance Delay and Loss Measurements in SR networks with MPLS data plane (SR-MPLS), for both SR-MPLS links and end-to-end SR-MPLS paths including Policies. In addition, this document defines Return Path TLV and Block Number TLV extensions for RFC 6374.
Introduction
Segment Routing (SR) leverages the source routing paradigm 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 [RFC9256] are used to steer traffic through a specific, user-defined paths using a stack of Segments. A comprehensive SR Performance Measurement (PM) toolset is one of the essential requirements to measure network performance to provide Service Level Agreements (SLAs).
[RFC6374] specifies protocol mechanisms to enable the efficient and accurate measurement of performance metrics in MPLS networks using query and response messages. [RFC7876] specifies mechanisms for sending and processing out-of-band responses over an UDP return path when receiving RFC 6374 based query messages. These mechanisms are also well-suited in SR-MPLS networks.
This document utilizes the mechanisms defined in [RFC6374] for Performance Delay and Loss Measurements in SR-MPLS networks, for both SR-MPLS links and end-to-end SR-MPLS paths including Policies. In addition, this document defines Return Path TLV and Block Number TLV extensions for [RFC6374].
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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
Abbreviations
ACH: Associated Channel Header.
DM: Delay Measurement.
ECMP: Equal Cost Multi-Path.
G-ACh: Generic Associated Channel (G-ACh).
GAL: Generic Associated Channel (G-ACh) Label.
LM: Loss Measurement.
MPLS: Multiprotocol Label Switching.
NTP: Network Time Protocol.
PM: Performance Measurement.
PSID: Path Segment Identifier.
PTP: Precision Time Protocol.
SID: Segment ID.
SL: Segment List.
SR: Segment Routing.
SR-MPLS: Segment Routing with MPLS data plane.
TC: Traffic Class.
TE: Traffic Engineering.
URO: UDP Return Object.
Reference Topology
In the reference topology shown in Figure 1, the querier node Q1 initiates a query message and the responder node R1 transmits a response message for the query message received. The response message may be sent back to the querier node Q1 in-band on the same path (same set of links and nodes) or a different path in the reverse direction.
SR is enabled with MPLS data plane on nodes Q1 and R1. The nodes Q1 and R1 may be directly connected via a link enabled with MPLS (Section 2.9.1 of [RFC6374]) or a Point-to-Point (P2P) SR-MPLS path [RFC8402]. The link may be a physical interface, virtual link, or Link Aggregation Group (LAG) [IEEE802.1AX], or LAG member link. The SR-MPLS path may be an SR-MPLS Policy [RFC9256] on node Q1 (called head-end) with destination to node R1 (called tail-end).
Reference Topology

                       T1                T2
                      /                   \
             +-------+       Query         +-------+
             |       | - - - - - - - - - ->|       |
             |   Q1  |=====================|   R1  |
             |       |<- - - - - - - - - - |       |
             +-------+       Response      +-------+
                      \                   /
                       T4                T3
              Querier                       Responder

Overview
For delay and loss measurement in SR-MPLS networks, the procedures defined in [RFC6374] are used in this document. Note that the one-way, two-way and round-trip delay measurements are defined in Section 2.4 of [RFC6374] and are further described in this document for SR-MPLS networks. Similarly, the packet loss measurement is defined in Section 2.2 of [RFC6374] and is further described in this document for SR-MPLS networks.
In SR-MPLS networks, the query and response messages defined in [RFC6374] are sent as following:
- For delay measurement, the query messages MUST be sent in-band (i.e., on the same path as data traffic) for SR-MPLS links and end-to-end SR-MPLS paths to collect transmit and receive timestamps.
- For loss measurement, the query messages MUST be sent in-band (i.e., on the same path as data traffic) for SR-MPLS links and end-to-end SR-MPLS paths to collect transmit and receive traffic counters (e.g. for traffic received on the incoming link for the link packet loss and for the incoming Path Segment Identifier (PSID) [I-D.ietf-spring-mpls-path-segment] for the end-to-end SR-MPLS path packet loss).
It may be desired in SR-MPLS networks that the same path (same set of links and nodes) between the querier and responder be used in both directions of the measurement. This is achieved by using the SR-MPLS Return Path TLV extension defined in this document.
The packet loss measurement using Alternate-Marking Method defined in [RFC8321] requires collecting Block Number of the traffic counters. This is achieved by using the Block Number TLV extension defined in this document.
The performance measurement procedure for SR-MPLS links can be used to compute extended Traffic Engineering (TE) metrics for delay and loss as described in this document. The metrics are advertised in the network using the routing protocol extensions defined in [RFC7471], [RFC8570], and [RFC8571].
Query and Response Messages
As described in Section 2.9.1 of [RFC6374], the query and response messages flow over an MPLS Generic Associated Channel (G-ACh). These query and response messages contain G-ACh Label (GAL) (value 13, with S=1). The GAL is followed by an Associated Channel Header (ACH), where Channel Type identifies the measurement message type, and the message payload following the ACH as shown in Figure 2.
RFC 6374 Query and Response Message Header

 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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |             GAL (value 13)            | TC  |S|      TTL      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |0 0 0 1|Version| Reserved      |       Channel Type            |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Query Message for SR-MPLS Links and Policies
Query Message for SR-MPLS Links
A query message as shown in Figure 2 is sent over the SR-MPLS links for both delay and loss measurement using the procedures described in [RFC6374]. For SR-MPLS links, the TTL value MUST be set to 255 in the SR-MPLS header. SR-MPLS encapsulation (e.g. using adjacency SID of the link) can be added for transmitting the query messages for SR-MPLS links.
Query Message for SR-MPLS Policies
An SR-MPLS Policy may contain a number of Segment Lists (SLs) (i.e. stack of MPLS labels) [RFC9256]. The query messages MUST be transmitted using each SL of the SR-MPLS Policy. A query message for an end-to-end SR-MPLS Policy, used for delay and/or loss measurement, contains an SR-MPLS label stack, with the G-ACh Label (GAL) at the bottom of the stack (with S=1) as shown in Figure 3. For SR-MPLS Policies, the TTL value MUST be set to 255 in the SR-MPLS header.
Example Query Message Header for an End-to-end SR-MPLS Policy

 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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                  Label(1)             | TC  |S|      TTL      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 .                                                               .
 .                                                               .
 .                                                               .
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                  Label(n)             | TC  |S|      TTL      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                  GAL (value 13)       | TC  |S|      TTL      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |0 0 0 1|Version| Reserved      |       Channel Type            |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The SR-MPLS label stack can be empty (format as shown in Figure 2) to indicate the Implicit NULL label case.
For an SR-MPLS Policy, in order to ensure that the query message is processed by the intended responder, Destination Address TLV (Type 129) [RFC6374] containing the address of the responder can be sent in the query message. The responder that supports this TLV MUST return Success in "Control Code" [RFC6374] if it is the intended destination for the query. Otherwise, it MUST return 0x15: Error - Invalid Destination Node Identifier [RFC6374]. The Destination Address TLV is applicable to P2P SR-MPLS Policy only.
Response Message for SR-MPLS Links and Policies
One-way Measurement Mode
In one-way measurement mode defined in Section 2.4 of [RFC6374], the querier can receive "out-of-band" response messages with IP/UDP header by properly setting the UDP Return Object (URO) TLV in the query message. The URO TLV (Type=131) is defined in [RFC7876] and includes the UDP-Destination-Port and IP Address. When the querier sets an IP address and an UDP port in the URO TLV, the response message MUST be sent to that IP address as the destination address and UDP port as the destination port. In addition, the "Control Code" in the query message MUST be set to "out-of-band response requested" [RFC6374].
In one-way delay measurement mode, as per Reference Topology in Figure 1, the timestamps T1 and T2 are collected by the query and response messages. Both these timestamps are used to measure one-way delay as (T2 - T1).
Two-way Measurement Mode
In two-way measurement mode defined in Section 2.4 of [RFC6374], the response messages are preferred to be sent back in-band on the same link or the same end-to-end SR-MPLS path (same set of links and nodes) in the reverse direction to the querier.
For SR-MPLS links, the response message (format as shown in Figure 2) is sent back on the same incoming link where the query message is received. In this case, the "Control Code" in the query message MUST be set to "in-band response requested" [RFC6374].
For end-to-end SR-MPLS paths, the responder transmits the response message (example as shown in Figure 3) on a specific return SR-MPLS path [I-D.ietf-pce-sr-bidir-path]. The querier can request in the query message to the responder to send the response message back on a given return path using the SR-MPLS Segment List sub-TLV in the Return Path TLV defined in this document.
In two-way delay measurement mode, as per Reference Topology in Figure 1, all four timestamps T1, T2, T3, and T4 are collected by the query and response messages. All four timestamps are used to measure two-way delay as ((T4 - T1) - (T3 - T2)).
Loopback Measurement Mode
The Loopback measurement mode defined in Section 2.8 of [RFC6374] is used to measure round-trip delay for a bidirectional circular SR-MPLS path [I-D.ietf-pce-sr-bidir-path]. In this mode, the received query messages MUST NOT be punted out of the fast path in forwarding (i.e. to slow path or control- plane) at the responder. In other words, the responder does not process the payload and generate response messages. The loopback function simply returns the received query message to the querier without responder modifications [RFC6374].
The loopback mode is done by generating "queries" with the Response flag set to 1 and adding the Loopback Request object (Type 3) [RFC6374]. The label stack in query messages in this case carry both the forward and reverse paths in the MPLS header. The GAL is still carried at the bottom of the label stack (with S=1) (example as shown in Figure 3).
In loopback delay measurement mode, as per Reference Topology in Figure 1, the timestamps T1 and T4 are collected by the query messages. Both these timestamps are used to measure round-trip delay as (T4 - T1). In this mode, the round-trip delay includes the processing delay on the responder. The responder processing delay component includes only the time required to loop the test packet from the incoming interface to the outgoing interface in forwarding plane.
Delay Measurement
Delay Measurement Message Format
As defined in [RFC6374], MPLS DM query and response messages use Associated Channel Header (ACH) (value 0x000C for delay measurement) [RFC6374], which identifies the message type, and the message payload following the ACH. For both SR-MPLS links and end-to-end SR-MPLS Policies, the same MPLS DM ACH value MUST be used.
The DM message payload as defined in Section 3.2 of [RFC6374] is used for delay measurement, for both SR-MPLS links and end-to-end SR-MPLS Policies.
Timestamps
The Section 3.4 of [RFC6374] defines timestamp format that can be used for delay measurement. The IEEE 1588 Precision Time Protocol (PTP) timestamp format [IEEE1588] is used by default as described in Appendix A of [RFC6374].
Loss Measurement
The LM protocol can perform two distinct kinds of loss measurement as described in Section 2.9.8 of [RFC6374].
- In inferred mode, LM will measure the loss of specially generated test messages in order to infer the approximate data plane loss level. Inferred mode LM provides only approximate loss accounting.
- In direct mode, LM will directly measure data plane packet loss. Direct mode LM provides perfect loss accounting, but may require hardware support.
Loss Measurement Message Format
As defined in [RFC6374], MPLS LM query and response messages use Associated Channel Header (ACH) (value 0x000A for direct loss measurement or value 0x000B for inferred loss measurement), which identifies the message type, and the message payload following the ACH. For both SR-MPLS links and end-to-end SR-MPLS Policies, the same MPLS LM ACH value MUST be used.
The LM message payload as defined in Section 3.1 of [RFC6374] is used for loss measurement, for both SR-MPLS links and end-to-end SR-MPLS Policies.
Combined Loss/Delay Measurement Message Format
As defined in [RFC6374], Combined DM+LM query and response messages use Associated Channel Header (ACH) (value 0x000D for direct loss and delay measurement or value 0x000E for inferred loss and delay measurement), which identifies the message type, and the message payload following the ACH. For both SR-MPLS links and end-to-end SR-MPLS Policies, the same MPLS DM+LM ACH value MUST be used.
The message payload as defined in Section 3.3 of [RFC6374] is used for combined delay and loss measurement, for both SR-MPLS links and end-to-end SR-MPLS Policies.
Counters
The Path Segment Identifier (PSID) [I-D.ietf-spring-mpls-path-segment] carried in the received data packet for the traffic flow under measurement can be used for accounting received traffic on the egress node of the SR-MPLS Policy. In direct mode, the PSID in the received query message as shown in Figure 4 can be used to associate the receive traffic counter on the responder to detect the transmit packet loss for the end-to-end SR-MPLS Policy.
In inferred mode, the PSID in the received query messages as shown in Figure 4 can be used to count the received query messages on the responder to detect the transmit packet loss for an end-to-end SR-MPLS Policy.
Example With Path Segment Identifier for SR-MPLS Policy

 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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                  PSID                 | TC  |S|      TTL      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                  GAL (value 13)       | TC  |S|      TTL      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |0 0 0 1|Version| Reserved      |       Channel Type            |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Different values of PSID can be used to measure packet loss per SR-MPLS Policy, per Candidate Path or per Segment List of the SR-MPLS Policy [RFC9256].
TLV Extensions
Return Path TLV Extension
In two-way measurement mode, the responder may transmit the response message on a specific return path, for example, in an ECMP environment. The querier can request in the query message to the responder to send a response message back on a given return path (e.g. co-routed SR-MPLS bidirectional path). This allows the responder to avoid creating and maintaining additional states (containing return paths) for the sessions.
The querier may not be directly reachable from the responder in a network. The querier in this case MUST send its reachability path information to the responder using the Return Path TLV.
[RFC6374] defines query and response messages those can include or more optional TLVs. New TLV Type (TBA1) is defined in this document for Return Path TLV to carry return path information in query messages. The format of the Return Path TLV is shown in Figure 5:
Return Path TLV

 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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |  Type = TBA1  |    Length     |      Reserved                 |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                    Return Path Sub-TLV                        |
 .                                                               .
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The Return Path TLV is a Mandatory TLV Type. The querier MUST only insert one Return Path TLV in the query message. The responder that supports this TLV, MUST only process the first Return Path TLV and ignore the other Return Path TLVs if present. The responder that supports this TLV, also MUST send response message back on the return path specified in the Return Path TLV. The responder also MUST NOT add Return Path TLV in the response message. The Reserved field MUST be set to 0 and MUST be ignored on the receive side.
Return Path Sub-TLV Extension
The Return Path TLV contains a Sub-TLV to carry the return path. The format of the SR-MPLS Segment List Sub-TLV is shown in Figure 6. The SR-MPLS Segment List Sub-TLV contains SR-MPLS Label Stack. The Label entries in the Segment List MUST be in network order. The SR-MPLS Segment List Sub-TLV in the Return Path TLV is of the following Type:
- Type (value 1): SR-MPLS Segment List of the Return Path
SR-MPLS Segment List Sub-TLV in Return Path TLV

 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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |    Type=1     |    Length     |      Reserved                 |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                    Label(1)                                   |
 .                                                               .
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 .                                                               .
 .                                                               .
 .                                                               .
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                    Label(n) (bottom of stack)                 |
 .                                                               .
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The SR-MPLS Label Stack contains a list of 32-bit Label Stack Entry (LSE) that includes a 20-bit label value, 8-bit TTL value, 3-bit TC value and 1-bit EOS field. An SR-MPLS Segment List Sub-TLV may carry only Binding SID label [I-D.ietf-pce-binding-label-sid] of the Return SR-MPLS Policy.
The Return Path TLV MUST carry only one Return Path Sub-TLV. The responder that supports this Sub-TLV, MUST only process the first Return Path Sub-TLV and ignore the other Return Path Sub-TLVs if present. The responder that supports this Sub-TLV, also MUST send response message back on the return path specified in the Return Path Sub-TLV. The Reserved field MUST be set to 0 and MUST be ignored on the receive side.
Note that in addition to the P2P SR-MPLS paths, the SR-MPLS Segment List Sub-TLV is also applicable to the P2MP SR-MPLS paths. For example, for P2MP SR-MPLS paths, it may only carry the Node Segment Identifier of the querier in order for the response to follow an SR-MPLS path back to the querier.
Block Number TLV Extension
The direct mode loss measurement using Alternate-Marking Method defined in [RFC8321] requires collecting Block Number of the counters for the data traffic flow under measurement. To be able to correlate the transmit and receive traffic counters of the matching Block Number, the Block Number of the traffic counters is carried in the LM query and response messages.
[RFC6374] defines query and response messages those can include one or more optional TLVs. New TLV Type (value TBA2) is defined in this document to carry the Block Number (8-bit) of the traffic counters in the LM query and response messages. The format of the Block Number TLV is shown in Figure 7:
Block Number TLV

 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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |  Type = TBA2  |    Length     | Reserved    |R| Block Number  |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The Block Number TLV is a Mandatory TLV Type. The querier MUST only insert one Block Number TLV in the query message to identify the Block Number for the traffic counters in the forward direction. The responder that supports this TLV, MUST only inert one Block Number TLV in the response message to identify the Block Number for the traffic counters in the reverse direction. The responder also MUST return the first Block Number TLV from the query message and ignore the other Block Number TLVs if present. The R Flag MUST be clear in the query message and set in the response message. The Reserved field MUST be set to 0 and MUST be ignored on the receive side.
Performance Measurement for P2MP SR-MPLS Policies
The Point-to-Multipoint (P2MP) SR-MPLS path that originates from a root node terminates on multiple destinations called leaf nodes (e.g. P2MP SR-MPLS Policy [I-D.ietf-pim-sr-p2mp-policy]).
The procedures for delay and loss measurement described in this document for end-to-end P2P SR-MPLS Policies are also equally applicable to the P2MP SR-MPLS Policies. The procedure for one-way measurement is defined as following:
- The querier root node transmits query messages using the Tree-SID defined in [I-D.ietf-pim-sr-p2mp-policy] for the P2MP SR-MPLS Policy as shown in Figure 8. The query messages may contain the replication SID as defined in [I-D.ietf-spring-sr-replication-segment].
- Each responder leaf node MUST send its node address in the "Source Address" TLV (Type 130) [RFC6374] in the response messages. This TLV allows the querier root node to identify the responder leaf nodes of the P2MP SR-MPLS Policy.
- The P2MP root node measures the delay and loss performance for each P2MP leaf node individually.
Example Query with Tree-SID for SR-MPLS Policy

 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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |              Tree-SID                 | TC  |S|      TTL      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 .                                                               .
 .                                                               .
 .                                                               .
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |              GAL (value 13)           | TC  |S|      TTL      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |0 0 0 1|Version| Reserved      |       Channel Type            |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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.
ECMP for SR-MPLS Policies
An SR-MPLS Policy can have ECMPs between the source and transit nodes, between transit nodes and between transit and destination nodes. Usage of Anycast SID [RFC8402] by an SR-MPLS Policy can result in ECMP paths via transit nodes part of that Anycast group. The query and response messages SHOULD be sent to traverse different ECMP paths to measure delay of each of the ECMP path of an SR-MPLS Policy.
Forwarding plane has various hashing functions available to forward packets on specific ECMP paths. For SR-MPLS Policy, sweeping of entropy label [RFC6790] values can be used in query and response messages to take advantage of the hashing function in forwarding plane to influence the ECMP path taken by them.
The considerations for loss measurement for different ECMP paths of an SR-MPLS Policy are outside the scope of this document.
SR-MPLS Link Extended TE Metrics Advertisements
The extended TE metrics for SR-MPLS link delay and loss can be computed using the performance measurement procedures described in this document to advertise in the routing domain as follows:
- For OSPF, ISIS, and BGP-LS, protocol extensions defined in [RFC7471], [RFC8570], and [RFC8571], respectively, are used for advertising the extended TE link delay and loss metrics in the network.
- The extended TE link delay and loss metrics are advertised for Layer-2 LAG bundle member links in OSPF [I-D.ietf-lsr-ospf-l2bundles] and ISIS [RFC8668] using the same protocol extensions defined in [RFC7471] and [RFC8570], respectively.
- The advertised delay-variance metric, Packet Delay Variation (PDV) is computed as described in Section 4.2 of [RFC5481].
- In the absence of one-way delay measurement, the extended TE link one-way delay metrics can be computed using the two-way and round-trip delay values by dividing the values by 2.
Backwards Compatibility
The procedures defined in this document are backwards compatible with the procedures defined in [RFC6374] at both querier and responder. If the responder does not support the new Mandatory TLV Types defined in this document, it MUST return Error 0x17: Unsupported Mandatory TLV Object as per [RFC6374].
Security Considerations
This document describes the procedures for performance delay and loss measurement for SR-MPLS networks, for both SR-MPLS links and end-to-end SR-MPLS Policies using the mechanisms defined in [RFC6374] and [RFC7876]. The security considerations covered in [RFC6374], [RFC7471], [RFC8570], [RFC8571], and [RFC7876] also apply to the procedures in this document.
The procedure defined in this document is intended for deployment in limited domains [RFC8799]. As such, it assumes that a querier node involved in the measurement operation has previously verified the integrity of the path and the identity of the far-end responder.
If desired, attacks can be mitigated by performing basic validation and sanity checks, at the querier, of the timestamp and counter fields in received response messages. The minimal state associated with these protocols also limits the extent of measurement disruption that can be caused by a corrupt or invalid message to a single test cycle.
The extensions defined in this document may be used for potential "proxying" attacks. For example, a querier may specify a return path that has a destination different from that of the responder. But normally, such attacks will not happen in an SR-MPLS domain where the queriers and responders belong to the same domain [RFC8799]. In order to prevent using the extension defined in this document for proxying any possible attacks, the return path has destination to the same node where the forward path is from. The responder may drop the query messages when it cannot determine whether the Return Path has the destination to the querier. That means, the querier may send a proper source address in the "Source Address" TLV according to the specified Return Path to help the responder to make that decision.
IANA Considerations
IANA is requested to allocate values for the following Mandatory TLV Types for [RFC6374] from the "MPLS Loss/Delay Measurement TLV Object" registry contained within the "Generic Associated Channel (G-ACh) Parameters" registry set:
MPLS Loss/Delay Measurement TLV Types
Value | Description | Reference
TBA1 | Return Path TLV | This document
TBA2 | Block Number TLV | This document
The Block Number TLV is carried in the query and response messages and Return Path TLV is carried in the query messages.
IANA is requested to create a sub-registry for "Return Path Sub-TLV Type". All code points in the range 1 through 175 in this registry shall be allocated according to the "IETF Review" procedure as specified in [RFC8126]. Code points in the range 176 through 239 in this registry shall be allocated according to the "First Come First Served" procedure as specified in [RFC8126]. Remaining code points are allocated according to Table 2:
Return Path Sub-TLV Type Registry
Value | Description | Reference
1 - 175 | IETF Review | This document
176 - 239 | First Come First Served | This document
240 - 251 | Experimental Use | This document
252 - 254 | Private Use | This document
This document defines the following values in the Return Path Sub-TLV Type sub-registry:
Return Path Sub-TLV Types
Value | Description | Reference
0 | Reserved | This document
1 | SR-MPLS Segment List of the Return Path | This document
255 | Reserved | This document
References
Normative References
[RFC2119]

Key words for use in RFCs to Indicate Requirement Levels
S. Bradner
March 1997
BCP 14
RFC 2119
DOI 10.17487/RFC2119
[RFC6374]

Packet Loss and Delay Measurement for MPLS Networks
D. Frost
S. Bryant
September 2011
RFC 6374
DOI 10.17487/RFC6374
[RFC7876]

UDP Return Path for Packet Loss and Delay Measurement for MPLS Networks
S. Bryant
S. Sivabalan
S. Soni
July 2016
RFC 7876
DOI 10.17487/RFC7876
[RFC8174]

Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words
B. Leiba
May 2017
BCP 14
RFC 8174
DOI 10.17487/RFC8174
Informative References
[IEEE1588]

1588-2008 IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems
IEEE
March 2008
[RFC5481]

Packet Delay Variation Applicability Statement
A. Morton
B. Claise
March 2009
RFC 5481
DOI 10.17487/RFC5481
[RFC6790]

The Use of Entropy Labels in MPLS Forwarding
K. Kompella
J. Drake
S. Amante
W. Henderickx
L. Yong
November 2012
RFC 6790
DOI 10.17487/RFC6790
[RFC7471]

OSPF Traffic Engineering (TE) Metric Extensions
S. Giacalone
D. Ward
J. Drake
A. Atlas
S. Previdi
March 2015
RFC 7471
DOI 10.17487/RFC7471
[RFC8126]

Guidelines for Writing an IANA Considerations Section in RFCs
M. Cotton
B. Leiba
T. Narten
June 2017
BCP 26
RFC 8126
DOI 10.17487/RFC8126
[RFC8321]

Alternate-Marking Method for Passive and Hybrid Performance Monitoring
G. Fioccola, Ed.
A. Capello
M. Cociglio
L. Castaldelli
M. Chen
L. Zheng
G. Mirsky
T. Mizrahi
January 2018
RFC 8321
DOI 10.17487/RFC8321
[RFC8402]

Segment Routing Architecture
C. Filsfils, Ed.
S. Previdi, Ed.
L. Ginsberg
B. Decraene
S. Litkowski
R. Shakir
July 2018
RFC 8402
DOI 10.17487/RFC8402
[RFC8570]

IS-IS Traffic Engineering (TE) Metric Extensions
L. Ginsberg, Ed.
S. Previdi, Ed.
S. Giacalone
D. Ward
J. Drake
Q. Wu
March 2019
RFC 8570
DOI 10.17487/RFC8570
[RFC8571]

BGP - Link State (BGP-LS) Advertisement of IGP Traffic Engineering Performance Metric Extensions
L. Ginsberg, Ed.
S. Previdi
Q. Wu
J. Tantsura
C. Filsfils
March 2019
RFC 8571
DOI 10.17487/RFC8571
[RFC8668]

Advertising Layer 2 Bundle Member Link Attributes in IS-IS
L. Ginsberg, Ed.
A. Bashandy
C. Filsfils
M. Nanduri
E. Aries
December 2019
RFC 8668
DOI 10.17487/RFC8668
[RFC8799]

Limited Domains and Internet Protocols
B. Carpenter
B. Liu
July 2020
RFC 8799
DOI 10.17487/RFC8799
[RFC9256]

Segment Routing Policy Architecture
Clarence Filsfils
Cisco Systems
Ketan Talaulikar
Cisco Systems
Daniel Voyer
Bell Canada
Alex Bogdanov
British Telecom
Paul Mattes
Microsoft
July 2022
RFC 9256
[I-D.ietf-pim-sr-p2mp-policy]

Segment Routing Point-to-Multipoint Policy
Daniel Voyer (editor)
Bell Canada
Clarence Filsfils
Cisco Systems, Inc.
Rishabh Parekh
Cisco Systems, Inc.
Hooman Bidgoli
Nokia
Zhaohui Zhang
Juniper Networks
02 July 2022
Internet-Draft draft-ietf-pim-sr-p2mp-policy-05
[I-D.ietf-spring-sr-replication-segment]

SR Replication Segment for Multi-point Service Delivery
Daniel Voyer (editor)
Bell Canada
Clarence Filsfils
Cisco Systems, Inc.
Rishabh Parekh
Cisco Systems, Inc.
Hooman Bidgoli
Nokia
Zhaohui Zhang
Juniper Networks
01 July 2022
Internet-Draft draft-ietf-spring-sr-replication-segment-08
[I-D.ietf-pce-binding-label-sid]

Carrying Binding Label/Segment Identifier (SID) in PCE-based Networks.
Siva Sivabalan
Ciena Corporation
Clarence Filsfils
Cisco Systems, Inc.
Jeff Tantsura
Microsoft Corporation
Stefano Previdi
Huawei Technologies
Cheng Li (editor)
Huawei Technologies
20 March 2022
Internet-Draft draft-ietf-pce-binding-label-sid-15
[I-D.ietf-spring-mpls-path-segment]

Path Segment in MPLS Based Segment Routing Network
Weiqiang Cheng
China Mobile
Han Li
China Mobile
Mach(Guoyi) Chen
Huawei
Rakesh Gandhi
Cisco Systems, Inc.
Royi Zigler
Broadcom
20 December 2021
Internet-Draft draft-ietf-spring-mpls-path-segment-07
[I-D.ietf-lsr-ospf-l2bundles]

Advertising L2 Bundle Member Link Attributes in OSPF
Ketan Talaulikar
Cisco Systems
Peter Psenak
Cisco Systems
23 May 2022
Internet-Draft draft-ietf-lsr-ospf-l2bundles-04
[I-D.ietf-pce-sr-bidir-path]

Path Computation Element Communication Protocol (PCEP) Extensions for Associated Bidirectional Segment Routing (SR) Paths
Cheng Li
Huawei Technologies
Mach(Guoyi) Chen
Huawei Technologies
Weiqiang Cheng
China Mobile
Rakesh Gandhi
Cisco Systems, Inc.
Quan Xiong
ZTE Corporation
7 March 2022
Internet-Draft draft-ietf-pce-sr-bidir-path-09
[IEEE802.1AX]

IEEE Standard for Local and metropolitan area networks - Link Aggregation
IEEE Std. 802.1AX
November 2008
Acknowledgments
The authors would like to thank Thierry Couture for the discussions on the use-cases for the performance measurement in segment routing networks. Authors would like to thank Patrick Khordoc for implementing the mechanisms defined in this document. The authors would like to thank Greg Mirsky for providing many useful comments and suggestions. The authors would also like to thank Stewart Bryant, Sam Aldrin, Tarek Saad, and Rajiv Asati for their review comments. Thanks to Huaimo Chen, Yimin Shen, and Xufeng Liu for MPLS-RT expert review.
Contributors

Sagar Soni
Cisco Systems, Inc.
Email: sagsoni@cisco.com

Zafar Ali
Cisco Systems, Inc.
Email: zali@cisco.com

Pier Luigi Ventre
CNIT
Italy
Email: pierluigi.ventre@cnit.it