idnits 2.17.1 draft-brockners-inband-oam-transport-03.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 (March 12, 2017) is 2602 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '0' on line 496 -- Looks like a reference, but probably isn't: '1' on line 500 == Outdated reference: A later version (-07) exists of draft-brockners-inband-oam-data-02 == Outdated reference: A later version (-03) exists of draft-brockners-inband-oam-requirements-02 == Outdated reference: A later version (-26) exists of draft-ietf-6man-segment-routing-header-05 == Outdated reference: A later version (-13) exists of draft-ietf-nvo3-vxlan-gpe-03 == Outdated reference: A later version (-28) exists of draft-ietf-sfc-nsh-12 == Outdated reference: A later version (-05) exists of draft-brockners-proof-of-transit-02 == Outdated reference: A later version (-13) exists of draft-ietf-ippm-6man-pdm-option-08 == Outdated reference: A later version (-15) exists of draft-ietf-spring-segment-routing-10 Summary: 0 errors (**), 0 flaws (~~), 9 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: September 13, 2017 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 March 12, 2017 23 Encapsulations for In-situ OAM Data 24 draft-brockners-inband-oam-transport-03 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 September 13, 2017. 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 . . . . . . . . . . . 6 79 4.1. In-situ OAM Metadata Transport in GRE . . . . . . . . . . 6 80 5. In-situ OAM Metadata Transport in VXLAN-GPE . . . . . . . . . 9 81 6. In-situ OAM Metadata Transport in NSH . . . . . . . . . . . . 11 82 6.1. In-situ OAM Tracing in NSH . . . . . . . . . . . . . . . 11 83 6.2. In-situ OAM POT in NSH . . . . . . . . . . . . . . . . . 13 84 6.3. In-situ OAM Edge-to-Edge in NSH . . . . . . . . . . . . . 14 85 7. In-situ OAM Metadata Transport in Segment Routing . . . . . . 15 86 7.1. In-situ OAM in SR with IPv6 Transport . . . . . . . . . . 15 87 7.2. In-situ OAM in SR with MPLS Transport . . . . . . . . . . 16 88 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 89 9. Manageability Considerations . . . . . . . . . . . . . . . . 16 90 10. Security Considerations . . . . . . . . . . . . . . . . . . . 16 91 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 92 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 93 12.1. Normative References . . . . . . . . . . . . . . . . . . 17 94 12.2. Informative References . . . . . . . . . . . . . . . . . 18 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 97 1. Introduction 99 This document discusses transport mechanisms for "in-situ" 100 Operations, Administration, and Maintenance (OAM) data fields. In- 101 situ OAM records OAM information within the packet while the packet 102 traverses a particular network domain. The term "in-situ" refers to 103 the fact that the OAM data is added to the data packets rather than 104 is being sent within packets specifically dedicated to OAM. A 105 discussion of the motivation and requirements for in-situ OAM can be 106 found in [I-D.brockners-inband-oam-requirements]. Data types and 107 data formats for in-situ OAM are defined in 108 [I-D.brockners-inband-oam-data]. 110 This document outlines transport encapsulations for the in-situ OAM 111 data defined in [I-D.brockners-inband-oam-data]. This document is to 112 serve informational purposes only. As part of an in-situ OAM 113 implementation study different protocol encapsulations for in-situ 114 OAM data are being explored. Once data formats and encapsulation 115 approaches are settled, protocol specific specifications for in-situ 116 OAM data transport will address the standardization aspect. 118 The data for in-situ OAM defined in [I-D.brockners-inband-oam-data] 119 can be carried in a variety of protocols based on the deployment 120 needs. This document discusses transport of in-situ OAM data for the 121 following protocols: 123 o IPv6 125 o IPv4 127 o VXLAN-GPE 129 o NSH 131 o Segment Routing (IPv6 and MPLS) 133 This list is non-exhaustive, as it is possible to carry the in-situ 134 OAM data in several other protocols and transports. 136 A feasibility study of in-situ OAM is currently underway as part of 137 the FD.io project [FD.io]. The in-situ OAM implementation study 138 should be considered as a "tool box" to showcase how "in-situ" OAM 139 can complement probe-packet based OAM mechanisms for different 140 deployments and packet transport formats. For details, see the open 141 source code in the FD.io [FD.io]. 143 2. Conventions 145 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 146 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 147 document are to be interpreted as described in [RFC2119]. 149 Abbreviations used in this document: 151 IOAM: In-situ Operations, Administration, and Maintenance 153 MTU: Maximum Transmit Unit 155 NSH: Network Service Header 157 OAM: Operations, Administration, and Maintenance 159 POT: Proof of Transit 161 SFC: Service Function Chain 163 SID: Segment Identifier 165 SR: Segment Routing 167 VXLAN-GPE: Virtual eXtensible Local Area Network, Generic Protocol 168 Extension 170 3. In-Situ OAM Metadata Transport in IPv6 172 This mechanisms of in-situ OAM in IPv6 complement others proposed to 173 enhance diagnostics of IPv6 networks, such as the IPv6 Performance 174 and Diagnostic Metrics Destination Option described in 175 [I-D.ietf-ippm-6man-pdm-option]. The IP Performance and Diagnostic 176 Metrics Destination Option is destination focused and specific to 177 IPv6, whereas in-situ OAM is performed between end-points of the 178 network or a network domain where it is enabled and used. 180 A historical note: The idea of IPv6 route recording was originally 181 introduced by [I-D.kitamura-ipv6-record-route] back in year 2000. 182 With IPv6 now being generally deployed and new concepts such as 183 Segment Routing [I-D.ietf-spring-segment-routing] being introduced, 184 it is imperative to further mature the Operations, Administration, 185 and Maintenance mechanisms available to IPv6 networks. 187 The in-situ OAM options translate into options for an IPv6 hop by hop 188 extension header. The extension header would be inserted by either a 189 host source of the packet, or by a transit/domain-edge node. If the 190 addition of the in-situ OAM Hop-by-Hop Option header would lead to 191 the packet exceeding the MTU of the domain an error should be 192 reported. The methods and procedures of how the error is reported 193 are outside the scope of this document. Likewise if an ICMPv6 194 forwarding error occurs between encapsulating and decapsulating 195 nodes, the node generating the ICMPv6 error should strip the in-situ 196 OAM Hop-by-Hop Option header before sending the ICMPv6 message to the 197 source. 199 3.1. In-situ OAM in IPv6 Hop by Hop Extension Header 201 This section defines in-situ OAM for IPv6 transport. In-situ OAM 202 Options are transported in IPv6 hop-by-hop extension header. 204 3.1.1. In-situ OAM Hop by Hop Options 206 IPv6 hop-by-hop option format for carrying in-situ OAM data fields: 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 | Option Type | Opt Data Len | Reserved (MBZ) | 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ 211 | | | 212 . . I 213 . Option Data . O 214 . . A 215 . . M 216 . . . 217 . . O 218 . . P 219 . . T 220 . . I 221 . . O 222 . . N 223 . . | 224 | | | 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ 227 Option Type 8-bit identifier of the type of option. 229 Opt Data Len 8-bit unsigned integer. Length of the 230 Reserved and Option Data field of this option, 231 in octets. 233 Reserved (MBZ) 16-bit field MUST be filled with zeroes. 235 Option Data Variable-length field. Option-Type-specific 236 data. 238 In-situ OAM Options are inserted as Option data as follows: 240 1. Pre-allocated Tracing Option: The in-situ OAM Preallocated 241 Tracing option defined in [I-D.brockners-inband-oam-data] is 242 represented as a IPv6 option in hop by hop extension header by 243 allocating following type: 245 Option Type: 001xxxxxx 8-bit identifier of the type of option. 246 xxxxxx=TBD_IANA_PRE_TRACE_OPTION_IPV6. 248 2. Incremental Tracing Option: The in-situ OAM Incremental Tracing 249 option defined in [I-D.brockners-inband-oam-data] is represented 250 as a IPv6 option in hop by hop extension header by allocating 251 following type: 253 Option Type: 001xxxxxx 8-bit identifier of the type of option. 254 xxxxxx=TBD_IANA_INCR_TRACE_OPTION_IPV6. 256 3. Proof of Transit Option: The in-situ OAM POT option defined in 257 [I-D.brockners-inband-oam-data] is represented as a IPv6 option 258 in hop by hop extension header by allocating following type: 260 Option Type: 001xxxxxx 8-bit identifier of the type of option. 261 xxxxxx=TBD_IANA_POT_OPTION_IPV6. 263 4. Edge to Edge Option: The in-situ OAM E2E option defined in 264 [I-D.brockners-inband-oam-data] is represented as a IPv6 option 265 in hop by hop extension header by allocating following type: 267 Option Type: 000xxxxxx 8-bit identifier of the type of option. 268 xxxxxx=TBD_IANA_E2E_OPTION_IPV6. 270 4. In-situ OAM Metadata Transport in IPv4 272 Transport of in-situ OAM data in IPv4 will use GRE encapsulation. 274 4.1. In-situ OAM Metadata Transport in GRE 276 GRE encapsulation is defined in [RFC2784]. IOAM is defined as a 277 "Protocol Type" TBD_IANA_ETHERNET_NUMBER_IOAM and follows GRE header. 278 The different IOAM data fields defined in 279 [I-D.brockners-inband-oam-data] are added as options within a new 280 IOAM protocol header following GRE header. In an administrative 281 domain where IOAM is used, insertion of the IOAM protocol header in 282 GRE is enabled at the GRE tunnel endpoints which also serve as IOAM 283 encapsulating/decapsulating nodes by means of configuration. 285 In-situ OAM header following GRE header: 287 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 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ 289 |C| Reserved0 | Ver | Protocol Type | G 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ R 291 | Checksum (optional) | Reserved1 (Optional) | E 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ 293 | Version | IOAM HDR len | Next Protocol Type | | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+IOAM 295 | IOAM options | | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ 297 | | 298 | | 299 | Payload + Padding (L2/L3/ESP/...) | 300 | | 301 | | 302 | | 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 The GRE header and fields are defined in [RFC2784] with Protocol Type 306 set to TBD_IANA_ETHERNET_NUMBER_IOAM. IOAM specific fields and 307 header are defined here: 309 Version: 8-bit unsigned integer defining IOAM protocol version. 311 IOAM HDR len: 8-bit unsigned integer. Length of the in-situ OAM HDR 312 in 8-octet units. 314 Next Protocol Type: 16 bits Next Protocol Type field contains the 315 protocol type of the packet following IOAM protocol header. These 316 Protocol Types are defined in [RFC3232] as "ETHER TYPES" and in 317 [ETYPES]. An implementation receiving a packet containing a 318 Protocol Type which is not listed in [RFC3232] or [ETYPES] SHOULD 319 discard the packet. 321 IOAM options: Variable-length field, of length such that the 322 complete in-situ OAM header is an integer multiple of 8 octets 323 long. Contains one or more TLV-encoded options of the format: 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 | Option Type | Opt Data Len | . 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . 328 | . 329 . . 330 . Option Data . 331 . . 332 | | 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 Option Type 8-bit identifier of the type of option. 336 Opt Data Len 8-bit unsigned integer. Length of the 337 Option Data field of this option, in octets. 339 Option Data Variable-length field. Option-Type-specific 340 data. 342 The IOAM data fields defined in [I-D.brockners-inband-oam-data] are 343 encoded with an option type allocated in the new IOAM IANA registry - 344 IOAM_PROTOCOL_OPTION_REGISTRY_IANA_TBD. In addition the following 345 padding options are defined to be used when necessary to align 346 subsequent options and to pad out the containing header to a multiple 347 of 8 octets in length. 349 Pad1 option (alignment requirement: none) 351 +-+-+-+-+-+-+-+-+ 352 | 0 | 353 +-+-+-+-+-+-+-+-+ 354 NOTE: The format of the Pad1 option is a special case -- it does 355 not have length and value fields. 357 The Pad1 option is used to insert one octet of padding into the 358 Options area of a header. If more than one octet of padding is 359 required, the PadN option, described next, should be used, rather 360 than multiple Pad1 options. 362 PadN option (alignment requirement: none) 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - 365 | 1 | Opt Data Len | Option Data 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - 367 The PadN option is used to insert two or more octets of padding 368 into the Options area of a header. For N octets of padding, the 369 Opt Data Len field contains the value N-2, and the Option Data 370 consists of N-2 zero-valued octets. 372 5. In-situ OAM Metadata Transport in VXLAN-GPE 374 VXLAN-GPE [I-D.ietf-nvo3-vxlan-gpe] encapsulation is somewhat similar 375 to IPv6 extension headers in that a series of headers can be 376 contained in the header as a linked list. The different iIOAM types 377 are added as options within a new IOAM protocol header in VXLAN GPE. 378 In an administrative domain where IOAM is used, insertion of the IOAM 379 protocol header in VXLAN GPE is enabled at the VXLAN GPE tunnel 380 endpoint which also serve as IOAM encapsulating/decapsulating nodes 381 by means of configuration. 383 In-situ OAM header in VXLAN GPE header: 385 0 1 2 3 386 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 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 | Outer Ethernet Header | 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 | Outer IP Header | 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 | Outer UDP Header | 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 394 |R|R|Ver|I|P|R|O| Reserved | NP = IOAM | | 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ GPE 396 | Virtual Network Identifier (VNI) | Reserved | | 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 398 | Type =IOAM | IOAM HDR len | Reserved | Next Protocol | | 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+IOAM 400 | IOAM options | | 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 402 | | 403 | | 404 | Payload + Padding (L2/L3/ESP/...) | 405 | | 406 | | 407 | | 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 The VXLAN-GPE header and fields are defined in 411 [I-D.ietf-nvo3-vxlan-gpe]. IOAM specific fields and header are 412 defined here: 414 Type: 8-bit unsigned integer defining IOAM header type 416 IOAM HDR len: 8-bit unsigned integer. Length of the in-situ OAM HDR 417 in 8-octet units 419 Reserved: 8-bit reserved field MUST be set to zero. 421 Next Protocol: 8-bit unsigned integer that determines the type of 422 header following IOAM protocol. The value is from the IANA 423 registry setup for VXLAN GPE Next Protocol defined in 424 [I-D.ietf-nvo3-vxlan-gpe]. 426 IOAM options: Variable-length field, of length such that the 427 complete IOAM header is an integer multiple of 8 octets long. 428 Contains one or more TLV-encoded options of the format: 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 | Option Type | Opt Data Len | Reserved (MBZ) | 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 | | 434 . . 435 . Option Data . 436 . . 437 | | 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 Option Type 8-bit identifier of the type of option. 441 Opt Data Len 8-bit unsigned integer. Length of the 442 Option Data field of this option, in octets. 444 Reserved (MBZ) 16-bit field MUST be filled with zeroes. 446 Option Data Variable-length field. Option-Type-specific 447 data. 449 The in-situ OAM options defined in [I-D.brockners-inband-oam-data] 450 are encoded with an option type allocated in the new in-situ OAM IANA 451 registry - in-situ OAM_PROTOCOL_OPTION_REGISTRY_IANA_TBD. In 452 addition the following padding options are defined to be used when 453 necessary to align subsequent options and to pad out the containing 454 header to a multiple of 8 octets in length. 456 Pad1 option (alignment requirement: none) 458 +-+-+-+-+-+-+-+-+ 459 | 0 | 460 +-+-+-+-+-+-+-+-+ 461 NOTE: The format of the Pad1 option is a special case -- it does 462 not have length and value fields. 464 The Pad1 option is used to insert one octet of padding into the 465 Options area of a header. If more than one octet of padding is 466 required, the PadN option, described next, should be used, rather 467 than multiple Pad1 options. 469 PadN option (alignment requirement: none) 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - 472 | 1 | Opt Data Len | Option Data 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - 474 The PadN option is used to insert two or more octets of padding 475 into the Options area of a header. For N octets of padding, the 476 Opt Data Len field contains the value N-2, and the Option Data 477 consists of N-2 zero-valued octets. 479 6. In-situ OAM Metadata Transport in NSH 481 6.1. In-situ OAM Tracing in NSH 483 In Service Function Chaining (SFC) [RFC7665], the Network Service 484 Header (NSH) [I-D.ietf-sfc-nsh] already includes path tracing 485 capabilities [I-D.penno-sfc-trace]. Tracing information can be 486 carried in-situ as IOAM data fields over NSH Type 2 metadata TLVs. 488 0 1 2 3 489 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 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 | TLV Class= TBD |C| Type=Trace |R| Len=n | 492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 493 | IOAM-Trace-Type | Octets-left | Flags | 494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ 495 | | | 496 | node data list [0] | | 497 | | | 498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ D 499 | | a 500 | node data list [1] | t 501 | | a 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 503 ~ ... ~ S 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ p 505 | | a 506 | node data list [n-1] | c 507 | | e 508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 509 | | | 510 | node data list [n] | | 511 | | | 512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-++ 514 TLV Class: Describes the scope of the "Type" field. In some cases, 515 the TLV Class will identify a specific vendor, in others, the TLV 516 Class will identify specific standards body allocated types. 517 TRACE is currently defined using the TBD TLV class. 519 C bit: Critical bit, See [I-D.ietf-sfc-nsh] for description. 521 Type: The specific type of information being carried, within the 522 scope of a given TLV Class. Value allocation is the 523 responsibility of the TLV Class owner. A type value of 524 0xTBD_NSH_IOAM_TRACE is used for IOAM Preallocated trace option. 526 Reserved bits and R-bits: one reserved bit is present for future 527 use. The reserved bits MUST be set to 0x0. 529 Length: Length of the variable metadata octets. 531 IOAM-trace-type: 16-bit identifier of IOAM Trace Type as defined in 532 [I-D.brockners-inband-oam-data] IOAM-Trace-Types. 534 Octets-left: 8-bit unsigned integer as defined in 535 [I-D.brockners-inband-oam-data]. 537 Flags 8-bit field as defined in [I-D.brockners-inband-oam-data]. 539 Node data List [n]: Variable-length field as defined in 540 [I-D.brockners-inband-oam-data]. 542 6.2. In-situ OAM POT in NSH 544 The "Proof of Transit" capabilities (see 545 [I-D.brockners-inband-oam-requirements] and 546 [I-D.brockners-proof-of-transit]) of in-situ OAM can be leveraged 547 within NSH. In an administrative domain where in-situ OAM is used, 548 insertion of the in-situ OAM data into the NSH header is enabled at 549 the required nodes (i.e. at the in-situ OAM encapsulating/ 550 decapsulating nodes) by means of configuration. 552 Proof of transit in-situ OAM data is added as NSH Type 2 metadata: 554 0 1 2 3 555 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 556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 557 | TLV Class=TBD |C| Type=POT |R| Len=20 | 558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ 559 |IOAM POT Type|P| Reserved (MBZ) | | 560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 561 | Random | | 562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ P 563 | Random(contd.) | O 564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ T 565 | Cumulative | | 566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 567 | Cumulative (contd.) | | 568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ 570 TLV Class: Describes the scope of the "Type" field. In some cases, 571 the TLV Class will identify a specific vendor, in others, the TLV 572 Class will identify specific standards body allocated types. POT 573 is currently defined using the Cisco (0x0009) TLV class. 575 C bit: Critical bit, See [I-D.ietf-sfc-nsh] for description. 577 Type: The specific type of information being carried, within the 578 scope of a given TLV Class. Value allocation is the 579 responsibility of the TLV Class owner. A type value of 580 0xTBD_NSH_IOAM_POT is used. 582 Reserved bit: one reserved bit is present for future use. The 583 reserved bits MUST be set to 0x0. 585 Length: Length of the variable metadata, in octets. Here the length 586 is 20. 588 IOAM POT Type: 7-bit identifier of a particular POT variant that 589 dictates the POT data that is included as defined in 590 [I-D.brockners-inband-oam-data]. 592 Profile to use (P): 1-bit as defined in 593 [I-D.brockners-inband-oam-data] IOAM POT Option. 595 Reserved (MBZ): 24-bit field MUST be filled with zeroes. 597 Random: 64-bit Per-packet Random number. 599 Cumulative: 64-bit Cumulative that is updated by the Service 600 Functions. 602 6.3. In-situ OAM Edge-to-Edge in NSH 604 The "Edge-to-Edge" capabilities (see 605 [I-D.brockners-inband-oam-requirements]) of in-situ OAM can be 606 leveraged within NSH. In an administrative domain where in-situ OAM 607 is used, insertion of the in-situ OAM data into the NSH header is 608 enabled at the required nodes (i.e. at the in-situ OAM encapsulating/ 609 decapsulating nodes) by means of configuration. 611 Edge-to-Edge in-situ OAM data is added as NSH Type 2 metadata: 613 0 1 2 3 614 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 615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 616 | TLV Class=TBD |C| Type=E2E |R| Len | 617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ 618 |IOAM E2E Type | Reserved (MBZ) | | 619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ E2E 620 | E2E Option data field determined by IOAM-E2E-Type | | 621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ 623 TLV Class: Describes the scope of the "Type" field. In some cases, 624 the TLV Class will identify a specific vendor, in others, the TLV 625 Class will identify specific standards body allocated types. POT 626 is currently defined using the Cisco (0x0009) TLV class. 628 C bit: Critical bit, See [I-D.ietf-sfc-nsh] for description. 630 Type: The specific type of information being carried, within the 631 scope of a given TLV Class. Value allocation is the 632 responsibility of the TLV Class owner. Currently a type value of 633 0xTBD_NSH_IOAM_E2E is used. 635 Reserved bits and R-bits: one reserved bit is present for future 636 use. The reserved bits MUST be set to 0x0. 638 Length: Length of the variable metadata, in octets. 640 IOAM E2E Type: 8-bit identifier of a particular E2E variant that 641 dictates the POT data that is included as defined in 642 [I-D.brockners-inband-oam-data]. 644 Reserved (MBZ): 24-bit field MUST be filled with zeroes. 646 E2E Option data field: Variable length field as defined in 647 [I-D.brockners-inband-oam-data] IOAM E2E Option. 649 7. In-situ OAM Metadata Transport in Segment Routing 651 7.1. In-situ OAM in SR with IPv6 Transport 653 Similar to NSH, a policy defined using Segment Routing for IPv6 can 654 be verified using the in-situ OAM "Proof of Transit" approach. The 655 Segment Routing Header (SRH) for IPv6 offers the ability to transport 656 TLV structured data, similar to what NSH does (see 657 [I-D.ietf-6man-segment-routing-header]). In an domain where in-situ 658 OAM is used, insertion of the in-situ OAM data is enabled at the 659 required edge nodes (i.e. at the in-situ OAM encapsulating/ 660 decapsulating nodes) by means of configuration. 662 A new "POT TLV" is defined for the SRH which is to carry proof of 663 transit in situ OAM data. 665 0 1 2 3 666 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 667 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 668 | Type | Length | RESERVED |F| Flags | 669 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ 670 |IOAM POT Type|P| Reserved (MBZ) | | 671 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 672 | Random | | 673 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ P 674 | Random(contd.) | O 675 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ T 676 | Cumulative | | 677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 678 | Cumulative (contd.) | | 679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ 680 Type: To be assigned by IANA. 682 Length: 20. 684 RESERVED: 8 bits. SHOULD be unset on transmission and MUST be 685 ignored on receipt. 687 F: 1 bit. Indicates which POT-profile is active. 0 means the even 688 POT-profile is active, 1 means the odd POT-profile is active. 690 Flags: 8 bits. No flags are defined in this document. 692 IOAM POT Type: 7-bit identifier of a particular POT variant that 693 dictates the POT data that is included as defined in 694 [I-D.brockners-inband-oam-data]. 696 Profile to use (P): 1-bit as defined in 697 [I-D.brockners-inband-oam-data] IOAM POT Option. 699 Reserved (MBZ): 24-bit field MUST be filled with zeroes. 701 Random: 64-bit per-packet random number. 703 Cumulative: 64-bit cumulative value that is updated at specific 704 nodes that form the service path to be verified. 706 7.2. In-situ OAM in SR with MPLS Transport 708 In-situ OAM "Proof of Transit" data can also be carried as part of 709 the MPLS label stack. Details will be addressed in a future version 710 of this document. 712 8. IANA Considerations 714 IANA considerations will be added in a future version of this 715 document. 717 9. Manageability Considerations 719 Manageability considerations will be addressed in a later version of 720 this document.. 722 10. Security Considerations 724 Security considerations will be addressed in a later version of this 725 document. For a discussion of security requirements of in-situ OAM, 726 please refer to [I-D.brockners-inband-oam-requirements]. 728 11. Acknowledgements 730 The authors would like to thank Eric Vyncke, Nalini Elkins, Srihari 731 Raghavan, Ranganathan T S, Karthik Babu Harichandra Babu, Akshaya 732 Nadahalli, Stefano Previdi, Hemant Singh, Erik Nordmark, LJ Wobker, 733 and Andrew Yourtchenko for the comments and advice. The authors 734 would like to acknowledge Craig Hill for contributing GRE IOAM 735 encapsulation. For the IPv6 encapsulation, this document leverages 736 and builds on top of several concepts described in 737 [I-D.kitamura-ipv6-record-route]. The authors would like to 738 acknowledge the work done by the author Hiroshi Kitamura and people 739 involved in writing it. 741 12. References 743 12.1. Normative References 745 [ETYPES] "IANA Ethernet Numbers", 746 . 749 [I-D.brockners-inband-oam-data] 750 Brockners, F., Bhandari, S., Pignataro, C., Gredler, H., 751 Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov, 752 P., and R. <>, "Data Formats for In-situ OAM", draft- 753 brockners-inband-oam-data-02 (work in progress), October 754 2016. 756 [I-D.brockners-inband-oam-requirements] 757 Brockners, F., Bhandari, S., Dara, S., Pignataro, C., 758 Gredler, H., Leddy, J., Youell, S., Mozes, D., Mizrahi, 759 T., <>, P., and r. remy@barefootnetworks.com, 760 "Requirements for In-situ OAM", draft-brockners-inband- 761 oam-requirements-02 (work in progress), October 2016. 763 [I-D.ietf-6man-segment-routing-header] 764 Previdi, S., Filsfils, C., Field, B., Leung, I., Linkova, 765 J., Aries, E., Kosugi, T., Vyncke, E., and D. Lebrun, 766 "IPv6 Segment Routing Header (SRH)", draft-ietf-6man- 767 segment-routing-header-05 (work in progress), February 768 2017. 770 [I-D.ietf-nvo3-vxlan-gpe] 771 Maino, F., Kreeger, L., and U. Elzur, "Generic Protocol 772 Extension for VXLAN", draft-ietf-nvo3-vxlan-gpe-03 (work 773 in progress), October 2016. 775 [I-D.ietf-sfc-nsh] 776 Quinn, P. and U. Elzur, "Network Service Header", draft- 777 ietf-sfc-nsh-12 (work in progress), February 2017. 779 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 780 Requirement Levels", BCP 14, RFC 2119, 781 DOI 10.17487/RFC2119, March 1997, 782 . 784 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 785 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 786 DOI 10.17487/RFC2784, March 2000, 787 . 789 [RFC3232] Reynolds, J., Ed., "Assigned Numbers: RFC 1700 is Replaced 790 by an On-line Database", RFC 3232, DOI 10.17487/RFC3232, 791 January 2002, . 793 12.2. Informative References 795 [FD.io] "Fast Data Project: FD.io", . 797 [I-D.brockners-proof-of-transit] 798 Brockners, F., Bhandari, S., Dara, S., Pignataro, C., 799 Leddy, J., Youell, S., Mozes, D., and T. Mizrahi, "Proof 800 of Transit", draft-brockners-proof-of-transit-02 (work in 801 progress), October 2016. 803 [I-D.ietf-ippm-6man-pdm-option] 804 Elkins, N., Hamilton, R., and m. mackermann@bcbsm.com, 805 "IPv6 Performance and Diagnostic Metrics (PDM) Destination 806 Option", draft-ietf-ippm-6man-pdm-option-08 (work in 807 progress), February 2017. 809 [I-D.ietf-spring-segment-routing] 810 Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., 811 and R. Shakir, "Segment Routing Architecture", draft-ietf- 812 spring-segment-routing-10 (work in progress), November 813 2016. 815 [I-D.kitamura-ipv6-record-route] 816 Kitamura, H., "Record Route for IPv6 (PR6) Hop-by-Hop 817 Option Extension", draft-kitamura-ipv6-record-route-00 818 (work in progress), November 2000. 820 [I-D.penno-sfc-trace] 821 Penno, R., Quinn, P., Pignataro, C., and D. Zhou, 822 "Services Function Chaining Traceroute", draft-penno-sfc- 823 trace-03 (work in progress), September 2015. 825 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 826 Chaining (SFC) Architecture", RFC 7665, 827 DOI 10.17487/RFC7665, October 2015, 828 . 830 Authors' Addresses 832 Frank Brockners 833 Cisco Systems, Inc. 834 Hansaallee 249, 3rd Floor 835 DUESSELDORF, NORDRHEIN-WESTFALEN 40549 836 Germany 838 Email: fbrockne@cisco.com 840 Shwetha Bhandari 841 Cisco Systems, Inc. 842 Cessna Business Park, Sarjapura Marathalli Outer Ring Road 843 Bangalore, KARNATAKA 560 087 844 India 846 Email: shwethab@cisco.com 848 Vengada Prasad Govindan 849 Cisco Systems, Inc. 851 Email: venggovi@cisco.com 853 Carlos Pignataro 854 Cisco Systems, Inc. 855 7200-11 Kit Creek Road 856 Research Triangle Park, NC 27709 857 United States 859 Email: cpignata@cisco.com 860 Hannes Gredler 861 RtBrick Inc. 863 Email: hannes@rtbrick.com 865 John Leddy 866 Comcast 868 Email: John_Leddy@cable.comcast.com 870 Stephen Youell 871 JP Morgan Chase 872 25 Bank Street 873 London E14 5JP 874 United Kingdom 876 Email: stephen.youell@jpmorgan.com 878 Tal Mizrahi 879 Marvell 880 6 Hamada St. 881 Yokneam 20692 882 Israel 884 Email: talmi@marvell.com 886 David Mozes 887 Mellanox Technologies Ltd. 889 Email: davidm@mellanox.com 891 Petr Lapukhov 892 Facebook 893 1 Hacker Way 894 Menlo Park, CA 94025 895 US 897 Email: petr@fb.com 898 Remy Chang 899 Barefoot Networks 900 2185 Park Boulevard 901 Palo Alto, CA 94306 902 US