idnits 2.17.1 draft-gandhi-spring-stamp-srpm-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 10, 2021) is 1171 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'IEEE802.1AX' is mentioned on line 189, but not defined == Outdated reference: A later version (-03) exists of draft-gandhi-ippm-stamp-srpm-02 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-09 == Outdated reference: A later version (-19) exists of draft-ietf-spring-sr-replication-segment-02 == Outdated reference: A later version (-08) exists of draft-ietf-pim-sr-p2mp-policy-01 == Outdated reference: A later version (-22) exists of draft-ietf-spring-mpls-path-segment-03 == Outdated reference: A later version (-07) exists of draft-ietf-spring-srv6-path-segment-00 == Outdated reference: A later version (-13) exists of draft-ietf-pce-sr-bidir-path-05 == Outdated reference: A later version (-12) exists of draft-ietf-ippm-stamp-yang-06 Summary: 0 errors (**), 0 flaws (~~), 10 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: Informational Cisco Systems, Inc. 5 Expires: August 14, 2021 D. Voyer 6 Bell Canada 7 M. Chen 8 Huawei 9 B. Janssens 10 Colt 11 February 10, 2021 13 Performance Measurement Using Simple TWAMP (STAMP) for Segment Routing 14 Networks 15 draft-gandhi-spring-stamp-srpm-05 17 Abstract 19 Segment Routing (SR) leverages the source routing paradigm. SR is 20 applicable to both Multiprotocol Label Switching (SR-MPLS) and IPv6 21 (SRv6) data planes. This document describes procedures for 22 Performance Measurement in SR networks using the mechanisms defined 23 in RFC 8762 (Simple Two-Way Active Measurement Protocol (STAMP)) and 24 its optional extensions defined in RFC 8972 and draft-gandhi-ippm- 25 stamp-srpm. The procedure described is applicable to SR-MPLS and 26 SRv6 data planes and is used for both links and end-to-end SR paths 27 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 August 14, 2021. 46 Copyright Notice 48 Copyright (c) 2021 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 . . . . . . . . . . . . . . 3 65 2.1. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3 66 2.2. Reference Topology . . . . . . . . . . . . . . . . . . . 4 67 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 3.1. Example STAMP Reference Model . . . . . . . . . . . . . . 5 69 4. Delay Measurement for Links and SR Paths . . . . . . . . . . 7 70 4.1. Session-Sender Test Packet . . . . . . . . . . . . . . . 7 71 4.1.1. Session-Sender Test Packet for Links . . . . . . . . 7 72 4.1.2. Session-Sender Test Packet for SR Paths . . . . . . . 7 73 4.2. Session-Reflector Test Packet . . . . . . . . . . . . . . 9 74 4.2.1. One-way Delay Measurement Mode . . . . . . . . . . . 10 75 4.2.2. Two-way Delay Measurement Mode . . . . . . . . . . . 10 76 4.2.3. Round-trip Delay Measurement Mode . . . . . . . . . . 12 77 4.3. Delay Measurement for P2MP SR Policies . . . . . . . . . 13 78 4.4. Additional STAMP Test Packet Processing Rules . . . . . . 14 79 4.4.1. TTL . . . . . . . . . . . . . . . . . . . . . . . . . 14 80 4.4.2. IPv6 Hop Limit . . . . . . . . . . . . . . . . . . . 14 81 4.4.3. Router Alert Option . . . . . . . . . . . . . . . . . 15 82 5. Packet Loss Measurement for Links and SR Paths . . . . . . . 15 83 6. Direct Measurement for Links and SR Paths . . . . . . . . . . 15 84 7. Session Status for Links and SR Paths . . . . . . . . . . . . 15 85 8. ECMP Support for SR Policies . . . . . . . . . . . . . . . . 15 86 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 87 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 88 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 89 11.1. Normative References . . . . . . . . . . . . . . . . . . 17 90 11.2. Informative References . . . . . . . . . . . . . . . . . 17 91 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 19 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 94 1. Introduction 96 Segment Routing (SR) leverages the source routing paradigm and 97 greatly simplifies network operations for Software Defined Networks 98 (SDNs). SR is applicable to both Multiprotocol Label Switching (SR- 99 MPLS) and IPv6 (SRv6) data planes [RFC8402]. SR takes advantage of 100 the Equal-Cost Multipaths (ECMPs) between source and transit nodes, 101 between transit nodes and between transit and destination nodes. SR 102 Policies as defined in [I-D.ietf-spring-segment-routing-policy] are 103 used to steer traffic through a specific, user-defined paths using a 104 stack of Segments. Built-in SR Performance Measurement (PM) is one 105 of the essential requirements to provide Service Level Agreements 106 (SLAs). 108 The Simple Two-way Active Measurement Protocol (STAMP) provides 109 capabilities for the measurement of various performance metrics in IP 110 networks [RFC8762]. It eliminates the need for control protocol by 111 using configuration and management model to provision and manage test 112 sessions. [RFC8972] defines optional extensions for STAMP. 113 [I-D.gandhi-ippm-stamp-srpm] defines STAMP extensions for SR 114 networks. 116 The STAMP supports two modes of STAMP Session-Reflector: Stateless 117 and Stateful as described in Section 4 of [RFC8762]. In Stateless 118 mode, maintenance of each STAMP test session on Session-Reflector is 119 avoided. In SR networks, as the state is in the packet, the 120 signaling of the parameters and creating extra states in the network 121 are undesired. Hence, Stateless mode of Session-Reflector is 122 preferred in SR networks. 124 This document describes procedures for Performance Measurement in SR 125 networks using the mechanisms defined in STAMP [RFC8762] and its 126 optional extensions defined in [RFC8972] and 127 [I-D.gandhi-ippm-stamp-srpm]. The procedure described is applicable 128 to SR-MPLS and SRv6 data planes and is used for both links and end- 129 to-end SR paths including SR Policies [RFC8402]. 131 2. Conventions Used in This Document 133 2.1. Abbreviations 135 BSID: Binding Segment ID. 137 DM: Delay Measurement. 139 ECMP: Equal Cost Multi-Path. 141 HMAC: Hashed Message Authentication Code. 143 LM: Loss Measurement. 145 MPLS: Multiprotocol Label Switching. 147 NTP: Network Time Protocol. 149 OWAMP: One-Way Active Measurement Protocol. 151 PM: Performance Measurement. 153 PSID: Path Segment Identifier. 155 PTP: Precision Time Protocol. 157 SHA: Secure Hash Algorithm. 159 SID: Segment ID. 161 SL: Segment List. 163 SR: Segment Routing. 165 SRH: Segment Routing Header. 167 SR-MPLS: Segment Routing with MPLS data plane. 169 SRv6: Segment Routing with IPv6 data plane. 171 SSID: STAMP Session Identifier. 173 STAMP: Simple Two-way Active Measurement Protocol. 175 TC: Traffic Class. 177 TTL: Time To Live. 179 2.2. Reference Topology 181 In the reference topology shown below, the STAMP Session-Sender R1 182 initiates a STAMP test packet and the STAMP Session-Reflector R3 183 transmits a reply test packet. The reply test packet is transmitted 184 back to the STAMP Session-Sender R1 on the same path or a different 185 path in the reverse direction. 187 The nodes R1 and R3 may be connected via a link or there exists an SR 188 path [RFC8402]. The link may be a physical interface, virtual link, 189 or Link Aggregation Group (LAG) [IEEE802.1AX], or LAG member link. 190 The SR path may be an SR Policy 192 [I-D.ietf-spring-segment-routing-policy] on node R1 (called head-end) 193 with destination to node R3 (called tail-end). 195 T1 T2 196 / \ 197 +-------+ Test Packet +-------+ 198 | | - - - - - - - - - ->| | 199 | R1 |=====================| R3 | 200 | |<- - - - - - - - - - | | 201 +-------+ Reply Test Packet +-------+ 202 \ / 203 T4 T3 205 STAMP Session-Sender STAMP Session-Reflector 207 Reference Topology 209 3. Overview 211 For performance measurement in SR networks, the STAMP test packets 212 defined in [RFC8762] and its optional extensions defined in [RFC8972] 213 and [I-D.gandhi-ippm-stamp-srpm] are used as described in this 214 document. The procedures are used to measure one-way, two-way and 215 round-trip delay as well as packet loss metrics in an SR network. 217 For performance delay and packet loss measurement, STAMP Session- 218 Sender test packets are transmitted in-band on the same path as the 219 data traffic flow under measurement to measure the delay and packet 220 loss experienced by the data traffic flow. It is also desired that 221 Session-Reflector reply test packets are transmitted in-band on the 222 same path in the reverse direction. This is achieved in SR networks 223 by using the STAMP extensions defined in 224 [I-D.gandhi-ippm-stamp-srpm]. 226 A destination UDP port number is selected as described in [RFC8762]. 227 The same destination UDP port is used for link and end-to-end SR path 228 STAMP test sessions. 230 3.1. Example STAMP Reference Model 232 An example of a STAMP reference model and typical measurement 233 parameters including the destination UDP port for STAMP test session 234 is shown in the following Figure 1: 236 +------------+ 237 | Controller | 238 +------------+ 239 / \ 240 Destination UDP Port / \ Destination UDP port 241 Authentication Mode & Key / \ Authentication Mode & Key 242 Delay Measurement Mode / \ 243 Timestamp Format / \ 244 Packet Loss Type / \ 245 / \ 246 v v 247 +-------+ +-------+ 248 | | | | 249 | R1 |==========| R3 | 250 | | | | 251 +-------+ +-------+ 253 STAMP Session-Sender STAMP Session-Reflector 255 Figure 1: Example STAMP Reference Model 257 Example of the Timestamp Format is PTPv2 [IEEE1588] and NTP. Example 258 of Delay Measurement Mode is one-way, two-way and round-trip mode as 259 described in this document. Example of Packet Loss Type is round- 260 trip packet loss [RFC8762]. 262 When using the authenticated mode for delay measurement, the matching 263 Authentication Type (e.g. HMAC-SHA-256) and Key are user-configured 264 on STAMP Session-Sender and STAMP Session-Reflector [RFC8762]. 266 The STAMP Session-Reflector R3 uses the timestamp format from the 267 received STAMP test packet. In addition, the STAMP Session-Reflector 268 R3 uses the parameters of the return path for the reply test packet 269 from the received STAMP test packet, as described in this document. 271 Note that the controller in the reference model is not intended for 272 signaling the SR parameters for STAMP test sessions between the STAMP 273 Session-Sender and STAMP Session-Reflector. In addition, maintenance 274 of each STAMP test session on Session-Reflector and creating extra 275 state are avoided in an SR network. 277 The YANG data model defined in [I-D.ietf-ippm-stamp-yang] can be used 278 to provision the STAMP Session-Sender and STAMP Session-Reflector. 280 4. Delay Measurement for Links and SR Paths 282 4.1. Session-Sender Test Packet 284 The content of an example STAMP Session-Sender test packet using an 285 UDP header [RFC0768] is shown in Figure 2. The payload contains the 286 STAMP Session-Sender test packet defined in [RFC8762]. 288 +---------------------------------------------------------------+ 289 | IP Header | 290 . Source IP Address = Session-Sender IPv4 or IPv6 Address . 291 . Destination IP Address=Session-Reflector IPv4 or IPv6 Address. 292 . Protocol = UDP . 293 . . 294 +---------------------------------------------------------------+ 295 | UDP Header | 296 . Source Port = As chosen by Session-Sender . 297 . Destination Port = User-configured Port | 862 . 298 . . 299 +---------------------------------------------------------------+ 300 | Payload = Test Packet as specified in Section 4.2 of RFC 8762 | 301 . . 302 +---------------------------------------------------------------+ 304 Figure 2: Example Session-Sender Test Packet 306 4.1.1. Session-Sender Test Packet for Links 308 The STAMP Session-Sender test packet as shown in Figure 2 is 309 transmitted over the link for delay measurement. The local and 310 remote IP addresses of the link are used as Source and Destination 311 Addresses. 313 4.1.2. Session-Sender Test Packet for SR Paths 315 The delay measurement for end-to-end SR path in SR network is 316 applicable to both end-to-end SR-MPLS and SRv6 paths including SR 317 Policies. 319 The STAMP Session-Sender IPv4 or IPv6 address is used as the Source 320 Address. The SR Policy endpoint IPv4 or IPv6 address is used as the 321 Destination Address. 323 In the case of Color-Only Destination Steering, with IPv4 endpoint of 324 0.0.0.0 or IPv6 endpoint of ::0 325 [I-D.ietf-spring-segment-routing-policy], the loopback address from 326 the range 127/8 for IPv4, or the loopback address ::1/128 for IPv6 is 327 used as the Destination Address, respectively. 329 4.1.2.1. Session-Sender Test Packet for SR-MPLS Policies 331 An SR-MPLS Policy may contain a number of Segment Lists. A STAMP 332 Session-Sender test packet is transmitted for each Segment List of 333 the SR-MPLS Policy. The content of an example STAMP Session-Sender 334 test packet for an end-to-end SR-MPLS Policy is shown in Figure 3. 336 0 1 2 3 337 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 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 | Segment(1) | TC |S| TTL | 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 . . 342 . . 343 . . 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 | Segment(n) | TC |S| TTL | 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 | PSID | TC |S| TTL | 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 | Test Packet as shown in Figure 2 | 350 . . 351 +---------------------------------------------------------------+ 353 Figure 3: Example Session-Sender Test Packet for SR-MPLS Policy 355 The Segment List (SL) can be empty in case of a single-hop SR-MPLS 356 Policy with Implicit NULL label. 358 The Path Segment Identifier (PSID) 359 [I-D.ietf-spring-mpls-path-segment] of an SR-MPLS Policy can be 360 carried in the MPLS header as shown in Figure 3, and can be used for 361 direct measurement as described in Section 7. 363 4.1.2.2. Session-Sender Test Packet for SRv6 Policies 365 An SRv6 Policy may contain a number of Segment Lists. A STAMP 366 Session-Sender test packet is transmitted for each Segment List of 367 the SRv6 Policy. An SRv6 Policy can contain an SRv6 Segment Routing 368 Header (SRH) carrying a Segment List as described in [RFC8754]. The 369 content of an example STAMP Session-Sender test packet for an end-to- 370 end SRv6 Policy is shown in Figure 4. 372 The SRv6 network programming is described in 373 [I-D.ietf-spring-srv6-network-programming]. The procedure defined 374 for upper-layer header processing for SRv6 SIDs in 375 [I-D.ietf-spring-srv6-network-programming] is used to process the 376 IPv6/UDP header in the received test packets on the Session- 377 Reflector. 379 +---------------------------------------------------------------+ 380 | IP Header | 381 . Source IP Address = Session-Sender IPv6 Address . 382 . Destination IP Address = Destination IPv6 Address . 383 . . 384 +---------------------------------------------------------------+ 385 | SRH as specified in RFC 8754 | 386 . . 387 . . 388 +---------------------------------------------------------------+ 389 | IP Header | 390 . Source IP Address = Session-Sender IPv6 Address . 391 . Destination IP Address = Session-Reflector IPv6 Address . 392 . Protocol = UDP . 393 . . 394 +---------------------------------------------------------------+ 395 | UDP Header | 396 . Source Port = As chosen by Session-Sender . 397 . Destination Port = User-configured Port | 862 . 398 . . 399 +---------------------------------------------------------------+ 400 | Payload = Test Packet as specified in Section 4.2 of RFC 8762 | 401 . . 402 +---------------------------------------------------------------+ 404 Figure 4: Example Session-Sender Test Packet for SRv6 Policy 406 The Segment List (SL) may be empty and no SRH may be carried. 408 The Path Segment Identifier (PSID) 409 [I-D.ietf-spring-srv6-path-segment] of the SRV6 Policy can be carried 410 in the SRH as shown in Figure 4 and can be used for direct 411 measurement as described in Section 7. 413 4.2. Session-Reflector Test Packet 415 The STAMP Session-Reflector reply test packet is transmitted using 416 the IP/UDP information from the received test packet. The content of 417 an example STAMP Session-Reflector reply test packet is shown in 418 Figure 5. 420 +---------------------------------------------------------------+ 421 | IP Header | 422 . Source IP Address = Session-Reflector IPv4 or IPv6 Address . 423 . Destination IP Address . 424 . = Source IP Address from Received Test Packet . 425 . Protocol = UDP . 426 . . 427 +---------------------------------------------------------------+ 428 | UDP Header | 429 . Source Port = As chosen by Session-Reflector . 430 . Destination Port = Source Port from Received Test Packet . 431 . . 432 +---------------------------------------------------------------+ 433 | Payload = Test Packet as specified in Section 4.3 of RFC 8762 | 434 . . 435 +---------------------------------------------------------------+ 437 Figure 5: Example Session-Reflector Test Packet 439 4.2.1. One-way Delay Measurement Mode 441 In one-way delay measurement mode, a reply test packet as shown in 442 Figure 5 is transmitted by the STAMP Session-Reflector, for both 443 links and SR Policies. The reply test packet may be transmitted on 444 the same path or a different path in the reverse direction. 446 The STAMP Session-Sender address may not be reachable via IP route 447 from the STAMP Session-Reflector. The STAMP Session-Sender in this 448 case can send its reachability path information to the STAMP Session- 449 Reflector using the Return Path TLV defined in 450 [I-D.gandhi-ippm-stamp-srpm]. 452 In this mode, as per Reference Topology, all timestamps T1, T2, T3, 453 and T4 are collected by the test packets. However, only timestamps 454 T1 and T2 are used to measure one-way delay as (T2 - T1). 456 4.2.2. Two-way Delay Measurement Mode 458 In two-way delay measurement mode, a reply test packet as shown in 459 Figure 5 is transmitted by the STAMP Session-Reflector in-band on the 460 same path in the reverse direction, e.g. on the reverse direction 461 link or associated reverse SR path [I-D.ietf-pce-sr-bidir-path]. 463 For two-way delay measurement mode for links, the STAMP Session- 464 Reflector needs to transmit the reply test packet in-band on the same 465 link where the test packet is received. The STAMP Session-Sender can 466 request in the test packet to the STAMP Session-Reflector to transmit 467 the reply test packet back on the same link using the Control Code 468 Sub-TLV in the Return Path TLV defined in 469 [I-D.gandhi-ippm-stamp-srpm]. 471 For two-way delay measurement mode for end-to-end SR paths, the STAMP 472 Session-Reflector needs to transmit the reply test packet in-band on 473 a specific reverse path. The STAMP Session-Sender can request in the 474 test packet to the STAMP Session-Reflector to transmit the reply test 475 packet back on a given reverse path using a Segment List sub-TLV in 476 the Return Path TLV defined in [I-D.gandhi-ippm-stamp-srpm]. 478 In this mode, as per Reference Topology, all timestamps T1, T2, T3, 479 and T4 are collected by the test packets. All four timestamps are 480 used to measure two-way delay as ((T4 - T1) - (T3 - T2)). 482 4.2.2.1. Session-Reflector Test Packet for SR-MPLS Policies 484 The content of an example STAMP Session-Reflector reply test packet 485 transmitted in-band on the same path as the data traffic flow under 486 measurement for two-way delay measurement of an end-to-end SR-MPLS 487 Policy is shown in Figure 6. 489 0 1 2 3 490 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 | Segment(1) | TC |S| TTL | 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 . . 495 . . 496 . . 497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 498 | Segment(n) | TC |S| TTL | 499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 500 | Test Packet as shown in Figure 5 | 501 . . 502 +---------------------------------------------------------------+ 504 Figure 6: Example Session-Reflector Test Packet for SR-MPLS Policy 506 4.2.2.2. Session-Reflector Test Packet for SRv6 Policies 508 The content of an example STAMP Session-Reflector reply test packet 509 transmitted in-band on the same path as the data traffic flow under 510 measurement for two-way delay measurement of an end-to-end SRv6 511 Policy with SRH is shown in Figure 7. 513 The procedure defined for upper-layer header processing for SRv6 SIDs 514 in [I-D.ietf-spring-srv6-network-programming] is also used to process 515 the IPv6/UDP header in the received reply test packets on the 516 Session-Sender. 518 +---------------------------------------------------------------+ 519 | IP Header | 520 . Source IP Address = Session-Reflector IPv6 Address . 521 . Destination IP Address = Destination IPv6 Address . 522 . . 523 +---------------------------------------------------------------+ 524 | SRH as specified in RFC 8754 | 525 . . 526 . . 527 +---------------------------------------------------------------+ 528 | IP Header | 529 . Source IP Address = Session-Reflector IPv6 Address . 530 . Destination IP Address . 531 . = Source IPv6 Address from Received Test Packet . 532 . Protocol = UDP . 533 . . 534 +---------------------------------------------------------------+ 535 | UDP Header | 536 . Source Port = As chosen by Session-Reflector . 537 . Destination Port = Source Port from Received Test Packet . 538 . . 539 +---------------------------------------------------------------+ 540 | Payload = Test Packet as specified in Section 4.3 of RFC 8762 | 541 . . 542 +---------------------------------------------------------------+ 544 Figure 7: Example Session-Reflector Test Packet for SRv6 Policy 546 4.2.3. Round-trip Delay Measurement Mode 548 The STAMP Session-Sender test packets are sent in loopback mode to 549 measure round-trip delay of a bidirectional path. The IP header of 550 the STAMP Session-Sender test packet contains the Destination Address 551 equals to the STAMP Session-Sender address and the Source Address 552 equals to the STAMP Session-Reflector address. Optionally, the STAMP 553 Session-Sender test packet can carry the return path information 554 (e.g. return path label stack for SR-MPLS) as part of the SR header. 555 This way, the received Session-Sender test packets are not punted out 556 of the fast path in forwarding (to slow path or control-plane) at the 557 STAMP Session-Reflector. Also, the Session-Reflector does not 558 process them and generate reply test packets. 560 As the reply test packet is not generated by the STAMP Session- 561 Reflector, the STAMP Session-Sender ignores the 'Session-Sender 562 Sequence Number', 'Session-Sender Timestamp', 'Session-Sender Error 563 Estimate', and 'Session-Sender TTL' in the received test packet. 565 In this mode, as per Reference Topology, the timestamps T1 and T4 are 566 collected by the test packets. Both these timestamps are used to 567 measure round-trip delay as (T4 - T1). 569 4.3. Delay Measurement for P2MP SR Policies 571 The Point-to-Multipoint (P2MP) SR path that originates from a root 572 node terminates on multiple destinations called leaf nodes (e.g. 573 P2MP SR Policy [I-D.ietf-pim-sr-p2mp-policy]). 575 The procedures for performance measurement described in this document 576 for P2P SR Policies are used for the P2MP SR Policies as listed 577 below. 579 o The STAMP Session-Sender root node transmits test packets using 580 the Tree-SID defined in [I-D.ietf-pim-sr-p2mp-policy] for the P2MP 581 SR-MPLS Policy as shown in Figure 8. The STAMP Session-Sender 582 test packets may contain the replication SID as defined in 583 [I-D.ietf-spring-sr-replication-segment]. 585 o The Destination Address is set to the loopback address from the 586 range 127/8 for IPv4, or the loopback address ::1/128 for IPv6. 588 o Each STAMP Session-Reflector leaf node transmits its node address 589 in the Source Address of the reply test packets shown in Figure 5. 590 This allows the STAMP Session-Sender root node to identify the 591 STAMP Session-Reflector leaf nodes of the P2MP SR Policy. 593 o The P2MP root node measures the delay for each P2MP leaf node 594 individually. 596 0 1 2 3 597 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 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 599 | Tree-SID | TC |S| TTL | 600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 601 . . 602 . . 603 . . 604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 605 | Test Packet as shown in Figure 2 | 606 . . 607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 609 Figure 8: Example Session-Sender Test Packet with Tree-SID for SR- 610 MPLS Policy 612 The round-trip delay measurement for a P2MP SR-MPLS Policy can use 613 the Node SID of the Session-Sender in the MPLS header of the Session- 614 Sender test packet. 616 4.4. Additional STAMP Test Packet Processing Rules 618 The processing rules described in this section are applicable to the 619 STAMP test packets for links and end-to-end SR paths including SR 620 Policies. 622 4.4.1. TTL 624 The TTL field in the IPv4 and MPLS headers of the STAMP Session- 625 Sender and STAMP Session-Reflector reply test packets is set to 255, 626 except in the following cases. 628 When using the Destination IPv4 Address from the range 127/8, the TTL 629 field in the IPv4 header is set to 1. 631 For link delay, the TTL field in the STAMP test packet is set to 1 in 632 one-way and two-way delay measurement modes. 634 4.4.2. IPv6 Hop Limit 636 The Hop Limit field in the IPv6 and SRH headers of the STAMP Session- 637 Sender and STAMP Session-Reflector reply test packets is set to 255, 638 except in the following cases. 640 When using the Destination IPv6 Address of loopback address ::1/128, 641 the Hop Limit field in the IPv6 header is set to 1. 643 For link delay, the Hop Limit field in the STAMP test packet is set 644 to 1 in one-way and two-way delay measurement modes. 646 4.4.3. Router Alert Option 648 The Router Alert IP option (RAO) [RFC2113] is not set in the STAMP 649 test packets for links and end-to-end SR paths. 651 5. Packet Loss Measurement for Links and SR Paths 653 The procedure described in Section 4 for delay measurement using 654 STAMP test packets can be used to detect (test) packet loss for links 655 and end-to-end SR paths. The Sequence Number field in the STAMP test 656 packet is used as described in Section 4 "Theory of Operation" of 657 [RFC8762], to detect forward, reverse and round-trip packet loss. 659 6. Direct Measurement for Links and SR Paths 661 The STAMP "Direct Measurement" TLV (Type 5) defined in [RFC8972] can 662 be used in SR networks. The STAMP test packets with this TLV are 663 transmitted using the procedures described in Section 4 to collect 664 the transmit and receive counters of the data flow for the links and 665 end-to-end SR paths. Note that in this case, the STAMP test packets 666 may follow the same or a different path than the data flow under 667 direct measurement. 669 The PSID carried in the received data packet for the traffic flow 670 under measurement can be used to measure receive data packets for 671 end-to-end SR path on the STAMP Session-Reflector. The PSID in the 672 received Session-Sender test packet header can be used to associate 673 the receive traffic counter on the Session-Reflector for the end-to- 674 end SR path. 676 7. Session Status for Links and SR Paths 678 The STAMP test session status allows to know if the performance 679 measurement is active on the links and end-to-end SR paths. The 680 STAMP test session status initially is declared succeeded when one or 681 more reply test packets are received at the STAMP Session-Sender. 682 The STAMP test session status is declared failed when consecutive N 683 number of reply test packets are not received at the STAMP Session- 684 Sender, where N is locally provisioned value. 686 8. ECMP Support for SR Policies 688 An SR Policy can have ECMPs between the source and transit nodes, 689 between transit nodes and between transit and destination nodes. 690 Usage of Anycast SID [RFC8402] by an SR Policy can result in ECMP 691 paths via transit nodes part of that Anycast group. The test packets 692 need to be transmitted to traverse different ECMP paths to measure 693 delay of an SR Policy. 695 Forwarding plane has various hashing functions available to forward 696 packets on specific ECMP paths. The mechanisms described in 697 [RFC8029] and [RFC5884] for handling ECMPs are also applicable to the 698 delay measurement. 700 In IPv4 header of the STAMP Session-Sender test packets, sweeping of 701 Destination Address from the range 127/8 can be used to exercise 702 particular ECMP paths. Note that in the loopback mode for round-trip 703 delay measurement, both the forward and the return paths must be SR- 704 MPLS paths in this case. 706 As specified in [RFC6437], Flow Label field in the outer IPv6 header 707 can also be used for sweeping to exercise different IPv6 ECMP paths. 709 The "Destination Node Address" TLV [I-D.gandhi-ippm-stamp-srpm] can 710 be carried in the STAMP Session-Sender test packet to identify the 711 intended destination node, for example, when using IPv4 Destination 712 Address from the range 127/8. The STAMP Session-Reflector must not 713 transmit reply test packet if it is not the intended destination node 714 in the "Destination Node Address" TLV [I-D.gandhi-ippm-stamp-srpm]. 716 9. Security Considerations 718 The performance measurement is intended for deployment in well- 719 managed private and service provider networks. As such, it assumes 720 that a node involved in a measurement operation has previously 721 verified the integrity of the path and the identity of the far-end 722 STAMP Session-Reflector. 724 If desired, attacks can be mitigated by performing basic validation 725 and sanity checks, at the STAMP Session-Sender, of the counter or 726 timestamp fields in received measurement reply test packets. The 727 minimal state associated with these protocols also limits the extent 728 of measurement disruption that can be caused by a corrupt or invalid 729 packet to a single test cycle. 731 Use of HMAC-SHA-256 in the authenticated mode protects the data 732 integrity of the test packets. SRv6 has HMAC protection 733 authentication defined for SRH [RFC8754]. Hence, test packets for 734 SRv6 may not need authentication mode. Cryptographic measures may be 735 enhanced by the correct configuration of access-control lists and 736 firewalls. 738 The security considerations specified in [RFC8762] and [RFC8972] also 739 apply to the procedures described in this document. 741 10. IANA Considerations 743 This document does not require any IANA action. 745 11. References 747 11.1. Normative References 749 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 750 DOI 10.17487/RFC0768, August 1980, 751 . 753 [RFC8762] Mirsky, G., Jun, G., Nydell, H., and R. Foote, "Simple 754 Two-Way Active Measurement Protocol", RFC 8762, 755 DOI 10.17487/RFC8762, March 2020, 756 . 758 [RFC8972] Mirsky, G., Min, X., Nydell, H., Foote, R., Masputra, A., 759 and E. Ruffini, "Simple Two-Way Active Measurement 760 Protocol Optional Extensions", RFC 8972, 761 DOI 10.17487/RFC8972, January 2021, 762 . 764 [I-D.gandhi-ippm-stamp-srpm] 765 Gandhi, R., Filsfils, C., Voyer, D., Chen, M., and B. 766 Janssens, "Simple TWAMP (STAMP) Extensions for Segment 767 Routing Networks", draft-gandhi-ippm-stamp-srpm-02 (work 768 in progress), February 2021. 770 [I-D.ietf-spring-srv6-network-programming] 771 Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., 772 Matsushima, S., and Z. Li, "SRv6 Network Programming", 773 draft-ietf-spring-srv6-network-programming-28 (work in 774 progress), December 2020. 776 11.2. Informative References 778 [IEEE1588] 779 IEEE, "1588-2008 IEEE Standard for a Precision Clock 780 Synchronization Protocol for Networked Measurement and 781 Control Systems", March 2008. 783 [RFC2113] Katz, D., "IP Router Alert Option", RFC 2113, 784 DOI 10.17487/RFC2113, February 1997, 785 . 787 [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, 788 "Bidirectional Forwarding Detection (BFD) for MPLS Label 789 Switched Paths (LSPs)", RFC 5884, DOI 10.17487/RFC5884, 790 June 2010, . 792 [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, 793 "IPv6 Flow Label Specification", RFC 6437, 794 DOI 10.17487/RFC6437, November 2011, 795 . 797 [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., 798 Aldrin, S., and M. Chen, "Detecting Multiprotocol Label 799 Switched (MPLS) Data-Plane Failures", RFC 8029, 800 DOI 10.17487/RFC8029, March 2017, 801 . 803 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 804 Decraene, B., Litkowski, S., and R. Shakir, "Segment 805 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 806 July 2018, . 808 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 809 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 810 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 811 . 813 [I-D.ietf-spring-segment-routing-policy] 814 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 815 P. Mattes, "Segment Routing Policy Architecture", draft- 816 ietf-spring-segment-routing-policy-09 (work in progress), 817 November 2020. 819 [I-D.ietf-spring-sr-replication-segment] 820 Voyer, D., Filsfils, C., Parekh, R., Bidgoli, H., and Z. 821 Zhang, "SR Replication Segment for Multi-point Service 822 Delivery", draft-ietf-spring-sr-replication-segment-02 823 (work in progress), October 2020. 825 [I-D.ietf-pim-sr-p2mp-policy] 826 Voyer, D., Filsfils, C., Parekh, R., Bidgoli, H., and Z. 827 Zhang, "Segment Routing Point-to-Multipoint Policy", 828 draft-ietf-pim-sr-p2mp-policy-01 (work in progress), 829 October 2020. 831 [I-D.ietf-spring-mpls-path-segment] 832 Cheng, W., Li, H., Chen, M., Gandhi, R., and R. Zigler, 833 "Path Segment in MPLS Based Segment Routing Network", 834 draft-ietf-spring-mpls-path-segment-03 (work in progress), 835 September 2020. 837 [I-D.ietf-spring-srv6-path-segment] 838 Li, C., Cheng, W., Chen, M., Dhody, D., and R. Gandhi, 839 "Path Segment for SRv6 (Segment Routing in IPv6)", draft- 840 ietf-spring-srv6-path-segment-00 (work in progress), 841 November 2020. 843 [I-D.ietf-pce-sr-bidir-path] 844 Li, C., Chen, M., Cheng, W., Gandhi, R., and Q. Xiong, 845 "Path Computation Element Communication Protocol (PCEP) 846 Extensions for Associated Bidirectional Segment Routing 847 (SR) Paths", draft-ietf-pce-sr-bidir-path-05 (work in 848 progress), January 2021. 850 [I-D.ietf-ippm-stamp-yang] 851 Mirsky, G., Min, X., and W. Luo, "Simple Two-way Active 852 Measurement Protocol (STAMP) Data Model", draft-ietf-ippm- 853 stamp-yang-06 (work in progress), October 2020. 855 Acknowledgments 857 The authors would like to thank Thierry Couture for the discussions 858 on the use-cases for Performance Measurement in segment routing. The 859 authors would also like to thank Greg Mirsky, Gyan Mishra, Xie 860 Jingrong, and Mike Koldychev for reviewing this document and 861 providing useful comments and suggestions. Patrick Khordoc and Radu 862 Valceanu have helped improve the mechanisms described in this 863 document. 865 Authors' Addresses 867 Rakesh Gandhi (editor) 868 Cisco Systems, Inc. 869 Canada 871 Email: rgandhi@cisco.com 873 Clarence Filsfils 874 Cisco Systems, Inc. 876 Email: cfilsfil@cisco.com 877 Daniel Voyer 878 Bell Canada 880 Email: daniel.voyer@bell.ca 882 Mach(Guoyi) Chen 883 Huawei 885 Email: mach.chen@huawei.com 887 Bart Janssens 888 Colt 890 Email: Bart.Janssens@colt.net