idnits 2.17.1 draft-ooamdt-rtgwg-ooam-header-04.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 (March 18, 2018) is 2224 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE.1588.2008' == Outdated reference: A later version (-16) exists of draft-ietf-nvo3-geneve-06 == Outdated reference: A later version (-13) exists of draft-ietf-nvo3-vxlan-gpe-05 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NVO3 Working Group G. Mirsky 3 Internet-Draft ZTE Corp. 4 Intended status: Standards Track N. Kumar 5 Expires: September 19, 2018 D. Kumar 6 Cisco Systems, Inc. 7 M. Chen 8 Y. Li 9 Huawei Technologies 10 D. Dolson 11 Sandvine 12 March 18, 2018 14 OAM Header for use in Overlay Networks 15 draft-ooamdt-rtgwg-ooam-header-04 17 Abstract 19 This document introduces Overlay Operations, Administration, and 20 Maintenance (OOAM) Header to be used in overlay networks to create 21 Overlay Associated Channel (OAC) to ensure that OOAM control packets 22 are in-band with user traffic and de-multiplex OOAM protocols. 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 September 19, 2018. 41 Copyright Notice 43 Copyright (c) 2018 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 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 1.1. Conventions used in this document . . . . . . . . . . . . 2 60 1.1.1. Terminology . . . . . . . . . . . . . . . . . . . . . 3 61 1.1.2. Requirements Language . . . . . . . . . . . . . . . . 3 62 2. General Requirements to OAM Protocols in Overlay Networks . . 3 63 3. Associated Channel in Overlay Networks . . . . . . . . . . . 4 64 4. Overlay OAM Header . . . . . . . . . . . . . . . . . . . . . 4 65 4.1. Use of OOAM Header in Active OAM . . . . . . . . . . . . 6 66 4.2. Use of OOAM Header in Hybrid OAM . . . . . . . . . . . . 7 67 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 68 5.1. OOAM Message Types . . . . . . . . . . . . . . . . . . . 7 69 5.2. OOAM Header Flags . . . . . . . . . . . . . . . . . . . . 8 70 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 71 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8 72 8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 9 73 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 74 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 75 9.2. Informative References . . . . . . . . . . . . . . . . . 9 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 78 1. Introduction 80 New protocols that support overlay networks like VxLAN-GPE 81 [I-D.ietf-nvo3-vxlan-gpe], GUE [I-D.ietf-nvo3-gue], Geneve 82 [I-D.ietf-nvo3-geneve], BIER [RFC8296], and NSH [RFC8300] support 83 multi-protocol payload, e.g. Ethernet, IPv4/IPv6, and recognize 84 Operations, Administration, and Maintenance (OAM) as one of distinct 85 types. That ensures that Overlay OAM (OOAM)packets are sharing fate 86 with Overlay data packet traversing the underlay. 88 This document introduces generic requirements to OAM protocols used 89 in overlay networks and defines OOAM Header to be used in overlay 90 networks to de-multiplex OOAM protocols. 92 1.1. Conventions used in this document 93 1.1.1. Terminology 95 Term "Overlay OAM" used in this document interchangeably with longer 96 version "set of OAM protocols, methods and tools for Overlay 97 networks". 99 NTP Network Time Protocol 101 OAC Overlay Associated Channel 103 OAM Operations, Administration, and Maintenance 105 OOAM Overlay OAM 107 PTP Precision Time Protocol 109 1.1.2. Requirements Language 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 113 "OPTIONAL" in this document are to be interpreted as described in 114 [RFC2119]. 116 2. General Requirements to OAM Protocols in Overlay Networks 118 OAM protocols, whether it is part of fault management or performance 119 monitoring, intended to provide reliable information that can be used 120 to identify defect, localize it and apply corrective actions. One of 121 the main challenges that network operators may encounter is 122 interpretations of reports of the defect or service degradation and 123 correlation to affected services. In order to improve reliability of 124 the correlation process we set forth the following requirements: 126 REQ#1: Overlay OAM packets SHOULD be fate sharing with data 127 traffic, i.e. in-band with the monitored traffic, i.e. follow 128 exactly the same overlay and transport path as data plane traffic, 129 in forward direction, i.e. from ingress toward egress end point(s) 130 of the OAM test. 132 REQ#2: Encapsulation of OAM control message and data packets in 133 underlay network MUST be indistinguishable from underlay network 134 forwarding point of view. 136 REQ#3: Presence of OAM control message in overlay packet MUST be 137 unambiguously identifiable. 139 REQ#4: It MUST be possible to express entropy for underlay Equal 140 Cost Multipath in overlay encapsulation in order to avoid using 141 data packet content by underlay transient nodes. 143 3. Associated Channel in Overlay Networks 145 Associated channel in the overlay network is the channel that, by 146 using the same encapsulation as user traffic, follows the same path 147 through the underlay network as user traffic. In other words, the 148 associated channel is in-band with user traffic. Creating notion of 149 the overlay associated channel (OAC) in the overlay network ensures 150 that control packets of active OAM protocols carried in the OAC are 151 in-band with user traffic. Additionally, OAC allows development of 152 OAM tools that, from operational point of view, function in 153 essentially the same manner in any type of overlay. 155 4. Overlay OAM Header 157 OOAM Header immediately follows the header of the overlay and 158 identifies OAC. The format of the OOAM Header is: 160 0 1 2 3 161 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 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 | V | Msg Type | Length | 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 | Flags | Reserved | Next Prot | 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 ~ OOAM control message ~ 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 Figure 1: Overlay OAM Header format 172 The OAM Header consists of the following fields: 174 o V - two bits long field indicates the current version of the 175 Overlay OAM Header. The current value is 0; 177 o Msg Type - 14 bits long field identifies OAM protocol, e.g. Echo 178 Request/Reply, BFD, Performance Measurement; 180 o Length - two octets long field that is length of the OOAM control 181 packet in octets; 183 o Flags -two octets long field carries bit flags that define 184 optional capability and thus processing of the OOAM control 185 packet; 187 o Reserved - one octet field that MUST be zeroed on transmit and 188 ignored on receipt; 190 o Next Prot - one octet long field that defines optional payload 191 that is present after the OOAM Control Packet. 193 The format of the Flags field is: 195 0 1 196 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 |T| Reserved | 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 Figure 2: Flags field format 203 where: 205 o T - Timestap block flag. 207 o Reserved - must be set to all zeroes on transmission and ignored 208 on receipt. 210 The OOAM header may be followed by the Timestamp control block 211 Figure 3 and then by OOAM Control Packet identified by the Msg Type 212 field. 214 0 1 2 3 215 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 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 | QTF | RTF | Reserved | 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 | Timestamp 1 | 220 | | 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 ~ ~ 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 | Timestamp 4 | 225 | | 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 Figure 3: Timestamp block format 230 where: 232 QTF - Querier timestamp format 234 RTF - Responder timestamp format 235 Timestamp 1-4 - 64-bit timestamp values 237 Network Time Protocol (NTP), described in [RFC5905], is widely used 238 and has long history of deployment. But it is the IEEE 1588 239 Precision Time Protocol (PTP) [IEEE.1588.2008] that is being broadly 240 used to achieve high-quality clock synchronization. Converging 241 between NTP and PTP time formats is possible but is not trivial and 242 does come with cost, particularly when it is required to be performed 243 in real time without loss of accuracy. And recently protocols that 244 supported only NTP time format, like One-Way Active Measurement 245 Protocol [RFC4656] and Two-Way Active Measurement Protocol [RFC5357], 246 have been enhanced to support the PTP time format as well [RFC8186]. 247 This document proposes to select PTP time format as default time 248 format for Overlay OAM performance measurement. Hence QTF, RTF 249 fields MUST be set to 0 if querier or responder use PTP time format 250 respectively. If the querier or responder use the NTP time format, 251 then QTF and/or RTF MUST be set to 1. Use of other values MUST be 252 considered as error and MAY be reported. 254 4.1. Use of OOAM Header in Active OAM 256 Active OAM methods, whether used for fault management or performance 257 monitoring, generate dedicated test packets [RFC7799]. Format of an 258 OAM test packet in overlay network presented in Figure 4. 260 0 1 2 3 261 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 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 ~ Underlay network encapsulation ~ 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 ~ Overlay network encapsulation ~ 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 | | 268 + OOAM Header +-+-+-+-+-+-+-+-+ 269 | |NextProt = None| 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 ~ OOAM control message ~ 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 Figure 4: Overlay OAM Header in Active OAM Control Packet 276 Because active OAM method uses only OAM protocol value of Next Prot 277 field in the OOAM header is set to None indicating that there's no 278 content from other protocol immediately after OOAM control message in 279 the packet. 281 4.2. Use of OOAM Header in Hybrid OAM 283 Hybrid OAM Type I methods, whether used for fault management or 284 performance monitoring, modify user data packets [RFC7799]. Format 285 of such modified packet in overlay network presented in Figure 5. 287 0 1 2 3 288 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 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 ~ Underlay network encapsulation ~ 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 ~ Overlay network encapsulation ~ 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 | | 295 + OOAM Header +-+-+-+-+-+-+-+-+ 296 | |NextProt = Data| 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 ~ OOAM control message ~ 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 ~ User data ~ 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 Figure 5: Overlay OAM Header in Hybrid OAM Control Packet 305 In case when OOAM header used for Hybrid Type I OAM method value of 306 the Next Prot field is set to the value associated with the protocol 307 of the user data. 309 5. IANA Considerations 311 IANA is requested to create new registry called "Overlay OAM". 313 5.1. OOAM Message Types 315 IANA is requested to create new sub-registry called "Overlay OAM 316 Protocol Types" in the "Overlay OAM" registry. All code points in 317 the range 1 through 15615 in this registry shall be allocated 318 according to the "IETF Review" procedure as specified in [RFC8126] . 319 Remaining code points are allocated according to the Table 1: 321 +---------------+--------------+-------------------------+ 322 | Value | Description | Reference | 323 +---------------+--------------+-------------------------+ 324 | 0 | Reserved | | 325 | 1 - 15615 | Unassigned | IETF Review | 326 | 15616 - 16127 | Unassigned | First Come First Served | 327 | 16128 - 16143 | Experimental | This document | 328 | 16144 - 16382 | Private Use | This document | 329 | 16383 | Reserved | This document | 330 +---------------+--------------+-------------------------+ 332 Table 1: Overlay OAM Protocol type 334 5.2. OOAM Header Flags 336 IANA is requested to create sub-registry "Overlay OAM Header Flags" 337 in "Overlay OAM" registry. Two flags are defined in this document. 338 New values are assigned via Standards Action [RFC8126]. 340 +-----------+-----------------+---------------+ 341 | Flags bit | Description | Reference | 342 +-----------+-----------------+---------------+ 343 | Bit 0 | Timestamp field | This document | 344 | Bit 1-15 | Unassigned | | 345 +-----------+-----------------+---------------+ 347 Table 2: Overlay OAM Flags 349 6. Security Considerations 351 TBD 353 7. Contributors 355 Work on this documented started by Overlay OAM Design Team with 356 contributions from: 358 Carlos Pignataro 360 Cisco Systems, Inc. 362 cpignata@cisco.com 364 Erik Nordmark 366 Arista Networks 368 nordmark@acm.org 369 Ignas Bagdonas 371 ibagdona@gmail.com 373 David Mozes 375 Mellanox Technologies Ltd. 377 davidm@mellanox.com 379 8. Acknowledgement 381 TBD 383 9. References 385 9.1. Normative References 387 [IEEE.1588.2008] 388 "Standard for a Precision Clock Synchronization Protocol 389 for Networked Measurement and Control Systems", 390 IEEE Standard 1588, July 2008. 392 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 393 Requirement Levels", BCP 14, RFC 2119, 394 DOI 10.17487/RFC2119, March 1997, 395 . 397 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 398 "Network Time Protocol Version 4: Protocol and Algorithms 399 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 400 . 402 9.2. Informative References 404 [I-D.ietf-nvo3-geneve] 405 Gross, J., Ganga, I., and T. Sridhar, "Geneve: Generic 406 Network Virtualization Encapsulation", draft-ietf- 407 nvo3-geneve-06 (work in progress), March 2018. 409 [I-D.ietf-nvo3-gue] 410 Herbert, T., Yong, L., and O. Zia, "Generic UDP 411 Encapsulation", draft-ietf-nvo3-gue-05 (work in progress), 412 October 2016. 414 [I-D.ietf-nvo3-vxlan-gpe] 415 Maino, F., Kreeger, L., and U. Elzur, "Generic Protocol 416 Extension for VXLAN", draft-ietf-nvo3-vxlan-gpe-05 (work 417 in progress), October 2017. 419 [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. 420 Zekauskas, "A One-way Active Measurement Protocol 421 (OWAMP)", RFC 4656, DOI 10.17487/RFC4656, September 2006, 422 . 424 [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. 425 Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", 426 RFC 5357, DOI 10.17487/RFC5357, October 2008, 427 . 429 [RFC7799] Morton, A., "Active and Passive Metrics and Methods (with 430 Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, 431 May 2016, . 433 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 434 Writing an IANA Considerations Section in RFCs", BCP 26, 435 RFC 8126, DOI 10.17487/RFC8126, June 2017, 436 . 438 [RFC8186] Mirsky, G. and I. Meilik, "Support of the IEEE 1588 439 Timestamp Format in a Two-Way Active Measurement Protocol 440 (TWAMP)", RFC 8186, DOI 10.17487/RFC8186, June 2017, 441 . 443 [RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 444 Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation 445 for Bit Index Explicit Replication (BIER) in MPLS and Non- 446 MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January 447 2018, . 449 [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 450 "Network Service Header (NSH)", RFC 8300, 451 DOI 10.17487/RFC8300, January 2018, 452 . 454 Authors' Addresses 456 Greg Mirsky 457 ZTE Corp. 459 Email: gregimirsky@gmail.com 460 Nagendra Kumar 461 Cisco Systems, Inc. 463 Email: naikumar@cisco.com 465 Deepak Kumar 466 Cisco Systems, Inc. 468 Email: dekumar@cisco.com 470 Mach Chen 471 Huawei Technologies 473 Email: mach.chen@huawei.com 475 Yizhou Li 476 Huawei Technologies 478 Email: liyizhou@huawei.com 480 David Dolson 481 Sandvine 483 Email: ddolson@sandvine.com