| IDR Working Group | Y. Tochio |
| Internet-Draft | Fujitsu |
| Intended status: Standards Track | H. van Helvoort |
| Expires: March 30, 2015 | Hai Gaoming BV |
| L. Xia | |
| Huawei | |
| September 26, 2014 |
Gap Analysis for Layer and Technology Independent OAM Management in the Multi-Layer Environment
draft-txh-opsawg-lime-gap-analysis-00
This draft analyses the existing management plane OAM related works in different SDOs, against the key objectives of Layer Independent OAM Management (LIME), to find the gap between them. The results can be used as the guidance for further work.
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 March 30, 2015.
Copyright (c) 2014 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.
Operations, Administration, and Maintenance (OAM) mechanisms are critical building blocks in network operations that are used for service assurance, fulfillment, or service diagnosis, troubleshooting, and repair. The current practice is maintenance and troubleshooting are achieved per technology and per layer. The operation process can be very cumbersome.
Due to this fact, [LIME-PS] discusses a valuable direction in management plane by consolidating OAM information from each layer using centralized management entity and have a unified and consistent OAM view of multi-layer network. Operators can rely on consolidated OAM management to correlate different layer OAM information (e.g., fault, defects and network failure), and quickly identify the faulty element with its layer information in the network path. The second important objective of LIME is to achieve a layer and technology independent OAM view of network and allow management application present to the user an abstract view of this network and its supporting layers that is strictly topological, free of any technology specific information. This means an abstract and generic OAM management model in management plane should be developed firstly, and then any technology-specific OAM data model can be developed by extending and inheriting from it. Generic OAM management model can provide a consistent configuration, reporting, and presentation for the OAM mechanisms. It also can mitigate the problem related to specific OAM technology dependency. [LIME-UC] lists the key use case for LIME application.
This draft analyses the existing management plane OAM related works in several SDOs, against the key objectives of LIME, to find the gap between them. The results can be used as the guidance for further work.
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 RFC2119 [RFC2119].
Two objectives of LIME are:
To achieve these two objectives and accelerate Yang data model development, we can use Existing Information model in ITU-T and MEF, OAM MIB Module and CFM model as basis and directly develop Yang Data model.
+---------------+ +---------------+ +----------+
| Existing IM | | OAM MIB Module| | CFM Model|
| in MEF, ITU-T | | (IETF, IEEE, | | Y.1731 |
| (e.g.,MEF 7.1 | | MEF) | | |
| ITU-T G.8052) | +-------|-------+ +-----|----+
+--------|------+ | |
| | |
-------------------|------------------|
+-----------------+
| Yang Data Model |
|for OAM Management
+------+----------+
| Augument/Inherit
+---------+-------------+
|Specific technology OAM|
| Data Model |
+-----------------------+
Yang Data Model Development
Following are the detailed surveys for the existing management plane OAM works.
ITU-T’s Recommendation [G.8052] and [G.8152] provide the management protocol-neutral information models for managing network elements in the Ethernet transport network and MPLS-TP transport network as defined in Recommendations [G.8010] and [G.8110.1] respectively. They contain the object classes for the Ethernet and MPLS-TP NE management. It includes the Termination Points (TP), Maintenance Entity Group (MEG) End Point (MEP), MEG Intermediate Point (MIP), Traffic Conditioning & Shaping (TCS), Loss Measurement (LM), Delay Measurement (DM), and the general Performance Monitoring (PM) Current Data (CD) and History Data (HD). [G.8052] has been published. [G.8152] is still in progress.
[MEF-7.1] specifies the EMS-NMS interface profile identifying the managed objects (i.e. logical UML objects) needed to support Metro Ethernet services. This specification provides the profile of management entities based on ITU-T [Q.840.1], and also provides a mapping to the TMF’s MTNM 3.5 Ethernet model. Specifically this document adds management support for Service OAM. The Ethernet Service OAM object definitions include common OAM objects (e.g., EthMe, EthMeg, EthMep, EthMip, EthMp, EthMd, EthMepPeerInfo), Fault Management Objects (e.g., Continuity Check, Loopback, Link Trace, Signal Functions), Performance Monitoring Objects (e.g., Abstract Performance Monitoring Objects, Loss Measurement, Delay Measurement, Function Sets).
The above OAM information models provide the baseline for the further definitions of OAM MIB modules and OAM YANG model. But they are still technology-specific definitions, not abstract and generic enough.
The IEEE8021-CFM-MIB MIB Module and IEEE8021-CFM-V2-MIB MIB module are CFM MIB modules for managing IEEE CFM in [802.1Q]. The former document defines all the MIB objects that used to read, create, modify, and delete OAM related information (i.e., CFM Stack Table, MD Table, MA Table, MEP Table, LinkTrace Reply Table, MEP DB Table, Notifications Table, etc). The latter document defines CFM V2 module for managing IEEE CFM. It contains objects that replace those deprecated in the IEEE8021-CFM-MIB module (i.e., CFM Stack Table, CFM Vlan Table, CFM Default MD Level Table, etc).
These CFM MIB modules defined for Ethernet network are the input for analyzing what the generic OAM data model should be and have.
[MEF-31] defines the MIB modules for MEF Service OAM Fault Management (FM). This document includes two MIBs necessary to support the MEF SOAM FM functionality: the MEF-SOAM-TC-MIB that includes the Textual Conventions (TC) for the SOAM MIB family and the MEF-SOAM-FM-MIB that includes extensions to Connectivity Fault Management (CFM) as developed in IEEE [802.1Q], including MIBs found in [IEEE 802.1Q] and [IEEE 802.1ap], and enhanced by ITU-T [Y.1731] to support the SOAM FM functions as presented in the [MEF-30] specification. It includes the SOAM FM MIB objects such as mefSoamNet, mefSoamMeg, mefSoamMep, mefSoamCc, mefSoamAis, mefSoamLb, etc.
[MEF-36] specifies the Performance Monitoring (PM) MIB necessary to manage SOAM implementations that satisfy the Service OAM requirements and framework specified by [MEF-17], the Service OAM Performance Monitoring requirements as specified by [MEF-35], and the Service OAM management objects as specified by [MEF-7.1] which are applicable to Performance Monitoring functions. Two non-MEF documents serve as the baseline documents for this work: ITU-T [Y.1731] and IEEE [802.1Q]. The SOAM PM MIB is divided into a number of different object groupings: the PM MIB MEP Objects, PM MIB Loss Measurement Objects, PM MIB Delay Measurement Objects, and SOAM PM Notifications.
These documents’ MIB definitions are also in the Ethernet layer and are the input for the LIME works.
IETF specifies a series MIB module for various technologies, which includes: [RFC7331] for BFD MIB, [RFC4560] for PING MIB, [MPLS-TP OAM ID MIB] for MPLS-TP MIB, etc.
All these documents are technology-specific and limited to layer 1/2/3. The OAM MIB definition above layer 3 (i.e., SFC service layer) is still missing in IETF. Further study is needed to abstract a unified and general OAM data model for any network layers from them and other SDOs’ OAM works.
SOAM CFM YANG module [MEF-38] is an important work that defines the managed objects necessary to support SOAM CFM functionality by using the IETF YANG Module Language [RFC6020]. This YANG module contains the management data definitions for the management of Ethernet Services OAM for Connectivity Fault Management.
[MEF-39] provides the YANG module that supports the Ethernet Service OAM (SOAM) Performance Monitoring functions. This YANG module contains the management data definitions for the management of Ethernet Services OAM for Performance Monitoring and extends the Connectivity Fault Management (CFM) YANG modules.
These MEF OAM YANG works are important reference for the LIME works.
[I-D.tissa-netmod-oam] is an IETF work that creates a YANG unified data model for OAM that is based on IEEE CFM model. This model may be used also for IP OAM functionality. This effort is focused on the management plane of OAM and should be complemented by an accompanying data-plane and/or control-plane work. It may require also some extensions to support wider variety of functions and technologies.
[I-D.tissa-nvo3-yang-oam] extends the Generic YANG model defined in [I-D.tissa-netmod-oam] for OAM with NVO3 technology specifics and presents Yang Module for NVO3 OAM.
Until now, all the OAM data models and operations in the management plane are technology dependent and limited to one specific layer.
Consolidation means here the management functions are capable of receiving and reacting to related information from every transport segment at every layer in the network. The reacting to related information from every layer can include:
However, there is little consolidation of OAM in management plane nor well-documented inter-layer OAM operations within current MIB definition works by IEEE, MEF or IETF, and YANG model definition work by MEF. This also results in an end to end and service-level OAM view of network is hardly generated in the management plane.
In addition to consolidation, a layer and technology independent OAM view of network is also important for multi-layer OAM. The challenge to get this view is to abstract in a way that retains in the management plane as much useful information as possible while filtering the data that is not needed to be leaked to layers in the data plane. An important part of this effort is a clear understanding of what information is actually needed. Current existing OAM works in various SDOs do not consider this issue now.
Another aspect is about the OAM data model specification. The existing traditional implementations of data models in management plane, such as MIB, YANG, are all technology-specific. They specify the MIB module or YANG model for specific technology respectively. There are many overlapping contents and repeated works during specify data model for any technologies. The same condition happens each time when a new technology needs to specify its own data model in management plane.
So, a generic and reusable OAM data model is essential and valuable for this kind of work. And to the extent that management operations are being redesigned in terms of YANG modules [RFC6020] over NETCONF [RFC6241], the opportunity appears to use the concept of layer and technology independent abstraction to extract the reusable parts, simplifying the work on the remainder.
TBD.