idnits 2.17.1
draft-brockners-inband-oam-transport-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 (July 18, 2016) is 2839 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
== Unused Reference: 'I-D.hildebrand-spud-prototype' is defined on line
545, but no explicit reference was found in the text
== Unused Reference: 'P4' is defined on line 581, but no explicit reference
was found in the text
== Outdated reference: A later version (-26) exists of
draft-ietf-6man-segment-routing-header-01
== Outdated reference: A later version (-13) exists of
draft-ietf-ippm-6man-pdm-option-03
== 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-05
== Outdated reference: A later version (-15) exists of
draft-ietf-spring-segment-routing-09
Summary: 0 errors (**), 0 flaws (~~), 8 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: January 19, 2017 Cisco
6 H. Gredler
7 RtBrick Inc.
8 J. Leddy
9 Comcast
10 S. Youell
11 JMPC
12 July 18, 2016
14 Encapsulations for In-band OAM Data
15 draft-brockners-inband-oam-transport-01
17 Abstract
19 In-band operation, administration and maintenance (OAM) records
20 operational and telemetry information in the packet while the packet
21 traverses a path between two points in the network. In-band OAM is
22 to complement current out-of-band OAM mechanisms based on ICMP or
23 other types of probe packets. This document outlines how in-band OAM
24 data records can be transported in protocols such as NSH, Segment
25 Routing, VXLAN-GPE, native IPv6 (via extension header), and IPv4.
26 Transport options are currently investigated as part of an
27 implementation study. This document is intended to only serve
28 informational purposes.
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 http://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 January 19, 2017.
47 Copyright Notice
49 Copyright (c) 2016 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 (http://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. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
66 3. In-Band OAM Metadata Transport in IPv6 . . . . . . . . . . . 4
67 3.1. In-band OAM in IPv6 Hop by Hop Extension Header . . . . . 4
68 3.1.1. In-band OAM Hop by Hop Options . . . . . . . . . . . 4
69 3.1.2. Procedure at the Ingress Edge to Insert the In-band
70 OAM Header . . . . . . . . . . . . . . . . . . . . . 6
71 3.1.3. Procedure at Intermediate Nodes . . . . . . . . . . . 7
72 3.1.4. Procedure at the Egress Edge to Remove the In-band
73 OAM Header . . . . . . . . . . . . . . . . . . . . . 7
74 4. In-band OAM Metadata Transport in VXLAN-GPE . . . . . . . . . 7
75 5. In-band OAM Metadata Transport in NSH . . . . . . . . . . . . 9
76 6. In-band OAM Metadata Transport in Segment Routing . . . . . . 11
77 6.1. In-band OAM in SR with IPv6 Transport . . . . . . . . . . 11
78 6.2. In-band OAM in SR with MPLS Transport . . . . . . . . . . 11
79 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
80 8. Manageability Considerations . . . . . . . . . . . . . . . . 12
81 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12
82 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
83 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
84 11.1. Normative References . . . . . . . . . . . . . . . . . . 12
85 11.2. Informative References . . . . . . . . . . . . . . . . . 12
86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
88 1. Introduction
90 This document discusses transport mechanisms for "in-band" operation,
91 administration, and maintenance (OAM) data records. In-band OAM
92 records OAM information within the packet while the packet traverses
93 a particular network domain. The term "in-band" refers to the fact
94 that the OAM data is added to the data packets rather than is being
95 sent within packets specifically dedicated to OAM. A discussion of
96 the motivation and requirements for in-band OAM can be found in
97 [draft-brockners-inband-oam-requirements]. Data types and data
98 formats for in-band OAM are defined in
99 [draft-brockners-inband-oam-data].
101 This document outlines transport encapsulations for the in-band OAM
102 data defined in [draft-brockners-inband-oam-data]. This document is
103 to serve informational purposes only. As part of an in-band OAM
104 implementation study different protocol encapsulations for in-band
105 OAM data are being explored. Once data formats and encapsulation
106 approaches are settled, protocol specific specifications for in-band
107 OAM data transport will address the standardization aspect.
109 The data for in-band OAM defined in [draft-brockners-inband-oam-data]
110 can be carried in a variety of protocols based on the deployment
111 needs. This document discusses transport of in-band OAM data for the
112 following protocols:
114 o IPv6
116 o VXLAN-GPE
118 o NSH
120 o Segment Routing (IPv6 and MPLS)
122 This list is non-exhaustive, as it is possible to carry the in-band
123 OAM data in several other protocols and transports.
125 A feasibility study of in-band OAM is currently underway as part of
126 the FD.io project [FD.io]. The in-band OAM implementation study
127 should be considered as a "tool box" to showcase how "in-band" OAM
128 can complement probe-packet based OAM mechanisms for different
129 deployments and packet transport formats. For details, see the open
130 source code in the FD.io [FD.io].
132 2. Conventions
134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
136 document are to be interpreted as described in [RFC2119].
138 Abbreviations used in this document:
140 MTU: Maximum Transmit Unit
142 OAM: Operations, Administration, and Maintenance
143 SR: Segment Routing
145 SID: Segment Identifier
147 NSH: Network Service Header
149 POT: Proof of Transit
151 SFC: Service Function Chain
153 VXLAN-GPE: Virtual eXtensible Local Area Network, Generic Protocol
154 Extension
156 3. In-Band OAM Metadata Transport in IPv6
158 This mechanisms of in-band OAM in IPv6 complement others proposed to
159 enhance diagnostics of IPv6 networks, such as the IPv6 Performance
160 and Diagnostic Metrics Destination Option described in
161 [I-D.ietf-ippm-6man-pdm-option]. The IP Performance and Diagnostic
162 Metrics Destination Option is destination focused and specific to
163 IPv6, whereas in-band OAM is performed between end-points of the
164 network or a network domain where it is enabled and used.
166 A historical note: The idea of IPv6 route recording was originally
167 introduced by [draft-kitamura-ipv6-record-route] back in year 2000.
168 With IPv6 now being generally deployed and new concepts such as
169 Segment Routing [I-D.ietf-spring-segment-routing] being introduced,
170 it is imperative to further mature the operations, administration,
171 and maintenance mechanisms available to IPv6 networks.
173 The in-band OAM options translate into options for an IPv6 extension
174 header. The extension header would be inserted by either a host
175 source of the packet, or by a transit/domain-edge node.
177 3.1. In-band OAM in IPv6 Hop by Hop Extension Header
179 This section defines in-band OAM for IPv6 transport. In-band OAM
180 data is transported as an IPv6 hop-by-hop extension header.
182 3.1.1. In-band OAM Hop by Hop Options
184 Brief recap of the IPv6 hop-by-hop header as well as the options used
185 for carrying in-band OAM data:
187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
188 | Next Header | Hdr Ext Len | |
189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
190 | |
191 . .
192 . Options .
193 . .
194 | |
195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
198 | Option Type | Opt Data Len | Option Data
199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
201 With 2 highest order bits of Option Type indicating the following:
203 00 - skip over this option and continue processing the header.
205 01 - discard the packet.
207 10 - discard the packet and, regardless of whether or not the
208 packet's Destination Address was a multicast address, send an
209 ICMP Parameter Problem, Code 2, message to the packet's
210 Source Address, pointing to the unrecognized Option Type.
212 11 - discard the packet and, only if the packet's Destination
213 Address was not a multicast address, send an ICMP Parameter
214 Problem, Code 2, message to the packet's Source Address,
215 pointing to the unrecognized Option Type.
217 3rd highest bit:
219 0 - Option Data does not change en-route
221 1 - Option Data may change en-route
223 In-band OAM data records are inserted as options in an IPv6 hop-by-
224 hop extension header:
226 1. Tracing Option: The in-band OAM Tracing option defined in
227 [draft-brockners-inband-oam-data] is represented as a IPv6 option
228 in hop by hop extension header by allocating following type:
230 Option Type: 001xxxxxx 8-bit identifier of the type of option.
231 xxxxxx=TBD_IANA_TRACE_OPTION_IPV6.
233 2. Proof of Transit Option: The in-band OAM POT option defined in
234 [draft-brockners-inband-oam-data] is represented as a IPv6 option
235 in hop by hop extension header by allocating following type:
237 Option Type: 001xxxxxx 8-bit identifier of the type of option.
238 xxxxxx=TBD_IANA_POT_OPTION_IPV6.
240 3. Edge to Edge Option: The in-band OAM E2E option defined in
241 [draft-brockners-inband-oam-data] is represented as a IPv6 option
242 in hop by hop extension header by allocating following type:
244 Option Type: 000xxxxxx 8-bit identifier of the type of option.
245 xxxxxx=TBD_IANA_E2E_OPTION_IPV6.
247 3.1.2. Procedure at the Ingress Edge to Insert the In-band OAM Header
249 In an administrative domain where in-band OAM is used, insertion of
250 the in-band OAM header is enabled at the required edge nodes by means
251 of configuration.
253 Such a config SHOULD allow selective enablement of in-band OAM header
254 insertion for a subset of traffic (e.g., one or several "pipes").
256 Further the ingress edge node should be aware of maximum size of the
257 header that can be inserted. Details on how the maximum size/size of
258 the in-band OAM domain are retrieved are outside the scope of this
259 document.
261 Let n = max number of nodes to be allocated;
262 (Based on PMTU advertised in the domain)
264 Let k = number of node data that can be allocated by this node
265 Let node_data_size = size of each node_data based on in-band OAM type
267 if (packet matches traffic for which in-band OAM is enabled) {
268 Create in-band OAM hbyh ext header with k node data preallocated
269 Increment payload length in IPv6 header :
270 with size of in-band OAM hbyh ext header
271 Populate node data at :
272 (size of in-band OAM hbyh header = 8) + k * node_data_size
273 from the beginning of the header
274 Set segments left to : k - 1
276 }
278 3.1.3. Procedure at Intermediate Nodes
280 If a network node receives a packet with an in-band OAM header and it
281 is enabled to process in-band OAM data it performs the following:
283 k = number of node data that this node can allocate
284 if (in-band OAM ext hbyh header is present) {
285 if (Segments Left > 0)) {
286 populate node data at :
287 node_data_start[Segments Left]
288 Segments Left = Segments Left - 1
289 }
290 }
292 3.1.4. Procedure at the Egress Edge to Remove the In-band OAM Header
294 egress_edge = list of interfaces where in-band OAM hbyh ext
295 header is to be stripped
296 Before forwarding packet out of interfaces in egress_edge list:
297 if (in-band OAM hbyh ext header is present) {
298 remove the in-band OAM hbyh ext header,
299 possibly store the record along with additional
300 fields for analysis and export
301 Decrement Payload Length in IPv6 header
302 by size of in-band OAM ext header
303 }
305 4. In-band OAM Metadata Transport in VXLAN-GPE
307 VXLAN-GPE [I-D.ietf-nvo3-vxlan-gpe] encapsulation is somewhat similar
308 to IPv6 extension headers in that a series of headers can be
309 contained in the header as a linked list. The different in-band OAM
310 types are added as options within a new in-band OAM protocol header
311 in VXLAN GPE.
313 In-band OAM header in VXLAN GPE header:
315 0 1 2 3
316 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
317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
318 | Outer Ethernet Header |
319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
320 | Outer IP Header |
321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
322 | Outer UDP Header |
323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
324 |R|R|Ver|I|P|R|O| Reserved | NP = i.b.OAM | |
325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ GPE
326 | Virtual Network Identifier (VNI) | Reserved | |
327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
328 | Type =i.b.OAM | i.b.OAM HDR len | Reserved | NP = IP/Eth | |
329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+iOAM
330 | in-band OAM options | |
331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
332 | |
333 | |
334 | Payload + Padding (L2/L3/ESP/...) |
335 | |
336 | |
337 | |
338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
340 The VXLAN-GPE header and fields are defined in
341 [I-D.ietf-nvo3-vxlan-gpe]. in-band OAM specific fields and header are
342 defined here:
344 Type: 8-bit unsigned integer defining in-band OAM header type
346 in-band OAM HDR len: 8-bit unsigned integer. Length of the in-band
347 OAM HDR in 8-octet units
349 in-band OAM options: Variable-length field, of length such that the
350 complete in-band OAM header is an integer multiple of 8 octets
351 long. Contains one or more TLV-encoded options of the format:
353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
354 | Option Type | Opt Data Len | Option Data
355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
357 Option Type 8-bit identifier of the type of option.
359 Opt Data Len 8-bit unsigned integer. Length of the Option
360 Data field of this option, in octets.
362 Option Data Variable-length field. Option-Type-specific
363 data.
365 The in-band OAM options defined in [draft-brockners-inband-oam-data]
366 are encoded with an option type allocated in the new in-band OAM IANA
367 registry - in-band OAM_PROTOCOL_OPTION_REGISTRY_IANA_TBD. In
368 addition the following padding options are defined to be used when
369 necessary to align subsequent options and to pad out the containing
370 header to a multiple of 8 octets in length.
372 Pad1 option (alignment requirement: none)
374 +-+-+-+-+-+-+-+-+
375 | 0 |
376 +-+-+-+-+-+-+-+-+
377 NOTE: The format of the Pad1 option is a special case -- it does
378 not have length and value fields.
380 The Pad1 option is used to insert one octet of padding into the
381 Options area of a header. If more than one octet of padding is
382 required, the PadN option, described next, should be used, rather
383 than multiple Pad1 options.
385 PadN option (alignment requirement: none)
387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
388 | 1 | Opt Data Len | Option Data
389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
390 The PadN option is used to insert two or more octets of padding
391 into the Options area of a header. For N octets of padding, the
392 Opt Data Len field contains the value N-2, and the Option Data
393 consists of N-2 zero-valued octets.
395 5. In-band OAM Metadata Transport in NSH
397 In Service Function Chaining (SFC) [RFC7665], the Network Service
398 Header (NSH) [I-D.ietf-sfc-nsh] already includes path tracing
399 capabilities [I-D.penno-sfc-trace], but currently does not offer a
400 solution to securely prove that packets really traversed the service
401 chain. The "Proof of Transit" capabilities (see
402 [draft-brockners-inband-oam-requirements] and
403 [draft-brockners-proof-of-transit]) of in-band OAM can be leveraged
404 within NSH. Proof of transit in-band OAM data is added as NSH Type 2
405 metadata:
407 0 1 2 3
408 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
409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
410 | TLV Class=Cisco (0x0009) |C| Type=POT |F|R|R| Len=4 |
411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+
412 | Random | |
413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ S
414 | Random(contd) | C
415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ V
416 | Cumulative | |
417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
418 | Cumulative (contd) | |
419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+
421 TLV Class: Describes the scope of the "Type" field. In some cases,
422 the TLV Class will identify a specific vendor, in others, the TLV
423 Class will identify specific standards body allocated types. POT
424 is currently defined using the Cisco (0x0009) TLV class.
426 Type: The specific type of information being carried, within the
427 scope of a given TLV Class. Value allocation is the
428 responsibility of the TLV Class owner. Currently a type value of
429 0x94 is used for proof of transit
431 Reserved bits: Two reserved bit are present for future use. The
432 reserved bits MUST be set to 0x0.
434 F: One bit. Indicates which POT-profile is active. 0 means the even
435 POT-profile is active, 1 means the odd POT-profile is active.
437 Length: Length of the variable metadata, in 4-octet words. Here the
438 length is 4.
440 Random: 64-bit Per packet Random number.
442 Cumulative: 64-bit Cumulative that is updated by the Service
443 Functions.
445 6. In-band OAM Metadata Transport in Segment Routing
447 6.1. In-band OAM in SR with IPv6 Transport
449 Similar to NSH, a service chain or path defined using Segment Routing
450 for IPv6 can be verified using the in-band OAM "Proof of Transit"
451 approach. The Segment Routing Header (SRH) for IPv6 offers the
452 ability to transport TLV structured data, similar to what NSH does
453 (see [I-D.ietf-6man-segment-routing-header]). A new "POT TLV" is
454 defined for the SRH which is to carry proof of transit in-band OAM
455 data.
457 0 1 2 3
458 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
459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
460 | Type | Length | RESERVED |F| Flags |
461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+
462 | Random | |
463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ P
464 | Random(contd) | O
465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ T
466 | Cumulative | |
467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
468 | Cumulative (contd) | |
469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+
471 Type: To be assigned by IANA.
473 Length: 18.
475 RESERVED: 8 bits. SHOULD be unset on transmission and MUST be
476 ignored on receipt.
478 F: 1 bit. Indicates which POT-profile is active. 0 means the even
479 POT-profile is active, 1 means the odd POT-profile is active.
481 Flags: 8 bits. No flags are defined in this document.
483 Random: 64-bit per packet random number.
485 Cumulative: 64-bit cumulative value that is updated at specific
486 nodes that form the service path to be verified.
488 6.2. In-band OAM in SR with MPLS Transport
490 In-band OAM "Proof of Transit" data can also be carried as part of
491 the MPLS label stack. Details will be addressed in a future version
492 of this document.
494 7. IANA Considerations
496 IANA considerations will be added in a future version of this
497 document.
499 8. Manageability Considerations
501 Manageability considerations will be addressed in a later version of
502 this document..
504 9. Security Considerations
506 Security considerations will be addressed in a later version of this
507 document. For a discussion of security requirements of in-band OAM,
508 please refer to [draft-brockners-inband-oam-requirements].
510 10. Acknowledgements
512 The authors would like to thank Eric Vyncke, Nalini Elkins, Srihari
513 Raghavan, Ranganathan T S, Karthik Babu Harichandra Babu, Akshaya
514 Nadahalli, Stefano Previdi and Andrew Yourtchenko for the comments
515 and advice. For the IPv6 encapsulation, this document leverages and
516 builds on top of several concepts described in
517 [draft-kitamura-ipv6-record-route]. The authors would like to
518 acknowledge the work done by the author Hiroshi Kitamura and people
519 involved in writing it.
521 11. References
523 11.1. Normative References
525 [draft-brockners-inband-oam-requirements]
526 Brockners, F., Bhandari, S., and S. Dara, "Requirements
527 for in-band OAM", July 2016.
529 11.2. Informative References
531 [draft-brockners-inband-oam-data]
532 Brockners, F., Bhandari, S., Pignataro, C., and H.
533 Gredler, "Data Formats for in-band OAM", July 2016.
535 [draft-brockners-proof-of-transit]
536 Brockners, F., Bhandari, S., and S. Dara, "Proof of
537 transit", July 2016.
539 [draft-kitamura-ipv6-record-route]
540 Kitamura, H., "Record Route for IPv6 (PR6),Hop-by-Hop
541 Option Extension", November 2000.
543 [FD.io] "Fast Data Project: FD.io", .
545 [I-D.hildebrand-spud-prototype]
546 Hildebrand, J. and B. Trammell, "Substrate Protocol for
547 User Datagrams (SPUD) Prototype", draft-hildebrand-spud-
548 prototype-03 (work in progress), March 2015.
550 [I-D.ietf-6man-segment-routing-header]
551 Previdi, S., Filsfils, C., Field, B., Leung, I., Linkova,
552 J., Aries, E., Kosugi, T., Vyncke, E., and D. Lebrun,
553 "IPv6 Segment Routing Header (SRH)", draft-ietf-6man-
554 segment-routing-header-01 (work in progress), March 2016.
556 [I-D.ietf-ippm-6man-pdm-option]
557 Elkins, N., Hamilton, R., and m. mackermann@bcbsm.com,
558 "IPv6 Performance and Diagnostic Metrics (PDM) Destination
559 Option", draft-ietf-ippm-6man-pdm-option-03 (work in
560 progress), June 2016.
562 [I-D.ietf-nvo3-vxlan-gpe]
563 Kreeger, L. and U. Elzur, "Generic Protocol Extension for
564 VXLAN", draft-ietf-nvo3-vxlan-gpe-02 (work in progress),
565 April 2016.
567 [I-D.ietf-sfc-nsh]
568 Quinn, P. and U. Elzur, "Network Service Header", draft-
569 ietf-sfc-nsh-05 (work in progress), May 2016.
571 [I-D.ietf-spring-segment-routing]
572 Filsfils, C., Previdi, S., Decraene, B., Litkowski, S.,
573 and R. Shakir, "Segment Routing Architecture", draft-ietf-
574 spring-segment-routing-09 (work in progress), July 2016.
576 [I-D.penno-sfc-trace]
577 Penno, R., Quinn, P., Pignataro, C., and D. Zhou,
578 "Services Function Chaining Traceroute", draft-penno-sfc-
579 trace-03 (work in progress), September 2015.
581 [P4] Kim, , "P4: In-band Network Telemetry (INT)", September
582 2015.
584 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
585 Requirement Levels", BCP 14, RFC 2119,
586 DOI 10.17487/RFC2119, March 1997,
587 .
589 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function
590 Chaining (SFC) Architecture", RFC 7665,
591 DOI 10.17487/RFC7665, October 2015,
592 .
594 Authors' Addresses
596 Frank Brockners
597 Cisco Systems, Inc.
598 Hansaallee 249, 3rd Floor
599 DUESSELDORF, NORDRHEIN-WESTFALEN 40549
600 Germany
602 Email: fbrockne@cisco.com
604 Shwetha Bhandari
605 Cisco Systems, Inc.
606 Cessna Business Park, Sarjapura Marathalli Outer Ring Road
607 Bangalore, KARNATAKA 560 087
608 India
610 Email: shwethab@cisco.com
612 Carlos Pignataro
613 Cisco Systems, Inc.
614 7200-11 Kit Creek Road
615 Research Triangle Park, NC 27709
616 United States
618 Email: cpignata@cisco.com
620 Hannes Gredler
621 RtBrick Inc.
623 Email: hannes@rtbrick.com
625 John Leddy
626 Comcast
628 Email: John_Leddy@cable.comcast.com
629 Stephen Youell
630 JP Morgan Chase
631 25 Bank Street
632 London E14 5JP
633 United Kingdom
635 Email: stephen.youell@jpmorgan.com