idnits 2.17.1
draft-wang-ippm-stamp-hbh-extensions-00.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (July 10, 2020) is 1379 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 355
-- Looks like a reference, but probably isn't: '1' on line 129
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: January 11, 2021 July 10, 2020
7 Simple Two-way Active Measurement Protocol Extensions for Hop-by-Hop OAM
8 Data Collection
9 draft-wang-ippm-stamp-hbh-extensions-00
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 collection at every node that STAMP test packets traverse.
18 Requirements Language
20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
21 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
22 document are to be interpreted as described in RFC 2119 [RFC2119].
24 Status of This Memo
26 This Internet-Draft is submitted in full conformance with the
27 provisions of BCP 78 and BCP 79.
29 Internet-Drafts are working documents of the Internet Engineering
30 Task Force (IETF). Note that other groups may also distribute
31 working documents as Internet-Drafts. The list of current Internet-
32 Drafts is at https://datatracker.ietf.org/drafts/current/.
34 Internet-Drafts are draft documents valid for a maximum of six months
35 and may be updated, replaced, or obsoleted by other documents at any
36 time. It is inappropriate to use Internet-Drafts as reference
37 material or to cite them other than as "work in progress."
39 This Internet-Draft will expire on January 11, 2021.
41 Copyright Notice
43 Copyright (c) 2020 IETF Trust and the persons identified as the
44 document authors. All rights reserved.
46 This document is subject to BCP 78 and the IETF Trust's Legal
47 Provisions Relating to IETF Documents
48 (https://trustee.ietf.org/license-info) in effect on the date of
49 publication of this document. Please review these documents
50 carefully, as they describe your rights and restrictions with respect
51 to this document. Code Components extracted from this document must
52 include Simplified BSD License text as described in Section 4.e of
53 the Trust Legal Provisions and are provided without warranty as
54 described in the Simplified BSD License.
56 Table of Contents
58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
60 3. TLV Extensions to STAMP . . . . . . . . . . . . . . . . . . . 3
61 3.1. IOAM Tracing Data TLV . . . . . . . . . . . . . . . . . . 3
62 3.2. Forward HbH Delay TLV . . . . . . . . . . . . . . . . . . 4
63 3.3. Backward HbH Delay TLV . . . . . . . . . . . . . . . . . 7
64 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
65 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
66 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
67 6.1. Normative References . . . . . . . . . . . . . . . . . . 9
68 6.2. Informative References . . . . . . . . . . . . . . . . . 9
69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
71 1. Introduction
73 Simple Two-way Active Measurement Protocol (STAMP) enables the
74 measurement of both one-way and round-trip performance metrics, such
75 as delay, delay variation, and packet loss [RFC8762]. In the STAMP
76 session, the bidirectional packet flow is transmited between STAMP
77 Session-Sender and STAMP Session-Reflector. The STAMP Session-
78 Reflector receives packets transmited from Session-Sender and acts
79 according to the configuration. However, the performance of
80 intermediate nodes that STAMP test packets traverse are invisible.
81 And the STAMP instance must be configured at every intermediate node
82 to measure the performance per node that test packets traverse, which
83 increases the complexity of OAM in large-scale networks.
85 This document extents optional TLVs to STAMP which enable OAM data
86 collection at every node that STAMP test packets traverse, such as
87 measurement of delay, packet loss, delay variation per hop, and
88 record of route information. STAMP Extensions have defined several
89 optionnal TLVs to enhance the STAMP base functions. These optional
90 TLVs are defined as updates of the STAMP Optional Extensions
91 [I-D.ietf-ippm-stamp-option-tlv]. The following sections describe
92 the use of TLVs for STAMP that extend STAMP capability beyond its
93 base specification.
95 2. Terminology
97 Following are abbreviations used in this document:
99 STAMP: Simple Two-way Active Measurement Protocol.
101 IOAM: In-situ OAM.
103 HbH: Hop-by-Hop.
105 3. TLV Extensions to STAMP
107 3.1. IOAM Tracing Data TLV
109 STAMP Session-Sender MAY place the IOAM Tracing Data TLV in STAMP
110 Session-Sender test packets to record the IOAM tracing data of every
111 IOAM capable node that the STAMP Session-Sender test packet traverses
112 in the forward path. As STAMP uses symmetrical packets, the Session-
113 Sender MUST set the Length value as a multiple of 4 octets according
114 to the number of intermediate nodes and the IOAM-Trace-Type (i.e. a
115 24-bit identifier which specifies which data types are used in the
116 node data list [I-D.ietf-ippm-ioam-data]). And the node-data-copied-
117 list fields MUST be set to zero upon Session-Sender test packets
118 transmission and ignored upon receipt.
120 The IOAM Tracing Data TLV has the following format:
122 0 1 2 3
123 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
124 +-------------------------------+-------------------------------+
125 | IOAM-Tracing-Data Type | Length |
126 +---------------------------------------------------------------+
127 | node data copied list [0] |
128 +---------------------------------------------------------------+
129 | node data copied list [1] |
130 +---------------------------------------------------------------+
131 ~ ... ~
132 +---------------------------------------------------------------+
133 | node data copied list [n] |
134 +---------------------------------------------------------------+
136 Fig. 1 IOAM Tracing Data TLV Format
138 where fields are defined as the following:
140 IOAM-Tracing-Data Type: To be assigned by IANA.
142 Length: A 2-octet field that indicates the length of the value field
143 in octets and equal to a multiple of 4 octets dependent on the number
144 of nodes and IOAM-Trace-Type bits.
146 node data copied list [0..n]: A variable-length field, which record
147 the copied content of each node data element determined by the IOAM-
148 Trace-Type. The order of packing the data fields in each node data
149 element follows the bit order of the IOAM-Trace-Type field (see
150 section 4.4.1 of [I-D.ietf-ippm-ioam-data]). The last node data
151 element in this list is the node data of the first IOAM trace capable
152 node in the path.
154 In an IOAM domain, the STAMP Session-Sender and the STAMP Session-
155 Reflector MAY be configured as the IOAM encapsulating node and the
156 IOAM decapsulating node. The STAMP Session-Sender (i.e. the IOAM
157 encapsulating node) generates the STAMP test packet with the IOAM
158 Tracing Data TLV. For applying the IOAM Trace-Option functionalities
159 to the STAMP Session-Sender test packet, the STAMP Session-Sender
160 must inserts the "trace option header" and allocate an node-data-list
161 array [I-D.ietf-ippm-ioam-data] into "option data" fields of Hop-by-
162 Hop Options header in IPv6 packets [I-D.ietf-ippm-ioam-ipv6-options],
163 and sets the corresponding bits in the IOAM-Trace-Type. Also, the
164 STAMP Session-Sender allocates an node-data-list array which is used
165 to store OAM data retrieved from every IOAM transit nodes while the
166 Session-Sender test packets traverse the path.
168 When the STAMP Session-Reflector (i.e. the IOAM decapsulating node)
169 received the STAMP Session-Sender test packet with the IOAM-Tracing-
170 Data TLV, it MUST copy the node-data-list array into the node-data-
171 copied-list array carried in the reflected test packet before
172 transmission and MUST remove the IOAM-Data-Fields. Hence, using
173 IOAM-Tracing-Data TLV in STAMP testing enables hop-by-hop OAM data
174 collection.
176 Also the STAMP Session-Reflector MAY be configured as IOAM
177 encapsulating node to apply the IOAM Trace-Option functionalities to
178 the reflected test packet. Hence, hop-by-hop OAM data collection can
179 be also enabled for the backward path that the reflected packets
180 traverse. When the reflected packet arrives at the Session-Sender
181 receives, it can be either locally processed or sent to the
182 centralized controller.
184 3.2. Forward HbH Delay TLV
186 STAMP Session-Sender MAY place the Forward HbH Delay TLV in Session-
187 Sender test packets to record the ingress timestamp and engress
188 timestamp at every intermediate nodes in the forward path that STAMP
189 test packets traverse. The Session-Sender MUST set the Length value
190 according to the number of intermediate nodes in the forward path and
191 the timestamp formats. There are several methods to synchronize the
192 clock, e.g., Network Time Protocol (NTP) [RFC5905]. For example, if
193 a 64-bit timestamp format defined in NTP is used, the Length value
194 MUST be set as a multiple of 8 octets. The Timestamp Tuple list
195 (Ingress Timestamp [0..n], Engress Timestamp [0..n]) fields MUST be
196 set to zero upon Session-Sender test packets transmission and ignored
197 upon receipt.
199 The Forward HbH Delay TLV has the following format:
201 0 1 2 3
202 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
203 +-------------------------------+---------------+---------------+
204 | Forward HbH Delay Type | Length | Node Left |
205 +-------------------------------+---------------+---------------+
206 | Ingress Timestamp [0] |
207 | |
208 +---------------------------------------------------------------+
209 | Engress Timestamp [0] |
210 | |
211 +---------------------------------------------------------------+
212 ~ ... ~
213 +---------------------------------------------------------------+
214 | Ingress Timestamp [n] |
215 | |
216 +---------------------------------------------------------------+
217 | Engress Timestamp [n] |
218 | |
219 +---------------------------------------------------------------+
221 Fig. 2 Forward HbH Delay TLV Format
223 where fields are defined as the following:
225 Forward HbH Delay Type: To be assigned by IANA.
227 Length: A 8-bit field that indicates the length of the value portion
228 in octets and MUST be a multiple of 8 octets according to the number
229 of intermediate nodes in the forward path.
231 Node Left: A 8-bit unsigned integer, which indicates the number of
232 intermediate nodes remaining. That is, number of exlicitly listed
233 intermediate nodes still to be visited before reaching the
234 destination node in the forward path. The Node Left field is set to
235 n-1, where n is the number of intermediate nodes.
237 Timestamp Tuple list (Ingress Timestamp [0..n], Engress Timestamp
238 [0..n]): A variable-length field, which record the timestamp when the
239 Session-Sender test packet is received at the ingress of the n-th
240 intermediate node and the timestamp when the Session-Sender test
241 packet is sent at engress of the n-th intermediate node. For
242 example, if a 64-bit timestamp format defined in NTP is used, the
243 length of each Timestamp tuple (Ingress Timestamp [n], Engress
244 Timestamp [n]) must be 16 octets. The Timestamp Tuple list is
245 encoded starting from the last intermediate node which is exlicitly
246 listed. That is, the first element of the Timestamp Tuple (Ingress
247 Timestamp [0], Engress Timestamp [0]) records the timestamps when the
248 Session-Sender test packet received and forwarded at the last
249 intermediate node of a explicit path, the second element records the
250 penultimate Timestamp Tuple when the Session-Sender test packet
251 received and forwarded at the penultimate intermediate node of a
252 explicit path, and so on.
254 In the following reference topology, Node N1, N2, N3, N4 and N5 are
255 SRv6 capable nodes. Node N1 is the STAMP Session-Sender and Node N5
256 is the STAMP Session-Reflector. T1 is the Timestamp taken by the
257 Session-Sender (i.e. N1) at the start of transmitting the test
258 packet. T2 is the Receive Timestamp when the test packet was
259 received by the Session-Reflector (i.e. N5). T3 is the Timestamp
260 taken by the Session-Reflector at the start of transmitting the test
261 packet. T4 is the Receive Timestamp when the test packet was
262 received by the Session-Sender. Timestamp tuples (t1,t2), (t3,t4)
263 and (t5,t6) are the timestamps when the test packet received and
264 transmited by sequence of intermediate nodes in the forward path.
265 Timestamp Tuples (t7,t8), (t9,t10) and (t11,t12) are the timestamps
266 when the test packet received and transmited by sequence of
267 intermediate nodes in the backward path.
269 ====== ====== ====== ====== ======
270 | | T1--->t1 | | t2--->t3 | | t4--->t5 | | t6--->T2| |
271 | N1 |==========| N2 |==========| N3 |==========| N4 |=========| N5 |
272 | | T4<---t12| |t11<---t10| | t9<---t8 | | t7<---T3| |
273 ====== ====== ====== ====== ======
275 Fig. 3 Reference Topology
277 The STAMP Session-Sender (i.e. Node N1) generates the STAMP test
278 packet with the Forward HbH Delay TLV. When an intermediate node
279 receives the STAMP test packet, the node sends the packet to control
280 plane and fills the Ingress Timestamp [n] filed in the Forward HbH
281 Delay TLV. Then the time taken by the intermediate node transmitting
282 the test packet is recorded in to Engress Timestamp [n] field in the
283 Forward HbH Delay TLV. The mechanism of timestamping and punting
284 packet to control plane is outside the scope of this specification.
286 When the STAMP Session-Reflector received the test packet with the
287 Forward HbH Delay TLV, it MUST copy the Forward HbH Delay TLV into
288 the reflected test packet before its transmission. Using Forward HbH
289 Delay TLV in STAMP testing enables hop-by-hop delay measurement in
290 the forward path.
292 3.3. Backward HbH Delay TLV
294 STAMP Session-Sender MAY place the Backward HbH Delay TLV in Session-
295 Sender test packets to record the ingress timestamp and engress
296 timestamp when Session-Reflector test packets are received and sent
297 at every intermediate nodes in the backward path. The Session-Sender
298 MUST set the Length value according to the number of intermediate
299 nodes in the backward path and the timestamp formats. There are
300 several methods to synchronize the clock, e.g., Network Time Protocol
301 (NTP) [RFC5905]. For example, if a 64-bit timestamp format defined
302 in NTP is used, the Length value MUST be set as a multiple of 8
303 octets. The Timestamp Tuple list (Ingress Timestamp [0..n], Engress
304 Timestamp [0..n]) fields MUST be set to zero upon Session-Sender test
305 packets transmission and ignored upon receipt.
307 The Backward HbH Delay TLV has the following format:
309 0 1 2 3
310 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
311 +-------------------------------+---------------+---------------+
312 | Backward HbH Delay Type | Length | Node Left |
313 +-------------------------------+---------------+---------------+
314 | Ingress Timestamp [0] |
315 | |
316 +---------------------------------------------------------------+
317 | Engress Timestamp [0] |
318 | |
319 +---------------------------------------------------------------+
320 ~ ... ~
321 +---------------------------------------------------------------+
322 | Ingress Timestamp [n] |
323 | |
324 +---------------------------------------------------------------+
325 | Engress Timestamp [n] |
326 | |
327 +---------------------------------------------------------------+
329 Fig. 4 Backward HbH Delay TLV Format
331 where fields are defined as the following:
333 Backward HbH Delay Type: To be assigned by IANA.
335 Length: A 8-bit field that indicates the length of the value portion
336 in octets and will be a multiple of 8 octets dependent on the number
337 of nodes in a path.
339 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 to
343 n-1, where n is the number of intermediate nodes.
345 Timestamp Tuple list (Ingress Timestamp [0..n], Engress Timestamp
346 [0..n]): A variable-length field, which record the timestamp when the
347 reflected test packet is received at the ingress of the n-th
348 intermediate node and the timestamp when the reflected test packet is
349 sent at engress of the n-th intermediate node. For example, if a
350 64-bit timestamp format defined in NTP is used, the length of each
351 Timestamp tuple (Ingress Timestamp [n], Engress Timestamp [n]) must
352 be 16 octets. The Timestamp Tuple list is encoded starting from the
353 last intermediate node which is exlicitly listed. That is, the first
354 element of the Timestamp Tuple (Ingress Timestamp [0], Engress
355 Timestamp [0]) records the timestamps when the reflected test packet
356 received and forwarded at the last intermediate node of a explicit
357 path, the second element records the penultimate Timestamp Tuple when
358 the reflected test packet received and forwarded at the penultimate
359 intermediate node of a explicit path, 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 reflected 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 hop-by-hop delay
371 measurement 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 introduces new TLV extensions 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