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