idnits 2.17.1 draft-gandhi-spring-stamp-srpm-04.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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 17) being 59 lines 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 (January 12, 2021) is 1200 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 (-03) exists of draft-gandhi-ippm-stamp-srpm-00 == Outdated reference: A later version (-10) exists of draft-ietf-ippm-stamp-option-tlv-09 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-08 == Outdated reference: A later version (-19) exists of draft-ietf-spring-sr-replication-segment-00 == Outdated reference: A later version (-04) exists of draft-shen-spring-p2mp-transport-chain-02 == Outdated reference: A later version (-08) exists of draft-ietf-pim-sr-p2mp-policy-00 == Outdated reference: A later version (-22) exists of draft-ietf-spring-mpls-path-segment-03 == Outdated reference: A later version (-28) exists of draft-ietf-spring-srv6-network-programming-24 == Outdated reference: A later version (-06) exists of draft-gandhi-mpls-ioam-sr-03 == 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-03 Summary: 0 errors (**), 0 flaws (~~), 13 warnings (==), 1 comment (--). 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: July 16, 2021 D. Voyer 6 Bell Canada 7 M. Chen 8 Huawei 9 B. Janssens 10 Colt 11 January 12, 2021 13 Performance Measurement Using Simple TWAMP (STAMP) for Segment Routing 14 Networks 15 draft-gandhi-spring-stamp-srpm-04 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 8762 (Simple Two-Way Active Measurement 25 Protocol (STAMP)) and its TLV extensions for Performance Measurement. 26 The procedure specified is applicable to SR-MPLS and SRv6 data planes 27 and is used for both Links and end-to-end SR Paths including SR 28 Policies. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on July 16, 2021. 47 Copyright Notice 49 Copyright (c) 2020 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (https://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 66 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 67 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3 68 2.3. Reference Topology . . . . . . . . . . . . . . . . . . . 4 69 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 3.1. Example Provisioning Model . . . . . . . . . . . . . . . 6 71 4. Probe Messages . . . . . . . . . . . . . . . . . . . . . . . 7 72 4.1. Probe Query Message . . . . . . . . . . . . . . . . . . . 7 73 4.1.1. Delay Measurement Query Message . . . . . . . . . . . 7 74 4.1.2. Loss Measurement Query Message . . . . . . . . . . . 8 75 4.1.3. Probe Query for Links . . . . . . . . . . . . . . . . 8 76 4.1.4. Probe Query for SR Policy . . . . . . . . . . . . . . 9 77 4.2. Probe Response Message . . . . . . . . . . . . . . . . . 11 78 4.2.1. One-way Measurement Mode . . . . . . . . . . . . . . 11 79 4.2.2. Two-way Measurement Mode . . . . . . . . . . . . . . 11 80 4.2.3. Loopback Measurement Mode . . . . . . . . . . . . . . 13 81 4.3. Additional Probe Message Processing Rules . . . . . . . . 14 82 4.3.1. TTL and Hop Limit . . . . . . . . . . . . . . . . . . 14 83 4.3.2. Router Alert Option . . . . . . . . . . . . . . . . . 14 84 4.3.3. UDP Checksum . . . . . . . . . . . . . . . . . . . . 14 85 5. Performance Measurement for P2MP SR Policies . . . . . . . . 15 86 6. ECMP Support for SR Policies . . . . . . . . . . . . . . . . 16 87 7. Performance Delay and Liveness Monitoring . . . . . . . . . . 16 88 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 89 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 90 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 91 10.1. Normative References . . . . . . . . . . . . . . . . . . 17 92 10.2. Informative References . . . . . . . . . . . . . . . . . 18 93 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 20 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 96 1. Introduction 98 Segment Routing (SR) leverages the source routing paradigm and 99 greatly simplifies network operations for Software Defined Networks 100 (SDNs). SR is applicable to both Multiprotocol Label Switching (SR- 101 MPLS) and IPv6 (SRv6) data planes. SR takes advantage of the Equal- 102 Cost Multipaths (ECMPs) between source and transit nodes, between 103 transit nodes and between transit and destination nodes. SR Policies 104 as defined in [I-D.ietf-spring-segment-routing-policy] are used to 105 steer traffic through a specific, user-defined paths using a stack of 106 Segments. Built-in SR Performance Measurement (PM) is one of the 107 essential requirements to provide Service Level Agreements (SLAs). 109 The Simple Two-way Active Measurement Protocol (STAMP) provides 110 capabilities for the measurement of various performance metrics in IP 111 networks using probe messages [RFC8762]. It eliminates the need for 112 control-channel signaling by using configuration data model to 113 provision a test-channel (e.g. UDP paths). 114 [I-D.ietf-ippm-stamp-option-tlv] defines TLV extensions for STAMP 115 messages. 117 This document specifies procedures for sending and processing probe 118 query and response messages for Performance Measurement in SR 119 networks. The procedure uses the mechanisms defined in [RFC8762] 120 (STAMP) and its TLV extensions [I-D.ietf-ippm-stamp-option-tlv] for 121 Performance Measurement. The procedure specified is applicable to 122 SR-MPLS and SRv6 data planes and is used for both Links and end-to- 123 end SR Paths including SR Policies and Flex-Algo IGP Paths. Unless 124 otherwise specified, the mechanisms defined in [RFC8762] and 125 [I-D.ietf-ippm-stamp-option-tlv] are not modified by this document. 127 2. Conventions Used in This Document 129 2.1. Requirements Language 131 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 133 document are to be interpreted as described in [RFC2119] [RFC8174] 134 when, and only when, they appear in all capitals, as shown here. 136 2.2. Abbreviations 138 BSID: Binding Segment ID. 140 DM: Delay Measurement. 142 ECMP: Equal Cost Multi-Path. 144 HMAC: Hashed Message Authentication Code. 146 LM: Loss Measurement. 148 MPLS: Multiprotocol Label Switching. 150 NTP: Network Time Protocol. 152 OWAMP: One-Way Active Measurement Protocol. 154 PM: Performance Measurement. 156 PSID: Path Segment Identifier. 158 PTP: Precision Time Protocol. 160 SID: Segment ID. 162 SL: Segment List. 164 SR: Segment Routing. 166 SRH: Segment Routing Header. 168 SR-MPLS: Segment Routing with MPLS data plane. 170 SRv6: Segment Routing with IPv6 data plane. 172 SSID: STAMP Session Identifier. 174 STAMP: Simple Two-way Active Measurement Protocol. 176 TC: Traffic Class. 178 2.3. Reference Topology 180 In the reference topology shown below, the sender node R1 initiates a 181 performance measurement probe query message and the reflector node R5 182 sends a probe response message for the query message received. The 183 probe response message is typically sent to the sender node R1. 185 SR is enabled on nodes R1 and R5. The nodes R1 and R5 may be 186 directly connected via a Link or there exists a Point-to-Point (P2P) 187 SR Path e.g. SR Policy [I-D.ietf-spring-segment-routing-policy] on 188 node R1 (called head-end) with destination to node R5 (called tail- 189 end). 191 t1 t2 192 / \ 193 +-------+ Query +-------+ 194 | | - - - - - - - - - ->| | 195 | R1 |=====================| R5 | 196 | |<- - - - - - - - - - | | 197 +-------+ Response +-------+ 198 \ / 199 t4 t3 200 Sender Reflector 202 Reference Topology 204 3. Overview 206 For one-way and two-way delay measurements in Segment Routing 207 networks, the probe messages defined in [RFC8762] are used. For 208 direct-mode and inferred-mode loss measurements, the probe messages 209 defined in [I-D.gandhi-ippm-stamp-srpm] are used. For both Links and 210 end-to-end SR Paths including SR Policies and Flex-Algo IGP Paths, no 211 PM state for delay or loss measurement need to be created on the 212 reflector node R5. 214 Separate UDP destination port numbers are user-configured for delay 215 and loss measurements from the range specified in [RFC8762]. As 216 specified in [RFC8762], the reflector supports the destination UDP 217 port 862 for delay measurement probe messages by default. This UDP 218 port however, is not used for loss measurement probe messages. The 219 sender uses the UDP port number following the guidelines specified in 220 Section 6 in [RFC6335]. The same destination UDP port is used for 221 Links and SR Paths and the reflector is unaware if the query is for 222 the Links or SR Paths. The number of UDP ports with PM functionality 223 needs to be minimized due to limited hardware resources. 225 For Performance Measurement, probe query and response messages are 226 sent as following: 228 o For delay measurement, the probe messages are sent on the 229 congruent path of the data traffic by the sender node, and are 230 used to measure the delay experienced by the actual data traffic 231 flowing on the Links and SR Paths. 233 o For loss measurement, the probe messages are sent on the congruent 234 path of the data traffic by the sender node, and are used to 235 collect the receive traffic counters for the incoming link or 236 incoming SID where the probe query messages are received at the 237 reflector node (incoming link or incoming SID needed since the 238 reflector node does not have PM state present). 240 The In-Situ Operations, Administration, and Maintenance (IOAM) 241 mechanisms for SR-MPLS defined in [I-D.gandhi-mpls-ioam-sr] and for 242 SRv6 defined in [I-D.ali-spring-ioam-srv6] are used to carry PM 243 information such as timestamp in-band as part of the data packets, 244 and are outside the scope of this document. 246 3.1. Example Provisioning Model 248 An example of a provisioning model and typical measurement parameters 249 for each user-configured destination UDP port for performance delay 250 and loss measurements is shown in the following Figure 1: 252 +------------+ 253 | Controller | 254 +------------+ 255 Destination UDP Port / \ Destination UDP port 256 Measurement Protocol / \ Measurement Protocol 257 Measurement Type / \ Measurement Type 258 Delay/Loss / \ Delay/Loss 259 Authentication Mode & Key / \ Authentication Mode & Key 260 Timestamp Format / \ Loss Measurement Mode 261 Delay Measurement Mode / \ SSID (Wildcard) 262 Loss Measurement Mode / \ 263 v v 264 +-------+ +-------+ 265 | | | | 266 | R1 |============| R5 | 267 | | SR Path | | 268 +-------+ Or Link +-------+ 269 Sender Reflector 271 Figure 1: Example Provisioning Model 273 Example of Measurement Protocol is STAMP, example of the Timestamp 274 Format is PTPv2 [IEEE1588] or NTP and example of the Loss Measurement 275 mode is inferred-mode or direct-mode. 277 The mechanisms to provision the sender and reflector nodes are 278 outside the scope of this document. The provisioning model is not 279 used for signaling the PM parameters between the reflector and sender 280 nodes in SR networks. 282 The reflector node R5 uses the parameters for the timestamp format 283 and delay measurement mode (i.e. one-way or two-way mode) from the 284 received probe query message. 286 4. Probe Messages 288 4.1. Probe Query Message 290 The probe messages defined in [RFC8762] are used for delay 291 measurement for Links and end-to-end SR Paths including SR Policies. 292 For loss measurement, the probe messages defined in [I-D.gandhi-ippm- 293 stamp-srpm] are used. 295 4.1.1. Delay Measurement Query Message 297 The message content for delay measurement probe query message using 298 UDP header [RFC0768] is shown in Figure 2. The DM probe query 299 message is sent with user-configured Destination UDP port number for 300 DM. The Destination UDP port cannot be used as Source port, since 301 the message does not have any indication to distinguish between the 302 query and response message. The payload of the DM probe query 303 message contains the delay measurement message defined in [RFC8762]. 305 +---------------------------------------------------------------+ 306 | IP Header | 307 . Source IP Address = Sender IPv4 or IPv6 Address . 308 . Destination IP Address = Reflector IPv4 or IPv6 Address . 309 . Protocol = UDP . 310 . . 311 +---------------------------------------------------------------+ 312 | UDP Header | 313 . Source Port = As chosen by Sender . 314 . Destination Port = User-configured Port for Delay Measurement. 315 . . 316 +---------------------------------------------------------------+ 317 | Payload = DM Message as specified in Section 4.2 of RFC 8762 | 318 . . 319 +---------------------------------------------------------------+ 321 Figure 2: DM Probe Query Message 323 Timestamp field is eight bytes and use the format defined in 324 Section 4.2.1 of [RFC8762]. It is recommended to use the IEEE 1588v2 325 Precision Time Protocol (PTP) truncated 64-bit timestamp format 326 [IEEE1588] as specified in [RFC8186], with hardware support in 327 Segment Routing networks. 329 4.1.1.1. Delay Measurement Authentication Mode 331 When using the authenticated mode for delay measurement, the matching 332 authentication type (e.g. HMAC-SHA-256) and key are user-configured 333 on both the sender and reflector nodes. A separate user-configured 334 destination UDP port is used for the delay measurement in 335 authentication mode due to the different probe message format. 337 4.1.2. Loss Measurement Query Message 339 The message content for loss measurement probe query message using 340 UDP header [RFC0768] is shown in Figure 3. The LM probe query 341 message is sent with user-configured Destination UDP port number for 342 LM, which is a different Destination UDP port number than DM. 343 Separate Destination UDP ports are used for direct-mode and inferred- 344 mode loss measurements. The Destination UDP port cannot be used as 345 Source port, since the message does not have any indication to 346 distinguish between the query and response message. The LM probe 347 query message contains the payload for loss measurement as defined in 348 [I-D.gandhi-ippm-stamp-srpm]. 350 +---------------------------------------------------------------+ 351 | IP Header | 352 . Source IP Address = Sender IPv4 or IPv6 Address . 353 . Destination IP Address = Reflector IPv4 or IPv6 Address . 354 . Protocol = UDP . 355 . . 356 +---------------------------------------------------------------+ 357 | UDP Header | 358 . Source Port = As chosen by Sender . 359 . Destination Port = User-configured Port for Loss Measurement . 360 . . 361 +---------------------------------------------------------------+ 362 | Payload = LM Message specified in [I-D.gandhi-ippm-stamp-srpm]| 363 . . 364 +---------------------------------------------------------------+ 366 Figure 3: LM Probe Query Message 368 4.1.2.1. Loss Measurement Authentication Mode 370 When using the authenticated mode for loss measurement, the matching 371 authentication type (e.g. HMAC-SHA-256) and key are user-configured 372 on both the sender and reflector nodes. A separate user-configured 373 destination UDP port is used for the loss measurement in 374 authentication mode due to the different message format. 376 4.1.3. Probe Query for Links 378 The probe query message as defined in Figure 2 for delay measurement 379 and Figure 3 for loss measurement are used for Links which may be 380 physical, virtual or LAG (bundle), LAG (bundle) member, numbered/ 381 unnumbered Links. The probe messages are pre-routed over the Link 382 for both delay and loss measurement. The local and remote IP 383 addresses of the link are used as Source and Destination Addresses. 384 They can also be IPv6 link local address as probe messages are pre- 385 routed. 387 4.1.4. Probe Query for SR Policy 389 The performance delay and loss measurement for segment routing is 390 applicable to both end-to-end SR-MPLS and SRv6 Policies. 392 The sender IPv4 or IPv6 address is used as the source address. The 393 endpoint IPv4 or IPv6 address is used as the destination address. In 394 the case of SR Policy with IPv4 endpoint of 0.0.0.0 or IPv6 endpoint 395 of ::0 [I-D.ietf-spring-segment-routing-policy], the loopback address 396 from range 127/8 for IPv4, or the loopback address ::1/128 for IPv6 397 is used as the destination address, respectively. In this case, Node 398 Address TLV [I-D.gandhi-ippm-stamp-srpm] can be sent in the probe 399 query message to identify the intended destination node. The 400 reflector node MUST NOT send response message if it is not the 401 intended destination node in the Node Address TLV [I-D.gandhi-ippm- 402 stamp-srpm]. 404 4.1.4.1. Probe Query Message for SR-MPLS Policy 406 The probe query messages for performance measurement of an end-to-end 407 SR-MPLS Policy is sent using its SR-MPLS header containing the MPLS 408 segment list as shown in Figure 4. 410 0 1 2 3 411 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 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 | Segment(1) | TC |S| TTL | 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 . . 416 . . 417 . . 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 | Segment(n) | TC |S| TTL | 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 | PSID | TC |S| TTL | 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 | Message as shown in Figure 2 for DM or Figure 3 for LM | 424 . . 425 +---------------------------------------------------------------+ 427 Figure 4: Example Probe Query Message for SR-MPLS Policy 429 The Segment List (SL) can be empty to indicate Implicit NULL label 430 case for a single-hop SR Policy. 432 The Path Segment Identifier (PSID) 433 [I-D.ietf-spring-mpls-path-segment] of the SR-MPLS Policy is used for 434 accounting received traffic on the egress node for loss measurement. 436 4.1.4.2. Probe Query Message for SRv6 Policy 438 An SRv6 Policy setup using the SRv6 Segment Routing Header (SRH) and 439 a Segment List as defined in [RFC8754]. The SRv6 network programming 440 is defined in [I-D.ietf-spring-srv6-network-programming]. The probe 441 query messages for performance measurement of an end-to-end SRv6 442 Policy is sent using its SRH with Segment List as shown in Figure 5. 443 The procedure defined for upper-layer header processing for SRv6 SIDs 444 in [I-D.ietf-spring-srv6-network-programming] is used to process the 445 UDP header in the received probe query messages. 447 +---------------------------------------------------------------+ 448 | IP Header | 449 . Source IP Address = Sender IPv6 Address . 450 . Destination IP Address = Destination IPv6 Address . 451 . . 452 +---------------------------------------------------------------+ 453 | SRH as specified in RFC 8754 | 454 . . 455 . . 456 +---------------------------------------------------------------+ 457 | IP Header (as needed) | 458 . Source IP Address = Sender IPv6 Address . 459 . Destination IP Address = Reflector IPv6 Address . 460 . . 461 +---------------------------------------------------------------+ 462 | UDP Header | 463 . Source Port = As chosen by Sender . 464 . Destination Port = User-configured Port . 465 . . 466 +---------------------------------------------------------------+ 467 | Payload = DM Message as specified in Section 4.2 of RFC 8762 | 468 . Payload = LM Message specified in [I-D.gandhi-ippm-stamp-srpm]. 469 . . 470 +---------------------------------------------------------------+ 472 Figure 5: Example Probe Query Message for SRv6 Policy 474 4.2. Probe Response Message 476 The probe response message is sent using the IP/UDP information from 477 the received probe query message. The content of the probe response 478 message is shown in Figure 6. 480 +---------------------------------------------------------------+ 481 | IP Header | 482 . Source IP Address = Reflector IPv4 or IPv6 Address . 483 . Destination IP Address = Source IP Address from Query . 484 . Protocol = UDP . 485 . . 486 +---------------------------------------------------------------+ 487 | UDP Header | 488 . Source Port = As chosen by Reflector . 489 . Destination Port = Source Port from Query . 490 . . 491 +---------------------------------------------------------------+ 492 | Payload = DM Message as specified in Section 4.3 of RFC 8762 | 493 . Payload = LM Message specified in [I-D.gandhi-ippm-stamp-srpm]. 494 . . 495 +---------------------------------------------------------------+ 497 Figure 6: Probe Response Message 499 4.2.1. One-way Measurement Mode 501 In one-way measurement mode, the probe response message as defined in 502 Figure 6 is sent back out-of-band to the sender node, for both Links 503 and SR Policies. The Sender Control Code is set to "Out-of-band 504 Response Requested". In this delay measurement mode, as per 505 Reference Topology, all timestamps t1, t2, t3, and t4 are collected 506 by the probes. However, only timestamps t1 and t2 are used to 507 measure one-way delay as (t2 - t1). 509 For one-way performance measurement, the sender node address may not 510 be reachable via IP route from the reflector node. The sender node 511 in this case needs to send its reachability path information to the 512 reflector node using Return Path TLV defined in [I-D.gandhi-ippm- 513 stamp-srpm]. 515 4.2.2. Two-way Measurement Mode 517 In two-way measurement mode, when using a bidirectional path, the 518 probe response message as defined in Figure 6 is sent back to the 519 sender node on the congruent path of the data traffic on the same 520 reverse direction Link or associated reverse SR Policy 521 [I-D.ietf-pce-sr-bidir-path]. The Sender Control Code is set to "In- 522 band Response Requested". In this delay measurement mode, as per 523 Reference Topology, all timestamps t1, t2, t3, and t4 are collected 524 by the probes. All four timestamps are used to measure two-way delay 525 as ((t4 - t1) - (t3 - t2)). 527 For two-way measurement mode for Links, the probe response message is 528 sent back on the incoming physical interface where the probe query 529 message is received. 531 For two-way measurement mode for SR Policy, the reflector node needs 532 to send the probe response message on a specific reverse path. The 533 sender node can request in the probe query message to the reflector 534 node to send a response message back on a given reverse path (e.g. 535 co-routed bidirectional path) using Return Path TLV defined in [I- 536 D.gandhi-ippm-stamp-srpm]. This way the reflector node does not 537 require any additional SR state for PM (recall that in SR networks, 538 the state is in the probe packet and signaling of the parameters is 539 undesired). 541 4.2.2.1. Probe Response Message for SR-MPLS Policy 543 The message content for sending probe response message for two-way 544 performance measurement of an end-to-end SR-MPLS Policy is shown in 545 Figure 7. 547 0 1 2 3 548 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 549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 550 | Segment(1) | TC |S| TTL | 551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 552 . . 553 . . 554 . . 555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 556 | Segment(n) | TC |S| TTL | 557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 558 | Message as shown in Figure 6 | 559 . . 560 +---------------------------------------------------------------+ 562 Figure 7: Example Probe Response Message for SR-MPLS Policy 564 The Path Segment Identifier (PSID) 565 [I-D.ietf-spring-mpls-path-segment] of the forward SR Policy in the 566 probe query can be used to find the associated reverse SR Policy 567 [I-D.ietf-pce-sr-bidir-path] to send the probe response message for 568 two-way measurement of SR Policy unless when using STAMP message with 569 Return Path TLV. 571 4.2.2.2. Probe Response Message for SRv6 Policy 573 The message content for sending probe response message on the 574 congruent path of the data traffic for two-way performance 575 measurement of an end-to-end SRv6 Policy with SRH is shown in 576 Figure 8. The procedure defined for upper-layer header processing 577 for SRv6 SIDs in [I-D.ietf-spring-srv6-network-programming] is used 578 to process the UDP header in the received probe response messages. 580 +---------------------------------------------------------------+ 581 | IP Header | 582 . Source IP Address = Reflector IPv6 Address . 583 . Destination IP Address = Destination IPv6 Address . 584 . . 585 +---------------------------------------------------------------+ 586 | SRH as specified in RFC 8754 | 587 . . 588 . . 589 +---------------------------------------------------------------+ 590 | IP Header (as needed) | 591 . Source IP Address = Reflector IPv6 Address . 592 . Destination IP Address = Source IPv6 Address from Query . 593 . . 594 +---------------------------------------------------------------+ 595 | UDP Header | 596 . Source Port = As chosen by Sender . 597 . Destination Port = User-configured Port . 598 . . 599 +---------------------------------------------------------------+ 600 | Payload = DM Message as specified in Section 4.3 of RFC 8762 | 601 . Payload = LM Message specified in [I-D.gandhi-ippm-stamp-srpm]. 602 . . 603 +---------------------------------------------------------------+ 605 Figure 8: Example Probe Response Message for SRv6 Policy 607 4.2.3. Loopback Measurement Mode 609 The Loopback measurement mode can be used to measure round-trip delay 610 for a bidirectional SR Path. The IP header of the probe query 611 message contains the destination address equals to the sender address 612 and the source address equals to the reflector address. Optionally, 613 the probe query message can carry the reverse path information (e.g. 614 reverse path label stack for SR-MPLS) as part of the SR header. The 615 probe messages are not punted at the reflector node and it does not 616 process them and generate response messages. The Sender Control Code 617 is set to the default value of 0. In this mode, as the probe packet 618 is not punted on the reflector node for processing, the querier 619 copies the 'Sequence Number' in 'Session-Sender Sequence Number' 620 directly. In this delay measurement mode, as per Reference Topology, 621 the timestamps t1 and t4 are collected by the probes. Both these 622 timestamps are used to measure round-trip delay as (t4 - t1). 624 4.3. Additional Probe Message Processing Rules 626 The processing rules defined in this section are applicable to the 627 STAMP messages for delay and loss measurement for Links and end-to- 628 end SR Paths including SR Policies. 630 4.3.1. TTL and Hop Limit 632 The TTL field in the IPv4 and MPLS headers of the probe query 633 messages is set to 255 [RFC8762]. Similarly, the Hop Limit field in 634 the IPv6 and SRH headers of the probe query messages is set to 255 635 [RFC8762]. 637 When using the Destination IPv4 Address from range 127/8, the TTL 638 field in the IPv4 header is set to 1 [RFC8029]. Similarly, when 639 using the Destination IPv6 Address from the ::FFFF:127/104 range, the 640 Hop Limit field in the IPv6 header is set to 1. 642 For Link performance delay and loss measurements, the TTL or Hop 643 Limit field in the probe message is set to 1 in both one-way and two- 644 way measurement modes. 646 4.3.2. Router Alert Option 648 The Router Alert IP option (RAO) [RFC2113] is not set in the probe 649 messages. 651 4.3.3. UDP Checksum 653 The UDP Checksum Complement for delay and loss measurement messages 654 follows the procedure defined in [RFC7820] and can be optionally used 655 with the procedures defined in this document. 657 For IPv4 and IPv6 probe messages, where the hardware is not capable 658 of re-computing the UDP checksum or adding checksum complement 659 [RFC7820], the sender node sets the UDP checksum to 0 [RFC6936] 660 [RFC8085]. The receiving node bypasses the checksum validation and 661 accepts the packets with UDP checksum value 0 for the UDP port being 662 used for delay and loss measurements. 664 5. Performance Measurement for P2MP SR Policies 666 The Point-to-Multipoint (P2MP) SR Path that originates from a root 667 node terminates on multiple destinations called leaf nodes (e.g. 668 P2MP SR Policy [I-D.ietf-pim-sr-p2mp-policy] or P2MP Transport 669 [I-D.shen-spring-p2mp-transport-chain]). 671 The procedures for delay and loss measurement described in this 672 document for P2P SR Policies are also equally applicable to the P2MP 673 SR Policies. The procedure for one-way measurement is defined as 674 following: 676 o The sender root node sends probe query messages using the Tree-SID 677 defined in [I-D.ietf-pim-sr-p2mp-policy] for the P2MP SR-MPLS 678 Policy as shown in Figure 9. 680 o The probe query messages can contain the replication SID as 681 defined in [I-D.ietf-spring-sr-replication-segment]. 683 o The Destination Address is set to the loopback address from range 684 127/8 for IPv4, or the loopback address ::1/128 for IPv6 address. 686 o Each reflector leaf node sends its IP address in the Source 687 Address of the probe response messages as shown in Figure 9. This 688 allows the sender root node to identify the reflector leaf nodes 689 of the P2MP SR Policy. 691 o The P2MP root node measures the delay and loss performance for 692 each P2MP leaf node of the end-to-end P2MP SR Policy. 694 0 1 2 3 695 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 696 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 697 | Tree-SID | TC |S| TTL | 698 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 699 . . 700 . . 701 . . 702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 703 | Message as shown in Figure 2 for DM or Figure 3 for LM | 704 . . 705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 707 Figure 9: Example Probe Query with Tree-SID for SR-MPLS Policy 709 The probe query messages can also be sent using the scheme defined 710 for P2MP Transport using Chain Replication that may contain Bud SID 711 as defined in [I-D.shen-spring-p2mp-transport-chain]. 713 The considerations for two-way mode for performance measurement for 714 P2MP SR Policy (e.g. for bidirectional SR Path) are outside the scope 715 of this document. 717 6. ECMP Support for SR Policies 719 An SR Policy can have ECMPs between the source and transit nodes, 720 between transit nodes and between transit and destination nodes. 721 Usage of Anycast SID [RFC8402] by an SR Policy can result in ECMP 722 paths via transit nodes part of that Anycast group. The probe 723 messages need to be sent to traverse different ECMP paths to measure 724 performance delay of an SR Policy. 726 Forwarding plane has various hashing functions available to forward 727 packets on specific ECMP paths. The mechanisms described in 728 [RFC8029] and [RFC5884] for handling ECMPs are also applicable to the 729 performance measurement. In IPv4 header of the probe messages, 730 sweeping of Destination Address from range 127/8 can be used to 731 exercise particular ECMP paths. As specified in [RFC6437], Flow 732 Label field in the outer IPv6 header can also be used for sweeping. 734 The considerations for performance loss measurement for different 735 ECMP paths of an SR Policy are outside the scope of this document. 737 7. Performance Delay and Liveness Monitoring 739 Liveness monitoring is required for connectivity verification and 740 continuity check in an SR network. The procedure defined in this 741 document for delay measurement using the STAMP probe messages can 742 also be applied to liveness monitoring of Links and SR Paths. The 743 one-way or two-way measurement mode can be used for liveness 744 monitoring. Liveness failure is notified when consecutive N number 745 of probe response messages are not received back at the sender node, 746 where N is locally provisioned value. Note that for one-way and two- 747 way modes, the failure detection interval and scale for number of 748 probe messages need to account for the processing of the probe query 749 messages which need to be punted from the forwarding fast path (to 750 slow path or control plane) and response messages need to be injected 751 on the reflector node. This is improved by using the probes in 752 loopback mode. 754 8. Security Considerations 756 The performance measurement is intended for deployment in well- 757 managed private and service provider networks. As such, it assumes 758 that a node involved in a measurement operation has previously 759 verified the integrity of the path and the identity of the far-end 760 reflector node. 762 If desired, attacks can be mitigated by performing basic validation 763 and sanity checks, at the sender, of the counter or timestamp fields 764 in received measurement response messages. The minimal state 765 associated with these protocols also limits the extent of measurement 766 disruption that can be caused by a corrupt or invalid message to a 767 single query/response cycle. 769 Use of HMAC-SHA-256 in the authenticated mode protects the data 770 integrity of the probe messages. SRv6 has HMAC protection 771 authentication defined for SRH [RFC8754]. Hence, probe messages for 772 SRv6 may not need authentication mode. Cryptographic measures may be 773 enhanced by the correct configuration of access-control lists and 774 firewalls. 776 9. IANA Considerations 778 This document does not require any IANA action. 780 10. References 782 10.1. Normative References 784 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 785 DOI 10.17487/RFC0768, August 1980, 786 . 788 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 789 Requirement Levels", BCP 14, RFC 2119, 790 DOI 10.17487/RFC2119, March 1997, 791 . 793 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 794 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 795 May 2017, . 797 [RFC8762] Mirsky, G., Jun, G., Nydell, H., and R. Foote, "Simple 798 Two-Way Active Measurement Protocol", RFC 8762, 799 DOI 10.17487/RFC8762, March 2020, 800 . 802 [I-D.gandhi-ippm-stamp-srpm] 803 Gandhi, R., Filsfils, C., Voyer, D., Chen, M., and B. 804 Janssens, "Simple TWAMP (STAMP) Extensions for Segment 805 Routing", draft-gandhi-ippm-stamp-srpm-00 (work 806 in progress), October 2020. 808 [I-D.ietf-ippm-stamp-option-tlv] 809 Mirsky, G., Min, X., Nydell, H., Foote, R., Masputra, A., 810 and E. Ruffini, "Simple Two-way Active Measurement 811 Protocol Optional Extensions", draft-ietf-ippm-stamp- 812 option-tlv-09 (work in progress), August 2020. 814 10.2. Informative References 816 [IEEE1588] 817 IEEE, "1588-2008 IEEE Standard for a Precision Clock 818 Synchronization Protocol for Networked Measurement and 819 Control Systems", March 2008. 821 [RFC2113] Katz, D., "IP Router Alert Option", RFC 2113, 822 DOI 10.17487/RFC2113, February 1997, 823 . 825 [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, 826 "Bidirectional Forwarding Detection (BFD) for MPLS Label 827 Switched Paths (LSPs)", RFC 5884, DOI 10.17487/RFC5884, 828 June 2010, . 830 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 831 Cheshire, "Internet Assigned Numbers Authority (IANA) 832 Procedures for the Management of the Service Name and 833 Transport Protocol Port Number Registry", BCP 165, 834 RFC 6335, DOI 10.17487/RFC6335, August 2011, 835 . 837 [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, 838 "IPv6 Flow Label Specification", RFC 6437, 839 DOI 10.17487/RFC6437, November 2011, 840 . 842 [RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement 843 for the Use of IPv6 UDP Datagrams with Zero Checksums", 844 RFC 6936, DOI 10.17487/RFC6936, April 2013, 845 . 847 [RFC7820] Mizrahi, T., "UDP Checksum Complement in the One-Way 848 Active Measurement Protocol (OWAMP) and Two-Way Active 849 Measurement Protocol (TWAMP)", RFC 7820, 850 DOI 10.17487/RFC7820, March 2016, 851 . 853 [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., 854 Aldrin, S., and M. Chen, "Detecting Multiprotocol Label 855 Switched (MPLS) Data-Plane Failures", RFC 8029, 856 DOI 10.17487/RFC8029, March 2017, 857 . 859 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 860 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 861 March 2017, . 863 [RFC8186] Mirsky, G. and I. Meilik, "Support of the IEEE 1588 864 Timestamp Format in a Two-Way Active Measurement Protocol 865 (TWAMP)", RFC 8186, DOI 10.17487/RFC8186, June 2017, 866 . 868 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 869 Decraene, B., Litkowski, S., and R. Shakir, "Segment 870 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 871 July 2018, . 873 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 874 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 875 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 876 . 878 [I-D.ietf-spring-segment-routing-policy] 879 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 880 P. Mattes, "Segment Routing Policy Architecture", draft- 881 ietf-spring-segment-routing-policy-08 (work in progress), 882 July 2020. 884 [I-D.ietf-spring-sr-replication-segment] 885 Voyer, D., Filsfils, C., Parekh, R., Bidgoli, H., and Z. 886 Zhang, "SR Replication Segment for Multi-point Service 887 Delivery", draft-ietf-spring-sr-replication-segment-00 888 (work in progress), July 2020. 890 [I-D.shen-spring-p2mp-transport-chain] 891 Shen, Y., Zhang, Z., Parekh, R., Bidgoli, H., and Y. 892 Kamite, "Point-to-Multipoint Transport Using Chain 893 Replication in Segment Routing", draft-shen-spring-p2mp- 894 transport-chain-02 (work in progress), April 2020. 896 [I-D.ietf-pim-sr-p2mp-policy] 897 Voyer, D., Filsfils, C., Parekh, R., Bidgoli, H., and Z. 898 Zhang, "Segment Routing Point-to-Multipoint Policy", 899 draft-ietf-pim-sr-p2mp-policy-00 (work in progress), July 900 2020. 902 [I-D.ietf-spring-mpls-path-segment] 903 Cheng, W., Li, H., Chen, M., Gandhi, R., and R. Zigler, 904 "Path Segment in MPLS Based Segment Routing Network", 905 draft-ietf-spring-mpls-path-segment-03 (work in progress), 906 September 2020. 908 [I-D.ietf-spring-srv6-network-programming] 909 Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., 910 Matsushima, S., and Z. Li, "SRv6 Network Programming", 911 draft-ietf-spring-srv6-network-programming-24 (work in 912 progress), October 2020. 914 [I-D.gandhi-mpls-ioam-sr] 915 Gandhi, R., Ali, Z., Filsfils, C., Brockners, F., Wen, B., 916 and V. Kozak, "MPLS Data Plane Encapsulation for In-situ 917 OAM Data", draft-gandhi-mpls-ioam-sr-03 (work in 918 progress), September 2020. 920 [I-D.ali-spring-ioam-srv6] 921 Ali, Z., Gandhi, R., Filsfils, C., Brockners, F., Kumar, 922 N., Pignataro, C., Li, C., Chen, M., and G. Dawra, 923 "Segment Routing Header encapsulation for In-situ OAM 924 Data", draft-ali-spring-ioam-srv6-02 (work in progress), 925 November 2019. 927 [I-D.ietf-pce-sr-bidir-path] 928 Li, C., Chen, M., Cheng, W., Gandhi, R., and Q. Xiong, 929 "PCEP Extensions for Associated Bidirectional Segment 930 Routing (SR) Paths", draft-ietf-pce-sr-bidir-path-03 (work 931 in progress), September 2020. 933 Acknowledgments 935 The authors would like to thank Thierry Couture for the discussions 936 on the use-cases for Performance Measurement in Segment Routing. The 937 authors would also like to thank Greg Mirsky for reviewing this 938 document and providing useful comments and suggestions. Patrick 939 Khordoc and Radu Valceanu, both from Cisco Systems have helped 940 significantly improve the mechanisms defined in this document. The 941 authors would also like to thank Sam Aldrin for the discussions to 942 check for broken path. 944 Authors' Addresses 945 Rakesh Gandhi (editor) 946 Cisco Systems, Inc. 947 Canada 949 Email: rgandhi@cisco.com 951 Clarence Filsfils 952 Cisco Systems, Inc. 954 Email: cfilsfil@cisco.com 956 Daniel Voyer 957 Bell Canada 959 Email: daniel.voyer@bell.ca 961 Mach(Guoyi) Chen 962 Huawei 964 Email: mach.chen@huawei.com 966 Bart Janssens 967 Colt 969 Email: Bart.Janssens@colt.net