summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc6291.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc6291.txt')
-rw-r--r--doc/rfc/rfc6291.txt507
1 files changed, 507 insertions, 0 deletions
diff --git a/doc/rfc/rfc6291.txt b/doc/rfc/rfc6291.txt
new file mode 100644
index 0000000..fc4eb6c
--- /dev/null
+++ b/doc/rfc/rfc6291.txt
@@ -0,0 +1,507 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) L. Andersson
+Request for Comments: 6291 Ericsson
+BCP: 161 H. van Helvoort
+Category: Best Current Practice Huawei Technologies
+ISSN: 2070-1721 R. Bonica
+ Juniper Networks
+ D. Romascanu
+ Avaya
+ S. Mansfield
+ Ericsson
+ June 2011
+
+
+ Guidelines for the Use of the "OAM" Acronym in the IETF
+
+Abstract
+
+ 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.
+
+ This document provides a definition of the acronym "OAM" (Operations,
+ Administration, and Maintenance) for use in all future IETF documents
+ that refer to OAM. There are other definitions and acronyms that
+ will be discussed while exploring the definition of the constituent
+ parts of the "OAM" term.
+
+Status of This Memo
+
+ This memo documents an Internet Best Current Practice.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Further information on
+ BCPs is available in Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc6291.
+
+
+
+
+
+
+
+
+
+
+
+Andersson, et al. Best Current Practice [Page 1]
+
+RFC 6291 OAM Terminology June 2011
+
+
+Copyright Notice
+
+ Copyright (c) 2011 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
+ 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2. Pre-Existing Uses of OAM . . . . . . . . . . . . . . . . . . . 3
+ 2.1. Uses of OAM in Other SDOs . . . . . . . . . . . . . . . . . 4
+ 2.1.1. The "O" in OAM . . . . . . . . . . . . . . . . . . . . 4
+ 2.1.2. The "A" in OAM . . . . . . . . . . . . . . . . . . . . 4
+ 2.1.3. The "M" in OAM . . . . . . . . . . . . . . . . . . . . 5
+ 2.2. Uses of OAM in the IETF . . . . . . . . . . . . . . . . . . 5
+ 3. Recommendations on the Use of the "OAM" Acronym . . . . . . . . 5
+ 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
+ 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7
+ 6. Informative References . . . . . . . . . . . . . . . . . . . . 7
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Andersson, et al. Best Current Practice [Page 2]
+
+RFC 6291 OAM Terminology June 2011
+
+
+1. Introduction
+
+ The main purpose of this document is to provide a definition of the
+ acronym "OAM" (Operations, Administration, and Maintenance) for use
+ in all future IETF documents that refer to OAM.
+
+ 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.
+
+ 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.
+
+ 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. Second, the
+ acronym, as such, represents something that is more than just the sum
+ of its parts.
+
+ There is also the issue of how each piece of the acronym is defined.
+ This document provides an analysis of what each initial of the
+ initialism represents and provides possible interpretations of the
+ acronym. Finally, a recommendation for the interpretation of the
+ "OAM" acronym is provided.
+
+ Another useful document to make the "OAM" term understandable in a
+ wider scope is found in "An Overview of Operations, Administration,
+ and Maintenance (OAM) Mechanisms" [OAM-OVERVIEW].
+
+1.1. Terminology
+
+ o "Mgmt" - Management
+
+ o O&M - OAM and Management
+
+ o OAM - Operations, Administration, and Maintenance
+
+ o SDO - Standards Development Organization
+
+2. Pre-Existing Uses of OAM
+
+ This section provides information on how OAM is used in other SDOs
+ (Standards Development Organizations) and provides the background
+ necessary to understand the how the term is used in the IETF.
+
+
+
+
+
+Andersson, et al. Best Current Practice [Page 3]
+
+RFC 6291 OAM Terminology June 2011
+
+
+2.1. Uses of OAM in Other SDOs
+
+ Operations And Maintenance (OAM): A group of network management
+ functions that provide network fault indication, performance
+ information, and data and diagnosis functions. ATM OAM ITU-T I.610
+ [ITU-T-I.610] is an example specification that uses this expansion of
+ the "OAM" acronym.
+
+ 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 IEEE
+ 802.3-2008 [IEEE.802.3-2008] and ITU-T Y.1731 [ITU-T-Y.1731].
+
+ The ITU-T M.3010 [ITU-T-M.3010] 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).
+
+ 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 effectively MEF 17 [MEF-17].
+
+2.1.1. The "O" in OAM
+
+ The "O" in OAM invariably stands for "Operations". However, there is
+ some ambivalence in the definition and scope of the term "Operation".
+
+ 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.
+
+2.1.2. The "A" in OAM
+
+ The "A" in OAM stands for "Administration".
+
+ Examples of "administration" tools are network discovery and planning
+ tools.
+
+
+
+
+
+
+
+
+
+
+Andersson, et al. Best Current Practice [Page 4]
+
+RFC 6291 OAM Terminology June 2011
+
+
+2.1.3. The "M" in OAM
+
+ The "M" in OAM stands for "Maintenance" or "Management".
+
+ 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.
+
+ The Recommendation ITU-T M.20 [ITU-T-M.20] 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 ITU-T M.60 [ITU-T-M.60] Recommendation). The
+ purpose is to properly plan and program the maintenance operations
+ required to establish and maintain a network.
+
+ 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.
+
+2.2. Uses of OAM in the IETF
+
+ The examples below show a number of different ways that the "OAM"
+ acronym has been expanded in IETF RFCs. The reference list is not
+ exhaustive.
+
+ o OAM = Operations, Administration, and Maintenance in RFC 5586
+ [RFC5586]
+
+ o OAM = Operations and Maintenance in RFC 3429 [RFC3429]
+
+ o OAM = Operations and Management in RFC 4377 [RFC4377]
+
+ o O&M = OAM and Maintenance in RFC 1812 [RFC1812]
+
+ Sometimes there is a fourth letter added to the acronym:
+
+ o OAM&P = Operations, Administration, Maintenance and Provisioning
+ in RFC 4594 [RFC4594]
+
+3. Recommendations on the Use of the "OAM" Acronym
+
+ The IETF-recommended expansion of the "OAM" acronym is given below.
+ In addition to the "OAM" acronym, two other recommendations are made
+ in this section.
+
+ o OAM - Operations, Administration, and Maintenance
+
+ o O&M - OAM and Management
+
+
+
+Andersson, et al. Best Current Practice [Page 5]
+
+RFC 6291 OAM Terminology June 2011
+
+
+ o "Mgmt" - Management
+
+ The components of the "OAM" acronym (and provisioning) are defined as
+ follows:
+
+ o 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.
+
+ o 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.
+
+ o 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 effectively, e.g., adjusting device
+ configuration and parameters.
+
+ "Provisioning" is outside the scope of this document, but the
+ following definition is provided for completeness.
+
+ o 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.
+
+ 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.
+
+ 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.
+
+ "Mgmt" will be used if an abbreviation for "Management" is needed.
+ This document does not define Management.
+
+4. Security Considerations
+
+ This document provides guidance for the use of the "OAM" acronym in
+ other documents. This document does not have direct security
+ implications.
+
+
+
+Andersson, et al. Best Current Practice [Page 6]
+
+RFC 6291 OAM Terminology June 2011
+
+
+ The misunderstanding of an acronym may lead to incorrect
+ specification or implementation which may, in turn, open up security
+ concerns with protocols or deployed networks. Clarifying the meaning
+ of OAM is, therefore, a benefit for future stability of
+ specifications.
+
+5. Acknowledgments
+
+ The following individuals significantly contributed to this document.
+
+ o Malcolm Betts from M. C. Betts Consulting, Ltd.
+
+ o Kam Lam from Alcatel Lucent
+
+ o Dieter Beller from Alcatel Lucent
+
+ o David Harrington from Huawei Technologies
+
+ Thanks to the experts of ITU-T SG 15 for their review and comments.
+
+6. Informative References
+
+ [IEEE.802.3-2008] IEEE, "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",
+ IEEE Standard 802.3, December 2008.
+
+ [ITU-T-I.610] International Telecommunication Union, "B-ISDN
+ operation and maintenance principles and
+ functions", ITU-T Recommendation I.610,
+ February 1999.
+
+ [ITU-T-M.20] International Telecommunication Union,
+ "Maintenance philosophy for telecommunication
+ networks", ITU-T Recommendation M.20,
+ October 1992.
+
+ [ITU-T-M.3010] International Telecommunication Union, "Principles
+ for a telecommunications management network", ITU-
+ T Recommendation M.3010, February 2000.
+
+ [ITU-T-M.60] International Telecommunication Union,
+ "Maintenance terminology and definitions", ITU-
+ T Recommendation M.60, March 1993.
+
+
+
+
+Andersson, et al. Best Current Practice [Page 7]
+
+RFC 6291 OAM Terminology June 2011
+
+
+ [ITU-T-Y.1731] International Telecommunication Union, "OAM
+ functions and mechanisms for Ethernet based
+ networks", ITU-T Recommendation Y.1731,
+ February 2008.
+
+ [MEF-17] Metro Ethernet Forum, "Service OAM Requirements &
+ Framework - Phase 1", MEF Technical Specification
+ MEF 17, April 2007.
+
+ [OAM-OVERVIEW] Mizrahi, T., Sprecher, N., Bellagamba, E., and Y.
+ Weingarten, "An Overview of Operations,
+ Administration, and Maintenance (OAM) Mechanisms",
+ Work in Progress, March 2011.
+
+ [RFC1812] Baker, F., "Requirements for IP Version 4
+ Routers", RFC 1812, June 1995.
+
+ [RFC3429] Ohta, H., "Assignment of the 'OAM Alert Label' for
+ Multiprotocol Label Switching Architecture (MPLS)
+ Operation and Maintenance (OAM) Functions",
+ RFC 3429, November 2002.
+
+ [RFC4377] Nadeau, T., Morrow, M., Swallow, G., Allan, D.,
+ and S. Matsushima, "Operations and Management
+ (OAM) Requirements for Multi-Protocol Label
+ Switched (MPLS) Networks", RFC 4377,
+ February 2006.
+
+ [RFC4594] Babiarz, J., Chan, K., and F. Baker,
+ "Configuration Guidelines for DiffServ Service
+ Classes", RFC 4594, August 2006.
+
+ [RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS
+ Generic Associated Channel", RFC 5586, June 2009.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Andersson, et al. Best Current Practice [Page 8]
+
+RFC 6291 OAM Terminology June 2011
+
+
+Authors' Addresses
+
+ Loa Andersson
+ Ericsson
+
+ EMail: loa.andersson@ericsson.com
+
+
+ Huub van Helvoort
+ Huawei Technologies
+
+ EMail: huub.van.helvoort@huawei.com
+
+
+ Ron Bonica
+ Juniper Networks
+
+ EMail: rbonica@juniper.net
+
+
+ Dan Romascanu
+ Avaya
+
+ EMail: dromasca@avaya.com
+
+
+ Scott Mansfield
+ Ericsson
+
+ EMail: scott.mansfield@ericsson.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Andersson, et al. Best Current Practice [Page 9]
+