idnits 2.17.1 draft-lam-lime-summary-l0-l2-layer-independent-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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (April 27, 2015) is 3287 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 Alcatel-Lucent 5 Expires: October 29, 2015 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 April 27, 2015 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-02 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 October 29, 2015. 47 Copyright Notice 49 Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . 13 89 10.2. Informative References . . . . . . . . . . . . . . . . . 18 90 Appendix A. Additional Stuff . . . . . . . . . . . . . . . . . . 18 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 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 | Equipment | G.806 | G.798 | G.8021 | G.8121.x | G.783 | 250 | Function | | | | series | | 251 +------------------------------------------------------------------+ 252 | Management | G.7710 | G.874 | G.8051 | G.8151 | G.784 | 253 | Requirement | | | | | | 254 +------------------------------------------------------------------+ 255 | Mgmt Interface | | | | | G.774 | 256 |Protocol-neutral| G.gim | G.874.1 | G.8052 | G.8152 | series| 257 | Info Model | | | | | Note 1| 258 +------------------------------------------------------------------+ 259 Note 1: The model had been specified, but not in a protocol neutral 260 manner. 261 Note 2: MPLS-TP is actually L2.5; it is included as it falls 262 under the generic transport management umbrella (as per design). 264 Figure 1: L0-L2 Architecture and Management Standards 266 4.1. Generic Transport Layer and Technology Independent Standards 268 4.1.1. Generic Transport Architecture 270 Recommendations [ITU-T_G.800] and [ITU-T_G.805] provide a technology 271 independent and model-based description of transport network 272 functionality. The first generic functional model based architecture 273 Recommendation was ITU-T G.805, which describes connection oriented 274 networks. ITU-T G.800 was subsequently developed to provide a common 275 framework to describe both connection-oriented and connectionless 276 networks. The descriptions are compatible with those of the earlier 277 generic Recommendations (e.g., ITU-T G.805). These standard model- 278 based approaches: 280 o Enable the description of the generic characteristics of networks 281 using a common language at a level that transcends technology and 282 physical architecture choices. 284 o Provide a view of functions or entities that may be distributed 285 among various equipment. 287 o Concurrently specify transport and management functionality. 289 These generic functional architectures of transport networks are the 290 basis for a harmonized set of functional architecture Recommendations 291 for specific transport layer network technologies that use circuit 292 switching or packet switching technology (e.g. [ITU-T_G.803] for 293 SDH, [ITU-T_G.872] for OTN, [ITU-T_G.8010] for Carrier Ethernet, 294 [ITU-T_G.8110.1] for MPLS-TP). These transport technology specific 295 architecture Recommendations are used as the basis for a 296 corresponding set of Recommendations for equipment specifications, 297 including OAM and management. 299 4.1.2. Generic processing of transport equipment OAM functions 301 The development of the OAM architecture used by ITU-T in transport 302 networks started around 1990, and basic generic OAM functions were 303 first defined in the period 1990-1993 and described in Recommendation 304 [ITU-T_G.806]. Since that time, this initial OAM architecture has 305 been extended to assure it remains generic with respect to emerging 306 transport technologies. The extended OAM functionality included the 307 definition of a transport maintenance entity with end-points and 308 intermediate-points, pro-active and on-demand OAM functions, defect 309 correlation, and alarm suppression, etc. The generic OAM 310 architecture in ITU-T G.806 has been used as the common basis for all 311 technology-specific transport equipment specifications (e.g., 312 [ITU-T_G.783] for SDH, [ITU-T_G.798] for OTN, [ITU-T_G.8021] for 313 Carrier Ethernet, and also [ITU-T_G.8121] for MPLS-TP). 315 4.1.3. Generic management requirements 317 Recommendation [ITU-T_G.7710] specifies the equipment management 318 function (EMF) requirements that are common to multiple transport 319 technologies and common to packet-based and circuit-based transport 320 networks. The Recommendation addresses the EMF inside a transport 321 network element, including the configuration, fault, and performance 322 (i.e. the C, F, P of FCAPS) management functions. The generic 323 management requirements in ITU-T G.7710 have been used as the common 324 basis for all technology-specific transport management specifications 325 (e.g., [ITU-T_G.784] for SDH, [ITU-T_G.874] for OTN, [ITU-T_G.8051] 326 for Carrier Ethernet, and [ITU-T_G.8151] for MPLS-TP. 328 4.1.4. Generic information model of transport network resources 330 ITU-T Recommendation [ITU-T_G.gim] and ONF Common Information Model 331 (ONF-CIM) (see [ONF_Liaison]) specify a core information model 332 [I-D.lam-topology] for transport resources. The model is also 333 applicable to the management and control of the transport network 334 regardless of the technology of the underlying transport network. 335 Furthermore, the applicability of the information model is 336 independent of the choice of protocol to be used in the management 337 and control interfaces. The core information model defined in this 338 Recommendation can be used as the basis for the extension of 339 transport/control-technology-specific information models. Such 340 extension will be specified in the technology-specific 341 Recommendations, such as [ITU-T_G.774] series for SDH, 342 [ITU-T_G.874.1] for OTN management, [ITU-T_G.8052] for Carrier 343 Ethernet management, [ITU-T_G.8152] for MPLS-TP management, and 344 [ITU-T_G.7718.1] for ASON control plane management. 346 4.2. Layer and Technology Specific Standards 348 4.2.1. Architecture 350 Recommendations [ITU-T_G.803] and [ITU-T_G.872] describe respectively 351 the functionality of the SDH and optical transport networks (OTN), L0 352 and L1, from a network level perspective using the generic principles 353 defined in ITU-T G.805 and ITU-T G.800. ITU-T G.803 and ITU-T G.872 354 describe the specific aspects concerning the SDH and optical 355 transport network layered structure, characteristic information, 356 client/server layer associations, network topology, and layer network 357 functionality. In accordance with ITU-T G.805 and ITU-T G.800, the 358 optical transport network is decomposed into independent transport 359 layer networks where each layer network can be separately partitioned 360 in a way which reflects the internal structure of that layer network. 361 In addition to reflecting the generic fault, configuration, and 362 performance management requirements, it describes requirements for 363 connection supervision (e.g., continuity, connectivity, required 364 maintenance information), signal quality supervision, adaptation 365 management, etc.) and connection supervision techniques (i.e., 366 inherent, non-intrusive, intrusive, and sublayer monitoring). 368 Recommendation [ITU-T_G.8010] describes the functional architecture 369 of L2 Ethernet networks using the modelling methodology described in 370 ITU-T G.800 and ITU-T G.805. The Ethernet network functionality is 371 described from a network level viewpoint, taking into account an 372 Ethernet network layered structure, client characteristic 373 information, client/server layer associations, networking topology, 374 and layer network functionality providing Ethernet signal 375 transmission, multiplexing, routing, supervision, performance 376 assessment, and network survivability. Recommendation ITU-T G.8010/ 377 Y.1306 describes the relevant parts of the Ethernet specifications in 378 [IEEE_802.1Q] and [IEEE_802.3] using the ITU-T transport network 379 modelling methodology. The ETH layer network provides the transport 380 of adapted information through an ETH connectionless trail between 381 ETH access points. The adapted information is a (non-) continuous 382 flow of MAC service data units (IEEE 802.3). 384 Recommendation [ITU-T_G.8110.1] provides functional components, based 385 on Recommendation ITU T G.805, that allow the Multi Protocol Label 386 Switching Transport Profile (MPLS-TP) to be modeled in a way that is 387 consistent with the description of other transport technologies 388 defined by the ITU-T to simplify integration with other transport 389 technologies. It provides a representation of the MPLS-TP technology 390 using the methodologies that have been used for other transport 391 technologies (e.g., SDH, OTN and Ethernet). In G.8110.1, the 392 architecture of MPLS-TP forwarding, OAM, and network survivability 393 are modeled from a network-level viewpoint. 395 4.2.2. Transport Equipment Functions 397 Recommendations [ITU-T_G.783] and [ITU-T_G.798] specify both the 398 components and the methodology that should be used in order to 399 specify the respective SDH and OTN functionality of network elements. 400 This Recommendations uses the specification methodology defined in 401 [ITU-T_G.806], in general for transport network equipment, and is 402 based on the architecture of SDH transport networks defined in 403 [ITU-T_G.783] and optical transport networks defined in [ITU-T_G.872] 404 and the interfaces for SDH transport networks defined in 405 [ITU-T_G.707] and optical transport networks defined in 406 [ITU-T_G.709]. The description is generic and no particular physical 407 partitioning of functions is implied. The input/output information 408 flows associated with the functional blocks serve for defining the 409 functions of the blocks and are considered to be conceptual, not 410 physical. They also provides processes for SDH OAM based on ITU-T 411 G.707 and OTN OAM based on ITU-T G.709. The functionality defined in 412 this Recommendation can be applied at user-to-network interfaces 413 (UNIs) and network node interfaces (NNIs) of the optical transport 414 network. 416 Recommendation [ITU-T_G.8021] specifies both the functional 417 components and the methodology that should be used in order to 418 specify the L2 Ethernet transport network functionality of network 419 elements. This Recommendation uses the specification methodology 420 defined in [ITU-T_G.806] in general for transport network equipment 421 and is based on the architecture of Ethernet layer networks defined 422 in [ITU-T_G.8010], the interfaces for Ethernet transport networks 423 defined in [ITU-T_G.8012], and in support of services defined in the 424 ITU-T G.8011.x series of Recommendations. It also provides processes 425 for Ethernet OAM based on [ITU-T_G.8013]. The description is generic 426 and no particular physical partitioning of functions is implied. The 427 input/output information flows associated with the functional blocks 428 serve to define the functions of the blocks and are considered to be 429 conceptual, not physical. The functionality defined in this 430 Recommendation can be applied at user-to-network interfaces (UNIs) 431 and network-to-network interfaces (NNIs) of the Ethernet transport 432 network. 434 Recommendation [ITU-T_G.8121] specifies both the functional 435 components and the methodology that should be used in order to 436 specify the multi-protocol label switching transport profile (MPLS- 437 TP) layer network functionality of network elements. This 438 Recommendation provides a representation of MPLS-TP technology which 439 uses the methodologies that have been used for other transport 440 technologies (e.g., optical transport network (OTN) and Ethernet). 441 It also provides generic processes for MPLS-TP OAM. It specifies a 442 library of basic building blocks and a set of rules by which they may 443 be combined in order to describe digital transmission equipment. The 444 library comprises the functional building blocks needed to specify 445 completely the generic functional structure of the MPLS-TP layer 446 network. 448 4.2.3. Transport management requirements 450 Recommendation [ITU-T_G.874] addresses management aspects of L0 and 451 L1 optical transport network elements containing transport functions 452 of one or more layer networks of the optical transport network (OTN). 453 It is based on the architecture of optical transport networks defined 454 in [ITU-T_G.872], the interfaces for OTN networks defined in 455 [ITU-T_G.709], and the OTN equipment function description defined in 456 [ITU-T_G.798]. The management functions for fault management, 457 configuration management, and performance management are specified. 458 Generic requirements in ITU-T G.7710/Y.1701 that are applicable to 459 OTN are identified in ITU-T G.874 via pointer references to ITU-T 460 G.7710/Y.1701. OTN-specific requirements explicitly specified 461 include separation of management communication network and signaling 462 communication network, OTN fault causes and failures, alarm reporting 463 control (ARC) setting, operational state, trail trace identifier 464 configuration, adaptation function configuration, connection function 465 configuration, tandem connection monitoring control function 466 configuration, and the management of the performance primitives. 468 Recommendation [ITU-T_G.8051] addresses management aspects of the L2 469 Ethernet Transport capable network element containing transport 470 functions of one or more of the layer networks of the Ethernet 471 transport network. The L2 Ethernet specific equipment functional 472 blocks are defined in [ITU-T_G.8021]. In this Recommendation, fault 473 management, configuration management, and performance management are 474 specified. Generic requirements in ITU-T G.7710/Y.1701 that are 475 applicable to Ethernet are identified in ITU-T G.8051/Y.1345 via 476 pointer references to ITU-T G.7710/Y.1701. Ethernet-specific 477 requirements explicitly specified include the management 478 communication channel, fault causes and failures, alarm reporting 479 control setting, operational state, flow termination function 480 configuration, adaptation function configuration, connection function 481 configuration, diagnostic function configuration, traffic 482 conditioning and shaping function configuration, performance 483 monitoring requirements, and the management of the performance 484 primitives. 486 Recommendation [ITU-T_G.8151] addresses management aspects of the 487 MPLS Transport Profile (MPLS-TP) capable network element, which is 488 separable from that of its client layer networks so that the same 489 means of management can be used regardless of the client. In this 490 Recommendation, fault management, configuration management, and 491 performance management are specified. The generic requirements for 492 managing transport network elements are specified in [ITU-T_G.7710] 493 and the requirements for the management of equipment used in networks 494 supporting an MPLS Transport Profile (MPLS-TP) are specified in [IETF 495 RFC 5951]. This Recommendation specifies the requirements for 496 managing the MPLS-TP specific equipment functional blocks, which are 497 defined in [ITU-T_G.8121]. 499 4.2.4. Management Information Models 501 Recommendation [ITU-T_G.874.1] provides a management-protocol-neutral 502 information model for managing network elements in the L0 and L1 503 optical transport network (OTN) [ITU-T_G.872], [ITU-T_G.709], and 504 [ITU-T_G.798] and supporting the management requirements specified in 505 [ITU-T_G.7710] and [ITU-T_G.874]. It identifies the managed entities 506 required for the management of OTN network elements, including 507 Termination Points (TP), Tandem Connection Monitoring (TCM), Non- 508 Intrusive Monitoring (NIM), Delay Measurement (DM), and the general 509 Performance Monitoring (PM) Current Data (CD) and History Data (HD). 510 These entities are relevant to information exchanged across 511 standardized management interfaces. The management-protocol-neutral 512 information model should be used as the base for defining management- 513 protocol-specific data schema. The specific mapping of the 514 management-protocol-neutral information model into management- 515 protocol-specific data schema is the decision of the management- 516 protocol-specific solution designer. The information model specified 517 in this Recommendation allows for managing the OTN functional 518 capabilities of the NE. 520 Recommendation [ITU-T_G.8052] provides a management-protocol-neutral 521 information model for managing network elements in the L2 Ethernet 522 transport network [ITU-T_G.8010], [ITU-T_G.8012], and [ITU-T_G.8021] 523 and supporting the management requirements specified in 524 [ITU-T_G.7710] and [ITU-T_G.8051]. It identifies the managed 525 entities required for the management of Ethernet transport network 526 elements, including Termination Points (TP), Maintenance Entity Group 527 (MEG) End Point (MEP), MEG Intermediate Point (MIP), Traffic 528 Conditioning and Shaping (TCS), Loss Measurement (LM), Delay 529 Measurement (DM), and the general Performance Monitoring (PM) Current 530 Data (CD) and History Data (HD). These entities are relevant to 531 information exchanged across standardized management interfaces. The 532 management-protocol-neutral information model should be used as the 533 base for defining management-protocol-specific data schema. The 534 specific mapping of the management-protocol-neutral information model 535 into management-protocol-specific data schema is the decision of the 536 management-protocol-specific solution design. The information model 537 specified in this Recommendation allows for managing the Ethernet 538 functional capabilities of the NE. 540 It should also be noted that [MEF_7.2] specifies the EMS-NMS 541 interface profile needed to support Metro Ethernet services, which 542 provides the profile of management entities based on [ITU-T_Q.840.1] 543 and [ITU-T_G.8052] and a mapping to the TMF's MTNM 3.5[TMF_MTNM] 544 Ethernet model. 546 Recommendation [ITU-T_G.8152] provides a management-protocol-neutral 547 information model for managing network elements in the L2 MPLS-TP 548 network [ITU-T_G.8110.1], [ITU-T_G.8112], and [ITU-T_G.8121] series 549 and supporting the management requirements specified in 550 [ITU-T_G.7710] and [ITU-T_G.8151]. It identifies the managed 551 entities required for the management of MPLS-TP network elements, 552 including Termination Points (TP), Maintenance Entity Group (MEG) End 553 Point (MEP), MEG Intermediate Point (MIP), Loss Measurement (LM), 554 Delay Measurement (DM), and the general Performance Monitoring (PM) 555 Current Data (CD) and History Data (HD). These entities are relevant 556 to information exchanged across standardized management interfaces. 557 The management-protocol-neutral information model should be used as 558 the base for defining management-protocol-specific data schema. The 559 specific mapping of the management-protocol-neutral information model 560 into management-protocol-specific data schema is the decision of the 561 management-protocol-specific solution design. The information model 562 specified in this Recommendation allows for managing the MPLS-TP 563 functional capabilities of the NE. 565 5. Discussion 567 This draft has provided an introduction to the significant body of 568 specifications developed in ITU-T that detail the generic 569 architectural principles for OAM in (multi layer) transport networks. 570 It also provides an introduction to the specifications that apply 571 those general principles in a consistent way to various layered 572 transport network technologies. It is anticipated that the generic 573 and layer specific OAM architecture and management specifications 574 described in this draft will prove valuable in considerations of 575 generic unified approaches to OAM and management for additional 576 multilayer networks. 578 6. Acknowledgements 580 7. Contributors 582 8. IANA Considerations 584 This memo includes no request to IANA. 586 9. Security Considerations 588 This informational document is solely intended to provide a summary 589 of the existing ITU-T SG 15 standards, (Layer 0 - Layer 2) both 590 technology-specific and generic across these technologies, relevant 591 to leveraging OAM to support fault management, performance 592 monitoring, and configuration management. No security threat is 593 introduced by this informational document. 595 10. References 597 10.1. Normative References 599 [I-D.lam-topology] 600 Lam, K., Varma, E., Doolan, P., Davis, N., Zeuner, B., 601 Betts, M., Busi, I., and S. Mansfield, "Usage of IM for 602 network topology to support TE Topology YANG Module 603 Development", 2015, . 606 [IEEE_802.1Q] 607 IEEE, "Media Access Control (MAC) Bridges and Virtual 608 Bridged Local Area Networks, IEEE Std 802.1Q-2014", 2014. 610 [IEEE_802.3] 611 IEEE, "Carrier sense multiple access with collision 612 detection (CSMA/CD) access method and physical layer 613 specifications, IEEE Std 802.3-2005", 2005. 615 [ITU-T_G.707] 616 ITU-T, "ITU-T G.707/Y.1322 - Network node interface for 617 the synchronous digital hierarchy (SDH), 01/2007, Amd.1 618 07/2007, Amd. 2 11/2009", 2007, 619 . 621 [ITU-T_G.709] 622 ITU-T, "ITU-T G.709/Y.1331 - Interfaces for the optical 623 transport network (OTN), 02/2012", 2012, 624 . 626 [ITU-T_G.7710] 627 ITU-T, "ITU-T G.7710/Y.1701 - Common Equipment Management 628 Function Requirements; 02/2012", 2012, 629 . 631 [ITU-T_G.7718.1] 632 ITU-T, "ITU-T G.7718.1/Y.1709.1 - Protocol-neutral 633 management information model for the control plane view; 634 12/2006", 2006, 635 . 637 [ITU-T_G.774] 638 ITU-T, "ITU-T G.774 - Synchronous digital hierarchy (SDH) 639 - Management information model for the network element 640 view ; 02/2001", 2001, 641 . 643 [ITU-T_G.783] 644 ITU-T, "ITU-T G.783 - Characteristics of Synchronous 645 Digital Hierarchy (SDH) equipment functional blocks; 646 03/2006", 2006, . 648 [ITU-T_G.784] 649 ITU-T, "ITU-T G.784 - Management aspects of synchronous 650 digital hierarchy (SDH) transport network elements ; 651 03/2008", 2008, . 653 [ITU-T_G.798] 654 ITU-T, "ITU-T G.798 - Characteristics of optical transport 655 network hierarchy equipment functional blocks; 12/2012", 656 2012, . 658 [ITU-T_G.800] 659 ITU-T, "ITU-T G.800 - Unified Model; 02/2012", 2012, 660 . 662 [ITU-T_G.8010] 663 ITU-T, "ITU-T G.8010/Y.1306 - Architecture of Ethernet 664 Layer Networks; 02/2004", 2004, 665 . 667 [ITU-T_G.8012] 668 ITU-T, "ITU-T G.8010/Y.1308 - Ethernet UNI and Ethernet 669 NNI; 08/2004", 2004, 670 . 672 [ITU-T_G.8013] 673 ITU-T, "ITU-T G.8013/Y.1731 - OAM functions and mechanisms 674 for Ethernet based networks; 11/2013", 2013, 675 . 677 [ITU-T_G.8021] 678 ITU-T, "ITU-T G.8021/Y.1341 - Characteristics of Ethernet 679 transport network equipment functional blocks; 04/2015", 680 2012, . 682 [ITU-T_G.803] 683 ITU-T, "ITU-T G.803 - Architecture of Transport Networks 684 based on the Synchronous Digital Hierarchy (SDH); 685 03/2000", 2000, . 687 [ITU-T_G.805] 688 ITU-T, "ITU-T G.805 - Generic functional architecture of 689 transport networks; 10/2000", 2000, 690 . 692 [ITU-T_G.8051] 693 ITU-T, "ITU-T G.8051/Y.1345 - Management aspects of the 694 Ethernet - over - Transport (EoT) capable network element; 695 08/2013", 2013, . 697 [ITU-T_G.8052] 698 ITU-T, "ITU-T G.8052/Y.1346 - Protocol-neutral management 699 information model for the Ethernet transport capable 700 network element; 08/2013", 2013, 701 . 703 [ITU-T_G.806] 704 ITU-T, "ITU-T G.806 - Characteristics of Transport 705 Equipment - Description Methodology and Generic 706 Functionality, 02/2012", 2012, 707 . 709 [ITU-T_G.8110.1] 710 ITU-T, "ITU-T G.8110.1/Y.1370.1 - Architecture of MPLS 711 Transport Profile (MPLS-TP) layer network; 12/2011", 2011, 712 . 714 [ITU-T_G.8112] 715 ITU-T, "ITU-T G.8110.1/Y.1371 - Interfaces for the MPLS 716 Transport Profile layer network ; 10/2012", 2012, 717 . 719 [ITU-T_G.8113.2] 720 ITU-T, "ITU-T G.8113.2/Y.1372.2 - Operations, 721 administration and maintenance mechanisms for MPLS-TP 722 networks using the tools defined for MPLS; 11/2012", 2012, 723 . 725 [ITU-T_G.8121] 726 ITU-T, "ITU-T G.8121/Y.1371 - Characteristics of MPLS-TP 727 equipment functional blocks; 11/2013", 2013, 728 . 730 [ITU-T_G.8151] 731 ITU-T, "ITU-T G.8151/Y.1374 - Management aspects of the 732 MPLS-TP network element; 01/2015", 2015, 733 . 735 [ITU-T_G.8152] 736 ITU-T, "ITU-T G.8152/Y.1375 (draft in progress), Protocol- 737 neutral management information model for the MPLS-TP 738 network element", 201x. 740 [ITU-T_G.872] 741 ITU-T, "ITU-T G.872 - Architecture of optical transport 742 networks; 10/2012", 2012, 743 . 745 [ITU-T_G.874] 746 ITU-T, "ITU-T G.874 - Management aspects of the optical 747 transport network element; 08/2013", 2013, 748 . 750 [ITU-T_G.874.1] 751 ITU-T, "ITU-T G.874.1 - Optical transport network (OTN) 752 protocol-neutral management information model for the 753 network element view; 10/2012", 2012, 754 . 756 [ITU-T_G.gim] 757 ITU-T, "ITU-T G.gim (draft in progress), Generic protocol- 758 neutral management Information Model for transport network 759 resources", 201x. 761 [ITU-T_Q.840.1] 762 ITU-T, "ITU-T Q.840.1 - Requirements and analysis for NMS- 763 EMS management interface of Ethernet over Transport and 764 Metro Ethernet Network (EoT/MEN)", 2007, 765 . 767 [MEF_7.2] MEF, "Carrier Ethernet Management Information Model", 768 2013, . 771 [ONF_Liaison] 772 ONF, "ONF Liaison Statement "Information Modeling Work In 773 Progress"", 2015, . 776 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 777 Requirement Levels", BCP 14, RFC 2119, March 1997. 779 [RFC5860] Vigoureux, M., Ward, D., and M. Betts, "Requirements for 780 Operations, Administration, and Maintenance (OAM) in MPLS 781 Transport Networks", RFC 5860, May 2010. 783 [RFC5950] Mansfield, S., Gray, E., and K. Lam, "Network Management 784 Framework for MPLS-based Transport Networks", RFC 5950, 785 September 2010. 787 [RFC5951] Lam, K., Mansfield, S., and E. Gray, "Network Management 788 Requirements for MPLS-based Transport Networks", RFC 5951, 789 September 2010. 791 [RFC6371] Busi, I. and D. Allan, "Operations, Administration, and 792 Maintenance Framework for MPLS-Based Transport Networks", 793 RFC 6371, September 2011. 795 [RFC6424] Bahadur, N., Kompella, K., and G. Swallow, "Mechanism for 796 Performing Label Switched Path Ping (LSP Ping) over MPLS 797 Tunnels", RFC 6424, November 2011. 799 [RFC6428] Allan, D., Swallow Ed. , G., and J. Drake Ed. , "Proactive 800 Connectivity Verification, Continuity Check, and Remote 801 Defect Indication for the MPLS Transport Profile", RFC 802 6428, November 2011. 804 [TMF_MTNM] 805 TM Forum, "TM Forum Multi Technology Network Management, 806 Release 3.5", 2009, 807 . 810 10.2. Informative References 812 [OTN_Handbook] 813 ITU-T, "ITU-T OTN Handbook - Optical Transport Networks 814 from TDM to Packet, ITU-T Manual 2010", 2010. 816 Appendix A. Additional Stuff 818 TBD 820 Authors' Addresses 822 Kam Lam (editor) 823 Alcatel-Lucent 824 USA 826 Phone: +1 732 331 3476 827 Email: kam.lam@alcatel-lucent.com 829 Eve Varma (editor) 830 Alcatel-Lucent 831 USA 833 Email: eve.varma@alcatel-lucent.com 834 Scott Mansfield (editor) 835 Ericsson 836 USA 838 Phone: +1 724 931 9316 839 Email: scott.mansfield@ericsson.com 841 Yuji Tochio (editor) 842 Fujitsu 843 Japan 845 Email: tochio@jp.fujitsu.com 847 Huub van Helvoort (editor) 848 Hai Gaoming BV 849 The Netherlands 851 Phone: +31 924 8936 852 Email: huubatwork@gmail.com 854 Maarten Vissers (editor) 855 Huawei 856 China 858 Phone: +31 62 611 2004 859 Email: maarten.vissers@huawei.com 861 Paul Doolan (editor) 862 Coriant 863 Germany 865 Phone: +1 972 357 5822 866 Email: paul.doolan@coriant.com