idnits 2.17.1
draft-brockners-inband-oam-transport-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 (October 30, 2016) is 2707 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
== Missing Reference: 'Elements-left' is mentioned on line 317, but not
defined
== Outdated reference: A later version (-03) exists of
draft-brockners-inband-oam-requirements-01
== Outdated reference: A later version (-07) exists of
draft-brockners-inband-oam-data-01
== Outdated reference: A later version (-05) exists of
draft-brockners-proof-of-transit-01
== Outdated reference: A later version (-26) exists of
draft-ietf-6man-segment-routing-header-02
== Outdated reference: A later version (-13) exists of
draft-ietf-ippm-6man-pdm-option-06
== Outdated reference: A later version (-13) exists of
draft-ietf-nvo3-vxlan-gpe-02
== Outdated reference: A later version (-28) exists of draft-ietf-sfc-nsh-10
== Outdated reference: A later version (-15) exists of
draft-ietf-spring-segment-routing-09
Summary: 0 errors (**), 0 flaws (~~), 10 warnings (==), 1 comment (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Network Working Group F. Brockners
3 Internet-Draft S. Bhandari
4 Intended status: Informational C. Pignataro
5 Expires: May 3, 2017 Cisco
6 H. Gredler
7 RtBrick Inc.
8 J. Leddy
9 Comcast
10 S. Youell
11 JMPC
12 T. Mizrahi
13 Marvell
14 D. Mozes
15 Mellanox Technologies Ltd.
16 P. Lapukhov
17 Facebook
18 R. Chang
19 Barefoot Networks
20 October 30, 2016
22 Encapsulations for In-situ OAM Data
23 draft-brockners-inband-oam-transport-02
25 Abstract
27 In-situ Operations, Administration, and Maintenance (OAM) records
28 operational and telemetry information in the packet while the packet
29 traverses a path between two points in the network. In-situ OAM is
30 to complement current out-of-band OAM mechanisms based on ICMP or
31 other types of probe packets. This document outlines how in-situ OAM
32 data records can be transported in protocols such as NSH, Segment
33 Routing, VXLAN-GPE, native IPv6 (via extension headers), and IPv4.
34 Transport options are currently investigated as part of an
35 implementation study. This document is intended to only serve
36 informational purposes.
38 Status of This Memo
40 This Internet-Draft is submitted in full conformance with the
41 provisions of BCP 78 and BCP 79.
43 Internet-Drafts are working documents of the Internet Engineering
44 Task Force (IETF). Note that other groups may also distribute
45 working documents as Internet-Drafts. The list of current Internet-
46 Drafts is at http://datatracker.ietf.org/drafts/current/.
48 Internet-Drafts are draft documents valid for a maximum of six months
49 and may be updated, replaced, or obsoleted by other documents at any
50 time. It is inappropriate to use Internet-Drafts as reference
51 material or to cite them other than as "work in progress."
53 This Internet-Draft will expire on May 3, 2017.
55 Copyright Notice
57 Copyright (c) 2016 IETF Trust and the persons identified as the
58 document authors. All rights reserved.
60 This document is subject to BCP 78 and the IETF Trust's Legal
61 Provisions Relating to IETF Documents
62 (http://trustee.ietf.org/license-info) in effect on the date of
63 publication of this document. Please review these documents
64 carefully, as they describe your rights and restrictions with respect
65 to this document. Code Components extracted from this document must
66 include Simplified BSD License text as described in Section 4.e of
67 the Trust Legal Provisions and are provided without warranty as
68 described in the Simplified BSD License.
70 Table of Contents
72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
73 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4
74 3. In-Situ OAM Metadata Transport in IPv6 . . . . . . . . . . . 4
75 3.1. In-situ OAM in IPv6 Hop by Hop Extension Header . . . . . 5
76 3.1.1. In-situ OAM Hop by Hop Options . . . . . . . . . . . 5
77 3.1.2. Procedure at the Ingress Edge to Insert the In-situ
78 OAM Header . . . . . . . . . . . . . . . . . . . . . 7
79 3.1.3. Procedure at Transit Nodes . . . . . . . . . . . . . 8
80 3.1.4. Procedure at the Egress Edge to Remove the In-situ
81 OAM Header . . . . . . . . . . . . . . . . . . . . . 8
82 4. In-situ OAM Metadata Transport in IPv4 . . . . . . . . . . . 9
83 5. In-situ OAM Metadata Transport in VXLAN-GPE . . . . . . . . . 9
84 6. In-situ OAM Metadata Transport in NSH . . . . . . . . . . . . 11
85 7. In-situ OAM Metadata Transport in Segment Routing . . . . . . 13
86 7.1. In-situ OAM in SR with IPv6 Transport . . . . . . . . . . 13
87 7.2. In-situ OAM in SR with MPLS Transport . . . . . . . . . . 14
88 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
89 9. Manageability Considerations . . . . . . . . . . . . . . . . 14
90 10. Security Considerations . . . . . . . . . . . . . . . . . . . 14
91 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
92 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
93 12.1. Normative References . . . . . . . . . . . . . . . . . . 14
94 12.2. Informative References . . . . . . . . . . . . . . . . . 14
95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
97 1. Introduction
99 This document discusses transport mechanisms for "in-situ"
100 Operations, Administration, and Maintenance (OAM) data records. In-
101 situ OAM records OAM information within the packet while the packet
102 traverses a particular network domain. The term "in-situ" refers to
103 the fact that the OAM data is added to the data packets rather than
104 is being sent within packets specifically dedicated to OAM. A
105 discussion of the motivation and requirements for in-situ OAM can be
106 found in [I-D.brockners-inband-oam-requirements]. Data types and
107 data formats for in-situ OAM are defined in
108 [I-D.brockners-inband-oam-data].
110 This document outlines transport encapsulations for the in-situ OAM
111 data defined in [I-D.brockners-inband-oam-data]. This document is to
112 serve informational purposes only. As part of an in-situ OAM
113 implementation study different protocol encapsulations for in-situ
114 OAM data are being explored. Once data formats and encapsulation
115 approaches are settled, protocol specific specifications for in-situ
116 OAM data transport will address the standardization aspect.
118 The data for in-situ OAM defined in [I-D.brockners-inband-oam-data]
119 can be carried in a variety of protocols based on the deployment
120 needs. This document discusses transport of in-situ OAM data for the
121 following protocols:
123 o IPv6
125 o IPv4
127 o VXLAN-GPE
129 o NSH
131 o Segment Routing (IPv6 and MPLS)
133 This list is non-exhaustive, as it is possible to carry the in-situ
134 OAM data in several other protocols and transports.
136 A feasibility study of in-situ OAM is currently underway as part of
137 the FD.io project [FD.io]. The in-situ OAM implementation study
138 should be considered as a "tool box" to showcase how "in-situ" OAM
139 can complement probe-packet based OAM mechanisms for different
140 deployments and packet transport formats. For details, see the open
141 source code in the FD.io [FD.io].
143 2. Conventions
145 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
146 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
147 document are to be interpreted as described in [RFC2119].
149 Abbreviations used in this document:
151 MTU: Maximum Transmit Unit
153 NSH: Network Service Header
155 OAM: Operations, Administration, and Maintenance
157 POT: Proof of Transit
159 SFC: Service Function Chain
161 SID: Segment Identifier
163 SR: Segment Routing
165 VXLAN-GPE: Virtual eXtensible Local Area Network, Generic Protocol
166 Extension
168 3. In-Situ OAM Metadata Transport in IPv6
170 This mechanisms of in-situ OAM in IPv6 complement others proposed to
171 enhance diagnostics of IPv6 networks, such as the IPv6 Performance
172 and Diagnostic Metrics Destination Option described in
173 [I-D.ietf-ippm-6man-pdm-option]. The IP Performance and Diagnostic
174 Metrics Destination Option is destination focused and specific to
175 IPv6, whereas in-situ OAM is performed between end-points of the
176 network or a network domain where it is enabled and used.
178 A historical note: The idea of IPv6 route recording was originally
179 introduced by [I-D.kitamura-ipv6-record-route] back in year 2000.
180 With IPv6 now being generally deployed and new concepts such as
181 Segment Routing [I-D.ietf-spring-segment-routing] being introduced,
182 it is imperative to further mature the Operations, Administration,
183 and Maintenance mechanisms available to IPv6 networks.
185 The in-situ OAM options translate into options for an IPv6 extension
186 header. The extension header would be inserted by either a host
187 source of the packet, or by a transit/domain-edge node. If the
188 addition of the in-situ OAM Hop-by-Hop Option header would lead to
189 the packet exceeding the MTU of the domain an error should be
190 reported. The methods and procedures of how the error is reported
191 are outside the scope of this document. Likewise if an ICMPv6
192 forwarding error occurs between encapsulating and decapsulating
193 nodes, the node generating the ICMPv6 error should strip the in-situ
194 OAM Hop-by-Hop Option header before sending the ICMPv6 message to the
195 source.
197 3.1. In-situ OAM in IPv6 Hop by Hop Extension Header
199 This section defines in-situ OAM for IPv6 transport. In-situ OAM
200 data is transported as an IPv6 hop-by-hop extension header.
202 3.1.1. In-situ OAM Hop by Hop Options
204 Brief recap of the IPv6 hop-by-hop header as well as the options used
205 for carrying in-situ OAM data:
207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
208 | Next Header | Hdr Ext Len | |
209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
210 | |
211 . .
212 . Options .
213 . .
214 | |
215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
218 | Option Type | Opt Data Len | Option Data
219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
221 With 2 highest order bits of Option Type indicating the following:
223 00 - skip over this option and continue processing the header.
225 01 - discard the packet.
227 10 - discard the packet and, regardless of whether or not the
228 packet's Destination Address was a multicast address, send an
229 ICMP Parameter Problem, Code 2, message to the packet's
230 Source Address, pointing to the unrecognized Option Type.
232 11 - discard the packet and, only if the packet's Destination
233 Address was not a multicast address, send an ICMP Parameter
234 Problem, Code 2, message to the packet's Source Address,
235 pointing to the unrecognized Option Type.
237 3rd highest bit:
239 0 - Option Data does not change en-route
241 1 - Option Data may change en-route
243 In-situ OAM data records are inserted as options in an IPv6 hop-by-
244 hop extension header:
246 1. Tracing Option: The in-situ OAM Tracing option defined in
247 [I-D.brockners-inband-oam-data] is represented as a IPv6 option
248 in hop by hop extension header by allocating following type:
250 Option Type: 001xxxxxx 8-bit identifier of the type of option.
251 xxxxxx=TBD_IANA_TRACE_OPTION_IPV6.
253 2. Proof of Transit Option: The in-situ OAM POT option defined in
254 [I-D.brockners-inband-oam-data] is represented as a IPv6 option
255 in hop by hop extension header by allocating following type:
257 Option Type: 001xxxxxx 8-bit identifier of the type of option.
258 xxxxxx=TBD_IANA_POT_OPTION_IPV6.
260 3. Edge to Edge Option: The in-situ OAM E2E option defined in
261 [I-D.brockners-inband-oam-data] is represented as a IPv6 option
262 in hop by hop extension header by allocating following type:
264 Option Type: 000xxxxxx 8-bit identifier of the type of option.
265 xxxxxx=TBD_IANA_E2E_OPTION_IPV6.
267 3.1.2. Procedure at the Ingress Edge to Insert the In-situ OAM Header
269 In an administrative domain where in-situ OAM is used, insertion of
270 the in-situ OAM header is enabled at the required edge nodes (i.e. at
271 the encapsulating/decapsulating nodes) by means of configuration.
273 Such a configuration SHOULD allow selective enablement of in-situ OAM
274 header insertion for a subset of traffic (e.g., one or several
275 "pipes").
277 Further the ingress edge node should be aware of maximum size of the
278 header that can be inserted. Details on how the maximum size/size of
279 the in-situ OAM domain are retrieved are outside the scope of this
280 document.
282 Let n = max number of nodes updating in-situ OAM data;
283 (calculated based on the packet size and the minimal MTU on all
284 links within the OAM domain)
286 Let k = number of node data records that can be allocated
287 by this node.
289 Let node_data_size = size of each node_data based on
290 in-situ OAM type.
292 if (packet matches traffic for which in-situ OAM is enabled) {
293 Create in-situ OAM hbyh ext-header with k node data records
294 preallocated.
295 Increment payload length in IPv6 header:
296 with size of in-situ OAM hbyh ext-header
297 Populate node data at:
298 (size of in-situ OAM hbyh ext-header = 8) + k * node_data_size
299 from the beginning of the header
300 Set Elements-left to: k - 1
302 Update "Next Header" field in main IPv6 header and
303 set "Next Header" field of OAM hbyh extension header
304 appropriately.
305 }
307 3.1.3. Procedure at Transit Nodes
309 If a network node receives a packet with an in-situ OAM header and it
310 is enabled to process in-situ OAM data it performs the following:
312 k = number of node data that this node can allocate
314 if (in-situ OAM ext hbyh ext-header is present) {
315 if (Elements-left > 0)) {
316 populate node data at :
317 node_data_start[Elements-left]
318 Elements-left = Elements-left - 1
319 }
320 }
322 3.1.4. Procedure at the Egress Edge to Remove the In-situ OAM Header
323 egress_edge = list of interfaces where in-situ OAM hbyh ext
324 header is to be stripped
326 Before forwarding packet out of interfaces in egress_edge list:
328 if (in-situ OAM hbyh ext-header is present) {
329 remove the in-situ OAM hbyh ext-header,
330 possibly store the record along with additional
331 fields for analysis and export
332 Decrement Payload Length in IPv6 header
333 by size of in-situ OAM ext header
335 Update "Next Header" field in main IPv6 header and
336 set "Next Header" field of OAM hbyh extension header
337 appropriately.
338 }
340 4. In-situ OAM Metadata Transport in IPv4
342 Transport of in-situ OAM data in IPv4 will be detailed in a future
343 version of this document.
345 5. In-situ OAM Metadata Transport in VXLAN-GPE
347 VXLAN-GPE [I-D.ietf-nvo3-vxlan-gpe] encapsulation is somewhat similar
348 to IPv6 extension headers in that a series of headers can be
349 contained in the header as a linked list. The different in-situ OAM
350 types are added as options within a new in-situ OAM protocol header
351 in VXLAN GPE. In an administrative domain where in-situ OAM is used,
352 insertion of the in-situ OAM protocol header in VXLAN GPE is enabled
353 at the VXLAN GPE tunnel endpoint which also serve as in-situ OAM
354 encapsulating/decapsulating nodes by means of configuration.
356 In-situ OAM header in VXLAN GPE header:
358 0 1 2 3
359 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
360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
361 | Outer Ethernet Header |
362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
363 | Outer IP Header |
364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
365 | Outer UDP Header |
366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
367 |R|R|Ver|I|P|R|O| Reserved | NP = i.s.OAM | |
368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ GPE
369 | Virtual Network Identifier (VNI) | Reserved | |
370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
371 | Type =i.s.OAM | i.s.OAM HDR len | Reserved | NP = IP/Eth | |
372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+iOAM
373 | in-situ OAM options | |
374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
375 | |
376 | |
377 | Payload + Padding (L2/L3/ESP/...) |
378 | |
379 | |
380 | |
381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
383 The VXLAN-GPE header and fields are defined in
384 [I-D.ietf-nvo3-vxlan-gpe]. in-situ OAM specific fields and header are
385 defined here:
387 Type: 8-bit unsigned integer defining in-situ OAM header type
389 in-situ OAM HDR len: 8-bit unsigned integer. Length of the in-situ
390 OAM HDR in 8-octet units
392 in-situ OAM options: Variable-length field, of length such that the
393 complete in-situ OAM header is an integer multiple of 8 octets
394 long. Contains one or more TLV-encoded options of the format:
396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
397 | Option Type | Opt Data Len | Option Data
398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
400 Option Type 8-bit identifier of the type of option.
402 Opt Data Len 8-bit unsigned integer. Length of the Option
403 Data field of this option, in octets.
405 Option Data Variable-length field. Option-Type-specific
406 data.
408 The in-situ OAM options defined in [I-D.brockners-inband-oam-data]
409 are encoded with an option type allocated in the new in-situ OAM IANA
410 registry - in-situ OAM_PROTOCOL_OPTION_REGISTRY_IANA_TBD. In
411 addition the following padding options are defined to be used when
412 necessary to align subsequent options and to pad out the containing
413 header to a multiple of 8 octets in length.
415 Pad1 option (alignment requirement: none)
417 +-+-+-+-+-+-+-+-+
418 | 0 |
419 +-+-+-+-+-+-+-+-+
420 NOTE: The format of the Pad1 option is a special case -- it does
421 not have length and value fields.
423 The Pad1 option is used to insert one octet of padding into the
424 Options area of a header. If more than one octet of padding is
425 required, the PadN option, described next, should be used, rather
426 than multiple Pad1 options.
428 PadN option (alignment requirement: none)
430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
431 | 1 | Opt Data Len | Option Data
432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
433 The PadN option is used to insert two or more octets of padding
434 into the Options area of a header. For N octets of padding, the
435 Opt Data Len field contains the value N-2, and the Option Data
436 consists of N-2 zero-valued octets.
438 6. In-situ OAM Metadata Transport in NSH
440 In Service Function Chaining (SFC) [RFC7665], the Network Service
441 Header (NSH) [I-D.ietf-sfc-nsh] already includes path tracing
442 capabilities [I-D.penno-sfc-trace], but currently does not offer a
443 solution to securely prove that packets really traversed the service
444 chain. The "Proof of Transit" capabilities (see
445 [I-D.brockners-inband-oam-requirements] and
446 [I-D.brockners-proof-of-transit]) of in-situ OAM can be leveraged
447 within NSH. In an administrative domain where in-situ OAM is used,
448 insertion of the in-situ OAM data into the NSH header is enabled at
449 the required nodes (i.e. at the in-situ OAM encapsulating/
450 decapsulating nodes) by means of configuration.
452 Proof of transit in-situ OAM data is added as NSH Type 2 metadata:
454 0 1 2 3
455 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
456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
457 | TLV Class=Cisco (0x0009) |C| Type=POT |R| Len=4 |
458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+
459 | Random | |
460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ P
461 | Random(contd.) | O
462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ T
463 | Cumulative | |
464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
465 | Cumulative (contd.) | |
466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+
468 TLV Class: Describes the scope of the "Type" field. In some cases,
469 the TLV Class will identify a specific vendor, in others, the TLV
470 Class will identify specific standards body allocated types. POT
471 is currently defined using the Cisco (0x0009) TLV class.
473 Type: The specific type of information being carried, within the
474 scope of a given TLV Class. Value allocation is the
475 responsibility of the TLV Class owner. Currently a type value of
476 0x94 is used for proof of transit
478 Reserved bits: Two reserved bit are present for future use. The
479 reserved bits MUST be set to 0x0.
481 F: One bit. Indicates which POT-profile is active. 0 means the even
482 POT-profile is active, 1 means the odd POT-profile is active.
484 Length: Length of the variable metadata, in 4-octet words. Here the
485 length is 4.
487 Random: 64-bit Per-packet Random number.
489 Cumulative: 64-bit Cumulative that is updated by the Service
490 Functions.
492 7. In-situ OAM Metadata Transport in Segment Routing
494 7.1. In-situ OAM in SR with IPv6 Transport
496 Similar to NSH, a service chain or path defined using Segment Routing
497 for IPv6 can be verified using the in-situ OAM "Proof of Transit"
498 approach. The Segment Routing Header (SRH) for IPv6 offers the
499 ability to transport TLV structured data, similar to what NSH does
500 (see [I-D.ietf-6man-segment-routing-header]). In an domain where in-
501 situ OAM is used, insertion of the in-situ OAM data is enabled at the
502 required edge nodes (i.e. at the in-situ OAM encapsulating/
503 decapsulating nodes) by means of configuration.
505 A new "POT TLV" is defined for the SRH which is to carry proof of
506 transit in situ OAM data.
508 0 1 2 3
509 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
510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
511 | Type | Length | RESERVED |F| Flags |
512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+
513 | Random | |
514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ P
515 | Random(contd.) | O
516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ T
517 | Cumulative | |
518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
519 | Cumulative (contd.) | |
520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+
522 Type: To be assigned by IANA.
524 Length: 18.
526 RESERVED: 8 bits. SHOULD be unset on transmission and MUST be
527 ignored on receipt.
529 F: 1 bit. Indicates which POT-profile is active. 0 means the even
530 POT-profile is active, 1 means the odd POT-profile is active.
532 Flags: 8 bits. No flags are defined in this document.
534 Random: 64-bit per-packet random number.
536 Cumulative: 64-bit cumulative value that is updated at specific
537 nodes that form the service path to be verified.
539 7.2. In-situ OAM in SR with MPLS Transport
541 In-situ OAM "Proof of Transit" data can also be carried as part of
542 the MPLS label stack. Details will be addressed in a future version
543 of this document.
545 8. IANA Considerations
547 IANA considerations will be added in a future version of this
548 document.
550 9. Manageability Considerations
552 Manageability considerations will be addressed in a later version of
553 this document..
555 10. Security Considerations
557 Security considerations will be addressed in a later version of this
558 document. For a discussion of security requirements of in-situ OAM,
559 please refer to [I-D.brockners-inband-oam-requirements].
561 11. Acknowledgements
563 The authors would like to thank Eric Vyncke, Nalini Elkins, Srihari
564 Raghavan, Ranganathan T S, Karthik Babu Harichandra Babu, Akshaya
565 Nadahalli, Stefano Previdi, Hemant Singh, Erik Nordmark, LJ Wobker,
566 and Andrew Yourtchenko for the comments and advice. For the IPv6
567 encapsulation, this document leverages and builds on top of several
568 concepts described in [I-D.kitamura-ipv6-record-route]. The authors
569 would like to acknowledge the work done by the author Hiroshi
570 Kitamura and people involved in writing it.
572 12. References
574 12.1. Normative References
576 [I-D.brockners-inband-oam-requirements]
577 Brockners, F., Bhandari, S., Dara, S., Pignataro, C.,
578 Gredler, H., Leddy, J., and S. Youell, "Requirements for
579 In-band OAM", draft-brockners-inband-oam-requirements-01
580 (work in progress), July 2016.
582 12.2. Informative References
584 [FD.io] "Fast Data Project: FD.io", .
586 [I-D.brockners-inband-oam-data]
587 Brockners, F., Bhandari, S., Pignataro, C., Gredler, H.,
588 Leddy, J., and S. Youell, "Data Formats for In-band OAM",
589 draft-brockners-inband-oam-data-01 (work in progress),
590 July 2016.
592 [I-D.brockners-proof-of-transit]
593 Brockners, F., Bhandari, S., Dara, S., Pignataro, C.,
594 Leddy, J., and S. Youell, "Proof of Transit", draft-
595 brockners-proof-of-transit-01 (work in progress), July
596 2016.
598 [I-D.ietf-6man-segment-routing-header]
599 Previdi, S., Filsfils, C., Field, B., Leung, I., Linkova,
600 J., Aries, E., Kosugi, T., Vyncke, E., and D. Lebrun,
601 "IPv6 Segment Routing Header (SRH)", draft-ietf-6man-
602 segment-routing-header-02 (work in progress), September
603 2016.
605 [I-D.ietf-ippm-6man-pdm-option]
606 Elkins, N., Hamilton, R., and m. mackermann@bcbsm.com,
607 "IPv6 Performance and Diagnostic Metrics (PDM) Destination
608 Option", draft-ietf-ippm-6man-pdm-option-06 (work in
609 progress), September 2016.
611 [I-D.ietf-nvo3-vxlan-gpe]
612 Kreeger, L. and U. Elzur, "Generic Protocol Extension for
613 VXLAN", draft-ietf-nvo3-vxlan-gpe-02 (work in progress),
614 April 2016.
616 [I-D.ietf-sfc-nsh]
617 Quinn, P. and U. Elzur, "Network Service Header", draft-
618 ietf-sfc-nsh-10 (work in progress), September 2016.
620 [I-D.ietf-spring-segment-routing]
621 Filsfils, C., Previdi, S., Decraene, B., Litkowski, S.,
622 and R. Shakir, "Segment Routing Architecture", draft-ietf-
623 spring-segment-routing-09 (work in progress), July 2016.
625 [I-D.kitamura-ipv6-record-route]
626 Kitamura, H., "Record Route for IPv6 (PR6) Hop-by-Hop
627 Option Extension", draft-kitamura-ipv6-record-route-00
628 (work in progress), November 2000.
630 [I-D.penno-sfc-trace]
631 Penno, R., Quinn, P., Pignataro, C., and D. Zhou,
632 "Services Function Chaining Traceroute", draft-penno-sfc-
633 trace-03 (work in progress), September 2015.
635 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
636 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
637 RFC2119, March 1997,
638 .
640 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function
641 Chaining (SFC) Architecture", RFC 7665, DOI 10.17487/
642 RFC7665, October 2015,
643 .
645 Authors' Addresses
647 Frank Brockners
648 Cisco Systems, Inc.
649 Hansaallee 249, 3rd Floor
650 DUESSELDORF, NORDRHEIN-WESTFALEN 40549
651 Germany
653 Email: fbrockne@cisco.com
655 Shwetha Bhandari
656 Cisco Systems, Inc.
657 Cessna Business Park, Sarjapura Marathalli Outer Ring Road
658 Bangalore, KARNATAKA 560 087
659 India
661 Email: shwethab@cisco.com
663 Carlos Pignataro
664 Cisco Systems, Inc.
665 7200-11 Kit Creek Road
666 Research Triangle Park, NC 27709
667 United States
669 Email: cpignata@cisco.com
671 Hannes Gredler
672 RtBrick Inc.
674 Email: hannes@rtbrick.com
675 John Leddy
676 Comcast
678 Email: John_Leddy@cable.comcast.com
680 Stephen Youell
681 JP Morgan Chase
682 25 Bank Street
683 London E14 5JP
684 United Kingdom
686 Email: stephen.youell@jpmorgan.com
688 Tal Mizrahi
689 Marvell
690 6 Hamada St.
691 Yokneam 20692
692 Israel
694 Email: talmi@marvell.com
696 David Mozes
697 Mellanox Technologies Ltd.
699 Email: davidm@mellanox.com
701 Petr Lapukhov
702 Facebook
703 1 Hacker Way
704 Menlo Park, CA 94025
705 US
707 Email: petr@fb.com
709 Remy Chang
710 Barefoot Networks
711 2185 Park Boulevard
712 Palo Alto, CA 94306
713 US