idnits 2.17.1 draft-mirsky-detnet-oam-02.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 (November 11, 2018) is 1993 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-detnet-architecture-09 == Outdated reference: A later version (-02) exists of draft-ietf-detnet-dp-sol-ip-01 == Outdated reference: A later version (-02) exists of draft-ietf-detnet-dp-sol-mpls-01 -- Obsolete informational reference (is this intentional?): RFC 8321 (Obsoleted by RFC 9341) Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DetNet Working Group G. Mirsky 3 Internet-Draft ZTE Corp. 4 Intended status: Standards Track M. Chen 5 Expires: May 15, 2019 Huawei 6 November 11, 2018 8 Operations, Administration and Maintenance (OAM) for Deterministic 9 Networks (DetNet) 10 draft-mirsky-detnet-oam-02 12 Abstract 14 This document lists functional requirements for Operations, 15 Administration and Maintenance (OAM) toolset in Deterministic 16 Networks (DetNet) and, using these requirements; defines format and 17 use principals of the DetNet service Associated Channel. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on May 15, 2019. 36 Copyright Notice 38 Copyright (c) 2018 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Conventions used in this document . . . . . . . . . . . . . . 3 55 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 56 2.2. Keywords . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 4 58 4. DetNet Data Plane in Support of Active OAM . . . . . . . . . 5 59 4.1. MPLS Encapsulation . . . . . . . . . . . . . . . . . . . 5 60 4.1.1. DetNet Active OAM Encapsulation . . . . . . . . . . . 6 61 4.1.2. IP Encapsulation . . . . . . . . . . . . . . . . . . 8 62 4.2. DetNet Replication, Elimination, and Ordering Sub- 63 functions Interaction with Active OAM . . . . . . . . . . 8 64 5. Use of Hybrid OAM in DetNet . . . . . . . . . . . . . . . . . 8 65 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 66 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 67 8. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 9 68 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 69 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 70 9.2. Informational References . . . . . . . . . . . . . . . . 10 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 73 1. Introduction 75 [I-D.ietf-detnet-architecture] introduces and explains Deterministic 76 Networks (DetNet) architecture and how the Packet Replication and 77 Elimination function (PREF) can be used to ensure low packet drop 78 ratio in DetNet domain. 80 Operations, Administration and Maintenance (OAM) protocols are used 81 to detect, localize defects in the network, and monitor network 82 performance. Some OAM functions, e.g., failure detection, work in 83 the network proactively, while others, e.g., defect localization, 84 usually performed on-demand. These tasks achieved by a combination 85 of active and hybrid, as defined in [RFC7799], OAM methods. 87 This document lists the functional requirements toward OAM for DetNet 88 domain. The list can further be used for gap analysis of available 89 OAM tools to identify possible enhancements of existing or whether 90 new OAM tools are required to support proactive and on-demand path 91 monitoring and service validation. 93 2. Conventions used in this document 95 2.1. Terminology 97 The term "DetNet OAM" used in this document interchangeably with 98 longer version "set of OAM protocols, methods and tools for 99 Deterministic Networks". 101 CW Control Word 103 DetNet Deterministic Networks 105 d-ACH DetNet Associated Channel Header 107 d-CW DetNet Control Word 109 DNH DetNet Header 111 GAL Generic Associated Channel Label 113 G-ACh Generic Associated Channel 115 OAM: Operations, Administration and Maintenance 117 PREF Packet Replication and Elimination Function 119 POF Packet Ordering Function 121 PW Pseudowire 123 RDI Remote Defect Indication 125 Underlay Network or Underlay Layer: The network that provides 126 connectivity between the DetNet nodes. MPLS network providing LSP 127 connectivity between DetNet nodes is an example of the underlay 128 layer. 130 DetNet Node - a node that is an actor in the DetNet domain. DetNet 131 domain edge node and node that performs PREF within the domain are 132 examples of DetNet node. 134 2.2. Keywords 136 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 137 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 138 "OPTIONAL" in this document are to be interpreted as described in BCP 139 14 [RFC2119] [RFC8174] when, and only when, they appear in all 140 capitals, as shown here. 142 3. Requirements 144 This section lists requirements for OAM in DetNet domain: 146 1. The listed requirements MUST be supported for any type of 147 underlay network over which a DetNet domain can be realized. 149 2. It MUST be possible to initiate DetNet OAM session from any 150 DetNet node towards another DetNet node(s) within given domain. 152 3. It SHOULD be possible to initialize DetNet OAM session from a 153 centralized controller. 155 4. DetNet OAM MUST support proactive and on-demand OAM monitoring 156 and measurement methods. 158 5. DetNet OAM packets MUST be in-band, i.e., follow precisely the 159 same path as DetNet data plane traffic both for unidirectional 160 and bi-directional DetNet paths. 162 6. DetNet OAM MUST support unidirectional OAM methods, continuity 163 check, connectivity verification, and performance measurement. 165 7. DetNet OAM MUST support bi-directional OAM methods. Such OAM 166 methods MAY combine in-band monitoring or measurement in the 167 forward direction and out-of-bound notification in the reverse 168 direction, i.e., from egress to ingress end point of the OAM 169 test session. 171 8. DetNet OAM MUST support proactive monitoring of a DetNet node 172 availability in the given DetNet domain. 174 9. DetNet OAM MUST support Path Maximum Transmission Unit 175 discovery. 177 10. DetNet OAM MUST support Remote Defect Indication (RDI) 178 notification to the DetNet node performing continuity checking. 180 11. DetNet OAM MUST support performance measurement methods. 182 12. DetNet OAM MAY support hybrid performance measurement methods. 184 13. DetNet OAM MUST support unidirectional performance measurement 185 methods. Calculated performance metrics MUST include but are 186 not limited to throughput, packet loss, delay and delay 187 variation metrics. [RFC6374] provides excellent details on 188 performance measurement and performance metrics. 190 14. DetNet OAM MUST support defect notification mechanism, like 191 Alarm Indication Signal. Any DetNet node in the given DetNet 192 domain MAY originate a defect notification addressed to any 193 subset of nodes within the domain. 195 15. DetNet OAM MUST support methods to enable survivability of the 196 DetNet domain. These recovery methods MAY use protection 197 switching and restoration. 199 16. DetNet OAM MUST support the discovery of Packet Replication, 200 Elimination, and Order preservation sub-functions locations in 201 the domain. 203 17. DetNet OAM MUST support testing of Packet Replication, 204 Elimination, and Order preservation sub-functions in the domain. 206 18. DetNet OAM MUST support monitoring any sub-set of paths 207 traversed through the DetNet domain by the DetNet flow. 209 4. DetNet Data Plane in Support of Active OAM 211 OAM protocols and mechanisms act within the data plane of the 212 particular networking layer. And thus it is critical that the data 213 plane encapsulation supports OAM mechanisms in such a way to comply 214 with the above-listed requirements. One of such examples that 215 require special consideration is requirement #5: 217 DetNet OAM packets MUST be in-band, i.e., follow precisely the 218 same path as DetNet data plane traffic both for unidirectional and 219 bi-directional DetNet paths. 221 4.1. MPLS Encapsulation 223 The Det Net data plane encapsulation in transport network with MPLS 224 and IP encapsulations specified in [I-D.ietf-detnet-dp-sol-mpls] and 225 [I-D.ietf-detnet-dp-sol-ip] respectively. For the MPLS underlay 226 network, DetNet flows to be encapsulated analogous to pseudowires 227 (PW) over MPLS packet switched network, as described in [RFC3985], 228 [RFC4385]. Generic PW MPLS Control Word (CW), defined in [RFC4385], 229 for DetNet displayed in Figure 1. 231 0 1 2 3 232 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 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 |0 0 0 0| Sequence Number | 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 Figure 1: DetNet Control Word Format 239 PREF in the DetNet domain composed by a combination of nodes that 240 perform replication and elimination sub-functions. The elimination 241 sub-function always uses the S-Label and packet sequencing 242 information, e.g., the value in the Sequence Number field of DetNet 243 CW (d-CW). The replication sub-function uses the S-Label information 244 only. For data packets Figure 2 presents an example of PREF in 245 DetNet domain. 247 1111 11111111 111111 112212 112212 132213 248 CE1----EN1--------R1-------R2-------R3--------EN2----CE2 249 \2 22222/ 3 / 250 \2222222 /----+ 3 / 251 +------R4------------------------+ 252 333333333333333333333333 254 Figure 2: DetNet Data Plane Based on PW 256 4.1.1. DetNet Active OAM Encapsulation 258 DetNet OAM, like PW OAM, uses PW Associated Channel Header defined in 259 [RFC4385]. Figure 3 displays the encapsulation of a DetNet active 260 OAM packet. 262 +---------------------------------+ 263 | | 264 | DetNet Flow | 265 | OAM Packet | 266 | | 267 +---------------------------------+ <--\ 268 | DetNet Associated Channel Header| | 269 +=================================+ +--> DetNet OAM data plane 270 | S-Label | | MPLS encapsulation 271 +---------------------------------+ <--/ 272 | T-Label(s) | 273 +---------------------------------+ 274 | Data-Link | 275 +---------------------------------+ 276 | Physical | 277 +---------------------------------+ 279 Figure 3: DetNet active OAM Packet Encapsulation 281 0 1 2 3 282 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 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 |0 0 0 1|Version|Sequence Number| Channel Type | 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 Figure 4: DetNet Associated Channel Header Format 289 Figure 4 displays the format of the DetNet Associated Channel Header 290 (d-ACH). The meanings of the fields in the d-ACH are: 292 Bits 0..3 MUST be 0b0001. This value of the first nibble allows 293 the packet to be distinguished from an IP packet [RFC4928] and a 294 DetNet data packet [I-D.ietf-detnet-dp-sol-mpls]. 296 Version: this is the version number of the d-ACH. This 297 specification defines version 0. 299 Sequence Number: this is unsigned eight bits-long field. The 300 originating DetNet node MUST set the value of the Sequence Number 301 field to a non-zero before packet being transmitted. The 302 originating node MUST monotonically increase the value of the 303 Sequence Number field for the every next active OAM packet. 305 Channel Type: the value of DetNet Associated Channel Type is one 306 of values defined in the IANA PW Associated Channel Type registry. 308 The DetNet flow, according to [I-D.ietf-detnet-dp-sol-mpls], is 309 identified by the S-label that MUST be at the bottom of the stack. 310 Active OAM packet MUST have d-ACH immediately following the S-label.A 311 DetNet node originating an OAM packet MUST ensure that the value of 312 the Sequence Number field in d-ACH is monotonically increasing for 313 the given value of the Channel Type field. 315 The Generic Associated Channel Label (GAL), defined in [RFC5586] and 316 [RFC6423], provides a generalized label-based exception mechanism to 317 indicate that the packet is on a Generic Associated Channel (G-ACh) 318 and that ACH immediately follows the label stack. For the DetNet 319 domain in MPLS transport network, GAL MAY be used. If GAL is used, 320 it MUST precede S-Label on the label stack, and the S-Label MUST be 321 followed by d-ACH. 323 4.1.2. IP Encapsulation 325 [Author's Note: This will be defined based on the DetNet Flow ID 326 specification for IP underlay in [I-D.ietf-detnet-dp-sol-ip].] 328 4.2. DetNet Replication, Elimination, and Ordering Sub-functions 329 Interaction with Active OAM 331 At the DetNet service layer, special functions MAY be applied to the 332 particular DetNet flow - PREF to potentially lower packet loss, 333 improve the probability of on-time packet delivery and Packet 334 Ordering Function (POF) to ensure in-order packet delivery. As data 335 and the active OAM packets have the same Flow ID, S-label, sub- 336 functions that rely on sequencing information in the DetNet service 337 layer MUST process 28 MSBs of the d-ACH as the source of the 338 sequencing information for the OAM packet. 340 5. Use of Hybrid OAM in DetNet 342 Hybrid OAM methods are used in performance monitoring and defined in 343 [RFC7799] as: 345 Hybrid Methods are Methods of Measurement that use a combination 346 of Active Methods and Passive Methods. 348 A hybrid measurement method may produce metrics as close to passive, 349 but it still alters something in a data packet even if that is the 350 value of a designated field in the packet encapsulation. One example 351 of such a hybrid measurement method is the Alternate Marking method 352 described in [RFC8321]. Reserving the field for the Alternate 353 Marking method in the DetNet Header will enhance available to an 354 operator set of DetNet OAM tools. 356 6. IANA Considerations 358 TBA 360 7. Security Considerations 362 This document lists the OAM requirements for a DetNet domain and does 363 not raise any security concerns or issues in addition to ones common 364 to networking. 366 8. Acknowledgment 368 Authors extend their appreciation to Pascal Thubert for his 369 insightful comments and productive discussion that helped to improve 370 the document. 372 9. References 374 9.1. Normative References 376 [I-D.ietf-detnet-architecture] 377 Finn, N., Thubert, P., Varga, B., and J. Farkas, 378 "Deterministic Networking Architecture", draft-ietf- 379 detnet-architecture-09 (work in progress), October 2018. 381 [I-D.ietf-detnet-dp-sol-ip] 382 Korhonen, J. and B. Varga, "DetNet IP Data Plane 383 Encapsulation", draft-ietf-detnet-dp-sol-ip-01 (work in 384 progress), October 2018. 386 [I-D.ietf-detnet-dp-sol-mpls] 387 Korhonen, J. and B. Varga, "DetNet MPLS Data Plane 388 Encapsulation", draft-ietf-detnet-dp-sol-mpls-01 (work in 389 progress), October 2018. 391 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 392 Requirement Levels", BCP 14, RFC 2119, 393 DOI 10.17487/RFC2119, March 1997, 394 . 396 [RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., 397 "MPLS Generic Associated Channel", RFC 5586, 398 DOI 10.17487/RFC5586, June 2009, 399 . 401 [RFC6423] Li, H., Martini, L., He, J., and F. Huang, "Using the 402 Generic Associated Channel Label for Pseudowire in the 403 MPLS Transport Profile (MPLS-TP)", RFC 6423, 404 DOI 10.17487/RFC6423, November 2011, 405 . 407 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 408 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 409 May 2017, . 411 9.2. Informational References 413 [RFC3985] Bryant, S., Ed. and P. Pate, Ed., "Pseudo Wire Emulation 414 Edge-to-Edge (PWE3) Architecture", RFC 3985, 415 DOI 10.17487/RFC3985, March 2005, 416 . 418 [RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, 419 "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for 420 Use over an MPLS PSN", RFC 4385, DOI 10.17487/RFC4385, 421 February 2006, . 423 [RFC4928] Swallow, G., Bryant, S., and L. Andersson, "Avoiding Equal 424 Cost Multipath Treatment in MPLS Networks", BCP 128, 425 RFC 4928, DOI 10.17487/RFC4928, June 2007, 426 . 428 [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay 429 Measurement for MPLS Networks", RFC 6374, 430 DOI 10.17487/RFC6374, September 2011, 431 . 433 [RFC7799] Morton, A., "Active and Passive Metrics and Methods (with 434 Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, 435 May 2016, . 437 [RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli, 438 L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, 439 "Alternate-Marking Method for Passive and Hybrid 440 Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321, 441 January 2018, . 443 Authors' Addresses 445 Greg Mirsky 446 ZTE Corp. 448 Email: gregimirsky@gmail.com 449 Mach(Guoyi) Chen 450 Huawei 452 Email: mach.chen@huawei.com