idnits 2.17.1 draft-lam-lime-summary-l0-l2-layer-independent-05.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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 25, 2016) is 2711 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 6424 (Obsoleted by RFC 8029) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 LIME Working Group K. Lam, Ed. 3 Internet-Draft E. Varma, Ed. 4 Intended status: Informational Nokia 5 Expires: April 28, 2017 S. Mansfield, Ed. 6 Ericsson 7 Y. Tochio, Ed. 8 Fujitsu 9 H. van Helvoort, Ed. 10 Hai Gaoming BV 11 M. Vissers, Ed. 12 Huawei 13 P. Doolan, Ed. 14 Coriant 15 October 25, 2016 17 Existing Support for Network Operations in Multilayer Transport Network 18 based upon unified approach to OAM (Layer 0 - Layer 2) 19 draft-lam-lime-summary-l0-l2-layer-independent-05 21 Abstract 23 This draft summarizes the existing ITU-T SG 15 standards, (Layer 0 - 24 Layer 2) both technology-specific and generic across these 25 technologies, relevant to leveraging OAM to support fault management, 26 performance monitoring, and configuration management. Knowledge from 27 this domain may be leveraged for the benefit of developing generic 28 layer independent management for other layers. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on April 28, 2017. 47 Copyright Notice 49 Copyright (c) 2016 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 66 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 3. Network Operation Supported by L0-L2 OAM . . . . . . . . . . 5 68 4. L0-L2 Architecture and Management Standards . . . . . . . . . 6 69 4.1. Generic Transport Layer and Technology Independent 70 Standards . . . . . . . . . . . . . . . . . . . . . . . . 6 71 4.1.1. Generic Transport Architecture . . . . . . . . . . . 6 72 4.1.2. Generic processing of transport equipment OAM 73 functions . . . . . . . . . . . . . . . . . . . . . . 7 74 4.1.3. Generic management requirements . . . . . . . . . . . 7 75 4.1.4. Generic information model of transport network 76 resources . . . . . . . . . . . . . . . . . . . . . . 8 77 4.2. Layer and Technology Specific Standards . . . . . . . . . 8 78 4.2.1. Architecture . . . . . . . . . . . . . . . . . . . . 8 79 4.2.2. Transport Equipment Functions . . . . . . . . . . . . 9 80 4.2.3. Transport management requirements . . . . . . . . . . 10 81 4.2.4. Management Information Models . . . . . . . . . . . . 11 82 5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 13 83 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 84 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 13 85 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 86 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 87 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 88 10.1. Normative References . . . . . . . . . . . . . . . . . . 14 89 10.2. Informative References . . . . . . . . . . . . . . . . . 18 90 Appendix A. Additional Stuff . . . . . . . . . . . . . . . . . . 19 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 93 1. Introduction 95 A comprehensive set of Operations, Administration, and Maintenance 96 (OAM) capabilities is essential for supporting the critical network 97 operations of fault management, performance monitoring, and 98 configuration management. For this reason in the ITU-T, Layer 0 - 99 Layer 2 technologies have been designed with extensive OAM 100 capabilities (e.g., as specified in [ITU-T_G.709], [ITU-T_G.707], 101 [ITU-T_G.8012], etc.) Considerable effort has been expended to 102 establish a coherent approach to OAM that allows monitoring of the 103 status and performance of (stacked) connections, including generic 104 layer independent principles and inter-layer interworking. Thus, the 105 OAM architecture used in transport networks has a common behavior 106 across all technologies and layer networks. This draft summarizes 107 ITU-T Recommendations that specify the generic architecture, 108 principles, and models, both technology specific and generic, 109 developed to support management of L0-L2 connections based upon a 110 unified and consistent OAM view of multi-layer networks. It should 111 be noted that the OAM and management framework and requirements for 112 MPLS-TP, which is L2.5, has also been based upon these principles 113 (e.g., RFC 6371 [RFC6371], RFC 5860 [RFC5860], RFC 5950 [RFC5950], 114 and RFC 5951 [RFC5951]. 116 It is believed that the generic architecture, principles and models 117 specified in the material summarized herein may be leveraged in 118 considerations of a common approach to OAM management for other layer 119 networks (e.g., Layer 3-Layer 7). 121 1.1. Requirements Language 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 125 document are to be interpreted as described in RFC 2119 [RFC2119]. 127 2. Terminology 129 Anomaly: The smallest discrepancy that can be observed between actual 130 and desired characteristics of an item. The occurrence of a single 131 anomaly does not constitute an interruption in ability to perform a 132 required function. Anomalies are used as the input for the 133 Performance Monitoring (PM) process and for detection of defects 134 (from [ITU-T_G.806], Section 3.7). 136 Defect: The density of anomalies has reached a level where the 137 ability to perform a required function has been interrupted. Defects 138 are used as input for performance monitoring, the control of 139 consequent actions, and the determination of fault cause (from 140 [ITU-T_G.806], Section 3.24). 142 Fault: A fault is the inability of a function to perform a required 143 action. This does not include an inability due to preventive 144 maintenance, lack of external resources, or planned actions (from 145 [ITU-T_G.806], Section 3.26). 147 Fault cause: A single disturbance or fault may lead to the detection 148 of multiple defects. A fault cause is the result of a correlation 149 process that is intended to identify the defect that is 150 representative of the disturbance or fault that is causing the 151 problem (from [ITU-T_G.806], Section 3.27). 153 Failure: The fault cause persisted long enough to consider the 154 ability of an item to perform a required function to be terminated. 155 The item may be considered as failed; a fault has now been detected 156 (from [ITU-T_G.806], Section 3.25). 158 Equipment Management Function (EMF): The management functions within 159 an NE (see [ITU-T_G.7710]). 161 Element Management System (EMS) 163 Information Model (IM): An information model condenses domain 164 knowledge and insights to provide a representation of its essential 165 concepts, structures, and interrelationships. It models managed 166 objects at a conceptual level, independent of any specific 167 implementations or protocols used to transport the data. 169 Layer 0 - Layer 2: Refers to physical (photonic), physical 170 (electrical), and data link (e.g., Ethernet) transport technology, 171 respectively. 173 Network Management System (NMS) 175 Network Element (NE) 177 Operations, Administration, and Maintenance (OAM) 179 o On-demand OAM - OAM actions that are initiated via manual 180 intervention for a limited time to carry out diagnostics. On- 181 demand OAM can result in singular or periodic OAM actions during 182 the diagnostic time interval. 184 o Proactive OAM - OAM actions that are carried on continuously to 185 permit timely reporting of fault and/or performance status. 187 3. Network Operation Supported by L0-L2 OAM 189 OAM mechanisms include the tools and utilities to plan, install, 190 monitor and troubleshoot a network layer. While the specific set of 191 OAM mechanisms in a layer depends upon the technology (e.g., 192 [ITU-T_G.709] on OTN, [ITU-T_G.707] on SDH, [ITU-T_G.8013] on 193 Ethernet), they all support the same fault management, performance 194 monitoring, and configuration management operations and processes. 195 As noted previously, MPLS-TP OAM (e.g., [ITU-T_G.8113.2], [RFC6424], 196 [RFC6428], etc.) was also designed to support L0-L2 operations and 197 processes. Some OAM functions are implemented in hardware (data 198 plane inherent, such as Tandem Connection Monitoring (TCM) or 199 Performance Monitoring (PM)), while other functions can be 200 implemented mostly in lower software layers. 202 Fault management includes defect detection, fault localization, fault 203 reporting, and protection switching [OTN Handbook, Chapter 3]. 205 o Defect detection: Failures affecting the transport of client 206 information are detected by continuous pro-active checking. 207 Persistent failures are considered to be service-affecting 208 defects. Detected defects are correlated with other detected 209 defects to find the most probable cause of the failure and 210 consequent actions, such as protection switching, are taken. 212 o Fault localization: If the defect information is insufficient to 213 locate the failure, on-demand OAM functions can be used to 214 determine the cause of the defect more accurately. 216 o Fault reporting: Persistent defects are reported to the network 217 management system to provide the appropriate alarm reports to 218 maintenance staff for maintaining the desired quality of service 219 level. 221 o Protection switching: After a defect has been detected, a 222 protection switch can be initiated as a consequent action to 223 restore the interrupted traffic, and thus improve the 224 availability. 226 Performance monitoring includes measuring the performance (e.g., 227 packet losses, bit errors, etc.) of the transport of client 228 information in order to verify the quality of service and to estimate 229 the transport integrity. 231 Configuration management includes indicating the operational state of 232 a connection; e.g., whether it can be used to transport client data 233 or whether the set-up of the connection is completed. 235 4. L0-L2 Architecture and Management Standards 237 Figure 1 below is a summary of relevant technology specific and 238 generic L0-L2 transport architecture and management standards. 240 +-------------------------------------------------+ 241 |Transport| Transport Technology Specific | 242 | Tech. |---------------------------------------+ 243 | Generic | OTN | Carrier | MPLS-TP | SDH | 244 | | | Ethernet | Note 2 | | 245 +------------------------------------------------------------------+ 246 | Transport | G.800 | G.872 | G.8010 | G.8110.1 | G.803 | 247 | Architecture | G.805 | | | | | 248 +------------------------------------------------------------------+ 249 | Operations | | | | | | 250 | Aministration | G.806 | G.709 | G.8013 | G.8113.x | G.707 | 251 | Maintenance | | | | series | | 252 +------------------------------------------------------------------+ 253 | Equipment | G.806 | G.798 | G.8021 | G.8121.x | G.783 | 254 | Function | | | | series | | 255 +------------------------------------------------------------------+ 256 | Management | G.7710 | G.874 | G.8051 | G.8151 | G.784 | 257 | Requirement | | | | | | 258 +------------------------------------------------------------------+ 259 | Mgmt Interface | | | | | G.774 | 260 |Protocol-neutral| G.7711 | G.874.1 | G.8052 | G.8152 | series| 261 | Info Model | | | | | Note 1| 262 +------------------------------------------------------------------+ 263 Note 1: The model had been specified, but not in a protocol neutral 264 manner. 265 Note 2: MPLS-TP is actually L2.5; it is included as it falls 266 under the generic transport management umbrella (as per design). 268 Figure 1: L0-L2 Architecture and Management Standards 270 4.1. Generic Transport Layer and Technology Independent Standards 272 4.1.1. Generic Transport Architecture 274 Recommendations [ITU-T_G.800] and [ITU-T_G.805] provide a technology 275 independent and model-based description of transport network 276 functionality. The first generic functional model based architecture 277 Recommendation was [ITU-T_G.805], which describes connection oriented 278 networks. [ITU-T_G.800] was subsequently developed to provide a 279 common framework to describe both connection-oriented and 280 connectionless networks. The descriptions are compatible with those 281 of the earlier generic Recommendations (e.g., [ITU-T_G.805]). These 282 standard model-based approaches: 284 o Enable the description of the generic characteristics of networks 285 using a common language at a level that transcends technology and 286 physical architecture choices. 288 o Provide a view of functions or entities that may be distributed 289 among various equipment. 291 o Concurrently specify transport and management functionality. 293 These generic functional architectures of transport networks are the 294 basis for a harmonized set of functional architecture Recommendations 295 for specific transport layer network technologies that use circuit 296 switching or packet switching technology (e.g. [ITU-T_G.803] for 297 SDH, [ITU-T_G.872] for OTN, [ITU-T_G.8010] for Carrier Ethernet, 298 [ITU-T_G.8110.1] for MPLS-TP). These transport technology specific 299 architecture Recommendations are used as the basis for a 300 corresponding set of Recommendations for equipment specifications, 301 including OAM and management. 303 4.1.2. Generic processing of transport equipment OAM functions 305 The development of the OAM architecture used by ITU-T in transport 306 networks started around 1990, and basic generic OAM functions were 307 first defined in the period 1990-1993 and described in Recommendation 308 [ITU-T_G.806]. Since that time, this initial OAM architecture has 309 been extended to assure it remains generic with respect to emerging 310 transport technologies. The extended OAM functionality included the 311 definition of a transport maintenance entity with end-points and 312 intermediate-points, pro-active and on-demand OAM functions, defect 313 correlation, and alarm suppression, etc. The generic OAM 314 architecture in [ITU-T_G.806] has been used as the common basis for 315 all technology-specific transport equipment specifications (e.g., 316 [ITU-T_G.783] for SDH, [ITU-T_G.798] for OTN, [ITU-T_G.8021] for 317 Carrier Ethernet, and also [ITU-T_G.8121] for MPLS-TP). 319 4.1.3. Generic management requirements 321 Recommendation [ITU-T_G.7710] specifies the equipment management 322 function (EMF) requirements that are common to multiple transport 323 technologies and common to packet-based and circuit-based transport 324 networks. The Recommendation addresses the EMF inside a transport 325 network element, including the configuration, fault, and performance 326 (i.e. the C, F, P of FCAPS) management functions. The generic 327 management requirements in [ITU-T_G.7710] have been used as the 328 common basis for all technology-specific transport management 329 specifications (e.g., [ITU-T_G.784] for SDH, [ITU-T_G.874] for OTN, 330 [ITU-T_G.8051] for Carrier Ethernet, and [ITU-T_G.8151] for MPLS-TP. 332 4.1.4. Generic information model of transport network resources 334 ITU-T Recommendation [ITU-T_G.7711] and [ONF_TR-512] of ONF Common 335 Information Model (ONF-CIM) [ONF_TR-513] specify a core information 336 model for transport resources. The model is also applicable to the 337 management and control of the transport network regardless of the 338 technology of the underlying transport network. Furthermore, the 339 applicability of the information model is independent of the choice 340 of protocol to be used in the management and control interfaces. The 341 core information model defined in this Recommendation can be used as 342 the basis for the extension of transport/control-technology-specific 343 information models. Such extension will be specified in the 344 technology-specific Recommendations, such as [ITU-T_G.774] series for 345 SDH, [ITU-T_G.874.1] for OTN management, [ITU-T_G.8052] for Carrier 346 Ethernet management, [ITU-T_G.8152] for MPLS-TP management, and 347 [ITU-T_G.7718.1] for ASON control plane management. 349 4.2. Layer and Technology Specific Standards 351 4.2.1. Architecture 353 Recommendations [ITU-T_G.803] and [ITU-T_G.872] describe respectively 354 the functionality of the SDH and optical transport networks (OTN), L0 355 and L1, from a network level perspective using the generic principles 356 defined in [ITU-T_G.805] and [ITU-T_G.800]. [ITU-T_G.803] and 357 [ITU-T_G.872] describe the specific aspects concerning the SDH and 358 optical transport network layered structure, characteristic 359 information, client/server layer associations, network topology, and 360 layer network functionality. In accordance with [ITU-T_G.805] and 361 [ITU-T_G.800], the optical transport network is decomposed into 362 independent transport layer networks where each layer network can be 363 separately partitioned in a way which reflects the internal structure 364 of that layer network. In addition to reflecting the generic fault, 365 configuration, and performance management requirements, it describes 366 requirements for connection supervision (e.g., continuity, 367 connectivity, required maintenance information), signal quality 368 supervision, adaptation management, etc.) and connection supervision 369 techniques (i.e., inherent, non-intrusive, intrusive, and sublayer 370 monitoring). 372 Recommendation [ITU-T_G.8010] describes the functional architecture 373 of L2 Ethernet networks using the modelling methodology described in 374 [ITU-T_G.800] and [ITU-T_G.805]. The Ethernet network functionality 375 is described from a network level viewpoint, taking into account an 376 Ethernet network layered structure, client characteristic 377 information, client/server layer associations, networking topology, 378 and layer network functionality providing Ethernet signal 379 transmission, multiplexing, routing, supervision, performance 380 assessment, and network survivability. Recommendation [ITU-T_G.8010] 381 describes the relevant parts of the Ethernet specifications in 382 [IEEE_802.1Q] and [IEEE_802.3] using the ITU-T transport network 383 modelling methodology. The ETH layer network provides the transport 384 of adapted information through an ETH connectionless trail between 385 ETH access points. The adapted information is a (non-) continuous 386 flow of MAC service data units ([IEEE_802.3]). 388 Recommendation [ITU-T_G.8110.1] provides functional components, based 389 on Recommendation [ITU-T_G.805], that allow the Multi Protocol Label 390 Switching Transport Profile (MPLS-TP) to be modeled in a way that is 391 consistent with the description of other transport technologies 392 defined by the ITU-T to simplify integration with other transport 393 technologies. It provides a representation of the MPLS-TP technology 394 using the methodologies that have been used for other transport 395 technologies (e.g., SDH, OTN and Ethernet). In [ITU-T_G.8110.1], the 396 architecture of MPLS-TP forwarding, OAM, and network survivability 397 are modeled from a network-level viewpoint. 399 4.2.2. Transport Equipment Functions 401 Recommendations [ITU-T_G.783] and [ITU-T_G.798] specify both the 402 components and the methodology that should be used in order to 403 specify the respective SDH and OTN functionality of network elements. 404 This Recommendations uses the specification methodology defined in 405 [ITU-T_G.806], in general for transport network equipment, and is 406 based on the architecture of SDH transport networks defined in 407 [ITU-T_G.783] and optical transport networks defined in [ITU-T_G.872] 408 and the interfaces for SDH transport networks defined in 409 [ITU-T_G.707] and optical transport networks defined in 410 [ITU-T_G.709]. The description is generic and no particular physical 411 partitioning of functions is implied. The input/output information 412 flows associated with the functional blocks serve for defining the 413 functions of the blocks and are considered to be conceptual, not 414 physical. They also provides processes for SDH OAM based on 415 [ITU-T_G.707] and OTN OAM based on [ITU-T_G.709]. The functionality 416 defined in this Recommendation can be applied at user-to-network 417 interfaces (UNIs) and network node interfaces (NNIs) of the optical 418 transport network. 420 Recommendation [ITU-T_G.8021] specifies both the functional 421 components and the methodology that should be used in order to 422 specify the Ethernet transport network functionality of network 423 elements. This Recommendation uses the specification methodology 424 defined in [ITU-T_G.806] in general for transport network equipment 425 and is based on the architecture of Ethernet layer networks defined 426 in [ITU-T_G.8010], the interfaces for Ethernet transport networks 427 defined in [ITU-T_G.8012], and in support of services defined in 428 [ITU-T_G.8011]. It also provides processes for Ethernet OAM based on 429 [ITU-T_G.8013]. The description is generic and no particular 430 physical partitioning of functions is implied. The input/output 431 information flows associated with the functional blocks serve to 432 define the functions of the blocks and are considered to be 433 conceptual, not physical. The functionality defined in this 434 Recommendation can be applied at user-to-network interfaces (UNIs) 435 and network-to-network interfaces (NNIs) of the Ethernet transport 436 network. 438 Recommendation [ITU-T_G.8121] specifies both the functional 439 components and the methodology that should be used in order to 440 specify the multi-protocol label switching transport profile (MPLS- 441 TP) layer network functionality of network elements. This 442 Recommendation provides a representation of MPLS-TP technology which 443 uses the methodologies that have been used for other transport 444 technologies (e.g., optical transport network (OTN) and Ethernet). 445 It also provides generic processes for MPLS-TP OAM. It specifies a 446 library of basic building blocks and a set of rules by which they may 447 be combined in order to describe digital transmission equipment. The 448 library comprises the functional building blocks needed to specify 449 completely the generic functional structure of the MPLS-TP layer 450 network. 452 4.2.3. Transport management requirements 454 Recommendation [ITU-T_G.874] addresses management aspects of L0 and 455 L1 optical transport network elements containing transport functions 456 of one or more layer networks of the optical transport network (OTN). 457 It is based on the architecture of optical transport networks defined 458 in [ITU-T_G.872], the interfaces for OTN networks defined in 459 [ITU-T_G.709], and the OTN equipment function description defined in 460 [ITU-T_G.798]. The management functions for fault management, 461 configuration management, and performance management are specified. 462 Generic requirements in [ITU-T_G.7710] that are applicable to OTN are 463 identified in [ITU-T_G.874] via pointer references to [ITU-T_G.7710]. 464 OTN-specific requirements explicitly specified include separation of 465 management communication network and signaling communication network, 466 OTN fault causes and failures, alarm reporting control (ARC) setting, 467 operational state, trail trace identifier configuration, adaptation 468 function configuration, connection function configuration, tandem 469 connection monitoring control function configuration, and the 470 management of the performance primitives. 472 Recommendation [ITU-T_G.8051] addresses management aspects of the L2 473 Ethernet Transport capable network element containing transport 474 functions of one or more of the layer networks of the Ethernet 475 transport network. The L2 Ethernet specific equipment functional 476 blocks are defined in [ITU-T_G.8021]. In this Recommendation, fault 477 management, configuration management, and performance management are 478 specified. Generic requirements in [ITU-T_G.7710] that are 479 applicable to Ethernet are identified in [ITU-T_G.8051] via pointer 480 references to [ITU-T_G.7710]. Ethernet-specific requirements 481 explicitly specified include the management communication channel, 482 fault causes and failures, alarm reporting control setting, 483 operational state, flow termination function configuration, 484 adaptation function configuration, connection function configuration, 485 diagnostic function configuration, traffic conditioning and shaping 486 function configuration, performance monitoring requirements, and the 487 management of the performance primitives. 489 Recommendation [ITU-T_G.8151] addresses management aspects of the 490 MPLS Transport Profile (MPLS-TP) capable network element, which is 491 separable from that of its client layer networks so that the same 492 means of management can be used regardless of the client. In this 493 Recommendation, fault management, configuration management, and 494 performance management are specified. The generic requirements for 495 managing transport network elements are specified in [ITU-T_G.7710] 496 and the requirements for the management of equipment used in networks 497 supporting an MPLS Transport Profile (MPLS-TP) are specified in [IETF 498 RFC 5951]. This Recommendation specifies the requirements for 499 managing the MPLS-TP specific equipment functional blocks, which are 500 defined in [ITU-T_G.8121]. 502 4.2.4. Management Information Models 504 Recommendation [ITU-T_G.874.1] provides a management-protocol-neutral 505 information model for managing network elements in the L0 and L1 506 optical transport network (OTN) [ITU-T_G.872], [ITU-T_G.709], and 507 [ITU-T_G.798] and supporting the management requirements specified in 508 [ITU-T_G.7710] and [ITU-T_G.874]. It identifies the managed entities 509 required for the management of OTN network elements, including 510 Termination Points (TP), Tandem Connection Monitoring (TCM), Non- 511 Intrusive Monitoring (NIM), Delay Measurement (DM), and the general 512 Performance Monitoring (PM) Current Data (CD) and History Data (HD). 513 These entities are relevant to information exchanged across 514 standardized management interfaces. The management-protocol-neutral 515 information model should be used as the base for defining management- 516 protocol-specific data schema. The specific mapping of the 517 management-protocol-neutral information model into management- 518 protocol-specific data schema is the decision of the management- 519 protocol-specific solution designer. The information model specified 520 in this Recommendation allows for managing the OTN functional 521 capabilities of the NE. 523 Recommendation [ITU-T_G.8052] provides a management-protocol-neutral 524 information model for managing network elements in the L2 Ethernet 525 transport network [ITU-T_G.8010], [ITU-T_G.8012], and [ITU-T_G.8021] 526 and supporting the management requirements specified in 527 [ITU-T_G.7710] and [ITU-T_G.8051]. It identifies the managed 528 entities required for the management of Ethernet transport network 529 elements, including Termination Points (TP), Maintenance Entity Group 530 (MEG) End Point (MEP), MEG Intermediate Point (MIP), Traffic 531 Conditioning and Shaping (TCS), Loss Measurement (LM), Delay 532 Measurement (DM), and the general Performance Monitoring (PM) Current 533 Data (CD) and History Data (HD). These entities are relevant to 534 information exchanged across standardized management interfaces. The 535 management-protocol-neutral information model should be used as the 536 base for defining management-protocol-specific data schema. The 537 specific mapping of the management-protocol-neutral information model 538 into management-protocol-specific data schema is the decision of the 539 management-protocol-specific solution design. The information model 540 specified in this Recommendation allows for managing the Ethernet 541 functional capabilities of the NE. 543 It should also be noted that [MEF_7.2] specifies the EMS-NMS 544 interface profile needed to support Metro Ethernet services, which 545 provides the profile of management entities based on [ITU-T_Q.840.1] 546 and [ITU-T_G.8052] and a mapping to the TMF's MTNM 3.5[TMF_MTNM] 547 Ethernet model. Work is in progress on [MEF_7.3], which describes 548 the Carrier Ethernet Service Management Information Model for the 549 management of MEF Carrier Ethernet services, including EVC and OVC as 550 customer facing services. There are additionally other protocol- 551 neutral MEF information modeling activities underway (e.g., MEF 552 Network Resource Management Information Model to specify mapping from 553 the [MEF_7.3] Service Model to a Network Resource Model based upon 554 [ONF_TR-512] and [ITU-T_G.8052]. 556 Recommendation [ITU-T_G.8152] provides a management-protocol-neutral 557 information model for managing network elements in the L2 MPLS-TP 558 network [ITU-T_G.8110.1], [ITU-T_G.8112], and [ITU-T_G.8121] series 559 and supporting the management requirements specified in 560 [ITU-T_G.7710] and [ITU-T_G.8151]. It identifies the managed 561 entities required for the management of MPLS-TP network elements, 562 including Termination Points (TP), Maintenance Entity Group (MEG) End 563 Point (MEP), MEG Intermediate Point (MIP), Loss Measurement (LM), 564 Delay Measurement (DM), and the general Performance Monitoring (PM) 565 Current Data (CD) and History Data (HD). These entities are relevant 566 to information exchanged across standardized management interfaces. 567 The management-protocol-neutral information model should be used as 568 the base for defining management-protocol-specific data schema. The 569 specific mapping of the management-protocol-neutral information model 570 into management-protocol-specific data schema is the decision of the 571 management-protocol-specific solution design. The information model 572 specified in this Recommendation allows for managing the MPLS-TP 573 functional capabilities of the NE. 575 5. Discussion 577 This draft has provided an introduction to the significant body of 578 specifications developed in ITU-T that detail the generic 579 architectural principles for OAM in (multi layer) transport networks. 580 It also provides an introduction to the specifications that apply 581 those general principles in a consistent way to various layered 582 transport network technologies. It is anticipated that the generic 583 and layer specific OAM architecture and management specifications 584 described in this draft will prove valuable in considerations of 585 generic unified approaches to OAM and management for additional 586 multilayer networks. 588 6. Acknowledgements 590 7. Contributors 592 8. IANA Considerations 594 This memo includes no request to IANA. 596 9. Security Considerations 598 This informational document is solely intended to provide a summary 599 of the existing ITU-T SG 15 standards, (Layer 0 - Layer 2) both 600 technology-specific and generic across these technologies, relevant 601 to leveraging OAM to support fault management, performance 602 monitoring, and configuration management. No security threat is 603 introduced by this informational document. 605 10. References 606 10.1. Normative References 608 [IEEE_802.1Q] 609 IEEE, "Media Access Control (MAC) Bridges and Virtual 610 Bridged Local Area Networks, IEEE Std 802.1Q-2014", 2014. 612 [IEEE_802.3] 613 IEEE, "Carrier sense multiple access with collision 614 detection (CSMA/CD) access method and physical layer 615 specifications, IEEE Std 802.3-2015", 2015. 617 [ITU-T_G.707] 618 ITU-T, "ITU-T G.707/Y.1322 - Network node interface for 619 the synchronous digital hierarchy (SDH), 01/2007, Amd.1 620 07/2007, Amd. 2 11/2009", 2007, 621 . 623 [ITU-T_G.709] 624 ITU-T, "ITU-T G.709/Y.1331 - Interfaces for the optical 625 transport network (OTN), 06/2016", 2016, 626 . 628 [ITU-T_G.7710] 629 ITU-T, "ITU-T G.7710/Y.1701 - Common Equipment Management 630 Function Requirements; 02/2012", 2012, 631 . 633 [ITU-T_G.7711] 634 ITU-T, "ITU-T G.7711/Y.1702, Generic protocol-neutral 635 management Information Model for transport network 636 resources; 09/2016", 2016. 638 [ITU-T_G.7718.1] 639 ITU-T, "ITU-T G.7718.1/Y.1709.1 - Protocol-neutral 640 management information model for the control plane view; 641 12/2006", 2006, 642 . 644 [ITU-T_G.774] 645 ITU-T, "ITU-T G.774 - Synchronous digital hierarchy (SDH) 646 - Management information model for the network element 647 view ; 02/2001", 2001, 648 . 650 [ITU-T_G.783] 651 ITU-T, "ITU-T G.783 - Characteristics of Synchronous 652 Digital Hierarchy (SDH) equipment functional blocks; 653 03/2006", 2006, . 655 [ITU-T_G.784] 656 ITU-T, "ITU-T G.784 - Management aspects of synchronous 657 digital hierarchy (SDH) transport network elements ; 658 03/2008", 2008, . 660 [ITU-T_G.798] 661 ITU-T, "ITU-T G.798 - Characteristics of optical transport 662 network hierarchy equipment functional blocks; 12/2012", 663 2012, . 665 [ITU-T_G.800] 666 ITU-T, "ITU-T G.800 - Unified Model; 04/2016", 2016, 667 . 669 [ITU-T_G.8010] 670 ITU-T, "ITU-T G.8010/Y.1306 - Architecture of Ethernet 671 Layer Networks; 02/2004", 2004, 672 . 674 [ITU-T_G.8011] 675 ITU-T, "ITU-T G.8011/Y.1307 - Ethernet service 676 characteristics; 01/2015", 2015, 677 . 679 [ITU-T_G.8012] 680 ITU-T, "ITU-T G.8010/Y.1308 - Ethernet UNI and Ethernet 681 NNI; 08/2004", 2004, 682 . 684 [ITU-T_G.8013] 685 ITU-T, "ITU-T G.8013/Y.1731 - OAM functions and mechanisms 686 for Ethernet based networks; 8/2015", 2015, 687 . 689 [ITU-T_G.8021] 690 ITU-T, "ITU-T G.8021/Y.1341 - Characteristics of Ethernet 691 transport network equipment functional blocks; 09/2016", 692 2016, . 694 [ITU-T_G.803] 695 ITU-T, "ITU-T G.803 - Architecture of Transport Networks 696 based on the Synchronous Digital Hierarchy (SDH); 697 03/2000", 2000, . 699 [ITU-T_G.805] 700 ITU-T, "ITU-T G.805 - Generic functional architecture of 701 transport networks; 10/2000", 2000, 702 . 704 [ITU-T_G.8051] 705 ITU-T, "ITU-T G.8051/Y.1345 - Management aspects of the 706 Ethernet - over - Transport (EoT) capable network element; 707 08/2015", 2015, . 709 [ITU-T_G.8052] 710 ITU-T, "ITU-T G.8052/Y.1346 - Protocol-neutral management 711 information model for the Ethernet transport capable 712 network element; 09/2016", 2016, 713 . 715 [ITU-T_G.806] 716 ITU-T, "ITU-T G.806 - Characteristics of Transport 717 Equipment - Description Methodology and Generic 718 Functionality, 02/2012", 2012, 719 . 721 [ITU-T_G.8110.1] 722 ITU-T, "ITU-T G.8110.1/Y.1370.1 - Architecture of MPLS 723 Transport Profile (MPLS-TP) layer network; 12/2011", 2011, 724 . 726 [ITU-T_G.8112] 727 ITU-T, "ITU-T G.8110.1/Y.1371 - Interfaces for the MPLS 728 Transport Profile layer network ; 8/2015", 2015, 729 . 731 [ITU-T_G.8113.2] 732 ITU-T, "ITU-T G.8113.2/Y.1372.2 - Operations, 733 administration and maintenance mechanisms for MPLS-TP 734 networks using the tools defined for MPLS; 8/2015", 2015, 735 . 737 [ITU-T_G.8121] 738 ITU-T, "ITU-T G.8121/Y.1371 - Characteristics of MPLS-TP 739 equipment functional blocks; 4/2016", 2016, 740 . 742 [ITU-T_G.8151] 743 ITU-T, "ITU-T G.8151/Y.1374 - Management aspects of the 744 MPLS-TP network element; 01/2015", 2015, 745 . 747 [ITU-T_G.8152] 748 ITU-T, "ITU-T G.8152/Y.1375 - Protocol-neutral management 749 information model for the MPLS-TP network element; 750 09/2016", 2016. 752 [ITU-T_G.872] 753 ITU-T, "ITU-T G.872 - Architecture of optical transport 754 networks; 9/2016", 2016, 755 . 757 [ITU-T_G.874] 758 ITU-T, "ITU-T G.874 - Management aspects of the optical 759 transport network element; 08/2013", 2013, 760 . 762 [ITU-T_G.874.1] 763 ITU-T, "ITU-T G.874.1 - Optical transport network (OTN) 764 protocol-neutral management information model for the 765 network element view; 9/2016", 2016, 766 . 768 [ITU-T_Q.840.1] 769 ITU-T, "ITU-T Q.840.1 - Requirements and analysis for NMS- 770 EMS management interface of Ethernet over Transport and 771 Metro Ethernet Network (EoT/MEN)", 2007, 772 . 774 [MEF_7.2] MEF, "Carrier Ethernet Information Model", 2013, . 778 [MEF_7.3] MEF, "Carrier Ethernet Management Information Model (Draft 779 in Process)", 201x. 781 [ONF_TR-512] 782 ONF, "TR-512 Core Information Model 1.2", 2016, 783 . 787 [ONF_TR-513] 788 ONF, "TR-513 Common Information Model Overview 1.2", 2016, 789 . 793 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 794 Requirement Levels", BCP 14, RFC 2119, 795 DOI 10.17487/RFC2119, March 1997, 796 . 798 [RFC5860] Vigoureux, M., Ed., Ward, D., Ed., and M. Betts, Ed., 799 "Requirements for Operations, Administration, and 800 Maintenance (OAM) in MPLS Transport Networks", RFC 5860, 801 DOI 10.17487/RFC5860, May 2010, 802 . 804 [RFC5950] Mansfield, S., Ed., Gray, E., Ed., and K. Lam, Ed., 805 "Network Management Framework for MPLS-based Transport 806 Networks", RFC 5950, DOI 10.17487/RFC5950, September 2010, 807 . 809 [RFC5951] Lam, K., Mansfield, S., and E. Gray, "Network Management 810 Requirements for MPLS-based Transport Networks", RFC 5951, 811 DOI 10.17487/RFC5951, September 2010, 812 . 814 [RFC6371] Busi, I., Ed. and D. Allan, Ed., "Operations, 815 Administration, and Maintenance Framework for MPLS-Based 816 Transport Networks", RFC 6371, DOI 10.17487/RFC6371, 817 September 2011, . 819 [RFC6424] Bahadur, N., Kompella, K., and G. Swallow, "Mechanism for 820 Performing Label Switched Path Ping (LSP Ping) over MPLS 821 Tunnels", RFC 6424, DOI 10.17487/RFC6424, November 2011, 822 . 824 [RFC6428] Allan, D., Ed., Swallow, G., Ed., and J. Drake, Ed., 825 "Proactive Connectivity Verification, Continuity Check, 826 and Remote Defect Indication for the MPLS Transport 827 Profile", RFC 6428, DOI 10.17487/RFC6428, November 2011, 828 . 830 [TMF_MTNM] 831 TM Forum, "TM Forum Multi Technology Network Management, 832 Release 3.5", 2009, 833 . 836 10.2. Informative References 838 [OTN_Handbook] 839 ITU-T, "ITU-T OTN Handbook - Optical Transport Networks 840 from TDM to Packet, ITU-T Manual 2010", 2010. 842 Appendix A. Additional Stuff 844 TBD 846 Authors' Addresses 848 Kam Lam (editor) 849 Nokia 850 USA 852 Phone: +1 732 331 3476 853 Email: kam.lam@nokia.com 855 Eve Varma (editor) 856 Nokia 857 USA 859 Email: eve.varma@nokia.com 861 Scott Mansfield (editor) 862 Ericsson 863 USA 865 Phone: +1 724 931 9316 866 Email: scott.mansfield@ericsson.com 868 Yuji Tochio (editor) 869 Fujitsu 870 Japan 872 Email: tochio@jp.fujitsu.com 874 Huub van Helvoort (editor) 875 Hai Gaoming BV 876 The Netherlands 878 Phone: +31 924 8936 879 Email: huubatwork@gmail.com 880 Maarten Vissers (editor) 881 Huawei 882 China 884 Phone: +31 62 611 2004 885 Email: maarten.vissers@huawei.com 887 Paul Doolan (editor) 888 Coriant 889 Germany 891 Phone: +1 972 357 5822 892 Email: paul.doolan@coriant.com