idnits 2.17.1 draft-gandhi-spring-twamp-srpm-01.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 (May 15, 2019) is 1802 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: November 16, 2019 D. Voyer 6 Bell Canada 7 M. Chen 8 Huawei 9 May 15, 2019 11 Performance Measurement Using TWAMP 12 for Segment Routing Networks 13 draft-gandhi-spring-twamp-srpm-01 15 Abstract 17 Segment Routing (SR) is applicable to both Multiprotocol Label 18 Switching (SR-MPLS) and IPv6 (SRv6) data planes. This document 19 specifies procedures for sending and processing synthetic probe query 20 and response messages for Performance Measurement (PM). The 21 procedure uses the mechanisms defined in RFC 5357 (Two-Way Active 22 Measurement Protocol (TWAMP)) for Delay Measurement, and also uses 23 the mechanisms specified in this document for direct-mode Loss 24 Measurement. The procedure specified is applicable to SR-MPLS and 25 SRv6 data planes for both links and end-to-end measurement for SR 26 Policies. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 Copyright Notice 45 Copyright (c) 2019 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 62 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 63 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4 64 2.3. Reference Topology . . . . . . . . . . . . . . . . . . . . 4 65 3. Probe Messages . . . . . . . . . . . . . . . . . . . . . . . . 5 66 3.1. Probe Query Message . . . . . . . . . . . . . . . . . . . 5 67 3.1.1. Delay Measurement Probe Query Message . . . . . . . . 6 68 3.1.1.1. Delay Measurement Message Checksum Complement . . 6 69 3.1.1.2. Delay Measurement Authentication Mode . . . . . . 7 70 3.1.2. Loss Measurement Probe Query Message . . . . . . . . . 7 71 3.1.2.1. Loss Measurement Message Checksum Complement . . . 10 72 3.1.2.2. Loss Measurement Authentication Mode . . . . . . . 10 73 3.1.3. Probe Query for SR Links . . . . . . . . . . . . . . . 10 74 3.1.4. Probe Query for End-to-end Measurement for SR Policy . 10 75 3.1.4.1. Probe Query Message for SR-MPLS Policy . . . . . . 10 76 3.1.4.2. Probe Query Message for SRv6 Policy . . . . . . . 11 77 3.2. Probe Response Message . . . . . . . . . . . . . . . . . . 12 78 3.2.1. One-way Measurement Mode . . . . . . . . . . . . . . . 14 79 3.2.2. Two-way Measurement Mode . . . . . . . . . . . . . . . 15 80 3.2.2.1. Return Path TLV . . . . . . . . . . . . . . . . . 15 81 3.2.2.2. Probe Response Message for SR-MPLS Policy . . . . 16 82 3.2.2.3. Probe Response Message for SRv6 Policy . . . . . . 17 83 3.2.3. Loopback Measurement Mode . . . . . . . . . . . . . . 17 84 4. Packet Loss Calculation . . . . . . . . . . . . . . . . . . . 17 85 5. Performance Measurement for P2MP SR Policies . . . . . . . . . 18 86 6. ECMP Support for SR Policies . . . . . . . . . . . . . . . . . 18 87 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 88 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 89 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 90 9.1. Normative References . . . . . . . . . . . . . . . . . . . 19 91 9.2. Informative References . . . . . . . . . . . . . . . . . . 20 92 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 22 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 95 1. Introduction 97 Segment Routing (SR) technology greatly simplifies network operations 98 for Software Defined Networks (SDNs). SR is applicable to both 99 Multiprotocol Label Switching (SR-MPLS) and IPv6 (SRv6) data planes. 100 SR takes advantage of the Equal-Cost Multipaths (ECMPs) between 101 source, transit and destination nodes. SR Policies as defined in 102 [I-D.spring-segment-routing-policy] are used to steer traffic through 103 a specific, user-defined path using a stack of Segments. Built-in SR 104 Performance Measurement (PM) is one of the essential requirements to 105 provide Service Level Agreements (SLAs). 107 The One-Way Active Measurement Protocol (OWAMP) defined in [RFC4656] 108 and Two-Way Active Measurement Protocol (TWAMP) defined in [RFC5357] 109 provide capabilities for the measurement of various performance 110 metrics in IP networks using synthetic probe messages. These 111 protocols rely on control channel signaling to establish a test 112 channel over an UDP path. These protocols lack support for 113 direct-mode Loss Measurement (LM) to detect actual data traffic loss 114 which is required in SR networks. The Simple Two-way Active 115 Measurement Protocol (STAMP) [I-D.ippm-stamp] alleviates the control 116 channel signaling by using configuration data model to provision test 117 channels and UDP ports. The TWAMP Light from broadband forum 118 [BBF.TR-390] provides simplified mechanisms for active performance 119 measurement in Customer Edge IP networks. 121 This document specifies procedures for sending and processing 122 synthetic probe query and response messages for Performance 123 Measurement. The procedure uses the mechanisms defined in RFC 5357 124 (Two-Way Active Measurement Protocol (TWAMP)) for Delay Measurement 125 (DM), and also uses the mechanisms specified in this document for 126 direct-mode Loss Measurement (LM). The procedure specified is 127 applicable to SR-MPLS and SRv6 data planes for both links and 128 end-to-end measurement for SR Policies. For SR Policies, there are 129 Equal Cost Multi-Paths (ECMP) between the source and transit nodes, 130 between transit nodes and between transit and destination nodes. 131 This document also defines mechanisms for handling ECMPs of SR 132 Policies for performance delay measurement. 134 2. Conventions Used in This Document 136 2.1. Requirements Language 138 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 139 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 140 document are to be interpreted as described in [RFC2119] [RFC8174] 141 when, and only when, they appear in all capitals, as shown here. 143 2.2. Abbreviations 145 BSID: Binding Segment ID. 147 DM: Delay Measurement. 149 ECMP: Equal Cost Multi-Path. 151 LM: Loss Measurement. 153 MPLS: Multiprotocol Label Switching. 155 NTP: Network Time Protocol. 157 OWAMP: One-Way Active Measurement Protocol. 159 PM: Performance Measurement. 161 PSID: Path Segment Identifier. 163 PTP: Precision Time Protocol. 165 SID: Segment ID. 167 SL: Segment List. 169 SR: Segment Routing. 171 SR-MPLS: Segment Routing with MPLS data plane. 173 SRv6: Segment Routing with IPv6 data plane. 175 STAMP: Simple Two-way Active Measurement Protocol. 177 TC: Traffic Class. 179 TWAMP: Two-Way Active Measurement Protocol. 181 2.3. Reference Topology 183 In the reference topology, the querier node R1 initiates a probe 184 query for performance measurement and the responder node R5 sends a 185 probe response for the query message received. The probe response 186 may be sent to the querier node R1. The nodes R1 and R5 may be 187 directly connected via a link enabled with Segment Routing or there 188 exists a Point-to-Point (P2P) SR Policy 189 [I-D.spring-segment-routing-policy] on node R1 with destination to 190 node R5. In case of Point-to-Multipoint (P2MP), SR Policy 191 originating from source node R1 may terminate on multiple destination 192 leaf nodes [I-D.spring-sr-p2mp-policy]. 194 +-------+ Query +-------+ 195 | | - - - - - - - - - ->| | 196 | R1 |---------------------| R5 | 197 | |<- - - - - - - - - - | | 198 +-------+ Response +-------+ 200 Reference Topology 202 For delay and loss measurements, for both links and end-to-end SR 203 Policies, no PM session is created on the responder node R5. One-way 204 delay and two-way delay measurements are defined in [RFC4656] and 205 [RFC5357], respectively. One-way loss measurement provides receive 206 packet loss whereas two-way loss measurement provides both transmit 207 and receive packet loss. 209 For Performance Measurement, synthetic probe query and response 210 messages are used as following: 212 o For Delay Measurement, the probe messages are sent on the 213 congruent path of the data traffic by the querier node, and are 214 used to measure the delay experienced by the actual data traffic 215 flowing on the links and SR Policies. 217 o For Loss Measurement, the probe messages are sent on the congruent 218 path of the data traffic by the querier node, and are used to 219 collect the receive traffic counters for the incoming link or 220 incoming SID where the probe query messages are received at the 221 responder node (incoming link or incoming SID used as the 222 responder node has no PM session state present). 224 The In-Situ Operations, Administration, and Maintenance (IOAM) 225 mechanisms for SR-MPLS defined in [I-D.spring-ioam-sr-mpls] and for 226 SRv6 defined in [I-D.spring-srv6-oam] are used to carry PM 227 information in-band as part of the data traffic, and are outside the 228 scope of this document. 230 3. Probe Messages 232 3.1. Probe Query Message 234 In this document, the probe messages defined in [RFC5357] are used 235 for Delay and Loss measurements for SR links and end-to-end SR 236 Policies. The user-configured UDP ports (separate UDP port for each 237 message format) are used for identifying the PM probe packets and to 238 avoid signaling to bootstrap PM sessions. This approach is similar 239 to the one defined in STAMP protocol [I-D.ippm-stamp]. The IPv4 TTL 240 or IPv6 Hop Limit field of the IP header MUST be set to 255. 242 3.1.1. Delay Measurement Probe Query Message 244 The message content for Delay Measurement probe query message using 245 UDP header [RFC768] is shown in Figure 1. The DM probe query message 246 is sent with user-configured Destination UDP port number for DM. The 247 Destination UDP port cannot be used as Source port, since the message 248 does not have any indication to distinguish between query and 249 response. The DM probe query message contains the payload for delay 250 measurement defined in Section 4.1.2 of OWAMP [RFC4656]. As an 251 alternative, the DM probe query message contains the payload defined 252 in Section 4.2.1 of TWAMP [RFC5357]. 254 +---------------------------------------------------------------+ 255 | IP Header | 256 . Source IP Address = Querier IPv4 or IPv6 Address . 257 . Destination IP Address = Responder IPv4 or IPv6 Address . 258 . Protocol = UDP . 259 . Router Alert Option Not Set . 260 . . 261 +---------------------------------------------------------------+ 262 | UDP Header | 263 . Source Port = As chosen by Querier . 264 . Destination Port = User-configured Port for Delay Measurement. 265 . . 266 +---------------------------------------------------------------+ 267 | Payload = Message as specified in Section 4.2.1 of RFC 5357 | 268 | | Payload = Message as specified in Section 4.1.2 of RFC 4656 | 269 . . 270 +---------------------------------------------------------------+ 272 Figure 1: DM Probe Query Message 274 Timestamp field is eight bytes. It is recommended to use the IEEE 275 1588v2 Precision Time Protocol (PTP) truncated 64-bit timestamp 276 format [IEEE1588] using the procedure defined in [RFC8186]. 278 3.1.1.1. Delay Measurement Message Checksum Complement 280 The Checksum Complement shown in Figure 3 for OWAMP in [RFC7820] and 281 Figure 4 for TWAMP in [RFC7820] for delay measurement message format 282 follows the procedure defined in [RFC7820] and can be used optionally 283 with the procedures defined in this document. 285 3.1.1.2. Delay Measurement Authentication Mode 287 When using the authenticated mode for delay measurement, the matching 288 authentication type (e.g. HMAC-SHA-256) and key are user-configured 289 on both the querier and responder nodes. A different user-configured 290 destination UDP port is required for the delay measurement in 291 authentication mode due to the different probe message format. 293 3.1.2. Loss Measurement Probe Query Message 295 The message content for Loss Measurement probe query message using 296 UDP header [RFC768] is shown in Figure 2. The LM probe query message 297 is sent with user-configured Destination UDP port number for LM. 298 Different Destination UDP ports are used for direct-mode and 299 inferred-mode loss measurements. The Destination UDP port cannot be 300 used as Source port, since the message does not have any indication 301 to distinguish between query and response. The LM probe query 302 message contains the payload for loss measurement as defined in 303 Figure 2. An alternative, the LM probe query message contains the 304 payload defined in Figure 8. 306 Both of these LM message formats define fixed locations for the 307 counters in the payload and are easy to implement in hardware. In 308 addition, new LM messages do not require any backwards compatibility 309 or support for the existing DM message formats in [RFC5357]. 311 +---------------------------------------------------------------+ 312 | IP Header | 313 . Source IP Address = Querier IPv4 or IPv6 Address . 314 . Destination IP Address = Responder IPv4 or IPv6 Address . 315 . Protocol = UDP . 316 . Router Alert Option Not Set . 317 . . 318 +---------------------------------------------------------------+ 319 | UDP Header | 320 . Source Port = As chosen by Querier . 321 . Destination Port = User-configured Port for Loss Measurement . 322 . . 323 +---------------------------------------------------------------+ 324 | Sequence Number | 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 | Transmit Counter | 327 | | 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 | Sender TTL |X|B|0|0|0|0|0|0| Block Number | 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 | | 332 . Packet Padding . 333 . . 334 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 | | Checksum Complement | 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 Figure 2A: LM Probe Query Message for OWAMP 340 +---------------------------------------------------------------+ 341 | IP Header | 342 . Source IP Address = Querier IPv4 or IPv6 Address . 343 . Destination IP Address = Responder IPv4 or IPv6 Address . 344 . Protocol = UDP . 345 . Router Alert Option Not Set . 346 . . 347 +---------------------------------------------------------------+ 348 | UDP Header | 349 . Source Port = As chosen by Querier . 350 . Destination Port = User-configured Port for Loss Measurement . 351 . . 352 +---------------------------------------------------------------+ 353 | Sequence Number | 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 | MBZ (12 octets) | 356 | | 357 | | 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 | Transmit Counter | 360 | | 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 | MBZ (8 octets) | 363 | | 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 365 | Sender TTL |X|B|0|0|0|0|0|0| Block Number | 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 | MBZ (12 octets) | 368 | | 369 | | 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 | HMAC (16 octets) | 372 | | 373 | | 374 | | 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 | | 377 . Packet Padding . 378 . . 379 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 | | Checksum Complement | 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 Figure 2B: LM Probe Query Message for OWAMP - Authenticated Mode 385 Sequence Number (32-bit): As defined in [RFC5357]. 387 Transmit Counter (64-bit): The number of packets sent by the querier 388 node in the query message and by the responder node in the response 389 message. The counter is always written at the fixed location in the 390 probe query and response messages. 392 Receive Counter (64-bit): The number of packets received at the 393 responder node. It is written by the responder node in the probe 394 response message. 396 Sender Counter (64-bit): This is the exact copy of the transmit 397 counter from the received query message. It is written by the 398 responder node in the probe response message. 400 Sender Sequence Number (32-bit): As defined in [RFC5357]. 402 Sender TTL: As defined in [RFC5357]. 404 Flag: The meanings of the Flag bits are: 406 X: Extended counter format indicator. Indicates the use of 407 extended (64-bit) counter values. Initialized to 1 upon creation 408 (and prior to transmission) of an LM Query and copied from an LM 409 Query to an LM response. Set to 0 when the LM message is 410 transmitted or received over an interface that writes 32-bit 411 counter values. 413 B: Octet (byte) count. When set to 1, indicates that the Counter 414 1-4 fields represent octet counts. The octet count applies to all 415 packets within the LM scope, and the octet count of a packet sent 416 or received over a channel includes the total length of that 417 packet (but excludes headers, labels, or framing of the channel 418 itself). When set to 0, indicates that the Counter fields 419 represent packet counts. 421 0: Set to 0. 423 Block Number (16-bit): The Loss Measurement using Alternate-Marking 424 method defined in [RFC8321] requires to identify the Block Number (or 425 color) of the traffic counters. The probe query and response 426 messages carry Block Number for the traffic counters for loss 427 measurement. In both probe query and response messages, the counters 428 MUST belong to the same Block Number. 430 HMAC: The PM probe packet in authenticated mode includes a key Hashed 431 Message Authentication Code (HMAC) ([RFC2104]) hash. Each probe 432 query and response messages are authenticated by adding Sequence 433 Number with Hashed Message Authentication Code (HMAC) TLV. It can 434 use HMAC-SHA-256 truncated to 128 bits (similarly to the use of it in 435 IPSec defined in [RFC4868]); hence the length of the HMAC field is 16 436 octets. 438 HMAC uses own key and the definition of the mechanism to distribute 439 the HMAC key is outside the scope of this document. 441 In authenticated mode, only the sequence number is encrypted, and the 442 other payload fields are sent in clear text. The probe packet MAY 443 include Comp.MBZ (Must Be Zero) variable length field to align the 444 packet on 16 octets boundary. 446 3.1.2.1. Loss Measurement Message Checksum Complement 448 The Checksum Complement shown in Figure 2 for loss measurement 449 message format follows the procedure defined in [RFC7820] and can be 450 used optionally with the procedures defined in this document. 452 3.1.2.2. Loss Measurement Authentication Mode 454 When using the authenticated mode for loss measurement, the matching 455 authentication type (e.g. HMAC-SHA-256) and key are user-configured 456 on both the querier and responder nodes. A different user-configured 457 destination UDP port is required for the loss measurement in 458 authentication mode due to the different message format. 460 3.1.3. Probe Query for SR Links 462 The probe query message as defined in Figure 1 is sent on the 463 congruent path of the data traffic for Delay measurement. The probe 464 query message as defined in Figure 2 is sent on the congruent path of 465 the data traffic for Loss measurement. 467 3.1.4. Probe Query for End-to-end Measurement for SR Policy 469 3.1.4.1. Probe Query Message for SR-MPLS Policy 471 The message content for the probe query message using UDP header for 472 end-to-end performance measurement of SR-MPLS Policy is shown in 473 Figure 3. 475 0 1 2 3 476 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 477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 478 | Segment List(1) | TC |S| TTL | 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 . . 481 . . 482 . . 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 | Segment List(n) | TC |S| TTL | 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 | PSID | TC |S| TTL | 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 | Message as shown in Figure 1 for DM or Figure 2 for LM | 489 . . 490 +---------------------------------------------------------------+ 492 Figure 3: Probe Query Message for SR-MPLS Policy 494 The Segment List (SL) can be empty to indicate Implicit NULL label 495 case. 497 The Path Segment Identifier (PSID) [I-D.spring-mpls-path-segment] of 498 the SR-MPLS Policy is used for accounting received traffic on the 499 egress node for loss measurement. The PSID is not required for 500 end-to-end SR Policy delay measurement. 502 3.1.4.2. Probe Query Message for SRv6 Policy 504 An SRv6 Policy setup using the SRv6 Segment Routing Header (SRH) and 505 a Segment List as defined in [I-D.6man-segment-routing-header]. The 506 probe query messages using UDP header for end-to-end performance 507 measurement of an SRv6 Policy is sent using its SRv6 Segment Routing 508 Header (SRH) and Segment List as shown in Figure 4. 510 0 1 2 3 511 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 512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 513 | SRH | 514 . END.OTP (DM) or END.OP (LM) with Target SRv6 SID . 515 . . 516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 517 | Message as shown in Figure 1 for DM or Figure 2 for LM | 518 . (Using IPv6 Addresses) . 519 . . 521 +---------------------------------------------------------------+ 523 Figure 4: Probe Query Message for SRv6 Policy 525 For delay measurement of SRv6 Policy using SRH, END function END.OTP 526 [I-D.spring-srv6-oam] is used with the target SRv6 SID to punt probe 527 messages on the target node, as shown in Figure 4. Similarly, for 528 loss measurement of SRv6 Policy, END function END.OP 529 [I-D.spring-srv6-oam] is used with target SRv6 SID to punt probe 530 messages on the target node. 532 3.2. Probe Response Message 534 The probe response message is sent using the IP/UDP information from 535 the probe query message. The content of the probe response message 536 is shown in Figure 5. 538 +---------------------------------------------------------------+ 539 | IP Header | 540 . Source IP Address = Responder IPv4 or IPv6 Address . 541 . Destination IP Address = Source IP Address from Query . 542 . Protocol = UDP . 543 . Router Alert Option Not Set . 544 . . 545 +---------------------------------------------------------------+ 546 | UDP Header | 547 . Source Port = As chosen by Responder . 548 . Destination Port = Source Port from Query . 549 . . 550 +---------------------------------------------------------------+ 551 | DM Payload as specified in Section 4.2.1 of RFC 5357, or | 552 . LM Payload as specified in Figure 8 in this document . 553 . . 554 +---------------------------------------------------------------+ 556 Figure 5: Probe Response Message 558 +---------------------------------------------------------------+ 559 | IP Header | 560 . Source IP Address = Querier IPv4 or IPv6 Address . 561 . Destination IP Address = Responder IPv4 or IPv6 Address . 562 . Protocol = UDP . 563 . Router Alert Option Not Set . 564 . . 565 +---------------------------------------------------------------+ 566 | UDP Header | 567 . Source Port = As chosen by Querier . 569 . Destination Port = User-configured Port for Loss Measurement . 570 . . 571 +---------------------------------------------------------------+ 572 | Sequence Number | 573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 574 | Transmit Counter | 575 | | 576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 577 | Receive Counter | 578 | | 579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 580 | Sender Sequence Number | 581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 582 | Sender Counter | 583 | | 584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 585 | Sender TTL |X|B|0|0|0|0|0|0| Block Number | 586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 587 | | 588 . . 589 . Packet Padding . 590 . . 591 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 592 | | Checksum Complement | 593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 595 Figure 8A: LM Probe Response Message for TWAMP 597 +---------------------------------------------------------------+ 598 | IP Header | 599 . Source IP Address = Querier IPv4 or IPv6 Address . 600 . Destination IP Address = Responder IPv4 or IPv6 Address . 601 . Protocol = UDP . 602 . Router Alert Option Not Set . 603 . . 604 +---------------------------------------------------------------+ 605 | UDP Header | 606 . Source Port = As chosen by Querier . 607 . Destination Port = User-configured Port for Loss Measurement . 608 . . 609 +---------------------------------------------------------------+ 610 | Sequence Number | 611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 612 | MBZ (12 octets) | 613 | | 614 | | 615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 616 | Transmit Counter | 617 | | 618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 619 | MBZ (8 octets) | 620 | | 621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 622 | Receive Counter | 623 | | 624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 625 | MBZ (8 octets) | 626 | | 627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 628 | Sender Sequence Number | 629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 630 | MBZ (12 octets) | 631 | | 632 | | 633 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 634 | Sender Counter | 635 | | 636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 637 | MBZ (8 octets) | 638 | | 639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 640 | Sender TTL |X|B|0|0|0|0|0|0| Block Number | 641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 642 | MBZ (12 octets) | 643 | | 644 | | 645 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 646 | HMAC (16 octets) | 647 | | 648 | | 649 | | 650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 651 | | 652 . . 653 . Packet Padding . 654 . . 655 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 656 | | Checksum Complement | 657 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 659 Figure 8B: LM Probe Response Message for TWAMP - Authenticated Mode 661 3.2.1. One-way Measurement Mode 662 In one-way performance measurement mode, the probe response message 663 as defined in Figure 5 is sent for both SR links and SR Policies. 665 3.2.2. Two-way Measurement Mode 667 In two-way performance measurement mode, when using a bidirectional 668 path, the probe response message as defined in Figure 5 is sent back 669 on the congruent path of the data traffic to the querier node. 671 3.2.2.1. Return Path TLV 673 For two-way performance measurement, the responder node needs to send 674 the probe response message on a specific reverse SR path. This way 675 the destination node does not require any additional SR Policy state. 676 The querier node can request in the probe query message to the 677 responder node to send a response back on a given reverse path 678 (typically co-routed path for two-way measurement). 680 [I-D.ippm-stamp-option-tlv] defines STAMP probe query messages that 681 can include one or more optional TLVs. New TLV Type (TBA1) is 682 defined in this document for Return Path to carry reverse SR path for 683 probe response messages (in the payload of the message). The format 684 of the Return Path TLV is shown in Figure 8A and 8B: 686 0 1 2 3 687 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 688 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 689 | Type = TBA1 | Length | Reserved | 690 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 691 | Return Path Sub-TLVs | 692 . . 693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 695 Figure 8A: Return Path TLV 697 0 1 2 3 698 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 699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 700 | Type | Length | Reserved | 701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 702 | Segment List(1) | 703 . . 704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 705 . . 706 . . 707 . . 708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 709 | Segment List(n) | 710 . . 711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 713 Figure 8B: Segment List Sub-TLV in Return Path TLV 715 The Sub-TLV in the Return Path TLV can be one of the following Types: 717 o Type (value 1): SR-MPLS Label Stack of the Reverse SR Policy 719 o Type (value 2): SR-MPLS Binding SID [I-D.pce-binding-label-sid] of 720 the Reverse SR Policy 722 o Type (value 3): SRv6 Segment List of the Reverse SR Policy 724 o Type (value 4): SRv6 Binding SID [I-D.pce-binding-label-sid] of 725 the Reverse SR Policy 727 With sub-TLV Type 1, the Segment List(1) can be used by the responder 728 node to compute the next-hop IP address and outgoing interface to 729 send the probe response messages. 731 The Return Path TLV is optional. The PM querier node MUST only 732 insert one Return Path TLV in the probe query message and the 733 responder node MUST only process the first Return Path TLV in the 734 probe query message and ignore other Return Path TLVs if present. 735 The responder node MUST send probe response message back on the 736 reverse path specified in the Return Path TLV and MUST NOT add Return 737 Path TLV in the probe response message. 739 3.2.2.2. Probe Response Message for SR-MPLS Policy 741 The message content for sending probe response message using the UDP 742 header for two-way end-to-end performance measurement of an SR-MPLS 743 Policy is shown in Figure 6. 745 0 1 2 3 746 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 747 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 748 | Segment List(1) | TC |S| TTL | 749 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 750 . . 751 . . 752 . . 753 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 754 | Segment List(n) | TC |S| TTL | 755 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 756 | Message as shown in Figure 5 | 757 . . 758 +---------------------------------------------------------------+ 760 Figure 6: Probe Response Message for SR-MPLS Policy 762 The Path Segment Identifier (PSID) [I-D.spring-mpls-path-segment] of 763 the forward SR Policy can be used to find the reverse SR Policy to 764 send the probe response message for two-way measurement of SR Policy. 766 3.2.2.3. Probe Response Message for SRv6 Policy 768 The message content for sending probe response message on the 769 congruent path of the data traffic using UDP header for two-way 770 end-to-end performance measurement of an SRv6 Policy with SRH is 771 shown in Figure 7. 773 0 1 2 3 774 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 775 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 776 | SRH | 777 . END.OTP (DM) or END.OP (LM) with Target SRv6 SID . 778 . . 779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 780 | Message as shown in Figure 5 (with IPv6 Addresses) | 781 . . 782 +---------------------------------------------------------------+ 784 Figure 7: Probe Response Message for SRv6 Policy 786 3.2.3. Loopback Measurement Mode 788 The Loopback measurement mode can be used to measure round-trip delay 789 for a bidirectional Path. The probe query messages in this case 790 either carry the reverse Path information as part of the SR header or 791 set the querier address as the destination address in the IP header. 792 The responder node does not process the PM probe messages and 793 generate response messages. 795 4. Packet Loss Calculation 797 The formula for calculating the one-way packet loss using packet 798 counters for a given block number is as following: 800 One-way Packet_Loss[n-1, n] 801 = (Sender_Counter[n] - Sender_Counter[n-1]) 802 - (Receive_Counter[n] - Receive_Counter[n-1]) 804 5. Performance Measurement for P2MP SR Policies 806 The procedures for delay and loss measurement described in this 807 document for Point-to-Point (P2P) SR Policies 808 [I-D.spring-segment-routing-policy] are also equally applicable to 809 the Point-to-Multipoint (P2MP) SR Policies 810 [I-D.spring-sr-p2mp-policy] as following: 812 o The querier root node sends probe query messages using the either 813 Spray P2MP segment or TreeSID P2MP segment defined in 814 [I-D.spring-sr-p2mp-policy] over the P2MP SR Policy. 816 o Each responder leaf node sends its IP address in the Source 817 Address of the probe response messages. This allows the querier 818 root node to identify the responder leaf nodes of the P2MP SR 819 Policy. 821 o The P2MP root node measures the end-to-end delay and loss 822 performance for each P2MP leaf node. 824 6. ECMP Support for SR Policies 826 An SR Policy can have ECMPs between the source and transit nodes, 827 between transit nodes and between transit and destination nodes. 828 Usage of Anycast SID [RFC8402] by an SR Policy can result in ECMP 829 paths via transit nodes part of that Anycast group. The PM probe 830 messages need to be sent to traverse different ECMP paths to measure 831 performance delay of an SR Policy. 833 Forwarding plane has various hashing functions available to forward 834 packets on specific ECMP paths. Following mechanisms can be used in 835 PM probe messages to take advantage of the hashing function in 836 forwarding plane to influence the path taken by them. 838 o The mechanisms described in [RFC8029] and [RFC5884] for handling 839 ECMPs are also applicable to the performance measurement. In the 840 IP/UDP header of the PM probe messages, Destination Addresses in 841 127/8 range for IPv4 or 0:0:0:0:0:FFFF:7F00/104 range for IPv6 can 842 be used to exercise a particular ECMP path. As specified in 843 [RFC6437], 3-tuple of Flow Label, Source Address and Destination 844 Address fields in the IPv6 header can also be used. 846 o For SR-MPLS Policy, entropy label [RFC6790] can be used in the PM 847 probe messages. 849 o For SRv6 Policy using SRH, Flow Label in the SRH 850 [I-D.6man-segment-routing-header] of the PM probe messages can be 851 used. 853 7. Security Considerations 855 The performance measurement is intended for deployment in 856 well-managed private and service provider networks. As such, it 857 assumes that a node involved in a measurement operation has 858 previously verified the integrity of the path and the identity of the 859 far end responder node. 861 If desired, attacks can be mitigated by performing basic validation 862 and sanity checks, at the querier, of the counter or timestamp fields 863 in received measurement response messages. The minimal state 864 associated with these protocols also limits the extent of measurement 865 disruption that can be caused by a corrupt or invalid message to a 866 single query/response cycle. 868 Use of HMAC-SHA-256 in the authenticated mode protects the data 869 integrity of the probe messages. SRv6 has HMAC protection 870 authentication defined for SRH [I-D.6man-segment-routing-header]. 871 Hence, PM probe messages for SRv6 may not need authentication mode. 872 Cryptographic measures may be enhanced by the correct configuration 873 of access-control lists and firewalls. 875 8. IANA Considerations 877 IANA is requested to allocate values for the following Return Path 878 TLV Type for [I-D.ippm-stamp-option-tlv] to be carried in PM probe 879 query messages: 881 o Type TBA1: Return Path TLV 883 9. References 885 9.1. Normative References 887 [RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 888 August 1980. 890 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 891 Requirement Levels", RFC 2119, March 1997. 893 [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. 894 Zekauskas, "A One-way Active Measurement Protocol 895 (OWAMP)", RFC 4656, September 2006. 897 [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. 898 Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", 899 RFC 5357, October 2008. 901 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 902 2119 Key Words", RFC 8174, May 2017. 904 [I-D.spring-srv6-oam] Ali, Z., et al., "Operations, Administration, 905 and Maintenance (OAM) in Segment Routing Networks with 906 IPv6 Data plane (SRv6)", draft-ali-spring-srv6-oam, work 907 in progress. 909 [I-D.ippm-stamp-option-tlv] Mirsky, G., et al., "Simple Two-way 910 Active Measurement Protocol Optional Extensions", 911 draft-mirsky-ippm-stamp-option-tlv, work in progress. 913 9.2. Informative References 915 [IEEE1588] IEEE, "1588-2008 IEEE Standard for a Precision Clock 916 Synchronization Protocol for Networked Measurement and 917 Control Systems", March 2008. 919 [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, 920 "Bidirectional Forwarding Detection (BFD) for MPLS Label 921 Switched Paths (LSPs)", RFC 5884, DOI 10.17487/RFC5884, 922 June 2010. 924 [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, 925 "IPv6 Flow Label Specification", RFC 6437, November 2011. 927 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 928 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 929 RFC 6790, November 2012. 931 [RFC7820] Mizrahi, T., "UDP Checksum Complement in the One-Way 932 Active Measurement Protocol (OWAMP) and Two-Way Active 933 Measurement Protocol (TWAMP)", RFC 7820, March 2016. 935 [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Kumar, N., 936 Aldrin, S. and M. Chen, "Detecting Multiprotocol Label 937 Switched (MPLS) Data-Plane Failures", RFC 8029, March 938 2017. 940 [RFC8186] Mirsky, G., and I. Meilik, "Support of the IEEE 1588 941 Timestamp Format in a Two-Way Active Measurement Protocol 942 (TWAMP)", RFC 8186, June 2017. 944 [RFC8321] Fioccola, G. Ed., "Alternate-Marking Method for Passive 945 and Hybrid Performance Monitoring", RFC 8321, January 946 2018. 948 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 949 Decraene, B., Litkowski, S., and R. Shakir, "Segment 950 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 951 July 2018, . 953 [I-D.spring-segment-routing-policy] Filsfils, C., et al., "Segment 954 Routing Policy Architecture", 955 draft-ietf-spring-segment-routing-policy, work in 956 progress. 958 [I-D.spring-sr-p2mp-policy] Voyer, D. Ed., et al., "SR Replication 959 Policy for P2MP Service Delivery", 960 draft-voyer-spring-sr-p2mp-policy, work in progress. 962 [I-D.spring-mpls-path-segment] Cheng, W., et al., "Path Segment in 963 MPLS Based Segment Routing Network", 964 draft-ietf-spring-mpls-path-segment, work in progress. 966 [I-D.6man-segment-routing-header] Filsfils, C., et al., "IPv6 967 Segment Routing Header (SRH)", 968 draft-ietf-6man-segment-routing-header, work in progress. 970 [I-D.ippm-stamp] Mirsky, G. et al. "Simple Two-way Active 971 Measurement Protocol", draft-ietf-ippm-stamp, work in 972 progress. 974 [I-D.pce-binding-label-sid] Filsfils, C., et al., "Carrying Binding 975 Label Segment-ID in PCE-based Networks", 976 draft-sivabalan-pce-binding-label-sid, work in progress. 978 [BBF.TR-390] "Performance Measurement from IP Edge to Customer 979 Equipment using TWAMP Light", BBF TR-390, May 2017. 981 [I-D.spring-ioam-sr-mpls] Gandhi, R. Ed., et al., "Segment Routing 982 with MPLS Data Plane Encapsulation for In-situ OAM Data", 983 draft-gandhi-spring-ioam-sr-mpls, work in progress. 985 [RFC2104] Krawczyk, H., Bell-are, M., and R. Canetti, "HMAC: Keyed- 986 Hashing for Message Authentication", RFC 2104, February 987 1997. 989 [RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA- 990 384, and HMAC-SHA-512 with IPsec", RFC 4868, May 2007. 992 Acknowledgments 994 The authors would like to thank Thierry Couture for various 995 discussions on the use-cases for TWAMP in segment routing. The 996 authors would also like to thank Greg Mirsky for reviewing this 997 document and providing useful comments and suggestions. 999 Authors' Addresses 1001 Rakesh Gandhi (editor) 1002 Cisco Systems, Inc. 1003 Canada 1004 Email: rgandhi@cisco.com 1006 Clarence Filsfils 1007 Cisco Systems, Inc. 1008 Email: cfilsfil@cisco.com 1010 Daniel Voyer 1011 Bell Canada 1012 Email: daniel.voyer@bell.ca 1014 Mach(Guoyi) Chen 1015 Huawei 1016 Email: mach.chen@huawei.com