idnits 2.17.1 draft-gandhi-spring-rfc6374-srpm-udp-05.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 (August 6, 2020) is 1358 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 (-09) exists of draft-ietf-mpls-rfc6374-sr-00 == 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 (-08) exists of draft-ietf-pim-sr-p2mp-policy-00 == Outdated reference: A later version (-16) exists of draft-ietf-pce-binding-label-sid-03 == Outdated reference: A later version (-28) exists of draft-ietf-spring-srv6-network-programming-16 == Outdated reference: A later version (-22) exists of draft-ietf-spring-mpls-path-segment-02 == Outdated reference: A later version (-06) exists of draft-gandhi-mpls-ioam-sr-02 == Outdated reference: A later version (-06) exists of draft-ali-spring-ioam-srv6-02 Summary: 0 errors (**), 0 flaws (~~), 10 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: February 7, 2021 D. Voyer 6 Bell Canada 7 S. Salsano 8 Universita di Roma "Tor Vergata" 9 M. Chen 10 Huawei 11 August 6, 2020 13 Performance Measurement Using RFC 6374 with UDP Path for Segment Routing 14 Networks 15 draft-gandhi-spring-rfc6374-srpm-udp-05 17 Abstract 19 Segment Routing (SR) leverages the source routing paradigm. Segment 20 Routing (SR) is applicable to both Multiprotocol Label Switching (SR- 21 MPLS) and IPv6 (SRv6) data planes. This document specifies 22 procedures for using UDP path for sending and processing probe query 23 and response messages for Performance Measurement (PM). The 24 procedure uses the mechanisms defined in RFC 6374 for Performance 25 Delay and Loss Measurement. The procedure specified is applicable to 26 SR-MPLS and SRv6 data planes for both Links and end-to-end SR Paths 27 including SR Policies measurements. 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 February 7, 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. Example Provisioning Model . . . . . . . . . . . . . . . 6 70 4. Probe Query Message . . . . . . . . . . . . . . . . . . . . . 7 71 4.1. Delay Measurement Probe Query Message . . . . . . . . . . 7 72 4.2. Loss Measurement Probe Query Message . . . . . . . . . . 7 73 4.3. Combined Loss/Delay Measurement Probe Query Message . . . 8 74 4.4. Probe Query Message for Links . . . . . . . . . . . . . . 9 75 4.5. Probe Query Message for SR Policies . . . . . . . . . . . 9 76 4.5.1. Probe Query Message for SR-MPLS Policy . . . . . . . 9 77 4.5.2. Probe Query Message for SRv6 Policy . . . . . . . . . 10 78 5. Probe Response Message . . . . . . . . . . . . . . . . . . . 11 79 5.1. One-way Measurement Mode . . . . . . . . . . . . . . . . 13 80 5.1.1. Links and SR Policies . . . . . . . . . . . . . . . . 13 81 5.1.2. Probe Response Message to Controller . . . . . . . . 13 82 5.2. Two-way Measurement Mode . . . . . . . . . . . . . . . . 13 83 5.2.1. Links . . . . . . . . . . . . . . . . . . . . . . . . 13 84 5.2.2. SR Policies . . . . . . . . . . . . . . . . . . . . . 13 85 5.2.3. Return Path TLV Extensions . . . . . . . . . . . . . 14 86 5.2.4. Probe Response Message for SR-MPLS Policy . . . . . . 14 87 5.2.5. Probe Response Message for SRv6 Policy . . . . . . . 15 88 5.3. Loopback Measurement Mode . . . . . . . . . . . . . . . . 15 89 6. Performance Measurement for P2MP SR Policies . . . . . . . . 16 90 7. ECMP Support for SR Policies . . . . . . . . . . . . . . . . 16 91 8. Additional Probe Message Processing Rules . . . . . . . . . . 16 92 9. Sequence Numbers . . . . . . . . . . . . . . . . . . . . . . 16 93 9.1. Sequence Number TLV Extension in Unauthenticated Mode . . 16 94 9.2. Sequence Number TLV Extension in Authenticated Mode . . . 17 95 10. Performance Delay and Liveness Monitoring . . . . . . . . . . 18 96 11. Security Considerations . . . . . . . . . . . . . . . . . . . 19 97 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 98 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 99 13.1. Normative References . . . . . . . . . . . . . . . . . . 20 100 13.2. Informative References . . . . . . . . . . . . . . . . . 20 101 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 22 102 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 22 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 105 1. Introduction 107 Segment Routing (SR) leverages the source routing paradigm and 108 greatly simplifies network operations for Software Defined Networks 109 (SDNs). SR is applicable to both Multiprotocol Label Switching (SR- 110 MPLS) and IPv6 (SRv6) data planes. SR takes advantage of the Equal- 111 Cost Multipaths (ECMPs) between source and transit nodes, between 112 transit nodes and between transit and destination nodes. SR Policies 113 as defined in [I-D.ietf-spring-segment-routing-policy] are used to 114 steer traffic through a specific, user-defined paths using a stack of 115 Segments. Built-in SR Performance Measurement (PM) is one of the 116 essential requirements to provide Service Level Agreements (SLAs). 118 [RFC6374] specifies protocol mechanisms to enable the efficient and 119 accurate measurement of performance metrics and can be used in SR 120 networks with MPLS data plane [I-D.ietf-mpls-rfc6374-sr]. [RFC6374] 121 addresses the limitations of the IP based performance measurement 122 protocols as specified in Section 1 of [RFC6374]. [RFC6374] requires 123 data plane to support MPLS Generic Associated Channel Label (GAL) and 124 Generic Associated Channel (G-ACh), which may not be supported on all 125 nodes in the segment routing network. 127 [RFC7876] specifies the procedures to be used when sending and 128 processing out-of-band performance measurement probe response 129 messages over an UDP return path for RFC 6374 based probe queries. 130 [RFC7876] can be used to send out-of-band probe response messages in 131 both SR-MPLS and SRv6 networks for one-way performance measurement. 133 For SR Policies, there are ECMPs between the source and transit 134 nodes, between transit nodes and between transit and destination 135 nodes. RFC 6374 does not define handling for ECMP forwarding paths 136 when used in SR networks. 138 For two-way measurements for SR Policies, there is a requirement to 139 specify a return path in the form of a Segment List in probe query 140 messages that does not require on any SR Policy state information on 141 the destination node. 143 This document specifies a procedure for sending and processing probe 144 query and response messages using UDP paths for Performance 145 Measurement in SR networks. The procedure uses RFC 6374 defined 146 mechanisms for Performance Delay and Loss Measurement and unless 147 otherwise specified, the procedures from RFC 6374 are not modified. 148 The procedure specified is applicable to both SR-MPLS and SRv6 data 149 planes. The procedure can be used for both Links and end-to-end SR 150 Paths including SR Policies and Flex-Algo IGP Paths. 152 2. Conventions Used in This Document 154 2.1. Requirements Language 156 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 157 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 158 document are to be interpreted as described in [RFC2119] [RFC8174] 159 when, and only when, they appear in all capitals, as shown here. 161 2.2. Abbreviations 163 BSID: Binding Segment ID. 165 DM: Delay Measurement. 167 ECMP: Equal Cost Multi-Path. 169 G-ACh: Generic Associated Channel (G-ACh). 171 GAL: Generic Associated Channel (G-ACh) Label. 173 LM: Loss Measurement. 175 MPLS: Multiprotocol Label Switching. 177 NTP: Network Time Protocol. 179 PM: Performance Measurement. 181 PSID: Path Segment Identifier. 183 PTP: Precision Time Protocol. 185 SID: Segment ID. 187 SL: Segment List. 189 SR: Segment Routing. 191 SRH: Segment Routing Header. 193 SR-MPLS: Segment Routing with MPLS data plane. 195 SRv6: Segment Routing with IPv6 data plane. 197 TC: Traffic Class. 199 URO: UDP Return Object. 201 2.3. Reference Topology 203 In the reference topology shown below, the querier node R1 initiates 204 a probe query for performance measurement and the responder node R5 205 sends a probe response message for the probe query message received. 206 The probe response message may be sent to the querier node R1 or to a 207 controller node R100. 209 SR is enabled on nodes R1 and R5. The nodes R1 and R5 may be 210 directly connected via a Link enabled with Segment Routing or there 211 exists a Point-to-Point (P2P) SR Path e.g. SR Policy 212 [I-D.ietf-spring-segment-routing-policy] on node R1 (called head-end) 213 with destination to node R5 (called head-end). 215 ------ 216 |R100| 217 ------ 218 ^ 219 | Response 220 | 221 t1 t2 | 222 / \ | 223 +-------+ Query +-------+ 224 | | - - - - - - - - - ->| | 225 | R1 |=====================| R5 | 226 | |<- - - - - - - - - - | | 227 +-------+ Response +-------+ 228 \ / 229 t4 t3 230 Querier Responder 232 Reference Topology 234 3. Overview 236 For one-way, two-way and round-trip delay measurements in Segment 237 Routing networks, the procedures defined in Section 2.4 and 238 Section 2.6 of [RFC6374] are used. For transmit and receive packet 239 loss measurements, the procedures defined in Section 2.2 and 240 Section 2.6 of [RFC6374] are used. The procedures use probe messages 241 with IP/UDP path and do not use MPLS GAL. For both Links and end-to- 242 end SR Paths including SR Policies and Flex-Algo IGP Paths, no PM 243 state for delay or loss measurement is created on the responder node 244 R5 [RFC6374]. 246 Separate UDP destination port numbers are user-configured for delay 247 and loss measurements from the range specified in [RFC8762]. The 248 querier and responder nodes use the destination UDP port number 249 following the guidelines specified in Section 6 in [RFC6335]. The 250 same destination UDP port is used for Links and SR Paths and the 251 responder is unaware if the query is for the Links or SR Paths. The 252 number of UDP ports with PM functionality needs to be minimized due 253 to limited hardware resoucres. 255 For Performance Measurement, probe query and response messages are 256 sent as following: 258 o For delay measurement, the probe messages are sent on the 259 congruent path of the data traffic by the querier node, and are 260 used to measure the delay experienced by the actual data traffic 261 flowing on the Links and SR Policies. 263 o For loss measurement, the probe messages are sent on the congruent 264 path of the data traffic by the querier node, and are used to 265 collect the receive traffic counters for the incoming link or 266 incoming SID where the probe query messages are received at the 267 responder node (incoming link or incoming SID needed since the 268 responder node does not have PM state present). 270 The In-Situ Operations, Administration, and Maintenance (IOAM) 271 mechanisms for SR-MPLS defined in [I-D.gandhi-mpls-ioam-sr] and for 272 SRv6 defined in [I-D.ali-spring-ioam-srv6] are used to carry PM 273 information such as timestamp in-band as part of the data packets, 274 and are outside the scope of this document. 276 3.1. Example Provisioning Model 278 An example provisioning model described in 279 [I-D.gandhi-spring-stamp-srpm] is also applicable to the procedures 280 defined in this document, albeit using the Measurrement Protocol as 281 [RFC6374]. The querier node is the sender node and the responder 282 node is the reflector node when using [RFC6374]. The provisioning 283 model is not used for signaling PM parameters between the responder 284 and querier nodes in SR networks. 286 4. Probe Query Message 288 In this document, UDP path is used for delay and loss measurements 289 for Links and end-to-end SR Policies for the probe messages defined 290 in [RFC6374]. The user-configured destination UDP ports (separate 291 UDP ports for different delay and loss message formats) are used for 292 identifying the probe messages. 294 4.1. Delay Measurement Probe Query Message 296 The message content for delay measurement for probe query message 297 using UDP header [RFC0768] is shown in Figure 1. The DM probe query 298 message is sent with user-configured Destination UDP port number for 299 DM. The Destination UDP port can also be used as Source port for 300 two-way delay measurement, since the message has a flag to 301 distinguish between query and response. The DM probe query message 302 contains the payload format for delay measurement defined in 303 Section 3.2 of [RFC6374]. 305 +---------------------------------------------------------------+ 306 | IP Header | 307 . Source IP Address = Querier IPv4 or IPv6 Address . 308 . Destination IP Address = Responder IPv4 or IPv6 Address . 309 . Protocol = UDP . 310 . . 311 +---------------------------------------------------------------+ 312 | UDP Header | 313 . Source Port = As chosen by Querier . 314 . Destination Port = User-configured Port for Delay Measurement. 315 . . 316 +---------------------------------------------------------------+ 317 | Payload = Message as specified in Section 3.2 of RFC 6374 | 318 . . 319 +---------------------------------------------------------------+ 321 Figure 1: DM Probe Query Message 323 It is recommended to use the IEEE 1588v2 Precision Time Protocol 324 (PTP) truncated 64-bit timestamp format as a default format as 325 specified in Appendix A of [RFC6374], with hardware support. As an 326 alternative, Network Time Protocol (NTP) timestamp format can also be 327 used [RFC6374]. 329 4.2. Loss Measurement Probe Query Message 331 The message content for loss measurement probe query message using 332 UDP header [RFC0768] is shown in Figure 2. As shown, the LM probe 333 query message is sent with user-configured Destination UDP port 334 number for LM. Separate Destination UDP ports are used for direct- 335 mode and inferred-mode loss measurements. The Destination UDP port 336 can also be used as Source port for two-way loss measurement, since 337 the message has a flag to distinguish between query and response. 338 The LM probe query message contains the payload format for loss 339 measurement defined in Section 3.1 of [RFC6374]. 341 +---------------------------------------------------------------+ 342 | IP Header | 343 . Source IP Address = Querier IPv4 or IPv6 Address . 344 . Destination IP Address = Responder IPv4 or IPv6 Address . 345 . Protocol = UDP . 346 . . 347 +---------------------------------------------------------------+ 348 | UDP Header | 349 . Source Port = As chosen by Querier . 350 . Destination Port = User-configured Port for Loss Measurement . 351 . . 352 +---------------------------------------------------------------+ 353 | Payload = Message as specified in Section 3.1 of RFC 6374 | 354 . . 355 +---------------------------------------------------------------+ 357 Figure 2: LM Probe Query Message 359 4.3. Combined Loss/Delay Measurement Probe Query Message 361 The message content for combined Loss/Delay measurement probe query 362 message using UDP header [RFC0768] is shown in Figure 3. As shown, 363 the probe query message is sent with user-configured Destination UDP 364 port number for combined LM/DM message format. Separate Destination 365 UDP ports are used for direct-mode and inferred-mode loss 366 measurements. The Destination UDP port can also be used as Source 367 port for two-way loss/delay measurement, since the message has a flag 368 to distinguish between query and response. The probe query message 369 contains the payload format for combined loss/delay measurement 370 defined in Section 3.3 of [RFC6374]. 372 +---------------------------------------------------------------+ 373 | IP Header | 374 . Source IP Address = Querier IPv4 or IPv6 Address . 375 . Destination IP Address = Responder IPv4 or IPv6 Address . 376 . Protocol = UDP . 377 . . 378 +---------------------------------------------------------------+ 379 | UDP Header | 380 . Source Port = As chosen by Querier . 381 . Destination Port = User-configured Port for . 382 . Loss/Delay Measurement . 383 . . 384 +---------------------------------------------------------------+ 385 | Payload = Message as specified in Section 3.3 of RFC 6374 | 386 . . 387 +---------------------------------------------------------------+ 389 Figure 3: LM/DM Probe Query Message 391 4.4. Probe Query Message for Links 393 The probe query message as defined in Figure 1 for delay measurement 394 and Figure 2 for loss measurement are used for Links which may be 395 physical, virtual or LAG (bundle), LAG (bundle) member, numbered/ 396 unnumbered Links. The probe messages are pre-routed over the Link 397 for both delay and loss measurement. 399 4.5. Probe Query Message for SR Policies 401 The performance delay and loss measurement for segment routing is 402 applicable to both end-to-end SR-MPLS and SRv6 Policies. 404 4.5.1. Probe Query Message for SR-MPLS Policy 406 The probe query message for performance measurement of end-to-end SR- 407 MPLS Policy is sent using its SR-MPLS header containing the MPLS 408 segment list as shown in Figure 4. 410 0 1 2 3 411 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 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 | Segment(1) | TC |S| TTL | 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 . . 416 . . 417 . . 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 | Segment(n) | TC |S| TTL | 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 | PSID | TC |S| TTL | 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 | Payload = DM Message as specified in Figure 1 | 424 . Payload = LM Message as specified in Figure 2 . 425 . Payload = LM/DM Message as specified in Figure 3 . 426 . . 427 +---------------------------------------------------------------+ 429 Figure 4: Example Probe Query Message for SR-MPLS Policy 431 The Segment List (SL) can be empty to indicate Implicit NULL label 432 case for a single-hop SR Policy. 434 The Path Segment Identifier (PSID) 435 [I-D.ietf-spring-mpls-path-segment] of the SR-MPLS Policy is used for 436 accounting received traffic on the egress node for loss measurement. 438 4.5.2. Probe Query Message for SRv6 Policy 440 An SRv6 Policy setup using the SRv6 Segment Routing Header (SRH) and 441 a Segment List is defined in [RFC8754]. The SRv6 network programming 442 is defined in [I-D.ietf-spring-srv6-network-programming]. The probe 443 query messages using UDP header for performance measurement of end- 444 to-end SRv6 Policy is sent using its SRv6 Segment Routing Header 445 (SRH) with Segment List as shown in Figure 5. The procedure defined 446 for upper-layer header processing for SRv6 SIDs in 447 [I-D.ietf-spring-srv6-network-programming] is used to process the UDP 448 header in the received probe query messages. 450 +---------------------------------------------------------------+ 451 | IP Header | 452 . Source IP Address = Querier IPv6 Address . 453 . Destination IP Address = Destination IPv6 Address . 454 . . 455 +---------------------------------------------------------------+ 456 | SRH as specified in RFC 8754 | 457 . . 458 . . 459 +---------------------------------------------------------------+ 460 | IP Header (as needed) | 461 . Source IP Address = Querier IPv6 Address . 462 . Destination IP Address = Responder IPv6 Address . 463 . . 464 +---------------------------------------------------------------+ 465 | UDP Header | 466 . Source Port = As chosen by Querier . 467 . Destination Port = User-configured Port . 468 . . 469 +---------------------------------------------------------------+ 470 | Payload = DM Message as specified in Figure 1 | 471 . Payload = LM Message as specified in Figure 2 . 472 . Payload = LM/DM Message as specified in Figure 3 . 473 . . 474 +---------------------------------------------------------------+ 476 Figure 5: Example Probe Query Message for SRv6 Policy 478 5. Probe Response Message 480 When the received probe query message does not contain any UDP Return 481 Object (URO) TLV [RFC7876], the probe response message is sent using 482 the IP/UDP information from the received probe query message. The 483 content of the probe response message is shown in Figure 6. 485 +---------------------------------------------------------------+ 486 | IP Header | 487 . Source IP Address = Responder IPv4 or IPv6 Address . 488 . Destination IP Address = Source IP Address from Query . 489 . Protocol = UDP . 490 . . 491 +---------------------------------------------------------------+ 492 | UDP Header | 493 . Source Port = As chosen by Responder . 494 . Destination Port = Source Port from Query . 495 . . 496 +---------------------------------------------------------------+ 497 | Message as specified in Section 3.2 of RFC 6374 for DM, or | 498 . Message as specified in Section 3.1 of RFC 6374 for LM, or . 499 . Message as specified in Section 3.3 of RFC 6374 for LM/DM . 500 . . 501 +---------------------------------------------------------------+ 503 Figure 6: Probe Response Message 505 When the received probe query message contains UDP Return Object 506 (URO) TLV [RFC7876], the probe response message uses the IP/UDP 507 information from the URO in the probe query message. The content of 508 the probe response message is shown in Figure 7. 510 +---------------------------------------------------------------+ 511 | IP Header | 512 . Source IP Address = Responder IPv4 or IPv6 Address . 513 . Destination IP Address = URO.Address . 514 . Protocol = UDP . 515 . . 516 +---------------------------------------------------------------+ 517 | UDP Header | 518 . Source Port = As chosen by Responder . 519 . Destination Port = URO.UDP-Destination-Port . 520 . . 521 +---------------------------------------------------------------+ 522 | Message as specified in Section 3.2 of RFC 6374 for DM, or | 523 . Message as specified in Section 3.1 of RFC 6374 for LM, or . 524 . Message as specified in Section 3.3 of RFC 6374 for LM/DM . 525 . . 526 +---------------------------------------------------------------+ 528 Figure 7: Probe Response Message Using URO from Probe Query 530 5.1. One-way Measurement Mode 532 5.1.1. Links and SR Policies 534 In one-way measurement mode, the probe response message as defined in 535 Figure 6 or Figure 7 is sent out-of-band to the querier node, for 536 both Links and SR Policies. 538 The querier node can receive probe response message back by setting 539 its own IP address as Source Address of the header or by adding URO 540 TLV in the probe query message and setting its own IP address in the 541 IP Address in the URO TLV (Type=131) [RFC7876]. The "control code" 542 in the probe query message is set to "out-of-band response 543 requested". The "Source Address" TLV (Type 130), and "Return 544 Address" TLV (Type 1), if present in the probe query message, are not 545 used to send probe response message. In this delay measurement mode, 546 as per Reference Topology, timestamps t1 and t2 are collected by the 547 probes to measure one-way delay as (t2 - t1). 549 5.1.2. Probe Response Message to Controller 551 As shown in the Reference Topology, if the querier node requires the 552 probe response message to be sent to the controller R100, it adds URO 553 TLV in the probe query message and sets the IP address of R100 in the 554 IP Address field and user-configured UDP port for DM and for LM in 555 the UDP-Destination-Port field of the URO TLV (Type=131) [RFC7876]. 557 5.2. Two-way Measurement Mode 559 5.2.1. Links 561 In two-way measurement mode, when using a bidirectional link, the 562 probe response message as defined in Figure 6 or Figure 7 is sent 563 back on the congruent path of the data traffic to the querier node 564 for Links. In this case, the "control code" in the probe query 565 message is set to "in-band response requested" [RFC6374]. In this 566 delay measurement mode, as per Reference Topology, timestamps t1, t2, 567 t3 and t4 are collected by the probes to measure two-way delay as 568 ((t4 - t1) - (t3 - t2)). 570 5.2.2. SR Policies 572 In two-way measurement mode, when using a bidirectional path, the 573 probe response message is sent back on the congruent path of the data 574 traffic to the querier node for end-to-end SR Policies measurements. 575 In this case, the "control code" in the probe query message is set to 576 "in-band response requested" [RFC6374]. 578 5.2.3. Return Path TLV Extensions 580 For two-way measurement, the querier node can request the responder 581 node to send a response message back on a given reverse path (e.g. 582 co-routed path for two-way measurement). Return Path TLV defined in 583 [I-D.ietf-mpls-rfc6374-sr] is used to carry reverse SR path 584 information as part of the payload of the probe query message. This 585 way the responder node does not require any additional SR state for 586 PM (recall that in SR networks, the state is in the probe packet and 587 signaling of the parameters is avoided). 589 Additional Sub-TLVs are defined in this document for the Return Path 590 TLV for the following Types: 592 o Type (value TBA1): SRv6 Segment List of the Reverse Path 594 o Type (value TBA2): SRv6 Binding SID 595 [I-D.ietf-pce-binding-label-sid] of the Reverse SR Policy 597 5.2.4. Probe Response Message for SR-MPLS Policy 599 The message content for sending probe response message on the 600 congruent path of the data traffic for two-way end-to-end SR-MPLS 601 Policy performance measurement is shown in Figure 8. The SR-MPLS 602 label stack in the probe packet header is built using the Segment 603 List received in the Return Path TLV in the probe query message. 605 0 1 2 3 606 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 607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 608 | Segment(1) | TC |S| TTL | 609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 610 . . 611 . . 612 . . 613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 614 | Segment(n) | TC |S| TTL | 615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 616 | Message as shown in Figure 6 or Figure 7 | 617 . . 618 +---------------------------------------------------------------+ 620 Figure 8: Example Probe Response Message for SR-MPLS Policy 622 The Path Segment Identifier (PSID) 623 [I-D.ietf-spring-mpls-path-segment] of the forward SR-MPLS Policy can 624 be used to find the reverse SR-MPLS Policy to send the probe response 625 message for two-way measurement in the absence of Return Path TLV. 627 5.2.5. Probe Response Message for SRv6 Policy 629 The message content for sending probe response message on the 630 congruent path of the data traffic for two-way end-to-end SRv6 Policy 631 performance measurement is shown in Figure 9. For SRv6 Policy using 632 SRH, the SRv6 SID list in the SRH of the probe response message is 633 built using the SRv6 Segment List received in the Return Path TLV in 634 the probe query message. The procedure defined for upper-layer 635 header processing for SRv6 SIDs in 636 [I-D.ietf-spring-srv6-network-programming] is used to process the UDP 637 header in the received probe response messages. 639 +---------------------------------------------------------------+ 640 | IP Header | 641 . Source IP Address = Responder IPv6 Address . 642 . Destination IP Address = Destination IPv6 Address . 643 . . 644 +---------------------------------------------------------------+ 645 | SRH as specified in RFC 8754 | 646 . . 647 . . 648 +---------------------------------------------------------------+ 649 | IP Header (as needed) | 650 . Source IP Address = Responder IPv6 Address . 651 . Destination IP Address = Querier IPv6 Address . 652 . . 653 +---------------------------------------------------------------+ 654 | UDP Header | 655 . Source Port = As chosen by Responder . 656 . Destination Port = Source Port from Query . 657 . . 658 +---------------------------------------------------------------+ 659 | Message as specified in Section 3.2 of RFC 6374 for DM, or | 660 . Message as specified in Section 3.1 of RFC 6374 for LM, or . 661 . Message as specified in Section 3.3 of RFC 6374 for LM/DM . 662 . . 663 +---------------------------------------------------------------+ 665 Figure 9: Example Probe Response Message for SRv6 Policy 667 5.3. Loopback Measurement Mode 669 The Loopback measurement mode defined in Section 2.8 of [RFC6374] can 670 be used to measure round-trip delay of a bidirectional SR Path. The 671 IP header of the probe query message contains the destination address 672 equals to the querier node address and the source address equals to 673 the responder address. Optionally, the probe query message can carry 674 the reverse path information (e.g. reverse path label stack for SR- 675 MPLS) as part of the SR header. The responder node does not process 676 the probe messages and generate response messages, and hence Loopback 677 Request object (Type 3) is not required for SR. In this delay 678 measurement mode, as per Reference Topology, timestamps t1 and t4 are 679 collected by the probes to measure round-trip delay. 681 6. Performance Measurement for P2MP SR Policies 683 The procedure defined for P2MP SR Policies 684 [I-D.ietf-pim-sr-p2mp-policy] in [I-D.gandhi-spring-stamp-srpm] is 685 also applicable using the RFC 6374 defined messages in the payload. 687 7. ECMP Support for SR Policies 689 The procedure defined for handling ECMP for SR Policies in 690 [I-D.gandhi-spring-stamp-srpm] is also applicable to the procedure 691 defined in this document. 693 8. Additional Probe Message Processing Rules 695 The additional probe message processing rules defined in 696 [I-D.gandhi-spring-stamp-srpm] are also applicable to the procedures 697 defined in this document. 699 9. Sequence Numbers 701 The message formats for DM and LM [RFC6374] can carry either 702 timestamp or sequence number but not both. There are case where both 703 timestamp and sequence number are desired for both DM and LM. 704 Sequence numbers can be useful when some probe query messages are 705 lost or they arrive out of order. In addition, the sequence numbers 706 can be useful for detecting denial-of-service (DoS) attacks on UDP 707 ports. 709 9.1. Sequence Number TLV Extension in Unauthenticated Mode 711 [RFC6374] defines DM and LM probe query and response messages that 712 can include one or more optional TLVs. New TLV Type (value TBA3) is 713 defined in this document to carry sequence number for probe query and 714 response messages for delay and loss measurement. The format of the 715 Sequence Number TLV in unauthenticated mode is shown in Figure 10. 717 0 1 2 3 718 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 719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 720 | Type TBA3 | Length | Reserved | 721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 722 | Sequence Number | 723 ~ ~ 724 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 726 Figure 10: Sequence Number TLV - Unauthenticated Mode 728 o The sequence numbers start with 0 and are incremented by one for 729 each subsequent probe query message. 731 o The sequence number are independent for DM and LM messages. 733 o The sequence number can be of any length determined by the querier 734 node. 736 o The Sequence Number TLV is optional. 738 o The querier node SHOULD only insert one Sequence Number TLV in the 739 probe query message and the responder node in the probe response 740 message SHOULD return the first Sequence Number TLV from the probe 741 query message and ignore the other Sequence Number TLVs if 742 present. 744 o When Sequence Number TLV is added, the DM and LM messages SHOULD 745 NOT carry sequence number in the timestamp field of the message. 747 9.2. Sequence Number TLV Extension in Authenticated Mode 749 The probe query and response message format in authenticated mode 750 includes a key Hashed Message Authentication Code (HMAC) ([RFC2104]) 751 hash. Each probe query and response messages are authenticated by 752 adding Sequence Number with Hashed Message Authentication Code (HMAC) 753 TLV. It can use HMAC-SHA-256 truncated to 128 bits (similarly to the 754 use of it in IPSec defined in [RFC4868]); hence the length of the 755 HMAC field is 16 octets. 757 In authenticated mode, only the sequence number is encrypted, and the 758 other payload fields are sent in clear text. The probe message MAY 759 include Comp.MBZ (Must Be Zero) variable length field to align the 760 message on 16 octets boundary. 762 The computation of HMAC field using HMAC-SHA1 can be used with the 763 procedure defined in this document. HMAC uses own key and the 764 definition of the mechanism to distribute the HMAC key is outside the 765 scope of this document. Both the authentication type and key can be 766 user-configured on both the querier and responder nodes. 768 The format of the Sequence Number TLV in authentication mode is shown 769 in Figure 11. 771 0 1 2 3 772 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 773 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 774 | Type TBA4 | Length | Reserved | 775 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 776 | Sequence Number | 777 ~ ~ 778 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 779 ~ Comp.MBZ ~ 780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 781 | HMAC (16 octets) | 782 | | 783 | | 784 | | 785 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 787 Figure 11: Sequence Number TLV - Authenticated Mode 789 o This TLV is mandatory in the authenticated mode. 791 o The node MUST discard the probe message if HMAC is invalid. 793 o The Sequence Number follows the same processing rule as defined in 794 the unauthenticated mode. 796 10. Performance Delay and Liveness Monitoring 798 Liveness monitoring is required for connectivity verification and 799 continuity check in an SR network. The procedure defined in this 800 document for one-way, two-way and loopback mode for delay measurement 801 can also be applied to liveness monitoring of Links and SR Paths. 802 Liveness failure is notified when consecutive N number of probe 803 response messages are not received back at the querier node, where N 804 is locally provisioned value. Note that for one-way and two-way 805 modes, the failure detection interval and scale for number of probe 806 messages need to account for the processing of the probe query 807 messages which need to be punted from the forwarding fast path (to 808 slow path or control plane), and response messages need to be 809 injected on the responder node. Hence, loopback mode is more 810 suitbale for liveness monitoring. 812 11. Security Considerations 814 The performance measurement is intended for deployment in well- 815 managed private and service provider networks. As such, it assumes 816 that a node involved in a measurement operation has previously 817 verified the integrity of the path and the identity of the far end 818 responder node. The security considerations described in Section 8 819 of [RFC6374] are applicable to this specification, and particular 820 attention should be paid to the last three paragraphs. 822 If desired, attacks can be mitigated by performing basic validation 823 and sanity checks, at the querier node, of the counter or timestamp 824 fields in received measurement response messages. The minimal state 825 associated with these protocols also limits the extent of measurement 826 disruption that can be caused by a corrupt or invalid message to a 827 single query/response cycle. 829 Use of HMAC-SHA-256 in the authenticated mode defined in this 830 document protects the data integrity of the probe messages. SRv6 has 831 HMAC protection authentication defined for SRH [RFC8754]. Hence, 832 probe messages for SRv6 may not need authentication mode. 833 Cryptographic measures may be enhanced by the correct configuration 834 of access-control lists and firewalls. 836 12. IANA Considerations 838 IANA is requested to allocate the values for the following Sub-TLV 839 Types for the Return Path TLV for RFC 6374 from the sub-registry 840 "Return Path Sub-TLV Type" of the "MPLS Loss/Delay Measurement TLV 841 Object" registry contained within the "Generic Associated Channel 842 (G-ACh) Parameters" registry set: 844 o Type TBA1: SRv6 Segment List of the Reverse Path 846 o Type TBA2: SRv6 Binding SID of the Reverse SR Policy 848 IANA is also requested to allocate the values for the following 849 Sequence Number TLV Types for RFC 6374 to be carried in the probe 850 query and response messages for delay and loss measurement from the 851 "MPLS Loss/Delay Measurement TLV Object" registry contained within 852 the "Generic Associated Channel (G-ACh) Parameters" registry set: 854 o Type TBA3: Sequence Number TLV in Unauthenticated Mode 856 o Type TBA4: Sequence Number TLV in Authenticated Mode 858 13. References 860 13.1. Normative References 862 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 863 DOI 10.17487/RFC0768, August 1980, 864 . 866 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 867 Requirement Levels", BCP 14, RFC 2119, 868 DOI 10.17487/RFC2119, March 1997, 869 . 871 [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay 872 Measurement for MPLS Networks", RFC 6374, 873 DOI 10.17487/RFC6374, September 2011, 874 . 876 [RFC7876] Bryant, S., Sivabalan, S., and S. Soni, "UDP Return Path 877 for Packet Loss and Delay Measurement for MPLS Networks", 878 RFC 7876, DOI 10.17487/RFC7876, July 2016, 879 . 881 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 882 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 883 May 2017, . 885 [I-D.ietf-mpls-rfc6374-sr] 886 Gandhi, R., Filsfils, C., Voyer, D., Salsano, S., and M. 887 Chen, "Performance Measurement Using RFC 6374 for Segment 888 Routing Networks with MPLS Data Plane", draft-ietf-mpls- 889 rfc6374-sr-00 (work in progress), July 2020. 891 [I-D.gandhi-spring-stamp-srpm] 892 Gandhi, R., Filsfils, C., Voyer, D., Chen, M., and B. 893 Janssens, "Performance Measurement Using STAMP for Segment 894 Routing Networks", draft-gandhi-spring-stamp-srpm-02 (work 895 in progress), August 2020. 897 13.2. Informative References 899 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 900 Hashing for Message Authentication", RFC 2104, 901 DOI 10.17487/RFC2104, February 1997, 902 . 904 [RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA- 905 384, and HMAC-SHA-512 with IPsec", RFC 4868, 906 DOI 10.17487/RFC4868, May 2007, 907 . 909 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 910 Cheshire, "Internet Assigned Numbers Authority (IANA) 911 Procedures for the Management of the Service Name and 912 Transport Protocol Port Number Registry", BCP 165, 913 RFC 6335, DOI 10.17487/RFC6335, August 2011, 914 . 916 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 917 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 918 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 919 . 921 [RFC8762] Mirsky, G., Jun, G., Nydell, H., and R. Foote, "Simple 922 Two-Way Active Measurement Protocol", RFC 8762, 923 DOI 10.17487/RFC8762, March 2020, 924 . 926 [I-D.ietf-spring-segment-routing-policy] 927 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 928 P. Mattes, "Segment Routing Policy Architecture", draft- 929 ietf-spring-segment-routing-policy-08 (work in progress), 930 July 2020. 932 [I-D.ietf-pim-sr-p2mp-policy] 933 Voyer, D., Filsfils, C., Parekh, R., Bidgoli, H., and Z. 934 Zhang, "Segment Routing Point-to-Multipoint Policy", 935 draft-ietf-pim-sr-p2mp-policy-00 (work in progress), July 936 2020. 938 [I-D.ietf-pce-binding-label-sid] 939 Filsfils, C., Sivabalan, S., Tantsura, J., Hardwick, J., 940 Previdi, S., and C. Li, "Carrying Binding Label/Segment-ID 941 in PCE-based Networks.", draft-ietf-pce-binding-label- 942 sid-03 (work in progress), June 2020. 944 [I-D.ietf-spring-srv6-network-programming] 945 Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., 946 Matsushima, S., and Z. Li, "SRv6 Network Programming", 947 draft-ietf-spring-srv6-network-programming-16 (work in 948 progress), June 2020. 950 [I-D.ietf-spring-mpls-path-segment] 951 Cheng, W., Li, H., Chen, M., Gandhi, R., and R. Zigler, 952 "Path Segment in MPLS Based Segment Routing Network", 953 draft-ietf-spring-mpls-path-segment-02 (work in progress), 954 February 2020. 956 [I-D.gandhi-mpls-ioam-sr] 957 Gandhi, R., Ali, Z., Filsfils, C., Brockners, F., Wen, B., 958 and V. Kozak, "MPLS Data Plane Encapsulation for In-situ 959 OAM Data", draft-gandhi-mpls-ioam-sr-02 (work in 960 progress), March 2020. 962 [I-D.ali-spring-ioam-srv6] 963 Ali, Z., Gandhi, R., Filsfils, C., Brockners, F., Kumar, 964 N., Pignataro, C., Li, C., Chen, M., and G. Dawra, 965 "Segment Routing Header encapsulation for In-situ OAM 966 Data", draft-ali-spring-ioam-srv6-02 (work in progress), 967 November 2019. 969 Acknowledgments 971 The authors would like to thank Patrick Khordoc for the discussions 972 on RFC 6374; Nagendra Kumar and Carlos Pignataro for the discussion 973 on SRv6 Performance Measurement. The authors would like to thank 974 Thierry Couture for the discussions on the use-cases for the 975 performance measurement in segment routing networks. The authors 976 would also like to thank Stewart Bryant for the discussion on UDP 977 port allocation for Performance Measurement and Greg Mirsky for 978 providing useful comments and suggestions. 980 Contributors 982 Sagar Soni 983 Cisco Systems, Inc. 984 Email: sagsoni@cisco.com 986 Zafar Ali 987 Cisco Systems, Inc. 988 Email: zali@cisco.com 990 Pier Luigi Ventre 991 CNIT 992 Italy 993 Email: pierluigi.ventre@cnit.it 995 Authors' Addresses 997 Rakesh Gandhi (editor) 998 Cisco Systems, Inc. 999 Canada 1001 Email: rgandhi@cisco.com 1003 Clarence Filsfils 1004 Cisco Systems, Inc. 1006 Email: cfilsfil@cisco.com 1008 Daniel Voyer 1009 Bell Canada 1011 Email: daniel.voyer@bell.ca 1013 Stefano Salsano 1014 Universita di Roma "Tor Vergata" 1015 Italy 1017 Email: stefano.salsano@uniroma2.it 1019 Mach(Guoyi) Chen 1020 Huawei 1022 Email: mach.chen@huawei.com