draft-ietf-mpls-tp-oam-requirements-00.txt   draft-ietf-mpls-tp-oam-requirements-01.txt 
MPLS Working Group M. Vigoureux (Editor)
Internet Draft Alcatel-Lucent
Intended status: Informational
Expires: May 2009 D. Ward (Editor)
Cisco Systems, Inc.
M. Betts (Editor) MPLS Working Group M. Vigoureux, Ed.
Internet-Draft Alcatel-Lucent
Intended status: Informational D. Ward, Ed.
Expires: September 10, 2009 Cisco Systems, Inc.
M. Betts, Ed.
Nortel Networks Nortel Networks
March 9, 2009
November 28, 2008
Requirements for OAM in MPLS Transport Networks Requirements for OAM in MPLS Transport Networks
draft-ietf-mpls-tp-oam-requirements-00 draft-ietf-mpls-tp-oam-requirements-01
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 other Task Force (IETF), its areas, and its working groups. Note that
groups may also distribute working documents as Internet-Drafts. other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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 May 28, 2009. This Internet-Draft will expire on September 10, 2009.
Abstract Copyright Notice
This document lists the requirements for Operations, Administration Copyright (c) 2009 IETF Trust and the persons identified as the
and Maintenance functionality in MPLS networks that are used for document authors. All rights reserved.
packet transport services and network operations.
These requirements are derived from the set of requirements specified This document is subject to BCP 78 and the IETF Trust's Legal
by ITU-T and first published in the ITU-T Supplement Y.Sup4 [5]. Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Conventions used in this document Abstract
This document lists the requirements for the Operations,
Administration and Maintenance functionality of MPLS Transport
Profile. These requirements apply to pseudowires, Label Switched
Paths, and Sections. Architectural, functional and operational
requirements are covered in this document.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [1]. document are to be interpreted as described in RFC 2119 [1].
Table of Contents Table of Contents
1. Introduction...................................................2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Terminology...............................................3 1.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5
1.2. Definitions...............................................3 1.2. Contributing Authors . . . . . . . . . . . . . . . . . . . 5
1.3. Context and Motivations...................................4 2. OAM Requirements . . . . . . . . . . . . . . . . . . . . . . . 5
2. OAM Requirements...............................................5 2.1. Architectural Requirements . . . . . . . . . . . . . . . . 6
2.1. Architectural Requirements................................5 2.1.1. Independence . . . . . . . . . . . . . . . . . . . . . 6
2.2. Functional Requirements...................................7 2.1.2. Addressing, Routing and Forwarding . . . . . . . . . . 6
2.2.1. General requirements.................................8 2.1.3. Interoperability and Interworking . . . . . . . . . . 6
2.2.2. Connectivity and Continuity Verification.............8 2.1.4. Data Plane . . . . . . . . . . . . . . . . . . . . . . 7
2.2.3. Client Failure Indication............................8 2.1.5. Scope . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2.4. Remote Defect Indication.............................8 2.2. Functional Requirements . . . . . . . . . . . . . . . . . 7
2.2.5. Alarm Suppression....................................8 2.2.1. General Requirements . . . . . . . . . . . . . . . . . 8
2.2.6. Packet Loss..........................................9 2.2.2. Continuity Checks . . . . . . . . . . . . . . . . . . 8
2.2.7. Delay Measurement....................................9 2.2.3. Connectivity Verifications . . . . . . . . . . . . . . 9
2.2.8. Route Determination..................................9 2.2.4. Diagnostic . . . . . . . . . . . . . . . . . . . . . . 9
2.2.9. Diagnostic..........................................10 2.2.5. Adjacency . . . . . . . . . . . . . . . . . . . . . . 9
2.3. Operational Requirements.................................10 2.2.6. Route Tracing . . . . . . . . . . . . . . . . . . . . 10
2.4. Performance Requirements.................................11 2.2.7. Lock . . . . . . . . . . . . . . . . . . . . . . . . . 10
3. Security Considerations.......................................11 2.2.8. Alarm Notification . . . . . . . . . . . . . . . . . . 10
4. Congestion Considerations.....................................12 2.2.9. Client Failure Indication . . . . . . . . . . . . . . 11
5. IANA Considerations...........................................12 2.2.10. Remote Defect Indication . . . . . . . . . . . . . . . 11
6. Acknowledgments...............................................12 2.2.11. Packet Loss . . . . . . . . . . . . . . . . . . . . . 11
7. References....................................................13 2.2.12. Delay Measurement . . . . . . . . . . . . . . . . . . 12
7.1. Normative References.....................................13 2.3. Operational Requirements . . . . . . . . . . . . . . . . . 12
7.2. Informative References...................................13 3. Congestion Considerations . . . . . . . . . . . . . . . . . . 14
Authors' Addresses...............................................13 4. Security Considerations . . . . . . . . . . . . . . . . . . . 14
Contributing Authors' Addresses..................................14 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property Statement..................................15 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
Disclaimer of Validity...........................................16 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Copyright Statement..............................................17 7.1. Normative References . . . . . . . . . . . . . . . . . . . 15
7.2. Informative References . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
This document lists the requirements for Operations, Administration In the context of MPLS Transport Profile (MPLS-TP, see [5] and [6]),
and Maintenance functionality in MPLS networks that are used for the rationales for Operations, Administration and Maintenance (OAM)
packet transport services and network operations. mechanisms are twofold as they can serve:
1.1. Terminology
AC Attachment Circuit
CSF Client Signal Fail
FCAPS Fault, Configuration, Accounting, Performance, Security
LER Label Edge Router
LSP Label Switched Path
LSR Label Switching Router
ME Maintenance Entity
MEP Maintenance End Point
MIP Maintenance Intermediate Point
MP Maintenance Point
MS-PW Multi Segment Pseudowire
OAM Operations, Administration and Maintenance o as a network-oriented mechanism (used by a transport network
operator) to monitor his network infrastructure and to implement
internal mechanisms in order to enhance the general behaviour and
the level of performance of his network (e.g., protection
mechanism in case of node or link failure). For example fault
localization is typically associated to this use case.
PE Provider Edge o as a service-oriented mechanism (used by a transport service
provider) to monitor offered services to end customers in order to
be able to react rapidly in case of a problem and to be able to
verify some of the Service Level Agreements (SLAs) parameters
(e.g., using performance monitoring) negotiated with the end
customer. Note that a transport service could be provided over
several networks or administrative domains that may not be all
owned and managed by the same transport service provider.
PSN Packet Switched Network More generally, OAM is an important and fundamental functionality in
transport networks as it contributes to:
PW Pseudowire o the reduction of operational complexity and costs, by allowing
efficient and automatic detection, localisation, handling, and
diagnosis of defects, and by minimizing service interruptions and
operational repair times.
SLA Service Level Agreement o the enhancement of network availability, by ensuring that defects,
for example resulting in misdirected customer traffic, and faults,
are detected, diagnosed and dealt with before a customer reports
the problem.
SS-PW Single Segment Pseudowire o meet service and performance objectives, by running OAM
functionality which allows SLA verification in a multi-maintenance
domain environment and allows the determination of service
degradation due, for example, to packet delay or packet loss.
S-PE PW Switching Provider Edge This document lists the requirements for the OAM functionality of
MPLS-TP. These requirements apply to pseudowires (PWs), Label
Switched Paths (LSPs), and Sections.
T-PE PW Terminating Provider Edge These requirements are derived from a set of requirements specified
by ITU-T and first published in the ITU-T Supplement Y.Sup4 [7].
TCME Tandem Connection Maintenance Entity By covering transport specificities, these requirements stand as a
complement to those identified in RFC 4377 [8].
1.2. Definitions 1.1. Definitions
In this document we refer to a fault as the inability of a function In this document we refer to a fault as the inability of a function
to perform a required action. This does not include an inability due to perform a required action. This does not include an inability due
to preventive maintenance, lack of external resources, or planned to preventive maintenance, lack of external resources, or planned
actions. See also ITU-T G.806 [3]. actions. See also ITU-T G.806 [2].
In this document we refer to a defect as the situation for which In this document we refer to a defect as the situation for which
density of anomalies has reached a level where the ability to perform density of anomalies has reached a level where the ability to perform
a required function has been interrupted. See also ITU-T G.806 [3]. a required function has been interrupted. See also ITU-T G.806 [2].
In this document, we refer to MPLS Transport Profile (MPLS-TP) as the
set of MPLS functions used to support packet transport services and
network operations.
In this document we refer to a MPLS Section as a network segment
between two LSRs that are immediately adjacent at the MPLS layer.
For definitions of OAM functional components such as Maintenance
Point, Maintenance End Point and Maintenance Intermediate Point,
please refer to [7].
Additional definitions can also be found in [8].
1.3. Context and Motivations In this document we refer to a Label Edge Router (LER), for a given
LSP or Section, and to a PW Terminating Provider Edge (T-PE), for a
given PW, as an End Point. Further, we refer to a Label Switching
Router (LSR), for a given LSP, and to a PW Switching Provider Edge
(S-PE), for a given PW, as an Intermediate Point. This document does
not make any distinction between End Points (e.g., source and
destination) as it can be inferred from the context of the sentences.
Important attributes of MPLS-TP are that In this document we use the term "node" as a general referral to End
Points and Intermediate Points.
o it is able to function regardless of which client signals are Other definitions, relating to MPLS-TP, can be found in [6].
using its connectivity service or over which transmission media it
is running. The client, transport network and server layers are,
from a functional point of view, independent layer networks. That
is, demarcation points exist between MPLS-TP and the client layer,
and between MPLS-TP and the underlying server layer.
o it provides means to commit to Service Level Agreements (SLAs) 1.2. Contributing Authors
negotiated with customers, as well as means to monitor compliance
with these SLAs.
o it is consistent with existing transport network OAM models. The editors gratefully acknowledge the contributions of Matthew
Bocci, Italo Busi, Thomas Dietz, Huub van Helvoort, Wataru Imajuku,
Marc Lasserre, Lieven Levrau, Han Li, Julien Meuric, Philippe Niger,
Benjamin Niven-Jenkins, Jing Ruiquan, Nurit Sprecher, Yuji Tochio,
Satoshi Ueno and Yaacov Weingarten.
In the context of MPLS-TP, the rationale for OAM mechanisms are 2. OAM Requirements
twofold as they can serve:
o as a network-oriented mechanism (used by a transport network This section lists the requirements by which the OAM functionality of
operator) to monitor his network infrastructure and to implement MPLS-TP should abide. Note that some requirements for this
internal mechanisms in order to enhance the general behaviour and application of MPLS are similar to some of those listed in RFC 4377
the level of performance of his network (e.g. protection mechanism [8].
in case of node or link failure). For example fault localization
is typically associated to this use case.
o as a service-oriented mechanism (used by a transport service The requirements listed below may be met by one or more OAM
provider) to monitor his offered services to end customers in protocols; the definition or selection of these protocols is outside
order to be able to react rapidly in case of a problem and to be the scope of this document.
able to verify some of the SLA parameters (i.e. performance
monitoring) negotiated with the end customer. Note that a
transport service could be provided over several networks or
administrative domains that may not be all owned and managed by
the same transport service provider.
More generally, OAM is an important and fundamental functionality in 2.1. Architectural Requirements
transport networks as it contributes to:
o the reduction of operational complexity and costs, by allowing 2.1.1. Independence
efficient and automatic detection, localisation, handling, and
diagnosis of defects, and by minimizing service interruptions and
operational repair times.
o the enhancement of network availability, by ensuring that defects, OAM functions SHOULD be independent of the underlying tunnelling or
for example resulting in misdirected customer traffic are point-to-point technology or transmission media.
detected, diagnosed and dealt with before a customer reports the
problem.
o meet service and performance objectives, by running OAM OAM functions SHOULD be independent of the service a PW may emulate.
functionality which allows SLA verification in a multi-maintenance
domain environment and allows the determination of service
degradation due to, for example, packet delay or packet loss.
This is achieved through the support of FCAPS functionality, as The set of OAM functions operated on a PW, LSP or Section SHOULD be
described in ITU-T M.3400 [2], itself relying on OAM related independent of the set of OAM functions operated on a different PW,
information. LSP or Section. In other words, only the OAM functions available for
e.g., a LSP should be used to achieve the OAM objectives for that
LSP. Note that independence should not be understood here in terms
of isolation as there can be interactions between OAM functions
operated on e.g., a LSP and on another LSP or on a PW.
2. OAM Requirements OAM functions MUST operate and be configurable even in the absence of
a control plane. Conversely, OAM functions SHOULD be configurable as
part of connectivity (e.g., LSP or PW) management. Means for
configuring OAM functions and for connectivity management are outside
the scope of this document.
This section lists the requirements by which the OAM functionality of 2.1.2. Addressing, Routing and Forwarding
MPLS-TP should abide. Some requirements for this application are
similar to some of those listed in RFC 4377 [6].
The requirements listed below may be met by one or more OAM The OAM functionality may be deployed in a variety of environments.
protocols, the definition or selection of these protocols is outside
the scope of this document. However, the specified solution MUST
inter-work with the existing MPLS and PW OAM protocols.
2.1. Architectural Requirements o In some environments (e.g., IP/MPLS environments), IP routing and
forwarding capabilities are inherently present. In this case, the
OAM functionality MUST support the use of IP routing and
forwarding capabilities.
OAM functions SHOULD be independent of the underlying tunnelling or o In some environments (e.g., MPLS-TP environments), IP routing and
point-to-point technology or transmission media. forwarding capabilities may not necessarily be present. In this
case, the OAM functions and their operation MUST NOT require
relying on IP routing and forwarding capabilities.
OAM functions SHOULD be independent of the service a pseudowire may In case OAM messages need to incorporate identification information
emulate. (e.g., of source and/or destination nodes), the protocol solution
MUST at least support an IP addressing structure and MUST also be
extensible to support additional addressing schemes.
The set of OAM functions operated on each Maintenance Entity SHOULD 2.1.3. Interoperability and Interworking
be independent one from another.
Note that independence should not be understood here in terms of
isolation but in terms of separate running processes. There should be
one OAM process running per Maintenance Entity but different OAM
running processes could interact (e.g. alarm summarization).
OAM functionality MAY be deployed in a variety of environments. In It is REQUIRED by this document that OAM interoperability is achieved
some of these IP routing and forwarding capabilities are inherently across the environments described in Section 2.1.2. It is also
present (e.g. IP/MPLS) and the OAM functionality MUST also support REQUIRED by this document that the two first requirements of Section
their use. Other deployment scenarios exist where IP routing and 2.1.2 still hold and MUST thus still be met when interoperability is
forwarding capabilities are not necessarily present (e.g. MPLS-TP).
In these latter cases, the operation of OAM functions MUST NOT rely
on IP routing and forwarding capabilities. Further, it is REQUIRED by
this document that OAM interoperability is achieved across these
environments. It is also REQUIRED by this document that the two above
requirements are still met and still hold when interoperability is
achieved. achieved.
Furthermore, in case OAM packets need to incorporate identification When MPLS-TP is run with IP routing and forwarding capabilities, it
information of source and/or destination nodes, an IP addressing MUST be possible to operate any of the existing IP/MPLS and PW OAM
structure MUST be supported. functionalities (e.g., LSP-Ping [3], MPLS-BFD [9], VCCV [4] and VCCV-
BFD [10]).
When MPLS-TP is run with IP routing and forwarding capabilities, all
existing IP/MPLS OAM functionality (e.g. LSP-Ping, BFD and VCCV) MUST
be able to operate seamlessly.
OAM functions MUST operate and be configurable even in the absence of The protocol solution(s) developed to meet the requirements listed in
a control plane. Conversely, OAM functions SHOULD be configurable as this document MUST interwork with the existing IP/MPLS and PW OAM
part of connectivity (LSP or PW) management. Note that means for protocols.
configuring OAM functions and for connectivity management are outside
the scope of this document.
The service emulated by a single segment or a multi-segment 2.1.4. Data Plane
pseudowire may span multiple domains. A LSP may also span multiple
domains. It MUST be possible to perform OAM functions on a per domain
basis and across multiple domains. More generally it MUST be possible
to perform OAM functions between any two switching elements of a PW
or of a LSP. This is referred to as segment (or tandem connection)
monitoring (see [7]). Furthermore, in case of a fault or defect on
the service, means MUST be available for the service provider to be
informed of the fault even if the fault is located outside of his
domain.
OAM functions operate in the data plane. OAM packets MUST run in- OAM functions operate in the data plane. OAM packets MUST run in-
band. That is, OAM packets for a specific Maintenance Entity MUST band; that is, OAM packets for a specific PW, LSP or Section MUST
follow the exact same data path as user traffic of that Maintenance follow the exact same data path as user traffic of that PW, LSP or
Entity. This is known as fate sharing. Section.
It MUST be possible to discriminate data traffic from OAM packets. It MUST be possible to discriminate user traffic from OAM packets.
This includes a means to differentiate OAM packets from user traffic This includes a means to differentiate OAM packets from user traffic
as well as the capability to apply specific treatment, to OAM as well as the capability to apply specific treatment, to OAM
packets, at the MIPs or MEPs targeted by these OAM packets. packets, at the nodes targeted by these OAM packets.
As part of the design of OAM mechanisms for MPLS-TP, a mechanism that As part of the design of OAM protocol solutions for MPLS-TP, a
enables the realization of a channel for general purpose signalling, mechanism enabling to encapsulate and differentiate OAM messages, on
e.g. for control, management and OAM information, associated with the a PW, LSP or Section, MUST be provided. Such mechanism MUST also
data plane paths, MUST be provided. Such mechanism SHOULD support the support the encapsulation and differentiation of existing IP/MPLS and
operation of existing IP/MPLS OAM. PW OAM messages.
OAM functions MUST be able to be used for PWs, LSPs and Sections. 2.1.5. Scope
Furthermore, since LSPs MAY be stacked, OAM functions MUST be able to
run on each LSP, regardless of the label stack depth. The service emulated by a single segment or a multi-segment PW may
span multiple domains. A LSP may also span multiple domains. It
MUST be possible to perform OAM functions on a per domain basis and
across multiple domains. More generally it MUST be possible to
perform OAM functions between any two switching elements (e.g., LSR
or S-PE) of a LSP or of PW. This is referred to as (concatenated)
segment monitoring.
2.2. Functional Requirements 2.2. Functional Requirements
Hereafter are listed the required functions composing the MPLS-TP OAM Hereafter are listed the required functions composing the MPLS-TP OAM
tool-set. The list may not be exhaustive and as such the OAM toolset. The list may not be exhaustive and as such the OAM
mechanisms developed in support of the identified requirements SHALL mechanisms developed in support of the identified requirements SHALL
be extensible and thus SHALL NOT preclude the definition of be extensible and thus SHALL NOT preclude the definition of
additional OAM functions in the future. Furthermore, the design of additional OAM functions, in the future.
OAM mechanisms for MPLS-TP MUST allow the ability to support vendor
specific and experimental OAM functions. Vendor specific and
experimental OAM functions MUST be disabled by default and explicitly
enabled by a service provider or network operator, between nodes that
support them.
Moreover, the use of OAM functions SHOULD be optional for the service The design of OAM mechanisms, for MPLS-TP, MUST allow the ability to
provider or network operator. A network operator or service provider support vendor specific and experimental OAM functions. These
SHOULD be able to choose which OAM functions to use and which functions MUST be disabled by default.
Maintenance Entities to apply them to.
Note that the functions listed below can serve the purpose of fault The use of any OAM function MUST be optional for the service provider
and/or performance management. For example, connectivity verification or network operator and a network operator or service provider MUST
can be used for fault management application by detecting failure be able to choose which OAM function(s) to use and on which PW, LSP
conditions, but may also be used for performance management or Section to apply it(them) to.
application through its contribution to the evaluation of performance
metrics (e.g. unavailability time). Nevertheless, it is outside the
scope of this document to specify which function should be used for
which application.
2.2.1. General requirements It is RECOMMENDED by this document that a protocol solution,
realizing a given function, effectively provides a fully featured
function, i.e., a function which is applicable to all the cases
identified in the table in Section 2.3, for that function.
If a defect or fault occurs, mechanisms MUST be provided to detect The OAM functions MUST be able to be operated on PWs, LSPs and
it, diagnose it, localize it, and notify the appropriate entities. Sections.
Corrective actions SHOULD be taken according to the type of defect or
fault.
In the case of the PW Maintenance Entity, OAM mechanisms SHOULD be Note that the functions listed below can be used for fault
provided to ensure that customers do not have to detect faults. The management, performance monitoring and/or protection switching
OAM functions SHOULD allow the service provider to automatically applications. For example, connectivity verification can be used for
detect and notify the faults associated with a PW Maintenance Entity. fault management application by detecting failure conditions, but may
also be used for performance monitoring application through its
contribution to the evaluation of performance metrics (e.g.,
unavailability time). Nevertheless, it is outside the scope of this
document to specify which function should be used for which
application.
2.2.2. Connectivity and Continuity Verification 2.2.1. General Requirements
The MPLS-TP OAM tool-set MUST provide a function to enable service If a defect or fault occurs on a PW, LSP or Section, mechanisms MUST
providers to detect loss of continuity but also mis-connectivity be provided to detect it, diagnose it, localize it, and notify the
between two points of a Maintenance Entity. appropriate entities. Corrective actions SHOULD be taken according
to the type of defect or fault.
2.2.3. Client Failure Indication Furthermore, in case of a fault or defect, affecting a service
provided by a service provider, mechanisms MUST be available for the
service provider to be informed of the fault or defect even if the
fault or defect is located outside of his domain.
The MPLS-TP OAM tool-set MUST provide a function to enable a MEP to 2.2.2. Continuity Checks
propagate a client failure indication to its peer MEP when alarm
suppression in the client layer is not supported.
In cases where the OAM of the native service of an AC or a PW type The MPLS-TP OAM toolset MUST provide a function to enable service
does not provide mechanisms to propagate failure condition providers and network operators to detect loss of continuity, but
information, while a downstream indication of such state is needed, also unintended connectivity, on a PW, LSP or Section.
MPLS-TP OAM SHOULD provide mechanisms for propagating AC failures and
their clearance across a MPLS-TP domain.
2.2.4. Remote Defect Indication This function SHOULD be performed pro-actively.
The MPLS-TP OAM tool-set MUST provide a function to enable a MEP to This function SHOULD be performed between End Points of PWs, LSPs and
notify its peer MEP of the detection of a defect on a bi-directional Sections.
connection between them.
2.2.5. Alarm Suppression Means MUST be available to parameterize the frequency at which is
performed this function as well as to parameterize the criteria, if
any (e.g., number of consecutive OAM messages not received), based on
which loss of continuity or unintended connectivity is detected. A
default value MAY be defined.
The MPLS-TP OAM tool-set MUST provide a function to enable a server 2.2.3. Connectivity Verifications
layer MEP to notify a failure condition or an administrative locking
to its client layer MEP(s) in order to suppress alarms that may be
generated by maintenance domains of the client layer as a result of
the failure condition or of the administrative locking in the server
layer.
The MPLS-TP OAM tool-set MUST allow the client layer to differentiate The MPLS-TP OAM toolset MUST provide a function to enable service
between a defect condition and an administrative locking action at providers and network operators to verify the connectivity of a PW,
the server layer ME. LSP or Section.
The server layer MEP and the client layer MEPs MAY reside on the same This function SHOULD be performed on-demand.
node or on different nodes. A mechanism MUST be provided for both
cases.
An alarm suppression and summarization mechanism MUST be provided. This function SHOULD be performed between End Points and Intermediate
For example, a fault detected at the LSP level MUST NOT trigger Points of PWs and LSPs, and between End Points of PWs, LSPs and
various alarms at the PW level. Sections.
2.2.6. Packet Loss Note that, this function is sometime referred to as loopback as End
Points expect to receive some level of information as a result of
their action.
The MPLS-TP OAM tool-set MUST provide a function to enable service 2.2.4. Diagnostic
providers to measure packet loss ratio between a pair of MEPs. Packet
loss ratio is the ratio of the user-plane packets not delivered to
the total number of user-plane packets transmitted during a defined
time interval. The number of user-plane packets not delivered is the
difference between the number of user-plane packets transmitted by
the source node and the number of user-plane packets received at the
destination node.
2.2.7. Delay Measurement The MPLS-TP OAM toolset MAY provide a function to enable service
providers and network operators to perform diagnostic tests (e.g.,
verify bandwidth throughput) on a PW, LSP or Section.
The MPLS-TP OAM tool-set MUST provide a function to enable service This function SHOULD be performed on-demand.
providers to measure the one-way or two-way delay of a packet
transmission between a pair of MEPs. Where,
o One-way packet delay is the time elapsed from the start of This function SHOULD be performed between End Points and Intermediate
transmission of the first bit of the packet by a source node until Points of PWs and LSPs, and between End Points of PWs, LSPs and
the reception of the last bit of that packet by the destination Sections.
node.
o Two-way packet delay is the time elapsed from the start of This function MAY be provided as part of the Connectivity
transmission of the first bit of the packet by a source node until Verifications function (see Section 2.2.3).
the reception of the last bit of the loop-backed packet by the
same source node, when the loopback is performed at the packet's
destination node.
2.2.8. Route Determination 2.2.5. Adjacency
The MPLS-TP OAM tool-set MUST provide a function to enable service The MPLS-TP OAM toolset MUST provide a function to enable an End
providers to determine the route of a connection across the MPLS Point to request, to, and receive from, any node along a PW, LSP or
transport network. Section, a certain level of information (e.g., identification,
distance in hops).
2.2.9. Diagnostic This function SHOULD be performed on-demand.
The MPLS-TP OAM tool-set MUST provide a function to enable service This function SHOULD be performed between End Points and any node of
providers to verify bandwidth throughput (and other diagnostic tests) a PW, LSP and Section.
between a pair of MEPs.
2.3. Operational Requirements This function MAY be provided jointly with the Route Tracing function
(see Section 2.2.6).
OAM functions such as connectivity and continuity verification MUST 2.2.6. Route Tracing
NOT rely on user traffic. Dedicated OAM flows SHOULD be used to
detect connectivity and continuity defects. See also ITU-T G.806 .
[3].
This document does not mandate the use of a particular OAM function,
however, it is RECOMMENDED that connectivity and continuity
verification is performed on every Maintenance Entity in order to
reliably detect connectivity defects.
OAM functions MUST be applicable to bidirectional point-to-point The MPLS-TP OAM toolset MUST provide a function to enable service
connections, and a subset of these OAM functions MUST be applicable providers and network operators to trace the route a PW, LSP or
to unidirectional point-to-point and point-to-multipoint connections. Section. The information collected SHOULD include identifiers
This subset is based on the nature of both the OAM functions and the related to the nodes composing that route and MAY include interface
connections to which they can apply. identifiers.
The following table describes how, on which Maintenance Entity and This function SHOULD be performed on-demand.
between which points of the Maintenance Entity SHOULD the required
OAM functions be applied. In these tables, MEP stands for monitoring
from MEP to MEP, MIP stands for monitoring from MEP to MIP, U stands
for unidirectional, B stands for bidirectional. Crosses (x) indicate
the way the considered function should be applied, numbers indicate
the way the considered function should be applied while pointing to a
footnote providing additional details.
+-------------------------------------------+ This function SHOULD be performed between End Points and Intermediate
| on-demand | proactive | Points of PWs and LSPs, and between End Points of PWs, LSPs and
|---------------------+----------+----------| Sections.
| MEP | MIP | MEP | MIP |
|----------+----------+----------+----------|
| P2P |P2MP| P2P |P2MP| P2P |P2MP| P2P |P2MP|
|-----+----+----------+----------+-----+----|
|U |B | U |U |B | U |U |B | U |U |B | U |
+----------------------+--+--+----+--+--+----+--+--+----+--+--+----|
| cc verification | |x | | |x | |x |x | x | | | |
|----------------------+--+--+----+--+--+----+--+--+----+--+--+----|
| client fail. indic. | | | | | | | |x | | | | |
|----------------------+--+--+----+--+--+----+--+--+----+--+--+----|
| remote defect indic. | | | | | | | |x | | | | |
|----------------------+--+--+----+--+--+----+--+--+----+--+--+----|
| alarm suppression | | | | | | |x |x | x | | | |
|----------------------+--+--+----+--+--+----+--+--+----+--+--+----|
| packet loss measure | |1 | | | | |x |2 | x | | | |
|----------------------+--+--+----+--+--+----+--+--+----+--+--+----|
| delay measurement |x |3 | x | | | | | | | | | |
|----------------------+--+--+----+--+--+----+--+--+----+--+--+----|
| route determination | |x | | |x | | | | | | | |
|----------------------+--+--+----+--+--+----+--+--+----+--+--+----|
| diagnostic |x |x | x | | | | | | | | | |
+----------------------+-------------------------------------------+
1: single-ended packet loss measurements
2: in both directions of the bi-directional connection This function MAY be provided jointly with the Adjacency function
(see Section 2.2.5).
3: one-way and two-way packet delay measurements 2.2.7. Lock
Table 1 : OAM functions and their applicability scope The MPLS-TP OAM toolset MAY provide a function enabling to
administratively shut down a PW, LSP or Section; that is, to stop
user traffic being sent over that PW, LSP or Section.
2.4. Performance Requirements This function SHOULD be performed on-demand.
OAM functions SHOULD continue to meet their objectives regardless of This function SHOULD be performed between End Points of PWs, LSPs and
congestion conditions. See also ITU-T Y.1541 [4]. Sections.
Additional requirements will be incorporated in a future revision of 2.2.8. Alarm Notification
this document.
3. Security Considerations The MPLS-TP OAM toolset MUST provide a function to enable server
layer End Points to notify a fault condition or an administrative
locking to the client layer End Points affected by this status. This
would enable to suppress alarms that may be generated in the client
layer as a result of the fault condition or of the administrative
locking in the server layer.
Mechanisms SHOULD be provided to ensure that unauthorized access is The MPLS-TP OAM toolset MUST allow for the distinction between a
prevented from triggering any OAM function. fault condition and an administrative locking action.
OAM messages MAY be authenticated. The server layer End Points generating the notification and the
client layer End Points receiving the notification may or may not be
the same nodes. A mechanism MUST be provided to support both cases.
An OAM packet for a Maintenance Entity MUST NOT leak out of the ME, This function SHOULD be performed pro-actively.
i.e. go beyond the terminating MEP.
4. Congestion Considerations This function SHOULD be performed between the End Points of PWs, LSPs
and Sections and the End Points of the PWs and/or LSPs affected by
the fault condition or administrative locking.
A mechanism (e.g. rate limiting) MUST be provided to prevent OAM 2.2.9. Client Failure Indication
messages from causing congestion in the PSN.
5. IANA Considerations The MPLS-TP OAM toolset MUST provide a function to enable the
propagation of client fault condition information, across the MPLS-TP
network, if the client layer OAM mechanisms do not provide an alarm
notification/propagation mechanism.
There are no IANA actions required by this draft. This function SHOULD be performed pro-actively.
6. Acknowledgments This function SHOULD be performed between End Points of PWs, LSPs and
Sections.
The authors would like to thank all members of the teams (the Joint 2.2.10. Remote Defect Indication
Working Team, the MPLS Interoperability Design Team in IETF and the
T-MPLS Ad Hoc Group in ITU-T) involved in the definition and
specification of MPLS Transport Profile.
7. References The MPLS-TP OAM toolset MUST provide a function to enable an End
Point to notify its associated End Point of the detection of a fault
or defect that it detects on a PW, LSP or Section between them.
7.1. Normative References This function SHOULD be performed pro-actively.
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement This function SHOULD be performed between End Points of PWs, LSPs and
[2] ITU-T Recommendation M.3400 (2000), TMN management functions Sections.
[3] ITU-T Recommendation G.806 (2006), Characteristics of transport 2.2.11. Packet Loss
equipment - Description methodology and generic functionality
[4] ITU-T Recommendation Y.1541 (2006), Network performance Packet loss ratio is the ratio of the user packets not delivered to
objectives for IP-based services the total number of user packets transmitted during a defined time
interval. The number of user packets not delivered is the difference
between the number of user packets transmitted by an End Point and
the number of user packets received at an End Point.
[5] ITU-T Supplement Y.Sup4 (2008), Transport Requirements for T- The MPLS-TP OAM toolset MUST provide a function to enable service
MPLS OAM and considerations for the application of IETF MPLS providers and network operators to derive packet loss ratio over a
Technology PW, LSP or Section.
7.2. Informative References This OAM function MUST support the configurability of the interval of
time during which the measure is performed.
[6] Nadeau, T., et al., "Operations and Management (OAM) This function SHOULD be performed pro-actively.
Requirements for Multi-Protocol Label Switched (MPLS)
Networks", RFC 4377, February 2006
[7] Busi, I., Niven-Jenkins, B., "MPLS-TP OAM Framework and This function SHOULD be performed between End Points of PWs, LSPs and
Overview", draft-busi-mpls-tp-oam-framework, October 2008 Sections.
[8] Niven-Jenkins, B., Brungard, D., Betts, M., "MPLS-TP 2.2.12. Delay Measurement
Requirements", draft-ietf-mpls-tp-requirements, November 2008
Authors' Addresses The MPLS-TP OAM toolset MUST provide a function to enable service
providers and network operators to measure the one-way, and if
appropriate, the two-way, delay of a PW, LSP or Section.
Martin Vigoureux o One-way delay is the time elapsed from the start of transmission
Alcatel-Lucent of the first bit of an OAM packet by an End Point until the
reception of the last bit of that OAM packet by the other End
Point.
Email: martin.vigoureux@alcatel-lucent.com o Two-way delay is the time elapsed from the start of transmission
of the first bit of an OAM packet by a End Point until the
reception of the last bit of that OAM packet by the same End
Point, when the loopback is performed at the other End Point.
David Ward This function SHOULD be performed on-demand.
Cisco Systems, Inc.
Email: dward@cisco.com This function SHOULD be performed between End Points of PWs, LSPs and
Malcolm Betts Sections.
Nortel Networks
Email: betts01@nortel.com 2.3. Operational Requirements
Contributing Authors' Addresses The OAM functions MUST NOT rely on user traffic to achieve their
objectives; that is, dedicated OAM messages MUST be used.
Matthew Bocci Some OAM functions require certain parameters for their operation.
Alcatel-Lucent These parameters MUST be configurable. A default value MAY be
defined.
Email: matthew.bocci@alcatel-lucent.com The specification of certain parameters' values SHOULD be such that
it accounts, at the design phase, for various possible network
conditions (e.g., the continuity check function should continue to
meet its objective (i.e. detect failures) even in the context of high
traffic load (e.g., congestion)).
Italo Busi This document does not mandate the use of a particular OAM function.
Alcatel-Lucent However, it is RECOMMENDED that MPLS-TP enables continuity checks to
be performed on every PW, LSP and Section in order to reliably detect
connectivity defects and faults.
Email: italo.busi@alcatel-lucent.it OAM functions MUST be applicable to bidirectional point-to-point PWs,
LSPs and Sections, and a subset of these OAM functions MUST be
applicable to unidirectional point-to-point and point-to-multipoint
PWs, LSPs and Sections. This subset is based on the nature of both
the OAM functions and the connections to which they can apply.
Huub van Helvoort The following table describes how, between which points of PWs, LSPs
Huawei Technologies Co.Ltd. and Sections SHOULD the required OAM functions be applied. In these
tables U stands for unidirectional; B stands for bidirectional; EP
stands for an OAM function being performed between End Points; IP
stands for an OAM function being performed between End Points and
Intermediate Points. Crosses (x) indicate the way the considered
function should be applied; numbers indicate the way the considered
function should be applied while pointing to a footnote providing
additional details.
+-------------------------------------------+
| on-demand | pro-active |
|---------------------+----------+----------|
| MEP | MIP | MEP | MIP |
|----------+----------+----------+----------|
| P2P |P2MP| P2P |P2MP| P2P |P2MP| P2P |P2MP|
|-----+----+----------+----------+-----+----|
|U |B | U |U |B | U |U |B | U |U |B | U |
+----------------------+--+--+----+--+--+----+--+--+----+--+--+----|
| c. checks | | | | | | |x |x | x | | | |
|----------------------+--+--+----+--+--+----+--+--+----+--+--+----|
| c. verifications |1 |x | 1 |1 |x | 1 | | | | | | |
|----------------------+--+--+----+--+--+----+--+--+----+--+--+----|
| diagnostic |x |x | x |2 |2 | 2 | | | | | | |
|----------------------+--+--+----+--+--+----+--+--+----+--+--+----|
| adjacency |1 |x | 1 |1 |x | 1 | | | | | | |
|----------------------+--+--+----+--+--+----+--+--+----+--+--+----|
| route tracing |1 |x | 1 |1 |x | 1 | | | | | | |
|----------------------+--+--+----+--+--+----+--+--+----+--+--+----|
| lock |x |x | x | | | | | | | | | |
|----------------------+--+--+----+--+--+----+--+--+----+--+--+----|
| alarm notification | | | | | | |x |x | x | | | |
|----------------------+--+--+----+--+--+----+--+--+----+--+--+----|
| client fail. indic. | | | | | | |2 |x | 2 | | | |
|----------------------+--+--+----+--+--+----+--+--+----+--+--+----|
| remote defect indic. | | | | | | |1 |x | 1 | | | |
|----------------------+--+--+----+--+--+----+--+--+----+--+--+----|
| packet loss |2 |3 | 2 | | | |x |4 | x | | | |
|----------------------+--+--+----+--+--+----+--+--+----+--+--+----|
| delay measurement |x |x | x | | | |2 |2 | 2 | | | |
+----------------------+--+--+----+--+--+----+--+--+----+--+--+----+
1: the function MAY be provided if a return path exists
2: the function MAY be performed
3: the function SHOULD be performed in one direction
4: the function SHOULD be performed in both directions
Email: hhelvoort@huawei.com OAM functions and their applicability scope
Marc Lasserre 3. Congestion Considerations
Alcatel-Lucent
Email: mlasserre@alcatel-lucent.com A mechanism (e.g., rate limiting) MUST be provided to prevent OAM
packets from causing congestion in the PSN.
Lieven Levrau 4. Security Considerations
Alcatel-Lucent
Email: llevrau@alcatel-lucent.com This document, as itself, does not imply any security consideration
but OAM, as such, is subject to several security considerations. OAM
messages can reveal sensitive information such as passwords,
performance data and details about e.g., the network topology.
Han Li The nature of OAM therefore suggests having some form of
China Mobile Communications Corporation (CMCC) authentication, authorization and encryption in place. This will
Email: lihan@chinamobile.com prevent unauthorized access to MPLS-TP equipment and it will prevent
Julien Meuric third parties from learning about sensitive information about the
Orange transport network.
Email: julien.meuric@orange-ftgroup.com In general, mechanisms SHOULD be provided to ensure that OAM
functions cannot be accessed unauthorized.
Philippe Niger Further, OAM messages MAY be authenticated to prove their origin and
Orange to make sure that they are destined for the receiving node.
Email: philippe.niger@orange-ftgroup.com An OAM packet received over a PW, LSP or Section MUST NOT be
forwarded beyond the End Point of that PW, LSP or Section, so as to
avoid that the OAM packet leaves the current administrative domain.
Benjamin Niven-Jenkins 5. IANA Considerations
BT
Email: benjamin.niven-jenkins@bt.com There are no IANA actions required by this draft.
Jing Ruiquan 6. Acknowledgements
China Telecom
Email: jingrq@ctbri.com.cn
Nurit Sprecher The authors would like to thank all members of the teams (the Joint
Nokia-Siemens Networks Working Team, the MPLS Interoperability Design Team in IETF and the
MPLS-TP Ad Hoc Group in ITU-T) involved in the definition and
specification of MPLS-TP.
Email: nurit.sprecher@nsn.com 7. References
Yuji Tochio 7.1. Normative References
Fujitsu
Email: tochio@jp.fujitsu.com [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
Yaacov Weingarten [2] ITU-T Recommendation G.806, "Characteristics of transport
Nokia-Siemens Networks equipment - Description methodology and generic functionality",
2009.
Email: yaacov.weingarten@nsn.com [3] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label
Switched (MPLS) Data Plane Failures", RFC 4379, February 2006.
Intellectual Property Statement [4] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit
Connectivity Verification (VCCV): A Control Channel for
Pseudowires", RFC 5085, December 2007.
The IETF Trust takes no position regarding the validity or scope of 7.2. Informative References
any Intellectual Property Rights or other rights that might be
claimed to pertain to the implementation or use of the technology
described in any IETF Document or the extent to which any license
under such rights might or might not be available; nor does it
represent that it has made any independent effort to identify any
such rights.
Copies of Intellectual Property disclosures made to the IETF [5] Bocci, M., Bryant, S., and L. Levrau, "A Framework for MPLS in
Secretariat and any assurances of licenses to be made available, or Transport Networks", draft-ietf-mpls-tp-framework-00 (work in
the result of an attempt made to obtain a general license or progress), November 2008.
permission for the use of such proprietary rights by implementers or
users of this specification can be obtained from the IETF on-line IPR
repository at http://www.ietf.org/ipr
The IETF invites any interested party to bring to its attention any [6] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., and
copyrights, patents or patent applications, or other proprietary S. Ueno, "MPLS-TP Requirements",
rights that may cover technology that may be required to implement draft-ietf-mpls-tp-requirements-04 (work in progress),
any standard or specification contained in an IETF Document. Please February 2009.
address the information to the IETF at ietf-ipr@ietf.org
The definitive version of an IETF Document is that published by, or [7] ITU-T Supplement Y.Sup4, "ITU-T Y.1300-series: Supplement on
under the auspices of, the IETF. Versions of IETF Documents that are transport requirements for T-MPLS OAM and considerations for
published by third parties, including those that are translated into the application of IETF MPLS technology", 2008.
other languages, should not be considered to be definitive versions
of IETF Documents. The definitive version of these Legal Provisions
is that published by, or under the auspices of, the IETF. Versions of
these Legal Provisions that are published by third parties, including
those that are translated into other languages, should not be
considered to be definitive versions of these Legal Provisions.
For the avoidance of doubt, each Contributor to the IETF Standards [8] Nadeau, T., Morrow, M., Swallow, G., Allan, D., and S.
Process licenses each Contribution that he or she makes as part of Matsushima, "Operations and Management (OAM) Requirements for
the IETF Standards Process to the IETF Trust pursuant to the Multi-Protocol Label Switched (MPLS) Networks", RFC 4377,
provisions of RFC 5378. No language to the contrary, or terms, February 2006.
conditions or rights that differ from or are inconsistent with the
rights and licenses granted under RFC 5378, shall have any effect and
shall be null and void, whether published or posted by such
Contributor, or included with or in such Contribution.
Disclaimer of Validity [9] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, "BFD
For MPLS LSPs", draft-ietf-bfd-mpls-07 (work in progress),
June 2008.
All IETF Documents and the information contained therein are provided [10] Nadeau, T. and C. Pignataro, "Bidirectional Forwarding
on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE Detection (BFD) for the Pseudowire Virtual Circuit
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE Connectivity Verification (VCCV)", draft-ietf-pwe3-vccv-bfd-03
IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL (work in progress), February 2009.
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.
Copyright Statement Authors' Addresses
Copyright (c) 2008 IETF Trust and the persons identified as the Martin Vigoureux (editor)
document authors. All rights reserved. Alcatel-Lucent
This document is subject to BCP 78 and the IETF Trust's Legal Email: martin.vigoureux@alcatel-lucent.com
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of David Ward (editor)
publication of this document. Please review these documents Cisco Systems, Inc.
carefully, as they describe your rights and restrictions with respect
to this document. Email: dward@cisco.com
Malcolm Betts (editor)
Nortel Networks
Email: betts01@nortel.com
 End of changes. 155 change blocks. 
490 lines changed or deleted 473 lines changed or added

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