idnits 2.17.1 draft-ietf-ippm-ioam-conf-state-10.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 (21 November 2022) is 494 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 (-13) exists of draft-ietf-bier-ping-07 == Outdated reference: A later version (-28) exists of draft-ietf-sfc-multi-layer-oam-22 Summary: 0 errors (**), 0 flaws (~~), 3 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: 25 May 2023 Ericsson 6 L. Bo 7 China Telecom 8 21 November 2022 10 Echo Request/Reply for Enabled In-situ OAM Capabilities 11 draft-ietf-ippm-ioam-conf-state-10 13 Abstract 15 This document describes a generic format for use in echo request/ 16 reply mechanisms, which can be used within an In situ Operations, 17 Administration, and Maintenance (IOAM) domain, allowing the IOAM 18 encapsulating node to discover the enabled IOAM capabilities of each 19 IOAM transit and IOAM decapsulating node. The generic format is 20 intended to be used with a variety of data planes such as IPv6, MPLS, 21 Service Function Chain (SFC) and Bit Index Explicit Replication 22 (BIER). 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on 25 May 2023. 41 Copyright Notice 43 Copyright (c) 2022 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 48 license-info) in effect on the date of publication of this document. 49 Please review these documents carefully, as they describe your rights 50 and restrictions with respect to this document. Code Components 51 extracted from this document must include Revised BSD License text as 52 described in Section 4.e of the Trust Legal Provisions and are 53 provided without warranty as described in the Revised BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 60 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 5 61 3. IOAM Capabilities Formats . . . . . . . . . . . . . . . . . . 6 62 3.1. IOAM Capabilities Query Container . . . . . . . . . . . . 6 63 3.2. IOAM Capabilities Response Container . . . . . . . . . . 7 64 3.2.1. IOAM Pre-allocated Tracing Capabilities Object . . . 8 65 3.2.2. IOAM Incremental Tracing Capabilities Object . . . . 9 66 3.2.3. IOAM Proof-of-Transit Capabilities Object . . . . . . 10 67 3.2.4. IOAM Edge-to-Edge Capabilities Object . . . . . . . . 11 68 3.2.5. IOAM DEX Capabilities Object . . . . . . . . . . . . 12 69 3.2.6. IOAM End-of-Domain Object . . . . . . . . . . . . . . 12 70 4. Operational Guide . . . . . . . . . . . . . . . . . . . . . . 13 71 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 72 5.1. IOAM SoP Capability Registry . . . . . . . . . . . . . . 14 73 5.2. IOAM TSF Capability Registry . . . . . . . . . . . . . . 15 74 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 75 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 76 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 77 8.1. Normative References . . . . . . . . . . . . . . . . . . 17 78 8.2. Informative References . . . . . . . . . . . . . . . . . 17 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 81 1. Introduction 83 In situ Operations, Administration, and Maintenance (IOAM) ([RFC9197] 84 [RFC9326]) defines data fields that record OAM information within the 85 packet while the packet traverses a particular network domain, called 86 an IOAM domain. IOAM can complement or replace other OAM mechanisms, 87 such as ICMP or other types of probe packets. 89 As specified in [RFC9197], within the IOAM domain, the IOAM data may 90 be updated by network nodes that the packet traverses. The device 91 which adds an IOAM header to the packet is called an "IOAM 92 encapsulating node". In contrast, the device which removes an IOAM 93 header is referred to as an "IOAM decapsulating node". Nodes within 94 the domain that are aware of IOAM data and read and/or write and/or 95 process IOAM data are called "IOAM transit nodes". IOAM 96 encapsulating or decapsulating nodes can also serve as IOAM transit 97 nodes at the same time. IOAM encapsulating or decapsulating nodes 98 are also referred to as IOAM domain edge devices, which can be hosts 99 or network devices. [RFC9197] defines four IOAM option types, and 100 [RFC9326] introduces a new IOAM option type called the Direct Export 101 (DEX) Option-Type, which is different from the other four IOAM option 102 types defined in [RFC9197] on how to collect the operational and 103 telemetry information defined in [RFC9197]. 105 As specified in [RFC9197], IOAM is focused on "limited domains" as 106 defined in [RFC8799]. In a limited domain, a control entity that has 107 control over every IOAM device may be deployed. If that's the case, 108 the control entity can provision both the explicit transport path and 109 the IOAM header applied to data packet at every IOAM encapsulating 110 node. 112 In a case when a control entity that has control over every IOAM 113 device is not deployed in the IOAM domain, the IOAM encapsulating 114 node needs to discover the enabled IOAM capabilities at the IOAM 115 transit and decapsulating nodes. For example, what types of IOAM 116 tracing data can be added or exported by the transit nodes along the 117 transport path of the data packet IOAM is applied to. The IOAM 118 encapsulating node can then add the correct IOAM header to the data 119 packet according to the discovered IOAM capabilities. Specifically, 120 the IOAM encapsulating node first identifies the types and lengths of 121 IOAM options included in the IOAM data fields according to the 122 discovered IOAM capabilities. Then the IOAM encapsulating node can 123 add the IOAM header to the data packet based on the identified types 124 and lengths of IOAM options included in the IOAM data fields. The 125 IOAM encapsulating node may use NETCONF/YANG or IGP to discover these 126 IOAM capabilities. However, NETCONF/YANG or IGP has some 127 limitations: 129 * When NETCONF/YANG is used in this scenario, each IOAM 130 encapsulating node (including the host when it takes the role of 131 an IOAM encapsulating node) needs to implement a NETCONF Client, 132 each IOAM transit and IOAM decapsulating node (including the host 133 when it takes the role of an IOAM decapsulating node) needs to 134 implement a NETCONF Server, the complexity can be an issue. 135 Furthermore, each IOAM encapsulating node needs to establish 136 NETCONF Connection with each IOAM transit and IOAM decapsulating 137 node, the scalability can be an issue. 139 * When IGP is used in this scenario, the IGP and IOAM domains don't 140 always have the same coverage. For example, when the IOAM 141 encapsulating node or the IOAM decapsulating node is a host, the 142 availability can be an issue. Furthermore, it might be too 143 challenging to reflect enabled IOAM capabilities at the IOAM 144 transit and IOAM decapsulating node if these are controlled by a 145 local policy depending on the identity of the IOAM encapsulating 146 node. 148 This document specifies formats and objects that can be used in the 149 extension of echo request/reply mechanisms used in IPv6 (including 150 Segment Routing with IPv6 data plane (SRv6)), MPLS (including Segment 151 Routing with MPLS data plane (SR-MPLS)), SFC and BIER environments, 152 which can be used within the IOAM domain, allowing the IOAM 153 encapsulating node to discover the enabled IOAM capabilities of each 154 IOAM transit and IOAM decapsulating node. 156 The following documents contain references to the echo request/reply 157 mechanisms used in IPv6 (including SRv6), MPLS (including SR-MPLS), 158 SFC and BIER environments: 160 * [RFC4443] ("Internet Control Message Protocol (ICMPv6) for the 161 Internet Protocol Version 6 (IPv6) Specification"), [RFC4620] 162 ("IPv6 Node Information Queries"), [RFC4884] ("Extended ICMP to 163 Support Multi-Part Messages") and [RFC8335] ("PROBE: A Utility for 164 Probing Interfaces") 166 * [RFC8029] ("Detecting Multiprotocol Label Switched (MPLS) Data- 167 Plane Failures") 169 * [I-D.ietf-sfc-multi-layer-oam] ("Active OAM for Service Function 170 Chaining (SFC)") 172 * [I-D.ietf-bier-ping] ("BIER Ping and Trace") 174 It is expected that the specification of the instantiation of each of 175 these extensions will be done in the form of an RFC jointly designed 176 by the working group that develops or maintains the echo request/ 177 reply protocol and the IETF IP Performance Measurement (IPPM) Working 178 Group. 180 Note that in this document the echo request/reply mechanism used in 181 IPv6 does not mean ICMPv6 Echo Request/Reply [RFC4443], but means 182 IPv6 Node Information Query/Reply [RFC4620]. 184 Fate sharing is a common requirement for all kinds of active OAM 185 packets, echo request is among them, in this document that means echo 186 request is required to traverse a path of IOAM data packet. This 187 requirement can be achieved by, e.g., applying same explicit path or 188 ECMP processing to both echo request and IOAM data packet. Specific 189 to apply same ECMP processing to both echo request and IOAM data 190 packet, one possible way is to populate the same value(s) of ECMP 191 affecting field(s) in the echo request. 193 2. Conventions 195 2.1. Requirements Language 197 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 198 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 199 "OPTIONAL" in this document are to be interpreted as described in BCP 200 14 [RFC2119] [RFC8174] when, and only when, they appear in all 201 capitals, as shown here. 203 2.2. Abbreviations 205 BIER: Bit Index Explicit Replication 207 BGP: Border Gateway Protocol 209 DEX: Direct Export 211 ECMP: Equal-Cost Multipath 213 E2E: Edge to Edge 215 ICMP: Internet Control Message Protocol 217 IGP: Interior Gateway Protocol 219 IOAM: In situ Operations, Administration, and Maintenance 221 LSP: Label Switched Path 223 MPLS: Multi-Protocol Label Switching 225 MTU: Maximum Transmission Unit 227 NTP: Network Time Protocol 229 OAM: Operations, Administration, and Maintenance 231 PCEP: Path Computation Element (PCE) Communication Protocol 233 POSIX: Portable Operating System Interface 234 POT: Proof of Transit 236 PTP: Precision Time Protocol 238 SR-MPLS: Segment Routing with MPLS data plane 240 SRv6: Segment Routing with IPv6 data plane 242 SFC: Service Function Chain 244 TTL: Time to Live, this is also the Hop Limit field in the IPv6 245 header 247 3. IOAM Capabilities Formats 249 3.1. IOAM Capabilities Query Container 251 For echo request, IOAM Capabilities Query uses a container which has 252 the following format: 254 0 1 2 3 255 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 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 . . 258 . IOAM Capabilities Query Container Header . 259 . . 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 . . 262 . List of IOAM Namespace-IDs . 263 . . 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 Figure 1: IOAM Capabilities Query Container of Echo Request 268 When this container is present in the echo request sent by an IOAM 269 encapsulating node, that means the IOAM encapsulating node requests 270 the receiving node to reply with its enabled IOAM capabilities. If 271 there is no IOAM capability to be reported by the receiving node, 272 then this container MUST be ignored by the receiving node, which 273 means the receiving node MUST send an echo reply without IOAM 274 capabilities or no echo reply, in the light of whether the echo 275 request includes other containers than the IOAM Capabilities Query 276 Container. A list of IOAM Namespace-IDs (one or more Namespace-IDs) 277 MUST be included in this container in the echo request, and if 278 present, the Default-Namespace-ID 0x0000 MUST be placed at the 279 beginning of the list of IOAM Namespace-IDs. The IOAM encapsulating 280 node requests only the enabled IOAM capabilities that match one of 281 the Namespace-IDs. Inclusion of the Default-Namespace-ID 0x0000 282 elicits replies only for capabilities that are configured with the 283 Default-Namespace-ID 0x0000.The Namespace-ID has the same definition 284 as what's specified in Section 4.3 of [RFC9197]. 286 The IOAM Capabilities Query Container has a container header that is 287 used to identify the type and optionally length of the container 288 payload, and the container payload (List of IOAM Namespace-IDs) is 289 zero-padded to align to a 4-octet boundary. Since the Default- 290 Namespace-ID of 0x0000 is mandated to appear first in the list, any 291 other occurrences of 0x0000 MUST be disregarded. 293 The length, structure, and definition of the IOAM Capabilities Query 294 Container Header depends on the specific deployment environment. 296 3.2. IOAM Capabilities Response Container 298 For echo reply, IOAM Capabilities Response uses a container which has 299 the following format: 301 0 1 2 3 302 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 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 . . 305 . IOAM Capabilities Response Container Header . 306 . . 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 . . 309 . List of IOAM Capabilities Objects . 310 . . 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 Figure 2: IOAM Capabilities Response Container of Echo Reply 315 When this container is present in the echo reply sent by an IOAM 316 transit node or IOAM decapsulating node, that means the IOAM function 317 is enabled at this node, and this container contains the enabled IOAM 318 capabilities of the sender. A list of IOAM capabilities objects (one 319 or more objects) which contains the enabled IOAM capabilities MUST be 320 included in this container of echo reply except the sender encounters 321 an error (e.g., no matched Namespace-ID). 323 The IOAM Capabilities Response Container has a container header that 324 is used to identify the type and optionally length of the container 325 payload. The container header MUST be defined such that it falls on 326 a four-octet boundary. 328 The length, structure, and definition of the IOAM Capabilities 329 Response Container Header depends on the specific deployment 330 environment. 332 Based on the IOAM data fields defined in [RFC9197] and [RFC9326], six 333 types of objects are defined in this document. The same type of 334 object MAY be present in the IOAM Capabilities Response Container 335 more than once, only if with a different Namespace-ID. 337 Similar to the container, each object has an object header that is 338 used to identify the type and length of the object payload. The 339 object payload MUST be defined such that it falls on a four-octet 340 boundary. 342 The length, structure, and definition of Object Header depends on the 343 specific deployment environment. 345 3.2.1. IOAM Pre-allocated Tracing Capabilities Object 347 0 1 2 3 348 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 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 . . 351 . IOAM Pre-allocated Tracing Capabilities Object Header . 352 . . 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 | IOAM-Trace-Type | Reserved |W| 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 | Namespace-ID | Ingress_MTU | 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 | Ingress_if_id (short or wide format) ...... | 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 Figure 3: IOAM Pre-allocated Tracing Capabilities Object 363 When this Object is present in the IOAM Capabilities Response 364 Container, that means the sending node is an IOAM transit node and 365 the IOAM pre-allocated tracing function is enabled at this IOAM 366 transit node. 368 IOAM-Trace-Type field has the same definition as what's specified in 369 Section 4.4 of [RFC9197]. 371 Reserved field is reserved for future use and MUST be set to zero, 372 and MUST be ignored when non-zero. 374 W flag indicates whether Ingress_if_id is in short or wide format. 375 The W-bit is set if the Ingress_if_id is in wide format. The W-bit 376 is clear if the Ingress_if_id is in short format. 378 Namespace-ID field has the same definition as what's specified in 379 Section 4.3 of [RFC9197], it MUST be one of the Namespace-IDs listed 380 in the IOAM Capabilities Query Object of the echo request. 382 Ingress_MTU field has 16 bits and specifies the MTU (in octets) of 383 the ingress interface from which the sending node received echo 384 request. 386 Ingress_if_id field has 16 bits (in short format) or 32 bits (in wide 387 format) and specifies the identifier of the ingress interface from 388 which the sending node received echo request. If the W-bit is 389 cleared that indicates Ingress_if_id field has 16 bits, then the 16 390 bits following the Ingress_if_id field are reserved for future use 391 and MUST be set to zero, and MUST be ignored when non-zero. 393 3.2.2. IOAM Incremental Tracing Capabilities Object 395 0 1 2 3 396 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 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 . . 399 . IOAM Incremental Tracing Capabilities Object Header . 400 . . 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 | IOAM-Trace-Type | Reserved |W| 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 | Namespace-ID | Ingress_MTU | 405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 | Ingress_if_id (short or wide format) ...... | 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 Figure 4: IOAM Incremental Tracing Capabilities Object 411 When this Object is present in the IOAM Capabilities Response 412 Container, that means the sending node is an IOAM transit node and 413 the IOAM incremental tracing function is enabled at this IOAM transit 414 node. 416 IOAM-Trace-Type field has the same definition as what's specified in 417 Section 4.4 of [RFC9197]. 419 Reserved field is reserved for future use and MUST be set to zero, 420 and MUST be ignored when non-zero. 422 W flag indicates whether Ingress_if_id is in short or wide format. 423 The W-bit is set if the Ingress_if_id is in wide format. The W-bit 424 is clear if the Ingress_if_id is in short format. 426 Namespace-ID field has the same definition as what's specified in 427 Section 4.3 of [RFC9197], it MUST be one of the Namespace-IDs listed 428 in the IOAM Capabilities Query Object of the echo request. 430 Ingress_MTU field has 16 bits and specifies the MTU (in octets) of 431 the ingress interface from which the sending node received echo 432 request. 434 Ingress_if_id field has 16 bits (in short format) or 32 bits (in wide 435 format) and specifies the identifier of the ingress interface from 436 which the sending node received echo request. If the W-bit is 437 cleared that indicates Ingress_if_id field has 16 bits, then the 16 438 bits following the Ingress_if_id field are reserved for future use 439 and MUST be set to zero, and MUST be ignored when non-zero. 441 3.2.3. IOAM Proof-of-Transit Capabilities Object 443 0 1 2 3 444 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 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 . . 447 . IOAM Proof-of-Transit Capabilities Object Header . 448 . . 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 | Namespace-ID | IOAM-POT-Type |SoP| Reserved | 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 Figure 5: IOAM Proof-of-Transit Capabilities Object 455 When this Object is present in the IOAM Capabilities Response 456 Container, that means the sending node is an IOAM transit node and 457 the IOAM Proof of Transit function is enabled at this IOAM transit 458 node. 460 Namespace-ID field has the same definition as what's specified in 461 Section 4.3 of [RFC9197], it MUST be one of the Namespace-IDs listed 462 in the IOAM Capabilities Query Object of the echo request. 464 IOAM-POT-Type field has the same definition as what's specified in 465 Section 4.5 of [RFC9197]. 467 SoP (Size of POT) field has two bits, which means the size of "PktID" 468 and "Cumulative" data that are specified in Section 4.5 of [RFC9197]. 469 This document defines SoP as follows: 471 0b00 means 64-bit "PktID" and 64-bit "Cumulative" data. 473 0b01~0b11: Reserved for future standardization 475 Reserved field is reserved for future use and MUST be set to zero, 476 and MUST be ignored when non-zero. 478 3.2.4. IOAM Edge-to-Edge Capabilities Object 480 0 1 2 3 481 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 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 . . 484 . IOAM Edge-to-Edge Capabilities Object Header . 485 . . 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 | Namespace-ID | IOAM-E2E-Type | 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 489 |TSF| Reserved | Reserved | 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 Figure 6: IOAM Edge-to-Edge Capabilities Object 494 When this Object is present in the IOAM Capabilities Response 495 Container, that means the sending node is an IOAM decapsulating node 496 and IOAM edge-to-edge function is enabled at this IOAM decapsulating 497 node. 499 Namespace-ID field has the same definition as what's specified in 500 Section 4.3 of [RFC9197], it MUST be one of the Namespace-IDs listed 501 in the IOAM Capabilities Query Object of the echo request. 503 IOAM-E2E-Type field has the same definition as what's specified in 504 Section 4.6 of [RFC9197]. 506 TSF field specifies the timestamp format used by the sending node. 507 Aligned with three possible timestamp formats specified in Section 5 508 of [RFC9197], this document defines TSF as follows: 510 0b00: PTP truncated timestamp format 512 0b01: NTP 64-bit timestamp format 514 0b10: POSIX-based timestamp format 516 0b11: Reserved for future standardization 518 Reserved field is reserved for future use and MUST be set to zero, 519 and MUST be ignored when non-zero. 521 3.2.5. IOAM DEX Capabilities Object 523 0 1 2 3 524 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 525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 526 . . 527 . IOAM DEX Capabilities Object Header . 528 . . 529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 530 | IOAM-Trace-Type | Reserved | 531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 532 | Namespace-ID | Reserved | 533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 535 Figure 7: IOAM DEX Capabilities Object 537 When this Object is present in the IOAM Capabilities Response 538 Container, that means the sending node is an IOAM transit node and 539 the IOAM direct exporting function is enabled at this IOAM transit 540 node. 542 IOAM-Trace-Type field has the same definition as what's specified in 543 Section 3.2 of [RFC9326]. 545 Namespace-ID field has the same definition as what's specified in 546 Section 4.3 of [RFC9197], it MUST be one of the Namespace-IDs listed 547 in the IOAM Capabilities Query Object of the echo request. 549 Reserved field is reserved for future use and MUST be set to zero, 550 and MUST be ignored when non-zero. 552 3.2.6. IOAM End-of-Domain Object 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 . . 558 . IOAM End-of-Domain Object Header . 559 . . 560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 561 | Namespace-ID | Must Be Zero | 562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 564 Figure 8: IOAM End-of-Domain Object 566 When this Object is present in the IOAM Capabilities Response 567 Container, that means the sending node is an IOAM decapsulating node. 568 Unless the IOAM Edge-to-Edge Capabilities Object is present, which 569 also indicates that the sending node is an IOAM decapsulating node, 570 the End-of-Domain Object MUST be present in the IOAM Capabilities 571 Response Container sent by an IOAM decapsulating node. When the IOAM 572 edge-to-edge function is enabled at the IOAM decapsulating node, it's 573 RECOMMENDED to include only the IOAM Edge-to-Edge Capabilities Object 574 but not the IOAM End-of-Domain Object. 576 Namespace-ID field has the same definition as what's specified in 577 Section 4.3 of [RFC9197], it MUST be one of the Namespace-IDs listed 578 in the IOAM Capabilities Query Container. 580 4. Operational Guide 582 Once the IOAM encapsulating node is triggered to discover the enabled 583 IOAM capabilities of each IOAM transit and IOAM decapsulating node, 584 the IOAM encapsulating node will send echo requests that include the 585 IOAM Capabilities Query Container. First, with TTL equal to 1 to 586 reach the closest node, which may be an IOAM transit node or not. 587 Then with TTL equal to 2 to reach the second-nearest node, which also 588 may be an IOAM transit node or not. And further, increasing by 1 the 589 TTL every time the IOAM encapsulating node sends a new echo request, 590 until the IOAM encapsulating node receives an echo reply sent by the 591 IOAM decapsulating node, which contains the IOAM Capabilities 592 Response Container including the IOAM Edge-to-Edge Capabilities 593 Object or the IOAM End-of-Domain Object. As a result, the echo 594 requests sent by the IOAM encapsulating node will reach all nodes one 595 by one along the transport path of IOAM data packet. Alternatively, 596 if the IOAM encapsulating node knows precisely all the IOAM transit 597 and IOAM decapsulating nodes beforehand, once the IOAM encapsulating 598 node is triggered to discover the enabled IOAM capabilities, it can 599 send an echo request to each IOAM transit and IOAM decapsulating node 600 directly, without TTL expiration. 602 The IOAM encapsulating node may be triggered by the device 603 administrator, the network management system, the network controller, 604 or data traffic. The specific triggering mechanisms are outside the 605 scope of this document. 607 Each IOAM transit and IOAM decapsulating node that receives an echo 608 request containing the IOAM Capabilities Query Container will send an 609 echo reply to the IOAM encapsulating node. For the echo reply, there 610 is an IOAM Capabilities Response Container containing one or more 611 Objects. The IOAM Capabilities Query Container of the echo request 612 would be ignored by the receiving node unaware of IOAM. 614 Note that the mechanism defined in this document applies to all kinds 615 of IOAM option types, whether the four types of IOAM option defined 616 in [RFC9197] or the DEX type of IOAM option defined in [RFC9326], 617 specifically, when applied to the IOAM DEX option, it allows the IOAM 618 encapsulating node to discover which nodes along the transport path 619 support IOAM direct exporting and which trace data types are 620 supported to be directly exported at these nodes. 622 5. IANA Considerations 624 This document requests the following IANA Actions. 626 IANA is requested to create a registry group named "In-Situ OAM 627 (IOAM) Capabilities Parameters". 629 This group will include the following registries: 631 * IOAM SoP Capability 633 * IOAM TSF Capability 635 New registries in this group can be created via RFC Required process 636 as per [RFC8126]. 638 The subsequent subsections detail the registries herein contained. 640 Considering the Containers/Objects defined in this document would be 641 carried in different types of Echo Request/Reply messages, such as 642 ICMPv6 or LSP Ping, it is intended that the registries for Container/ 643 Object Type would be requested in subsequent documents. 645 5.1. IOAM SoP Capability Registry 647 This registry defines 4 code points for the IOAM SoP Capability field 648 for identifying the size of "PktID" and "Cumulative" data as 649 explained in Section 4.5 of [RFC9197]. 651 A new entry in this registry requires the following fields: 653 * SoP: size of POT; a two-bit binary field as defined in 654 Section 3.2.3 656 * Description: a terse description of the meaning of this SoP value 658 The registry initially contains the following value: 660 SoP Description 661 ---- ----------- 662 0b00 64-bit "PktID" and 64-bit "Cumulative" data 664 0b01 - 0b11 are available for assignment via IETF Review process as 665 per [RFC8126]. 667 5.2. IOAM TSF Capability Registry 669 This registry defines 4 code points for the IOAM TSF Capability field 670 for identifying the timestamp format as explained in Section 5 of 671 [RFC9197]. 673 A new entry in this registry requires the following fields: 675 * TSF: timestamp format; a two-bit binary field as defined in 676 Section 3.2.4 678 * Description: a terse description of the meaning of this TSF value 680 The registry initially contains the following values: 682 TSF Description 683 ---- ----------- 684 0b00 PTP Truncated Timestamp Format 685 0b01 NTP 64-bit Timestamp Format 686 0b10 POSIX-based Timestamp Format 688 0b11 is available for assignment via IETF Review process as per 689 [RFC8126]. 691 6. Security Considerations 693 Overall, the security needs for IOAM capabilities query mechanisms 694 used in different environments are similar. 696 To avoid potential Denial-of-Service (DoS) attacks, it is RECOMMENDED 697 that implementations apply rate-limiting to incoming echo requests 698 and replies. 700 To protect against unauthorized sources using echo request messages 701 to obtain IOAM Capabilities information, implementations MUST provide 702 a means of checking the source addresses of echo request messages 703 against an access list before accepting the message. 705 A deployment MUST ensure that border filtering drops inbound echo 706 requests with an IOAM Capabilities Container Header from outside of 707 the domain, and drops outbound echo request/replies with IOAM 708 Capabilities Headers leaving the domain. 710 A deployment MUST support the configuration option to enable/disable 711 the IOAM Capabilities Discovery feature defined in this document. By 712 default, the IOAM Capabilities Discovery feature MUST be disabled. 714 The integrity protection on IOAM Capabilities information carried in 715 echo reply messages can be achieved by the underlying transport. For 716 example, if the environment is an IPv6 network, the IP Authentication 717 Header [RFC4302] or IP Encapsulating Security Payload Header 718 [RFC4303] can be used. 720 The collected IOAM Capabilities information by queries may be 721 considered confidential. An implementation can use secure underlying 722 transport of echo request/reply to provide privacy protection. For 723 example, if the environment is an IPv6 network, confidentiality can 724 be achieved by using the IP Encapsulating Security Payload Header 725 [RFC4303]. 727 An implementation can also directly secure the data carried in echo 728 requests and replies if needed, the specific mechanism on how to 729 secure the data is beyond the scope of this document. 731 An implementation can also check whether the fields in received echo 732 requests and replies strictly conform to the specifications, e.g., 733 whether the list of IOAM Namespace-IDs includes duplicate entries, 734 whether the received Namespace-ID is an operator-assigned or IANA- 735 assigned one, once a check fails, an exception event indicating the 736 checked field should be reported to the management. 738 Except for what's described above, the security issues discussed in 739 [RFC9197] provide a good guidance on implementation of this 740 specification. 742 7. Acknowledgements 744 The authors would like to acknowledge Tianran Zhou, Dhruv Dhody, 745 Frank Brockners, Cheng Li, Gyan Mishra, Marcus Ihlar, Martin Duke, 746 Chris Lonvick, Eric Vyncke, Alvaro Retana, Paul Wouters, Roman 747 Danyliw, Lars Eggert, Warren Kumari, John Scudder, Robert Wilton, 748 Erik Kline, Zaheduzzaman Sarker and Murray Kucherawy for their 749 careful review and helpful comments. 751 The authors appreciate the f2f discussion with Frank Brockners on 752 this document. 754 The authors would like to acknowledge Tommy Pauly and Ian Swett for 755 their good suggestion and guidance. 757 8. References 759 8.1. Normative References 761 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 762 Requirement Levels", BCP 14, RFC 2119, 763 DOI 10.17487/RFC2119, March 1997, 764 . 766 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 767 Writing an IANA Considerations Section in RFCs", BCP 26, 768 RFC 8126, DOI 10.17487/RFC8126, June 2017, 769 . 771 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 772 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 773 May 2017, . 775 [RFC9197] Brockners, F., Ed., Bhandari, S., Ed., and T. Mizrahi, 776 Ed., "Data Fields for In Situ Operations, Administration, 777 and Maintenance (IOAM)", RFC 9197, DOI 10.17487/RFC9197, 778 May 2022, . 780 [RFC9326] Song, H., Gafni, B., Brockners, F., Bhandari, S., and T. 781 Mizrahi, "In Situ Operations, Administration, and 782 Maintenance (IOAM) Direct Exporting", RFC 9326, 783 DOI 10.17487/RFC9326, November 2022, 784 . 786 8.2. Informative References 788 [I-D.ietf-bier-ping] 789 Kumar, N., Pignataro, C., Akiya, N., Zheng, L., Chen, M., 790 and G. Mirsky, "BIER Ping and Trace", Work in Progress, 791 Internet-Draft, draft-ietf-bier-ping-07, 11 May 2020, 792 . 795 [I-D.ietf-sfc-multi-layer-oam] 796 Mirsky, G., Meng, W., Ao, T., Khasnabish, B., Leung, K., 797 and G. Mishra, "Active OAM for Service Function Chaining 798 (SFC)", Work in Progress, Internet-Draft, draft-ietf-sfc- 799 multi-layer-oam-22, 25 July 2022, 800 . 803 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 804 DOI 10.17487/RFC4302, December 2005, 805 . 807 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 808 RFC 4303, DOI 10.17487/RFC4303, December 2005, 809 . 811 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 812 Control Message Protocol (ICMPv6) for the Internet 813 Protocol Version 6 (IPv6) Specification", STD 89, 814 RFC 4443, DOI 10.17487/RFC4443, March 2006, 815 . 817 [RFC4620] Crawford, M. and B. Haberman, Ed., "IPv6 Node Information 818 Queries", RFC 4620, DOI 10.17487/RFC4620, August 2006, 819 . 821 [RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, 822 "Extended ICMP to Support Multi-Part Messages", RFC 4884, 823 DOI 10.17487/RFC4884, April 2007, 824 . 826 [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., 827 Aldrin, S., Chen, M., and RFC Publisher, "Detecting 828 Multiprotocol Label Switched (MPLS) Data-Plane Failures", 829 RFC 8029, DOI 10.17487/RFC8029, March 2017, 830 . 832 [RFC8335] Bonica, R., Thomas, R., Linkova, J., Lenart, C., and M. 833 Boucadair, "PROBE: A Utility for Probing Interfaces", 834 RFC 8335, DOI 10.17487/RFC8335, February 2018, 835 . 837 [RFC8799] Carpenter, B. and B. Liu, "Limited Domains and Internet 838 Protocols", RFC 8799, DOI 10.17487/RFC8799, July 2020, 839 . 841 Authors' Addresses 843 Xiao Min 844 ZTE Corp. 845 Nanjing 846 China 847 Phone: +86 25 88013062 848 Email: xiao.min2@zte.com.cn 849 Greg Mirsky 850 Ericsson 851 United States of America 852 Email: gregimirsky@gmail.com 854 Lei Bo 855 China Telecom 856 Beijing 857 China 858 Phone: +86 10 50902903 859 Email: leibo@chinatelecom.cn