idnits 2.17.1 draft-gandhi-spring-sr-enhanced-plm-02.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 11, 2020) is 1378 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 (-11) exists of draft-gandhi-spring-twamp-srpm-09 == Outdated reference: A later version (-07) exists of draft-gandhi-spring-stamp-srpm-01 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-07 == Outdated reference: A later version (-28) exists of draft-ietf-spring-srv6-network-programming-16 == Outdated reference: A later version (-06) exists of draft-ietf-mpls-spl-terminology-02 == Outdated reference: A later version (-16) exists of draft-ietf-pce-binding-label-sid-03 == Outdated reference: A later version (-13) exists of draft-ietf-pce-sr-bidir-path-02 Summary: 0 errors (**), 0 flaws (~~), 8 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: January 12, 2021 N. Vaghamshi 6 Reliance 7 M. Nagarajah 8 Telstra 9 R. Foote 10 Nokia 11 July 11, 2020 13 Enhanced Performance Delay and Liveness Monitoring in Segment Routing 14 Networks 15 draft-gandhi-spring-sr-enhanced-plm-02 17 Abstract 19 Segment Routing (SR) leverages the source routing paradigm. SR is 20 applicable to both Multiprotocol Label Switching (SR-MPLS) and IPv6 21 (SRv6) data planes. This document defines procedure for Enhanced 22 Performance Delay and Liveness Monitoring (PDLM) in Segment Routing 23 networks. The procedure uses the probe messages defined in RFC 5357 24 (Two-Way Active Measurement Protocol (TWAMP) Light) and RFC 8762 25 (Simple Two-Way Active Measurement Protocol (STAMP)) for end-to-end 26 SR Paths including SR Policies with both SR-MPLS and SRv6 data 27 planes. 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 January 12, 2021. 46 Copyright Notice 48 Copyright (c) 2020 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (https://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Conventions Used in This Document . . . . . . . . . . . . . . 4 65 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 66 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4 67 2.3. Reference Topology . . . . . . . . . . . . . . . . . . . 5 68 2.4. Loopback Mode . . . . . . . . . . . . . . . . . . . . . . 5 69 3. Probe Messages . . . . . . . . . . . . . . . . . . . . . . . 5 70 3.1. Example Provisioning Model . . . . . . . . . . . . . . . 6 71 4. Performance Delay and Liveness Monitoring . . . . . . . . . . 7 72 4.1. Probe Message for SR-MPLS . . . . . . . . . . . . . . . . 7 73 4.2. Probe Message for SRv6 . . . . . . . . . . . . . . . . . 8 74 5. Enhanced Performance Delay and Liveness Monitoring . . . . . 9 75 5.1. Loopback Mode Enabled with Network Programming . . . . . 9 76 5.2. Probe Message with Network Programming for SR-MPLS . . . 10 77 5.2.1. Node Capability for Timestamp Label . . . . . . . . . 11 78 5.2.2. Timestamp Label Allocation . . . . . . . . . . . . . 11 79 5.3. Probe Message with Network Programming for SRv6 . . . . . 12 80 6. ECMP Handling . . . . . . . . . . . . . . . . . . . . . . . . 13 81 7. Failure Notification . . . . . . . . . . . . . . . . . . . . 13 82 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 83 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 84 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 85 10.1. Normative References . . . . . . . . . . . . . . . . . . 15 86 10.2. Informative References . . . . . . . . . . . . . . . . . 15 87 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 17 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 90 1. Introduction 92 Segment Routing (SR) leverages the source routing paradigm and 93 greatly simplifies network operations for Software Defined Networks 94 (SDNs). SR is applicable to both Multiprotocol Label Switching (SR- 95 MPLS) and IPv6 (SRv6) data planes [RFC8402]. SR takes advantage of 96 the Equal-Cost Multipaths (ECMPs) between source and transit nodes, 97 between transit nodes and between transit and destination nodes. SR 98 Policies as defined in [I-D.ietf-spring-segment-routing-policy] are 99 used to steer traffic through a specific, user-defined paths using a 100 stack of Segments. Built-in Liveness Monitoring for detecting faults 101 as well as Performance Delay Measurement (DM) and Loss Measurement 102 (LM) are essential requirements to provide Service Level Agreements 103 (SLAs) in SR networks. 105 The One-Way Active Measurement Protocol (OWAMP) defined in [RFC4656] 106 and Two-Way Active Measurement Protocol (TWAMP) defined in [RFC5357] 107 provide capabilities for the measurement of various performance 108 metrics in IP networks using probe messages. The TWAMP Light 109 [Appendix I in RFC5357] and the Simple Two-way Active Measurement 110 Protocol (STAMP) [RFC8762] provide simplified mechanisms for active 111 performance measurement in IP networks, alleviating the need for 112 control-channel signaling by using configuration data model to 113 provision a test-channel. 115 [I-D.gandhi-spring-twamp-srpm] defines procedure for performance 116 measurement using TWAMP Light messages with user-defined IP/UDP paths 117 in SR networks. [I-D.gandhi-spring-stamp-srpm] defines similar 118 procedure using STAMP messages in SR networks. The procedure for 119 one-way and two-way modes defined for delay measurement can also be 120 applied to liveness monitoring of SR Paths. However, it limits the 121 scale for number of PM sessions and fault detection interval since 122 the probe query messages need to be punted from the forwarding path 123 (to slow path or control plane) and response messages need to be 124 injected. 126 For Liveness Monitoring, Seamless Bidirectional Forwarding Detection 127 (S-BFD) [RFC7880] can be used in Segment Routing networks. However, 128 S-BFD requires protocol support on the reflector node to process the 129 S-BFD packets as packets need to be punted from the forwarding path 130 in order to send the reply thereby limiting the scale for number of 131 PM sessions and fault detection interval. In addition, S-BFD 132 protocol does not have the capability today to enable performance 133 delay monitoring in SR networks. Enabling multiple protocols in SR 134 networks, S-BFD for liveness monitoring and TWAMP Light or STAMP for 135 performance delay monitoring increases the deployment and operational 136 complexities in SR networks. 138 This document defines procedure for Enhanced Performance Delay and 139 Liveness Monitoring (PDLM) in Segment Routing networks. The 140 procedure uses the probe messages defined in [RFC5357] (TWAMP Light) 141 and [RFC8762] (STAMP) for end-to-end SR Paths including SR Policies 142 with both SR-MPLS and SRv6 data planes. 144 2. Conventions Used in This Document 146 2.1. Requirements Language 148 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 149 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 150 document are to be interpreted as described in [RFC2119] [RFC8174] 151 when, and only when, they appear in all capitals, as shown here. 153 2.2. Abbreviations 155 BFD: Bidirectional Forwarding Detection. 157 BSID: Binding Segment ID. 159 DM: Delay Measurement. 161 ECMP: Equal Cost Multi-Path. 163 LM: Loss Measurement. 165 MPLS: Multiprotocol Label Switching. 167 OWAMP: One-Way Active Measurement Protocol. 169 PDLM: Performance Delay and Liveness Monitoring. 171 PM: Performance Measurement. 173 PTP: Precision Time Protocol. 175 SID: Segment ID. 177 SL: Segment List. 179 SR: Segment Routing. 181 SRH: Segment Routing Header. 183 SR-MPLS: Segment Routing with MPLS data plane. 185 SRv6: Segment Routing with IPv6 data plane. 187 STAMP: Simple Two-way Active Measurement Protocol. 189 TWAMP: Two-Way Active Measurement Protocol. 191 2.3. Reference Topology 193 In the reference topology shown below, the nodes R1 and R5 are 194 connected via Point-to-Point (P2P) SR Path such as SR Policy 195 [I-D.ietf-spring-segment-routing-policy] originating on node R1 with 196 endpoint on node R5. 198 t1 199 / 200 +-------+ Probe +-------+ 201 | | - - - - - - - - - - | | 202 | R1 |====================|| R5 | 203 | |<- - - - - - - - - - | | 204 +-------+ Return Probe +-------+ 205 \ 206 t4 207 Sender Reflector 208 (Simply Forward) 210 Figure 1: Reference Topology 212 2.4. Loopback Mode 214 In loopback mode, the sender node R1 initiates probe messages and the 215 reflector node R5 forwards them back to the sender node R1 just like 216 data packets for the normal traffic. The probe messages are not 217 punted at the reflector node and it does not process them and 218 generate response messages. The reflector node must not drop the 219 loopback probe messages, for example, due to a local policy 220 provisioned on the node. 222 3. Probe Messages 224 The TWAMP Light probe messages for delay measurement as defined in 225 [RFC5357] or STAMP probe messages as defined in [RFC8762] are sent by 226 the sender node R1 towards the reflector node R5 in loopback mode as 227 shown in Figure 1. The probe messages are sent by the sender node on 228 the congruent path of the data traffic flowing on the SR Path. 230 Both Source and Destination UDP ports in the probe messages are 231 allocated dynamically or user-configured from the range specified in 232 [RFC8762] and are different than the ports used for TWAMP Light and 233 STAMP sessions. The Source and Destination IP addresses in the probe 234 messages are set to the reflector and the sender node addresses, 235 respectively (representing the reverse path). The IPv4 Time To Live 236 (TTL) and IPv6 Hop Limit (HL) are set to 255. 238 No PM session is created on the reflector node R5. As the probe 239 message is not punted on the reflector node for processing, the 240 Sender copies the 'Sequence Number' in 'Session-Sender Sequence 241 Number' field directly. Also, the Sender Timestamp, Sender Error 242 Estimate and Sender TTL fields [RFC5357] [RFC8762] in the probe 243 message are not used. The rest of the fields are set as defined in 244 [RFC5357] [RFC8762] 246 Timestamp format preferred is 64-bit PTPv2 [IEEE1588] as specified in 247 [RFC8186], implemented in hardware. The NTP timestamp format MUST be 248 supported [RFC5357], however, since PTPv2 is widely used, it SHOULD 249 also be supported. In addition to adding the timestamp in the 250 message, the "Error Estimate" field in the payload of the message can 251 be updated using the procedure defined in [RFC4656]. 253 3.1. Example Provisioning Model 255 An example provisioning model and typical measurement parameters are 256 shown in Figure 2: 258 +------------+ 259 | Controller | 260 +------------+ 261 PDLM Mode / \ Network Programming Label 262 LB or Enhanced Mode / \ Timestamp2 Offset 263 Measurement Protocol / \ Timestamp Format 264 Missed Probe Message Count / \ 265 Network Programming Label / \ 266 Timestamp Format / \ 267 Delay Threshold/Count / \ 268 Source/Dest UDP Ports / \ 269 v v 270 +-------+ +-------+ 271 | | | | 272 | R1 |============| R5 | 273 | | SR Path | | 274 +-------+ +-------+ 275 Sender Reflector 277 Figure 2: Example Provisioning Model 279 Example of Measurement Protocol is TWAMP Light and STAMP, example of 280 Timestamp Format is 64-bit PTPv2 [IEEE1588] and NTP, etc. 282 The mechanisms to provision the sender and reflector nodes are 283 outside the scope of this document. 285 4. Performance Delay and Liveness Monitoring 287 For performance delay and liveness monitoring of an end-to-end SR 288 Path including SR Policy, PM probes in loopback mode is used. The PM 289 probe messages are sent by the sender (head-end) node R1 to the 290 reflector (endpoint) node R5 of the SR Policy as shown in Figure 1. 292 The probe messages are sent using the Segment List (SL) of the 293 Candidate-paths of the SR Policy 294 [I-D.ietf-spring-segment-routing-policy]. When a Candidate-path has 295 more than one Segment Lists, multiple probe messages are sent, one 296 using each Segment List. The return probe messages are received by 297 the sender node via IP/UDP [RFC0768] return path by default. The 298 Segment List of the return SR path can be added in the probe message 299 header to receive the return probe message on a specific path using 300 the mechanisms defined in [I-D.ietf-pce-binding-label-sid] and 301 [I-D.ietf-pce-sr-bidir-path]. 303 4.1. Probe Message for SR-MPLS 305 The TWAMP Light or STAMP probe messages for SR-MPLS data plane are 306 sent using the MPLS header containing the label stack of the SR 307 Policy as shown in Figure 3. In case of IP/UDP return path, the MPLS 308 header is removed by the reflector node. The label stack can contain 309 a reverse SR-MPLS path to receive the return probe message on a 310 specific path. In this case, the MPLS header will not be removed by 311 the reflector node. 313 0 1 2 3 314 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 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 | Label(1) | TC |S| TTL | 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 . . 319 . . 320 . . 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 | Label(n) | TC |S| TTL | 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 | IP Header | 325 . Source IP Address = Reflector IPv4 or IPv6 Address . 326 . Destination IP Address = Sender IPv4 or IPv6 Address . 327 . Protocol = UDP . 328 . . 329 +---------------------------------------------------------------+ 330 | UDP Header | 331 . Source Port = As chosen by Sender . 332 . Destination Port = As chosen by Sender . 333 . . 334 +---------------------------------------------------------------+ 335 | Payload as defined in Section 4.2.1 of RFC 5357 | | 336 | Payload as defined in Section 4.2 of RFC 8762 | 337 . . 338 +---------------------------------------------------------------+ 340 Figure 3: Example Probe Message for SR-MPLS 342 4.2. Probe Message for SRv6 344 The TWAMP Light or STAMP probe messages for SRv6 data plane are sent 345 using the Segment Routing Header (SRH) [RFC8754] containing the 346 Segment List of the SR Policy as shown in Figure 4. In case of IP/ 347 UDP return path, the SRH is removed by the reflector node. The 348 Segment List can contain a reverse SRv6 path to receive the return 349 probe message on a specific path. In this case, the SRH will not be 350 removed by the reflector node. 352 +---------------------------------------------------------------+ 353 | IP Header | 354 . Source IP Address = Sender IPv6 Address . 355 . Destination IP Address = Destination IPv6 Address . 356 . . 357 +---------------------------------------------------------------+ 358 | SRH as specified in RFC 8754 | 359 . . 360 . . 361 +---------------------------------------------------------------+ 362 | IP Header | 363 . Source IP Address = Reflector IPv6 Address . 364 . Destination IP Address = Sender IPv6 Address . 365 . . 366 +---------------------------------------------------------------+ 367 | UDP Header | 368 . Source Port = As chosen by Sender . 369 . Destination Port = As chosen by Sender . 370 . . 371 +---------------------------------------------------------------+ 372 | Payload as defined in Section 4.2.1 of RFC 5357 | | 373 | Payload as defined in Section 4.2 of RFC 8762 | 374 . . 375 +---------------------------------------------------------------+ 377 Figure 4: Example Probe Message for SRv6 379 5. Enhanced Performance Delay and Liveness Monitoring 381 The enhanced performance delay and liveness monitoring of an end-to- 382 end SR Path including SR Policy is defined using the PM probes in 383 "loopback mode enabled with network programming". 385 5.1. Loopback Mode Enabled with Network Programming 387 In "loopback mode enabled with network programming", both transmit 388 (t1) and receive (t2) timestamps in data plane are collected by the 389 probe messages sent in loopback mode as shown in Figure 5. The 390 network programming function optimizes the "operations of punt, add 391 receive timestamp and inject the probe packet" on the reflector node 392 and it is implemented in hardware. The payload of the probe message 393 is not modified by any intermediate nodes. 395 t1 t2 396 / \ 397 +-------+ Probe +-------+ 398 | | - - - - - - - - - - | | 399 | R1 |====================|| R5 | 400 | |<- - - - - - - - - - | | 401 +-------+ Return Probe +-------+ 402 Sender Reflector 403 (Timestamp, 404 Pop and Forward) 406 Figure 5: Loopback Mode Enabled with Network Programming 408 The sender node adds transmit (t1) timestamp in the payload of the 409 TWAMP Light or STAMP probe message and clears the receive (t2) 410 timestamp. The reflector node adds the receive timestamp in the 411 payload of the received probe message without punting the message to 412 slow-path (or control-plane). The reflector node only adds the 413 receive timestamp if the source or destination address in the probe 414 message matches the local node address to ensure that the receive 415 timestamp is returned by the intended reflector node. 417 The network programming function enables the node to add receive 418 timestamp in the payload of the probe message at a specific offset 419 which is locally provisioned consistently in the network. In TWAMP 420 Light message defined in Section 4.2.1 of [RFC5357] or STAMP message 421 defined in [RFC8762] for delay measurement, the 64-bit receive 422 timestamp is added at byte-offset 16 which is from the start of the 423 payload. 425 5.2. Probe Message with Network Programming for SR-MPLS 427 In this document, new Timestamp Label (value TBD1) is defined for SR- 428 MPLS data plane to enable network programming function for 429 "timestamp, pop and forward" the received packet. 431 In the probe message for SR-MPLS, Timestamp Label is added in the 432 MPLS header as shown in Figure 6, to collect "Receive Timestamp" 433 field in the payload of the TWAMP Light [RFC5357] or STAMP probe 434 message. The label stack for the reverse SR-MPLS path can be added 435 after the Timestamp Label to receive the return probe message on a 436 specific path. When a node receives a message with Timestamp Label, 437 after timestamping the message at a specific offset, the node pops 438 the Timestamp Label and forwards the message using the next label or 439 IP header in the message (just like the data packets for the normal 440 traffic). 442 0 1 2 3 443 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 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 | Label(1) | TC |S| TTL | 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 . . 448 . . 449 . . 450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 451 | Label(n) | TC |S| TTL | 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 | Timestamp Label (TBA1) | TC |S| TTL | 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 | IP Header | 456 . Source IP Address = Reflector IPv4 or IPv6 Address . 457 . Destination IP Address = Sender IPv4 or IPv6 Address . 458 . Protocol = UDP . 459 . . 460 +---------------------------------------------------------------+ 461 | UDP Header | 462 . Source Port = As chosen by Sender . 463 . Destination Port = As chosen by Sender . 464 . . 465 +---------------------------------------------------------------+ 466 | Payload as defined in Section 4.2.1 of RFC 5357 Or | 467 | Payload as defined in Section 4.2 of RFC 8762 | 468 . . 469 +---------------------------------------------------------------+ 471 Figure 6: Example Probe Message with Timestamp Label for SR-MPLS 473 5.2.1. Node Capability for Timestamp Label 475 The ingress node needs to know if the egress node can process the 476 Timestamp Label. The signaling extension for this capability 477 exchange is outside the scope of this document. 479 Another way is to leverage a centralized controller (e.g., SDN 480 controller) to program the ingress and egress nodes. In this case, 481 the controller MUST make sure (e.g., by some capability discovery 482 mechanisms outside the scope of this document) that the egress node 483 can process the Timestamp Label. 485 5.2.2. Timestamp Label Allocation 487 Timestamp Label (value TBA1) can be allocated using one of the 488 following methods: 490 o Labels assigned by IANA with value TBA1 from the Extended Special- 491 Purpose MPLS Values [I-D.ietf-mpls-spl-terminology]. 493 o Labels allocated by a Controller from the global table of the 494 egress node. The Controller provisions the label on both ingress 495 and egress nodes. 497 o Labels allocated by the egress node. The signaling or IGP 498 flooding extension for this is outside the scope of this document. 500 5.3. Probe Message with Network Programming for SRv6 502 In this document, new Endpoint function "Timestamp and Forward (TSF)" 503 (value TBD2) is defined for Segment Routing Header (SRH) [RFC8754] 504 for SRv6 data plane to enable network programming function for 505 "timestamp and forward" the received message. 507 In the probe message for SRv6, END.TSF function is added for the 508 Endpoint Segment Identifier (SID) in SRH [RFC8754] as shown in 509 Figure 7, to collect "Receive Timestamp" field in the payload of the 510 TWAMP Light [RFC5357] or STAMP probe message. When a node receives a 511 packet with END.TSF function for the target SID which is local, after 512 timestamping the packet at a specific offset, the node forwards the 513 packet using the next SID or IP header in the packet (just like the 514 packets for the normal traffic). 516 +---------------------------------------------------------------+ 517 | IP Header | 518 . Source IP Address = Sender IPv6 Address . 519 . Destination IP Address = Destination IPv6 Address . 520 . . 521 +---------------------------------------------------------------+ 522 | SRH as specified in RFC 8754 | 523 . . 524 . . 525 +---------------------------------------------------------------+ 526 | IP Header | 527 . Source IP Address = Reflector IPv6 Address . 528 . Destination IP Address = Sender IPv6 Address . 529 . . 530 +---------------------------------------------------------------+ 531 | UDP Header | 532 . Source Port = As chosen by Sender . 533 . Destination Port = As chosen by Sender . 534 . . 535 +---------------------------------------------------------------+ 536 | Payload as defined in Section 4.2.1 of RFC 5357 Or | 537 | Payload as defined in Section 4.2 of RFC 8762 | 538 . . 539 +---------------------------------------------------------------+ 541 Figure 7: Example Probe Message with Endpoint Function for SRv6 543 6. ECMP Handling 545 An SR Policy can have ECMPs between the source and transit nodes, 546 between transit nodes and between transit and destination nodes. The 547 PM probe messages need to be sent to traverse different ECMP paths to 548 monitor the liveness for an end-to-end SR Policy. 550 Forwarding plane has various hashing functions available to forward 551 packets on specific ECMP paths. In IPv4 header of the PM probe 552 messages, sweeping of Destination Address in 127/8 range can be used 553 to exercise different ECMP paths in the loopback mode as long as the 554 return path is also SR-MPLS. The Flow Label field in the outer IPv6 555 header can also be used for sweeping to exercise different ECMP 556 paths. 558 7. Failure Notification 560 Liveness failure for SR Path is notified when consecutive N number of 561 return probe messages are not received at the sender node, where N 562 (Missed Probe Message Count) is locally provisioned value. 563 Similarly, delay metrics are notified when consecutive M number of 564 probe messages have measured delay values exceed user-configured 565 thresholds (absolute and percentage), where M is also locally 566 provisioned value. 568 In loopback mode, the timestamps t1 and t4 are used to measure round- 569 trip delay. In loopback mode enabled with network programming, the 570 timestamps t1 and t2 are used to measure one-way delay. 572 8. Security Considerations 574 The Performance Delay and Liveness Monitoring is intended for 575 deployment in the well-managed private and service provider networks. 576 As such, it assumes that a node involved in a monitoring operation 577 has previously verified the integrity of the path and the identity of 578 the reflector node. If desired, attacks can be mitigated by 579 performing basic validation and sanity checks, at the sender, of the 580 timestamp fields in received probe messages. The minimal state 581 associated with these protocols also limits the extent of disruption 582 that can be caused by a corrupt or invalid message to a single probe 583 cycle. Use of HMAC-SHA-256 in the authenticated mode protects the 584 data integrity of the probe messages. Cryptographic measures may be 585 enhanced by the correct configuration of access-control lists and 586 firewalls. 588 9. IANA Considerations 590 IANA maintains the "Special-Purpose Multiprotocol Label Switching 591 (MPLS) Label Values" registry (see ). IANA is requested to 593 allocate Timestamp Label value from the "Extended Special-Purpose 594 MPLS Label Values" registry: 596 +-------------+---------------------------------+---------------+ 597 | Value | Description | Reference | 598 +-------------+---------------------------------+---------------+ 599 | TBA1 | Timestamp Label | This document | 600 +-------------+---------------------------------+---------------+ 602 IANA is requested to allocate, within the "SRv6 Endpoint Behaviors 603 Registry" sub-registry belonging to the top-level "Segment-routing 604 with IPv6 data plane (SRv6) Parameters" registry 605 [I-D.ietf-spring-srv6-network-programming], the following allocation: 607 +-------------+---------------------------------+---------------+ 608 | Value | Endpoint Behavior | Reference | 609 +-------------+---------------------------------+---------------+ 610 | TBA2 | END.TSF (Timestamp and Forward) | This document | 611 +-------------+---------------------------------+---------------+ 613 10. References 615 10.1. Normative References 617 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 618 DOI 10.17487/RFC0768, August 1980, 619 . 621 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 622 Requirement Levels", BCP 14, RFC 2119, 623 DOI 10.17487/RFC2119, March 1997, 624 . 626 [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. 627 Zekauskas, "A One-way Active Measurement Protocol 628 (OWAMP)", RFC 4656, DOI 10.17487/RFC4656, September 2006, 629 . 631 [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. 632 Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", 633 RFC 5357, DOI 10.17487/RFC5357, October 2008, 634 . 636 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 637 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 638 May 2017, . 640 [RFC8762] Mirsky, G., Jun, G., Nydell, H., and R. Foote, "Simple 641 Two-Way Active Measurement Protocol", RFC 8762, 642 DOI 10.17487/RFC8762, March 2020, 643 . 645 10.2. Informative References 647 [IEEE1588] 648 IEEE, "1588-2008 IEEE Standard for a Precision Clock 649 Synchronization Protocol for Networked Measurement and 650 Control Systems", March 2008. 652 [RFC7880] Pignataro, C., Ward, D., Akiya, N., Bhatia, M., and S. 653 Pallagatti, "Seamless Bidirectional Forwarding Detection 654 (S-BFD)", RFC 7880, DOI 10.17487/RFC7880, July 2016, 655 . 657 [RFC8186] Mirsky, G. and I. Meilik, "Support of the IEEE 1588 658 Timestamp Format in a Two-Way Active Measurement Protocol 659 (TWAMP)", RFC 8186, DOI 10.17487/RFC8186, June 2017, 660 . 662 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 663 Decraene, B., Litkowski, S., and R. Shakir, "Segment 664 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 665 July 2018, . 667 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 668 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 669 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 670 . 672 [I-D.gandhi-spring-twamp-srpm] 673 Gandhi, R., Filsfils, C., Voyer, D., Chen, M., and B. 674 Janssens, "Performance Measurement Using TWAMP Light for 675 Segment Routing Networks", draft-gandhi-spring-twamp- 676 srpm-09 (work in progress), June 2020. 678 [I-D.gandhi-spring-stamp-srpm] 679 Gandhi, R., Filsfils, C., Voyer, D., Chen, M., and B. 680 Janssens, "Performance Measurement Using STAMP for Segment 681 Routing Networks", draft-gandhi-spring-stamp-srpm-01 (work 682 in progress), June 2020. 684 [I-D.ietf-spring-segment-routing-policy] 685 Filsfils, C., Sivabalan, S., Voyer, D., Bogdanov, A., and 686 P. Mattes, "Segment Routing Policy Architecture", draft- 687 ietf-spring-segment-routing-policy-07 (work in progress), 688 May 2020. 690 [I-D.ietf-spring-srv6-network-programming] 691 Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., 692 Matsushima, S., and Z. Li, "SRv6 Network Programming", 693 draft-ietf-spring-srv6-network-programming-16 (work in 694 progress), June 2020. 696 [I-D.ietf-mpls-spl-terminology] 697 Andersson, L., Kompella, K., and A. Farrel, "Special 698 Purpose Label terminology", draft-ietf-mpls-spl- 699 terminology-02 (work in progress), May 2020. 701 [I-D.ietf-pce-binding-label-sid] 702 Filsfils, C., Sivabalan, S., Tantsura, J., Hardwick, J., 703 Previdi, S., and C. Li, "Carrying Binding Label/Segment-ID 704 in PCE-based Networks.", draft-ietf-pce-binding-label- 705 sid-03 (work in progress), June 2020. 707 [I-D.ietf-pce-sr-bidir-path] 708 Li, C., Chen, M., Cheng, W., Gandhi, R., and Q. Xiong, 709 "PCEP Extensions for Associated Bidirectional Segment 710 Routing (SR) Paths", draft-ietf-pce-sr-bidir-path-02 (work 711 in progress), March 2020. 713 Acknowledgments 715 TBD 717 Authors' Addresses 719 Rakesh Gandhi (editor) 720 Cisco Systems, Inc. 721 Canada 723 Email: rgandhi@cisco.com 725 Clarence Filsfils 726 Cisco Systems, Inc. 728 Email: cfilsfil@cisco.com 730 Navin Vaghamshi 731 Reliance 733 Email: Navin.Vaghamshi@ril.com 735 Moses Nagarajah 736 Telstra 738 Email: Moses.Nagarajah@team.telstra.com 740 Richard Foote 741 Nokia 743 Email: footer.foote@nokia.com