One document matched: draft-ww-opsawg-multi-layer-oam-00.xml
<?xml version="1.0" encoding="UTF-8"?>
<!-- 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="std" docName="draft-ww-opsawg-multi-layer-oam-00.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="Service Layer OAM">Problem Statement and Architecture for
Transport Independent OAM in the multiple layer network</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>
<email>mishael.wexler@huawei.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>RTG</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, Service Layer OAM</keyword>
<abstract>
<t>Operations, Administration, and Maintenance (OAM) mechanisms
[RFC6291] are basic building blocks for every communication layer and
technology. The current practice is that many technologies and layers
have their own OAM protocols. In the current situation there is a little
or no re-use of software and hardware in the existing OAM protocols.
Vendors and operators waste a lot through the whole OAM life-cycle when
a new technology is introduced. Integration of OAM across multiple
technologies is extremely difficult. In many cases it is desirable to
have a generic OAM to cover heterogeneous networking technologies. An
example to this generic approach is the Bidirectional Forwarding
Detection [BFD] mechanism that offers a way to monitor, troubleshoot and
maintain the network and services in support multi-layer OAM independent
of media, data protocols, and routing protocols. Generic OAM tools can
be deployed over various encapsulating protocols, and in various medium
types.</t>
<t>An example of an environment in which a generic and integrated OAM
protocol would be valuable is Service Function Chaining. A Service
Function Chaining is composed by series of service Functions, that can
act in different layers but providing an end-to-end chain or path from a
source to destination in a given order [I.D-ietf-sfc-problem-statement].
In service function chaining environment it is necessary to provide end
to end OAM across certain or all entities and involving many layers. OAM
information should be exchanged between service functions in different
layers while using various encapsulating protocols. In some cases OAM
should cross different administration and/or maintenance domains.</t>
<t>This document sets out the problem statement and architecture for the
Generic OAM in the Service Layer Routing. This document will cover at
least the basic OAM functions and information such as Connectivity
Verification (CV), Path Verification and Continuity Checks (CC),Path
Discovery / Fault Localization and Performance Monitoring necessary to
monitor and maintain the network.</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>Operations, Administration, and Maintenance (OAM) mechanisms
[RFC6291] are basic building blocks for every communication layer and
technology. The basic concepts of OAM and the functional roles in
monitoring and diagnosing the behavior of telecommunications networks
have been long term studied at the Layer 1&2 & Layer 3 levels.
Certain OAM functions are used in many management applications for (i)
defect and failure detection, (ii) reporting the defect/failure
information, (iii) defect/failure localization, (iv) performance
monitoring, and (v) service recovery.</t>
<t>The current practice is that many technologies and layers have their
own OAM protocols. There is little or no re-use of software and hardware
for each OAM protocol. Vendors and operators waste a lot through the
whole OAM life-cycle when a new technology is introduced. Integration of
OAM across multiple technologies is extremely difficult. When having
networks with more than one technology, maintenance and troubleshooting
are done per technology and layer, operation process can be very
cumbersome. In many cases it is desirable to have a generic OAM to cover
heterogeneous networking technologies. Generic OAM tools should be
deployed over various encapsulating protocols, and in various medium
types. An example to this generic approach is the Bidirectional
Forwarding Detection [BFD] mechanism that offers a way to monitor,
troubleshoot and maintain the network and services in support multi-
layer OAM independent of media, data protocols, and routing
protocols.</t>
<t>An example of an environment in which a generic and integrated OAM
protocol would be valuable is Service Function Chaining. A Service
Function Chaining is composed by a series of service Functions, that can
act in different layers but providing an end-to- end chain or path from
a source to destination in a given order [I.D
-ietf-sfc-problem-statement]. In service function chaining Environment,
it is necessary to provide end to end OAM across certain or all entities
and involving many layers. OAM information should be exchanged between
service functions in different layers while using various encapsulating
protocols. In some cases OAM should cross different administration
and/or maintenance domains.</t>
<t>This document sets out the problem statement and architecture for the
Generic OAM in the multi-layer network and outlines the problems
encountered with existing OAM protocol variety and their impact on
introduction of new technologies. The scope of this document will at
least cover the basic OAM functions and information (Connectivity
Verification (CV), Path Verification and Continuity Checks (CC),Path
Discovery / Fault Localization,Performance Monitoring) necessary to
monitor and diagnose network.</t>
<section title="What is Generic OAM in the multi-layer network?">
<t>In an multi-layer network, generic OAM is the ability to exchange
OAM information across layers between nodes along forwarding path and
gather and provide it to the management application through unified
interface. OAM information includes OAM configuration and operational
data abstracted from various network technologies, protocols and
layers.</t>
</section>
</section>
<section title="Terminology">
<section title="Standards Language">
<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 <xref
target="RFC2119">RFC 2119</xref>.</t>
</section>
</section>
<section title="Overview of Use Cases">
<section title="Fault localization in multi-layer network">
<t>A user who wishes to issue a Ping command or a Traceroute or
initiate a session monitoring can do so in the same manner regardless
of the underlying protocol or technology. Consider a scenario where an
IP ping to device B from Device A failed. Between device A and B there
are IEEE 802.1 bridges a,b and c. Let's assume a,b and c are using
[8021Q] CFM. Upon detecting IP layer ping failure, the user may wish
to "go down" to the Ethernet layer and issue the corresponding fault
verification (LBM) and fault isolation (LTM) tools, using the same
API.</t>
</section>
<section title="Multi-layer OAM in support of service function chain">
<t>In service function chain, the service packets is steered through a
set of service nodes distributed in the network.When the service
packet enters the network OAM information needs to be imposed by
ingress node of the network into the packet and pass throught the
network in the same route as the service nodes. In case several SFs
are co-located in the same service node, the packet is processed by
all SFs in the service node, Once the packet is successfully handled
by one SF, the packet is forwarded to the next SF that is in the same
service node. When the packet leave the network, the OAM information
needs to stripped out from the packet. To provide unified view of OAM
information, these OAM information needs to gathered from various
layer using different encapsulation and tunneling techniques and
abstracted and provided to the management application via the unified
management interface.</t>
</section>
</section>
<section title="Problem Statement">
<t>OAM mechanisms are usually oriented to a single network technology or
a single layer. Each technology or layer has its best suited 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. 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 we invest in design and development of data, control and
management planes. In some cases, even adding a single OAM function
requires the above whole life-cycle (2) Operation and Maintenance: There
is a need to train operation people for every new 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>
<t>Specifically, in service function chaining environment, every
function may operate in 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 is very high. Still, end-to-end service OAM mechanisms
and information exchanges between functions should be provided to
operate and maintain the network as a whole. This requires a generic
tool-set that can provide all standard tools in context of
multi-technology, multi-layer, physical and virtual environments.</t>
<t>An interesting angle to aspect of this problem is how the OAM
information at different layer is made available to 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 layer and provide them to the management
application.</t>
<section title="Use of Existing Protocol Mechanisms">
<t>OAM information relies on network technology 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,I2RS or NetConf/Yang.</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 protocol or
functionality that is commonly implemented on routers and is currently
deployed. 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, 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 technology they
are associated with. Addressing scheme is a good example for an issue
that has a high price for being non-generic. Ping of IPv4 and IPv6
looks different in the addressing scheme as well in the ICMP
indication field, but they have the same OAM functionalities.</t>
</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- discernable 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>This 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 would be more desirable to drop down to the
another layer OAM and issue the corresponding OAM command, using the
same API 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 and can ping IPv4 host by an IPv6 source or having
one tool to troubleshoot combined IP, MPLS, Ethernet, GRE and VXLAN
network.</t>
</section>
<section title="Lack of OAM above Layer 3">
<t>The Layer 2/3 protocols are quite rich in their functionality, well
defined, standardized and heavily used. In the last years a lot of
work was done to consider maintenance domains and levels in order to
better handle the issues of cross technology, vendor and operator
domains to provide smooth interoperability and domain separation.</t>
<t>The above mechanisms are not defined for the technologies above
Layer 3. Therefore, in the SFC environment 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
work at different layers above layer 3.</t>
</section>
<section title="Issues of Abstraction">
<t>In multi-layer network,OAM function is enabled at different layer
and various OAM information needs to be gathered from various layer.
Without multi-layer OAM in place, it is hard for management
application to understand what these information at different layer
stands for. One possible solution to the 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 trick to this multi-layer problem, is to abstract in a way that
retains as much useful information as possible while removing the data
that is not needed. An important part of this trick is a clear
understanding of what information is actually needed.</t>
</section>
<section title="Issue of OAM information gathering from Service Function">
<t>When the service packets is steered through a set of service nodes
distributed in the network, each service node work at different layers
above layer 3 and may have several SFs collocated with itself. When
OAM mechanism is applied, it is necessary to allow OAM packet
exchanged between these service nodes or service function at different
layers. when Service function involved in the SFC doesn't support OAM
capability(e.g., SF is SFC-unaware service function), Service node
should be responsible for monitor and diagnose the Service function
and check service availability to these service function. It is more
desirable to allow service function register to service node. Either
service function report status to service node or service node perform
live check to these service function.</t>
<t>In addtion, 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 is no OAM functions at service
layers at top of 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 service function, assume two service functions are
embedded in two different service nodes, how to detect the fault
between them and how to isolate problem to that layer?</t>
</section>
</section>
<section title="Existing Work">
<t>The following subsections discuss related IETF work and are provided
for reference. This section is not exhaustive, rather it provides an
overview of few initiatives tackling the pain-points of OAM. <list
style="numbers">
<t>An important work done in [I-D.tissa-netmod-oam] create a YANG
unified data model for OAM that is based on IEEE CFM model. This
model can be used also for IP OAM functionality. The above work is
focused on the management plane of OAM and should be complemented by
an accompanying data-plane and/or control-plan work. It may require
also some extensions to address wider variety of functions and
technologies.</t>
<t>Several works done in the last years 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.</t>
</list></t>
</section>
<section title="Architectural Consideration">
<section title="Basic Components">
<section title="Interconnect OAM at different layers"/>
<section title="Interconnect OAM at the same shim layer above layer 3"/>
</section>
<section title="OAM Functions in Data Plane">
<section title="Continuity Check">
<t>This type of mechanisms check that the monitored layer and/or
entity are alive and providing connectivity from specific point(s)
to other point(s). Some examples are BFD and ETH CC.</t>
</section>
<section title="Connectivity Verification">
<t>Verifying that the actual connection is consistent with the
required connection and no misconnection occurred. Some examples are
IP Ping, VCCV 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 Trace, IP Trace-route and Ethernet
Trace.</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/
OWAMP and Y.1731.</t>
</section>
<section title="Protection Switching">
<t>A function that is used to signal protection switching states and
commands. Examples are ETH APS messages.</t>
</section>
<section title="Alarm/defect indication">
<t>A function that is used to indicate that a failure occured
downstream or upstream within a connection/service. Used also to
trigger fast protection or to suppress alarms. Examples are ETH AIS
and ETH RDI.</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>There are two phases to OAM provision. The first phase is the
network provisioning phase, which sets up Maintenance Domains (MD) and
Maintenance Intermediate Points (MIP) and enables basic OAM
functionality(e.g.,Connectivity Fault Management (CFM)) on the
devices.</t>
<t>The second provision phase is the service activation phase,which
enable the origin of ping and trace packets, as well as configure
continuity-check and cross-check functionalities.</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"/>
<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="Summary">
<t>This document highlights problems associated with OAM in packet
technologies today. We detail the problem scope, identified the main OAM
functions that should be addressed based on the current aggregated
functions.</t>
</section>
<section title="Acknowledgements">
<t>The authors would like to thank Romascanu, Dan, Tissa Senevirathne
for their valuable reviews and suggestions on this document.</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>
</references>
<references title="Informative References">
<reference anchor="I-D.ietf-nsc-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-quinn-nsc-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>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 04:09:28 |