LIME Working Group K. Lam, Ed. Internet-Draft E. Varma, Ed. Intended status: Informational Nokia Expires: September 19, 2016 S. Mansfield, Ed. Ericsson Y. Tochio, Ed. Fujitsu H. van Helvoort, Ed. Hai Gaoming BV M. Vissers, Ed. Huawei P. Doolan, Ed. Coriant March 18, 2016 Existing Support for Network Operations in Multilayer Transport Network based upon unified approach to OAM (Layer 0 - Layer 2) draft-lam-lime-summary-l0-l2-layer-independent-04 Abstract This draft summarizes the existing ITU-T SG 15 standards, (Layer 0 - Layer 2) both technology-specific and generic across these technologies, relevant to leveraging OAM to support fault management, performance monitoring, and configuration management. Knowledge from this domain may be leveraged for the benefit of developing generic layer independent management for other layers. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on September 19, 2016. Lam, et al. Expires September 19, 2016 [Page 1] Internet-Draft L0-L2 Independent Management March 2016 Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Network Operation Supported by L0-L2 OAM . . . . . . . . . . 5 4. L0-L2 Architecture and Management Standards . . . . . . . . . 6 4.1. Generic Transport Layer and Technology Independent Standards . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1.1. Generic Transport Architecture . . . . . . . . . . . 6 4.1.2. Generic processing of transport equipment OAM functions . . . . . . . . . . . . . . . . . . . . . . 7 4.1.3. Generic management requirements . . . . . . . . . . . 7 4.1.4. Generic information model of transport network resources . . . . . . . . . . . . . . . . . . . . . . 8 4.2. Layer and Technology Specific Standards . . . . . . . . . 8 4.2.1. Architecture . . . . . . . . . . . . . . . . . . . . 8 4.2.2. Transport Equipment Functions . . . . . . . . . . . . 9 4.2.3. Transport management requirements . . . . . . . . . . 10 4.2.4. Management Information Models . . . . . . . . . . . . 11 5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 13 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 13 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 10.1. Normative References . . . . . . . . . . . . . . . . . . 14 10.2. Informative References . . . . . . . . . . . . . . . . . 18 Appendix A. Additional Stuff . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 Lam, et al. Expires September 19, 2016 [Page 2] Internet-Draft L0-L2 Independent Management March 2016 1. Introduction A comprehensive set of Operations, Administration, and Maintenance (OAM) capabilities is essential for supporting the critical network operations of fault management, performance monitoring, and configuration management. For this reason in the ITU-T, Layer 0 - Layer 2 technologies have been designed with extensive OAM capabilities (e.g., as specified in [ITU-T_G.709], [ITU-T_G.707], [ITU-T_G.8012], etc.) Considerable effort has been expended to establish a coherent approach to OAM that allows monitoring of the status and performance of (stacked) connections, including generic layer independent principles and inter-layer interworking. Thus, the OAM architecture used in transport networks has a common behavior across all technologies and layer networks. This draft summarizes ITU-T Recommendations that specify the generic architecture, principles, and models, both technology specific and generic, developed to support management of L0-L2 connections based upon a unified and consistent OAM view of multi-layer networks. It should be noted that the OAM and management framework and requirements for MPLS-TP, which is L2.5, has also been based upon these principles (e.g., RFC 6371 [RFC6371], RFC 5860 [RFC5860], RFC 5950 [RFC5950], and RFC 5951 [RFC5951]. It is believed that the generic architecture, principles and models specified in the material summarized herein may be leveraged in considerations of a common approach to OAM management for other layer networks (e.g., Layer 3-Layer 7). 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2. Terminology Anomaly: The smallest discrepancy that can be observed between actual and desired characteristics of an item. The occurrence of a single anomaly does not constitute an interruption in ability to perform a required function. Anomalies are used as the input for the Performance Monitoring (PM) process and for detection of defects (from [ITU-T_G.806], Section 3.7). Defect: The density of anomalies has reached a level where the ability to perform a required function has been interrupted. Defects are used as input for performance monitoring, the control of consequent actions, and the determination of fault cause (from [ITU-T_G.806], Section 3.24). Lam, et al. Expires September 19, 2016 [Page 3] Internet-Draft L0-L2 Independent Management March 2016 Fault: A fault is the inability of a function to perform a required action. This does not include an inability due to preventive maintenance, lack of external resources, or planned actions (from [ITU-T_G.806], Section 3.26). Fault cause: A single disturbance or fault may lead to the detection of multiple defects. A fault cause is the result of a correlation process that is intended to identify the defect that is representative of the disturbance or fault that is causing the problem (from [ITU-T_G.806], Section 3.27). Failure: The fault cause persisted long enough to consider the ability of an item to perform a required function to be terminated. The item may be considered as failed; a fault has now been detected (from [ITU-T_G.806], Section 3.25). Equipment Management Function (EMF): The management functions within an NE (see [ITU-T_G.7710]). Element Management System (EMS) Information Model (IM): An information model condenses domain knowledge and insights to provide a representation of its essential concepts, structures, and interrelationships. It models managed objects at a conceptual level, independent of any specific implementations or protocols used to transport the data. Layer 0 - Layer 2: Refers to physical (photonic), physical (electrical), and data link (e.g., Ethernet) transport technology, respectively. Network Management System (NMS) Network Element (NE) Operations, Administration, and Maintenance (OAM) o On-demand OAM - OAM actions that are initiated via manual intervention for a limited time to carry out diagnostics. On- demand OAM can result in singular or periodic OAM actions during the diagnostic time interval. o Proactive OAM - OAM actions that are carried on continuously to permit timely reporting of fault and/or performance status. Lam, et al. Expires September 19, 2016 [Page 4] Internet-Draft L0-L2 Independent Management March 2016 3. Network Operation Supported by L0-L2 OAM OAM mechanisms include the tools and utilities to plan, install, monitor and troubleshoot a network layer. While the specific set of OAM mechanisms in a layer depends upon the technology (e.g., [ITU-T_G.709] on OTN, [ITU-T_G.707] on SDH, [ITU-T_G.8013] on Ethernet), they all support the same fault management, performance monitoring, and configuration management operations and processes. As noted previously, MPLS-TP OAM (e.g., [ITU-T_G.8113.2], [RFC6424], [RFC6428], etc.) was also designed to support L0-L2 operations and processes. Some OAM functions are implemented in hardware (data plane inherent, such as Tandem Connection Monitoring (TCM) or Performance Monitoring (PM)), while other functions can be implemented mostly in lower software layers. Fault management includes defect detection, fault localization, fault reporting, and protection switching [OTN Handbook, Chapter 3]. o Defect detection: Failures affecting the transport of client information are detected by continuous pro-active checking. Persistent failures are considered to be service-affecting defects. Detected defects are correlated with other detected defects to find the most probable cause of the failure and consequent actions, such as protection switching, are taken. o Fault localization: If the defect information is insufficient to locate the failure, on-demand OAM functions can be used to determine the cause of the defect more accurately. o Fault reporting: Persistent defects are reported to the network management system to provide the appropriate alarm reports to maintenance staff for maintaining the desired quality of service level. o Protection switching: After a defect has been detected, a protection switch can be initiated as a consequent action to restore the interrupted traffic, and thus improve the availability. Performance monitoring includes measuring the performance (e.g., packet losses, bit errors, etc.) of the transport of client information in order to verify the quality of service and to estimate the transport integrity. Configuration management includes indicating the operational state of a connection; e.g., whether it can be used to transport client data or whether the set-up of the connection is completed. Lam, et al. Expires September 19, 2016 [Page 5] Internet-Draft L0-L2 Independent Management March 2016 4. L0-L2 Architecture and Management Standards Figure 1 below is a summary of relevant technology specific and generic L0-L2 transport architecture and management standards. +-------------------------------------------------+ |Transport| Transport Technology Specific | | Tech. |---------------------------------------+ | Generic | OTN | Carrier | MPLS-TP | SDH | | | | Ethernet | Note 2 | | +------------------------------------------------------------------+ | Transport | G.800 | G.872 | G.8010 | G.8110.1 | G.803 | | Architecture | G.805 | | | | | +------------------------------------------------------------------+ | Operations | | | | | | | Aministration | G.806 | G.709 | G.8013 | G.8113.x | G.707 | | Maintenance | | | | series | | +------------------------------------------------------------------+ | Equipment | G.806 | G.798 | G.8021 | G.8121.x | G.783 | | Function | | | | series | | +------------------------------------------------------------------+ | Management | G.7710 | G.874 | G.8051 | G.8151 | G.784 | | Requirement | | | | | | +------------------------------------------------------------------+ | Mgmt Interface | | | | | G.774 | |Protocol-neutral| G.7711 | G.874.1 | G.8052 | G.8152 | series| | Info Model | | | | | Note 1| +------------------------------------------------------------------+ Note 1: The model had been specified, but not in a protocol neutral manner. Note 2: MPLS-TP is actually L2.5; it is included as it falls under the generic transport management umbrella (as per design). Figure 1: L0-L2 Architecture and Management Standards 4.1. Generic Transport Layer and Technology Independent Standards 4.1.1. Generic Transport Architecture Recommendations [ITU-T_G.800] and [ITU-T_G.805] provide a technology independent and model-based description of transport network functionality. The first generic functional model based architecture Recommendation was [ITU-T_G.805], which describes connection oriented networks. [ITU-T_G.800] was subsequently developed to provide a common framework to describe both connection-oriented and connectionless networks. The descriptions are compatible with those Lam, et al. Expires September 19, 2016 [Page 6] Internet-Draft L0-L2 Independent Management March 2016 of the earlier generic Recommendations (e.g., [ITU-T_G.805]). These standard model-based approaches: o Enable the description of the generic characteristics of networks using a common language at a level that transcends technology and physical architecture choices. o Provide a view of functions or entities that may be distributed among various equipment. o Concurrently specify transport and management functionality. These generic functional architectures of transport networks are the basis for a harmonized set of functional architecture Recommendations for specific transport layer network technologies that use circuit switching or packet switching technology (e.g. [ITU-T_G.803] for SDH, [ITU-T_G.872] for OTN, [ITU-T_G.8010] for Carrier Ethernet, [ITU-T_G.8110.1] for MPLS-TP). These transport technology specific architecture Recommendations are used as the basis for a corresponding set of Recommendations for equipment specifications, including OAM and management. 4.1.2. Generic processing of transport equipment OAM functions The development of the OAM architecture used by ITU-T in transport networks started around 1990, and basic generic OAM functions were first defined in the period 1990-1993 and described in Recommendation [ITU-T_G.806]. Since that time, this initial OAM architecture has been extended to assure it remains generic with respect to emerging transport technologies. The extended OAM functionality included the definition of a transport maintenance entity with end-points and intermediate-points, pro-active and on-demand OAM functions, defect correlation, and alarm suppression, etc. The generic OAM architecture in [ITU-T_G.806] has been used as the common basis for all technology-specific transport equipment specifications (e.g., [ITU-T_G.783] for SDH, [ITU-T_G.798] for OTN, [ITU-T_G.8021] for Carrier Ethernet, and also [ITU-T_G.8121] for MPLS-TP). 4.1.3. Generic management requirements Recommendation [ITU-T_G.7710] specifies the equipment management function (EMF) requirements that are common to multiple transport technologies and common to packet-based and circuit-based transport networks. The Recommendation addresses the EMF inside a transport network element, including the configuration, fault, and performance (i.e. the C, F, P of FCAPS) management functions. The generic management requirements in [ITU-T_G.7710] have been used as the common basis for all technology-specific transport management Lam, et al. Expires September 19, 2016 [Page 7] Internet-Draft L0-L2 Independent Management March 2016 specifications (e.g., [ITU-T_G.784] for SDH, [ITU-T_G.874] for OTN, [ITU-T_G.8051] for Carrier Ethernet, and [ITU-T_G.8151] for MPLS-TP. 4.1.4. Generic information model of transport network resources ITU-T Recommendation [ITU-T_G.7711] and [ONF_TR-512] of ONF Common Information Model (ONF-CIM) [ONF_TR-513] specify a core information model for transport resources. The model is also applicable to the management and control of the transport network regardless of the technology of the underlying transport network. Furthermore, the applicability of the information model is independent of the choice of protocol to be used in the management and control interfaces. The core information model defined in this Recommendation can be used as the basis for the extension of transport/control-technology-specific information models. Such extension will be specified in the technology-specific Recommendations, such as [ITU-T_G.774] series for SDH, [ITU-T_G.874.1] for OTN management, [ITU-T_G.8052] for Carrier Ethernet management, [ITU-T_G.8152] for MPLS-TP management, and [ITU-T_G.7718.1] for ASON control plane management. 4.2. Layer and Technology Specific Standards 4.2.1. Architecture Recommendations [ITU-T_G.803] and [ITU-T_G.872] describe respectively the functionality of the SDH and optical transport networks (OTN), L0 and L1, from a network level perspective using the generic principles defined in [ITU-T_G.805] and [ITU-T_G.800]. [ITU-T_G.803] and [ITU-T_G.872] describe the specific aspects concerning the SDH and optical transport network layered structure, characteristic information, client/server layer associations, network topology, and layer network functionality. In accordance with [ITU-T_G.805] and [ITU-T_G.800], the optical transport network is decomposed into independent transport layer networks where each layer network can be separately partitioned in a way which reflects the internal structure of that layer network. In addition to reflecting the generic fault, configuration, and performance management requirements, it describes requirements for connection supervision (e.g., continuity, connectivity, required maintenance information), signal quality supervision, adaptation management, etc.) and connection supervision techniques (i.e., inherent, non-intrusive, intrusive, and sublayer monitoring). Recommendation [ITU-T_G.8010] describes the functional architecture of L2 Ethernet networks using the modelling methodology described in [ITU-T_G.800] and [ITU-T_G.805]. The Ethernet network functionality is described from a network level viewpoint, taking into account an Ethernet network layered structure, client characteristic Lam, et al. Expires September 19, 2016 [Page 8] Internet-Draft L0-L2 Independent Management March 2016 information, client/server layer associations, networking topology, and layer network functionality providing Ethernet signal transmission, multiplexing, routing, supervision, performance assessment, and network survivability. Recommendation [ITU-T_G.8010] describes the relevant parts of the Ethernet specifications in [IEEE_802.1Q] and [IEEE_802.3] using the ITU-T transport network modelling methodology. The ETH layer network provides the transport of adapted information through an ETH connectionless trail between ETH access points. The adapted information is a (non-) continuous flow of MAC service data units ([IEEE_802.3]). Recommendation [ITU-T_G.8110.1] provides functional components, based on Recommendation [ITU-T_G.805], that allow the Multi Protocol Label Switching Transport Profile (MPLS-TP) to be modeled in a way that is consistent with the description of other transport technologies defined by the ITU-T to simplify integration with other transport technologies. It provides a representation of the MPLS-TP technology using the methodologies that have been used for other transport technologies (e.g., SDH, OTN and Ethernet). In [ITU-T_G.8110.1], the architecture of MPLS-TP forwarding, OAM, and network survivability are modeled from a network-level viewpoint. 4.2.2. Transport Equipment Functions Recommendations [ITU-T_G.783] and [ITU-T_G.798] specify both the components and the methodology that should be used in order to specify the respective SDH and OTN functionality of network elements. This Recommendations uses the specification methodology defined in [ITU-T_G.806], in general for transport network equipment, and is based on the architecture of SDH transport networks defined in [ITU-T_G.783] and optical transport networks defined in [ITU-T_G.872] and the interfaces for SDH transport networks defined in [ITU-T_G.707] and optical transport networks defined in [ITU-T_G.709]. The description is generic and no particular physical partitioning of functions is implied. The input/output information flows associated with the functional blocks serve for defining the functions of the blocks and are considered to be conceptual, not physical. They also provides processes for SDH OAM based on [ITU-T_G.707] and OTN OAM based on [ITU-T_G.709]. The functionality defined in this Recommendation can be applied at user-to-network interfaces (UNIs) and network node interfaces (NNIs) of the optical transport network. Recommendation [ITU-T_G.8021] specifies both the functional components and the methodology that should be used in order to specify the Ethernet transport network functionality of network elements. This Recommendation uses the specification methodology defined in [ITU-T_G.806] in general for transport network equipment Lam, et al. Expires September 19, 2016 [Page 9] Internet-Draft L0-L2 Independent Management March 2016 and is based on the architecture of Ethernet layer networks defined in [ITU-T_G.8010], the interfaces for Ethernet transport networks defined in [ITU-T_G.8012], and in support of services defined in [ITU-T_G.8011]. It also provides processes for Ethernet OAM based on [ITU-T_G.8013]. The description is generic and no particular physical partitioning of functions is implied. The input/output information flows associated with the functional blocks serve to define the functions of the blocks and are considered to be conceptual, not physical. The functionality defined in this Recommendation can be applied at user-to-network interfaces (UNIs) and network-to-network interfaces (NNIs) of the Ethernet transport network. Recommendation [ITU-T_G.8121] specifies both the functional components and the methodology that should be used in order to specify the multi-protocol label switching transport profile (MPLS- TP) layer network functionality of network elements. This Recommendation provides a representation of MPLS-TP technology which uses the methodologies that have been used for other transport technologies (e.g., optical transport network (OTN) and Ethernet). It also provides generic processes for MPLS-TP OAM. It specifies a library of basic building blocks and a set of rules by which they may be combined in order to describe digital transmission equipment. The library comprises the functional building blocks needed to specify completely the generic functional structure of the MPLS-TP layer network. 4.2.3. Transport management requirements Recommendation [ITU-T_G.874] addresses management aspects of L0 and L1 optical transport network elements containing transport functions of one or more layer networks of the optical transport network (OTN). It is based on the architecture of optical transport networks defined in [ITU-T_G.872], the interfaces for OTN networks defined in [ITU-T_G.709], and the OTN equipment function description defined in [ITU-T_G.798]. The management functions for fault management, configuration management, and performance management are specified. Generic requirements in [ITU-T_G.7710] that are applicable to OTN are identified in [ITU-T_G.874] via pointer references to [ITU-T_G.7710]. OTN-specific requirements explicitly specified include separation of management communication network and signaling communication network, OTN fault causes and failures, alarm reporting control (ARC) setting, operational state, trail trace identifier configuration, adaptation function configuration, connection function configuration, tandem connection monitoring control function configuration, and the management of the performance primitives. Lam, et al. Expires September 19, 2016 [Page 10] Internet-Draft L0-L2 Independent Management March 2016 Recommendation [ITU-T_G.8051] addresses management aspects of the L2 Ethernet Transport capable network element containing transport functions of one or more of the layer networks of the Ethernet transport network. The L2 Ethernet specific equipment functional blocks are defined in [ITU-T_G.8021]. In this Recommendation, fault management, configuration management, and performance management are specified. Generic requirements in [ITU-T_G.7710] that are applicable to Ethernet are identified in [ITU-T_G.8051] via pointer references to [ITU-T_G.7710]. Ethernet-specific requirements explicitly specified include the management communication channel, fault causes and failures, alarm reporting control setting, operational state, flow termination function configuration, adaptation function configuration, connection function configuration, diagnostic function configuration, traffic conditioning and shaping function configuration, performance monitoring requirements, and the management of the performance primitives. Recommendation [ITU-T_G.8151] addresses management aspects of the MPLS Transport Profile (MPLS-TP) capable network element, which is separable from that of its client layer networks so that the same means of management can be used regardless of the client. In this Recommendation, fault management, configuration management, and performance management are specified. The generic requirements for managing transport network elements are specified in [ITU-T_G.7710] and the requirements for the management of equipment used in networks supporting an MPLS Transport Profile (MPLS-TP) are specified in [IETF RFC 5951]. This Recommendation specifies the requirements for managing the MPLS-TP specific equipment functional blocks, which are defined in [ITU-T_G.8121]. 4.2.4. Management Information Models Recommendation [ITU-T_G.874.1] provides a management-protocol-neutral information model for managing network elements in the L0 and L1 optical transport network (OTN) [ITU-T_G.872], [ITU-T_G.709], and [ITU-T_G.798] and supporting the management requirements specified in [ITU-T_G.7710] and [ITU-T_G.874]. It identifies the managed entities required for the management of OTN network elements, including Termination Points (TP), Tandem Connection Monitoring (TCM), Non- Intrusive Monitoring (NIM), Delay Measurement (DM), and the general Performance Monitoring (PM) Current Data (CD) and History Data (HD). These entities are relevant to information exchanged across standardized management interfaces. The management-protocol-neutral information model should be used as the base for defining management- protocol-specific data schema. The specific mapping of the management-protocol-neutral information model into management- protocol-specific data schema is the decision of the management- protocol-specific solution designer. The information model specified Lam, et al. Expires September 19, 2016 [Page 11] Internet-Draft L0-L2 Independent Management March 2016 in this Recommendation allows for managing the OTN functional capabilities of the NE. Recommendation [ITU-T_G.8052] provides a management-protocol-neutral information model for managing network elements in the L2 Ethernet transport network [ITU-T_G.8010], [ITU-T_G.8012], and [ITU-T_G.8021] and supporting the management requirements specified in [ITU-T_G.7710] and [ITU-T_G.8051]. It identifies the managed entities required for the management of Ethernet transport network elements, including Termination Points (TP), Maintenance Entity Group (MEG) End Point (MEP), MEG Intermediate Point (MIP), Traffic Conditioning and Shaping (TCS), Loss Measurement (LM), Delay Measurement (DM), and the general Performance Monitoring (PM) Current Data (CD) and History Data (HD). These entities are relevant to information exchanged across standardized management interfaces. The management-protocol-neutral information model should be used as the base for defining management-protocol-specific data schema. The specific mapping of the management-protocol-neutral information model into management-protocol-specific data schema is the decision of the management-protocol-specific solution design. The information model specified in this Recommendation allows for managing the Ethernet functional capabilities of the NE. It should also be noted that [MEF_7.2] specifies the EMS-NMS interface profile needed to support Metro Ethernet services, which provides the profile of management entities based on [ITU-T_Q.840.1] and [ITU-T_G.8052] and a mapping to the TMF's MTNM 3.5[TMF_MTNM] Ethernet model. Work is in progress on [MEF_7.3], which describes the Carrier Ethernet Service Management Information Model for the management of MEF Carrier Ethernet services, including EVC and OVC as customer facing services. There are additionally other protocol- neutral MEF information modeling activities underway (e.g., MEF Network Resource Management Information Model to specify mapping from the [MEF_7.3] Service Model to a Network Resource Model based upon [ONF_TR-512] and [ITU-T_G.8052]. Recommendation [ITU-T_G.8152] provides a management-protocol-neutral information model for managing network elements in the L2 MPLS-TP network [ITU-T_G.8110.1], [ITU-T_G.8112], and [ITU-T_G.8121] series and supporting the management requirements specified in [ITU-T_G.7710] and [ITU-T_G.8151]. It identifies the managed entities required for the management of MPLS-TP network elements, including Termination Points (TP), Maintenance Entity Group (MEG) End Point (MEP), MEG Intermediate Point (MIP), Loss Measurement (LM), Delay Measurement (DM), and the general Performance Monitoring (PM) Current Data (CD) and History Data (HD). These entities are relevant to information exchanged across standardized management interfaces. The management-protocol-neutral information model should be used as Lam, et al. Expires September 19, 2016 [Page 12] Internet-Draft L0-L2 Independent Management March 2016 the base for defining management-protocol-specific data schema. The specific mapping of the management-protocol-neutral information model into management-protocol-specific data schema is the decision of the management-protocol-specific solution design. The information model specified in this Recommendation allows for managing the MPLS-TP functional capabilities of the NE. 5. Discussion This draft has provided an introduction to the significant body of specifications developed in ITU-T that detail the generic architectural principles for OAM in (multi layer) transport networks. It also provides an introduction to the specifications that apply those general principles in a consistent way to various layered transport network technologies. It is anticipated that the generic and layer specific OAM architecture and management specifications described in this draft will prove valuable in considerations of generic unified approaches to OAM and management for additional multilayer networks. 6. Acknowledgements 7. Contributors 8. IANA Considerations This memo includes no request to IANA. 9. Security Considerations This informational document is solely intended to provide a summary of the existing ITU-T SG 15 standards, (Layer 0 - Layer 2) both technology-specific and generic across these technologies, relevant to leveraging OAM to support fault management, performance monitoring, and configuration management. No security threat is introduced by this informational document. 10. References Lam, et al. Expires September 19, 2016 [Page 13] Internet-Draft L0-L2 Independent Management March 2016 10.1. Normative References [IEEE_802.1Q] IEEE, "Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks, IEEE Std 802.1Q-2014", 2014. [IEEE_802.3] IEEE, "Carrier sense multiple access with collision detection (CSMA/CD) access method and physical layer specifications, IEEE Std 802.3-2015", 2015. [ITU-T_G.707] ITU-T, "ITU-T G.707/Y.1322 - Network node interface for the synchronous digital hierarchy (SDH), 01/2007, Amd.1 07/2007, Amd. 2 11/2009", 2007, . [ITU-T_G.709] ITU-T, "ITU-T G.709/Y.1331 - Interfaces for the optical transport network (OTN), 02/2012", 2012, . [ITU-T_G.7710] ITU-T, "ITU-T G.7710/Y.1701 - Common Equipment Management Function Requirements; 02/2012", 2012, . [ITU-T_G.7711] ITU-T, "ITU-T G.7711/Y.1702, Generic protocol-neutral management Information Model for transport network resources", 2015. [ITU-T_G.7718.1] ITU-T, "ITU-T G.7718.1/Y.1709.1 - Protocol-neutral management information model for the control plane view; 12/2006", 2006, . [ITU-T_G.774] ITU-T, "ITU-T G.774 - Synchronous digital hierarchy (SDH) - Management information model for the network element view ; 02/2001", 2001, . [ITU-T_G.783] ITU-T, "ITU-T G.783 - Characteristics of Synchronous Digital Hierarchy (SDH) equipment functional blocks; 03/2006", 2006, . Lam, et al. Expires September 19, 2016 [Page 14] Internet-Draft L0-L2 Independent Management March 2016 [ITU-T_G.784] ITU-T, "ITU-T G.784 - Management aspects of synchronous digital hierarchy (SDH) transport network elements ; 03/2008", 2008, . [ITU-T_G.798] ITU-T, "ITU-T G.798 - Characteristics of optical transport network hierarchy equipment functional blocks; 12/2012", 2012, . [ITU-T_G.800] ITU-T, "ITU-T G.800 - Unified Model; 02/2012", 2012, . [ITU-T_G.8010] ITU-T, "ITU-T G.8010/Y.1306 - Architecture of Ethernet Layer Networks; 02/2004", 2004, . [ITU-T_G.8011] ITU-T, "ITU-T G.8011/Y.1307 - Ethernet service characteristics; 01/2015", 2015, . [ITU-T_G.8012] ITU-T, "ITU-T G.8010/Y.1308 - Ethernet UNI and Ethernet NNI; 08/2004", 2004, . [ITU-T_G.8013] ITU-T, "ITU-T G.8013/Y.1731 - OAM functions and mechanisms for Ethernet based networks; 8/2015", 2015, . [ITU-T_G.8021] ITU-T, "ITU-T G.8021/Y.1341 - Characteristics of Ethernet transport network equipment functional blocks; 04/2015", 2012, . [ITU-T_G.803] ITU-T, "ITU-T G.803 - Architecture of Transport Networks based on the Synchronous Digital Hierarchy (SDH); 03/2000", 2000, . [ITU-T_G.805] ITU-T, "ITU-T G.805 - Generic functional architecture of transport networks; 10/2000", 2000, . Lam, et al. Expires September 19, 2016 [Page 15] Internet-Draft L0-L2 Independent Management March 2016 [ITU-T_G.8051] ITU-T, "ITU-T G.8051/Y.1345 - Management aspects of the Ethernet - over - Transport (EoT) capable network element; 08/2013", 2013, . [ITU-T_G.8052] ITU-T, "ITU-T G.8052/Y.1346 - Protocol-neutral management information model for the Ethernet transport capable network element; 08/2013", 2013, . [ITU-T_G.806] ITU-T, "ITU-T G.806 - Characteristics of Transport Equipment - Description Methodology and Generic Functionality, 02/2012", 2012, . [ITU-T_G.8110.1] ITU-T, "ITU-T G.8110.1/Y.1370.1 - Architecture of MPLS Transport Profile (MPLS-TP) layer network; 12/2011", 2011, . [ITU-T_G.8112] ITU-T, "ITU-T G.8110.1/Y.1371 - Interfaces for the MPLS Transport Profile layer network ; 8/2015", 2015, . [ITU-T_G.8113.2] ITU-T, "ITU-T G.8113.2/Y.1372.2 - Operations, administration and maintenance mechanisms for MPLS-TP networks using the tools defined for MPLS; 8/2015", 2015, . [ITU-T_G.8121] ITU-T, "ITU-T G.8121/Y.1371 - Characteristics of MPLS-TP equipment functional blocks; 11/2013", 2013, . [ITU-T_G.8151] ITU-T, "ITU-T G.8151/Y.1374 - Management aspects of the MPLS-TP network element; 01/2015", 2015, . [ITU-T_G.8152] ITU-T, "ITU-T G.8152/Y.1375 (draft in progress), Protocol- neutral management information model for the MPLS-TP network element", 201x. Lam, et al. Expires September 19, 2016 [Page 16] Internet-Draft L0-L2 Independent Management March 2016 [ITU-T_G.872] ITU-T, "ITU-T G.872 - Architecture of optical transport networks; 10/2012", 2012, . [ITU-T_G.874] ITU-T, "ITU-T G.874 - Management aspects of the optical transport network element; 08/2013", 2013, . [ITU-T_G.874.1] ITU-T, "ITU-T G.874.1 - Optical transport network (OTN) protocol-neutral management information model for the network element view; 10/2012", 2012, . [ITU-T_Q.840.1] ITU-T, "ITU-T Q.840.1 - Requirements and analysis for NMS- EMS management interface of Ethernet over Transport and Metro Ethernet Network (EoT/MEN)", 2007, . [MEF_7.2] MEF, "Carrier Ethernet Information Model", 2013, . [MEF_7.3] MEF, "Carrier Ethernet Management Information Model (Draft in Process)", 201x. [ONF_TR-512] ONF, "TR-512 Core Information Model 1.1", 2015, . [ONF_TR-513] ONF, "TR-513 Common Information Model Overview 1.1", 2015, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Lam, et al. Expires September 19, 2016 [Page 17] Internet-Draft L0-L2 Independent Management March 2016 [RFC5860] Vigoureux, M., Ed., Ward, D., Ed., and M. Betts, Ed., "Requirements for Operations, Administration, and Maintenance (OAM) in MPLS Transport Networks", RFC 5860, DOI 10.17487/RFC5860, May 2010, . [RFC5950] Mansfield, S., Ed., Gray, E., Ed., and K. Lam, Ed., "Network Management Framework for MPLS-based Transport Networks", RFC 5950, DOI 10.17487/RFC5950, September 2010, . [RFC5951] Lam, K., Mansfield, S., and E. Gray, "Network Management Requirements for MPLS-based Transport Networks", RFC 5951, DOI 10.17487/RFC5951, September 2010, . [RFC6371] Busi, I., Ed. and D. Allan, Ed., "Operations, Administration, and Maintenance Framework for MPLS-Based Transport Networks", RFC 6371, DOI 10.17487/RFC6371, September 2011, . [RFC6424] Bahadur, N., Kompella, K., and G. Swallow, "Mechanism for Performing Label Switched Path Ping (LSP Ping) over MPLS Tunnels", RFC 6424, DOI 10.17487/RFC6424, November 2011, . [RFC6428] Allan, D., Ed., Swallow, G., Ed., and J. Drake, Ed., "Proactive Connectivity Verification, Continuity Check, and Remote Defect Indication for the MPLS Transport Profile", RFC 6428, DOI 10.17487/RFC6428, November 2011, . [TMF_MTNM] TM Forum, "TM Forum Multi Technology Network Management, Release 3.5", 2009, . 10.2. Informative References [OTN_Handbook] ITU-T, "ITU-T OTN Handbook - Optical Transport Networks from TDM to Packet, ITU-T Manual 2010", 2010. Lam, et al. Expires September 19, 2016 [Page 18] Internet-Draft L0-L2 Independent Management March 2016 Appendix A. Additional Stuff TBD Authors' Addresses Kam Lam (editor) Nokia USA Phone: +1 732 331 3476 Email: kam.lam@nokia.com Eve Varma (editor) Nokia USA Email: eve.varma@nokia.com Scott Mansfield (editor) Ericsson USA Phone: +1 724 931 9316 Email: scott.mansfield@ericsson.com Yuji Tochio (editor) Fujitsu Japan Email: tochio@jp.fujitsu.com Huub van Helvoort (editor) Hai Gaoming BV The Netherlands Phone: +31 924 8936 Email: huubatwork@gmail.com Lam, et al. Expires September 19, 2016 [Page 19] Internet-Draft L0-L2 Independent Management March 2016 Maarten Vissers (editor) Huawei China Phone: +31 62 611 2004 Email: maarten.vissers@huawei.com Paul Doolan (editor) Coriant Germany Phone: +1 972 357 5822 Email: paul.doolan@coriant.com Lam, et al. Expires September 19, 2016 [Page 20]