One document matched: draft-ww-opsawg-multi-layer-oam-02.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- edited with XMLSPY v5 rel. 3 U (http://www.xmlspy.com)
by Daniel M Kohn (private) -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
]>
<rfc category="info" docName="draft-ww-opsawg-multi-layer-oam-02.txt"
ipr="trust200902">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<front>
<title abbrev="Multi-Layer OAM">Problem Statement and Architecture for
Transport-Independent Multiple Layer OAM</title>
<author fullname="Qin Wu" initials="Q." surname="Wu">
<organization>Huawei</organization>
<address>
<postal>
<street>101 Software Avenue, Yuhua District</street>
<city>Nanjing</city>
<region>Jiangsu</region>
<code>210012</code>
<country>China</country>
</postal>
<email>bill.wu@huawei.com</email>
</address>
</author>
<author fullname="Mishael Wexler" initials="M." surname="Wexler">
<organization>Huawei</organization>
<address>
<postal>
<street>Riesstr. 25</street>
<region>Munich</region>
<code>80992</code>
<country>Germany</country>
</postal>
<email>mishael.wexler@huawei.com</email>
</address>
</author>
<author fullname="Mohamed Boucadair" initials="M" surname="Boucadair">
<organization>France Telecom</organization>
<address>
<postal>
<street>Rennes 35000</street>
<country>France</country>
</postal>
<email>mohamed.boucadair@orange.com</email>
</address>
</author>
<author fullname="Sam Aldrin" initials="S." surname="Aldrin">
<organization abbrev="Huawei USA">Huawei Technologies USA</organization>
<address>
<postal>
<street>2330 Central Expressway</street>
<city>NSanta Clara</city>
<region>CA</region>
<code>95051</code>
<country>USA</country>
</postal>
<email>aldrin.ietf@gmail.com</email>
</address>
</author>
<author fullname="Greg Mirsky" initials="G." surname="Mirsky">
<organization>Ericsson</organization>
<address>
<email>gregory.mirsky@ericsson.com</email>
</address>
</author>
<author fullname="Pradeep Jain" initials="P." surname="Jain">
<organization>Nuage Networks</organization>
<address>
<postal>
<street>755 Ravendale Drive</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043</code>
<country>USA</country>
</postal>
<email>pradeep@nuagenetworks.net</email>
</address>
</author>
<date year="2014"/>
<area>OPS</area>
<workgroup>Operations and Management Area Working Group</workgroup>
<keyword>RFC</keyword>
<keyword>Request for Comments</keyword>
<keyword>I-D</keyword>
<keyword>Internet-Draft</keyword>
<keyword>Multi-Layer OAM, Transport Independent</keyword>
<abstract>
<t>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 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.</t>
<t>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.</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>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.</t>
<t>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.</t>
<t>It is worth to mention also that there are two restrictions for
multi-layer structure as discussed in [RFC7276]: <list style="symbols">
<t>Each layer has its own OAM protocol, OAM should not cross layer
boundaries.</t>
<t>Each layer OAM used at different level of hierarchy in the
network.</t>
</list></t>
<t>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 technologies in
either data plane or management plane is extremely difficult to
achieve.</t>
<t>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.</t>
<t>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).</t>
<t>This document covers the following:<list style="symbols">
<t>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;</t>
<t>Management plane consolidation by interacting with data plane OAM
and abstracting OAM information common to different layer via
uniformed interface.</t>
</list></t>
</section>
<section title="Terminology">
<t>This document defines the following terms:<list style="hanging">
<t hangText="Transport Independent Multi-Layer OAM:"><vspace
blankLines="1"/>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.</t>
<t hangText="OAM function:"><vspace blankLines="1"/>Refers to the
atomic building blocks of OAM; an OAM function defines an OAM
capability (See section 2.2.3 of [RFC7276]).</t>
<t hangText="OAM protocol:"><vspace blankLines="1"/>Refers to a
protocol used for implementing one or more OAM functions (See
section 2.2.3 of [RFC7276]).</t>
<t hangText="OAM tool:"><vspace blankLines="1"/>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]).</t>
<t hangText="OAM packet:"><vspace blankLines="1"/>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.</t>
<t hangText="Maintenance Domain (MD):"><vspace
blankLines="1"/>Refers to the part of a network where OAM function
is performed (initiated).</t>
<t hangText="Maintenance Point (MP):"><vspace blankLines="1"/>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.</t>
<t hangText="Maintenance Endpoint (MEP):"><vspace blankLines="1"/>Is
an endpoint MP that initiates OAM packets and responds to them.</t>
<t hangText="Maintenance Intermediary Point(MIP):"><vspace
blankLines="1"/>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.</t>
<t hangText="Maintenance Association (MA):"><vspace
blankLines="1"/>The relationship between a set of MEPs to which
maintenance and monitoring operations apply.</t>
<t hangText="Network Element (NE):"><vspace blankLines="1"/>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.</t>
</list></t>
<section title="Acronyms and Abbreviations">
<t><list>
<t>CC - Continuity Check</t>
<t>CV - Connectivity Verification</t>
<t>SNMP - Simple Network Management Protocol</t>
<t>NETCONF - Network Configuration</t>
<t>ETH - Ethernet</t>
<t>APS - Automatic Protection Switching</t>
<t>LT - LinkTrace</t>
<t>RDI - Remote Defect Indication</t>
<t>AIS - Alarm indication Signal</t>
<t>OWAMP - One Way Active Measurement Protocol</t>
<t>TWAMP - Two Way Active Measurement Protocol</t>
<t>CFM - Connectivity Fault Management</t>
</list></t>
</section>
</section>
<section title="Problem Statement">
<t>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.</t>
<t>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: <list>
<t>(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 adding a single OAM function requires the above complete
life-cycle.</t>
<t>(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.</t>
</list></t>
<t>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.</t>
<t>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.</t>
<section title="Use of Existing Protocols">
<t>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].</t>
<t>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.</t>
<t>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 similar mechanisms exist in other
technologies, a new protocol can be preferable to a "messy" hack of an
existing protocol.</t>
</section>
<section title="Strong Technology dependency">
<t>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 IETF OAM protocols.</t>
<figure align="left" anchor="fig-1" title="Examples of IETF OAM tools">
<artwork>|--------+------------+--------------+--------------+------------+
| |Continuity | Connectivity| Path | Performance|
| | Check | Verification| Discovery | Measurement|
+--------+------------+--------------+--------------+------------+
| | | | |-Delay |
| ICMP | Echo(Ping) | | Traceroute |-Loss rough |
| | | | | measurement|
+--------+------------+--------------+--------------+------------+
| | BFD | | | |
| BFD | Control | BFD Control | | |
| | /Echo | | | |
+--------+------------+--------------+--------------+------------+
| LSP | | | | - Delay |
| Ping | | Ping | Traceroute | - Packet |
| | | | | Loss |
+--------+------------+--------------+--------------+------------+
| | | | | -OWAMP |
| IPPM | | | | -TWAMP |
| | | | | |
|--------+------------+--------------+--------------+------------+
| MPLS-TP| | | | |
| OAM | CC | CV | Traceroute | -Delay |
| |(use of BFD)|(use of BFD) | | -Packet |
| | | or LSP Ping) | | Loss |
+--------+------------+--------------+--------------+------------+
</artwork>
</figure>
</section>
<section title="Weakness of Cross-Layer OAM">
<t>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-discernible and native OAM stream. In addition, OAM
messages should not be leaked outside of a management domain 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.</t>
<t>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.</t>
<t>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.</t>
</section>
<section title="Lack of OAM above Layer 3">
<t>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.</t>
<t>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
<xref target="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.</t>
</section>
<section title="Issues of Abstraction">
<t>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 API to
activate the OAM functions at different layers and retrieve the
results.</t>
<t>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.</t>
</section>
<section title="Issue of OAM Information Gathering from Layers Covering Heterogeneous Network Technologies">
<t>In SFC, the service packets are steered through a set of service
nodes (virtual or physical) hosting the service function 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.</t>
<t>When any overlay Segment or segment of service chain in the network
fails to deliver user traffic, there is a need to provide a tool that
would enable users to detect such failures at different layer using
various encapsulation protocols and locate faults in the specific part
of the network, and a mechanism to isolate these faults. It may also
be desirable to test the data path before mapping user traffic to the
Overlay Segment or segment of service chain. When multiple layer OAMs
are used in the different parts of the network; how these layers OAM
interwork at the boundary of each part of network is also a serious
issue.</t>
<section title="Focus on Service Function Chaining">
<t>When the service packets are steered through a set of Service
Nodes (virtual or physical) hosting the Service Function distributed
in the network, each Service Node may work at different layer above
layer 3 and may embed several SFs. When OAM mechanism is applied, it
is necessary to allow OAM packets to be exchanged: <list
style="symbols">
<t>between Service Functions/Service Nodes and the SFC
Management System,</t>
<t>between these Service Nodes,</t>
<t>between Service Functions at different layers,</t>
<t>or between Service Nodes and ingress node of the SFC-enabled
domain.</t>
</list></t>
<t>When Service Functions that are part of the SFC-enabled domain do
support the OAM capability (e.g., an SFC-unaware Service Function)
and Service Node has OAM capability, Service Nodes may be
responsible for monitoring and diagnosing and reporting service
availability of these Service Functions. It is more desirable to
allow Service Functions register with a Service Node. Either Service
Functions report status to the Service Node or the Service Node
performs liveness check of the Service Function.</t>
<t>In addition, some Service Functions may not 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 the 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 SFC ingress node (i.e.,Classifier) and
traverse a set of Service Nodes that host Service Function,the data
packet may be discarded either at the SFC ingress node, one specific
Service Node or one specific Service Function. Also the data packet
may be lost between SFC ingress and one Service Node, or between two
Service Nodes, or between one Service Node and one Service Function,
how to detect the fault between them and how to isolate problem to
that layer?</t>
<t>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.</t>
</section>
</section>
</section>
<section title="Architecture Overview">
<t>Figure 2 shows the reference architecture for Layering OAM. This
reference architecture assumes that <list style="symbols">
<t>Any network element can use different technologies and
corresponding OAM on the same layer at the boundary of two adjacent
domains</t>
<t>Any two network element may provide service delivery at different
layer</t>
<t>Management entity can manage network devices in more than one
maintenance domains.</t>
</list></t>
<t>In this architecture, three layers are defined:<list>
<t>M1: "Data Plane layer"</t>
<t>M2: "Management Plane layer"</t>
<t>M3: "Service Plane layer"</t>
</list></t>
<t>In the M1 layer, a typical network can be partitioned into several
domains. Each domain has at least two MEPs and none or several MIPs. One
domain can contain one or more maintenance associations (MAs). MEP is a
maintenance functional entity that is implemented into a Network Element
at the maintenance domain boundary and can 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
and respond OAM packets only when triggered by a specific OAM function
(e.g., Path Discovery or Connectivity Verification). MEPs and MIPs can
exist in the same maintenance domain and belong to different MAs. They
can also exist at different layers and use various encapsulating
protocols.</t>
<t>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 network device
include SNMP [RFC1157], Command Line Interfaces, NETCONF [RFC6241], and
other protocols.</t>
<t>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.</t>
<t><figure align="left" anchor="fig-2"
title="Architecture for Layering OAM in the management plane">
<artwork> 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 | | |
+----------------------------+ +---------------------+
</artwork>
</figure></t>
<t>An example of service-specific that depicts OAM layers can be found
in [RFC4176] (L3VPN case).</t>
</section>
<section title="Existing Work">
<t>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: <list
style="numbers">
<t><xref target="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.</t>
<t>Several contributions conducted in the past years, had tried to
address new technologies using existing mechanisms. <xref
target="I-D.jain-nvo3-overlay-oam"/> and MPLS-TP OAM documents are
only examples for such efforts.</t>
</list></t>
</section>
<section title="Architectural Consideration">
<section title="Basic Components">
<section title="Overlay OAM"/>
<section title="OAM at the top of Layer 3"/>
</section>
<section title="OAM Functions in the Data Plane">
<t>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.</t>
<t>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.</t>
<section title="Continuity Check">
<t>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.</t>
</section>
<section title="Connectivity Verification">
<t>Verifying that the actual connection is consistent with the
required connection and no mis-connection occurred. Some examples
are IP Ping, and ETH loopback.</t>
</section>
<section title="Path Discovery">
<t>Used to discover the path that specific service traverses in the
network. Some examples are LSP Traceroute, IP Traceroute and
ETH-LT/linktrace.</t>
</section>
<section title="Performance Measurement">
<t>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].</t>
</section>
<section title="Protection Switching Coordination">
<t>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].</t>
</section>
<section title="Alarm/defect Indication">
<t>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].</t>
</section>
<section title="Maintenance Commands">
<t>A function that is used to signal a maintenance state or command
within a connection/service. Examples can be ETH Lockout.</t>
</section>
</section>
<section title="OAM in Management Plane">
<t>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.</t>
<t>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: <list style="symbols">
<t>OAM information needs to be abstracted that are common to
different layer and different domain.</t>
<t>Support customized OAM service, e.g., customized service
diagnose.</t>
<t>OAM information is provided to management entity from managed
device via a uniform interface (API and/or UI)</t>
<t>Sets up MD MEP and MIP in the network provision phase</t>
<t>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.</t>
</list></t>
<t>The different OAM tools may be used in one of two basic types of
activation: <list style="symbols">
<t>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.</t>
<t>On-demand activation - indicates that the tool is activated
"manually" to detect a specific anomaly.</t>
</list></t>
<t/>
</section>
</section>
<section title="Building on Existing Protocols"/>
<section title="Scoping Future Work">
<t>This section includes a set of candidate items for activities to be
conducted within IETF.</t>
<t>These objectives are not frozen; further discussion is required to
target key issues and scope the work to be conducted within IETF
accordingly.</t>
<t>Candidate investigation items are listed below:<list style="symbols">
<t>Understand and discuss situations where an OAM protocol can be
tuned and optimized for a specific data plane.</t>
<t>OAM consolidation in the data plane:<list style="symbols">
<t>Exchange OAM information at the service layer atop of layer
3.</t>
<t>Deployed over various encapsulating protocols, and in various
medium types</t>
</list></t>
<t>OAM consolidation in the management plane:<list style="symbols">
<t>Abstract OAM information common to different layers.</t>
<t>Expose OAM information via unified interface to management
entities, independently of the layer they belong to.</t>
<t>Discuss how information gathered from various layers can be
correlated for the sake of network operations optimization
purposes.</t>
<t>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.</t>
<t>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.</t>
</list></t>
</list></t>
</section>
<section title="Manageability Considerations"/>
<section title="Security Considerations">
<t>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.</t>
</section>
<section title="Acknowledgements">
<t>The authors would like to thank Romascanu, Dan, Tom Taylor, Tissa
Senevirathne,Huub van Helvoort, Yuji Tochio for their valuable reviews
and suggestions.</t>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor="RFC2119">
<front>
<title abbrev="RFC Key Words">Key words for use in RFCs to Indicate
Requirement Levels</title>
<author fullname="Scott Bradner" initials="S." surname="Bradner">
<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass. Ave.</street>
<street>Cambridge</street>
<street>MA 02138</street>
</postal>
<phone>- +1 617 495 3864</phone>
<email>sob@harvard.edu</email>
</address>
</author>
<date month="March" year="1997"/>
<area>General</area>
<keyword>keyword</keyword>
<abstract>
<t>In many standards track documents several words are used to
signify the requirements in the specification. These words are
often capitalized. This document defines these words as they
should be interpreted in IETF documents. Authors who follow these
guidelines should incorporate this phrase near the beginning of
their document: <list>
<t>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.</t>
</list></t>
<t>Note that the force of these words is modified by the
requirement level of the document in which they are used.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC7276">
<front>
<title>An Overview of Operations, Administration, and Maintenance
(OAM) Tools</title>
<author fullname="T. Mizrahi" initials="T." surname="Mizrahi">
<organization/>
</author>
<author fullname="N. Sprecher" initials="N." surname="Sprecher">
<organization/>
</author>
<date day="10" month="June" year="2014"/>
</front>
<seriesInfo name="RFC" value="7276"/>
<format target="http://tools.ietf.org/html/rfc7276" type="TXT"/>
</reference>
<reference anchor="RFC6291">
<front>
<title>Guidelines for the Use of the "OAM" Acronym in the
IETF</title>
<author fullname="L. Andersson" initials="L." surname="Andersson">
<organization/>
</author>
<author fullname="H. van Helvoort" initials="H." surname="Helvoort">
<organization/>
</author>
<author fullname="R. Bonica" initials="R." surname="Bonica">
<organization/>
</author>
<author fullname="D. Romascanu" initials="D." surname="Romascanu">
<organization/>
</author>
<author fullname="S. Mansfield" initials="S." surname="Mansfield">
<organization/>
</author>
<date day="10" month="June" year="2011"/>
</front>
<seriesInfo name="RFC" value="6291"/>
<format target="http://tools.ietf.org/html/rfc6291" type="TXT"/>
</reference>
</references>
<references title="Informative References">
<reference anchor="RFC3411">
<front>
<title>An Architecture for Describing Simple Network Management
Protocol (SNMP) Management Frameworks</title>
<author fullname="D. Harrington" initials="D." surname="Harrington">
<organization/>
</author>
<author fullname="R. Presuhn" initials="R." surname="Presuhn">
<organization/>
</author>
<date day="10" month="December" year="2002"/>
</front>
<seriesInfo name="RFC" value="3411"/>
<format target="http://tools.ietf.org/html/rfc3411" type="TXT"/>
</reference>
<reference anchor="RFC6241">
<front>
<title>Network Configuration Protocol (NETCONF)</title>
<author fullname="R. Enns" initials="R." surname="Enns">
<organization/>
</author>
<author fullname="M. Bjorklund" initials="M." surname="Bjorklund">
<organization/>
</author>
<author fullname="J. Schoenwaelder" initials="J."
surname="Schoenwaelder">
<organization/>
</author>
<author fullname="A. Bierman" initials="A." surname="Bierman">
<organization/>
</author>
<date month="June" year="2011"/>
</front>
<seriesInfo name="RFC" value="6241"/>
<format target="http://tools.ietf.org/html/rfc6241" type="TXT"/>
</reference>
<reference anchor="I.D-ietf-sfc-problem-statement">
<front>
<title>Network Service Chaining Problem Statement</title>
<author fullname="P.Quinn" initials="P." surname="Quinn">
<organization/>
</author>
<author fullname="J.Guichard" initials="J." surname="Guichard">
<organization/>
</author>
<author fullname="S.Surendra" initials="S." surname="Surendra">
<organization/>
</author>
<date month="August" year="2013"/>
</front>
<seriesInfo name="ID" value="draft-ietf-sfc-problem-statement"/>
</reference>
<reference anchor="I-D.tissa-netmod-oam">
<front>
<title>YANG Data Model for Operations Administration and Maintenance
(OAM)</title>
<author fullname="Tissa Senevirathne" initials="T."
surname="Senevirathne ">
<organization/>
</author>
<author fullname="Norman Finn" initials="N." surname="Finn">
<organization/>
</author>
<author fullname="Deepak Kumar " initials="D." surname="Kumar ">
<organization/>
</author>
<author fullname="Samer Salam" initials="S." surname="Salam ">
<organization/>
</author>
<date month="March" year="2014"/>
</front>
<seriesInfo name="ID" value="draft-tissa-netmod-oam-00"/>
</reference>
<reference anchor="I-D.jain-nvo3-overlay-oam">
<front>
<title>Generic Overlay OAM and Datapath Failure Detection</title>
<author fullname="P. Jain" initials="P." surname="Jain">
<organization/>
</author>
<date month="February" year="2014"/>
</front>
<seriesInfo name="ID" value="draft-jain-nvo3-overlay-oam-01"/>
</reference>
<reference anchor="RFC5880">
<front>
<title>Bidirectional Forwarding Detection (BFD)</title>
<author fullname="D. Katz" initials="D." surname="Katz">
<organization/>
</author>
<author fullname="D.Ward" initials="D." surname="Ward">
<organization/>
</author>
<date month="June" year="2010"/>
</front>
<seriesInfo name="RFC" value="5880"/>
<format target="http://tools.ietf.org/html/rfc5880" type="TXT"/>
</reference>
<reference anchor="RFC4656">
<front>
<title>A One-way Active Measurement Protocol (OWAMP)</title>
<author fullname="S.Shalunov" initials="S." surname="Shalunov">
<organization/>
</author>
<author fullname="A.Karp" initials="A." surname="Karp">
<organization/>
</author>
<author fullname="J.Boote" initials="J." surname="Boote">
<organization/>
</author>
<author fullname="M.Zekauskas" initials="M." surname="Zekauskas">
<organization/>
</author>
<date month="September" year="2006"/>
</front>
<seriesInfo name="RFC" value="4656"/>
<format target="http://tools.ietf.org/html/rfc4656" type="TXT"/>
</reference>
<reference anchor="RFC5357">
<front>
<title>A Two-Way Active Measurement Protocol (TWAMP)</title>
<author fullname="K.Hedeyat" initials="K." surname="Hedeyat">
<organization/>
</author>
<author fullname="R.Krzanowski" initials="R." surname="Krzanowski">
<organization/>
</author>
<author fullname="A.Morton" initials="A." surname="Morton">
<organization/>
</author>
<author fullname="K.Yum" initials="K." surname="Yum">
<organization/>
</author>
<author fullname="J.Babiarz" initials="J." surname="Babiarz">
<organization/>
</author>
<date month="October" year="2008"/>
</front>
<seriesInfo name="RFC" value="5357"/>
<format target="http://tools.ietf.org/html/rfc5357" type="TXT"/>
</reference>
<reference anchor="RFC6374">
<front>
<title>Packet Loss and Delay Measurement for MPLS Networks</title>
<author fullname="D. Frost" initials="D." surname="Frost">
<organization/>
</author>
<author fullname="S.Bryant" initials="S." surname="Bryant">
<organization/>
</author>
<date month="September" year="2011"/>
</front>
<seriesInfo name="RFC" value="6374"/>
<format target="http://tools.ietf.org/html/rfc6374" type="TXT"/>
</reference>
<reference anchor="RFC6378">
<front>
<title>Packet Loss and Delay Measurement for MPLS Networks</title>
<author fullname="Y. Weingarten" initials="Y." surname="Weingarten">
<organization/>
</author>
<author fullname="S.Bryant" initials="S." surname="Bryant">
<organization/>
</author>
<author fullname="E.Osborne" initials="E." surname="Osborne">
<organization/>
</author>
<author fullname="N.Sprecher" initials="N." surname="Sprecher">
<organization/>
</author>
<author fullname="A. Fuligoli" initials="A." surname="Fuligoli">
<organization/>
</author>
<date month="October" year="2011"/>
</front>
<seriesInfo name="RFC" value="6378"/>
<format target="http://tools.ietf.org/html/rfc6378" type="TXT"/>
</reference>
<reference anchor="RFC6428">
<front>
<title>Proactive Connectivity Verification, Continuity Check, and
Remote Defect Indication for the MPLS Transport Profile</title>
<author fullname="D. Allan" initials="D." surname="Allan">
<organization/>
</author>
<author fullname="G.Swallow" initials="G." surname="Swallow">
<organization/>
</author>
<author fullname="J.Drake" initials="J." surname="Drake">
<organization/>
</author>
<date month="November" year="2011"/>
</front>
<seriesInfo name="RFC" value="6428"/>
<format target="http://tools.ietf.org/html/rfc6428" type="TXT"/>
</reference>
<reference anchor="RFC4176">
<front>
<title>Framework for Layer 3 Virtual Private Networks (L3VPN)
Operations and Management</title>
<author fullname="Y. El Mghazli" initials="Y." surname="El Mghazli">
<organization/>
</author>
<author fullname="T.Nadeau" initials="T." surname="Nadeau">
<organization/>
</author>
<author fullname="M.Boucadair" initials="M." surname="Boucadair">
<organization/>
</author>
<author fullname="K.Chan" initials="K." surname="Chan">
<organization/>
</author>
<author fullname="A.Gonguet" initials="A." surname="Gonguet">
<organization/>
</author>
<date month="October" year="2005"/>
</front>
<seriesInfo name="RFC" value="4176"/>
<format target="http://tools.ietf.org/html/rfc4176" type="TXT"/>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 04:09:21 |