idnits 2.17.00 (12 Aug 2021) /tmp/idnits27062/draft-gandhi-spring-enhanced-srpm-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document date (15 February 2022) is 88 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) ** Downref: Normative reference to an Informational draft: draft-ietf-spring-stamp-srpm (ref. 'I-D.ietf-spring-stamp-srpm') == Outdated reference: A later version (-01) exists of draft-ietf-spring-srv6-srh-compression-00 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-16 == Outdated reference: A later version (-15) exists of draft-ietf-pce-binding-label-sid-12 == Outdated reference: A later version (-09) exists of draft-ietf-pce-sr-bidir-path-08 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SPRING Working Group R. Gandhi, Ed. 3 Internet-Draft C. Filsfils 4 Intended status: Standards Track Cisco Systems, Inc. 5 Expires: 19 August 2022 N. Vaghamshi 6 Reliance 7 M. Nagarajah 8 Telstra 9 R. Foote 10 Nokia 11 M. Chen 12 Huawei 13 A. Dhamija 14 Rakuten 15 15 February 2022 17 Enhanced Performance Measurement Using Simple TWAMP in Segment Routing 18 Networks 19 draft-gandhi-spring-enhanced-srpm-01 21 Abstract 23 Segment Routing (SR) leverages the source routing paradigm. SR is 24 applicable to both Multiprotocol Label Switching (SR-MPLS) and IPv6 25 (SRv6) data planes. This document defines procedure for Enhanced 26 Performance Measurement of end-to-end SR paths including SR Policies 27 for both SR-MPLS and SRv6 data planes using Simple Two-Way Active 28 Measurement Protocol (STAMP) defined in RFC 8762. The procedure 29 reduces the deployment and operational complexities in a network. 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 19 August 2022. 48 Copyright Notice 50 Copyright (c) 2022 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 (https://trustee.ietf.org/ 55 license-info) in effect on the date of publication of this document. 56 Please review these documents carefully, as they describe your rights 57 and restrictions with respect to this document. Code Components 58 extracted from this document must include Revised BSD License text as 59 described in Section 4.e of the Trust Legal Provisions and are 60 provided without warranty as described in the Revised BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 66 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 67 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4 68 2.3. Reference Topology . . . . . . . . . . . . . . . . . . . 5 69 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 3.1. Enhanced Loopback Mode Enabled with Network Programming 71 Function . . . . . . . . . . . . . . . . . . . . . . . . 5 72 3.2. Example Provisioning Model . . . . . . . . . . . . . . . 6 73 4. Enhanced Performance Measurement Procedure . . . . . . . . . 7 74 4.1. Enhanced Performance Measurement Procedure for SR-MPLS 75 Policies . . . . . . . . . . . . . . . . . . . . . . . . 7 76 4.1.1. Timestamp Label Allocation . . . . . . . . . . . . . 9 77 4.1.2. Node Capability for Timestamp Label . . . . . . . . . 9 78 4.2. Enhanced Performance Measurement Procedure for SRv6 79 Policies . . . . . . . . . . . . . . . . . . . . . . . . 9 80 4.2.1. Timestamp Endpoint Function Assignment . . . . . . . 11 81 4.2.2. Node Capability for Timestamp Endpoint Function . . . 12 82 5. Example Failure Notifications . . . . . . . . . . . . . . . . 12 83 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 84 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 85 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 86 8.1. Normative References . . . . . . . . . . . . . . . . . . 14 87 8.2. Informative References . . . . . . . . . . . . . . . . . 15 88 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 16 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 91 1. Introduction 93 Segment Routing (SR) leverages the source routing paradigm and 94 greatly simplifies network operations for Software Defined Networks 95 (SDNs). SR is applicable to both Multiprotocol Label Switching (SR- 96 MPLS) and IPv6 (SRv6) data planes [RFC8402]. SR Policies as defined 97 in [I-D.ietf-spring-segment-routing-policy] are used to steer traffic 98 through a specific, user-defined paths using a stack of Segments. A 99 comprehensive SR Performance Measurement (PM) for delay and packet 100 loss as well as Connectivity Verification (CV) is one of the 101 essential requirements to measure network performance to provide 102 Service Level Agreements (SLAs). 104 The Simple Two-Way Active Measurement Protocol (STAMP) provides 105 capabilities for the measurement of various performance metrics in IP 106 networks [RFC8762] without the use of a control channel to pre-signal 107 session parameters. As described in [I-D.ietf-spring-stamp-srpm], 108 STAMP can be used for performance measurement for delay and packet 109 loss of end-to-end SR paths. 111 Seamless Bidirectional Forwarding Detection (S-BFD) [RFC7880] 112 provides a simplified mechanism for using BFD for path monitoring 113 with a large proportion of negotiation aspects eliminated. The S-BFD 114 can be used for connectivity verification of end-to-end SR paths. 116 Both STAMP and S-BFD require protocol support on the far-end 117 Reflector node to process the received packets, and hence the 118 received packets need to be punted from the forwarding fast path and 119 return packets need to be generated. This limits the scale for 120 number sessions and the ability to provide faster detection interval. 122 Enabling multiple protocols, S-BFD for connectivity verification and 123 STAMP for performance measurement increases the deployment and 124 operational complexities in a network. Also, implementing multiple 125 protocols in a hardware significantly increases the development cost. 127 This document defines procedure for Enhanced Performance Measurement 128 of end-to-end SR paths including SR Policies for both SR-MPLS and 129 SRv6 data planes, using Simple Two-Way Active Measurement Protocol 130 (STAMP) defined in [RFC8762]. The procedure reduces the deployment 131 and operational complexities in a network. 133 2. Conventions Used in This Document 134 2.1. Requirements Language 136 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 137 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 138 document are to be interpreted as described in [RFC2119] [RFC8174] 139 when, and only when, they appear in all capitals, as shown here. 141 2.2. Abbreviations 143 S-BFD: Seamless Bidirectional Forwarding Detection. 145 BSID: Binding Segment ID. 147 ECMP: Equal Cost Multi-Path. 149 EB: Endpoint Behaviour. 151 HMAC: Hashed Message Authentication Code. 153 MBZ: Must be Zero. 155 MPLS: Multiprotocol Label Switching. 157 PM: Performance Measurement. 159 PTP: Precision Time Protocol. 161 SID: Segment ID. 163 SL: Segment List. 165 SR: Segment Routing. 167 SRH: Segment Routing Header. 169 SR-MPLS: Segment Routing with MPLS data plane. 171 SRv6: Segment Routing with IPv6 data plane. 173 STAMP: Simple Two-way Active Measurement Protocol. 175 TC: Traffic Class. 177 TTL: Time To Live. 179 2.3. Reference Topology 181 In the reference topology shown in Figure 1, the STAMP Session-Sender 182 [RFC8762] S1 initiates a Session-Sender test packet and the Session- 183 Reflector R1 returns the test packet. The return test packet may be 184 transmitted back to the Session-Sender S1 on the same path (same set 185 of links and nodes) or a different path in the reverse direction from 186 the path taken towards the Session-Reflector R1. 188 The Session-Sender S1 and Session-Reflector R1 are connected via an 189 SR path [RFC8402]. The SR path can be an SR Policy 190 [I-D.ietf-spring-segment-routing-policy] on node S1 (called head-end) 191 with destination to node R1 (called tail-end). 193 T1 T2 194 / \ 195 +-------+ STAMP Test Packet +-------+ 196 | | - - - - - - - - - - - | | 197 | S1 |======================|| R1 | 198 | |<- - - - - - - - - - - | | 199 +-------+ Return Test Packet +-------+ 200 \ 201 T4 203 Session-Sender Session-Reflector 204 (Timestamp, 205 Pop and Forward) 207 Figure 1: Loopback Mode Enabled with Network Programming Function 209 3. Overview 211 3.1. Enhanced Loopback Mode Enabled with Network Programming Function 213 As described in [I-D.ietf-spring-stamp-srpm], in loopback mode, the 214 STAMP Session-Sender S1 initiates Session-Sender test packets and the 215 Session-Reflector R1 forwards them back to the Session-Sender S1. 216 The received STAMP test packets are not punted out of the fast path 217 in forwarding at the Session-Reflector. At the Session-Reflector, 218 the loopback function simply makes the necessary changes to the 219 encapsulation including IP and UDP headers to return the STAMP test 220 packet to the Session-Sender S1. No STAMP test session is created on 221 the Session-Reflector R1. As described in 222 [I-D.ietf-spring-stamp-srpm], only round-trip delay can be measured 223 in the loopback mode. In SR networks, there is also a need to 224 measure one-way delay to provide low latency services. 226 This document defines a new STAMP measurement mode, enhanced loopback 227 mode, that is loopback mode enabled with network programming 228 function. In this mode, both transmit (T1) and receive (T2) 229 timestamps in data plane are collected by the Session-Sender test 230 packets as shown in Figure 1. The network programming function 231 optimizes the "operations of punt test packet and generate return 232 test packet" on the Session-Reflector as timestamping is implemented 233 in forwarding fast path in hardware. This helps to achieve higher 234 STAMP test session scale and faster detection interval. 236 The Session-Sender adds transmit timestamp (T1) in the payload of the 237 Session-Sender test packet. The Session-Reflector adds the receive 238 timestamp (T2) in the payload of the received test packet in 239 forwarding fast path in hardware without punting the test packet 240 (e.g. to slow path or control-plane). The network programming 241 function enables Session-Reflector to add the receive timestamp (T2) 242 at a specific offset in the payload which is locally provisioned, 243 consistently in the network. 245 3.2. Example Provisioning Model 247 An example provisioning model and typical measurement parameters are 248 shown in Figure 2: 250 +------------+ 251 | Controller | 252 +------------+ 253 STAMP Mode / \ Timestamp Label/SRv6 EB 254 Enhanced Loopback Mode / \ Timestamp Offset 255 Timestamp Label/SRv6 EB / \ Timestamp Format 256 Timestamp Format / \ 257 Missed Packet Count (N) / \ 258 Delay Threshold/Count(TH/M) / \ 259 Packet Loss Threshold(XofY) / \ 260 v v 261 +-------+ +-------+ 262 | | | | 263 | S1 |==========| R1 | 264 | | | | 265 +-------+ +-------+ 267 Session-Sender Session-Reflector 269 Figure 2: Example Provisioning Model 271 Example of a STAMP mode is enhanced loopback mode defined in this 272 document. The values for Timestamp Label and SRv6 Endpoint Behaviour 273 may be provisioned as described in this document. Example of 274 Timestamp Format is 64-bit PTPv2 [IEEE1588]. Example of Timestamp 275 Offset is 16 and 32 bytes for the unauthenticated and authenticated 276 STAMP Session-Sender test packets, respectively. Example of 277 threshold values configured for generating notifications are: Missed 278 Packet Count (N), Delay Exceeded Threshold and Packet Count (TH/M) 279 and Packet Loss Threshold (XofY), as described in this document. 281 The mechanisms to provision the Session-Sender and Session-Reflector 282 are outside the scope of this document. 284 4. Enhanced Performance Measurement Procedure 286 For enhanced performance monitoring of an end-to-end SR path 287 including SR Policy, STAMP Session-Sender test packets are 288 transmitted in loopback mode enabled with network programming 289 function to timestamp and forward the packet. 291 For SR Policy, the Session-Sender test packets are transmitted using 292 the Segment List (SL) of the Candidate-Path 293 [I-D.ietf-spring-segment-routing-policy]. When a Candidate-Path has 294 more than one Segment Lists, multiple Session-Sender test packets 295 MUST be transmitted, one using each Segment List. 297 4.1. Enhanced Performance Measurement Procedure for SR-MPLS Policies 299 An SR-MPLS Policy may contain a number of Segment Lists (SLs). A 300 Session-Sender test packet MUST be transmitted for each Segment List 301 of the SR-MPLS Policy. The content of an example Session-Sender test 302 packet for an end-to-end SR-MPLS Policy is shown in Figure 3. 304 The SR-MPLS header can contain the MPLS label stack of the forward 305 path or both forward and the reverse direction paths. In the former 306 case, the return test packets are received by the Session-Sender via 307 IP/UDP [RFC0768] return path and the MPLS header is removed by the 308 Session-Reflector. 310 In the latter case, the Segment List of the reverse direction SR path 311 is added in the Session-Sender test packet header to receive the 312 return test packet on a specific path, either using the Binding SID 313 [I-D.ietf-pce-binding-label-sid] or Segment List of the Reverse SR 314 Policy [I-D.ietf-pce-sr-bidir-path]. In this case, the MPLS header 315 is not removed by the Session-Reflector. 317 In both cases, the Session-Sender MUST set the Destination Address 318 equal to the Session-Sender address in the IP header of the test 319 packets. 321 In this document, two new Timestamp Labels are defined for SR-MPLS 322 data plane to enable network programming function for "timestamp, pop 323 and forward" the received test packet, one for unauthenticated mode 324 and one for authenticated mode. 326 In the Session-Sender test packets for SR-MPLS Policies, a Timestamp 327 Label is added in the MPLS header as shown in Figure 3, to collect 328 "Receive Timestamp" field in the payload of the test packet. The 329 Label Stack for the reverse direction SR-MPLS path can be added after 330 the Timestamp Label (not shown in the Figure) to receive the return 331 test packet on a specific path. When a Session-Reflector receives a 332 packet with Timestamp Label, after timestamping the packet at a 333 specific offset, the Session-Reflector pops the Timestamp Label and 334 forwards the packet using the next label or IP header in the packet 335 (just like the data packets for the normal traffic). 337 0 1 2 3 338 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 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 | Label(1) | TC |S| TTL | 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 . . 343 . . 344 . . 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 | Label(n) | TC |S| TTL | 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 | Extension Label (15) | TC |S| TTL | 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 | Timestamp Label (TBA1 or TBA2) | TC |S| TTL | 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 | IP Header | 353 . Source IP Address = Session-Sender IPv4 or IPv6 Address . 354 . Destination IP Address = Session-Sender IPv4 or IPv6 Address . 355 . Protocol = UDP . 356 . . 357 +---------------------------------------------------------------+ 358 | UDP Header | 359 . Source Port = As chosen by Session-Sender . 360 . Destination Port = As chosen by Session-Sender . 361 . . 362 +---------------------------------------------------------------+ 363 | Payload = Test Packet as specified in Section 3 of RFC 8972 | 364 . in Figure 1 and Figure 3 . 365 . . 366 +---------------------------------------------------------------+ 368 Figure 3: Example STAMP Test Packet with Timestamp Label for SR-MPLS 370 4.1.1. Timestamp Label Allocation 372 The timestamp Labels for STAMP test packets in unauthenticated and 373 authenticated modes can be allocated using one of the following 374 methods: 376 * Labels (values TBA1 and TBA2) assigned by IANA from the "Extended 377 Special-Purpose MPLS Values" [RFC9017]. For Label (value TBA1), 378 the timestamp offset is fixed at byte-offset 16 from the start of 379 the payload for the STAMP test packets in unauthenticated mode, 380 and Label (value TBA2) at byte-offset 32 from the start of the 381 payload for the STAMP test packets in authenticated mode, both 382 using the timestamp format 64-bit PTPv2. 384 * Labels allocated by a Controller from the global table of the 385 Session-Reflector. The Controller provisions the labels on both 386 Session-Sender and Session-Reflector, as well as timestamp offsets 387 and timestamp formats. 389 * Labels allocated by the Session-Reflector. The signaling and IGP 390 flooding extension for the labels (including their timestamp 391 offsets and timestamp formats) are outside the scope of this 392 document. 394 4.1.2. Node Capability for Timestamp Label 396 The STAMP Session-Sender needs to know if the Session-Reflector can 397 process the Timestamp Label to avoid dropping test packets. The 398 signaling extension or local configuration for this capability 399 exchange is outside the scope of this document. 401 4.2. Enhanced Performance Measurement Procedure for SRv6 Policies 403 An SRv6 Policy may contain a number of Segment Lists. Each Segment 404 List may contain a number of SRv6 SIDs as defined in [RFC8986], 405 [I-D.filsfils-spring-net-pgm-extension-srv6-usid] and 406 [I-D.ietf-spring-srv6-srh-compression]. A Session-Sender test packet 407 MUST be transmitted for each Segment List of the SRv6 Policy. An 408 SRv6 Policy may contain an SRv6 Segment Routing Header (SRH) carrying 409 a Segment List as described in [RFC8754]. The content of an example 410 Session-Sender test packet for an end-to-end SRv6 Policy using an SRH 411 is shown in Figure 4. 413 The SRH can contain the Segment List of the forward path only or both 414 forward and the reverse direction paths. In the former case, an 415 inner IPv6 header (after the SRH and before the UDP header) MUST be 416 added that contains the Destination Address equal to the Session- 417 Sender address as shown in Figure 4. In this case, the SRH is 418 removed by the Session-Reflector and IP/UDP return path is used. 420 In the latter case, the Segment List of the reverse direction SR path 421 is added in the SRH to receive the return test packet on a specific 422 path, either using the Binding SID [I-D.ietf-pce-binding-label-sid] 423 or Segment List of the Reverse SR Policy 424 [I-D.ietf-pce-sr-bidir-path]. In this case, the SRH is not removed 425 by the Session-Reflector and an inner IPv6 header is not required. 426 When the return test packet contains an SRH at the Session-Sender, 427 the procedure defined for upper-layer header processing for SRv6 SIDs 428 in [RFC8986] MUST be used to process the UDP header after the SRH in 429 the received test packets. 431 The [RFC8986] defines SRv6 Endpoint Behaviours (EB) for SRv6 nodes. 432 In this document, two new Timestamp Endpoint Behaviours are defined 433 for Segment Routing Header (SRH) [RFC8754] to enable "Timestamp and 434 Forward (TSF)" function for the received test packets, one for 435 unauthenticated mode and one for authenticated mode. 437 In the Session-Sender test packets for SRv6 Policies, Timestamp 438 Endpoint Function (End.TSF) is carried with the target Segment 439 Identifier (SID) in SRH [RFC8754] as shown in Figure 4, to collect 440 "Receive Timestamp" field in the payload of the test packet. The 441 Segment List for the reverse direction path can be added after the 442 target SID to receive the return test packet on a specific path. 443 When a Session-Reflector receives a packet with Timestamp Endpoint 444 (End.TSF) for the target SID which is local, after timestamping the 445 packet at a specific offset, the Session-Reflector forwards the 446 packet using the next SID in the SRH or inner IPv6 header in the 447 packet (just like the data packets for the normal traffic). 449 +---------------------------------------------------------------+ 450 | IP Header | 451 . Source IP Address = Session-Sender IPv6 Address . 452 . Destination IP Address = Destination IPv6 Address . 453 . Next-Header = 43 (Type SRH) . 454 . . 455 +---------------------------------------------------------------+ 456 | SRH as specified in RFC 8754 | 457 . . 458 . SRv6 Endpoint End.TSF (value TBA3 or TBA4) . 459 . . 460 +---------------------------------------------------------------+ 461 | IP Header | 462 . Source IP Address = Session-Sender IPv6 Address . 463 . Destination IP Address = Session-Sender IPv6 Address . 464 . Next-Header = UDP (17) . 465 . . 466 +---------------------------------------------------------------+ 467 | UDP Header | 468 . Source Port = As chosen by Session-Sender . 469 . Destination Port = As chosen by Session-Sender . 470 . . 471 +---------------------------------------------------------------+ 472 | Payload = Test Packet as specified in Section 3 of RFC 8972 | 473 . in Figure 1 and Figure 3 . 474 . . 475 +---------------------------------------------------------------+ 477 Figure 4: Example STAMP Test Packet with Endpoint Function for SRv6 479 4.2.1. Timestamp Endpoint Function Assignment 481 The Timestamp Endpoint Functions for "Timestamp and Forward" can be 482 signaled using one of the following methods: 484 * Timestamp Endpoint Functions (values TBA3 and TBA4) assigned by 485 IANA from the "SRv6 Endpoint Behaviors Registry". For endpoint 486 behaviour (value TBA3), the timestamp offset is fixed at byte- 487 offset 16 from the start of the payload for the STAMP test packets 488 in unauthenticated mode, and endpoint behaviour (value TBA4) at 489 byte-offset 32 from the start of the payload for the STAMP test 490 packets in authenticated mode, both using the timestamp format 491 64-bit PTPv2. 493 * Timestamp Endpoint Functions assigned by a Controller. The 494 Controller provisions the values on both Session-Sender and 495 Session-Reflector, as well as timestamp offsets and timestamp 496 formats. 498 * Timestamp Endpoint Functions assigned by the Session-Reflector. 499 The signaling and IGP flooding extension for the endpoint 500 functions (including timestamp offsets and timestamp formats) are 501 outside the scope of this document. 503 4.2.2. Node Capability for Timestamp Endpoint Function 505 The STAMP Session-Sender needs to know if the Session-Reflector can 506 process the Timestamp Endpoint Function to avoid dropping test 507 packets. The signaling extension for this capability exchange is 508 outside the scope of this document. 510 5. Example Failure Notifications 512 The timestamps T1 and T2 are used to measure the one-way delay. The 513 delay metrics for an end-to-end SR path are notified, for example, 514 when consecutive M number of test packets have measured delay values 515 exceed the user-configured threshold TH, where M (Delay Exceeded 516 Packet Count) and TH (Absolute and Percentage Delay Exceeded 517 Thresholds) are also locally provisioned values. 519 The round-trip packet loss for an end-to-end SR path is calculated 520 using the Sequence Number in the Session-Sender test packets. The 521 packet loss metric is notified when X number of Session-Sender test 522 packets were lost out of last Y number of test packets transmitted by 523 the Session-Sender, where Threshold XofY is locally provisioned 524 value. 526 STAMP session state as UP (i.e. Connectivity verification success) 527 for an end-to-end SR path is initially notified as soon as one or 528 more return test packets are received at the Session-Sender. 530 STAMP session state as DOWN (i.e. Connectivity verification failure) 531 for an end-to-end SR path is notified when consecutive N number of 532 return test packets are not received at the Session-Sender, where N 533 (Missed Packet Count) is a locally provisioned value. 535 In the loopback mode, a connectivity verification failure on the 536 reverse direction path can cause the return test packets to not reach 537 the Session-Sender. This is also true in the case where the return 538 test packets are generated by the stateless Session-Reflector in two- 539 way measurement. The stateful Session-Reflector can solve this issue 540 by maintaining the forwarding direction state and notifying a 541 connectivity verification success and failure to the Session-Sender. 543 6. Security Considerations 545 The STAMP protocol is intended for deployment in limited domains 546 [RFC8799]. As such, it assumes that a node involved in the STAMP 547 protocol operation has previously verified the integrity of the path 548 and the identity of the far-end Session-Reflector. 550 The security considerations specified in [RFC8762] and [RFC8972] also 551 apply to the procedures defined in this document. Specifically, the 552 message integrity protection using HMAC, as defined in Section 4.4 of 553 [RFC8762] also apply to the procedure described in this document. 555 7. IANA Considerations 557 IANA maintains the "Special-Purpose Multiprotocol Label Switching 558 (MPLS) Label Values" registry (see ). IANA is requested to 560 allocate Timestamp Label value from the "Extended Special-Purpose 561 MPLS Label Values" registry: 563 +-------------+---------------------------------+---------------+ 564 | Value | Description | Reference | 565 +-------------+---------------------------------+---------------+ 566 | TBA1 | Timestamp Label | This document | 567 | | for offset 16 for STAMP | | 568 | | in Unauthenticated Mode | | 569 +-------------+---------------------------------+---------------+ 570 | TBA2 | Timestamp Label | This document | 571 | | for offset 32 for STAMP | | 572 | | in Authenticated Mode | | 573 +-------------+---------------------------------+---------------+ 575 IANA is requested to allocate, within the "SRv6 Endpoint Behaviors 576 Registry" sub-registry belonging to the top-level "Segment Routing 577 Parameters" registry [RFC8986], the following allocation: 579 +-------------+---------------------------------+---------------+ 580 | Value | Endpoint Behavior | Reference | 581 +-------------+---------------------------------+---------------+ 582 | TBA3 | End.TSF (Timestamp and Forward) | This document | 583 | | for offset 16 for STAMP | | 584 | | in Unauthenticated Mode | | 585 +-------------+---------------------------------+---------------+ 586 | TBA4 | End.TSF (Timestamp and Forward) | This document | 587 | | for offset 32 for STAMP | | 588 | | in Authenticated Mode | | 589 +-------------+---------------------------------+---------------+ 591 8. References 593 8.1. Normative References 595 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 596 DOI 10.17487/RFC0768, August 1980, 597 . 599 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 600 Requirement Levels", BCP 14, RFC 2119, 601 DOI 10.17487/RFC2119, March 1997, 602 . 604 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 605 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 606 May 2017, . 608 [RFC8762] Mirsky, G., Jun, G., Nydell, H., and R. Foote, "Simple 609 Two-Way Active Measurement Protocol", RFC 8762, 610 DOI 10.17487/RFC8762, March 2020, 611 . 613 [RFC8972] Mirsky, G., Min, X., Nydell, H., Foote, R., Masputra, A., 614 and E. Ruffini, "Simple Two-Way Active Measurement 615 Protocol Optional Extensions", RFC 8972, 616 DOI 10.17487/RFC8972, January 2021, 617 . 619 [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, 620 D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 621 (SRv6) Network Programming", RFC 8986, 622 DOI 10.17487/RFC8986, February 2021, 623 . 625 [I-D.ietf-spring-stamp-srpm] 626 Gandhi, R., Filsfils, C., Voyer, D., Chen, M., Janssens, 627 B., and R. Foote, "Performance Measurement Using Simple 628 TWAMP (STAMP) for Segment Routing Networks", Work in 629 Progress, Internet-Draft, draft-ietf-spring-stamp-srpm-03, 630 1 February 2022, . 633 8.2. Informative References 635 [IEEE1588] IEEE, "1588-2008 IEEE Standard for a Precision Clock 636 Synchronization Protocol for Networked Measurement and 637 Control Systems", March 2008. 639 [RFC7880] Pignataro, C., Ward, D., Akiya, N., Bhatia, M., and S. 640 Pallagatti, "Seamless Bidirectional Forwarding Detection 641 (S-BFD)", RFC 7880, DOI 10.17487/RFC7880, July 2016, 642 . 644 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 645 Decraene, B., Litkowski, S., and R. Shakir, "Segment 646 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 647 July 2018, . 649 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 650 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 651 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 652 . 654 [RFC8799] Carpenter, B. and B. Liu, "Limited Domains and Internet 655 Protocols", RFC 8799, DOI 10.17487/RFC8799, July 2020, 656 . 658 [RFC9017] Andersson, L., Kompella, K., and A. Farrel, "Special- 659 Purpose Label Terminology", RFC 9017, 660 DOI 10.17487/RFC9017, April 2021, 661 . 663 [I-D.ietf-spring-srv6-srh-compression] 664 Cheng, W., Filsfils, C., Li, Z., Decraene, B., Cai, D., 665 Voyer, D., Clad, F., Zadok, S., Guichard, J. N., Aihua, 666 L., Raszuk, R., and C. Li, "Compressed SRv6 Segment List 667 Encoding in SRH", Work in Progress, Internet-Draft, draft- 668 ietf-spring-srv6-srh-compression-00, 11 February 2022, 669 . 672 [I-D.filsfils-spring-net-pgm-extension-srv6-usid] 673 Filsfils, C., Garvia, P. C., Cai, D., Voyer, D., Meilik, 674 I., Patel, K., Henderickx, W., Jonnalagadda, P., Melman, 675 D., Liu, Y., and J. Guichard, "Network Programming 676 extension: SRv6 uSID instruction", Work in Progress, 677 Internet-Draft, draft-filsfils-spring-net-pgm-extension- 678 srv6-usid-12, 13 December 2021, 679 . 682 [I-D.ietf-spring-segment-routing-policy] 683 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 684 P. Mattes, "Segment Routing Policy Architecture", Work in 685 Progress, Internet-Draft, draft-ietf-spring-segment- 686 routing-policy-16, 28 January 2022, 687 . 690 [I-D.ietf-pce-binding-label-sid] 691 Sivabalan, S., Filsfils, C., Tantsura, J., Previdi, S., 692 and C. L. (editor), "Carrying Binding Label/Segment 693 Identifier in PCE-based Networks.", Work in Progress, 694 Internet-Draft, draft-ietf-pce-binding-label-sid-12, 24 695 January 2022, . 698 [I-D.ietf-pce-sr-bidir-path] 699 Li, C., Chen, M., Cheng, W., Gandhi, R., and Q. Xiong, 700 "Path Computation Element Communication Protocol (PCEP) 701 Extensions for Associated Bidirectional Segment Routing 702 (SR) Paths", Work in Progress, Internet-Draft, draft-ietf- 703 pce-sr-bidir-path-08, 9 September 2021, 704 . 707 Acknowledgments 709 The authors would like to thank Greg Mirsky, Kireeti Kompella, and 710 Adrian Farrel for providing useful comments. 712 Authors' Addresses 714 Rakesh Gandhi (editor) 715 Cisco Systems, Inc. 716 Canada 718 Email: rgandhi@cisco.com 719 Clarence Filsfils 720 Cisco Systems, Inc. 722 Email: cfilsfil@cisco.com 724 Navin Vaghamshi 725 Reliance 727 Email: Navin.Vaghamshi@ril.com 729 Moses Nagarajah 730 Telstra 732 Email: Moses.Nagarajah@team.telstra.com 734 Richard Foote 735 Nokia 737 Email: footer.foote@nokia.com 739 Mach(Guoyi) Chen 740 Huawei 742 Email: mach.chen@huawei.com 744 Amit Dhamija 745 Rakuten 747 Email: amit.dhamija@rakuten.com