idnits 2.17.1 draft-brockners-inband-oam-transport-04.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 02, 2017) is 2491 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '0' on line 824 -- Looks like a reference, but probably isn't: '1' on line 828 == Outdated reference: A later version (-07) exists of draft-brockners-inband-oam-data-05 == Outdated reference: A later version (-26) exists of draft-ietf-6man-segment-routing-header-06 == Outdated reference: A later version (-13) exists of draft-ietf-nvo3-vxlan-gpe-04 == Outdated reference: A later version (-28) exists of draft-ietf-sfc-nsh-13 == Outdated reference: A later version (-05) exists of draft-brockners-proof-of-transit-03 == Outdated reference: A later version (-15) exists of draft-ietf-spring-segment-routing-12 Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ippm F. Brockners 3 Internet-Draft S. Bhandari 4 Intended status: Informational V. Govindan 5 Expires: January 3, 2018 C. Pignataro 6 Cisco 7 H. Gredler 8 RtBrick Inc. 9 J. Leddy 10 Comcast 11 S. Youell 12 JMPC 13 T. Mizrahi 14 Marvell 15 D. Mozes 16 Mellanox Technologies Ltd. 17 P. Lapukhov 18 Facebook 19 R. Chang 20 Barefoot Networks 21 July 02, 2017 23 Encapsulations for In-situ OAM Data 24 draft-brockners-inband-oam-transport-04 26 Abstract 28 In-situ Operations, Administration, and Maintenance (OAM) records 29 operational and telemetry information in the packet while the packet 30 traverses a path between two points in the network. In-situ OAM is 31 to complement current out-of-band OAM mechanisms based on ICMP or 32 other types of probe packets. This document outlines how in-situ OAM 33 data fields can be transported in protocols such as NSH, Segment 34 Routing, VXLAN-GPE, native IPv6 (via extension headers), and IPv4. 35 Transport options are currently investigated as part of an 36 implementation study. This document is intended to only serve 37 informational purposes. 39 Status of This Memo 41 This Internet-Draft is submitted in full conformance with the 42 provisions of BCP 78 and BCP 79. 44 Internet-Drafts are working documents of the Internet Engineering 45 Task Force (IETF). Note that other groups may also distribute 46 working documents as Internet-Drafts. The list of current Internet- 47 Drafts is at http://datatracker.ietf.org/drafts/current/. 49 Internet-Drafts are draft documents valid for a maximum of six months 50 and may be updated, replaced, or obsoleted by other documents at any 51 time. It is inappropriate to use Internet-Drafts as reference 52 material or to cite them other than as "work in progress." 54 This Internet-Draft will expire on January 3, 2018. 56 Copyright Notice 58 Copyright (c) 2017 IETF Trust and the persons identified as the 59 document authors. All rights reserved. 61 This document is subject to BCP 78 and the IETF Trust's Legal 62 Provisions Relating to IETF Documents 63 (http://trustee.ietf.org/license-info) in effect on the date of 64 publication of this document. Please review these documents 65 carefully, as they describe your rights and restrictions with respect 66 to this document. Code Components extracted from this document must 67 include Simplified BSD License text as described in Section 4.e of 68 the Trust Legal Provisions and are provided without warranty as 69 described in the Simplified BSD License. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 74 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 75 3. In-Situ OAM Metadata Transport in IPv6 . . . . . . . . . . . 4 76 3.1. In-situ OAM in IPv6 Hop by Hop Extension Header . . . . . 5 77 3.1.1. In-situ OAM Hop by Hop Options . . . . . . . . . . . 5 78 4. In-situ OAM Metadata Transport in IPv4 . . . . . . . . . . . 7 79 4.1. In-situ OAM Tracing in GRE . . . . . . . . . . . . . . . 7 80 4.2. In-situ OAM POT in GRE . . . . . . . . . . . . . . . . . 10 81 4.3. In-situ OAM End-to-End in GRE . . . . . . . . . . . . . . 12 82 5. In-situ OAM Metadata Transport in VXLAN-GPE . . . . . . . . . 12 83 5.1. In-situ OAM Tracing in VXLAN-GPE . . . . . . . . . . . . 13 84 5.2. In-situ OAM POT in VXLAN-GPE . . . . . . . . . . . . . . 16 85 5.3. In-situ OAM Edge-to-Edge in VXLAN-GPE . . . . . . . . . . 18 86 6. In-situ OAM Metadata Transport in NSH . . . . . . . . . . . . 18 87 6.1. In-situ OAM Tracing in NSH . . . . . . . . . . . . . . . 18 88 6.2. In-situ OAM POT in NSH . . . . . . . . . . . . . . . . . 22 89 6.3. In-situ OAM Edge-to-Edge in NSH . . . . . . . . . . . . . 24 90 7. In-situ OAM Metadata Transport in Segment Routing . . . . . . 25 91 7.1. In-situ OAM in SR with IPv6 Transport . . . . . . . . . . 25 92 7.2. In-situ OAM in SR with MPLS Transport . . . . . . . . . . 26 93 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 94 9. Manageability Considerations . . . . . . . . . . . . . . . . 26 95 10. Security Considerations . . . . . . . . . . . . . . . . . . . 26 96 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 97 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 98 12.1. Normative References . . . . . . . . . . . . . . . . . . 27 99 12.2. Informative References . . . . . . . . . . . . . . . . . 28 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 102 1. Introduction 104 This document discusses transport mechanisms for "in-situ" 105 Operations, Administration, and Maintenance (OAM) data fields. In- 106 situ OAM records OAM information within the packet while the packet 107 traverses a particular network domain. The term "in-situ" refers to 108 the fact that the OAM data is added to the data packets rather than 109 is being sent within packets specifically dedicated to OAM. A 110 discussion of the motivation and requirements for in-situ OAM can be 111 found in [I-D.brockners-inband-oam-requirements]. Data types and 112 data formats for in-situ OAM are defined in 113 [I-D.brockners-inband-oam-data]. 115 This document outlines transport encapsulations for the in-situ OAM 116 data defined in [I-D.brockners-inband-oam-data]. This document is to 117 serve informational purposes only. As part of an in-situ OAM 118 implementation study different protocol encapsulations for in-situ 119 OAM data are being explored. Once data formats and encapsulation 120 approaches are settled, protocol specific specifications for in-situ 121 OAM data transport will address the standardization aspect. 123 The data for in-situ OAM defined in [I-D.brockners-inband-oam-data] 124 can be carried in a variety of protocols based on the deployment 125 needs. This document discusses transport of in-situ OAM data for the 126 following protocols: 128 o IPv6 130 o IPv4 132 o VXLAN-GPE 134 o NSH 136 o Segment Routing (IPv6 and MPLS) 138 This list is non-exhaustive, as it is possible to carry the in-situ 139 OAM data in several other protocols and transports. 141 A feasibility study of in-situ OAM is currently underway as part of 142 the FD.io project [FD.io]. The in-situ OAM implementation study 143 should be considered as a "tool box" to showcase how "in-situ" OAM 144 can complement probe-packet based OAM mechanisms for different 145 deployments and packet transport formats. For details, see the open 146 source code in the FD.io [FD.io]. 148 2. Conventions 150 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 151 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 152 document are to be interpreted as described in [RFC2119]. 154 Abbreviations used in this document: 156 IOAM: In-situ Operations, Administration, and Maintenance 158 MTU: Maximum Transmit Unit 160 NSH: Network Service Header 162 OAM: Operations, Administration, and Maintenance 164 POT: Proof of Transit 166 SFC: Service Function Chain 168 SID: Segment Identifier 170 SR: Segment Routing 172 VXLAN-GPE: Virtual eXtensible Local Area Network, Generic Protocol 173 Extension 175 3. In-Situ OAM Metadata Transport in IPv6 177 This mechanisms of in-situ OAM in IPv6 complement others proposed to 178 enhance diagnostics of IPv6 networks, such as the IPv6 Performance 179 and Diagnostic Metrics Destination Option described in 180 [I-D.ietf-ippm-6man-pdm-option]. The IP Performance and Diagnostic 181 Metrics Destination Option is destination focused and specific to 182 IPv6, whereas in-situ OAM is performed between end-points of the 183 network or a network domain where it is enabled and used. 185 A historical note: The idea of IPv6 route recording was originally 186 introduced by [I-D.kitamura-ipv6-record-route] back in year 2000. 187 With IPv6 now being generally deployed and new concepts such as 188 Segment Routing [I-D.ietf-spring-segment-routing] being introduced, 189 it is imperative to further mature the Operations, Administration, 190 and Maintenance mechanisms available to IPv6 networks. 192 The in-situ OAM options translate into options for an IPv6 hop by hop 193 extension header. The extension header would be inserted by either a 194 host source of the packet, or by a transit/domain-edge node. If the 195 addition of the in-situ OAM Hop-by-Hop Option header would lead to 196 the packet exceeding the MTU of the domain an error should be 197 reported. The methods and procedures of how the error is reported 198 are outside the scope of this document. Likewise if an ICMPv6 199 forwarding error occurs between encapsulating and decapsulating 200 nodes, the node generating the ICMPv6 error should strip the in-situ 201 OAM Hop-by-Hop Option header before sending the ICMPv6 message to the 202 source. 204 3.1. In-situ OAM in IPv6 Hop by Hop Extension Header 206 This section defines in-situ OAM for IPv6 transport. In-situ OAM 207 Options are transported in IPv6 hop-by-hop extension header. 209 3.1.1. In-situ OAM Hop by Hop Options 211 IPv6 hop-by-hop option format for carrying in-situ OAM data fields: 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 | Option Type | Opt Data Len | Reserved (MBZ) | 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ 216 | | | 217 . . I 218 . Option Data . O 219 . . A 220 . . M 221 . . . 222 . . O 223 . . P 224 . . T 225 . . I 226 . . O 227 . . N 228 . . | 229 | | | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ 232 Option Type 8-bit identifier of the type of option. 234 Opt Data Len 8-bit unsigned integer. Length of the 235 Reserved and Option Data field of this option, 236 in octets. 238 Reserved (MBZ) 16-bit field MUST be filled with zeroes. 240 Option Data Variable-length field. Option-Type-specific 241 data. 243 In-situ OAM Options are inserted as Option data as follows: 245 1. Pre-allocated Tracing Option: The in-situ OAM Preallocated 246 Tracing option defined in [I-D.brockners-inband-oam-data] is 247 represented as a IPv6 option in hop by hop extension header by 248 allocating following type: 250 Option Type: 001xxxxxx 8-bit identifier of the type of option. 251 xxxxxx=TBD_IANA_PRE_TRACE_OPTION_IPV6. 253 2. Incremental Tracing Option: The in-situ OAM Incremental Tracing 254 option defined in [I-D.brockners-inband-oam-data] is represented 255 as a IPv6 option in hop by hop extension header by allocating 256 following type: 258 Option Type: 001xxxxxx 8-bit identifier of the type of option. 259 xxxxxx=TBD_IANA_INCR_TRACE_OPTION_IPV6. 261 3. Proof of Transit Option: The in-situ OAM POT option defined in 262 [I-D.brockners-inband-oam-data] is represented as a IPv6 option 263 in hop by hop extension header by allocating following type: 265 Option Type: 001xxxxxx 8-bit identifier of the type of option. 266 xxxxxx=TBD_IANA_POT_OPTION_IPV6. 268 4. Edge to Edge Option: The in-situ OAM E2E option defined in 269 [I-D.brockners-inband-oam-data] is represented as a IPv6 option 270 in hop by hop extension header by allocating following type: 272 Option Type: 000xxxxxx 8-bit identifier of the type of option. 273 xxxxxx=TBD_IANA_E2E_OPTION_IPV6. 275 4. In-situ OAM Metadata Transport in IPv4 277 Transport of in-situ OAM data in IPv4 will use GRE encapsulation. 279 GRE encapsulation is defined in [RFC2784]. IOAM is defined as a "set 280 of Protocol Types" TBD_IANA_ETHERNET_NUMBER_IOAM_* and follows GRE 281 header. These Protocol Types are defined in [RFC3232] as "ETHER 282 TYPES" and in [ETYPES]. 284 The different IOAM data fields defined in 285 [I-D.brockners-inband-oam-data] are added as TLVs following the GRE 286 header. In an administrative domain where IOAM is used, insertion of 287 the IOAM protocol header in GRE is enabled at the GRE tunnel 288 endpoints which also serve as IOAM encapsulating/decapsulating nodes 289 by means of configuration. 291 For IOAM the following new GRE protocol types are requested: 293 1. IOAM_Trace_Preallocated: 294 TBD_IANA_ETHERNET_NUMBER_IOAM_TRACE_PREALLOCATED 296 2. IOAM_Trace_Incremental: 297 TBD_IANA_ETHERNET_NUMBER_IOAM_TRACE_INCREMENTAL 299 3. IOAM_POT: TBD_IANA_ETHERNET_NUMBER_IOAM_POT 301 4. IOAM_End-to_End: TBD_IANA_ETHERNET_NUMBER_IOAM_E2E 303 4.1. In-situ OAM Tracing in GRE 305 The packet formats of the pre-allocated IOAM trace and incremental 306 IOAM trace when transported using GRE are defined as below. See 307 [I-D.brockners-inband-oam-data] for details about pre-allocated and 308 incremental IOAM trace options. 310 In-situ OAM Trace header following GRE header(Preallocated IOAM trace): 312 0 1 2 3 313 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 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ 315 |C| Reserved0 | Ver | Protocol Type = IOAM_Trace | G 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ R 317 | Checksum (optional) | Reserved1 (Optional) | E 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ 319 | Type | IOAM HDR len| Next Protocol | | 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+IOAM 321 | IOAM-Trace-Type |NodeLen| Flags | Octets-left |Trace 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ 323 | | | 324 | node data list [0] | IOAM 325 | | | 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ D 327 | | a 328 | node data list [1] | t 329 | | a 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 ~ ... ~ S 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ p 333 | | a 334 | node data list [n-1] | c 335 | | e 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 337 | | | 338 | node data list [n] | | 339 | | | 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ 341 | | 342 | Payload + Padding (L2/L3/ESP/...) | 343 | | 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 Pre-allocated Trace Option Data MUST be 4-byte aligned: 348 In-situ OAM Trace header following GRE header(Incremental IOAM trace): 350 0 1 2 3 351 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 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ 353 |C| Reserved0 | Ver |Protocol Type = IOAM_Trace | G 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ R 355 | Checksum (optional) | Reserved1 (Optional) | E 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ 357 | Type | IOAM HDR len| Next Protocol | | 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+IOAM 359 | IOAM-Trace-Type |NodeLen| Flags | Max Length |Trace 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ 361 | | | 362 | node data list [0] | IOAM 363 | | | 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ D 365 | | a 366 | node data list [1] | t 367 | | a 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 ~ ... ~ S 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ p 371 | | a 372 | node data list [n-1] | c 373 | | e 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 375 | | | 376 | node data list [n] | | 377 | | | 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ 379 | | 380 | Payload + Padding (L2/L3/ESP/...) | 381 | | 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 In-situ OAM Incremental Trace Option Data MUST be 4-byte aligned: 386 The GRE header and fields are defined in [RFC2784] with Protocol Type 387 set to TBD_IANA_ETHERNET_NUMBER_IOAM_TRACE. IOAM specific fields and 388 header are defined here: 390 Type: 8-bit unsigned integer defining IOAM header type 391 IOAM_TRACE_Preallocated or IOAM_Trace_Incremental are defined 392 here. 394 IOAM HDR Len: 8 bits Length field contains the length of the 395 variable metadata octets. 397 Next Protocol: 16 bits Next Protocol Type field contains the 398 protocol type of the packet following IOAM protocol header. These 399 Protocol Types are defined in [RFC3232] as "ETHER TYPES" and in 400 [ETYPES]. An implementation receiving a packet containing a 401 Protocol Type which is not listed in [RFC3232] or [ETYPES] SHOULD 402 discard the packet. 404 IOAM-Trace-Type: 16-bit identifier of IOAM Trace Type as defined in 405 [I-D.brockners-inband-oam-data] IOAM-Trace-Types. 407 Node Data Length: 4-bit unsigned integer as defined in 408 [I-D.brockners-inband-oam-data]. 410 Flags: 5-bit field as defined in [I-D.brockners-inband-oam-data]. 412 Octets-left: 7-bit unsigned integer as defined in 413 [I-D.brockners-inband-oam-data]. 415 Maximum-length: 7-bit unsigned integer as defined in 416 [I-D.brockners-inband-oam-data]. 418 Node data List [n]: Variable-length field as defined in 419 [I-D.brockners-inband-oam-data]. 421 4.2. In-situ OAM POT in GRE 422 In-situ OAM POT header following GRE header: 424 0 1 2 3 425 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 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ 427 |C| Reserved0 | Ver | Protocol Type = IOAM_POT | G 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ R 429 | Checksum (optional) | Reserved1 (Optional) | E 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ 431 |IOAM POT Type|P| IOAM HDR len| Next Protocol | | 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+IOAM 433 | Random | | 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ P 435 | Random(contd.) | O 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ T 437 | Cumulative | | 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 439 | Cumulative (contd.) | | 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ 441 | | 442 | Payload + Padding (L2/L3/ESP/...) | 443 | | 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 The GRE header and fields are defined in [RFC2784] with Protocol Type 447 set to TBD_IANA_ETHERNET_NUMBER_IOAM_POT. IOAM specific fields and 448 header are defined here: 450 IOAM POT Type: 7-bit identifier of a particular POT variant that 451 dictates the POT data that is included as defined in 452 [I-D.brockners-inband-oam-data]. 454 Profile to use (P): 1-bit as defined in 455 [I-D.brockners-inband-oam-data] IOAM POT Option. 457 IOAM HDR Len: 8 bits Length field contains the length of the 458 variable metadata octets. 460 Next Protocol: 16 bits Next Protocol Type field contains the 461 protocol type of the packet following IOAM protocol header. These 462 Protocol Types are defined in [RFC3232] as "ETHER TYPES" and in 463 [ETYPES]. An implementation receiving a packet containing a 464 Protocol Type which is not listed in [RFC3232] or [ETYPES] SHOULD 465 discard the packet. 467 Random: 64-bit Per-packet random number. 469 Cumulative: 64-bit Cumulative value that is updated by the Service 470 Functions. 472 4.3. In-situ OAM End-to-End in GRE 474 In-situ OAM End-to-End header following GRE header: 476 0 1 2 3 477 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 478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ 479 |C| Reserved0 | Ver | Protocol Type = IOAM_E2E | G 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ R 481 | Checksum (optional) | Reserved1 (Optional) | E 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ 483 |IOAM_E2E_Type | IOAM HDR len| Next Protocol | | 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+IOAM 485 | E2E Option data field determined by IOAM-E2E-Type | | 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ 487 | | 488 | Payload + Padding (L2/L3/ESP/...) | 489 | | 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 IOAM E2E Type: 8-bit identifier of a particular E2E variant that 493 dictates the E2E data that is included as defined in 494 [I-D.brockners-inband-oam-data]. 496 IOAM HDR Len: 8 bits Length field contains the length of the 497 variable metadata octets. 499 Next Protocol: 16 bits Next Protocol Type field contains the 500 protocol type of the packet following IOAM protocol header. These 501 Protocol Types are defined in [RFC3232] as "ETHER TYPES" and in 502 [ETYPES]. An implementation receiving a packet containing a 503 Protocol Type which is not listed in [RFC3232] or [ETYPES] SHOULD 504 discard the packet. 506 E2E Option data field: Variable length field as defined in 507 [I-D.brockners-inband-oam-data] IOAM E2E Option. 509 5. In-situ OAM Metadata Transport in VXLAN-GPE 511 VXLAN-GPE [I-D.ietf-nvo3-vxlan-gpe] encapsulation is somewhat similar 512 to IPv6 extension headers in that a series of headers can be 513 contained in the header as a linked list. The different iIOAM types 514 are added as options within a new IOAM protocol header in VXLAN GPE. 515 In an administrative domain where IOAM is used, insertion of the IOAM 516 protocol header in VXLAN GPE is enabled at the VXLAN GPE tunnel 517 endpoint which also serve as IOAM encapsulating/decapsulating nodes 518 by means of configuration. 520 5.1. In-situ OAM Tracing in VXLAN-GPE 522 The packet formats of the pre-allocated IOAM trace and incremental 523 IOAM trace when transported in VXLAN-GPE are defined as below. See 524 [I-D.brockners-inband-oam-data] for details about pre-allocated and 525 incremental IOAM trace options. 527 The VXLAN-GPE header and fields are defined in 528 [I-D.ietf-nvo3-vxlan-gpe]. IOAM specific fields and header are 529 defined here: 531 In-situ OAM Trace header following VXLAN GPE header 532 (Pre-allocated trace): 534 0 1 2 3 535 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 536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 537 | Outer Ethernet Header | 538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 539 | Outer IP Header | 540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 541 | Outer UDP Header | 542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+ 543 |R|R|Ver|I|P|R|O| Reserved |NP=IOAM_Trace | | 544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ GPE 545 | Virtual Network Identifier (VNI) | Reserved | | 546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+ 547 | Type | IOAM HDR len| Reserved | Next Protocol | | 548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+IOAM 549 | IOAM-Trace-Type |NodeLen| Flags | Octets-left |Trace 550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ 551 | | | 552 | node data list [0] | IOAM 553 | | | 554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ D 555 | | a 556 | node data list [1] | t 557 | | a 558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 559 ~ ... ~ S 560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ p 561 | | a 562 | node data list [n-1] | c 563 | | e 564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 565 | | | 566 | node data list [n] | | 567 | | | 568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<--+ 569 | | 570 | | 571 | Payload + Padding (L2/L3/ESP/...) | 572 | | 573 | | 574 | | 575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 576 Pre-allocated Trace Option Data MUST be 4-byte aligned: 578 In-situ OAM Trace header following VXLAN GPE header 579 (Incremental IOAM trace): 581 0 1 2 3 582 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 583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 584 | Outer Ethernet Header | 585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 586 | Outer IP Header | 587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 588 | Outer UDP Header | 589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+ 590 |R|R|Ver|I|P|R|O| Reserved | NP=IOAM_Trace | | 591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ GPE 592 | Virtual Network Identifier (VNI) | Reserved | | 593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+ 594 | Type | IOAM HDR len| Reserved | Next Protocol | | 595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+IOAM 596 | IOAM-Trace-Type |NodeLen| Flags | Max Length |Trace 597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ 598 | | | 599 | node data list [0] | IOAM 600 | | | 601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ D 602 | | a 603 | node data list [1] | t 604 | | a 605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 606 ~ ... ~ S 607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ p 608 | | a 609 | node data list [n-1] | c 610 | | e 611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 612 | | | 613 | node data list [n] | | 614 | | | 615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<--+ 616 | | 617 | | 618 | Payload + Padding (L2/L3/ESP/...) | 619 | | 620 | | 621 | | 622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 623 In-situ OAM Incremental Trace Option Data MUST be 4-byte aligned: 625 Type: 8-bit unsigned integer defining IOAM header type 626 IOAM_TRACE_Preallocated or IOAM_Trace_Incremental are defined 627 here. 629 IOAM HDR len: 8-bit unsigned integer. Length of the in-situ OAM HDR 630 in 8-octet units. 632 Reserved: 8-bit reserved field MUST be set to zero. 634 Next Protocol: 8-bit unsigned integer that determines the type of 635 header following IOAM protocol. The value is from the IANA 636 registry setup for VXLAN GPE Next Protocol defined in 637 [I-D.ietf-nvo3-vxlan-gpe]. 639 IOAM-Trace-Type: 16-bit identifier of IOAM Trace Type as defined in 640 [I-D.brockners-inband-oam-data] IOAM-Trace-Types. 642 Node Data Length: 4-bit unsigned integer as defined in 643 [I-D.brockners-inband-oam-data]. 645 Flags: 5-bit field as defined in [I-D.brockners-inband-oam-data]. 647 Octets-left: 7-bit unsigned integer as defined in 648 [I-D.brockners-inband-oam-data]. 650 Maximum-length: 7-bit unsigned integer as defined in 651 [I-D.brockners-inband-oam-data]. 653 Node data List [n]: Variable-length field as defined in 654 [I-D.brockners-inband-oam-data]. 656 5.2. In-situ OAM POT in VXLAN-GPE 658 The VXLAN-GPE header and fields are defined in 659 [I-D.ietf-nvo3-vxlan-gpe]. IOAM specific fields and header are 660 defined here: 662 In-situ OAM POT header following VXLAN GPE header: 664 0 1 2 3 665 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 666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 667 | Outer Ethernet Header | 668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 669 | Outer IP Header | 670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 671 | Outer UDP Header | 672 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+ 673 |R|R|Ver|I|P|R|O| Reserved(MBZ) |NP = IOAM_POT | | 674 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ GPE 675 | Virtual Network Identifier (VNI) | Reserved | | 676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+ 677 |IOAM POT Type|P| IOAM HDR len| Reserved | Next Protocol | | 678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+IOAM 679 | Random | | 680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ P 681 | Random(contd.) | O 682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ T 683 | Cumulative | | 684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 685 | Cumulative (contd.) | | 686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ 688 IOAM POT Type: 7-bit identifier of a particular POT variant that 689 dictates the POT data that is included as defined in 690 [I-D.brockners-inband-oam-data]. 692 Profile to use (P): 1-bit as defined in 693 [I-D.brockners-inband-oam-data] IOAM POT Option. 695 IOAM HDR len: 8-bit unsigned integer. Length of the in-situ OAM HDR 696 in 8-octet units 698 Reserved: 8-bit reserved field MUST be set to zero. 700 Next Protocol: 8-bit unsigned integer that determines the type of 701 header following IOAM protocol. The value is from the IANA 702 registry setup for VXLAN GPE Next Protocol defined in 703 [I-D.ietf-nvo3-vxlan-gpe]. 705 Random: 64-bit Per-packet random number. 707 Cumulative: 64-bit Cumulative value that is updated by the Service 708 Functions. 710 5.3. In-situ OAM Edge-to-Edge in VXLAN-GPE 712 In-situ OAM Edge-to-Edge in VXLAN GPE header: 714 0 1 2 3 715 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 716 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 717 | Outer Ethernet Header | 718 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 719 | Outer IP Header | 720 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 721 | Outer UDP Header | 722 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+ 723 |R|R|Ver|I|P|R|O| Reserved |NP = IOAM_E2E | | 724 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ GPE 725 | Virtual Network Identifier (VNI) | Reserved | | 726 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+ 727 |Type=IOAM_E2E | IOAM HDR len | Reserved | Next Protocol | | 728 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+IOAM 729 | E2E Option data field determined by IOAM-E2E-Type | | 730 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ 732 Type: 8-bit identifier of a particular E2E variant that dictates the 733 E2E data that is included as defined in 734 [I-D.brockners-inband-oam-data]. 736 IOAM HDR len: 8-bit unsigned integer. Length of the in-situ OAM HDR 737 in 8-octet units 739 Reserved: 8-bit reserved field MUST be set to zero. 741 Next Protocol: 8-bit unsigned integer that determines the type of 742 header following IOAM protocol. The value is from the IANA 743 registry setup for VXLAN GPE Next Protocol defined in 744 [I-D.ietf-nvo3-vxlan-gpe]. 746 E2E Option data field: Variable length field as defined in 747 [I-D.brockners-inband-oam-data] IOAM E2E Option. 749 6. In-situ OAM Metadata Transport in NSH 751 6.1. In-situ OAM Tracing in NSH 753 The packet formats of the pre-allocated IOAM trace and incremental 754 IOAM trace when transported in NSH are defined as below. See 755 [I-D.brockners-inband-oam-data] for details about pre-allocated and 756 incremental IOAM trace options. 758 In Service Function Chaining (SFC) [RFC7665], the Network Service 759 Header (NSH) [I-D.ietf-sfc-nsh] already includes path tracing 760 capabilities [I-D.penno-sfc-trace]. Tracing information can be 761 carried in-situ as IOAM data fields following NSH MDx metadata TLVs. 763 In-situ OAM Trace header following NSH MDx header 764 (Pre-allocated IOAM trace): 766 0 1 2 3 767 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 768 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ 769 |Ver|O|C|R|R|R|R|R|R| Length | MD Type | NP=IOAM_Trace | | 770 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ N 771 | Service Path Identifer | Service Index | S 772 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ H 773 | ... | | 774 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ 775 | Type | IOAM HDR len| Reserved | Next Protocol | | 776 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+IOAM 777 | IOAM-Trace-Type |NodeLen| Flags | Octets-left |Trace 778 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ 779 | | | 780 | node data list [0] |IOAM 781 | | | 782 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ D 783 | | a 784 | node data list [1] | t 785 | | a 786 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 787 ~ ... ~ S 788 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ p 789 | | a 790 | node data list [n-1] | c 791 | | e 792 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 793 | | | 794 | node data list [n] | | 795 | | | 796 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<--+ 797 | | 798 | | 799 | Payload + Padding (L2/L3/ESP/...) | 800 | | 801 | | 802 | | 803 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 805 In-situ OAM Pre-allocated Trace Option Data MUST be 4-byte aligned: 807 In-situ OAM Trace header following NSH MDx header 808 (Incremental IOAM trace): 810 0 1 2 3 811 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 812 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ 813 |Ver|O|C|R|R|R|R|R|R| Length | MD Type | NP=IOAM_Trace | N 814 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ S 815 | Service Path Identifer | Service Index | H 816 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 817 | ... | | 818 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ 819 | Type | IOAM HDR len | Reserved | Next Protocol | | 820 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+IOAM 821 | IOAM-Trace-Type |NodeLen| Flags | Max Length |Trace 822 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ 823 | | | 824 | node data list [0] |IOAM 825 | | | 826 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ D 827 | | a 828 | node data list [1] | t 829 | | a 830 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 831 ~ ... ~ S 832 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ p 833 | | a 834 | node data list [n-1] | c 835 | | e 836 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 837 | | | 838 | node data list [n] | | 839 | | | 840 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<--+ 841 | | 842 | | 843 | Payload + Padding (L2/L3/ESP/...) | 844 | | 845 | | 846 | | 847 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 849 In-situ OAM Incremental Trace Option Data MUST be 4-byte aligned: 851 Next Protocol of NSH: TBD value for IOAM_Trace. 853 Type: 8-bit unsigned integer defining IOAM header type 854 IOAM_TRACE_Preallocated or IOAM_Trace_Incremental are defined 855 here. 857 IOAM HDR len: 8-bit unsigned integer. Length of the in-situ OAM HDR 858 in 8-octet units. 860 Reserved bits and R bits: Reserved bits are present for future use. 861 The reserved bits MUST be set to 0x0. 863 Next Protocol: 8-bit unsigned integer that determines the type of 864 header following IOAM protocol. 866 IOAM-Trace-Type: 16-bit identifier of IOAM Trace Type as defined in 867 [I-D.brockners-inband-oam-data] IOAM-Trace-Types. 869 Node Data Length: 4-bit unsigned integer as defined in 870 [I-D.brockners-inband-oam-data]. 872 Flags: 5-bit field as defined in [I-D.brockners-inband-oam-data]. 874 Octets-left: 7-bit unsigned integer as defined in 875 [I-D.brockners-inband-oam-data]. 877 Maximum-length: 7-bit unsigned integer as defined in 878 [I-D.brockners-inband-oam-data]. 880 Node data List [n]: Variable-length field as defined in 881 [I-D.brockners-inband-oam-data]. 883 6.2. In-situ OAM POT in NSH 885 The "Proof of Transit" capabilities (see 886 [I-D.brockners-inband-oam-requirements] and 887 [I-D.brockners-proof-of-transit]) of in-situ OAM can be leveraged 888 within NSH. In an administrative domain where in-situ OAM is used, 889 insertion of the in-situ OAM data into the NSH header is enabled at 890 the required nodes (i.e. at the in-situ OAM encapsulating/ 891 decapsulating nodes) by means of configuration. 893 Proof of transit in-situ OAM data is added as NSH Type 2 metadata: 895 In-situ OAM POT header following NSH MDx header: 897 0 1 2 3 898 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 899 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ 900 |Ver|O|C|R|R|R|R|R|R| Length | MD Type |NP = IOAM_POT | | 901 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ N 902 | Service Path Identifer | Service Index | S 903 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ H 904 | ... | | 905 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ 906 |IOAM_POT Type|P| IOAM HDR len| Reserved | Next Protocol | | 907 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 908 | Random | | 909 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ P 910 | Random(contd.) | O 911 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ T 912 | Cumulative | | 913 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 914 | Cumulative (contd.) | | 915 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ 917 Next Protocol of NSH: TBD value for IOAM_POT. 919 IOAM POT Type: 7-bit identifier of a particular POT variant that 920 dictates the POT data that is included as defined in 921 [I-D.brockners-inband-oam-data]. 923 Profile to use (P): 1-bit as defined in 924 [I-D.brockners-inband-oam-data] IOAM POT Option. 926 IOAM HDR len: 8-bit unsigned integer. Length of the in-situ OAM HDR 927 in 8-octet units 929 Reserved bits and R bits: Reserved bits are present for future use. 930 The reserved bits MUST be set to 0x0. 932 Next Protocol: 8-bit unsigned integer that determines the type of 933 header following IOAM protocol. 935 Random: 64-bit Per-packet random number. 937 Cumulative: 64-bit Cumulative value that is updated by the Service 938 Functions. 940 6.3. In-situ OAM Edge-to-Edge in NSH 942 The "Edge-to-Edge" capabilities (see 943 [I-D.brockners-inband-oam-requirements]) of in-situ OAM can be 944 leveraged within NSH. In an administrative domain where in-situ OAM 945 is used, insertion of the in-situ OAM data into the NSH header is 946 enabled at the required nodes (i.e. at the in-situ OAM encapsulating/ 947 decapsulating nodes) by means of configuration. 949 Edge-to-Edge in-situ OAM data is added as a TLV following NSH MDx 950 metadata: 952 In-situ OAM E2E header following NSH MDx header: 954 0 1 2 3 955 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 956 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ 957 |Ver|O|C|R|R|R|R|R|R| Length | MD Type |NP = IOAM_E2E | | 958 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ N 959 | Service Path Identifer | Service Index | S 960 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ H 961 | ... | | 962 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ 963 |IOAM_E2E_Type | IOAM HDR len| Reserved | Next Protocol | IOAM 964 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ E2E 965 | E2E Option data field determined by IOAM-E2E-Type | | 966 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ 968 Next Protocol of NSH: TBD value for IOAM_E2E. 970 IOAM E2E Type: 8-bit identifier of a particular E2E variant that 971 dictates the IOAM E2E data that is included as defined in 972 [I-D.brockners-inband-oam-data]. 974 IOAM HDR len: 8-bit unsigned integer. Length of the in-situ OAM HDR 975 in 8-octet units 977 Reserved bits and R bits: Reserved bits are present for future use. 978 The reserved bits MUST be set to 0x0. 980 Next Protocol: 8-bit unsigned integer that determines the type of 981 header following IOAM protocol. 983 E2E Option data field: Variable length field as defined in 984 [I-D.brockners-inband-oam-data] IOAM E2E Option. 986 7. In-situ OAM Metadata Transport in Segment Routing 988 7.1. In-situ OAM in SR with IPv6 Transport 990 Similar to NSH, a policy defined using Segment Routing for IPv6 can 991 be verified using the in-situ OAM "Proof of Transit" approach. The 992 Segment Routing Header (SRH) for IPv6 offers the ability to transport 993 TLV structured data, similar to what NSH does (see 994 [I-D.ietf-6man-segment-routing-header]). In an domain where in-situ 995 OAM is used, insertion of the in-situ OAM data is enabled at the 996 required edge nodes (i.e. at the in-situ OAM encapsulating/ 997 decapsulating nodes) by means of configuration. 999 A new "POT TLV" is defined for the SRH which is to carry proof of 1000 transit in situ OAM data. 1002 0 1 2 3 1003 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 1004 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1005 | Type | Length | RESERVED |F| Flags | 1006 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ 1007 |IOAM POT Type|P| Reserved (MBZ) | | 1008 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1009 | Random | | 1010 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ P 1011 | Random(contd.) | O 1012 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ T 1013 | Cumulative | | 1014 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1015 | Cumulative (contd.) | | 1016 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ 1018 Type: To be assigned by IANA. 1020 Length: 20. 1022 RESERVED: 8 bits. SHOULD be unset on transmission and MUST be 1023 ignored on receipt. 1025 F: 1 bit. Indicates which POT-profile is active. 0 means the even 1026 POT-profile is active, 1 means the odd POT-profile is active. 1028 Flags: 8 bits. No flags are defined in this document. 1030 IOAM POT Type: 7-bit identifier of a particular POT variant that 1031 dictates the POT data that is included as defined in 1032 [I-D.brockners-inband-oam-data]. 1034 Profile to use (P): 1-bit as defined in 1035 [I-D.brockners-inband-oam-data] IOAM POT Option. 1037 Reserved (MBZ): 24-bit field MUST be filled with zeroes. 1039 Random: 64-bit per-packet random number. 1041 Cumulative: 64-bit cumulative value that is updated at specific 1042 nodes that form the service path to be verified. 1044 7.2. In-situ OAM in SR with MPLS Transport 1046 In-situ OAM "Proof of Transit" data can also be carried as part of 1047 the MPLS label stack. Details will be addressed in a future version 1048 of this document. 1050 8. IANA Considerations 1052 IANA considerations will be added in a future version of this 1053 document. 1055 9. Manageability Considerations 1057 Manageability considerations will be addressed in a later version of 1058 this document.. 1060 10. Security Considerations 1062 Security considerations will be addressed in a later version of this 1063 document. For a discussion of security requirements of in-situ OAM, 1064 please refer to [I-D.brockners-inband-oam-requirements]. 1066 11. Acknowledgements 1068 The authors would like to thank Eric Vyncke, Nalini Elkins, Srihari 1069 Raghavan, Ranganathan T S, Karthik Babu Harichandra Babu, Akshaya 1070 Nadahalli, Stefano Previdi, Hemant Singh, Erik Nordmark, LJ Wobker, 1071 and Andrew Yourtchenko for the comments and advice. The authors 1072 would like to acknowledge Craig Hill for contributing GRE IOAM 1073 encapsulation. For the IPv6 encapsulation, this document leverages 1074 and builds on top of several concepts described in 1075 [I-D.kitamura-ipv6-record-route]. The authors would like to 1076 acknowledge the work done by the author Hiroshi Kitamura and people 1077 involved in writing it. 1079 12. References 1081 12.1. Normative References 1083 [ETYPES] "IANA Ethernet Numbers", 1084 . 1087 [I-D.brockners-inband-oam-data] 1088 Brockners, F., Bhandari, S., Pignataro, C., Gredler, H., 1089 Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov, 1090 P., <>, R., and d. daniel.bernier@bell.ca, "Data Fields 1091 for In-situ OAM", draft-brockners-inband-oam-data-05 (work 1092 in progress), May 2017. 1094 [I-D.brockners-inband-oam-requirements] 1095 Brockners, F., Bhandari, S., Dara, S., Pignataro, C., 1096 Gredler, H., Leddy, J., Youell, S., Mozes, D., Mizrahi, 1097 T., <>, P., and r. remy@barefootnetworks.com, 1098 "Requirements for In-situ OAM", draft-brockners-inband- 1099 oam-requirements-03 (work in progress), March 2017. 1101 [I-D.ietf-6man-segment-routing-header] 1102 Previdi, S., Filsfils, C., Raza, K., Leddy, J., Field, B., 1103 daniel.voyer@bell.ca, d., daniel.bernier@bell.ca, d., 1104 Matsushima, S., Leung, I., Linkova, J., Aries, E., Kosugi, 1105 T., Vyncke, E., Lebrun, D., Steinberg, D., and R. Raszuk, 1106 "IPv6 Segment Routing Header (SRH)", draft-ietf-6man- 1107 segment-routing-header-06 (work in progress), March 2017. 1109 [I-D.ietf-nvo3-vxlan-gpe] 1110 Maino, F., Kreeger, L., and U. Elzur, "Generic Protocol 1111 Extension for VXLAN", draft-ietf-nvo3-vxlan-gpe-04 (work 1112 in progress), April 2017. 1114 [I-D.ietf-sfc-nsh] 1115 Quinn, P. and U. Elzur, "Network Service Header", draft- 1116 ietf-sfc-nsh-13 (work in progress), June 2017. 1118 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1119 Requirement Levels", BCP 14, RFC 2119, 1120 DOI 10.17487/RFC2119, March 1997, 1121 . 1123 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 1124 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 1125 DOI 10.17487/RFC2784, March 2000, 1126 . 1128 [RFC3232] Reynolds, J., Ed., "Assigned Numbers: RFC 1700 is Replaced 1129 by an On-line Database", RFC 3232, DOI 10.17487/RFC3232, 1130 January 2002, . 1132 12.2. Informative References 1134 [FD.io] "Fast Data Project: FD.io", . 1136 [I-D.brockners-proof-of-transit] 1137 Brockners, F., Bhandari, S., Dara, S., Pignataro, C., 1138 Leddy, J., Youell, S., Mozes, D., and T. Mizrahi, "Proof 1139 of Transit", draft-brockners-proof-of-transit-03 (work in 1140 progress), March 2017. 1142 [I-D.ietf-ippm-6man-pdm-option] 1143 Elkins, N., Hamilton, R., and m. mackermann@bcbsm.com, 1144 "IPv6 Performance and Diagnostic Metrics (PDM) Destination 1145 Option", draft-ietf-ippm-6man-pdm-option-13 (work in 1146 progress), June 2017. 1148 [I-D.ietf-spring-segment-routing] 1149 Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., 1150 and R. Shakir, "Segment Routing Architecture", draft-ietf- 1151 spring-segment-routing-12 (work in progress), June 2017. 1153 [I-D.kitamura-ipv6-record-route] 1154 Kitamura, H., "Record Route for IPv6 (PR6) Hop-by-Hop 1155 Option Extension", draft-kitamura-ipv6-record-route-00 1156 (work in progress), November 2000. 1158 [I-D.penno-sfc-trace] 1159 Penno, R., Quinn, P., Pignataro, C., and D. Zhou, 1160 "Services Function Chaining Traceroute", draft-penno-sfc- 1161 trace-03 (work in progress), September 2015. 1163 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 1164 Chaining (SFC) Architecture", RFC 7665, 1165 DOI 10.17487/RFC7665, October 2015, 1166 . 1168 Authors' Addresses 1169 Frank Brockners 1170 Cisco Systems, Inc. 1171 Hansaallee 249, 3rd Floor 1172 DUESSELDORF, NORDRHEIN-WESTFALEN 40549 1173 Germany 1175 Email: fbrockne@cisco.com 1177 Shwetha Bhandari 1178 Cisco Systems, Inc. 1179 Cessna Business Park, Sarjapura Marathalli Outer Ring Road 1180 Bangalore, KARNATAKA 560 087 1181 India 1183 Email: shwethab@cisco.com 1185 Vengada Prasad Govindan 1186 Cisco Systems, Inc. 1188 Email: venggovi@cisco.com 1190 Carlos Pignataro 1191 Cisco Systems, Inc. 1192 7200-11 Kit Creek Road 1193 Research Triangle Park, NC 27709 1194 United States 1196 Email: cpignata@cisco.com 1198 Hannes Gredler 1199 RtBrick Inc. 1201 Email: hannes@rtbrick.com 1203 John Leddy 1204 Comcast 1206 Email: John_Leddy@cable.comcast.com 1207 Stephen Youell 1208 JP Morgan Chase 1209 25 Bank Street 1210 London E14 5JP 1211 United Kingdom 1213 Email: stephen.youell@jpmorgan.com 1215 Tal Mizrahi 1216 Marvell 1217 6 Hamada St. 1218 Yokneam 20692 1219 Israel 1221 Email: talmi@marvell.com 1223 David Mozes 1224 Mellanox Technologies Ltd. 1226 Email: davidm@mellanox.com 1228 Petr Lapukhov 1229 Facebook 1230 1 Hacker Way 1231 Menlo Park, CA 94025 1232 US 1234 Email: petr@fb.com 1236 Remy Chang 1237 Barefoot Networks 1238 2185 Park Boulevard 1239 Palo Alto, CA 94306 1240 US