Internet DRAFT - draft-txh-opsawg-lime-gap-analysis
draft-txh-opsawg-lime-gap-analysis
LIME Working Group Y. Tochio
Internet-Draft Fujitsu
Intended status: Informational H. van Helvoort
Expires: October 29, 2015 Hai Gaoming BV
L. Xia
Huawei
April 27, 2015
Gap Analysis for Layer and Technology Independent OAM Management in the
Multi-Layer Environment
draft-txh-opsawg-lime-gap-analysis-03
Abstract
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 gap analysis is not
targeted at L0-L2 transport OAM in ITU-T, either technology specific
or generic across those technologies. Rather, it is intended to
leverage knowledge from that domain for the benefit of developing
generic layer independent OAM management for L3-L7 (and L2.5 MPLS
OAM).
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 April 29, 2015.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
Tochio, et al. Expires October 29, 2015 [Page 1]
Internet-Draft LIME Gap Analysis April 2015
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions used in this document . . . . . . . . . . . . . . 3
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
3. Existing OAM Related Works . . . . . . . . . . . . . . . . . 4
3.1. Survey of ITU-T Work from L0-L2 . . . . . . . . . . . . . 5
3.1.1. Generic L0-L2 . . . . . . . . . . . . . . . . . . . . 5
3.1.2. Technology Specific L0-L2 . . . . . . . . . . . . . . 5
3.2. Management Information Models . . . . . . . . . . . . . . 5
3.3. IEEE CFM MIB . . . . . . . . . . . . . . . . . . . . . . 6
3.4. MEF SOAM FM and PM MIB . . . . . . . . . . . . . . . . . 6
3.5. IETF Technology-specific MIB Series . . . . . . . . . . . 7
3.6. MEF CFM and SOAM YANG Data Model . . . . . . . . . . . . 7
3.7. YANG Model for OAM Management and Technology-specific
extensions . . . . . . . . . . . . . . . . . . . . . . . 7
3.8. Discussion . . . . . . . . . . . . . . . . . . . . . . . 8
4. Security Considerations . . . . . . . . . . . . . . . . . . . 8
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
6. Normative References . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction
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. At present, within the
L0-L2 technology domains, considerable effort has been expended in
ITU-T to establish a coherent approach to OAM, including generic
layer independent principles.
Due to this fact, [I-D.edprop-opsawg-multi-layer-oam-ps] discusses a
valuable direction in management plane by establishing a coherent
approach to OAM information from L2.5-L7 using a centralized
management entity and have a unified and consistent OAM view of
Tochio, et al. Expires October 29, 2015 [Page 2]
Internet-Draft LIME Gap Analysis April 2015
multi-layer networks. 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. Note that current
LIME work focuses on layer-independent and technology-independent
configuration, reporting and presentation for OAM mechanisms in the
context of IP, MPLS, BFD, pseudowires, and Transparent
Interconnection of Lots of Links (TRILL) technology developed by
IETF. The second important objective of LIME is to achieve a layer
and technology independent OAM view of a network and allow management
applications 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 the management plane should be utilized (with
extensions as appropriate to L2.5-L7), from which OAM specific views
can be established, and technology-specific OAM data models can be
developed by mapping from the information model view. A 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. [I-D.king-
opsawg-lime-multi-layer-oam-use-case] lists the key use case for LIME
application.
This draft analyses the existing management plane OAM related work 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.
2. Conventions used in this document
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].
2.1. Terminology
DM Data Model
EMS Element Management System
IM Information Model
NMS Network Management System
Tochio, et al. Expires October 29, 2015 [Page 3]
Internet-Draft LIME Gap Analysis April 2015
MP Maintenance Point [802.1Q]
MEG Maintenance Entity Group [G.8013] [RFC6371]
MEP MEG End Point [G.8013] [RFC6371]
MIP MEG Intermediate Point [G.8013] [RFC6371]
ME Maintenance Entity [G.8013] [RFC6371]
MD Maintenance Domain [802.1Q]
MPLS Multiprotocol Label Switching
NE Network Element
NVO3 Network Virtualization Overlays
OAM Operations, Administration, and Maintenance [RFC6291]
LIME Layer Independent OAM Management [I-D.edprop-opsawg-multi-
layer-oam-ps]
SFC Service Function Chaining
SFF Service Function Forwarder
SDO Standard Developing Organization
3. Existing OAM Related Works
Tochio, et al. Expires October 29, 2015 [Page 4]
Internet-Draft LIME Gap Analysis April 2015
3.1. Survey of ITU-T Work from L0-L2
3.1.1. Generic L0-L2
[G.800] and [G.805] specify the unified and generic functional
architecture of transport networks. [G.806] specifies the generic
processing of transport equipment functions, including handling of
OAM, defect correlation, and alarm suppression, etc. [G.7710]
specifies the generic management requirements for configuration,
fault, and performance (i.e. the C, F, P of FCAPS). [G.gim] is on-
going work in ITU-T to specify the generic management information
model for L0-L2 transport networks.
3.1.2. Technology Specific L0-L2
[G.803], [G.872], [G.8010] and [G.8110.1] specify the functional
architecture respectively for SDH, OTN, Ethernet, MPLS-TP transport
networks. [G.783], [G.798], [G.8021] and
[G.8121]/[G.8121.1]/[G.8121.2] specify respectively the processing of
transport equipment functions for SDH, OTN, Ethernet, MPLS-TP,
including handling of OAM, defect correlation, and alarm suppression,
etc. [G.784], [G.874], [G.8051] and [G.8151] specify respectively
the management requirements for configuration, fault, and performance
(i.e. the C, F, P of FCAPS). [G.774], [G.874.1], [G.8052] and
[G.8152] specify respectively the management information model for
SDH, OTN, Ethernet, MPLS-TP transport networks.
3.2. Management Information Models
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. The
management information models are derived from the "functional
models", which describe the data plane behavior and processing.
Management information models manage the "atomic functions" defined
in the data plane in transport networks. They contain the object
classes for the Ethernet and MPLS-TP NE management. This includes
the Termination Point (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. There
is already some degree of consolidation among the /L0 (OTN)
[G.874.1], (SDH) [G.774]/, /L1 (OTN) [G.874.1], (SDH) [G.774]/ and
/L2 (Ethernet) [G.8052], (MPLS-TP) [G.8152]/ information models
specified by these ITU-T recommendations. In fact, they have a
Tochio, et al. Expires October 29, 2015 [Page 5]
Internet-Draft LIME Gap Analysis April 2015
common basis for information model and are not technology-specific
models any more.
[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, ,etc), Fault Management Objects (e.g.,
Continuity Check, Loopback, etc.), Performance Monitoring Objects
(e.g., Loss Measurement, Delay Measurement, etc.).
3.3. IEEE CFM MIB
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).
3.4. MEF SOAM FM and PM MIB
[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 [G.8013] and IEEE [802.1Q].
The SOAM PM MIB is divided into a number of different object
Tochio, et al. Expires October 29, 2015 [Page 6]
Internet-Draft LIME Gap Analysis April 2015
groupings: the PM MIB MEP Objects, PM MIB Loss Measurement Objects,
PM MIB Delay Measurement Objects, and SOAM PM Notifications.
3.5. IETF Technology-specific MIB Series
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 L1, L2,
L3. The OAM MIB definition above L3 (i.e., SFC service layer) is
still missing in IETF.
3.6. MEF CFM and SOAM YANG Data Model
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.
3.7. YANG Model for OAM Management and Technology-specific extensions
[I-D.tissa-lime-yang-oam-model], [I-D.wang-lime-rpc-yang-oam-
management] are two IETF work that creates a YANG unified data models
for OAM that is based on IEEE CFM model. [I-D. tissa-lime-yang-oam-
model] defines a YANG [RFC6020] data model for Layer independent OAM
Management implementations that can be applied to various network
technologies. [I-D.wang-lime-rpc-yang-oam-management] describes the
abstract notification and rpc command to the YANG Module which is
complementary to the one defined in the [I-D.tissa-lime-yang-oam-
model]. These efforts are 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-lime-yang-oam-model] for OAM with NVO3 technology
specifics and presents Yang Module for NVO3 OAM.
[I-D.xia-sfc-yang-oam] extends the Generic YANG model defined [I-
D.tissa-lime-yang-oam-model], [I-D.wang-lime-rpc-yang-oam-management]
Tochio, et al. Expires October 29, 2015 [Page 7]
Internet-Draft LIME Gap Analysis April 2015
for OAM with SFC technology specifics and presents YANG Module for
SFC OAM.
[I-D.wang-bfd-yang-oam]extends the Generic YANG model defined in [I-
D.tissa-lime-yang-oam-model], [I-D.wang-lime-rpc-yang-oam-management]
for OAM with BFD technology specifics and present YANG Module for BFD
OAM.
3.8. Discussion
Until now, all the OAM models and operations in the management plane
for L3-L7 are technology dependent and limited to one specific layer.
One point which should be noticed is that the information models
specified for transport networks (L0/L1/L2, [G.874.1], [G.8052],
[G.8152] ) by the ITU-T have received some degree of consolidation,
and are not technology dependent. [I-D. lam-lime-summary-l0-l2-
layer-independent] provides the summary on this point.
4. Security Considerations
TBD.
5. Acknowledgements
The authors would like to thank for Eve Varma, Maarten Vissers for
their valuable comments and thoughtful inputs to this draft regarding
ITU-T OAM works in L0-L2.
6. Normative References
[G.774] "Synchronous digital hierarchy (SDH) - Management
information model for the network element view", ITU-T
G.774, February 2001.
[G.783] "Characteristics of synchronous digital hierarchy (SDH)
equipment functional blocks", ITU-T G.783, March 2006.
[G.784] "Management aspects of synchronous digital hierarchy (SDH)
transport network elements", ITU-T G.784, March 2008.
[G.798] "Characteristics of optical transport network hierarchy
equipment functional blocks", ITU-T G.798, December 2012.
[G.800] "Unified functional architecture of transport networks",
ITU-T G.800, February 2012.
[G.8010] "Architecture of Ethernet layer networks", ITU-T G.8010,
February 2004.
Tochio, et al. Expires October 29, 2015 [Page 8]
Internet-Draft LIME Gap Analysis April 2015
[G.8013] "OAM functions and mechanisms for Ethernet based
networks", ITU-T G.8013/Y.1731, February 2013.
[G.8021] "Characteristics of Ethernet transport network equipment
functional blocks", ITU-T G.8021, January 2015.
[G.803] "Architecture of transport networks based on the
synchronous digital hierarchy (SDH)", ITU-T G.803, March
2000.
[G.805] "Generic functional architecture of transport networks",
ITU-T G.805, March 2000.
[G.8051] "Management aspects of the Ethernet Transport (ET) capable
network element", ITU-T G.8051, August 2013.
[G.8052] "Protocol-neutral management information model for the
Ethernet transport capable network element", Draft
Recommendation ITU-T G.8052/Y.1346, August 2013.
[G.806] "Characteristics of transport equipment - Description
methodology and generic functionality", ITU-T G.806,
February 2012.
[G.8110.1]
"Architecture of MPLS Transport Profile (MPLS-TP) layer
network", ITU-T G.8110.1/Y.1370.1, December 2011.
[G.8121] "Characteristics of MPLS-TP equipment functional blocks",
ITU-T G.8121, November 2013.
[G.8121.1]
"Characteristics of MPLS-TP equipment functional blocks
supporting ITU-T G.8113.1/Y.1372.1 OAM mechanisms", ITU-T
G.8121.1, November 2013.
[G.8121.2]
"Characteristics of MPLS-TP equipment functional blocks
supporting ITU-T G.8113.2/Y.1372.2 OAM mechanisms", ITU-T
G.8121.2, November 2013.
[G.8151] "Management aspects of the MPLS-TP network element", ITU-T
G.8151, January 2015.
[G.8152] "Protocol-neutral management information model for the
MPLS-TP network element", Draft Recommendation ITU-T
G.8152/Y.1375, 2016.
Tochio, et al. Expires October 29, 2015 [Page 9]
Internet-Draft LIME Gap Analysis April 2015
[G.872] "Architecture of optical transport networks", ITU-T G.872,
Octorber 2012.
[G.874] "Management aspects of optical transport network
elements", ITU-T G.874, August 2013.
[G.874.1] "Optical transport network: Protocol-neutral management
information model for the network element view", ITU-T
G.874.1, Octorber 2012.
[I-D.edprop-opsawg-multi-layer-oam-ps]
Taylor, T., "Problem Statement for Layer and Technology
Independent OAM in a Multi-Layer Environment", ID draft-
edprop-opsawg-multi-layer-oam-ps (Exipred), September 2014.
[I-D.ietf-mpls-tp-oam-id-mib]
Aldrin, S., Mahalingam, V., Sampath, K., and T. Nadeau,
"MPLS-TP Operations, Administration, and Management (OAM)
Identifiers Management Information Base (MIB)", draft-
ietf-mpls-tp-oam-id-mib-08 (work in progress), February 2015.
[I-D.king-opsawg-lime-multi-layer-oam-use-case]
King, D. and D. King, "Use Cases and Requirements for
Layer Independent OAM Management in multi-layer
environments", ID draft-king-opsawg-lime-multi-layer-oam-
use-case (Exipred), September 2014.
[I-D.tissa-lime-yang-oam-model]
Senevirathne, T., Finn, N., Kumar, D., Salam, S., and Q.
Wu, "Generic YANG Data Model for Operations,
Administration, and Maintenance (OAM)", draft-tissa-lime-
yang-oam-model-04 (work in progress), April 2015.
[I-D.tissa-nvo3-yang-oam]
Senevirathne, T., "YANG Data Model for NVO3 Operations,
Administration, and Maintenance(OAM)", ID draft-tissa-
nvo3-yang-oam-00 (Exipred), June 2014.
[I-D.wang-bfd-yang-oam]
Wang, Z., "A YANG Data Model for BFD Operations,
Administration, and Maintenance (OAM)", ID draft-wang-bfd-
yang-oam-01, March 2015.
[I-D.wang-lime-rpc-yang-oam-management]
Wang, Z., "Additional RPC definitions to Generic YANG Data
Model for layer Independent OAM Management", ID draft-
wang-lime-rpc-yang-oam-management-02, March 2015.
Tochio, et al. Expires October 29, 2015 [Page 10]
Internet-Draft LIME Gap Analysis April 2015
[I-D.xia-sfc-yang-oam]
Xia, L., "YANG Data Model for SFC Operations,
Administration, and Maintenance (OAM)", ID draft-xia-sfc-
yang-oam-02, March 2015.
[I-D. lam-lime-summary-l0-l2-layer-independent]
K. Lam., "Existing Support for Network Operations in
Multilayer Transport Network based upon unified approach to
OAM (Layer 0 - Layer 2)", ID draft-lam-lime-summary-l0-l2-
layer-independent-02, April 2015.
[IEEE802.1Q]
"Media Access Control (MAC) Bridges and Virtual Bridged
Local Area Networks", IEEE Std 802.1Q-2014, November 2014.
[MEF-30] "Service OAM Fault Management Implementation Agreement",
MEF 30, January 2011.
[MEF-31] "Service OAM Fault Management Definition of Managed
Objects", MEF 31, January 2011.
[MEF-35] "Service OAM Performance Monitoring Implementation
Agreement", MEF 35, January 2012.
[MEF-36] "Service OAM SNMP MIB for Performance Monitoring", MEF 36,
January 2012.
[MEF-38] "Service OAM Fault Management YANG Modules", MEF 38, April
2012.
[MEF-39] "Service OAM Performance Monitoring YANG Module", MEF 39,
April 2012.
[MEF-7.1] "EMS-NMS Information Model -Phase 2", Metro Ethernet Forum
MEF 7.1, 2009.
[Q.840.1] "Requirements and Analysis for NMS-EMS Management
Interface of Ethernet over Transport and Metro Ethernet
Network", Draft Recommendation ITU-T Q.840.1, 2007.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", March 1997.
[RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the
Network Configuration Protocol (NETCONF)", RFC 6020,
October 2010.
[RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu,
D., and S. Mansfield, "Guidelines for the use of the "OAM"
Acronym in the IETF", RFC 6291, June 2011.
[RFC6371] Busi, I. and D. Allan, "Operations, Administration, and
Maintenance Framework for MPLS-Based Transport Networks",
RFC 6371, September 2011.
Tochio, et al. Expires October 29, 2015 [Page 11]
Internet-Draft LIME Gap Analysis April 2015
[RFC7331] Nadeau, T., Ali, Z., and N. Akiya, "Bidirectional
Forwarding Detection (BFD) Management Information Base",
RFC 7331, August 2014.
Authors' Addresses
Yuji Tochio
Fujitsu
Email: tochio@jp.fujitsu.com
Huub van Helvoort
Hai Gaoming BV
The Netherlands
Email: huubatwork@gmail.com
Liang (Frank) Xia
Huawei
101 Software Avenue, Yuhua District
Nanjing, Jiangsu 210012
China
Email: Frank.xialiang@huawei.com
Tochio, et al. Expires October 29, 2015 [Page 12]
