idnits 2.17.1 draft-gandhi-spring-twamp-srpm-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 30, 2019) is 1695 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: March 2, 2020 D. Voyer 6 Bell Canada 7 M. Chen 8 Huawei 9 B. Janssens 10 Colt 11 August 30, 2019 13 Performance Measurement Using TWAMP Light 14 for Segment Routing Networks 15 draft-gandhi-spring-twamp-srpm-02 17 Abstract 19 Segment Routing (SR) leverages the source routing paradigm. SR is 20 applicable to both Multiprotocol Label Switching (SR-MPLS) and IPv6 21 (SRv6) data planes. This document specifies procedure for sending 22 and processing synthetic probe query and response messages for 23 Performance Measurement (PM) in Segment Routing networks. The 24 procedure uses the mechanisms defined in RFC 5357 (Two-Way Active 25 Measurement Protocol (TWAMP) Light) for Delay Measurement, and also 26 uses the mechanisms defined in this document for Loss Measurement. 27 The procedure specified is applicable to SR-MPLS and SRv6 data planes 28 and are used for both links and end-to-end SR Policies. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 Copyright Notice 47 Copyright (c) 2019 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Conventions Used in This Document . . . . . . . . . . . . . . 4 64 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 65 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4 66 2.3. Reference Topology . . . . . . . . . . . . . . . . . . . . 5 67 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 3.1. Example Provisioning Model for TWAMP Light . . . . . . . . 6 69 3.2. STAMP Applicability . . . . . . . . . . . . . . . . . . . 6 70 4. Probe Messages . . . . . . . . . . . . . . . . . . . . . . . . 7 71 4.1. Probe Query Message . . . . . . . . . . . . . . . . . . . 7 72 4.1.1. Delay Measurement Probe Query Message . . . . . . . . 7 73 4.1.1.1. Delay Measurement Authentication Mode . . . . . . 8 74 4.1.2. Loss Measurement Probe Query Message . . . . . . . . . 8 75 4.1.2.1. Loss Measurement Authentication Mode . . . . . . . 11 76 4.1.3. Probe Query for SR Links . . . . . . . . . . . . . . . 11 77 4.1.4. Probe Query for End-to-end Measurement for SR Policy . 12 78 4.1.4.1. Probe Query Message for SR-MPLS Policy . . . . . . 12 79 4.1.4.2. Probe Query Message for SRv6 Policy . . . . . . . 12 80 4.2. Probe Response Message . . . . . . . . . . . . . . . . . . 13 81 4.2.1. One-way Measurement Mode . . . . . . . . . . . . . . . 15 82 4.2.2. Two-way Measurement Mode . . . . . . . . . . . . . . . 16 83 4.2.2.1. Return Path TLV . . . . . . . . . . . . . . . . . 16 84 4.2.2.2. Probe Response Message for SR-MPLS Policy . . . . 17 85 4.2.2.3. Probe Response Message for SRv6 Policy . . . . . . 18 86 4.2.3. Loopback Measurement Mode . . . . . . . . . . . . . . 18 87 5. Performance Measurement for P2MP SR Policies . . . . . . . . . 18 88 6. ECMP Support for SR Policies . . . . . . . . . . . . . . . . . 19 89 7. Additional Message Processing Rules . . . . . . . . . . . . . 20 90 7.1. TTL Value . . . . . . . . . . . . . . . . . . . . . . . . 20 91 7.2. Router Alert Option . . . . . . . . . . . . . . . . . . . 20 92 7.3. UDP Checksum . . . . . . . . . . . . . . . . . . . . . . . 20 93 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 94 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 95 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 96 10.1. Normative References . . . . . . . . . . . . . . . . . . 21 97 10.2. Informative References . . . . . . . . . . . . . . . . . 22 98 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 24 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 101 1. Introduction 103 Segment Routing (SR) leverages the source routing paradigm and 104 greatly simplifies network operations for Software Defined Networks 105 (SDNs). SR is applicable to both Multiprotocol Label Switching 106 (SR-MPLS) and IPv6 (SRv6) data planes. SR takes advantage of the 107 Equal-Cost Multipaths (ECMPs) between source and transit nodes, 108 between transit nodes and between transit and destination nodes. SR 109 Policies as defined in [I-D.spring-segment-routing-policy] are used 110 to steer traffic through a specific, user-defined paths using a stack 111 of Segments. Built-in SR Performance Measurement (PM) is one of the 112 essential requirements to provide Service Level Agreements (SLAs). 114 The One-Way Active Measurement Protocol (OWAMP) defined in [RFC4656] 115 and Two-Way Active Measurement Protocol (TWAMP) defined in [RFC5357] 116 provide capabilities for the measurement of various performance 117 metrics in IP networks using synthetic probe messages. These 118 protocols rely on control-channel signaling to establish a 119 test-channel over an UDP path. These protocols lack support for 120 direct-mode Loss Measurement (LM) to detect actual data traffic loss 121 which is required in SR networks. The Simple Two-way Active 122 Measurement Protocol (STAMP) [I-D.ippm-stamp] alleviates the 123 control-channel signaling by using configuration data model to 124 provision a test-channel. The TWAMP Light [Appendix I in RFC5357] 125 [BBF.TR-390] provides simplified mechanisms for active performance 126 measurement in Customer IP networks by provisioning UDP paths and 127 eliminates the control-channel signaling. 129 This document specifies procedures for sending and processing 130 synthetic probe query and response messages for Performance 131 Measurement in SR networks. The procedure uses the mechanisms 132 defined in [RFC5357] (TWAMP Light) for Delay Measurement (DM), and 133 also uses the mechanisms defined in this document for Loss 134 Measurement. The procedure specified is applicable to SR-MPLS and 135 SRv6 data planes and are used for both links and end-to-end SR 136 Policies. This document also defines mechanisms for handling ECMPs 137 of SR Policies for performance delay measurements. 139 2. Conventions Used in This Document 141 2.1. Requirements Language 143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 145 document are to be interpreted as described in [RFC2119] [RFC8174] 146 when, and only when, they appear in all capitals, as shown here. 148 2.2. Abbreviations 150 BSID: Binding Segment ID. 152 DM: Delay Measurement. 154 ECMP: Equal Cost Multi-Path. 156 LM: Loss Measurement. 158 MPLS: Multiprotocol Label Switching. 160 NTP: Network Time Protocol. 162 OWAMP: One-Way Active Measurement Protocol. 164 PM: Performance Measurement. 166 PSID: Path Segment Identifier. 168 PTP: Precision Time Protocol. 170 SID: Segment ID. 172 SL: Segment List. 174 SR: Segment Routing. 176 SR-MPLS: Segment Routing with MPLS data plane. 178 SRv6: Segment Routing with IPv6 data plane. 180 STAMP: Simple Two-way Active Measurement Protocol. 182 TC: Traffic Class. 184 TWAMP: Two-Way Active Measurement Protocol. 186 2.3. Reference Topology 188 In the reference topology shown below, the sender node R1 initiates a 189 probe query for performance measurement and the responder node R5 190 sends a probe response for the query message received. The probe 191 response is sent to the sender node R1. The nodes R1 and R5 may be 192 directly connected via a link enabled with Segment Routing or there 193 exists a Point-to-Point (P2P) SR Policy 194 [I-D.spring-segment-routing-policy] on node R1 with destination to 195 node R5. In case of Point-to-Multipoint (P2MP), SR Policy 196 originating from source node R1 may terminate on multiple destination 197 leaf nodes [I-D.spring-sr-p2mp-policy]. 199 +-------+ Query +-------+ 200 | | - - - - - - - - - ->| | 201 | R1 |---------------------| R5 | 202 | |<- - - - - - - - - - | | 203 +-------+ Response +-------+ 204 Sender Responder 206 Reference Topology 208 3. Overview 210 For one-way, two-way and round-trip delay measurements in Segment 211 Routing networks, the TWAMP Light procedures defined in Appendix I of 212 [RFC5357] are used. For one-way and two-way direct-mode and 213 inferred-mode loss measurements in Segment Routing networks, the 214 procedures defined in this document are used. One-way loss 215 measurement provides receive packet loss whereas two-way loss 216 measurement provides both transmit and receive packet loss. Separate 217 UDP destination port numbers are user-configured for delay and loss 218 measurements from the range specified in [I-D.ippm-stamp]. For both 219 links and end-to-end SR Policies, no PM session for delay or loss 220 measurement is created on the responder node R5 [RFC5357]. 222 For Performance Measurement, synthetic probe query and response 223 messages are sent as following: 225 o For Delay Measurement, the probe messages are sent on the 226 congruent path of the data traffic by the sender node, and are 227 used to measure the delay experienced by the actual data traffic 228 flowing on the links and SR Policies. 230 o For Loss Measurement, the probe messages are sent on the congruent 231 path of the data traffic by the sender node, and are used to 232 collect the receive traffic counters for the incoming link or 233 incoming SID where the probe query messages are received at the 234 responder node (incoming link or incoming SID needed since the 235 responder node does not have PM session state present). 237 The In-Situ Operations, Administration, and Maintenance (IOAM) 238 mechanisms for SR-MPLS defined in [I-D.spring-ioam-sr-mpls] and for 239 SRv6 defined in [I-D.spring-srv6-oam] are used to carry PM 240 information such as timestamp in-band as part of the data packets, 241 and are outside the scope of this document. 243 3.1. Example Provisioning Model for TWAMP Light 245 An example of a provisioning model and typical measurement parameters 246 for performance delay and loss measurements using TWAMP Light is 247 shown in the following Figure: 249 +------------+ 250 | Controller | 251 +------------+ 252 Measurement Protocol / \ Measurement Protocol 253 Destination UDP Port / \ Destination UDP port 254 Measurement Type / \ Measurement Type 255 Delay/Loss / \ Delay/Loss 256 Authentication Mode & Key / \ Authentication Mode & Key 257 Timestamp Format / \ 258 Measurement Mode / \ 259 Padding/MBZ Bytes / \ 260 Loss Measurement Mode / \ 261 v v 262 +-------+ +-------+ 263 | | | | 264 | R1 |------------| R5 | 265 | | | | 266 +-------+ +-------+ 267 Sender Responder 269 Provisioning Model 271 The mechanisms used to provision the sender and responder nodes are 272 outside the scope of this document. 274 3.2. STAMP Applicability 276 The Simple Two-way Active Measurement Protocol (STAMP) 277 [I-D.ippm-stamp] and the STAMP TLVs [I-D.ippm-stamp-option-tlv] are 278 both equally applicable to the procedures specified in this document. 280 This is because the delay measurement message formats defined for 281 STAMP and STAMP TLVs are backwards compatible with the delay 282 measurement message formats defined in [RFC5357]. Hence, the same 283 user-configured destination UDP port for delay measurement can be 284 used for STAMP and TWAMP Light messages. The STAMP with a TLV for 285 "direct measurement" can be used for combined delay + loss 286 measurement using a separate user-configured UDP destination port. 288 The loss measurement probe and query messages defined in this 289 document are also equally applicable to STAMP and STAMP TLVs, by 290 using the packet padding size of 30 octets. 292 4. Probe Messages 294 4.1. Probe Query Message 296 In this document, the probe messages defined in [RFC5357] are used 297 for Delay and Loss measurements for SR links and end-to-end SR 298 Policies. The user-configured destination UDP ports (separate UDP 299 ports for delay and loss message formats) are used for identifying 300 the PM probe packets as described in Appendix I of [RFC5357]. The 301 sender uses the UDP port number following the guidelines specified in 302 Section 6 in [RFC6335]. 304 4.1.1. Delay Measurement Probe Query Message 306 The message content for Delay Measurement probe query message using 307 UDP header [RFC768] is shown in Figure 1. The DM probe query message 308 is sent with user-configured Destination UDP port number for DM. The 309 Destination UDP port cannot be used as Source port, since the message 310 does not have any indication to distinguish between query and 311 response. The DM probe query message contains the payload for delay 312 measurement defined in Section 4.1.2 of [RFC5357]. For symmetrical 313 size query and response messages [RFC6038], the DM probe query 314 message contains the payload format defined in Section 4.2.1 of 315 [RFC5357]. 317 +---------------------------------------------------------------+ 318 | IP Header | 319 . Source IP Address = Sender IPv4 or IPv6 Address . 320 . Destination IP Address = Responder IPv4 or IPv6 Address . 321 . Protocol = UDP . 322 . . 323 +---------------------------------------------------------------+ 324 | UDP Header | 325 . Source Port = As chosen by Sender . 326 . Destination Port = User-configured Port for Delay Measurement. 328 . . 329 +---------------------------------------------------------------+ 330 | Payload = Message as specified in Section 4.2.1 of RFC 5357 | | 331 | Payload = Message as specified in Section 4.1.2 of RFC 5357 | 332 . . 333 +---------------------------------------------------------------+ 335 Figure 1: DM Probe Query Message 337 Timestamp field is eight bytes. It is recommended to use the IEEE 338 1588v2 Precision Time Protocol (PTP) truncated 64-bit timestamp 339 format [IEEE1588] as specified in [RFC8186]. 341 4.1.1.1. Delay Measurement Authentication Mode 343 When using the authenticated mode for delay measurement, the matching 344 authentication type (e.g. HMAC-SHA-256) and key are user-configured 345 on both the sender and responder nodes. A separate user-configured 346 destination UDP port is used for the delay measurement in 347 authentication mode due to the different probe message format. 349 4.1.2. Loss Measurement Probe Query Message 351 In this document, new probe query message formats are defined for 352 loss measurement as shown in Figure 3A and Figure 3B. The message 353 formats are hardware efficient due to the small size payload and 354 well-known locations of counters. They are similar to the delay 355 measurement message formats and do not require any backwards 356 compatibility and support for the existing DM message formats from 357 [RFC5357]. 359 The message content for Loss Measurement probe query message using 360 UDP header [RFC768] is shown in Figure 2. The LM probe query message 361 is sent with user-configured Destination UDP port number for LM. 362 Separate Destination UDP ports are used for direct-mode and 363 inferred-mode loss measurements. The Destination UDP port cannot be 364 used as Source port, since the message does not have any indication 365 to distinguish between query and response. The LM probe query 366 message contains the payload for loss measurement as defined in 367 Figure 3A and Figure 3B. For symmetrical size query and response 368 messages [RFC6038], the LM probe query message contains the payload 369 format defined in Figure 7A and Figure 7B for loss measurement. 371 +---------------------------------------------------------------+ 372 | IP Header | 373 . Source IP Address = Sender IPv4 or IPv6 Address . 374 . Destination IP Address = Responder IPv4 or IPv6 Address . 376 . Protocol = UDP . 377 . . 378 +---------------------------------------------------------------+ 379 | UDP Header | 380 . Source Port = As chosen by Sender . 381 . Destination Port = User-configured Port for Loss Measurement . 382 . . 383 +---------------------------------------------------------------+ 384 | Payload = Message as specified in Figure 3A or 3B | | 385 | Payload = Message as specified in Figure 7A or 7B | 386 . . 387 +---------------------------------------------------------------+ 389 Figure 2: DM Probe Query Message 391 0 1 2 3 392 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 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 | Sequence Number | 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 | Transmit Counter | 397 | | 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 |X|B| Reserved | Block Number | 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 | | 402 . Packet Padding . 403 . . 404 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 | | Checksum Complement | 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 Figure 3A: LM Probe Query Message 410 0 1 2 3 411 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 | Sequence Number | 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 | MBZ (12 octets) | 416 | | 417 | | 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 | Transmit Counter | 420 | | 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 |X|B|I| Reserved | Block Number | 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 | MBZ (6 octets) | 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 | HMAC (16 octets) | 427 | | 428 | | 429 | | 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 | | 432 . Packet Padding . 433 . . 434 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 | | Checksum Complement | 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 Figure 3B: LM Probe Query Message - Authenticated Mode 440 Sequence Number (32-bit): As defined in [RFC5357]. 442 Transmit Counter (64-bit): The number of packets sent by the sender 443 node in the query message and by the responder node in the response 444 message. The counter is always written at the fixed location in the 445 probe query and response messages. 447 Receive Counter (64-bit): The number of packets received at the 448 responder node. It is written by the responder node in the probe 449 response message. 451 Sender Counter (64-bit): This is the exact copy of the transmit 452 counter from the received query message. It is written by the 453 responder node in the probe response message. 455 Sender Sequence Number (32-bit): As defined in [RFC5357]. 457 Sender TTL: As defined in [RFC5357]. 459 Flag: The meanings of the Flag bits are: 461 X: Extended counter format indicator. Indicates the use of 462 extended (64-bit) counter values. Initialized to 1 upon creation 463 (and prior to transmission) of an LM Query and copied from an LM 464 Query to an LM response. Set to 0 when the LM message is 465 transmitted or received over an interface that writes 32-bit 466 counter values. 468 B: Octet (byte) count. When set to 1, indicates that the Counter 469 1-4 fields represent octet counts. The octet count applies to all 470 packets within the LM scope, and the octet count of a packet sent 471 or received includes the total length of that packet (but excludes 472 headers, labels, or framing of the channel itself). When set to 473 0, indicates that the Counter fields represent packet counts. 475 I: Inferred Mode Loss Measurement: When set to 1, indicates that 476 inferred-mode of loss measurement is used. When set to 0, it 477 indicates direct-mode of loss measurement is used. 479 Block Number (16-bit): The Loss Measurement using Alternate-Marking 480 method defined in [RFC8321] requires to identify the Block Number (or 481 color) of the traffic counters. The probe query and response 482 messages carry Block Number for the traffic counters for loss 483 measurement. In both probe query and response messages, the counters 484 MUST belong to the same Block Number. 486 HMAC: The PM probe packet in authenticated mode includes a key Hashed 487 Message Authentication Code (HMAC) ([RFC2104]) hash. Each probe 488 query and response messages are authenticated by adding Sequence 489 Number with Hashed Message Authentication Code (HMAC) TLV. It can 490 use HMAC-SHA-256 truncated to 128 bits (similarly to the use of it in 491 IPSec defined in [RFC4868]); hence the length of the HMAC field is 16 492 octets. 494 HMAC uses its own key and the mechanism to distribute the HMAC key is 495 outside the scope of this document. 497 In authenticated mode, only the sequence number is encrypted, and the 498 other payload fields are sent in clear text. The probe packet MAY 499 include Comp.MBZ (Must Be Zero) variable length field to align the 500 packet on 16 octets boundary. 502 4.1.2.1. Loss Measurement Authentication Mode 504 When using the authenticated mode for loss measurement, the matching 505 authentication type (e.g. HMAC-SHA-256) and key are user-configured 506 on both the sender and responder nodes. A separate user-configured 507 destination UDP port is used for the loss measurement in 508 authentication mode due to the different message format. 510 4.1.3. Probe Query for SR Links 512 The probe query message as defined in Figure 1 is sent on the 513 congruent path of the data traffic for Delay measurement. The probe 514 query message as defined in Figure 2 is sent on the congruent path of 515 the data traffic for Loss measurement. 517 4.1.4. Probe Query for End-to-end Measurement for SR Policy 519 The performance delay and loss measurement for segment routing is 520 applicable to both SR-MPLS and SRv6 Policies. 522 4.1.4.1. Probe Query Message for SR-MPLS Policy 524 The probe query messages for end-to-end performance measurement of an 525 SR-MPLS Policy is sent using its SR-MPLS header containing the MPLS 526 segment list as shown in Figure 4. 528 0 1 2 3 529 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 530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 531 | Segment List(1) | TC |S| TTL | 532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 . . 534 . . 535 . . 536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 537 | Segment List(n) | TC |S| TTL | 538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 539 | PSID | TC |S| TTL | 540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 541 | Message as shown in Figure 1 for DM or Figure 2 for LM | 542 . . 543 +---------------------------------------------------------------+ 545 Figure 4: Probe Query Message for SR-MPLS Policy 547 The Segment List (SL) can be empty to indicate Implicit NULL label 548 case for a single-hop SR Policy. 550 The Path Segment Identifier (PSID) [I-D.spring-mpls-path-segment] of 551 the SR-MPLS Policy is used for accounting received traffic on the 552 egress node for loss measurement. The PSID is not added for 553 end-to-end SR Policy delay measurement. 555 4.1.4.2. Probe Query Message for SRv6 Policy 557 An SRv6 Policy setup using the SRv6 Segment Routing Header (SRH) and 558 a Segment List as defined in [I-D.6man-segment-routing-header]. The 559 probe query messages for end-to-end performance measurement of an 560 SRv6 Policy is sent using its SRv6 Segment Routing Header (SRH) and 561 Segment List as shown in Figure 5. 563 +---------------------------------------------------------------+ 564 | SRH | 565 . END.OTP (DM) or END.OP (LM) with Target SRv6 SID . 566 . . 567 +---------------------------------------------------------------+ 568 | Message as shown in Figure 1 for DM or Figure 2 for LM | 569 . (Using IPv6 Source and Destination Addresses) . 570 . . 571 +---------------------------------------------------------------+ 573 Figure 5: Probe Query Message for SRv6 Policy 575 For delay measurement of SRv6 Policy using SRH, END function END.OTP 576 [I-D.spring-srv6-oam] is used with the target SRv6 SID to punt probe 577 messages on the target node, as shown in Figure 5. Similarly, for 578 loss measurement of SRv6 Policy, END function END.OP 579 [I-D.spring-srv6-oam] is used with target SRv6 SID to punt probe 580 messages on the target node. 582 4.2. Probe Response Message 584 The probe response message is sent using the IP/UDP information from 585 the received probe query message. The content of the probe response 586 message is shown in Figure 6. 588 +---------------------------------------------------------------+ 589 | IP Header | 590 . Source IP Address = Responder IPv4 or IPv6 Address . 591 . Destination IP Address = Source IP Address from Query . 592 . Protocol = UDP . 593 . . 594 +---------------------------------------------------------------+ 595 | UDP Header | 596 . Source Port = As chosen by Responder . 597 . Destination Port = Source Port from Query . 598 . . 599 +---------------------------------------------------------------+ 600 | DM Payload as specified in Section 4.2.1 of RFC 5357, or | 601 . LM Payload as specified in Figure 7A or 7B in this document . 602 . . 603 +---------------------------------------------------------------+ 605 Figure 6: Probe Response Message 607 In this document, new probe response message formats are defined for 608 loss measurement as shown in Figure 7A and Figure 7B. The message 609 formats are hardware efficient due to the small size payload and well 610 known locations of the counters. They are also similar to the delay 611 measurement message formats. 613 0 1 2 3 614 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 615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 616 | Sequence Number | 617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 618 | Transmit Counter | 619 | | 620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 621 |X|B| Reserved | Block Number | 622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 623 | Receive Counter | 624 | | 625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 626 | Sender Sequence Number | 627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 628 | Sender Counter | 629 | | 630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 631 |X|B| Reserved | Sender Block Number | 632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 633 | Sender TTL | | 634 +-+-+-+-+-+-+-+-+ + 635 | Packet Padding | 636 . . 637 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 638 | | Checksum Complement | 639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 641 Figure 7A: LM Probe Response Message 643 0 1 2 3 644 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 645 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 646 | Sequence Number | 647 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 648 | MBZ (12 octets) | 649 | | 650 | | 651 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 652 | Transmit Counter | 653 | | 654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 655 |X|B| Reserved | Block Number | 656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 657 | MBZ (6 octets) | 658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 659 | Receive Counter | 660 | | 661 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 662 | MBZ (8 octets) | 663 | | 664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 665 | Sender Sequence Number | 666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 667 | MBZ (12 octets) | 668 | | 669 | | 670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 671 | Sender Counter | 672 | | 673 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 674 |X|B| Reserved | Sender Block Number | 675 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 676 | MBZ (4 octets) | 677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 678 | Sender TTL | | 679 +-+-+-+-+-+-+-+-+ + 680 | MBZ (15 octets) | 681 | | 682 | | 683 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 684 | HMAC (16 octets) | 685 | | 686 | | 687 | | 688 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 689 | | 690 . . 691 . Packet Padding . 692 . . 693 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 694 | | Checksum Complement | 695 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 697 Figure 7B: LM Probe Response Message - Authenticated Mode 699 4.2.1. One-way Measurement Mode 701 In one-way performance measurement mode, the probe response message 702 as defined in Figure 6 is sent back out of band to the sender node, 703 for both SR links and SR Policies. 705 4.2.2. Two-way Measurement Mode 707 In two-way performance measurement mode, when using a bidirectional 708 path, the probe response message as defined in Figure 6 is sent back 709 on the congruent path of the data traffic to the sender node, for 710 both SR links and SR Policies. 712 4.2.2.1. Return Path TLV 714 For two-way performance measurement, the responder node needs to send 715 the probe response message on a specific reverse path. This way the 716 destination node does not require any additional state. The sender 717 node can request in the probe query message to the responder node to 718 send a response back on a given reverse path (e.g. co-routed path for 719 two-way measurement). 721 [I-D.ippm-stamp-option-tlv] defines STAMP probe query messages that 722 can include one or more optional TLVs. New TLV Type (TBA1) is 723 defined in this document for Return Path to carry reverse path for 724 probe response messages (in the payload of the message). The format 725 of the Return Path TLV is shown in Figure 8A and Figure 8B: 727 0 1 2 3 728 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 729 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 730 | Type = TBA1 | Length | Reserved | 731 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 732 | Return Path Sub-TLVs | 733 . . 734 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 736 Figure 8A: Return Path TLV 738 0 1 2 3 739 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 740 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 741 | Type | Length | Reserved | 742 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 743 | Segment List(1) | 744 . . 745 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 746 . . 747 . . 748 . . 749 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 750 | Segment List(n) | 751 . . 752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 754 Figure 8B: Segment List Sub-TLV in Return Path TLV 756 The Segment List Sub-TLV in the Return Path TLV can be one of the 757 following Types: 759 o Type (value 1): Respond back on Incoming Interface (Layer-3 and 760 Layer-2) (Segment List is Empty) 762 o Type (value 2): SR-MPLS Segment List (Label Stack) of the Reverse 763 SR Path 765 o Type (value 3): SR-MPLS Binding SID [I-D.pce-binding-label-sid] of 766 the Reverse SR Policy 768 o Type (value 4): SRv6 Segment List of the Reverse SR Path 770 o Type (value 5): SRv6 Binding SID [I-D.pce-binding-label-sid] of 771 the Reverse SR Policy 773 The Return Path TLV is optional. The PM sender node MUST only insert 774 one Return Path TLV in the probe query message and the responder node 775 MUST only process the first Return Path TLV in the probe query 776 message and ignore other Return Path TLVs if present. The responder 777 node MUST send probe response message back on the reverse path 778 specified in the Return Path TLV and MUST NOT add Return Path TLV in 779 the probe response message. 781 4.2.2.2. Probe Response Message for SR-MPLS Policy 783 The message content for sending probe response message for two-way 784 end-to-end performance measurement of an SR-MPLS Policy is shown in 785 Figure 9. 787 0 1 2 3 788 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 789 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 790 | Segment List(1) | TC |S| TTL | 791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 792 . . 793 . . 794 . . 796 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 797 | Segment List(n) | TC |S| TTL | 798 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 799 | Message as shown in Figure 6 | 800 . . 801 +---------------------------------------------------------------+ 803 Figure 9: Probe Response Message for SR-MPLS Policy 805 The Path Segment Identifier (PSID) [I-D.spring-mpls-path-segment] of 806 the forward SR Policy can be used to find the reverse SR Policy to 807 send the probe response message for two-way measurement of SR Policy. 809 4.2.2.3. Probe Response Message for SRv6 Policy 811 The message content for sending probe response message on the 812 congruent path of the data traffic for two-way end-to-end performance 813 measurement of an SRv6 Policy with SRH is shown in Figure 10. 815 +---------------------------------------------------------------+ 816 | SRH | 817 . END.OTP (DM) or END.OP (LM) with Target SRv6 SID . 818 . . 819 +---------------------------------------------------------------+ 820 | Message as shown in Figure 6 | 821 . (with IPv6 Source and Destination Addresses) . 822 . . 823 +---------------------------------------------------------------+ 825 Figure 10: Probe Response Message for SRv6 Policy 827 4.2.3. Loopback Measurement Mode 829 The Loopback measurement mode can be used to measure round-trip delay 830 for a bidirectional SR Path. The IP header of the probe query 831 message contains the destination address equals to the sender address 832 and the source address equals to the responder address. Optionally, 833 the probe query message can carry the reverse path information (e.g. 834 reverse path label stack for SR-MPLS) as part of the SR header. The 835 responder node does not process the PM probe messages and generate 836 response messages. 838 5. Performance Measurement for P2MP SR Policies 840 The procedures for delay and loss measurement described in this 841 document for Point-to-Point (P2P) SR Policies 843 [I-D.spring-segment-routing-policy] are also equally applicable to 844 the Point-to-Multipoint (P2MP) SR Policies 845 [I-D.spring-sr-p2mp-policy] as following: 847 o The sender root node sends probe query messages using either Spray 848 P2MP segment or TreeSID P2MP segment defined in 849 [I-D.spring-sr-p2mp-policy] over the P2MP SR Policy. 851 o The sender root node sets the PM probe query message Destination 852 IPv4 Address from the 127/8 range for SR-MPLS Policy. 854 o Each responder leaf node sends its IP address in the Source 855 Address of the probe response messages. This allows the sender 856 root node to identify the responder leaf nodes of the P2MP SR 857 Policy. 859 o The P2MP root node measures the end-to-end delay and loss 860 performance for each P2MP leaf node. 862 6. ECMP Support for SR Policies 864 An SR Policy can have ECMPs between the source and transit nodes, 865 between transit nodes and between transit and destination nodes. 866 Usage of Anycast SID [RFC8402] by an SR Policy can result in ECMP 867 paths via transit nodes part of that Anycast group. The PM probe 868 messages need to be sent to traverse different ECMP paths to measure 869 performance delay of an SR Policy. 871 Forwarding plane has various hashing functions available to forward 872 packets on specific ECMP paths. Following mechanisms can be used in 873 PM probe messages to take advantage of the hashing function in 874 forwarding plane to influence the path taken by them. 876 o The mechanisms described in [RFC8029] and [RFC5884] for handling 877 ECMPs are also applicable to the performance measurement. In the 878 IP/UDP header of the PM probe messages, Destination Addresses in 879 127/8 range for IPv4 or 0:0:0:0:0:FFFF:7F00/104 range for IPv6 can 880 be used to exercise a particular ECMP path. As specified in 881 [RFC6437], 3-tuple of Flow Label, Source Address and Destination 882 Address fields in the IPv6 header can also be used. 884 o For SR-MPLS Policy, entropy label [RFC6790] can be used in the PM 885 probe messages. 887 o For SRv6 Policy using SRH, Flow Label in the SRH 888 [I-D.6man-segment-routing-header] of the PM probe messages can be 889 used, in addition to the Source and Destination Addresses of the 890 SRv6 Policy. 892 7. Additional Message Processing Rules 894 7.1. TTL Value 896 The TTL or the Hop Limit field in the IP, MPLS and SRH headers of the 897 probe query messages are set to 255 [RFC5357]. 899 When using the Destination IPv4 Address from the 127/8 range, the TTL 900 in the IPv4 header is set to 1 [RFC8029]. Similarly, when using the 901 Destination IPv6 Address from the 0:0:0:0:0:FFFF:7F00/104 range, the 902 Hop Limit field in the inner IPv6 header is set to 1 whereas in the 903 outer IPv6 header is set to 255. 905 7.2. Router Alert Option 907 The Router Alert IP option is not set when using the routable 908 Destination IP Address in the probe messages. 910 When using the Destination IPv4 Address from the 127/8 range, the 911 Router Alert IP Option of value 0x0 [RFC2113] for IPv4 is set in the 912 IP header [RFC8029]. Similarly, when using the Destination IPv6 913 Address from the 0:0:0:0:0:FFFF:7F00/104 range, the Router Alert IP 914 Option of value 69 [RFC7506] for IPv6 is set in the IP header. 916 7.3. UDP Checksum 918 The Checksum Complement for delay and loss measurement messages 919 follows the procedure defined in [RFC7820] and can be optionally used 920 with the procedures defined in this document. 922 For IPv4 and IPv6 probe messages, where the hardware is not capable 923 of re-computing the UDP checksum or adding checksum complement 924 [RFC7820], the sender node sets the UDP checksum to 0 [RFC6936] 925 [RFC8085]. The receiving node bypasses the checksum validation and 926 accepts the packets with UDP checksum of 0 for the UDP port being 927 used for PM. 929 8. Security Considerations 931 The performance measurement is intended for deployment in 932 well-managed private and service provider networks. As such, it 933 assumes that a node involved in a measurement operation has 934 previously verified the integrity of the path and the identity of the 935 far end responder node. 937 If desired, attacks can be mitigated by performing basic validation 938 and sanity checks, at the sender, of the counter or timestamp fields 939 in received measurement response messages. The minimal state 940 associated with these protocols also limits the extent of measurement 941 disruption that can be caused by a corrupt or invalid message to a 942 single query/response cycle. 944 Use of HMAC-SHA-256 in the authenticated mode protects the data 945 integrity of the probe messages. SRv6 has HMAC protection 946 authentication defined for SRH [I-D.6man-segment-routing-header]. 947 Hence, PM probe messages for SRv6 may not need authentication mode. 948 Cryptographic measures may be enhanced by the correct configuration 949 of access-control lists and firewalls. 951 9. IANA Considerations 953 IANA is requested to allocate value for the following Return Path TLV 954 Type for [I-D.ippm-stamp-option-tlv] to be carried in PM probe query 955 messages: 957 o Type TBA1: Return Path TLV 959 10. References 961 10.1. Normative References 963 [RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 964 August 1980. 966 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 967 Requirement Levels", RFC 2119, March 1997. 969 [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. 970 Zekauskas, "A One-way Active Measurement Protocol 971 (OWAMP)", RFC 4656, September 2006. 973 [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. 974 Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", 975 RFC 5357, October 2008. 977 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 978 2119 Key Words", RFC 8174, May 2017. 980 [I-D.spring-srv6-oam] Ali, Z., et al., "Operations, Administration, 981 and Maintenance (OAM) in Segment Routing Networks with 982 IPv6 Data plane (SRv6)", draft-ali-spring-srv6-oam, work 983 in progress. 985 [I-D.ippm-stamp] Mirsky, G. et al. "Simple Two-way Active 986 Measurement Protocol", draft-ietf-ippm-stamp, work in 987 progress. 989 [I-D.ippm-stamp-option-tlv] Mirsky, G., et al., "Simple Two-way 990 Active Measurement Protocol Optional Extensions", 991 draft-ietf-ippm-stamp-option-tlv, work in progress. 993 10.2. Informative References 995 [IEEE1588] IEEE, "1588-2008 IEEE Standard for a Precision Clock 996 Synchronization Protocol for Networked Measurement and 997 Control Systems", March 2008. 999 [RFC2104] Krawczyk, H., Bell-are, M., and R. Canetti, "HMAC: Keyed- 1000 Hashing for Message Authentication", RFC 2104, February 1001 1997. 1003 [RFC2113] Katz, D., "IP Router Alert Option", RFC 2113, February 1004 1997. 1006 [RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA- 1007 384, and HMAC-SHA-512 with IPsec", RFC 4868, May 2007. 1009 [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, 1010 "Bidirectional Forwarding Detection (BFD) for MPLS Label 1011 Switched Paths (LSPs)", RFC 5884, DOI 10.17487/RFC5884, 1012 June 2010. 1014 [RFC6038] Morton, A. and L. Ciavattone, "Two-Way Active Measurement 1015 Protocol (TWAMP) Reflect Octets and Symmetrical Size 1016 Features", RFC 6038, October, 2010 1018 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 1019 Cheshire, "Internet Assigned Numbers Authority (IANA) 1020 Procedures for the Management of the Service Name and 1021 Transport Protocol Port Number Registry", BCP 165,RFC 1022 6335, August 2011. 1024 [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, 1025 "IPv6 Flow Label Specification", RFC 6437, November 2011. 1027 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 1028 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 1029 RFC 6790, November 2012. 1031 [RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement 1032 for the Use of IPv6 UDP Datagrams with Zero Checksums", 1033 RFC 6936, April 2013. 1035 [RFC7506] Raza, K., Akiya, N., and C. Pignataro, "IPv6 Router Alert 1036 Option for MPLS Operations, Administration, and 1037 Maintenance (OAM)", RFC 7506, DOI 10.17487/RFC7506, April 1038 2015, . 1040 [RFC7820] Mizrahi, T., "UDP Checksum Complement in the One-Way 1041 Active Measurement Protocol (OWAMP) and Two-Way Active 1042 Measurement Protocol (TWAMP)", RFC 7820, March 2016. 1044 [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Kumar, N., 1045 Aldrin, S. and M. Chen, "Detecting Multiprotocol Label 1046 Switched (MPLS) Data-Plane Failures", RFC 8029, March 1047 2017. 1049 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 1050 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 1051 March 2017, . 1053 [RFC8186] Mirsky, G., and I. Meilik, "Support of the IEEE 1588 1054 Timestamp Format in a Two-Way Active Measurement Protocol 1055 (TWAMP)", RFC 8186, June 2017. 1057 [RFC8321] Fioccola, G. Ed., "Alternate-Marking Method for Passive 1058 and Hybrid Performance Monitoring", RFC 8321, January 1059 2018. 1061 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 1062 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1063 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 1064 July 2018, . 1066 [I-D.spring-segment-routing-policy] Filsfils, C., et al., "Segment 1067 Routing Policy Architecture", 1068 draft-ietf-spring-segment-routing-policy, work in 1069 progress. 1071 [I-D.spring-sr-p2mp-policy] Voyer, D. Ed., et al., "SR Replication 1072 Policy for P2MP Service Delivery", 1073 draft-voyer-spring-sr-p2mp-policy, work in progress. 1075 [I-D.spring-mpls-path-segment] Cheng, W., et al., "Path Segment in 1076 MPLS Based Segment Routing Network", 1077 draft-ietf-spring-mpls-path-segment, work in progress. 1079 [I-D.6man-segment-routing-header] Filsfils, C., et al., "IPv6 1080 Segment Routing Header (SRH)", 1081 draft-ietf-6man-segment-routing-header, work in progress. 1083 [I-D.pce-binding-label-sid] Filsfils, C., et al., "Carrying Binding 1084 Label Segment-ID in PCE-based Networks", 1085 draft-sivabalan-pce-binding-label-sid, work in progress. 1087 [BBF.TR-390] "Performance Measurement from IP Edge to Customer 1088 Equipment using TWAMP Light", BBF TR-390, May 2017. 1090 [I-D.spring-ioam-sr-mpls] Gandhi, R. Ed., et al., "Segment Routing 1091 with MPLS Data Plane Encapsulation for In-situ OAM Data", 1092 draft-gandhi-spring-ioam-sr-mpls, work in progress. 1094 Acknowledgments 1096 The authors would like to thank Thierry Couture for various 1097 discussions on the use-cases for TWAMP Light in Segment Routing. The 1098 authors would also like to thank Greg Mirsky for reviewing this 1099 document and providing useful comments and suggestions. Patrick 1100 Khordoc and Radu Valceanu, both from Cisco Systems have helped 1101 significantly improve the mechanisms defined in this document. The 1102 authors would like to acknowledge the earlier work on the loss 1103 measurement using TWAMP described in 1104 draft-xiao-ippm-twamp-ext-direct-loss. 1106 Authors' Addresses 1108 Rakesh Gandhi (editor) 1109 Cisco Systems, Inc. 1110 Canada 1111 Email: rgandhi@cisco.com 1113 Clarence Filsfils 1114 Cisco Systems, Inc. 1115 Email: cfilsfil@cisco.com 1117 Daniel Voyer 1118 Bell Canada 1119 Email: daniel.voyer@bell.ca 1121 Mach(Guoyi) Chen 1122 Huawei 1123 Email: mach.chen@huawei.com 1125 Bart Janssens 1126 Colt 1127 Email: Bart.Janssens@colt.net