idnits 2.17.1 draft-gandhi-spring-twamp-srpm-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 9, 2019) is 1903 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 13, 2019 D. Voyer 6 Bell Canada 7 February 9, 2019 9 In-band Performance Measurement Using TWAMP 10 for Segment Routing Networks 11 draft-gandhi-spring-twamp-srpm-00 13 Abstract 15 Segment Routing (SR) is applicable to both Multiprotocol Label 16 Switching (SR-MPLS) and IPv6 (SRv6) data planes. This document 17 specifies procedures for sending and processing in-band probe query 18 and response messages for Performance Measurement. The procedure 19 uses the mechanisms defined in RFC 5357 (Two-Way Active Measurement 20 Protocol (TWAMP)) for Delay Measurement, and also uses the mechanisms 21 for direct-mode loss measurement defined in this document. The 22 procedure specified is applicable to SR-MPLS and SRv6 data planes for 23 both links and end-to-end measurement for SR Policies. 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 http://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 Copyright Notice 42 Copyright (c) 2019 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 59 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 60 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3 61 2.3. Reference Topology . . . . . . . . . . . . . . . . . . . . 4 62 2.4. In-band Probe Messages . . . . . . . . . . . . . . . . . . 5 63 3. Probe Messages . . . . . . . . . . . . . . . . . . . . . . . . 5 64 3.1. Probe Query Message . . . . . . . . . . . . . . . . . . . 5 65 3.1.1. Delay Measurement Probe Query Message . . . . . . . . 5 66 3.1.2. Loss Measurement Probe Query Message . . . . . . . . . 6 67 3.1.3. Probe Query for SR Links . . . . . . . . . . . . . . . 10 68 3.1.4. Probe Query for End-to-end Measurement for SR Policy . 11 69 3.1.4.1. Probe Query Message for SR-MPLS Policy . . . . . . 11 70 3.1.4.2. Probe Query Message for SRv6 Policy . . . . . . . 11 71 3.2. Probe Response Message . . . . . . . . . . . . . . . . . . 12 72 3.2.1. One-way Measurement . . . . . . . . . . . . . . . . . 12 73 3.2.2. Two-way Measurement . . . . . . . . . . . . . . . . . 12 74 3.2.2.1. Probe Response Message for SR-MPLS Policy . . . . 13 75 3.2.2.2. Probe Response Message for SRv6 Policy . . . . . . 13 76 4. Packet Loss Calculation . . . . . . . . . . . . . . . . . . . 13 77 5. Performance Measurement for P2MP SR Policies . . . . . . . . . 14 78 6. ECMP Support . . . . . . . . . . . . . . . . . . . . . . . . . 14 79 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 80 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 81 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 82 9.1. Normative References . . . . . . . . . . . . . . . . . . . 15 83 9.2. Informative References . . . . . . . . . . . . . . . . . . 15 84 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 18 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 87 1. Introduction 89 Segment Routing (SR) technology greatly simplifies network operations 90 for Software Defined Networks (SDNs). SR is applicable to both 91 Multiprotocol Label Switching (SR-MPLS) and IPv6 (SRv6) data planes. 93 SR takes advantage of the Equal-Cost Multipaths (ECMPs) between 94 source, transit and destination nodes. SR Policies as defined in 95 [I-D.spring-segment-routing-policy] are used to steer traffic through 96 a specific, user-defined path using a stack of Segments. Built-in SR 97 Performance Measurement (PM) is one of the essential requirements to 98 provide Service Level Agreements (SLAs). 100 The One-Way Active Measurement Protocol (OWAMP) defined in [RFC4656] 101 and Two-Way Active Measurement Protocol (TWAMP) defined in [RFC5357] 102 provide capabilities for the measurement of various performance 103 metrics in IP networks. These protocols rely on control channel 104 signaling to establish a test channel over an UDP path. These 105 protocols lack support for direct-mode Loss Measurement (LM) to 106 detect actual data traffic loss which is required in SR networks. 107 The Simple Two-way Active Measurement Protocol (STAMP) 108 [I-D.ippm-stamp] alleviates the control channel signaling by using 109 configuration data model to provision test channels and required UDP 110 ports. The TWAMP Light from broadband forum [BBF.TR-390] provides 111 simplified mechanisms for active performance measurement in Customer 112 Edge IP networks. 114 This document specifies procedures for sending and processing in-band 115 probe query and response messages for Performance Measurement. The 116 procedure uses the mechanisms defined in RFC 5357 (Two-Way Active 117 Measurement Protocol (TWAMP)) for Delay Measurement, and also uses 118 the mechanisms for direct-mode loss measurement defined in this 119 document. The procedure specified is applicable to SR-MPLS and SRv6 120 data planes for both links and end-to-end measurement for SR 121 Policies. For SR Policies, there are ECMPs between the source and 122 transit nodes, between transit nodes and between transit and 123 destination nodes. This document also defines mechanisms for 124 handling ECMPs of SR Policies for performance delay measurement. 126 2. Conventions Used in This Document 128 2.1. Requirements Language 130 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 131 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 132 document are to be interpreted as described in [RFC2119] [RFC8174] 133 when, and only when, they appear in all capitals, as shown here. 135 2.2. Abbreviations 137 BSID: Binding Segment ID. 139 DM: Delay Measurement. 141 ECMP: Equal Cost Multi-Path. 143 LM: Loss Measurement. 145 MPLS: Multiprotocol Label Switching. 147 NTP: Network Time Protocol. 149 OWAMP: One-Way Active Measurement Protocol. 151 PM: Performance Measurement. 153 PSID: Path Segment Identifier. 155 PTP: Precision Time Protocol. 157 SID: Segment ID. 159 SL: Segment List. 161 SR: Segment Routing. 163 SR-MPLS: Segment Routing with MPLS data plane. 165 SRv6: Segment Routing with IPv6 data plane. 167 STAMP: Simple Two-way Active Measurement Protocol. 169 TC: Traffic Class. 171 TWAMP: Two-Way Active Measurement Protocol. 173 2.3. Reference Topology 175 In the reference topology, the querier node R1 initiates a probe 176 query for performance measurement and the responder node R5 sends a 177 probe response for the query message received. The probe response 178 may be sent to the querier node R1. The nodes R1 and R5 may be 179 directly connected via a link enabled with Segment Routing or there 180 exists a Point-to-Point (P2P) SR Policy 181 [I-D.spring-segment-routing-policy] on node R1 with destination to 182 node R5. In case of Point-to-Multipoint (P2MP), SR Policy 183 originating from source node R1 may terminate on multiple destination 184 leaf nodes [I-D.spring-sr-p2mp-policy]. 186 +-------+ Query +-------+ 187 | | - - - - - - - - - ->| | 188 | R1 |---------------------| R5 | 189 | |<- - - - - - - - - - | | 190 +-------+ Response +-------+ 192 Reference Topology 194 Both Delay and Loss performance measurement is performed in-band for 195 the traffic traversing between node R1 and node R5. One-way delay 196 and two-way delay measurements are defined in [RFC4656] and 197 [RFC5357], respectively. One-way loss measurement provides receive 198 packet loss whereas two-way loss measurement provides both transmit 199 and receive packet loss. 201 2.4. In-band Probe Messages 203 For both Delay and Loss measurements for links and SR Policies, no PM 204 session is created on the responder node. The probe messages for 205 Delay measurement are sent in-band by the querier node to measure the 206 delay experienced by the actual traffic flowing on the links and SR 207 Policies. For Loss measurement, in-band probe messages are used to 208 collect the traffic counter for the incoming link or incoming SID on 209 which the probe query message is received at the responder node R5 as 210 it has no PM session state present on the node. The performance 211 measurement for Delay and Loss using out-of-band probe query messages 212 are outside the scope of this document. 214 3. Probe Messages 216 3.1. Probe Query Message 218 In this document, procedures using [RFC5357] is used for Delay and 219 Loss measurements for SR links and end-to-end SR Policies. A 220 user-configured UDP port is used for identifying PM probe packets 221 that does not require to bootstrap PM sessions. A UDP port number 222 from the Dynamic and/or Private Ports range 49152-65535 is used as 223 the destination UDP port. This approach is similar to the one 224 defined in STAMP protocol [I-D.ippm-stamp]. The IPv4 TTL or IPv6 Hop 225 Limit field of the IP header MUST be set to 255. 227 3.1.1. Delay Measurement Probe Query Message 229 The message content for Delay Measurement probe query message using 230 UDP header [RFC768] is shown in Figure 1. The DM probe query message 231 is sent with user-configured Destination UDP port number [I-D.ippm- 232 stamp]. The Source UDP port is set to the same value for two-way 233 delay measurement. The DM probe query message contains the payload 234 for delay measurement defined in Section 4.2.1 of [RFC5357] for TWAMP 235 or in Section 4.1.2 of [RFC4656] for OWAMP. 237 +---------------------------------------------------------------+ 238 | IP Header | 239 . Source IP Address = Querier IPv4 or IPv6 Address . 240 . Destination IP Address = Responder IPv4 or IPv6 Address . 241 . Protocol = UDP . 242 . Router Alert Option Not Set . 243 . . 244 +---------------------------------------------------------------+ 245 | UDP Header | 246 . Source Port = As chosen by Querier . 247 . Destination Port = User-configured Port for Delay Measurement. 248 . . 249 +---------------------------------------------------------------+ 250 | Payload = Message as specified in Section 4.2.1 of RFC 5357 | 251 | | Payload = Message as specified in Section 4.1.2 of RFC 4656 | 252 . . 253 +---------------------------------------------------------------+ 255 Figure 1: DM Probe Query Message 257 Timestamp field is eight bytes and by default uses the IEEE 1588v2 258 Precision Time Protocol (PTP) truncated 64-bit timestamp format 259 [IEEE1588]. 261 3.1.2. Loss Measurement Probe Query Message 263 The message content for Loss Measurement probe query message using 264 UDP header [RFC768] is shown in Figure 2. The LM probe query message 265 is sent with user-configured Destination UDP port number [I-D.ippm- 266 stamp]. The Source UDP port is set to the same value for two-way 267 loss measurement. The LM probe query message contains the payload 268 for loss measurement defined below. 270 +---------------------------------------------------------------+ 271 | IP Header | 272 . Source IP Address = Querier IPv4 or IPv6 Address . 273 . Destination IP Address = Responder IPv4 or IPv6 Address . 274 . Protocol = UDP . 275 . Router Alert Option Not Set . 276 . . 277 +---------------------------------------------------------------+ 278 | UDP Header | 279 . Source Port = As chosen by Querier . 281 . Destination Port = User-configured Port for Loss Measurement . 282 . . 283 +---------------------------------------------------------------+ 284 | Sequence Number | 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 | Transmit Counter | 287 | | 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 | Receive Counter | 290 | | 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 | Sender Sequence Number | 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 | Sender Counter | 295 | | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | Sender TTL | Block Number | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | Padding | 300 . . 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 Figure 2A: LM Probe Query Message for TWAMP 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 . Router Alert Option Not Set . 311 . . 312 +---------------------------------------------------------------+ 313 | UDP Header | 314 . Source Port = As chosen by Querier . 315 . Destination Port = User-configured Port for Loss Measurement . 316 . . 317 +---------------------------------------------------------------+ 318 | Sequence Number | 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | MBZ (12 octets) | 321 | | 322 | | 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 | Transmit Counter | 325 | | 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 | MBZ (8 octets) | 328 | | 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 | Receive Counter | 331 | | 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 | MBZ (8 octets) | 334 | | 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 | Sender Sequence Number | 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 | MBZ (12 octets) | 339 | | 340 | | 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 | Sender Counter | 343 | | 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 | MBZ (8 octets) | 346 | | 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 | Sender TTL | Block Number | 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 | MBZ (12 octets) | 351 | | 352 | | 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 | HMAC (16 octets) | 355 | | 356 | | 357 | | 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 | Padding | 360 . . 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 Figure 2B: LM Probe Query Message for TWAMP - Authenticated Mode 365 +---------------------------------------------------------------+ 366 | IP Header | 367 . Source IP Address = Querier IPv4 or IPv6 Address . 368 . Destination IP Address = Responder IPv4 or IPv6 Address . 369 . Protocol = UDP . 370 . Router Alert Option Not Set . 371 . . 372 +---------------------------------------------------------------+ 373 | UDP Header | 374 . Source Port = As chosen by Querier . 376 . Destination Port = User-configured Port for Loss Measurement . 377 . . 378 +---------------------------------------------------------------+ 379 | Sequence Number | 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 | Transmit Counter | 382 | | 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 | Sender TTL | Block Number | 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 | Padding | 387 . . 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 Figure 2C: LM Probe Query Message for OWAMP 392 +---------------------------------------------------------------+ 393 | IP Header | 394 . Source IP Address = Querier IPv4 or IPv6 Address . 395 . Destination IP Address = Responder IPv4 or IPv6 Address . 396 . Protocol = UDP . 397 . Router Alert Option Not Set . 398 . . 399 +---------------------------------------------------------------+ 400 | UDP Header | 401 . Source Port = As chosen by Querier . 402 . Destination Port = User-configured Port for Loss Measurement . 403 . . 404 +---------------------------------------------------------------+ 405 | Sequence Number | 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 | MBZ (12 octets) | 408 | | 409 | | 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 | Transmit Counter | 412 | | 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 | MBZ (8 octets) | 415 | | 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 | Sender TTL | Block Number | 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 | MBZ (12 octets) | 420 | | 421 | | 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 | HMAC (16 octets) | 424 | | 425 | | 426 | | 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 | Padding | 429 . . 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 Figure 2D: LM Probe Query Message for OWAMP - Authenticated Mode 434 Sequence Number (32-bit): As defined in [RFC5357]. 436 Transmit Counter (64-bit): The number of packets sent by the querier 437 node in the query message and by the responder node in the response 438 message. The counter is always written at fixed location in the 439 probe query and response messages. 441 Receive Counter (64-bit): The number of packets received at the 442 responder node. It is written by the responder node in the probe 443 response message. 445 Sender Counter (64-bit): This is the exact copy of the transmit 446 counter from the received query message. It is written by the 447 responder node in the probe response message. 449 Sender Sequence Number (32-bit): As defined in [RFC5357]. 451 Sender TTL: As defined in [RFC5357]. 453 Block Number (24-bit): The Loss Measurement using Alternate-Marking 454 method defined in [RFC8321] requires to identify the Block Number (or 455 color) of the traffic counters. The probe query and response 456 messages carry Block Number for the traffic counters for loss 457 measurement. In both probe query and response messages, the counters 458 MUST belong to the same Block Number. 460 The Path Segment Identifier (PSID) [I-D.spring-mpls-path-segment] of 461 the SR-MPLS Policy is used for accounting received traffic on the 462 egress node for loss measurement. 464 3.1.3. Probe Query for SR Links 466 The probe query message as defined in Figure 1 is sent in-band for 467 Delay measurement. The probe query message as defined in Figure 2 is 468 sent in-band for Loss measurement. 470 3.1.4. Probe Query for End-to-end Measurement for SR Policy 472 3.1.4.1. Probe Query Message for SR-MPLS Policy 474 The message content for in-band probe query message using UDP header 475 for end-to-end performance measurement of SR-MPLS Policy is shown in 476 Figure 3. 478 0 1 2 3 479 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 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 481 | Segment List(0) | TC |S| TTL | 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 . . 484 . . 485 . . 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 | Segment List(n) | TC |S| TTL | 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 489 | Message as shown in Figure 1 for DM or Figure 2 for LM | 490 . . 491 +---------------------------------------------------------------+ 493 Figure 3: Probe Query Message for SR-MPLS Policy 495 The Segment List (SL) can be empty to indicate Implicit NULL label 496 case. 498 3.1.4.2. Probe Query Message for SRv6 Policy 500 The in-band probe query messages using UDP header for end-to-end 501 performance measurement of an SRv6 Policy is sent using SRv6 Segment 502 Routing Header (SRH) and Segment List of the SRv6 Policy as defined 503 in [I-D.6man-segment-routing-header] and is shown in Figure 4. 505 0 1 2 3 506 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 507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 | SRH | 509 . END.OTP (DM) or END.OP (LM) with Target SRv6 SID . 510 . . 511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 512 | Message as shown in Figure 1 for DM or Figure 2 for LM | 513 . (Using IPv6 Addresses) . 514 . . 515 +---------------------------------------------------------------+ 517 Figure 4: Probe Query Message for SRv6 Policy 519 For delay measurement of SRv6 Policy, END function END.OTP 520 [I-D.spring-srv6-oam] is used with the target SRv6 SID to punt probe 521 messages on the target node, as shown in Figure 4. Similarly, for 522 loss measurement of SRv6 Policy, END function END.OP 523 [I-D.spring-srv6-oam] is used with target SRv6 SID to punt probe 524 messages on the target node. 526 3.2. Probe Response Message 528 The probe response message is sent using the IP/UDP information from 529 the probe query message. The content of the probe response message 530 is shown in Figure 5. 532 +---------------------------------------------------------------+ 533 | IP Header | 534 . Source IP Address = Responder IPv4 or IPv6 Address . 535 . Destination IP Address = Source IP Address from Query . 536 . Protocol = UDP . 537 . Router Alert Option Not Set . 538 . . 539 +---------------------------------------------------------------+ 540 | UDP Header | 541 . Source Port = As chosen by Responder . 542 . Destination Port = Source Port from Query . 543 . . 544 +---------------------------------------------------------------+ 545 | Payload as specified in Section 4.2.1 of RFC 5357, or | 546 . Payload as specified in Figure 2 in this document . 547 . . 548 +---------------------------------------------------------------+ 550 Figure 5: Probe Response Message 552 3.2.1. One-way Measurement 554 For one-way performance measurement, the probe response message as 555 defined in Figure 5 is sent for both SR links and SR Policies. 557 3.2.2. Two-way Measurement 559 For two-way performance measurement, when using a bidirectional 560 channel, the probe response message as defined in Figure 5 is sent 561 back in-band to the querier node. 563 The Path Segment Identifier (PSID) [I-D.spring-mpls-path-segment] of 564 the forward SR Policy can be used to find the reverse SR Policy to 565 send the probe response message for two-way measurement of SR Policy. 567 3.2.2.1. Probe Response Message for SR-MPLS Policy 569 The message content for sending probe response message in-band using 570 UDP header for two-way end-to-end performance measurement of an 571 SR-MPLS Policy is shown in Figure 6. 573 0 1 2 3 574 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 575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 576 | Segment List(0) | TC |S| TTL | 577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 578 . . 579 . . 580 . . 581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 582 | Segment List(n) | TC |S| TTL | 583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 584 | Message as shown in Figure 5 | 585 . . 586 +---------------------------------------------------------------+ 588 Figure 6: Probe Response Message for SR-MPLS Policy 590 3.2.2.2. Probe Response Message for SRv6 Policy 592 The message content for sending probe response message in-band using 593 UDP header for two-way end-to-end performance measurement of an SRv6 594 Policy is shown in Figure 7. 596 0 1 2 3 597 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 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 599 | SRH | 600 . END.OTP (DM) or END.OP (LM) with Target SRv6 SID . 601 . . 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 603 | Message as shown in Figure 5 (with IPv6 Addresses) | 604 . . 605 +---------------------------------------------------------------+ 607 Figure 7: Probe Response Message for SRv6 Policy 609 4. Packet Loss Calculation 611 The formula for calculating the one-way packet loss using counters 612 for a given block number is as following: 614 o One-way Packet_Loss[n-1, n] = (Sender_Counter[n] - 615 Sender_Counter[n-1]) - (Receive_Counter[n] - Receive_Counter[n-1]) 617 5. Performance Measurement for P2MP SR Policies 619 The procedures for delay and loss measurement described in this 620 document for Point-to-Point (P2P) SR-MPLS Policies are also equally 621 applicable to the Point-to-Multipoint (P2MP) SR Policies. 623 6. ECMP Support 625 An SR Policy can have ECMPs between the source and transit nodes, 626 between transit nodes and between transit and destination nodes. 627 Usage of Anycast SID [RFC8402] by an SR Policy can result in ECMP 628 paths via transit nodes part of that Anycast group. The PM probe 629 messages need to be sent to traverse different ECMP paths to measure 630 performance delay of an SR Policy. 632 Forwarding plane has various hashing functions available to forward 633 packets on specific ECMP paths. Following mechanisms can be used in 634 PM probe messages to take advantage of the hashing function in 635 forwarding plane to influence the path taken by them. 637 o The mechanisms described in [RFC8029] [RFC5884] for handling ECMPs 638 are also applicable to the performance measurement. In the IP/UDP 639 header of the PM probe messages, Destination Addresses in 127/8 640 range for IPv4 or 0:0:0:0:0:FFFF:7F00/104 range for IPv6 can be 641 used to exercise a particular ECMP path. As specified in 642 [RFC6437], 3-tuple of Flow Label, Source Address and Destination 643 Address fields in the IPv6 header can also be used. 645 o For SR-MPLS, entropy label [RFC6790] in the PM probe messages can 646 be used. 648 o For SRv6, Flow Label in SRH [I-D.6man-segment-routing-header] of 649 the PM probe messages can be used. 651 7. Security Considerations 653 The performance measurement is intended for deployment in 654 well-managed private and service provider networks. As such, it 655 assumes that a node involved in a measurement operation has 656 previously verified the integrity of the path and the identity of the 657 far end responder node. 659 If desired, attacks can be mitigated by performing basic validation 660 and sanity checks, at the querier, of the counter or timestamp fields 661 in received measurement response messages. The minimal state 662 associated with these protocols also limits the extent of measurement 663 disruption that can be caused by a corrupt or invalid message to a 664 single query/response cycle. 666 Use of HMAC-SHA-256 in the authenticated mode defined in this 667 document protects the data integrity of the probe messages. SRv6 has 668 HMAC protection authentication defined for SRH 669 [I-D.6man-segment-routing-header]. Hence, PM probe messages for SRv6 670 may not need authentication mode. Cryptographic measures may be 671 enhanced by the correct configuration of access-control lists and 672 firewalls. 674 8. IANA Considerations 676 This document does not require any IANA actions. 678 9. References 680 9.1. Normative References 682 [RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 683 August 1980. 685 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 686 Requirement Levels", RFC 2119, March 1997. 688 [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. 689 Zekauskas, "A One-way Active Measurement Protocol 690 (OWAMP)", RFC 4656, September 2006. 692 [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. 693 Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", 694 RFC 5357, October 2008. 696 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 697 2119 Key Words", RFC 8174, May 2017. 699 [I-D.spring-srv6-oam] Ali, Z., et al., "Operations, Administration, 700 and Maintenance (OAM) in Segment Routing Networks with 701 IPv6 Data plane (SRv6)", draft-ali-spring-srv6-oam. 703 9.2. Informative References 705 [IEEE1588] IEEE, "1588-2008 IEEE Standard for a Precision Clock 706 Synchronization Protocol for Networked Measurement and 707 Control Systems", March 2008. 709 [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, 710 "Bidirectional Forwarding Detection (BFD) for MPLS Label 711 Switched Paths (LSPs)", RFC 5884, DOI 10.17487/RFC5884, 712 June 2010. 714 [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, 715 "IPv6 Flow Label Specification", RFC 6437, November 2011. 717 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 718 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 719 RFC 6790, November 2012. 721 [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Kumar, N., 722 Aldrin, S. and M. Chen, "Detecting Multiprotocol Label 723 Switched (MPLS) Data-Plane Failures", RFC 8029, March 724 2017. 726 [RFC8321] Fioccola, G. Ed., "Alternate-Marking Method for Passive 727 and Hybrid Performance Monitoring", RFC 8321, January 728 2018. 730 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 731 Decraene, B., Litkowski, S., and R. Shakir, "Segment 732 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 733 July 2018, . 735 [I-D.spring-segment-routing-policy] Filsfils, C., et al., "Segment 736 Routing Policy Architecture", 737 draft-ietf-spring-segment-routing-policy, work in 738 progress. 740 [I-D.spring-sr-p2mp-policy] Voyer, D. Ed., et al., "SR Replication 741 Policy for P2MP Service Delivery", 742 draft-voyer-spring-sr-p2mp-policy, work in progress. 744 [I-D.spring-mpls-path-segment] Cheng, W., et al., "Path Segment in 745 MPLS Based Segment Routing Network", draft-cheng-spring- 746 mpls-path-segment, work in progress. 748 [I-D.6man-segment-routing-header] Filsfils, C., et al., "IPv6 749 Segment Routing Header (SRH)", 750 draft-ietf-6man-segment-routing-header, work in progress. 752 [I-D.ippm-stamp] Mirsky, G. et al. "Simple Two-way Active 753 Measurement Protocol", draft-ietf-ippm-stamp, work in 754 progress. 756 [BBF.TR-390] "Performance Measurement from IP Edge to Customer 757 Equipment using TWAMP Light", BBF TR-390, May 2017. 759 Acknowledgments 761 TBA 763 Authors' Addresses 765 Rakesh Gandhi (editor) 766 Cisco Systems, Inc. 767 Canada 768 Email: rgandhi@cisco.com 770 Clarence Filsfils 771 Cisco Systems, Inc. 772 Email: cfilsfil@cisco.com 774 Daniel Voyer 775 Bell Canada 776 Email: daniel.voyer@bell.ca