idnits 2.17.1 draft-gandhi-spring-twamp-srpm-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 (December 5, 2019) is 1603 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) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 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: June 7, 2020 D. Voyer 6 Bell Canada 7 M. Chen 8 Huawei 9 B. Janssens 10 Colt 11 December 5, 2019 13 Performance Measurement Using TWAMP Light 14 for Segment Routing Networks 15 draft-gandhi-spring-twamp-srpm-05 17 Abstract 19 Segment Routing (SR) leverages the source routing paradigm. SR is 20 applicable to both Multiprotocol Label Switching (SR-MPLS) and IPv6 21 (SRv6) data planes. This document specifies procedure for sending 22 and processing probe query and response messages for Performance 23 Measurement (PM) in Segment Routing networks. The procedure uses the 24 mechanisms defined in RFC 5357 (Two-Way Active Measurement Protocol 25 (TWAMP) Light) and Simple Two-Way Active Measurement Protocol (STAMP) 26 for Delay Measurement, and also uses the mechanisms defined in this 27 document for Loss Measurement. The procedure specified is applicable 28 to SR-MPLS and SRv6 data planes and are used for both links and 29 end-to-end SR Policies. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 Copyright Notice 47 Copyright (c) 2019 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Conventions Used in This Document . . . . . . . . . . . . . . 4 64 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 65 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4 66 2.3. Reference Topology . . . . . . . . . . . . . . . . . . . . 5 67 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 3.1. Example Provisioning Model . . . . . . . . . . . . . . . . 6 69 3.2. STAMP Applicability . . . . . . . . . . . . . . . . . . . 7 70 4. Probe Messages . . . . . . . . . . . . . . . . . . . . . . . . 7 71 4.1. Probe Query Message . . . . . . . . . . . . . . . . . . . 7 72 4.1.1. Delay Measurement Probe Query Message . . . . . . . . 7 73 4.1.1.1. Delay Measurement Authentication Mode . . . . . . 9 74 4.1.2. Loss Measurement Probe Query Message . . . . . . . . . 9 75 4.1.2.1. Loss Measurement Authentication Mode . . . . . . . 13 76 4.1.3. Probe Query for SR Links . . . . . . . . . . . . . . . 13 77 4.1.4. Probe Query for End-to-end Measurement for SR Policy . 13 78 4.1.4.1. Probe Query Message for SR-MPLS Policy . . . . . . 14 79 4.1.4.2. Probe Query Message for SRv6 Policy . . . . . . . 14 80 4.2. Probe Response Message . . . . . . . . . . . . . . . . . . 15 81 4.2.1. One-way Measurement Mode . . . . . . . . . . . . . . . 19 82 4.2.2. Two-way Measurement Mode . . . . . . . . . . . . . . . 19 83 4.2.2.1. Probe Response Message for SR-MPLS Policy . . . . 19 84 4.2.2.2. Probe Response Message for SRv6 Policy . . . . . . 20 85 4.2.3. Loopback Measurement Mode . . . . . . . . . . . . . . 20 86 4.3. Return Path TLV . . . . . . . . . . . . . . . . . . . . . 20 87 4.4. Node Address TLV . . . . . . . . . . . . . . . . . . . . . 22 88 5. Performance Measurement for P2MP SR Policies . . . . . . . . . 23 89 6. ECMP Support for SR Policies . . . . . . . . . . . . . . . . . 24 90 7. Additional Message Processing Rules . . . . . . . . . . . . . 24 91 7.1. TTL Value . . . . . . . . . . . . . . . . . . . . . . . . 24 92 7.2. Router Alert Option . . . . . . . . . . . . . . . . . . . 24 93 7.3. UDP Checksum . . . . . . . . . . . . . . . . . . . . . . . 25 94 8. Security Considerations . . . . . . . . . . . . . . . . . . . 25 95 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 96 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 97 10.1. Normative References . . . . . . . . . . . . . . . . . . 26 98 10.2. Informative References . . . . . . . . . . . . . . . . . 27 99 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 29 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 102 1. Introduction 104 Segment Routing (SR) leverages the source routing paradigm and 105 greatly simplifies network operations for Software Defined Networks 106 (SDNs). SR is applicable to both Multiprotocol Label Switching 107 (SR-MPLS) and IPv6 (SRv6) data planes. SR takes advantage of the 108 Equal-Cost Multipaths (ECMPs) between source and transit nodes, 109 between transit nodes and between transit and destination nodes. SR 110 Policies as defined in [I-D.spring-segment-routing-policy] are used 111 to steer traffic through a specific, user-defined paths using a stack 112 of Segments. Built-in SR Performance Measurement (PM) is one of the 113 essential requirements to provide Service Level Agreements (SLAs). 115 The One-Way Active Measurement Protocol (OWAMP) defined in [RFC4656] 116 and Two-Way Active Measurement Protocol (TWAMP) defined in [RFC5357] 117 provide capabilities for the measurement of various performance 118 metrics in IP networks using probe messages. These protocols rely on 119 control-channel signaling to establish a test-channel over an UDP 120 path. These protocols lack support for direct-mode Loss Measurement 121 (LM) to detect actual data traffic loss which is required in SR 122 networks. The Simple Two-way Active Measurement Protocol (STAMP) 123 [I-D.ippm-stamp] alleviates the control-channel signaling by using 124 configuration data model to provision a test-channel. The TWAMP 125 Light [Appendix I in RFC5357] [BBF.TR-390] provides simplified 126 mechanisms for active performance measurement in Customer IP networks 127 by provisioning UDP paths and eliminates the control-channel 128 signaling. 130 This document specifies procedures for sending and processing probe 131 query and response messages for Performance Measurement in SR 132 networks. The procedure uses the mechanisms defined in [RFC5357] 133 (TWAMP Light) and STAMP for Delay Measurement (DM), and also uses the 134 mechanisms defined in this document for Loss Measurement. The 135 procedure specified is applicable to SR-MPLS and SRv6 data planes and 136 are used for both links and end-to-end SR Policies. This document 137 also defines mechanisms for handling ECMPs of SR Policies for 138 performance delay measurements. 140 2. Conventions Used in This Document 142 2.1. Requirements Language 144 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 145 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 146 document are to be interpreted as described in [RFC2119] [RFC8174] 147 when, and only when, they appear in all capitals, as shown here. 149 2.2. Abbreviations 151 BSID: Binding Segment ID. 153 DM: Delay Measurement. 155 ECMP: Equal Cost Multi-Path. 157 HMAC: Hashed Message Authentication Code. 159 LM: Loss Measurement. 161 MPLS: Multiprotocol Label Switching. 163 NTP: Network Time Protocol. 165 OWAMP: One-Way Active Measurement Protocol. 167 PM: Performance Measurement. 169 PSID: Path Segment Identifier. 171 PTP: Precision Time Protocol. 173 SID: Segment ID. 175 SL: Segment List. 177 SR: Segment Routing. 179 SRH: Segment Routing Header. 181 SR-MPLS: Segment Routing with MPLS data plane. 183 SRv6: Segment Routing with IPv6 data plane. 185 STAMP: Simple Two-way Active Measurement Protocol. 187 TC: Traffic Class. 189 TWAMP: Two-Way Active Measurement Protocol. 191 2.3. Reference Topology 193 In the reference topology shown below, the sender node R1 initiates a 194 probe query for performance measurement and the reflector node R5 195 sends a probe response for the query message received. The probe 196 response is sent to the sender node R1. The nodes R1 and R5 may be 197 directly connected via a link enabled with Segment Routing or there 198 exists a Point-to-Point (P2P) SR Policy 199 [I-D.spring-segment-routing-policy] on node R1 with destination to 200 node R5. In case of Point-to-Multipoint (P2MP), SR Policy 201 originating from source node R1 may terminate on multiple destination 202 leaf nodes [I-D.spring-sr-p2mp-policy]. 204 +-------+ Query +-------+ 205 | | - - - - - - - - - ->| | 206 | R1 |---------------------| R5 | 207 | |<- - - - - - - - - - | | 208 +-------+ Response +-------+ 209 Sender Reflector 211 Reference Topology 213 3. Overview 215 For one-way, two-way and round-trip delay measurements in Segment 216 Routing networks, the TWAMP Light procedures defined in Appendix I of 217 [RFC5357] are used. For one-way and two-way direct-mode and 218 inferred-mode loss measurements in Segment Routing networks, the 219 procedures defined in this document are used. One-way loss 220 measurement provides receive packet loss whereas two-way loss 221 measurement provides both transmit and receive packet loss. Separate 222 UDP destination port numbers are user-configured for delay and loss 223 measurements from the range specified in [I-D.ippm-stamp]. The 224 sender uses the UDP port number following the guidelines specified in 225 Section 6 in [RFC6335]. For both links and end-to-end SR Policies, 226 no PM session for delay or loss measurement is created on the 227 reflector node R5 [RFC5357]. 229 For Performance Measurement, probe query and response messages are 230 sent as following: 232 o For Delay Measurement, the probe messages are sent on the 233 congruent path of the data traffic by the sender node, and are 234 used to measure the delay experienced by the actual data traffic 235 flowing on the links and SR Policies. 237 o For Loss Measurement, the probe messages are sent on the congruent 238 path of the data traffic by the sender node, and are used to 239 collect the receive traffic counters for the incoming link or 240 incoming SID where the probe query messages are received at the 241 reflector node (incoming link or incoming SID needed since the 242 reflector node does not have PM session state present). 244 The In-Situ Operations, Administration, and Maintenance (IOAM) 245 mechanisms for SR-MPLS defined in [I-D.spring-ioam-sr-mpls] and for 246 SRv6 defined in [I-D.spring-ioam-srv6] are used to carry PM 247 information such as timestamp in-band as part of the data packets, 248 and are outside the scope of this document. 250 3.1. Example Provisioning Model 252 An example of a provisioning model and typical measurement parameters 253 for performance delay and loss measurements is shown in the following 254 Figure: 256 +------------+ 257 | Controller | 258 +------------+ 259 Measurement Protocol / \ Measurement Protocol 260 Destination UDP Port / \ Destination UDP port 261 Measurement Type / \ Measurement Type 262 Delay/Loss / \ Delay/Loss 263 Authentication Mode & Key / \ Authentication Mode & Key 264 Timestamp Format / \ Loss Measurement Mode 265 Delay Measurement Mode / \ 266 Padding/MBZ Bytes / \ 267 Loss Measurement Mode / \ 268 v v 269 +-------+ +-------+ 270 | | | | 271 | R1 |------------| R5 | 272 | | | | 273 +-------+ +-------+ 274 Sender Reflector 276 Example Provisioning Model 278 The reflector node R5 uses the parameters for the timestamp format, 279 delay measurement mode (i.e. one-way, two-way or loopback mode) and 280 packet padding size from the received probe query message. 282 Examples of Measurement Protocol is TWAMP Light or STAMP, the 283 Timestamp Format is PTPv2 [IEEE1588] or NTP and the Loss Measurement 284 mode is inferred or direct mode. The mechanisms to provision the 285 sender and reflector nodes are outside the scope of this document. 287 3.2. STAMP Applicability 289 The Simple Two-way Active Measurement Protocol (STAMP) 290 [I-D.ippm-stamp] and the STAMP TLVs [I-D.ippm-stamp-option-tlv] are 291 both equally applicable to the procedures specified in this document. 292 This is because the delay measurement message formats defined for 293 STAMP and STAMP TLVs are backwards compatible with the delay 294 measurement message formats defined in [RFC5357]. Hence, the same 295 user-configured destination UDP port for delay measurement can be 296 used for STAMP and TWAMP Light messages. The STAMP with a TLV for 297 "direct measurement" can be used for combined delay + loss 298 measurement using a separate user-configured UDP destination port. 300 The loss measurement probe and query messages defined in this 301 document are also equally applicable to STAMP and STAMP TLVs, and use 302 the message formats defined in [I-D.ippm-stamp]. 304 4. Probe Messages 306 4.1. Probe Query Message 308 In this document, the probe messages defined in [RFC5357] are used 309 for Delay and Loss measurements for SR links and end-to-end SR 310 Policies. The user-configured destination UDP ports (separate UDP 311 ports for different delay and loss message formats) are used for 312 identifying the PM probe packets as described in Appendix I of 313 [RFC5357]. 315 The Sender IPv4 or IPv6 address is used as the source address. When 316 known, the reflector IPv4 or IPv6 address is used as the destination 317 address. If not known, the address in the range of 127/8 for IPv4 or 318 0:0:0:0:0:FFFF:7F00/104 for IPv6 is used as destination address. 319 This is the case for example, when using SR Policy with IPv4 endpoint 320 of 0.0.0.0 or IPv6 endpoint of ::0 321 [I-D.spring-segment-routing-policy]. 323 4.1.1. Delay Measurement Probe Query Message 325 The message content for Delay Measurement probe query message using 326 UDP header [RFC768] is shown in Figure 1. The DM probe query message 327 is sent with user-configured Destination UDP port number for DM. The 328 Destination UDP port cannot be used as Source port, since the message 329 does not have any indication to distinguish between query and 330 response. The DM probe query message contains the payload for delay 331 measurement defined in Section 4.1.2 of [RFC5357]. For symmetrical 332 size query and response messages [RFC6038], the DM probe query 333 message contains the payload format defined in Section 4.2.1 of 334 [RFC5357]. 336 +---------------------------------------------------------------+ 337 | IP Header | 338 . Source IP Address = Sender IPv4 or IPv6 Address . 339 . Destination IP Address = Reflector IPv4 or IPv6 Address . 340 . Protocol = UDP . 341 . . 342 +---------------------------------------------------------------+ 343 | UDP Header | 344 . Source Port = As chosen by Sender . 345 . Destination Port = User-configured Port for Delay Measurement. 346 . . 347 +---------------------------------------------------------------+ 348 | Payload = Message as specified in Section 4.2.1 of RFC 5357 | | 349 . Payload = Message as specified in Section 4.1.2 of RFC 5357 | . 350 . Payload = Message specified in Section 4.2 of [I-D.ippm-stamp]. 351 . . 352 +---------------------------------------------------------------+ 354 Figure 1: DM Probe Query Message 356 The Control Code field is defined in the modified DM probe message 357 format as follows. This DM probe message format is backwards 358 compatible with the format defined in [RFC5357] as its reflector MUST 359 ignore the received MBZ field. 361 . . 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 | Error Estimate | Reserved | Control Code | 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 365 . . 367 Control Code: Set as follows in a probe query and response messages. 369 For a Query: 371 0x0: Out-of-band Response Requested. Indicates that the response 372 is not required over the same path in the reverse direction. 373 This is also the default behavior. 375 0x1: In-band Response Requested. Indicates that this query has 376 been sent over a bidirectional path and the response is required 377 over the same path in the reverse direction. 379 For a Response: 381 0x1: Error - Invalid Message. Indicates that the operation 382 failed because the received query message was malformed. 384 Reserved: Reserved for future use. 386 Timestamp field is eight bytes and use the format defined in Section 387 4.2.1 of [RFC5357]. It is recommended to use the IEEE 1588v2 388 Precision Time Protocol (PTP) truncated 64-bit timestamp format 389 [IEEE1588] as specified in [RFC8186], preferred with hardware support 390 in Segment Routing networks. 392 4.1.1.1. Delay Measurement Authentication Mode 394 When using the authenticated mode for delay measurement, the matching 395 authentication type (e.g. HMAC-SHA-256) and key are user-configured 396 on both the sender and reflector nodes. A separate user-configured 397 destination UDP port is used for the delay measurement in 398 authentication mode due to the different probe message format. 400 4.1.2. Loss Measurement Probe Query Message 402 In this document, new probe query message formats are defined for 403 loss measurement as shown in Figure 3A and Figure 3B. The message 404 formats are hardware efficient due to the small size payload and 405 well-known locations of counters. They are similar to the delay 406 measurement message formats and do not require any backwards 407 compatibility and support for the existing DM message formats from 408 [RFC5357]. 410 The message content for Loss Measurement probe query message using 411 UDP header [RFC768] is shown in Figure 2. The LM probe query message 412 is sent with user-configured Destination UDP port number for LM. 413 Separate Destination UDP ports are used for direct-mode and 414 inferred-mode loss measurements. The Destination UDP port cannot be 415 used as Source port, since the message does not have any indication 416 to distinguish between query and response. The LM probe query 417 message contains the payload for loss measurement as defined in 418 Figure 3A-3D. 420 +---------------------------------------------------------------+ 421 | IP Header | 422 . Source IP Address = Sender IPv4 or IPv6 Address . 424 . Destination IP Address = Reflector IPv4 or IPv6 Address . 425 . Protocol = UDP . 426 . . 427 +---------------------------------------------------------------+ 428 | UDP Header | 429 . Source Port = As chosen by Sender . 430 . Destination Port = User-configured Port for Loss Measurement . 431 . . 432 +---------------------------------------------------------------+ 433 | Payload = Message as specified in Figure 3A or 3B | | 434 . Payload = Message as specified in Figure 3C or 3D . 435 . . 436 +---------------------------------------------------------------+ 438 Figure 2: LM Probe Query Message 440 0 1 2 3 441 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 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 | Sequence Number | 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 | Transmit Counter | 446 | | 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 |X|B| Reserved | Block Number | Reserved | Control Code | 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 | | 451 . Packet Padding . 452 . . 453 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 | | Checksum Complement | 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 Figure 3A: LM Probe Query Message Format 459 0 1 2 3 460 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 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 | Sequence Number | 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 | MBZ (12 octets) | 465 | | 466 | | 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 | Transmit Counter | 469 | | 470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 471 |X|B| Reserved | Block Number | Reserved | Control Code | 472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 | MBZ (4 octets) | 474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 | HMAC (16 octets) | 476 | | 477 | | 478 | | 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 | | 481 . Packet Padding . 482 . . 483 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 | | Checksum Complement | 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 Figure 3B: LM Probe Query Message Format - Authenticated Mode 489 0 1 2 3 490 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 491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 | Sequence Number | 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 | Transmit Counter | 495 | | 496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 497 |X|B| Reserved | Block Number | Reserved | Control Code | 498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 499 | | 500 | MBZ (28 octets) | 501 | | 502 | | 503 | | 504 | | 505 | | 506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 Figure 3C: STAMP LM Probe Query Message Format 510 0 1 2 3 511 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 512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 513 | Sequence Number | 514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 515 | MBZ (12 octets) | 516 | | 517 | | 518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 519 | Transmit Counter | 520 | | 521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 522 |X|B| Reserved | Block Number | Reserved | Control Code | 523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 524 ~ ~ 525 | MBZ (68 octets) | 526 ~ ~ 527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 528 | HMAC (16 octets) | 529 | | 530 | | 531 | | 532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 534 Figure 3D: STAMP LM Probe Query Message Format - Authenticated Mode 536 Sequence Number (32-bit): As defined in [RFC5357]. 538 Transmit Counter (64-bit): The number of packets or octets sent by 539 the sender node in the query message and by the reflector node in the 540 response message. The counter is always written at the fixed 541 location in the probe query and response messages. 543 Receive Counter (64-bit): The number of packets or octets received at 544 the reflector node. It is written by the reflector node in the probe 545 response message. 547 Sender Counter (64-bit): This is the exact copy of the transmit 548 counter from the received query message. It is written by the 549 reflector node in the probe response message. 551 Sender Sequence Number (32-bit): As defined in [RFC5357]. 553 Sender TTL: As defined in [RFC5357]. 555 LM Flags: The meanings of the Flag bits are: 557 X: Extended counter format indicator. Indicates the use of 558 extended (64-bit) counter values. Initialized to 1 upon creation 559 (and prior to transmission) of an LM Query and copied from an LM 560 Query to an LM response. Set to 0 when the LM message is 561 transmitted or received over an interface that writes 32-bit 562 counter values. 564 B: Octet (byte) count. When set to 1, indicates that the Counter 565 1-4 fields represent octet counts. The octet count applies to all 566 packets within the LM scope, and the octet count of a packet sent 567 or received includes the total length of that packet (but excludes 568 headers, labels, or framing of the channel itself). When set to 569 0, indicates that the Counter fields represent packet counts. 571 Block Number (8-bit): The Loss Measurement using Alternate-Marking 572 method defined in [RFC8321] requires to color the data traffic. To 573 be able to compare the transmit and receive traffic counters of the 574 matching color, the Block Number (or color) of the traffic counters 575 is carried by the probe query and response messages for loss 576 measurement. 578 HMAC: The PM probe packet in authenticated mode includes a key Hashed 579 Message Authentication Code (HMAC) ([RFC2104]) hash. Each probe 580 query and response messages are authenticated by adding Sequence 581 Number with Hashed Message Authentication Code (HMAC) TLV. It can 582 use HMAC-SHA-256 truncated to 128 bits (similarly to the use of it in 583 IPSec defined in [RFC4868]); hence the length of the HMAC field is 16 584 octets. 586 HMAC uses its own key and the mechanism to distribute the HMAC key is 587 outside the scope of this document. 589 In authenticated mode, only the sequence number is encrypted, and the 590 other payload fields are sent in clear text. The probe packet MAY 591 include Comp.MBZ (Must Be Zero) variable length field to align the 592 packet on 16 octets boundary. 594 4.1.2.1. Loss Measurement Authentication Mode 596 When using the authenticated mode for loss measurement, the matching 597 authentication type (e.g. HMAC-SHA-256) and key are user-configured 598 on both the sender and reflector nodes. A separate user-configured 599 destination UDP port is used for the loss measurement in 600 authentication mode due to the different message format. 602 4.1.3. Probe Query for SR Links 604 The probe query message as defined in Figure 1 is sent on the 605 congruent path of the data traffic for Delay measurement. The probe 606 query message as defined in Figure 2 is sent on the congruent path of 607 the data traffic for Loss measurement. 609 4.1.4. Probe Query for End-to-end Measurement for SR Policy 611 The performance delay and loss measurement for segment routing is 612 applicable to both SR-MPLS and SRv6 Policies. 614 4.1.4.1. Probe Query Message for SR-MPLS Policy 616 The probe query messages for end-to-end performance measurement of an 617 SR-MPLS Policy is sent using its SR-MPLS header containing the MPLS 618 segment list as shown in Figure 4. 620 0 1 2 3 621 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 622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 623 | Segment(1) | TC |S| TTL | 624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 625 . . 626 . . 627 . . 628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 629 | Segment(n) | TC |S| TTL | 630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 631 | PSID | TC |S| TTL | 632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 633 | Message as shown in Figure 1 for DM or Figure 2 for LM | 634 . . 635 +---------------------------------------------------------------+ 637 Figure 4: Probe Query Message for SR-MPLS Policy 639 The Segment List (SL) can be empty to indicate Implicit NULL label 640 case for a single-hop SR Policy. 642 The Path Segment Identifier (PSID) [I-D.spring-mpls-path-segment] of 643 the SR-MPLS Policy is used for accounting received traffic on the 644 egress node for loss measurement. The PSID is not required for 645 end-to-end SR Policy delay measurement. 647 4.1.4.2. Probe Query Message for SRv6 Policy 649 An SRv6 Policy setup using the SRv6 Segment Routing Header (SRH) and 650 a Segment List as defined in [I-D.6man-segment-routing-header]. The 651 probe query messages for end-to-end performance measurement of an 652 SRv6 Policy is sent using its SRH and Segment List as shown in Figure 653 5. 655 +---------------------------------------------------------------+ 656 | SRH | 657 . END.OTP (DM) or END.OP (LM) with Target SRv6 SID . 658 . . 659 +---------------------------------------------------------------+ 660 | Message as shown in Figure 1 for DM or Figure 2 for LM | 661 . (Using IPv6 Source and Destination Addresses) . 662 . . 663 +---------------------------------------------------------------+ 665 Figure 5: Probe Query Message for SRv6 Policy 667 For delay measurement of SRv6 Policy using SRH, END function END.OTP 668 [I-D.6man-srv6-oam] is used with the target SRv6 SID to punt probe 669 messages on the target node, as shown in Figure 5. Similarly, for 670 loss measurement of SRv6 Policy, END function END.OP 671 [I-D.6man-srv6-oam] is used with target SRv6 SID to punt probe 672 messages on the target node. 674 4.2. Probe Response Message 676 The probe response message is sent using the IP/UDP information from 677 the received probe query message. The content of the probe response 678 message is shown in Figure 6. 680 +---------------------------------------------------------------+ 681 | IP Header | 682 . Source IP Address = Reflector IPv4 or IPv6 Address . 683 . Destination IP Address = Source IP Address from Query . 684 . Protocol = UDP . 685 . . 686 +---------------------------------------------------------------+ 687 | UDP Header | 688 . Source Port = As chosen by Reflector . 689 . Destination Port = Source Port from Query . 690 . . 691 +---------------------------------------------------------------+ 692 | DM Payload as specified in Section 4.2.1 of RFC 5357, or | 693 . DM payload as specified in Section 4.3 of [I-D.ippm-stamp] . 694 . LM Payload as specified in Figure 7A or 7B in this document or. 695 . LM Payload as specified in Figure 7C or 7D in this document . 696 . . 697 +---------------------------------------------------------------+ 699 Figure 6: Probe Response Message 701 In this document, probe response message formats are defined for loss 702 measurement as shown in Figure 7A-7D. The message formats are 703 hardware efficient due to the small size payload and well known 704 locations of the counters. They are also similar to the delay 705 measurement message formats. 707 0 1 2 3 708 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 709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 710 | Sequence Number | 711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 712 | Transmit Counter | 713 | | 714 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 715 |X|B| Reserved | Block Number | Reserved | Control Code | 716 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 717 | Receive Counter | 718 | | 719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 720 | Sender Sequence Number | 721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 722 | Sender Counter | 723 | | 724 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 725 |X|B| Reserved |Sender Block Nu| MBZ | 726 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 727 | Sender TTL | | 728 +-+-+-+-+-+-+-+-+ + 729 | Packet Padding | 730 . . 731 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 732 | | Checksum Complement | 733 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 735 Figure 7A: LM Probe Response Message Format 737 0 1 2 3 738 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 739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 740 | Sequence Number | 741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 742 | MBZ (12 octets) | 743 | | 744 | | 745 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 746 | Transmit Counter | 747 | | 748 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 749 |X|B| Reserved | Block Number | Reserved | Control Code | 750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 751 | MBZ (4 octets) | 752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 753 | Receive Counter | 754 | | 755 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 756 | MBZ (8 octets) | 757 | | 758 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 759 | Sender Sequence Number | 760 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 761 | MBZ (12 octets) | 762 | | 763 | | 764 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 765 | Sender Counter | 766 | | 767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 768 |X|B| Reserved |Sender Block Nu| MBZ | 769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 770 | MBZ (4 octets) | 771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 772 | Sender TTL | | 773 +-+-+-+-+-+-+-+-+ + 774 | MBZ (15 octets) | 775 | | 776 | | 777 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 778 | HMAC (16 octets) | 779 | | 780 | | 781 | | 782 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 783 | | 784 . . 785 . Packet Padding . 786 . . 787 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 788 | | Checksum Complement | 789 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 791 Figure 7B: LM Probe Response Message Format - Authenticated Mode 793 0 1 2 3 794 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 795 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 796 | Sequence Number | 797 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 798 | Transmit Counter | 799 | | 800 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 801 |X|B| Reserved | Block Number | Reserved | Control Code | 802 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 803 | Receive Counter | 804 | | 805 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 806 | Sender Sequence Number | 807 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 808 | Sender Counter | 809 | | 810 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 811 |X|B| Reserved |Sender Block Nu| MBZ | 812 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 813 | Ses-Sender TTL| Reserved | 814 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 816 Figure 7C: STAMP LM Probe Response Message Format 818 0 1 2 3 819 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 820 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 821 | Sequence Number | 822 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 823 | MBZ (12 octets) | 824 | | 825 | | 826 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 827 | Transmit Counter | 828 | | 829 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 830 |X|B| Reserved | Block Number | Reserved | Control Code | 831 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 832 | MBZ (4 octets) | 833 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 834 | Receive Counter | 835 | | 836 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 837 | MBZ (8 octets) | 838 | | 839 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 840 | Sender Sequence Number | 841 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 842 | MBZ (12 octets) | 843 | | 844 | | 845 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 846 | Sender Counter | 847 | | 848 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 849 |X|B| Reserved |Sender Block Nu| MBZ | 850 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 851 | MBZ (4 octets) | 852 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 853 | Ses-Sender TTL| | 854 +-+-+-+-+-+-+-+-+ + 855 | MBZ (15 octets) | 856 | | 857 | | 858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 859 | HMAC (16 octets) | 860 | | 861 | | 862 | | 863 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 865 Figure 7D: STAMP LM Probe Response Message Format - Authenticated 867 4.2.1. One-way Measurement Mode 869 In one-way performance measurement mode, the probe response message 870 as defined in Figure 6 is sent back out-of-band to the sender node, 871 for both SR links and SR Policies. The Control Code is set to 872 "Out-of-band Response Requested". 874 4.2.2. Two-way Measurement Mode 876 In two-way performance measurement mode, when using a bidirectional 877 path, the probe response message as defined in Figure 6 is sent back 878 to the sender node on the congruent path of the data traffic on the 879 same reverse direction SR Link or associated reverse SR Policy 880 [I-D.bidir-sr]. The Control Code is set to "In-band Response 881 Requested". 883 4.2.2.1. Probe Response Message for SR-MPLS Policy 885 The message content for sending probe response message for two-way 886 end-to-end performance measurement of an SR-MPLS Policy is shown in 887 Figure 9. 889 0 1 2 3 890 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 891 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 892 | Segment(1) | TC |S| TTL | 893 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 894 . . 896 . . 897 . . 898 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 899 | Segment(n) | TC |S| TTL | 900 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 901 | Message as shown in Figure 6 | 902 . . 903 +---------------------------------------------------------------+ 905 Figure 9: Probe Response Message for SR-MPLS Policy 907 The Path Segment Identifier (PSID) [I-D.spring-mpls-path-segment] of 908 the forward SR Policy in the probe query can be used to find the 909 associated reverse SR Policy [I-D.bidir-sr] to send the probe 910 response message for two-way measurement of SR Policy when Return 911 Path TLV is not sent. 913 4.2.2.2. Probe Response Message for SRv6 Policy 915 The message content for sending probe response message on the 916 congruent path of the data traffic for two-way end-to-end performance 917 measurement of an SRv6 Policy with SRH is shown in Figure 10. 919 +---------------------------------------------------------------+ 920 | SRH | 921 . END.OTP (DM) or END.OP (LM) with Target SRv6 SID . 922 . . 923 +---------------------------------------------------------------+ 924 | Message as shown in Figure 6 | 925 . (with IPv6 Source and Destination Addresses) . 926 . . 927 +---------------------------------------------------------------+ 929 Figure 10: Probe Response Message for SRv6 Policy 931 4.2.3. Loopback Measurement Mode 933 The Loopback measurement mode can be used to measure round-trip delay 934 for a bidirectional SR Path. The IP header of the probe query 935 message contains the destination address equals to the sender address 936 and the source address equals to the reflector address. Optionally, 937 the probe query message can carry the reverse path information (e.g. 938 reverse path label stack for SR-MPLS) as part of the SR header. The 939 reflector node does not process the PM probe messages and generate 940 response messages. 942 4.3. Return Path TLV 943 For two-way performance measurement, the reflector node needs to send 944 the probe response message on a specific reverse path. The sender 945 node can request in the probe query message to the reflector node to 946 send a response back on a given reverse path (e.g. co-routed 947 bidirectional path). This way the destination node does not require 948 any additional SR Policy state. 950 For one-way performance measurement, the sender node address may not 951 be reachable via IP route from the reflector node. The sender node 952 in this case needs to send its reachability path information to the 953 reflector node. 955 [I-D.ippm-stamp-option-tlv] defines STAMP probe query messages that 956 can include one or more optional TLVs. The TLV Type (TBA1) is 957 defined in this document for Return Path to carry reverse path for 958 probe response messages (in the payload of the message). The format 959 of the Return Path TLV is shown in Figure 8A and Figure 8B: 961 0 1 2 3 962 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 963 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 964 | Type = TBA1 | Length | Reserved | 965 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 966 | Return Path Sub-TLVs | 967 . . 968 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 970 Figure 8A: Return Path TLV 972 The Node Address sub-TLV (shown in Figure 12) in the Return Path TLV 973 can be one of the following Types: 975 o Type (value 0): Return Address. Target node address of the 976 response different than the Source Address in the query 978 0 1 2 3 979 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 980 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 981 | Type | Length | Reserved | 982 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 983 | Segment(1) | 984 . . 985 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 986 . . 987 . . 988 . . 990 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 991 | Segment(n) | 992 . . 993 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 995 Figure 8B: Segment List Sub-TLV in Return Path TLV 997 The Segment List Sub-TLV (shown in Figure 8B) in the Return Path TLV 998 can be one of the following Types: 1000 o Type (value 1): SR-MPLS Label Stack of the Reverse SR Path 1002 o Type (value 2): SR-MPLS Binding SID [I-D.pce-binding-label-sid] of 1003 the Reverse SR Policy 1005 o Type (value 3): SRv6 Segment List of the Reverse SR Path 1007 o Type (value 4): SRv6 Binding SID [I-D.pce-binding-label-sid] of 1008 the Reverse SR Policy 1010 The Return Path TLV is optional. The PM sender node MUST only insert 1011 one Return Path TLV in the probe query message and the reflector node 1012 MUST only process the first Return Path TLV in the probe query 1013 message and ignore other Return Path TLVs if present. The reflector 1014 node MUST send probe response message back on the reverse path 1015 specified in the Return Path TLV and MUST NOT add Return Path TLV in 1016 the probe response message. 1018 In the absence of Return Path TLV, in two-way measurement mode, the 1019 probe response message is sent back on the incoming physical 1020 interface where the probe query message is received. This is useful 1021 for example, in case of two-way measurement mode for SR link delay. 1023 4.4. Node Address TLV 1025 The Node Address TLV has the following format: 1027 0 1 2 3 1028 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 1029 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1030 | Type | Length | Address Family | 1031 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1032 ~ Address ~ 1033 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1034 Figure 12: Node Address TLV Format 1036 The Address Family field indicates the type of the address, and it 1037 SHALL be set to one of the assigned values in the "IANA Address 1038 Family Numbers" registry. 1040 The Node Address TLV is of the following Type: Destination Node 1041 Address. 1043 The Destination Node Address TLV is optional. The Destination Node 1044 Address TLV indicates the address of the intended recipient of the 1045 probe message. The destination node SHOULD NOT send response if it 1046 is not the intended destination node of the prone query message. 1047 This check is useful for example, for performance measurement of SR 1048 Policy when using the destination address in 127/8 range for IPv4 or 1049 in 0:0:0:0:0:FFFF:7F00/104 range for IPv6. 1051 5. Performance Measurement for P2MP SR Policies 1053 The procedures for delay and loss measurement described in this 1054 document for Point-to-Point (P2P) SR Policies 1055 [I-D.spring-segment-routing-policy] are also equally applicable to 1056 the Point-to-Multipoint (P2MP) SR Policies 1057 [I-D.spring-sr-p2mp-policy] as following: 1059 o The sender root node sends probe query messages using the 1060 Replication Segment defined in [I-D.spring-sr-p2mp-policy] for the 1061 P2MP SR Policy as shown in Figure 11. 1063 o Each reflector leaf node sends its IP address in the Source 1064 Address of the probe response messages as shown in Figure 6. This 1065 allows the sender root node to identify the reflector leaf nodes 1066 of the P2MP SR Policy. 1068 o The P2MP root node measures the end-to-end delay and loss 1069 performance for each P2MP leaf node of the P2MP SR Policy. 1071 0 1 2 3 1072 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 1073 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1074 | Replication SID | TC |S| TTL | 1075 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1076 | Message as shown in Figure 1 for DM or Figure 2 for LM | 1077 . . 1078 +---------------------------------------------------------------+ 1079 Figure 11: With Replication Segment for SR-MPLS Policy 1081 6. ECMP Support for SR Policies 1083 An SR Policy can have ECMPs between the source and transit nodes, 1084 between transit nodes and between transit and destination nodes. 1085 Usage of Anycast SID [RFC8402] by an SR Policy can result in ECMP 1086 paths via transit nodes part of that Anycast group. The PM probe 1087 messages need to be sent to traverse different ECMP paths to measure 1088 performance delay of an SR Policy. 1090 Forwarding plane has various hashing functions available to forward 1091 packets on specific ECMP paths. The mechanisms described in 1092 [RFC8029] and [RFC5884] for handling ECMPs are also applicable to the 1093 performance measurement. In the IP header of the PM probe messages, 1094 sweeping of Destination Addresses in 127/8 range for IPv4 or 1095 0:0:0:0:0:FFFF:7F00/104 range for IPv6 can be used to exercise a 1096 particular ECMP path. As specified in [RFC6437], Flow Label field in 1097 the IPv6 header can also be used for sweeping. 1099 The considerations for performance loss measurement for different 1100 ECMP paths of an SR Policy are outside the scope of this document. 1102 7. Additional Message Processing Rules 1104 7.1. TTL Value 1106 The TTL or the Hop Limit field in the IP, MPLS and SRH headers of the 1107 probe query messages are set to 255 [RFC5357]. 1109 When using the Destination IPv4 Address from the 127/8 range, the TTL 1110 in the IPv4 header is set to 1 [RFC8029]. Similarly, when using the 1111 Destination IPv6 Address from the 0:0:0:0:0:FFFF:7F00/104 range, the 1112 Hop Limit field in the inner IPv6 header is set to 1 whereas in the 1113 outer IPv6 header is set to 255. 1115 7.2. Router Alert Option 1117 The Router Alert IP option is not set when using the routable 1118 Destination IP Address in the probe messages. 1120 When using the Destination IPv4 Address from the 127/8 range, to be 1121 able to punt probe packets on the reflector node, the Router Alert IP 1122 Option of value 0x0 [RFC2113] for IPv4 MAY be added [RFC8029]. 1123 Similarly, when using the Destination IPv6 Address from the 1124 0:0:0:0:0:FFFF:7F00/104 range, the Router Alert IP Option of value 69 1126 [RFC7506] for IPv6 MAY be added in the destination option. For SRv6 1127 Policy using SRH, it is added in the inner IPv6 header. 1129 7.3. UDP Checksum 1131 The Checksum Complement for delay and loss measurement messages 1132 follows the procedure defined in [RFC7820] and can be optionally used 1133 with the procedures defined in this document. 1135 For IPv4 and IPv6 probe messages, where the hardware is not capable 1136 of re-computing the UDP checksum or adding checksum complement 1137 [RFC7820], the sender node sets the UDP checksum to 0 [RFC6936] 1138 [RFC8085]. The receiving node bypasses the checksum validation and 1139 accepts the packets with UDP checksum value 0 for the UDP port being 1140 used for PM delay and loss measurements. 1142 8. Security Considerations 1144 The performance measurement is intended for deployment in 1145 well-managed private and service provider networks. As such, it 1146 assumes that a node involved in a measurement operation has 1147 previously verified the integrity of the path and the identity of the 1148 far-end reflector node. 1150 If desired, attacks can be mitigated by performing basic validation 1151 and sanity checks, at the sender, of the counter or timestamp fields 1152 in received measurement response messages. The minimal state 1153 associated with these protocols also limits the extent of measurement 1154 disruption that can be caused by a corrupt or invalid message to a 1155 single query/response cycle. 1157 Use of HMAC-SHA-256 in the authenticated mode protects the data 1158 integrity of the probe messages. SRv6 has HMAC protection 1159 authentication defined for SRH [I-D.6man-segment-routing-header]. 1160 Hence, PM probe messages for SRv6 may not need authentication mode. 1161 Cryptographic measures may be enhanced by the correct configuration 1162 of access-control lists and firewalls. 1164 9. IANA Considerations 1166 IANA is requested to allocate a value for the following optional 1167 Return Path TLV Type for [I-D.ippm-stamp-option-tlv] to be carried in 1168 PM probe query messages: 1170 o Type TBA1: Return Path TLV 1172 IANA is also requested to allocate the values for the following 1173 Sub-TLV Types for the Return Path TLV. 1175 o Type (value 0): Return Address 1177 o Type (value 1): SR-MPLS Label Stack of the Reverse SR Path 1179 o Type (value 2): SR-MPLS Binding SID [I-D.pce-binding-label-sid] 1180 of the Reverse SR Policy 1182 o Type (value 3): SRv6 Segment List of the Reverse SR Path 1184 o Type (value 4): SRv6 Binding SID [I-D.pce-binding-label-sid] of 1185 the Reverse SR Policy 1187 IANA is requested to allocate a value for the following optional 1188 Destination Address TLV Type for [I-D.ippm-stamp-option-tlv] to be 1189 carried in PM probe message: 1191 o Type TBA2: Destination Address TLV 1193 10. References 1195 10.1. Normative References 1197 [RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1198 August 1980. 1200 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1201 Requirement Levels", RFC 2119, March 1997. 1203 [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. 1204 Zekauskas, "A One-way Active Measurement Protocol 1205 (OWAMP)", RFC 4656, September 2006. 1207 [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. 1208 Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", 1209 RFC 5357, October 2008. 1211 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1212 2119 Key Words", RFC 8174, May 2017. 1214 [I-D.6man-srv6-oam] Ali, Z., et al., "Operations, Administration, 1215 and Maintenance (OAM) in Segment Routing Networks with 1216 IPv6 Data plane (SRv6)", draft-ietf-6man-spring-srv6-oam, 1217 work in progress. 1219 [I-D.ippm-stamp] Mirsky, G. et al., "Simple Two-way Active 1220 Measurement Protocol", draft-ietf-ippm-stamp, work in 1221 progress. 1223 [I-D.ippm-stamp-option-tlv] Mirsky, G., et al., "Simple Two-way 1224 Active Measurement Protocol Optional Extensions", 1225 draft-ietf-ippm-stamp-option-tlv, work in progress. 1227 10.2. Informative References 1229 [IEEE1588] IEEE, "1588-2008 IEEE Standard for a Precision Clock 1230 Synchronization Protocol for Networked Measurement and 1231 Control Systems", March 2008. 1233 [RFC2104] Krawczyk, H., Bell-are, M., and R. Canetti, "HMAC: Keyed- 1234 Hashing for Message Authentication", RFC 2104, February 1235 1997. 1237 [RFC2113] Katz, D., "IP Router Alert Option", RFC 2113, February 1238 1997. 1240 [RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA- 1241 384, and HMAC-SHA-512 with IPsec", RFC 4868, May 2007. 1243 [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, 1244 "Bidirectional Forwarding Detection (BFD) for MPLS Label 1245 Switched Paths (LSPs)", RFC 5884, DOI 10.17487/RFC5884, 1246 June 2010. 1248 [RFC6038] Morton, A. and L. Ciavattone, "Two-Way Active Measurement 1249 Protocol (TWAMP) Reflect Octets and Symmetrical Size 1250 Features", RFC 6038, October, 2010 1252 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 1253 Cheshire, "Internet Assigned Numbers Authority (IANA) 1254 Procedures for the Management of the Service Name and 1255 Transport Protocol Port Number Registry", BCP 165,RFC 1256 6335, August 2011. 1258 [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, 1259 "IPv6 Flow Label Specification", RFC 6437, November 2011. 1261 [RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement 1262 for the Use of IPv6 UDP Datagrams with Zero Checksums", 1263 RFC 6936, April 2013. 1265 [RFC7506] Raza, K., Akiya, N., and C. Pignataro, "IPv6 Router Alert 1266 Option for MPLS Operations, Administration, and 1267 Maintenance (OAM)", RFC 7506, DOI 10.17487/RFC7506, April 1268 2015, . 1270 [RFC7820] Mizrahi, T., "UDP Checksum Complement in the One-Way 1271 Active Measurement Protocol (OWAMP) and Two-Way Active 1272 Measurement Protocol (TWAMP)", RFC 7820, March 2016. 1274 [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Kumar, N., 1275 Aldrin, S. and M. Chen, "Detecting Multiprotocol Label 1276 Switched (MPLS) Data-Plane Failures", RFC 8029, March 1277 2017. 1279 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 1280 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 1281 March 2017, . 1283 [RFC8186] Mirsky, G., and I. Meilik, "Support of the IEEE 1588 1284 Timestamp Format in a Two-Way Active Measurement Protocol 1285 (TWAMP)", RFC 8186, June 2017. 1287 [RFC8321] Fioccola, G. Ed., "Alternate-Marking Method for Passive 1288 and Hybrid Performance Monitoring", RFC 8321, January 1289 2018. 1291 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 1292 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1293 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 1294 July 2018, . 1296 [I-D.spring-segment-routing-policy] Filsfils, C., et al., "Segment 1297 Routing Policy Architecture", 1298 draft-ietf-spring-segment-routing-policy, work in 1299 progress. 1301 [I-D.spring-sr-p2mp-policy] Voyer, D. Ed., et al., "SR Replication 1302 Segment for Multi-point Service Delivery", 1303 draft-voyer-spring-sr-replication-segment, work in 1304 progress. 1306 [I-D.spring-mpls-path-segment] Cheng, W., et al., "Path Segment in 1307 MPLS Based Segment Routing Network", 1308 draft-ietf-spring-mpls-path-segment, work in progress. 1310 [I-D.6man-segment-routing-header] Filsfils, C., et al., "IPv6 1311 Segment Routing Header (SRH)", 1312 draft-ietf-6man-segment-routing-header, work in progress. 1314 [I-D.pce-binding-label-sid] Filsfils, C., et al., "Carrying Binding 1315 Label/ Segment-ID in PCE-based Networks", 1316 draft-ietf-pce-binding-label-sid, work in progress. 1318 [BBF.TR-390] "Performance Measurement from IP Edge to Customer 1319 Equipment using TWAMP Light", BBF TR-390, May 2017. 1321 [I-D.spring-ioam-sr-mpls] Gandhi, R. Ed., et al., "Segment Routing 1322 with MPLS Data Plane Encapsulation for In-situ OAM Data", 1323 draft-gandhi-spring-ioam-sr-mpls, work in progress. 1325 [I-D.spring-ioam-srv6] Ali, Z., et al., "Segment Routing Header 1326 encapsulation for In-situ OAM Data", 1327 draft-ali-spring-ioam-srv6, work in progress. 1329 [I-D.bidir-sr] Li, C., et al., "PCEP Extensions for Associated 1330 Bidirectional Segment Routing (SR) Paths", 1331 draft-li-pce-sr-bidir-path, work in progress. 1333 Acknowledgments 1335 The authors would like to thank Thierry Couture for the discussions 1336 on the use-cases for TWAMP Light in Segment Routing. The authors 1337 would also like to thank Greg Mirsky for reviewing this document and 1338 providing useful comments and suggestions. Patrick Khordoc and Radu 1339 Valceanu, both from Cisco Systems have helped significantly improve 1340 the mechanisms defined in this document. The authors would like to 1341 acknowledge the earlier work on the loss measurement using TWAMP 1342 described in draft-xiao-ippm-twamp-ext-direct-loss. The authors 1343 would also like to thank Sam Aldrin for the discussions to check for 1344 broken path. 1346 Authors' Addresses 1348 Rakesh Gandhi (editor) 1349 Cisco Systems, Inc. 1350 Canada 1351 Email: rgandhi@cisco.com 1353 Clarence Filsfils 1354 Cisco Systems, Inc. 1355 Email: cfilsfil@cisco.com 1357 Daniel Voyer 1358 Bell Canada 1359 Email: daniel.voyer@bell.ca 1361 Mach(Guoyi) Chen 1362 Huawei 1363 Email: mach.chen@huawei.com 1365 Bart Janssens 1366 Colt 1367 Email: Bart.Janssens@colt.net