idnits 2.17.00 (12 Aug 2021) /tmp/idnits50741/draft-ietf-ippm-ioam-data-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 30, 2017) is 1663 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '0' on line 612 -- Looks like a reference, but probably isn't: '1' on line 516 -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE1588v2' == Outdated reference: draft-ietf-nvo3-geneve has been published as RFC 8926 == Outdated reference: A later version (-12) exists of draft-ietf-nvo3-vxlan-gpe-04 == Outdated reference: draft-ietf-sfc-nsh has been published as RFC 8300 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 4 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: Standards Track C. Pignataro 5 Expires: May 3, 2018 Cisco 6 H. Gredler 7 RtBrick Inc. 8 J. Leddy 9 Comcast 10 S. Youell 11 JPMC 12 T. Mizrahi 13 Marvell 14 D. Mozes 15 Mellanox Technologies Ltd. 16 P. Lapukhov 17 Facebook 18 R. Chang 19 Barefoot Networks 20 D. Bernier 21 Bell Canada 22 October 30, 2017 24 Data Fields for In-situ OAM 25 draft-ietf-ippm-ioam-data-01 27 Abstract 29 In-situ Operations, Administration, and Maintenance (IOAM) records 30 operational and telemetry information in the packet while the packet 31 traverses a path between two points in the network. This document 32 discusses the data fields and associated data types for in-situ OAM. 33 In-situ OAM data fields can be embedded into a variety of transports 34 such as NSH, Segment Routing, Geneve, native IPv6 (via extension 35 header), or IPv4. In-situ OAM can be used to complement OAM 36 mechanisms based on e.g. ICMP or other types of probe packets. 38 Status of This Memo 40 This Internet-Draft is submitted in full conformance with the 41 provisions of BCP 78 and BCP 79. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF). Note that other groups may also distribute 45 working documents as Internet-Drafts. The list of current Internet- 46 Drafts is at http://datatracker.ietf.org/drafts/current/. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 This Internet-Draft will expire on May 3, 2018. 55 Copyright Notice 57 Copyright (c) 2017 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (http://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with respect 65 to this document. Code Components extracted from this document must 66 include Simplified BSD License text as described in Section 4.e of 67 the Trust Legal Provisions and are provided without warranty as 68 described in the Simplified BSD License. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 73 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 74 3. Scope, Applicability, and Assumptions . . . . . . . . . . . . 4 75 4. IOAM Data Types and Formats . . . . . . . . . . . . . . . . . 5 76 4.1. IOAM Tracing Options . . . . . . . . . . . . . . . . . . 6 77 4.1.1. Pre-allocated Trace Option . . . . . . . . . . . . . 8 78 4.1.2. Incremental Trace Option . . . . . . . . . . . . . . 11 79 4.1.3. IOAM node data fields and associated formats . . . . 14 80 4.1.4. Examples of IOAM node data . . . . . . . . . . . . . 19 81 4.2. IOAM Proof of Transit Option . . . . . . . . . . . . . . 21 82 4.3. IOAM Edge-to-Edge Option . . . . . . . . . . . . . . . . 23 83 5. IOAM Data Export . . . . . . . . . . . . . . . . . . . . . . 23 84 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 85 6.1. Creation of a new In-Situ OAM Protocol Parameters 86 Registry (IOAM) Protocol 87 Parameters IANA registry . . . . . . . . . . . . . . . . 24 88 6.2. IOAM Trace Type Registry . . . . . . . . . . . . . . . . 24 89 6.3. IOAM Trace Flags Registry . . . . . . . . . . . . . . . . 24 90 6.4. IOAM POT Type Registry . . . . . . . . . . . . . . . . . 25 91 6.5. IOAM E2E Type Registry . . . . . . . . . . . . . . . . . 25 92 7. Manageability Considerations . . . . . . . . . . . . . . . . 25 93 8. Security Considerations . . . . . . . . . . . . . . . . . . . 25 94 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 95 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 96 10.1. Normative References . . . . . . . . . . . . . . . . . . 25 97 10.2. Informative References . . . . . . . . . . . . . . . . . 26 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 100 1. Introduction 102 This document defines data fields for "in-situ" Operations, 103 Administration, and Maintenance (IOAM). In-situ OAM records OAM 104 information within the packet while the packet traverses a particular 105 network domain. The term "in-situ" refers to the fact that the OAM 106 data is added to the data packets rather than is being sent within 107 packets specifically dedicated to OAM. A discussion of the 108 motivation and requirements for in-situ OAM can be found in 109 [I-D.brockners-inband-oam-requirements]. IOAM is to complement 110 mechanisms such as Ping or Traceroute, or more recent active probing 111 mechanisms as described in [I-D.lapukhov-dataplane-probe]. In terms 112 of "active" or "passive" OAM, "in-situ" OAM can be considered a 113 hybrid OAM type. While no extra packets are sent, IOAM adds 114 information to the packets therefore cannot be considered passive. 115 In terms of the classification given in [RFC7799] IOAM could be 116 portrayed as Hybrid Type 1. "In-situ" mechanisms do not require 117 extra packets to be sent and hence don't change the packet traffic 118 mix within the network. IOAM mechanisms can be leveraged where 119 mechanisms using e.g. ICMP do not apply or do not offer the desired 120 results, such as proving that a certain traffic flow takes a pre- 121 defined path, SLA verification for the live data traffic, detailed 122 statistics on traffic distribution paths in networks that distribute 123 traffic across multiple paths, or scenarios in which probe traffic is 124 potentially handled differently from regular data traffic by the 125 network devices. 127 2. Conventions 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 131 document are to be interpreted as described in [RFC2119]. 133 Abbreviations used in this document: 135 E2E Edge to Edge 137 Geneve: Generic Network Virtualization Encapsulation 138 [I-D.ietf-nvo3-geneve] 140 IOAM: In-situ Operations, Administration, and Maintenance 142 MTU: Maximum Transmit Unit 143 NSH: Network Service Header [I-D.ietf-sfc-nsh] 145 OAM: Operations, Administration, and Maintenance 147 POT: Proof of Transit 149 SFC: Service Function Chain 151 SID: Segment Identifier 153 SR: Segment Routing 155 VXLAN-GPE: Virtual eXtensible Local Area Network, Generic Protocol 156 Extension [I-D.ietf-nvo3-vxlan-gpe] 158 3. Scope, Applicability, and Assumptions 160 IOAM deployment assumes a set of constraints, requirements, and 161 guiding principles which are described in this section. 163 Scope: This document defines the data fields and associated data 164 types for in-situ OAM. The in-situ OAM data field can be transported 165 by a variety of transport protocols, including NSH, Segment Routing, 166 Geneve, IPv6, or IPv4. Specification details for these different 167 transport protocols are outside the scope of this document. 169 Deployment domain (or scope) of in-situ OAM deployment: IOAM is a 170 network domain focused feature, with "network domain" being a set of 171 network devices or entities within a single administration. For 172 example, a network domain can include an enterprise campus using 173 physical connections between devices or an overlay network using 174 virtual connections / tunnels for connectivity between said devices. 175 A network domain is defined by its perimeter or edge. Designers of 176 carrier protocols for IOAM must specify mechanisms to ensure that 177 IOAM data stays within an IOAM domain. In addition, the operator of 178 such a domain is expected to put provisions in place to ensure that 179 IOAM data does not leak beyond the edge of an IOAM domain, e.g. using 180 for example packet filtering methods. The operator should consider 181 potential operational impact of IOAM to mechanisms such as ECMP 182 processing (e.g. load-balancing schemes based on packet length could 183 be impacted by the increased packet size due to IOAM), path MTU (i.e. 184 ensure that the MTU of all links within a domain is sufficiently 185 large to support the increased packet size due to IOAM) and ICMP 186 message handling (i.e. in case of a native IPv6 transport, IOAM 187 support for ICMPv6 Echo Request/Reply could desired which would 188 translate into ICMPv6 extensions to enable IOAM data fields to be 189 copied from an Echo Request message to an Echo Reply message). 191 IOAM control points: IOAM data fields are added to or removed from 192 the live user traffic by the devices which form the edge of a domain. 193 Devices within an IOAM domain can update and/or add IOAM data-fields. 194 Domain edge devices can be hosts or network devices. 196 Traffic-sets that IOAM is applied to: IOAM can be deployed on all or 197 only on subsets of the live user traffic. It SHOULD be possible to 198 enable IOAM on a selected set of traffic (e.g., per interface, based 199 on an access control list or flow specification defining a specific 200 set of traffic, etc.) The selected set of traffic can also be all 201 traffic. 203 Encapsulation independence: Data formats for IOAM SHOULD be defined 204 in a transport-independent manner. IOAM applies to a variety of 205 encapsulating protocols. A definition of how IOAM data fields are 206 carried by different transport protocols is outside the scope of this 207 document. 209 Layering: If several encapsulation protocols (e.g., in case of 210 tunneling) are stacked on top of each other, IOAM data-records could 211 be present at every layer. The behavior follows the ships-in-the- 212 night model. 214 Combination with active OAM mechanisms: IOAM should be usable for 215 active network probing, enabling for example a customized version of 216 traceroute. Decapsulating IOAM nodes may have an ability to send the 217 IOAM information retrieved from the packet back to the source address 218 of the packet or to the encapsulating node. 220 IOAM implementation: The IOAM data-field definitions take the 221 specifics of devices with hardware data-plane and software data-plane 222 into account. 224 4. IOAM Data Types and Formats 226 This section defines IOAM data types and data fields and associated 227 data types required for IOAM. The different uses of IOAM require the 228 definition of different types of data. The IOAM data fields for the 229 data being carried corresponds to the three main categories of IOAM 230 data defined in [I-D.brockners-inband-oam-requirements], which are: 231 edge-to-edge, per node, and for selected nodes only. 233 Transport options for IOAM data are outside the scope of this memo, 234 and are discussed in [I-D.brockners-inband-oam-transport]. IOAM data 235 fields are fixed length data fields. A bit field determines the set 236 of OAM data fields embedded in a packet. Depending on the type of 237 the encapsulation, a counter field indicates how many data fields are 238 included in a particular packet. 240 IOAM is expected to be deployed in a specific domain rather than on 241 the overall Internet. The part of the network which employs IOAM is 242 referred to as the "IOAM-domain". IOAM data is added to a packet 243 upon entering the IOAM-domain and is removed from the packet when 244 exiting the domain. Within the IOAM-domain, the IOAM data may be 245 updated by network nodes that the packet traverses. The device which 246 adds an IOAM data container to the packet to capture IOAM data is 247 called the "IOAM encapsulating node", whereas the device which 248 removes the IOAM data container is referred to as the "IOAM 249 decapsulating node". Nodes within the domain which are aware of IOAM 250 data and read and/or write or process the IOAM data are called "IOAM 251 transit nodes". IOAM nodes which add or remove the IOAM data 252 container can also update the IOAM data fields at the same time. Or 253 in other words, IOAM encapsulation or decapsulating nodes can also 254 serve as IOAM transit nodes at the same time. Note that not every 255 node in an IOAM domain needs to be an IOAM transit node. For 256 example, a Segment Routing deployment might require the segment 257 routing path to be verified. In that case, only the SR nodes would 258 also be IOAM transit nodes rather than all nodes. 260 4.1. IOAM Tracing Options 262 "IOAM tracing data" is expected to be collected at every node that a 263 packet traverses to ensure visibility into the entire path a packet 264 takes within an IOAM domain, i.e., in a typical deployment all nodes 265 in an in-situ OAM-domain would participate in IOAM and thus be IOAM 266 transit nodes, IOAM encapsulating or IOAM decapsulating nodes. If 267 not all nodes within a domain are IOAM capable, IOAM tracing 268 information will only be collected on those nodes which are IOAM 269 capable. Nodes which are not IOAM capable will forward the packet 270 without any changes to the IOAM data fields. The maximum number of 271 hops and the minimum path MTU of the IOAM domain is assumed to be 272 known. 274 To optimize hardware and software implementations tracing is defined 275 as two separate options. Any deployment MAY choose to configure and 276 support one or both of the following options. An implementation of 277 the transport protocol that carries these in-situ OAM data MAY choose 278 to support only one of the options. In the event that both options 279 are utilized at the same time, the Incremental Trace Option MUST be 280 placed before the Pre-allocated Trace Option. Given that the 281 operator knows which equipment is deployed in a particular IOAM, the 282 operator will decide by means of configuration which type(s) of trace 283 options will be enabled for a particular domain. 285 Pre-allocated Trace Option: This trace option is defined as a 286 container of node data fields with pre-allocated space for each 287 node to populate its information. This option is useful for 288 software implementations where it is efficient to allocate the 289 space once and index into the array to populate the data during 290 transit. The IOAM encapsulating node allocates the option header 291 and sets the fields in the option header. The in situ OAM 292 encapsulating node allocates an array which is used to store 293 operational data retrieved from every node while the packet 294 traverses the domain. IOAM transit nodes update the content of 295 the array. A pointer which is part of the IOAM trace data points 296 to the next empty slot in the array, which is where the next IOAM 297 transit node fills in its data. 299 Incremental Trace Option: This trace option is defined as a 300 container of node data fields where each node allocates and pushes 301 its node data immediately following the option header. The 302 maximum length of the node data list is written into the option 303 header. This type of trace recording is useful for some of the 304 hardware implementations as this eliminates the need for the 305 transit network elements to read the full array in the option and 306 allows for arbitrarily long packets as the MTU allows. The in- 307 situ OAM encapsulating node allocates the option header. The in- 308 situ OAM encapsulating node based on operational state and 309 configuration sets the fields in the header to control how large 310 the node data list can grow. IOAM transit nodes push their node 311 data to the node data list and increment the number of node data 312 fields in the header. 314 Every node data entry is to hold information for a particular IOAM 315 transit node that is traversed by a packet. The in-situ OAM 316 decapsulating node removes the IOAM data and processes and/or exports 317 the metadata. IOAM data uses its own name-space for information such 318 as node identifier or interface identifier. This allows for a 319 domain-specific definition and interpretation. For example: In one 320 case an interface-id could point to a physical interface (e.g., to 321 understand which physical interface of an aggregated link is used 322 when receiving or transmitting a packet) whereas in another case it 323 could refer to a logical interface (e.g., in case of tunnels). 325 The following IOAM data is defined for IOAM tracing: 327 o Identification of the IOAM node. An IOAM node identifier can 328 match to a device identifier or a particular control point or 329 subsystem within a device. 331 o Identification of the interface that a packet was received on, 332 i.e. ingress interface. 334 o Identification of the interface that a packet was sent out on, 335 i.e. egress interface. 337 o Time of day when the packet was processed by the node. Different 338 definitions of processing time are feasible and expected, though 339 it is important that all devices of an in-situ OAM domain follow 340 the same definition. 342 o Generic data: Format-free information where syntax and semantic of 343 the information is defined by the operator in a specific 344 deployment. For a specific deployment, all IOAM nodes should 345 interpret the generic data the same way. Examples for generic 346 IOAM data include geo-location information (location of the node 347 at the time the packet was processed), buffer queue fill level or 348 cache fill level at the time the packet was processed, or even a 349 battery charge level. 351 o A mechanism to detect whether IOAM trace data was added at every 352 hop or whether certain hops in the domain weren't in-situ OAM 353 transit nodes. 355 The "node data list" array in the packet is populated iteratively as 356 the packet traverses the network, starting with the last entry of the 357 array, i.e., "node data list [n]" is the first entry to be populated, 358 "node data list [n-1]" is the second one, etc. 360 4.1.1. Pre-allocated Trace Option 361 In-situ OAM pre-allocated trace option: 363 Pre-allocated trace option header: 365 0 1 2 3 366 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 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 | IOAM-Trace-Type |NodeLen| Flags | Octets-left | 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 Pre-allocated Trace Option Data MUST be 4-octet aligned: 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ 373 | | | 374 | node data list [0] | | 375 | | | 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ D 377 | | a 378 | node data list [1] | t 379 | | a 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 ~ ... ~ S 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ p 383 | | a 384 | node data list [n-1] | c 385 | | e 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 387 | | | 388 | node data list [n] | | 389 | | | 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ 392 IOAM-Trace-Type: A 16-bit identifier which specifies which data 393 types are used in this node data list. 395 The IOAM-Trace-Type value is a bit field. The following bit 396 fields are defined in this document, with details on each field 397 described in the Section 4.1.3. The order of packing the data 398 fields in each node data element follows the bit order of the 399 IOAM-Trace-Type field, as follows: 401 Bit 0 (Most significant bit) When set indicates presence of 402 Hop_Lim and node_id in the node data. 404 Bit 1 When set indicates presence of ingress_if_id and 405 egress_if_id (short format) in the node data. 407 Bit 2 When set indicates presence of timestamp seconds in the 408 node data 410 Bit 3 When set indicates presence of timestamp nanoseconds in 411 the node data. 413 Bit 4 When set indicates presence of transit delay in the node 414 data. 416 Bit 5 When set indicates presence of app_data (short format) in 417 the node data. 419 Bit 6 When set indicates presence of queue depth in the node 420 data. 422 Bit 7 When set indicates presence of variable length Opaque 423 State Snapshot field. 425 Bit 8 When set indicates presence of Hop_Lim and node_id in 426 wide format in the node data. 428 Bit 9 When set indicates presence of ingress_if_id and 429 egress_if_id in wide format in the node data. 431 Bit 10 When set indicates presence of app_data wide in the node 432 data. 434 Bit 11 When set indicates presence of the Checksum Complement 435 node data. 437 Bit 12-15 Undefined in this draft. 439 Section 4.1.3 describes the IOAM data types and their formats. 440 Within an in-situ OAM domain possible combinations of these bits 441 making the IOAM-Trace-Type can be restricted by configuration 442 knobs. 444 NodeLen: 4-bit unsigned integer. This field specifies the length of 445 data added by each node in multiples of 4-octets. For example, if 446 3 IOAM-Trace-Type bits are set and none of them is wide, then the 447 NodeLen would be 3. If 3 IOAM-Trace-Type bits are set and 2 of 448 them are wide, then the NodeLen would be 5. 450 Flags 5-bit field. Following flags are defined: 452 Bit 0 "Overflow" (O-bit) (most significant bit). This bit is set 453 by the network element if there is not enough number of octets 454 left to record node data, no field is added and the overflow 455 "O-bit" must be set to "1" in the header. This is useful for 456 transit nodes to ignore further processing of the option. 458 Bit 1 "Loopback" (L-bit). Loopback mode is used to send a copy 459 of a packet back towards the source. Loopback mode assumes 460 that a return path from transit nodes and destination nodes 461 towards the source exists. The encapsulating node decides 462 (e.g. using a filter) which packets loopback mode is enabled 463 for by setting the loopback bit. The encapsulating node also 464 needs to ensure that sufficient space is available in the IOAM 465 header for loopback operation. The loopback bit when set 466 indicates to the transit nodes processing this option to create 467 a copy of the packet received and send this copy of the packet 468 back to the source of the packet while it continues to forward 469 the original packet towards the destination. The source 470 address of the original packet is used as destination address 471 in the copied packet. The address of the node performing the 472 copy operation is used as the source address. The L-bit MUST 473 be cleared in the copy of the packet a nodes sends it back 474 towards the source. On its way back towards the source, the 475 packet is processed like a regular packet with IOAM 476 information. Once the return packet reaches the IOAM domain 477 boundary IOAM decapsulation occurs as with any other packet 478 containing IOAM information. 480 Bit 2-4 Reserved: Must be zero. 482 Octets-left: 7-bit unsigned integer. It is the data space in 483 multiples of 4-octets remaining for recording the node data. This 484 is used as an offset in data space to record the node data 485 element. 487 Node data List [n]: Variable-length field. The type of which is 488 determined by the IOAM-Trace-Type representing the n-th node data 489 in the node data list. The node data list is encoded starting 490 from the last node data of the path. The first element of the 491 node data list (node data list [0]) contains the last node of the 492 path while the last node data of the node data list (node data 493 list[n]) contains the first node data of the path traced. The 494 index contained in "Octets-left" identifies the offset for current 495 active node data to be populated. 497 4.1.2. Incremental Trace Option 498 In-situ OAM incremental trace option: 500 In-situ OAM incremental trace option Header: 502 0 1 2 3 503 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 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 505 | IOAM-Trace-Type |NodeLen| Flags | Max Length | 506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 IOAM Incremental Trace Option Data MUST be 4-octet aligned: 510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 511 | | 512 | node data list [0] | 513 | | 514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 515 | | 516 | node data list [1] | 517 | | 518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 519 ~ ... ~ 520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 521 | | 522 | node data list [n-1] | 523 | | 524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 525 | | 526 | node data list [n] | 527 | | 528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 530 IOAM-trace-type: A 16-bit identifier which specifies which data 531 types are used in this node data list. 533 The IOAM-Trace-Type value is a bit field. The following bit 534 fields are defined in this document, with details on each field 535 described in the Section 4.1.3. The order of packing the data 536 fields in each node data element follows the bit order of the 537 IOAM-Trace-Type field, as follows: 539 Bit 0 (Most significant bit) When set indicates presence of 540 Hop_Lim and node_id in the node data. 542 Bit 1 When set indicates presence of ingress_if_id and 543 egress_if_id (short format) in the node data. 545 Bit 2 When set indicates presence of timestamp seconds in the 546 node data. 548 Bit 3 When set indicates presence of timestamp nanoseconds in 549 the node data. 551 Bit 4 When set indicates presence of transit delay in the node 552 data. 554 Bit 5 When set indicates presence of app_data in the node data. 556 Bit 6 When set indicates presence of queue depth in the node 557 data. 559 Bit 7 When set indicates presence of variable length Opaque 560 State Snapshot field. 562 Bit 8 When set indicates presence of Hop_Lim and node_id wide 563 in the node data. 565 Bit 9 When set indicates presence of ingress_if_id and 566 egress_if_id in wide format in the node data. 568 Bit 10 When set indicates presence of app_data wide in the node 569 data. 571 Bit 11 When set indicates presence of the Checksum Complement 572 node data. 574 Bit 12-15 Undefined in this draft. 576 Section 4.1.3 describes the IOAM data types and their formats. 578 NodeLen: 4-bit unsigned integer. This field specifies the length of 579 data added by each node in multiples of 4-octets. For example, if 580 3 IOAM-Trace-Type bits are set and none of them is wide, then the 581 NodeLen would be 3. If 3 IOAM-Trace-Type bits are set and 2 of 582 them are wide, then the NodeLen would be 5. 584 Flags 5-bit field. Following flags are defined: 586 Bit 0 "Overflow" (O-bit) (most significant bit). This bit is set 587 by the network element if there is not enough number of octets 588 left to record node data, no field is added and the overflow 589 "O-bit" must be set to "1" in the header. This is useful for 590 transit nodes to ignore further processing of the option. 592 Bit 1 "Loopback" (L-bit). This bit when set indicates to the 593 transit nodes processing this option to send a copy of the 594 packet back to the source of the packet while it continues to 595 forward the original packet towards the destination. The L-bit 596 MUST be cleared in the copy of the packet before sending it. 598 Bit 2-4 Reserved. Must be zero. 600 Maximum Length: 7-bit unsigned integer. This field specifies the 601 maximum length of the node data list in multiples of 4-octets. 602 Given that the sender knows the minimum path MTU, the sender can 603 set the maximum length according to the number of node data bytes 604 allowed before exceeding the MTU. Thus, a simple comparison 605 between "NodeLen" and "Max Length" allows to decide whether or not 606 data could be added. 608 Node data List [n]: Variable-length field. The type of which is 609 determined by the OAM Type representing the n-th node data in the 610 node data list. The node data list is encoded starting from the 611 last node data of the path. The first element of the node data 612 list (node data list [0]) contains the last node of the path while 613 the last node data of the node data list (node data list[n]) 614 contains the first node data of the path traced. 616 4.1.3. IOAM node data fields and associated formats 618 All the data fields MUST be 4-octet aligned. The IOAM encapsulating 619 node MUST initialize data fields that it adds to the packet to zero. 620 If a node which is supposed to update an IOAM data field is not 621 capable of populating the value of a field set in the IOAM-Trace- 622 Type, the field value MUST be left unaltered except when explicitly 623 specified in the field description below. In the description of data 624 below if zero is valid value then a non-zero value to mean not 625 populated is specified. 627 Data field and associated data type for each of the data field is 628 shown below: 630 Hop_Lim and node_id: 4-octet field defined as follows: 632 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 633 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 634 | Hop_Lim | node_id | 635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 637 Hop_Lim: 1-octet unsigned integer. It is set to the Hop Limit 638 value in the packet at the node that records this data. Hop 639 Limit information is used to identify the location of the node 640 in the communication path. This is copied from the lower 641 layer, e.g., TTL value in IPv4 header or hop limit field from 642 IPv6 header of the packet when the packet is ready for 643 transmission. The semantics of the Hop_Lim field depend on the 644 lower layer protocol that IOAM is encapsulated over, and 645 therefore its specific semantics are outside the scope of this 646 memo. 648 node_id: 3-octet unsigned integer. Node identifier field to 649 uniquely identify a node within in-situ OAM domain. The 650 procedure to allocate, manage and map the node_ids is beyond 651 the scope of this document. 653 ingress_if_id and egress_if_id: 4-octet field defined as follows: 654 When this field is part of the data field but a node populating 655 the field is not able to fill it, the position in the field must 656 be filled with value 0xFFFFFFFF to mean not populated. 658 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 659 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 660 | ingress_if_id | egress_if_id | 661 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 663 ingress_if_id: 2-octet unsigned integer. Interface identifier to 664 record the ingress interface the packet was received on. 666 egress_if_id: 2-octet unsigned integer. Interface identifier to 667 record the egress interface the packet is forwarded out of. 669 timestamp seconds: 4-octet unsigned integer. Absolute timestamp in 670 seconds that specifies the time at which the packet was received 671 by the node. The structure of this field is identical to the most 672 significant 32 bits of the 64 least significant bits of the 673 [IEEE1588v2] timestamp. This truncated field consists of a 32-bit 674 seconds field. As defined in [IEEE1588v2], the timestamp 675 specifies the number of seconds elapsed since 1 January 1970 676 00:00:00 according to the International Atomic Time (TAI). 678 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 679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 680 | timestamp seconds | 681 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 683 timestamp nanoseconds: 4-octet unsigned integer in the range 0 to 684 10^9-1. This timestamp specifies the fractional part of the wall 685 clock time at which the packet was received by the node in units 686 of nanoseconds. This field is identical to the 32 least 687 significant bits of the [IEEE1588v2] timestamp. This fields 688 allows for delay computation between any two nodes in the network 689 when the nodes are time synchronized. When this field is part of 690 the data field but a node populating the field is not able to fill 691 it, the field position in the field must be filled with value 692 0xFFFFFFFF to mean not populated. 694 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 695 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 696 | timestamp nanoseconds | 697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 699 transit delay: 4-octet unsigned integer in the range 0 to 2^31-1. 700 It is the time in nanoseconds the packet spent in the transit 701 node. This can serve as an indication of the queuing delay at the 702 node. If the transit delay exceeds 2^31-1 nanoseconds then the 703 top bit 'O' is set to indicate overflow and value set to 704 0x80000000. When this field is part of the data field but a node 705 populating the field is not able to fill it, the field position in 706 the field must be filled with value 0xFFFFFFFF to mean not 707 populated. 709 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 710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 711 |O| transit delay | 712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 714 app_data: 4-octet placeholder which can be used by the node to add 715 application specific data. App_data represents a "free-format" 716 4-octet bit field with its semantics defined by a specific 717 deployment. 719 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 720 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 721 | app_data | 722 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 724 queue depth: 4-octet unsigned integer field. This field indicates 725 the current length of the egress interface queue of the interface 726 from where the packet is forwarded out. The queue depth is 727 expressed as the current number of memory buffers used by the 728 queue (a packet may consume one or more memory buffers, depending 729 on its size). When this field is part of the data field but a 730 node populating the field is not able to fill it, the field 731 position in the field must be filled with value 0xFFFFFFFF to mean 732 not populated. 734 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 735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 736 | queue depth | 737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 739 Opaque State Snapshot: Variable length field. It allows the network 740 element to store an arbitrary state in the node data field , 741 without a pre-defined schema. The schema needs to be made known 742 to the analyzer by some out-of-band mechanism. The specification 743 of this mechanism is beyond the scope of this document. The 744 24-bit "Schema Id" field in the field indicates which particular 745 schema is used, and should be configured on the network element by 746 the operator. 748 0 1 2 3 749 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 750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 751 | Length | Schema ID | 752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 753 | | 754 | | 755 | Opaque data | 756 ~ ~ 757 . . 758 . . 759 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 761 Length: 1-octet unsigned integer. It is the length in octets of 762 the Opaque data field that follows Schema Id. It MUST always 763 be a multiple of 4. 765 Schema ID: 3-octet unsigned integer identifying the schema of 766 Opaque data. 768 Opaque data: Variable length field. This field is interpreted as 769 specified by the schema identified by the Schema ID. 771 Hop_Lim and node_id wide: 8-octet field defined as follows: 773 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 774 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 775 | Hop_Lim | node_id ~ 776 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 777 ~ node_id (contd) | 778 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 780 Hop_Lim: 1-octet unsigned integer. It is set to the Hop Limit 781 value in the packet at the node that records this data. Hop 782 Limit information is used to identify the location of the node 783 in the communication path. This is copied from the lower layer 784 for e.g. TTL value in IPv4 header or hop limit field from IPv6 785 header of the packet. The semantics of the Hop_Lim field 786 depend on the lower layer protocol that IOAM is encapsulated 787 over, and therefore its specific semantics are outside the 788 scope of this memo. 790 node_id: 7-octet unsigned integer. Node identifier field to 791 uniquely identify a node within in-situ OAM domain. The 792 procedure to allocate, manage and map the node_ids is beyond 793 the scope of this document. 795 ingress_if_id and egress_if_id wide: 8-octet field defined as 796 follows: When this field is part of the data field but a node 797 populating the field is not able to fill it, the field position in 798 the field must be filled with value 0xFFFFFFFFFFFFFFFF to mean not 799 populated. 801 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 802 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 803 | ingress_if_id | 804 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 805 | egress_if_id | 806 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 808 ingress_if_id: 4-octet unsigned integer. Interface identifier to 809 record the ingress interface the packet was received on. 811 egress_if_id: 4-octet unsigned integer. Interface identifier to 812 record the egress interface the packet is forwarded out of. 814 app_data wide: 8-octet placeholder which can be used by the node to 815 add application specific data. App data represents a "free- 816 format" 8-octed bit field with its semantics defined by a specific 817 deployment. 819 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 820 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 821 | app data ~ 822 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 823 ~ app data (contd) | 824 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 826 Checksum Complement: 4-octet node data which contains a two-octet 827 Checksum Complement field, and a 2-octet reserved field. The 828 Checksum Complement can be used when IOAM is transported over 829 encapsulations that make use of a UDP transport, such as VXLAN-GPE 830 or Geneve. In this case, incorporating the IOAM node data 831 requires the UDP Checksum field to be updated. Rather than to 832 recompute the Chekcsum field, a node can use the Checksum 833 Complement to make a checksum-neutral update in the UDP payload; 834 the Checksum Complement is assigned a value that complements the 835 rest of the node data fields that were added by the current node, 836 causing the existing UDP Checksum field to remain correct. 837 Checksum Complement fields are used in a similar manner in 838 [RFC7820] and [RFC7821]. 840 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 841 8 9 0 1 2 3 4 5 6 7 8 9 0 1 842 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 843 | Checksum Complement | Reserved | 844 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 846 4.1.4. Examples of IOAM node data 848 An entry in the "node data list" array can have different formats, 849 following the needs of the deployment. Some deployments might only 850 be interested in recording the node identifiers, whereas others might 851 be interested in recording node identifier and timestamp. The 852 section defines different types that an entry in "node data list" can 853 take. 855 0xD400: IOAM-Trace-Type is 0xD400 then the format of node data is: 857 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 858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 859 | Hop_Lim | node_id | 860 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 861 | ingress_if_id | egress_if_id | 862 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 863 | timestamp nanoseconds | 864 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 865 | app_data | 866 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 868 0xC000: IOAM-Trace-Type is 0xC000 then the format is: 870 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 871 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 872 | Hop_Lim | node_id | 873 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 874 | ingress_if_id | egress_if_id | 875 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 877 0x9000: IOAM-Trace-Type is 0x9000 then the format is: 879 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 880 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 881 | Hop_Lim | node_id | 882 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 883 | timestamp nanoseconds | 884 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 886 0x8400: IOAM-Trace-Type is 0x8400 then the format is: 888 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 889 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 890 | Hop_Lim | node_id | 891 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 892 | app_data | 893 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 895 0x9400: IOAM-Trace-Type is 0x9400 then the format is: 897 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 898 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 899 | Hop_Lim | node_id | 900 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 901 | timestamp nanoseconds | 902 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 903 | app_data | 904 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 906 0x3180: IOAM-Trace-Type is 0x3180 then the format is: 908 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 909 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 910 | timestamp seconds | 911 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 912 | timestamp nanoseconds | 913 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 914 | Length | Schema Id | 915 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 916 | | 917 | | 918 | Opaque data | 919 ~ ~ 920 . . 921 . . 922 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 923 | Hop_Lim | node_id | 924 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 925 | node_id(contd) | 926 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 928 4.2. IOAM Proof of Transit Option 930 IOAM Proof of Transit data is to support the path or service function 931 chain [RFC7665] verification use cases. Proof-of-transit uses 932 methods like nested hashing or nested encryption of the IOAM data or 933 mechanisms such as Shamir's Secret Sharing Schema (SSSS). While 934 details on how the IOAM data for the proof of transit option is 935 processed at IOAM encapsulating, decapsulating and transit nodes are 936 outside the scope of the document, all of these approaches share the 937 need to uniquely identify a packet as well as iteratively operate on 938 a set of information that is handed from node to node. 939 Correspondingly, two pieces of information are added as IOAM data to 940 the packet: 942 o Random: Unique identifier for the packet (e.g., 64-bits allow for 943 the unique identification of 2^64 packets). 945 o Cumulative: Information which is handed from node to node and 946 updated by every node according to a verification algorithm. 948 IOAM proof of transit option: 950 IOAM proof of transit option header: 952 0 1 2 3 4 5 6 7 953 +-+-+-+-+-+-+-+-+ 954 |IOAM POT Type|P| 955 +-+-+-+-+-+-+-+-+ 957 IOAM proof of transit option data MUST be 4-octet aligned: 959 0 1 2 3 960 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 961 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ 962 | Random | | 963 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ P 964 | Random(contd) | O 965 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ T 966 | Cumulative | | 967 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 968 | Cumulative (contd) | | 969 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ 971 IOAM POT Type: 7-bit identifier of a particular POT variant that 972 dictates the POT data that is included. This document defines POT 973 Type 0: 975 0: POT data is a 16 Octet field as described below. 977 Profile to use (P): 1-bit. Indicates which POT-profile is used to 978 generate the Cumulative. Any node participating in POT will have 979 a maximum of 2 profiles configured that drive the computation of 980 cumulative. The two profiles are numbered 0, 1. This bit conveys 981 whether profile 0 or profile 1 is used to compute the Cumulative. 983 Random: 64-bit Per packet Random number. 985 Cumulative: 64-bit Cumulative that is updated at specific nodes by 986 processing per packet Random number field and configured 987 parameters. 989 Note: Larger or smaller sizes of "Random" and "Cumulative" data are 990 feasible and could be required for certain deployments (e.g. in case 991 of space constraints in the transport protocol used). Future 992 versions of this document will address different sizes of data for 993 "proof of transit". 995 4.3. IOAM Edge-to-Edge Option 997 The IOAM edge-to-edge option is to carry data that is added by the 998 IOAM encapsulating node and interpreted by IOAM decapsulating node. 999 The IOAM transit nodes MAY process the data without modifying it. 1001 Currently only sequence numbers use the IOAM edge-to-edge option. In 1002 order to detect packet loss, packet reordering, or packet duplication 1003 in an in-situ OAM-domain, sequence numbers can be added to packets of 1004 a particular tube (see [I-D.hildebrand-spud-prototype]). Each tube 1005 leverages a dedicated namespace for its sequence numbers. 1007 IOAM edge-to-edge option: 1009 IOAM edge-to-edge option header: 1011 0 1 2 3 4 5 6 7 1012 +-+-+-+-+-+-+-+-+ 1013 | IOAM-E2E-Type | 1014 +-+-+-+-+-+-+-+-+ 1016 IOAM edge-to-edge option data MUST be 4-octet aligned: 1018 0 1 2 3 1019 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 1020 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1021 | E2E Option data field determined by IOAM-E2E-Type | 1022 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1024 IOAM-E2E-Type: 8-bit identifier of a particular in situ OAM E2E 1025 variant. 1027 0: E2E option data is a 64-bit sequence number added to a 1028 specific tube which is used to identify packet loss and 1029 reordering for that tube. 1031 5. IOAM Data Export 1033 IOAM nodes collect information for packets traversing a domain that 1034 supports IOAM. IOAM decapsulating nodes as well as IOAM transit 1035 nodes can choose to retrieve IOAM information from the packet, 1036 process the information further and export the information using 1037 e.g., IPFIX. 1039 The discussion of IOAM data processing and export is left for a 1040 future version of this document. 1042 6. IANA Considerations 1044 This document requests the following IANA Actions. 1046 6.1. Creation of a new In-Situ OAM Protocol Parameters Registry (IOAM) 1047 Protocol Parameters IANA registry 1049 IANA is requested to create a new protocol registry for "In-Situ OAM 1050 (IOAM) Protocol Parameters". This is the common registry that will 1051 include registrations for all IOAM namespaces. Each Registry, whose 1052 names are listed below: 1054 IOAM Trace Type 1056 IOAM Trace flags 1058 IOAM POT Type 1060 IOAM E2E Type 1062 will contain the current set of possibilities defined in this 1063 document. New registries in this name space are created via RFC 1064 Required process as per [RFC8126]. 1066 The subsequent sub-sections detail the registries herein contained. 1068 6.2. IOAM Trace Type Registry 1070 This registry defines code point for each bit in the 16-bit IOAM- 1071 Trace-Type field for Pre-allocated trace option and Incremental trace 1072 option defined in Section 4.1. The meaning of Bit 0 - 11 for trace 1073 type are defined in this document in Paragraph 1 of (Section 4.1.1). 1074 The meaning for Bit 12 - 15 are available for assignment via RFC 1075 Required process as per [RFC8126]. 1077 6.3. IOAM Trace Flags Registry 1079 This registry defines code point for each bit in the 5 bit flags for 1080 Pre-allocated trace option and Incremental trace option defined in 1081 Section 4.1. The meaning of Bit 0 - 1 for trace flags are defined in 1082 this document in Paragraph 5 of Section 4.1.1. The meaning for Bit 2 1083 - 4 are available for assignment via RFC Required process as per 1084 [RFC8126]. 1086 6.4. IOAM POT Type Registry 1088 This registry defines 128 code points to define IOAM POT Type for 1089 IOAM proof of transit option Section 4.2. The code point value 0 is 1090 defined in this document, 1 - 127 are available for assignment via 1091 RFC Required process as per [RFC8126]. 1093 6.5. IOAM E2E Type Registry 1095 This registry defines 256 code points to define IOAM-E2E-Type for 1096 IOAM E2E option Section 4.3. The code point value 0 is defined in 1097 this document, 1 - 255 are available for assignments via RFC Required 1098 process as per [RFC8126]. 1100 7. Manageability Considerations 1102 Manageability considerations will be addressed in a later version of 1103 this document.. 1105 8. Security Considerations 1107 Security considerations will be addressed in a later version of this 1108 document. For a discussion of security requirements of in-situ OAM, 1109 please refer to [I-D.brockners-inband-oam-requirements]. 1111 9. Acknowledgements 1113 The authors would like to thank Eric Vyncke, Nalini Elkins, Srihari 1114 Raghavan, Ranganathan T S, Karthik Babu Harichandra Babu, Akshaya 1115 Nadahalli, LJ Wobker, Erik Nordmark, Vengada Prasad Govindan, and 1116 Andrew Yourtchenko for the comments and advice. 1118 This document leverages and builds on top of several concepts 1119 described in [I-D.kitamura-ipv6-record-route]. The authors would 1120 like to acknowledge the work done by the author Hiroshi Kitamura and 1121 people involved in writing it. 1123 The authors would like to gracefully acknowledge useful review and 1124 insightful comments received from Joe Clarke, Al Morton, and Mickey 1125 Spiegel. 1127 10. References 1129 10.1. Normative References 1131 [IEEE1588v2] 1132 Institute of Electrical and Electronics Engineers, 1133 "1588-2008 - IEEE Standard for a Precision Clock 1134 Synchronization Protocol for Networked Measurement and 1135 Control Systems", IEEE Std 1588-2008, 2008, 1136 . 1139 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1140 Requirement Levels", BCP 14, RFC 2119, 1141 DOI 10.17487/RFC2119, March 1997, . 1144 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1145 Writing an IANA Considerations Section in RFCs", BCP 26, 1146 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1147 . 1149 10.2. Informative References 1151 [I-D.brockners-inband-oam-requirements] 1152 Brockners, F., Bhandari, S., Dara, S., Pignataro, C., 1153 Gredler, H., Leddy, J., Youell, S., Mozes, D., Mizrahi, 1154 T., <>, P., and r. remy@barefootnetworks.com, 1155 "Requirements for In-situ OAM", draft-brockners-inband- 1156 oam-requirements-03 (work in progress), March 2017. 1158 [I-D.brockners-inband-oam-transport] 1159 Brockners, F., Bhandari, S., Govindan, V., Pignataro, C., 1160 Gredler, H., Leddy, J., Youell, S., Mizrahi, T., Mozes, 1161 D., Lapukhov, P., and R. Chang, "Encapsulations for In- 1162 situ OAM Data", draft-brockners-inband-oam-transport-05 1163 (work in progress), July 2017. 1165 [I-D.hildebrand-spud-prototype] 1166 Hildebrand, J. and B. Trammell, "Substrate Protocol for 1167 User Datagrams (SPUD) Prototype", draft-hildebrand-spud- 1168 prototype-03 (work in progress), March 2015. 1170 [I-D.ietf-nvo3-geneve] 1171 Gross, J., Ganga, I., and T. Sridhar, "Geneve: Generic 1172 Network Virtualization Encapsulation", draft-ietf- 1173 nvo3-geneve-05 (work in progress), September 2017. 1175 [I-D.ietf-nvo3-vxlan-gpe] 1176 Maino, F., Kreeger, L., and U. Elzur, "Generic Protocol 1177 Extension for VXLAN", draft-ietf-nvo3-vxlan-gpe-04 (work 1178 in progress), April 2017. 1180 [I-D.ietf-sfc-nsh] 1181 Quinn, P., Elzur, U., and C. Pignataro, "Network Service 1182 Header (NSH)", draft-ietf-sfc-nsh-27 (work in progress), 1183 October 2017. 1185 [I-D.kitamura-ipv6-record-route] 1186 Kitamura, H., "Record Route for IPv6 (PR6) Hop-by-Hop 1187 Option Extension", draft-kitamura-ipv6-record-route-00 1188 (work in progress), November 2000. 1190 [I-D.lapukhov-dataplane-probe] 1191 Lapukhov, P. and r. remy@barefootnetworks.com, "Data-plane 1192 probe for in-band telemetry collection", draft-lapukhov- 1193 dataplane-probe-01 (work in progress), June 2016. 1195 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 1196 Chaining (SFC) Architecture", RFC 7665, 1197 DOI 10.17487/RFC7665, October 2015, . 1200 [RFC7799] Morton, A., "Active and Passive Metrics and Methods (with 1201 Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, 1202 May 2016, . 1204 [RFC7820] Mizrahi, T., "UDP Checksum Complement in the One-Way 1205 Active Measurement Protocol (OWAMP) and Two-Way Active 1206 Measurement Protocol (TWAMP)", RFC 7820, 1207 DOI 10.17487/RFC7820, March 2016, . 1210 [RFC7821] Mizrahi, T., "UDP Checksum Complement in the Network Time 1211 Protocol (NTP)", RFC 7821, DOI 10.17487/RFC7821, March 1212 2016, . 1214 Authors' Addresses 1216 Frank Brockners 1217 Cisco Systems, Inc. 1218 Hansaallee 249, 3rd Floor 1219 DUESSELDORF, NORDRHEIN-WESTFALEN 40549 1220 Germany 1222 Email: fbrockne@cisco.com 1223 Shwetha Bhandari 1224 Cisco Systems, Inc. 1225 Cessna Business Park, Sarjapura Marathalli Outer Ring Road 1226 Bangalore, KARNATAKA 560 087 1227 India 1229 Email: shwethab@cisco.com 1231 Carlos Pignataro 1232 Cisco Systems, Inc. 1233 7200-11 Kit Creek Road 1234 Research Triangle Park, NC 27709 1235 United States 1237 Email: cpignata@cisco.com 1239 Hannes Gredler 1240 RtBrick Inc. 1242 Email: hannes@rtbrick.com 1244 John Leddy 1245 Comcast 1247 Email: John_Leddy@cable.comcast.com 1249 Stephen Youell 1250 JP Morgan Chase 1251 25 Bank Street 1252 London E14 5JP 1253 United Kingdom 1255 Email: stephen.youell@jpmorgan.com 1257 Tal Mizrahi 1258 Marvell 1259 6 Hamada St. 1260 Yokneam 2066721 1261 Israel 1263 Email: talmi@marvell.com 1264 David Mozes 1265 Mellanox Technologies Ltd. 1267 Email: davidm@mellanox.com 1269 Petr Lapukhov 1270 Facebook 1271 1 Hacker Way 1272 Menlo Park, CA 94025 1273 US 1275 Email: petr@fb.com 1277 Remy Chang 1278 Barefoot Networks 1279 2185 Park Boulevard 1280 Palo Alto, CA 94306 1281 US 1283 Daniel 1284 Bell Canada 1286 Email: daniel.bernier@bell.ca