draft-ietf-opsawg-mpls-tp-oam-def-00.txt   draft-ietf-opsawg-mpls-tp-oam-def-01.txt 
Network Working Group L. Andersson Network Working Group L. Andersson
Internet-Draft Ericsson Internet-Draft Ericsson
Intended status: Informational M. Betts Intended status: Informational M. Betts
Expires: March 13, 2010 H. van Helvoort Expires: July 19, 2010 ZTE Corporation
Huawei Tecnologies H. van Helvoort
Huawei Technologies
R. Bonica R. Bonica
Juniper Networks Juniper Networks
D. Romascanu D. Romascanu
Avaya Avaya
September 9, 2009 January 15, 2010
"The OAM Acronym Soup" "The OAM Acronym Soup"
draft-ietf-opsawg-mpls-tp-oam-def-00.txt draft-ietf-opsawg-mpls-tp-oam-def-01.txt
Abstract
At first glance the acronym "OAM" seems to be well known and well
understood. Looking at it a bit more closely reveals a set of
recurring problems that are revisited time and again. This document
has one primary and one secondary goal. The primary goal is to find
an understanding of OAM that is useful for the MPLS Transport Profile
(MPLS-TP) effort. The secondary goal is to make this understanding
applicable in a wider scope.
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.
This Informational Internet-Draft is aimed at achieving IETF
Consensus before publication as an RFC and will be subject to an IETF
Last Call.
[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.]
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 38 skipping to change at page 2, line 17
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 13, 2010. This Internet-Draft will expire on July 19, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
At first glance the acronym "OAM" seems to be well known and well described in the BSD License.
understood. Looking at it a bit more closely reveals a set of
recurring problems that are revisited time and again. This document
has one primary and a secondary goal. The primary goal is to find an
understanding of OAM that is feasible for the MPLS Transport Profile
(MPLS-TP)effort. The secondary goal is to make this understanding
applicable in a wider scope
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. OAM and O, A and M . . . . . . . . . . . . . . . . . . . . . . 5 2. OAM and O, A and M . . . . . . . . . . . . . . . . . . . . . . 6
2.1. OAM as a functional unit . . . . . . . . . . . . . . . . . 5 2.1. OAM as a functional unit . . . . . . . . . . . . . . . . . 6
2.2. The acronym broken up . . . . . . . . . . . . . . . . . . 5 2.2. The acronym broken up . . . . . . . . . . . . . . . . . . 6
2.2.1. O in OAM . . . . . . . . . . . . . . . . . . . . . . . 5 2.2.1. O in OAM . . . . . . . . . . . . . . . . . . . . . . . 6
2.2.2. A in OAM . . . . . . . . . . . . . . . . . . . . . . . 5 2.2.2. A in OAM . . . . . . . . . . . . . . . . . . . . . . . 6
2.2.3. M in OAM . . . . . . . . . . . . . . . . . . . . . . . 6 2.2.3. M in OAM . . . . . . . . . . . . . . . . . . . . . . . 7
3. Use of the OAM acronym MPLS-TP effort . . . . . . . . . . . . 7 3. Use of the OAM acronym MPLS-TP effort . . . . . . . . . . . . 8
4. Acronyms for the MPLS-TP effort . . . . . . . . . . . . . . . 9 4. Acronyms for the MPLS-TP effort . . . . . . . . . . . . . . . 10
5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 10 5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 11
6. Security considerations . . . . . . . . . . . . . . . . . . . 11 6. Security considerations . . . . . . . . . . . . . . . . . . . 12
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
8.1. Normative References . . . . . . . . . . . . . . . . . . . 13 8.1. Normative references . . . . . . . . . . . . . . . . . . . 14
8.2. Informative references . . . . . . . . . . . . . . . . . . 13 8.2. Informative references . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
The state of this work is very much "work in progress" and the The state of this work is very much "work in progress" and the
discussion is ongoing. The reason to publish the draft at this stage discussion is ongoing. The reason to publish the draft at this stage
is that some of the relevant MPLS-TP drafts are getting close to is that some of the relevant MPLS-TP drafts are getting close to
working group last call and some of the directives in this document working group last call and some of the definitions in this document
is needed for consistency within that group af draft. are needed for consistency within that group of drafts.
The acronym OAM is frequently used in the data- and telecommunication The acronym OAM is frequently used in the data and telecommunication
industry. One would assume that something that is so widely used is industry. One would assume that something that is so widely used is
very clearly defined. However a closer look reveals some points that very clearly defined. However a closer look reveals some points that
needs to be clarified. need to be clarified.
The examples used below comes mainly from the first set of MPLS-TP The examples below come mainly from the first set of MPLS-TP IDs. In
IDs. In the IDs there were a number of examples of how the acronym the IDs there were a number of examples of how the OAM acronym could
could be a number of ways to expand and understand the acronym e.g.: be used and there were a number of ways to expand and understand the
acronym e.g.:
o OAM = Operations, Administration, Maintenance o OAM = Operations, Administration, Maintenance
o OAM = Operations, Administration, Management o OAM = Operations, Administration, Management
o OAM = Operations and Maintenance o OAM = Operations and Maintenance
o OAM = Operations and Management o OAM = Operations and Management
o O&M = Operations and Maintenance o O&M = Operations and Maintenance
o O&M = Operations and Management o O&M = Operations and Management
The examples above were taken from drafts that later has been The examples above were taken from drafts that later were corrected
corrected and aligned with what is proposed in this document. and aligned with what is proposed in this document.
Sometimes there is a fourth letter added to the acronym: Sometimes there is a fourth letter added to the acronym:
o OAM and P = Operations, Administration, Maintenance and o OAM and P = Operations, Administration, Maintenance and
Provisioning Provisioning
If such an important piece of our technology is so poorly defined, or If such an important piece of our technology is so poorly defined, or
if there are dialects of the technology with different understandings if there are dialects of the technology with different understandings
of such a key concept, this will eventually cause problems. of such a key concept, this will eventually cause problems.
Trying to understand the use of an acronym that is as "content-rich" 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 as OAM reveals two levels of complexity. First, each letter in the
acronym represent a integrated piece of functionality; secondly the acronym represents an integrated piece of functionality; secondly the
acronym as such represent something that is more than just the sum of acronym as such represents something that is more than just the sum
the pieces of its parts.
There is also the issue of how each piece of the acronym is defined. 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 report [1] is
provided.
In this document we will analyse how each piece of the acronym is The immediate target is to document the use of the OAM acronym such
defined and provide possible interpretations of the acronym. Finally that it is useful for MPLS-TP. However, broader applicability of the
we will suggest the use of the OAM acronym for the MPLS-TP effort definitions in this document may also come to light.
based on the greement reached based on the JWT report
[I-D.bryant-mpls-tp-jwt-report].
Our immediate target is to document the use of the OAM acronym such
that it is useful for MPLS-TP. However, we hope to shed some light
on the issue in a broader scope.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", This document is a product of a joint Internet Engineering Task Force
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this (IETF) / International Telecommunication Union Telecommunication
document are to be interpreted as described in RFC 2119 [RFC2119]. 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.
2. OAM and O, A and M 2. OAM and O, A and M
2.1. OAM as a functional unit 2.1. OAM as a functional unit
Operations, Administration, and Maintenance (OAM): A group of network Operations, Administration, and Maintenance (OAM): A group of network
management functions that provide network fault indication, management functions that provide network fault indication,
performance information, and data and diagnosis functions. Examples performance information, and data and diagnosis functions. Examples
are ATM OAM [ITU-T I-610] and IEEE Std. 802.3 Clause 57 OAM are ATM OAM ITU-T I.610 [3] and Clause 57 of IEEE 802.3-2008 [2].
Alternatively (Huub :) )
Operations, Administration, and Maintenance (OAM): A group of network Operations, Administration, and Maintenance (OAM): A group of network
management functions that provide network fault indication, fault management functions that provide network fault indication, fault
localisation performance information, and data and diagnosis localization, performance information, and data and diagnosis
functions. functions.
ITU-T M.3010 recommendation defines: The ITU-T M.3010 [6] recommendation defines operations systems
function as a function block that processes information related to
operations systems function: A function block that processes the telecommunications management for the purpose of monitoring/
information related to the telecommunications management for the coordinating and/or controlling telecommunication functions including
purpose of monitoring/coordinating and/or controlling management functions (i.e. the TMN itself).
telecommunication functions including management functions (i.e. the
TMN itself).
The Metro Ethernet Forum refers to OAM as to: OAM refers to the tools The Metro Ethernet Forum refers to OAM as the tools and utilities to
and utilities to install, monitor and troubleshoot a network, helping install, monitor and troubleshoot a network, helping carriers run
carriers run their networks more efficiently. their networks more efficiently.
Note: the paragraphs above are so far just placeholders. Note: the paragraphs above are so far just placeholders.
2.2. The acronym broken up 2.2. The acronym broken up
2.2.1. O in OAM 2.2.1. O in OAM
The O in the OAM acronym invariably stands for "Operations". The O in the OAM acronym invariably stands for "Operations".
However there is some ambivalences in the definition and scope of However there is some ambivalence in the definition and scope of the
"Operation" term "Operation".
Note: Examples to be provided. Note: Examples to be provided.
2.2.2. A in OAM 2.2.2. A in OAM
The A in the OAM acronym mostly stands for "Adminstration", though in The A in the OAM acronym mostly stands for "Administration", though
a few cases it seems like "Accounting" have crept in. For the in a few cases it seems like "Accounting" is also used. For the
purpose of this document we will assume that "Adminstration" is the purpose of this document it is assumed that "Administration" is the
correct expansion of "A". correct expansion of "A".
Note: Examples to be provided. Note: Examples to be provided.
Admistration is used to support maintenance functions, e.g. by Administration is used to support maintenance functions, e.g. by
collecting failure and performance information, continuous or on- collecting failure and performance information, continuous or on-
demand. demand.
2.2.3. M in OAM 2.2.3. M in OAM
In the list above the M in the OAM acronym stands for "Maintenance" In the list above the M in the OAM acronym stands for "Maintenance"
or "Management". or "Management".
Since Maintenance and Management are defined as two different Since Maintenance and Management are defined as two different
actvities it does not seem to be a good idea to use them activities it does not seem to be a good idea to use them
interchangeably. interchangeably.
Note: Examples to be provided. Note: Examples to be provided.
The recommendation M.20 from ITU-T defines mainteance: The recommendation ITU-T M.20 [4] defines maintenance as the whole of
operations required for setting up and maintaining, within prescribed
Maintenance involves the whole of operations required for setting up limits, any element involved in the setting up of a connection (see
and maintaining, within prescribed limits, any element entering into the ITU-T M.60 [5] recommendation). The purpose is to properly plan
the setting-up of a connection (see Recommendation M.60). In order and program the maintenance operations required to establish and
to properly plan and program the maintenance operations required to maintain a network.
establish and maintain a network.
It should have as a major aim to minimize both the occurrence and the A major aim of the concept of maintenance is to minimize both the
impact of failures and to ensure that in cause of a failure the occurrence and the impact of failures and to ensure that in case of a
correct actions are taken. The ITU-T document also clearly defines a failure the correct actions are taken. The ITU-T document also
maintenace philosphy. clearly defines a maintenance philosophy.
3. Use of the OAM acronym MPLS-TP effort 3. Use of the OAM acronym MPLS-TP effort
In Section 4 we list the acronyms as they will be used in the MPLS-TP In Section 4 the acronyms as they will be used in the MPLS-TP effort
effort, this section gives somwe background. are listed. This section gives some background on the definitions
provided.
If we need as an abbreviation for "Management" we will use "Mgt". We "Mgt" will be used if an abbreviation for "Management" is needed.
do not define Management in this draft, but note that an important This draft does not define Management. It is noted, however, that an
part of the Management funtionality relates to tools to report the important part of management functionality relates to tools to report
state of the network. the state of the network.
We propose that the OAM acronym is reserved to be used for In MPLS-TP drafts, the OAM acronym is to be used for "Operations,
"Operations, Administration and Maintenance", i.e. excluding Administration and Maintenance", i.e. excluding provisioning.
provisioning.
OAM tools and protocols and the "Management space" are complementary OAM tools and protocols and the "Management space" are complementary
in natur. Management focuses on FCAPS functionality and on manager in nature. Management focuses on FCAPS functionality and on manager
(or NOC) to device (or network) interaction. (or NOC) to device (or network) interaction.
From an architecture point of view OAM protocols and tools tend to be From an architecture point of view OAM protocols and tools tend to be
"horizontal" i.e. network element to network element while the "horizontal" i.e. network element to network element while the
management protocols tend to be "vertical" management protocols tend to be "vertical".
Where each part of the acronym and provisioning is defined as Where each part of the acronym and provisioning is defined as
follows: follows:
o Operations - Operation activities is undertaken to keep the o Operations - Operation activities are undertaken to keep the
network (and the services that the network provides) up and network (and the services that the network provides) up and
running. It includes monitoring the network and find problems. running. It includes monitoring the network and finding problems.
Ideally these problems should be found before users are affected." Ideally these problems should be found before users are affected."
o Administration - Administration activities involves keeping track o Administration - Administration activities involve keeping track
of resources in the network and how they are used. It includes of resources in the network and how they are used. It includes
all the book keeping that is necessary to keep track of networking all the bookkeeping that is necessary to track networking
resources and the network under control. resources and the network under control.
o Maintenance - Maintenance activities are focused on facilitating o Maintenance - Maintenance activities are focused on facilitating
repairs and upgrades - for example, when equipment must be repairs and upgrades - for example, when equipment must be
replaced, when a router needs a patch for an operating system replaced, when a router needs a patch for an operating system
image, when a new switch is added to a network. Maintenance also image, or when a new switch is added to a network. Maintenance
involves corrective and preventive measures to make the managed also involves corrective and preventive measures to make the
network run more efficient, e.g. adjusting device configuration managed network run more efficiently, e.g. adjusting device
and parameters. configuration and parameters.
o Even though we don't include "Provisioning" in the OAM acronym we o Even though "Provisioning" is not included in this document, the
note that: following definition is provided for completeness.
Provisioning - Provisioning activities involves configuring Provisioning - Provisioning activities involve configuring
resources in the network to support the offered services. This resources in the network to support the offered services. This
might include setting up the network so that a new customer can might include setting up the network so that a new customer can
receive an Internet access service. receive an Internet access service.
o We also note that sometimes it is necessary to talk about the o Sometimes it is necessary to talk about the combination of
combination of functions and tools suplied by OAM and Management, functions and tools supplied by OAM and Management, it is
we prefer that this is spelled out as "OAM and Management". In preferred that this is spelled out as "OAM and Management". In
cases where an acronym is needed O&M should be used. cases where an acronym is needed O&M should be used.
4. Acronyms for the MPLS-TP effort 4. Acronyms for the MPLS-TP effort
OAM - Operations, Administration and Maintenance OAM - Operations, Administration and Maintenance
O&M - Operations, Administration, Maintenance and Management O&M - Operations, Administration, Maintenance and Management
"Mgt" - Management "Mgt" - Management
5. IANA considerations 5. IANA considerations
There are no requests for IANA allocation of code points in this There are no requests for IANA allocation of code points in this
document. document.
6. Security considerations 6. Security considerations
This document only changes the name of one field in the MPLS Shim Security is a significant requirement of MPLS-TP. However, this
Header and thus does not introduce any new security considerations. informational document is intended only to provide guidance on the
use of the OAM acronym, and the security concerns are, therefore, out
of scope.
7. Acknowledgments 7. Acknowledgments
- -
8. References 8. References
8.1. Normative References 8.1. Normative references
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
8.2. Informative references 8.2. Informative references
[I-D.bryant-mpls-tp-jwt-report] [1] Bryant, S. and L. Andersson, "Joint Working Team (JWT) Report on
Bryant, S. and L. Andersson, "JWT Report on MPLS MPLS Architectural Considerations for a Transport Profile",
Architectural Considerations for a Transport Profile", RFC 5317, February 2009.
draft-bryant-mpls-tp-jwt-report-00 (work in progress),
July 2008. [2] 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.
[3] International Telecommunication Union, "B-ISDN operation and
maintenance principles and functions", ITU-T Recommendation
I.610, February 1999.
[4] International Telecommunication Union, "Maintenance philosophy
for telecommunication networks", ITU-T Recommendation M.20,
October 1992.
[5] International Telecommunication Union, "Maintenance terminology
and definitions", ITU-T Recommendation M.60, March 1993.
[6] International Telecommunication Union, "Principles for a
telecommunications management network", ITU-T Recommendation
M.3010, February 2000.
Authors' Addresses Authors' Addresses
Loa Andersson Loa Andersson
Ericsson Ericsson
Email: loa.andersson@ericsson.com Email: loa.andersson@ericsson.com
Malcolm Betts Malcolm Betts
Huawei Tecnologies ZTE Corporation
Email: malcolm.betts@huawei.com Email: malcolm.betts@zte.com.cn
Huub van Helvoort Huub van Helvoort
Huawei Tecnologies Huawei Technologies
Email: hhelvoort@huawei.com Email: hhelvoort@huawei.com
Ron Bonica Ron Bonica
Juniper Networks Juniper Networks
Email: rbonica@juniper.net Email: rbonica@juniper.net
Dan Romascanu Dan Romascanu
Avaya Avaya
 End of changes. 45 change blocks. 
131 lines changed or deleted 166 lines changed or added

This html diff was produced by rfcdiff 1.37b. The latest version is available from http://tools.ietf.org/tools/rfcdiff/