idnits 2.17.1 draft-xiao-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 (June 7, 2021) is 1052 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 (-17) exists of draft-ietf-ippm-ioam-data-12 == Outdated reference: A later version (-11) exists of draft-ietf-ippm-ioam-direct-export-03 -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE1588v2' == 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-10 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPPM Working Group X. Min 3 Internet-Draft G. Mirsky 4 Intended status: Standards Track ZTE Corp. 5 Expires: December 9, 2021 L. Bo 6 China Telecom 7 June 7, 2021 9 Echo Request/Reply for Enabled In-situ OAM Capabilities 10 draft-xiao-ippm-ioam-conf-state-10 12 Abstract 14 This document describes an extension to the echo request/reply 15 mechanisms used in IPv6, MPLS, SFC and BIER environments, which can 16 be used within an IOAM domain, allowing the IOAM encapsulating node 17 to acquire the enabled IOAM capabilities of each IOAM transit node 18 and/or IOAM decapsulating node. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on December 9, 2021. 37 Copyright Notice 39 Copyright (c) 2021 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 57 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4 58 3. IOAM Capabilities Formats . . . . . . . . . . . . . . . . . . 5 59 3.1. IOAM Capabilities Query TLV in the Echo Request . . . . . 5 60 3.2. IOAM Capabilities Response TLV in the Echo Reply . . . . 6 61 3.2.1. IOAM Pre-allocated Tracing Capabilities sub-TLV . . . 7 62 3.2.2. IOAM Incremental Tracing Capabilities sub-TLV . . . . 8 63 3.2.3. IOAM Proof of Transit Capabilities sub-TLV . . . . . 9 64 3.2.4. IOAM Edge-to-Edge Capabilities sub-TLV . . . . . . . 10 65 3.2.5. IOAM DEX Capabilities sub-TLV . . . . . . . . . . . . 11 66 3.2.6. IOAM End-of-Domain sub-TLV . . . . . . . . . . . . . 12 67 4. Operational Guide . . . . . . . . . . . . . . . . . . . . . . 13 68 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 69 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 70 6.1. IOAM SoR Capability Registry . . . . . . . . . . . . . . 14 71 6.2. IOAM TSF+TSL Capability Registry . . . . . . . . . . . . 15 72 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 73 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 74 8.1. Normative References . . . . . . . . . . . . . . . . . . 16 75 8.2. Informative References . . . . . . . . . . . . . . . . . 16 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 78 1. Introduction 80 The Data Fields for In-situ OAM (IOAM) [I-D.ietf-ippm-ioam-data] 81 defines data fields that record OAM information within the packet 82 while the packet traverses a particular network domain, which is 83 called an IOAM domain. IOAM can be used to complement OAM mechanisms 84 based on, e.g., ICMP or other types of probe packets, and IOAM 85 mechanisms can be leveraged where mechanisms using, e.g., ICMP do not 86 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 data container to the 91 packet to capture IOAM data is called the "IOAM encapsulating node". 92 In contrast, the device which removes the IOAM data container is 93 referred to as the "IOAM decapsulating node". Nodes within the 94 domain that are aware of IOAM data and read and/or write or process 95 the IOAM data are called "IOAM transit nodes". Both the IOAM 96 encapsulating node and the decapsulating node are referred to as 97 domain edge devices, which can be hosts or network devices. 99 In order to add the correct IOAM data container to the packet, the 100 IOAM encapsulating node needs to know the enabled IOAM capabilities 101 at the IOAM transit nodes and/or the IOAM decapsulating node as a 102 whole, e.g., how many IOAM transit nodes will add tracing data, and 103 what kinds of data fields will be added. A centralized controller 104 could be used in some IOAM deployments. The IOAM encapsulating node 105 can acquire these IOAM capabilities info from the centralized 106 controller, through, e.g., NETCONF/YANG, PCEP, or BGP. In the IOAM 107 deployment scenario where there is no centralized controller, 108 NETCONF/YANG or IGP may be used for the IOAM encapsulating node to 109 acquire these IOAM capabilities info, however, whether NETCONF/YANG 110 or IGP has some limitations as follows. 112 o When NETCONF/YANG is used in this scenario, each IOAM 113 encapsulating node (including the host when it takes the role of 114 an IOAM encapsulating node) needs to implement a NETCONF Client, 115 each IOAM transit node and IOAM decapsulating node (including the 116 host when it takes the role of an IOAM decapsulating node) needs 117 to implement a NETCONF Server, the complexity can be an issue. 118 Furthermore, each IOAM encapsulating node needs to establish 119 NETCONF Connection with each IOAM transit node and IOAM 120 decapsulating node, the scalability can be an issue. 122 o When IGP is used in this scenario, the IGP domain and an IOAM 123 domain don't always have the same coverage. For example, when the 124 IOAM encapsulating node or the IOAM decapsulating node is a host, 125 the availability can be an issue. Furthermore, it might be too 126 challenging to reflect IOAM capabilities at the IOAM transit node 127 and/or the IOAM decapsulating node if these are controlled by a 128 local policy depending on the identity of the IOAM encapsulating 129 node. 131 This document describes an extension to the echo request/reply 132 mechanisms used in IPv6, MPLS, SFC and BIER environments, which can 133 be used within an IOAM domain where no Centralized Controller exists, 134 allowing the IOAM encapsulating node to acquire the enabled IOAM 135 capabilities of each IOAM transit node and/or IOAM decapsulating 136 node. 138 The following documents contain references to the echo request/reply 139 mechanisms used in IPv6, MPLS, SFC and BIER environments: 141 o [RFC4443] ("Internet Control Message Protocol (ICMPv6) for the 142 Internet Protocol Version 6 (IPv6) Specification"), [RFC4884] 143 ("Extended ICMP to Support Multi-Part Messages") and [RFC8335] 144 ("PROBE: A Utility for Probing Interfaces") 146 o [RFC8029] ("Detecting Multiprotocol Label Switched (MPLS) Data- 147 Plane Failures") 149 o [I-D.ietf-sfc-multi-layer-oam] ("Active OAM for Service Function 150 Chains in Networks") 152 o [I-D.ietf-bier-ping] ("BIER Ping and Trace") 154 This feature described in this document is assumedly applied to 155 explicit path (strict or loose), because the precondition for this 156 feature to work is that the echo request reaches each IOAM transit 157 node as live traffic traverses. 159 2. Conventions 161 2.1. Requirements Language 163 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 164 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 165 "OPTIONAL" in this document are to be interpreted as described in BCP 166 14 [RFC2119] [RFC8174] when, and only when, they appear in all 167 capitals, as shown here. 169 2.2. Abbreviations 171 BIER: Bit Index Explicit Replication 173 BGP: Border Gateway Protocol 175 E2E: Edge to Edge 177 ICMP: Internet Control Message Protocol 179 IGP: Interior Gateway Protocol 181 IOAM: In-situ Operations, Administration, and Maintenance 183 LSP: Label Switched Path 185 MPLS: Multi-Protocol Label Switching 187 MBZ: Must Be Zero 189 MTU: Maximum Transmission Unit 190 NTP: Network Time Protocol 192 OAM: Operations, Administration, and Maintenance 194 PCEP: Path Computation Element (PCE) Communication Protocol 196 POSIX: Portable Operating System Interface 198 POT: Proof of Transit 200 PTP: Precision Time Protocol 202 SFC: Service Function Chain 204 TTL: Time to Live 206 3. IOAM Capabilities Formats 208 3.1. IOAM Capabilities Query TLV in the Echo Request 210 In echo request IOAM Capabilities Query uses TLV (Type-Length-Value 211 tuple) which have the following format: 213 0 1 2 3 214 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 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 | Type = IOAM Capabilities Query| Length | 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 . . 219 . List of Namespace-IDs . 220 . . 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 Figure 1: IOAM Capabilities Query TLV in the Echo Request 225 When this TLV is present in the echo request sent by an IOAM 226 encapsulating node, it means that the IOAM encapsulating node 227 requests the receiving node to reply with its enabled IOAM 228 capabilities. If there is no IOAM capability to be reported by the 229 receiving node, then this TLV SHOULD be ignored by the receiving 230 node, which means the receiving node SHOULD send echo reply without 231 IOAM capabilities or no echo reply, in the light of whether the echo 232 request includes other TLV than IOAM Capabilities Query TLV. List of 233 Namespace-IDs MAY be included in this TLV of the echo request. In 234 that case, the IOAM encapsulating node requests only the IOAM 235 capabilities that match one of the Namespace-IDs. The Namespace-ID 236 has the same definition as what's specified in 237 [I-D.ietf-ippm-ioam-data]. 239 Type is set to the value that identifies it as an IOAM Capabilities 240 Query TLV. 242 Length is the length of the TLV's Value field in octets, including a 243 List of Namespace-IDs. 245 Value field of this TLV is zero-padded to align to a 4-octet 246 boundary. 248 3.2. IOAM Capabilities Response TLV in the Echo Reply 250 In echo reply IOAM Capabilities Response uses TLV which have the 251 following format: 253 0 1 2 3 254 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 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 | Type = IOAM Capabilities Resp | Length | 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 . . 259 . List of Sub-TLVs . 260 . . 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 Figure 2: IOAM Capabilities Response TLV in the Echo Reply 265 When this TLV is present in the echo reply sent by an IOAM transit 266 node and/or an IOAM decapsulating node, it means that the IOAM 267 function is enabled at this node, and this TLV contains the enabled 268 IOAM capabilities of the sender. A list of Sub-TLVs which contains 269 the IOAM capabilities SHOULD be included in this TLV of the echo 270 reply. Note that the IOAM encapsulating node or the IOAM 271 decapsulating node can also be an IOAM transit node. 273 Type is set to the value that identifies it as an IOAM Capabilities 274 Response TLV. 276 Length is the length of the TLV's Value field in octets, including a 277 List of Sub-TLVs. 279 Value field of this TLV or any Sub-TLV is zero-padded to align to a 280 4-octet boundary. Based on the data fields for IOAM, specified in 281 [I-D.ietf-ippm-ioam-data] and [I-D.ietf-ippm-ioam-direct-export], six 282 kinds of Sub-TLVs are defined in this document. The same type of the 283 sub-TLV MAY be in the IOAM Capabilities Response TLV more than once 284 only if with a different Namespace-ID. 286 3.2.1. IOAM Pre-allocated Tracing Capabilities sub-TLV 288 0 1 2 3 289 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 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 |Sub-type = Pre-allocated trace | Length | 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | IOAM-Trace-Type | Reserved | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | Namespace-ID | Egress_MTU | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | Egress_if_id (short or wide format) ...... | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 Figure 3: IOAM Pre-allocated Tracing Capabilities Sub-TLV 302 When this sub-TLV is present in the IOAM Capabilities Response TLV, 303 it means that the sending node is an IOAM transit node and IOAM pre- 304 allocated tracing function is enabled at this IOAM transit node. 306 Sub-type is set to the value that identifies it as an IOAM Pre- 307 allocated Tracing Capabilities sub-TLV. 309 Length is the length of the sub-TLV's Value field in octets. If 310 Egress_if_id is in the short format, which is 16 bits long, it MUST 311 be set to 10. If Egress_if_id is in the wide format, which is 32 312 bits long, it MUST be set to 12. 314 IOAM-Trace-Type field has the same definition as what's specified in 315 section 5.4 of [I-D.ietf-ippm-ioam-data]. 317 Reserved field is reserved for future use and MUST be set to zero. 319 Namespace-ID field has the same definition as what's specified in 320 section 5.3 of [I-D.ietf-ippm-ioam-data], it should be one of the 321 Namespace-IDs listed in the IOAM Capabilities Query TLV of echo 322 request. 324 Egress_MTU field has 16 bits and specifies the MTU of the egress 325 direction out of which the sending node would forward the received 326 echo request, it should be the MTU of the egress interface or the MTU 327 between the sending node and the downstream IOAM transit node. 329 Egress_if_id field has 16 bits (in short format) or 32 bits (in wide 330 format) and specifies the identifier of the egress interface out of 331 which the sending node would forward the received echo request. 333 3.2.2. IOAM Incremental Tracing Capabilities sub-TLV 335 0 1 2 3 336 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 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 | Sub-type = Incremental trace | Length | 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 | IOAM-Trace-Type | Reserved | 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 | Namespace-ID | Egress_MTU | 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 | Egress_if_id (short or wide format) ...... | 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 Figure 4: IOAM Incremental Tracing Capabilities Sub-TLV 349 When this sub-TLV is present in the IOAM Capabilities Response TLV, 350 it means that the sending node is an IOAM transit node and IOAM 351 incremental tracing function is enabled at this IOAM transit node. 353 Sub-type is set to the value that identifies it as an IOAM 354 Incremental Tracing Capabilities sub-TLV. 356 Length is the length of the sub-TLV's Value field in octets. If 357 Egress_if_id is in the short format, which is 16 bits long, it MUST 358 be set to 10. If Egress_if_id is in the wide format, which is 32 359 bits long, it MUST be set to 12. 361 IOAM-Trace-Type field has the same definition as what's specified in 362 section 5.4 of [I-D.ietf-ippm-ioam-data]. 364 Reserved field is reserved for future use and MUST be set to zero. 366 Namespace-ID field has the same definition as what's specified in 367 section 5.3 of [I-D.ietf-ippm-ioam-data], it should be one of the 368 Namespace-IDs listed in the IOAM Capabilities Query TLV of echo 369 request. 371 Egress_MTU field has 16 bits and specifies the MTU of the egress 372 direction out of which the sending node would forward the received 373 echo request, it should be the MTU of the egress interface or the MTU 374 between the sending node and the downstream IOAM transit node. 376 Egress_if_id field has 16 bits (in short format) or 32 bits (in wide 377 format) and specifies the identifier of the egress interface out of 378 which the sending node would forward the received echo request. 380 3.2.3. IOAM Proof of Transit Capabilities sub-TLV 382 0 1 2 3 383 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 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 | Sub-type = POT Capabilities | Length | 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 | Namespace-ID | IOAM-POT-Type |P|SoR|Reserved | 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 Figure 5: IOAM Proof of Transit Capabilities Sub-TLV 392 When this sub-TLV is present in the IOAM Capabilities Response TLV, 393 it means that the sending node is an IOAM transit node and IOAM proof 394 of transit function is enabled at this IOAM transit node. 396 Sub-type is set to the value that identifies it as an IOAM Proof of 397 Transit Capabilities sub-TLV. 399 Length is the length of the sub-TLV's Value field in octets and MUST 400 be set to 4. 402 Namespace-ID field has the same definition as what's specified in 403 section 5.3 of [I-D.ietf-ippm-ioam-data], it should be one of the 404 Namespace-IDs listed in the IOAM Capabilities Query TLV of echo 405 request. 407 IOAM-POT-Type field and P bit have the same definition as what's 408 specified in section 5.5 of [I-D.ietf-ippm-ioam-data]. If the IOAM 409 encapsulating node receives IOAM-POT-Type and/or P bit values from an 410 IOAM transit node that are different from its own, then the IOAM 411 encapsulating node MAY choose to abandon the proof of transit 412 function or to select one kind of IOAM-POT-Type and P bit, it's based 413 on the policy applied to the IOAM encapsulating node. 415 SoR field has two bits, which means the size of "Random" and 416 "Cumulative" data that are specified in section 5.5 of 417 [I-D.ietf-ippm-ioam-data]. This document defines SoR as follow: 419 0b00 means 64-bit "Random" and 64-bit "Cumulative" data. 421 0b01~0b11: Reserved for future standardization 423 Reserved field is reserved for future use and MUST be set to zero. 425 3.2.4. IOAM Edge-to-Edge Capabilities sub-TLV 427 0 1 2 3 428 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 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 | Sub-type = E2E Capabilities | Length | 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 | Namespace-ID | IOAM-E2E-Type | 433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 |TSF|TSL| Reserved | MBZ | 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 Figure 6: IOAM Edge-to-Edge Capabilities Sub-TLV 439 When this sub-TLV is present in the IOAM Capabilities Response TLV, 440 it means that the sending node is an IOAM decapsulating node and IOAM 441 edge-to-edge function is enabled at this IOAM decapsulating node. 442 That is to say, if the IOAM encapsulating node receives this sub-TLV, 443 the IOAM encapsulating node can determine that the node which sends 444 this sub-TLV is an IOAM decapsulating node. 446 Sub-type is set to the value that identifies it as an IOAM Edge-to- 447 Edge Capabilities sub-TLV. 449 Length is the length of the sub-TLV's Value field in octets and MUST 450 be set to 8. 452 Namespace-ID field has the same definition as what's specified in 453 section 5.3 of [I-D.ietf-ippm-ioam-data], it should be one of the 454 Namespace-IDs listed in the IOAM Capabilities Query TLV of echo 455 request. 457 IOAM-E2E-Type field has the same definition as what's specified in 458 section 5.6 of [I-D.ietf-ippm-ioam-data]. 460 TSF field specifies the timestamp format used by the sending node. 461 This document defines TSF as follow: 463 0b00: PTP timestamp format 465 0b01: NTP timestamp format 467 0b10: POSIX timestamp format 469 0b11: Reserved for future standardization 471 TSL field specifies the timestamp length used by the sending node. 472 This document defines TSL as follow. 474 When the TSF field is set to 0b00, which indicates the PTP 475 timestamp format, the values of the TSL field are interpreted as 476 follows: 478 0b00: 64-bit PTPv1 timestamp as defined in IEEE1588-2008 479 [IEEE1588v2] 481 0b01: 80-bit PTPv2 timestamp as defined in IEEE1588-2008 482 [IEEE1588v2] 484 0b10~0b11: Reserved for future standardization 486 When the TSF field is set to 0b01, which indicates the NTP 487 timestamp format, the values of the TSL field are interpreted as 488 follows: 490 0b00: 32-bit NTP timestamp as defined in NTPv4 [RFC5905] 492 0b01: 64-bit NTP timestamp as defined in NTPv4 [RFC5905] 494 0b10: 128-bit NTP timestamp as defined in NTPv4 [RFC5905] 496 0b11: Reserved for future standardization 498 When the TSF field is set to 0b10 or 0b11, the TSL field would be 499 ignored. 501 Reserved field is reserved for future use and MUST be set to zero. 503 3.2.5. IOAM DEX Capabilities sub-TLV 505 0 1 2 3 506 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 507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 | Sub-type = DEX Capabilities | Length | 509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 510 | IOAM-Trace-Type | Reserved | 511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 512 | Namespace-ID | Reserved | 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 515 Figure 7: IOAM DEX Capabilities Sub-TLV 517 When this sub-TLV is present in the IOAM Capabilities Response TLV, 518 it means that the sending node is an IOAM transit node and the IOAM 519 DEX function is enabled at this IOAM transit node. 521 Sub-type is set to the value that identifies it as an IOAM DEX 522 Capabilities sub-TLV. 524 Length is the length of the sub-TLV's Value field in octets and MUST 525 be set to 8. 527 IOAM-Trace-Type field has the same definition as what's specified in 528 section 3.2 of [I-D.ietf-ippm-ioam-direct-export]. 530 Namespace-ID field has the same definition as what's specified in 531 section 3.2 of [I-D.ietf-ippm-ioam-direct-export], it should be one 532 of the Namespace-IDs listed in the IOAM Capabilities Query TLV of 533 echo request. 535 Reserved field is reserved for future use and MUST be set to zero. 537 3.2.6. IOAM End-of-Domain sub-TLV 539 0 1 2 3 540 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 541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 542 | Sub-type = End of Domain | Length | 543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 544 | Namespace-ID | MBZ | 545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 547 Figure 8: IOAM End of Domain Sub-TLV 549 When this sub-TLV is present in the IOAM Capabilities Response TLV, 550 it means that the sending node is an IOAM decapsulating node. That 551 is to say, if the IOAM encapsulating node receives this sub-TLV, the 552 IOAM encapsulating node can determine that the node which sends this 553 sub-TLV is an IOAM decapsulating node. When the IOAM Edge-to-Edge 554 Capabilities sub-TLV is present in the IOAM Capabilities Response TLV 555 sent by the IOAM decapsulating node, the IOAM End-of-Domain sub-TLV 556 doesn't need to be present in the same IOAM Capabilities Response 557 TLV, otherwise the End-of-Domain sub-TLV MUST be present in the IOAM 558 Capabilities Response TLV sent by the IOAM decapsulating node. Both 559 the IOAM Edge-to-Edge Capabilities sub-TLV and the IOAM End-of-Domain 560 sub-TLV can be used to indicate that the sending node is an IOAM 561 decapsulating node. It's recommended to include only the IOAM Edge- 562 to-Edge Capabilities sub-TLV if IOAM edge-to-edge function is enabled 563 at this IOAM decapsulating node. 565 Sub-type is set to the value that identifies it as an IOAM End of 566 Domain sub-TLV. 568 Length is the length of the sub-TLV's Value field in octets and MUST 569 be set to 4. 571 Namespace-ID field has the same definition as what's specified in 572 section 5.3 of [I-D.ietf-ippm-ioam-data], it should be one of the 573 Namespace-IDs listed in the IOAM Capabilities Query TLV of echo 574 request. 576 4. Operational Guide 578 Once the IOAM encapsulating node is triggered to acquire the enabled 579 IOAM capabilities of each IOAM transit node and/or IOAM decapsulating 580 node, the IOAM encapsulating node will send echo requests that 581 include the IOAM Capabilities Query TLV. First with TTL equal to 1 582 to reach the nearest node, which may be an IOAM transit node or not. 583 Then with TTL equal to 2 to reach the second nearest node, which also 584 may be an IOAM transit node or not. And further, increasing by 1 the 585 TTL every time the IOAM encapsulating node sends a new echo request, 586 until the IOAM encapsulating node receives an echo reply sent by the 587 IOAM decapsulating node, which should contain the IOAM Capabilities 588 Response TLV including the IOAM Edge-to-Edge Capabilities sub-TLV or 589 the IOAM End-of-Domain sub-TLV. Alternatively, if the IOAM 590 encapsulating node knows exactly all the IOAM transit nodes and/or 591 IOAM decapsulating node beforehand, once the IOAM encapsulating node 592 is triggered to acquire the enabled IOAM capabilities, it can send an 593 echo request to each IOAM transit node and/or IOAM decapsulating node 594 directly, without TTL expiration. 596 The IOAM encapsulating node may be triggered by the device 597 administrator, the network management system, the network controller, 598 or even the live user traffic. The specific triggering mechanisms 599 are outside the scope of this document. 601 Each IOAM transit node and/or IOAM decapsulating node that receives 602 an echo request containing the IOAM Capabilities Query TLV will send 603 an echo reply to the IOAM encapsulating node, and within the echo 604 reply, there should be an IOAM Capabilities Response TLV containing 605 one or more sub-TLVs. The IOAM Capabilities Query TLV contained in 606 the echo request would be ignored by the receiving node that is 607 unaware of IOAM. 609 5. Security Considerations 611 Queries and responses about the state of an IOAM domain should be 612 processed only from a trusted source. An unauthorized query MUST be 613 discarded by an implementation that supports this specification. 614 Similarly, unsolicited echo response with the IOAM Capabilities TLV 615 MUST be discarded. Authentication of echo request/reply that 616 includes the IOAM Capabilities TLV is one of methods of the integrity 617 protection. Implementations could also provide a means of filtering 618 based on the source address of the received echo request/reply. The 619 integrity protection for IOAM capabilities information collection can 620 also be achieved using mechanisms in the underlay data plane. For 621 example, if the underlay is an IPv6 network, IP Authentication Header 622 [RFC4302] or IP Encapsulating Security Payload Header [RFC4303] can 623 be used to provide integrity protection. 625 Information about the state of the IOAM domain collected in the IAOM 626 Capabilities TLV is confidential. An implementation can use secure 627 transport to provide privacy protection. For example, if the 628 underlay is an IPv6 network, confidentiality can be achieved using 629 the IP Encapsulating Security Payload Header [RFC4303]. 631 6. IANA Considerations 633 This document requests the following IANA Actions. 635 IANA is requested to create a registry group named "In-Situ OAM 636 (IOAM) Capabilities Parameters". 638 This group will include the following registries: 640 o IOAM SoR Capability 642 o IOAM TSF+TSL Capability 644 New registries in this group can be created via RFC Required process 645 as per [RFC8126]. 647 The subsequent sub-sections detail the registries herein contained. 649 Considering the TLVs/sub-TLVs defined in this document would be 650 carried in different kinds of Echo Request/Reply message, such as 651 ICMPv6 or LSP Ping, it is intended that the registries for Type and 652 sub-Type would be requested in subsequent documents. 654 6.1. IOAM SoR Capability Registry 656 This registry defines 4 code points for the IOAM SoR Capability field 657 for identifying the size of "Random" and "Cumulative" data as 658 explained in section 5.5 of [I-D.ietf-ippm-ioam-data]. The following 659 code points are defined in this draft: 661 SoR Description 662 ---- ----------- 663 0b00 64-bit "Random" and 64-bit "Cumulative" data 665 0b01 - 0b11 are available for assignment via RFC Required process as 666 per [RFC8126]. 668 6.2. IOAM TSF+TSL Capability Registry 670 This registry defines 3 code points for the IOAM TSF Capability field 671 for identifying the timestamp format as explained in section 6 of 672 [I-D.ietf-ippm-ioam-data]. 674 o When the code point for the IOAM TSF Capability field equals 0b00 675 which means PTP timestamp format, this registry defines 2 code 676 points for the IOAM TSL Capability field for identifying the 677 timestamp length. 679 o When the code point for the IOAM TSF Capability field equals 0b01 680 which means NTP timestamp format, this registry defines 3 code 681 points for the IOAM TSL Capability field for identifying the 682 timestamp length. 684 The following code points are defined in this draft: 686 TSF TSL Description 687 ---- ---- ----------- 688 0b00 PTP Timestamp Format 689 0b00 64-bit PTPv1 timestamp 690 0b01 80-bit PTPv2 timestamp 691 0b01 NTP Timestamp Format 692 0b00 32-bit NTP timestamp 693 0b01 64-bit NTP timestamp 694 0b10 128-bit NTP timestamp 695 0b10 POSIX Timestamp Format 697 Unassigned code points of TSF+TSL are available for assignment via 698 RFC Required process as per [RFC8126]. 700 7. Acknowledgements 702 The authors would like to acknowledge Tianran Zhou, Dhruv Dhody, 703 Frank Brockners and Cheng Li for their careful review and helpful 704 comments. 706 The authors appreciate the f2f discussion with Frank Brockners on 707 this document. 709 The authors would like to acknowledge Tommy Pauly and Ian Swett for 710 their good suggestion and guidance. 712 8. References 714 8.1. Normative References 716 [I-D.ietf-ippm-ioam-data] 717 Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields 718 for In-situ OAM", draft-ietf-ippm-ioam-data-12 (work in 719 progress), February 2021. 721 [I-D.ietf-ippm-ioam-direct-export] 722 Song, H., Gafni, B., Zhou, T., Li, Z., Brockners, F., 723 Bhandari, S., Sivakolundu, R., and T. Mizrahi, "In-situ 724 OAM Direct Exporting", draft-ietf-ippm-ioam-direct- 725 export-03 (work in progress), February 2021. 727 [IEEE1588v2] 728 IEEE, "IEEE Std 1588-2008 - IEEE Standard for a Precision 729 Clock Synchronization Protocol for Networked Measurement 730 and Control Systems", IEEE Std 1588-2008, 2008, 731 . 734 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 735 Requirement Levels", BCP 14, RFC 2119, 736 DOI 10.17487/RFC2119, March 1997, 737 . 739 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 740 "Network Time Protocol Version 4: Protocol and Algorithms 741 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 742 . 744 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 745 Writing an IANA Considerations Section in RFCs", BCP 26, 746 RFC 8126, DOI 10.17487/RFC8126, June 2017, 747 . 749 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 750 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 751 May 2017, . 753 8.2. Informative References 755 [I-D.ietf-bier-ping] 756 Kumar, N., Pignataro, C., Akiya, N., Zheng, L., Chen, M., 757 and G. Mirsky, "BIER Ping and Trace", draft-ietf-bier- 758 ping-07 (work in progress), May 2020. 760 [I-D.ietf-sfc-multi-layer-oam] 761 Mirsky, G., Meng, W., Khasnabish, B., and C. Wang, "Active 762 OAM for Service Function Chaining", draft-ietf-sfc-multi- 763 layer-oam-10 (work in progress), March 2021. 765 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 766 DOI 10.17487/RFC4302, December 2005, 767 . 769 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 770 RFC 4303, DOI 10.17487/RFC4303, December 2005, 771 . 773 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 774 Control Message Protocol (ICMPv6) for the Internet 775 Protocol Version 6 (IPv6) Specification", STD 89, 776 RFC 4443, DOI 10.17487/RFC4443, March 2006, 777 . 779 [RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, 780 "Extended ICMP to Support Multi-Part Messages", RFC 4884, 781 DOI 10.17487/RFC4884, April 2007, 782 . 784 [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., 785 Aldrin, S., and M. Chen, "Detecting Multiprotocol Label 786 Switched (MPLS) Data-Plane Failures", RFC 8029, 787 DOI 10.17487/RFC8029, March 2017, 788 . 790 [RFC8335] Bonica, R., Thomas, R., Linkova, J., Lenart, C., and M. 791 Boucadair, "PROBE: A Utility for Probing Interfaces", 792 RFC 8335, DOI 10.17487/RFC8335, February 2018, 793 . 795 Authors' Addresses 797 Xiao Min 798 ZTE Corp. 799 Nanjing 800 China 802 Phone: +86 25 88013062 803 Email: xiao.min2@zte.com.cn 804 Greg Mirsky 805 ZTE Corp. 806 USA 808 Email: gregory.mirsky@ztetx.com 810 Lei Bo 811 China Telecom 812 Beijing 813 China 815 Phone: +86 10 50902903 816 Email: leibo@chinatelecom.cn