idnits 2.17.1 draft-gandhi-spring-sr-enhanced-plm-04.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 (February 09, 2021) is 1170 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 (-22) exists of draft-ietf-spring-segment-routing-policy-09 == Outdated reference: A later version (-16) exists of draft-ietf-pce-binding-label-sid-05 == Outdated reference: A later version (-13) exists of draft-ietf-pce-sr-bidir-path-05 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SPRING Working Group R. Gandhi, Ed. 3 Internet-Draft C. Filsfils 4 Intended status: Standards Track Cisco Systems, Inc. 5 Expires: August 13, 2021 N. Vaghamshi 6 Reliance 7 M. Nagarajah 8 Telstra 9 R. Foote 10 Nokia 11 February 09, 2021 13 Enhanced Performance and Liveness Monitoring in Segment Routing Networks 14 draft-gandhi-spring-sr-enhanced-plm-04 16 Abstract 18 Segment Routing (SR) leverages the source routing paradigm. SR is 19 applicable to both Multiprotocol Label Switching (SR-MPLS) and IPv6 20 (SRv6) data planes. This document defines procedures for Enhanced 21 Performance and Liveness Monitoring (PLM) for end-to-end SR paths 22 including SR Policies for both SR-MPLS and SRv6 data planes, those 23 reduce the deployment and operational complexities in a network. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on August 13, 2021. 42 Copyright Notice 44 Copyright (c) 2021 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 61 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 62 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4 63 2.3. Reference Topology . . . . . . . . . . . . . . . . . . . 5 64 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 3.1. Loopback Mode . . . . . . . . . . . . . . . . . . . . . . 5 66 3.2. Loopback Mode Enabled with Network Programming Function . 6 67 3.3. Example Provisioning Model . . . . . . . . . . . . . . . 6 68 4. PLM Test Packet Formats . . . . . . . . . . . . . . . . . . . 7 69 5. PLM Procedure . . . . . . . . . . . . . . . . . . . . . . . . 9 70 5.1. PLM for SR-MPLS Policies . . . . . . . . . . . . . . . . 10 71 5.2. PLM for SRv6 Policies . . . . . . . . . . . . . . . . . . 10 72 6. Enhanced PLM Procedure . . . . . . . . . . . . . . . . . . . 11 73 6.1. Enhanced PLM with Timestamp Label for SR-MPLS Policies . 11 74 6.1.1. Timestamp Label Allocation . . . . . . . . . . . . . 12 75 6.1.2. Node Capability for Timestamp Label . . . . . . . . . 13 76 6.2. Enhanced PLM with Timestamp Endpoint Function for SRv6 77 Policies . . . . . . . . . . . . . . . . . . . . . . . . 13 78 6.2.1. Timestamp Endpoint Function Assignment . . . . . . . 14 79 6.2.2. Node Capability for Timestamp Endpoint Function . . . 15 80 7. ECMP Handling . . . . . . . . . . . . . . . . . . . . . . . . 15 81 8. Example PLM Failure Notifications . . . . . . . . . . . . . . 15 82 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 83 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 84 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 85 11.1. Normative References . . . . . . . . . . . . . . . . . . 17 86 11.2. Informative References . . . . . . . . . . . . . . . . . 18 87 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 19 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 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 Policies as defined 96 in [I-D.ietf-spring-segment-routing-policy] are used to steer traffic 97 through a specific, user-defined paths using a stack of Segments. 98 Built-in Performance Measurement as well as Liveness Monitoring for 99 Connectivity Verification (CV) and Continuity Check (CC) are 100 essential requirements to provide Service Level Agreements (SLAs) in 101 SR networks. 103 The Simple Two-way Active Measurement Protocol (STAMP) provides 104 capabilities for the measurement of various performance metrics in IP 105 networks [RFC8762]. It eliminates the need for control protocol by 106 using configuration and management model to provision and manage test 107 sessions. The STAMP can be used for Performance Measurement (PM) in 108 SR networks as well as liveness monitoring and connectivity loss 109 detection of SR paths. However, the STAMP requires protocol support 110 on the Session-Reflector to process the STAMP test packets as packets 111 need to be punted from the forwarding fast path (to slow path or 112 control plane) on the Session-Reflector and STAMP reply test packets 113 need to be generated. This limits the scale for number of STAMP test 114 sessions and faster fault detection intervals. 116 For Liveness Monitoring, Seamless Bidirectional Forwarding Detection 117 (S-BFD) [RFC7880] can be used in SR networks. However, S-BFD 118 requires protocol support on the BFD-Reflector to process the S-BFD 119 packets as packets need to be punted from the forwarding fast path 120 and generate the reply packets thereby limiting the scale for number 121 S-BFD sessions and faster fault detection intervals. In addition, 122 S-BFD protocol is not defined to enable performance measurement in a 123 network. 125 Enabling multiple protocols, S-BFD for liveness monitoring and STAMP 126 for performance measurement increases the deployment and operational 127 complexities a network. Also, implementing multiple protocols in a 128 hardware significantly increases the development cost. 130 This document defines procedures for Enhanced Performance and 131 Liveness Monitoring (PLM) for end-to-end SR paths including SR 132 Policies for both SR-MPLS and SRv6 data planes, those reduce the 133 deployment and operational complexities in a network. The procedures 134 use the new test packet formats those have the timestamps at the same 135 locations as the base STAMP test packets to leverage the existing 136 hardware support for STAMP. 138 2. Conventions Used in This Document 140 2.1. Requirements Language 142 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 143 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 144 document are to be interpreted as described in [RFC2119] [RFC8174] 145 when, and only when, they appear in all capitals, as shown here. 147 2.2. Abbreviations 149 S-BFD: Seamless Bidirectional Forwarding Detection. 151 BSID: Binding Segment ID. 153 ECMP: Equal Cost Multi-Path. 155 EB: Endpoint Behaviour. 157 HMAC: Hashed Message Authentication Code. 159 MBZ: Must be Zero. 161 MPLS: Multiprotocol Label Switching. 163 PLM: Performance and Liveness Monitoring. 165 PM: Performance Measurement. 167 PTP: Precision Time Protocol. 169 SID: Segment ID. 171 SL: Segment List. 173 SR: Segment Routing. 175 SRH: Segment Routing Header. 177 SR-MPLS: Segment Routing with MPLS data plane. 179 SRv6: Segment Routing with IPv6 data plane. 181 SSID: Sender Session Identifier. 183 STAMP: Simple Two-way Active Measurement Protocol. 185 TC: Traffic Class. 187 TTL: Time To Live. 189 2.3. Reference Topology 191 In the reference topology shown below, the Session-Sender R1 192 initiates a PLM test packet and the Session-Reflector R3 transmits a 193 PLM return test packet. The PLM return test packet is transmitted 194 back to the Session-Sender R1 on the same path or a different path in 195 the reverse direction. 197 The Session-Sender R1 and Session-Reflector R3 are connected via an 198 SR path [RFC8402]. The SR path may be an SR Policy 199 [I-D.ietf-spring-segment-routing-policy] on node R1 (called head-end) 200 with destination to node R3 (called tail-end). 202 T1 203 / 204 +-------+ PLM Test Packet +-------+ 205 | | - - - - - - - - - - - | | 206 | R1 |======================|| R3 | 207 | |<- - - - - - - - - - - | | 208 +-------+ Return Test Packet +-------+ 209 \ 210 T4 212 Session-Sender Session-Reflector 213 (Simply Forward) 215 Reference Topology 217 3. Overview 219 3.1. Loopback Mode 221 In loopback mode, the Session-Sender R1 initiates PLM test packets 222 and the Session-Reflector R3 forwards them just like data packets for 223 the regular traffic back to the Session-Sender R1. The PLM test 224 packets are not punted at the Session-Reflector and does not process 225 them and generate PLM return test packets. The Session-Reflector 226 must not drop the loopback PLM test packets, for example, due to a 227 local policy provisioned. No PLM test session is created on the 228 Session-Reflector. 230 The Source and Destination IP addresses in the PLM test packets are 231 set to the Session-Reflector and the Session-Sender IP addresses, 232 respectively (representing the reverse direction path). The Source 233 and Destination UDP ports in the PLM test packets follow the 234 procedure defined in [RFC8762]. The IPv4 Time To Live (TTL) and IPv6 235 Hop Limit (HL) are set to 255. 237 3.2. Loopback Mode Enabled with Network Programming Function 239 In loopback mode enabled with network programming function, both 240 transmit (T1) and receive (T2) timestamps in data plane are collected 241 by the PLM test packets transmitted in loopback mode as shown in 242 Figure 1. The network programming function optimizes the "operations 243 of punt and generate the PLM test packet" on the Session-Reflector as 244 timestamping is implemented in forwarding fast path in hardware. 245 This helps to achieve higher test session scale and faster failure 246 detection interval. 248 T1 T2 249 / \ 250 +-------+ PLM Test Packet +-------+ 251 | | - - - - - - - - - - - | | 252 | R1 |======================|| R3 | 253 | |<- - - - - - - - - - - | | 254 +-------+ Return Test Packet +-------+ 255 \ 256 T4 258 Session-Sender Session-Reflector 259 (Timestamp, 260 Pop and Forward) 262 Figure 1: Loopback Mode Enabled with Network Programming Function 264 The Session-Sender adds transmit timestamp (T1) in the payload of the 265 PLM test packet and clears the receive (T2) timestamp. The Session- 266 Reflector adds the receive timestamp (T2) in the payload of the 267 received PLM test packet in forwarding fast path in hardware without 268 punting the test packet to the slow path (or control-plane). The 269 network programming function enables Session-Reflector to add the 270 receive timestamp (T2) at a specific offset in the payload which is 271 locally provisioned consistently in the network. The payload of the 272 PLM test packet is not modified by the intermediate nodes. 274 The Session-Reflector only adds the receive timestamp if the source 275 IP address (in case of SR-MPLS) or destination IP address (in case of 276 SRv6) in the PLM test packet matches the local node address to ensure 277 that the PLM test packet reaches the intended Session-Reflector and 278 the receive timestamp is returned by the intended Session-Reflector. 280 3.3. Example Provisioning Model 282 An example provisioning model and typical measurement parameters are 283 shown in Figure 2: 285 +------------+ 286 | Controller | 287 +------------+ 288 PLM Mode / \ Timestamp Label/SRV6 EB 289 Loopback or Enhanced Mode / \ Timestamp Offset 290 Timestamp Label/SRv6 EB / \ Timestamp Format 291 Timestamp Format / \ 292 Missed Packet Count (N) / \ 293 Delay Threshold/Count (T/M) / \ 294 Packet Loss Threshold (XofY)/ \ 295 v v 296 +-------+ +-------+ 297 | | | | 298 | R1 |==========| R3 | 299 | | | | 300 +-------+ +-------+ 302 Session-Sender Session-Reflector 304 Figure 2: Example Provisioning Model 306 Example of PLM mode is loopback mode. The values for Timestamp Label 307 and SRv6 Endpoint Behaviour may be provisioned as described in 308 Section 6. Example of Timestamp Format is 64-bit PTPv2 [IEEE1588]. 309 Example of Timestamp Offset is 16 and 32 bytes for the PLM test 310 packet formats defined in this document. Example threshold values 311 configured for generating notifications are: Missed Packet Count (N), 312 Delay Exceeded Threshold and Packet Count (T/M) and Packet Loss 313 Threshold (XofY), as described in Section 7. 315 The mechanisms to provision the Session-Sender and Session-Reflector 316 are outside the scope of this document. 318 4. PLM Test Packet Formats 320 The PLM test packet formats for unauthenticated and authenticated 321 modes are defined in this document as shown in Figure 3 those have 322 the transmit and receive timestamps at the same locations as the base 323 STAMP test packets to leverage the existing hardware support for 324 STAMP. 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 | Sequence Number | 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 | Transmit Timestamp (T1) | 330 | | 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 | Transmit Error Estimate | SSID | 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 | Receive Timestamp (T2) | 335 | | 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 | | 338 | MBZ (12 Octets) | 339 | | 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 | Receive Error Estimate | MBZ | 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 | MBZ (4 Octets) | 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 PLM Test Packet Format in Unauthenticated Mode 348 0 1 2 3 349 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 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 | Sequence Number | 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 | MBZ (12 octets) | 354 | | 355 | | 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 | Transmit Timestamp (T1) | 358 | | 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 | Transmit Error Estimate | SSID | 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 | MBZ (4 octets) | 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 | Receive Timestamp (T2) | 365 | | 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 | | 368 | MBZ (32 octets) | 369 | | 370 | | 371 | | 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 | Receive Error Estimate | | 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 375 | MBZ (6 octets) | 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 | | 378 | MBZ (16 octets) | 379 | | 380 | | 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 | | 383 | HMAC (16 octets) | 384 | | 385 | | 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 PLM Test Packet Format in Authenticated Mode 390 Figure 3: PLM Test Packet Formats 392 Sequence Number is the sequence number of the PLM test packet 393 according to its transmit order. It starts with zero and is 394 incremented by one for each subsequent PLM test packet. 396 SSID (16-bits): PLM Sender Session Identifier. Uses the procedure 397 for SSID defined in [RFC8762]. 399 Transmit Timestamp and Transmit Error Estimate are the Session- 400 Sender's transmit timestamp and error estimate for the PLM test 401 packet, respectively. 403 Receive Timestamp and Receive Error Estimate are the Session- 404 Reflector's receive timestamp and error estimate, respectively. 406 The timestamp and error estimate fields follow the definition and 407 formats defined in Section 4.1.2 in [RFC8762]. The timestamp format 408 used by default is 64-bit PTPv2 [IEEE1588]. 410 HMAC: The use of the HMAC field is described in Section 4.4 of 411 [RFC8762]. 413 MBZ: Must be Zero. It MUST be all zeroed on the transmission and 414 MUST be ignored on receipt. 416 5. PLM Procedure 418 For performance and liveness monitoring of an end-to-end SR path 419 including SR Policy, PLM test packets in loopback mode are used. 421 For SR Policy, the PLM test packets are transmitted using the Segment 422 List (SL) of the Candidate-Path 423 [I-D.ietf-spring-segment-routing-policy]. When a Candidate-Path has 424 more than one Segment Lists, multiple PLM test packets are sent, one 425 using each Segment List. The PLM return test packets are received by 426 the Session-Sender via IP/UDP [RFC0768] return path by default. The 427 Segment List of the return SR path can be added in the PLM test 428 packet header to receive the return test packet on a specific path 429 using the Binding SID [I-D.ietf-pce-binding-label-sid] or Segment 430 List of the Reverse SR Policy [I-D.ietf-pce-sr-bidir-path]. 432 5.1. PLM for SR-MPLS Policies 434 The PLM test packets are transmitted using the MPLS header for each 435 Label Stack of the SR-MPLS Policy Candidate-Path(s) as shown in 436 Figure 4. In case of IP/UDP return path, the MPLS header is removed 437 by the Session-Reflector. The Label Stack can contain a reverse SR- 438 MPLS path to receive the PLM return test packet on a specific path. 439 In this case, the MPLS header will not be removed by the Session- 440 Reflector. 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 | IP Header | 454 . Source IP Address = Session-Reflector IPv4 or IPv6 Address . 455 . Destination IP Address = Session-Sender IPv4 or IPv6 Address . 456 . Protocol = UDP . 457 . . 458 +---------------------------------------------------------------+ 459 | UDP Header | 460 . Source Port = As chosen by Session-Sender . 461 . Destination Port = As chosen by Session-Sender . 462 . . 463 +---------------------------------------------------------------+ 464 | Payload as defined in Figure 3 | 465 . . 466 +---------------------------------------------------------------+ 468 Figure 4: Example PLM Test Packet for SR-MPLS 470 5.2. PLM for SRv6 Policies 472 The PLM test packets for SRv6 data plane are transmitted using the 473 Segment Routing Header (SRH) [RFC8754] for each Segment List of the 474 SRv6 Policy Candidate-Path(s) as shown in Figure 5. In case of IP/ 475 UDP return path, the SRH is removed by the Session-Reflector. The 476 Segment List can contain a reverse SRv6 path to receive the PLM 477 return test packet on a specific path. In this case, the SRH will 478 not be removed by the Session-Reflector. When the PLM return test 479 packet contains an SRH at the Session-Sender, the procedure defined 480 for upper-layer header processing for SRv6 SIDs in 481 [I-D.ietf-spring-srv6-network-programming] is used to process the UDP 482 header in the received PLM test packets. 484 +---------------------------------------------------------------+ 485 | IP Header | 486 . Source IP Address = Session-Sender IPv6 Address . 487 . Destination IP Address = Destination IPv6 Address . 488 . . 489 +---------------------------------------------------------------+ 490 | SRH as specified in RFC 8754 | 491 . . 492 . . 493 +---------------------------------------------------------------+ 494 | IP Header | 495 . Source IP Address = Session-Reflector IPv6 Address . 496 . Destination IP Address = Session-Sender IPv6 Address . 497 . . 498 +---------------------------------------------------------------+ 499 | UDP Header | 500 . Source Port = As chosen by Session-Sender . 501 . Destination Port = As chosen by Session-Sender . 502 . . 503 +---------------------------------------------------------------+ 504 | Payload as defined in Figure 3 | 505 . . 506 +---------------------------------------------------------------+ 508 Figure 5: Example PLM Test Packet for SRv6 510 6. Enhanced PLM Procedure 512 The enhanced performance and liveness monitoring of an end-to-end SR 513 path including SR Policy is defined using the PLM test packets in 514 loopback mode enabled with network programming function. 516 6.1. Enhanced PLM with Timestamp Label for SR-MPLS Policies 518 In this document, two new Timestamp Labels are defined for SR-MPLS 519 data plane to enable network programming function for "timestamp, pop 520 and forward" the received test packet. 522 In the PLM test packets for SR-MPLS Policies, a Timestamp Label is 523 added in the MPLS header as shown in Figure 6, to collect "Receive 524 Timestamp" field in the payload of the PLM test packet. The Label 525 Stack for the reverse SR-MPLS path can be added after the Timestamp 526 Label to receive the PLM return test packet on a specific path. When 527 a Session-Reflector receives a packet with Timestamp Label, after 528 timestamping the packet at a specific offset, the Session-Reflector 529 pops the Timestamp Label and forwards the packet using the next label 530 or IP header in the packet (just like the data packets for the 531 regular traffic). 533 0 1 2 3 534 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 535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 536 | Label(1) | TC |S| TTL | 537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 538 . . 539 . . 540 . . 541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 542 | Label(n) | TC |S| TTL | 543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 544 | Extension Label (15) | TC |S| TTL | 545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 546 | Timestamp Label (TBA1 or TBA2) | TC |S| TTL | 547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 548 | IP Header | 549 . Source IP Address = Session-Reflector IPv4 or IPv6 Address . 550 . Destination IP Address = Session-Sender IPv4 or IPv6 Address . 551 . Protocol = UDP . 552 . . 553 +---------------------------------------------------------------+ 554 | UDP Header | 555 . Source Port = As chosen by Session-Sender . 556 . Destination Port = As chosen by Session-Sender . 557 . . 558 +---------------------------------------------------------------+ 559 | Payload as defined in Figure 3 | 560 . . 561 +---------------------------------------------------------------+ 563 Figure 6: Example PLM Test Packet with Timestamp Label for SR-MPLS 565 6.1.1. Timestamp Label Allocation 567 The timestamp Labels for unauthenticated and authenticated modes can 568 be allocated using one of the following methods: 570 o Labels (values TBA1 and TBA2) assigned by IANA from the "Extended 571 Special-Purpose MPLS Values" [I-D.ietf-mpls-spl-terminology]. For 572 Label (value TBA1), the timestamp offset is fixed at byte-offset 573 16 from the start of the payload for the unauthenticated mode, and 574 Label (value TBA2) at byte-offset 32 from the start of the payload 575 for the authenticated mode, both using the timestamp format 64-bit 576 PTPv2. 578 o Labels allocated by a Controller from the global table of the 579 Session-Reflector. The Controller provisions the labels on both 580 Session-Sender and Session-Reflector, as well as timestamp offsets 581 and timestamp formats. 583 o Labels allocated by the Session-Reflector. The signaling and IGP 584 flooding extension for the labels (including timestamp offsets and 585 timestamp formats) are outside the scope of this document. 587 6.1.2. Node Capability for Timestamp Label 589 The PLM Session-Sender needs to know if the Session-Reflector can 590 process the Timestamp Label to avoid dropping PLM test packets. The 591 signaling extension for this capability exchange is outside the scope 592 of this document. 594 6.2. Enhanced PLM with Timestamp Endpoint Function for SRv6 Policies 596 The [I-D.ietf-spring-srv6-network-programming] defines SRv6 Endpoint 597 Behaviours (EB) for SRv6 nodes. In this document, two new Timestamp 598 Endpoint Behaviours are defined for Segment Routing Header (SRH) 599 [RFC8754] to enable "Timestamp and Forward (TSF)" function for the 600 received test packets. 602 In the PLM test packets for SRv6 Policies, Timestamp Endpoint 603 Function (End.TSF) is carried with the target Segment Identifier 604 (SID) in SRH [RFC8754] as shown in Figure 7, to collect "Receive 605 Timestamp" field in the payload of the PLM test packet. The Segment 606 List for the reverse path can be added after the target SID to 607 receive the PLM return test packet on a specific path. When a 608 Session-Reflector receives a packet with Timestamp Endpoint (End.TSF) 609 for the target SID which is local, after timestamping the packet at a 610 specific offset, the Session-Reflector forwards the packet using the 611 next SID or IP header in the packet (just like the data packets for 612 the regular traffic). 614 +---------------------------------------------------------------+ 615 | IP Header | 616 . Source IP Address = Session-Sender IPv6 Address . 617 . Destination IP Address = Destination IPv6 Address . 618 . . 619 +---------------------------------------------------------------+ 620 | SRH as specified in RFC 8754 | 621 . . 622 . SRv6 Endpoint End.TSF (value TBA3 or TBA4) . 623 . . 624 +---------------------------------------------------------------+ 625 | IP Header | 626 . Source IP Address = Session-Reflector IPv6 Address . 627 . Destination IP Address = Session-Sender IPv6 Address . 628 . . 629 +---------------------------------------------------------------+ 630 | UDP Header | 631 . Source Port = As chosen by Session-Sender . 632 . Destination Port = As chosen by Session-Sender . 633 . . 634 +---------------------------------------------------------------+ 635 | Payload as defined in Figure 3 | 636 . . 637 +---------------------------------------------------------------+ 639 Figure 7: Example PLM Test Packet with Endpoint Function for SRv6 641 6.2.1. Timestamp Endpoint Function Assignment 643 The Timestamp Endpoint Functions for "Timestamp and Forward" can be 644 signaled using one of the following methods: 646 o Timestamp Endpoint Functions (values TBA3 and TBA4) assigned by 647 IANA from the "SRv6 Endpoint Behaviors Registry". For endpoint 648 behaviour (value TBA3), the timestamp offset is fixed at byte- 649 offset 16 from the start of the payload for the unauthenticated 650 mode, and endpoint behaviour (value TBA4) at byte-offset 32 from 651 the start of the payload for the authenticated mode, both using 652 the timestamp format 64-bit PTPv2. 654 o Timestamp Endpoint Functions assigned by a Controller. The 655 Controller provisions the values on both Session-Sender and 656 Session-Reflector, as well as timestamp offsets and timestamp 657 formats. 659 o Timestamp Endpoint Functions assigned by the Session-Reflector. 660 The signaling and IGP flooding extension for the endpoint 661 functions (including timestamp offsets and timestamp formats) are 662 outside the scope of this document. 664 6.2.2. Node Capability for Timestamp Endpoint Function 666 The PLM Session-Sender needs to know if the Session-Reflector can 667 process the Timestamp Endpoint Function to avoid dropping PLM test 668 packets. The signaling extension for this capability exchange is 669 outside the scope of this document. 671 7. ECMP Handling 673 An SR Policy can have ECMPs between the source and transit nodes, 674 between transit nodes and between transit and destination nodes. The 675 PLM test packets need to be sent to traverse different ECMP paths to 676 monitor an end-to-end SR Policy. 678 Forwarding plane has various hashing functions available to forward 679 packets on specific ECMP paths. In IPv4 header of the PLM test 680 packets, sweeping of Destination Address from the 127/8 range can be 681 used to exercise different IPv4 ECMP paths in both loopback modes as 682 long as the forward and the return paths are SR-MPLS paths. In this 683 case, the TTL field in the IPv4 header is set to 1. 685 The Flow Label field in the outer IPv6 header can also be used for 686 sweeping to exercise different IPv6 ECMP paths. 688 8. Example PLM Failure Notifications 690 Liveness or connectivity success for an end-to-end SR path is 691 initially notified as soon as one or more PLM return test packets are 692 received at the Session-Sender. 694 Liveness or connectivity failure for an end-to-end SR path is 695 notified when consecutive N number of PLM return test packets are not 696 received at the Session-Sender, where N (Missed PLM Packet Count) is 697 a locally provisioned value. 699 The round-trip packet loss for an end-to-end SR path is calculated 700 using the Sequence Number in the PLM test packets. The packet loss 701 metric is notified when X number of PLM test packets were lost out of 702 last Y number of PLM test packets transmitted by the Session-Sender, 703 where Threshold XofY is locally provisioned value. 705 Similarly, the delay metrics are notified, as an example, when 706 consecutive M number of PLM test packets have measured delay values 707 exceed user-configured threshold T, where M (Delay Exceeded Packet 708 Count) and T (Absolute and Percentage Delay Exceeded Threshold) are 709 also locally provisioned values. 711 In both loopback modes, the timestamps T1 and T4 are used to measure 712 round-trip delay. In loopback mode enabled with network programming 713 function, the timestamps T1 and T2 are used to measure one-way delay. 715 In both loopback modes, a failure on the reverse direction path can 716 cause the PLM return test packets to not reach the Session-Sender. 717 This is also true in the case where the PLM return test packets were 718 generated by the Session-Reflector e.g. to indicate Session-Sender of 719 a failure on the forward direction path. As such, the test packet 720 based methods have a limitation of false detection due to a reverse 721 direction failure. 723 9. Security Considerations 725 The Performance and Liveness Monitoring is intended for deployment in 726 the well-managed private and service provider networks. As such, it 727 assumes that a node involved in a monitoring operation has previously 728 verified the integrity of the path and the identity of the Session- 729 Reflector. 731 If desired, attacks can be mitigated by performing basic validation 732 and sanity checks, at the Session-Sender, of the timestamp fields in 733 received PLM packets. The minimal state associated with these 734 protocols also limits the extent of disruption that can be caused by 735 a corrupt or invalid packet to a single test cycle. 737 Use of HMAC-SHA-256 in the authenticated mode protects the data 738 integrity of the test packets. Cryptographic measures may be 739 enhanced by the correct configuration of access-control lists and 740 firewalls. 742 The security considerations specified in [RFC8762] also apply to the 743 procedures defined in this document. 745 10. IANA Considerations 747 IANA maintains the "Special-Purpose Multiprotocol Label Switching 748 (MPLS) Label Values" registry (see ). IANA is requested to 750 allocate Timestamp Label value from the "Extended Special-Purpose 751 MPLS Label Values" registry: 753 +-------------+---------------------------------+---------------+ 754 | Value | Description | Reference | 755 +-------------+---------------------------------+---------------+ 756 | TBA1 | Timestamp Label | This document | 757 | | for offset 16 | | 758 | | for Unauthenticated Mode | | 759 +-------------+---------------------------------+---------------+ 760 | TBA2 | Timestamp Label | This document | 761 | | for offset 32 | | 762 | | for Authenticated Mode | | 763 +-------------+---------------------------------+---------------+ 765 IANA is requested to allocate, within the "SRv6 Endpoint Behaviors 766 Registry" sub-registry belonging to the top-level "Segment Routing 767 Parameters" registry [I-D.ietf-spring-srv6-network-programming], the 768 following allocation: 770 +-------------+---------------------------------+---------------+ 771 | Value | Endpoint Behavior | Reference | 772 +-------------+---------------------------------+---------------+ 773 | TBA3 | End.TSF (Timestamp and Forward) | This document | 774 | | for offset 16 | | 775 | | for Unauthenticated Mode | | 776 +-------------+---------------------------------+---------------+ 777 | TBA4 | End.TSF (Timestamp and Forward) | This document | 778 | | for offset 32 | | 779 | | for Authenticated Mode | | 780 +-------------+---------------------------------+---------------+ 782 11. References 784 11.1. Normative References 786 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 787 DOI 10.17487/RFC0768, August 1980, 788 . 790 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 791 Requirement Levels", BCP 14, RFC 2119, 792 DOI 10.17487/RFC2119, March 1997, 793 . 795 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 796 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 797 May 2017, . 799 [RFC8762] Mirsky, G., Jun, G., Nydell, H., and R. Foote, "Simple 800 Two-Way Active Measurement Protocol", RFC 8762, 801 DOI 10.17487/RFC8762, March 2020, 802 . 804 [I-D.ietf-spring-srv6-network-programming] 805 Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., 806 Matsushima, S., and Z. Li, "SRv6 Network Programming", 807 draft-ietf-spring-srv6-network-programming-28 (work in 808 progress), December 2020. 810 11.2. Informative References 812 [IEEE1588] 813 IEEE, "1588-2008 IEEE Standard for a Precision Clock 814 Synchronization Protocol for Networked Measurement and 815 Control Systems", March 2008. 817 [RFC7880] Pignataro, C., Ward, D., Akiya, N., Bhatia, M., and S. 818 Pallagatti, "Seamless Bidirectional Forwarding Detection 819 (S-BFD)", RFC 7880, DOI 10.17487/RFC7880, July 2016, 820 . 822 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 823 Decraene, B., Litkowski, S., and R. Shakir, "Segment 824 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 825 July 2018, . 827 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 828 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 829 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 830 . 832 [I-D.ietf-spring-segment-routing-policy] 833 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 834 P. Mattes, "Segment Routing Policy Architecture", draft- 835 ietf-spring-segment-routing-policy-09 (work in progress), 836 November 2020. 838 [I-D.ietf-mpls-spl-terminology] 839 Andersson, L., Kompella, K., and A. Farrel, "Special 840 Purpose Label terminology", draft-ietf-mpls-spl- 841 terminology-06 (work in progress), January 2021. 843 [I-D.ietf-pce-binding-label-sid] 844 Sivabalan, S., Filsfils, C., Tantsura, J., Hardwick, J., 845 Previdi, S., and C. Li, "Carrying Binding Label/Segment-ID 846 in PCE-based Networks.", draft-ietf-pce-binding-label- 847 sid-05 (work in progress), October 2020. 849 [I-D.ietf-pce-sr-bidir-path] 850 Li, C., Chen, M., Cheng, W., Gandhi, R., and Q. Xiong, 851 "Path Computation Element Communication Protocol (PCEP) 852 Extensions for Associated Bidirectional Segment Routing 853 (SR) Paths", draft-ietf-pce-sr-bidir-path-05 (work in 854 progress), January 2021. 856 Acknowledgments 858 The authors would like to thank Greg Mirsky, Mach Chen, Kireeti 859 Kompella, and Adrian Farrel for providing the review comments. 861 Authors' Addresses 863 Rakesh Gandhi (editor) 864 Cisco Systems, Inc. 865 Canada 867 Email: rgandhi@cisco.com 869 Clarence Filsfils 870 Cisco Systems, Inc. 872 Email: cfilsfil@cisco.com 874 Navin Vaghamshi 875 Reliance 877 Email: Navin.Vaghamshi@ril.com 879 Moses Nagarajah 880 Telstra 882 Email: Moses.Nagarajah@team.telstra.com 883 Richard Foote 884 Nokia 886 Email: footer.foote@nokia.com