idnits 2.17.1 draft-gandhi-spring-sr-enhanced-plm-03.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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (September 26, 2020) is 1308 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-10 == Outdated reference: A later version (-07) exists of draft-gandhi-spring-stamp-srpm-02 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-08 == Outdated reference: A later version (-28) exists of draft-ietf-spring-srv6-network-programming-20 == Outdated reference: A later version (-06) exists of draft-ietf-mpls-spl-terminology-04 == 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-03 Summary: 0 errors (**), 0 flaws (~~), 9 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: March 30, 2021 N. Vaghamshi 6 Reliance 7 M. Nagarajah 8 Telstra 9 R. Foote 10 Nokia 11 September 26, 2020 13 Enhanced Performance Delay and Liveness Monitoring in Segment Routing 14 Networks 15 draft-gandhi-spring-sr-enhanced-plm-03 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 leverages the probe messages compatible with 24 the delay measurement message formats defined in RFC 5357 (Two-Way 25 Active Measurement Protocol (TWAMP)) and RFC 8762 (Simple Two-Way 26 Active Measurement Protocol (STAMP)) and is applicable to end-to-end 27 SR Paths including SR Policies for both SR-MPLS and SRv6 data 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 March 30, 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 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 3.1. Loopback Mode . . . . . . . . . . . . . . . . . . . . . . 5 70 3.2. Loopback Mode Enabled with Network Programming Function . 6 71 3.3. Example Provisioning Model . . . . . . . . . . . . . . . 6 72 4. Probe Message Formats . . . . . . . . . . . . . . . . . . . . 7 73 5. Performance Delay and Liveness Monitoring . . . . . . . . . . 9 74 5.1. Probe Message for SR-MPLS . . . . . . . . . . . . . . . . 9 75 5.2. Probe Message for SRv6 . . . . . . . . . . . . . . . . . 10 76 6. Enhanced Performance Delay and Liveness Monitoring . . . . . 11 77 6.1. Probe Message with Timestamp Label for SR-MPLS . . . . . 11 78 6.1.1. Timestamp Label Allocation . . . . . . . . . . . . . 12 79 6.1.2. Node Capability for Timestamp Label . . . . . . . . . 13 80 6.2. Probe Message with Timestamp Endpoint Function for SRv6 . 13 81 6.2.1. Timestamp Endpoint Function Assignment . . . . . . . 14 82 6.2.2. Node Capability for Timestamp Endpoint Function . . . 15 83 7. ECMP Handling . . . . . . . . . . . . . . . . . . . . . . . . 15 84 8. Failure Notification . . . . . . . . . . . . . . . . . . . . 15 85 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 86 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 87 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 88 11.1. Normative References . . . . . . . . . . . . . . . . . . 16 89 11.2. Informative References . . . . . . . . . . . . . . . . . 17 90 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 19 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 93 1. Introduction 95 Segment Routing (SR) leverages the source routing paradigm and 96 greatly simplifies network operations for Software Defined Networks 97 (SDNs). SR is applicable to both Multiprotocol Label Switching (SR- 98 MPLS) and IPv6 (SRv6) data planes [RFC8402]. SR takes advantage of 99 the Equal-Cost Multipaths (ECMPs) between source and transit nodes, 100 between transit nodes and between transit and destination nodes. SR 101 Policies as defined in [I-D.ietf-spring-segment-routing-policy] are 102 used to steer traffic through a specific, user-defined paths using a 103 stack of Segments. Built-in Performance Delay Measurement (DM) as 104 well as Liveness Monitoring for Connectivity Verification (CV) and 105 Continuity Check (CC) are essential requirements to provide Service 106 Level Agreements (SLAs) in SR networks. 108 The One-Way Active Measurement Protocol (OWAMP) defined in [RFC4656] 109 and Two-Way Active Measurement Protocol (TWAMP) defined in [RFC5357] 110 provide capabilities for the measurement of various performance 111 metrics in IP networks using probe messages. The TWAMP Light 112 [Appendix I in RFC5357] and the Simple Two-way Active Measurement 113 Protocol (STAMP) [RFC8762] provide simplified mechanisms for active 114 performance measurement in IP networks, alleviating the need for 115 control-channel signaling by using configuration data model to 116 provision a test-channel. 118 [I-D.gandhi-spring-twamp-srpm] defines procedure for performance 119 measurement using TWAMP Light messages with user-defined IP/UDP paths 120 in SR networks. [I-D.gandhi-spring-stamp-srpm] defines similar 121 procedure using STAMP messages in SR networks. The procedure for 122 one-way and two-way modes defined for delay measurement can also be 123 applied to liveness monitoring of SR Paths. However, it limits the 124 scale for number of PM sessions and fault detection interval since 125 the probe query messages need to be punted from the forwarding path 126 (to slow path or control plane) and response messages need to be 127 injected. 129 For Liveness Monitoring, Seamless Bidirectional Forwarding Detection 130 (S-BFD) [RFC7880] can be used in Segment Routing networks. However, 131 S-BFD requires protocol support on the reflector node to process the 132 S-BFD packets as packets need to be punted from the forwarding path 133 in order to send the reply thereby limiting the scale for number of 134 PM sessions and fault detection interval. In addition, S-BFD 135 protocol does not have the capability today to enable performance 136 delay monitoring in SR networks. Enabling multiple protocols in SR 137 networks, S-BFD for liveness monitoring and TWAMP Light or STAMP for 138 performance delay monitoring increases the deployment and operational 139 complexities in SR networks. 141 This document defines procedure for Enhanced Performance Delay and 142 Liveness Monitoring (PDLM) in Segment Routing networks. The 143 procedure leverages the probe messages compatible with the delay 144 measurement message formats defined in RFC 5357 (Two-Way Active 145 Measurement Protocol (TWAMP)) and RFC 8762 (Simple Two-Way Active 146 Measurement Protocol (STAMP)) and is applicable to end-to-end SR 147 Paths including SR Policies for both SR-MPLS and SRv6 data planes. 149 2. Conventions Used in This Document 151 2.1. Requirements Language 153 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 154 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 155 document are to be interpreted as described in [RFC2119] [RFC8174] 156 when, and only when, they appear in all capitals, as shown here. 158 2.2. Abbreviations 160 BFD: Bidirectional Forwarding Detection. 162 BSID: Binding Segment ID. 164 DM: Delay Measurement. 166 ECMP: Equal Cost Multi-Path. 168 LM: Loss Measurement. 170 MPLS: Multiprotocol Label Switching. 172 OWAMP: One-Way Active Measurement Protocol. 174 PDLM: Performance Delay and Liveness Monitoring. 176 PM: Performance Measurement. 178 PTP: Precision Time Protocol. 180 SID: Segment ID. 182 SL: Segment List. 184 SR: Segment Routing. 186 SRH: Segment Routing Header. 188 SR-MPLS: Segment Routing with MPLS data plane. 190 SRv6: Segment Routing with IPv6 data plane. 192 STAMP: Simple Two-way Active Measurement Protocol. 194 TWAMP: Two-Way Active Measurement Protocol. 196 2.3. Reference Topology 198 In the reference topology shown in Figure 1, the nodes R1 and R5 are 199 connected via Point-to-Point (P2P) SR Path such as SR Policy 200 [I-D.ietf-spring-segment-routing-policy] originating on node R1 with 201 endpoint on node R5. 203 t1 204 / 205 +-------+ Probe +-------+ 206 | | - - - - - - - - - - | | 207 | R1 |====================|| R5 | 208 | |<- - - - - - - - - - | | 209 +-------+ Return Probe +-------+ 210 \ 211 t4 212 Sender Reflector 213 (Simply Forward) 215 Figure 1: Reference Topology 217 3. Overview 219 3.1. Loopback Mode 221 In loopback mode, the sender node R1 initiates probe messages and the 222 reflector node R5 forwards them just like data packets for the normal 223 traffic back to the sender node R1. The probe messages are not 224 punted at the reflector node and it does not process them and 225 generate response messages. The reflector node must not drop the 226 loopback probe messages, for example, due to a local policy 227 provisioned on the node. No PM session is created on the reflector 228 node. 230 The Source and Destination IP addresses in the probe messages are set 231 to the reflector and the sender node addresses, respectively 232 (representing the reverse path). Both Source and Destination UDP 233 ports in the probe messages are allocated dynamically or user- 234 configured from the range specified in [RFC8762]. The UDP ports used 235 in loopback mode are different than the ports used for TWAMP and 236 STAMP sessions. The IPv4 Time To Live (TTL) and IPv6 Hop Limit (HL) 237 are set to 255. 239 3.2. Loopback Mode Enabled with Network Programming Function 241 In "loopback mode enabled with network programming function", both 242 transmit (t1) and receive (t2) timestamps in data plane are collected 243 by the probe messages sent in loopback mode as shown in Figure 2. 244 The network programming function optimizes the "operations of punt 245 and inject the probe packet" on the reflector node as timestamping is 246 implemented in hardware. This helps to achieve higher scale and 247 faster rate, resulting in faster failure detection. 249 t1 t2 250 / \ 251 +-------+ Probe +-------+ 252 | | - - - - - - - - - - | | 253 | R1 |====================|| R5 | 254 | |<- - - - - - - - - - | | 255 +-------+ Return Probe +-------+ 256 Sender Reflector 257 (Timestamp, 258 Pop and Forward) 260 Figure 2: Loopback Mode Enabled with Network Programming Function 262 The sender node adds transmit (t1) timestamp in the payload of the 263 probe message and clears the receive (t2) timestamp. The reflector 264 node adds the receive timestamp in the payload of the received probe 265 message in hardware without punting the message to slow-path (or 266 control-plane). The reflector node only adds the receive timestamp 267 if the source or destination address in the probe message matches the 268 local node address to ensure that the probe message reaches the 269 intended reflector node and the receive timestamp is returned by the 270 that node. The payload of the probe message is not modified by any 271 intermediate nodes. 273 The network programming function enables the node to add receive 274 timestamp in the payload of the probe message at a specific offset 275 which is locally provisioned consistently in the network. In the 276 probe message defined in Figure 4 for delay measurement, the 64-bit 277 receive timestamp is added at byte-offset 16 which is from the start 278 of the payload. 280 3.3. Example Provisioning Model 282 An example provisioning model and typical measurement parameters are 283 shown in Figure 3: 285 +------------+ 286 | Controller | 287 +------------+ 288 PDLM Mode / \ Timestamp Label/SRV6 EP 289 LB or Enhanced Mode / \ Timestamp2 Offset 290 Message Format / \ Timestamp Format 291 Missed Probe Message Count / \ 292 Timestamp Label/SRv6 EP / \ 293 Timestamp Format / \ 294 Delay Threshold/Count / \ 295 Source/Dest UDP Ports / \ 296 v v 297 +-------+ +-------+ 298 | | | | 299 | R1 |============| R5 | 300 | | SR Path | | 301 +-------+ +-------+ 302 Sender Reflector 304 Figure 3: Example Provisioning Model 306 Example of message format is TWAMP and STAMP, example of Timestamp 307 Format is 64-bit PTPv2 [IEEE1588] and NTP, etc. 309 The mechanisms to provision the sender and reflector nodes are 310 outside the scope of this document. 312 4. Probe Message Formats 314 The probe messages compatible with the delay measurement message 315 formats defined in TWAMP [RFC5357] and STAMP [RFC8762] are specified 316 in Figure 4. 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 | Sequence Number | 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 | Transmit Timestamp (t1) | 322 | | 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 | Transmit Error Estimate | MBZ | 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 | Receive Timestamp (t2) | 327 | | 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 | Receive Error Estimate | MBZ | 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 . Variable Length Padding . 332 ~ ~ 333 . . 334 . . 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 TWAMP Compatible Probe Packet Format 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 | Sequence Number | 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 | Transmit Timestamp (t1) | 343 | | 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 | Transmit Error Estimate | SSID | 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 | Receive Timestamp (t2) | 348 | | 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 | Receive Error Estimate | MBZ | 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 | Fixed Length Padding | 353 | | 354 | | 355 | | 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 STAMP Compatible Probe Packet Format 360 Figure 4: Probe Packet Formats 362 Sequence Number is the sequence number of the probe packet according 363 to its transmit order. It starts with zero and is incremented by one 364 for each subsequent packet. 366 Transmit Timestamp and Transmit Error Estimate are the Sender's 367 transmit timestamp and error estimate for the probe packet, 368 respectively. Similarly, Receive Timestamp and Receive Error 369 Estimate are the Reflector's receive timestamp and error estimate, 370 respectively. The timestamp and error estimate fields follow the 371 definition and formats defined in Section 4.1.2 in [RFC4656]. 372 Timestamp format preferred is 64-bit PTPv2 [IEEE1588] as specified in 373 [RFC8186], implemented in hardware. 375 5. Performance Delay and Liveness Monitoring 377 For performance delay and liveness monitoring of an end-to-end SR 378 Path including SR Policy, PM probes in loopback mode is used. 380 For SR Policy, the probe messages are sent using the Segment List 381 (SL) of the Candidate-path [I-D.ietf-spring-segment-routing-policy]. 382 When a Candidate-path has more than one Segment Lists, multiple probe 383 messages are sent, one using each Segment List. The return probe 384 messages are received by the sender node via IP/UDP [RFC0768] return 385 path by default. The Segment List of the return SR path can be added 386 in the probe message header to receive the return probe message on a 387 specific path using the Binding SID [I-D.ietf-pce-binding-label-sid] 388 or Segment List of the Reverse SR Policy 389 [I-D.ietf-pce-sr-bidir-path]. 391 5.1. Probe Message for SR-MPLS 393 The probe messages are sent using the MPLS header containing the 394 label stack of the SR Policy as shown in Figure 5. In case of IP/UDP 395 return path, the MPLS header is removed by the reflector node. The 396 label stack can contain a reverse SR-MPLS path to receive the return 397 probe message on a specific path. In this case, the MPLS header will 398 not be removed by the reflector node. 400 0 1 2 3 401 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 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 | Label(1) | TC |S| TTL | 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 . . 406 . . 407 . . 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 | Label(n) | TC |S| TTL | 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 | IP Header | 412 . Source IP Address = Reflector IPv4 or IPv6 Address . 413 . Destination IP Address = Sender IPv4 or IPv6 Address . 414 . Protocol = UDP . 415 . . 416 +---------------------------------------------------------------+ 417 | UDP Header | 418 . Source Port = As chosen by Sender . 419 . Destination Port = As chosen by Sender . 420 . . 421 +---------------------------------------------------------------+ 422 | Payload as defined in Figure 4 | 423 . . 424 +---------------------------------------------------------------+ 426 Figure 5: Example Probe Message for SR-MPLS 428 5.2. Probe Message for SRv6 430 The probe messages for SRv6 data plane are sent using the Segment 431 Routing Header (SRH) [RFC8754] containing the Segment List of the SR 432 Policy as shown in Figure 6. In case of IP/UDP return path, the SRH 433 is removed by the reflector node. The Segment List can contain a 434 reverse SRv6 path to receive the return probe message on a specific 435 path. In this case, the SRH will not be removed by the reflector 436 node. When the return probe message contains an SRH at the sender 437 node, the procedure defined for upper-layer header processing for 438 SRv6 SIDs in [I-D.ietf-spring-srv6-network-programming] is used to 439 process the UDP header in the received probe messages. 441 +---------------------------------------------------------------+ 442 | IP Header | 443 . Source IP Address = Sender IPv6 Address . 444 . Destination IP Address = Destination IPv6 Address . 445 . . 446 +---------------------------------------------------------------+ 447 | SRH as specified in RFC 8754 | 448 . . 449 . . 450 +---------------------------------------------------------------+ 451 | IP Header | 452 . Source IP Address = Reflector IPv6 Address . 453 . Destination IP Address = Sender IPv6 Address . 454 . . 455 +---------------------------------------------------------------+ 456 | UDP Header | 457 . Source Port = As chosen by Sender . 458 . Destination Port = As chosen by Sender . 459 . . 460 +---------------------------------------------------------------+ 461 | Payload as defined in Figure 4 | 462 . . 463 +---------------------------------------------------------------+ 465 Figure 6: Example Probe Message for SRv6 467 6. Enhanced Performance Delay and Liveness Monitoring 469 The enhanced performance delay and liveness monitoring of an end-to- 470 end SR Path including SR Policy is defined using the PM probes in 471 "loopback mode enabled with network programming function". 473 6.1. Probe Message with Timestamp Label for SR-MPLS 475 In this document, new Timestamp Label (Extended Special-Purpose value 476 TBD1) is defined for SR-MPLS data plane to enable network programming 477 function for "timestamp, pop and forward" the received packet. 479 In the probe message for SR-MPLS, Timestamp Label is added in the 480 MPLS header as shown in Figure 7, to collect "Receive Timestamp" 481 field in the payload of the probe message. The label stack for the 482 reverse SR-MPLS path can be added after the Timestamp Label to 483 receive the return probe message on a specific path. When a node 484 receives a message with Timestamp Label, after timestamping the 485 packet at a specific offset, the node pops the Timestamp Label and 486 forwards the message using the next label or IP header in the message 487 (just like the data packets for the normal traffic). 489 0 1 2 3 490 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 491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 | Label(1) | TC |S| TTL | 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 . . 495 . . 496 . . 497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 498 | Label(n) | TC |S| TTL | 499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 500 | Extension Label (15) | TC |S| TTL | 501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 502 | Timestamp Label (TBA1) | TC |S| TTL | 503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 504 | IP Header | 505 . Source IP Address = Reflector IPv4 or IPv6 Address . 506 . Destination IP Address = Sender IPv4 or IPv6 Address . 507 . Protocol = UDP . 508 . . 509 +---------------------------------------------------------------+ 510 | UDP Header | 511 . Source Port = As chosen by Sender . 512 . Destination Port = As chosen by Sender . 513 . . 514 +---------------------------------------------------------------+ 515 | Payload as defined in Figure 4 | 516 . . 517 +---------------------------------------------------------------+ 519 Figure 7: Example Probe Message with Timestamp Label for SR-MPLS 521 6.1.1. Timestamp Label Allocation 523 Timestamp Label can be allocated using one of the following methods: 525 o Label (value TBA1) assigned by IANA from the "Extended Special- 526 Purpose MPLS Values" [I-D.ietf-mpls-spl-terminology]. The 527 timestamp offset is fixed at byte-offset 16 from the start of the 528 payload and timestamp format is 64-bit PTPv2 for this label. 530 o Label allocated by a Controller from the global table of the 531 egress node. The Controller provisions the label on both ingress 532 and egress nodes, as well as timestamp offset and timestamp 533 format. 535 o Label allocated by the egress node. The signaling and IGP 536 flooding extension for the label (including timestamp offset and 537 timestamp format) are outside the scope of this document. 539 6.1.2. Node Capability for Timestamp Label 541 The ingress node needs to know if the egress node can process the 542 Timestamp Label to avoid dropping probe packets. The signaling 543 extension for this capability exchange is outside the scope of this 544 document. 546 6.2. Probe Message with Timestamp Endpoint Function for SRv6 548 In this document, Timestamp Endpoint function for "Timestamp and 549 Forward (TSF)" (SRv6 Endpoint Behaviour value TBD2) is defined for 550 Segment Routing Header (SRH) [RFC8754] for SRv6 data plane to enable 551 network programming function to "timestamp and forward" the received 552 packet. 554 In the probe message for SRv6, End.TSF function is added for the 555 target Segment Identifier (SID) in SRH [RFC8754] as shown in 556 Figure 8, to collect "Receive Timestamp" field in the payload of the 557 probe message. The Segment List for the reverse path can be added 558 after the target SID to receive the return probe message on a 559 specific path. When a reflector node receives a message with End.TSF 560 function for the target SID which is local, after timestamping the 561 packet at a specific offset, the node forwards the packet using the 562 next SID or IP header in the message (just like the data packets for 563 the normal traffic). 565 +---------------------------------------------------------------+ 566 | IP Header | 567 . Source IP Address = Sender IPv6 Address . 568 . Destination IP Address = Destination IPv6 Address . 569 . . 570 +---------------------------------------------------------------+ 571 | SRH as specified in RFC 8754 | 572 . . 573 . SRv6 Endpoint End.TSF (value TBA2) . 574 . . 575 +---------------------------------------------------------------+ 576 | IP Header | 577 . Source IP Address = Reflector IPv6 Address . 578 . Destination IP Address = Sender IPv6 Address . 579 . . 580 +---------------------------------------------------------------+ 581 | UDP Header | 582 . Source Port = As chosen by Sender . 583 . Destination Port = As chosen by Sender . 584 . . 585 +---------------------------------------------------------------+ 586 | Payload as defined in Figure 4 | 587 . . 588 +---------------------------------------------------------------+ 590 Figure 8: Example Probe Message with Endpoint Function for SRv6 592 6.2.1. Timestamp Endpoint Function Assignment 594 Timestamp endpoint function for "Timestamp and Forward" can be 595 signaled using one of the following methods: 597 o Timestamp endpoint function (value TBA2) assigned by IANA from the 598 "SRv6 Endpoint Behaviors Registry". The timestamp offset is fixed 599 at byte-offset 16 from the start of the payload and timestamp 600 format is 64-bit PTPv2 for this endpoint function. 602 o Timestamp endpoint function assigned by a Controller. The 603 Controller provisions the value on both ingress and egress nodes, 604 as well as timestamp offset and timestamp format. 606 o Timestamp endpoint function assigned by the egress node. The 607 signaling and IGP flooding extension for the endpoint function 608 (including timestamp offset and timestamp format) are outside the 609 scope of this document. 611 6.2.2. Node Capability for Timestamp Endpoint Function 613 The ingress node needs to know if the egress node can process the 614 Timestamp Endpoint Function to enable the monitoring. The signaling 615 extension for this capability exchange is outside the scope of this 616 document. 618 7. ECMP Handling 620 An SR Policy can have ECMPs between the source and transit nodes, 621 between transit nodes and between transit and destination nodes. The 622 PM probe messages need to be sent to traverse different ECMP paths to 623 monitor the liveness for an end-to-end SR Policy. 625 Forwarding plane has various hashing functions available to forward 626 packets on specific ECMP paths. In IPv4 header of the PM probe 627 messages, sweeping of Destination Address in 127/8 range can be used 628 to exercise different ECMP paths in the loopback mode as long as the 629 return path is also SR-MPLS. The Flow Label field in the outer IPv6 630 header can also be used for sweeping to exercise different ECMP 631 paths. 633 8. Failure Notification 635 Liveness success for SR Path is initially notified as soon as one or 636 more return probe messages are received at the sender node. 638 Liveness failure for SR Path is notified when consecutive N number of 639 return probe messages are not received at the sender node, where N 640 (Missed Probe Message Count) is locally provisioned value. 641 Similarly, delay metrics are notified as an example when consecutive 642 M number of probe messages have measured delay values exceed user- 643 configured thresholds (absolute and percentage), where M is also 644 locally provisioned value. 646 For the probe messages generated by the Sender node R1 in the 647 loopback mode, a failure on the reverse direction path can also cause 648 the return probe messages to not reach the Sender node. This is also 649 true in case of the probe response messages generated by the 650 Reflector node R5 e.g. to indicate node R1 of any failure on the 651 forward direction path. As such, the probe-based methods have this 652 limitation for the liveness monitoring of the forward direction path. 654 In loopback mode, the timestamps t1 and t4 are used to measure round- 655 trip delay. In loopback mode enabled with network programming 656 function, the timestamps t1 and t2 are used to measure one-way delay. 658 9. Security Considerations 660 The Performance Delay and Liveness Monitoring is intended for 661 deployment in the well-managed private and service provider networks. 662 As such, it assumes that a node involved in a monitoring operation 663 has previously verified the integrity of the path and the identity of 664 the reflector node. If desired, attacks can be mitigated by 665 performing basic validation and sanity checks, at the sender, of the 666 timestamp fields in received probe messages. The minimal state 667 associated with these protocols also limits the extent of disruption 668 that can be caused by a corrupt or invalid message to a single probe 669 cycle. Cryptographic measures may be used by the correct 670 configuration of access-control lists and firewalls. 672 10. IANA Considerations 674 IANA maintains the "Special-Purpose Multiprotocol Label Switching 675 (MPLS) Label Values" registry (see ). IANA is requested to 677 allocate Timestamp Label value from the "Extended Special-Purpose 678 MPLS Label Values" registry: 680 +-------------+---------------------------------+---------------+ 681 | Value | Description | Reference | 682 +-------------+---------------------------------+---------------+ 683 | TBA1 | Timestamp Label | This document | 684 +-------------+---------------------------------+---------------+ 686 IANA is requested to allocate, within the "SRv6 Endpoint Behaviors 687 Registry" sub-registry belonging to the top-level "Segment Routing 688 Parameters" registry [I-D.ietf-spring-srv6-network-programming], the 689 following allocation: 691 +-------------+---------------------------------+---------------+ 692 | Value | Endpoint Behavior | Reference | 693 +-------------+---------------------------------+---------------+ 694 | TBA2 | End.TSF (Timestamp and Forward) | This document | 695 +-------------+---------------------------------+---------------+ 697 11. References 699 11.1. Normative References 701 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 702 DOI 10.17487/RFC0768, August 1980, 703 . 705 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 706 Requirement Levels", BCP 14, RFC 2119, 707 DOI 10.17487/RFC2119, March 1997, 708 . 710 [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. 711 Zekauskas, "A One-way Active Measurement Protocol 712 (OWAMP)", RFC 4656, DOI 10.17487/RFC4656, September 2006, 713 . 715 [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. 716 Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", 717 RFC 5357, DOI 10.17487/RFC5357, October 2008, 718 . 720 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 721 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 722 May 2017, . 724 [RFC8762] Mirsky, G., Jun, G., Nydell, H., and R. Foote, "Simple 725 Two-Way Active Measurement Protocol", RFC 8762, 726 DOI 10.17487/RFC8762, March 2020, 727 . 729 11.2. Informative References 731 [IEEE1588] 732 IEEE, "1588-2008 IEEE Standard for a Precision Clock 733 Synchronization Protocol for Networked Measurement and 734 Control Systems", March 2008. 736 [RFC7880] Pignataro, C., Ward, D., Akiya, N., Bhatia, M., and S. 737 Pallagatti, "Seamless Bidirectional Forwarding Detection 738 (S-BFD)", RFC 7880, DOI 10.17487/RFC7880, July 2016, 739 . 741 [RFC8186] Mirsky, G. and I. Meilik, "Support of the IEEE 1588 742 Timestamp Format in a Two-Way Active Measurement Protocol 743 (TWAMP)", RFC 8186, DOI 10.17487/RFC8186, June 2017, 744 . 746 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 747 Decraene, B., Litkowski, S., and R. Shakir, "Segment 748 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 749 July 2018, . 751 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 752 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 753 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 754 . 756 [I-D.gandhi-spring-twamp-srpm] 757 Gandhi, R., Filsfils, C., Voyer, D., Chen, M., and B. 758 Janssens, "Performance Measurement Using TWAMP Light for 759 Segment Routing Networks", draft-gandhi-spring-twamp- 760 srpm-10 (work in progress), August 2020. 762 [I-D.gandhi-spring-stamp-srpm] 763 Gandhi, R., Filsfils, C., Voyer, D., Chen, M., and B. 764 Janssens, "Performance Measurement Using Simple TWAMP 765 (STAMP) for Segment Routing Networks", draft-gandhi- 766 spring-stamp-srpm-02 (work in progress), August 2020. 768 [I-D.ietf-spring-segment-routing-policy] 769 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 770 P. Mattes, "Segment Routing Policy Architecture", draft- 771 ietf-spring-segment-routing-policy-08 (work in progress), 772 July 2020. 774 [I-D.ietf-spring-srv6-network-programming] 775 Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., 776 Matsushima, S., and Z. Li, "SRv6 Network Programming", 777 draft-ietf-spring-srv6-network-programming-20 (work in 778 progress), September 2020. 780 [I-D.ietf-mpls-spl-terminology] 781 Andersson, L., Kompella, K., and A. Farrel, "Special 782 Purpose Label terminology", draft-ietf-mpls-spl- 783 terminology-04 (work in progress), September 2020. 785 [I-D.ietf-pce-binding-label-sid] 786 Filsfils, C., Sivabalan, S., Tantsura, J., Hardwick, J., 787 Previdi, S., and C. Li, "Carrying Binding Label/Segment-ID 788 in PCE-based Networks.", draft-ietf-pce-binding-label- 789 sid-03 (work in progress), June 2020. 791 [I-D.ietf-pce-sr-bidir-path] 792 Li, C., Chen, M., Cheng, W., Gandhi, R., and Q. Xiong, 793 "PCEP Extensions for Associated Bidirectional Segment 794 Routing (SR) Paths", draft-ietf-pce-sr-bidir-path-03 (work 795 in progress), September 2020. 797 Acknowledgments 799 The authors would like to thank Greg Mirsky, Mach Chen, Kireeti 800 Kompella, and Adrian Farrel for providing the review comments. 802 Authors' Addresses 804 Rakesh Gandhi (editor) 805 Cisco Systems, Inc. 806 Canada 808 Email: rgandhi@cisco.com 810 Clarence Filsfils 811 Cisco Systems, Inc. 813 Email: cfilsfil@cisco.com 815 Navin Vaghamshi 816 Reliance 818 Email: Navin.Vaghamshi@ril.com 820 Moses Nagarajah 821 Telstra 823 Email: Moses.Nagarajah@team.telstra.com 825 Richard Foote 826 Nokia 828 Email: footer.foote@nokia.com