idnits 2.17.00 (12 Aug 2021)
/tmp/idnits3492/draft-wang-ippm-stamp-hbh-extensions-03.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 (February 22, 2021) is 446 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 139
-- Looks like a reference, but probably isn't: '1' on line 668
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: August 26, 2021 H. Yang
6 China Mobile
7 C. Liu
8 China Unicom
9 February 22, 2021
11 Simple Two-way Active Measurement Protocol Extensions for Hop-by-Hop OAM
12 Data Collection
13 draft-wang-ippm-stamp-hbh-extensions-03
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 August 26, 2021.
47 Copyright Notice
49 Copyright (c) 2021 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 Direct Loss TLV . . . . . . . . . . . . . . . . . . . 9
71 3.5. HbH Bandwidth Utilization TLV . . . . . . . . . . . . . . 11
72 3.6. HbH Timestamp Information TLV . . . . . . . . . . . . . . 12
73 3.7. HbH Interface Errors TLV . . . . . . . . . . . . . . . . 14
74 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
75 5. Security Considerations . . . . . . . . . . . . . . . . . . . 16
76 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
77 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
78 7.1. Normative References . . . . . . . . . . . . . . . . . . 16
79 7.2. Informative References . . . . . . . . . . . . . . . . . 17
80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
82 1. Introduction
84 Simple Two-way Active Measurement Protocol (STAMP) [RFC8762] enables
85 the measurement of both one-way and round-trip performance metrics,
86 such as delay, delay variation, and packet loss. In the STAMP
87 session, the bidirectional packet flow is transmitted between STAMP
88 Session-Sender and STAMP Session-Reflector. The STAMP Session-
89 Reflector receives test packets transmitted from Session-Sender and
90 acts according to the configuration. However, the performance of
91 intermediate nodes and links that STAMP test packets traverse are
92 invisible. In addition, the STAMP instance must be configured at
93 every intermediate node to measure the performance per node and link
94 that test packets traverse, which increases the complexity of OAM in
95 large-scale networks.
97 STAMP Extensions have defined several optional TLVs to enhance the
98 STAMP base functions. These optional TLVs are defined as updates of
99 the STAMP Optional Extensions [RFC8972]. This document extents
100 optional TLVs to STAMP, which enables performance measurement at
101 every intermediate node and link along a STAMP test packet's delivery
102 path, such as measurement of delay, delay variation, packet loss, and
103 record of link errors and route information. The following sections
104 describe the use of TLVs for STAMP that extend STAMP capability
105 beyond its base specification.
107 2. Terminology
109 Following are abbreviations used in this document:
111 STAMP: Simple Two-way Active Measurement Protocol.
113 IOAM: In-situ OAM.
115 HbH: Hop-by-Hop.
117 3. TLV Extensions to STAMP
119 3.1. IOAM-Tracing-Data TLV
121 STAMP Session-Sender MAY place the IOAM-Tracing-Data TLV in Session-
122 Sender test packets to record the IOAM tracing data at every IOAM
123 capable node along the Session-Sender test packet's forward-delivery
124 path. As STAMP uses symmetrical packets, the Session-Sender MUST set
125 the Length value as a multiple of 4 octets according to the number of
126 nodes and the IOAM-Trace-Type (i.e. a 24-bit identifier which
127 specifies which data types are used in the node data list
128 [I-D.ietf-ippm-ioam-data]). And the node-data-copied-list fields
129 MUST be set to zero upon Session-Sender test packets transmission and
130 ignored upon receipt.
132 The IOAM-Tracing-Data TLV has the following format:
134 0 1 2 3
135 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
136 +-------------------------------+-------------------------------+
137 | IOAM-Tracing-Data Type | Length |
138 +---------------------------------------------------------------+
139 | node-data-copied-list [0] |
140 +---------------------------------------------------------------+
141 | node-data-copied-list [1] |
142 +---------------------------------------------------------------+
143 ~ ... ~
144 +---------------------------------------------------------------+
145 | node-data-copied-list [n] |
146 +---------------------------------------------------------------+
148 Fig. 1 IOAM-Tracing-Data TLV Format
150 where fields are defined as the following:
152 o IOAM-Tracing-Data Type: To be assigned by IANA.
154 o Length: A 2-octet field that indicates the length of the value
155 field in octets and equal to a multiple of 4 octets dependent on
156 the number of nodes and IOAM-Trace-Type bits.
158 o node-data-copied-list [0..n]: A variable-length field, which
159 record the copied content of each node data element determined by
160 the IOAM-Trace-Type. The order of packing the data fields in each
161 node data element follows the bit order of the IOAM-Trace-Type
162 field (see section 4.4.1 of [I-D.ietf-ippm-ioam-data]). The last
163 node data element in this list is the node data of the first IOAM
164 trace capable node in the path.
166 In an IOAM domain, the STAMP Session-Sender and the STAMP Session-
167 Reflector MAY be configured as the IOAM encapsulating node and the
168 IOAM decapsulating node. The STAMP Session-Sender (i.e. the IOAM
169 encapsulating node) generates the test packet with the IOAM Tracing
170 Data TLV. For applying the IOAM Trace-Option functionalities to the
171 Session-Sender test packet, the Session-Sender must inserts the
172 "trace option header" and allocate an node-data-list array
173 [I-D.ietf-ippm-ioam-data] into "option data" fields of Hop-by-Hop
174 Options header in IPv6 packets [I-D.ietf-ippm-ioam-ipv6-options], and
175 sets the corresponding bits in the IOAM-Trace-Type. Also, the STAMP
176 Session-Sender allocates a node-data-copied-list array in the
177 optional IOAM-Tracing-Data TLV to store OAM data retrieved from every
178 IOAM transit node along the Session-Sender test packet's delivery
179 path.
181 When the STAMP Session-Reflector (i.e. the IOAM decapsulating node)
182 received the STAMP Session-Sender test packet with the IOAM-Tracing-
183 Data TLV, it MUST copy the node-data-list array into the node-data-
184 copied-list array carried in the Session-Reflector test packet before
185 transmission and MUST remove the IOAM-Data-Fields. Hence, carrying
186 IOAM-Tracing-Data TLV in STAMP test packets enables OAM data
187 collection and measurement at every node and link.
189 Also the STAMP Session-Reflector MAY be configured as IOAM
190 encapsulating node to apply the IOAM Trace-Option functionalities to
191 the Session-Reflector test packet. Hence, OAM data collection and
192 measurement can be also enabled at every node and link along the
193 Session-Reflector test packet's backward delivery path. When the
194 reflected packet arrives at the Session-Sender, it can be either
195 locally processed or sent to the centralized controller.
197 3.2. Forward HbH Delay TLV
199 STAMP Session-Sender MAY place the Forward HbH Delay TLV in Session-
200 Sender test packets to record the ingress timestamp and the egress
201 timestamp at every intermediate nodes along the Session-Sender test
202 packet's forward path. The Session-Sender MUST set the Length value
203 according to the number of explicitly listed intermediate nodes in
204 the forward path and the timestamp formats. There are several
205 methods to synchronize the clock, e.g., Network Time Protocol (NTP)
206 [RFC5905] and IEEE 1588v2 Precision Time Protocol (PTP)
207 [IEEE.1588.2008]. For example, if a 64-bit timestamp format defined
208 in NTP is used, the Length value MUST be set as a multiple of 16
209 octets. The Timestamp Tuple list [1..n] fields MUST be set to zero
210 upon Session-Sender test packets transmission.
212 The Forward HbH Delay TLV has the following format:
214 0 1 2 3
215 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
216 +-------------------------------+---------------+---------------+
217 | Forward HbH Delay Type | Length | Node Left |
218 +-------------------------------+---------------+---------------+
219 | |
220 | Timestamp Tuple list [1] |
221 | |
222 | |
223 +---------------------------------------------------------------+
224 ~ ... ~
225 +---------------------------------------------------------------+
226 | |
227 | Timestamp Tuple list [n] |
228 | |
229 | |
230 +---------------------------------------------------------------+
232 Fig. 2 Forward HbH Delay TLV Format
234 where fields are defined as the following:
236 o Forward HbH Delay Type: To be assigned by IANA.
238 o Length: A 8-bit field that indicates the length of the value
239 portion in octets and MUST be a multiple of 16 octets according to
240 the number of explicitly listed intermediate nodes in the forward
241 path.
243 o Node Left: A 8-bit unsigned integer, which indicates the number of
244 intermediate nodes remaining. That is, number of explicitly
245 listed intermediate nodes still to be visited before reaching the
246 destination node in the forward path. The Node Left field is set
247 to n-1, where n is the number of intermediate nodes.
249 o Timestamp Tuple list [1..n]: A variable-length field, which record
250 the timestamp when the Session-Sender test packet is received at
251 the ingress of the n-th intermediate node and the timestamp when
252 the Session-Sender test packet is sent at egress of the n-th
253 intermediate node. For example, if a 64-bit timestamp format
254 defined in NTP is used, the length of each Timestamp Tuple
255 (ingress timestamp [n], egress timestamp [n]) must be 16 octets.
256 The Timestamp Tuple list is encoded starting from the last
257 intermediate node which is explicitly listed. That is, the first
258 element of the Timestamp Tuple list [1] records the timestamps
259 when the Session-Sender test packet received and forwarded at the
260 last intermediate node of a explicit path, the second element
261 records the penultimate Timestamp Tuple when the Session-Sender
262 test packet received and forwarded at the penultimate intermediate
263 node of a explicit path, and so on.
265 In the following reference topology, Node N1, N2, N3, N4 and N5 are
266 SRv6 capable nodes. Node N1 is the STAMP Session-Sender and Node N5
267 is the STAMP Session-Reflector. T1 is the Timestamp taken by the
268 Session-Sender (i.e. N1) at the start of transmitting the test
269 packet. T2 is the Receive Timestamp when the test packet was
270 received by the Session-Reflector (i.e. N5). T3 is the Timestamp
271 taken by the Session-Reflector at the start of transmitting the test
272 packet. T4 is the Receive Timestamp when the test packet was
273 received by the Session-Sender. Timestamp tuples (t1,t2), (t3,t4)
274 and (t5,t6) are the timestamps when the test packet received and
275 transmitted by sequence of intermediate nodes in the forward path.
276 Timestamp Tuples (t7,t8), (t9,t10) and (t11,t12) are the timestamps
277 when the test packet received and transmitted by sequence of
278 intermediate nodes in the backward path.
280 ====== ====== ====== ====== ======
281 | | T1--->t1 | | t2--->t3 | | t4--->t5 | | t6--->T2| |
282 | N1 |==========| N2 |==========| N3 |==========| N4 |=========| N5 |
283 | | T4<---t12| |t11<---t10| | t9<---t8 | | t7<---T3| |
284 ====== ====== ====== ====== ======
286 Fig. 3 Reference Topology
288 The STAMP Session-Sender (i.e. Node N1) generates the STAMP test
289 packet with the Forward HbH Delay TLV. When an intermediate node
290 receives the STAMP test packet, the node punts the packet to control
291 plane and fills the ingress timestamp [n] filed in the Timestamp
292 Tuple list [n]. Then the time taken by the intermediate node
293 transmitting the test packet is recorded in to egress timestamp [n]
294 field. The mechanism of timestamping and punting packet to control
295 plane is outside the scope of this specification.
297 When the STAMP Session-Reflector received the test packet with the
298 Forward HbH Delay TLV, it MUST copy the Forward HbH Delay TLV into
299 the Session-Reflector test packet before its transmission. Using
300 Forward HbH Delay TLV in STAMP testing enables delay measurement per
301 link in the forward path.
303 3.3. Backward HbH Delay TLV
305 STAMP Session-Sender MAY place the Backward HbH Delay TLV in Session-
306 Sender test packets to record the ingress timestamp and egress
307 timestamp when Session-Reflector test packets are received and sent
308 at every intermediate nodes in the backward path. The Session-Sender
309 MUST set the Length value according to the number of explicitly
310 listed intermediate nodes in the backward path and the timestamp
311 formats. There are several methods to synchronize the clock, e.g.,
312 Network Time Protocol (NTP) [RFC5905] and IEEE 1588v2 Precision Time
313 Protocol (PTP) [IEEE.1588.2008]. For example, if a 64-bit timestamp
314 format defined in NTP is used, the Length value MUST be set as a
315 multiple of 16 octets. The Timestamp Tuple list [1..n] fields MUST
316 be set to zero upon Session-Sender test packets transmission and
317 ignored upon receipt.
319 The Backward HbH Delay TLV has the following format:
321 0 1 2 3
322 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
323 +-------------------------------+---------------+---------------+
324 | Backward HbH Delay Type | Length | Node Left |
325 +-------------------------------+---------------+---------------+
326 | |
327 | Timestamp Tuple list [1] |
328 | |
329 | |
330 +---------------------------------------------------------------+
331 ~ ... ~
332 +---------------------------------------------------------------+
333 | |
334 | Timestamp Tuple list [n] |
335 | |
336 | |
337 +---------------------------------------------------------------+
339 Fig. 4 Backward HbH Delay TLV Format
341 where fields are defined as the following:
343 o Backward HbH Delay Type: To be assigned by IANA.
345 o Length: A 8-bit field that indicates the length of the value
346 portion in octets and will be a multiple of 16 octets dependent on
347 the number of explicitly listed intermediate nodes in the backward
348 path.
350 o Node Left: A 8-bit unsigned integer, which indicates the number of
351 intermediate nodes remaining. That is, number of explicitly
352 listed intermediate nodes still to be visited before reaching the
353 destination node in the backward path. The Node Left field is set
354 to n-1, where n is the number of intermediate nodes.
356 o Timestamp Tuple list [1..n]: A variable-length field, which record
357 the timestamp when the reflected test packet is received at the
358 ingress of the n-th intermediate node and the timestamp when the
359 reflected test packet is sent at egress of the n-th intermediate
360 node. For example, if a 64-bit timestamp format defined in NTP is
361 used, the length of each Timestamp tuple (ingress timestamp [n],
362 egress timestamp [n]) must be 16 octets. The Timestamp Tuple list
363 is encoded starting from the last intermediate node which is
364 explicitly listed. That is, the first element of the Timestamp
365 Tuple list [1] records the timestamps when the reflected test
366 packet received and forwarded at the last intermediate node of a
367 explicit path, the second element records the penultimate
368 Timestamp Tuple when the reflected test packet received and
369 forwarded at the penultimate intermediate node of a explicit path,
370 and so on.
372 When the STAMP Session-Reflector received the Session-Sender test
373 packet with the Backward HbH Delay TLV, it MUST copy the Backward HbH
374 Delay TLV into the Session-Reflector test packet.
376 When an intermediate node receives the reflected test packet, the
377 node sends the packet to control plane and fills the ingress
378 timestamp [n] filed of Backward HbH Delay TLV. Then the time taken
379 by the intermediate node transmitting the test packet is recorded in
380 to egress timestamp [n] field of Backward HbH Delay TLV. Using
381 Backward HbH Delay TLV in STAMP testing enables delay measurement per
382 link in the backward path.
384 3.4. HbH Direct Loss TLV
386 STAMP Session-Sender MAY place the HbH Direct Loss TLV in Session-
387 Sender test packets to record the number of packets that form a
388 specific data flow received at and transmitted by every intermediate
389 nodes along the forward path. The Session-Sender MUST set the Length
390 value according to the number of explicitly listed intermediate nodes
391 in the forward path. A Counter Tuple is composed of a 64-bit Receive
392 Counter field and a 64-bit Transmit Counter field. The Counter Tuple
393 list [1..n] fields MUST be set to zero upon Session-Sender test
394 packets transmission.
396 The HbH Direct Loss TLV has the following format:
398 0 1 2 3
399 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
400 +-------------------------------+---------------+---------------+
401 | HbH Direct Loss Type | Length | Node Left |
402 +-------------------------------+---------------+---------------+
403 | |
404 | Counter Tuple list [1] |
405 | |
406 | |
407 +---------------------------------------------------------------+
408 ~ ... ~
409 +---------------------------------------------------------------+
410 | |
411 | Counter Tuple list [n] |
412 | |
413 | |
414 +---------------------------------------------------------------+
416 Fig. 5 HbH Direct Loss TLV Format
418 where fields are defined as the following:
420 o HbH Direct Loss Type: To be assigned by IANA.
422 o Length: A 8-bit field that indicates the length of the value
423 portion in octets and will be a multiple of 16 octets dependent on
424 the number of explicitly listed intermediate nodes in the forward
425 path.
427 o Node Left: A 8-bit unsigned integer, which indicates the number of
428 intermediate nodes remaining. That is, number of explicitly
429 listed intermediate nodes still to be visited before reaching the
430 destination node in the forward path. The Node Left field is set
431 to n-1, where n is the number of intermediate nodes.
433 o Counter Tuple list [1..n]: A variable-length field, which record
434 the Receive Counter and the Transmit Counter when the data packet
435 is received at and transmitted by the n-th intermediate node. The
436 Counter Tuple list is encoded starting from the last intermediate
437 node which is explicitly listed. That is, the first element of
438 the Counter Tuple list [1] records the Receive Counter and the
439 Transmit Counter when the data packet is received at and
440 transmitted by the last intermediate node of a explicit path, the
441 second element records the penultimate Counter Tuple when the data
442 packet received and forwarded at the penultimate intermediate node
443 of a explicit path, and so on.
445 The STAMP Session-Sender generates the STAMP test packet with the HbH
446 Direct Loss TLV. When an intermediate node receives the STAMP test
447 packet, the node punts the packet to control plane and writes the
448 Receive Counter [n] and the Transmit Counter [n] at the Counter Tuple
449 list [n] in the Session-Sender test packet. The mechanism of punting
450 packet to control plane is outside the scope of this specification.
452 When the STAMP Session-Reflector received the test packet with the
453 HbH Direct Loss TLV, it MUST copy the HbH Direct Loss TLV into the
454 Session-Reflector test packet before its transmission. Using HbH
455 Direct Loss TLV in STAMP testing enables packet loss measurement per
456 node/link in the forward path.
458 3.5. HbH Bandwidth Utilization TLV
460 STAMP Session-Sender MAY place the HbH Bandwidth Utilization (BW
461 Utilization) TLV in Session-Sender test packets to record the ingress
462 and egress BW Utilization at every intermediate nodes along the
463 forward path. The Session-Sender MUST set the Length value according
464 to the number of explicitly listed intermediate nodes in the forward
465 path. A BW Utilization Tuple is composed of a 32-bit ingress BW
466 Utilization field and a 32-bit egress BW Utilization field. The BW
467 Utilization Tuple list [1..n] fields MUST be set to zero upon
468 Session-Sender test packets transmission.
470 The HbH Bandwidth Utilization TLV has the following format:
472 0 1 2 3
473 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
474 +-------------------------------+---------------+---------------+
475 | HbH BW Utilization Type | Length | Node Left |
476 +-------------------------------+---------------+---------------+
477 | BW Utilization Tuple list [1] |
478 | |
479 +---------------------------------------------------------------+
480 ~ ... ~
481 +---------------------------------------------------------------+
482 | BW Utilization Tuple list [n] |
483 | |
484 +---------------------------------------------------------------+
486 Fig. 6 HbH Bandwidth Utilization TLV Format
488 where fields are defined as the following:
490 o HbH BW Utilization Type: To be assigned by IANA.
492 o Length: A 8-bit field that indicates the length of the value
493 portion in octets and will be a multiple of 8 octets dependent on
494 the number of explicitly listed intermediate nodes in the forward
495 path.
497 o Node Left: A 8-bit unsigned integer, which indicates the number of
498 intermediate nodes remaining. That is, number of explicitly
499 listed intermediate nodes still to be visited before reaching the
500 destination node in the forward path. The Node Left field is set
501 to n-1, where n is the number of intermediate nodes.
503 o BW Utilization Tuple list [1..n]: A variable-length field, which
504 record the ingress and egress bandwidth utilization when the test
505 packet is received at and transmitted by the n-th intermediate
506 node. The BW Utilization Tuple list is encoded starting from the
507 last intermediate node which is explicitly listed. That is, the
508 first element of the BW Utilization Tuple list [1] records the
509 ingress and the egress bandwidth utilization when the test packet
510 is received at and transmitted by the last intermediate node of a
511 explicit path, the second element records the penultimate BW
512 Utilization Tuple when the test packet received at and transmitted
513 by the penultimate intermediate node of a explicit path, and so
514 on.
516 The STAMP Session-Sender generates the STAMP test packet with the HbH
517 BW Utilization TLV. When an intermediate node receives the STAMP
518 test packet, the node punts the packet to control plane and writes
519 the ingress and egress bandwidth utilization at the BW Utilization
520 Tuple list [n] in the Session-Sender test packet. The mechanism of
521 punting packet to control plane is outside the scope of this
522 specification.
524 When the STAMP Session-Reflector received the test packet with the
525 HbH BW Utilization TLV, it MUST copy the HbH BW Utilization TLV into
526 the Session-Reflector test packet before its transmission. The HbH
527 BW Utilization TLV carried in STAMP test packet is usable to detect
528 and troubleshoot the link congestion in the forward path.
530 3.6. HbH Timestamp Information TLV
532 STAMP Session-Sender MAY place the HbH Timestamp Information TLV in
533 Session-Sender test packets to record the ingress and egress
534 Timestamp Information at every intermediate nodes along the forward
535 path. The Timestamp Information includes the source of clock
536 synchronization and the method of timestamp obtainment. There are
537 several types of clock synchronization source, e.g., NTP, PTP. The
538 method of timestamp obtainment may be from control plane (e.g. NTP)
539 or from data plane (e.g. PTP).
541 A Timestamp Info Tuple is composed of a 8-bit ingress clock source
542 field, a 8-bit ingress timestamp obtainment field, a 8-bit egress
543 clock source field, and a 8-bit egress timestamp obtainment field.
544 The Session-Sender MUST set the Length value according to the number
545 of explicitly listed intermediate nodes in the forward path. The
546 Timestamp Info Tuple list [1..n] fields MUST be set to zero upon
547 Session-Sender test packets transmission.
549 The HbH Timestamp Information TLV has the following format:
551 0 1 2 3
552 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
553 +-------------------------------+---------------+---------------+
554 | HbH Timestamp Info Type | Length | Node Left |
555 +-------------------------------+---------------+---------------+
556 | Timestamp Info Tuple list [1] |
557 +---------------------------------------------------------------+
558 ~ ... ~
559 +---------------------------------------------------------------+
560 | Timestamp Info Tuple list [n] |
561 +---------------------------------------------------------------+
563 Fig. 6 HbH Timestamp Information TLV Format
565 where fields are defined as the following:
567 o HbH Timestamp Info Type: To be assigned by IANA.
569 o Length: A 8-bit field that indicates the length of the value
570 portion in octets and will be a multiple of 4 octets dependent on
571 the number of explicitly listed intermediate nodes in the forward
572 path.
574 o Node Left: A 8-bit unsigned integer, which indicates the number of
575 intermediate nodes remaining. That is, number of explicitly
576 listed intermediate nodes still to be visited before reaching the
577 destination node in the forward path. The Node Left field is set
578 to n-1, where n is the number of intermediate nodes.
580 o Timestamp Info Tuple list [1..n]: A variable-length field, which
581 record the source of clock synchronization and the method of
582 timestamp obtainment at the ingress and egress when the test
583 packet is received at and transmitted by the n-th intermediate
584 node. The Timestamp Info Tuple list is encoded starting from the
585 last intermediate node which is explicitly listed. That is, the
586 first element of the Timestamp Info Tuple list [1] records the
587 source of clock synchronization and the method of timestamp
588 obtainment at the ingress and egress when the test packet is
589 received at and transmitted by the last intermediate node of a
590 explicit path, the second element records the penultimate
591 Timestamp Info Tuple when the test packet received at and
592 transmitted by the penultimate intermediate node of a explicit
593 path, and so on.
595 The STAMP Session-Sender generates the STAMP test packet with the HbH
596 Timestamp Information TLV. When an intermediate node receives the
597 STAMP test packet, the node punts the packet to control plane and
598 writes the source of clock synchronization and the method of
599 timestamp obtainment at the Timestamp Info Tuple list [n] in the
600 Session-Sender test packet. The mechanism of punting packet to
601 control plane is outside the scope of this specification.
603 When the STAMP Session-Reflector received the test packet with the
604 HbH Timestamp Information TLV, it MUST copy the HbH Timestamp
605 Information TLV into the Session-Reflector test packet before its
606 transmission. The HbH Timestamp Information TLV carried in STAMP
607 test packet is usable to query timestamp information from every nodes
608 in the forward path.
610 Note that the source of clock synchronization, NTP or PTP, is part of
611 configuration of the Session-Sender/Reflector or a particular test
612 session [RFC8762]. This draft recommends every intermediate nodes to
613 be configured to use the same source of clock synchronization.
615 3.7. HbH Interface Errors TLV
617 STAMP Session-Sender MAY place the HbH Interface Errors TLV in
618 Session-Sender test packets to record the errors detected on the
619 interface of every intermediate node used to receive the packet along
620 the forward path. The record of interface errors indicates the
621 quality of the interfaces along the forward path and is helpful to
622 analyze the performance degrades associated with the flow.
624 A Interface Errors is a 32 bits unsigned integer field. This field
625 records the Bit Error Rate (BER) or number of packet drop due to
626 Cyclic Redundancy Check (CRC) errors. The Session-Sender MUST set
627 the Length value according to the number of explicitly listed
628 intermediate nodes in the forward path. The Interface Errors list
629 [1..n] fields MUST be set to zero upon Session-Sender test packets
630 transmission.
632 The HbH Timestamp Information TLV has the following format:
634 0 1 2 3
635 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
636 +-------------------------------+---------------+---------------+
637 | HbH Interface Errors Type | Length | Node Left |
638 +-------------------------------+---------------+---------------+
639 | Interface Errors list [1] |
640 +---------------------------------------------------------------+
641 ~ ... ~
642 +---------------------------------------------------------------+
643 | Interface Errors list [n] |
644 +---------------------------------------------------------------+
646 Fig. 6 HbH Timestamp Information TLV Format
648 where fields are defined as the following:
650 o HbH Interface Errors Type: To be assigned by IANA.
652 o Length: A 8-bit field that indicates the length of the value
653 portion in octets and will be a multiple of 4 octets dependent on
654 the number of explicitly listed intermediate nodes in the forward
655 path.
657 o Node Left: A 8-bit unsigned integer, which indicates the number of
658 intermediate nodes remaining. That is, number of explicitly
659 listed intermediate nodes still to be visited before reaching the
660 destination node in the forward path. The Node Left field is set
661 to n-1, where n is the number of intermediate nodes.
663 o Interface Errors list [1..n]: A variable-length field, which
664 record the errors detected on the interface of the n-th
665 intermediate node used to receive the packet along the forward
666 path. The Interface Errors list is encoded starting from the last
667 intermediate node which is explicitly listed. That is, the first
668 element of the Interface Errors list [1] records the interface
669 errors when the test packet is received at the last intermediate
670 node of a explicit path, the second element records the
671 penultimate interface errors when the test packet received at the
672 penultimate intermediate node of a explicit path, and so on.
674 The STAMP Session-Sender generates the STAMP test packet with the HbH
675 Interface Errors TLV. When an intermediate node receives the STAMP
676 test packet, the node punts the packet to control plane and writes
677 the errors at the Interface Errors list [n] in the Session-Sender
678 test packet. The mechanism of punting packet to control plane is
679 outside the scope of this specification.
681 When the STAMP Session-Reflector received the test packet with the
682 HbH Interface Errors TLV, it MUST copy the HbH Interface Errors TLV
683 into the Session-Reflector test packet before its transmission. The
684 HbH Interface Errors TLV carried in STAMP test packet is usable to
685 detect interface errors from every intermediate nodes along the
686 forward path.
688 4. IANA Considerations
690 IANA is requested to allocate values for the following TLV Type from
691 the "STAMP TLV Type" registry [RFC8972].
693 +------------+-------------------------------+---------------+
694 | Code Point | Description | Reference |
695 +------------+-------------------------------+---------------+
696 | TBA1 | IOAM Tracing Data TLV | This document |
697 | TBA2 | Forward HbH Delay TLV | This document |
698 | TBA3 | Backward HbH Delay TLV | This document |
699 | TBA4 | HbH Direct Loss TLV | This document |
700 | TBA5 | HbH BW Utilization TLV | This document |
701 | TBA6 | HbH Timestamp Information TLV | This document |
702 | TBA7 | HbH Interface Errors TLV | This document |
703 +------------+-------------------------------+---------------+
705 5. Security Considerations
707 This document extensions new optional TLVs to STAMP. It does not
708 introduce any new security risks to STAMP.
710 6. Acknowledgements
712 The authors would like to thank Giuseppe Fioccola for the reviews and
713 comments.
715 7. References
717 7.1. Normative References
719 [I-D.ietf-ippm-ioam-data]
720 "Data Fields for In-situ OAM",
721 .
724 [I-D.ietf-ippm-ioam-ipv6-options]
725 "In-situ OAM IPv6 Options",
726 .
729 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
730 Requirement Levels", BCP 14, RFC 2119,
731 DOI 10.17487/RFC2119, March 1997,
732 .
734 [RFC8762] "Simple Two-Way Active Measurement Protocol",
735 .
737 [RFC8972] "Simple Two-way Active Measurement Protocol Optional
738 Extensions", .
740 7.2. Informative References
742 [IEEE.1588.2008]
743 "IEEE Standard for a Precision Clock Synchronization
744 Protocol for Networked Measurement and Control Systems",
745 .
747 [RFC5905] "Network Time Protocol Version 4: Protocol and Algorithms
748 Specification", .
750 Authors' Addresses
752 Yali Wang
753 Huawei
754 156 Beijing Rd., Haidian District
755 Beijing
756 China
758 Email: wangyali11@huawei.com
760 Tianran Zhou
761 Huawei
762 156 Beijing Rd., Haidian District
763 Beijing
764 China
766 Email: zhoutianran@huawei.com
768 Hongwei Yang
769 China Mobile
770 Xibianmen Inner St, 53, Xicheng District
771 Beijing
772 China
774 Email: yanghongwei@chinamobile.com
775 Chang Liu
776 China Unicom
777 Beijing
778 China
780 Email: liuc131@chinaunicom.cn