One document matched: draft-ietf-opsawg-mpls-tp-oam-def-04.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc5317 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5317.xml">
]>

<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="no" ?>
<?rfc sortrefs="no"?>
<?rfc iprnotified="no" ?>
<?rfc strict="no" ?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<rfc category="info" docName="draft-ietf-opsawg-mpls-tp-oam-def-04.txt" ipr="trust200902">
<!-- the 03-version -->

<front>
	<title abbrev="The use of the OAM Acronym in MPLS-TP">"The use of the OAM Acronym in MPLS-TP"</title>

<author fullname="Loa Andersson"
	initials="L"
	surname="Andersson">
	<organization>Ericsson</organization>
		<address>
			<email>loa.andersson@ericsson.com</email>
		</address>

</author>
    
<author fullname="Huub van Helvoort"
	initials="H"
	surname="van Helvoort">
	<organization>Huawei Technologies</organization>
		<address>
			<email>hhelvoort@huawei.com</email>
		</address>
</author>    

<author fullname="Ron Bonica"
	initials="R"
	surname="Bonica">
	<organization>Juniper Networks</organization>
		<address>
			<email>rbonica@juniper.net</email>
		</address>
</author>

<author fullname="Dan Romascanu"
	initials="D"
	surname="Romascanu">
	<organization>Avaya</organization>
		<address>
			<email>dromasca@avaya.com</email>
		</address>
</author>
    
<author fullname="Scott Mansfield"
	initials="S"
	surname="Mansfield">
	<organization>Ericsson</organization>
		<address>
			<email>scott.mansfield@ericsson.com</email>
		</address>
</author>
    
<date year="2010" />

<keyword>Intended status: Informational</keyword>

<abstract>
	<t> At first glance the acronym "OAM" seems to be well known and well understood.  Looking at the acronym a bit more closely reveals a set of recurring problems that are revisited time and again. The goal of this document is to find an understanding of the OAM acronym that is useful for the MPLS Transport Profile (MPLS-TP) effort.
	</t>

	<t> This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and PWE3 architectures to support the capabilities and functionalities of a packet transport network.
	</t>

	<t>This Informational Internet-Draft is aimed at achieving IETF Consensus before publication as an RFC and will be subject to an IETF Last Call.
	</t>

	<t>[RFC Editor, please remove this note before publication as an RFC and insert the correct Streams Boilerplate to indicate that the published RFC has IETF Consensus.]
	</t>
</abstract>
</front>

<middle>
<!-- section 1 -->

<section anchor="intro" title="Introduction">
	<t> The purpose of this document is to provide a definition of the OAM acronym such that it is useful for MPLS-TP. The acronym OAM is frequently used in the data and telecommunication industry. One would assume that something that is so widely used is very clearly defined. However a closer look reveals some points that need to be clarified.
	</t>
      
	<t> The examples below show a number of different ways that the OAM acronym could be expanded and understood. The examples come from many sources including some of the early MPLS-TP I-Ds.
	<list style="symbols">
      
		<t> OAM = Operation, Administration, Maintenance
		</t>
	 
		<t> OAM = Operations, Administration, Maintenance
		</t>
	 
		<t> OAM = Operations, Administration, Management
		</t>
	 
		<t> OAM = Operations and Maintenance
		</t>
	 
		<t> OAM = Operations and Management
		</t>
	 
		<t> O&M = Operations and Maintenance
		</t>
	 
		<t> O&M = Operations and Management
		</t>
	 
		<t> O&M = OAM and Management
		</t>
	 	         
	</list>
	</t>

	<t> Sometimes there is a fourth letter added to the acronym:
	<list style="symbols">
		<t> OAM and P = Operations, Administration, Maintenance and Provisioning
		</t>
	</list>
	</t>

	<t> If such an important piece of our technology is so poorly defined, or if there are dialects of the technology with different understandings of such a key concept, this will eventually cause problems.
	</t>

	<t> Trying to understand the use of an acronym that is as "content-rich" as OAM reveals two levels of complexity. First, each letter in the acronym represents an integrated piece of functionality; secondly the acronym as such represents something that is more than just the sum of its parts.
	</t>

	<t> There is also the issue of how each piece of the acronym is defined.  This document provides an analysis of how each piece of the acronym is defined and provides possible interpretations of the acronym.  Finally the interpretation of the OAM acronym to use for the MPLS-TP effort based on the agreement reached in the JWT (Joint Working Team) report <xref target="RFC5317"/> is provided.
	</t>

	<t> Another useful document to make the OAM term understandable in a wider scope is found in <xref target="I-D.ietf-opsawg-oam-overview"> An Overview of Operations, Administration, and Maintenance (OAM) Mechanisms </xref>.
	</t>

	<t> This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and PWE3 architectures to support the capabilities and functionalities of a packet transport network.
	</t>

<!-- end section 1 -->
</section>

<!-- section 2 -->

<section anchor="acronym-oam" title="OAM and O, A and M">

<section anchor="acronym-unit" title="OAM as a functional unit">

	<t> Operations And Maintenance (OAM): A group of network management functions that provide network fault indication, performance information, and data and diagnosis functions.  ATM OAM <xref target="ITU-T I.610">ITU-T I.610</xref> is an example specification that uses this expansion of the OAM acronym.
	</t>

	<t> Operations, Administration, and Maintenance (OAM): A group of network management functions that provide network fault indication, fault localization, performance information, and data and diagnosis functions.  Examples where this acronym is used are Clause 57 of <xref target="IEEE.802.3-2008">IEEE 802.3-2008</xref> and <xref target="ITU-T Y.1731">ITU-T Y.1731</xref>.
	</t>

	<t> The <xref target="ITU-T M.3010">ITU-T M.3010</xref> Recommendation defines operations systems function as a function block that processes information related to the telecommunications management for the purpose of monitoring/coordinating and/or controlling telecommunication functions including management functions (i.e. the TMN (Telecommunications Management Network) itself).
	</t>

	<t> The Metro Ethernet Forum refers to OAM as the tools and utilities to install, monitor and troubleshoot a network, helping carriers run their networks more efficiently.
	</t>

</section>

<section anchor="acronym-o" title="The acronym broken up">

<section anchor="O" title="O in OAM">

	<t> The O in the OAM acronym invariably stands for "Operations".
	</t>

	<t> However there is some ambivalence in the definition and scope of the term "Operation".
	</t>
       
	<t> Examples of tools related to "operations" are performance monitoring tools used for service level agreement (SLA) measurement, fault management tools used to monitor the health of nodes and links in the network, and network provisioning tools.
	</t>

</section>

<section anchor="A" title="A in OAM">

	<t> The A in the OAM acronym mostly stands for "Administration", though in a few cases it seems like "Accounting" is also used. For the purpose of this document it is assumed that "Administration" is the correct expansion of "A".
	</t>

	<t> Examples of "administration" tools are network discovery and planning tools.
	</t>

</section>

<section anchor="M" title="M in OAM">

	<t> In the list above the M in the OAM acronym stands for "Maintenance" or "Management".
	</t>

	<t> Since Maintenance and Management are defined as two different activities it does not seem to be a good idea to use them interchangeably.  The concept behind OAM is management, so it makes more sense to use maintenance as the expansion of the "M" in the acronym.
	</t>

	<t> Examples of "maintenance" tools are implementations of connectivity check, loopback, link trace, and other tools that can be used to monitor and diagnose failures in a network or network element.
	</t>

	<t> The Recommendation <xref target="ITU-T M.20">ITU-T M.20</xref> defines maintenance as the whole of operations required for setting up and maintaining, within prescribed limits, any element involved in the setting up of a connection (see the <xref target="ITU-T M.60">ITU-T M.60</xref> Recommendation). The purpose is to properly plan and program the maintenance operations required to establish and maintain a network.
	</t>

	<t> A major aim of the concept of maintenance is to minimize both the occurrence and the impact of failures and to ensure that in case of a failure the correct actions are taken. The ITU-T documents also clearly define a maintenance philosophy.
	</t>

</section>

</section>

<!-- end of section 2 -->
</section>

<!-- section 3 -->

<section anchor="solution" title="Use of the OAM Acronym in the MPLS-TP effort">
	<t> In  <xref target="acro"/> the acronyms as they will be used in the MPLS-TP effort are listed.  This section gives some background on the definitions provided.
	</t>

	<t> "Mgt" will be used if an abbreviation for "Management" is needed.  This draft does not define Management.  It is noted, however, that an important part of management functionality relates to tools to report the state of the network.
	</t>

	<t> In MPLS-TP documents, the OAM acronym is to be used for "Operations, Administration and Maintenance", i.e. excluding provisioning.
	</t>

	<t> OAM tools and protocols and the "Management space" are complementary in nature. Management focuses on FCAPS (Fault, Configuration, Accounting, Provisioning, and Security) functionality and on manager (or NOC (Network Operations Center)) to device (or network) interaction. 
	</t>

	<t> From an architecture point of view OAM protocols and tools deployed in the data plane tend to be "horizontal" i.e. network element to network element while the management protocols tend to be "vertical".
	</t>

	<t> The components of the OAM acronym (and provisioning) are defined as follows:
	<list style="symbols">

		<t> Operations - Operation activities are undertaken to keep the network (and the services that the network provides) up and running. It includes monitoring the network and finding problems. Ideally these problems should be found before users are affected.
		</t>

		<t> Administration - Administration activities involve keeping track of resources in the network and how they are used. It includes all the bookkeeping that is necessary to track networking resources and the network under control.
		</t>

		<t> Maintenance - Maintenance activities are focused on facilitating repairs and upgrades - for example, when equipment must be replaced, when a router needs a patch for an operating system image, or when a new switch is added to a network. Maintenance also involves corrective and preventive measures to make the managed network run more efficiently, e.g. adjusting device configuration and parameters.
		</t>
	</list>

	<t> Even though "Provisioning" is not included in this document, the following definition is provided for completeness.
	</t>
	<list style="symbols">

		<t> Provisioning -  Provisioning activities involve configuring resources in the network to support the offered services. This might include setting up the network so that a new customer can receive an Internet access service.
		</t>
	</list>

	<t> In general, Provisioning is used to configure the network for providing new services, whereas OAM is used to keep the network in a state that it can support already existing services.
	</t>

	<t> Sometimes it is necessary to talk about the combination of functions and tools supplied by OAM and Management, it is preferred that this is spelled out as "OAM and Management". In cases where an acronym is needed O&M should be used.
	</t>

	</t>

<!-- end of section 3 -->
</section>

<!-- section 4 -->
<section anchor="acro" title="Acronyms for the MPLS-TP effort">
	<t> OAM - Operations, Administration and Maintenance
	</t>

	<t> O&M - OAM and Management
	</t>

	<t> "Mgt" - Management
	</t>

<!-- end of section 4 -->
</section>

<!-- section 5 -->
<section anchor="iana" title="IANA considerations">

	<t> This memo includes no request to IANA.
	</t>

<!-- end of section 4 -->
</section>

<!-- section 5 -->
<section anchor="security" title="Security considerations">

	<t> Security is a significant requirement of MPLS-TP.  However, this informational document is intended only to provide guidance on the use of the OAM acronym, and the security concerns are, therefore, out of scope.
	</t>

<!-- end of section  5 -->
</section>

<!-- section 6 -->

<section anchor="acknowledgments" title="Acknowledgments">

	<t> Malcolm Betts from M. C. Betts Consulting Ltd. significantly contributed to this document.
	</t>

</section>
<!-- end of section  6 -->    

</middle>

<back>

<references title="Informative references">
	&rfc5317;
	<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-opsawg-oam-overview.xml" ?>
	<reference anchor="IEEE.802.3-2008">
		<front>
			<title>Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific requirements - Part 3: Carrier sense multiple access with collision detection (CSMA/CD) access method and physical layer specifications"</title>
			<author>
				<organization>IEEE</organization>
			</author>
			<date month="December" year="2008" />
		</front>
		<seriesInfo name="IEEE" value="Standard 802.3" />
	</reference>
	
	<reference anchor="ITU-T I.610">
		<front>
			<title>B-ISDN operation and maintenance principles and functions</title>
			<author>
				<organization>International Telecommunication Union</organization>
			</author>
			<date month="February" year="1999"/>
		</front>
		<seriesInfo name="ITU-T" value="Recommendation I.610"/>
	</reference>

	<reference anchor="ITU-T M.20">
		<front>
			<title>Maintenance philosophy for telecommunication networks</title>
			<author>
				<organization>International Telecommunication Union</organization>
			</author>
			<date month="October" year="1992"/>
		</front>
		<seriesInfo name="ITU-T" value="Recommendation M.20"/>
	</reference>

	<reference anchor="ITU-T M.60">
		<front>
			<title>Maintenance terminology and definitions</title>
			<author>
				<organization>International Telecommunication Union</organization>
			</author>
			<date month="March" year="1993"/>
		</front>
		<seriesInfo name="ITU-T" value="Recommendation M.60"/>
	</reference>

	<reference anchor="ITU-T M.3010">
		<front>
			<title>Principles for a telecommunications management network</title>
			<author>
				<organization>International Telecommunication Union</organization>
			</author>
			<date month="February" year="2000"/>
		</front>
		<seriesInfo name="ITU-T" value="Recommendation M.3010"/>
	</reference>

	<reference anchor="ITU-T Y.1731">
		<front>
			<title>OAM functions and mechanisms for Ethernet based networks</title>
			<author>
				<organization>International Telecommunication Union</organization>
			</author>
			<date month="February" year="2008"/>
		</front>
		<seriesInfo name="ITU-T" value="Recommendation Y.1731"/>
	</reference>
<!--    </references> -->
</references>
</back>
</rfc>