idnits 2.17.1 draft-xiao-ippm-ioam-conf-state-09.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 (May 13, 2021) is 1080 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 (-28) exists of draft-ietf-sfc-multi-layer-oam-10 Summary: 0 errors (**), 0 flaws (~~), 4 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: November 14, 2021 L. Bo 6 China Telecom 7 May 13, 2021 9 Echo Request/Reply for Enabled In-situ OAM Capabilities 10 draft-xiao-ippm-ioam-conf-state-09 12 Abstract 14 This document describes an extension to the echo request/reply 15 mechanisms used in IPv6, MPLS and SFC environments, which can be used 16 within an IOAM domain, allowing the IOAM encapsulating node to 17 acquire the enabled IOAM capabilities of each IOAM transit node and/ 18 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 November 14, 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 and SFC environments, which can be used 133 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 and SFC 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 This feature described in this document is assumedly applied to 153 explicit path (strict or loose), because the precondition for this 154 feature to work is that the echo request reaches each IOAM transit 155 node as live traffic traverses. 157 2. Conventions 159 2.1. Requirements Language 161 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 162 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 163 "OPTIONAL" in this document are to be interpreted as described in BCP 164 14 [RFC2119] [RFC8174] when, and only when, they appear in all 165 capitals, as shown here. 167 2.2. Abbreviations 169 BGP: Border Gateway Protocol 171 E2E: Edge to Edge 173 ICMP: Internet Control Message Protocol 175 IGP: Interior Gateway Protocol 177 IOAM: In-situ Operations, Administration, and Maintenance 179 LSP: Label Switched Path 181 MPLS: Multi-Protocol Label Switching 183 MBZ: Must Be Zero 185 MTU: Maximum Transmission Unit 187 NTP: Network Time Protocol 189 OAM: Operations, Administration, and Maintenance 190 PCEP: Path Computation Element (PCE) Communication Protocol 192 POSIX: Portable Operating System Interface 194 POT: Proof of Transit 196 PTP: Precision Time Protocol 198 SFC: Service Function Chain 200 TTL: Time to Live 202 3. IOAM Capabilities Formats 204 3.1. IOAM Capabilities Query TLV in the Echo Request 206 In echo request IOAM Capabilities Query uses TLV (Type-Length-Value 207 tuple) which have the following format: 209 0 1 2 3 210 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 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 | Type = IOAM Capabilities Query| Length | 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 . . 215 . List of Namespace-IDs . 216 . . 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 Figure 1: IOAM Capabilities Query TLV in the Echo Request 221 When this TLV is present in the echo request sent by an IOAM 222 encapsulating node, it means that the IOAM encapsulating node 223 requests the receiving node to reply with its enabled IOAM 224 capabilities. If there is no IOAM capability to be reported by the 225 receiving node, then this TLV SHOULD be ignored by the receiving 226 node, which means the receiving node SHOULD send echo reply without 227 IOAM capabilities or no echo reply, in the light of whether the echo 228 request includes other TLV than IOAM Capabilities Query TLV. List of 229 Namespace-IDs MAY be included in this TLV of the echo request. In 230 that case, the IOAM encapsulating node requests only the IOAM 231 capabilities that match one of the Namespace-IDs. The Namespace-ID 232 has the same definition as what's specified in 233 [I-D.ietf-ippm-ioam-data]. 235 Type is set to the value that identifies it as an IOAM Capabilities 236 Query TLV. 238 Length is the length of the TLV's Value field in octets, including a 239 List of Namespace-IDs. 241 Value field of this TLV is zero-padded to align to a 4-octet 242 boundary. 244 3.2. IOAM Capabilities Response TLV in the Echo Reply 246 In echo reply IOAM Capabilities Response uses TLV which have the 247 following format: 249 0 1 2 3 250 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 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | Type = IOAM Capabilities Resp | Length | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 . . 255 . List of Sub-TLVs . 256 . . 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 Figure 2: IOAM Capabilities Response TLV in the Echo Reply 261 When this TLV is present in the echo reply sent by an IOAM transit 262 node and/or an IOAM decapsulating node, it means that the IOAM 263 function is enabled at this node, and this TLV contains the enabled 264 IOAM capabilities of the sender. A list of Sub-TLVs which contains 265 the IOAM capabilities SHOULD be included in this TLV of the echo 266 reply. Note that the IOAM encapsulating node or the IOAM 267 decapsulating node can also be an IOAM transit node. 269 Type is set to the value that identifies it as an IOAM Capabilities 270 Response TLV. 272 Length is the length of the TLV's Value field in octets, including a 273 List of Sub-TLVs. 275 Value field of this TLV or any Sub-TLV is zero-padded to align to a 276 4-octet boundary. Based on the data fields for IOAM, specified in 277 [I-D.ietf-ippm-ioam-data] and [I-D.ietf-ippm-ioam-direct-export], six 278 kinds of Sub-TLVs are defined in this document. The same type of the 279 sub-TLV MAY be in the IOAM Capabilities Response TLV more than once 280 only if with a different Namespace-ID. 282 3.2.1. IOAM Pre-allocated Tracing Capabilities sub-TLV 284 0 1 2 3 285 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 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 |Sub-type = Pre-allocated trace | Length | 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 | IOAM-Trace-Type | Reserved | 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 | Namespace-ID | Egress_MTU | 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | Egress_if_id (short or wide format) ...... | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 Figure 3: IOAM Pre-allocated Tracing Capabilities Sub-TLV 298 When this sub-TLV is present in the IOAM Capabilities Response TLV, 299 it means that the sending node is an IOAM transit node and IOAM pre- 300 allocated tracing function is enabled at this IOAM transit node. 302 Sub-type is set to the value that identifies it as an IOAM Pre- 303 allocated Tracing Capabilities sub-TLV. 305 Length is the length of the sub-TLV's Value field in octets. If 306 Egress_if_id is in the short format, which is 16 bits long, it MUST 307 be set to 10. If Egress_if_id is in the wide format, which is 32 308 bits long, it MUST be set to 12. 310 IOAM-Trace-Type field has the same definition as what's specified in 311 section 5.4 of [I-D.ietf-ippm-ioam-data]. 313 Reserved field is reserved for future use and MUST be set to zero. 315 Namespace-ID field has the same definition as what's specified in 316 section 5.3 of [I-D.ietf-ippm-ioam-data], it should be one of the 317 Namespace-IDs listed in the IOAM Capabilities Query TLV of echo 318 request. 320 Egress_MTU field has 16 bits and specifies the MTU of the egress 321 direction out of which the sending node would forward the received 322 echo request, it should be the MTU of the egress interface or the MTU 323 between the sending node and the downstream IOAM transit node. 325 Egress_if_id field has 16 bits (in short format) or 32 bits (in wide 326 format) and specifies the identifier of the egress interface out of 327 which the sending node would forward the received echo request. 329 3.2.2. IOAM Incremental Tracing Capabilities sub-TLV 331 0 1 2 3 332 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 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 | Sub-type = Incremental trace | Length | 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 | IOAM-Trace-Type | Reserved | 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 | Namespace-ID | Egress_MTU | 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 | Egress_if_id (short or wide format) ...... | 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 Figure 4: IOAM Incremental Tracing Capabilities Sub-TLV 345 When this sub-TLV is present in the IOAM Capabilities Response TLV, 346 it means that the sending node is an IOAM transit node and IOAM 347 incremental tracing function is enabled at this IOAM transit node. 349 Sub-type is set to the value that identifies it as an IOAM 350 Incremental Tracing Capabilities sub-TLV. 352 Length is the length of the sub-TLV's Value field in octets. If 353 Egress_if_id is in the short format, which is 16 bits long, it MUST 354 be set to 10. If Egress_if_id is in the wide format, which is 32 355 bits long, it MUST be set to 12. 357 IOAM-Trace-Type field has the same definition as what's specified in 358 section 5.4 of [I-D.ietf-ippm-ioam-data]. 360 Reserved field is reserved for future use and MUST be set to zero. 362 Namespace-ID field has the same definition as what's specified in 363 section 5.3 of [I-D.ietf-ippm-ioam-data], it should be one of the 364 Namespace-IDs listed in the IOAM Capabilities Query TLV of echo 365 request. 367 Egress_MTU field has 16 bits and specifies the MTU of the egress 368 direction out of which the sending node would forward the received 369 echo request, it should be the MTU of the egress interface or the MTU 370 between the sending node and the downstream IOAM transit node. 372 Egress_if_id field has 16 bits (in short format) or 32 bits (in wide 373 format) and specifies the identifier of the egress interface out of 374 which the sending node would forward the received echo request. 376 3.2.3. IOAM Proof of Transit Capabilities sub-TLV 378 0 1 2 3 379 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 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 | Sub-type = POT Capabilities | Length | 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 | Namespace-ID | IOAM-POT-Type |P|SoR|Reserved | 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 Figure 5: IOAM Proof of Transit Capabilities Sub-TLV 388 When this sub-TLV is present in the IOAM Capabilities Response TLV, 389 it means that the sending node is an IOAM transit node and IOAM proof 390 of transit function is enabled at this IOAM transit node. 392 Sub-type is set to the value that identifies it as an IOAM Proof of 393 Transit Capabilities sub-TLV. 395 Length is the length of the sub-TLV's Value field in octets and MUST 396 be set to 4. 398 Namespace-ID field has the same definition as what's specified in 399 section 5.3 of [I-D.ietf-ippm-ioam-data], it should be one of the 400 Namespace-IDs listed in the IOAM Capabilities Query TLV of echo 401 request. 403 IOAM-POT-Type field and P bit have the same definition as what's 404 specified in section 5.5 of [I-D.ietf-ippm-ioam-data]. If the IOAM 405 encapsulating node receives IOAM-POT-Type and/or P bit values from an 406 IOAM transit node that are different from its own, then the IOAM 407 encapsulating node MAY choose to abandon the proof of transit 408 function or to select one kind of IOAM-POT-Type and P bit, it's based 409 on the policy applied to the IOAM encapsulating node. 411 SoR field has two bits, which means the size of "Random" and 412 "Cumulative" data that are specified in section 5.5 of 413 [I-D.ietf-ippm-ioam-data]. This document defines SoR as follow: 415 0b00 means 64-bit "Random" and 64-bit "Cumulative" data. 417 0b01~0b11: Reserved for future standardization 419 Reserved field is reserved for future use and MUST be set to zero. 421 3.2.4. IOAM Edge-to-Edge Capabilities sub-TLV 423 0 1 2 3 424 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 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 | Sub-type = E2E Capabilities | Length | 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 | Namespace-ID | IOAM-E2E-Type | 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 |TSF|TSL| Reserved | MBZ | 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 Figure 6: IOAM Edge-to-Edge Capabilities Sub-TLV 435 When this sub-TLV is present in the IOAM Capabilities Response TLV, 436 it means that the sending node is an IOAM decapsulating node and IOAM 437 edge-to-edge function is enabled at this IOAM decapsulating node. 438 That is to say, if the IOAM encapsulating node receives this sub-TLV, 439 the IOAM encapsulating node can determine that the node which sends 440 this sub-TLV is an IOAM decapsulating node. 442 Sub-type is set to the value that identifies it as an IOAM Edge-to- 443 Edge Capabilities sub-TLV. 445 Length is the length of the sub-TLV's Value field in octets and MUST 446 be set to 8. 448 Namespace-ID field has the same definition as what's specified in 449 section 5.3 of [I-D.ietf-ippm-ioam-data], it should be one of the 450 Namespace-IDs listed in the IOAM Capabilities Query TLV of echo 451 request. 453 IOAM-E2E-Type field has the same definition as what's specified in 454 section 5.6 of [I-D.ietf-ippm-ioam-data]. 456 TSF field specifies the timestamp format used by the sending node. 457 This document defines TSF as follow: 459 0b00: PTP timestamp format 461 0b01: NTP timestamp format 463 0b10: POSIX timestamp format 465 0b11: Reserved for future standardization 467 TSL field specifies the timestamp length used by the sending node. 468 This document defines TSL as follow. 470 When the TSF field is set to 0b00, which indicates the PTP 471 timestamp format, the values of the TSL field are interpreted as 472 follows: 474 0b00: 64-bit PTPv1 timestamp as defined in IEEE1588-2008 475 [IEEE1588v2] 477 0b01: 80-bit PTPv2 timestamp as defined in IEEE1588-2008 478 [IEEE1588v2] 480 0b10~0b11: Reserved for future standardization 482 When the TSF field is set to 0b01, which indicates the NTP 483 timestamp format, the values of the TSL field are interpreted as 484 follows: 486 0b00: 32-bit NTP timestamp as defined in NTPv4 [RFC5905] 488 0b01: 64-bit NTP timestamp as defined in NTPv4 [RFC5905] 490 0b10: 128-bit NTP timestamp as defined in NTPv4 [RFC5905] 492 0b11: Reserved for future standardization 494 When the TSF field is set to 0b10 or 0b11, the TSL field would be 495 ignored. 497 Reserved field is reserved for future use and MUST be set to zero. 499 3.2.5. IOAM DEX Capabilities sub-TLV 501 0 1 2 3 502 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 503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 504 | Sub-type = DEX Capabilities | Length | 505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 506 | IOAM-Trace-Type | Reserved | 507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 | Namespace-ID | Reserved | 509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 511 Figure 7: IOAM DEX Capabilities Sub-TLV 513 When this sub-TLV is present in the IOAM Capabilities Response TLV, 514 it means that the sending node is an IOAM transit node and the IOAM 515 DEX function is enabled at this IOAM transit node. 517 Sub-type is set to the value that identifies it as an IOAM DEX 518 Capabilities sub-TLV. 520 Length is the length of the sub-TLV's Value field in octets and MUST 521 be set to 8. 523 IOAM-Trace-Type field has the same definition as what's specified in 524 section 3.2 of [I-D.ietf-ippm-ioam-direct-export]. 526 Namespace-ID field has the same definition as what's specified in 527 section 3.2 of [I-D.ietf-ippm-ioam-direct-export], it should be one 528 of the Namespace-IDs listed in the IOAM Capabilities Query TLV of 529 echo request. 531 Reserved field is reserved for future use and MUST be set to zero. 533 3.2.6. IOAM End-of-Domain sub-TLV 535 0 1 2 3 536 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 537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 538 | Sub-type = End of Domain | Length | 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 540 | Namespace-ID | MBZ | 541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 543 Figure 8: IOAM End of Domain Sub-TLV 545 When this sub-TLV is present in the IOAM Capabilities Response TLV, 546 it means that the sending node is an IOAM decapsulating node. That 547 is to say, if the IOAM encapsulating node receives this sub-TLV, the 548 IOAM encapsulating node can determine that the node which sends this 549 sub-TLV is an IOAM decapsulating node. When the IOAM Edge-to-Edge 550 Capabilities sub-TLV is present in the IOAM Capabilities Response TLV 551 sent by the IOAM decapsulating node, the IOAM End-of-Domain sub-TLV 552 doesn't need to be present in the same IOAM Capabilities Response 553 TLV, otherwise the End-of-Domain sub-TLV MUST be present in the IOAM 554 Capabilities Response TLV sent by the IOAM decapsulating node. Both 555 the IOAM Edge-to-Edge Capabilities sub-TLV and the IOAM End-of-Domain 556 sub-TLV can be used to indicate that the sending node is an IOAM 557 decapsulating node. It's recommended to include only the IOAM Edge- 558 to-Edge Capabilities sub-TLV if IOAM edge-to-edge function is enabled 559 at this IOAM decapsulating node. 561 Sub-type is set to the value that identifies it as an IOAM End of 562 Domain sub-TLV. 564 Length is the length of the sub-TLV's Value field in octets and MUST 565 be set to 4. 567 Namespace-ID field has the same definition as what's specified in 568 section 5.3 of [I-D.ietf-ippm-ioam-data], it should be one of the 569 Namespace-IDs listed in the IOAM Capabilities Query TLV of echo 570 request. 572 4. Operational Guide 574 Once the IOAM encapsulating node is triggered to acquire the enabled 575 IOAM capabilities of each IOAM transit node and/or IOAM decapsulating 576 node, the IOAM encapsulating node will send echo requests that 577 include the IOAM Capabilities Query TLV. First with TTL equal to 1 578 to reach the nearest node, which may be an IOAM transit node or not. 579 Then with TTL equal to 2 to reach the second nearest node, which also 580 may be an IOAM transit node or not. And further, increasing by 1 the 581 TTL every time the IOAM encapsulating node sends a new echo request, 582 until the IOAM encapsulating node receives an echo reply sent by the 583 IOAM decapsulating node, which should contain the IOAM Capabilities 584 Response TLV including the IOAM Edge-to-Edge Capabilities sub-TLV or 585 the IOAM End-of-Domain sub-TLV. Alternatively, if the IOAM 586 encapsulating node knows exactly all the IOAM transit nodes and/or 587 IOAM decapsulating node beforehand, once the IOAM encapsulating node 588 is triggered to acquire the enabled IOAM capabilities, it can send an 589 echo request to each IOAM transit node and/or IOAM decapsulating node 590 directly, without TTL expiration. 592 The IOAM encapsulating node may be triggered by the device 593 administrator, the network management system, the network controller, 594 or even the live user traffic. The specific triggering mechanisms 595 are outside the scope of this document. 597 Each IOAM transit node and/or IOAM decapsulating node that receives 598 an echo request containing the IOAM Capabilities Query TLV will send 599 an echo reply to the IOAM encapsulating node, and within the echo 600 reply, there should be an IOAM Capabilities Response TLV containing 601 one or more sub-TLVs. The IOAM Capabilities Query TLV contained in 602 the echo request would be ignored by the receiving node that is 603 unaware of IOAM. 605 5. Security Considerations 607 Queries and responses about the state of an IOAM domain should be 608 processed only from a trusted source. An unauthorized query MUST be 609 discarded by an implementation that supports this specification. 610 Similarly, unsolicited echo response with the IOAM Capabilities TLV 611 MUST be discarded. Authentication of echo request/reply that 612 includes the IOAM Capabilities TLV is one of methods of the integrity 613 protection. Implementations could also provide a means of filtering 614 based on the source address of the received echo request/reply. The 615 integrity protection for IOAM capabilities information collection can 616 also be achieved using mechanisms in the underlay data plane. For 617 example, if the underlay is an IPv6 network, IP Authentication Header 618 [RFC4302] or IP Encapsulating Security Payload Header [RFC4303] can 619 be used to provide integrity protection. 621 Information about the state of the IOAM domain collected in the IAOM 622 Capabilities TLV is confidential. An implementation can use secure 623 transport to provide privacy protection. For example, if the 624 underlay is an IPv6 network, confidentiality can be achieved using 625 the IP Encapsulating Security Payload Header [RFC4303]. 627 6. IANA Considerations 629 This document requests the following IANA Actions. 631 IANA is requested to create a registry group named "In-Situ OAM 632 (IOAM) Capabilities Parameters". 634 This group will include the following registries: 636 o IOAM SoR Capability 638 o IOAM TSF+TSL Capability 640 New registries in this group can be created via RFC Required process 641 as per [RFC8126]. 643 The subsequent sub-sections detail the registries herein contained. 645 Considering the TLVs/sub-TLVs defined in this document would be 646 carried in different kinds of Echo Request/Reply message, such as 647 ICMPv6 or LSP Ping, it is intended that the registries for Type and 648 sub-Type would be requested in subsequent documents. 650 6.1. IOAM SoR Capability Registry 652 This registry defines 4 code points for the IOAM SoR Capability field 653 for identifying the size of "Random" and "Cumulative" data as 654 explained in section 5.5 of [I-D.ietf-ippm-ioam-data]. The following 655 code points are defined in this draft: 657 SoR Description 658 ---- ----------- 659 0b00 64-bit "Random" and 64-bit "Cumulative" data 661 0b01 - 0b11 are available for assignment via RFC Required process as 662 per [RFC8126]. 664 6.2. IOAM TSF+TSL Capability Registry 666 This registry defines 3 code points for the IOAM TSF Capability field 667 for identifying the timestamp format as explained in section 6 of 668 [I-D.ietf-ippm-ioam-data]. 670 o When the code point for the IOAM TSF Capability field equals 0b00 671 which means PTP timestamp format, this registry defines 2 code 672 points for the IOAM TSL Capability field for identifying the 673 timestamp length. 675 o When the code point for the IOAM TSF Capability field equals 0b01 676 which means NTP timestamp format, this registry defines 3 code 677 points for the IOAM TSL Capability field for identifying the 678 timestamp length. 680 The following code points are defined in this draft: 682 TSF TSL Description 683 ---- ---- ----------- 684 0b00 PTP Timestamp Format 685 0b00 64-bit PTPv1 timestamp 686 0b01 80-bit PTPv2 timestamp 687 0b01 NTP Timestamp Format 688 0b00 32-bit NTP timestamp 689 0b01 64-bit NTP timestamp 690 0b10 128-bit NTP timestamp 691 0b10 POSIX Timestamp Format 693 Unassigned code points of TSF+TSL are available for assignment via 694 RFC Required process as per [RFC8126]. 696 7. Acknowledgements 698 The authors would like to acknowledge Tianran Zhou, Dhruv Dhody, 699 Frank Brockners and Cheng Li for their careful review and helpful 700 comments. 702 The authors appreciate the f2f discussion with Frank Brockners on 703 this document. 705 The authors would like to acknowledge Tommy Pauly and Ian Swett for 706 their good suggestion and guidance. 708 8. References 710 8.1. Normative References 712 [I-D.ietf-ippm-ioam-data] 713 Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields 714 for In-situ OAM", draft-ietf-ippm-ioam-data-12 (work in 715 progress), February 2021. 717 [I-D.ietf-ippm-ioam-direct-export] 718 Song, H., Gafni, B., Zhou, T., Li, Z., Brockners, F., 719 Bhandari, S., Sivakolundu, R., and T. Mizrahi, "In-situ 720 OAM Direct Exporting", draft-ietf-ippm-ioam-direct- 721 export-03 (work in progress), February 2021. 723 [IEEE1588v2] 724 IEEE, "IEEE Std 1588-2008 - IEEE Standard for a Precision 725 Clock Synchronization Protocol for Networked Measurement 726 and Control Systems", IEEE Std 1588-2008, 2008, 727 . 730 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 731 Requirement Levels", BCP 14, RFC 2119, 732 DOI 10.17487/RFC2119, March 1997, 733 . 735 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 736 "Network Time Protocol Version 4: Protocol and Algorithms 737 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 738 . 740 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 741 Writing an IANA Considerations Section in RFCs", BCP 26, 742 RFC 8126, DOI 10.17487/RFC8126, June 2017, 743 . 745 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 746 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 747 May 2017, . 749 8.2. Informative References 751 [I-D.ietf-sfc-multi-layer-oam] 752 Mirsky, G., Meng, W., Khasnabish, B., and C. Wang, "Active 753 OAM for Service Function Chaining", draft-ietf-sfc-multi- 754 layer-oam-10 (work in progress), March 2021. 756 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 757 DOI 10.17487/RFC4302, December 2005, 758 . 760 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 761 RFC 4303, DOI 10.17487/RFC4303, December 2005, 762 . 764 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 765 Control Message Protocol (ICMPv6) for the Internet 766 Protocol Version 6 (IPv6) Specification", STD 89, 767 RFC 4443, DOI 10.17487/RFC4443, March 2006, 768 . 770 [RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, 771 "Extended ICMP to Support Multi-Part Messages", RFC 4884, 772 DOI 10.17487/RFC4884, April 2007, 773 . 775 [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., 776 Aldrin, S., and M. Chen, "Detecting Multiprotocol Label 777 Switched (MPLS) Data-Plane Failures", RFC 8029, 778 DOI 10.17487/RFC8029, March 2017, 779 . 781 [RFC8335] Bonica, R., Thomas, R., Linkova, J., Lenart, C., and M. 782 Boucadair, "PROBE: A Utility for Probing Interfaces", 783 RFC 8335, DOI 10.17487/RFC8335, February 2018, 784 . 786 Authors' Addresses 788 Xiao Min 789 ZTE Corp. 790 Nanjing 791 China 793 Phone: +86 25 88013062 794 Email: xiao.min2@zte.com.cn 796 Greg Mirsky 797 ZTE Corp. 798 USA 800 Email: gregory.mirsky@ztetx.com 801 Lei Bo 802 China Telecom 803 Beijing 804 China 806 Phone: +86 10 50902903 807 Email: leibo@chinatelecom.cn