idnits 2.17.1
draft-wang-ippm-stamp-hbh-extensions-01.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (October 27, 2020) is 1277 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
-- Looks like a reference, but probably isn't: '0' on line 129
-- Looks like a reference, but probably isn't: '1' on line 354
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: April 30, 2021 October 27, 2020
7 Simple Two-way Active Measurement Protocol Extensions for Hop-by-Hop OAM
8 Data Collection
9 draft-wang-ippm-stamp-hbh-extensions-01
11 Abstract
13 This document defines optional TLVs which are carried in Simple Two-
14 way Active Measurement Protocol (STAMP) test packets to enhance the
15 STAMP base functions. Such extensions to STAMP enable OAM data
16 measurement and collection at every node and link along a STAMP test
17 packet's delivery path.
19 Requirements Language
21 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
22 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
23 document are to be interpreted as described in RFC 2119 [RFC2119].
25 Status of This Memo
27 This Internet-Draft is submitted in full conformance with the
28 provisions of BCP 78 and BCP 79.
30 Internet-Drafts are working documents of the Internet Engineering
31 Task Force (IETF). Note that other groups may also distribute
32 working documents as Internet-Drafts. The list of current Internet-
33 Drafts is at https://datatracker.ietf.org/drafts/current/.
35 Internet-Drafts are draft documents valid for a maximum of six months
36 and may be updated, replaced, or obsoleted by other documents at any
37 time. It is inappropriate to use Internet-Drafts as reference
38 material or to cite them other than as "work in progress."
40 This Internet-Draft will expire on April 30, 2021.
42 Copyright Notice
44 Copyright (c) 2020 IETF Trust and the persons identified as the
45 document authors. All rights reserved.
47 This document is subject to BCP 78 and the IETF Trust's Legal
48 Provisions Relating to IETF Documents
49 (https://trustee.ietf.org/license-info) in effect on the date of
50 publication of this document. Please review these documents
51 carefully, as they describe your rights and restrictions with respect
52 to this document. Code Components extracted from this document must
53 include Simplified BSD License text as described in Section 4.e of
54 the Trust Legal Provisions and are provided without warranty as
55 described in the Simplified BSD License.
57 Table of Contents
59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
61 3. TLV Extensions to STAMP . . . . . . . . . . . . . . . . . . . 3
62 3.1. IOAM Tracing Data TLV . . . . . . . . . . . . . . . . . . 3
63 3.2. Forward HbH Delay TLV . . . . . . . . . . . . . . . . . . 4
64 3.3. Backward HbH Delay TLV . . . . . . . . . . . . . . . . . 7
65 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
66 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
67 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
68 6.1. Normative References . . . . . . . . . . . . . . . . . . 9
69 6.2. Informative References . . . . . . . . . . . . . . . . . 9
70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
72 1. Introduction
74 Simple Two-way Active Measurement Protocol (STAMP) [RFC8762] enables
75 the measurement of both one-way and round-trip performance metrics,
76 such as delay, delay variation, and packet loss. In the STAMP
77 session, the bidirectional packet flow is transmited between STAMP
78 Session-Sender and STAMP Session-Reflector. The STAMP Session-
79 Reflector receives test packets transmited from Session-Sender and
80 acts according to the configuration. However, the performance of
81 intermediate nodes and links that STAMP test packets traverse are
82 invisible. In additon, the STAMP instance must be configured at
83 every intermediate node to measure the performance per node and link
84 that test packets traverse, which increases the complexity of OAM in
85 large-scale networks.
87 STAMP Extensions have defined several optional TLVs to enhance the
88 STAMP base functions. These optional TLVs are defined as updates of
89 the STAMP Optional Extensions [I-D.ietf-ippm-stamp-option-tlv]. This
90 document extents optional TLVs to STAMP, which enable performance
91 measurement at every intermediate node and link along a STAMP test
92 packet's delivery path, such as measurement of delay, delay
93 variation, packet loss, and record of route information. The
94 following sections describe the use of TLVs for STAMP that extend
95 STAMP capability beyond its base specification.
97 2. Terminology
99 Following are abbreviations used in this document:
101 STAMP: Simple Two-way Active Measurement Protocol.
103 IOAM: In-situ OAM.
105 HbH: Hop-by-Hop.
107 3. TLV Extensions to STAMP
109 3.1. IOAM Tracing Data TLV
111 STAMP Session-Sender MAY place the IOAM Tracing Data TLV in Session-
112 Sender test packets to record the IOAM tracing data at every IOAM
113 capable node along the Session-Sender test packet's forward-delivery
114 path. As STAMP uses symmetrical packets, the Session-Sender MUST set
115 the Length value as a multiple of 4 octets according to the number of
116 nodes and the IOAM-Trace-Type (i.e. a 24-bit identifier which
117 specifies which data types are used in the node data list
118 [I-D.ietf-ippm-ioam-data]). And the node-data-copied-list fields
119 MUST be set to zero upon Session-Sender test packets transmission and
120 ignored upon receipt.
122 The IOAM Tracing Data TLV has the following format:
124 0 1 2 3
125 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
126 +-------------------------------+-------------------------------+
127 | IOAM-Tracing-Data Type | Length |
128 +---------------------------------------------------------------+
129 | node data copied list [0] |
130 +---------------------------------------------------------------+
131 | node data copied list [1] |
132 +---------------------------------------------------------------+
133 ~ ... ~
134 +---------------------------------------------------------------+
135 | node data copied list [n] |
136 +---------------------------------------------------------------+
138 Fig. 1 IOAM Tracing Data TLV Format
140 where fields are defined as the following:
142 o IOAM-Tracing-Data Type: To be assigned by IANA.
144 o Length: A 2-octet field that indicates the length of the value
145 field in octets and equal to a multiple of 4 octets dependent on
146 the number of nodes and IOAM-Trace-Type bits.
148 o node data copied list [0..n]: A variable-length field, which
149 record the copied content of each node data element determined by
150 the IOAM-Trace-Type. The order of packing the data fields in each
151 node data element follows the bit order of the IOAM-Trace-Type
152 field (see section 4.4.1 of [I-D.ietf-ippm-ioam-data]). The last
153 node data element in this list is the node data of the first IOAM
154 trace capable node in the path.
156 In an IOAM domain, the STAMP Session-Sender and the STAMP Session-
157 Reflector MAY be configured as the IOAM encapsulating node and the
158 IOAM decapsulating node. The STAMP Session-Sender (i.e. the IOAM
159 encapsulating node) generates the test packet with the IOAM Tracing
160 Data TLV. For applying the IOAM Trace-Option functionalities to the
161 Session-Sender test packet, the Session-Sender must inserts the
162 "trace option header" and allocate an node-data-list array
163 [I-D.ietf-ippm-ioam-data] into "option data" fields of Hop-by-Hop
164 Options header in IPv6 packets [I-D.ietf-ippm-ioam-ipv6-options], and
165 sets the corresponding bits in the IOAM-Trace-Type. Also, the STAMP
166 Session-Sender allocates a node-data-copied-list array in the
167 optional IOAM Tracing Data TLV to store OAM data retrieved from every
168 IOAM transit node along the Session-Sender test packet's delivery
169 path.
171 When the STAMP Session-Reflector (i.e. the IOAM decapsulating node)
172 received the STAMP Session-Sender test packet with the IOAM-Tracing-
173 Data TLV, it MUST copy the node-data-list array into the node-data-
174 copied-list array carried in the Session-Reflector test packet before
175 transmission and MUST remove the IOAM-Data-Fields. Hence, carrying
176 IOAM-Tracing-Data TLV in STAMP test packets enables OAM data
177 collection and measurement at every node and link.
179 Also the STAMP Session-Reflector MAY be configured as IOAM
180 encapsulating node to apply the IOAM Trace-Option functionalities to
181 the Session-Reflector test packet. Hence, OAM data collection and
182 measurement can be also enabled at every node and link along the
183 Session-Reflector test packet's backward delivery path. When the
184 reflected packet arrives at the Session-Sender, it can be either
185 locally processed or sent to the centralized controller.
187 3.2. Forward HbH Delay TLV
189 STAMP Session-Sender MAY place the Forward HbH Delay TLV in Session-
190 Sender test packets to record the ingress timestamp and the egress
191 timestamp at every intermediate nodes along the Session-Sender test
192 packet's forward path. The Session-Sender MUST set the Length value
193 according to the number of explicitly listed intermediate nodes in
194 the forward path and the timestamp formats. There are several
195 methods to synchronize the clock, e.g., Network Time Protocol (NTP)
196 [RFC5905]. For example, if a 64-bit timestamp format defined in NTP
197 is used, the Length value MUST be set as a multiple of 8 octets. The
198 Timestamp Tuple list [1..n] fields MUST be set to zero upon Session-
199 Sender test packets transmission and ignored upon receipt.
201 The Forward HbH Delay TLV has the following format:
203 0 1 2 3
204 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
205 +-------------------------------+---------------+---------------+
206 | Forward HbH Delay Type | Length | Node Left |
207 +-------------------------------+---------------+---------------+
208 | |
209 | Timestamp Tuple list [1] |
210 | |
211 | |
212 +---------------------------------------------------------------+
213 ~ ... ~
214 +---------------------------------------------------------------+
215 | |
216 | Timestamp Tuple list [n] |
217 | |
218 | |
219 +---------------------------------------------------------------+
221 Fig. 2 Forward HbH Delay TLV Format
223 where fields are defined as the following:
225 o Forward HbH Delay Type: To be assigned by IANA.
227 o Length: A 8-bit field that indicates the length of the value
228 portion in octets and MUST be a multiple of 8 octets according to
229 the number of explicitly listed intermediate nodes in the forward
230 path.
232 o Node Left: A 8-bit unsigned integer, which indicates the number of
233 intermediate nodes remaining. That is, number of exlicitly listed
234 intermediate nodes still to be visited before reaching the
235 destination node in the forward path. The Node Left field is set
236 to n-1, where n is the number of intermediate nodes.
238 o Timestamp Tuple list [1..n]: A variable-length field, which record
239 the timestamp when the Session-Sender test packet is received at
240 the ingress of the n-th intermediate node Ingress Timestamp [n]
241 and the timestamp when the Session-Sender test packet is sent at
242 egress of the n-th intermediate node Engress Timestamp [n]. For
243 example, if a 64-bit timestamp format defined in NTP is used, the
244 length of each Timestamp tuple (Ingress Timestamp [n], Engress
245 Timestamp [n]) must be 16 octets. The Timestamp Tuple list is
246 encoded starting from the last intermediate node which is
247 exlicitly listed. That is, the first element of the Timestamp
248 Tuple list [1] records the timestamps when the Session-Sender test
249 packet received and forwarded at the last intermediate node of a
250 explicit path, the second element records the penultimate
251 Timestamp Tuple when the Session-Sender test packet received and
252 forwarded at the penultimate intermediate node of a explicit path,
253 and so on.
255 In the following reference topology, Node N1, N2, N3, N4 and N5 are
256 SRv6 capable nodes. Node N1 is the STAMP Session-Sender and Node N5
257 is the STAMP Session-Reflector. T1 is the Timestamp taken by the
258 Session-Sender (i.e. N1) at the start of transmitting the test
259 packet. T2 is the Receive Timestamp when the test packet was
260 received by the Session-Reflector (i.e. N5). T3 is the Timestamp
261 taken by the Session-Reflector at the start of transmitting the test
262 packet. T4 is the Receive Timestamp when the test packet was
263 received by the Session-Sender. Timestamp tuples (t1,t2), (t3,t4)
264 and (t5,t6) are the timestamps when the test packet received and
265 transmited by sequence of intermediate nodes in the forward path.
266 Timestamp Tuples (t7,t8), (t9,t10) and (t11,t12) are the timestamps
267 when the test packet received and transmited by sequence of
268 intermediate nodes in the backward path.
270 ====== ====== ====== ====== ======
271 | | T1--->t1 | | t2--->t3 | | t4--->t5 | | t6--->T2| |
272 | N1 |==========| N2 |==========| N3 |==========| N4 |=========| N5 |
273 | | T4<---t12| |t11<---t10| | t9<---t8 | | t7<---T3| |
274 ====== ====== ====== ====== ======
276 Fig. 3 Reference Topology
278 The STAMP Session-Sender (i.e. Node N1) generates the STAMP test
279 packet with the Forward HbH Delay TLV. When an intermediate node
280 receives the STAMP test packet, the node punts the packet to control
281 plane and fills the Ingress Timestamp [n] filed in the Timestamp
282 Tuple list [n]. Then the time taken by the intermediate node
283 transmitting the test packet is recorded in to Engress Timestamp [n]
284 field. The mechanism of timestamping and punting packet to control
285 plane is outside the scope of this specification.
287 When the STAMP Session-Reflector received the test packet with the
288 Forward HbH Delay TLV, it MUST copy the Forward HbH Delay TLV into
289 the Session-Reflector test packet before its transmission. Using
290 Forward HbH Delay TLV in STAMP testing enables delay measurement per
291 link in the forward path.
293 3.3. Backward HbH Delay TLV
295 STAMP Session-Sender MAY place the Backward HbH Delay TLV in Session-
296 Sender test packets to record the ingress timestamp and egress
297 timestamp when Session-Reflector test packets are received and sent
298 at every intermediate nodes in the backward path. The Session-Sender
299 MUST set the Length value according to the number of explicitly
300 listed intermediate nodes in the backward path and the timestamp
301 formats. There are several methods to synchronize the clock, e.g.,
302 Network Time Protocol (NTP) [RFC5905]. For example, if a 64-bit
303 timestamp format defined in NTP is used, the Length value MUST be set
304 as a multiple of 8 octets. The Timestamp Tuple list [1..n] fields
305 MUST be set to zero upon Session-Sender test packets transmission and
306 ignored upon receipt.
308 The Backward HbH Delay TLV has the following format:
310 0 1 2 3
311 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
312 +-------------------------------+---------------+---------------+
313 | Backward HbH Delay Type | Length | Node Left |
314 +-------------------------------+---------------+---------------+
315 | |
316 | Timestamp Tuple list [1] |
317 | |
318 | |
319 +---------------------------------------------------------------+
320 ~ ... ~
321 +---------------------------------------------------------------+
322 | |
323 | Timestamp Tuple list [n] |
324 | |
325 | |
326 +---------------------------------------------------------------+
328 Fig. 4 Backward HbH Delay TLV Format
330 where fields are defined as the following:
332 o Backward HbH Delay Type: To be assigned by IANA.
334 o Length: A 8-bit field that indicates the length of the value
335 portion in octets and will be a multiple of 8 octets dependent on
336 the number of explicitly listed intermediate nodes in the backward
337 path.
339 o Node Left: A 8-bit unsigned integer, which indicates the number of
340 intermediate nodes remaining. That is, number of exlicitly listed
341 intermediate nodes still to be visited before reaching the
342 destination node in the backward path. The Node Left field is set
343 to n-1, where n is the number of intermediate nodes.
345 o Timestamp Tuple list [1..n]: A variable-length field, which record
346 the timestamp when the reflected test packet is received at the
347 ingress of the n-th intermediate node and the timestamp when the
348 reflected test packet is sent at egress of the n-th intermediate
349 node. For example, if a 64-bit timestamp format defined in NTP is
350 used, the length of each Timestamp tuple (Ingress Timestamp [n],
351 Engress Timestamp [n]) must be 16 octets. The Timestamp Tuple
352 list is encoded starting from the last intermediate node which is
353 exlicitly listed. That is, the first element of the Timestamp
354 Tuple list [1] records the timestamps when the reflected test
355 packet received and forwarded at the last intermediate node of a
356 explicit path, the second element records the penultimate
357 Timestamp Tuple when the reflected test packet received and
358 forwarded at the penultimate intermediate node of a explicit path,
359 and so on.
361 When the STAMP Session-Reflector received the Session-Sender test
362 packet with the Backward HbH Delay TLV, it MUST copy the Backward HbH
363 Delay TLV into the Session-Reflector test packet.
365 When an intermediate node receives the reflected test packet, the
366 node sends the packet to control plane and fills the Ingress
367 Timestamp [n] filed of Backward HbH Delay TLV. Then the time taken
368 by the intermediate node transmitting the test packet is recorded in
369 to Engress Timestamp [n] field of Backward HbH Delay TLV. Using
370 Backward HbH Delay TLV in STAMP testing enables delay measurement per
371 link in the backward path.
373 4. IANA Considerations
375 IANA is requested to allocate values for the following TLV Type from
376 the "STAMP TLV Type" registry [I-D.ietf-ippm-stamp-option-tlv].
378 +------------+------------------------+---------------+
379 | Code Point | Description | Reference |
380 +------------+------------------------+---------------+
381 | TBA1 | IOAM Tracing Data TLV | This document |
382 | TBA2 | Forward HBH Delay TLV | This document |
383 | TBA3 | Backward HBH Delay TLV | This document |
384 +------------+------------------------+---------------+
386 5. Security Considerations
388 This document extensions new optional TLVs to STAMP. It does not
389 introduce any new security risks to STAMP.
391 6. References
393 6.1. Normative References
395 [I-D.ietf-ippm-ioam-data]
396 "Data Fields for In-situ OAM",
397 .
400 [I-D.ietf-ippm-ioam-ipv6-options]
401 "In-situ OAM IPv6 Options",
402 .
405 [I-D.ietf-ippm-stamp-option-tlv]
406 "Simple Two-way Active Measurement Protocol Optional
407 Extensions", .
410 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
411 Requirement Levels", BCP 14, RFC 2119,
412 DOI 10.17487/RFC2119, March 1997,
413 .
415 [RFC8762] "Simple Two-Way Active Measurement Protocol",
416 .
418 6.2. Informative References
420 [RFC5905] "Network Time Protocol Version 4: Protocol and Algorithms
421 Specification", .
423 Authors' Addresses
425 Yali Wang
426 Huawei
427 156 Beiqing Rd., Haidian District
428 Beijing
429 China
431 Email: wangyali11@huawei.com
433 Tianran Zhou
434 Huawei
435 156 Beiqing Rd., Haidian District
436 Beijing
437 China
439 Email: zhoutianran@huawei.com