idnits 2.17.1 draft-wang-ippm-stamp-hbh-extensions-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 (November 15, 2020) is 1252 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) -- Looks like a reference, but probably isn't: '0' on line 138 -- Looks like a reference, but probably isn't: '1' on line 589 Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IP Performance Measurement Group Y. Wang 3 Internet-Draft T. Zhou 4 Intended status: Standards Track Huawei 5 Expires: May 19, 2021 H. Yang 6 China Mobile 7 C. Liu 8 China Unicom 9 November 15, 2020 11 Simple Two-way Active Measurement Protocol Extensions for Hop-by-Hop OAM 12 Data Collection 13 draft-wang-ippm-stamp-hbh-extensions-02 15 Abstract 17 This document defines optional TLVs which are carried in Simple Two- 18 way Active Measurement Protocol (STAMP) test packets to enhance the 19 STAMP base functions. Such extensions to STAMP enable OAM data 20 measurement and collection at every node and link along a STAMP test 21 packet's delivery path without maintaining a state for each 22 configured STAMP-Test session at every devices. 24 Requirements Language 26 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 27 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 28 document are to be interpreted as described in RFC 2119 [RFC2119]. 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 https://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 This Internet-Draft will expire on May 19, 2021. 47 Copyright Notice 49 Copyright (c) 2020 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (https://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 65 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 3. TLV Extensions to STAMP . . . . . . . . . . . . . . . . . . . 3 67 3.1. IOAM Tracing Data TLV . . . . . . . . . . . . . . . . . . 3 68 3.2. Forward HbH Delay TLV . . . . . . . . . . . . . . . . . . 5 69 3.3. Backward HbH Delay TLV . . . . . . . . . . . . . . . . . 7 70 3.4. HbH Packet Loss TLV . . . . . . . . . . . . . . . . . . . 9 71 3.5. HbH Bandwidth Utilization TLV . . . . . . . . . . . . . . 11 72 3.6. HbH Timestamp Information TLV . . . . . . . . . . . . . . 12 73 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 74 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 75 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 76 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 77 7.1. Normative References . . . . . . . . . . . . . . . . . . 15 78 7.2. Informative References . . . . . . . . . . . . . . . . . 15 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 81 1. Introduction 83 Simple Two-way Active Measurement Protocol (STAMP) [RFC8762] enables 84 the measurement of both one-way and round-trip performance metrics, 85 such as delay, delay variation, and packet loss. In the STAMP 86 session, the bidirectional packet flow is transmitted between STAMP 87 Session-Sender and STAMP Session-Reflector. The STAMP Session- 88 Reflector receives test packets transmitted from Session-Sender and 89 acts according to the configuration. However, the performance of 90 intermediate nodes and links that STAMP test packets traverse are 91 invisible. In addition, the STAMP instance must be configured at 92 every intermediate node to measure the performance per node and link 93 that test packets traverse, which increases the complexity of OAM in 94 large-scale networks. 96 STAMP Extensions have defined several optional TLVs to enhance the 97 STAMP base functions. These optional TLVs are defined as updates of 98 the STAMP Optional Extensions [I-D.ietf-ippm-stamp-option-tlv]. This 99 document extents optional TLVs to STAMP, which enables performance 100 measurement at every intermediate node and link along a STAMP test 101 packet's delivery path, such as measurement of delay, delay 102 variation, packet loss, and record of route information. The 103 following sections describe the use of TLVs for STAMP that extend 104 STAMP capability beyond its base specification. 106 2. Terminology 108 Following are abbreviations used in this document: 110 STAMP: Simple Two-way Active Measurement Protocol. 112 IOAM: In-situ OAM. 114 HbH: Hop-by-Hop. 116 3. TLV Extensions to STAMP 118 3.1. IOAM Tracing Data TLV 120 STAMP Session-Sender MAY place the IOAM Tracing Data TLV in Session- 121 Sender test packets to record the IOAM tracing data at every IOAM 122 capable node along the Session-Sender test packet's forward-delivery 123 path. As STAMP uses symmetrical packets, the Session-Sender MUST set 124 the Length value as a multiple of 4 octets according to the number of 125 nodes and the IOAM-Trace-Type (i.e. a 24-bit identifier which 126 specifies which data types are used in the node data list 127 [I-D.ietf-ippm-ioam-data]). And the node-data-copied-list fields 128 MUST be set to zero upon Session-Sender test packets transmission and 129 ignored upon receipt. 131 The IOAM Tracing Data TLV has the following format: 133 0 1 2 3 134 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 135 +-------------------------------+-------------------------------+ 136 | IOAM-Tracing-Data Type | Length | 137 +---------------------------------------------------------------+ 138 | node data copied list [0] | 139 +---------------------------------------------------------------+ 140 | node data copied list [1] | 141 +---------------------------------------------------------------+ 142 ~ ... ~ 143 +---------------------------------------------------------------+ 144 | node data copied list [n] | 145 +---------------------------------------------------------------+ 147 Fig. 1 IOAM Tracing Data TLV Format 149 where fields are defined as the following: 151 o IOAM-Tracing-Data Type: To be assigned by IANA. 153 o Length: A 2-octet field that indicates the length of the value 154 field in octets and equal to a multiple of 4 octets dependent on 155 the number of nodes and IOAM-Trace-Type bits. 157 o node data copied list [0..n]: A variable-length field, which 158 record the copied content of each node data element determined by 159 the IOAM-Trace-Type. The order of packing the data fields in each 160 node data element follows the bit order of the IOAM-Trace-Type 161 field (see section 4.4.1 of [I-D.ietf-ippm-ioam-data]). The last 162 node data element in this list is the node data of the first IOAM 163 trace capable node in the path. 165 In an IOAM domain, the STAMP Session-Sender and the STAMP Session- 166 Reflector MAY be configured as the IOAM encapsulating node and the 167 IOAM decapsulating node. The STAMP Session-Sender (i.e. the IOAM 168 encapsulating node) generates the test packet with the IOAM Tracing 169 Data TLV. For applying the IOAM Trace-Option functionalities to the 170 Session-Sender test packet, the Session-Sender must inserts the 171 "trace option header" and allocate an node-data-list array 172 [I-D.ietf-ippm-ioam-data] into "option data" fields of Hop-by-Hop 173 Options header in IPv6 packets [I-D.ietf-ippm-ioam-ipv6-options], and 174 sets the corresponding bits in the IOAM-Trace-Type. Also, the STAMP 175 Session-Sender allocates a node-data-copied-list array in the 176 optional IOAM Tracing Data TLV to store OAM data retrieved from every 177 IOAM transit node along the Session-Sender test packet's delivery 178 path. 180 When the STAMP Session-Reflector (i.e. the IOAM decapsulating node) 181 received the STAMP Session-Sender test packet with the IOAM-Tracing- 182 Data TLV, it MUST copy the node-data-list array into the node-data- 183 copied-list array carried in the Session-Reflector test packet before 184 transmission and MUST remove the IOAM-Data-Fields. Hence, carrying 185 IOAM-Tracing-Data TLV in STAMP test packets enables OAM data 186 collection and measurement at every node and link. 188 Also the STAMP Session-Reflector MAY be configured as IOAM 189 encapsulating node to apply the IOAM Trace-Option functionalities to 190 the Session-Reflector test packet. Hence, OAM data collection and 191 measurement can be also enabled at every node and link along the 192 Session-Reflector test packet's backward delivery path. When the 193 reflected packet arrives at the Session-Sender, it can be either 194 locally processed or sent to the centralized controller. 196 In addition to IOAM, other telemetry data (e.g. alternate marking) 197 could be transmitted by STAMP optional TLV extensions. The draft 198 will keep the option open for future augmentations. 200 3.2. Forward HbH Delay TLV 202 STAMP Session-Sender MAY place the Forward HbH Delay TLV in Session- 203 Sender test packets to record the ingress timestamp and the egress 204 timestamp at every intermediate nodes along the Session-Sender test 205 packet's forward path. The Session-Sender MUST set the Length value 206 according to the number of explicitly listed intermediate nodes in 207 the forward path and the timestamp formats. There are several 208 methods to synchronize the clock, e.g., Network Time Protocol (NTP) 209 [RFC5905] and IEEE 1588v2 Precision Time Protocol (PTP) 210 [IEEE.1588.2008]. For example, if a 64-bit timestamp format defined 211 in NTP is used, the Length value MUST be set as a multiple of 16 212 octets. The Timestamp Tuple list [1..n] fields MUST be set to zero 213 upon Session-Sender test packets transmission. 215 The Forward HbH Delay TLV has the following format: 217 0 1 2 3 218 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 219 +-------------------------------+---------------+---------------+ 220 | Forward HbH Delay Type | Length | Node Left | 221 +-------------------------------+---------------+---------------+ 222 | | 223 | Timestamp Tuple list [1] | 224 | | 225 | | 226 +---------------------------------------------------------------+ 227 ~ ... ~ 228 +---------------------------------------------------------------+ 229 | | 230 | Timestamp Tuple list [n] | 231 | | 232 | | 233 +---------------------------------------------------------------+ 235 Fig. 2 Forward HbH Delay TLV Format 237 where fields are defined as the following: 239 o Forward HbH Delay Type: To be assigned by IANA. 241 o Length: A 8-bit field that indicates the length of the value 242 portion in octets and MUST be a multiple of 16 octets according to 243 the number of explicitly listed intermediate nodes in the forward 244 path. 246 o Node Left: A 8-bit unsigned integer, which indicates the number of 247 intermediate nodes remaining. That is, number of explicitly 248 listed intermediate nodes still to be visited before reaching the 249 destination node in the forward path. The Node Left field is set 250 to n-1, where n is the number of intermediate nodes. 252 o Timestamp Tuple list [1..n]: A variable-length field, which record 253 the timestamp when the Session-Sender test packet is received at 254 the ingress of the n-th intermediate node Ingress Timestamp [n] 255 and the timestamp when the Session-Sender test packet is sent at 256 egress of the n-th intermediate node Egress Timestamp [n]. For 257 example, if a 64-bit timestamp format defined in NTP is used, the 258 length of each Timestamp tuple (Ingress Timestamp [n], Egress 259 Timestamp [n]) must be 16 octets. The Timestamp Tuple list is 260 encoded starting from the last intermediate node which is 261 explicitly listed. That is, the first element of the Timestamp 262 Tuple list [1] records the timestamps when the Session-Sender test 263 packet received and forwarded at the last intermediate node of a 264 explicit path, the second element records the penultimate 265 Timestamp Tuple when the Session-Sender test packet received and 266 forwarded at the penultimate intermediate node of a explicit path, 267 and so on. 269 In the following reference topology, Node N1, N2, N3, N4 and N5 are 270 SRv6 capable nodes. Node N1 is the STAMP Session-Sender and Node N5 271 is the STAMP Session-Reflector. T1 is the Timestamp taken by the 272 Session-Sender (i.e. N1) at the start of transmitting the test 273 packet. T2 is the Receive Timestamp when the test packet was 274 received by the Session-Reflector (i.e. N5). T3 is the Timestamp 275 taken by the Session-Reflector at the start of transmitting the test 276 packet. T4 is the Receive Timestamp when the test packet was 277 received by the Session-Sender. Timestamp tuples (t1,t2), (t3,t4) 278 and (t5,t6) are the timestamps when the test packet received and 279 transmitted by sequence of intermediate nodes in the forward path. 280 Timestamp Tuples (t7,t8), (t9,t10) and (t11,t12) are the timestamps 281 when the test packet received and transmitted by sequence of 282 intermediate nodes in the backward path. 284 ====== ====== ====== ====== ====== 285 | | T1--->t1 | | t2--->t3 | | t4--->t5 | | t6--->T2| | 286 | N1 |==========| N2 |==========| N3 |==========| N4 |=========| N5 | 287 | | T4<---t12| |t11<---t10| | t9<---t8 | | t7<---T3| | 288 ====== ====== ====== ====== ====== 290 Fig. 3 Reference Topology 292 The STAMP Session-Sender (i.e. Node N1) generates the STAMP test 293 packet with the Forward HbH Delay TLV. When an intermediate node 294 receives the STAMP test packet, the node punts the packet to control 295 plane and fills the Ingress Timestamp [n] filed in the Timestamp 296 Tuple list [n]. Then the time taken by the intermediate node 297 transmitting the test packet is recorded in to Egress Timestamp [n] 298 field. The mechanism of timestamping and punting packet to control 299 plane is outside the scope of this specification. 301 When the STAMP Session-Reflector received the test packet with the 302 Forward HbH Delay TLV, it MUST copy the Forward HbH Delay TLV into 303 the Session-Reflector test packet before its transmission. Using 304 Forward HbH Delay TLV in STAMP testing enables delay measurement per 305 link in the forward path. 307 3.3. Backward HbH Delay TLV 309 STAMP Session-Sender MAY place the Backward HbH Delay TLV in Session- 310 Sender test packets to record the ingress timestamp and egress 311 timestamp when Session-Reflector test packets are received and sent 312 at every intermediate nodes in the backward path. The Session-Sender 313 MUST set the Length value according to the number of explicitly 314 listed intermediate nodes in the backward path and the timestamp 315 formats. There are several methods to synchronize the clock, e.g., 316 Network Time Protocol (NTP) [RFC5905] and IEEE 1588v2 Precision Time 317 Protocol (PTP) [IEEE.1588.2008]. For example, if a 64-bit timestamp 318 format defined in NTP is used, the Length value MUST be set as a 319 multiple of 16 octets. The Timestamp Tuple list [1..n] fields MUST 320 be set to zero upon Session-Sender test packets transmission and 321 ignored upon receipt. 323 The Backward HbH Delay TLV has the following format: 325 0 1 2 3 326 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 327 +-------------------------------+---------------+---------------+ 328 | Backward HbH Delay Type | Length | Node Left | 329 +-------------------------------+---------------+---------------+ 330 | | 331 | Timestamp Tuple list [1] | 332 | | 333 | | 334 +---------------------------------------------------------------+ 335 ~ ... ~ 336 +---------------------------------------------------------------+ 337 | | 338 | Timestamp Tuple list [n] | 339 | | 340 | | 341 +---------------------------------------------------------------+ 343 Fig. 4 Backward HbH Delay TLV Format 345 where fields are defined as the following: 347 o Backward HbH Delay Type: To be assigned by IANA. 349 o Length: A 8-bit field that indicates the length of the value 350 portion in octets and will be a multiple of 16 octets dependent on 351 the number of explicitly listed intermediate nodes in the backward 352 path. 354 o Node Left: A 8-bit unsigned integer, which indicates the number of 355 intermediate nodes remaining. That is, number of explicitly 356 listed intermediate nodes still to be visited before reaching the 357 destination node in the backward path. The Node Left field is set 358 to n-1, where n is the number of intermediate nodes. 360 o Timestamp Tuple list [1..n]: A variable-length field, which record 361 the timestamp when the reflected test packet is received at the 362 ingress of the n-th intermediate node and the timestamp when the 363 reflected test packet is sent at egress of the n-th intermediate 364 node. For example, if a 64-bit timestamp format defined in NTP is 365 used, the length of each Timestamp tuple (Ingress Timestamp [n], 366 Egress Timestamp [n]) must be 16 octets. The Timestamp Tuple list 367 is encoded starting from the last intermediate node which is 368 explicitly listed. That is, the first element of the Timestamp 369 Tuple list [1] records the timestamps when the reflected test 370 packet received and forwarded at the last intermediate node of a 371 explicit path, the second element records the penultimate 372 Timestamp Tuple when the reflected test packet received and 373 forwarded at the penultimate intermediate node of a explicit path, 374 and so on. 376 When the STAMP Session-Reflector received the Session-Sender test 377 packet with the Backward HbH Delay TLV, it MUST copy the Backward HbH 378 Delay TLV into the Session-Reflector test packet. 380 When an intermediate node receives the reflected test packet, the 381 node sends the packet to control plane and fills the Ingress 382 Timestamp [n] filed of Backward HbH Delay TLV. Then the time taken 383 by the intermediate node transmitting the test packet is recorded in 384 to Egress Timestamp [n] field of Backward HbH Delay TLV. Using 385 Backward HbH Delay TLV in STAMP testing enables delay measurement per 386 link in the backward path. 388 3.4. HbH Packet Loss TLV 390 STAMP Session-Sender MAY place the HbH Packet Loss TLV in Session- 391 Sender test packets to record the number of Session-Sender test 392 packets received at and transmitted by every intermediate nodes along 393 the forward path. The Session-Sender MUST set the Length value 394 according to the number of explicitly listed intermediate nodes in 395 the forward path. A Counter Tuple is composed of a 64-bit Receive 396 Counter field and a 64-bit Transmit Counter field. The Counter Tuple 397 list [1..n] fields MUST be set to zero upon Session-Sender test 398 packets transmission. 400 The HbH Packet Loss TLV has the following format: 402 0 1 2 3 403 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 404 +-------------------------------+---------------+---------------+ 405 | HbH Packet Loss Type | Length | Node Left | 406 +-------------------------------+---------------+---------------+ 407 | | 408 | Counter Tuple list [1] | 409 | | 410 | | 411 +---------------------------------------------------------------+ 412 ~ ... ~ 413 +---------------------------------------------------------------+ 414 | | 415 | Counter Tuple list [n] | 416 | | 417 | | 418 +---------------------------------------------------------------+ 420 Fig. 5 HbH Packet Loss TLV Format 422 where fields are defined as the following: 424 o HbH Packet Loss Type: To be assigned by IANA. 426 o Length: A 8-bit field that indicates the length of the value 427 portion in octets and will be a multiple of 16 octets dependent on 428 the number of explicitly listed intermediate nodes in the forward 429 path. 431 o Node Left: A 8-bit unsigned integer, which indicates the number of 432 intermediate nodes remaining. That is, number of explicitly 433 listed intermediate nodes still to be visited before reaching the 434 destination node in the forward path. The Node Left field is set 435 to n-1, where n is the number of intermediate nodes. 437 o Counter Tuple list [1..n]: A variable-length field, which record 438 the Receive Counter and the Transmit Counter when the test packet 439 is received at and transmitted by the n-th intermediate node. The 440 Counter Tuple list is encoded starting from the last intermediate 441 node which is explicitly listed. That is, the first element of 442 the Counter Tuple list [1] records the Receive Counter and the 443 Transmit Counter when the test packet is received at and 444 transmitted by the last intermediate node of a explicit path, the 445 second element records the penultimate Counter Tuple when the test 446 packet received and forwarded at the penultimate intermediate node 447 of a explicit path, and so on. 449 The STAMP Session-Sender generates the STAMP test packet with the HbH 450 Packet Loss TLV. When an intermediate node receives the STAMP test 451 packet, the node punts the packet to control plane and writes the 452 Receive Counter and the Transmit Counter at the Counter Tuple list 453 [n] in the Session-Sender test packet. The mechanism of punting 454 packet to control plane is outside the scope of this specification. 456 When the STAMP Session-Reflector received the test packet with the 457 HbH Packet Loss TLV, it MUST copy the HbH Packet Loss TLV into the 458 Session-Reflector test packet before its transmission. Using HbH 459 Packet Loss TLV in STAMP testing enables packet loss measurement per 460 node/link in the forward path. 462 3.5. HbH Bandwidth Utilization TLV 464 STAMP Session-Sender MAY place the HbH Bandwidth Utilization TLV in 465 Session-Sender test packets to record the ingress and egress 466 bandwidth utilization at every intermediate nodes along the forward 467 path. The Session-Sender MUST set the Length value according to the 468 number of explicitly listed intermediate nodes in the forward path. 469 A BW Utilization Tuple is composed of a 32-bit ingress bandwidth 470 utilization field and a 32-bit egress bandwidth utilization field. 471 The BW Utilization Tuple list [1..n] fields MUST be set to zero upon 472 Session-Sender test packets transmission. 474 The HbH Bandwidth Utilization TLV has the following format: 476 0 1 2 3 477 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 478 +-------------------------------+---------------+---------------+ 479 | HbH BW Utilization Type | Length | Node Left | 480 +-------------------------------+---------------+---------------+ 481 | BW Utilization Tuple list [1] | 482 | | 483 +---------------------------------------------------------------+ 484 ~ ... ~ 485 +---------------------------------------------------------------+ 486 | BW Utilization Tuple list [n] | 487 | | 488 +---------------------------------------------------------------+ 490 Fig. 6 HbH Bandwidth Utilization TLV Format 492 where fields are defined as the following: 494 o HbH BW Utilization Type: To be assigned by IANA. 496 o Length: A 8-bit field that indicates the length of the value 497 portion in octets and will be a multiple of 8 octets dependent on 498 the number of explicitly listed intermediate nodes in the forward 499 path. 501 o Node Left: A 8-bit unsigned integer, which indicates the number of 502 intermediate nodes remaining. That is, number of explicitly 503 listed intermediate nodes still to be visited before reaching the 504 destination node in the forward path. The Node Left field is set 505 to n-1, where n is the number of intermediate nodes. 507 o BW Utilization Tuple list [1..n]: A variable-length field, which 508 record the ingress and egress bandwidth utilization when the test 509 packet is received at and transmitted by the n-th intermediate 510 node. The BW Utilization Tuple list is encoded starting from the 511 last intermediate node which is explicitly listed. That is, the 512 first element of the BW Utilization Tuple list [1] records the 513 ingress and the egress bandwidth utilization when the test packet 514 is received at and transmitted by the last intermediate node of a 515 explicit path, the second element records the penultimate BW 516 Utilization Tuple when the test packet received at and transmitted 517 by the penultimate intermediate node of a explicit path, and so 518 on. 520 The STAMP Session-Sender generates the STAMP test packet with the HbH 521 BW Utilization TLV. When an intermediate node receives the STAMP 522 test packet, the node punts the packet to control plane and writes 523 the ingress and egress bandwidth utilization at the BW Utilization 524 Tuple list [n] in the Session-Sender test packet. The mechanism of 525 punting packet to control plane is outside the scope of this 526 specification. 528 When the STAMP Session-Reflector received the test packet with the 529 HbH BW Utilization TLV, it MUST copy the HbH BW Utilization TLV into 530 the Session-Reflector test packet before its transmission. The HbH 531 BW Utilization TLV carried in STAMP test packet is usable to detect 532 and troubleshoot the link congestion in the forward path. 534 3.6. HbH Timestamp Information TLV 536 STAMP Session-Sender MAY place the HbH Timestamp Information TLV in 537 Session-Sender test packets to query the ingress and egress Timestamp 538 Information at every intermediate nodes along the forward path. The 539 Timestamp Information includes the source of clock synchronization 540 and the method of timestamp obtainment. There are several types of 541 clock synchronization source, e.g., NTP, PTP. The method of 542 timestamp obtainment may be from control plane (e.g. NTP) or from 543 data plane (e.g. PTP). A Timestamp Info Tuple is composed of a 544 8-bit ingress clock source field, a 8-bit ingress timestamp 545 obtainment field, a 8-bit egress clock source field, and a 8-bit 546 egress timestamp obtainment field. The Session-Sender MUST set the 547 Length value according to the number of explicitly listed 548 intermediate nodes in the forward path. The Timestamp Info Tuple 549 list [1..n] fields MUST be set to zero upon Session-Sender test 550 packets transmission. 552 The HbH Timestamp Information TLV has the following format: 554 0 1 2 3 555 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 556 +-------------------------------+---------------+---------------+ 557 | HbH Timestamp Info Type | Length | Node Left | 558 +-------------------------------+---------------+---------------+ 559 | Timestamp Info Tuple list [1] | 560 +---------------------------------------------------------------+ 561 ~ ... ~ 562 +---------------------------------------------------------------+ 563 | Timestamp Info Tuple list [n] | 564 +---------------------------------------------------------------+ 566 Fig. 6 HbH Timestamp Information TLV Format 568 where fields are defined as the following: 570 o HbH Timestamp Info Type: To be assigned by IANA. 572 o Length: A 8-bit field that indicates the length of the value 573 portion in octets and will be a multiple of 4 octets dependent on 574 the number of explicitly listed intermediate nodes in the forward 575 path. 577 o Node Left: A 8-bit unsigned integer, which indicates the number of 578 intermediate nodes remaining. That is, number of explicitly 579 listed intermediate nodes still to be visited before reaching the 580 destination node in the forward path. The Node Left field is set 581 to n-1, where n is the number of intermediate nodes. 583 o Timestamp Info Tuple list [1..n]: A variable-length field, which 584 record the source of clock synchronization and the method of 585 timestamp obtainment at the ingress and egress when the test 586 packet is received at and transmitted by the n-th intermediate 587 node. The Timestamp Info Tuple list is encoded starting from the 588 last intermediate node which is explicitly listed. That is, the 589 first element of the Timestamp Info Tuple list [1] records the 590 source of clock synchronization and the method of timestamp 591 obtainment at the ingress and egress when the test packet is 592 received at and transmitted by the last intermediate node of a 593 explicit path, the second element records the penultimate 594 Timestamp Info Tuple when the test packet received at and 595 transmitted by the penultimate intermediate node of a explicit 596 path, and so on. 598 The STAMP Session-Sender generates the STAMP test packet with the HbH 599 Timestamp Information TLV. When an intermediate node receives the 600 STAMP test packet, the node punts the packet to control plane and 601 writes the source of clock synchronization and the method of 602 timestamp obtainment at the Timestamp Info Tuple list [n] in the 603 Session-Sender test packet. The mechanism of punting packet to 604 control plane is outside the scope of this specification. 606 When the STAMP Session-Reflector received the test packet with the 607 HbH Timestamp Information TLV, it MUST copy the HbH Timestamp 608 Information TLV into the Session-Reflector test packet before its 609 transmission. The HbH Timestamp Information TLV carried in STAMP 610 test packet is usable to query timestamp information from every nodes 611 in the forward path. 613 Note that the source of clock synchronization, NTP or PTP, is part of 614 configuration of the Session-Sender/Reflector or a particular test 615 session [RFC8762]. This draft recommends every intermediate nodes to 616 be configured to use the same source of clock synchronization. 618 4. IANA Considerations 620 IANA is requested to allocate values for the following TLV Type from 621 the "STAMP TLV Type" registry [I-D.ietf-ippm-stamp-option-tlv]. 623 +------------+-------------------------------+---------------+ 624 | Code Point | Description | Reference | 625 +------------+-------------------------------+---------------+ 626 | TBA1 | IOAM Tracing Data TLV | This document | 627 | TBA2 | Forward HbH Delay TLV | This document | 628 | TBA3 | Backward HbH Delay TLV | This document | 629 | TBA4 | HbH Packet Loss TLV | This document | 630 | TBA5 | HbH BW Utilization TLV | This document | 631 | TBA6 | HbH Timestamp Information TLV | This document | 632 +------------+-------------------------------+---------------+ 634 5. Security Considerations 636 This document extensions new optional TLVs to STAMP. It does not 637 introduce any new security risks to STAMP. 639 6. Acknowledgements 641 The authors would like to thank Hongwei Yang, Giuseppe Fioccola and 642 Chang Liu for the reviews and comments. 644 7. References 646 7.1. Normative References 648 [I-D.ietf-ippm-ioam-data] 649 "Data Fields for In-situ OAM", 650 . 653 [I-D.ietf-ippm-ioam-ipv6-options] 654 "In-situ OAM IPv6 Options", 655 . 658 [I-D.ietf-ippm-stamp-option-tlv] 659 "Simple Two-way Active Measurement Protocol Optional 660 Extensions", . 663 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 664 Requirement Levels", BCP 14, RFC 2119, 665 DOI 10.17487/RFC2119, March 1997, 666 . 668 [RFC8762] "Simple Two-Way Active Measurement Protocol", 669 . 671 7.2. Informative References 673 [IEEE.1588.2008] 674 "IEEE Standard for a Precision Clock Synchronization 675 Protocol for Networked Measurement and Control Systems", 676 . 678 [RFC5905] "Network Time Protocol Version 4: Protocol and Algorithms 679 Specification", . 681 Authors' Addresses 682 Yali Wang 683 Huawei 684 156 Beijing Rd., Haidian District 685 Beijing 686 China 688 Email: wangyali11@huawei.com 690 Tianran Zhou 691 Huawei 692 156 Beijing Rd., Haidian District 693 Beijing 694 China 696 Email: zhoutianran@huawei.com 698 Hongwei Yang 699 China Mobile 700 Beijing 701 China 703 Email: yanghongwei@chinamobile.com 705 Chang Liu 706 China Unicom 707 Beijing 708 China 710 Email: liuc131@chinaunicom.cn