idnits 2.17.1 draft-gandhi-spring-rfc6374-srpm-udp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 14, 2019) is 1897 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) -- Obsolete informational reference (is this intentional?): RFC 8321 (Obsoleted by RFC 9341) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). 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 18, 2019 D. Voyer 6 Bell Canada 7 S. Salsano 8 Universita di Roma "Tor Vergata" 9 P. L. Ventre 10 CNIT 11 M. Chen 12 Huawei 13 February 14, 2019 15 In-band Performance Measurement Using UDP Path 16 for Segment Routing Networks 17 draft-gandhi-spring-rfc6374-srpm-udp-00 19 Abstract 21 Segment Routing (SR) is applicable to both Multiprotocol Label 22 Switching (SR-MPLS) and IPv6 (SRv6) data planes. This document 23 specifies procedures for using UDP path for sending and processing 24 in-band probe query and response messages for Performance 25 Measurement. The procedure uses the RFC 6374 defined mechanisms for 26 Delay and Loss performance measurement. The procedure specified is 27 applicable to SR-MPLS and SRv6 data planes for both links and 28 end-to-end measurement for SR Policies. In addition, this document 29 defines Return Path TLV for two-way performance measurement and Block 30 Number TLV for loss measurement. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 Copyright Notice 48 Copyright (c) 2019 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 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Conventions Used in This Document . . . . . . . . . . . . . . 4 65 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 66 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4 67 2.3. Reference Topology . . . . . . . . . . . . . . . . . . . . 5 68 2.4. In-band Probe Messages . . . . . . . . . . . . . . . . . . 6 69 3. Probe Messages . . . . . . . . . . . . . . . . . . . . . . . . 6 70 3.1. Probe Query Message . . . . . . . . . . . . . . . . . . . 6 71 3.1.1. Delay Measurement Probe Query Message . . . . . . . . 7 72 3.1.2. Loss Measurement Probe Query Message . . . . . . . . . 7 73 3.1.2.1. Block Number TLV . . . . . . . . . . . . . . . . . 8 74 3.1.3. Probe Query for SR Links . . . . . . . . . . . . . . . 9 75 3.1.4. Probe Query for End-to-end Measurement for SR Policy . 9 76 3.1.4.1. Probe Query Message for SR-MPLS Policy . . . . . . 9 77 3.1.4.2. Probe Query Message for SRv6 Policy . . . . . . . 9 78 3.2. Probe Response Message . . . . . . . . . . . . . . . . . . 10 79 3.2.1. One-way Measurement for SR Link and end-to-end SR 80 Policy . . . . . . . . . . . . . . . . . . . . . . . . 11 81 3.2.1.1. Probe Response Message to Controller . . . . . . . 11 82 3.2.2. Two-way Measurement for SR Links . . . . . . . . . . . 11 83 3.2.3. Two-way End-to-end Measurement for SR Policy . . . . . 12 84 3.2.3.1. Return Path TLV . . . . . . . . . . . . . . . . . 12 85 3.2.3.2. Probe Response Message for SR-MPLS Policy . . . . 13 86 3.2.3.3. Probe Response Message for SRv6 Policy . . . . . . 14 87 4. Performance Measurement for P2MP SR Policies . . . . . . . . . 14 88 5. ECMP Support . . . . . . . . . . . . . . . . . . . . . . . . . 14 89 6. Sequence Numbers . . . . . . . . . . . . . . . . . . . . . . . 15 90 6.1. Sequence Number TLV in Unauthenticated Mode . . . . . . . 15 91 6.2. Sequence Number TLV in Authenticated Mode . . . . . . . . 16 92 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 93 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 94 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 95 9.1. Normative References . . . . . . . . . . . . . . . . . . . 18 96 9.2. Informative References . . . . . . . . . . . . . . . . . . 19 97 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 21 98 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 101 1. Introduction 103 Segment Routing (SR) technology greatly simplifies network operations 104 for Software Defined Networks (SDNs). SR is applicable to both 105 Multiprotocol Label Switching (SR-MPLS) and IPv6 (SRv6) data planes. 106 SR takes advantage of the Equal-Cost Multipaths (ECMPs) between 107 source, transit and destination nodes. SR Policies as defined in 108 [I-D.spring-segment-routing-policy] are used to steer traffic through 109 a specific, user-defined path using a stack of Segments. Built-in SR 110 Performance Measurement (PM) is one of the essential requirements to 111 provide Service Level Agreements (SLAs). 113 The One-Way Active Measurement Protocol (OWAMP) defined in [RFC4656] 114 and Two-Way Active Measurement Protocol (TWAMP) defined in [RFC5357] 115 provide capabilities for the measurement of various performance 116 metrics in IP networks. These protocols rely on control channel 117 signaling to establish a test channel over an UDP path. These 118 protocols lack support for IEEE 1588 timestamp [IEEE1588] format and 119 direct-mode Loss Measurement (LM), which are required in SR networks 120 [RFC6374]. The Simple Two-way Active Measurement Protocol (STAMP) 121 [I-D.ippm-stamp] alleviates the control channel signaling by using 122 configuration data model to provision test channels. In addition, 123 the STAMP supports IEEE 1588 timestamp format for Delay Measurement 124 (DM). The TWAMP Light from broadband forum [BBF.TR-390] provides 125 simplified mechanisms for active performance measurement in Customer 126 Edge IP networks. [Y1731] specifies the mechanisms to carry OAM 127 messages specifically for Ethernet networks that include Ethernet 128 Frame Delay and Loss measurements. 130 [RFC6374] specifies protocol mechanisms to enable the efficient and 131 accurate measurement of performance metrics and can be used in SR 132 networks with MPLS data plane [I-D.spring-rfc6374-srpm-mpls]. 133 [RFC6374] addresses the limitations of the IP based performance 134 measurement protocols as specified in Section 1 of [RFC6374]. The 135 [RFC6374] requires data plane to support MPLS Generic Associated 136 Channel Label (GAL) and Generic Associated Channel (G-Ach), which may 137 not be supported on all nodes in the network. 139 [RFC7876] specifies the procedures to be used when sending and 140 processing out-of-band performance measurement probe response 141 messages over an UDP return path for RFC 6374 based probe queries. 142 [RFC7876] can be used to send out-of-band PM probe responses in both 143 SR-MPLS and SRv6 networks for one-way performance measurement. 145 For SR Policies, there are ECMPs between the source and transit 146 nodes, between transit nodes and between transit and destination 147 nodes. Existing PM protocols (e.g. RFC 6374) do not define handling 148 for ECMP forwarding paths in SR networks. 150 For two-way measurements for SR Policies, there is a need to specify 151 a return path in the form of a Segment List in PM probe query 152 messages without requiring any SR Policy state on the destination 153 node. Existing protocols do not have such mechanisms to specify 154 return path in the PM probe query messages. 156 This document specifies a procedure for using UDP path for sending 157 and processing in-band probe query and response messages for 158 Performance Measurement that does not require to bootstrap PM 159 sessions. The procedure uses RFC 6374 defined mechanisms for Delay 160 and Loss PM and unless otherwise specified, the procedures from RFC 161 6374 are not modified. The procedure specified is applicable to both 162 SR-MPLS and SRv6 data planes. The procedure can be used for both SR 163 links and end-to-end performance measurement for SR Policies. This 164 document also defines mechanisms for handling Equal Cost Multipaths 165 (ECMPs) of SR Policies for performance delay measurement. In 166 addition, this document defines Return Path TLV for two-way 167 performance measurement, Block Number TLV for loss measurement and 168 Sequence Number TLV. 170 2. Conventions Used in This Document 172 2.1. Requirements Language 174 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 175 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 176 document are to be interpreted as described in [RFC2119] [RFC8174] 177 when, and only when, they appear in all capitals, as shown here. 179 2.2. Abbreviations 181 ACH: Associated Channel Header. 183 BSID: Binding Segment ID. 185 DFLag: Data Format Flag. 187 DM: Delay Measurement. 189 ECMP: Equal Cost Multi-Path. 191 G-ACh: Generic Associated Channel (G-ACh). 193 GAL: Generic Associated Channel (G-ACh) Label. 195 LM: Loss Measurement. 197 MPLS: Multiprotocol Label Switching. 199 NTP: Network Time Protocol. 201 OWAMP: One-Way Active Measurement Protocol. 203 PM: Performance Measurement. 205 PSID: Path Segment Identifier. 207 PTP: Precision Time Protocol. 209 SID: Segment ID. 211 SL: Segment List. 213 SR: Segment Routing. 215 SR-MPLS: Segment Routing with MPLS data plane. 217 SRv6: Segment Routing with IPv6 data plane. 219 STAMP: Simple Two-way Active Measurement Protocol. 221 TC: Traffic Class. 223 TWAMP: Two-Way Active Measurement Protocol. 225 URO: UDP Return Object. 227 2.3. Reference Topology 229 In the reference topology, the querier node R1 initiates a probe 230 query for performance measurement and the responder node R5 sends a 231 probe response for the query message received. The probe response 232 may be sent to the querier node R1 or to a controller node R100. The 233 nodes R1 and R5 may be directly connected via a link enabled with 234 Segment Routing or there exists a Point-to-Point (P2P) SR Policy 235 [I-D.spring-segment-routing-policy] on node R1 with destination to 236 node R5. In case of Point-to-Multipoint (P2MP), SR Policy 237 originating from source node R1 may terminate on multiple destination 238 leaf nodes [I-D.spring-sr-p2mp-policy]. 240 ------ 241 |R100| 242 ------ 243 ^ 244 | Response 245 | 246 +-------+ Query +-------+ 247 | | - - - - - - - - - ->| | 248 | R1 |---------------------| R5 | 249 | |<- - - - - - - - - - | | 250 +-------+ Response +-------+ 252 Reference Topology 254 Both Delay and Loss performance measurement is performed in-band for 255 the traffic traversing between node R1 and node R5. One-way delay 256 and two-way delay measurements are defined in Section 2.4 of 257 [RFC6374]. Transmit and Receive packet loss measurements are defined 258 in Section 2.2 and Section 2.6 of [RFC6374]. One-way loss 259 measurement provides receive packet loss whereas two-way loss 260 measurement provides both transmit and receive packet loss. 262 2.4. In-band Probe Messages 264 For both Delay and Loss measurements for links and SR Policies, no PM 265 session is created on the responder node. The probe messages for 266 Delay measurement are sent in-band by the querier node to measure the 267 delay experienced by the actual traffic flowing on the links and SR 268 Policies. For Loss measurement, in-band probe messages are used to 269 collect the traffic counter for the incoming link or incoming SID on 270 which the probe query message is received at the responder node R5 as 271 it has no PM session state present on the node. The performance 272 measurement for Delay and Loss using out-of-band probe query messages 273 are outside the scope of this document. 275 3. Probe Messages 277 3.1. Probe Query Message 279 In this document, UDP path is used for Delay and Loss measurements 280 for SR links and end-to-end SR Policies. A user-configured UDP port 281 is used for identifying PM probe packets that does not require to 282 bootstrap PM sessions. A UDP port number from the Dynamic and/or 283 Private Ports range 49152-65535 is used as the destination UDP port. 284 This approach is similar to the one defined in STAMP protocol 285 [I-D.ippm-stamp]. The IPv4 TTL or IPv6 Hop Limit field of the IP 286 header MUST be set to 255. 288 3.1.1. Delay Measurement Probe Query Message 290 The message content for Delay Measurement probe query message using 291 UDP header [RFC768] is shown in Figure 1. The DM probe query message 292 is sent with user-configured Destination UDP port number. The Source 293 UDP port can be set to the same value for two-way delay measurement 294 as indication of query and response is present in the message. The 295 DM probe query message contains the payload for delay measurement 296 defined in Section 3.2 of [RFC6374]. 298 +---------------------------------------------------------------+ 299 | IP Header | 300 . Source IP Address = Querier IPv4 or IPv6 Address . 301 . Destination IP Address = Responder IPv4 or IPv6 Address . 302 . Protocol = UDP . 303 . Router Alert Option Not Set . 304 . . 305 +---------------------------------------------------------------+ 306 | UDP Header | 307 . Source Port = As chosen by Querier . 308 . Destination Port = User-configured Port for Delay Measurement. 309 . . 310 +---------------------------------------------------------------+ 311 | Payload = Message as specified in Section 3.2 of RFC 6374 | 312 . . 313 +---------------------------------------------------------------+ 315 Figure 1: DM Probe Query Message 317 3.1.2. Loss Measurement Probe Query Message 319 The message content for Loss measurement probe query message using 320 UDP header [RFC768] is shown in Figure 2. As shown, the LM probe 321 query message is sent with user-configured Destination UDP port 322 number. The Source UDP port can be set to the same value for two-way 323 loss measurement as indication of query and response is present in 324 the message. The LM probe query message contains the payload for 325 loss measurement defined in Section 3.1 of [RFC6374]. 327 +---------------------------------------------------------------+ 328 | IP Header | 329 . Source IP Address = Querier IPv4 or IPv6 Address . 331 . Destination IP Address = Responder IPv4 or IPv6 Address . 332 . Protocol = UDP . 333 . Router Alert Option Not Set . 334 . . 335 +---------------------------------------------------------------+ 336 | UDP Header | 337 . Source Port = As chosen by Querier . 338 . Destination Port = User-configured Port for Loss Measurement . 339 . . 340 +---------------------------------------------------------------+ 341 | Payload = Message as specified in Section 3.1 of RFC 6374 | 342 . . 343 +---------------------------------------------------------------+ 345 Figure 2: LM Probe Query Message 347 The Path Segment Identifier (PSID) [I-D.spring-mpls-path-segment] of 348 the SR Policy is used for accounting received traffic on the egress 349 node for loss measurement. 351 3.1.2.1. Block Number TLV 353 The Loss Measurement using Alternate-Marking method defined in 354 [RFC8321] requires to identify the Block Number (or color) of the 355 traffic counters carried by the probe query and response messages. 356 Probe query and response messages specified in [RFC6374] for Loss 357 Measurement do not define any means to carry the Block Number. 359 [RFC6374] defines probe query and response messages that can include 360 one or more optional TLVs. New TLV Type (value TBA2) is defined in 361 this document to carry Block Number (32-bit) for the traffic counters 362 in the probe query and response messages for loss measurement. The 363 format of the Block Number TLV is shown in Figure 11: 365 0 1 2 3 366 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 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 | Type TBA2 | Length | Reserved | 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 | Block Number | 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 Figure 11: Block Number TLV 375 The Block Number TLV is optional. The PM querier node SHOULD only 376 insert one Block Number TLV in the probe query message and the 377 responder node in the probe response message SHOULD return the first 378 Block Number TLV from the probe query messages and ignore other Block 379 Number TLVs if present. In both probe query and response messages, 380 the counters MUST belong to the same Block Number. 382 3.1.3. Probe Query for SR Links 384 The probe query message as defined in Figure 1 is sent in-band for 385 Delay measurement. The probe query message as defined in Figure 2 is 386 sent in-band for Loss measurement. 388 3.1.4. Probe Query for End-to-end Measurement for SR Policy 390 3.1.4.1. Probe Query Message for SR-MPLS Policy 392 The message content for in-band probe query message using UDP header 393 for end-to-end performance measurement of SR-MPLS Policy is shown in 394 Figure 3. 396 0 1 2 3 397 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 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 | Segment List(0) | TC |S| TTL | 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 . . 402 . . 403 . . 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 | Segment List(n) | TC |S| TTL | 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 | Message as shown in Figure 1 for DM or Figure 2 for LM | 408 . . 409 +---------------------------------------------------------------+ 411 Figure 3: Probe Query Message for SR-MPLS Policy 413 The Segment List (SL) can be empty to indicate Implicit NULL label 414 case. 416 3.1.4.2. Probe Query Message for SRv6 Policy 418 The in-band probe query messages using UDP header for end-to-end 419 performance measurement of an SRv6 Policy is sent using SRv6 Segment 420 Routing Header (SRH) and Segment List of the SRv6 Policy as defined 421 in [I-D.6man-segment-routing-header] and is shown in Figure 4. 423 0 1 2 3 424 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 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 | SRH | 427 . END.OTP (DM) or END.OP (LM) with Target SRv6 SID . 428 . . 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 | Message as shown in Figure 1 for DM or Figure 2 for LM | 431 . (Using IPv6 Addresses) . 432 . . 433 +---------------------------------------------------------------+ 435 Figure 4: Probe Query Message for SRv6 Policy 437 For delay measurement of SRv6 Policy, END function END.OTP 438 [I-D.spring-srv6-oam] is used with the target SRv6 SID to punt probe 439 messages on the target node, as shown in Figure 4. Similarly, for 440 loss measurement of SRv6 Policy, END function END.OP 441 [I-D.spring-srv6-oam] is used with target SRv6 SID to punt probe 442 messages on the target node. 444 3.2. Probe Response Message 446 When the received probe query message does not contain any UDP Return 447 Object (URO) TLV [RFC7876], the probe response message is sent using 448 the IP/UDP information from the probe query message. The content of 449 the probe response message is shown in Figure 5. 451 +---------------------------------------------------------------+ 452 | IP Header | 453 . Source IP Address = Responder IPv4 or IPv6 Address . 454 . Destination IP Address = Source IP Address from Query . 455 . Protocol = UDP . 456 . Router Alert Option Not Set . 457 . . 458 +---------------------------------------------------------------+ 459 | UDP Header | 460 . Source Port = As chosen by Responder . 461 . Destination Port = Source Port from Query . 462 . . 463 +---------------------------------------------------------------+ 464 | Message as specified in Section 3.2 of RFC 6374 for DM, or | 465 . Message as specified in Section 3.1 of RFC 6374 for LM . 466 . . 467 +---------------------------------------------------------------+ 469 Figure 5: Probe Response Message 471 When the received probe query message contains UDP Return Object 472 (URO) TLV [RFC7876], the probe response message uses the IP/UDP 473 information from the URO in the probe query message. The content of 474 the probe response message is shown in Figure 6. 476 +---------------------------------------------------------------+ 477 | IP Header | 478 . Source IP Address = Responder IPv4 or IPv6 Address . 479 . Destination IP Address = URO.Address . 480 . Protocol = UDP . 481 . Router Alert Option Not Set . 482 . . 483 +---------------------------------------------------------------+ 484 | UDP Header | 485 . Source Port = As chosen by Responder . 486 . Destination Port = URO.UDP-Destination-Port . 487 . . 488 +---------------------------------------------------------------+ 489 | Message as specified in Section 3.2 of RFC 6374 for DM, or | 490 . Message as specified in Section 3.1 of RFC 6374 for LM . 491 . . 492 +---------------------------------------------------------------+ 494 Figure 6: Probe Response Message Using URO from Probe Query Message 496 3.2.1. One-way Measurement for SR Link and end-to-end SR Policy 498 For one-way performance measurement, the probe response message as 499 defined in Figure 5 or Figure 6 is sent out-of-band for both SR links 500 and SR Policies. 502 The PM querier node can receive probe response message back by 503 properly setting its own IP address as Source Address of the header 504 or by adding URO TLV in the probe query message and setting its own 505 IP address in the IP Address in the URO TLV (Type=131) [RFC7876]. In 506 addition, the "control code" in the probe query message is set to 507 "out-of-band response requested". The "Source Address" TLV (Type 508 130), and "Return Address" TLV (Type 1), if present in the probe 509 query message, are not used to send probe response message. 511 3.2.1.1. Probe Response Message to Controller 513 As shown in the Reference Topology, if the querier node requires the 514 probe response message to be sent to the controller R100, it adds URO 515 TLV in the probe query message and sets the IP address of R100 in the 516 IP Address field and user-configured UDP port for DM and for LM in 517 the UDP-Destination-Port field of the URO TLV (Type=131) [RFC7876]. 519 3.2.2. Two-way Measurement for SR Links 521 For two-way performance measurement, when using a bidirectional 522 channel, the probe response message as defined in Figure 5 or Figure 523 6 is sent back in-band to the querier node for SR links. In this 524 case, the "control code" in the probe query message is set to 525 "in-band response requested" [RFC6374]. 527 3.2.3. Two-way End-to-end Measurement for SR Policy 529 For two-way performance measurement, when using a bidirectional 530 channel, the probe response message is sent back in-band to the 531 querier node for end-to-end measurement of SR Policies. In this 532 case, the "control code" in the probe query message is set to 533 "in-band response requested" [RFC6374]. 535 The Path Segment Identifier (PSID) [I-D.spring-mpls-path-segment] of 536 the forward SR Policy can be used to find the reverse SR Policy to 537 send the probe response message for two-way measurement in the 538 absence of Return Path TLV defined in the following Section. 540 3.2.3.1. Return Path TLV 542 For two-way performance measurement, the responder node needs to send 543 the probe response message in-band on a specific reverse SR path. 544 This way the destination node does not require any additional SR 545 Policy state. The querier node can request in the probe query 546 message to the responder node to send a response back on a given 547 reverse path (typically co-routed path for two-way measurement). 549 [RFC6374] defines DM and LM probe query messages that can include one 550 or more optional TLVs. New TLV Type (TBA1) is defined in this 551 document for Return Path to carry reverse SR path for probe response 552 messages (in the payload of the message). The format of the Return 553 Path TLV is shown in Figure 7A and 7B: 555 0 1 2 3 556 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 557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 558 | Type = TBA1 | Length | Reserved | 559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 560 | Return Path Sub-TLVs | 561 . . 562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 564 Figure 7A: Return Path TLV 566 0 1 2 3 567 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 568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 | Type | Length | Reserved | 570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 | Segment List(0) | 572 . . 573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 574 . . 575 . . 576 . . 577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 578 | Segment List(n) | 579 . . 580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 582 Figure 7B: Segment List Sub-TLV in Return Path TLV 584 The Sub-TLV in the Return Path TLV can be one of the following Types: 586 o Type (value 1): SR-MPLS Label Stack of the Reverse SR Policy 588 o Type (value 2): SR-MPLS Binding SID [I-D.pce-binding-label-sid] of 589 the Reverse SR Policy 591 o Type (value 3): SRv6 Segment List of the Reverse SR Policy 593 o Type (value 4): SRv6 Binding SID [I-D.pce-binding-label-sid] of 594 the Reverse SR Policy 596 With sub-TLV Type 1, the Segment List(0) can be used by the responder 597 node to compute the next-hop IP address and outgoing interface to 598 send the probe response messages. 600 The Return Path TLV is optional. The PM querier node MUST only 601 insert one Return Path TLV in the probe query message and the 602 responder node MUST only process the first Return Path TLV in the 603 probe query message and ignore other Return Path TLVs if present. 604 The responder node MUST send probe response message back on the 605 reverse path specified in the Return Path TLV and MUST NOT add Return 606 Path TLV in the probe response message. 608 3.2.3.2. Probe Response Message for SR-MPLS Policy 610 The message content for sending probe response message in-band using 611 UDP header for two-way end-to-end performance measurement of an 612 SR-MPLS Policy is shown in Figure 8. The SR-MPLS label stack in the 613 packet header is built using the Segment List received in the Return 614 Path TLV in the probe query message. 616 0 1 2 3 617 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 618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 619 | Segment List(0) | TC |S| TTL | 620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 621 . . 622 . . 623 . . 624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 625 | Segment List(n) | TC |S| TTL | 626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 627 | Message as shown in Figure 5 or 6 | 628 . . 629 +---------------------------------------------------------------+ 631 Figure 8: Probe Response Message for SR-MPLS Policy 633 3.2.3.3. Probe Response Message for SRv6 Policy 635 The message content for sending probe response message in-band using 636 UDP header for two-way end-to-end performance measurement of an SRv6 637 Policy is shown in Figure 9. For SRv6 Policy, the SRv6 SID list in 638 the SRH of the probe response message is built using the SRv6 Segment 639 List received in the Return Path TLV in the probe query message. 641 0 1 2 3 642 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 643 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 644 | SRH | 645 . END.OTP (DM) or END.OP (LM) with Target SRv6 SID . 646 . . 647 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 648 | Message as shown in Figure 5 or 6 (with IPv6 Addresses) | 649 . . 650 +---------------------------------------------------------------+ 652 Figure 9: Probe Response Message for SRv6 Policy 654 4. Performance Measurement for P2MP SR Policies 656 The procedures for delay and loss measurement described in this 657 document for Point-to-Point (P2P) SR-MPLS Policies are also equally 658 applicable to the Point-to-Multipoint (P2MP) SR Policies. 660 5. ECMP Support 662 An SR Policy can have ECMPs between the source and transit nodes, 663 between transit nodes and between transit and destination nodes. 664 Usage of Anycast SID [RFC8402] by an SR Policy can result in ECMP 665 paths via transit nodes part of that Anycast group. The PM probe 666 messages need to be sent to traverse different ECMP paths to measure 667 performance delay of an SR Policy. 669 Forwarding plane has various hashing functions available to forward 670 packets on specific ECMP paths. Following mechanisms can be used in 671 PM probe messages to take advantage of the hashing function in 672 forwarding plane to influence the path taken by them. 674 o The mechanisms described in [RFC8029] [RFC5884] for handling ECMPs 675 are also applicable to the performance measurement. In the IP/UDP 676 header of the PM probe messages, Destination Addresses in 127/8 677 range for IPv4 or 0:0:0:0:0:FFFF:7F00/104 range for IPv6 can be 678 used to exercise a particular ECMP path. As specified in 679 [RFC6437], 3-tuple of Flow Label, Source Address and Destination 680 Address fields in the IPv6 header can also be used. 682 o For SR-MPLS, entropy label [RFC6790] in the PM probe messages can 683 be used. 685 o For SRv6, Flow Label in SRH [I-D.6man-segment-routing-header] of 686 the PM probe messages can be used. 688 6. Sequence Numbers 690 The message formats for DM and LM [RFC6374] can carry either 691 timestamp or sequence number but not both. There are case where both 692 timestamp and sequence number are desired for both DM and LM. 693 Sequence numbers can be useful when some probe query messages are 694 lost or they arrive out of order. In addition, the sequence numbers 695 can be useful for detecting denial-of-service (DoS) attacks on UDP 696 ports. 698 6.1. Sequence Number TLV in Unauthenticated Mode 700 [RFC6374] defines DM and LM probe query and response messages that 701 can include one or more optional TLVs. New TLV Type (value TBA3) is 702 defined in this document to carry sequence number for probe query and 703 response messages for delay and loss measurement. The format of the 704 Sequence Number TLV is shown in Figure 10: 706 0 1 2 3 707 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 708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 709 | Type TBA3 | Length | Reserved | 710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 711 | Sequence Number | 712 ~ ~ 713 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 715 Figure 10: Sequence Number TLV - Unauthenticated Mode 717 o The sequence numbers start with 0 and are incremented by one for 718 each subsequent probe query packet. 720 o The sequence number are independent for DM and LM messages. 722 o The sequence number can be of any length determined by the querier 723 node. 725 o The Sequence Number TLV is optional. 727 o The PM querier node SHOULD only insert one Sequence Number TLV in 728 the probe query message and the responder node in the probe 729 response message SHOULD return the first Sequence Number TLV from 730 the probe query message and ignore the other Sequence Number TLVs 731 if present. 733 o When Sequence Number TLV is added, the DM and LM messages SHOULD 734 NOT carry sequence number in the timestamp field of the message. 736 6.2. Sequence Number TLV in Authenticated Mode 738 The PM probe query and reply packet format in authenticated mode 739 includes a key Hashed Message Authentication Code (HMAC) ([RFC2104]) 740 hash. Each probe query and reply messages are authenticated by 741 adding Sequence Number with Hashed Message Authentication Code (HMAC) 742 TLV. It uses HMAC-SHA-256 truncated to 128 bits (similarly to the 743 use of it in IPSec defined in [RFC4868]); hence the length of the 744 HMAC field is 16 octets. HMAC uses own key and the definition of the 745 mechanism to distribute the HMAC key is outside the scope of this 746 document. 748 In authenticated mode, only the sequence number is encrypted, and the 749 other payload fields are sent in clear text. The probe packet MAY 750 include Comp.MBZ (Must Be Zero) variable length field to align the 751 packet on 16 octets boundary. 753 0 1 2 3 754 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 755 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 756 | Type TBA4 | Length | Reserved | 757 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 758 | Sequence Number | 759 ~ ~ 760 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 761 ~ Comp.MBZ ~ 762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 763 | HMAC (16 octets) | 764 | | 765 | | 766 | | 767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 769 Figure 11: Sequence Number TLV - Authenticated Mode 771 o This TLV is mandatory in the authenticated mode. 773 o The node MUST discard the probe message if HMAC is invalid. 775 o The Sequence Number follows the same processing rule as defined in 776 the unauthenticated mode. 778 7. Security Considerations 780 The performance measurement is intended for deployment in 781 well-managed private and service provider networks. As such, it 782 assumes that a node involved in a measurement operation has 783 previously verified the integrity of the path and the identity of the 784 far end responder node. The security considerations described in 785 Section 8 of [RFC6374] are applicable to this specification, and 786 particular attention should be paid to the last three paragraphs. 788 Use of HMAC-SHA-256 in the authenticated mode defined in this 789 document protects the data integrity of the probe messages. SRv6 has 790 HMAC protection authentication defined for SRH 791 [I-D.6man-segment-routing-header]. Hence, PM probe messages for SRv6 792 may not need authentication mode. Cryptographic measures may be 793 enhanced by the correct configuration of access-control lists and 794 firewalls. 796 8. IANA Considerations 798 IANA is requested to allocate values for the following Return Path 799 TLV Type for RFC 6374 to be carried in PM probe query messages: 801 o Type TBA1: Return Path TLV 803 IANA is requested to allocate the values for the following Sub-TLV 804 Types for the Return Path TLV. 806 o Type 1: SR-MPLS Label Stack of the Reverse SR Policy 808 o Type 2: SR-MPLS Binding SID of the Reverse SR Policy 810 o Type 3: SRv6 Segment List of the Reverse SR Policy 812 o Type 4: SRv6 Binding SID of the Reverse SR Policy 814 IANA is also requested to allocate a value for the following Block 815 Number TLV Type for RFC 6374 to be carried in the PM probe query and 816 response messages for loss measurement: 818 o Type TBA2: Block Number TLV 820 IANA is also requested to allocate a value for the following Sequence 821 Number TLV Types for RFC 6374 to be carried in the PM probe query and 822 response messages for delay and loss measurement: 824 o Type TBA3: Sequence Number TLV in Unauthenticated Mode 826 o Type TBA4: Sequence Number TLV in Authenticated Mode 828 9. References 830 9.1. Normative References 832 [RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 833 August 1980. 835 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 836 Requirement Levels", RFC 2119, March 1997. 838 [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay 839 Measurement for MPLS networks', RFC 6374, September 2011. 841 [RFC7876] Bryant, S., Sivabalan, S., and Soni, S., "UDP Return Path 842 for Packet Loss and Delay Measurement for MPLS Networks", 843 RFC 7876, July 2016. 845 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 846 2119 Key Words", RFC 8174, May 2017. 848 [I-D.spring-srv6-oam] Ali, Z., et al., "Operations, Administration, 849 and Maintenance (OAM) in Segment Routing Networks with 850 IPv6 Data plane (SRv6)", draft-ali-spring-srv6-oam. 852 9.2. Informative References 854 [IEEE1588] IEEE, "1588-2008 IEEE Standard for a Precision Clock 855 Synchronization Protocol for Networked Measurement and 856 Control Systems", March 2008. 858 [Y1731] ITU-T Recommendation Y.1731 (02/08), "OAM functions and 859 mechanisms for Ethernet based networks", February 2008. 861 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 862 Hashing for Message Authentication", RFC 2104, DOI 863 10.17487/RFC2104, February 1997, . 866 [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. 867 Zekauskas, "A One-way Active Measurement Protocol 868 (OWAMP)", RFC 4656, September 2006. 870 [RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA- 871 384, and HMAC-SHA-512 with IPsec", RFC 4868,DOI 872 10.17487/RFC4868, May 2007, . 875 [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. 876 Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", 877 RFC 5357, October 2008. 879 [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, 880 "Bidirectional Forwarding Detection (BFD) for MPLS Label 881 Switched Paths (LSPs)", RFC 5884, DOI 10.17487/RFC5884, 882 June 2010. 884 [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, 885 "IPv6 Flow Label Specification", RFC 6437, November 2011. 887 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 888 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 889 RFC 6790, November 2012. 891 [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Kumar, N., 892 Aldrin, S. and M. Chen, "Detecting Multiprotocol Label 893 Switched (MPLS) Data-Plane Failures", RFC 8029, March 894 2017. 896 [RFC8321] Fioccola, G. Ed., "Alternate-Marking Method for Passive 897 and Hybrid Performance Monitoring", RFC 8321, January 898 2018. 900 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 901 Decraene, B., Litkowski, S., and R. Shakir, "Segment 902 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 903 July 2018, . 905 [I-D.spring-segment-routing-policy] Filsfils, C., et al., "Segment 906 Routing Policy Architecture", 907 draft-ietf-spring-segment-routing-policy, work in 908 progress. 910 [I-D.spring-sr-p2mp-policy] Voyer, D. Ed., et al., "SR Replication 911 Policy for P2MP Service Delivery", 912 draft-voyer-spring-sr-p2mp-policy, work in progress. 914 [I-D.6man-segment-routing-header] Filsfils, C., et al., "IPv6 915 Segment Routing Header (SRH)", 916 draft-ietf-6man-segment-routing-header, work in progress. 918 [I-D.spring-rfc6374-srpm-mpls] Filsfils, C., Gandhi, R. Ed., et al. 919 "Performance Measurement in Segment Routing Networks with 920 MPLS Data Plane", draft-gandhi-spring-rfc6374-srpm-mpls, 921 work in progress. 923 [I-D.pce-binding-label-sid] Filsfils, C., et al., "Carrying Binding 924 Label Segment-ID in PCE-based Networks", 925 draft-sivabalan-pce-binding-label-sid, work in progress. 927 [I-D.spring-mpls-path-segment] Cheng, W., et al., "Path Segment in 928 MPLS Based Segment Routing Network", 929 draft-cheng-spring-mpls-path-segment, work in progress. 931 [I-D.ippm-stamp] Mirsky, G. et al. "Simple Two-way Active 932 Measurement Protocol", draft-ietf-ippm-stamp, work in 933 progress. 935 [BBF.TR-390] "Performance Measurement from IP Edge to Customer 936 Equipment using TWAMP Light", BBF TR-390, May 2017. 938 Acknowledgments 940 The authors would like to thank Nagendra Kumar and Carlos Pignataro 941 for the discussion on SRv6 Performance Measurement. The authors 942 would also like to thank Stewart Bryant for the discussion on UDP 943 port allocation for Performance Measurement and Greg Mirsky for 944 providing many useful comments and suggestions. 946 Contributors 948 Sagar Soni 949 Cisco Systems, Inc. 950 Email: sagsoni@cisco.com 952 Patrick Khordoc 953 Cisco Systems, Inc. 954 Email: pkhordoc@cisco.com 956 Zafar Ali 957 Cisco Systems, Inc. 958 Email: zali@cisco.com 960 Authors' Addresses 962 Rakesh Gandhi (editor) 963 Cisco Systems, Inc. 964 Canada 965 Email: rgandhi@cisco.com 967 Clarence Filsfils 968 Cisco Systems, Inc. 969 Email: cfilsfil@cisco.com 971 Daniel Voyer 972 Bell Canada 973 Email: daniel.voyer@bell.ca 975 Stefano Salsano 976 Universita di Roma "Tor Vergata" 977 Italy 978 Email: stefano.salsano@uniroma2.it 979 Pier Luigi Ventre 980 CNIT 981 Italy 982 Email: pierluigi.ventre@cnit.it 984 Mach(Guoyi) Chen 985 Huawei 986 Email: mach.chen@huawei.com