idnits 2.17.1 draft-gandhi-spring-stamp-srpm-06.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 (April 29, 2021) is 1065 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- 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-09 == Outdated reference: A later version (-19) exists of draft-ietf-spring-sr-replication-segment-04 == Outdated reference: A later version (-07) exists of draft-ietf-pim-sr-p2mp-policy-02 == Outdated reference: A later version (-22) exists of draft-ietf-spring-mpls-path-segment-04 == 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-07 Summary: 0 errors (**), 0 flaws (~~), 8 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: Informational Cisco Systems, Inc. 5 Expires: October 31, 2021 D. Voyer 6 Bell Canada 7 M. Chen 8 Huawei 9 B. Janssens 10 Colt 11 R. Foote 12 Nokia 13 April 29, 2021 15 Performance Measurement Using Simple TWAMP (STAMP) for Segment Routing 16 Networks 17 draft-gandhi-spring-stamp-srpm-06 19 Abstract 21 Segment Routing (SR) leverages the source routing paradigm. SR is 22 applicable to both Multiprotocol Label Switching (SR-MPLS) and IPv6 23 (SRv6) data planes. This document describes procedures for 24 Performance Measurement in SR networks using the mechanisms defined 25 in RFC 8762 (Simple Two-Way Active Measurement Protocol (STAMP)) and 26 its optional extensions defined in RFC 8972 and further augmented in 27 draft-gandhi-ippm-stamp-srpm. The procedure described is applicable 28 to SR-MPLS and SRv6 data planes and is used for both links and end- 29 to-end SR paths including SR Policies. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on October 31, 2021. 48 Copyright Notice 50 Copyright (c) 2021 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 67 2.1. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3 68 2.2. Reference Topology . . . . . . . . . . . . . . . . . . . 4 69 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 3.1. Example STAMP Reference Model . . . . . . . . . . . . . . 6 71 4. Delay Measurement for Links and SR Paths . . . . . . . . . . 7 72 4.1. Session-Sender Test Packet . . . . . . . . . . . . . . . 7 73 4.1.1. Session-Sender Test Packet for Links . . . . . . . . 7 74 4.1.2. Session-Sender Test Packet for SR Paths . . . . . . . 8 75 4.2. Session-Reflector Test Packet . . . . . . . . . . . . . . 10 76 4.2.1. One-way Measurement Mode . . . . . . . . . . . . . . 11 77 4.2.2. Two-way Measurement Mode . . . . . . . . . . . . . . 11 78 4.2.3. Loopback Measurement Mode . . . . . . . . . . . . . . 13 79 4.3. Delay Measurement for P2MP SR Policies . . . . . . . . . 14 80 4.4. Additional STAMP Test Packet Processing Rules . . . . . . 15 81 4.4.1. TTL . . . . . . . . . . . . . . . . . . . . . . . . . 15 82 4.4.2. IPv6 Hop Limit . . . . . . . . . . . . . . . . . . . 16 83 4.4.3. Router Alert Option . . . . . . . . . . . . . . . . . 16 84 4.4.4. UDP Checksum . . . . . . . . . . . . . . . . . . . . 16 85 5. Packet Loss Measurement for Links and SR Paths . . . . . . . 16 86 6. Direct Measurement for Links and SR Paths . . . . . . . . . . 16 87 7. Session State for Links and SR Paths . . . . . . . . . . . . 17 88 8. ECMP Support for SR Policies . . . . . . . . . . . . . . . . 17 89 9. Security Considerations . . . . . . . . . . . . . . . . . . . 18 90 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 91 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 92 11.1. Normative References . . . . . . . . . . . . . . . . . . 19 93 11.2. Informative References . . . . . . . . . . . . . . . . . 19 94 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 22 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 97 1. Introduction 99 Segment Routing (SR) leverages the source routing paradigm and 100 greatly simplifies network operations for Software Defined Networks 101 (SDNs). SR is applicable to both Multiprotocol Label Switching (SR- 102 MPLS) and IPv6 (SRv6) data planes [RFC8402]. SR takes advantage of 103 the Equal-Cost Multipaths (ECMPs) between source and transit nodes, 104 between transit nodes and between transit and destination nodes. SR 105 Policies as defined in [I-D.ietf-spring-segment-routing-policy] are 106 used to steer traffic through a specific, user-defined paths using a 107 stack of Segments. Built-in SR Performance Measurement (PM) is one 108 of the essential requirements to provide Service Level Agreements 109 (SLAs). 111 The Simple Two-way Active Measurement Protocol (STAMP) provides 112 capabilities for the measurement of various performance metrics in IP 113 networks [RFC8762] without the use of a control channel to pre-signal 114 session parameters. [RFC8972] defines optional extensions for STAMP. 115 [I-D.gandhi-ippm-stamp-srpm] augments that framework to define STAMP 116 extensions for SR networks. 118 This document describes procedures for Performance Measurement in SR 119 networks using the mechanisms defined in STAMP [RFC8762] and its 120 optional extensions defined in [RFC8972] and further augmented in 121 [I-D.gandhi-ippm-stamp-srpm]. The procedure described is applicable 122 to SR-MPLS and SRv6 data planes and is used for both links and end- 123 to-end SR paths including SR Policies [RFC8402]. 125 2. Conventions Used in This Document 127 2.1. Abbreviations 129 BSID: Binding Segment ID. 131 DM: Delay Measurement. 133 ECMP: Equal Cost Multi-Path. 135 HMAC: Hashed Message Authentication Code. 137 LM: Loss Measurement. 139 MPLS: Multiprotocol Label Switching. 141 NTP: Network Time Protocol. 143 OWAMP: One-Way Active Measurement Protocol. 145 PM: Performance Measurement. 147 PSID: Path Segment Identifier. 149 PTP: Precision Time Protocol. 151 SHA: Secure Hash Algorithm. 153 SID: Segment ID. 155 SL: Segment List. 157 SR: Segment Routing. 159 SRH: Segment Routing Header. 161 SR-MPLS: Segment Routing with MPLS data plane. 163 SRv6: Segment Routing with IPv6 data plane. 165 SSID: STAMP Session Identifier. 167 STAMP: Simple Two-way Active Measurement Protocol. 169 TC: Traffic Class. 171 TTL: Time To Live. 173 2.2. Reference Topology 175 In the Reference Topology shown below, the STAMP Session-Sender R1 176 initiates a STAMP test packet and the STAMP Session-Reflector R3 177 transmits a reply test packet. The reply test packet may be 178 transmitted to the STAMP Session-Sender R1 on the same path (same set 179 of links and nodes) or a different path in the reverse direction from 180 the path taken towards the Session-Reflector. 182 The nodes R1 and R3 may be connected via a link or an SR path 183 [RFC8402]. The link may be a physical interface, virtual link, or 184 Link Aggregation Group (LAG) [IEEE802.1AX], or LAG member link. The 185 SR path may be an SR Policy [I-D.ietf-spring-segment-routing-policy] 186 on node R1 (called head-end) with destination to node R3 (called 187 tail-end). 189 T1 T2 190 / \ 191 +-------+ Test Packet +-------+ 192 | | - - - - - - - - - ->| | 193 | R1 |=====================| R3 | 194 | |<- - - - - - - - - - | | 195 +-------+ Reply Test Packet +-------+ 196 \ / 197 T4 T3 199 STAMP Session-Sender STAMP Session-Reflector 201 Reference Topology 203 3. Overview 205 For performance measurement in SR networks, the STAMP Session-Sender 206 and Session-Reflector test packets defined in [RFC8762] are used. 207 They are used in one-way, two-way (i.e. round-trip) and loopback 208 measurement modes. Note that one-way and round-trip are referred to 209 in [RFC8762] and are further described in this document because of 210 the introduction of loopback measurement mode in SR networks. The 211 procedures defined in this document are also used to infer packet 212 loss in SR networks. 214 The STAMP test packets are transmitted on the same path as the data 215 traffic flow under measurement to measure the delay and packet loss 216 experienced by the data traffic flow. 218 Typically, the STAMP test packets are transmitted along an IP path 219 between a Session-Sender and a Session-Reflector to measure delay and 220 packet loss along that IP path. Matching the forward and reverse 221 direction paths for STAMP test packets, even for directly connected 222 nodes is not guaranteed. 224 It may be desired in SR networks that the same path (same set of 225 links and nodes) between the Session-Sender and Session-Reflector be 226 used for the STAMP test packets in both directions. This is achieved 227 by using the optional STAMP extensions for SR-MPLS and SRv6 networks 228 specified in [I-D.gandhi-ippm-stamp-srpm]. The STAMP Session- 229 Reflector uses the return path parameters for the reply test packet 230 from the received STAMP test packet, as described in 231 [I-D.gandhi-ippm-stamp-srpm]. This way signaling and maintaining 232 dynamic SR network state for the STAMP sessions on the Session- 233 Reflector are avoided. 235 The optional STAMP extensions defined in [RFC8972] are used for 236 direct measurement packet loss in SR networks. 238 3.1. Example STAMP Reference Model 240 An example of a STAMP reference model with some of the typical 241 measurement parameters including the Reflector UDP port for STAMP 242 test session is shown in the following Figure 1: 244 +------------+ 245 | Controller | 246 +------------+ 247 / \ 248 Reflector UDP Port / \ Reflector UDP Port 249 Authentication Mode / \ Authentication Mode 250 Key-chain / \ Key-chain 251 Timestamp Format / \ Timestamp Format 252 Packet Loss Type / \ Reflector Mode 253 Delay Measurement Mode / \ 254 v v 255 +-------+ +-------+ 256 | | | | 257 | R1 |==========| R3 | 258 | | | | 259 +-------+ +-------+ 261 STAMP Session-Sender STAMP Session-Reflector 263 Figure 1: Example STAMP Reference Model 265 A reflector UDP port number is selected as described in [RFC8762]. 266 The same reflector UDP port can be used for STAMP test sessions for 267 link and end-to-end SR paths. In this case, the reflector UDP port 268 does not distinguish between link or end-to-end SR path measurements. 270 Example of the Timestamp Format is Precision Time Protocol 64-bit 271 truncated (PTPv2) [IEEE1588] and Network Time Protocol (NTP). By 272 default, the Session-Reflector replies in kind to the timestamp 273 format received in the received Session-Sender test packet, as 274 indicated by the "Z" field in the Error Estimate field as described 275 in [RFC8762]. 277 The Session-Reflector mode can be Stateful or Stateless as defined in 278 [RFC8762]. 280 Example of Delay Measurement Mode is one-way, two-way (i.e. round- 281 trip) and loopback mode as described in this document. 283 Example of Packet Loss Type can be round-trip, near-end (forward) and 284 far-end (backward) packet loss as defined in [RFC8762]. 286 When using the authenticated mode for the STAMP test sessions, the 287 matching Authentication Type (e.g. HMAC-SHA-256) and Key-chain are 288 user-configured on STAMP Session-Sender and STAMP Session-Reflector 289 [RFC8762]. 291 The controller shown in the example reference model is not intended 292 for the dynamic signaling of the SR parameters for STAMP test 293 sessions between the STAMP Session-Sender and STAMP Session- 294 Reflector. 296 Note that the YANG data model defined in [I-D.ietf-ippm-stamp-yang] 297 can be used to provision the STAMP Session-Sender and STAMP Session- 298 Reflector. 300 4. Delay Measurement for Links and SR Paths 302 4.1. Session-Sender Test Packet 304 The content of an example STAMP Session-Sender test packet using an 305 UDP header [RFC0768] is shown in Figure 2. The payload contains the 306 STAMP Session-Sender test packet defined in [RFC8762]. 308 +---------------------------------------------------------------+ 309 | IP Header | 310 . Source IP Address = Session-Sender IPv4 or IPv6 Address . 311 . Destination IP Address=Session-Reflector IPv4 or IPv6 Address. 312 . Protocol = UDP . 313 . . 314 +---------------------------------------------------------------+ 315 | UDP Header | 316 . Source Port = As chosen by Session-Sender . 317 . Destination Port = User-configured Reflector Port | 862 . 318 . . 319 +---------------------------------------------------------------+ 320 | Payload = Test Packet as specified in Section 4.2 of RFC 8762 | 321 . . 322 +---------------------------------------------------------------+ 324 Figure 2: Example Session-Sender Test Packet 326 4.1.1. Session-Sender Test Packet for Links 328 The STAMP Session-Sender test packet as shown in Figure 2 is 329 transmitted over the link under delay measurement. The local and 330 remote IP addresses of the link are used as Source and Destination 331 Addresses, respectively. For IPv6 links, the link local addresses 332 [RFC7404] can be used in the IPv6 header. The Session-Sender may use 333 the local Address Resolution Protocol (ARP) table, Neighbor 334 Solicitation or other bootstrap method to find the IP address for the 335 links and refresh. An IPv4 address from the range 127/8 or IPv6 336 loopback address ::1/128 [RFC4291] must not be used to IP route test 337 packets in a network. 339 4.1.2. Session-Sender Test Packet for SR Paths 341 The delay measurement for end-to-end SR path in an SR network is 342 applicable to both end-to-end SR-MPLS and SRv6 paths including SR 343 Policies. 345 The STAMP Session-Sender IPv4 or IPv6 address is used as the Source 346 Address. The SR Policy endpoint IPv4 or IPv6 address is used as the 347 Destination Address. 349 In the case of Color-Only Destination Steering, with IPv4 endpoint of 350 0.0.0.0 or IPv6 endpoint of ::0 351 [I-D.ietf-spring-segment-routing-policy], the loopback address from 352 the range 127/8 for IPv4, or the loopback address ::1/128 for IPv6 353 [RFC4291] is used as the Session-Reflector Address, respectively. 355 4.1.2.1. Session-Sender Test Packet for SR-MPLS Policies 357 An SR-MPLS Policy may contain a number of Segment Lists (SLs). A 358 STAMP Session-Sender test packet is transmitted for each Segment List 359 of the SR-MPLS Policy. The content of an example STAMP Session- 360 Sender test packet for an end-to-end SR-MPLS Policy is shown in 361 Figure 3. 363 0 1 2 3 364 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 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 | Segment(1) | TC |S| TTL | 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 . . 369 . . 370 . . 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 | Segment(n) | TC |S| TTL | 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 | PSID | TC |S| TTL | 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 | Test Packet as shown in Figure 2 | 377 . . 378 +---------------------------------------------------------------+ 380 Figure 3: Example Session-Sender Test Packet for SR-MPLS Policy 382 The Segment List can be empty in case of a single-hop SR-MPLS Policy 383 with Implicit NULL label. 385 The Path Segment Identifier (PSID) 386 [I-D.ietf-spring-mpls-path-segment] of an SR-MPLS Policy can be 387 carried in the MPLS header as shown in Figure 3, and can be used for 388 direct measurement as described in Section 6, titled "Direct 389 Measurement for Links and SR Paths". 391 4.1.2.2. Session-Sender Test Packet for SRv6 Policies 393 An SRv6 Policy may contain a number of Segment Lists. A STAMP 394 Session-Sender test packet is transmitted for each Segment List of 395 the SRv6 Policy. An SRv6 Policy can contain an SRv6 Segment Routing 396 Header (SRH) carrying a Segment List as described in [RFC8754]. The 397 content of an example STAMP Session-Sender test packet for an end-to- 398 end SRv6 Policy is shown in Figure 4. 400 The SRv6 network programming is described in [RFC8986]. The 401 procedure defined for Upper-Layer Header processing for SRv6 End SIDs 402 in Section 4.1.1 in [RFC8986] is used to process the IPv6/UDP header 403 in the received test packets on the Session-Reflector. 405 +---------------------------------------------------------------+ 406 | IP Header | 407 . Source IP Address = Session-Sender IPv6 Address . 408 . Destination IP Address = Destination IPv6 Address . 409 . . 410 +---------------------------------------------------------------+ 411 | SRH as specified in RFC 8754 | 412 . . 413 . . 414 +---------------------------------------------------------------+ 415 | IP Header | 416 . Source IP Address = Session-Sender IPv6 Address . 417 . Destination IP Address = Session-Reflector IPv6 Address . 418 . Protocol = UDP . 419 . . 420 +---------------------------------------------------------------+ 421 | UDP Header | 422 . Source Port = As chosen by Session-Sender . 423 . Destination Port = User-configured Reflector Port | 862 . 424 . . 425 +---------------------------------------------------------------+ 426 | Payload = Test Packet as specified in Section 4.2 of RFC 8762 | 427 . . 428 +---------------------------------------------------------------+ 430 Figure 4: Example Session-Sender Test Packet for SRv6 Policy 432 The Segment List (SL) may be empty and no SRH may be carried. 434 The Path Segment Identifier (PSID) 435 [I-D.ietf-spring-srv6-path-segment] of the SRV6 Policy can be carried 436 in the SRH as shown in Figure 4 and can be used for direct 437 measurement as described in Section 6, titled "Direct Measurement for 438 Links and SR Paths". 440 4.2. Session-Reflector Test Packet 442 The STAMP Session-Reflector reply test packet uses the IP/UDP 443 information from the received test packet as shown in Figure 5. 445 +---------------------------------------------------------------+ 446 | IP Header | 447 . Source IP Address = Session-Reflector IPv4 or IPv6 Address . 448 . Destination IP Address . 449 . = Source IP Address from Received Test Packet . 450 . Protocol = UDP . 451 . . 452 +---------------------------------------------------------------+ 453 | UDP Header | 454 . Source Port = As chosen by Session-Reflector . 455 . Destination Port = Source Port from Received Test Packet . 456 . . 457 +---------------------------------------------------------------+ 458 | Payload = Test Packet as specified in Section 4.3 of RFC 8762 | 459 . . 460 +---------------------------------------------------------------+ 462 Figure 5: Example Session-Reflector Test Packet 464 4.2.1. One-way Measurement Mode 466 In one-way delay measurement mode, a reply test packet as shown in 467 Figure 5 is transmitted by the STAMP Session-Reflector, for both 468 links and end-to-end SR Policies. The reply test packet may be 469 transmitted on the same path or a different path in the reverse 470 direction. 472 The STAMP Session-Sender address may not be reachable via IP route 473 from the STAMP Session-Reflector. The STAMP Session-Sender in this 474 case can send its reachability path information to the STAMP Session- 475 Reflector using the Return Path TLV defined in 476 [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. However, only timestamps 480 T1 and T2 are used to measure one-way delay as (T2 - T1). The one- 481 way delay measurement mode requires the clock on the Session-Sender 482 and Session-Reflector to be synchronized. 484 4.2.2. Two-way Measurement Mode 486 In two-way (i.e. round-trip) delay measurement mode, a reply test 487 packet as shown in Figure 5 is transmitted by the STAMP Session- 488 Reflector on the same path in the reverse direction, e.g. on the 489 reverse direction link or associated reverse SR path 490 [I-D.ietf-pce-sr-bidir-path]. 492 For two-way delay measurement mode for links, the STAMP Session- 493 Reflector needs to transmit the reply test packet on the same link 494 where the test packet is received. The STAMP Session-Sender can 495 request in the test packet to the STAMP Session-Reflector to transmit 496 the reply test packet back on the same link using the Control Code 497 Sub-TLV in the Return Path TLV defined in 498 [I-D.gandhi-ippm-stamp-srpm]. 500 For two-way delay measurement mode for end-to-end SR paths, the STAMP 501 Session-Reflector needs to transmit the reply test packet on a 502 specific reverse path. The STAMP Session-Sender can request in the 503 test packet to the STAMP Session-Reflector to transmit the reply test 504 packet back on a given reverse path using a Segment List sub-TLV in 505 the Return Path TLV defined in [I-D.gandhi-ippm-stamp-srpm]. 507 In this mode, as per Reference Topology, all timestamps T1, T2, T3, 508 and T4 are collected by the test packets. All four timestamps are 509 used to measure two-way delay as ((T4 - T1) - (T3 - T2)). When clock 510 synchronization on the Session-Sender and Session-Reflector nodes is 511 not possible, the one-way delay can be derived using two-way delay 512 divided by two. 514 4.2.2.1. Session-Reflector Test Packet for SR-MPLS Policies 516 The content of an example STAMP Session-Reflector reply test packet 517 transmitted on the same path as the data traffic flow under 518 measurement for two-way delay measurement of an end-to-end SR-MPLS 519 Policy is shown in Figure 6. 521 0 1 2 3 522 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 523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 524 | Segment(1) | TC |S| TTL | 525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 526 . . 527 . . 528 . . 529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 530 | Segment(n) | TC |S| TTL | 531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 532 | Test Packet as shown in Figure 5 | 533 . . 534 +---------------------------------------------------------------+ 536 Figure 6: Example Session-Reflector Test Packet for SR-MPLS Policy 538 4.2.2.2. Session-Reflector Test Packet for SRv6 Policies 540 The content of an example STAMP Session-Reflector reply test packet 541 transmitted on the same path as the data traffic flow under 542 measurement for two-way delay measurement of an end-to-end SRv6 543 Policy with SRH is shown in Figure 7. 545 The procedure defined for Upper-Layer Header processing for SRv6 End 546 SIDs in Section 4.1.1 in [RFC8986] is used to process the IPv6/UDP 547 header in the received reply test packets on the Session-Sender. 549 +---------------------------------------------------------------+ 550 | IP Header | 551 . Source IP Address = Session-Reflector IPv6 Address . 552 . Destination IP Address = Destination IPv6 Address . 553 . . 554 +---------------------------------------------------------------+ 555 | SRH as specified in RFC 8754 | 556 . . 557 . . 558 +---------------------------------------------------------------+ 559 | IP Header | 560 . Source IP Address = Session-Reflector IPv6 Address . 561 . Destination IP Address . 562 . = Source IPv6 Address from Received Test Packet . 563 . Protocol = UDP . 564 . . 565 +---------------------------------------------------------------+ 566 | UDP Header | 567 . Source Port = As chosen by Session-Reflector . 568 . Destination Port = Source Port from Received Test Packet . 569 . . 570 +---------------------------------------------------------------+ 571 | Payload = Test Packet as specified in Section 4.3 of RFC 8762 | 572 . . 573 +---------------------------------------------------------------+ 575 Figure 7: Example Session-Reflector Test Packet for SRv6 Policy 577 4.2.3. Loopback Measurement Mode 579 The STAMP Session-Sender test packets are transmitted in loopback 580 mode to measure loopback delay of a bidirectional circular path. In 581 this mode, the received Session-Sender test packets are not punted 582 out of the fast path in forwarding (to slow path or control-plane) at 583 the STAMP Session-Reflector. In other words, the Session-Reflector 584 does not process them and generate reply test packets. 586 The IP header of the STAMP Session-Sender test packet contains the 587 Destination Address equals to the STAMP Session-Sender address and 588 the Source Address equals to the STAMP Session-Reflector address. 589 The Session-Sender sets the Reflector UDP port that it uses to 590 receive the test packet. Optionally, the STAMP Session-Sender test 591 packet can carry the return path information (e.g. return path label 592 stack for SR-MPLS) as part of the SR header. 594 The Session-Sender can use the SSID field in the reply test packet 595 and/ or local configuration to know that the test session is using 596 the loopback mode. As the reply test packet is not generated by the 597 STAMP Session-Reflector, the STAMP Session-Sender ignores the 598 'Session-Sender Sequence Number', 'Session-Sender Timestamp', 599 'Session-Sender Error Estimate', and 'Session-Sender TTL' in the 600 received test packet. The Session-Sender sets these fields to 0 upon 601 transmission. 603 In this mode, as per Reference Topology, the timestamps T1 and T4 are 604 collected by the test packets. Both these timestamps are used to 605 measure loopback delay as (T4 - T1). When STAMP capability on the 606 Session-Reflector node is not possible, the one-way delay can be 607 derived using loopback delay divided by two. In this mode, the 608 responder node processing time component reflects only the time 609 required to loop the test packet from the incoming interface to the 610 outgoing interface in forwarding plane. 612 4.3. Delay Measurement for P2MP SR Policies 614 The Point-to-Multipoint (P2MP) SR path that originates from a root 615 node terminates on multiple destinations called leaf nodes (e.g. 616 P2MP SR Policy [I-D.ietf-pim-sr-p2mp-policy]). 618 The procedures for delay and loss measurement described in this 619 document for end-to-end P2P SR Policies are also equally applicable 620 to the P2MP SR Policies. The procedure for one-way measurement is 621 defined as following: 623 o The STAMP Session-Sender root node transmits test packets using 624 the Tree-SID defined in [I-D.ietf-pim-sr-p2mp-policy] for the P2MP 625 SR-MPLS Policy as shown in Figure 8. The STAMP Session-Sender 626 test packets may contain the replication SID as defined in 627 [I-D.ietf-spring-sr-replication-segment]. 629 o The Destination Address is set to the loopback address from the 630 range 127/8 for IPv4, or the loopback address ::1/128 for IPv6. 632 o Each STAMP Session-Reflector leaf node transmits its node address 633 in the Source Address of the reply test packets shown in Figure 5. 635 This allows the STAMP Session-Sender root node to identify the 636 STAMP Session-Reflector leaf nodes of the P2MP SR Policy. 638 o The P2MP root node measures the delay for each P2MP leaf node 639 individually. 641 0 1 2 3 642 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 643 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 644 | Tree-SID | TC |S| TTL | 645 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 646 . . 647 . . 648 . . 649 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 650 | Test Packet as shown in Figure 2 | 651 . . 652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 654 Figure 8: Example Session-Sender Test Packet with Tree-SID for SR- 655 MPLS Policy 657 The considerations for two-way mode for P2MP SR Policy (e.g. for co- 658 routed bidirectional SR-MPLS path) are outside the scope of this 659 document. 661 4.4. Additional STAMP Test Packet Processing Rules 663 The processing rules described in this section are applicable to the 664 STAMP test packets for links and end-to-end SR paths including SR 665 Policies. 667 4.4.1. TTL 669 The TTL field in the IPv4 and MPLS headers of the STAMP Session- 670 Sender and STAMP Session-Reflector test packets is set to 255, except 671 in the following cases. 673 When using the Session-Reflector IPv4 Address from the range 127/8, 674 the TTL field in the IPv4 header is set to 1, for otherwise, 675 encapsulated packets. 677 For link delay, the TTL field in the STAMP test packet is set to 1 in 678 one-way and two-way delay measurement modes. 680 4.4.2. IPv6 Hop Limit 682 The Hop Limit field in the IPv6 and SRH headers of the STAMP Session- 683 Sender and STAMP Session-Reflector test packets is set to 255, except 684 in the following cases. 686 When using the Session-Reflector IPv6 Address of loopback address 687 ::1/128, the Hop Limit field in the IPv6 header is set to 1, for 688 otherwise, encapsulated packets. 690 For link delay, the Hop Limit field in the STAMP test packet is set 691 to 1 in one-way and two-way delay measurement modes. 693 4.4.3. Router Alert Option 695 The Router Alert IP option (RAO) [RFC2113] is not set in the STAMP 696 test packets for links and end-to-end SR paths. 698 4.4.4. UDP Checksum 700 For IPv4 test packets, where the hardware is not capable of re- 701 computing the UDP checksum or adding checksum complement [RFC7820], 702 the Session-Sender may set the UDP checksum value to 0 [RFC8085]. 704 For IPv6 test packets, where the hardware is not capable of re- 705 computing the UDP checksum or adding checksum complement [RFC7820], 706 the Session-Sender and Session-Reflector may use the procedure 707 defined in [RFC6936] for the UDP checksum. 709 5. Packet Loss Measurement for Links and SR Paths 711 The procedure described in Section 4 for delay measurement using 712 STAMP test packets can be used to detect (test) packet loss for links 713 and end-to-end SR paths. The Sequence Number field in the STAMP test 714 packet is used as described in Section 4 "Theory of Operation" where 715 Stateful and Stateless Session-Reflector operations are defined 716 [RFC8762], to detect round-trip, near-end (forward) and far-end 717 (backward) packet loss. 719 This method can be used for inferred packet loss measurement, 720 however, it does not provide accurate data packet loss metric. 722 6. Direct Measurement for Links and SR Paths 724 The STAMP "Direct Measurement" TLV (Type 5) defined in [RFC8972] can 725 be used in SR networks for data packet loss measurement. The STAMP 726 test packets with this TLV are transmitted using the procedures 727 described in Section 4 to collect the transmit and receive counters 728 of the data flow for the links and end-to-end SR paths. 730 The PSID carried in the received data packet for the traffic flow 731 under measurement can be used to measure receive data packets (for 732 receive traffic counter) for an end-to-end SR path on the STAMP 733 Session-Reflector. The PSID in the received Session-Sender test 734 packet header can be used to associate the receive traffic counter on 735 the Session-Reflector for the end-to-end SR path. 737 The STAMP "Direct Measurement" TLV (Type 5) lacks the support to 738 identify the Block Number of the Direct Measurement traffic counters, 739 which is required for Alternate-Marking Method [RFC8321] for accurate 740 data packet loss metric. 742 7. Session State for Links and SR Paths 744 The STAMP test session state allows to know if the performance 745 measurement test is active. The threshold-based notification may not 746 be generated if the delay values do not change significantly. For an 747 unambiguous monitoring, the controller needs to distinguish the cases 748 whether the performance measurement is active, or delay values are 749 not changing to cross threshold. 751 The STAMP test session state initially is declared active when one or 752 more reply test packets are received at the STAMP Session-Sender. 753 The STAMP test session state is declared idle (or failed) when 754 consecutive N number of reply test packets are not received at the 755 STAMP Session-Sender, where N is locally provisioned value. 757 8. ECMP Support for SR Policies 759 An SR Policy can have ECMPs between the source and transit nodes, 760 between transit nodes and between transit and destination nodes. 761 Usage of Anycast SID [RFC8402] by an SR Policy can result in ECMP 762 paths via transit nodes part of that Anycast group. The test packets 763 need to be transmitted to traverse different ECMP paths to measure 764 end-to-end delay of an SR Policy. 766 Forwarding plane has various hashing functions available to forward 767 packets on specific ECMP paths. The mechanisms described in 768 [RFC8029] and [RFC5884] for handling ECMPs are also applicable to the 769 delay measurement. 771 In IPv4 header of the STAMP Session-Sender test packets, sweeping of 772 Session-Reflector Address from the range 127/8 can be used to 773 exercise ECMP paths. In this case, both the forward and the return 774 paths must be SR-MPLS paths when using the loopback mode. 776 As specified in [RFC6437], Flow Label field in the outer IPv6 header 777 can also be used for sweeping to exercise different IPv6 ECMP paths. 779 The "Destination Node Address" TLV [I-D.gandhi-ippm-stamp-srpm] can 780 be carried in the STAMP Session-Sender test packet to identify the 781 intended Session-Reflector, for example, in case of using IPv4 782 Session-Reflector Address from 127/8 range when the STAMP test packet 783 is encapsulated by a tunneling protocol or an MPLS Segment list. The 784 STAMP Session-Reflector must not transmit reply test packet if it is 785 not the intended destination node in the "Destination Node Address" 786 TLV [I-D.gandhi-ippm-stamp-srpm]. 788 9. Security Considerations 790 The performance measurement is intended for deployment in well- 791 managed private and service provider networks. As such, it assumes 792 that a node involved in a measurement operation has previously 793 verified the integrity of the path and the identity of the far-end 794 STAMP Session-Reflector. 796 If desired, attacks can be mitigated by performing basic validation 797 and sanity checks, at the STAMP Session-Sender, of the counter or 798 timestamp fields in received measurement reply test packets. The 799 minimal state associated with these protocols also limits the extent 800 of measurement disruption that can be caused by a corrupt or invalid 801 packet to a single test cycle. 803 Use of HMAC-SHA-256 in the authenticated mode protects the data 804 integrity of the test packets. SRv6 has HMAC protection 805 authentication defined for SRH [RFC8754]. Hence, test packets for 806 SRv6 may not need authentication mode. Cryptographic measures may be 807 enhanced by the correct configuration of access-control lists and 808 firewalls. 810 The security considerations specified in [RFC8762] and [RFC8972] also 811 apply to the procedures described in this document. 813 When using the procedures defined in [RFC6936], the security 814 considerations specified in [RFC6936] also apply. 816 10. IANA Considerations 818 This document does not require any IANA action. 820 11. References 822 11.1. Normative References 824 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 825 DOI 10.17487/RFC0768, August 1980, 826 . 828 [RFC8762] Mirsky, G., Jun, G., Nydell, H., and R. Foote, "Simple 829 Two-Way Active Measurement Protocol", RFC 8762, 830 DOI 10.17487/RFC8762, March 2020, 831 . 833 [RFC8972] Mirsky, G., Min, X., Nydell, H., Foote, R., Masputra, A., 834 and E. Ruffini, "Simple Two-Way Active Measurement 835 Protocol Optional Extensions", RFC 8972, 836 DOI 10.17487/RFC8972, January 2021, 837 . 839 [I-D.gandhi-ippm-stamp-srpm] 840 Gandhi, R., Filsfils, C., Voyer, D., Chen, M., and B. 841 Janssens, "Simple TWAMP (STAMP) Extensions for Segment 842 Routing Networks", draft-gandhi-ippm-stamp-srpm-03 (work 843 in progress), April 2021. 845 11.2. Informative References 847 [IEEE1588] 848 IEEE, "1588-2008 IEEE Standard for a Precision Clock 849 Synchronization Protocol for Networked Measurement and 850 Control Systems", March 2008. 852 [RFC2113] Katz, D., "IP Router Alert Option", RFC 2113, 853 DOI 10.17487/RFC2113, February 1997, 854 . 856 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 857 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 858 2006, . 860 [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, 861 "Bidirectional Forwarding Detection (BFD) for MPLS Label 862 Switched Paths (LSPs)", RFC 5884, DOI 10.17487/RFC5884, 863 June 2010, . 865 [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, 866 "IPv6 Flow Label Specification", RFC 6437, 867 DOI 10.17487/RFC6437, November 2011, 868 . 870 [RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement 871 for the Use of IPv6 UDP Datagrams with Zero Checksums", 872 RFC 6936, DOI 10.17487/RFC6936, April 2013, 873 . 875 [RFC7404] Behringer, M. and E. Vyncke, "Using Only Link-Local 876 Addressing inside an IPv6 Network", RFC 7404, 877 DOI 10.17487/RFC7404, November 2014, 878 . 880 [RFC7820] Mizrahi, T., "UDP Checksum Complement in the One-Way 881 Active Measurement Protocol (OWAMP) and Two-Way Active 882 Measurement Protocol (TWAMP)", RFC 7820, 883 DOI 10.17487/RFC7820, March 2016, 884 . 886 [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., 887 Aldrin, S., and M. Chen, "Detecting Multiprotocol Label 888 Switched (MPLS) Data-Plane Failures", RFC 8029, 889 DOI 10.17487/RFC8029, March 2017, 890 . 892 [RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli, 893 L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, 894 "Alternate-Marking Method for Passive and Hybrid 895 Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321, 896 January 2018, . 898 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 899 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 900 March 2017, . 902 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 903 Decraene, B., Litkowski, S., and R. Shakir, "Segment 904 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 905 July 2018, . 907 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 908 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 909 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 910 . 912 [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, 913 D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 914 (SRv6) Network Programming", RFC 8986, 915 DOI 10.17487/RFC8986, February 2021, 916 . 918 [I-D.ietf-spring-segment-routing-policy] 919 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 920 P. Mattes, "Segment Routing Policy Architecture", draft- 921 ietf-spring-segment-routing-policy-09 (work in progress), 922 November 2020. 924 [I-D.ietf-spring-sr-replication-segment] 925 Voyer, D., Filsfils, C., Parekh, R., Bidgoli, H., and Z. 926 Zhang, "SR Replication Segment for Multi-point Service 927 Delivery", draft-ietf-spring-sr-replication-segment-04 928 (work in progress), February 2021. 930 [I-D.ietf-pim-sr-p2mp-policy] 931 Voyer, D., Filsfils, C., Parekh, R., Bidgoli, H., and Z. 932 Zhang, "Segment Routing Point-to-Multipoint Policy", 933 draft-ietf-pim-sr-p2mp-policy-02 (work in progress), 934 February 2021. 936 [I-D.ietf-spring-mpls-path-segment] 937 Cheng, W., Li, H., Chen, M., Gandhi, R., and R. Zigler, 938 "Path Segment in MPLS Based Segment Routing Network", 939 draft-ietf-spring-mpls-path-segment-04 (work in progress), 940 April 2021. 942 [I-D.ietf-spring-srv6-path-segment] 943 Li, C., Cheng, W., Chen, M., Dhody, D., and R. Gandhi, 944 "Path Segment for SRv6 (Segment Routing in IPv6)", draft- 945 ietf-spring-srv6-path-segment-00 (work in progress), 946 November 2020. 948 [I-D.ietf-pce-sr-bidir-path] 949 Li, C., Chen, M., Cheng, W., Gandhi, R., and Q. Xiong, 950 "Path Computation Element Communication Protocol (PCEP) 951 Extensions for Associated Bidirectional Segment Routing 952 (SR) Paths", draft-ietf-pce-sr-bidir-path-05 (work in 953 progress), January 2021. 955 [I-D.ietf-ippm-stamp-yang] 956 Mirsky, G., Min, X., and W. Luo, "Simple Two-way Active 957 Measurement Protocol (STAMP) Data Model", draft-ietf-ippm- 958 stamp-yang-07 (work in progress), March 2021. 960 [IEEE802.1AX] 961 IEEE Std. 802.1AX, "IEEE Standard for Local and 962 metropolitan area networks - Link Aggregation", November 963 2008. 965 Acknowledgments 967 The authors would like to thank Thierry Couture for the discussions 968 on the use-cases for Performance Measurement in segment routing. The 969 authors would also like to thank Greg Mirsky, Gyan Mishra, Xie 970 Jingrong, and Mike Koldychev for reviewing this document and 971 providing useful comments and suggestions. Patrick Khordoc and Radu 972 Valceanu have helped improve the mechanisms described in this 973 document. 975 Authors' Addresses 977 Rakesh Gandhi (editor) 978 Cisco Systems, Inc. 979 Canada 981 Email: rgandhi@cisco.com 983 Clarence Filsfils 984 Cisco Systems, Inc. 986 Email: cfilsfil@cisco.com 988 Daniel Voyer 989 Bell Canada 991 Email: daniel.voyer@bell.ca 993 Mach(Guoyi) Chen 994 Huawei 996 Email: mach.chen@huawei.com 998 Bart Janssens 999 Colt 1001 Email: Bart.Janssens@colt.net 1002 Richard Foote 1003 Nokia 1005 Email: footer.foote@nokia.com