idnits 2.17.1 draft-gandhi-ippm-stamp-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 (October 20, 2020) is 1277 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-10) exists of draft-ietf-ippm-stamp-option-tlv-09 -- Obsolete informational reference (is this intentional?): RFC 8321 (Obsoleted by RFC 9341) == Outdated reference: A later version (-16) exists of draft-ietf-pce-binding-label-sid-03 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPPM Working Group R. Gandhi, Ed. 3 Internet-Draft C. Filsfils 4 Intended status: Standards Track Cisco Systems, Inc. 5 Expires: April 23, 2021 D. Voyer 6 Bell Canada 7 M. Chen 8 Huawei 9 B. Janssens 10 Colt 11 October 20, 2020 13 Simple TWAMP (STAMP) Extensions for Segment Routing Networks 14 draft-gandhi-ippm-stamp-srpm-00 16 Abstract 18 Segment Routing (SR) leverages the source routing paradigm. SR is 19 applicable to both Multiprotocol Label Switching (SR-MPLS) and IPv6 20 (SRv6) data planes. This document specifies RFC 8762 (Simple Two-Way 21 Active Measurement Protocol (STAMP)) extensions for Delay and Loss 22 Measurement in Segment Routing networks, for both SR-MPLS and SRv6 23 data planes. 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 https://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 This Internet-Draft will expire on April 23, 2021. 42 Copyright Notice 44 Copyright (c) 2020 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 61 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 62 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3 63 2.3. Reference Topology . . . . . . . . . . . . . . . . . . . 4 64 3. Probe Query Message . . . . . . . . . . . . . . . . . . . . . 4 65 3.1. Control Code Field Extension for STAMP Messages . . . . . 4 66 3.2. Loss Measurement Query Message Extensions . . . . . . . . 5 67 4. Probe Response Message . . . . . . . . . . . . . . . . . . . 8 68 4.1. Loss Measurement Response Message Extensions . . . . . . 8 69 5. Node Address TLV Extensions . . . . . . . . . . . . . . . . . 10 70 6. Return Path TLV Extensions . . . . . . . . . . . . . . . . . 10 71 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 72 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 73 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 74 9.1. Normative References . . . . . . . . . . . . . . . . . . 14 75 9.2. Informative References . . . . . . . . . . . . . . . . . 14 76 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 15 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 79 1. Introduction 81 Segment Routing (SR) leverages the source routing paradigm and 82 greatly simplifies network operations for Software Defined Networks 83 (SDNs). SR is applicable to both Multiprotocol Label Switching (SR- 84 MPLS) and IPv6 (SRv6) data planes. Built-in SR Performance 85 Measurement (PM) is one of the essential requirements to provide 86 Service Level Agreements (SLAs). 88 The Simple Two-way Active Measurement Protocol (STAMP) provides 89 capabilities for the measurement of various performance metrics in IP 90 networks using probe messages [RFC8762]. It eliminates the need for 91 control-channel signaling by using configuration data model to 92 provision a test-channel (e.g. UDP paths). 93 [I-D.ietf-ippm-stamp-option-tlv] defines TLV extensions for STAMP 94 messages. 96 The STAMP message with a TLV for "direct measurement" can be used for 97 combined Delay + Loss measurement [I-D.ietf-ippm-stamp-option-tlv]. 98 However, in order to use only for loss measurement purpose, it 99 requires the node to support the delay measurement messages and 100 support timestamp for these messages (which may also require clock 101 synchronization). Furthermore, for hardware-based counter collection 102 for direct-mode loss measurement, the optional TLV based processing 103 adds unnecessary overhead (as counters are not at well-known 104 locations). 106 This document specifies RFC 8762 (Simple Two-Way Active Measurement 107 Protocol (STAMP)) extensions for Delay and Loss Measurement in 108 Segment Routing networks, for both SR-MPLS and SRv6 data planes. 110 2. Conventions Used in This Document 112 2.1. Requirements Language 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 116 document are to be interpreted as described in [RFC2119] [RFC8174] 117 when, and only when, they appear in all capitals, as shown here. 119 2.2. Abbreviations 121 BSID: Binding Segment ID. 123 DM: Delay Measurement. 125 HMAC: Hashed Message Authentication Code. 127 LM: Loss Measurement. 129 MPLS: Multiprotocol Label Switching. 131 NTP: Network Time Protocol. 133 OWAMP: One-Way Active Measurement Protocol. 135 PM: Performance Measurement. 137 PTP: Precision Time Protocol. 139 SID: Segment ID. 141 SL: Segment List. 143 SR: Segment Routing. 145 SRH: Segment Routing Header. 147 SR-MPLS: Segment Routing with MPLS data plane. 149 SRv6: Segment Routing with IPv6 data plane. 151 SSID: STAMP Session Identifier. 153 STAMP: Simple Two-way Active Measurement Protocol. 155 2.3. Reference Topology 157 In the reference topology shown below, the sender node R1 initiates a 158 performance measurement probe query message and the reflector node R5 159 sends a probe response message for the query message received. The 160 probe response message is typically sent to the sender node R1. 162 t1 t2 163 / \ 164 +-------+ Query +-------+ 165 | | - - - - - - - - - ->| | 166 | R1 |=====================| R5 | 167 | |<- - - - - - - - - - | | 168 +-------+ Response +-------+ 169 \ / 170 t4 t3 171 Sender Reflector 173 Reference Topology 175 3. Probe Query Message 177 3.1. Control Code Field Extension for STAMP Messages 179 In this document, the Control Code field is defined for delay and 180 loss measurement probe query messages for STAMP protocol in 181 unauthenticated and authenticated modes. The modified delay 182 measurement probe query message format is shown in Figure 1. This 183 message format is backwards compatible with the message format 184 defined in STAMP [RFC8762] as its reflector MUST ignore the received 185 field (previously identified as MBZ). With this field, the reflector 186 node does not require any additional state for PM (recall that in SR 187 networks, the state is in the probe packet and signaling of the 188 parameters is undesired). The usage of the Control Code is not 189 limited to the SR and can be used for non-SR network. 191 . . 192 . . 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 | Timestamp | 195 | | 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 | Error Estimate | SSID | 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 | MBZ |Se Control Code| 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 . . 202 . . 204 Figure 1: Sender Control Code in STAMP DM Message 206 Sender Control Code: Set as follows in STAMP probe query message. 208 In a Query: 210 0x0: Out-of-band Response Requested. Indicates that the probe 211 response is not required over the same path in the reverse 212 direction. This is also the default behavior. 214 0x1: In-band Response Requested. Indicates that this query has 215 been sent over a bidirectional path and the probe response is 216 required over the same path in the reverse direction. 218 0x2: No Response Requested. 220 3.2. Loss Measurement Query Message Extensions 222 In this document, STAMP probe query messages for loss measurement are 223 defined as shown in Figure 2 and Figure 3. The message formats are 224 hardware efficient due to well-known locations of the counters and 225 payload small in size. They are stand-alone and similar to the delay 226 measurement message formats (e.g. location of the Counter and 227 Timestamp). They also do not require backwards compatibility and 228 support for the existing DM message formats from [RFC8762] as 229 different user-configured destination UDP port is used for loss 230 measurement. 232 0 1 2 3 233 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 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 | Sequence Number | 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 | Transmit Counter | 238 | | 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 |X|B| Reserved | Block Number | SSID | 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 | MBZ |Se Control Code| 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 | | 245 | MBZ (24 octets) | 246 | | 247 | | 248 | | 249 | | 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 Figure 2: STAMP LM Probe Query Message - Unauthenticated Mode 254 0 1 2 3 255 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 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 | Sequence Number | 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 | MBZ (12 octets) | 260 | | 261 | | 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 | Transmit Counter | 264 | | 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 |X|B| Reserved | Block Number | SSID | 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 | MBZ |Se Control Code| 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | MBZ (64 octets) | 271 . . 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 | | 274 | HMAC (16 octets) | 275 | | 276 | | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 Figure 3: STAMP LM Probe Query Message - Authenticated Mode 281 Sequence Number (32-bit): As defined in [RFC8762]. 283 Transmit Counter (64-bit): The number of packets or octets sent by 284 the sender node in the query message and by the reflector node in the 285 response message. The counter is always written at the well-known 286 location in the probe query and response messages. 288 Receive Counter (64-bit): The number of packets or octets received at 289 the reflector node. It is written by the reflector node in the probe 290 response message. 292 Sender Counter (64-bit): This is the exact copy of the transmit 293 counter from the received query message. It is written by the 294 reflector node in the probe response message. 296 Sender Sequence Number (32-bit): As defined in [RFC8762]. 298 Sender TTL: As defined in [RFC8762]. 300 LM Flags: The meanings of the Flag bits are: 302 X: Extended counter format indicator. Indicates the use of 303 extended (64-bit) counter values. Initialized to 1 upon creation 304 (and prior to transmission) of an LM query and copied from an LM 305 query to an LM response message. Set to 0 when the LM message is 306 transmitted or received over an interface that writes 32-bit 307 counter values. 309 B: Octet (byte) count. When set to 1, indicates that the Counter 310 1-4 fields represent octet counts. The octet count applies to all 311 packets within the LM scope, and the octet count of a packet sent 312 or received includes the total length of that packet (but excludes 313 headers, labels, or framing of the channel itself). When set to 314 0, indicates that the Counter fields represent packet counts. 316 Block Number (8-bit): The Loss Measurement using Alternate-Marking 317 method defined in [RFC8321] requires to color the data traffic. To 318 be able to correlate the transmit and receive traffic counters of the 319 matching color, the Block Number (or color) of the traffic counters 320 is carried by the probe query and response messages for loss 321 measurement. The Block Number can also be used to aggregate 322 performance metrics collected. 324 HMAC: The probe message in authenticated mode includes a key Hashed 325 Message Authentication Code (HMAC) [RFC2104] hash. Each probe query 326 and response messages are authenticated by adding Sequence Number 327 with Hashed Message Authentication Code (HMAC) TLV. It can use HMAC- 328 SHA-256 truncated to 128 bits (similarly to the use of it in IPSec 329 defined in [RFC4868]); hence the length of the HMAC field is 16 330 octets. 332 HMAC uses its own key and the mechanism to distribute the HMAC key is 333 outside the scope of this document. 335 In authenticated mode, only the sequence number is encrypted, and the 336 other payload fields are sent in clear text. The probe message MAY 337 include Comp.MBZ (Must Be Zero) variable length field to align the 338 packet on 16 octets boundary. 340 4. Probe Response Message 342 4.1. Loss Measurement Response Message Extensions 344 In this document, STAMP probe response message formats are defined 345 for loss measurement as shown in Figure 4 and Figure 5. 347 0 1 2 3 348 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 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 | Sequence Number | 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 | Transmit Counter | 353 | | 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 |X|B| Reserved | Block Number | SSID | 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 | Receive Counter | 358 | | 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 | Sender Sequence Number | 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 | Sender Counter | 363 | | 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 365 |X|B| Reserved |Sender Block Nu| MBZ | 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 | Sender TTL | MBZ | 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 Figure 4: STAMP LM Probe Response Message - Unauthenticated Mode 372 0 1 2 3 373 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 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 | Sequence Number | 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 | MBZ (12 octets) | 378 | | 379 | | 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 | Transmit Counter | 382 | | 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 |X|B| Reserved | Block Number | SSID | 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 | MBZ (4 octets) | 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 | Receive Counter | 389 | | 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 | MBZ (8 octets) | 392 | | 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 | Sender Sequence Number | 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 | MBZ (12 octets) | 397 | | 398 | | 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 | Sender Counter | 401 | | 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 |X|B| Reserved |Sender Block Nu| MBZ | 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 | MBZ (4 octets) | 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 | Sender TTL | | 408 +-+-+-+-+-+-+-+-+ | 409 | MBZ (15 octets) | 410 | | 411 | | 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 | | 414 | HMAC (16 octets) | 415 | | 416 | | 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 Figure 5: STAMP LM Probe Response Message - Authenticated Mode 421 5. Node Address TLV Extensions 423 In this document, Node Address TLV is defined for STAMP message 424 [I-D.ietf-ippm-stamp-option-tlv] and has the following format shown 425 in Figure 6: 427 0 1 2 3 428 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 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 |STAMP TLV Flags| Type | Length | 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 | Reserved | Address Family | 433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 ~ Address ~ 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 Figure 6: Node Address TLV Format 439 The Address Family field indicates the type of the address, and it 440 SHALL be set to one of the assigned values in the "IANA Address 441 Family Numbers" registry. 443 The STAMP TLV Flags are set using the procedures described in 444 [I-D.ietf-ippm-stamp-option-tlv]. 446 The following Type is defined and it contains Node Address TLV: 448 Destination Node Address (value TBA1): 450 The Destination Node Address TLV is optional. The Destination Node 451 Address TLV indicates the address of the intended recipient node of 452 the probe message. The reflector node MUST NOT send response message 453 if it is not the intended destination node of the probe query 454 message. 456 6. Return Path TLV Extensions 458 For two-way performance measurement, the reflector node needs to send 459 the probe response message on a specific reverse path. The sender 460 node can request in the probe query message to the reflector node to 461 send a response message back on a given reverse path (e.g. co-routed 462 bidirectional path). This way the reflector node does not require 463 any additional state for PM (recall that in SR networks, the state is 464 in the probe packet and signaling of the parameters is undesired). 466 For one-way performance measurement, the sender node address may not 467 be reachable via IP route from the reflector node. The sender node 468 in this case needs to send its reachability path information to the 469 reflector node. 471 [I-D.ietf-ippm-stamp-option-tlv] defines STAMP probe query messages 472 that can include one or more optional TLVs. The TLV Type (value 473 TBA2) is defined in this document for Return Path that carries 474 reverse path for STAMP probe response messages (in the payload of the 475 message). The format of the Return Path TLV is shown in Figure 7: 477 0 1 2 3 478 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 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 |STAMP TLV Flags| Type=TBA2 | Length | 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 482 | Return Path Sub-TLVs | 483 . . 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 Figure 7: Return Path TLV 488 The STAMP TLV Flags are set using the procedures described in 489 [I-D.ietf-ippm-stamp-option-tlv]. 491 The following Type defined for the Return Path TLV contains the Node 492 Address sub-TLV using the format shown above in Figure 7: 494 o Type (value 0): Return Address. Target node address of the 495 response message different than the Source Address in the query 497 0 1 2 3 498 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 499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 500 |STAMP TLV Flags| Type | Length | 501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 502 | Segment(1) | 503 . . 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 505 . . 506 . . 507 . . 509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 510 | Segment(n) | 511 . . 512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 514 Figure 8: Segment List Sub-TLV in Return Path TLV 516 The Segment List Sub-TLV (shown above in Figure 8) in the Return Path 517 TLV can be one of the following Types: 519 o Type (value 1): SR-MPLS Label Stack of the Reverse Path 521 o Type (value 2): SR-MPLS Binding SID 522 [I-D.ietf-pce-binding-label-sid] of the Reverse SR Policy 524 o Type (value 3): SRv6 Segment List of the Reverse Path 526 o Type (value 4): SRv6 Binding SID [I-D.ietf-pce-binding-label-sid] 527 of the Reverse SR Policy 529 The Return Path TLV is optional. The sender node MUST only insert 530 one Return Path TLV in the probe query message and the reflector node 531 MUST only process the first Return Path TLV in the probe query 532 message and ignore other Return Path TLVs if present. The reflector 533 node MUST send probe response message back on the reverse path 534 specified in the Return Path TLV and MUST NOT add Return Path TLV in 535 the probe response message. 537 7. Security Considerations 539 The performance measurement is intended for deployment in well- 540 managed private and service provider networks. As such, it assumes 541 that a node involved in a measurement operation has previously 542 verified the integrity of the path and the identity of the far-end 543 reflector node. 545 If desired, attacks can be mitigated by performing basic validation 546 and sanity checks, at the sender, of the counter or timestamp fields 547 in received measurement response messages. The minimal state 548 associated with these protocols also limits the extent of measurement 549 disruption that can be caused by a corrupt or invalid message to a 550 single query/response cycle. 552 Use of HMAC-SHA-256 in the authenticated mode protects the data 553 integrity of the probe messages. Cryptographic measures may be 554 enhanced by the correct configuration of access-control lists and 555 firewalls. 557 8. IANA Considerations 559 IANA will create a "STAMP TLV Type" registry for 560 [I-D.ietf-ippm-stamp-option-tlv]. IANA is requested to allocate a 561 value for the following Destination Address TLV Type from the IETF 562 Review TLV range of this registry. This TLV is to be carried in the 563 probe messages. 565 o Type TBA1: Destination Node Address TLV 567 IANA is also requested to allocate a value for the following Return 568 Path TLV Type from the IETF Review TLV range of the same registry. 569 This TLV is to be carried in the probe query messages. 571 o Type TBA2: Return Path TLV 573 IANA is requested to create a sub-registry for "Return Path Sub-TLV 574 Type". All code points in the range 1 through 175 in this registry 575 shall be allocated according to the "IETF Review" procedure as 576 specified in [RFC8126]. Code points in the range 176 through 239 in 577 this registry shall be allocated according to the "First Come First 578 Served" procedure as specified in [RFC8126]. Remaining code points 579 are allocated according to Table 1: 581 +-----------+--------------+---------------+ 582 | Value | Description | Reference | 583 +-----------+--------------+---------------+ 584 | 0 | Reserved | This document | 585 | 1 - 175 | Unassigned | This document | 586 | 176 - 239 | Unassigned | This document | 587 | 240 - 251 | Experimental | This document | 588 | 252 - 254 | Private Use | This document | 589 | 255 | Reserved | This document | 590 +-----------+--------------+---------------+ 592 Table 1: Return Path Sub-TLV Type Registry 594 IANA is requested to allocate the values for the following Sub-TLV 595 Types from this registry. 597 o Type (value 1): Return Address 599 o Type (value 2): SR-MPLS Label Stack of the Reverse Path 601 o Type (value 3): SR-MPLS Binding SID 602 [I-D.ietf-pce-binding-label-sid] of the Reverse SR Policy 604 o Type (value 4): SRv6 Segment List of the Reverse Path 606 o Type (value 5): SRv6 Binding SID [I-D.ietf-pce-binding-label-sid] 607 of the Reverse SR Policy 609 9. References 611 9.1. Normative References 613 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 614 Requirement Levels", BCP 14, RFC 2119, 615 DOI 10.17487/RFC2119, March 1997, 616 . 618 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 619 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 620 May 2017, . 622 [RFC8762] Mirsky, G., Jun, G., Nydell, H., and R. Foote, "Simple 623 Two-Way Active Measurement Protocol", RFC 8762, 624 DOI 10.17487/RFC8762, March 2020, 625 . 627 [I-D.ietf-ippm-stamp-option-tlv] 628 Mirsky, G., Min, X., Nydell, H., Foote, R., Masputra, A., 629 and E. Ruffini, "Simple Two-way Active Measurement 630 Protocol Optional Extensions", draft-ietf-ippm-stamp- 631 option-tlv-09 (work in progress), August 2020. 633 9.2. Informative References 635 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 636 Hashing for Message Authentication", RFC 2104, 637 DOI 10.17487/RFC2104, February 1997, 638 . 640 [RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA- 641 384, and HMAC-SHA-512 with IPsec", RFC 4868, 642 DOI 10.17487/RFC4868, May 2007, 643 . 645 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 646 Writing an IANA Considerations Section in RFCs", BCP 26, 647 RFC 8126, DOI 10.17487/RFC8126, June 2017, 648 . 650 [RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli, 651 L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, 652 "Alternate-Marking Method for Passive and Hybrid 653 Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321, 654 January 2018, . 656 [I-D.ietf-pce-binding-label-sid] 657 Filsfils, C., Sivabalan, S., Tantsura, J., Hardwick, J., 658 Previdi, S., and C. Li, "Carrying Binding Label/Segment-ID 659 in PCE-based Networks.", draft-ietf-pce-binding-label- 660 sid-03 (work in progress), June 2020. 662 Acknowledgments 664 The authors would like to thank Thierry Couture for the discussions 665 on the use-cases for Performance Measurement in Segment Routing. The 666 authors would also like to thank Greg Mirsky for reviewing this 667 document and providing useful comments and suggestions. The authors 668 would like to acknowledge the earlier work on the loss measurement 669 using TWAMP described in draft-xiao-ippm-twamp-ext-direct-loss. 671 Authors' Addresses 673 Rakesh Gandhi (editor) 674 Cisco Systems, Inc. 675 Canada 677 Email: rgandhi@cisco.com 679 Clarence Filsfils 680 Cisco Systems, Inc. 682 Email: cfilsfil@cisco.com 684 Daniel Voyer 685 Bell Canada 687 Email: daniel.voyer@bell.ca 689 Mach(Guoyi) Chen 690 Huawei 692 Email: mach.chen@huawei.com 694 Bart Janssens 695 Colt 697 Email: Bart.Janssens@colt.net