idnits 2.17.1 draft-gandhi-spring-stamp-srpm-07.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 (July 06, 2021) is 996 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 (-18) exists of draft-ietf-ippm-stamp-srpm-00 -- 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-11 == 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 (~~), 9 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SPRING Working Group R. Gandhi, Ed. 3 Internet-Draft C. Filsfils 4 Intended status: Standards Track Cisco Systems, Inc. 5 Expires: January 7, 2022 D. Voyer 6 Bell Canada 7 M. Chen 8 Huawei 9 B. Janssens 10 Colt 11 R. Foote 12 Nokia 13 July 06, 2021 15 Performance Measurement Using Simple TWAMP (STAMP) for Segment Routing 16 Networks 17 draft-gandhi-spring-stamp-srpm-07 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-ietf-ippm-stamp-srpm. The procedure described is applicable to 28 SR-MPLS and SRv6 data planes and is used for both links and end-to- 29 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 January 7, 2022. 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. Requirements Language . . . . . . . . . . . . . . . . . . 3 68 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3 69 2.3. Reference Topology . . . . . . . . . . . . . . . . . . . 4 70 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 71 3.1. Example STAMP Reference Model . . . . . . . . . . . . . . 6 72 4. Delay Measurement for Links and SR Paths . . . . . . . . . . 7 73 4.1. Session-Sender Test Packet . . . . . . . . . . . . . . . 7 74 4.1.1. Session-Sender Test Packet for Links . . . . . . . . 8 75 4.1.2. Session-Sender Test Packet for SR Paths . . . . . . . 8 76 4.2. Session-Reflector Test Packet . . . . . . . . . . . . . . 10 77 4.2.1. One-way Measurement Mode . . . . . . . . . . . . . . 11 78 4.2.2. Two-way Measurement Mode . . . . . . . . . . . . . . 11 79 4.2.3. Loopback Measurement Mode . . . . . . . . . . . . . . 13 80 4.3. Delay Measurement for P2MP SR Policies . . . . . . . . . 14 81 4.4. Additional STAMP Test Packet Processing Rules . . . . . . 15 82 4.4.1. TTL . . . . . . . . . . . . . . . . . . . . . . . . . 16 83 4.4.2. IPv6 Hop Limit . . . . . . . . . . . . . . . . . . . 16 84 4.4.3. Router Alert Option . . . . . . . . . . . . . . . . . 16 85 4.4.4. UDP Checksum . . . . . . . . . . . . . . . . . . . . 16 86 5. Packet Loss Measurement for Links and SR Paths . . . . . . . 16 87 6. Direct Measurement for Links and SR Paths . . . . . . . . . . 16 88 7. Session State for Links and SR Paths . . . . . . . . . . . . 17 89 8. ECMP Support for SR Policies . . . . . . . . . . . . . . . . 17 90 9. Security Considerations . . . . . . . . . . . . . . . . . . . 18 91 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 92 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 93 11.1. Normative References . . . . . . . . . . . . . . . . . . 19 94 11.2. Informative References . . . . . . . . . . . . . . . . . 19 95 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 22 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 98 1. Introduction 100 Segment Routing (SR) leverages the source routing paradigm and 101 greatly simplifies network operations for Software Defined Networks 102 (SDNs). SR is applicable to both Multiprotocol Label Switching (SR- 103 MPLS) and IPv6 (SRv6) data planes [RFC8402]. SR takes advantage of 104 the Equal-Cost Multipaths (ECMPs) between source and transit nodes, 105 between transit nodes and between transit and destination nodes. SR 106 Policies as defined in [I-D.ietf-spring-segment-routing-policy] are 107 used to steer traffic through a specific, user-defined paths using a 108 stack of Segments. Built-in SR Performance Measurement (PM) is one 109 of the essential requirements to provide Service Level Agreements 110 (SLAs). 112 The Simple Two-way Active Measurement Protocol (STAMP) provides 113 capabilities for the measurement of various performance metrics in IP 114 networks [RFC8762] without the use of a control channel to pre-signal 115 session parameters. [RFC8972] defines optional extensions for STAMP. 116 [I-D.ietf-ippm-stamp-srpm] augments that framework to define STAMP 117 extensions for SR networks. 119 This document describes procedures for Performance Measurement in SR 120 networks using the mechanisms defined in STAMP [RFC8762] and its 121 optional extensions defined in [RFC8972] and further augmented in 122 [I-D.ietf-ippm-stamp-srpm]. The procedure described is applicable to 123 SR-MPLS and SRv6 data planes and is used for both links and end-to- 124 end SR paths including SR Policies [RFC8402]. 126 2. Conventions Used in This Document 128 2.1. Requirements Language 130 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 131 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 132 document are to be interpreted as described in [RFC2119] [RFC8174] 133 when, and only when, they appear in all capitals, as shown here. 135 2.2. Abbreviations 137 BSID: Binding Segment ID. 139 DM: Delay Measurement. 141 ECMP: Equal Cost Multi-Path. 143 HL: Hop Limit. 145 HMAC: Hashed Message Authentication Code. 147 LM: Loss Measurement. 149 MPLS: Multiprotocol Label Switching. 151 NTP: Network Time Protocol. 153 OWAMP: One-Way Active Measurement Protocol. 155 PM: Performance Measurement. 157 PSID: Path Segment Identifier. 159 PTP: Precision Time Protocol. 161 SHA: Secure Hash Algorithm. 163 SID: Segment ID. 165 SL: Segment List. 167 SR: Segment Routing. 169 SRH: Segment Routing Header. 171 SR-MPLS: Segment Routing with MPLS data plane. 173 SRv6: Segment Routing with IPv6 data plane. 175 SSID: STAMP Session Identifier. 177 STAMP: Simple Two-way Active Measurement Protocol. 179 TC: Traffic Class. 181 TTL: Time To Live. 183 2.3. Reference Topology 185 In the Reference Topology shown below, the STAMP Session-Sender R1 186 initiates a STAMP test packet and the STAMP Session-Reflector R3 187 transmits a reply test packet. The reply test packet may be 188 transmitted to the STAMP Session-Sender R1 on the same path (same set 189 of links and nodes) or a different path in the reverse direction from 190 the path taken towards the Session-Reflector. 192 The nodes R1 and R3 may be connected via a link or an SR path 193 [RFC8402]. The link may be a physical interface, virtual link, or 194 Link Aggregation Group (LAG) [IEEE802.1AX], or LAG member link. The 195 SR path may be an SR Policy [I-D.ietf-spring-segment-routing-policy] 196 on node R1 (called head-end) with destination to node R3 (called 197 tail-end). 199 T1 T2 200 / \ 201 +-------+ Test Packet +-------+ 202 | | - - - - - - - - - ->| | 203 | R1 |=====================| R3 | 204 | |<- - - - - - - - - - | | 205 +-------+ Reply Test Packet +-------+ 206 \ / 207 T4 T3 209 STAMP Session-Sender STAMP Session-Reflector 211 Reference Topology 213 3. Overview 215 For performance measurement in SR networks, the STAMP Session-Sender 216 and Session-Reflector test packets defined in [RFC8762] are used. 217 The STAMP test packets require to be encapsulated to be transmitted 218 on a desired path under measurement. The base STAMP test packets can 219 be encapsulated using IP/UDP header and may use Destination UDP port 220 862 [RFC8762]. In this document, the STAMP packets using IP/UDP 221 header are considered for SR networks. 223 The STAMP test packets are used in one-way, two-way (i.e. round-trip) 224 and loopback measurement modes. Note that one-way and round-trip are 225 referred to in [RFC8762] and are further described in this document 226 because of the introduction of loopback measurement mode in SR 227 networks. The procedures defined in this document are also used to 228 infer packet loss in SR networks. 230 The STAMP test packets are transmitted on the same path as the data 231 traffic flow under measurement to measure the delay and packet loss 232 experienced by the data traffic flow. 234 Typically, the STAMP test packets are transmitted along an IP path 235 between a Session-Sender and a Session-Reflector to measure delay and 236 packet loss along that IP path. Matching the forward and reverse 237 direction paths for STAMP test packets, even for directly connected 238 nodes is not guaranteed. 240 It may be desired in SR networks that the same path (same set of 241 links and nodes) between the Session-Sender and Session-Reflector be 242 used for the STAMP test packets in both directions. This is achieved 243 by using the optional STAMP extensions for SR-MPLS and SRv6 networks 244 specified in [I-D.ietf-ippm-stamp-srpm]. The STAMP Session-Reflector 245 uses the return path parameters for the reply test packet from the 246 received STAMP test packet, as described in 247 [I-D.ietf-ippm-stamp-srpm]. This way signaling and maintaining 248 dynamic SR network state for the STAMP sessions on the Session- 249 Reflector are avoided. 251 The optional STAMP extensions defined in [RFC8972] are used for 252 direct measurement packet loss in SR networks. 254 3.1. Example STAMP Reference Model 256 An example of a STAMP reference model with some of the typical 257 measurement parameters including the Destination UDP port for STAMP 258 test session is shown in the following Figure 1: 260 +------------+ 261 | Controller | 262 +------------+ 263 / \ 264 Destination UDP Port / \ Destination UDP Port 265 Authentication Mode / \ Authentication Mode 266 Key-chain / \ Key-chain 267 Timestamp Format / \ Timestamp Format 268 Packet Loss Type / \ Session-Reflector Mode 269 Delay Measurement Mode / \ 270 v v 271 +-------+ +-------+ 272 | | | | 273 | R1 |==========| R3 | 274 | | | | 275 +-------+ +-------+ 277 STAMP Session-Sender STAMP Session-Reflector 279 Figure 1: Example STAMP Reference Model 281 A Destination UDP port number is selected as described in [RFC8762]. 282 The same Destination UDP port can be used for STAMP test sessions for 283 link and end-to-end SR paths. In this case, the Destination UDP port 284 does not distinguish between link or end-to-end SR path measurements. 286 Example of the Timestamp Format is Precision Time Protocol 64-bit 287 truncated (PTPv2) [IEEE1588] and Network Time Protocol (NTP). By 288 default, the Session-Reflector replies in kind to the timestamp 289 format received in the received Session-Sender test packet, as 290 indicated by the "Z" field in the Error Estimate field as described 291 in [RFC8762]. 293 The Session-Reflector mode can be Stateful or Stateless as defined in 294 [RFC8762]. 296 Example of Delay Measurement Mode is one-way, two-way (i.e. round- 297 trip) and loopback mode as described in this document. 299 Example of Packet Loss Type can be round-trip, near-end (forward) and 300 far-end (backward) packet loss as defined in [RFC8762]. 302 When using the authenticated mode for the STAMP test sessions, the 303 matching Authentication Type (e.g. HMAC-SHA-256) and Key-chain are 304 user-configured on STAMP Session-Sender and STAMP Session-Reflector 305 [RFC8762]. 307 The controller shown in the example reference model is not intended 308 for the dynamic signaling of the SR parameters for STAMP test 309 sessions between the STAMP Session-Sender and STAMP Session- 310 Reflector. 312 Note that the YANG data model defined in [I-D.ietf-ippm-stamp-yang] 313 can be used to provision the STAMP Session-Sender and STAMP Session- 314 Reflector. 316 4. Delay Measurement for Links and SR Paths 318 4.1. Session-Sender Test Packet 320 The content of an example STAMP Session-Sender test packet using an 321 UDP header [RFC0768] is shown in Figure 2. The payload contains the 322 STAMP Session-Sender test packet defined in [RFC8762]. 324 +---------------------------------------------------------------+ 325 | IP Header | 326 . Source IP Address = Session-Sender IPv4 or IPv6 Address . 327 . Destination IP Address=Session-Reflector IPv4 or IPv6 Address. 328 . Protocol = UDP . 329 . . 330 +---------------------------------------------------------------+ 331 | UDP Header | 332 . Source Port = As chosen by Session-Sender . 333 . Destination Port = User-configured Destination Port | 862 . 334 . . 335 +---------------------------------------------------------------+ 336 | Payload = Test Packet as specified in Section 3 of RFC 8972 | 337 . in Figure 1 and Figure 3 . 338 . . 339 +---------------------------------------------------------------+ 341 Figure 2: Example Session-Sender Test Packet 343 4.1.1. Session-Sender Test Packet for Links 345 The STAMP Session-Sender test packet as shown in Figure 2 is 346 transmitted over the link under delay measurement. The local and 347 remote IP addresses of the link are used as Source and Destination 348 Addresses, respectively. For IPv6 links, the link local addresses 349 [RFC7404] can be used in the IPv6 header. The Session-Sender may use 350 the local Address Resolution Protocol (ARP) table, Neighbor 351 Solicitation or other bootstrap method to find the IP address for the 352 links and refresh. SR encapsulation (e.g. adjacency SID of the link) 353 can be added for transmitting the STAMP test packets for links. 355 4.1.2. Session-Sender Test Packet for SR Paths 357 The delay measurement for end-to-end SR path in an SR network is 358 applicable to both end-to-end SR-MPLS and SRv6 paths including SR 359 Policies. 361 The STAMP Session-Sender (the head-end of the SR Policy) IPv4 or IPv6 362 address MUST be used as the Source Address in the IP header of the 363 test packet. The STAMP Session-Reflector (the SR Policy endpoint) 364 IPv4 or IPv6 address MUST be used as the Destination Address in the 365 IP header of the test packet. 367 In the case of Color-Only Destination Steering, with IPv4 endpoint of 368 0.0.0.0 or IPv6 endpoint of ::0 369 [I-D.ietf-spring-segment-routing-policy], the loopback address from 370 the range 127/8 for IPv4, or the loopback address ::1/128 for IPv6 371 [RFC4291] is used as the Session-Reflector Address, respectively. 373 4.1.2.1. Session-Sender Test Packet for SR-MPLS Policies 375 An SR-MPLS Policy may contain a number of Segment Lists (SLs). A 376 STAMP Session-Sender test packet MUST be transmitted for each Segment 377 List of the SR-MPLS Policy. The content of an example STAMP Session- 378 Sender test packet for an end-to-end SR-MPLS Policy is shown in 379 Figure 3. 381 0 1 2 3 382 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 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 | Segment(1) | TC |S| TTL | 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 . . 387 . . 388 . . 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 | Segment(n) | TC |S| TTL | 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 | PSID | TC |S| TTL | 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 | Test Packet as shown in Figure 2 | 395 . . 396 +---------------------------------------------------------------+ 398 Figure 3: Example Session-Sender Test Packet for SR-MPLS Policy 400 The Segment List can be empty in case of a single-hop SR-MPLS Policy 401 with Implicit NULL label. 403 The Path Segment Identifier (PSID) 404 [I-D.ietf-spring-mpls-path-segment] of an SR-MPLS Policy can be 405 carried in the MPLS header as shown in Figure 3, and can be used for 406 direct measurement as described in Section 6, titled "Direct 407 Measurement for Links and SR Paths". 409 4.1.2.2. Session-Sender Test Packet for SRv6 Policies 411 An SRv6 Policy may contain a number of Segment Lists. A STAMP 412 Session-Sender test packet MUST be transmitted for each Segment List 413 of the SRv6 Policy. An SRv6 Policy can contain an SRv6 Segment 414 Routing Header (SRH) carrying a Segment List as described in 415 [RFC8754]. The content of an example STAMP Session-Sender test 416 packet for an end-to-end SRv6 Policy is shown in Figure 4. 418 The SRv6 network programming is described in [RFC8986]. The 419 procedure defined for Upper-Layer Header processing for SRv6 End SIDs 420 in Section 4.1.1 in [RFC8986] is used to process the IPv6/UDP header 421 in the received test packets on the Session-Reflector. 423 +---------------------------------------------------------------+ 424 | IP Header | 425 . Source IP Address = Session-Sender IPv6 Address . 426 . Destination IP Address = Destination IPv6 Address . 427 . Protocol = UDP . 428 . . 429 +---------------------------------------------------------------+ 430 | SRH as specified in RFC 8754 | 431 . . 432 . . 433 +---------------------------------------------------------------+ 434 | UDP Header | 435 . Source Port = As chosen by Session-Sender . 436 . Destination Port = User-configured Destination Port | 862 . 437 . . 438 +---------------------------------------------------------------+ 439 | Payload = Test Packet as specified in Section 3 of RFC 8972 | 440 . in Figure 1 and Figure 3 . 441 . . 442 +---------------------------------------------------------------+ 444 Figure 4: Example Session-Sender Test Packet for SRv6 Policy 446 The Segment List (SL) may be empty and no SRH may be carried. 448 The Path Segment Identifier (PSID) 449 [I-D.ietf-spring-srv6-path-segment] of the SRV6 Policy can be carried 450 in the SRH as shown in Figure 4 and can be used for direct 451 measurement as described in Section 6, titled "Direct Measurement for 452 Links and SR Paths". 454 4.2. Session-Reflector Test Packet 456 The STAMP Session-Reflector reply test packet uses the IP/UDP 457 information from the received test packet as shown in Figure 5. 459 +---------------------------------------------------------------+ 460 | IP Header | 461 . Source IP Address = Session-Reflector IPv4 or IPv6 Address . 462 . Destination IP Address . 463 . = Source IP Address from Received Test Packet . 464 . Protocol = UDP . 465 . . 466 +---------------------------------------------------------------+ 467 | UDP Header | 468 . Source Port = As chosen by Session-Reflector . 469 . Destination Port = Source Port from Received Test Packet . 470 . . 471 +---------------------------------------------------------------+ 472 | Payload = Test Packet as specified in Section 3 of RFC 8972 | 473 . in Figure 2 and Figure 4 . 474 . . 475 +---------------------------------------------------------------+ 477 Figure 5: Example Session-Reflector Test Packet 479 4.2.1. One-way Measurement Mode 481 In one-way delay measurement mode, a reply test packet as shown in 482 Figure 5 is transmitted by the STAMP Session-Reflector, for both 483 links and end-to-end SR Policies. The reply test packet may be 484 transmitted on the same path or a different path in the reverse 485 direction. 487 The STAMP Session-Sender address may not be reachable via IP route 488 from the STAMP Session-Reflector. The STAMP Session-Sender in this 489 case MUST send its reachability path information to the STAMP 490 Session-Reflector using the Return Path TLV defined in 491 [I-D.ietf-ippm-stamp-srpm]. 493 In this mode, as per Reference Topology, all timestamps T1, T2, T3, 494 and T4 are collected by the test packets. However, only timestamps 495 T1 and T2 are used to measure one-way delay as (T2 - T1). The one- 496 way delay measurement mode requires the clock on the Session-Sender 497 and Session-Reflector to be synchronized. 499 4.2.2. Two-way Measurement Mode 501 In two-way (i.e. round-trip) delay measurement mode, a reply test 502 packet as shown in Figure 5 is transmitted by the STAMP Session- 503 Reflector on the same path in the reverse direction, e.g. on the 504 reverse direction link or associated reverse SR path 505 [I-D.ietf-pce-sr-bidir-path]. 507 For two-way delay measurement mode for links, the STAMP Session- 508 Reflector transmits the reply test packet on the same link where the 509 test packet is received. The STAMP Session-Sender can request in the 510 test packet to the STAMP Session-Reflector to transmit the reply test 511 packet back on the same link using the Control Code Sub-TLV in the 512 Return Path TLV defined in [I-D.ietf-ippm-stamp-srpm]. 514 For two-way delay measurement mode for end-to-end SR paths, the STAMP 515 Session-Reflector transmits the reply test packet on a specific 516 reverse path. The STAMP Session-Sender can request in the test 517 packet to the STAMP Session-Reflector to transmit the reply test 518 packet back on a given reverse path using a Segment List sub-TLV in 519 the Return Path TLV defined in [I-D.ietf-ippm-stamp-srpm]. 521 In this mode, as per Reference Topology, all timestamps T1, T2, T3, 522 and T4 are collected by the test packets. All four timestamps are 523 used to measure two-way delay as ((T4 - T1) - (T3 - T2)). When clock 524 synchronization on the Session-Sender and Session-Reflector nodes is 525 not possible, the one-way delay can be derived using two-way delay 526 divided by two. 528 4.2.2.1. Session-Reflector Test Packet for SR-MPLS Policies 530 The content of an example STAMP Session-Reflector reply test packet 531 transmitted on the same path as the data traffic flow under 532 measurement for two-way delay measurement of an end-to-end SR-MPLS 533 Policy is shown in Figure 6. 535 0 1 2 3 536 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 537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 538 | Segment(1) | TC |S| TTL | 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 540 . . 541 . . 542 . . 543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 544 | Segment(n) | TC |S| TTL | 545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 546 | Test Packet as shown in Figure 5 | 547 . . 548 +---------------------------------------------------------------+ 550 Figure 6: Example Session-Reflector Test Packet for SR-MPLS Policy 552 4.2.2.2. Session-Reflector Test Packet for SRv6 Policies 554 The content of an example STAMP Session-Reflector reply test packet 555 transmitted on the same path as the data traffic flow under 556 measurement for two-way delay measurement of an end-to-end SRv6 557 Policy with SRH is shown in Figure 7. 559 The procedure defined for Upper-Layer Header processing for SRv6 End 560 SIDs in Section 4.1.1 in [RFC8986] is used to process the IPv6/UDP 561 header in the received reply test packets on the Session-Sender. 563 +---------------------------------------------------------------+ 564 | IP Header | 565 . Source IP Address = Session-Reflector IPv6 Address . 566 . Destination IP Address = Destination IPv6 Address . 567 . Protocol = UDP . 568 . . 569 +---------------------------------------------------------------+ 570 | SRH as specified in RFC 8754 | 571 . . 572 . . 573 +---------------------------------------------------------------+ 574 | UDP Header | 575 . Source Port = As chosen by Session-Reflector . 576 . Destination Port = Source Port from Received Test Packet . 577 . . 578 +---------------------------------------------------------------+ 579 | Payload = Test Packet as specified in Section 3 of RFC 8972 | 580 . in Figure 2 and Figure 4 . 581 . . 582 +---------------------------------------------------------------+ 584 Figure 7: Example Session-Reflector Test Packet for SRv6 Policy 586 4.2.3. Loopback Measurement Mode 588 The STAMP Session-Sender test packets are transmitted in loopback 589 mode to measure loopback delay of a bidirectional circular path. In 590 this mode, the received Session-Sender test packets are not punted 591 out of the fast path in forwarding (i.e. to slow path or control- 592 plane) at the STAMP Session-Reflector. In other words, the Session- 593 Reflector does not process them and generate Session-Reflector test 594 packets. This is a new measurement mode, not defined by STAMP 595 process [RFC8762]. 597 The STAMP Session-Sender MUST set the Destination UDP port to the UDP 598 port it uses to receive the reply STAMP test packets. Since the 599 Session-Reflector does not support the STAMP process, the loopback 600 function simply makes the necessary changes to the encapsulation 601 including IP and UDP headers to return the test packet to the 602 Session-Sender. The typical Session-Reflector test packet is not 603 used in this mode. The loopback function simply returns the received 604 Session-Sender test packet to the Session-Sender without STAMP 605 modifications defined in [RFC8762]. 607 In case of SR-MPLS paths, the SR-MPLS header can contain the MPLS 608 label stack of the forward path or both forward and the reverse 609 paths. The IP header of the STAMP Session-Sender test packets MUST 610 set the Destination Address equal to the STAMP Session-Sender address 611 and the Source Address equal to the STAMP Session-Reflector address. 613 In case of SRv6 paths, the SRH can contain the Segment List of the 614 forward path or both forward and the reverse paths. In the former 615 case, an inner IPv6 header (after SRH and before UDP header) MUST be 616 added that contains the Destination Address equal to the STAMP 617 Session-Sender address and the Source Address equal to the STAMP 618 Session-Reflector address. 620 The Session-Sender may use the SSID field in the received reply test 621 packet or local configuration to identify its test session using the 622 loopback mode. In the received Session-Sender test packet at the 623 Session-Sender, the 'Session-Sender Sequence Number', 'Session-Sender 624 Timestamp', 'Session-Sender Error Estimate', and 'Session-Sender TTL' 625 fields are not present in this mode. 627 In this mode, as per Reference Topology, the test packet received 628 back at the Session-Sender retrieves the timestamp T1 from the test 629 packet and adds the received timestamp T4 locally. Both these 630 timestamps are used to measure the loopback delay as (T4 - T1). The 631 one-way delay can be derived using the loopback delay divided by two. 632 In loopback mode, the loopback delay includes the processing delay on 633 the Session-Reflector. The Session-Reflector processing delay 634 component includes only the time required to loop the test packet 635 from the incoming interface to the outgoing interface in forwarding 636 plane. 638 4.3. Delay Measurement for P2MP SR Policies 640 The Point-to-Multipoint (P2MP) SR path that originates from a root 641 node terminates on multiple destinations called leaf nodes (e.g. 642 P2MP SR Policy [I-D.ietf-pim-sr-p2mp-policy]). 644 The procedures for delay and loss measurement described in this 645 document for end-to-end P2P SR Policies are also equally applicable 646 to the P2MP SR Policies. The procedure for one-way measurement is 647 defined as following: 649 o The STAMP Session-Sender root node transmits test packets using 650 the Tree-SID defined in [I-D.ietf-pim-sr-p2mp-policy] for the P2MP 651 SR-MPLS Policy as shown in Figure 8. The STAMP Session-Sender 652 test packets may contain the replication SID as defined in 653 [I-D.ietf-spring-sr-replication-segment]. 655 o The Destination Address MUST be set to the loopback address from 656 the range 127/8 for IPv4, or the loopback address ::1/128 for 657 IPv6. 659 o Each STAMP Session-Reflector leaf node MUST transmit its node 660 address in the Source Address of the reply test packets shown in 661 Figure 5. This allows the STAMP Session-Sender root node to 662 identify the STAMP Session-Reflector leaf nodes of the P2MP SR 663 Policy. 665 o The P2MP root node measures the delay for each P2MP leaf node 666 individually. 668 0 1 2 3 669 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 670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 671 | Tree-SID | TC |S| TTL | 672 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 673 . . 674 . . 675 . . 676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 677 | Test Packet as shown in Figure 2 | 678 . . 679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 681 Figure 8: Example Session-Sender Test Packet with Tree-SID for SR- 682 MPLS Policy 684 The considerations for two-way mode for P2MP SR Policy (e.g. for co- 685 routed bidirectional SR-MPLS path) are outside the scope of this 686 document. 688 4.4. Additional STAMP Test Packet Processing Rules 690 The processing rules described in this section are applicable to the 691 STAMP test packets for links and end-to-end SR paths including SR 692 Policies. 694 4.4.1. TTL 696 The TTL field in the IPv4 and MPLS headers of the STAMP Session- 697 Sender and STAMP Session-Reflector test packet is set to 255 as per 698 Generalized TTL Security Mechanism (GTSM) [RFC5082]. 700 4.4.2. IPv6 Hop Limit 702 The Hop Limit (HL) field in the IPv6 and SRH headers of the STAMP 703 Session-Sender and STAMP Session-Reflector test packet is set to 255 704 as per Generalized TTL Security Mechanism (GTSM) [RFC5082]. 706 4.4.3. Router Alert Option 708 The Router Alert IP option (RAO) [RFC2113] is not set in the STAMP 709 test packets for links and end-to-end SR paths. 711 4.4.4. UDP Checksum 713 For IPv4 test packets, where the hardware is not capable of re- 714 computing the UDP checksum or adding checksum complement [RFC7820], 715 the Session-Sender may set the UDP checksum value to 0 [RFC8085]. 717 For IPv6 test packets, where the hardware is not capable of re- 718 computing the UDP checksum or adding checksum complement [RFC7820], 719 the Session-Sender and Session-Reflector may use the procedure 720 defined in [RFC6936] for the UDP checksum. 722 5. Packet Loss Measurement for Links and SR Paths 724 The procedure described in Section 4 for delay measurement using 725 STAMP test packets can be used to detect (test) packet loss for links 726 and end-to-end SR paths. The Sequence Number field in the STAMP test 727 packet is used as described in Section 4 "Theory of Operation" where 728 Stateful and Stateless Session-Reflector operations are defined 729 [RFC8762], to detect round-trip, near-end (forward) and far-end 730 (backward) packet loss. In the case of the loopback mode introduced 731 in this document, only the round-trip packet loss is applicable. 733 This method can be used for inferred packet loss measurement, 734 however, it provides only approximate view of the data packet loss. 736 6. Direct Measurement for Links and SR Paths 738 The STAMP "Direct Measurement" TLV (Type 5) defined in [RFC8972] can 739 be used in SR networks for data packet loss measurement. The STAMP 740 test packets with this TLV are transmitted using the procedures 741 described in Section 4 to collect the transmit and receive counters 742 of the data flow for the links and end-to-end SR paths. 744 The PSID carried in the received data packet for the traffic flow 745 under measurement can be used to measure receive data packets (for 746 receive traffic counter) for an end-to-end SR path on the STAMP 747 Session-Reflector. The PSID in the received Session-Sender test 748 packet header can be used to associate the receive traffic counter on 749 the Session-Reflector for the end-to-end SR path. 751 The STAMP "Direct Measurement" TLV (Type 5) lacks the support to 752 identify the Block Number of the Direct Measurement traffic counters, 753 which is required for Alternate-Marking Method [RFC8321] for accurate 754 data packet loss metric. 756 7. Session State for Links and SR Paths 758 The STAMP test session state allows to know if the performance 759 measurement test is active. The threshold-based notification may not 760 be generated if the delay values do not change significantly. For an 761 unambiguous monitoring, the controller needs to distinguish the cases 762 whether the performance measurement is active, or delay values are 763 not changing to cross threshold. 765 The STAMP test session state initially is declared active when one or 766 more reply test packets are received at the STAMP Session-Sender. 767 The STAMP test session state is declared idle (or failed) when 768 consecutive N number of reply test packets are not received at the 769 STAMP Session-Sender, where N is locally provisioned value. 771 8. ECMP Support for SR Policies 773 An SR Policy can have ECMPs between the source and transit nodes, 774 between transit nodes and between transit and destination nodes. 775 Usage of Anycast SID [RFC8402] by an SR Policy can result in ECMP 776 paths via transit nodes part of that Anycast group. The test packets 777 SHOULD be transmitted to traverse different ECMP paths to measure 778 end-to-end delay of an SR Policy. 780 Forwarding plane has various hashing functions available to forward 781 packets on specific ECMP paths. The mechanisms described in 782 [RFC8029] and [RFC5884] for handling ECMPs are also applicable to the 783 delay measurement. 785 For SR-MPLS Policy, sweeping of MPLS entropy label [RFC6790] values 786 can be used in Session-Sender test packets and Session-Reflector test 787 packets to take advantage of the hashing function in forwarding plane 788 to influence the ECMP path taken by them. 790 In IPv4 header of the STAMP Session-Sender test packets, sweeping of 791 Session-Reflector Address from the range 127/8 can be used to 792 exercise ECMP paths. In this case, both the forward and the return 793 paths MUST be SR-MPLS paths when using the loopback mode. 795 As specified in [RFC6437], Flow Label field in the outer IPv6 header 796 can also be used for sweeping to exercise different IPv6 ECMP paths. 798 The "Destination Node Address" TLV [I-D.ietf-ippm-stamp-srpm] MUST be 799 carried in the STAMP Session-Sender test packet to identify the 800 intended Session-Reflector, when using IPv4 Session-Reflector Address 801 from 127/8 range for a P2P SR Policy, when the STAMP test packet is 802 encapsulated by a tunneling protocol or an MPLS Segment List. 804 9. Security Considerations 806 The performance measurement is intended for deployment in well- 807 managed private and service provider networks. As such, it assumes 808 that a node involved in a measurement operation has previously 809 verified the integrity of the path and the identity of the far-end 810 STAMP Session-Reflector. 812 If desired, attacks can be mitigated by performing basic validation 813 and sanity checks, at the STAMP Session-Sender, of the counter or 814 timestamp fields in received measurement reply test packets. The 815 minimal state associated with these protocols also limits the extent 816 of measurement disruption that can be caused by a corrupt or invalid 817 packet to a single test cycle. 819 Use of HMAC-SHA-256 in the authenticated mode protects the data 820 integrity of the test packets. SRv6 has HMAC protection 821 authentication defined for SRH [RFC8754]. Hence, test packets for 822 SRv6 may not need authentication mode. Cryptographic measures may be 823 enhanced by the correct configuration of access-control lists and 824 firewalls. 826 The security considerations specified in [RFC8762] and [RFC8972] also 827 apply to the procedures described in this document. 829 The Security Considerations specified in [I-D.ietf-ippm-stamp-srpm] 830 are also equally applicable to the procedures defined in this 831 document. 833 When using the procedures defined in [RFC6936], the security 834 considerations specified in [RFC6936] also apply. 836 10. IANA Considerations 838 This document does not require any IANA action. 840 11. References 842 11.1. Normative References 844 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 845 DOI 10.17487/RFC0768, August 1980, 846 . 848 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 849 Requirement Levels", BCP 14, RFC 2119, 850 DOI 10.17487/RFC2119, March 1997, 851 . 853 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 854 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 855 May 2017, . 857 [RFC8762] Mirsky, G., Jun, G., Nydell, H., and R. Foote, "Simple 858 Two-Way Active Measurement Protocol", RFC 8762, 859 DOI 10.17487/RFC8762, March 2020, 860 . 862 [RFC8972] Mirsky, G., Min, X., Nydell, H., Foote, R., Masputra, A., 863 and E. Ruffini, "Simple Two-Way Active Measurement 864 Protocol Optional Extensions", RFC 8972, 865 DOI 10.17487/RFC8972, January 2021, 866 . 868 [I-D.ietf-ippm-stamp-srpm] 869 Gandhi, R., Filsfils, C., Voyer, D., Chen, M., Janssens, 870 B., and R. Foote, "Simple TWAMP (STAMP) Extensions for 871 Segment Routing Networks", draft-ietf-ippm-stamp-srpm-00 872 (work in progress), June 2021. 874 11.2. Informative References 876 [IEEE1588] 877 IEEE, "1588-2008 IEEE Standard for a Precision Clock 878 Synchronization Protocol for Networked Measurement and 879 Control Systems", March 2008. 881 [RFC2113] Katz, D., "IP Router Alert Option", RFC 2113, 882 DOI 10.17487/RFC2113, February 1997, 883 . 885 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 886 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 887 2006, . 889 [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C. 890 Pignataro, "The Generalized TTL Security Mechanism 891 (GTSM)", RFC 5082, DOI 10.17487/RFC5082, October 2007, 892 . 894 [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, 895 "Bidirectional Forwarding Detection (BFD) for MPLS Label 896 Switched Paths (LSPs)", RFC 5884, DOI 10.17487/RFC5884, 897 June 2010, . 899 [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, 900 "IPv6 Flow Label Specification", RFC 6437, 901 DOI 10.17487/RFC6437, November 2011, 902 . 904 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 905 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 906 RFC 6790, DOI 10.17487/RFC6790, November 2012, 907 . 909 [RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement 910 for the Use of IPv6 UDP Datagrams with Zero Checksums", 911 RFC 6936, DOI 10.17487/RFC6936, April 2013, 912 . 914 [RFC7404] Behringer, M. and E. Vyncke, "Using Only Link-Local 915 Addressing inside an IPv6 Network", RFC 7404, 916 DOI 10.17487/RFC7404, November 2014, 917 . 919 [RFC7820] Mizrahi, T., "UDP Checksum Complement in the One-Way 920 Active Measurement Protocol (OWAMP) and Two-Way Active 921 Measurement Protocol (TWAMP)", RFC 7820, 922 DOI 10.17487/RFC7820, March 2016, 923 . 925 [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., 926 Aldrin, S., and M. Chen, "Detecting Multiprotocol Label 927 Switched (MPLS) Data-Plane Failures", RFC 8029, 928 DOI 10.17487/RFC8029, March 2017, 929 . 931 [RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli, 932 L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, 933 "Alternate-Marking Method for Passive and Hybrid 934 Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321, 935 January 2018, . 937 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 938 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 939 March 2017, . 941 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 942 Decraene, B., Litkowski, S., and R. Shakir, "Segment 943 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 944 July 2018, . 946 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 947 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 948 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 949 . 951 [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, 952 D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 953 (SRv6) Network Programming", RFC 8986, 954 DOI 10.17487/RFC8986, February 2021, 955 . 957 [I-D.ietf-spring-segment-routing-policy] 958 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 959 P. Mattes, "Segment Routing Policy Architecture", draft- 960 ietf-spring-segment-routing-policy-11 (work in progress), 961 April 2021. 963 [I-D.ietf-spring-sr-replication-segment] 964 Voyer, D., Filsfils, C., Parekh, R., Bidgoli, H., and Z. 965 Zhang, "SR Replication Segment for Multi-point Service 966 Delivery", draft-ietf-spring-sr-replication-segment-04 967 (work in progress), February 2021. 969 [I-D.ietf-pim-sr-p2mp-policy] 970 Voyer, D., Filsfils, C., Parekh, R., Bidgoli, H., and Z. 971 Zhang, "Segment Routing Point-to-Multipoint Policy", 972 draft-ietf-pim-sr-p2mp-policy-02 (work in progress), 973 February 2021. 975 [I-D.ietf-spring-mpls-path-segment] 976 Cheng, W., Li, H., Chen, M., Gandhi, R., and R. Zigler, 977 "Path Segment in MPLS Based Segment Routing Network", 978 draft-ietf-spring-mpls-path-segment-04 (work in progress), 979 April 2021. 981 [I-D.ietf-spring-srv6-path-segment] 982 Li, C., Cheng, W., Chen, M., Dhody, D., and R. Gandhi, 983 "Path Segment for SRv6 (Segment Routing in IPv6)", draft- 984 ietf-spring-srv6-path-segment-00 (work in progress), 985 November 2020. 987 [I-D.ietf-pce-sr-bidir-path] 988 Li, C., Chen, M., Cheng, W., Gandhi, R., and Q. Xiong, 989 "Path Computation Element Communication Protocol (PCEP) 990 Extensions for Associated Bidirectional Segment Routing 991 (SR) Paths", draft-ietf-pce-sr-bidir-path-05 (work in 992 progress), January 2021. 994 [I-D.ietf-ippm-stamp-yang] 995 Mirsky, G., Min, X., and W. S. Luo, "Simple Two-way Active 996 Measurement Protocol (STAMP) Data Model", draft-ietf-ippm- 997 stamp-yang-07 (work in progress), March 2021. 999 [IEEE802.1AX] 1000 IEEE Std. 802.1AX, "IEEE Standard for Local and 1001 metropolitan area networks - Link Aggregation", November 1002 2008. 1004 Acknowledgments 1006 The authors would like to thank Thierry Couture for the discussions 1007 on the use-cases for Performance Measurement in Segment Routing. The 1008 authors would also like to thank Greg Mirsky, Gyan Mishra, Xie 1009 Jingrong, and Mike Koldychev for reviewing this document and 1010 providing useful comments and suggestions. Patrick Khordoc and Radu 1011 Valceanu have helped improve the mechanisms described in this 1012 document. 1014 Authors' Addresses 1016 Rakesh Gandhi (editor) 1017 Cisco Systems, Inc. 1018 Canada 1020 Email: rgandhi@cisco.com 1021 Clarence Filsfils 1022 Cisco Systems, Inc. 1024 Email: cfilsfil@cisco.com 1026 Daniel Voyer 1027 Bell Canada 1029 Email: daniel.voyer@bell.ca 1031 Mach(Guoyi) Chen 1032 Huawei 1034 Email: mach.chen@huawei.com 1036 Bart Janssens 1037 Colt 1039 Email: Bart.Janssens@colt.net 1041 Richard Foote 1042 Nokia 1044 Email: footer.foote@nokia.com