idnits 2.17.1 draft-gandhi-spring-enhanced-srpm-00.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 (24 August 2021) is 977 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 (-15) exists of draft-ietf-spring-stamp-srpm-01 ** Downref: Normative reference to an Informational draft: draft-ietf-spring-stamp-srpm (ref. 'I-D.ietf-spring-stamp-srpm') == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-13 == Outdated reference: A later version (-16) exists of draft-ietf-pce-binding-label-sid-10 == Outdated reference: A later version (-13) exists of draft-ietf-pce-sr-bidir-path-07 Summary: 1 error (**), 0 flaws (~~), 5 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: 25 February 2022 N. Vaghamshi 6 Reliance 7 M. Nagarajah 8 Telstra 9 R. Foote 10 Nokia 11 M. Chen 12 Huawei 13 24 August 2021 15 Enhanced Performance Measurement Using Simple TWAMP in Segment Routing 16 Networks 17 draft-gandhi-spring-enhanced-srpm-00 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 defines procedure for Enhanced 24 Performance Measurement of end-to-end SR paths including SR Policies 25 for both SR-MPLS and SRv6 data planes using Simple Two-Way Active 26 Measurement Protocol (STAMP) defined in RFC 8762. The procedure 27 reduces the deployment and operational complexities in a network. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on 25 February 2022. 46 Copyright Notice 48 Copyright (c) 2021 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 53 license-info) in effect on the date of publication of this document. 54 Please review these documents carefully, as they describe your rights 55 and restrictions with respect to this document. Code Components 56 extracted from this document must include Simplified BSD License text 57 as described in Section 4.e of the Trust Legal Provisions and are 58 provided without warranty as described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 64 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 65 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4 66 2.3. Reference Topology . . . . . . . . . . . . . . . . . . . 5 67 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 3.1. Enhanced Loopback Mode Enabled with Network Programming 69 Function . . . . . . . . . . . . . . . . . . . . . . . . 5 70 3.2. Example Provisioning Model . . . . . . . . . . . . . . . 6 71 4. Enhanced Performance Measurement Procedure . . . . . . . . . 7 72 4.1. Enhanced Performance Measurement Procedure for SR-MPLS 73 Policies . . . . . . . . . . . . . . . . . . . . . . . . 7 74 4.1.1. Timestamp Label Allocation . . . . . . . . . . . . . 9 75 4.1.2. Node Capability for Timestamp Label . . . . . . . . . 9 76 4.2. Enhanced Performance Measurement Procedure for SRv6 77 Policies . . . . . . . . . . . . . . . . . . . . . . . . 9 78 4.2.1. Timestamp Endpoint Function Assignment . . . . . . . 11 79 4.2.2. Node Capability for Timestamp Endpoint Function . . . 12 80 5. Example Failure Notifications . . . . . . . . . . . . . . . . 12 81 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 82 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 83 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 84 8.1. Normative References . . . . . . . . . . . . . . . . . . 14 85 8.2. Informative References . . . . . . . . . . . . . . . . . 15 86 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 16 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 89 1. Introduction 91 Segment Routing (SR) leverages the source routing paradigm and 92 greatly simplifies network operations for Software Defined Networks 93 (SDNs). SR is applicable to both Multiprotocol Label Switching (SR- 94 MPLS) and IPv6 (SRv6) data planes [RFC8402]. SR Policies as defined 95 in [I-D.ietf-spring-segment-routing-policy] are used to steer traffic 96 through a specific, user-defined paths using a stack of Segments. 97 Built-in Performance Measurement (PM) for delay and packet loss as 98 well as Connectivity Verification (CV) are essential requirements to 99 provide Service Level Agreements (SLAs) in SR networks. 101 The Simple Two-Way Active Measurement Protocol (STAMP) provides 102 capabilities for the measurement of various performance metrics in IP 103 networks [RFC8762] without the use of a control channel to pre-signal 104 session parameters. As described in [I-D.ietf-spring-stamp-srpm], 105 the STAMP can be used for performance measurement for delay and 106 packet loss of end-to-end SR paths. 108 Seamless Bidirectional Forwarding Detection (S-BFD) [RFC7880] 109 provides a simplified mechanism for using BFD for path monitoring 110 with a large proportion of negotiation aspects eliminated. The S-BFD 111 can be used for connectivity verification of end-to-end SR paths. 113 Both STAMP and S-BFD require protocol support on the far-end 114 Reflector node to process the received packets, and hence the 115 received packets need to be punted from the forwarding fast path and 116 return packets need to be generated. This limits the scale for 117 number sessions and the ability to provide faster detection interval. 119 Enabling multiple protocols, S-BFD for connectivity verification and 120 STAMP for performance measurement increases the deployment and 121 operational complexities in a network. Also, implementing multiple 122 protocols in a hardware significantly increases the development cost. 124 This document defines procedure for Enhanced Performance Measurement 125 of end-to-end SR paths including SR Policies for both SR-MPLS and 126 SRv6 data planes, using Simple Two-Way Active Measurement Protocol 127 (STAMP) defined in [RFC8762]. The procedure reduces the deployment 128 and operational complexities in a network. 130 2. Conventions Used in This Document 131 2.1. Requirements Language 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 135 document are to be interpreted as described in [RFC2119] [RFC8174] 136 when, and only when, they appear in all capitals, as shown here. 138 2.2. Abbreviations 140 S-BFD: Seamless Bidirectional Forwarding Detection. 142 BSID: Binding Segment ID. 144 ECMP: Equal Cost Multi-Path. 146 EB: Endpoint Behaviour. 148 HMAC: Hashed Message Authentication Code. 150 MBZ: Must be Zero. 152 MPLS: Multiprotocol Label Switching. 154 PM: Performance Measurement. 156 PTP: Precision Time Protocol. 158 SID: Segment ID. 160 SL: Segment List. 162 SR: Segment Routing. 164 SRH: Segment Routing Header. 166 SR-MPLS: Segment Routing with MPLS data plane. 168 SRv6: Segment Routing with IPv6 data plane. 170 STAMP: Simple Two-way Active Measurement Protocol. 172 TC: Traffic Class. 174 TTL: Time To Live. 176 2.3. Reference Topology 178 In the reference topology shown in Figure 1, the STAMP Session-Sender 179 [RFC8762] S1 initiates a Session-Sender test packet and the Session- 180 Reflector R1 returns the test packet. The return test packet is 181 transmitted back to the Session-Sender S1 on the same path (same set 182 of links and nodes) or a different path in the reverse direction from 183 the path taken towards the Session-Reflector R1. 185 The Session-Sender S1 and Session-Reflector R1 are connected via an 186 SR path [RFC8402]. The SR path can be an SR Policy 187 [I-D.ietf-spring-segment-routing-policy] on node S1 (called head-end) 188 with destination to node R1 (called tail-end). 190 T1 T2 191 / \ 192 +-------+ STAMP Test Packet +-------+ 193 | | - - - - - - - - - - - | | 194 | S1 |======================|| R1 | 195 | |<- - - - - - - - - - - | | 196 +-------+ Return Test Packet +-------+ 197 \ 198 T4 200 Session-Sender Session-Reflector 201 (Timestamp, 202 Pop and Forward) 204 Figure 1: Loopback Mode Enabled with Network Programming Function 206 3. Overview 208 3.1. Enhanced Loopback Mode Enabled with Network Programming Function 210 As described in [I-D.ietf-spring-stamp-srpm], in loopback mode, the 211 STAMP Session-Sender S1 initiates Session-Sender test packets and the 212 Session-Reflector R1 forwards them back to the Session-Sender S1. 213 The received STAMP test packets are not punted out of the fast path 214 in forwarding at the Session-Reflector. At the Session-Reflector, 215 the loopback function simply makes the necessary changes to the 216 encapsulation including IP and UDP headers to return the STAMP test 217 packet to the Session-Sender S1. No STAMP test session is created on 218 the Session-Reflector R1. 220 This document defines a new STAMP measurement mode, enhanced loopback 221 mode, that is loopback mode enabled with network programming 222 function. In this mode, both transmit (T1) and receive (T2) 223 timestamps in data plane are collected by the Session-Sender test 224 packets as shown in Figure 1. The network programming function 225 optimizes the "operations of punt test packet and generate return 226 test packet" on the Session-Reflector as timestamping is implemented 227 in forwarding fast path in hardware. This helps to achieve higher 228 STAMP test session scale and faster detection interval. 230 The Session-Sender adds transmit timestamp (T1) in the payload of the 231 Session-Sender test packet. The Session-Reflector adds the receive 232 timestamp (T2) in the payload of the received test packet in 233 forwarding fast path in hardware without punting the test packet 234 (e.g. to slow path or control-plane). The network programming 235 function enables Session-Reflector to add the receive timestamp (T2) 236 at a specific offset in the payload which is locally provisioned, 237 consistently in the network. 239 The Session-Reflector only adds the receive timestamp if the source 240 IP address (in case of SR-MPLS) or outer IPv6 header destination IP 241 address (in case of SRv6) in the test packet matches the local node 242 address to ensure that the test packet reaches the intended Session- 243 Reflector and the receive timestamp is returned by the intended 244 Session-Reflector. 246 3.2. Example Provisioning Model 248 An example provisioning model and typical measurement parameters are 249 shown in Figure 2: 251 +------------+ 252 | Controller | 253 +------------+ 254 STAMP Mode / \ Timestamp Label/SRv6 EB 255 Enhanced Loopback Mode / \ Timestamp Offset 256 Timestamp Label/SRv6 EB / \ Timestamp Format 257 Timestamp Format / \ 258 Missed Packet Count (N) / \ 259 Delay Threshold/Count(TH/M) / \ 260 Packet Loss Threshold(XofY) / \ 261 v v 262 +-------+ +-------+ 263 | | | | 264 | S1 |==========| R1 | 265 | | | | 266 +-------+ +-------+ 268 Session-Sender Session-Reflector 270 Figure 2: Example Provisioning Model 272 Example of a STAMP mode is enhanced loopback mode defined in this 273 document. The values for Timestamp Label and SRv6 Endpoint Behaviour 274 may be provisioned as described in this document. Example of 275 Timestamp Format is 64-bit PTPv2 [IEEE1588]. Example of Timestamp 276 Offset is 16 and 32 bytes for the unauthenticated and authenticated 277 STAMP Session-Sender test packets, respectively. Example of 278 threshold values configured for generating notifications are: Missed 279 Packet Count (N), Delay Exceeded Threshold and Packet Count (TH/M) 280 and Packet Loss Threshold (XofY), as described in this document. 282 The mechanisms to provision the Session-Sender and Session-Reflector 283 are outside the scope of this document. 285 4. Enhanced Performance Measurement Procedure 287 For enhanced performance monitoring of an end-to-end SR path 288 including SR Policy, STAMP Session-Sender test packets are 289 transmitted in loopback mode enabled with network programming 290 function to timestamp and forward the packet. 292 For SR Policy, the Session-Sender test packets are transmitted using 293 the Segment List (SL) of the Candidate-Path 294 [I-D.ietf-spring-segment-routing-policy]. When a Candidate-Path has 295 more than one Segment Lists, multiple Session-Sender test packets 296 MUST be transmitted, one using each Segment List. 298 4.1. Enhanced Performance Measurement Procedure for SR-MPLS Policies 300 The STAMP Session-Sender test packets is transmitted using an MPLS 301 header for each Label Stack of the SR-MPLS Policy Candidate-Path(s) 302 as 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 and the Source Address equal to 319 the Session-Reflector address in the IP header of the test 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-Reflector 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 timestamp offsets and 391 timestamp formats) are outside the scope of this document. 393 4.1.2. Node Capability for Timestamp Label 395 The STAMP Session-Sender needs to know if the Session-Reflector can 396 process the Timestamp Label to avoid dropping test packets. The 397 signaling extension for this capability exchange is outside the scope 398 of this document. 400 4.2. Enhanced Performance Measurement Procedure for SRv6 Policies 402 The STAMP Session-Sender test packets for SRv6 data plane is 403 transmitted using a Segment Routing Header (SRH) [RFC8754] for each 404 Segment List of the SRv6 Policy Candidate-Path(s) as shown in 405 Figure 4. 407 The SRH can contain the Segment List of the forward path or both 408 forward and the reverse direction paths. In the former case, an 409 inner IPv6 header (after SRH and before UDP header) MUST be added 410 that contains the Destination Address equal to the Session-Sender 411 address and the Source Address equal to the Session-Reflector address 412 as shown in Figure 4. In this case, the SRH is removed by the 413 Session-Reflector and IP/UDP return path is used. 415 In the latter case, the Segment List of the reverse direction SR path 416 is added in the SRH to receive the return test packet on a specific 417 path, either using the Binding SID [I-D.ietf-pce-binding-label-sid] 418 or Segment List of the Reverse SR Policy 419 [I-D.ietf-pce-sr-bidir-path]. In this case, the SRH is not removed 420 by the Session-Reflector and an inner IPv6 header is not required. 421 When the return test packet contains an SRH at the Session-Sender, 422 the procedure defined for upper-layer header processing for SRv6 SIDs 423 in [RFC8986] MUST be used to process the UDP header in the received 424 test packets. 426 The [RFC8986] defines SRv6 Endpoint Behaviours (EB) for SRv6 nodes. 427 In this document, two new Timestamp Endpoint Behaviours are defined 428 for Segment Routing Header (SRH) [RFC8754] to enable "Timestamp and 429 Forward (TSF)" function for the received test packets, one for 430 unauthenticated mode and one for authenticated mode. 432 In the Session-Sender test packets for SRv6 Policies, Timestamp 433 Endpoint Function (End.TSF) is carried with the target Segment 434 Identifier (SID) in SRH [RFC8754] as shown in Figure 4, to collect 435 "Receive Timestamp" field in the payload of the test packet. The 436 Segment List for the reverse direction path can be added after the 437 target SID to receive the return test packet on a specific path. 438 When a Session-Reflector receives a packet with Timestamp Endpoint 439 (End.TSF) for the target SID which is local, after timestamping the 440 packet at a specific offset, the Session-Reflector forwards the 441 packet using the next SID in the SRH or inner IPv6 header in the 442 packet (just like the data packets for the normal traffic). 444 +---------------------------------------------------------------+ 445 | IP Header | 446 . Source IP Address = Session-Sender IPv6 Address . 447 . Destination IP Address = Destination IPv6 Address . 448 . . 449 +---------------------------------------------------------------+ 450 | SRH as specified in RFC 8754 | 451 . . 452 . SRv6 Endpoint End.TSF (value TBA3 or TBA4) . 453 . . 454 +---------------------------------------------------------------+ 455 | IP Header | 456 . Source IP Address = Session-Reflector IPv6 Address . 457 . Destination IP Address = Session-Sender IPv6 Address . 458 . . 459 +---------------------------------------------------------------+ 460 | UDP Header | 461 . Source Port = As chosen by Session-Sender . 462 . Destination Port = As chosen by Session-Sender . 463 . . 464 +---------------------------------------------------------------+ 465 | Payload = Test Packet as specified in Section 3 of RFC 8972 | 466 . in Figure 1 and Figure 3 . 467 . . 468 +---------------------------------------------------------------+ 470 Figure 4: Example STAMP Test Packet with Endpoint Function for SRv6 472 4.2.1. Timestamp Endpoint Function Assignment 474 The Timestamp Endpoint Functions for "Timestamp and Forward" can be 475 signaled using one of the following methods: 477 * Timestamp Endpoint Functions (values TBA3 and TBA4) assigned by 478 IANA from the "SRv6 Endpoint Behaviors Registry". For endpoint 479 behaviour (value TBA3), the timestamp offset is fixed at byte- 480 offset 16 from the start of the payload for the STAMP test packets 481 in unauthenticated mode, and endpoint behaviour (value TBA4) at 482 byte-offset 32 from the start of the payload for the STAMP test 483 packets in authenticated mode, both using the timestamp format 484 64-bit PTPv2. 486 * Timestamp Endpoint Functions assigned by a Controller. The 487 Controller provisions the values on both Session-Sender and 488 Session-Reflector, as well as timestamp offsets and timestamp 489 formats. 491 * Timestamp Endpoint Functions assigned by the Session-Reflector. 492 The signaling and IGP flooding extension for the endpoint 493 functions (including timestamp offsets and timestamp formats) are 494 outside the scope of this document. 496 4.2.2. Node Capability for Timestamp Endpoint Function 498 The STAMP Session-Sender needs to know if the Session-Reflector can 499 process the Timestamp Endpoint Function to avoid dropping test 500 packets. The signaling extension for this capability exchange is 501 outside the scope of this document. 503 5. Example Failure Notifications 505 The timestamps T1 and T2 are used to measure the one-way delay. The 506 delay metrics for an end-to-end SR path are notified, for example, 507 when consecutive M number of test packets have measured delay values 508 exceed the user-configured threshold TH, where M (Delay Exceeded 509 Packet Count) and TH (Absolute and Percentage Delay Exceeded 510 Threshold) are also locally provisioned values. 512 The round-trip packet loss for an end-to-end SR path is calculated 513 using the Sequence Number in the Session-Sender test packets. The 514 packet loss metric is notified when X number of Session-Sender test 515 packets were lost out of last Y number of test packets transmitted by 516 the Session-Sender, where Threshold XofY is locally provisioned 517 value. 519 STAMP session state as UP (i.e. Connectivity verification success) 520 for an end-to-end SR path is initially notified as soon as one or 521 more return test packets are received at the Session-Sender. 523 STAMP session state as DOWN (i.e. Connectivity verification failure) 524 for an end-to-end SR path is notified when consecutive N number of 525 return test packets are not received at the Session-Sender, where N 526 (Missed Packet Count) is a locally provisioned value. 528 In the loopback mode, a connectivity verification failure on the 529 reverse direction path can cause the return test packets to not reach 530 the Session-Sender. This is also true in the case where the return 531 test packets are generated by the stateless Session-Reflector in two- 532 way measurement. The stateful Session-Reflector can solve this issue 533 by maintaining the forwarding direction state and notifying a 534 connectivity verification success and failure to the Session-Sender. 536 6. Security Considerations 538 The STAMP protocol is intended for deployment in limited domains 539 [RFC8799]. As such, it assumes that a node involved in the STAMP 540 protocol operation has previously verified the integrity of the path 541 and the identity of the far-end Session-Reflector. 543 The security considerations specified in [RFC8762] and [RFC8972] also 544 apply to the procedures defined in this document. Specifically, the 545 message integrity protection using HMAC, as defined in Section 4.4 of 546 [RFC8762] also apply to the procedure described in this document. 548 7. IANA Considerations 550 IANA maintains the "Special-Purpose Multiprotocol Label Switching 551 (MPLS) Label Values" registry (see ). IANA is requested to 553 allocate Timestamp Label value from the "Extended Special-Purpose 554 MPLS Label Values" registry: 556 +-------------+---------------------------------+---------------+ 557 | Value | Description | Reference | 558 +-------------+---------------------------------+---------------+ 559 | TBA1 | Timestamp Label | This document | 560 | | for offset 16 for STAMP | | 561 | | in Unauthenticated Mode | | 562 +-------------+---------------------------------+---------------+ 563 | TBA2 | Timestamp Label | This document | 564 | | for offset 32 for STAMP | | 565 | | in Authenticated Mode | | 566 +-------------+---------------------------------+---------------+ 568 IANA is requested to allocate, within the "SRv6 Endpoint Behaviors 569 Registry" sub-registry belonging to the top-level "Segment Routing 570 Parameters" registry [RFC8986], the following allocation: 572 +-------------+---------------------------------+---------------+ 573 | Value | Endpoint Behavior | Reference | 574 +-------------+---------------------------------+---------------+ 575 | TBA3 | End.TSF (Timestamp and Forward) | This document | 576 | | for offset 16 for STAMP | | 577 | | in Unauthenticated Mode | | 578 +-------------+---------------------------------+---------------+ 579 | TBA4 | End.TSF (Timestamp and Forward) | This document | 580 | | for offset 32 for STAMP | | 581 | | in Authenticated Mode | | 582 +-------------+---------------------------------+---------------+ 584 8. References 586 8.1. Normative References 588 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 589 DOI 10.17487/RFC0768, August 1980, 590 . 592 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 593 Requirement Levels", BCP 14, RFC 2119, 594 DOI 10.17487/RFC2119, March 1997, 595 . 597 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 598 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 599 May 2017, . 601 [RFC8762] Mirsky, G., Jun, G., Nydell, H., and R. Foote, "Simple 602 Two-Way Active Measurement Protocol", RFC 8762, 603 DOI 10.17487/RFC8762, March 2020, 604 . 606 [RFC8972] Mirsky, G., Min, X., Nydell, H., Foote, R., Masputra, A., 607 and E. Ruffini, "Simple Two-Way Active Measurement 608 Protocol Optional Extensions", RFC 8972, 609 DOI 10.17487/RFC8972, January 2021, 610 . 612 [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, 613 D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 614 (SRv6) Network Programming", RFC 8986, 615 DOI 10.17487/RFC8986, February 2021, 616 . 618 [I-D.ietf-spring-stamp-srpm] 619 Gandhi, R., Filsfils, C., Voyer, D., Chen, M., Janssens, 620 B., and R. Foote, "Performance Measurement Using Simple 621 TWAMP (STAMP) for Segment Routing Networks", Work in 622 Progress, Internet-Draft, draft-ietf-spring-stamp-srpm-01, 623 6 July 2021, . 626 8.2. Informative References 628 [IEEE1588] IEEE, "1588-2008 IEEE Standard for a Precision Clock 629 Synchronization Protocol for Networked Measurement and 630 Control Systems", March 2008. 632 [RFC7880] Pignataro, C., Ward, D., Akiya, N., Bhatia, M., and S. 633 Pallagatti, "Seamless Bidirectional Forwarding Detection 634 (S-BFD)", RFC 7880, DOI 10.17487/RFC7880, July 2016, 635 . 637 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 638 Decraene, B., Litkowski, S., and R. Shakir, "Segment 639 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 640 July 2018, . 642 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 643 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 644 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 645 . 647 [RFC8799] Carpenter, B. and B. Liu, "Limited Domains and Internet 648 Protocols", RFC 8799, DOI 10.17487/RFC8799, July 2020, 649 . 651 [RFC9017] Andersson, L., Kompella, K., and A. Farrel, "Special- 652 Purpose Label Terminology", RFC 9017, 653 DOI 10.17487/RFC9017, April 2021, 654 . 656 [I-D.ietf-spring-segment-routing-policy] 657 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 658 P. Mattes, "Segment Routing Policy Architecture", Work in 659 Progress, Internet-Draft, draft-ietf-spring-segment- 660 routing-policy-13, 28 May 2021, 661 . 664 [I-D.ietf-pce-binding-label-sid] 665 Sivabalan, S., Filsfils, C., Tantsura, J., Previdi, S., 666 and C. L. (editor), "Carrying Binding Label/Segment 667 Identifier in PCE-based Networks.", Work in Progress, 668 Internet-Draft, draft-ietf-pce-binding-label-sid-10, 10 669 July 2021, . 672 [I-D.ietf-pce-sr-bidir-path] 673 Li, C., Chen, M., Cheng, W., Gandhi, R., and Q. Xiong, 674 "Path Computation Element Communication Protocol (PCEP) 675 Extensions for Associated Bidirectional Segment Routing 676 (SR) Paths", Work in Progress, Internet-Draft, draft-ietf- 677 pce-sr-bidir-path-07, 12 July 2021, 678 . 681 Acknowledgments 683 The authors would like to thank Greg Mirsky, Kireeti Kompella, and 684 Adrian Farrel for providing useful comments. 686 Authors' Addresses 688 Rakesh Gandhi (editor) 689 Cisco Systems, Inc. 690 Canada 692 Email: rgandhi@cisco.com 694 Clarence Filsfils 695 Cisco Systems, Inc. 697 Email: cfilsfil@cisco.com 699 Navin Vaghamshi 700 Reliance 702 Email: Navin.Vaghamshi@ril.com 704 Moses Nagarajah 705 Telstra 707 Email: Moses.Nagarajah@team.telstra.com 708 Richard Foote 709 Nokia 711 Email: footer.foote@nokia.com 713 Mach(Guoyi) Chen 714 Huawei 716 Email: mach.chen@huawei.com