draft-ietf-mpls-tp-oam-requirements-02.txt   draft-ietf-mpls-tp-oam-requirements-03.txt 
MPLS Working Group M. Vigoureux, Ed. MPLS Working Group M. Vigoureux, Ed.
Internet-Draft Alcatel-Lucent Internet-Draft Alcatel-Lucent
Intended status: Standards Track D. Ward, Ed. Intended status: Standards Track D. Ward, Ed.
Expires: December 30, 2009 Cisco Systems, Inc. Expires: March 4, 2010 Cisco Systems, Inc.
M. Betts, Ed. M. Betts, Ed.
Huawei Huawei
June 28, 2009 August 31, 2009
Requirements for OAM in MPLS Transport Networks Requirements for OAM in MPLS Transport Networks
draft-ietf-mpls-tp-oam-requirements-02 draft-ietf-mpls-tp-oam-requirements-03
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 35 skipping to change at page 1, line 35
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 December 30, 2009. This Internet-Draft will expire on March 4, 2010.
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 architectural and functional requirements for the
Administration and Maintenance functionality of MPLS Transport Operations, Administration and Maintenance of MPLS Transport Profile.
Profile. These requirements apply to pseudowires, Label Switched These requirements apply to pseudowires, Label Switched Paths, and
Paths, and Sections. Architectural and functional requirements are Sections.
covered in this document.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language and Terminology . . . . . . . . . . 4 1.1. Scope of this Document . . . . . . . . . . . . . . . . . . 3
2. OAM Requirements . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Requirements Language and Terminology . . . . . . . . . . 4
2. OAM Requirements . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Architectural Requirements . . . . . . . . . . . . . . . . 5 2.1. Architectural Requirements . . . . . . . . . . . . . . . . 5
2.1.1. Scope of OAM . . . . . . . . . . . . . . . . . . . . . 5 2.1.1. Scope of OAM . . . . . . . . . . . . . . . . . . . . . 5
2.1.2. Independence . . . . . . . . . . . . . . . . . . . . . 5 2.1.2. Independence . . . . . . . . . . . . . . . . . . . . . 6
2.1.3. Addressing, Routing and Forwarding . . . . . . . . . . 6 2.1.3. OAM and IP Capabilities . . . . . . . . . . . . . . . 6
2.1.4. Interoperability and Interworking . . . . . . . . . . 6 2.1.4. Interoperability and Interworking . . . . . . . . . . 7
2.1.5. Data Plane . . . . . . . . . . . . . . . . . . . . . . 7 2.1.5. Data Plane . . . . . . . . . . . . . . . . . . . . . . 7
2.2. Functional Requirements . . . . . . . . . . . . . . . . . 7 2.1.6. Configuration . . . . . . . . . . . . . . . . . . . . 7
2.2. Functional Requirements . . . . . . . . . . . . . . . . . 8
2.2.1. General Requirements . . . . . . . . . . . . . . . . . 8 2.2.1. General Requirements . . . . . . . . . . . . . . . . . 8
2.2.2. Continuity Checks . . . . . . . . . . . . . . . . . . 8 2.2.2. Continuity Checks . . . . . . . . . . . . . . . . . . 9
2.2.3. Connectivity Verifications . . . . . . . . . . . . . . 8 2.2.3. Connectivity Verifications . . . . . . . . . . . . . . 9
2.2.4. Diagnostic . . . . . . . . . . . . . . . . . . . . . . 8 2.2.4. Diagnostic Tests . . . . . . . . . . . . . . . . . . . 9
2.2.5. Route Tracing . . . . . . . . . . . . . . . . . . . . 9 2.2.5. Route Tracing . . . . . . . . . . . . . . . . . . . . 10
2.2.6. Lock Instruct . . . . . . . . . . . . . . . . . . . . 9 2.2.6. Lock Instruct . . . . . . . . . . . . . . . . . . . . 10
2.2.7. Lock Reporting . . . . . . . . . . . . . . . . . . . . 9 2.2.7. Lock Reporting . . . . . . . . . . . . . . . . . . . . 11
2.2.8. Alarm Reporting . . . . . . . . . . . . . . . . . . . 10 2.2.8. Alarm Reporting . . . . . . . . . . . . . . . . . . . 11
2.2.9. Remote Defect Indication . . . . . . . . . . . . . . . 10 2.2.9. Remote Defect Indication . . . . . . . . . . . . . . . 12
2.2.10. Client Failure Indication . . . . . . . . . . . . . . 10 2.2.10. Client Failure Indication . . . . . . . . . . . . . . 12
2.2.11. Packet Loss . . . . . . . . . . . . . . . . . . . . . 10 2.2.11. Packet Loss Measurement . . . . . . . . . . . . . . . 12
2.2.12. Delay Measurement . . . . . . . . . . . . . . . . . . 11 2.2.12. Packet Delay Measurement . . . . . . . . . . . . . . . 13
3. Congestion Considerations . . . . . . . . . . . . . . . . . . 11 3. Congestion Considerations . . . . . . . . . . . . . . . . . . 13
4. Security Considerations . . . . . . . . . . . . . . . . . . . 11 4. Security Considerations . . . . . . . . . . . . . . . . . . . 13
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
7.1. Normative References . . . . . . . . . . . . . . . . . . . 12 7.1. Normative References . . . . . . . . . . . . . . . . . . . 14
7.2. Informative References . . . . . . . . . . . . . . . . . . 13 7.2. Informative References . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
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: are twofold as it can serve:
o as a network-oriented mechanism (used by a transport network o as a network-oriented functionality, 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). As an example, fault
localization is typically associated with 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 functionality, used by a transport service
provider) to monitor services offered 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
customers. 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 all be 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 for 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, as well as by minimizing service
operational repair times. interruptions and 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, as the OAM functionality o meeting service and performance objectives, as the OAM
allows for SLA verification in a multi-maintenance domain functionality allows for SLA verification in a multi-maintenance
environment and allows for the determination of service domain 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 1.1. Scope of this Document
MPLS-TP. These requirements apply to pseudowires (PWs), Label
Switched Paths (LSPs), and Sections. This document lists architectural and functional requirements for the
OAM functionality of MPLS-TP. These requirements apply to
pseudowires (PWs), Label Switched Paths (LSPs) and Sections.
These requirements are derived from the set of requirements specified These requirements are derived from the set of requirements specified
by ITU-T and 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 complement By covering transport specificities, these requirements complement
those identified in RFC 4377 [8]. those identified in RFC 4377 [8], yet some requirements may be
similar.
Note that the OAM functionalities identified in this document may be This document only lists architectural and functional OAM
used for fault management, performance monitoring and/or protection requirements. It does not detail the implications of their
applicability to the various types (e.g., point-to-point, point-to-
multipoint, unidirectional, bidirectional ...) of PWs, LSPs and
Sections. Furthermore, this document does not provide requirements
on how the protocol solution(s) should behave to achieve the
functional objectives. Please see [9] for further information.
Note that the OAM functions identified in this document may be used
for fault management, performance monitoring and/or protection
switching applications. For example, connectivity verification can switching applications. For example, connectivity verification can
be used for fault management application by detecting failure be used for fault management by detecting failure conditions, but may
conditions, but may also be used for performance monitoring also be used for performance monitoring through its contribution to
application through its contribution to the evaluation of performance the evaluation of performance metrics (e.g., unavailability time).
metrics (e.g., unavailability time). Nevertheless, it is outside the Nevertheless, it is outside the scope of this document to specify
scope of this document to specify which functionality should be used which function should be used for which application.
for which application.
1.1. Requirements Language and Terminology 1.2. Requirements Language and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", Although this document is not a protocol specification, the key words
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
document are to be interpreted as described in RFC 2119 [1]. "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be
interpreted as described in RFC 2119 [1] and are to be interpreted as
instructions to the protocol designers producing solutions that
satisfy the requirements set out in this document.
In this document we refer to the inability of a function to perform a 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 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 the situation in which the density of In this document we refer to the situation in which the density of
anomalies has reached a level where the ability to perform a required anomalies has reached a level where the ability to perform a required
function has been interrupted, as a defect. See also ITU-T G.806 function has been interrupted, as a defect. See also ITU-T G.806
[2]. [2].
skipping to change at page 4, line 47 skipping to change at page 5, line 12
not make a 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 reference to End In this document we use the term "node" as a general reference to End
Points and Intermediate Points. Points and Intermediate Points.
In this document we refer to both segment and concatenated segments In this document we refer to both segment and concatenated segments
as segments (see [6] for definitions relating to the term "segment" as segments (see [6] for definitions relating to the term "segment"
as well as for other definitions relating to MPLS-TP). as well as for other definitions relating to MPLS-TP).
In this document we refer to both single segment PWs and multi-
segment PWs as PWs.
In this document we refer to both bidirectional associated LSPs and
bidirectional co-routed LSPs as bidirectional LSPs.
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.
application of MPLS are similar to some of those listed in RFC 4377
[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. Scope of OAM 2.1.1. Scope of OAM
The protocol solutions developed to meet the requirements identified The protocol solution(s) developed to meet the requirements
in this document MUST be applicable to point-to-point bidirectional identified in this document MUST at least be applicable to point-to-
PWs, point-to-point bidirectional LSPs, and point-to-point point bidirectional PWs, point-to-point co-routed bidirectional LSPs,
bidirectional Sections and SHOULD additionaly be applicable to and point-to-point bidirectional Sections. Section 2.2 provides
unidirectional point-to-point and point-to-multipoint LSPs. additional information with regards to the applicability to point-to-
point associated bidirectional LSPs, point-to-point undirectional
LSPs and point-to-multipoint LSPs.
The service emulated by a single segment or a multi-segment PW may The service emulated by a PW may span multiple domains. An LSP may
span multiple domains. An LSP may also span multiple domains. It also span multiple domains. The protocol solution(s) MUST be
MUST be possible to operate OAM functions on a per domain basis. applicable end-to-end and to segments. More generally, it MUST be
More generally, the protocol solutions MUST be applicable end-to-end possible to operate OAM functions on a per domain basis and across
and to segments. multiple domains.
Since LSPs may be stacked, the protocol solutions MUST be applicable Since LSPs may be stacked, the protocol solution(s) MUST be
on any LSP, regardless of the label stack depth. Furthermore it MUST applicable on any LSP, regardless of the label stack depth.
be possible to estimate OAM fault and performance metrics of a single Furthermore it MUST be possible to estimate OAM fault and performance
PW or LSP segment or of an aggregate of PWs or LSPs segments. metrics of a single PW or LSP segment or of an aggregate of PWs or
LSPs segments.
2.1.2. Independence 2.1.2. Independence
The protocol solutions SHOULD be independent of the underlying The protocol solution(s) SHOULD be independent of the underlying
tunnelling or point-to-point technology or transmission media. tunnelling or point-to-point technology or transmission media.
The protocol solutions SHOULD be independent of the service a PW may The protocol solution(s) SHOULD be independent of the service a PW
emulate. may emulate.
Any OAM function operated on a PW, LSP or Section SHOULD be 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 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 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. 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 The protocol solution(s) MUST support the capability to be
concurrently and independently operated end-to-end and on segments.
Therefore, 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- 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 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 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 running on the end-to-end PW or LSP.
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 Furthermore, any OAM function applied to segment(s) of a PW or LSP
a control plane. Conversely, it SHOULD be possible to enable/disable SHOULD be independent of the OAM function(s) applied to other
the capability to operate OAM functions as part of connectivity segment(s) of the same PW or LSP.
management and it SHOULD also be possible to enable/disable the
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.3. Addressing, Routing and Forwarding Note: Independence should not be understood 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.
The OAM functionality may be deployed in a variety of environments. 2.1.3. OAM and IP Capabilities
The OAM functionality may be deployed in various 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 the forwarding forwarding capabilities are inherently present in the data plane.
plane. In this case, it MUST be possible to operate the OAM
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 the user forwarding capabilities may not necessarily be present in the data
plane. In this case, it MUST be possible to operate the OAM plane.
functions without relying on IP routing and forwarding
capabilities.
In cases where OAM messages need to incorporate identification In the former case, it MUST be possible to operate the OAM functions
information (e.g., source and/or destination nodes), the protocol by relying on IP routing and forwarding capabilities (e.g.,
solution(s) MUST at least support an IP addressing structure and MUST encapsulation in IP header for (de)multiplexing purposes) while in
also be extensible to support additional identification schemes. the latter case it MUST be possible to operate the OAM functions
without relying on IP routing and forwarding capabilities.
For certain functions, OAM messages need to incorporate
identification information (e.g., of source and/or destination
nodes). The protocol solution(s) MUST at least support
identification information in the form of an IP addressing structure
and MUST also be extensible to support additional identification
schemes.
2.1.4. Interoperability and Interworking 2.1.4. Interoperability and Interworking
It is REQUIRED that OAM interoperability is achieved across the It is REQUIRED that OAM interoperability is achieved between distinct
environments described in Section 2.1.3. It is also REQUIRED that domains materializing the environments described in Section 2.1.3.
the two first requirements of Section 2.1.3 still hold and MUST still It is also REQUIRED that the first two requirements of Section 2.1.3
be met when interoperability is achieved. still hold and MUST still be met when interoperability is 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
protocols (e.g., LSP-Ping [3], MPLS-BFD [9], VCCV [4] and VCCV-BFD protocols (e.g., LSP-Ping [3], MPLS-BFD [10], VCCV [4] and VCCV-BFD
[10]). [11]).
2.1.5. 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. This is often referred to as fate sharing. 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 packets, as well as the capability to apply specific treatment to OAM packets,
at the nodes targeted by these OAM packets. at the nodes processing these OAM packets.
As part of the design of OAM protocol solution(s) for MPLS-TP, a As part of the design of OAM protocol solution(s) for MPLS-TP, a
mechanism, for enabling the encapsulation and differentiation of OAM mechanism, for enabling the encapsulation and differentiation of OAM
messages on a PW, LSP or Section, MUST be provided. Such mechanism messages on a PW, LSP or Section, MUST be provided. Such mechanism
SHOULD also support the encapsulation and differentiation of existing SHOULD also support the encapsulation and differentiation of existing
IP/MPLS and PW OAM messages. IP/MPLS and PW OAM messages.
2.1.6. Configuration
OAM functions MUST operate and be configurable even in the absence of
a control plane. Conversely, it SHOULD be possible to configure as
well as enable/disable the capability to operate OAM functions as
part of connectivity management and it SHOULD also be possible to
configure as well as enable/disable the 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.2. Functional Requirements 2.2. Functional Requirements
Hereafter are listed the required functionalities composing the Hereafter are listed the required functionalities composing the
MPLS-TP OAM toolset. The list may not be exhaustive and as such the MPLS-TP OAM toolset. The list may not be exhaustive and as such the
OAM mechanisms developed in support of the identified requirements OAM mechanisms developed in support of the identified requirements
SHALL be extensible and thus SHALL NOT preclude the definition of SHALL be extensible and thus SHALL NOT preclude the definition of
additional OAM functionalities, in the future. additional OAM functionalities, in the future.
The design of OAM mechanisms for MPLS-TP, MUST allow for the ability The design of OAM mechanisms for MPLS-TP, MUST allow for the ability
to support experimental OAM functions. These functions MUST be to support experimental OAM functions. These functions MUST be
disabled by default. disabled by default.
The use of any OAM function MUST be optional and it MUST be possible The use of any OAM function MUST be optional and it MUST be possible
to choose which OAM function(s) to use and on which PW, LSP or to select the set of OAM function(s) to use on any PW, LSP or
Section to apply it(them) to. Section.
It is RECOMMENDED that the protocol solution, meeting one or more It is RECOMMENDED that any protocol solution, meeting one or more
functional requirement(s), be the same for PWs, LSPs and Sections. functional requirement(s), be the same for PWs, LSPs and Sections.
It is RECOMMENDED that the protocol solution, meeting one or more It is RECOMMENDED that any protocol solution, meeting one or more
functional requirement(s), effectively provides a fully featured functional requirement(s), effectively provides a fully featured
function; that is, a function which is applicable to all the cases function; that is, a function which is applicable to all the cases
identified for that functionality. In that context, protocol identified for that functionality. In that context, protocol
solution(s) MUST state their applicability. solution(s) MUST state their applicability.
Unless otherwise stated, the OAM functionalities MUST NOT rely on Unless otherwise stated, the OAM functionalities MUST NOT rely on
user traffic; that is, only OAM messages MUST be used to achieve the user traffic; that is, only OAM messages MUST be used to achieve the
objectives. objectives.
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 nodes. Mechanisms SHOULD exist such that corrective appropriate nodes. Mechanisms SHOULD exist such that corrective
actions can be taken. actions can be taken.
Furthermore, mechanisms MUST be available for a service provider to Furthermore, mechanisms MUST be available for a service provider to
be informed of a fault or defect affecting the service(s) it be aware of a fault or defect affecting the service(s) he provides,
provides, even if the fault or defect is located outside of his even if the fault or defect is located outside of his domain.
domain.
The protocol solution(s) developed to meet these requirements may Protocol solution(s) developed to meet these requirements may rely on
rely on information exchange. Information exchange between various information exchange. Information exchange between various nodes
nodes involved in the operation of an OAM function SHOULD be reliable involved in the operation of an OAM function SHOULD be reliable such
such that, for example, defects or faults are properly detected or that, for example, defects or faults are properly detected or that
that state changes are effectively known by the appropriate nodes. state changes are effectively known by the appropriate nodes.
2.2.2. Continuity Checks 2.2.2. Continuity Checks
The MPLS-TP OAM toolset MUST provide functionality to enable the The MPLS-TP OAM toolset MUST provide a function to enable an End
verification of the continuity of a PW, LSP or Section. Point to determine whether or not it receives traffic on 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.
This function SHOULD be performed pro-actively. This function SHOULD be performed pro-actively.
The protocol solution(s) developed to perform this function MUST also
apply to point-to-point associated bidirectional LSPs, point-to-point
unidirectional LSPs and point-to-multipoint LSPs.
2.2.3. Connectivity Verifications 2.2.3. Connectivity Verifications
The MPLS-TP OAM toolset MUST provide functionality to enable the The MPLS-TP OAM toolset MUST provide a function to enable an End
verification of the connectivity of a PW, LSP or Section. Point of a PW, LSP or Section to determine whether or not the
connectivity provided to an other node through a PW, LSP or Section
is effective (i.e., that a packet sent on that PW, LSP or Section,
reaches the expected node).
This function SHOULD be performed between End Points and Intermediate This function SHOULD be performed pro-actively between End Points of
Points of PWs and LSPs, and between End Points of PWs, LSPs and PWs, LSPs and Sections.
Sections.
This function SHOULD be performed on-demand. This function SHOULD be This function SHOULD be performed on-demand between End Points and
performed pro-actively only between End Points of PWs, LSPs and Intermediate Points of PWs and LSPs, and between End Points of PWs,
Sections. LSPs and Sections.
2.2.4. Diagnostic The protocol solution(s) developed to perform this function pro-
actively MUST also apply to point-to-point associated bidirectional
LSPs, point-to-point unidirectional LSPs and point-to-multipoint
LSPs.
The MPLS-TP OAM toolset MAY provide functionality to enable the The protocol solution(s) developed to perform this function on-demand
conduction of diagnostic tests on a PW, LSP or Section. An example MAY also apply to point-to-point associated bidirectional LSPs, to
of such diagnotic test would consist in looping the traffic at an point-to-point unidirectional LSPs and point-to-multipoint LSPs in
Intermediate Point, back to the End Point it originates from. case a return path exists.
Another example of such diagnotic test would consist in estimating
the bandwidth of e.g., an LSP. 2.2.4. Diagnostic Tests
The MPLS-TP OAM toolset MUST provide a function to enable conducting
diagnostic tests on a PW, LSP or Section. An example of such
diagnostic test consists in looping the traffic at an Intermediate
Point back to the originating End Point. Another example of such
diagnostic test consists 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.
The protocol solution(s) developed to perform this function MAY also
apply to point-to-point associated bidirectional LSPs, to point-to-
point unidirectional LSPs and point-to-multipoint LSPs in case a
return path exists.
2.2.5. Route Tracing 2.2.5. Route Tracing
The MPLS-TP OAM toolset MUST provide functionality to enable an End The MPLS-TP OAM toolset MUST provide functionality to enable an End
Point to discover the Intermediate (if any) and End Point(s) along a Point to discover the Intermediate (if any) and End Point(s) along a
PW, LSP or Section, and more generaly to trace the route of a PW, LSP PW, LSP or Section, and more generally to trace the route of a PW,
or Section. The information collected MUST include identifiers LSP or Section. The information collected MUST include identifiers
related to the nodes and interfaces composing that route. 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.
The protocol solution(s) developed to perform this function MAY also
apply to point-to-point associated bidirectional LSPs, to point-to-
point unidirectional LSPs and point-to-multipoint LSPs in case a
return path exists.
2.2.6. Lock Instruct 2.2.6. Lock Instruct
The MPLS-TP OAM toolset MUST provide functionality to enable an End The MPLS-TP OAM toolset MUST provide functionality to enable an End
Point of a PW, LSP or Section to instruct its associated End Point(s) Point of a PW, LSP or Section to instruct its associated End Point(s)
to lock the PW, LSP or Section. Note that lock corresponds to an to lock the PW, LSP or Section. Note that lock corresponds to an
administrative status in which forwarding traffic on and from the PW, administrative status in which it is expected that only test traffic,
LSP or Section is disabled. if any, and OAM (dedicated to the PW, LSP or Section) can be mapped
on that PW, LSP or Section.
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.
The protocol solution(s) developed to perform this function MUST also
apply to point-to-point associated bidirectional LSPs, point-to-point
unidirectional LSPs and point-to-multipoint LSPs.
2.2.7. Lock Reporting 2.2.7. Lock Reporting
The MPLS-TP OAM toolset MUST provide functionality to enable an Based on the tunnelling capabilities of MPLS, there are cases where
Intermediate Point of a PW or LSP to report, to an End Point of that Intermediate Point(s) of a PW or of an LSP coincide with End Point(s)
same PW or LSP, an external lock condition affecting that PW or LSP. of another LSP on which the former is mapped/tunnelled. Further, it
may happen that the tunnel LSP be out of service as a result of a
lock action on that tunnel LSP. By means outside of the scope of
this document, the Intermediate Point(s) of the PW or LSP may be
aware of this condition. The MPLS-TP OAM toolset MUST provide a
function to enable an Intermediate Point of a PW or LSP to report, to
an End Point of that same PW or LSP, a lock condition indirectly
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 Intermediate Points and End This function SHOULD be performed between Intermediate Points and End
Points of PWs and LSPs. Points of PWs and LSPs.
The protocol solution(s) developed to perform this function MUST also
apply to point-to-point associated bidirectional LSPs, point-to-point
unidirectional LSPs and point-to-multipoint LSPs.
2.2.8. Alarm Reporting 2.2.8. Alarm Reporting
The MPLS-TP OAM toolset MUST provide functionality to enable an Based on the tunnelling capabilities of MPLS, there are cases where
Intermediate Point of a PW or LSP to report, to an End Point of that Intermediate Point(s) of a PW or of an LSP coincide with End Point(s)
same PW or LSP, a fault or defect condition affecting that PW or LSP. of another LSP on which the former is mapped/tunnelled. Further, it
may happen that the tunnel LSP be out of service as a result of a
fault on that tunnel LSP. By means outside of the scope of this
document, the Intermediate Point(s) of the PW or LSP may be aware of
this condition. 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 indirectly
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 Intermediate Points and End This function SHOULD be performed between Intermediate Points and End
Points of PWs and LSPs. Points of PWs and LSPs.
The protocol solution(s) developed to perform this function MUST also
apply to point-to-point associated bidirectional LSPs, point-to-point
unidirectional LSPs and point-to-multipoint LSPs.
2.2.9. Remote Defect Indication 2.2.9. Remote Defect Indication
The MPLS-TP OAM toolset MUST provide functionality to enable an End The MPLS-TP OAM toolset MUST provide a function to enable an End
Point to report, to its associated End Point, a fault or defect Point to report, to its associated End Point, a fault or defect
condition that it detects on a PW, LSP or Section for which they are condition that it detects on a PW, LSP or Section for which they are
the End Points. 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.
The protocol solution(s) developed to perform this function MUST also
apply to point-to-point associated bidirectional LSPs and MAY also
apply to point-to-point unidirectional LSPs and point-to-multipoint
LSPs in case a return path exists.
2.2.10. Client Failure Indication 2.2.10. Client Failure Indication
The MPLS-TP OAM toolset MUST provide functionality to enable the The MPLS-TP OAM toolset MUST provide a function to enable the
propagation, across an MPLS-TP network, of information pertaining to propagation, from edge to edge of an MPLS-TP network, of information
a client defect of fault condition detected at an End Point of a PW pertaining to a client (i.e., external to the MPLS-TP network) defect
or LSP, if the client layer OAM mechanisms do not provide an alarm or fault condition detected at an End Point of a PW or LSP, if the
notification/propagation mechanism. client layer OAM functionality does not provide an alarm
notification/propagation functionality.
This function SHOULD be performed pro-actively. This function SHOULD be performed pro-actively.
This function SHOULD be performed between End Points of PWs and LSPs. This function SHOULD be performed between End Points of PWs and LSPs.
2.2.11. Packet Loss The protocol solution(s) developed to perform this function MUST also
apply to point-to-point associated bidirectional LSPs, point-to-point
unidirectional LSPs and point-to-multipoint LSPs.
The MPLS-TP OAM toolset MUST provide functionality to enable the 2.2.11. Packet Loss Measurement
The MPLS-TP OAM toolset MUST provide a function to enable the
quantification of packet loss ratio over a PW, LSP or Section. quantification of packet loss ratio over a PW, LSP or Section.
Note that packet loss ratio is the ratio of the user packets not Note that packet loss ratio is the ratio of the user packets not
delivered to the total number of user packets transmitted during a delivered to the total number of user packets transmitted during a
defined time interval. The number of user packets not delivered is defined time interval. The number of user packets not delivered is
the difference between the number of user packets transmitted by an the difference between the number of user packets transmitted by an
End Point and the number of user packets received at an End Point. End Point and the number of user packets received at an End Point.
This function MAY either be performed pro-actively or on-demand. 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 It SHOULD be possible to rely on user traffic to perform that
functionality. functionality.
2.2.12. Delay Measurement The protocol solution(s) developed to perform this function MUST also
apply to point-to-point associated bidirectional LSPs, point-to-point
unidirectional LSPs and point-to-multipoint LSPs.
The MPLS-TP OAM toolset MUST provide functionality to enable the 2.2.12. Packet Delay Measurement
The MPLS-TP OAM toolset MUST provide a function to enable the
quantification of the one-way, and if appropriate, the two-way, delay quantification of the one-way, and if 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 a packet by an End Point until the reception of the first bit of a packet by an End Point until the reception
of the last bit of that packet by the other End Point. of the last bit of that packet by the other End 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 a packet by a End Point until the reception of of the first bit of a packet by a End Point until the reception of
the last bit of that packet by the same End Point, when loopback the last bit of that packet by the same End Point, when loopback
is performed at the other End Point. is performed at the other End Point.
This function SHOULD be performed on-demand and MAY be perform pro- This function SHOULD be performed on-demand and MAY be performed pro-
actively. 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.
It SHOULD be possible to rely on user-plane traffic to achieve that The protocol solution(s) developed to perform this function MUST also
functionality. apply to point-to-point associated bidirectional LSPs, point-to-point
unidirectional LSPs and point-to-multipoint LSPs but only to enable
the quantification of the one-way delay.
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 Packet Switched Network.
4. Security Considerations 4. Security Considerations
This document, as itself, does not imply any security consideration This document, in 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
messages can reveal sensitive information such as passwords, messages can reveal sensitive information such as passwords,
performance data and details about e.g., the network topology. performance data and details about e.g., the network topology.
The nature of OAM therefore suggests having some form of The nature of OAM therefore suggests having some form of
authentication, authorization and encryption in place. This will authentication, authorization and encryption in place. This will
prevent unauthorized access to MPLS-TP equipment and it will prevent prevent unauthorized access to MPLS-TP equipment and it will prevent
third parties from learning about sensitive information about the third parties from learning about sensitive information about the
transport network. transport network.
skipping to change at page 12, line 23 skipping to change at page 14, line 28
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 The editors gratefully acknowledge the contributions of Matthew
Bocci, Italo Busi, Thomas Dietz, Huub van Helvoort, Wataru Imajuku, Bocci, Italo Busi, Thomas Dietz, Annamaria Fulignoli, Huub van
Marc Lasserre, Lieven Levrau, Han Li, Julien Meuric, Philippe Niger, Helvoort, Wataru Imajuku, Marc Lasserre, Lieven Levrau, Han Li,
Benjamin Niven-Jenkins, Jing Ruiquan, Nurit Sprecher, Yuji Tochio, Julien Meuric, Philippe Niger, Benjamin Niven-Jenkins, Jing Ruiquan,
Satoshi Ueno and Yaacov Weingarten. 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
skipping to change at page 13, line 9 skipping to change at page 15, line 13
[3] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label [3] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label
Switched (MPLS) Data Plane Failures", RFC 4379, February 2006. Switched (MPLS) Data Plane Failures", RFC 4379, February 2006.
[4] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit [4] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit
Connectivity Verification (VCCV): A Control Channel for Connectivity Verification (VCCV): A Control Channel for
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-03 (work in
progress), November 2008. progress), August 2009.
[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-09 (work in progress), draft-ietf-mpls-tp-requirements-10 (work in progress),
June 2009. August 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] Busi, I. and B. Niven-Jenkins, "MPLS-TP OAM Framework and
Overview", draft-ietf-mpls-tp-oam-framework-01 (work in
progress), July 2009.
[10] 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 [11] 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-05 Connectivity Verification (VCCV)", draft-ietf-pwe3-vccv-bfd-07
(work in progress), June 2009. (work in progress), July 2009.
Authors' Addresses Authors' Addresses
Martin Vigoureux (editor) Martin Vigoureux (editor)
Alcatel-Lucent Alcatel-Lucent
Route de Villejust Route de Villejust
Nozay, 91620 Nozay, 91620
France France
Email: martin.vigoureux@alcatel-lucent.com Email: martin.vigoureux@alcatel-lucent.com
 End of changes. 80 change blocks. 
191 lines changed or deleted 296 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/