idnits 2.17.1 draft-gandhi-spring-stamp-srpm-01.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 210 has weird spacing: '...esponse t3 +...' -- The document date (June 5, 2020) is 1420 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 (-10) exists of draft-ietf-ippm-stamp-option-tlv-04 -- Obsolete informational reference (is this intentional?): RFC 8321 (Obsoleted by RFC 9341) == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-07 == Outdated reference: A later version (-04) exists of draft-voyer-spring-sr-replication-segment-03 == 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-15 == 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-02 Summary: 0 errors (**), 0 flaws (~~), 11 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: December 7, 2020 D. Voyer 6 Bell Canada 7 M. Chen 8 Huawei 9 B. Janssens 10 Colt 11 June 5, 2020 13 Performance Measurement Using STAMP for Segment Routing Networks 14 draft-gandhi-spring-stamp-srpm-01 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 Paths including 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 December 7, 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 . . . . . . . 11 78 4.2. Probe Response Message . . . . . . . . . . . . . . . . . 14 79 4.2.1. One-way Measurement Mode . . . . . . . . . . . . . . 14 80 4.2.2. Two-way Measurement Mode . . . . . . . . . . . . . . 15 81 4.2.3. Loss Measurement Response Message Formats . . . . . . 16 82 4.3. Node Address TLV . . . . . . . . . . . . . . . . . . . . 19 83 4.4. Return Path TLV . . . . . . . . . . . . . . . . . . . . . 19 84 4.5. Additional Probe Message Processing Rules . . . . . . . . 21 85 4.5.1. TTL and Hop Limit . . . . . . . . . . . . . . . . . . 21 86 4.5.2. Router Alert Option . . . . . . . . . . . . . . . . . 21 87 4.5.3. UDP Checksum . . . . . . . . . . . . . . . . . . . . 21 88 5. Performance Measurement for P2MP SR Policies . . . . . . . . 22 89 6. ECMP Support for SR Policies . . . . . . . . . . . . . . . . 22 90 7. Performance Delay and Liveness Monitoring . . . . . . . . . . 23 91 8. Security Considerations . . . . . . . . . . . . . . . . . . . 23 92 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 93 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 94 10.1. Normative References . . . . . . . . . . . . . . . . . . 25 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 need for 115 control-channel signaling by using configuration data model to 116 provision a test-channel (e.g. UDP paths). 117 [I-D.ietf-ippm-stamp-option-tlv] defines TLV extensions for STAMP 118 messages. 120 The STAMP message with a TLV for "direct measurement" can be used for 121 combined Delay + Loss measurement [I-D.ietf-ippm-stamp-option-tlv]. 122 However, in order to use only for loss measurement purpose, it 123 requires the node to support the delay measurement messages and 124 support timestamp for these messages (which may also require clock 125 synchronization). Furthermore, for hardware-based counter collection 126 for direct-mode loss measurement, the optional TLV based processing 127 adds unnecessary overhead (as counters are not at well-known 128 locations). 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 [RFC8762] 133 (STAMP) (including the TLV extensions) for Delay Measurement (DM), 134 and uses the mechanisms defined in this document for Loss 135 Measurement. The procedure specified is applicable to SR-MPLS and 136 SRv6 data planes and is used for both Links and end-to-end SR Paths 137 including SR Policies. This document also defines mechanisms for 138 handling ECMPs of SR Paths for performance delay measurement. Unless 139 otherwise specified, the mechanisms defined in [RFC8762] and 140 [I-D.ietf-ippm-stamp-option-tlv] are not modified by this document. 142 2. Conventions Used in This Document 144 2.1. Requirements Language 146 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 147 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 148 document are to be interpreted as described in [RFC2119] [RFC8174] 149 when, and only when, they appear in all capitals, as shown here. 151 2.2. Abbreviations 153 BSID: Binding Segment ID. 155 DM: Delay Measurement. 157 ECMP: Equal Cost Multi-Path. 159 HMAC: Hashed Message Authentication Code. 161 LM: Loss Measurement. 163 MPLS: Multiprotocol Label Switching. 165 NTP: Network Time Protocol. 167 OWAMP: One-Way Active Measurement Protocol. 169 PM: Performance Measurement. 171 PSID: Path Segment Identifier. 173 PTP: Precision Time Protocol. 175 SID: Segment ID. 177 SL: Segment List. 179 SR: Segment Routing. 181 SRH: Segment Routing Header. 183 SR-MPLS: Segment Routing with MPLS data plane. 185 SRv6: Segment Routing with IPv6 data plane. 187 SSID: STAMP Session Identifier. 189 STAMP: Simple Two-way Active Measurement Protocol. 191 TC: Traffic Class. 193 2.3. Reference Topology 195 In the reference topology shown below, the sender node R1 initiates a 196 probe query for performance measurement and the reflector node R5 197 sends a probe response for the query message received. The probe 198 response is sent to the sender node R1. The nodes R1 and R5 may be 199 directly connected via a Link or there exists a Point-to-Point (P2P) 200 SR Path e.g. SR Policy [I-D.ietf-spring-segment-routing-policy] on 201 node R1 with destination to node R5. In case of Point-to-Multipoint 202 (P2MP), SR Policy originating from source node R1 may terminate on 203 multiple destination leaf nodes 204 [I-D.voyer-spring-sr-replication-segment]. 206 +-------+ t1 Query t2 +-------+ 207 | | - - - - - - - - - ->| | 208 | R1 |=====================| R5 | 209 | |<- - - - - - - - - - | | 210 +-------+ t4 Response t3 +-------+ 211 Sender Reflector 213 Reference Topology 215 3. Overview 217 For one-way and two-way delay measurements in Segment Routing 218 networks, the probe messages defined in [RFC8762] are used. For 219 direct-mode and inferred-mode loss measurements in Segment Routing 220 networks, the messages defined in this document are used. Separate 221 UDP destination port numbers are user-configured for delay and loss 222 measurements from the range specified in [RFC8762]. As specified in 223 [RFC8762], the reflector supports the destination UDP port 862 for 224 delay measurement probe messages by default. This UDP port however, 225 is not used for loss measurement probe messages defined in this 226 document. The sender uses the UDP port number following the 227 guidelines specified in Section 6 in [RFC6335]. For both Links and 228 end-to-end SR Paths including SR Policies, no PM session for delay or 229 loss measurement is created on the reflector node R5 [RFC8762]. 231 For Performance Measurement, probe query and response messages are 232 sent as following: 234 o For Delay Measurement, the probe messages are sent on the 235 congruent path of the data traffic by the sender node, and are 236 used to measure the delay experienced by the actual data traffic 237 flowing on the Links and SR Paths. 239 o For Loss Measurement, the probe messages are sent on the congruent 240 path of the data traffic by the sender node, and are used to 241 collect the receive traffic counters for the incoming link or 242 incoming SID where the probe query messages are received at the 243 reflector node (incoming link or incoming SID needed since the 244 reflector node does not have PM session state present). 246 The In-Situ Operations, Administration, and Maintenance (IOAM) 247 mechanisms for SR-MPLS defined in [I-D.gandhi-mpls-ioam-sr] and for 248 SRv6 defined in [I-D.ali-spring-ioam-srv6] are used to carry PM 249 information such as timestamp in-band as part of the data packets, 250 and are outside the scope of this document. 252 3.1. Example Provisioning Model 254 An example of a provisioning model and typical measurement parameters 255 for each user-configured destination UDP port for performance delay 256 and loss measurements is shown in the following Figure 1: 258 +------------+ 259 | Controller | 260 +------------+ 261 Destination UDP Port / \ Destination UDP port 262 Measurement Protocol / \ Measurement Protocol 263 Measurement Type / \ Measurement Type 264 Delay/Loss / \ Delay/Loss 265 Authentication Mode & Key / \ Authentication Mode & Key 266 Timestamp Format / \ Loss Measurement Mode 267 Delay Measurement Mode / \ 268 Loss Measurement Mode / \ 269 v v 270 +-------+ +-------+ 271 | | | | 272 | R1 |============| R5 | 273 | | SR Path | | 274 +-------+ Or Link +-------+ 275 Sender Reflector 277 Figure 1: Example Provisioning Model 279 Example of Measurement Protocol is STAMP, example of the Timestamp 280 Format is PTPv2 [IEEE1588] or NTP and example of the Loss Measurement 281 mode is inferred-mode or direct-mode. 283 The mechanisms to provision the sender and reflector nodes are 284 outside the scope of this document. 286 The reflector node R5 uses the parameters for the timestamp format 287 and delay measurement mode (i.e. one-way or two-way mode) from the 288 received probe query message. 290 4. Probe Messages 292 4.1. Probe Query Message 294 The probe messages defined in [RFC8762] are used for Delay 295 Measurement for Links and end-to-end SR Paths including SR Policies. 296 For Loss Measurement, the probe messages defined in this document are 297 used. 299 The Sender IPv4 or IPv6 address is used as the source address. The 300 reflector IPv4 or IPv6 address is used as the destination address. 301 In the case of SR Policy with IPv4 endpoint of 0.0.0.0 or IPv6 302 endpoint of ::0 [I-D.ietf-spring-segment-routing-policy], the address 303 in the range of 127/8 for IPv4 or ::FFFF:127/104 for IPv6 is used as 304 the destination address, respectively. 306 4.1.1. Delay Measurement Query Message 308 The message content for Delay Measurement probe query message using 309 UDP header [RFC0768] is shown in Figure 2. The DM probe query 310 message is sent with user-configured Destination UDP port number for 311 DM. The Destination UDP port cannot be used as Source port, since 312 the message does not have any indication to distinguish between the 313 query and response message. The payload of the DM probe query 314 message contains the delay measurement message defined in [RFC8762]. 316 +---------------------------------------------------------------+ 317 | IP Header | 318 . Source IP Address = Sender IPv4 or IPv6 Address . 319 . Destination IP Address = Reflector IPv4 or IPv6 Address . 320 . Protocol = UDP . 321 . . 322 +---------------------------------------------------------------+ 323 | UDP Header | 324 . Source Port = As chosen by Sender . 325 . Destination Port = User-configured Port for Delay Measurement. 326 . . 327 +---------------------------------------------------------------+ 328 | Payload = DM Message as specified in Section 4.2 of RFC 8762 | 329 . . 330 +---------------------------------------------------------------+ 332 Figure 2: DM Probe Query Message 334 Timestamp field is eight bytes and use the format defined in 335 Section 4.2.1 of [RFC8762]. It is recommended to use the IEEE 1588v2 336 Precision Time Protocol (PTP) truncated 64-bit timestamp format 337 [IEEE1588] as specified in [RFC8186], with hardware support in 338 Segment Routing networks. 340 4.1.1.1. Delay Measurement Authentication Mode 342 When using the authenticated mode for delay measurement, the matching 343 authentication type (e.g. HMAC-SHA-256) and key are user-configured 344 on both the sender and reflector nodes. A separate user-configured 345 destination UDP port is used for the delay measurement in 346 authentication mode due to the different probe message format. 348 4.1.2. Loss Measurement Query Message 350 The message content for Loss Measurement probe query message using 351 UDP header [RFC0768] is shown in Figure 3. The LM probe query 352 message is sent with user-configured Destination UDP port number for 353 LM, which is a different Destination UDP port number than DM. 354 Separate Destination UDP ports are used for direct-mode and inferred- 355 mode loss measurements. The Destination UDP port cannot be used as 356 Source port, since the message does not have any indication to 357 distinguish between the query and response message. The LM probe 358 query message contains the payload for loss measurement as defined in 359 Figure 7 and Figure 8. 361 +---------------------------------------------------------------+ 362 | IP Header | 363 . Source IP Address = Sender IPv4 or IPv6 Address . 364 . Destination IP Address = Reflector IPv4 or IPv6 Address . 365 . Protocol = UDP . 366 . . 367 +---------------------------------------------------------------+ 368 | UDP Header | 369 . Source Port = As chosen by Sender . 370 . Destination Port = User-configured Port for Loss Measurement . 371 . . 372 +---------------------------------------------------------------+ 373 | Payload = LM Message as specified in Figure 7 or 8 | 374 . . 375 +---------------------------------------------------------------+ 377 Figure 3: LM Probe Query Message 379 4.1.2.1. Loss Measurement Authentication Mode 381 When using the authenticated mode for loss measurement, the matching 382 authentication type (e.g. HMAC-SHA-256) and key are user-configured 383 on both the sender and reflector nodes. A separate user-configured 384 destination UDP port is used for the loss measurement in 385 authentication mode due to the different message format. 387 4.1.3. Probe Query for Links 389 The probe query message as defined in Figure 2 for delay measurement 390 and Figure 3 for loss measurement is sent on the congruent path of 391 the data traffic. The probe messages are routed over the Link for 392 both delay and loss measurement. 394 4.1.4. Probe Query for End-to-end Measurement for SR Policy 396 The performance delay and loss measurement for segment routing is 397 applicable to both SR-MPLS and SRv6 Policies. 399 4.1.4.1. Probe Query Message for SR-MPLS Policy 401 The probe query messages for end-to-end performance measurement of an 402 SR-MPLS Policy is sent using its SR-MPLS header containing the MPLS 403 segment list as shown in Figure 4. 405 0 1 2 3 406 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 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 | Segment(1) | TC |S| TTL | 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 . . 411 . . 412 . . 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 | Segment(n) | TC |S| TTL | 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 | PSID | TC |S| TTL | 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 | Message as shown in Figure 2 for DM or Figure 3 for LM | 419 . . 420 +---------------------------------------------------------------+ 422 Figure 4: Example Probe Query Message for SR-MPLS Policy 424 The Segment List (SL) can be empty to indicate Implicit NULL label 425 case for a single-hop SR Policy. 427 The Path Segment Identifier (PSID) 428 [I-D.ietf-spring-mpls-path-segment] of the SR-MPLS Policy is used for 429 accounting received traffic on the egress node for loss measurement. 431 4.1.4.2. Probe Query Message for SRv6 Policy 433 An SRv6 Policy setup using the SRv6 Segment Routing Header (SRH) and 434 a Segment List as defined in [RFC8754]. For SRv6, network 435 programming is defined in [I-D.ietf-spring-srv6-network-programming]. 436 The probe query messages for end-to-end performance measurement of an 437 SRv6 Policy is sent using its SRH with Segment List as shown in 438 Figure 5. 440 +---------------------------------------------------------------+ 441 | IP Header | 442 . Source IP Address = Sender IPv6 Address . 443 . Destination IP Address = Destination IPv6 Address . 444 . . 445 +---------------------------------------------------------------+ 446 | SRH as specified in RFC 8754 | 447 . . 448 . . 449 +---------------------------------------------------------------+ 450 | IP Header (Optional) | 451 . Source IP Address = Sender IPv6 Address . 452 . Destination IP Address = Reflector IPv6 Address . 453 . . 454 +---------------------------------------------------------------+ 455 | UDP Header | 456 . Source Port = As chosen by Sender . 457 . Destination Port = User-configured Port . 458 . . 459 +---------------------------------------------------------------+ 460 | Payload = DM Message as specified in Section 4.2 of RFC 8762| | 461 . Payload = LM Message as specified in Figure 7 or 8 . 462 . . 463 +---------------------------------------------------------------+ 465 Figure 5: Example Probe Query Message for SRv6 Policy 467 4.1.5. Control Code Field for STAMP Messages 469 The Control Code field is defined for delay and loss measurement 470 probe query messages for STAMP protocol in unauthenticated and 471 authenticated modes. The modified delay measurement probe query 472 message format is shown in Figure 6. This message format is 473 backwards compatible with the message format defined in STAMP 474 [RFC8762] as its reflector MUST ignore the received field (previously 475 identified as MBZ). The usage of the Control Code is not limited to 476 the SR paths and can be used for non-SR paths in a network. 478 . . 479 . . 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 481 | Timestamp | 482 | | 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 | Error Estimate | SSID | 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 | MBZ |Se Control Code| 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 . . 489 . . 491 Figure 6: Sender Control Code in STAMP DM Message 493 Sender Control Code: Set as follows in STAMP probe query message. 495 In a Query: 497 0x0: Out-of-band Response Requested. Indicates that the probe 498 response is not required over the same path in the reverse 499 direction. This is also the default behavior. 501 0x1: In-band Response Requested. Indicates that this query has 502 been sent over a bidirectional path and the probe response is 503 required over the same path in the reverse direction. 505 0x2: No Response Requested. 507 4.1.6. Loss Measurement Query Message Formats 509 In this document, STAMP probe query messages for loss measurement are 510 defined as shown in Figure 7 and Figure 8. The message formats are 511 hardware efficient due to well-known locations of the counters and 512 payload small in size. They are stand-alone and similar to the delay 513 measurement message formats (e.g. location of the Counter and 514 Timestamp). They also do not require backwards compatibility and 515 support for the existing DM message formats from [RFC8762] as 516 different user-configured destination UDP port is used for loss 517 measurement. 519 0 1 2 3 520 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 521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 522 | Sequence Number | 523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 524 | Transmit Counter | 525 | | 526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 527 |X|B| Reserved | Block Number | SSID | 528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 529 | MBZ |Se Control Code| 530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 531 | | 532 | MBZ (24 octets) | 533 | | 534 | | 535 | | 536 | | 537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 539 Figure 7: STAMP LM Probe Query Message - Unauthenticated Mode 541 0 1 2 3 542 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 543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 544 | Sequence Number | 545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 546 | MBZ (12 octets) | 547 | | 548 | | 549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 550 | Transmit Counter | 551 | | 552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 553 |X|B| Reserved | Block Number | SSID | 554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 555 | MBZ |Se Control Code| 556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 557 | MBZ (64 octets) | 558 . . 559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 560 | | 561 | HMAC (16 octets) | 562 | | 563 | | 564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 566 Figure 8: STAMP LM Probe Query Message - Authenticated Mode 568 Sequence Number (32-bit): As defined in [RFC8762]. 570 Transmit Counter (64-bit): The number of packets or octets sent by 571 the sender node in the query message and by the reflector node in the 572 response message. The counter is always written at the well-known 573 location in the probe query and response messages. 575 Receive Counter (64-bit): The number of packets or octets received at 576 the reflector node. It is written by the reflector node in the probe 577 response message. 579 Sender Counter (64-bit): This is the exact copy of the transmit 580 counter from the received query message. It is written by the 581 reflector node in the probe response message. 583 Sender Sequence Number (32-bit): As defined in [RFC8762]. 585 Sender TTL: As defined in Section 7.1. 587 LM Flags: The meanings of the Flag bits are: 589 X: Extended counter format indicator. Indicates the use of 590 extended (64-bit) counter values. Initialized to 1 upon creation 591 (and prior to transmission) of an LM Query and copied from an LM 592 Query to an LM response. Set to 0 when the LM message is 593 transmitted or received over an interface that writes 32-bit 594 counter values. 596 B: Octet (byte) count. When set to 1, indicates that the Counter 597 1-4 fields represent octet counts. The octet count applies to all 598 packets within the LM scope, and the octet count of a packet sent 599 or received includes the total length of that packet (but excludes 600 headers, labels, or framing of the channel itself). When set to 601 0, indicates that the Counter fields represent packet counts. 603 Block Number (8-bit): The Loss Measurement using Alternate-Marking 604 method defined in [RFC8321] requires to color the data traffic. To 605 be able to compare the transmit and receive traffic counters of the 606 matching color, the Block Number (or color) of the traffic counters 607 is carried by the probe query and response messages for loss 608 measurement. 610 HMAC: The PM probe message in authenticated mode includes a key 611 Hashed Message Authentication Code (HMAC) [RFC2104] hash. Each probe 612 query and response messages are authenticated by adding Sequence 613 Number with Hashed Message Authentication Code (HMAC) TLV. It can 614 use HMAC-SHA-256 truncated to 128 bits (similarly to the use of it in 615 IPSec defined in [RFC4868]); hence the length of the HMAC field is 16 616 octets. 618 HMAC uses its own key and the mechanism to distribute the HMAC key is 619 outside the scope of this document. 621 In authenticated mode, only the sequence number is encrypted, and the 622 other payload fields are sent in clear text. The probe message MAY 623 include Comp.MBZ (Must Be Zero) variable length field to align the 624 packet on 16 octets boundary. 626 4.2. Probe Response Message 628 The probe response message is sent using the IP/UDP information from 629 the received probe query message. The content of the probe response 630 message is shown in Figure 9. 632 +---------------------------------------------------------------+ 633 | IP Header | 634 . Source IP Address = Reflector IPv4 or IPv6 Address . 635 . Destination IP Address = Source IP Address from Query . 636 . Protocol = UDP . 637 . . 638 +---------------------------------------------------------------+ 639 | UDP Header | 640 . Source Port = As chosen by Reflector . 641 . Destination Port = Source Port from Query . 642 . . 643 +---------------------------------------------------------------+ 644 | Payload = DM Message as specified in Section 4.3 of RFC 8762| | 645 . Payload = LM Message as specified in Figure 12 or 13 . 646 . . 647 +---------------------------------------------------------------+ 649 Figure 9: Probe Response Message 651 4.2.1. One-way Measurement Mode 653 In one-way performance measurement mode, the probe response message 654 as defined in Figure 9 is sent back out-of-band to the sender node, 655 for both Links and SR Policies. The Sender Control Code is set to 656 "Out-of-band Response Requested". In this delay measurement mode, as 657 per Reference Topology, all timestamps t1, t2, t3, and t4 are 658 collected by the probes. However, only timestamps t1 and t2 are used 659 to measure one-way delay. 661 4.2.2. Two-way Measurement Mode 663 In two-way performance measurement mode, when using a bidirectional 664 path, the probe response message as defined in Figure 9 is sent back 665 to the sender node on the congruent path of the data traffic on the 666 same reverse direction Link or associated reverse SR Policy 667 [I-D.ietf-pce-sr-bidir-path]. The Sender Control Code is set to "In- 668 band Response Requested". In this delay measurement mode, as per 669 Reference Topology, all timestamps t1, t2, t3, and t4 are collected 670 by the probes. All four timestamps are used to measure two-way 671 delay. 673 Specifically, the probe response message is sent back on the incoming 674 physical interface where the probe query message is received. This 675 is required for example, in case of two-way measurement mode for Link 676 delay. 678 4.2.2.1. Probe Response Message for SR-MPLS Policy 680 The message content for sending probe response message for two-way 681 end-to-end performance measurement of an SR-MPLS Policy is shown in 682 Figure 10. 684 0 1 2 3 685 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 686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 687 | Segment(1) | TC |S| TTL | 688 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 689 . . 690 . . 691 . . 692 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 693 | Segment(n) | TC |S| TTL | 694 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 695 | Message as shown in Figure 9 | 696 . . 697 +---------------------------------------------------------------+ 699 Figure 10: Example Probe Response Message for SR-MPLS Policy 701 The Path Segment Identifier (PSID) 702 [I-D.ietf-spring-mpls-path-segment] of the forward SR Policy in the 703 probe query can be used to find the associated reverse SR Policy 704 [I-D.ietf-pce-sr-bidir-path] to send the probe response message for 705 two-way measurement of SR Policy unless when using STAMP message with 706 Return Path TLV. 708 4.2.2.2. Probe Response Message for SRv6 Policy 710 The message content for sending probe response message on the 711 congruent path of the data traffic for two-way end-to-end performance 712 measurement of an SRv6 Policy with SRH is shown in Figure 11. 714 +---------------------------------------------------------------+ 715 | IP Header | 716 . Source IP Address = Reflector IPv6 Address . 717 . Destination IP Address = Destination IPv6 Address . 718 . . 719 +---------------------------------------------------------------+ 720 | SRH as specified in RFC 8754 | 721 . . 722 . . 723 +---------------------------------------------------------------+ 724 | IP Header (Optional) | 725 . Source IP Address = Reflector IPv6 Address . 726 . Destination IP Address = Source IPv6 Address from Query . 727 . . 728 +---------------------------------------------------------------+ 729 | UDP Header | 730 . Source Port = As chosen by Sender . 731 . Destination Port = User-configured Port . 732 . . 733 +---------------------------------------------------------------+ 734 | Payload = DM Message as specified in Section 4.3 of RFC 8762| | 735 . Payload = LM Message as specified in Figure 12 or 13 . 736 . . 737 +---------------------------------------------------------------+ 739 Figure 11: Example Probe Response Message for SRv6 Policy 741 4.2.3. Loss Measurement Response Message Formats 743 In this document, STAMP probe response message formats are defined 744 for loss measurement as shown in Figure 12 and Figure 13. 746 0 1 2 3 747 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 748 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 749 | Sequence Number | 750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 751 | Transmit Counter | 752 | | 753 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 754 |X|B| Reserved | Block Number | SSID | 755 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 756 | Receive Counter | 757 | | 758 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 759 | Sender Sequence Number | 760 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 761 | Sender Counter | 762 | | 763 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 764 |X|B| Reserved |Sender Block Nu| MBZ | 765 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 766 | Sender TTL | MBZ | 767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 769 Figure 12: STAMP LM Probe Response Message - Unauthenticated Mode 771 0 1 2 3 772 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 773 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 774 | Sequence Number | 775 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 776 | MBZ (12 octets) | 777 | | 778 | | 779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 780 | Transmit Counter | 781 | | 782 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 783 |X|B| Reserved | Block Number | SSID | 784 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 785 | MBZ (4 octets) | 786 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 787 | Receive Counter | 788 | | 789 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 790 | MBZ (8 octets) | 791 | | 792 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 793 | Sender Sequence Number | 794 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 795 | MBZ (12 octets) | 796 | | 797 | | 798 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 799 | Sender Counter | 800 | | 801 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 802 |X|B| Reserved |Sender Block Nu| MBZ | 803 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 804 | MBZ (4 octets) | 805 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 806 | Sender TTL | | 807 +-+-+-+-+-+-+-+-+ | 808 | MBZ (15 octets) | 809 | | 810 | | 811 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 812 | | 813 | HMAC (16 octets) | 814 | | 815 | | 816 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 818 Figure 13: STAMP LM Probe Response Message - Authenticated Mode 820 4.3. Node Address TLV 822 In this document, Node Address TLV is defined for STAMP message 823 [I-D.ietf-ippm-stamp-option-tlv] and has the following format shown 824 in Figure 14: 826 0 1 2 3 827 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 828 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 829 | Type | Length | 830 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 831 | Reserved | Address Family | 832 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 833 ~ Address ~ 834 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 836 Figure 14: Node Address TLV Format 838 The Address Family field indicates the type of the address, and it 839 SHALL be set to one of the assigned values in the "IANA Address 840 Family Numbers" registry. 842 The following Type is defined and it contains Node Address TLV: 844 Destination Node Address (value TBA1): 846 The Destination Node Address TLV is optional. The Destination Node 847 Address TLV indicates the address of the intended recipient node of 848 the probe message. The reflector node MUST NOT send response if it 849 is not the intended destination node of the probe query message. 850 This check is useful for example, for performance measurement of SR 851 Policy when using the destination address in 127/8 range for IPv4 or 852 in ::FFFF:127/104 range for IPv6. 854 4.4. Return Path TLV 856 For two-way performance measurement, the reflector node needs to send 857 the probe response message on a specific reverse path. The sender 858 node can request in the probe query message to the reflector node to 859 send a response back on a given reverse path (e.g. co-routed 860 bidirectional path). This way the destination node does not require 861 any additional SR Policy state. 863 For one-way performance measurement, the sender node address may not 864 be reachable via IP route from the reflector node. The sender node 865 in this case needs to send its reachability path information to the 866 reflector node. 868 [I-D.ietf-ippm-stamp-option-tlv] defines STAMP probe query messages 869 that can include one or more optional TLVs. The TLV Type (value 870 TBA2) is defined in this document for Return Path that carries 871 reverse path for STAMP probe response messages (in the payload of the 872 message). The format of the Return Path TLV is shown in Figure 15: 874 0 1 2 3 875 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 876 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 877 | Type = TBA2 | Length | 878 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 879 | Return Path Sub-TLVs | 880 . . 881 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 883 Figure 15: Return Path TLV 885 The following Type defined for the Return Path TLV contains the Node 886 Address sub-TLV using the format shown in Figure 14: 888 o Type (value 0): Return Address. Target node address of the 889 response different than the Source Address in the query 891 0 1 2 3 892 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 893 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 894 | Type | Length | 895 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 896 | Segment(1) | 897 . . 898 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 899 . . 900 . . 901 . . 903 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 904 | Segment(n) | 905 . . 906 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 908 Figure 16: Segment List Sub-TLV in Return Path TLV 910 The Segment List Sub-TLV (shown in Figure 16) in the Return Path TLV 911 can be one of the following Types: 913 o Type (value 1): SR-MPLS Label Stack of the Reverse SR Path 914 o Type (value 2): SR-MPLS Binding SID 915 [I-D.ietf-pce-binding-label-sid] of the Reverse SR Policy 917 o Type (value 3): SRv6 Segment List of the Reverse SR Path 919 o Type (value 4): SRv6 Binding SID [I-D.ietf-pce-binding-label-sid] 920 of the Reverse SR Policy 922 The Return Path TLV is optional. The PM sender node MUST only insert 923 one Return Path TLV in the probe query message and the reflector node 924 MUST only process the first Return Path TLV in the probe query 925 message and ignore other Return Path TLVs if present. The reflector 926 node MUST send probe response message back on the reverse path 927 specified in the Return Path TLV and MUST NOT add Return Path TLV in 928 the probe response message. 930 4.5. Additional Probe Message Processing Rules 932 The processing rules defined in this section are applicable to the 933 STAMP messages for delay and loss measurement for Links and end-to- 934 end SR Paths including SR Policies. 936 4.5.1. TTL and Hop Limit 938 The TTL field in the IPv4 and MPLS headers of the probe query 939 messages is set to 255 [RFC8762]. Similarly, the Hop Limit field in 940 the IPv6 and SRH headers of the probe query messages is set to 255 941 [RFC8762]. 943 When using the Destination IPv4 Address from the 127/8 range, the TTL 944 in the IPv4 header is set to 1 [RFC8029]. Similarly, when using the 945 Destination IPv6 Address from the ::FFFF:127/104 range, the Hop Limit 946 field in the IPv6 header is set to 1. 948 For Link performance delay and loss measurements, the TTL or Hop 949 Limit field in the probe message is set to 1 in both one-way and two- 950 way measurement modes. 952 4.5.2. Router Alert Option 954 The Router Alert IP option (RAO) [RFC2113] is not set in the probe 955 messages. 957 4.5.3. UDP Checksum 959 The UDP Checksum Complement for delay and loss measurement messages 960 follows the procedure defined in [RFC7820] and can be optionally used 961 with the procedures defined in this document. 963 For IPv4 and IPv6 probe messages, where the hardware is not capable 964 of re-computing the UDP checksum or adding checksum complement 965 [RFC7820], the sender node sets the UDP checksum to 0 [RFC6936] 966 [RFC8085]. The receiving node bypasses the checksum validation and 967 accepts the packets with UDP checksum value 0 for the UDP port being 968 used for PM delay and loss measurements. 970 5. Performance Measurement for P2MP SR Policies 972 The procedures for delay and loss measurement described in this 973 document for Point-to-Point (P2P) SR Policies 974 [I-D.ietf-spring-segment-routing-policy] are also equally applicable 975 to the Point-to-Multipoint (P2MP) SR Policies as following: 977 o The sender root node sends probe query messages using the 978 Replication Segment defined in 979 [I-D.voyer-spring-sr-replication-segment] for the P2MP SR Policy 980 as shown in Figure 17. 982 o Each reflector leaf node sends its IP address in the Source 983 Address of the probe response messages as shown in Figure 9. This 984 allows the sender root node to identify the reflector leaf nodes 985 of the P2MP SR Policy. 987 o The P2MP root node measures the end-to-end delay and loss 988 performance for each P2MP leaf node of the P2MP SR Policy. 990 0 1 2 3 991 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 992 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 993 | Replication SID | TC |S| TTL | 994 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 995 | Message as shown in Figure 2 for DM or Figure 3 for LM | 996 . . 997 +---------------------------------------------------------------+ 999 Figure 17: Example Query with Replication Segment for SR-MPLS Policy 1001 6. ECMP Support for SR Policies 1003 An SR Policy can have ECMPs between the source and transit nodes, 1004 between transit nodes and between transit and destination nodes. 1005 Usage of Anycast SID [RFC8402] by an SR Policy can result in ECMP 1006 paths via transit nodes part of that Anycast group. The PM probe 1007 messages need to be sent to traverse different ECMP paths to measure 1008 performance delay of an SR Policy. 1010 Forwarding plane has various hashing functions available to forward 1011 packets on specific ECMP paths. The mechanisms described in 1012 [RFC8029] and [RFC5884] for handling ECMPs are also applicable to the 1013 performance measurement. In IPv4 header of the PM probe messages, 1014 sweeping of Destination Address in 127/8 range can be used to 1015 exercise particular ECMP paths. As specified in [RFC6437], Flow 1016 Label field in the outer IPv6 header can also be used for sweeping. 1018 The considerations for performance loss measurement for different 1019 ECMP paths of an SR Policy are outside the scope of this document. 1021 7. Performance Delay and Liveness Monitoring 1023 The procedure defined in this document for delay measurement using 1024 the STAMP probe messages can also be applied to liveness monitoring 1025 of Links and SR Paths. The one-way or two-way measurement mode can 1026 be used for liveness monitoring. Liveness failure is notified when 1027 consecutive N number of probe response messages are not received back 1028 at the sender node, where N is locally provisioned value. Note that 1029 detection interval and scale for number of sessions need to account 1030 for the processing of the probe messages which are punted out of fast 1031 path in forwarding (to slow path or control plane), and re-injected 1032 back on the reflector node. 1034 8. Security Considerations 1036 The performance measurement is intended for deployment in well- 1037 managed private and service provider networks. As such, it assumes 1038 that a node involved in a measurement operation has previously 1039 verified the integrity of the path and the identity of the far-end 1040 reflector node. 1042 If desired, attacks can be mitigated by performing basic validation 1043 and sanity checks, at the sender, of the counter or timestamp fields 1044 in received measurement response messages. The minimal state 1045 associated with these protocols also limits the extent of measurement 1046 disruption that can be caused by a corrupt or invalid message to a 1047 single query/response cycle. 1049 Use of HMAC-SHA-256 in the authenticated mode protects the data 1050 integrity of the probe messages. SRv6 has HMAC protection 1051 authentication defined for SRH [RFC8754]. Hence, PM probe messages 1052 for SRv6 may not need authentication mode. Cryptographic measures 1053 may be enhanced by the correct configuration of access-control lists 1054 and firewalls. 1056 9. IANA Considerations 1058 IANA will create a "STAMP TLV Type" registry for 1059 [I-D.ietf-ippm-stamp-option-tlv]. IANA is requested to allocate a 1060 value for the following mandatory Destination Address TLV Type from 1061 this registry. This TLV is to be carried in PM probe messages. 1063 o Type TBA1: Destination Node Address TLV 1065 IANA is also requested to allocate a value for the following 1066 mandatory Return Path TLV Type from the same registry. This TLV is 1067 to be carried in PM probe query messages. 1069 o Type TBA2: Return Path TLV 1071 IANA is requested to create a sub-registry for "Return Path Sub-TLV 1072 Type". All code points in the range 1 through 32759 in this registry 1073 shall be allocated according to the "IETF Review" procedure as 1074 specified in [RFC8126]. Code points in the range 32760 through 65279 1075 in this registry shall be allocated according to the "First Come 1076 First Served" procedure as specified in [RFC8126]. Remaining code 1077 points are allocated according to Table 1: 1079 +---------------+-------------------------+-------------------------+ 1080 | Value | Description | Reference | 1081 +---------------+-------------------------+-------------------------+ 1082 | 0- 32767 | Mandatory TLV, | IETF Review | 1083 | | unassigned | | 1084 | 32768 - 65279 | Optional TLV, | First Come First Served | 1085 | | unassigned | | 1086 | 65280 - 65519 | Experimental | This document | 1087 | 65520 - 65534 | Private Use | This document | 1088 | 65535 | Reserved | This document | 1089 +---------------+-------------------------+-------------------------+ 1091 Table 1: Return Path Sub-TLV Type Registry 1093 IANA is requested to allocate the values for the following Sub-TLV 1094 Types from this registry. 1096 o Type (value 0): Return Address 1098 o Type (value 1): SR-MPLS Label Stack of the Reverse SR Path 1100 o Type (value 2): SR-MPLS Binding SID 1101 [I-D.ietf-pce-binding-label-sid] of the Reverse SR Policy 1103 o Type (value 3): SRv6 Segment List of the Reverse SR Path 1104 o Type (value 4): SRv6 Binding SID [I-D.ietf-pce-binding-label-sid] 1105 of the Reverse SR Policy 1107 10. References 1109 10.1. Normative References 1111 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1112 DOI 10.17487/RFC0768, August 1980, 1113 . 1115 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1116 Requirement Levels", BCP 14, RFC 2119, 1117 DOI 10.17487/RFC2119, March 1997, 1118 . 1120 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1121 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1122 May 2017, . 1124 [RFC8762] Mirsky, G., Jun, G., Nydell, H., and R. Foote, "Simple 1125 Two-Way Active Measurement Protocol", RFC 8762, 1126 DOI 10.17487/RFC8762, March 2020, 1127 . 1129 [I-D.ietf-ippm-stamp-option-tlv] 1130 Mirsky, G., Min, X., Nydell, H., Foote, R., Masputra, A., 1131 and E. Ruffini, "Simple Two-way Active Measurement 1132 Protocol Optional Extensions", draft-ietf-ippm-stamp- 1133 option-tlv-04 (work in progress), March 2020. 1135 10.2. Informative References 1137 [IEEE1588] 1138 IEEE, "1588-2008 IEEE Standard for a Precision Clock 1139 Synchronization Protocol for Networked Measurement and 1140 Control Systems", March 2008. 1142 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 1143 Hashing for Message Authentication", RFC 2104, 1144 DOI 10.17487/RFC2104, February 1997, 1145 . 1147 [RFC2113] Katz, D., "IP Router Alert Option", RFC 2113, 1148 DOI 10.17487/RFC2113, February 1997, 1149 . 1151 [RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA- 1152 384, and HMAC-SHA-512 with IPsec", RFC 4868, 1153 DOI 10.17487/RFC4868, May 2007, 1154 . 1156 [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, 1157 "Bidirectional Forwarding Detection (BFD) for MPLS Label 1158 Switched Paths (LSPs)", RFC 5884, DOI 10.17487/RFC5884, 1159 June 2010, . 1161 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 1162 Cheshire, "Internet Assigned Numbers Authority (IANA) 1163 Procedures for the Management of the Service Name and 1164 Transport Protocol Port Number Registry", BCP 165, 1165 RFC 6335, DOI 10.17487/RFC6335, August 2011, 1166 . 1168 [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, 1169 "IPv6 Flow Label Specification", RFC 6437, 1170 DOI 10.17487/RFC6437, November 2011, 1171 . 1173 [RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement 1174 for the Use of IPv6 UDP Datagrams with Zero Checksums", 1175 RFC 6936, DOI 10.17487/RFC6936, April 2013, 1176 . 1178 [RFC7820] Mizrahi, T., "UDP Checksum Complement in the One-Way 1179 Active Measurement Protocol (OWAMP) and Two-Way Active 1180 Measurement Protocol (TWAMP)", RFC 7820, 1181 DOI 10.17487/RFC7820, March 2016, 1182 . 1184 [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., 1185 Aldrin, S., and M. Chen, "Detecting Multiprotocol Label 1186 Switched (MPLS) Data-Plane Failures", RFC 8029, 1187 DOI 10.17487/RFC8029, March 2017, 1188 . 1190 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 1191 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 1192 March 2017, . 1194 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1195 Writing an IANA Considerations Section in RFCs", BCP 26, 1196 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1197 . 1199 [RFC8186] Mirsky, G. and I. Meilik, "Support of the IEEE 1588 1200 Timestamp Format in a Two-Way Active Measurement Protocol 1201 (TWAMP)", RFC 8186, DOI 10.17487/RFC8186, June 2017, 1202 . 1204 [RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli, 1205 L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, 1206 "Alternate-Marking Method for Passive and Hybrid 1207 Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321, 1208 January 2018, . 1210 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 1211 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1212 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 1213 July 2018, . 1215 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 1216 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 1217 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 1218 . 1220 [I-D.ietf-spring-segment-routing-policy] 1221 Filsfils, C., Sivabalan, S., Voyer, D., Bogdanov, A., and 1222 P. Mattes, "Segment Routing Policy Architecture", draft- 1223 ietf-spring-segment-routing-policy-07 (work in progress), 1224 May 2020. 1226 [I-D.voyer-spring-sr-replication-segment] 1227 Voyer, D., Filsfils, C., Parekh, R., Bidgoli, H., and Z. 1228 Zhang, "SR Replication Segment for Multi-point Service 1229 Delivery", draft-voyer-spring-sr-replication-segment-03 1230 (work in progress), June 2020. 1232 [I-D.ietf-spring-mpls-path-segment] 1233 Cheng, W., Li, H., Chen, M., Gandhi, R., and R. Zigler, 1234 "Path Segment in MPLS Based Segment Routing Network", 1235 draft-ietf-spring-mpls-path-segment-02 (work in progress), 1236 February 2020. 1238 [I-D.ietf-spring-srv6-network-programming] 1239 Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., 1240 Matsushima, S., and Z. Li, "SRv6 Network Programming", 1241 draft-ietf-spring-srv6-network-programming-15 (work in 1242 progress), March 2020. 1244 [I-D.ietf-pce-binding-label-sid] 1245 Sivabalan, S., Filsfils, C., Tantsura, J., Hardwick, J., 1246 Previdi, S., and C. Li, "Carrying Binding Label/Segment-ID 1247 in PCE-based Networks.", draft-ietf-pce-binding-label- 1248 sid-02 (work in progress), March 2020. 1250 [I-D.gandhi-mpls-ioam-sr] 1251 Gandhi, R., Ali, Z., Filsfils, C., Brockners, F., Wen, B., 1252 and V. Kozak, "MPLS Data Plane Encapsulation for In-situ 1253 OAM Data", draft-gandhi-mpls-ioam-sr-02 (work in 1254 progress), March 2020. 1256 [I-D.ali-spring-ioam-srv6] 1257 Ali, Z., Gandhi, R., Filsfils, C., Brockners, F., Kumar, 1258 N., Pignataro, C., Li, C., Chen, M., and G. Dawra, 1259 "Segment Routing Header encapsulation for In-situ OAM 1260 Data", draft-ali-spring-ioam-srv6-02 (work in progress), 1261 November 2019. 1263 [I-D.ietf-pce-sr-bidir-path] 1264 Li, C., Chen, M., Cheng, W., Gandhi, R., and Q. Xiong, 1265 "PCEP Extensions for Associated Bidirectional Segment 1266 Routing (SR) Paths", draft-ietf-pce-sr-bidir-path-02 (work 1267 in progress), March 2020. 1269 Acknowledgments 1271 The authors would like to thank Thierry Couture for the discussions 1272 on the use-cases for Performance Measurement in Segment Routing. The 1273 authors would also like to thank Greg Mirsky for reviewing this 1274 document and providing useful comments and suggestions. Patrick 1275 Khordoc and Radu Valceanu, both from Cisco Systems have helped 1276 significantly improve the mechanisms defined in this document. The 1277 authors would like to acknowledge the earlier work on the loss 1278 measurement using TWAMP described in draft-xiao-ippm-twamp-ext- 1279 direct-loss. The authors would also like to thank Sam Aldrin for the 1280 discussions to check for broken path. 1282 Authors' Addresses 1284 Rakesh Gandhi (editor) 1285 Cisco Systems, Inc. 1286 Canada 1288 Email: rgandhi@cisco.com 1289 Clarence Filsfils 1290 Cisco Systems, Inc. 1292 Email: cfilsfil@cisco.com 1294 Daniel Voyer 1295 Bell Canada 1297 Email: daniel.voyer@bell.ca 1299 Mach(Guoyi) Chen 1300 Huawei 1302 Email: mach.chen@huawei.com 1304 Bart Janssens 1305 Colt 1307 Email: Bart.Janssens@colt.net