Operations and Management Area Working Group Q. Wu
Internet-Draft M. Wexler
Intended status: Informational Huawei
Expires: December 31, 2014 M. Boucadair
France Telecom
S. Aldrin
Huawei USA
G. Mirsky
Ericsson
P. Jain
Nuage Networks
June 29, 2014
Problem Statement and Architecture for Transport-Independent Multiple
Layer OAM
draft-ww-opsawg-multi-layer-oam-01.txt
Abstract
Operations, Administration, and Maintenance (OAM) mechanismsare
critical building blocks in network operations that are used for
service assurance, fulfillment, or service diagnosis,
troubleshooting, and repair. The current practice is that many
technologies rely on their own OAM protocols that are exclusive to a
given layer. There is little consolidation of OAM in either data
plane or management plane nor well-documented inter-layer OAM
operations. Vendors and Operators dedicate significant resources and
effort through the whole OAM life-cycle each time when a new
technology is (to be) introduced. This is even exacerbated when
dealing with integration of OAM across multiple technologies.
This document describes the problem space and defines an architecture
for the generic and integrated OAM with a focus of multi-layer and
cross-layer considerations.
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
Wu, et al. Expires December 31, 2014 [Page 1]
Internet-Draft Multi-Layer OAM June 2014
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 December 31, 2014.
Copyright Notice
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Acronyms and Abbreviations . . . . . . . . . . . . . . . 6
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Use of Existing Protocols . . . . . . . . . . . . . . . . 7
3.2. Strong Technology dependency . . . . . . . . . . . . . . 8
3.3. Weakness of Cross-Layer OAM . . . . . . . . . . . . . . . 8
3.4. Lack of OAM above Layer 3 . . . . . . . . . . . . . . . . 9
3.5. Issues of Abstraction . . . . . . . . . . . . . . . . . . 9
3.6. Issue of OAM Information Gathering from Layers Covering
Heterogeneous Network Technologies . . . . . . . . . . . 10
3.6.1. Focus on Service Function Chaining . . . . . . . . . 10
4. Architecture Overview . . . . . . . . . . . . . . . . . . . . 11
5. Existing Work . . . . . . . . . . . . . . . . . . . . . . . . 12
6. Architectural Consideration . . . . . . . . . . . . . . . . . 13
6.1. Basic Components . . . . . . . . . . . . . . . . . . . . 13
6.1.1. Overlay OAM . . . . . . . . . . . . . . . . . . . . . 13
6.1.2. OAM at the top of Layer 3 . . . . . . . . . . . . . . 13
6.2. OAM Functions in the Data Plane . . . . . . . . . . . . . 13
6.2.1. Continuity Check . . . . . . . . . . . . . . . . . . 13
6.2.2. Connectivity Verification . . . . . . . . . . . . . . 13
6.2.3. Path Discovery . . . . . . . . . . . . . . . . . . . 14
6.2.4. Performance Measurement . . . . . . . . . . . . . . . 14
6.2.5. Protection Switching Coordination . . . . . . . . . . 14
6.2.6. Alarm/defect Indication . . . . . . . . . . . . . . . 14
6.2.7. Maintenance Commands . . . . . . . . . . . . . . . . 14
Wu, et al. Expires December 31, 2014 [Page 2]
Internet-Draft Multi-Layer OAM June 2014
6.3. OAM in Management Plane . . . . . . . . . . . . . . . . . 14
7. Building on Existing Protocols . . . . . . . . . . . . . . . 15
8. Scoping Future Work . . . . . . . . . . . . . . . . . . . . . 15
9. Manageability Considerations . . . . . . . . . . . . . . . . 16
10. Security Considerations . . . . . . . . . . . . . . . . . . . 16
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
12.1. Normative References . . . . . . . . . . . . . . . . . . 16
12.2. Informative References . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction
Operations, Administration, and Maintenance (OAM) mechanisms being
understood and used in context of RFC 6291 [RFC6291] are critical
building blocks in network operations that are used for service
assurance, fulfillment, or service diagnosis, troubleshooting, and
repair. The key foundations of OAM and its functional roles in
monitoring and diagnosing the behavior of networks have been studied
at OSI layers 1, 2 and 3 since a while. As a reminder, OAM functions
are used in many management applications for various objectives such
as (i) failure detection, (ii) reporting the defect/ failure
information, (iii) defect/failure localization, (iv) performance
monitoring, and (v) service recovery.
The current practice that consists in enabling OAM techniques for
each layer has shown its limits; this is a need for cross-layer and
inter-layer OAM considerations [RFC7276]. This need for inter-layer
OAM is motivated by the need to achieve: network optimization,
efficient enforcement of TE (Traffic Engineering) techniques
including ensuring path diversity at distinct layers or computing
completely disjoint paths at several layers, fine-grain tweaking,
ease of root cause analysis, ability to maintain a network-wise
visibility in addition to layer-specific one, etc.
It is worth to mention also that there are two restrictions for
multi-layer structure as discussed in [RFC7276]:
o Each layer has its own OAM protocol, OAM should not cross layer
boundaries.
o Each layer OAM used at different level of hierarchy in the
network.
Moreover, there is little consolidation of OAM in either data plane
or management plane. Vendors and operators dedicate a lot resources
and effort through the whole OAM life-cycle each time a new
technology is (to be) introduced. Integration of OAM across multiple
Wu, et al. Expires December 31, 2014 [Page 3]
Internet-Draft Multi-Layer OAM June 2014
technologies in either data plane or management plane is extremely
difficult to achieve.
When operating networks with more than one technology, maintenance
and troubleshooting are achieved per technology and per layer,
operation process can be very cumbersome since OAM is not defined to
cross layer boundaries. Another challenge is presented by use of
different technologies and corresponding OAM on the same layer of
adjacent network domains. Interworking between different OAM often
not defined and are left to proprietary solutions. In many cases
when keeping network complexity down and simplifying OAM is needed,
it is desirable to have a generic and integrated OAM to cover
heterogeneous networking technologies.
This document defines the problem space and describes an architecture
for the generic and integrated OAM in the multi-layer and multi-
domain networks. In particular, it outlines the problems encountered
with existing OAM protocols and their impact on introduction of new
technologies (see Section 3).
This document covers the following:
o Data plane OAM consolidation by looking at the common active OAM
functions (including, Connectivity Verification (CV), Path
Verification and Continuity Checks (CC), Path Discovery,
Performance Measurement) necessary to monitor and diagnose a
network;
o Management plane consolidation by interacting with data plane OAM
and abstracting OAM information common to different layer via
uniformed interface.
2. Terminology
This document defines the following terms:
Transport Independent Multi-Layer OAM :
In an multi-layer network, transport independent OAM is OAM that
can be deployed independent of media, data protocols, and routing
protocols It denotes the ability to exchange OAM information
across layers and domains between nodes along forwarding path, and
gather OAM information that are common to different layers and
expose it to the management application through a unified
interface. These aspects are not specific to a given transport
technology.
OAM function :
Wu, et al. Expires December 31, 2014 [Page 4]
Internet-Draft Multi-Layer OAM June 2014
Refers to the atomic building blocks of OAM; an OAM function
defines an OAM capability (See section 2.2.3 of [RFC7276]).
OAM protocol :
Refers to a protocol used for implementing one or more OAM
functions (See section 2.2.3 of [RFC7276]).
OAM tool :
Denotes a specific means of applying one or more OAM functions.
An OAM protocol can be an OAM tool. An OAM tool can use a set of
OAM protocols or a set of protocols that are not strictly OAM
related (See section 2.2.3 of [RFC7276]).
OAM packet :
Refers to a packet generated at Maintenance Point using an OAM
protocol. An OAM packet, which carries OAM information, is
usually forwarded through the same route/path as the data traffic
and receive the same (forwarding) treatment.
Maintenance Domain (MD):
Refers to the part of a network whereOAM function is performed
(initiated).
Maintenance Point (MP):
Is a generic functional entity that is associated with a
particular MD, defined at a specific layer of a network and can
initiate and/or react to OAM packets.
Maintenance Endpoint (MEP):
Is an endpoint MP that initiates OAM packets and responds to them.
Maintenance Intermediary Point(MIP):
In between MEPs, there are zero or more intermediate points,
called Maintenance Intermediary Point. A Maintenance Intermediary
Point (MIP) is an intermediate MP that does not generally initiate
OAM packets but is able to respond to OAM packets that are
destined to it.
Network Element (NE) :
Wu, et al. Expires December 31, 2014 [Page 5]
Internet-Draft Multi-Layer OAM June 2014
Denotes a physical or virtual network device/function that
connects directly to the network. NE can host MPs and provide
network connectivity to one or many MPs.
2.1. Acronyms and Abbreviations
CC - Continuity Check
CV - Connectivity Verification
SNMP - Simple Network Management Protocol
NETCONF - Network Configuration
ETH - Ethernet
APS - Automatic Protection Switching
LT - LinkTrace
RDI - Remote Defect Indication
AIS - Alarm indication Signal
OWAMP - One Way Active Measurement Protocol
TWAMP - Two Way Active Measurement Protocol
CFM - Connectivity Fault Management
3. Problem Statement
OAM mechanisms are usually oriented toward a single network
technology or a single layer. Each technology or layer has its best
suited OAM tools. Some of them providing rich functionality rely on
the capabilities of one protocol, while the others provide each
function with a different protocol; In the current situation, there
is little, or no re-use, of software and hardware for each OAM
protocol.
Integration of OAM across multiple technologies is extremely
difficult. Vendors and operators waste a lot through the whole OAM
life-cycle when a new technology is introduced:
(1) Design and development: For every new protocol there is a need
to invest in complete life-cycle (i.e.,the design and development
of data, control and management planes). In some cases, even
Wu, et al. Expires December 31, 2014 [Page 6]
Internet-Draft Multi-Layer OAM June 2014
adding a single OAM function requires the above complete life-
cycle.
(2) Operation and Maintenance: There is a need to re-train
operation people for almost every newly introduced technology or
feature. The above causes a slow time-to-market and a waste of
time and effort for any new technology and/or OAM function.
Specifically, in Service Function Chaining environment, every Service
Function may operate at a different layer and may use different
encapsulation and tunneling techniques. When taking into account
virtualization related technologies, the number of encapsulation and
tunneling options increase even more. Still, end-to-end service OAM
mechanisms and information exchanges between Service Functions should
be provided to operate and maintain the network as a whole. This
requires a generic toolkit that can provide all necessary tools in
context of multi-technology, multi-layer, physical and virtual
environments.
A particular problem is how OAM information at different layer is
made available to a management application for use and learnt via the
unified management interface. For example, in the case of an multi-
layer network, OAM information needs to be imposed to the packet and
injected into the network and at last abstracted from various layers
and expose them to the management application.
3.1. Use of Existing Protocols
OAM information resides at each layer and may currently be exchanged
at each network layer in a domain by using various encapsulation
technologies at the Layer 2 & Layer 3 levels. OAM information may be
gathered and exported from a domain (for example, northbound) using
SNMP [RFC3411]or NETCONF/YANG [RFC6241].
It is desirable that a solution to the problem described in this
document does not require the implementation of a new, network-wide
protocol or introduce a shim layer to carry OAM information.
Instead, it would be advantageous to make use of an existing
protocols or functionalities that are commonly implemented and are
currently deployed in operational networks. This has many benefits
in network stability, time to deployment, and operator training.
It is recognized, however, that existing protocols or functionalities
are unlikely to be immediately suitable to this problem space without
some protocol extensions. Extending protocols must be done with care
and with consideration for the stability of existing deployments. In
extreme cases, when there is a lack of functionality, although
Wu, et al. Expires December 31, 2014 [Page 7]
Internet-Draft Multi-Layer OAM June 2014
similar mechanisms exist in other technologies, a new protocol can be
preferable to a "messy" hack of an existing protocol.
3.2. Strong Technology dependency
OAM protocols are relying heavily on the specific network technology
they are associated with. For example, ICMP, LSP Ping are using
different network technologies but provide the same OAM
functionality, i.e., Path Discovery. Another example is BFD,LSP Ping
are using different network technologies but provide the same
functionality, i.e., Continuity Verification. Figure 1 shows common
OAM functionalities shared by various existing OAM protocols.
|--------+------------+--------------+--------------+------------+
| |Continuity | Connectivity| Path | Performance|
| | Check | Verification| Discovery | Measurement|
+--------+------------+--------------+--------------+------------+
| | | | |-Delay |
| ICMP | Echo(Ping) | Echo(Ping) | Traceroute |-Loss rough |
| | | | | measurement|
+--------+------------+--------------+--------------+------------+
| | | | | |
| BFD | BFD | BFD Echo | | |
| | Control | | | |
+--------+------------+--------------+--------------+------------+
| LSP | | | | - Delay |
| Ping | | Ping | Traceroute | - Packet |
| | | | | Loss |
+--------+------------+--------------+--------------+------------+
| | | | | -OWAMP |
| IPPM | | | | -TWAMP |
| | | | | |
|--------+------------+--------------+--------------+------------+
| MPLS-TP| | | | |
| OAM | CC | CV | Traceroute | -Delay |
| |(use of BFD)|(use of BFD) | | -Packet |
| | | | | Loss |
+--------+------------+--------------+--------------+------------+
Figure 1.Examples of OAM tools
3.3. Weakness of Cross-Layer OAM
Troubleshooting is cumbersome due to protocol variety and lack of
multi-layer OAM. Usually OAM messages should not cross layer
boundaries. Each of the service, network and transport layers
possesses its well-discernable and native OAM stream. In addition,
OAM messages should not be leaked outside of a management domain
Wu, et al. Expires December 31, 2014 [Page 8]
Internet-Draft Multi-Layer OAM June 2014
within a layer, where a management domain is governed by a single
business organization. When having networks with more than one
technology, maintenance and troubleshooting are done per technology
and layer.
These rules could in some cases ease the understanding in which
technology the operation is done or fault is located. In some cases,
when one layer OAM fails, it may be desirable to drop down to the
another layer OAM and issue the corresponding OAM command, using the
same APIs, if OAM in multiple layers can be supported. However, in
most cases switching tools and layers in the same operation process
is cumbersome and not serving the main idea - to find the root cause
location. It would be very helpful to have a generic mechanisms that
is end to end basis, allow management application interact with data
plane OAM and can ping IPv4 host by an IPv6 source or having one tool
to troubleshoot combined IP, MPLS, Ethernet, GRE and VXLAN network.
In Service Function Chaining environment, it is necessary to provide
end-to-end OAM across certain or all entities and involving many
layers. Inter-layer OAM considerations are key in an SFC context
because problems may occur at the network layer or at the service
chaining layer.
3.4. Lack of OAM above Layer 3
The Layer 2/3 OAM protocols are quite rich in their functionality,
well defined, standardized and heavily used. In the last years a lot
of work was conducted to consider maintenance domains and levels in
order to better handle the issues of technology re-use, smooth
interoperability and interworking between domains.
The above mechanisms are not defined for the technologies above Layer
3. Therefore, in the SFC environment where a Service Function
Chaining is composed by a set of Service Functions, but providing an
end-to-end chain or path from a source to destination in a given
order [I.D-ietf-sfc- problem- statement], no standard exists as a
reference for OAM since when the service packets is steered through a
set of service nodes distributed in the network, each service node
may act at different layers above layer 3.
3.5. Issues of Abstraction
In multi-layer network, OAM functions are enabled at different layers
and various OAM information needs to be gathered from various layers.
Without multi-layer OAM in place, it is hard for management
applications to understand what information at different layers
stands for. One possible solution to these issues is to abstract the
OAM information shared across layers, i.e., using the same tool or
Wu, et al. Expires December 31, 2014 [Page 9]
Internet-Draft Multi-Layer OAM June 2014
API to activate the OAM functions at different layers and retrieve
the results.
The challenge is to abstract in a way that retains as much useful
information as possible while filtering the data that is not needed
to be leaked to other layers. An important part of this effort is a
clear understanding of what information is actually needed.
3.6. Issue of OAM Information Gathering from Layers Covering
Heterogeneous Network Technologies
In SFC, the service packets are steered through a set of service
nodes distributed in the network. In the NVO3 network, the data
packet may also traverse a set of overlay nodes distributed in the
network. Overlay technologies or other tunneling technologies can be
used to stitch these service nodes or overlay node in order to form
end to end path.
When any overlay Segment or segment of service chain fails to deliver
user traffic, there is a need to provide a tool that would enable
users to detect such failures, and a mechanism to isolate faults. It
may also be desirable to test the data path before mapping user
traffic to the Overlay Segment or segment of service chain.
3.6.1. Focus on Service Function Chaining
When the service packets are steered through a set of service nodes
distributed in the network, each service node may work at different
layer above layer 3 and may have several SFs collocated with itself.
When OAM mechanism is applied, it is necessary to allow OAM packet To
be exchanged between these service nodes or service function at
different layers. When Service functions that are part of the SFC
doesn't support OAM capability(e.g., an SFC-unaware service
function), service node should be responsible for monitoring and
diagnosing and reporting service availability to the service
function. It is more desirable to allow a service function register
with service node. Either service function reports status to service
node or service node performs live check of the service function.
In addition, service functions usually don't have Layer 2-3
switching/routing capability and therefore are not aware of any OAM
function at Layer 2-3. Also when there are no OAM functions at
service Layers above layer 3, it is hard to identify layer that can
be used to gather OAM information when it comes to a fault situation
or degradation of performance. For example, when a data packet is
transmitted from one service function to another service function and
the data packet may be lost between two service functions or
discarded by either of them. Consider when two service functions are
Wu, et al. Expires December 31, 2014 [Page 10]
Internet-Draft Multi-Layer OAM June 2014
embedded in (associated with) two different service nodes, how to
detect the fault between them and how to isolate problem to that
layer?
Editor's Note: Section 3.6.1 is too specific. This text can be
presented as an example to illustrate a problem not a problem per se
or moved to a use case draft.
4. Architecture Overview
Figure 2 shows the reference architecture for Layering OAM. This
reference architecture assumes that
o Any network element can use different technologies and
corresponding OAM on the same layer at the boundary of two
adjacent domains
o Any two network element may provide service delivery at different
layer
o Management entity can manage network devices in more than one
maintenance domains.
In this architecture, three layers are defined:
M1: "Data Plane layer"
M2: "Management Plane layer"
M3: "Service Plane layer"
In the M1 layer, a typical network can be partitioned into several
domains. Each domain has at least two MEPs and none or one to more
MIPs. MEP is a maintenance functional entity that is implemented
into a Network Element either at the maintenance domain boundary or
in the maintenance domain and can generate, send and receive OAM
packets. MIP is a maintenance functional entity that is implemented
into a Network Element in the maintenance domain and can forward OAM
packets. Either MEP or MIP may be at different layer and use various
different encapsulating protocols.
The M2 contains the interface which management entity uses to manage
individual network devices. In this document, we further require
management entities to use this interface as uniform interface (API
and or UI) to gather OAM information from MEP and MIP in the network
devices(either physical or virtual entity) and execute transactions
or operations on MEP and MIP across domains, layers and vendors.
Protocols that can be used to manipulate the configuration of a
Wu, et al. Expires December 31, 2014 [Page 11]
Internet-Draft Multi-Layer OAM June 2014
network device include SNMP [RFC1157], Command Line Interfaces,
NETCONF [RFC6241], and other protocols.
On the M3 layer, there is a uniform interface (API and/or UI) that
covers all the managed devices and can execute network-wide
transactions. This layer allows applications and operators to
execute configuration, monitoring and action tasks across multiple
network devices, from a mix of domains, layers, vendors. Still the
abstraction level is that of the network elements themselves, so
whatever configuration, status, actions and notifications they
provide, that is what you get here, but without having to worry about
the location and the protocol to reach the device.
Service +-------------------+
---- Plane | Customer |
^ Layer +-------------------+
|
| +-------------+ +-------------+
V | Management | | Management |
---Management | Entity | | Entity |
^ Plane +-------------+ +-------------+
| Layer
|
|
| |----------------------------+ +---------------------+
| |Maintenance Domain 1 | |Maintenance Domain 2 |
| | | | |
| | | | |
| NE| NE NE NE| | NE NE |
V +-----+ +-----+ +-----+ +------+ +-----+ +--+--+
---- | MEP +----+ MIP +--| MIP +----| MEP +-----| MIP +-----+ MEP |
+-----+ +-----+ +-----+ ++----++ +-----+ +-----+
Data Plane | | |
Layer | | |
+----------------------------+ +---------------------+
Figure 2 Architecture for Layering OAM in the management plane
An example of service-specific that depicts OAM layers can be found
in [RFC4176] (L3VPN case).
5. Existing Work
The following discuss related IETF work and is provided for
reference. This section is not exhaustive, rather it provides an
overview of few initiatives focusing on the pain-points of OAM:
Wu, et al. Expires December 31, 2014 [Page 12]
Internet-Draft Multi-Layer OAM June 2014
1. [I-D.tissa-netmod-oam] is an important 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 address wider variety of
functions and technologies.
2. Several contributions conducted in the past years, had tried to
address new technologies using existing mechanisms. [I-D.jain-
nvo3-overlay- oam] and MPLS-TP OAM documents are only examples
for such efforts.
6. Architectural Consideration
6.1. Basic Components
6.1.1. Overlay OAM
6.1.2. OAM at the top of Layer 3
6.2. OAM Functions in the Data Plane
Many OAM functions may require protocol extensions or new protocol
development to meet the transport requirements. In the existing OAM
tools, Some of them providing rich functionality in one protocol,the
other providing each function with a different protocol and each
technology is developed independently.
To consolidate OAM in the data plane, the OAM in multi-layer
Environment is expect to support the following common OAM functions
used in OAM-related standards. These functions are used as building
blocks in the data plane OAM standards described in this document.
6.2.1. Continuity Check
This type of mechanisms check that the monitored layer and/or entity
are alive and providing path from specific point(s) to other
point(s). Some examples are IP Ping, BFD [RFC5880] and ETH CC.
6.2.2. Connectivity Verification
Verifying that the actual connection is consistent with the required
connection and no misconnection occurred. Some examples are IP Ping,
and ETH loopback.
Wu, et al. Expires December 31, 2014 [Page 13]
Internet-Draft Multi-Layer OAM June 2014
6.2.3. Path Discovery
Used to discover the path that specific service traverses in the
network. Some examples are LSP Traceroute, IP Traceroute and ETH-LT/
linktrace.
6.2.4. Performance Measurement
A function that monitors the performance parameters of a network
entity. Such parameters could be Delay, Delay-variation, loss,
availability of services and class of services. Examples are
TWAMP[RFC5357]/ OWAMP[RFC4656] and Y.1731,MPLS Loss and Delay
Measurement [RFC6374].
6.2.5. Protection Switching Coordination
A function that is used to signal protection switching states and
commands. Examples are ETH APS messages and MPLS-TP Protection
Switching Coordination OAM [RFC6378].
6.2.6. Alarm/defect Indication
A function that is used to indicate that a failure occurred
downstream or upstream within a connection/service. Used also to
trigger fast protection or to suppress alarms. Examples are ETH AIS
and ETH RDI, MPLS-TP RDI [RFC6428].
6.2.7. Maintenance Commands
A function that is used to signal a maintenance state or command
within a connection/service. Examples can be ETH Lockout.
6.3. OAM in Management Plane
Management systems play an important role in configuring or
provisioning OAM functionality consistently across all devices in the
network, and for automating the monitoring and troubleshooting of
network faults. However OAM is not provision. In general,
provisioning is used to configure the network to provide new
services, whereas OAM is used to keep the network in a state that it
can support already existing services.
As we know each layer has its own OAM protocols. OAM can be used at
different levels of hierarchy in the network to form a multi-layer
OAM solution [RFC7276]. To support multi-layer OAM covering various
heterogeneous transport technologies, the OAM in the management needs
to be consolidated as follows:
Wu, et al. Expires December 31, 2014 [Page 14]
Internet-Draft Multi-Layer OAM June 2014
o OAM information needs to be abstracted that are common to
different layer and different domain.
o Support customized OAM service, e.g., customized service diagnose.
o OAM information is provided to management entity from managed
device via a uniform interface (API and/or UI)
o Sets up MD MEP and MIP in the network provision phase
o Enables basic OAM functionality(e.g., enable the origin of ping
and trace packets or configure Connectivity Fault Management
(CFM)) on the managed devices in the service activation phase.
The different OAM tools may be used in one of two basic types of
activation:
o Proactive activation - indicates that the tool is activated on a
continual basis, where messages are sent periodically, and errors
are detected when a certain number of expected messages are not
received.
o On-demand activation - indicates that the tool is activated
"manually" to detect a specific anomaly.
7. Building on Existing Protocols
8. Scoping Future Work
This section includes a set of candidate items for activities to be
conducted within IETF.
These objectives are not frozen; further discussion is required to
target key issues and scope the work to be conducted within IETF
accordingly.
Candidate investigation items are listed below:
o Understand and discuss situations where an OAM protocol can be
tuned and optimized for a specific data plane.
o OAM consolidation in the data plane:
* Exchange OAM information at the service layer atop of layer 3.
* Deployed over various encapsulating protocols, and in various
medium types
Wu, et al. Expires December 31, 2014 [Page 15]
Internet-Draft Multi-Layer OAM June 2014
o OAM consolidation in the management plane:
* Abstract OAM information common to different layers.
* Expose OAM information via unified interface to management
entities, independently of the layer they belong to.
* Discuss how information gathered from various layers can be
correlated for the sake of network operations optimization
purposes.
* Propose means to help during service diagnosis; these means may
rely on filtering information to be leaked to other layers so
that time recovery can be optimized. A typical example would
be efficient root cause analysis that is fed with input from
various layers.
* Propose means that would help to optimize a network as a whole
instead of the monolithic approach that is specific to a given
layer. For example, investigate means that would help in
computing diverse and completely disjoint paths, not only at
layer 3 but also at the physical layer.
9. Manageability Considerations
10. Security Considerations
Security considerations are not addressed in this problem statement
only document. Given the scope of OAM, and the implications on data
and control planes, security considerations are clearly important and
will be addressed in the specific protocol and deployment documents.
11. Acknowledgements
The authors would like to thank Romascanu, Dan, Tissa Senevirathne
for their valuable reviews and suggestions.
12. References
12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", March 1997.
[RFC6291] Andersson, L., Helvoort, H., Bonica, R., Romascanu, D.,
and S. Mansfield, "Guidelines for the Use of the "OAM"
Acronym in the IETF", RFC 6291, June 2011.
Wu, et al. Expires December 31, 2014 [Page 16]
Internet-Draft Multi-Layer OAM June 2014
[RFC7276] Mizrahi, T. and N. Sprecher, "An Overview of Operations,
Administration, and Maintenance (OAM) Tools", RFC 7276,
June 2014.
12.2. Informative References
[I-D.ietf-sfc-problem-statement]
Quinn, P., Guichard, J., and S. Surendra, "Network Service
Chaining Problem Statement", ID draft-ietf-sfc-problem-
statement, August 2013.
[I-D.jain-nvo3-overlay-oam]
Jain, P., "Generic Overlay OAM and Datapath Failure
Detection", ID draft-jain-nvo3-overlay-oam-01, February
2014.
[I-D.tissa-netmod-oam]
Senevirathne , T., Finn, N., Kumar , D., and S. Salam ,
"YANG Data Model for Operations Administration and
Maintenance (OAM)", ID draft-tissa-netmod-oam-00, March
2014.
[RFC3411] Harrington, D. and R. Presuhn, "An Architecture for
Describing Simple Network Management Protocol (SNMP)
Management Frameworks", RFC 3411, December 2002.
[RFC4656] Shalunov, S., Karp, A., Boote, J., and M. Zekauskas, "A
One-way Active Measurement Protocol (OWAMP)", RFC 4656,
September 2006.
[RFC5357] Hedeyat, K., Krzanowski, R., Morton, A., Yum, K., and J.
Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)",
RFC 5357, October 2008.
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD)", RFC 5880, June 2010.
[RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A.
Bierman, "Network Configuration Protocol (NETCONF)", RFC
6241, June 2011.
[RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay
Measurement for MPLS Networks", RFC 6374, September 2011.
[RFC6378] Weingarten, Y., Bryant, S., Osborne, E., Sprecher, N., and
A. Fuligoli, "Packet Loss and Delay Measurement for MPLS
Networks", RFC 6378, October 2011.
Wu, et al. Expires December 31, 2014 [Page 17]
Internet-Draft Multi-Layer OAM June 2014
[RFC6428] Allan, D., Swallow, G., and J. Drake, "Proactive
Connectivity Verification, Continuity Check, and Remote
Defect Indication for the MPLS Transport Profile", RFC
6428, November 2011.
Authors' Addresses
Qin Wu
Huawei
101 Software Avenue, Yuhua District
Nanjing, Jiangsu 210012
China
Email: bill.wu@huawei.com
Mishael Wexler
Huawei
Riesstr. 25
Munich 80992
Germany
Email: mishael.wexler@huawei.com
Mohamed Boucadair
France Telecom
Rennes 35000
France
Email: mohamed.boucadair@orange.com
Sam Aldrin
Huawei Technologies USA
2330 Central Expressway
NSanta Clara, CA 95051
USA
Email: aldrin.ietf@gmail.com
Greg Mirsky
Ericsson
Email: gregory.mirsky@ericsson.com
Wu, et al. Expires December 31, 2014 [Page 18]
Internet-Draft Multi-Layer OAM June 2014
Pradeep Jain
Nuage Networks
755 Ravendale Drive
Mountain View, CA 94043
USA
Email: pradeep@nuagenetworks.net
Wu, et al. Expires December 31, 2014 [Page 19]