idnits 2.17.1 draft-gandhi-spring-stamp-srpm-00.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 == Line 206 has weird spacing: '...esponse t3 +-...' -- The document date (March 23, 2020) is 1487 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) == Outdated reference: A later version (-13) exists of draft-ietf-6man-spring-srv6-oam-03 == Outdated reference: A later version (-10) exists of draft-ietf-ippm-stamp-option-tlv-03 -- 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-06 == Outdated reference: A later version (-04) exists of draft-voyer-spring-sr-replication-segment-02 == Outdated reference: A later version (-22) exists of draft-ietf-spring-mpls-path-segment-02 == Outdated reference: A later version (-28) exists of draft-ietf-spring-srv6-network-programming-14 == Outdated reference: A later version (-16) exists of draft-ietf-pce-binding-label-sid-02 == Outdated reference: A later version (-06) exists of draft-gandhi-mpls-ioam-sr-02 == Outdated reference: A later version (-06) exists of draft-ali-spring-ioam-srv6-02 == Outdated reference: A later version (-13) exists of draft-ietf-pce-sr-bidir-path-01 Summary: 0 errors (**), 0 flaws (~~), 12 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SPRING Working Group R. Gandhi, Ed. 3 Internet-Draft C. Filsfils 4 Intended status: Standards Track Cisco Systems, Inc. 5 Expires: September 24, 2020 D. Voyer 6 Bell Canada 7 M. Chen 8 Huawei 9 B. Janssens 10 Colt 11 March 23, 2020 13 Performance Measurement Using STAMP for Segment Routing Networks 14 draft-gandhi-spring-stamp-srpm-00 16 Abstract 18 Segment Routing (SR) leverages the source routing paradigm. SR is 19 applicable to both Multiprotocol Label Switching (SR-MPLS) and IPv6 20 (SRv6) data planes. This document specifies procedure for sending 21 and processing probe query and response messages for Performance 22 Measurement (PM) in Segment Routing networks. The procedure uses the 23 mechanisms defined in RFC 8762 (Simple Two-Way Active Measurement 24 Protocol (STAMP)) for Delay Measurement, and uses the mechanisms 25 defined in this document for Loss Measurement. The procedure 26 specified is applicable to SR-MPLS and SRv6 data planes and is used 27 for both Links and end-to-end SR Policies. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on September 24, 2020. 46 Copyright Notice 48 Copyright (c) 2020 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (https://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Conventions Used in This Document . . . . . . . . . . . . . . 4 65 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 66 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4 67 2.3. Reference Topology . . . . . . . . . . . . . . . . . . . 5 68 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 3.1. Example Provisioning Model . . . . . . . . . . . . . . . 6 70 4. Probe Messages . . . . . . . . . . . . . . . . . . . . . . . 7 71 4.1. Probe Query Message . . . . . . . . . . . . . . . . . . . 7 72 4.1.1. Delay Measurement Query Message . . . . . . . . . . . 7 73 4.1.2. Loss Measurement Query Message . . . . . . . . . . . 8 74 4.1.3. Probe Query for Links . . . . . . . . . . . . . . . . 9 75 4.1.4. Probe Query for End-to-end Measurement for SR Policy 9 76 4.1.5. Control Code Field for STAMP Messages . . . . . . . . 10 77 4.1.6. Loss Measurement Query Message Formats for STAMP . . 12 78 4.2. Probe Response Message . . . . . . . . . . . . . . . . . 14 79 4.2.1. One-way Measurement Mode . . . . . . . . . . . . . . 15 80 4.2.2. Two-way Measurement Mode . . . . . . . . . . . . . . 15 81 4.2.3. Loopback Measurement Mode . . . . . . . . . . . . . . 17 82 4.2.4. Loss Measurement Response Message Formats for STAMP . 17 83 4.3. Node Address TLV for STAMP Message . . . . . . . . . . . 19 84 4.4. Return Path TLV for STAMP Message . . . . . . . . . . . . 19 85 5. Performance Measurement for P2MP SR Policies . . . . . . . . 21 86 6. ECMP Support for SR Policies . . . . . . . . . . . . . . . . 22 87 7. Additional Message Processing Rules . . . . . . . . . . . . . 22 88 7.1. TTL and Hop Limit . . . . . . . . . . . . . . . . . . . . 22 89 7.2. Router Alert Option . . . . . . . . . . . . . . . . . . . 23 90 7.3. UDP Checksum . . . . . . . . . . . . . . . . . . . . . . 23 91 8. Security Considerations . . . . . . . . . . . . . . . . . . . 23 92 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 93 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 94 10.1. Normative References . . . . . . . . . . . . . . . . . . 24 95 10.2. Informative References . . . . . . . . . . . . . . . . . 25 96 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 28 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 99 1. Introduction 101 Segment Routing (SR) leverages the source routing paradigm and 102 greatly simplifies network operations for Software Defined Networks 103 (SDNs). SR is applicable to both Multiprotocol Label Switching (SR- 104 MPLS) and IPv6 (SRv6) data planes. SR takes advantage of the Equal- 105 Cost Multipaths (ECMPs) between source and transit nodes, between 106 transit nodes and between transit and destination nodes. SR Policies 107 as defined in [I-D.ietf-spring-segment-routing-policy] are used to 108 steer traffic through a specific, user-defined paths using a stack of 109 Segments. Built-in SR Performance Measurement (PM) is one of the 110 essential requirements to provide Service Level Agreements (SLAs). 112 The Simple Two-way Active Measurement Protocol (STAMP) provides 113 capabilities for the measurement of various performance metrics in IP 114 networks using probe messages [RFC8762]. It eliminates the control- 115 channel signaling by using configuration data model to provision a 116 test-channel (e.g. UDP paths). [I-D.ietf-ippm-stamp-option-tlv] 117 defines TLV extensions for STAMP messages. 119 The STAMP message with a TLV for "direct measurement" can be used for 120 combined Delay + Loss measurement [I-D.ietf-ippm-stamp-option-tlv]. 121 However, in order to use only for loss measurement purpose, it 122 requires the node to support the delay measurement messages and 123 support timestamp for these messages (which may also require clock 124 synchronization). Furthermore, for hardware-based counter collection 125 for direct-mode loss meaurement, the optional TLV based processing 126 adds unnecessary overhead (as counters are not at well-known 127 locations). 129 This document specifies procedures for sending and processing probe 130 query and response messages for Performance Measurement in SR 131 networks. The procedure uses the mechanisms defined in [RFC8762] 132 (STAMP) (including the TLV extensions) for Delay Measurement (DM), 133 and uses the mechanisms defined in this document for Loss 134 Measurement. The procedure specified is applicable to SR-MPLS and 135 SRv6 data planes and are used for both Links and end-to-end SR 136 Policies. This document also defines mechanisms for handling ECMPs 137 of SR Policies for performance delay measurement. Unless otherwise 138 specified, the mechanisms defined in [RFC8762] and 139 [I-D.ietf-ippm-stamp-option-tlv] are not modified by this document. 141 2. Conventions Used in This Document 143 2.1. Requirements Language 145 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 146 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 147 document are to be interpreted as described in [RFC2119] [RFC8174] 148 when, and only when, they appear in all capitals, as shown here. 150 2.2. Abbreviations 152 BSID: Binding Segment ID. 154 DM: Delay Measurement. 156 ECMP: Equal Cost Multi-Path. 158 HMAC: Hashed Message Authentication Code. 160 LM: Loss Measurement. 162 MPLS: Multiprotocol Label Switching. 164 NTP: Network Time Protocol. 166 OWAMP: One-Way Active Measurement Protocol. 168 PM: Performance Measurement. 170 PSID: Path Segment Identifier. 172 PTP: Precision Time Protocol. 174 SID: Segment ID. 176 SL: Segment List. 178 SR: Segment Routing. 180 SRH: Segment Routing Header. 182 SR-MPLS: Segment Routing with MPLS data plane. 184 SRv6: Segment Routing with IPv6 data plane. 186 STAMP: Simple Two-way Active Measurement Protocol. 188 TC: Traffic Class. 190 2.3. Reference Topology 192 In the reference topology shown below, the sender node R1 initiates a 193 probe query for performance measurement and the reflector node R5 194 sends a probe response for the query message received. The probe 195 response is sent to the sender node R1. The nodes R1 and R5 may be 196 directly connected via a Link or there exists a Point-to-Point (P2P) 197 SR Policy [I-D.ietf-spring-segment-routing-policy] on node R1 with 198 destination to node R5. In case of Point-to-Multipoint (P2MP), SR 199 Policy originating from source node R1 may terminate on multiple 200 destination leaf nodes [I-D.voyer-spring-sr-replication-segment]. 202 +-------+ t1 Query t2 +-------+ 203 | | - - - - - - - - - ->| | 204 | R1 |---------------------| R5 | 205 | |<- - - - - - - - - - | | 206 +-------+ t4 Response t3 +-------+ 207 Sender Reflector 209 Reference Topology 211 3. Overview 213 For one-way, two-way and round-trip delay measurements in Segment 214 Routing networks, the probe messages defined in [RFC8762] are used. 215 For direct-mode and inferred-mode loss measurements in Segment 216 Routing networks, the messages defined in this document are used. 217 Separate UDP destination port numbers are user-configured for delay 218 and loss measurements from the range specified in [RFC8762]. The 219 sender uses the UDP port number following the guidelines specified in 220 Section 6 in [RFC6335]. The UDP destination port 862 can be used for 221 delay measurement probes by default except for the case where the 222 reflector needs to process STAMP TLVs. For both Links and end-to-end 223 SR Policies, no PM session for delay or loss measurement is created 224 on the reflector node R5 [RFC8762]. 226 For Performance Measurement, probe query and response messages are 227 sent as following: 229 o For Delay Measurement, the probe messages are sent on the 230 congruent path of the data traffic by the sender node, and are 231 used to measure the delay experienced by the actual data traffic 232 flowing on the Links and SR Policies. 234 o For Loss Measurement, the probe messages are sent on the congruent 235 path of the data traffic by the sender node, and are used to 236 collect the receive traffic counters for the incoming link or 237 incoming SID where the probe query messages are received at the 238 reflector node (incoming link or incoming SID needed since the 239 reflector node does not have PM session state present). 241 The In-Situ Operations, Administration, and Maintenance (IOAM) 242 mechanisms for SR-MPLS defined in [I-D.gandhi-mpls-ioam-sr] and for 243 SRv6 defined in [I-D.ali-spring-ioam-srv6] are used to carry PM 244 information such as timestamp in-band as part of the data packets, 245 and are outside the scope of this document. 247 3.1. Example Provisioning Model 249 An example of a provisioning model and typical measurement parameters 250 for each user-configured destination UDP port for performance delay 251 and loss measurements is shown in the following Figure 1: 253 +------------+ 254 | Controller | 255 +------------+ 256 Destination UDP Port / \ Destination UDP port 257 Measurement Protocol / \ Measurement Protocol 258 Measurement Type / \ Measurement Type 259 Delay/Loss / \ Delay/Loss 260 Authentication Mode & Key / \ Authentication Mode & Key 261 Timestamp Format / \ Loss Measurement Mode 262 Delay Measurement Mode / \ 263 Loss Measurement Mode / \ 264 v v 265 +-------+ +-------+ 266 | | | | 267 | R1 |------------| R5 | 268 | | | | 269 +-------+ +-------+ 270 Sender Reflector 272 Figure 1: Example Provisioning Model 274 Example of Measurement Protocol is STAMP, the Timestamp Format is 275 PTPv2 [IEEE1588] or NTP and the Loss Measurement mode is inferred- 276 mode or direct-mode. The mechanisms to provision the sender and 277 reflector nodes are outside the scope of this document. 279 The reflector node R5 uses the parameters for the timestamp format 280 and delay measurement mode (i.e. one-way, two-way or loopback mode) 281 from the received probe query message. 283 4. Probe Messages 285 4.1. Probe Query Message 287 The probe messages defined in [RFC8762] are used for Delay 288 Measurement for Links and end-to-end SR Policies. For Loss 289 Measurement, the probe messages defined in this document are used. 291 The Sender IPv4 or IPv6 address is used as the source address. When 292 known, the reflector IPv4 or IPv6 address is used as the destination 293 address. If not known, the address in the range of 127/8 for IPv4 or 294 0:0:0:0:0:FFFF:7F00/104 for IPv6 is used as destination address. 295 This is the case for example, when using SR Policy with IPv4 endpoint 296 of 0.0.0.0 or IPv6 endpoint of ::0 297 [I-D.ietf-spring-segment-routing-policy]. 299 4.1.1. Delay Measurement Query Message 301 The message content for Delay Measurement probe query message using 302 UDP header [RFC0768] is shown in Figure 2. The DM probe query 303 message is sent with user-configured Destination UDP port number for 304 DM. The Destination UDP port cannot be used as Source port, since 305 the message does not have any indication to distinguish between the 306 query and response message. The payload of the DM probe query 307 message contains the delay measuremen message defined in [RFC8762]. 309 +---------------------------------------------------------------+ 310 | IP Header | 311 . Source IP Address = Sender IPv4 or IPv6 Address . 312 . Destination IP Address = Reflector IPv4 or IPv6 Address . 313 . Protocol = UDP . 314 . . 315 +---------------------------------------------------------------+ 316 | UDP Header | 317 . Source Port = As chosen by Sender . 318 . Destination Port = User-configured Port for Delay Measurement. 319 . . 320 +---------------------------------------------------------------+ 321 | Payload = Message specified in Section 4.2 of RFC 8762 | 322 . . 323 +---------------------------------------------------------------+ 325 Figure 2: DM Probe Query Message 327 Timestamp field is eight bytes and use the format defined in 328 Section 4.2.1 of [RFC8762]. It is recommended to use the IEEE 1588v2 329 Precision Time Protocol (PTP) truncated 64-bit timestamp format 331 [IEEE1588] as specified in [RFC8186], with hardware support in 332 Segment Routing networks. 334 4.1.1.1. Delay Measurement Authentication Mode 336 When using the authenticated mode for delay measurement, the matching 337 authentication type (e.g. HMAC-SHA-256) and key are user-configured 338 on both the sender and reflector nodes. A separate user-configured 339 destination UDP port is used for the delay measurement in 340 authentication mode due to the different probe message format. 342 4.1.2. Loss Measurement Query Message 344 The message content for Loss Measurement probe query message using 345 UDP header [RFC0768] is shown in Figure 3. The LM probe query 346 message is sent with user-configured Destination UDP port number for 347 LM, which is a different Destination UDP port number than DM. 348 Separate Destination UDP ports are used for direct-mode and inferred- 349 mode loss measurements. The Destination UDP port cannot be used as 350 Source port, since the message does not have any indication to 351 distinguish between the query and response message. The LM probe 352 query message contains the payload for loss measurement as defined in 353 Figure 7 and Figure 8. 355 +---------------------------------------------------------------+ 356 | IP Header | 357 . Source IP Address = Sender IPv4 or IPv6 Address . 358 . Destination IP Address = Reflector IPv4 or IPv6 Address . 359 . Protocol = UDP . 360 . . 361 +---------------------------------------------------------------+ 362 | UDP Header | 363 . Source Port = As chosen by Sender . 364 . Destination Port = User-configured Port for Loss Measurement . 365 . . 366 +---------------------------------------------------------------+ 367 | Payload = Message as specified in Figure 7 or 8 | 368 . . 369 +---------------------------------------------------------------+ 371 Figure 3: LM Probe Query Message 373 4.1.2.1. Loss Measurement Authentication Mode 375 When using the authenticated mode for loss measurement, the matching 376 authentication type (e.g. HMAC-SHA-256) and key are user-configured 377 on both the sender and reflector nodes. A separate user-configured 378 destination UDP port is used for the loss measurement in 379 authentication mode due to the different message format. 381 4.1.3. Probe Query for Links 383 The probe query message as defined in Figure 2 for delay measurement 384 and Figure 3 for loss measurement is sent on the congruent path of 385 the data traffic. The probe messages are routed over the Link for 386 both delay and loss measurement. 388 4.1.4. Probe Query for End-to-end Measurement for SR Policy 390 The performance delay and loss measurement for segment routing is 391 applicable to both SR-MPLS and SRv6 Policies. 393 4.1.4.1. Probe Query Message for SR-MPLS Policy 395 The probe query messages for end-to-end performance measurement of an 396 SR-MPLS Policy is sent using its SR-MPLS header containing the MPLS 397 segment list as shown in Figure 4. 399 0 1 2 3 400 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 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 | Segment(1) | TC |S| TTL | 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 . . 405 . . 406 . . 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 | Segment(n) | TC |S| TTL | 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 | PSID | TC |S| TTL | 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 | Message as shown in Figure 2 for DM or Figure 3 for LM | 413 . . 414 +---------------------------------------------------------------+ 416 Figure 4: Probe Query Message for SR-MPLS Policy 418 The Segment List (SL) can be empty to indicate Implicit NULL label 419 case for a single-hop SR Policy. 421 The Path Segment Identifier (PSID) 422 [I-D.ietf-spring-mpls-path-segment] of the SR-MPLS Policy is used for 423 accounting received traffic on the egress node for loss measurement. 425 4.1.4.2. Probe Query Message for SRv6 Policy 427 An SRv6 Policy setup using the SRv6 Segment Routing Header (SRH) and 428 a Segment List as defined in [RFC8754]. For SRv6, network 429 programming is defined in [I-D.ietf-spring-srv6-network-programming]. 430 The probe query messages for end-to-end performance measurement of an 431 SRv6 Policy is sent using its SRH with Segment List as shown in 432 Figure 5. 434 +---------------------------------------------------------------+ 435 | SRH | 436 . . 437 +---------------------------------------------------------------+ 438 | Message as shown in Figure 2 for DM or Figure 3 for LM | 439 . (Using IPv6 Source and Destination Addresses) . 440 . . 441 +---------------------------------------------------------------+ 443 Figure 5: Probe Query Message for SRv6 Policy 445 For delay measurement of SRv6 Policy using SRH, END function END.OTP 446 [I-D.ietf-6man-spring-srv6-oam] is used with the target SRv6 SID to 447 punt probe messages on the target node, as shown in Figure 5. 448 Similarly, for loss measurement of SRv6 Policy, END function END.OP 449 [I-D.ietf-6man-spring-srv6-oam] is used with target SRv6 SID to punt 450 probe messages on the target node. 452 4.1.5. Control Code Field for STAMP Messages 454 The Control Code field is defined for delay and loss measurement 455 probe query and response messages for STAMP protocol in 456 unauthenticated and authenticated modes. The modified delay 457 measurement probe query and response message format for STAMP is 458 shown in Figure 6. This message format is backwards compatible with 459 the message format defined in STAMP [RFC8762] as its reflector MUST 460 ignore the received field (previously identified as MBZ). The usage 461 of the Control Code is not limited to the SR networks and can be used 462 for various bidirectional paths in a network. 464 . . 465 . . 466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 467 | Timestamp | 468 | | 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 | Error Estimate | Session ID | 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 472 | MBZ |Se Control Code| 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 474 . . 475 . . 477 . . 478 . . 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 | Session-Sender Error Estimate | MBZ |Re Control Code| 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 482 |Ses-Sender TTL | MBZ | 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 . . 485 . . 487 Figure 6: Sender and Reflector Control Code in STAMP DM Message 489 Sender Control Code: Set as follows in STAMP probe query message. 491 For a Query: 493 0x0: Out-of-band Response Requested. Indicates that the probe 494 response is not required over the same path in the reverse 495 direction. This is also the default behavior. 497 0x1: In-band Response Requested. Indicates that this query has 498 been sent over a bidirectional path and the probe response is 499 required over the same path in the reverse direction. The 500 bidirectional path does not have to be an SR path. 502 Reflector Control Code: Set as follows in STAMP probe response 503 message. 505 For a Response: 507 0x1: Error - Invalid Message. Indicates that the operation 508 failed because the received query message could not be processed. 510 Additional Error Codes to be defined in future. 512 4.1.6. Loss Measurement Query Message Formats for STAMP 514 In this document, STAMP probe query message formats are defined for 515 loss measurement as shown in Figure 7 and Figure 8. The message 516 formats are hardware efficient due to the well-known locations of the 517 counters. They are similar to the delay measurement message formats 518 (e.g. location of the Counter and Timestamp) and do not require any 519 backwards compatibility or support for the existing DM message 520 formats from [RFC8762] as different user-configured destination UDP 521 port is used for loss measurement. 523 0 1 2 3 524 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 525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 526 | Sequence Number | 527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 528 | Transmit Counter | 529 | | 530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 531 |X|B| Reserved | Block Number | Session ID | 532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 | MBZ |Se Control Code| 534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 535 | | 536 | MBZ (24 octets) | 537 | | 538 | | 539 | | 540 | | 541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 543 Figure 7: STAMP LM Probe Query Message - Unauthenticated Mode 545 0 1 2 3 546 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 547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 548 | Sequence Number | 549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 550 | MBZ (12 octets) | 551 | | 552 | | 553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 554 | Transmit Counter | 555 | | 556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 557 |X|B| Reserved | Block Number | Session ID | 558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 559 | MBZ |Se Control Code| 560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 561 | MBZ (64 octets) | 562 . . 563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 564 | | 565 | HMAC (16 octets) | 566 | | 567 | | 568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 570 Figure 8: STAMP LM Probe Query Message - Authenticated Mode 572 Sequence Number (32-bit): As defined in [RFC8762]. 574 Transmit Counter (64-bit): The number of packets or octets sent by 575 the sender node in the query message and by the reflector node in the 576 response message. The counter is always written at the well-known 577 location in the probe query and response messages. 579 Receive Counter (64-bit): The number of packets or octets received at 580 the reflector node. It is written by the reflector node in the probe 581 response message. 583 Sender Counter (64-bit): This is the exact copy of the transmit 584 counter from the received query message. It is written by the 585 reflector node in the probe response message. 587 Sender Sequence Number (32-bit): As defined in [RFC8762]. 589 Sender TTL: As defined in Section 7.1. 591 LM Flags: The meanings of the Flag bits are: 593 X: Extended counter format indicator. Indicates the use of 594 extended (64-bit) counter values. Initialized to 1 upon creation 595 (and prior to transmission) of an LM Query and copied from an LM 596 Query to an LM response. Set to 0 when the LM message is 597 transmitted or received over an interface that writes 32-bit 598 counter values. 600 B: Octet (byte) count. When set to 1, indicates that the Counter 601 1-4 fields represent octet counts. The octet count applies to all 602 packets within the LM scope, and the octet count of a packet sent 603 or received includes the total length of that packet (but excludes 604 headers, labels, or framing of the channel itself). When set to 605 0, indicates that the Counter fields represent packet counts. 607 Block Number (8-bit): The Loss Measurement using Alternate-Marking 608 method defined in [RFC8321] requires to color the data traffic. To 609 be able to compare the transmit and receive traffic counters of the 610 matching color, the Block Number (or color) of the traffic counters 611 is carried by the probe query and response messages for loss 612 measurement. 614 HMAC: The PM probe message in authenticated mode includes a key 615 Hashed Message Authentication Code (HMAC) ([RFC2104]) hash. Each 616 probe query and response messages are authenticated by adding 617 Sequence Number with Hashed Message Authentication Code (HMAC) TLV. 618 It can use HMAC-SHA-256 truncated to 128 bits (similarly to the use 619 of it in IPSec defined in [RFC4868]); hence the length of the HMAC 620 field is 16 octets. 622 HMAC uses its own key and the mechanism to distribute the HMAC key is 623 outside the scope of this document. 625 In authenticated mode, only the sequence number is encrypted, and the 626 other payload fields are sent in clear text. The probe message MAY 627 include Comp.MBZ (Must Be Zero) variable length field to align the 628 packet on 16 octets boundary. 630 4.2. Probe Response Message 632 The probe response message is sent using the IP/UDP information from 633 the received probe query message. The content of the probe response 634 message is shown in Figure 9. 636 +---------------------------------------------------------------+ 637 | IP Header | 638 . Source IP Address = Reflector IPv4 or IPv6 Address . 639 . Destination IP Address = Source IP Address from Query . 640 . Protocol = UDP . 641 . . 642 +---------------------------------------------------------------+ 643 | UDP Header | 644 . Source Port = As chosen by Reflector . 645 . Destination Port = Source Port from Query . 646 . . 647 +---------------------------------------------------------------+ 648 | DM payload as specified in Section 4.3 of RFC 8762 | | 649 . LM Payload as specified in Figure 12 or 13 . 650 . . 651 +---------------------------------------------------------------+ 653 Figure 9: Probe Response Message 655 4.2.1. One-way Measurement Mode 657 In one-way performance measurement mode, the probe response message 658 as defined in Figure 9 is sent back out-of-band to the sender node, 659 for both Links and SR Policies. The Sender Control Code is set to 660 "Out-of-band Response Requested". In this delay measurement mode, as 661 per Reference Topology, all timestamps t1, t2, t3, and t4 are 662 collected by the probes. However, only timestamps t1 and t2 are 663 needed to measure one-way delay. 665 4.2.2. Two-way Measurement Mode 667 In two-way performance measurement mode, when using a bidirectional 668 path, the probe response message as defined in Figure 9 is sent back 669 to the sender node on the congruent path of the data traffic on the 670 same reverse direction Link or associated reverse SR Policy 671 [I-D.ietf-pce-sr-bidir-path]. The Sender Control Code is set to "In- 672 band Response Requested". In this delay measurement mode, as per 673 Reference Topology, all timestamps t1, t2, t3, and t4 are collected 674 by the probes. All four timestamps are needed to measure two-way 675 delay. 677 Specifically, the probe response message is sent back on the incoming 678 physical interface where the probe query message is received. This 679 is useful for example, in case of two-way measurement mode for Link 680 delay. 682 4.2.2.1. Probe Response Message for SR-MPLS Policy 684 The message content for sending probe response message for two-way 685 end-to-end performance measurement of an SR-MPLS Policy is shown in 686 Figure 10. 688 0 1 2 3 689 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 690 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 691 | Segment(1) | TC |S| TTL | 692 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 693 . . 694 . . 695 . . 696 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 697 | Segment(n) | TC |S| TTL | 698 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 699 | Message as shown in Figure 9 | 700 . . 701 +---------------------------------------------------------------+ 703 Figure 10: Probe Response Message for SR-MPLS Policy 705 The Path Segment Identifier (PSID) 706 [I-D.ietf-spring-mpls-path-segment] of the forward SR Policy in the 707 probe query can be used to find the associated reverse SR Policy 708 [I-D.ietf-pce-sr-bidir-path] to send the probe response message for 709 two-way measurement of SR Policy unless when using STAMP message with 710 Return Path TLV. 712 4.2.2.2. Probe Response Message for SRv6 Policy 714 The message content for sending probe response message on the 715 congruent path of the data traffic for two-way end-to-end performance 716 measurement of an SRv6 Policy with SRH is shown in Figure 11. 718 +---------------------------------------------------------------+ 719 | SRH | 720 . . 721 +---------------------------------------------------------------+ 722 | Message as shown in Figure 9 | 723 . (Using IPv6 Source and Destination Addresses) . 724 . . 725 +---------------------------------------------------------------+ 727 Figure 11: Probe Response Message for SRv6 Policy 729 4.2.3. Loopback Measurement Mode 731 The Loopback measurement mode can be used to measure round-trip delay 732 for a bidirectional SR Path. The IP header of the probe query 733 message contains the destination address equals to the sender address 734 and the source address equals to the reflector address. Optionally, 735 the probe query message can carry the reverse path information (e.g. 736 reverse path label stack for SR-MPLS) as part of the SR header. The 737 probe messages are not punted at the reflector node and it does not 738 process them and generate response messages. The Sender Control Code 739 is set to the default value of 0. In this mode, as the probe packet 740 is not punted on the reflector node for processing, the querier 741 copies the 'Sequence Number' in 'Session-Sender Sequence Number' 742 directly. In this delay measurement mode, as per Reference Topology, 743 the timestamps t1 and t4 are collected by the probes. Both these 744 timestamps are needed to measure round-trip delay. 746 4.2.4. Loss Measurement Response Message Formats for STAMP 748 In this document, STAMP probe response message formats are defined 749 for loss measurement as shown in Figure 12 and Figure 13. 751 0 1 2 3 752 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 753 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 754 | Sequence Number | 755 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 756 | Transmit Counter | 757 | | 758 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 759 |X|B| Reserved | Block Number | Session ID | 760 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 761 | Receive Counter | 762 | | 763 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 764 | Sender Sequence Number | 765 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 766 | Sender Counter | 767 | | 768 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 769 |X|B| Reserved |Sender Block Nu| MBZ |Re Control Code| 770 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 771 | Sender TTL | MBZ | 772 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 774 Figure 12: STAMP LM Probe Response Message - Unauthenticated Mode 776 0 1 2 3 777 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 778 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 779 | Sequence Number | 780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 781 | MBZ (12 octets) | 782 | | 783 | | 784 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 785 | Transmit Counter | 786 | | 787 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 788 |X|B| Reserved | Block Number | Session ID | 789 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 790 | MBZ (4 octets) | 791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 792 | Receive Counter | 793 | | 794 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 795 | MBZ (8 octets) | 796 | | 797 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 798 | Sender Sequence Number | 799 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 800 | MBZ (12 octets) | 801 | | 802 | | 803 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 804 | Sender Counter | 805 | | 806 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 807 |X|B| Reserved |Sender Block Nu| MBZ |Re Control Code| 808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 809 | MBZ (4 octets) | 810 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 811 | Sender TTL | | 812 +-+-+-+-+-+-+-+-+ | 813 | MBZ (15 octets) | 814 | | 815 | | 816 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 817 | | 818 | HMAC (16 octets) | 819 | | 820 | | 821 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 823 Figure 13: STAMP LM Probe Response Message - Authenticated Mode 825 4.3. Node Address TLV for STAMP Message 827 In this document, Node Address TLV is defined for STAMP message 828 [I-D.ietf-ippm-stamp-option-tlv] and has the following format shown 829 in Figure 14: 831 0 1 2 3 832 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 833 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 834 | Type | Length | Address Family | 835 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 836 ~ Address ~ 837 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 839 Figure 14: Node Address TLV Format 841 The Address Family field indicates the type of the address, and it 842 SHALL be set to one of the assigned values in the "IANA Address 843 Family Numbers" registry. 845 The following Type is defined and it contains Node Address TLV: 847 Destination Node Address (value TBA1): 849 The Destination Node Address TLV is optional. The Destination Node 850 Address TLV indicates the address of the intended recipient node of 851 the probe message. The reflector node SHOULD NOT send response if it 852 is not the intended destination node of the probe query message. 853 This check is useful for example, for performance measurement of SR 854 Policy when using the destination address in 127/8 range for IPv4 or 855 in 0:0:0:0:0:FFFF:7F00/104 range for IPv6. 857 4.4. Return Path TLV for STAMP Message 859 For two-way performance measurement, the reflector node needs to send 860 the probe response message on a specific reverse path. The sender 861 node can request in the probe query message to the reflector node to 862 send a response back on a given reverse path (e.g. co-routed 863 bidirectional path). This way the destination node does not require 864 any additional SR Policy state. 866 For one-way performance measurement, the sender node address may not 867 be reachable via IP route from the reflector node. The sender node 868 in this case needs to send its reachability path information to the 869 reflector node. 871 [I-D.ietf-ippm-stamp-option-tlv] defines STAMP probe query messages 872 that can include one or more optional TLVs. The TLV Type (value 873 TBA2) is defined in this document for Return Path that carries 874 reverse path for STAMP probe response messages (in the payload of the 875 message). The format of the Return Path TLV is shown in Figure 15: 877 0 1 2 3 878 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 879 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 880 | Type = TBA2 | Length | Reserved | 881 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 882 | Return Path Sub-TLVs | 883 . . 884 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 886 Figure 15: Return Path TLV 888 The following Type defined for the Return Path TLV contains the Node 889 Address sub-TLV using the format shown in Figure 14: 891 o Type (value 0): Return Address. Target node address of the 892 response different than the Source Address in the query 894 0 1 2 3 895 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 896 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 897 | Type | Length | Reserved | 898 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 899 | Segment(1) | 900 . . 901 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 902 . . 903 . . 904 . . 906 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 907 | Segment(n) | 908 . . 909 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 911 Figure 16: Segment List Sub-TLV in Return Path TLV 913 The Segment List Sub-TLV (shown in Figure 16) in the Return Path TLV 914 can be one of the following Types: 916 o Type (value 1): SR-MPLS Label Stack of the Reverse SR Path 918 o Type (value 2): SR-MPLS Binding SID 919 [I-D.ietf-pce-binding-label-sid] of the Reverse SR Policy 921 o Type (value 3): SRv6 Segment List of the Reverse SR Path 923 o Type (value 4): SRv6 Binding SID [I-D.ietf-pce-binding-label-sid] 924 of the Reverse SR Policy 926 The Return Path TLV is optional. The PM sender node MUST only insert 927 one Return Path TLV in the probe query message and the reflector node 928 MUST only process the first Return Path TLV in the probe query 929 message and ignore other Return Path TLVs if present. The reflector 930 node MUST send probe response message back on the reverse path 931 specified in the Return Path TLV and MUST NOT add Return Path TLV in 932 the probe response message. 934 5. Performance Measurement for P2MP SR Policies 936 The procedures for delay and loss measurement described in this 937 document for Point-to-Point (P2P) SR Policies 938 [I-D.ietf-spring-segment-routing-policy] are also equally applicable 939 to the Point-to-Multipoint (P2MP) SR Policies as following: 941 o The sender root node sends probe query messages using the 942 Replication Segment defined in 943 [I-D.voyer-spring-sr-replication-segment] for the P2MP SR Policy 944 as shown in Figure 17. 946 o Each reflector leaf node sends its IP address in the Source 947 Address of the probe response messages as shown in Figure 9. This 948 allows the sender root node to identify the reflector leaf nodes 949 of the P2MP SR Policy. 951 o The P2MP root node measures the end-to-end delay and loss 952 performance for each P2MP leaf node of the P2MP SR Policy. 954 0 1 2 3 955 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 956 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 957 | Replication SID | TC |S| TTL | 958 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 959 | Message as shown in Figure 2 for DM or Figure 3 for LM | 960 . . 961 +---------------------------------------------------------------+ 963 Figure 17: Query with Replication Segment for SR-MPLS Policy 965 6. ECMP Support for SR Policies 967 An SR Policy can have ECMPs between the source and transit nodes, 968 between transit nodes and between transit and destination nodes. 969 Usage of Anycast SID [RFC8402] by an SR Policy can result in ECMP 970 paths via transit nodes part of that Anycast group. The PM probe 971 messages need to be sent to traverse different ECMP paths to measure 972 performance delay of an SR Policy. 974 Forwarding plane has various hashing functions available to forward 975 packets on specific ECMP paths. The mechanisms described in 976 [RFC8029] and [RFC5884] for handling ECMPs are also applicable to the 977 performance measurement. In the IP header of the PM probe messages, 978 sweeping of Destination Addresses in 127/8 range for IPv4 or 979 0:0:0:0:0:FFFF:7F00/104 range for IPv6 can be used to exercise 980 particular ECMP paths. As specified in [RFC6437], Flow Label field 981 in the outer IPv6 header can also be used for sweeping. 983 The considerations for performance loss measurement for different 984 ECMP paths of an SR Policy are outside the scope of this document. 986 7. Additional Message Processing Rules 988 The processing rules defined in this section are applicable to the 989 STAMP messages for delay and loss measurement for Links and end-to- 990 end SR Policies. 992 7.1. TTL and Hop Limit 994 The TTL field in the IPv4 and MPLS headers of the probe query 995 messages is set to 255 [RFC8762]. Similarly, the Hop Limit field in 996 the IPv6 and SRH headers of the probe query messages is set to 255 997 [RFC8762]. 999 When using the Destination IPv4 Address from the 127/8 range, the TTL 1000 in the IPv4 header is set to 1 [RFC8029]. Similarly, when using the 1001 Destination IPv6 Address from the 0:0:0:0:0:FFFF:7F00/104 range, the 1002 Hop Limit field in the inner IPv6 header is set to 1 whereas in the 1003 outer IPv6 header is set to 255. 1005 For Link performance delay and loss measurements, the TTL and Hop 1006 Limit field in the probe message is set to 1 in both one-way and two- 1007 way measurement modes. 1009 7.2. Router Alert Option 1011 The Router Alert IP option is not set when using the routable 1012 Destination IP Address in the probe messages. 1014 When using the Destination IPv4 Address from the 127/8 range, to be 1015 able to punt probe packets on the reflector node, the Router Alert IP 1016 Option of value 0x0 [RFC2113] for IPv4 MAY be added [RFC8029]. 1017 Similarly, when using the Destination IPv6 Address from the 1018 0:0:0:0:0:FFFF:7F00/104 range, the Router Alert IP Option of value 69 1019 [RFC7506] for IPv6 MAY be added in the destination option header, 1020 Section 4.6 of [RFC8200]. For SRv6 Policy using SRH, it is added in 1021 the inner IPv6 header. 1023 7.3. UDP Checksum 1025 The UDP Checksum Complement for delay and loss measurement messages 1026 follows the procedure defined in [RFC7820] and can be optionally used 1027 with the procedures defined in this document. 1029 For IPv4 and IPv6 probe messages, where the hardware is not capable 1030 of re-computing the UDP checksum or adding checksum complement 1031 [RFC7820], the sender node sets the UDP checksum to 0 [RFC6936] 1032 [RFC8085]. The receiving node bypasses the checksum validation and 1033 accepts the packets with UDP checksum value 0 for the UDP port being 1034 used for PM delay and loss measurements. 1036 8. Security Considerations 1038 The performance measurement is intended for deployment in well- 1039 managed private and service provider networks. As such, it assumes 1040 that a node involved in a measurement operation has previously 1041 verified the integrity of the path and the identity of the far-end 1042 reflector node. 1044 If desired, attacks can be mitigated by performing basic validation 1045 and sanity checks, at the sender, of the counter or timestamp fields 1046 in received measurement response messages. The minimal state 1047 associated with these protocols also limits the extent of measurement 1048 disruption that can be caused by a corrupt or invalid message to a 1049 single query/response cycle. 1051 Use of HMAC-SHA-256 in the authenticated mode protects the data 1052 integrity of the probe messages. SRv6 has HMAC protection 1053 authentication defined for SRH [RFC8754]. Hence, PM probe messages 1054 for SRv6 may not need authentication mode. Cryptographic measures 1055 may be enhanced by the correct configuration of access-control lists 1056 and firewalls. 1058 9. IANA Considerations 1060 IANA is requested to allocate a value for the following optional 1061 Destination Address TLV Type for [I-D.ietf-ippm-stamp-option-tlv] to 1062 be carried in PM probe messages: 1064 o Type TBA1: Destination Node Address TLV 1066 IANA is also requested to allocate a value for the following optional 1067 Return Path TLV Type for [I-D.ietf-ippm-stamp-option-tlv] to be 1068 carried in PM probe query messages: 1070 o Type TBA2: Return Path TLV 1072 IANA is also requested to allocate the values for the following Sub- 1073 TLV Types for the Return Path TLV. 1075 o Type (value 0): Return Address 1077 o Type (value 1): SR-MPLS Label Stack of the Reverse SR Path 1079 o Type (value 2): SR-MPLS Binding SID 1080 [I-D.ietf-pce-binding-label-sid] of the Reverse SR Policy 1082 o Type (value 3): SRv6 Segment List of the Reverse SR Path 1084 o Type (value 4): SRv6 Binding SID [I-D.ietf-pce-binding-label-sid] 1085 of the Reverse SR Policy 1087 10. References 1089 10.1. Normative References 1091 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1092 DOI 10.17487/RFC0768, August 1980, 1093 . 1095 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1096 Requirement Levels", BCP 14, RFC 2119, 1097 DOI 10.17487/RFC2119, March 1997, 1098 . 1100 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1101 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1102 May 2017, . 1104 [RFC8762] Mirsky, G., Jun, G., Nydell, H., and R. Foote, "Simple 1105 Two-Way Active Measurement Protocol", RFC 8762, 1106 DOI 10.17487/RFC8762, March 2020, 1107 . 1109 [I-D.ietf-6man-spring-srv6-oam] 1110 Ali, Z., Filsfils, C., Matsushima, S., Voyer, D., and M. 1111 Chen, "Operations, Administration, and Maintenance (OAM) 1112 in Segment Routing Networks with IPv6 Data plane (SRv6)", 1113 draft-ietf-6man-spring-srv6-oam-03 (work in progress), 1114 December 2019. 1116 [I-D.ietf-ippm-stamp-option-tlv] 1117 Mirsky, G., Xiao, M., Nydell, H., Foote, R., Masputra, A., 1118 and E. Ruffini, "Simple Two-way Active Measurement 1119 Protocol Optional Extensions", draft-ietf-ippm-stamp- 1120 option-tlv-03 (work in progress), February 2020. 1122 10.2. Informative References 1124 [IEEE1588] 1125 IEEE, "1588-2008 IEEE Standard for a Precision Clock 1126 Synchronization Protocol for Networked Measurement and 1127 Control Systems", March 2008. 1129 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 1130 Hashing for Message Authentication", RFC 2104, 1131 DOI 10.17487/RFC2104, February 1997, 1132 . 1134 [RFC2113] Katz, D., "IP Router Alert Option", RFC 2113, 1135 DOI 10.17487/RFC2113, February 1997, 1136 . 1138 [RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA- 1139 384, and HMAC-SHA-512 with IPsec", RFC 4868, 1140 DOI 10.17487/RFC4868, May 2007, 1141 . 1143 [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, 1144 "Bidirectional Forwarding Detection (BFD) for MPLS Label 1145 Switched Paths (LSPs)", RFC 5884, DOI 10.17487/RFC5884, 1146 June 2010, . 1148 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 1149 Cheshire, "Internet Assigned Numbers Authority (IANA) 1150 Procedures for the Management of the Service Name and 1151 Transport Protocol Port Number Registry", BCP 165, 1152 RFC 6335, DOI 10.17487/RFC6335, August 2011, 1153 . 1155 [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, 1156 "IPv6 Flow Label Specification", RFC 6437, 1157 DOI 10.17487/RFC6437, November 2011, 1158 . 1160 [RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement 1161 for the Use of IPv6 UDP Datagrams with Zero Checksums", 1162 RFC 6936, DOI 10.17487/RFC6936, April 2013, 1163 . 1165 [RFC7506] Raza, K., Akiya, N., and C. Pignataro, "IPv6 Router Alert 1166 Option for MPLS Operations, Administration, and 1167 Maintenance (OAM)", RFC 7506, DOI 10.17487/RFC7506, April 1168 2015, . 1170 [RFC7820] Mizrahi, T., "UDP Checksum Complement in the One-Way 1171 Active Measurement Protocol (OWAMP) and Two-Way Active 1172 Measurement Protocol (TWAMP)", RFC 7820, 1173 DOI 10.17487/RFC7820, March 2016, 1174 . 1176 [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., 1177 Aldrin, S., and M. Chen, "Detecting Multiprotocol Label 1178 Switched (MPLS) Data-Plane Failures", RFC 8029, 1179 DOI 10.17487/RFC8029, March 2017, 1180 . 1182 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 1183 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 1184 March 2017, . 1186 [RFC8186] Mirsky, G. and I. Meilik, "Support of the IEEE 1588 1187 Timestamp Format in a Two-Way Active Measurement Protocol 1188 (TWAMP)", RFC 8186, DOI 10.17487/RFC8186, June 2017, 1189 . 1191 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1192 (IPv6) Specification", STD 86, RFC 8200, 1193 DOI 10.17487/RFC8200, July 2017, 1194 . 1196 [RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli, 1197 L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, 1198 "Alternate-Marking Method for Passive and Hybrid 1199 Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321, 1200 January 2018, . 1202 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 1203 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1204 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 1205 July 2018, . 1207 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 1208 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 1209 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 1210 . 1212 [I-D.ietf-spring-segment-routing-policy] 1213 Filsfils, C., Sivabalan, S., Voyer, D., Bogdanov, A., and 1214 P. Mattes, "Segment Routing Policy Architecture", draft- 1215 ietf-spring-segment-routing-policy-06 (work in progress), 1216 December 2019. 1218 [I-D.voyer-spring-sr-replication-segment] 1219 Voyer, D., Filsfils, C., Parekh, R., Bidgoli, H., and Z. 1220 Zhang, "SR Replication Segment for Multi-point Service 1221 Delivery", draft-voyer-spring-sr-replication-segment-02 1222 (work in progress), November 2019. 1224 [I-D.ietf-spring-mpls-path-segment] 1225 Cheng, W., Li, H., Chen, M., Gandhi, R., and R. Zigler, 1226 "Path Segment in MPLS Based Segment Routing Network", 1227 draft-ietf-spring-mpls-path-segment-02 (work in progress), 1228 February 2020. 1230 [I-D.ietf-spring-srv6-network-programming] 1231 Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., 1232 Matsushima, S., and Z. Li, "SRv6 Network Programming", 1233 draft-ietf-spring-srv6-network-programming-14 (work in 1234 progress), March 2020. 1236 [I-D.ietf-pce-binding-label-sid] 1237 Sivabalan, S., Filsfils, C., Tantsura, J., Hardwick, J., 1238 Previdi, S., and C. Li, "Carrying Binding Label/Segment-ID 1239 in PCE-based Networks.", draft-ietf-pce-binding-label- 1240 sid-02 (work in progress), March 2020. 1242 [I-D.gandhi-mpls-ioam-sr] 1243 Gandhi, R., Ali, Z., Filsfils, C., Brockners, F., Wen, B., 1244 and V. Kozak, "MPLS Data Plane Encapsulation for In-situ 1245 OAM Data", draft-gandhi-mpls-ioam-sr-02 (work in 1246 progress), March 2020. 1248 [I-D.ali-spring-ioam-srv6] 1249 Ali, Z., Gandhi, R., Filsfils, C., Brockners, F., Kumar, 1250 N., Pignataro, C., Li, C., Chen, M., and G. Dawra, 1251 "Segment Routing Header encapsulation for In-situ OAM 1252 Data", draft-ali-spring-ioam-srv6-02 (work in progress), 1253 November 2019. 1255 [I-D.ietf-pce-sr-bidir-path] 1256 Li, C., Chen, M., Cheng, W., Gandhi, R., and Q. Xiong, 1257 "PCEP Extensions for Associated Bidirectional Segment 1258 Routing (SR) Paths", draft-ietf-pce-sr-bidir-path-01 (work 1259 in progress), February 2020. 1261 Acknowledgments 1263 The authors would like to thank Thierry Couture for the discussions 1264 on the use-cases for Performance Measurement in Segment Routing. The 1265 authors would also like to thank Greg Mirsky for reviewing this 1266 document and providing useful comments and suggestions. Patrick 1267 Khordoc and Radu Valceanu, both from Cisco Systems have helped 1268 significantly improve the mechanisms defined in this document. The 1269 authors would like to acknowledge the earlier work on the loss 1270 measurement using TWAMP described in draft-xiao-ippm-twamp-ext- 1271 direct-loss. The authors would also like to thank Sam Aldrin for the 1272 discussions to check for broken path. 1274 Authors' Addresses 1276 Rakesh Gandhi (editor) 1277 Cisco Systems, Inc. 1278 Canada 1280 Email: rgandhi@cisco.com 1282 Clarence Filsfils 1283 Cisco Systems, Inc. 1285 Email: cfilsfil@cisco.com 1286 Daniel Voyer 1287 Bell Canada 1289 Email: daniel.voyer@bell.ca 1291 Mach(Guoyi) Chen 1292 Huawei 1294 Email: mach.chen@huawei.com 1296 Bart Janssens 1297 Colt 1299 Email: Bart.Janssens@colt.net