idnits 2.17.1
draft-brockners-inband-oam-transport-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 8, 2016) is 2848 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
== Unused Reference: 'I-D.hildebrand-spud-prototype' is defined on line
541, but no explicit reference was found in the text
== Unused Reference: 'P4' is defined on line 577, 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 9, 2017 Cisco
6 H. Gredler
7 RtBrick Inc.
8 July 8, 2016
10 Encapsulations for In-band OAM Data
11 draft-brockners-inband-oam-transport-00
13 Abstract
15 In-band operation, administration and maintenance (OAM) records
16 operational and telemetry information in the packet while the packet
17 traverses a path between two points in the network. In-band OAM is
18 to complement current out-of-band OAM mechanisms based on ICMP or
19 other types of probe packets. This document outlines how in-band OAM
20 data records can be transported in protocols such as NSH, Segment
21 Routing, VXLAN-GPE, native IPv6 (via extension header), and IPv4.
22 Transport options are currently investigated as part of an
23 implementation study. This document is intended to only serve
24 informational purposes.
26 Status of This Memo
28 This Internet-Draft is submitted in full conformance with the
29 provisions of BCP 78 and BCP 79.
31 Internet-Drafts are working documents of the Internet Engineering
32 Task Force (IETF). Note that other groups may also distribute
33 working documents as Internet-Drafts. The list of current Internet-
34 Drafts is at http://datatracker.ietf.org/drafts/current/.
36 Internet-Drafts are draft documents valid for a maximum of six months
37 and may be updated, replaced, or obsoleted by other documents at any
38 time. It is inappropriate to use Internet-Drafts as reference
39 material or to cite them other than as "work in progress."
41 This Internet-Draft will expire on January 9, 2017.
43 Copyright Notice
45 Copyright (c) 2016 IETF Trust and the persons identified as the
46 document authors. All rights reserved.
48 This document is subject to BCP 78 and the IETF Trust's Legal
49 Provisions Relating to IETF Documents
50 (http://trustee.ietf.org/license-info) in effect on the date of
51 publication of this document. Please review these documents
52 carefully, as they describe your rights and restrictions with respect
53 to this document. Code Components extracted from this document must
54 include Simplified BSD License text as described in Section 4.e of
55 the Trust Legal Provisions and are provided without warranty as
56 described in the Simplified BSD License.
58 Table of Contents
60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
61 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
62 3. In-Band OAM Metadata Transport in IPv6 . . . . . . . . . . . 4
63 3.1. In-band OAM in IPv6 Hop by Hop Extension Header . . . . . 4
64 3.1.1. In-band OAM Hop by Hop Options . . . . . . . . . . . 4
65 3.1.2. Procedure at the Ingress Edge to Insert the In-band
66 OAM Header . . . . . . . . . . . . . . . . . . . . . 6
67 3.1.3. Procedure at Intermediate Nodes . . . . . . . . . . . 7
68 3.1.4. Procedure at the Egress Edge to Remove the In-band
69 OAM Header . . . . . . . . . . . . . . . . . . . . . 7
70 4. In-band OAM Metadata Transport in VXLAN-GPE . . . . . . . . . 7
71 5. In-band OAM Metadata Transport in NSH . . . . . . . . . . . . 9
72 6. In-band OAM Metadata Transport in Segment Routing . . . . . . 11
73 6.1. In-band OAM in SR with IPv6 Transport . . . . . . . . . . 11
74 6.2. In-band OAM in SR with MPLS Transport . . . . . . . . . . 11
75 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
76 8. Manageability Considerations . . . . . . . . . . . . . . . . 12
77 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12
78 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
79 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
80 11.1. Normative References . . . . . . . . . . . . . . . . . . 12
81 11.2. Informative References . . . . . . . . . . . . . . . . . 12
82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
84 1. Introduction
86 This document discusses transport mechanisms for "in-band" operation,
87 administration, and maintenance (OAM) data records. In-band OAM
88 records OAM information within the packet while the packet traverses
89 a particular network domain. The term "in-band" refers to the fact
90 that the OAM data is added to the data packets rather than is being
91 sent within packets specifically dedicated to OAM. A discussion of
92 the motivation and requirements for in-band OAM can be found in
93 [draft-brockners-inband-oam-requirements]. Data types and data
94 formats for in-band OAM are defined in
95 [draft-brockners-inband-oam-data].
97 This document outlines transport encapsulations for the in-band OAM
98 data defined in [draft-brockners-inband-oam-data]. This document is
99 to serve informational purposes only. As part of an in-band OAM
100 implementation study different protocol encapsulations for in-band
101 OAM data are being explored. Once data formats and encapsulation
102 approaches are settled, protocol specific specifications for in-band
103 OAM data transport will address the standardization aspect.
105 The data for in-band OAM defined in [draft-brockners-inband-oam-data]
106 can be carried in a variety of protocols based on the deployment
107 needs. This document discusses transport of in-band OAM data for the
108 following protocols:
110 o IPv6
112 o VXLAN-GPE
114 o NSH
116 o Segment Routing (IPv6 and MPLS)
118 This list is non-exhaustive, as it is possible to carry the in-band
119 OAM data in several other protocols and transports.
121 A feasibility study of in-band OAM is currently underway as part of
122 the FD.io project [FD.io]. The in-band OAM implementation study
123 should be considered as a "tool box" to showcase how "in-band" OAM
124 can complement probe-packet based OAM mechanisms for different
125 deployments and packet transport formats. For details, see the open
126 source code in the FD.io [FD.io].
128 2. Conventions
130 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
131 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
132 document are to be interpreted as described in [RFC2119].
134 Abbreviations used in this document:
136 MTU: Maximum Transmit Unit
138 OAM: Operations, Administration, and Maintenance
140 SR: Segment Routing
142 SID: Segment Identifier
144 NSH: Network Service Header
145 POT: Proof of Transit
147 SFC: Service Function Chain
149 VXLAN-GPE: Virtual eXtensible Local Area Network, Generic Protocol
150 Extension
152 3. In-Band OAM Metadata Transport in IPv6
154 This mechanisms of in-band OAM in IPv6 complement others proposed to
155 enhance diagnostics of IPv6 networks, such as the IPv6 Performance
156 and Diagnostic Metrics Destination Option described in
157 [I-D.ietf-ippm-6man-pdm-option]. The IP Performance and Diagnostic
158 Metrics Destination Option is destination focused and specific to
159 IPv6, whereas in-band OAM is performed between end-points of the
160 network or a network domain where it is enabled and used.
162 A historical note: The idea of IPv6 route recording was originally
163 introduced by [draft-kitamura-ipv6-record-route] back in year 2000.
164 With IPv6 now being generally deployed and new concepts such as
165 Segment Routing [I-D.ietf-spring-segment-routing] being introduced,
166 it is imperative to further mature the operations, administration,
167 and maintenance mechanisms available to IPv6 networks.
169 The in-band OAM options translate into options for an IPv6 extension
170 header. The extension header would be inserted by either a host
171 source of the packet, or by a transit/domain-edge node.
173 3.1. In-band OAM in IPv6 Hop by Hop Extension Header
175 This section defines in-band OAM for IPv6 transport. In-band OAM
176 data is transported as an IPv6 hop-by-hop extension header.
178 3.1.1. In-band OAM Hop by Hop Options
180 Brief recap of the IPv6 hop-by-hop header as well as the options used
181 for carrying in-band OAM data:
183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
184 | Next Header | Hdr Ext Len | |
185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
186 | |
187 . .
188 . Options .
189 . .
190 | |
191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
194 | Option Type | Opt Data Len | Option Data
195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
197 With 2 highest order bits of Option Type indicating the following:
199 00 - skip over this option and continue processing the header.
201 01 - discard the packet.
203 10 - discard the packet and, regardless of whether or not the
204 packet's Destination Address was a multicast address, send an
205 ICMP Parameter Problem, Code 2, message to the packet's
206 Source Address, pointing to the unrecognized Option Type.
208 11 - discard the packet and, only if the packet's Destination
209 Address was not a multicast address, send an ICMP Parameter
210 Problem, Code 2, message to the packet's Source Address,
211 pointing to the unrecognized Option Type.
213 3rd highest bit:
215 0 - Option Data does not change en-route
217 1 - Option Data may change en-route
219 In-band OAM data records are inserted as options in an IPv6 hop-by-
220 hop extension header:
222 1. Tracing Option: The in-band OAM Tracing option defined in
223 [draft-brockners-inband-oam-data] is represented as a IPv6 option
224 in hop by hop extension header by allocating following type:
226 Option Type: 001xxxxxx 8-bit identifier of the type of option.
227 xxxxxx=TBD_IANA_TRACE_OPTION_IPV6.
229 2. Proof of Transit Option: The in-band OAM POT option defined in
230 [draft-brockners-inband-oam-data] is represented as a IPv6 option
231 in hop by hop extension header by allocating following type:
233 Option Type: 001xxxxxx 8-bit identifier of the type of option.
234 xxxxxx=TBD_IANA_POT_OPTION_IPV6.
236 3. Edge to Edge Option: The in-band OAM E2E option defined in
237 [draft-brockners-inband-oam-data] is represented as a IPv6 option
238 in hop by hop extension header by allocating following type:
240 Option Type: 000xxxxxx 8-bit identifier of the type of option.
241 xxxxxx=TBD_IANA_E2E_OPTION_IPV6.
243 3.1.2. Procedure at the Ingress Edge to Insert the In-band OAM Header
245 In an administrative domain where in-band OAM is used, insertion of
246 the in-band OAM header is enabled at the required edge nodes by means
247 of configuration.
249 Such a config SHOULD allow selective enablement of in-band OAM header
250 insertion for a subset of traffic (e.g., one or several "pipes").
252 Further the ingress edge node should be aware of maximum size of the
253 header that can be inserted. Details on how the maximum size/size of
254 the in-band OAM domain are retrieved are outside the scope of this
255 document.
257 Let n = max number of nodes to be allocated;
258 (Based on PMTU advertised in the domain)
260 Let k = number of node data that can be allocated by this node
261 Let node_data_size = size of each node_data based on in-band OAM type
263 if (packet matches traffic for which in-band OAM is enabled) {
264 Create in-band OAM hbyh ext header with k node data preallocated
265 Increment payload length in IPv6 header :
266 with size of in-band OAM hbyh ext header
267 Populate node data at :
268 (size of in-band OAM hbyh header = 8) + k * node_data_size
269 from the beginning of the header
270 Set segments left to : k - 1
272 }
274 3.1.3. Procedure at Intermediate Nodes
276 If a network node receives a packet with an in-band OAM header and it
277 is enabled to process in-band OAM data it performs the following:
279 k = number of node data that this node can allocate
280 if (in-band OAM ext hbyh header is present) {
281 if (Segments Left > 0)) {
282 populate node data at :
283 node_data_start[Segments Left]
284 Segments Left = Segments Left - 1
285 }
286 }
288 3.1.4. Procedure at the Egress Edge to Remove the In-band OAM Header
290 egress_edge = list of interfaces where in-band OAM hbyh ext
291 header is to be stripped
292 Before forwarding packet out of interfaces in egress_edge list:
293 if (in-band OAM hbyh ext header is present) {
294 remove the in-band OAM hbyh ext header,
295 possibly store the record along with additional
296 fields for analysis and export
297 Decrement Payload Length in IPv6 header
298 by size of in-band OAM ext header
299 }
301 4. In-band OAM Metadata Transport in VXLAN-GPE
303 VXLAN-GPE [I-D.ietf-nvo3-vxlan-gpe] encapsulation is somewhat similar
304 to IPv6 extension headers in that a series of headers can be
305 contained in the header as a linked list. The different in-band OAM
306 types are added as options within a new in-band OAM protocol header
307 in VXLAN GPE.
309 In-band OAM header in VXLAN GPE header:
311 0 1 2 3
312 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
313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
314 | Outer Ethernet Header |
315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
316 | Outer IP Header |
317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
318 | Outer UDP Header |
319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
320 |R|R|Ver|I|P|R|O| Reserved | NP = i.b.OAM | |
321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ GPE
322 | Virtual Network Identifier (VNI) | Reserved | |
323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
324 | Type =i.b.OAM | i.b.OAM HDR len | Reserved | NP = IP/Eth | |
325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+iOAM
326 | in-band OAM options | |
327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
328 | |
329 | |
330 | Payload + Padding (L2/L3/ESP/...) |
331 | |
332 | |
333 | |
334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
336 The VXLAN-GPE header and fields are defined in
337 [I-D.ietf-nvo3-vxlan-gpe]. in-band OAM specific fields and header are
338 defined here:
340 Type: 8-bit unsigned integer defining in-band OAM header type
342 in-band OAM HDR len: 8-bit unsigned integer. Length of the in-band
343 OAM HDR in 8-octet units
345 in-band OAM options: Variable-length field, of length such that the
346 complete in-band OAM header is an integer multiple of 8 octets
347 long. Contains one or more TLV-encoded options of the format:
349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
350 | Option Type | Opt Data Len | Option Data
351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
353 Option Type 8-bit identifier of the type of option.
355 Opt Data Len 8-bit unsigned integer. Length of the Option
356 Data field of this option, in octets.
358 Option Data Variable-length field. Option-Type-specific
359 data.
361 The in-band OAM options defined in [draft-brockners-inband-oam-data]
362 are encoded with an option type allocated in the new in-band OAM IANA
363 registry - in-band OAM_PROTOCOL_OPTION_REGISTRY_IANA_TBD. In
364 addition the following padding options are defined to be used when
365 necessary to align subsequent options and to pad out the containing
366 header to a multiple of 8 octets in length.
368 Pad1 option (alignment requirement: none)
370 +-+-+-+-+-+-+-+-+
371 | 0 |
372 +-+-+-+-+-+-+-+-+
373 NOTE: The format of the Pad1 option is a special case -- it does
374 not have length and value fields.
376 The Pad1 option is used to insert one octet of padding into the
377 Options area of a header. If more than one octet of padding is
378 required, the PadN option, described next, should be used, rather
379 than multiple Pad1 options.
381 PadN option (alignment requirement: none)
383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
384 | 1 | Opt Data Len | Option Data
385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
386 The PadN option is used to insert two or more octets of padding
387 into the Options area of a header. For N octets of padding, the
388 Opt Data Len field contains the value N-2, and the Option Data
389 consists of N-2 zero-valued octets.
391 5. In-band OAM Metadata Transport in NSH
393 In Service Function Chaining (SFC) [RFC7665], the Network Service
394 Header (NSH) [I-D.ietf-sfc-nsh] already includes path tracing
395 capabilities [I-D.penno-sfc-trace], but currently does not offer a
396 solution to securely prove that packets really traversed the service
397 chain. The "Proof of Transit" capabilities (see
398 [draft-brockners-inband-oam-requirements] and
399 [draft-brockners-proof-of-transit]) of in-band OAM can be leveraged
400 within NSH. Proof of transit in-band OAM data is added as NSH Type 2
401 metadata:
403 0 1 2 3
404 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
405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
406 | TLV Class=Cisco (0x0009) |C| Type=POT |F|R|R| Len=4 |
407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+
408 | Random | |
409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ S
410 | Random(contd) | C
411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ V
412 | Cumulative | |
413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
414 | Cumulative (contd) | |
415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+
417 TLV Class: Describes the scope of the "Type" field. In some cases,
418 the TLV Class will identify a specific vendor, in others, the TLV
419 Class will identify specific standards body allocated types. POT
420 is currently defined using the Cisco (0x0009) TLV class.
422 Type: The specific type of information being carried, within the
423 scope of a given TLV Class. Value allocation is the
424 responsibility of the TLV Class owner. Currently a type value of
425 0x94 is used for proof of transit
427 Reserved bits: Two reserved bit are present for future use. The
428 reserved bits MUST be set to 0x0.
430 F: One bit. Indicates which POT-profile is active. 0 means the even
431 POT-profile is active, 1 means the odd POT-profile is active.
433 Length: Length of the variable metadata, in 4-octet words. Here the
434 length is 4.
436 Random: 64-bit Per packet Random number.
438 Cumulative: 64-bit Cumulative that is updated by the Service
439 Functions.
441 6. In-band OAM Metadata Transport in Segment Routing
443 6.1. In-band OAM in SR with IPv6 Transport
445 Similar to NSH, a service chain or path defined using Segment Routing
446 for IPv6 can be verified using the in-band OAM "Proof of Transit"
447 approach. The Segment Routing Header (SRH) for IPv6 offers the
448 ability to transport TLV structured data, similar to what NSH does
449 (see [I-D.ietf-6man-segment-routing-header]). A new "POT TLV" is
450 defined for the SRH which is to carry proof of transit in-band OAM
451 data.
453 0 1 2 3
454 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
455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
456 | Type | Length | RESERVED |F| Flags |
457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+
458 | Random | |
459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ P
460 | Random(contd) | O
461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ T
462 | Cumulative | |
463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
464 | Cumulative (contd) | |
465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+
467 Type: To be assigned by IANA.
469 Length: 18.
471 RESERVED: 8 bits. SHOULD be unset on transmission and MUST be
472 ignored on receipt.
474 F: 1 bit. Indicates which POT-profile is active. 0 means the even
475 POT-profile is active, 1 means the odd POT-profile is active.
477 Flags: 8 bits. No flags are defined in this document.
479 Random: 64-bit per packet random number.
481 Cumulative: 64-bit cumulative value that is updated at specific
482 nodes that form the service path to be verified.
484 6.2. In-band OAM in SR with MPLS Transport
486 In-band OAM "Proof of Transit" data can also be carried as part of
487 the MPLS label stack. Details will be addressed in a future version
488 of this document.
490 7. IANA Considerations
492 IANA considerations will be added in a future version of this
493 document.
495 8. Manageability Considerations
497 Manageability considerations will be addressed in a later version of
498 this document..
500 9. Security Considerations
502 Security considerations will be addressed in a later version of this
503 document. For a discussion of security requirements of in-band OAM,
504 please refer to [draft-brockners-inband-oam-requirements].
506 10. Acknowledgements
508 The authors would like to thank Steve Youell, Eric Vyncke, Nalini
509 Elkins, Srihari Raghavan, Ranganathan T S, Karthik Babu Harichandra
510 Babu, Akshaya Nadahalli, and Andrew Yourtchenko for the comments and
511 advice. For the IPv6 encapsulation, this document leverages and
512 builds on top of several concepts described in
513 [draft-kitamura-ipv6-record-route]. The authors would like to
514 acknowledge the work done by the author Hiroshi Kitamura and people
515 involved in writing it.
517 11. References
519 11.1. Normative References
521 [draft-brockners-inband-oam-requirements]
522 Brockners, F., Bhandari, S., and S. Dara, "Requirements
523 for in-band OAM", July 2016.
525 11.2. Informative References
527 [draft-brockners-inband-oam-data]
528 Brockners, F., Bhandari, S., Pignataro, C., and H.
529 Gredler, "Data Formats for in-band OAM", July 2016.
531 [draft-brockners-proof-of-transit]
532 Brockners, F., Bhandari, S., and S. Dara, "Proof of
533 transit", July 2016.
535 [draft-kitamura-ipv6-record-route]
536 Kitamura, H., "Record Route for IPv6 (PR6),Hop-by-Hop
537 Option Extension", November 2000.
539 [FD.io] "Fast Data Project: FD.io", .
541 [I-D.hildebrand-spud-prototype]
542 Hildebrand, J. and B. Trammell, "Substrate Protocol for
543 User Datagrams (SPUD) Prototype", draft-hildebrand-spud-
544 prototype-03 (work in progress), March 2015.
546 [I-D.ietf-6man-segment-routing-header]
547 Previdi, S., Filsfils, C., Field, B., Leung, I., Linkova,
548 J., Aries, E., Kosugi, T., Vyncke, E., and D. Lebrun,
549 "IPv6 Segment Routing Header (SRH)", draft-ietf-6man-
550 segment-routing-header-01 (work in progress), March 2016.
552 [I-D.ietf-ippm-6man-pdm-option]
553 Elkins, N., Hamilton, R., and m. mackermann@bcbsm.com,
554 "IPv6 Performance and Diagnostic Metrics (PDM) Destination
555 Option", draft-ietf-ippm-6man-pdm-option-03 (work in
556 progress), June 2016.
558 [I-D.ietf-nvo3-vxlan-gpe]
559 Kreeger, L. and U. Elzur, "Generic Protocol Extension for
560 VXLAN", draft-ietf-nvo3-vxlan-gpe-02 (work in progress),
561 April 2016.
563 [I-D.ietf-sfc-nsh]
564 Quinn, P. and U. Elzur, "Network Service Header", draft-
565 ietf-sfc-nsh-05 (work in progress), May 2016.
567 [I-D.ietf-spring-segment-routing]
568 Filsfils, C., Previdi, S., Decraene, B., Litkowski, S.,
569 and R. Shakir, "Segment Routing Architecture", draft-ietf-
570 spring-segment-routing-09 (work in progress), July 2016.
572 [I-D.penno-sfc-trace]
573 Penno, R., Quinn, P., Pignataro, C., and D. Zhou,
574 "Services Function Chaining Traceroute", draft-penno-sfc-
575 trace-03 (work in progress), September 2015.
577 [P4] Kim, , "P4: In-band Network Telemetry (INT)", September
578 2015.
580 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
581 Requirement Levels", BCP 14, RFC 2119,
582 DOI 10.17487/RFC2119, March 1997,
583 .
585 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function
586 Chaining (SFC) Architecture", RFC 7665,
587 DOI 10.17487/RFC7665, October 2015,
588 .
590 Authors' Addresses
592 Frank Brockners
593 Cisco Systems, Inc.
594 Hansaallee 249, 3rd Floor
595 DUESSELDORF, NORDRHEIN-WESTFALEN 40549
596 Germany
598 Email: fbrockne@cisco.com
600 Shwetha Bhandari
601 Cisco Systems, Inc.
602 Cessna Business Park, Sarjapura Marathalli Outer Ring Road
603 Bangalore, KARNATAKA 560 087
604 India
606 Email: shwethab@cisco.com
608 Carlos Pignataro
609 Cisco Systems, Inc.
610 7200-11 Kit Creek Road
611 Research Triangle Park, NC 27709
612 United States
614 Email: cpignata@cisco.com
616 Hannes Gredler
617 RtBrick Inc.
619 Email: hannes@rtbrick.com