draft-ietf-mpls-tp-oam-requirements-01.txt   draft-ietf-mpls-tp-oam-requirements-02.txt 
MPLS Working Group M. Vigoureux, Ed. MPLS Working Group M. Vigoureux, Ed.
Internet-Draft Alcatel-Lucent Internet-Draft Alcatel-Lucent
Intended status: Informational D. Ward, Ed. Intended status: Standards Track D. Ward, Ed.
Expires: September 10, 2009 Cisco Systems, Inc. Expires: December 30, 2009 Cisco Systems, Inc.
M. Betts, Ed. M. Betts, Ed.
Nortel Networks Huawei
March 9, 2009 June 28, 2009
Requirements for OAM in MPLS Transport Networks Requirements for OAM in MPLS Transport Networks
draft-ietf-mpls-tp-oam-requirements-01 draft-ietf-mpls-tp-oam-requirements-02
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.
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 September 10, 2009. This Internet-Draft will expire on December 30, 2009.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. and restrictions with respect to this document.
Abstract Abstract
This document lists the requirements for the Operations, This document lists the requirements for the Operations,
Administration and Maintenance functionality of MPLS Transport Administration and Maintenance functionality of MPLS Transport
Profile. These requirements apply to pseudowires, Label Switched Profile. These requirements apply to pseudowires, Label Switched
Paths, and Sections. Architectural, functional and operational Paths, and Sections. Architectural and functional requirements are
requirements are covered in this document. covered in this document.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [1].
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Requirements Language and Terminology . . . . . . . . . . 4
1.2. Contributing Authors . . . . . . . . . . . . . . . . . . . 5 2. OAM Requirements . . . . . . . . . . . . . . . . . . . . . . . 4
2. OAM Requirements . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Architectural Requirements . . . . . . . . . . . . . . . . 5
2.1. Architectural Requirements . . . . . . . . . . . . . . . . 6 2.1.1. Scope of OAM . . . . . . . . . . . . . . . . . . . . . 5
2.1.1. Independence . . . . . . . . . . . . . . . . . . . . . 6 2.1.2. Independence . . . . . . . . . . . . . . . . . . . . . 5
2.1.2. Addressing, Routing and Forwarding . . . . . . . . . . 6 2.1.3. Addressing, Routing and Forwarding . . . . . . . . . . 6
2.1.3. Interoperability and Interworking . . . . . . . . . . 6 2.1.4. Interoperability and Interworking . . . . . . . . . . 6
2.1.4. Data Plane . . . . . . . . . . . . . . . . . . . . . . 7 2.1.5. Data Plane . . . . . . . . . . . . . . . . . . . . . . 7
2.1.5. Scope . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2. Functional Requirements . . . . . . . . . . . . . . . . . 7 2.2. Functional Requirements . . . . . . . . . . . . . . . . . 7
2.2.1. General Requirements . . . . . . . . . . . . . . . . . 8 2.2.1. General Requirements . . . . . . . . . . . . . . . . . 8
2.2.2. Continuity Checks . . . . . . . . . . . . . . . . . . 8 2.2.2. Continuity Checks . . . . . . . . . . . . . . . . . . 8
2.2.3. Connectivity Verifications . . . . . . . . . . . . . . 9 2.2.3. Connectivity Verifications . . . . . . . . . . . . . . 8
2.2.4. Diagnostic . . . . . . . . . . . . . . . . . . . . . . 9 2.2.4. Diagnostic . . . . . . . . . . . . . . . . . . . . . . 8
2.2.5. Adjacency . . . . . . . . . . . . . . . . . . . . . . 9 2.2.5. Route Tracing . . . . . . . . . . . . . . . . . . . . 9
2.2.6. Route Tracing . . . . . . . . . . . . . . . . . . . . 10 2.2.6. Lock Instruct . . . . . . . . . . . . . . . . . . . . 9
2.2.7. Lock . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.2.7. Lock Reporting . . . . . . . . . . . . . . . . . . . . 9
2.2.8. Alarm Notification . . . . . . . . . . . . . . . . . . 10 2.2.8. Alarm Reporting . . . . . . . . . . . . . . . . . . . 10
2.2.9. Client Failure Indication . . . . . . . . . . . . . . 11 2.2.9. Remote Defect Indication . . . . . . . . . . . . . . . 10
2.2.10. Remote Defect Indication . . . . . . . . . . . . . . . 11 2.2.10. Client Failure Indication . . . . . . . . . . . . . . 10
2.2.11. Packet Loss . . . . . . . . . . . . . . . . . . . . . 11 2.2.11. Packet Loss . . . . . . . . . . . . . . . . . . . . . 10
2.2.12. Delay Measurement . . . . . . . . . . . . . . . . . . 12 2.2.12. Delay Measurement . . . . . . . . . . . . . . . . . . 11
2.3. Operational Requirements . . . . . . . . . . . . . . . . . 12 3. Congestion Considerations . . . . . . . . . . . . . . . . . . 11
3. Congestion Considerations . . . . . . . . . . . . . . . . . . 14 4. Security Considerations . . . . . . . . . . . . . . . . . . . 11
4. Security Considerations . . . . . . . . . . . . . . . . . . . 14 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 7.1. Normative References . . . . . . . . . . . . . . . . . . . 12
7.1. Normative References . . . . . . . . . . . . . . . . . . . 15 7.2. Informative References . . . . . . . . . . . . . . . . . . 13
7.2. Informative References . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
In the context of MPLS Transport Profile (MPLS-TP, see [5] and [6]), In the context of MPLS Transport Profile (MPLS-TP, see [5] and [6]),
the rationales for Operations, Administration and Maintenance (OAM) the rationales for Operations, Administration and Maintenance (OAM)
mechanisms are twofold as they can serve: mechanisms are twofold as they can serve:
o as a network-oriented mechanism (used by a transport network o as a network-oriented mechanism (used by a transport network
operator) to monitor his network infrastructure and to implement operator) to monitor his network infrastructure and to implement
internal mechanisms in order to enhance the general behaviour and internal mechanisms in order to enhance the general behaviour and
the level of performance of his network (e.g., protection the level of performance of his network (e.g., protection
mechanism in case of node or link failure). For example fault mechanism in case of node or link failure). For example, fault
localization is typically associated to this use case. localization is typically associated with this use case.
o as a service-oriented mechanism (used by a transport service o as a service-oriented mechanism (used by a transport service
provider) to monitor offered services to end customers in order to provider) to monitor services offered to end customers in order to
be able to react rapidly in case of a problem and to be able 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 verify some of the Service Level Agreements (SLAs) parameters
(e.g., using performance monitoring) negotiated with the end (e.g., using performance monitoring) negotiated with the end
customer. Note that a transport service could be provided over customers. Note that a transport service could be provided over
several networks or administrative domains that may not be all several networks or administrative domains that may not all be
owned and managed by the same transport service provider. owned and managed by the same transport service provider.
More generally, OAM is an important and fundamental functionality in More generally, OAM is an important and fundamental functionality in
transport networks as it contributes to: transport networks as it contributes to:
o the reduction of operational complexity and costs, by allowing o the reduction of operational complexity and costs, by allowing for
efficient and automatic detection, localisation, handling, and efficient and automatic detection, localisation, handling, and
diagnosis of defects, and by minimizing service interruptions and diagnosis of defects, and by minimizing service interruptions and
operational repair times. operational repair times.
o the enhancement of network availability, by ensuring that defects, o the enhancement of network availability, by ensuring that defects,
for example resulting in misdirected customer traffic, and faults, for example resulting in misdirected customer traffic, and faults,
are detected, diagnosed and dealt with before a customer reports are detected, diagnosed and dealt with before a customer reports
the problem. the problem.
o meet service and performance objectives, by running OAM o meet service and performance objectives, as the OAM functionality
functionality which allows SLA verification in a multi-maintenance allows for SLA verification in a multi-maintenance domain
domain environment and allows the determination of service environment and allows for the determination of service
degradation due, for example, to packet delay or packet loss. degradation due, for example, to packet delay or packet loss.
This document lists the requirements for the OAM functionality of This document lists the requirements for the OAM functionality of
MPLS-TP. These requirements apply to pseudowires (PWs), Label MPLS-TP. These requirements apply to pseudowires (PWs), Label
Switched Paths (LSPs), and Sections. Switched Paths (LSPs), and Sections.
These requirements are derived from a set of requirements specified These requirements are derived from the set of requirements specified
by ITU-T and first published in the ITU-T Supplement Y.Sup4 [7]. by ITU-T and published in the ITU-T Supplement Y.Sup4 [7].
By covering transport specificities, these requirements stand as a By covering transport specificities, these requirements complement
complement to those identified in RFC 4377 [8]. those identified in RFC 4377 [8].
1.1. Definitions Note that the OAM functionalities identified in this document may be
used for fault management, performance monitoring and/or protection
switching applications. For example, connectivity verification can
be used for 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 functionality should be used
for which application.
In this document we refer to a fault as the inability of a function 1.1. Requirements Language and Terminology
to perform a required action. This does not include an inability due
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [1].
In this document we refer to the inability of a function to perform a
required action, as a fault. 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 [2]. 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 the situation in which the density of
density of anomalies has reached a level where the ability to perform anomalies has reached a level where the ability to perform a required
a required function has been interrupted. See also ITU-T G.806 [2]. function has been interrupted, as a defect. See also ITU-T G.806
[2].
In this document we refer to a Label Edge Router (LER), for a given 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 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 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 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 (S-PE), for a given PW, as an Intermediate Point. This document does
not make any distinction between End Points (e.g., source and not make a distinction between End Points (e.g., source and
destination) as it can be inferred from the context of the sentences. destination) as it can be inferred from the context of the sentences.
In this document we use the term "node" as a general referral to End In this document we use the term "node" as a general reference to End
Points and Intermediate Points. Points and Intermediate Points.
Other definitions, relating to MPLS-TP, can be found in [6]. In this document we refer to both segment and concatenated segments
as segments (see [6] for definitions relating to the term "segment"
1.2. Contributing Authors as well as for other definitions relating to MPLS-TP).
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.
2. OAM Requirements 2. OAM Requirements
This section lists the requirements by which the OAM functionality of This section lists the requirements by which the OAM functionality of
MPLS-TP should abide. Note that some requirements for this MPLS-TP should abide. Note that some requirements for this
application of MPLS are similar to some of those listed in RFC 4377 application of MPLS are similar to some of those listed in RFC 4377
[8]. [8].
The requirements listed below may be met by one or more OAM The requirements listed below may be met by one or more OAM
protocols; the definition or selection of these protocols is outside protocols; the definition or selection of these protocols is outside
the scope of this document. the scope of this document.
2.1. Architectural Requirements 2.1. Architectural Requirements
2.1.1. Independence 2.1.1. Scope of OAM
OAM functions SHOULD be independent of the underlying tunnelling or The protocol solutions developed to meet the requirements identified
point-to-point technology or transmission media. in this document MUST be applicable to point-to-point bidirectional
PWs, point-to-point bidirectional LSPs, and point-to-point
bidirectional Sections and SHOULD additionaly be applicable to
unidirectional point-to-point and point-to-multipoint LSPs.
OAM functions SHOULD be independent of the service a PW may emulate. The service emulated by a single segment or a multi-segment PW may
span multiple domains. An LSP may also span multiple domains. It
MUST be possible to operate OAM functions on a per domain basis.
More generally, the protocol solutions MUST be applicable end-to-end
and to segments.
The set of OAM functions operated on a PW, LSP or Section SHOULD be Since LSPs may be stacked, the protocol solutions MUST be applicable
independent of the set of OAM functions operated on a different PW, on any LSP, regardless of the label stack depth. Furthermore it MUST
LSP or Section. In other words, only the OAM functions available for be possible to estimate OAM fault and performance metrics of a single
e.g., a LSP should be used to achieve the OAM objectives for that PW or LSP segment or of an aggregate of PWs or LSPs segments.
LSP. Note that independence should not be understood here in terms
of isolation as there can be interactions between OAM functions 2.1.2. Independence
operated on e.g., a LSP and on another LSP or on a PW.
The protocol solutions SHOULD be independent of the underlying
tunnelling or point-to-point technology or transmission media.
The protocol solutions SHOULD be independent of the service a PW may
emulate.
Any OAM function operated on a PW, LSP or Section SHOULD be
independent of the OAM function(s) operated on a different PW, LSP or
Section. In other words, only the OAM functions operated on e.g., a
given 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., an LSP, and on another LSP or a PW.
Likewise, any OAM function applied to segment(s) of a PW or LSP
SHOULD be independent of the OAM function(s) operated on the end-to-
end PW or LSP. It SHOULD also be possible to distinguish an OAM
packet running over a segment of a PW or LSP from another OAM packet
running on the end-to-end PW or LSP. Furthermore, any OAM function
applied to segment(s) of a PW or LSP SHOULD be independent of the OAM
function(s) applied to other segment(s) of the same PW or LSP.
Finally, the protocol solutions MUST support the capability to be
concurrently and independently operated end-to-end and on segments.
OAM functions MUST operate and be configurable even in the absence of OAM functions MUST operate and be configurable even in the absence of
a control plane. Conversely, OAM functions SHOULD be configurable as a control plane. Conversely, it SHOULD be possible to enable/disable
part of connectivity (e.g., LSP or PW) management. Means for the capability to operate OAM functions as part of connectivity
configuring OAM functions and for connectivity management are outside management and it SHOULD also be possible to enable/disable the
the scope of this document. capability to operate OAM functions after connectivity has been
established. In the latter case, the customer MUST NOT perceive
service degradation as a result of OAM enabling/disabling. Ideally
OAM enabling/disabling should take place without introducing any
customer impairments (e.g., no customer packet losses). Procedures
aimed to prevent any traffic impairment MUST be defined for the
enabling/disabling of OAM functions. Means for configuring OAM
functions and for connectivity management are outside the scope of
this document.
2.1.2. Addressing, Routing and Forwarding 2.1.3. Addressing, Routing and Forwarding
The OAM functionality may be deployed in a variety of environments. The OAM functionality may be deployed in a variety of environments.
o In some environments (e.g., IP/MPLS environments), IP routing and o In some environments (e.g., IP/MPLS environments), IP routing and
forwarding capabilities are inherently present. In this case, the forwarding capabilities are inherently present in the forwarding
OAM functionality MUST support the use of IP routing and plane. In this case, it MUST be possible to operate the OAM
forwarding capabilities. functions by relying on IP routing and forwarding capabilities.
o In some environments (e.g., MPLS-TP environments), IP routing and o In some environments (e.g., MPLS-TP environments), IP routing and
forwarding capabilities may not necessarily be present. In this forwarding capabilities may not necessarily be present in the user
case, the OAM functions and their operation MUST NOT require plane. In this case, it MUST be possible to operate the OAM
relying on IP routing and forwarding capabilities. functions without relying on IP routing and forwarding
capabilities.
In case OAM messages need to incorporate identification information In cases where OAM messages need to incorporate identification
(e.g., of source and/or destination nodes), the protocol solution information (e.g., source and/or destination nodes), the protocol
MUST at least support an IP addressing structure and MUST also be solution(s) MUST at least support an IP addressing structure and MUST
extensible to support additional addressing schemes. also be extensible to support additional identification schemes.
2.1.3. Interoperability and Interworking 2.1.4. Interoperability and Interworking
It is REQUIRED by this document that OAM interoperability is achieved It is REQUIRED that OAM interoperability is achieved across the
across the environments described in Section 2.1.2. It is also environments described in Section 2.1.3. It is also REQUIRED that
REQUIRED by this document that the two first requirements of Section the two first requirements of Section 2.1.3 still hold and MUST still
2.1.2 still hold and MUST thus still be met when interoperability is be met when interoperability is achieved.
achieved.
When MPLS-TP is run with IP routing and forwarding capabilities, it When MPLS-TP is run with IP routing and forwarding capabilities, it
MUST be possible to operate any of the existing IP/MPLS and PW OAM MUST be possible to operate any of the existing IP/MPLS and PW OAM
functionalities (e.g., LSP-Ping [3], MPLS-BFD [9], VCCV [4] and VCCV- protocols (e.g., LSP-Ping [3], MPLS-BFD [9], VCCV [4] and VCCV-BFD
BFD [10]). [10]).
The protocol solution(s) developed to meet the requirements listed in
this document MUST interwork with the existing IP/MPLS and PW OAM
protocols.
2.1.4. Data Plane 2.1.5. Data Plane
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 PW, LSP or Section 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 PW, LSP or follow the exact same data path as user traffic of that PW, LSP or
Section. Section. This is often referred to as fate sharing.
It MUST be possible to discriminate user 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,
packets, at the nodes targeted by these OAM packets. at the nodes targeted by these OAM packets.
As part of the design of OAM protocol solutions for MPLS-TP, a
mechanism enabling to encapsulate and differentiate OAM messages, on
a PW, LSP or Section, MUST be provided. Such mechanism MUST also
support the encapsulation and differentiation of existing IP/MPLS and
PW OAM messages.
2.1.5. Scope
The service emulated by a single segment or a multi-segment PW may As part of the design of OAM protocol solution(s) for MPLS-TP, a
span multiple domains. A LSP may also span multiple domains. It mechanism, for enabling the encapsulation and differentiation of OAM
MUST be possible to perform OAM functions on a per domain basis and messages on a PW, LSP or Section, MUST be provided. Such mechanism
across multiple domains. More generally it MUST be possible to SHOULD also support the encapsulation and differentiation of existing
perform OAM functions between any two switching elements (e.g., LSR IP/MPLS and PW OAM messages.
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 functionalities composing the
toolset. The list may not be exhaustive and as such the OAM MPLS-TP OAM toolset. The list may not be exhaustive and as such the
mechanisms developed in support of the identified requirements SHALL OAM mechanisms developed in support of the identified requirements
be extensible and thus SHALL NOT preclude the definition of SHALL be extensible and thus SHALL NOT preclude the definition of
additional OAM functions, in the future. additional OAM functionalities, in the future.
The design of OAM mechanisms, for MPLS-TP, MUST allow the ability to The design of OAM mechanisms for MPLS-TP, MUST allow for the ability
support vendor specific and experimental OAM functions. These to support experimental OAM functions. These functions MUST be
functions MUST be disabled by default. disabled by default.
The use of any OAM function MUST be optional for the service provider The use of any OAM function MUST be optional and it MUST be possible
or network operator and a network operator or service provider MUST to choose which OAM function(s) to use and on which PW, LSP or
be able to choose which OAM function(s) to use and on which PW, LSP Section to apply it(them) to.
or Section to apply it(them) to.
It is RECOMMENDED by this document that a protocol solution, It is RECOMMENDED that the protocol solution, meeting one or more
realizing a given function, effectively provides a fully featured functional requirement(s), be the same for PWs, LSPs and Sections.
function, i.e., a function which is applicable to all the cases
identified in the table in Section 2.3, for that function.
The OAM functions MUST be able to be operated on PWs, LSPs and It is RECOMMENDED that the protocol solution, meeting one or more
Sections. functional requirement(s), effectively provides a fully featured
function; that is, a function which is applicable to all the cases
identified for that functionality. In that context, protocol
solution(s) MUST state their applicability.
Note that the functions listed below can be used for fault Unless otherwise stated, the OAM functionalities MUST NOT rely on
management, performance monitoring and/or protection switching user traffic; that is, only OAM messages MUST be used to achieve the
applications. For example, connectivity verification can be used for objectives.
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.1. General Requirements 2.2.1. General Requirements
If a defect or fault occurs on a PW, LSP or Section, mechanisms MUST If a defect or fault occurs on a PW, LSP or Section, mechanisms MUST
be provided to detect it, diagnose it, localize it, and notify the be provided to detect it, diagnose it, localize it, and notify the
appropriate entities. Corrective actions SHOULD be taken according appropriate nodes. Mechanisms SHOULD exist such that corrective
to the type of defect or fault. actions can be taken.
Furthermore, in case of a fault or defect, affecting a service Furthermore, mechanisms MUST be available for a service provider to
provided by a service provider, mechanisms MUST be available for the be informed of a fault or defect affecting the service(s) it
service provider to be informed of the fault or defect even if the provides, even if the fault or defect is located outside of his
fault or defect is located outside of his domain. domain.
2.2.2. Continuity Checks The protocol solution(s) developed to meet these requirements may
rely on information exchange. Information exchange between various
nodes involved in the operation of an OAM function SHOULD be reliable
such that, for example, defects or faults are properly detected or
that state changes are effectively known by the appropriate nodes.
The MPLS-TP OAM toolset MUST provide a function to enable service 2.2.2. Continuity Checks
providers and network operators to detect loss of continuity, but
also unintended connectivity, on a PW, LSP or Section.
This function SHOULD be performed pro-actively. The MPLS-TP OAM toolset MUST provide functionality to enable the
verification of the continuity of a PW, LSP or Section.
This function SHOULD be performed between End Points of PWs, LSPs and This function SHOULD be performed between End Points of PWs, LSPs and
Sections. Sections.
Means MUST be available to parameterize the frequency at which is This function SHOULD be performed pro-actively.
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.
2.2.3. Connectivity Verifications 2.2.3. Connectivity Verifications
The MPLS-TP OAM toolset MUST provide a function to enable service The MPLS-TP OAM toolset MUST provide functionality to enable the
providers and network operators to verify the connectivity of a PW, verification of the connectivity of a PW, LSP or Section.
LSP or Section.
This function SHOULD be performed on-demand.
This function SHOULD be performed between End Points and Intermediate This function SHOULD be performed between End Points and Intermediate
Points of PWs and LSPs, and between End Points of PWs, LSPs and Points of PWs and LSPs, and between End Points of PWs, LSPs and
Sections. Sections.
Note that, this function is sometime referred to as loopback as End This function SHOULD be performed on-demand. This function SHOULD be
Points expect to receive some level of information as a result of performed pro-actively only between End Points of PWs, LSPs and
their action. Sections.
2.2.4. Diagnostic 2.2.4. Diagnostic
The MPLS-TP OAM toolset MAY provide a function to enable service The MPLS-TP OAM toolset MAY provide functionality to enable the
providers and network operators to perform diagnostic tests (e.g., conduction of diagnostic tests on a PW, LSP or Section. An example
verify bandwidth throughput) on a PW, LSP or Section. of such diagnotic test would consist in looping the traffic at an
Intermediate Point, back to the End Point it originates from.
Another example of such diagnotic test would consist in estimating
the bandwidth of e.g., an LSP.
This function SHOULD be performed on-demand. This function SHOULD be performed on-demand.
This function SHOULD be performed between End Points and Intermediate This function SHOULD be performed between End Points and Intermediate
Points of PWs and LSPs, and between End Points of PWs, LSPs and Points of PWs and LSPs, and between End Points of PWs, LSPs and
Sections. Sections.
This function MAY be provided as part of the Connectivity 2.2.5. Route Tracing
Verifications function (see Section 2.2.3).
2.2.5. Adjacency
The MPLS-TP OAM toolset MUST provide a function to enable an End
Point to request, to, and receive from, any node along a PW, LSP or
Section, a certain level of information (e.g., identification,
distance in hops).
This function SHOULD be performed on-demand.
This function SHOULD be performed between End Points and any node of
a PW, LSP and Section.
This function MAY be provided jointly with the Route Tracing function
(see Section 2.2.6).
2.2.6. Route Tracing
The MPLS-TP OAM toolset MUST provide a function to enable service The MPLS-TP OAM toolset MUST provide functionality to enable an End
providers and network operators to trace the route a PW, LSP or Point to discover the Intermediate (if any) and End Point(s) along a
Section. The information collected SHOULD include identifiers PW, LSP or Section, and more generaly to trace the route of a PW, LSP
related to the nodes composing that route and MAY include interface or Section. The information collected MUST include identifiers
identifiers. related to the nodes and interfaces composing that route.
This function SHOULD be performed on-demand. This function SHOULD be performed on-demand.
This function SHOULD be performed between End Points and Intermediate This function SHOULD be performed between End Points and Intermediate
Points of PWs and LSPs, and between End Points of PWs, LSPs and Points of PWs and LSPs, and between End Points of PWs, LSPs and
Sections. Sections.
This function MAY be provided jointly with the Adjacency function 2.2.6. Lock Instruct
(see Section 2.2.5).
2.2.7. Lock
The MPLS-TP OAM toolset MAY provide a function enabling to The MPLS-TP OAM toolset MUST provide functionality to enable an End
administratively shut down a PW, LSP or Section; that is, to stop Point of a PW, LSP or Section to instruct its associated End Point(s)
user traffic being sent over that PW, LSP or Section. to lock the PW, LSP or Section. Note that lock corresponds to an
administrative status in which forwarding traffic on and from the PW,
LSP or Section is disabled.
This function SHOULD be performed on-demand. This function SHOULD be performed on-demand.
This function SHOULD be performed between End Points of PWs, LSPs and This function SHOULD be performed between End Points of PWs, LSPs and
Sections. Sections.
2.2.8. Alarm Notification 2.2.7. Lock Reporting
The MPLS-TP OAM toolset MUST provide a function to enable server The MPLS-TP OAM toolset MUST provide functionality to enable an
layer End Points to notify a fault condition or an administrative Intermediate Point of a PW or LSP to report, to an End Point of that
locking to the client layer End Points affected by this status. This same PW or LSP, an external lock condition affecting that PW or LSP.
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.
The MPLS-TP OAM toolset MUST allow for the distinction between a This function SHOULD be performed pro-actively.
fault condition and an administrative locking action.
The server layer End Points generating the notification and the This function SHOULD be performed between Intermediate Points and End
client layer End Points receiving the notification may or may not be Points of PWs and LSPs.
the same nodes. A mechanism MUST be provided to support both cases.
2.2.8. Alarm Reporting
The MPLS-TP OAM toolset MUST provide functionality to enable an
Intermediate Point of a PW or LSP to report, to an End Point of that
same PW or LSP, a fault or defect condition affecting that PW or LSP.
This function SHOULD be performed pro-actively. This function SHOULD be performed pro-actively.
This function SHOULD be performed between the End Points of PWs, LSPs This function SHOULD be performed between Intermediate Points and End
and Sections and the End Points of the PWs and/or LSPs affected by Points of PWs and LSPs.
the fault condition or administrative locking.
2.2.9. Client Failure Indication 2.2.9. Remote Defect Indication
The MPLS-TP OAM toolset MUST provide a function to enable the The MPLS-TP OAM toolset MUST provide functionality to enable an End
propagation of client fault condition information, across the MPLS-TP Point to report, to its associated End Point, a fault or defect
network, if the client layer OAM mechanisms do not provide an alarm condition that it detects on a PW, LSP or Section for which they are
notification/propagation mechanism. the End Points.
This function SHOULD be performed pro-actively. This function SHOULD be performed pro-actively.
This function SHOULD be performed between End Points of PWs, LSPs and This function SHOULD be performed between End Points of PWs, LSPs and
Sections. Sections.
2.2.10. Remote Defect Indication 2.2.10. Client Failure Indication
The MPLS-TP OAM toolset MUST provide a function to enable an End The MPLS-TP OAM toolset MUST provide functionality to enable the
Point to notify its associated End Point of the detection of a fault propagation, across an MPLS-TP network, of information pertaining to
or defect that it detects on a PW, LSP or Section between them. a client defect of fault condition detected at an End Point of a PW
or LSP, if the client layer OAM mechanisms do not provide an alarm
notification/propagation mechanism.
This function SHOULD be performed pro-actively. This function SHOULD be performed pro-actively.
This function SHOULD be performed between End Points of PWs, LSPs and This function SHOULD be performed between End Points of PWs and LSPs.
Sections.
2.2.11. Packet Loss 2.2.11. Packet Loss
Packet loss ratio is the ratio of the user packets not delivered to The MPLS-TP OAM toolset MUST provide functionality to enable the
the total number of user packets transmitted during a defined time quantification of packet loss ratio over a PW, LSP or Section.
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.
The MPLS-TP OAM toolset MUST provide a function to enable service
providers and network operators to derive packet loss ratio over a
PW, LSP or Section.
This OAM function MUST support the configurability of the interval of Note that packet loss ratio is the ratio of the user packets not
time during which the measure is performed. delivered to 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.
This function SHOULD be performed pro-actively. This function MAY either be performed pro-actively or on-demand.
This function SHOULD be performed between End Points of PWs, LSPs and This function SHOULD be performed between End Points of PWs, LSPs and
Sections. Sections.
It SHOULD be possible to rely on user-plane traffic to achieve that
functionality.
2.2.12. Delay Measurement 2.2.12. Delay Measurement
The MPLS-TP OAM toolset MUST provide a function to enable service The MPLS-TP OAM toolset MUST provide functionality to enable the
providers and network operators to measure the one-way, and if quantification of the one-way, and if appropriate, the two-way, delay
appropriate, the two-way, delay of a PW, LSP or Section. of a PW, LSP or Section.
o One-way delay is the time elapsed from the start of transmission o One-way delay is the time elapsed from the start of transmission
of the first bit of an OAM packet by an End Point until the of the first bit of a packet by an End Point until the reception
reception of the last bit of that OAM packet by the other End of the last bit of that packet by the other End Point.
Point.
o Two-way delay is the time elapsed from the start of transmission 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 of the first bit of a packet by a End Point until the reception of
reception of the last bit of that OAM packet by the same End the last bit of that packet by the same End Point, when loopback
Point, when the loopback is performed at the other End Point. is performed at the other End Point.
This function SHOULD be performed on-demand. This function SHOULD be performed on-demand and MAY be perform pro-
actively.
This function SHOULD be performed between End Points of PWs, LSPs and This function SHOULD be performed between End Points of PWs, LSPs and
Sections. Sections.
2.3. Operational Requirements It SHOULD be possible to rely on user-plane traffic to achieve that
functionality.
The OAM functions MUST NOT rely on user traffic to achieve their
objectives; that is, dedicated OAM messages MUST be used.
Some OAM functions require certain parameters for their operation.
These parameters MUST be configurable. A default value MAY be
defined.
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)).
This document does not mandate the use of a particular OAM function.
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.
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.
The following table describes how, between which points of PWs, LSPs
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
OAM functions and their applicability scope
3. Congestion Considerations 3. Congestion Considerations
A mechanism (e.g., rate limiting) MUST be provided to prevent OAM A mechanism (e.g., rate limiting) MUST be provided to prevent OAM
packets from causing congestion in the PSN. packets from causing congestion in the PSN.
4. Security Considerations 4. Security Considerations
This document, as itself, does not imply any security consideration This document, as itself, does not imply any security consideration
but OAM, as such, is subject to several security considerations. OAM but OAM, as such, is subject to several security considerations. OAM
skipping to change at page 14, line 39 skipping to change at page 12, line 22
An OAM packet received over a PW, LSP or Section MUST NOT be 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 forwarded beyond the End Point of that PW, LSP or Section, so as to
avoid that the OAM packet leaves the current administrative domain. avoid that the OAM packet leaves the current administrative domain.
5. IANA Considerations 5. IANA Considerations
There are no IANA actions required by this draft. There are no IANA actions required by this draft.
6. Acknowledgements 6. Acknowledgements
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.
The authors would like to thank all members of the teams (the Joint The authors would like to thank all members of the teams (the Joint
Working Team, the MPLS Interoperability Design Team in IETF and the Working Team, the MPLS Interoperability Design Team in IETF and the
MPLS-TP Ad Hoc Group in ITU-T) involved in the definition and MPLS-TP Ad Hoc Group in ITU-T) involved in the definition and
specification of MPLS-TP. specification of MPLS-TP.
7. References 7. References
7.1. Normative References 7.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
skipping to change at page 15, line 31 skipping to change at page 13, line 14
Pseudowires", RFC 5085, December 2007. Pseudowires", RFC 5085, December 2007.
7.2. Informative References 7.2. Informative References
[5] Bocci, M., Bryant, S., and L. Levrau, "A Framework for MPLS in [5] Bocci, M., Bryant, S., and L. Levrau, "A Framework for MPLS in
Transport Networks", draft-ietf-mpls-tp-framework-00 (work in Transport Networks", draft-ietf-mpls-tp-framework-00 (work in
progress), November 2008. progress), November 2008.
[6] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., and [6] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., and
S. Ueno, "MPLS-TP Requirements", S. Ueno, "MPLS-TP Requirements",
draft-ietf-mpls-tp-requirements-04 (work in progress), draft-ietf-mpls-tp-requirements-09 (work in progress),
February 2009. June 2009.
[7] ITU-T Supplement Y.Sup4, "ITU-T Y.1300-series: Supplement on [7] ITU-T Supplement Y.Sup4, "ITU-T Y.1300-series: Supplement on
transport requirements for T-MPLS OAM and considerations for transport requirements for T-MPLS OAM and considerations for
the application of IETF MPLS technology", 2008. the application of IETF MPLS technology", 2008.
[8] Nadeau, T., Morrow, M., Swallow, G., Allan, D., and S. [8] Nadeau, T., Morrow, M., Swallow, G., Allan, D., and S.
Matsushima, "Operations and Management (OAM) Requirements for Matsushima, "Operations and Management (OAM) Requirements for
Multi-Protocol Label Switched (MPLS) Networks", RFC 4377, Multi-Protocol Label Switched (MPLS) Networks", RFC 4377,
February 2006. February 2006.
[9] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, "BFD [9] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, "BFD
For MPLS LSPs", draft-ietf-bfd-mpls-07 (work in progress), For MPLS LSPs", draft-ietf-bfd-mpls-07 (work in progress),
June 2008. June 2008.
[10] Nadeau, T. and C. Pignataro, "Bidirectional Forwarding [10] Nadeau, T. and C. Pignataro, "Bidirectional Forwarding
Detection (BFD) for the Pseudowire Virtual Circuit Detection (BFD) for the Pseudowire Virtual Circuit
Connectivity Verification (VCCV)", draft-ietf-pwe3-vccv-bfd-03 Connectivity Verification (VCCV)", draft-ietf-pwe3-vccv-bfd-05
(work in progress), February 2009. (work in progress), June 2009.
Authors' Addresses Authors' Addresses
Martin Vigoureux (editor) Martin Vigoureux (editor)
Alcatel-Lucent Alcatel-Lucent
Route de Villejust
Nozay, 91620
France
Email: martin.vigoureux@alcatel-lucent.com Email: martin.vigoureux@alcatel-lucent.com
David Ward (editor) David Ward (editor)
Cisco Systems, Inc. Cisco Systems, Inc.
170 W. Tasman Dr.
San Jose, CA 95134
USA
Email: dward@cisco.com Email: dward@cisco.com
Malcolm Betts (editor) Malcolm Betts (editor)
Nortel Networks Huawei
Email: betts01@nortel.com Email: malcolm.betts@huawei.com
 End of changes. 83 change blocks. 
342 lines changed or deleted 282 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/