idnits 2.17.1 draft-mirsky-detnet-oam-01.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 (September 25, 2018) is 2033 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-08 == Outdated reference: A later version (-02) exists of draft-ietf-detnet-dp-sol-ip-00 == Outdated reference: A later version (-02) exists of draft-ietf-detnet-dp-sol-mpls-00 -- 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: March 29, 2019 Huawei 6 September 25, 2018 8 Operations, Administration and Maintenance (OAM) for Deterministic 9 Networks (DetNet) 10 draft-mirsky-detnet-oam-01 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 March 29, 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 . . . . . . . . . . . . . . . . . . 7 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 . . . . . . . . . . . . . . . . . . . . . 8 66 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 67 8. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 8 68 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 70 9.2. Informational References . . . . . . . . . . . . . . . . 9 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 to for gap analysis of 89 available OAM tools to identify possible enhancements of existing or 90 whether new OAM tools are required to support proactive and on-demand 91 path 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 with 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 and 200 Elimination sub-functions locations in the domain. 202 17. DetNet OAM MUST support testing of Packet Replication and 203 Elimination sub-functions in the domain. 205 4. DetNet Data Plane in Support of Active OAM 207 OAM protocols and mechanisms act within the data plane of the 208 particular networking layer. And thus it is critical that the data 209 plane encapsulation supports OAM mechanisms in such a way to comply 210 with the above-listed requirements. One of such examples that 211 require special consideration is requirement #5: 213 DetNet OAM packets MUST be in-band, i.e., follow precisely the 214 same path as DetNet data plane traffic both for unidirectional and 215 bi-directional DetNet paths. 217 4.1. MPLS Encapsulation 219 The Det Net data plane encapsulation in transport network with MPLS 220 and IP encapsulations specified in [I-D.ietf-detnet-dp-sol-mpls] and 221 [I-D.ietf-detnet-dp-sol-ip] respectively. For the MPLS underlay 222 network, DetNet flows to be encapsulated analogous to pseudowires 223 (PW) over MPLS packet switched network, as described in [RFC3985], 224 [RFC4385]. Generic PW MPLS Control Word (CW), defined in [RFC4385], 225 for DetNet displayed in Figure 1. 227 0 1 2 3 228 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 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 |0 0 0 0| Sequence Number | 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 Figure 1: DetNet Control Word Format 235 PREF in the DetNet domain composed by a combination of nodes that 236 perform replication and elimination sub-functions. The elimination 237 sub-function always uses the S-Label and packet sequencing 238 information, e.g., the value in the Sequence Number field of DetNet 239 CW (d-CW). The replication sub-function uses the S-Label information 240 only. For data packets Figure 2 presents an example of PREF in 241 DetNet domain. 243 1111 11111111 111111 112212 112212 132213 244 CE1----EN1--------R1-------R2-------R3--------EN2----CE2 245 \2 22222/ 3 / 246 \2222222 /----+ 3 / 247 +------R4------------------------+ 248 333333333333333333333333 250 Figure 2: DetNet Data Plane Based on PW 252 4.1.1. DetNet Active OAM Encapsulation 254 DetNet OAM, like PW OAM, uses PW Associated Channel Header defined in 255 [RFC4385]. Figure 3 displays the encapsulation of a DetNet active 256 OAM packet. 258 +---------------------------------+ 259 | | 260 | DetNet Flow | 261 | OAM Packet | 262 | | 263 +---------------------------------+ <--\ 264 | DetNet Associated Channel Header| | 265 +=================================+ +--> DetNet OAM data plane 266 | S-Label | | MPLS encapsulation 267 +---------------------------------+ <--/ 268 | T-Label(s) | 269 +---------------------------------+ 270 | Data-Link | 271 +---------------------------------+ 272 | Physical | 273 +---------------------------------+ 275 Figure 3: DetNet active OAM Packet Encapsulation 277 0 1 2 3 278 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 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 |0 0 0 1|Version|Sequence Number| Channel Type | 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 Figure 4: DetNet Associated Channel Header Format 285 Figure 4 displays the format of the DetNet Associated Channel Header 286 (d-ACH). The meanings of the fields in the d-ACH are: 288 Bits 0..3 MUST be 0b0001. This value of the first nibble allows 289 the packet to be distinguished from an IP packet [RFC4928] and a 290 DetNet data packet [I-D.ietf-detnet-dp-sol-mpls]. 292 Version: this is the version number of the d-ACH. This 293 specification defines version 0. 295 Sequence Number: this is unsigned eight bits-long field. The 296 originating DetNet node MUST set the value of the Sequence Number 297 field to a non-zero before packet being transmitted. The 298 originating node MUST monotonically increase the value of the 299 Sequence Number field for the every next active OAM packet. 301 Channel Type: the value of DetNet Associated Channel Type is one 302 of values defined in the IANA PW Associated Channel Type registry. 304 The DetNet flow, according to [I-D.ietf-detnet-dp-sol-mpls], is 305 identified by the S-label that MUST be at the bottom of the stack. 306 Active OAM packet MUST have d-ACH immediately following the S-label.A 307 DetNet node originating an OAM packet MUST ensure that the value of 308 the Sequence Number field in d-ACH is monotonically increasing for 309 the given value of the Channel Type field. 311 The Generic Associated Channel Label (GAL), defined in [RFC5586] and 312 [RFC6423], provides a generalized label-based exception mechanism to 313 indicate that the packet is on a Generic Associated Channel (G-ACh) 314 and that ACH immediately follows the label stack. For the DetNet 315 domain in MPLS transport network, GAL MAY be used. If GAL is used, 316 it MUST precede S-Label on the label stack, and the S-Label MUST be 317 followed by d-ACH. 319 4.1.2. IP Encapsulation 321 [Author's Note: This will be defined based on the DetNet Flow ID 322 specification for IP underlay in [I-D.ietf-detnet-dp-sol-ip].] 324 4.2. DetNet Replication, Elimination, and Ordering Sub-functions 325 Interaction with Active OAM 327 At the DetNet service layer, special functions MAY be applied to the 328 particular DetNet flow - PREF to potentially lower packet loss, 329 improve the probability of on-time packet delivery and Packet 330 Ordering Function (POF) to ensure in-order packet delivery. As data 331 and the active OAM packets have the same Flow ID, S-label, sub- 332 functions that rely on sequencing information in the DetNet service 333 layer MUST process 28 MSBs of the d-ACH as the source of the 334 sequencing information for the OAM packet. 336 5. Use of Hybrid OAM in DetNet 338 Hybrid OAM methods are used in performance monitoring and defined in 339 [RFC7799] as: 341 Hybrid Methods are Methods of Measurement that use a combination 342 of Active Methods and Passive Methods. 344 A hybrid measurement method may produce metrics as close to passive, 345 but it still alters something in a data packet even if that is the 346 value of a designated field in the packet encapsulation. One example 347 of such hybrid measurement method is the Alternate Marking method 348 described in [RFC8321]. Reserving the field for the Alternate 349 Marking method in the DetNet Header will enhance available to an 350 operator set of DetNet OAM tools. 352 6. IANA Considerations 354 TBA 356 7. Security Considerations 358 This document lists the OAM requirements for a DetNet domain and does 359 not raise any security concerns or issues in addition to ones common 360 to networking. 362 8. Acknowledgment 364 TBD 366 9. References 367 9.1. Normative References 369 [I-D.ietf-detnet-architecture] 370 Finn, N., Thubert, P., Varga, B., and J. Farkas, 371 "Deterministic Networking Architecture", draft-ietf- 372 detnet-architecture-08 (work in progress), September 2018. 374 [I-D.ietf-detnet-dp-sol-ip] 375 Korhonen, J. and B. Varga, "DetNet IP Data Plane 376 Encapsulation", draft-ietf-detnet-dp-sol-ip-00 (work in 377 progress), July 2018. 379 [I-D.ietf-detnet-dp-sol-mpls] 380 Korhonen, J. and B. Varga, "DetNet MPLS Data Plane 381 Encapsulation", draft-ietf-detnet-dp-sol-mpls-00 (work in 382 progress), July 2018. 384 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 385 Requirement Levels", BCP 14, RFC 2119, 386 DOI 10.17487/RFC2119, March 1997, 387 . 389 [RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., 390 "MPLS Generic Associated Channel", RFC 5586, 391 DOI 10.17487/RFC5586, June 2009, 392 . 394 [RFC6423] Li, H., Martini, L., He, J., and F. Huang, "Using the 395 Generic Associated Channel Label for Pseudowire in the 396 MPLS Transport Profile (MPLS-TP)", RFC 6423, 397 DOI 10.17487/RFC6423, November 2011, 398 . 400 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 401 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 402 May 2017, . 404 9.2. Informational References 406 [RFC3985] Bryant, S., Ed. and P. Pate, Ed., "Pseudo Wire Emulation 407 Edge-to-Edge (PWE3) Architecture", RFC 3985, 408 DOI 10.17487/RFC3985, March 2005, 409 . 411 [RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, 412 "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for 413 Use over an MPLS PSN", RFC 4385, DOI 10.17487/RFC4385, 414 February 2006, . 416 [RFC4928] Swallow, G., Bryant, S., and L. Andersson, "Avoiding Equal 417 Cost Multipath Treatment in MPLS Networks", BCP 128, 418 RFC 4928, DOI 10.17487/RFC4928, June 2007, 419 . 421 [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay 422 Measurement for MPLS Networks", RFC 6374, 423 DOI 10.17487/RFC6374, September 2011, 424 . 426 [RFC7799] Morton, A., "Active and Passive Metrics and Methods (with 427 Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, 428 May 2016, . 430 [RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli, 431 L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, 432 "Alternate-Marking Method for Passive and Hybrid 433 Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321, 434 January 2018, . 436 Authors' Addresses 438 Greg Mirsky 439 ZTE Corp. 441 Email: gregimirsky@gmail.com 443 Mach(Guoyi) Chen 444 Huawei 446 Email: mach.chen@huawei.com