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