idnits 2.17.1 draft-ietf-ippm-ioam-conf-state-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 (26 January 2022) is 819 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) == Outdated reference: A later version (-11) exists of draft-ietf-ippm-ioam-direct-export-07 == Outdated reference: A later version (-13) exists of draft-ietf-bier-ping-07 == Outdated reference: A later version (-28) exists of draft-ietf-sfc-multi-layer-oam-18 == Outdated reference: A later version (-02) exists of draft-xiao-6man-icmpv6-ioam-conf-state-00 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPPM Working Group X. Min 3 Internet-Draft ZTE Corp. 4 Intended status: Standards Track G. Mirsky 5 Expires: 30 July 2022 Ericsson 6 L. Bo 7 China Telecom 8 26 January 2022 10 Echo Request/Reply for Enabled In-situ OAM Capabilities 11 draft-ietf-ippm-ioam-conf-state-03 13 Abstract 15 This document describes an extension to the echo request/reply 16 mechanisms used in IPv6 (including SRv6), MPLS (including SR-MPLS), 17 SFC and BIER environments, which can be used within the IOAM domain, 18 allowing the IOAM encapsulating node to discover the enabled IOAM 19 capabilities of each IOAM transit and IOAM decapsulating node. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on 30 July 2022. 38 Copyright Notice 40 Copyright (c) 2022 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 45 license-info) in effect on the date of publication of this document. 46 Please review these documents carefully, as they describe your rights 47 and restrictions with respect to this document. Code Components 48 extracted from this document must include Revised BSD License text as 49 described in Section 4.e of the Trust Legal Provisions and are 50 provided without warranty as described in the Revised BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 57 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 5 58 3. IOAM Capabilities Formats . . . . . . . . . . . . . . . . . . 5 59 3.1. IOAM Capabilities Query Container . . . . . . . . . . . . 6 60 3.2. IOAM Capabilities Response Container . . . . . . . . . . 6 61 3.2.1. IOAM Pre-allocated Tracing Capabilities Object . . . 7 62 3.2.2. IOAM Incremental Tracing Capabilities Object . . . . 8 63 3.2.3. IOAM Proof-of-Transit Capabilities Object . . . . . . 9 64 3.2.4. IOAM Edge-to-Edge Capabilities Object . . . . . . . . 10 65 3.2.5. IOAM DEX Capabilities Object . . . . . . . . . . . . 11 66 3.2.6. IOAM End-of-Domain Object . . . . . . . . . . . . . . 12 67 4. Operational Guide . . . . . . . . . . . . . . . . . . . . . . 13 68 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 69 5.1. IOAM SoP Capability Registry . . . . . . . . . . . . . . 14 70 5.2. IOAM TSF Capability Registry . . . . . . . . . . . . . . 14 71 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 72 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 73 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 74 8.1. Normative References . . . . . . . . . . . . . . . . . . 15 75 8.2. Informative References . . . . . . . . . . . . . . . . . 16 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 78 1. Introduction 80 In-situ OAM (IOAM) ([I-D.ietf-ippm-ioam-data] 81 [I-D.ietf-ippm-ioam-direct-export]) defines data fields that record 82 OAM information within the packet while the packet traverses a 83 particular network domain, called an IOAM domain. IOAM can be used 84 to complement OAM mechanisms based on, e.g., ICMP or other types of 85 probe packets, and IOAM mechanisms can be leveraged where mechanisms 86 using, e.g., ICMP, do not apply or do not offer the desired results. 88 As specified in [I-D.ietf-ippm-ioam-data], within the IOAM domain, 89 the IOAM data may be updated by network nodes that the packet 90 traverses. The device which adds an IOAM header to the packet is 91 called an "IOAM encapsulating node". In contrast, the device which 92 removes an IOAM header is referred to as an "IOAM decapsulating 93 node". Nodes within the domain that are aware of IOAM data and read 94 and/or write and/or process IOAM data are called "IOAM transit 95 nodes". IOAM encapsulating or decapsulating nodes can also serve as 96 IOAM transit nodes at the same time. IOAM encapsulating or 97 decapsulating nodes are also referred to as IOAM domain edge devices, 98 which can be hosts or network devices. 100 As specified in [I-D.ietf-ippm-ioam-data], IOAM is focused on 101 "limited domains" as defined in [RFC8799]. In a limited domain, a 102 control entity that has control over every IOAM device may be 103 deployed. If that's the case, the control entity can provision both 104 the explicit transport path and the IOAM header applied to data 105 packet at every IOAM encapsulating node. 107 In a case when a control entity that has control over every IOAM 108 device is not deployed in the IOAM domain, the IOAM encapsulating 109 node needs to discover the enabled IOAM capabilities at the IOAM 110 transit and decapsulating nodes. For example, what types of IOAM 111 tracing data can be added by the transit nodes along the transport 112 path of the data packet IOAM is applied to. The IOAM encapsulating 113 node can then add the correct IOAM header to the data packet 114 according to the discovered IOAM capabilities. Specifically, the 115 IOAM encapsulating node first identifies the types and lengths of 116 IOAM options included in the IOAM data according to the discovered 117 IOAM capabilities. Then the IOAM encapsulating node can add the IOAM 118 header to the data packet based on the identified types and lengths 119 of IOAM options included in the IOAM data. The IOAM encapsulating 120 node may use NETCONF/YANG or IGP to discover these IOAM capabilities. 121 However, NETCONF/YANG or IGP has some limitations: 123 * When NETCONF/YANG is used in this scenario, each IOAM 124 encapsulating node (including the host when it takes the role of 125 an IOAM encapsulating node) needs to implement a NETCONF Client, 126 each IOAM transit and IOAM decapsulating node (including the host 127 when it takes the role of an IOAM decapsulating node) needs to 128 implement a NETCONF Server, the complexity can be an issue. 129 Furthermore, each IOAM encapsulating node needs to establish 130 NETCONF Connection with each IOAM transit and IOAM decapsulating 131 node, the scalability can be an issue. 133 * When IGP is used in this scenario, the IGP and IOAM domains don't 134 always have the same coverage. For example, when the IOAM 135 encapsulating node or the IOAM decapsulating node is a host, the 136 availability can be an issue. Furthermore, it might be too 137 challenging to reflect enabled IOAM capabilities at the IOAM 138 transit and IOAM decapsulating node if these are controlled by a 139 local policy depending on the identity of the IOAM encapsulating 140 node. 142 This document describes an extension to the echo request/reply 143 mechanisms used in IPv6 (including SRv6), MPLS (including SR-MPLS), 144 SFC and BIER environments, which can be used within the IOAM domain, 145 allowing the IOAM encapsulating node to discover the enabled IOAM 146 capabilities of each IOAM transit and IOAM decapsulating node. 148 The following documents contain references to the echo request/reply 149 mechanisms used in IPv6 (including SRv6), MPLS (including SR-MPLS), 150 SFC and BIER environments: 152 * [RFC4443] ("Internet Control Message Protocol (ICMPv6) for the 153 Internet Protocol Version 6 (IPv6) Specification"), [RFC4884] 154 ("Extended ICMP to Support Multi-Part Messages") and [RFC8335] 155 ("PROBE: A Utility for Probing Interfaces") 157 * [RFC8029] ("Detecting Multiprotocol Label Switched (MPLS) Data- 158 Plane Failures") 160 * [I-D.ietf-sfc-multi-layer-oam] ("Active OAM for Service Function 161 Chains in Networks") 163 * [I-D.ietf-bier-ping] ("BIER Ping and Trace") 165 The precondition for the feature described in this document to work 166 is that the echo request reaches each IOAM transit node as the data 167 packet traverses, so the feature is applied to explicit path (strict 168 or loose), or there is only one path between the IOAM encapsulating 169 node and the IOAM decapsulating node, or the echo request can 170 experience the same ECMP processing as the data packet. 172 2. Conventions 174 2.1. Requirements Language 176 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 177 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 178 "OPTIONAL" in this document are to be interpreted as described in BCP 179 14 [RFC2119] [RFC8174] when, and only when, they appear in all 180 capitals, as shown here. 182 2.2. Abbreviations 184 BIER: Bit Index Explicit Replication 186 BGP: Border Gateway Protocol 188 ECMP: Equal-Cost Multipath 190 E2E: Edge to Edge 192 ICMP: Internet Control Message Protocol 194 IGP: Interior Gateway Protocol 196 IOAM: In-situ Operations, Administration, and Maintenance 198 LSP: Label Switched Path 200 MPLS: Multi-Protocol Label Switching 202 MBZ: Must Be Zero 204 MTU: Maximum Transmission Unit 206 NTP: Network Time Protocol 208 OAM: Operations, Administration, and Maintenance 210 PCEP: Path Computation Element (PCE) Communication Protocol 212 POSIX: Portable Operating System Interface 214 POT: Proof of Transit 216 PTP: Precision Time Protocol 218 SR-MPLS: Segment Routing with MPLS data plane 220 SRv6: Segment Routing with IPv6 data plane 222 SFC: Service Function Chain 224 TTL: Time to Live 226 3. IOAM Capabilities Formats 227 3.1. IOAM Capabilities Query Container 229 For echo request, IOAM Capabilities Query uses container which has 230 the following format: 232 0 1 2 3 233 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 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 . . 236 . IOAM Capabilities Query Container Header . 237 . . 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 . . 240 . List of Namespace-IDs . 241 . . 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 Figure 1: IOAM Capabilities Query Container of Echo Request 246 When this container is present in or equal to the echo request sent 247 by an IOAM encapsulating node, that means the IOAM encapsulating node 248 requests the receiving node to reply with its enabled IOAM 249 capabilities. If there is no IOAM capability to be reported by the 250 receiving node, then this container SHOULD be ignored by the 251 receiving node, which means the receiving node SHOULD send an echo 252 reply without IOAM capabilities or no echo reply, in the light of 253 whether the echo request includes other containers than the IOAM 254 Capabilities Query Container. A list of Namespace-IDs (one or more 255 Namespace-IDs) MUST be included in this container in the echo 256 request. The IOAM encapsulating node requests only the enabled IOAM 257 capabilities that match one of the Namespace-IDs. The Namespace-ID 258 has the same definition as what's specified in Section 5.3 of 259 [I-D.ietf-ippm-ioam-data]. 261 The IOAM Capabilities Query Container has a container header that is 262 used to identify the type and optionally length of the container 263 payload, and the container payload (List of Namespace-IDs) is zero- 264 padded to align to a 4-octet boundary. 266 The length, structure, and definition of the IOAM Capabilities Query 267 Container Header depends on the specific environment it is applied 268 at. 270 3.2. IOAM Capabilities Response Container 272 For echo reply, IOAM Capabilities Response uses container which has 273 the following format: 275 0 1 2 3 276 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 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 . . 279 . IOAM Capabilities Response Container Header . 280 . . 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 . . 283 . List of Objects . 284 . . 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 Figure 2: IOAM Capabilities Response Container of Echo Reply 289 When this container is present in or equal to the echo reply sent by 290 an IOAM transit node or IOAM decapsulating node, that means the IOAM 291 function is enabled at this node, and this container contains the 292 enabled IOAM capabilities of the sender. A list of objects (one or 293 more objects) which contains the enabled IOAM capabilities SHOULD be 294 included in this container of echo reply. 296 The IOAM Capabilities Response Container has a container header that 297 is used to identify the type and optionally length of the container 298 payload, and the container payload (List of Objects) is zero-padded 299 to align to a 4-octet boundary. 301 The length, structure, and definition of the IOAM Capabilities 302 Response Container Header depends on the specific environment it is 303 applied at. 305 Based on the IOAM data fields defined in [I-D.ietf-ippm-ioam-data] 306 and [I-D.ietf-ippm-ioam-direct-export], six types of objects are 307 defined in this document. The same type of object MAY be present in 308 the IOAM Capabilities Response Container more than once, only if with 309 a different Namespace-ID. 311 Similar to the container, each object has an object header that is 312 used to identify the type and length of the object payload, and the 313 object payload is zero-padded to align to a 4-octet boundary. 315 The length, structure, and definition of Object Header depends on the 316 specific environment it is applied at. 318 3.2.1. IOAM Pre-allocated Tracing Capabilities Object 319 0 1 2 3 320 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 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 . . 323 . IOAM Pre-allocated Tracing Capabilities Object Header . 324 . . 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 | IOAM-Trace-Type | Reserved |W| 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 | Namespace-ID | Ingress_MTU | 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 | Ingress_if_id (short or wide format) ...... | 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 Figure 3: IOAM Pre-allocated Tracing Capabilities Object 335 When this Object is present in the IOAM Capabilities Response 336 Container, that means the sending node is an IOAM transit node and 337 the IOAM pre-allocated tracing function is enabled at this IOAM 338 transit node. 340 IOAM-Trace-Type field has the same definition as what's specified in 341 Section 5.4 of [I-D.ietf-ippm-ioam-data]. 343 Reserved field is reserved for future use and MUST be set to zero. 345 W flag indicates whether Ingress_if_id is in short or wide format. 346 The W-bit is set if the Ingress_if_id is in wide format. The W-bit 347 is clear if the Ingress_if_id is in short format. 349 Namespace-ID field has the same definition as what's specified in 350 Section 5.3 of [I-D.ietf-ippm-ioam-data], it should be one of the 351 Namespace-IDs listed in the IOAM Capabilities Query Object of the 352 echo request. 354 Ingress_MTU field has 16 bits and specifies the MTU (in octets) of 355 the ingress interface from which the sending node received echo 356 request. 358 Ingress_if_id field has 16 bits (in short format) or 32 bits (in wide 359 format) and specifies the identifier of the ingress interface from 360 which the sending node received echo request. If the W-bit is 361 cleared that indicates Ingress_if_id field has 16 bits, then the 16 362 bits following the Ingress_if_id field are reserved for future use 363 and MUST be set to zero. 365 3.2.2. IOAM Incremental Tracing Capabilities Object 366 0 1 2 3 367 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 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 . . 370 . IOAM Incremental Tracing Capabilities Object Header . 371 . . 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 | IOAM-Trace-Type | Reserved |W| 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 | Namespace-ID | Ingress_MTU | 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 | Ingress_if_id (short or wide format) ...... | 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 Figure 4: IOAM Incremental Tracing Capabilities Object 382 When this Object is present in the IOAM Capabilities Response 383 Container, that means the sending node is an IOAM transit node and 384 the IOAM incremental tracing function is enabled at this IOAM transit 385 node. 387 IOAM-Trace-Type field has the same definition as what's specified in 388 Section 5.4 of [I-D.ietf-ippm-ioam-data]. 390 Reserved field is reserved for future use and MUST be set to zero. 392 W flag indicates whether Ingress_if_id is in short or wide format. 393 The W-bit is set if the Ingress_if_id is in wide format. The W-bit 394 is clear if the Ingress_if_id is in short format. 396 Namespace-ID field has the same definition as what's specified in 397 Section 5.3 of [I-D.ietf-ippm-ioam-data], it should be one of the 398 Namespace-IDs listed in the IOAM Capabilities Query Object of the 399 echo request. 401 Ingress_MTU field has 16 bits and specifies the MTU (in octets) of 402 the ingress interface from which the sending node received echo 403 request. 405 Ingress_if_id field has 16 bits (in short format) or 32 bits (in wide 406 format) and specifies the identifier of the ingress interface from 407 which the sending node received echo request. If the W-bit is 408 cleared that indicates Ingress_if_id field has 16 bits, then the 16 409 bits following the Ingress_if_id field are reserved for future use 410 and MUST be set to zero. 412 3.2.3. IOAM Proof-of-Transit Capabilities Object 413 0 1 2 3 414 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 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 . . 417 . IOAM Proof-of-Transit Capabilities Object Header . 418 . . 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 | Namespace-ID | IOAM-POT-Type |SoP| Reserved | 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 Figure 5: IOAM Proof-of-Transit Capabilities Object 425 When this Object is present in the IOAM Capabilities Response 426 Container, that means the sending node is an IOAM transit node and 427 the IOAM Proof of Transit function is enabled at this IOAM transit 428 node. 430 Namespace-ID field has the same definition as what's specified in 431 Section 5.3 of [I-D.ietf-ippm-ioam-data], it should be one of the 432 Namespace-IDs listed in the IOAM Capabilities Query Object of the 433 echo request. 435 IOAM-POT-Type field has the same definition as what's specified in 436 Section 5.5 of [I-D.ietf-ippm-ioam-data]. 438 SoP field has two bits, which means the size of "PktID" and 439 "Cumulative" data that are specified in Section 5.5 of 440 [I-D.ietf-ippm-ioam-data]. This document defines SoP as follow: 442 0b00 means 64-bit "PktID" and 64-bit "Cumulative" data. 444 0b01~0b11: Reserved for future standardization 446 Reserved field is reserved for future use and MUST be set to zero. 448 3.2.4. IOAM Edge-to-Edge Capabilities Object 449 0 1 2 3 450 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 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 . . 453 . IOAM Edge-to-Edge Capabilities Object Header . 454 . . 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 | Namespace-ID | IOAM-E2E-Type | 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 |TSF| Reserved | MBZ | 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 Figure 6: IOAM Edge-to-Edge Capabilities Object 463 When this Object is present in the IOAM Capabilities Response 464 Container, that means the sending node is an IOAM decapsulating node 465 and IOAM edge-to-edge function is enabled at this IOAM decapsulating 466 node. 468 Namespace-ID field has the same definition as what's specified in 469 Section 5.3 of [I-D.ietf-ippm-ioam-data], it should be one of the 470 Namespace-IDs listed in the IOAM Capabilities Query Object of the 471 echo request. 473 IOAM-E2E-Type field has the same definition as what's specified in 474 Section 5.6 of [I-D.ietf-ippm-ioam-data]. 476 TSF field specifies the timestamp format used by the sending node. 477 Aligned with three possible timestamp formats specified in Section 6 478 of [I-D.ietf-ippm-ioam-data], this document defines TSF as follows: 480 0b00: PTP truncated timestamp format 482 0b01: NTP 64-bit timestamp format 484 0b10: POSIX-based timestamp format 486 0b11: Reserved for future standardization 488 Reserved field is reserved for future use and MUST be set to zero. 490 3.2.5. IOAM DEX Capabilities Object 491 0 1 2 3 492 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 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 . . 495 . IOAM DEX Capabilities Object Header . 496 . . 497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 498 | IOAM-Trace-Type | Reserved | 499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 500 | Namespace-ID | Reserved | 501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 503 Figure 7: IOAM DEX Capabilities Object 505 When this Object is present in the IOAM Capabilities Response 506 Container, that means the sending node is an IOAM transit node and 507 the IOAM direct exporting function is enabled at this IOAM transit 508 node. 510 IOAM-Trace-Type field has the same definition as what's specified in 511 Section 3.2 of [I-D.ietf-ippm-ioam-direct-export]. 513 Namespace-ID field has the same definition as what's specified in 514 Section 5.3 of [I-D.ietf-ippm-ioam-data], it should be one of the 515 Namespace-IDs listed in the IOAM Capabilities Query Object of the 516 echo request. 518 Reserved field is reserved for future use and MUST be set to zero. 520 3.2.6. IOAM End-of-Domain Object 522 0 1 2 3 523 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 524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 525 . . 526 . IOAM End-of-Domain Object Header . 527 . . 528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 529 | Namespace-ID | MBZ | 530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 532 Figure 8: IOAM End-of-Domain Object 534 When this Object is present in the IOAM Capabilities Response 535 Container, that means the sending node is an IOAM decapsulating node. 536 Unless the IOAM Edge-to-Edge Capabilities Object is present, which 537 also indicates that the sending node is an IOAM decapsulating node, 538 the End-of-Domain Object MUST be present in the IOAM Capabilities 539 Response Container sent by an IOAM decapsulating node. When the IOAM 540 edge-to-edge function is enabled at the IOAM decapsulating node, it's 541 RECOMMENDED to include only the IOAM Edge-to-Edge Capabilities Object 542 but not the IOAM End-of-Domain Object. 544 Namespace-ID field has the same definition as what's specified in 545 Section 5.3 of [I-D.ietf-ippm-ioam-data], it SHOULD be one of the 546 Namespace-IDs listed in the IOAM Capabilities Query Container. 548 4. Operational Guide 550 Once the IOAM encapsulating node is triggered to discover the enabled 551 IOAM capabilities of each IOAM transit and IOAM decapsulating node, 552 the IOAM encapsulating node will send echo requests that include the 553 IOAM Capabilities Query Container. First, with TTL equal to 1 to 554 reach the closest node, which may be an IOAM transit node or not. 555 Then with TTL equal to 2 to reach the second nearest node, which also 556 may be an IOAM transit node or not. And further, increasing by 1 the 557 TTL every time the IOAM encapsulating node sends a new echo request, 558 until the IOAM encapsulating node receives an echo reply sent by the 559 IOAM decapsulating node, which should contain the IOAM Capabilities 560 Response Container including the IOAM Edge-to-Edge Capabilities 561 Object or the IOAM End-of-Domain Object. Alternatively, if the IOAM 562 encapsulating node knows precisely all the IOAM transit and IOAM 563 decapsulating nodes beforehand, once the IOAM encapsulating node is 564 triggered to discover the enabled IOAM capabilities, it can send an 565 echo request to each IOAM transit and IOAM decapsulating node 566 directly, without TTL expiration. 568 The IOAM encapsulating node may be triggered by the device 569 administrator, the network management system, the network controller, 570 or data traffic. The specific triggering mechanisms are outside the 571 scope of this document. 573 Each IOAM transit and IOAM decapsulating node that receives an echo 574 request containing the IOAM Capabilities Query Container will send an 575 echo reply to the IOAM encapsulating node. For the echo reply, there 576 should be an IOAM Capabilities Response Container containing one or 577 more Objects. The IOAM Capabilities Query Container of the echo 578 request would be ignored by the receiving node unaware of IOAM. 580 5. IANA Considerations 582 This document requests the following IANA Actions. 584 IANA is requested to create a registry group named "In-Situ OAM 585 (IOAM) Capabilities Parameters". 587 This group will include the following registries: 589 * IOAM SoP Capability 591 * IOAM TSF Capability 593 New registries in this group can be created via RFC Required process 594 as per [RFC8126]. 596 The subsequent sub-sections detail the registries herein contained. 598 Considering the Containers/Objects defined in this document would be 599 carried in different types of Echo Request/Reply messages, such as 600 ICMPv6 or LSP Ping, it is intended that the registries for Container/ 601 Object Type would be requested in subsequent documents. 603 5.1. IOAM SoP Capability Registry 605 This registry defines 4 code points for the IOAM SoP Capability field 606 for identifying the size of "PktID" and "Cumulative" data as 607 explained in Section 5.5 of [I-D.ietf-ippm-ioam-data]. The following 608 code points are defined in this document: 610 SoP Description 611 ---- ----------- 612 0b00 64-bit "PktID" and 64-bit "Cumulative" data 614 0b01 - 0b11 are available for assignment via RFC Required process as 615 per [RFC8126]. 617 5.2. IOAM TSF Capability Registry 619 This registry defines 3 code points for the IOAM TSF Capability field 620 for identifying the timestamp format as explained in Section 6 of 621 [I-D.ietf-ippm-ioam-data]. The following code points are defined in 622 this document: 624 TSF Description 625 ---- ----------- 626 0b00 PTP Truncated Timestamp Format 627 0b01 NTP 64-bit Timestamp Format 628 0b10 POSIX-based Timestamp Format 630 0b11 is available for assignment via RFC Required process as per 631 [RFC8126]. 633 6. Security Considerations 635 Queries and responses about the state of an IOAM domain should be 636 processed only from a trusted source. An unauthorized query MUST be 637 discarded by an implementation that supports this specification. 638 Similarly, an unsolicited echo response with the IOAM Capabilities 639 Container MUST be discarded. Authentication of echo request/reply 640 that includes the IOAM Capabilities Container is one of the integrity 641 protection methods. Implementations could also provide a means of 642 filtering based on the source address of the received echo request/ 643 reply. The integrity protection for enabled IOAM capabilities 644 information collection can also be achieved using mechanisms in the 645 underlay data plane. For example, if the underlay is an IPv6 646 network, IP Authentication Header [RFC4302] or IP Encapsulating 647 Security Payload Header [RFC4303] can be used to provide integrity 648 protection, the specific requirements on integrity protection for 649 enabled IOAM capabilities in IPv6 networks are discussed in 650 [I-D.xiao-6man-icmpv6-ioam-conf-state]. 652 Information about the state of the IOAM domain collected in the IAOM 653 Capabilities Container is confidential. An implementation can use 654 secure transport to provide privacy protection. For example, if the 655 underlay is an IPv6 network, confidentiality can be achieved using 656 the IP Encapsulating Security Payload Header [RFC4303], the specific 657 requirements on privacy protection for enabled IOAM capabilities in 658 IPv6 networks are discussed in 659 [I-D.xiao-6man-icmpv6-ioam-conf-state]. 661 7. Acknowledgements 663 The authors would like to acknowledge Tianran Zhou, Dhruv Dhody, 664 Frank Brockners, Cheng Li and Gyan Mishra for their careful review 665 and helpful comments. 667 The authors appreciate the f2f discussion with Frank Brockners on 668 this document. 670 The authors would like to acknowledge Tommy Pauly and Ian Swett for 671 their good suggestion and guidance. 673 8. References 675 8.1. Normative References 677 [I-D.ietf-ippm-ioam-data] 678 Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields 679 for In-situ OAM", Work in Progress, Internet-Draft, draft- 680 ietf-ippm-ioam-data-17, 13 December 2021, 681 . 684 [I-D.ietf-ippm-ioam-direct-export] 685 Song, H., Gafni, B., Zhou, T., Li, Z., Brockners, F., 686 Bhandari, S., Sivakolundu, R., and T. Mizrahi, "In-situ 687 OAM Direct Exporting", Work in Progress, Internet-Draft, 688 draft-ietf-ippm-ioam-direct-export-07, 13 October 2021, 689 . 692 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 693 Requirement Levels", BCP 14, RFC 2119, 694 DOI 10.17487/RFC2119, March 1997, 695 . 697 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 698 Writing an IANA Considerations Section in RFCs", BCP 26, 699 RFC 8126, DOI 10.17487/RFC8126, June 2017, 700 . 702 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 703 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 704 May 2017, . 706 8.2. Informative References 708 [I-D.ietf-bier-ping] 709 Kumar, N., Pignataro, C., Akiya, N., Zheng, L., Chen, M., 710 and G. Mirsky, "BIER Ping and Trace", Work in Progress, 711 Internet-Draft, draft-ietf-bier-ping-07, 11 May 2020, 712 . 715 [I-D.ietf-sfc-multi-layer-oam] 716 Mirsky, G., Meng, W., Khasnabish, B., Ao, T., Leung, K., 717 and G. Mishra, "Active OAM for Service Function Chaining", 718 Work in Progress, Internet-Draft, draft-ietf-sfc-multi- 719 layer-oam-18, 20 December 2021, 720 . 723 [I-D.xiao-6man-icmpv6-ioam-conf-state] 724 Min, X. and G. Mirsky, "ICMPv6 Echo Request/Reply for 725 Enabled In-situ OAM Capabilities", Work in Progress, 726 Internet-Draft, draft-xiao-6man-icmpv6-ioam-conf-state-00, 727 24 October 2021, . 730 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 731 DOI 10.17487/RFC4302, December 2005, 732 . 734 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 735 RFC 4303, DOI 10.17487/RFC4303, December 2005, 736 . 738 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 739 Control Message Protocol (ICMPv6) for the Internet 740 Protocol Version 6 (IPv6) Specification", STD 89, 741 RFC 4443, DOI 10.17487/RFC4443, March 2006, 742 . 744 [RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, 745 "Extended ICMP to Support Multi-Part Messages", RFC 4884, 746 DOI 10.17487/RFC4884, April 2007, 747 . 749 [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., 750 Aldrin, S., and M. Chen, "Detecting Multiprotocol Label 751 Switched (MPLS) Data-Plane Failures", RFC 8029, 752 DOI 10.17487/RFC8029, March 2017, 753 . 755 [RFC8335] Bonica, R., Thomas, R., Linkova, J., Lenart, C., and M. 756 Boucadair, "PROBE: A Utility for Probing Interfaces", 757 RFC 8335, DOI 10.17487/RFC8335, February 2018, 758 . 760 [RFC8799] Carpenter, B. and B. Liu, "Limited Domains and Internet 761 Protocols", RFC 8799, DOI 10.17487/RFC8799, July 2020, 762 . 764 Authors' Addresses 766 Xiao Min 767 ZTE Corp. 768 Nanjing 769 China 770 Phone: +86 25 88013062 771 Email: xiao.min2@zte.com.cn 773 Greg Mirsky 774 Ericsson 775 United States of America 777 Email: gregimirsky@gmail.com 779 Lei Bo 780 China Telecom 781 Beijing 782 China 784 Phone: +86 10 50902903 785 Email: leibo@chinatelecom.cn