idnits 2.17.1 draft-gandhi-mpls-rfc6374-sr-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 25, 2020) is 1400 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 8321 (Obsoleted by RFC 9341) == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-07 == Outdated reference: A later version (-02) exists of draft-voyer-pim-sr-p2mp-policy-01 == Outdated reference: A later version (-04) exists of draft-voyer-spring-sr-replication-segment-03 == Outdated reference: A later version (-04) exists of draft-shen-spring-p2mp-transport-chain-02 == Outdated reference: A later version (-16) exists of draft-ietf-pce-binding-label-sid-03 == Outdated reference: A later version (-22) exists of draft-ietf-spring-mpls-path-segment-02 == Outdated reference: A later version (-06) exists of draft-gandhi-mpls-ioam-sr-02 == Outdated reference: A later version (-02) exists of draft-ketant-lsr-ospf-l2bundles-01 == Outdated reference: A later version (-13) exists of draft-ietf-pce-sr-bidir-path-02 Summary: 0 errors (**), 0 flaws (~~), 10 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS Working Group R. Gandhi, Ed. 3 Internet-Draft C. Filsfils 4 Intended status: Standards Track Cisco Systems, Inc. 5 Expires: December 27, 2020 D. Voyer 6 Bell Canada 7 S. Salsano 8 Universita di Roma "Tor Vergata" 9 M. Chen 10 Huawei 11 June 25, 2020 13 Performance Measurement Using RFC 6374 for Segment Routing Networks with 14 MPLS Data Plane 15 draft-gandhi-mpls-rfc6374-sr-05 17 Abstract 19 Segment Routing (SR) leverages the source routing paradigm. RFC 6374 20 specifies protocol mechanisms to enable the efficient and accurate 21 measurement of packet loss, one-way and two-way delay, as well as 22 related metrics such as delay variation in MPLS networks using probe 23 messages. This document utilizes these mechanisms for Performance 24 Delay and Loss Measurements in Segment Routing networks with MPLS 25 data plane (SR-MPLS), for both SR-MPLS Links and end-to-end Paths 26 including SR-MPLS Policies. In addition, this document defines 27 Return Path TLV for two-way performance measurement and Block Number 28 TLV for loss measurement. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on December 27, 2020. 47 Copyright Notice 49 Copyright (c) 2020 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (https://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Conventions Used in This Document . . . . . . . . . . . . . . 4 66 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 67 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4 68 2.3. Reference Topology . . . . . . . . . . . . . . . . . . . 5 69 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 4. Probe Query and Response Messages . . . . . . . . . . . . . . 6 71 4.1. Probe Message for SR-MPLS Links . . . . . . . . . . . . . 6 72 4.2. Probe Message for SR-MPLS Policies . . . . . . . . . . . 6 73 4.3. Probe Response Message for SR-MPLS Links and Policies . . 7 74 4.3.1. One-way Measurement Mode . . . . . . . . . . . . . . 7 75 4.3.2. Two-way Measurement Mode . . . . . . . . . . . . . . 8 76 4.3.3. Loopback Measurement Mode . . . . . . . . . . . . . . 8 77 4.4. Return Path TLV Extensions . . . . . . . . . . . . . . . 8 78 5. Delay Measurement . . . . . . . . . . . . . . . . . . . . . . 10 79 5.1. Delay Measurement Message Format . . . . . . . . . . . . 10 80 5.2. Timestamps . . . . . . . . . . . . . . . . . . . . . . . 10 81 6. Loss Measurement . . . . . . . . . . . . . . . . . . . . . . 10 82 6.1. Loss Measurement Message Format . . . . . . . . . . . . . 11 83 6.2. Block Number TLV Extensions . . . . . . . . . . . . . . . 11 84 6.3. Combined Loss/Delay Measurement Message Format . . . . . 12 85 7. Performance Measurement for P2MP SR-MPLS Policies . . . . . . 12 86 8. ECMP for SR-MPLS Policies . . . . . . . . . . . . . . . . . . 13 87 9. SR-MPLS Link Extended TE Metrics Advertisements . . . . . . . 14 88 10. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 14 89 11. Security Considerations . . . . . . . . . . . . . . . . . . . 14 90 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 91 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 92 13.1. Normative References . . . . . . . . . . . . . . . . . . 16 93 13.2. Informative References . . . . . . . . . . . . . . . . . 16 94 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 19 95 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 19 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 98 1. Introduction 100 Service provider's ability to satisfy Service Level Agreements (SLAs) 101 depend on the ability to measure and monitor performance metrics for 102 packet loss and one-way and two-way delay, as well as related metrics 103 such as delay variation. The ability to monitor these performance 104 metrics also provides operators with greater visibility into the 105 performance characteristics of their networks, thereby facilitating 106 planning, troubleshooting, and network performance evaluation. 108 Segment Routing (SR) leverages the source routing paradigm and 109 greatly simplifies network operations for Software Defined Networks 110 (SDNs). SR is applicable to both Multiprotocol Label Switching (SR- 111 MPLS) and IPv6 (SRv6) data planes. SR takes advantage of the Equal- 112 Cost Multipaths (ECMPs) between source and transit nodes, between 113 transit nodes and between transit and destination nodes. SR Policies 114 as defined in [I-D.ietf-spring-segment-routing-policy] are used to 115 steer traffic through a specific, user-defined paths using a stack of 116 Segments. Built-in SR Performance Measurement (PM) is one of the 117 essential requirements to provide Service Level Agreements (SLAs). 119 [RFC6374] specifies protocol mechanisms to enable the efficient and 120 accurate measurement of performance metrics in MPLS networks using 121 probe messages. The One-Way Active Measurement Protocol (OWAMP) 122 defined in [RFC4656] and Two-Way Active Measurement Protocol (TWAMP) 123 defined in [RFC5357] provide capabilities for the measurement of 124 various performance metrics in IP networks. However, mechanisms 125 defined in [RFC6374] are more suitable for Segment Routing when using 126 MPLS data plane (SR-MPLS). [RFC6374] also supports "direct mode" 127 Loss Measurement (LM), which is required in SR networks. 129 [RFC7876] specifies the procedures to be used when sending and 130 processing out-of-band performance measurement probe responses over 131 an UDP return path when receiving RFC 6374 based probe queries. 132 These procedures can be used to send out-of-band probe responses for 133 both SR-MPLS Links and Policies for one-way measurement. 135 This document utilizes the probe-based mechanisms defined in 136 [RFC6374] for Performance Delay and Loss Measurements in SR networks 137 with MPLS data plane, for both SR-MPLS Links and end-to-end Paths 138 including SR-MPLS Policies. In addition, this document defines 139 Return Path TLV for two-way performance measurement and Block Number 140 TLV for loss measurement. The Performance Measurements (PM) for SR- 141 MPLS Links are used to compute extended Traffic Engineering (TE) 142 metrics for delay and loss and can be advertised in the network using 143 the routing protocol extensions defined in [RFC7471], [RFC8570], and 144 [RFC8571]. 146 2. Conventions Used in This Document 148 2.1. Requirements Language 150 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 151 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 152 document are to be interpreted as described in [RFC2119] [RFC8174] 153 when, and only when, they appear in all capitals, as shown here. 155 2.2. Abbreviations 157 ACH: Associated Channel Header. 159 DM: Delay Measurement. 161 ECMP: Equal Cost Multi-Path. 163 G-ACh: Generic Associated Channel (G-ACh). 165 GAL: Generic Associated Channel (G-ACh) Label. 167 LM: Loss Measurement. 169 MPLS: Multiprotocol Label Switching. 171 NTP: Network Time Protocol. 173 PM: Performance Measurement. 175 PSID: Path Segment Identifier. 177 PTP: Precision Time Protocol. 179 SID: Segment ID. 181 SL: Segment List. 183 SR: Segment Routing. 185 SR-MPLS: Segment Routing with MPLS data plane. 187 TC: Traffic Class. 189 TE: Traffic Engineering. 191 URO: UDP Return Object. 193 2.3. Reference Topology 195 In the reference topology shown in Figure 1, the querier node R1 196 initiates a performance measurement probe query and the responder 197 node R5 sends a probe response message for the query message 198 received. The probe response message is typically sent back to the 199 querier node R1. 201 SR is enabled with MPLS data plane on nodes R1 and R5. The nodes R1 202 and R5 may be directly connected via a Link enabled with MPLS or 203 there exists a Point-to-Point (P2P) SR-MPLS Path e.g. Policy 204 [I-D.ietf-spring-segment-routing-policy] on node R1 (called head-end) 205 with destination to node R5 (called tail-end). 207 t1 t2 208 / \ 209 +-------+ Query +-------+ 210 | | - - - - - - - - - ->| | 211 | R1 |=====================| R5 | 212 | |<- - - - - - - - - - | | 213 +-------+ Response +-------+ 214 \ / 215 t4 t3 216 Querier Responder 218 Figure 1: Reference Topology 220 3. Overview 222 For one-way, two-way and round-trip delay measurements, the 223 procedures defined in Section 2.4 and Section 2.6 of [RFC6374] are 224 used. For transmit and receive packet loss measurements, the 225 procedures defined in Section 2.2 and Section 2.6 of [RFC6374] are 226 used. For both SR-MPLS Links and end-to-end Policies, no PM session 227 for delay or loss measurement is created on the responder node R5 228 [RFC6374]. 230 For Performance Measurement, probe query and response messages are 231 sent as following: 233 o For delay measurement, the probe messages are sent on the 234 congruent path of the data traffic by the querier node, and are 235 used to measure the delay experienced by the actual data traffic 236 flowing on the SR-MPLS Links and Policies. 238 o For loss measurement, the probe messages are sent on the congruent 239 path of the data traffic by the querier node, and are used to 240 collect the receive traffic counters for the incoming link or 241 incoming SID where the probe query messages are received at the 242 responder node (incoming link or incoming SID needed since the 243 responder node does not have PM session state present). 245 The In-Situ Operations, Administration, and Maintenance (IOAM) 246 mechanisms for SR-MPLS defined in [I-D.gandhi-mpls-ioam-sr] are used 247 to carry PM information in-band as part of the data traffic packets, 248 and are outside the scope of this document. 250 4. Probe Query and Response Messages 252 4.1. Probe Message for SR-MPLS Links 254 As described in Section 2.9.1 of [RFC6374], probe query and response 255 messages flow over the MPLS Generic Associated Channel (G-ACh). A 256 probe message for SR-MPLS Links contains G-ACh Label (GAL) (with 257 S=1). The GAL is followed by an Associated Channel Header (ACH), 258 which identifies the message type, and the message payload following 259 the ACH as shown in Figure 2. The probe messages are routed over the 260 Links for both delay and loss measurement using the same procedure 261 described in [RFC6374]. For SR-MPLS Links, the TTL value is set to 1 262 in the SR-MPLS header for one-way and two-way measurement modes. 264 0 1 2 3 265 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 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 | GAL (value 13) | TC |S| TTL | 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 |0 0 0 1|Version| Reserved | GAL Channel Type | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 Figure 2: Probe Message Header for an SR-MPLS Link 274 4.2. Probe Message for SR-MPLS Policies 276 As described in Section 2.9.1 of [RFC6374], probe query and response 277 messages flow over the MPLS Generic Associated Channel (G-ACh). A 278 probe message for an end-to-end SR-MPLS Policy measurement contains 279 SR-MPLS label stack [I-D.ietf-spring-segment-routing-policy], with 280 the G-ACh Label (GAL) at the bottom of the stack (with S=1). The GAL 281 is followed by an Associated Channel Header (ACH), which identifies 282 the message type, and the message payload following the ACH as shown 283 in Figure 3. For SR-MPLS Policies, the TTL value is set to 255 in 284 the SR-MPLS header. 286 0 1 2 3 287 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 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 | Label(1) | TC |S| TTL | 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 . . 292 . . 293 . . 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | Label(n) | TC |S| TTL | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | GAL (value 13) | TC |S| TTL | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 |0 0 0 1|Version| Reserved | GAL Channel Type | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 Figure 3: Example Probe Message Header for an End-to-end SR-MPLS 303 Policy 305 The SR-MPLS label stack can be empty (as shown in Figure 2) to 306 indicate Implicit NULL label case. 308 For SR-MPLS Policy performance measurement, in order to ensure that 309 the probe query message is processed by the intended responder node, 310 Destination Address TLV (Type 129) [RFC6374] MAY be sent in the probe 311 query message. The responder node only returns Success in Control 312 Code if it is the intended destination for the probe query. 313 Otherwise, it MUST return 0x15: Error - Invalid Destination Node 314 Identifier [RFC6374]. 316 4.3. Probe Response Message for SR-MPLS Links and Policies 318 4.3.1. One-way Measurement Mode 320 In one-way performance measurement mode [RFC7679], the querier node 321 can receive "out-of-band" probe responses by properly setting the UDP 322 Return Object (URO) TLV in the probe query message. The URO TLV 323 (Type=131) is defined in [RFC7876] and includes the UDP-Destination- 324 Port and IP Address. In particular, if the querier node sets its own 325 IP address in the URO TLV, the probe response is sent back by the 326 responder node to the querier node. In addition, the "control code" 327 in the probe query message is set to "out-of-band response 328 requested". In this delay measurement mode, as per Reference 329 Topology, timestamps t1 and t2 are collected by the probes to measure 330 one-way delay. The one-way mode is applicable to both SR-MPLS Links 331 and Policies. 333 4.3.2. Two-way Measurement Mode 335 In two-way performance measurement mode [RFC6374], when using a 336 bidirectional SR path [I-D.ietf-pce-sr-bidir-path], the probe 337 response message is sent back to the querier node on the congruent 338 path of the data traffic on the reverse direction SR-MPLS Link or 339 associated SR-MPLS Policy [I-D.ietf-pce-sr-bidir-path] using a 340 message with format similar to their probe query message. In this 341 case, the "control code" in the probe query message is set to "in- 342 band response requested". In this delay measurement mode, as per 343 Reference Topology, all timestamps t1, t2, t3, and t4 are collected 344 by the probes. All four timestamps are used to measure two-way 345 delay. The two-way mode is applicable to both SR-MPLS Links and 346 Policies. 348 Specifically, the probe response message is sent back on the incoming 349 physical interface where the probe query message is received. This 350 is useful for example, in case of two-way measurement mode for Link 351 delay. 353 The Path Segment Identifier (PSID) 354 [I-D.ietf-spring-mpls-path-segment] of the forward SR-MPLS Policy in 355 the probe query can be used to find the associated reverse SR-MPLS 356 Policy [I-D.ietf-pce-sr-bidir-path] to send the probe response 357 message for two-way measurement of SR-MPLS Policy unless when using 358 the Return Path TLV. 360 4.3.3. Loopback Measurement Mode 362 The Loopback measurement mode defined in Section 2.8 of [RFC6374] can 363 be used to measure round-trip delay for a bidirectional SR-MPLS Path 364 [I-D.ietf-pce-sr-bidir-path]. The probe query messages in this case 365 carries the reverse Path label stack as part of the MPLS header. The 366 GAL is still carried at the bottom of the label stack (with S=1). 367 The responder node does not process the probe messages and generate 368 response messages, and hence Loopback Request object (Type 3) is not 369 required for SR. In this delay measurement mode, as per Reference 370 Topology, the timestamps t1 and t4 are collected by the probes. Both 371 these timestamps are used to measure round-trip delay. 373 4.4. Return Path TLV Extensions 375 For two-way performance measurement, the responder node needs to send 376 the probe response message on a specific reverse path. The querier 377 node can request in the probe query message to the responder node to 378 send a response message back on a given reverse path (e.g. co-routed 379 path for two-way measurement). This way the destination node does 380 not require any additional SR-MPLS Policy state. 382 For one-way performance measurement, the querier node address may not 383 be reachable via IP route from the responder node. The querier node 384 in this case needs to send its reachability path information to the 385 responder node. 387 [RFC6374] defines DM and LM probe query messages that can include one 388 or more optional TLVs. New TLV Type (TBA1) is defined in this 389 document for Return Path to carry reverse path information in the 390 probe query messages (in the payload). The format of the Return Path 391 TLV is shown in Figure 4 and Figure 5: 393 0 1 2 3 394 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 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 | Type = TBA1 | Length | Reserved | 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 | Return Path Sub-TLVs | 399 . . 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 Figure 4: Return Path TLV 404 0 1 2 3 405 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 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 | Type | Length | Reserved | 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 | Label(1) | 410 . . 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 . . 413 . . 414 . . 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 | Label(n) | 417 . . 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 Figure 5: Segment List Sub-TLV in Return Path TLV 422 The Segment List Sub-TLV in the Return Path TLV can be one of the 423 following Types: 425 o Type (value 1): SR-MPLS Label Stack of the Reverse Path 426 o Type (value 2): SR-MPLS Binding SID 427 [I-D.ietf-pce-binding-label-sid] of the Reverse SR Policy 429 The Return Path TLV is a Mandatory TLV Type. The querier node MUST 430 only insert one Return Path TLV in the probe query message and the 431 responder node MUST only process the first Return Path TLV in the 432 probe query message and ignore other Return Path TLVs if present. 433 The responder node MUST send probe response message back on the 434 reverse path specified in the Return Path TLV and MUST NOT add Return 435 Path TLV in the probe response message. 437 5. Delay Measurement 439 5.1. Delay Measurement Message Format 441 As defined in [RFC6374], MPLS DM probe query and response messages 442 use Associated Channel Header (ACH) (value 0x000C for delay 443 measurement) [RFC6374], which identifies the message type, and the 444 message payload following the ACH. For both SR-MPLS Links and end- 445 to-end Policies measurements, the same MPLS DM ACH value is used. 447 The DM message payload as defined in Section 3.2 of [RFC6374] is used 448 for SR-MPLS delay measurement, for both SR-MPLS Links and end-to-end 449 Policies. 451 5.2. Timestamps 453 The Section 3.4 of [RFC6374] defines timestamp format that can be 454 used for delay measurement. The IEEE 1588 Precision Time Protocol 455 (PTP) timestamp format [IEEE1588] is used by default as described in 456 Appendix A of [RFC6374], with hardware support in Segment Routing 457 networks. 459 6. Loss Measurement 461 The LM protocol can perform two distinct kinds of loss measurement as 462 described in Section 2.9.8 of [RFC6374]. 464 o In inferred mode, LM will measure the loss of specially generated 465 test messages in order to infer the approximate data plane loss 466 level. Inferred mode LM provides only approximate loss 467 accounting. 469 o In direct mode, LM will directly measure data plane packet loss. 470 Direct mode LM provides perfect loss accounting, but may require 471 hardware support. 473 For both of these modes of LM, Path Segment Identifier (PSID) 474 [I-D.ietf-spring-mpls-path-segment] is used for accounting received 475 traffic on the egress node of the SR-MPLS Policy as shown in 476 Figure 6. Different values of PSID can be used to measure packet 477 loss per SR-MPLS Policy, per Candidate Path or per Segment List of 478 the SR Policy. 480 0 1 2 3 481 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 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 | PSID | TC |S| TTL | 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 485 | GAL (value 13) | TC |S| TTL | 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 |0 0 0 1|Version| Reserved | GAL Channel Type | 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 Figure 6: Example With Path Segment Identifier for SR-MPLS Policy 492 6.1. Loss Measurement Message Format 494 As defined in [RFC6374], MPLS LM probe query and response messages 495 use Associated Channel Header (ACH) (value 0x000A for direct loss 496 measurement or value 0x000B for inferred loss measurement), which 497 identifies the message type, and the message payload following the 498 ACH. For both SR-MPLS Links and end-to-end Policies measurements, 499 the same MPLS LM ACH value is used. 501 The LM message payload as defined in Section 3.1 of [RFC6374] is used 502 for SR-MPLS loss measurement, for both SR-MPLS Links and end-to-end 503 Policies. 505 6.2. Block Number TLV Extensions 507 The loss measurement using Alternate-Marking method defined in 508 [RFC8321] requires to color the data traffic. To be able to 509 correlate the transmit and receive traffic counters of the matching 510 color, the Block Number (or color) of the traffic counters is carried 511 by the probe query and response messages for loss measurement. The 512 probe query and response messages currently specified in [RFC6374] 513 for loss measurement do not identify the Block Number of the 514 counters. The Block Number can also be used to aggregate performance 515 metrics collected. 517 [RFC6374] defines probe query and response messages that can include 518 one or more optional TLVs. New TLV Type (value TBA2) is defined in 519 this document to carry the Block Number (8-bit) of the traffic 520 counters in the probe query and response messages for loss 521 measurement. The format of the Block Number TLV is shown in 522 Figure 7: 524 0 1 2 3 525 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 526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 527 | Type TBA2 | Length | Reserved | Block Number | 528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 530 Figure 7: Block Number TLV 532 The Block Number TLV is a Mandatory TLV Type. The querier node 533 SHOULD only insert one Block Number TLV in the probe query message 534 and the responder node in the probe response message SHOULD return 535 the first Block Number TLV from the probe query messages and ignore 536 other Block Number TLVs if present. In probe messages, the counters 537 MUST belong to the same Block Number. 539 6.3. Combined Loss/Delay Measurement Message Format 541 As defined in [RFC6374], Combined DM+LM probe query and response 542 messages use Associated Channel Header (ACH) (value 0x000D for direct 543 loss and delay measurement or value 0x000E for inferred loss and 544 delay measurement), which identifies the message type, and the 545 message payload following the ACH. For both SR-MPLS Links and end- 546 to-end Policies measurements, the same MPLS ACH value is used. 548 The message payload as defined in Section 3.3 of [RFC6374] is used 549 for SR-MPLS combined delay and loss measurement, for both SR-MPLS 550 Links and end-to-end Policies. 552 7. Performance Measurement for P2MP SR-MPLS Policies 554 The Point-to-Multipoint (P2MP) SR-MPLS Path that originates from a 555 root node terminates on multiple destinations called leaf nodes (e.g. 556 P2MP SR-MPLS Policy [I-D.voyer-pim-sr-p2mp-policy] or P2MP Transport 557 [I-D.shen-spring-p2mp-transport-chain]). 559 The procedures for delay and loss measurement described in this 560 document for P2P SR-MPLS Policies are also equally applicable to the 561 P2MP SR-MPLS Policies. The procedure for one-way measurement is 562 defined as following: 564 o The querier root node sends probe query messages using the Tree- 565 SID defined in [I-D.voyer-pim-sr-p2mp-policy] for the P2MP SR-MPLS 566 Policy as shown in Figure 8. 568 o The probe query messages can contain the replication SID as 569 defined in [I-D.voyer-spring-sr-replication-segment]. 571 o Each responder leaf node adds the "Source Address" TLV (Type 130) 572 [RFC6374] with its IP address in the probe response messages. 573 This TLV allows the querier root node to identify the responder 574 leaf nodes of the P2MP SR-MPLS Policy. 576 o The P2MP root node measures the delay and loss performance for 577 each P2MP leaf node of the end-to-end P2MP SR-MPLS Policy. 579 0 1 2 3 580 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 581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 582 | Tree-SID | TC |S| TTL | 583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 584 . . 585 . . 586 . . 587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 588 | GAL (value 13) | TC |S| TTL | 589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 590 |0 0 0 1|Version| Reserved | GAL Channel Type | 591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 593 Figure 8: Example Probe Query with Tree-SID for SR-MPLS Policy 595 The probe query messages can also be sent using the scheme defined 596 for P2MP Transport using Chain Replication that may contain Bud SID 597 as defined in [I-D.shen-spring-p2mp-transport-chain]. 599 The considerations for two-way mode for performance measurement for 600 P2MP SR-MPLS Policy (e.g. for bidirectional SR-MPLS Path) are outside 601 the scope of this document. 603 8. ECMP for SR-MPLS Policies 605 An SR-MPLS Policy can have ECMPs between the source and transit 606 nodes, between transit nodes and between transit and destination 607 nodes. Usage of Anycast SID [RFC8402] by an SR-MPLS Policy can 608 result in ECMP paths via transit nodes part of that Anycast group. 609 The probe messages need to be sent to traverse different ECMP paths 610 to measure performance delay of each of the ECMP path of an SR-MPLS 611 Policy. 613 Forwarding plane has various hashing functions available to forward 614 packets on specific ECMP paths. For SR-MPLS Policy, sweeping of 615 entropy label [RFC6790] values can be used in probe messages to take 616 advantage of the hashing function in forwarding plane to influence 617 the ECMP path taken by them. 619 The considerations for performance loss measurement for different 620 ECMP paths of an SR-MPLS Policy are outside the scope of this 621 document. 623 9. SR-MPLS Link Extended TE Metrics Advertisements 625 The extended TE metrics for SR-MPLS Link delay and loss computed 626 using the performance measurement procedures described in this 627 document can be advertised in the routing domain as follows: 629 o For OSPF, ISIS, and BGP-LS, protocol extensions defined in 630 [RFC7471], [RFC8570], and [RFC8571] are used, respectively for 631 advertising the extended TE link metrics in the network. 633 o The advertised delay-variance metric is computed as specified in 634 Section 4.2 of [RFC5481]. 636 o The extended TE link one-way delay metrics can also be computed 637 using two-way delay measurement or round-trip delay measurement 638 from loopback mode by dividing the measured delay values by 2. 640 o The extended TE link delay and loss metrics are advertised for 641 Layer 2 bundle members in OSPF [I-D.ketant-lsr-ospf-l2bundles] and 642 ISIS [RFC8668] using the same mechanisms defined in [RFC7471] and 643 [RFC8570], respectively. 645 10. Backwards Compatibility 647 The procedures defined in this document are backwards compatible with 648 the procedures defined in [RFC6374] at both querier and responder 649 nodes. If the responder does not support the new Mandatory TLV Types 650 defined in this document, it MUST return Error 0x17: Unsupported 651 Mandatory TLV Object as per [RFC6374]. 653 11. Security Considerations 655 This document describes the procedures for performance delay and loss 656 measurement for SR-MPLS networks, for both SR-MPLS Links and end-to- 657 end Policies using the mechanisms defined in [RFC6374] and [RFC7876]. 658 This document does not introduce any additional security 659 considerations other than those covered in [RFC6374], [RFC7471], 660 [RFC8570], [RFC8571], and [RFC7876]. 662 12. IANA Considerations 664 IANA is requested to allocate a value for the following Mandatory 665 Return Path TLV Type for [RFC6374] to be carried in probe query 666 message from the "MPLS Loss/Delay Measurement TLV Object" registry 667 contained within the "Generic Associated Channel (G-ACh) Parameters" 668 registry set: 670 o Type TBA1: Return Path TLV 672 IANA is requested to create a sub-registry for "Return Path Sub-TLV 673 Type" for the Return Path TLV. All code points in the range 1 674 through 32759 in this registry shall be allocated according to the 675 "IETF Review" procedure as specified in [RFC8126]. Code points in 676 the range 32760 through 65279 in this registry shall be allocated 677 according to the "First Come First Served" procedure as specified in 678 [RFC8126]. Remaining code points are allocated according to Table 1: 680 +---------------+-------------------------+-------------------------+ 681 | Value | Description | Reference | 682 +---------------+-------------------------+-------------------------+ 683 | 0- 32767 | Mandatory TLV, | IETF Review | 684 | | unassigned | | 685 | 32768 - 65279 | Optional TLV, | First Come First Served | 686 | | unassigned | | 687 | 65280 - 65519 | Experimental | This document | 688 | 65520 - 65534 | Private Use | This document | 689 | 65535 | Reserved | This document | 690 +---------------+-------------------------+-------------------------+ 692 Table 1: Return Path Sub-TLV Type Registry 694 IANA is requested to allocate the values for the following Sub-TLV 695 Types from this registry. 697 o Type (value 1): SR-MPLS Label Stack of the Reverse Path 699 o Type (value 2): SR-MPLS Binding SID 700 [I-D.ietf-pce-binding-label-sid] of the Reverse SR Policy 702 IANA is also requested to allocate a value for the following 703 Mandatory Block Number TLV Type for RFC 6374 to be carried in the 704 probe query and response messages for loss measurement from the "MPLS 705 Loss/Delay Measurement TLV Object" registry contained within the 706 "Generic Associated Channel (G-ACh) Parameters" registry set: 708 o Type TBA2: Block Number TLV 710 13. References 712 13.1. Normative References 714 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 715 Requirement Levels", BCP 14, RFC 2119, 716 DOI 10.17487/RFC2119, March 1997, 717 . 719 [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay 720 Measurement for MPLS Networks", RFC 6374, 721 DOI 10.17487/RFC6374, September 2011, 722 . 724 [RFC7876] Bryant, S., Sivabalan, S., and S. Soni, "UDP Return Path 725 for Packet Loss and Delay Measurement for MPLS Networks", 726 RFC 7876, DOI 10.17487/RFC7876, July 2016, 727 . 729 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 730 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 731 May 2017, . 733 13.2. Informative References 735 [IEEE1588] 736 IEEE, "1588-2008 IEEE Standard for a Precision Clock 737 Synchronization Protocol for Networked Measurement and 738 Control Systems", March 2008. 740 [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. 741 Zekauskas, "A One-way Active Measurement Protocol 742 (OWAMP)", RFC 4656, DOI 10.17487/RFC4656, September 2006, 743 . 745 [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. 746 Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", 747 RFC 5357, DOI 10.17487/RFC5357, October 2008, 748 . 750 [RFC5481] Morton, A. and B. Claise, "Packet Delay Variation 751 Applicability Statement", RFC 5481, DOI 10.17487/RFC5481, 752 March 2009, . 754 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 755 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 756 RFC 6790, DOI 10.17487/RFC6790, November 2012, 757 . 759 [RFC7679] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, 760 Ed., "A One-Way Delay Metric for IP Performance Metrics 761 (IPPM)", STD 81, RFC 7679, DOI 10.17487/RFC7679, January 762 2016, . 764 [RFC7471] Giacalone, S., Ward, D., Drake, J., Atlas, A., and S. 765 Previdi, "OSPF Traffic Engineering (TE) Metric 766 Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015, 767 . 769 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 770 Writing an IANA Considerations Section in RFCs", BCP 26, 771 RFC 8126, DOI 10.17487/RFC8126, June 2017, 772 . 774 [RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli, 775 L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, 776 "Alternate-Marking Method for Passive and Hybrid 777 Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321, 778 January 2018, . 780 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 781 Decraene, B., Litkowski, S., and R. Shakir, "Segment 782 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 783 July 2018, . 785 [RFC8570] Ginsberg, L., Ed., Previdi, S., Ed., Giacalone, S., Ward, 786 D., Drake, J., and Q. Wu, "IS-IS Traffic Engineering (TE) 787 Metric Extensions", RFC 8570, DOI 10.17487/RFC8570, March 788 2019, . 790 [RFC8571] Ginsberg, L., Ed., Previdi, S., Wu, Q., Tantsura, J., and 791 C. Filsfils, "BGP - Link State (BGP-LS) Advertisement of 792 IGP Traffic Engineering Performance Metric Extensions", 793 RFC 8571, DOI 10.17487/RFC8571, March 2019, 794 . 796 [RFC8668] Ginsberg, L., Ed., Bashandy, A., Filsfils, C., Nanduri, 797 M., and E. Aries, "Advertising Layer 2 Bundle Member Link 798 Attributes in IS-IS", RFC 8668, DOI 10.17487/RFC8668, 799 December 2019, . 801 [I-D.ietf-spring-segment-routing-policy] 802 Filsfils, C., Sivabalan, S., Voyer, D., Bogdanov, A., and 803 P. Mattes, "Segment Routing Policy Architecture", draft- 804 ietf-spring-segment-routing-policy-07 (work in progress), 805 May 2020. 807 [I-D.voyer-pim-sr-p2mp-policy] 808 Voyer, D., Filsfils, C., Parekh, R., Bidgoli, H., and Z. 809 Zhang, "Segment Routing Point-to-Multipoint Policy", 810 draft-voyer-pim-sr-p2mp-policy-01 (work in progress), 811 April 2020. 813 [I-D.voyer-spring-sr-replication-segment] 814 Voyer, D., Filsfils, C., Parekh, R., Bidgoli, H., and Z. 815 Zhang, "SR Replication Segment for Multi-point Service 816 Delivery", draft-voyer-spring-sr-replication-segment-03 817 (work in progress), June 2020. 819 [I-D.shen-spring-p2mp-transport-chain] 820 Shen, Y., Zhang, Z., Parekh, R., Bidgoli, H., and Y. 821 Kamite, "Point-to-Multipoint Transport Using Chain 822 Replication in Segment Routing", draft-shen-spring-p2mp- 823 transport-chain-02 (work in progress), April 2020. 825 [I-D.ietf-pce-binding-label-sid] 826 Filsfils, C., Sivabalan, S., Tantsura, J., Hardwick, J., 827 Previdi, S., and C. Li, "Carrying Binding Label/Segment-ID 828 in PCE-based Networks.", draft-ietf-pce-binding-label- 829 sid-03 (work in progress), June 2020. 831 [I-D.ietf-spring-mpls-path-segment] 832 Cheng, W., Li, H., Chen, M., Gandhi, R., and R. Zigler, 833 "Path Segment in MPLS Based Segment Routing Network", 834 draft-ietf-spring-mpls-path-segment-02 (work in progress), 835 February 2020. 837 [I-D.gandhi-mpls-ioam-sr] 838 Gandhi, R., Ali, Z., Filsfils, C., Brockners, F., Wen, B., 839 and V. Kozak, "MPLS Data Plane Encapsulation for In-situ 840 OAM Data", draft-gandhi-mpls-ioam-sr-02 (work in 841 progress), March 2020. 843 [I-D.ketant-lsr-ospf-l2bundles] 844 Talaulikar, K. and P. Psenak, "Advertising L2 Bundle 845 Member Link Attributes in OSPF", draft-ketant-lsr-ospf- 846 l2bundles-01 (work in progress), January 2020. 848 [I-D.ietf-pce-sr-bidir-path] 849 Li, C., Chen, M., Cheng, W., Gandhi, R., and Q. Xiong, 850 "PCEP Extensions for Associated Bidirectional Segment 851 Routing (SR) Paths", draft-ietf-pce-sr-bidir-path-02 (work 852 in progress), March 2020. 854 Acknowledgments 856 The authors would like to thank Thierry Couture for the discussions 857 on the use-cases for the performance measurement in segment routing 858 networks. Authors would like to thank Patrick Khordoc for 859 implementing the mechanisms defined in this document. The authors 860 would like to thank Greg Mirsky for providing many useful comments 861 and suggestions. The authors would also like to thank Stewart 862 Bryant, Sam Aldrin, Tarek Saad, and Rajiv Asati for their review 863 comments. Thanks to Huaimo Chen, Yimin Shen, and Xufeng Liu for 864 MPLS-RT expert review. 866 Contributors 868 Sagar Soni 869 Cisco Systems, Inc. 870 Email: sagsoni@cisco.com 872 Zafar Ali 873 Cisco Systems, Inc. 874 Email: zali@cisco.com 876 Pier Luigi Ventre 877 CNIT 878 Italy 879 Email: pierluigi.ventre@cnit.it 881 Authors' Addresses 883 Rakesh Gandhi (editor) 884 Cisco Systems, Inc. 885 Canada 887 Email: rgandhi@cisco.com 889 Clarence Filsfils 890 Cisco Systems, Inc. 892 Email: cfilsfil@cisco.com 894 Daniel Voyer 895 Bell Canada 897 Email: daniel.voyer@bell.ca 898 Stefano Salsano 899 Universita di Roma "Tor Vergata" 900 Italy 902 Email: stefano.salsano@uniroma2.it 904 Mach(Guoyi) Chen 905 Huawei 907 Email: mach.chen@huawei.com