draft-ietf-mpls-tp-oam-requirements-06.txt   rfc5860.txt 
MPLS Working Group M. Vigoureux, Ed. Internet Engineering Task Force (IETF) M. Vigoureux, Ed.
Internet-Draft Alcatel-Lucent Request for Comments: 5860 Alcatel-Lucent
Intended status: Standards Track D. Ward, Ed. Category: Standards Track D. Ward, Ed.
Expires: September 6, 2010 Juniper Networks ISSN: 2070-1721 Juniper Networks
M. Betts, Ed. M. Betts, Ed.
M. C. Betts Consulting Ltd. M. C. Betts Consulting Ltd.
March 5, 2010 May 2010
Requirements for OAM in MPLS Transport Networks Requirements for Operations, Administration, and Maintenance (OAM)
draft-ietf-mpls-tp-oam-requirements-06 in MPLS Transport Networks
Abstract Abstract
This document lists architectural and functional requirements for the This document lists architectural and functional requirements for the
Operations, Administration and Maintenance of MPLS Transport Profile. Operations, Administration, and Maintenance of MPLS Transport
These requirements apply to pseudowires, Label Switched Paths, and Profile. These requirements apply to pseudowires, Label Switched
Sections. Paths, and Sections.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Status of This Memo
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at This is an Internet Standards Track document.
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at This document is a product of the Internet Engineering Task Force
http://www.ietf.org/shadow.html. (IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on September 6, 2010. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc5860.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Scope of this Document . . . . . . . . . . . . . . . . . . 3 1.1. Scope of This Document . . . . . . . . . . . . . . . . . . 3
1.2. Requirements Language and Terminology . . . . . . . . . . 4 1.2. Requirements Language and Terminology . . . . . . . . . . 4
2. OAM Requirements . . . . . . . . . . . . . . . . . . . . . . . 5 2. OAM Requirements . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Architectural Requirements . . . . . . . . . . . . . . . . 6 2.1. Architectural Requirements . . . . . . . . . . . . . . . . 6
2.1.1. Scope of OAM . . . . . . . . . . . . . . . . . . . . . 6 2.1.1. Scope of OAM . . . . . . . . . . . . . . . . . . . . . 6
2.1.2. Independence . . . . . . . . . . . . . . . . . . . . . 6 2.1.2. Independence . . . . . . . . . . . . . . . . . . . . . 6
2.1.3. Data Plane . . . . . . . . . . . . . . . . . . . . . . 7 2.1.3. Data Plane . . . . . . . . . . . . . . . . . . . . . . 7
2.1.4. OAM and IP Capabilities . . . . . . . . . . . . . . . 7 2.1.4. OAM and IP Capabilities . . . . . . . . . . . . . . . 7
2.1.5. Interoperability and Interworking . . . . . . . . . . 8 2.1.5. Interoperability and Interworking . . . . . . . . . . 8
2.1.6. Configuration . . . . . . . . . . . . . . . . . . . . 8 2.1.6. Configuration . . . . . . . . . . . . . . . . . . . . 8
2.2. Functional Requirements . . . . . . . . . . . . . . . . . 8 2.2. Functional Requirements . . . . . . . . . . . . . . . . . 9
2.2.1. General Requirements . . . . . . . . . . . . . . . . . 9 2.2.1. General Requirements . . . . . . . . . . . . . . . . . 9
2.2.2. Continuity Checks . . . . . . . . . . . . . . . . . . 9 2.2.2. Continuity Checks . . . . . . . . . . . . . . . . . . 10
2.2.3. Connectivity Verifications . . . . . . . . . . . . . . 10 2.2.3. Connectivity Verifications . . . . . . . . . . . . . . 10
2.2.4. Route Tracing . . . . . . . . . . . . . . . . . . . . 10 2.2.4. Route Tracing . . . . . . . . . . . . . . . . . . . . 11
2.2.5. Diagnostic Tests . . . . . . . . . . . . . . . . . . . 11 2.2.5. Diagnostic Tests . . . . . . . . . . . . . . . . . . . 11
2.2.6. Lock Instruct . . . . . . . . . . . . . . . . . . . . 11 2.2.6. Lock Instruct . . . . . . . . . . . . . . . . . . . . 11
2.2.7. Lock Reporting . . . . . . . . . . . . . . . . . . . . 11 2.2.7. Lock Reporting . . . . . . . . . . . . . . . . . . . . 12
2.2.8. Alarm Reporting . . . . . . . . . . . . . . . . . . . 12 2.2.8. Alarm Reporting . . . . . . . . . . . . . . . . . . . 12
2.2.9. Remote Defect Indication . . . . . . . . . . . . . . . 12 2.2.9. Remote Defect Indication . . . . . . . . . . . . . . . 13
2.2.10. Client Failure Indication . . . . . . . . . . . . . . 13 2.2.10. Client Failure Indication . . . . . . . . . . . . . . 13
2.2.11. Packet Loss Measurement . . . . . . . . . . . . . . . 13 2.2.11. Packet Loss Measurement . . . . . . . . . . . . . . . 13
2.2.12. Packet Delay Measurement . . . . . . . . . . . . . . . 14 2.2.12. Packet Delay Measurement . . . . . . . . . . . . . . . 14
3. Congestion Considerations . . . . . . . . . . . . . . . . . . 14 3. Congestion Considerations . . . . . . . . . . . . . . . . . . 15
4. Security Considerations . . . . . . . . . . . . . . . . . . . 14 4. Security Considerations . . . . . . . . . . . . . . . . . . . 15
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 6.1. Normative References . . . . . . . . . . . . . . . . . . . 16
7.1. Normative References . . . . . . . . . . . . . . . . . . . 15 6.2. Informative References . . . . . . . . . . . . . . . . . . 16
7.2. Informative References . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
In the context of MPLS Transport Profile (MPLS-TP, see [9] and [1]), In the context of MPLS Transport Profile (MPLS-TP, see [9] and [1]),
the rationales for Operations, Administration and Maintenance (OAM) the rationales for Operations, Administration, and Maintenance (OAM)
are twofold as it can serve: are twofold as it can serve:
o as a network-oriented functionality, 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 behavior 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). As an 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 functionality, 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 Agreement (SLA) parameters (e.g.,
(e.g., using performance monitoring) negotiated with the end using performance monitoring) negotiated with the end customers.
customers. Note that a transport service could be provided over Note that a transport service could be provided over several
several networks or administrative domains that may not all be networks or administrative domains that may not all be owned and
owned and managed by the same transport service provider. 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, localization, and handling and
diagnosis of defects, as well as by minimizing service diagnosis of defects, as well as by minimizing service
interruptions and 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, those resulting in misdirected customer traffic) and
are detected, diagnosed and dealt with before a customer reports faults are detected, diagnosed, and dealt with before a customer
the problem. reports the problem.
o meeting service and performance objectives, as the OAM o meeting service and performance objectives, as the OAM
functionality allows for SLA verification in a multi-maintenance functionality allows for SLA verification in a multi-maintenance
domain 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.
1.1. Scope of this Document 1.1. Scope of This Document
This document lists architectural and functional requirements for the This document lists architectural and functional requirements for the
OAM functionality of MPLS-TP. These requirements apply to OAM functionality of MPLS-TP. These requirements apply to
pseudowires (PWs), Label Switched Paths (LSPs) and Sections. 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 [10]. by ITU-T and published in the ITU-T Supplement Y.Sup4 [10].
By covering transport specificities, these requirements complement By covering transport specificities, these requirements complement
those identified in RFC 4377 [11], yet some requirements may be those identified in RFC 4377 [11]; yet, some requirements may be
similar. similar.
This document only lists architectural and functional OAM This document only lists architectural and functional OAM
requirements. It does not detail the implications of their requirements. It does not detail the implications of their
applicability to the various types (e.g., point-to-point, point-to- applicability to the various types (e.g., point-to-point, point-to-
multipoint, unidirectional, bidirectional ...) of PWs, LSPs and multipoint, unidirectional, bidirectional, etc.) of PWs, LSPs, and
Sections. Furthermore, this document does not provide requirements Sections. Furthermore, this document does not provide requirements
on how the protocol solution(s) should behave to achieve the on how the protocol solution(s) should behave to achieve the
functional objectives. Please see [12] for further information. functional objectives. Please see [12] for further information.
Note that the OAM functions identified in this document may be used Note that the OAM functions identified in this document may be used
for fault management, performance monitoring and/or protection 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 by detecting failure conditions, but may be used for fault management by detecting failure conditions, but may
also be used for performance monitoring through its contribution to also be used for performance monitoring through its contribution to
the evaluation of performance metrics (e.g., unavailability time). the evaluation of performance metrics (e.g., unavailability time).
Nevertheless, it is outside the scope of this document to specify Nevertheless, it is outside the scope of this document to specify
which function should be used for which application. which function should be used for which application.
Note also that it is anticipated that implementers may wish to Note also that it is anticipated that implementers may wish to
implement OAM message handling in hardware. Although not a implement OAM message handling in hardware. Although not a
requirement, this fact could be taken as a design consideration. requirement, this fact could be taken as a design consideration.
skipping to change at page 4, line 40 skipping to change at page 4, line 40
1.2. Requirements Language and Terminology 1.2. Requirements Language and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [2]. document are to be interpreted as described in RFC 2119 [2].
Although this document is not a protocol specification, the use of Although this document is not a protocol specification, the use of
this language clarifies the instructions to protocol designers this language clarifies the instructions to protocol designers
producing solutions that satisfy the requirements set out in this producing solutions that satisfy the requirements set out in this
document. document.
In this document we refer to the inability of a function to perform a In this document, we:
required action, as a fault. This does not include an inability due
to preventive maintenance, lack of external resources, or planned
actions. See also ITU-T G.806 [3].
In this document we refer to the situation in which the density of o refer to the inability of a function to perform a required action
anomalies has reached a level where the ability to perform a required as a fault. This does not include an inability due to preventive
function has been interrupted, as a defect. See also ITU-T G.806 maintenance, lack of external resources, or planned actions. See
[3]. also ITU-T G.806 [3].
In this document we refer to OAM actions which are carried out o refer to the situation in which the density of anomalies has
continuously or at least on long periods of time, permitting reached a level where the ability to perform a required function
proactive reporting of fault and/or performance results, as proactive has been interrupted as a defect. See also ITU-T G.806 [3].
OAM.
In this document we refer to OAM actions which are initiated via o refer to OAM actions that are carried out continuously or at least
manual intervention for a limited time to carry out troubleshooting, over long periods of time, permitting proactive reporting of fault
as on-demand OAM. and/or performance results as proactive OAM.
In this document we refer to a Label Edge Router (LER), for a given o refer to OAM actions that are initiated via manual intervention
LSP or Section, and to a PW Terminating Provider Edge (T-PE), for a for a limited time to carry out troubleshooting as on-demand OAM.
given PW, as an End Point. Further, we refer to a Label Switching
Router (LSR), for a given LSP, and to a PW Switching Provider Edge
(S-PE), for a given PW, as an Intermediate Point. This document does
not make a distinction between End Points (e.g., source and
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 o refer to a Label Edge Router (LER), for a given LSP or Section,
Points and Intermediate Points. and to a PW Terminating Provider Edge (T-PE), for a given PW, as
an End Point. Further, we refer to a Label Switching Router
(LSR), for a given LSP, and to a PW Switching Provider Edge
(S-PE), for a given PW, as an Intermediate Point. This document
does not make a distinction between End Points (e.g., source and
destination) as it can be inferred from the context of the
sentences.
In this document we refer to both segment and concatenated segments o use the term "node" as a general reference to End Points and
as segments (see [1] for definitions relating to the term "segment" Intermediate Points.
as well as for other definitions relating to MPLS-TP).
In this document we refer to both single segment PWs and multi- o refer to both segment and concatenated segments as segments (see
segment PWs as PWs. [1] for definitions relating to the term "segment" as well as for
other definitions relating to MPLS-TP).
In this document we refer to both bidirectional associated LSPs and o refer to both single segment PWs and multi-segment PWs as PWs.
bidirectional co-routed LSPs as bidirectional LSPs.
o 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. MPLS-TP should abide.
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.
RFC5654 [1] states (Requirement #2) that the MPLS-TP design SHOULD as RFC 5654 [1] states (Requirement #2) that the MPLS-TP design, SHOULD
far as reasonably possible reuse existing MPLS standards. This as far as reasonably possible, reuse existing MPLS standards. This
general requirement applies to MPLS-TP OAM. MPLS-TP OAM is defined general requirement applies to MPLS-TP OAM. MPLS-TP OAM is defined
in this document through a set of functional requirements. These in this document through a set of functional requirements. These
requirements will be met by protocol solutions defined in other requirements will be met by protocol solutions defined in other
documents. The way in which those protocols are operated and the way documents. The way in which those protocols are operated and the way
in which a network operator can control and use the MPLS-TP OAM in which a network operator can control and use the MPLS-TP OAM
functions SHOULD be as similar as possible to the mechanisms and functions SHOULD be as similar as possible to the mechanisms and
techniques used to operate OAM in other transport technologies. techniques used to operate OAM in other transport technologies.
2.1. Architectural Requirements 2.1. Architectural Requirements
2.1.1. Scope of OAM 2.1.1. Scope of OAM
The protocol solution(s) developed to meet the requirements The protocol solution(s) developed to meet the requirements
identified in this document MUST at least be applicable to point-to- identified in this document MUST at least be applicable to point-to-
point bidirectional PWs, point-to-point co-routed bidirectional LSPs, point bidirectional PWs, point-to-point co-routed bidirectional LSPs,
and point-to-point bidirectional Sections. Section 2.2 provides and point-to-point bidirectional Sections. Section 2.2 provides
additional information with regards to the applicability to point-to- additional information with regard to the applicability to point-to-
point associated bidirectional LSPs, point-to-point unidirectional point associated bidirectional LSPs, point-to-point unidirectional
LSPs and point-to-multipoint LSPs. LSPs, and point-to-multipoint LSPs.
The service emulated by a PW may span multiple domains. An LSP may The service emulated by a PW may span multiple domains. An LSP may
also span multiple domains. The protocol solution(s) MUST be also span multiple domains. The protocol solution(s) MUST be
applicable end-to-end and to segments. More generally, it MUST be applicable to end-to-end and to segments. More generally, it MUST be
possible to operate OAM functions on a per domain basis and across possible to operate OAM functions on a per-domain basis and across
multiple domains. multiple domains.
Since LSPs may be stacked, the protocol solution(s) MUST be Since LSPs may be stacked, the protocol solution(s) MUST be
applicable on any LSP, regardless of the label stack depth. applicable on any LSP, regardless of the label stack depth.
Furthermore it MUST be possible to estimate OAM fault and performance Furthermore, it MUST be possible to estimate OAM fault and
metrics of a single PW or LSP segment or of an aggregate of PWs or performance metrics of a single PW or LSP segment or of an aggregate
LSPs segments. of PW or LSP segments.
2.1.2. Independence 2.1.2. Independence
The protocol solution(s) 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. tunneling or point-to-point technology or transmission media.
The protocol solution(s) SHOULD be independent of the service a PW The protocol solution(s) SHOULD be independent of the service a PW
may 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,
Section. In other words, only the OAM functions operated on e.g., a or Section. In other words, only the OAM functions operated on a
given LSP should be used to achieve the OAM objectives for that LSP. given LSP (for example) should be used to achieve the OAM objectives
for that LSP.
The protocol solution(s) MUST support the capability to be The protocol solution(s) MUST support the capability to be
concurrently and independently operated end-to-end and on segments. concurrently and independently operated end-to-end and on segments.
Therefore, any OAM function applied to segment(s) of a PW or LSP 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. running on the end-to-end PW or LSP.
Furthermore, any OAM function applied to segment(s) of a 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 SHOULD be independent of the OAM function(s) applied to other
segment(s) of the same PW or LSP. segment(s) of the same PW or LSP.
Note: Independence should not be understood in terms of isolation as Note: Independence should not be understood in terms of isolation
there can be interactions between OAM functions operated on e.g., as there can be interactions between OAM functions operated, for
an LSP, and on another LSP or a PW. example, on two different LSPs.
2.1.3. Data Plane 2.1.3. 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 processing 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.4. OAM and IP Capabilities 2.1.4. OAM and IP Capabilities
There are environments where IP capabilities are present in the data There are environments where IP capabilities are present in the data
plane. IP/MPLS environments are examples of such environments. plane. IP/MPLS environments are examples of such environments.
There are also environments where IP capabilities may not be present There are also environments where IP capabilities may not be present
in the data plane. MPLS-TP environments are examples of environments in the data plane. MPLS-TP environments are examples of environments
where IP capabilities might or might not be present. where IP capabilities might or might not be present.
Presence or absence of IP capabilities is deployment scenario
dependent. Note: Presence or absence of IP capabilities is deployment
scenario dependent.
It MUST be possible to deploy the OAM functionality in any of these It MUST be possible to deploy the OAM functionality in any of these
environments. As a result, it MUST be possible to operate OAM environments. As a result, it MUST be possible to operate OAM
functions with or without relying on IP capabilities and it MUST be functions with or without relying on IP capabilities, and it MUST be
possible to choose to make use of IP capabilities when these are possible to choose to make use of IP capabilities when these are
present. present.
Furthermore, the mechanism required for enabling the encapsulation Furthermore, the mechanism required for enabling the encapsulation
and differentiation of OAM messages (see Section 2.1.3) MUST support and differentiation of OAM messages (see Section 2.1.3) MUST support
the capability to differentiate OAM messages of an OAM function the capability to differentiate OAM messages of an OAM function
operated by relying on IP capabilities (e.g., using encapsulation in operated by relying on IP capabilities (e.g., using encapsulation in
an IP header) from OAM messages of an OAM function operated without an IP header) from OAM messages of an OAM function operated without
relying on any IP capability. relying on any IP capability.
Note that IP capabilities include the capability to form a standard Note that IP capabilities include the capability to form a standard
IP header, to encapsulate a payload in an IP header, to parse and IP header, to encapsulate a payload in an IP header, to parse and
analyse the fields of an IP header and to take actions based on the analyze the fields of an IP header, and to take actions based on the
content of these fields. content of these fields.
For certain functions, OAM messages need to incorporate For certain functions, OAM messages need to incorporate
identification information (e.g., of source and/or destination identification information (e.g., of source and/or destination
nodes). The protocol solution(s) MUST at least support nodes). The protocol solution(s) MUST at least support
identification information in the form of an IP addressing structure identification information in the form of an IP addressing structure
and MUST also be extensible to support additional identification and MUST also be extensible to support additional identification
schemes. schemes.
2.1.5. Interoperability and Interworking 2.1.5. Interoperability and Interworking
It is REQUIRED that OAM interoperability is achieved between distinct It is REQUIRED that OAM interoperability is achieved between distinct
domains materializing the environments described in Section 2.1.4. domains materializing the environments described in Section 2.1.4.
It is also REQUIRED that the first two requirements of Section 2.1.4 It is also REQUIRED that the first two requirements of Section 2.1.4
still hold and MUST still 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 [4], MPLS-BFD [13], VCCV [5] and VCCV-BFD protocols (e.g., LSP-Ping [4], MPLS-BFD [13], VCCV [5], and VCCV-BFD
[14]). [14]).
2.1.6. Configuration 2.1.6. Configuration
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, it SHOULD be possible to configure as a control plane. Conversely, it SHOULD be possible to configure as
well as enable/disable the capability to operate OAM functions as well as enable/disable the capability to operate OAM functions as
part of connectivity management and it SHOULD also be possible to part of connectivity management, and it SHOULD also be possible to
configure as well as enable/disable the capability to operate OAM configure as well as enable/disable the capability to operate OAM
functions after connectivity has been established. functions after connectivity has been established.
In the latter case, the customer MUST NOT perceive service In the latter case, the customer MUST NOT perceive service
degradation as a result of OAM enabling/disabling. Ideally OAM degradation as a result of OAM enabling/disabling. Ideally, OAM
enabling/disabling should take place without introducing any customer enabling/disabling should take place without introducing any customer
impairments (e.g., no customer packet losses). Procedures aimed to impairments (e.g., no customer packet losses). Procedures aimed to
prevent any traffic impairment MUST be defined for the enabling/ prevent any traffic impairment MUST be defined for the enabling/
disabling of OAM functions. disabling of OAM functions.
Means for configuring OAM functions and for connectivity management Means for configuring OAM functions and for connectivity management
are outside the scope of this document. are outside the scope of this document.
2.2. Functional Requirements 2.2. Functional Requirements
skipping to change at page 9, line 10 skipping to change at page 9, line 18
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 select the set of OAM function(s) to use on any PW, LSP or to select the set of OAM function(s) to use on any PW, LSP, or
Section. Section.
It is RECOMMENDED that any 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 any 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 that 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.
For the on-demand OAM functions, the result of which may vary For the on-demand OAM functions, the result of which may vary
depending on packet size, it SHOULD be possible to perform these depending on packet size, it SHOULD be possible to perform these
functions using different packet sizes. functions using different packet sizes.
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 aware of a fault or defect affecting the service(s) he provides, be aware of a fault or defect affecting the service(s) he provides,
even if the fault or defect is located outside of his domain. even if the fault or defect is located outside of his domain.
Protocol solution(s) developed to meet these requirements may rely on Protocol solution(s) developed to meet these requirements may rely on
information exchange. Information exchange between various nodes information exchange. Information exchange between various nodes
involved in the operation of an OAM function SHOULD be reliable such involved in the operation of an OAM function SHOULD be reliable such
that, for example, defects or faults are properly detected or that that, for example, defects or faults are properly detected or 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 a function to enable an End The MPLS-TP OAM toolset MUST provide a function to enable an End
Point to monitor the liveness of a PW, LSP or Section. Point to monitor the liveness 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,
Sections. and Sections.
This function SHOULD be performed pro-actively. This function SHOULD be performed proactively.
The protocol solution(s) developed to perform this function MUST also The protocol solution(s) developed to perform this function MUST also
apply to point-to-point associated bidirectional LSPs, point-to-point apply to point-to-point associated bidirectional LSPs, point-to-point
unidirectional LSPs and point-to-multipoint LSPs. unidirectional LSPs, and point-to-multipoint LSPs.
2.2.3. Connectivity Verifications 2.2.3. Connectivity Verifications
The MPLS-TP OAM toolset MUST provide a function to enable an End The MPLS-TP OAM toolset MUST provide a function to enable an End
Point to determine whether or not it is connected to specific End Point to determine whether or not it is connected to specific End
Point(s) by means of the expected PW, LSP or Section. Point(s) by means of the expected PW, LSP, or Section.
This function SHOULD be performed pro-actively between End Points of This function SHOULD be performed proactively between End Points of
PWs, LSPs and Sections. PWs, LSPs, and Sections.
This function SHOULD be performed on-demand between End Points and This function SHOULD be performed on-demand between End Points and
Intermediate Points of PWs and LSPs, and between End Points of PWs, Intermediate Points of PWs and LSPs, and between End Points of PWs,
LSPs and Sections. LSPs, and Sections.
The protocol solution(s) developed to perform this function pro- The protocol solution(s) developed to perform this function
actively MUST also apply to point-to-point associated bidirectional proactively MUST also apply to point-to-point associated
LSPs, point-to-point unidirectional LSPs and point-to-multipoint bidirectional LSPs, point-to-point unidirectional LSPs, and point-to-
LSPs. multipoint LSPs.
The protocol solution(s) developed to perform this function on-demand The protocol solution(s) developed to perform this function on-demand
MAY also apply to point-to-point associated bidirectional LSPs, to MAY also apply to point-to-point associated bidirectional LSPs, to
point-to-point unidirectional LSPs and point-to-multipoint LSPs in point-to-point unidirectional LSPs, and point-to-multipoint LSPs in
case a return path exists. case a return path exists.
2.2.4. Route Tracing 2.2.4. 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 generally to trace the route of a PW, PW, LSP, or Section, and more generally to trace the route of a PW,
LSP 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 The protocol solution(s) developed to perform this function MAY also
apply to point-to-point associated bidirectional LSPs, to point-to- apply to point-to-point associated bidirectional LSPs, to point-to-
point unidirectional LSPs and point-to-multipoint LSPs in case a point unidirectional LSPs, and point-to-multipoint LSPs in case a
return path exists. return path exists.
2.2.5. Diagnostic Tests 2.2.5. Diagnostic Tests
The MPLS-TP OAM toolset MUST provide a function to enable conducting 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 tests on a PW, LSP, or Section. An example of such a
diagnostic test consists of performing a loop-back function at a node diagnostic test consists of performing a loop-back function at a node
such that all OAM and data traffic are looped back to the originating such that all OAM and data traffic are looped back to the originating
End Point. Another example of such diagnostic test consists in End Point. Another example of such diagnostic test consists in
estimating the bandwidth of e.g., an LSP. 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 The protocol solution(s) developed to perform this function MAY also
apply to point-to-point associated bidirectional LSPs, to point-to- apply to point-to-point associated bidirectional LSPs, to point-to-
point unidirectional LSPs and point-to-multipoint LSPs in case a point unidirectional LSPs and point-to-multipoint LSPs, in case a
return path exists. 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
to lock the PW, LSP or Section. Note that lock corresponds to an Point(s) to lock the PW, LSP, or Section. Note that lock corresponds
administrative status in which it is expected that only test traffic, to an administrative status in which it is expected that only test
if any, and OAM (dedicated to the PW, LSP or Section) can be mapped traffic, if any, and OAM (dedicated to the PW, LSP, or Section) can
on that PW, LSP or Section. 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,
Sections. and Sections.
The protocol solution(s) developed to perform this function MUST also The protocol solution(s) developed to perform this function MUST also
apply to point-to-point associated bidirectional LSPs, point-to-point apply to point-to-point associated bidirectional LSPs, point-to-point
unidirectional LSPs and point-to-multipoint LSPs. unidirectional LSPs, and point-to-multipoint LSPs.
2.2.7. Lock Reporting 2.2.7. Lock Reporting
Based on the tunnelling capabilities of MPLS, there are cases where Based on the tunneling capabilities of MPLS, there are cases where
Intermediate Point(s) of a PW or of an LSP coincide with End Point(s) Intermediate Point(s) of a PW or of an LSP coincide with End Point(s)
of another LSP on which the former is mapped/tunnelled. Further, it of another LSP on which the former is mapped/tunneled. Further, it
may happen that the tunnel LSP be out of service as a result of a may happen that the tunnel LSP is out of service as a result of a
lock action on that tunnel LSP. By means outside of the scope of 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 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 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 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 an End Point of that same PW or LSP, a lock condition indirectly
affecting that PW or LSP. affecting that PW or LSP.
This function SHOULD be performed pro-actively. This function SHOULD be performed proactively.
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 The protocol solution(s) developed to perform this function MUST also
apply to point-to-point associated bidirectional LSPs, point-to-point apply to point-to-point associated bidirectional LSPs, point-to-point
unidirectional LSPs and point-to-multipoint LSPs. unidirectional LSPs, and point-to-multipoint LSPs.
2.2.8. Alarm Reporting 2.2.8. Alarm Reporting
Based on the tunnelling capabilities of MPLS, there are cases where Based on the tunneling capabilities of MPLS, there are cases where
Intermediate Point(s) of a PW or of an LSP coincide with End Point(s) Intermediate Point(s) of a PW or of an LSP coincide with End Point(s)
of another LSP on which the former is mapped/tunnelled. Further, it of another LSP on which the former is mapped/tunneled. Further, it
may happen that the tunnel LSP be out of service as a result of a 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 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 document, the Intermediate Point(s) of the PW or LSP may be aware of
this condition. The MPLS-TP OAM toolset MUST provide functionality 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 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 Point of that same PW or LSP, a fault or defect condition indirectly
affecting that PW or LSP. affecting that PW or LSP.
This function SHOULD be performed pro-actively. This function SHOULD be performed proactively.
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 The protocol solution(s) developed to perform this function MUST also
apply to point-to-point associated bidirectional LSPs, point-to-point apply to point-to-point associated bidirectional LSPs, point-to-point
unidirectional LSPs and point-to-multipoint LSPs. 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 a function 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 proactively.
This function SHOULD be performed between End Points of PWs, LSPs and This function SHOULD be performed between End Points of PWs, LSPs,
Sections. and Sections.
The protocol solution(s) developed to perform this function MUST also 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 associated bidirectional LSPs and MAY also
apply to point-to-point unidirectional LSPs and point-to-multipoint apply to point-to-point unidirectional LSPs and point-to-multipoint
LSPs in case a return path exists. 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 a function to enable the The MPLS-TP OAM toolset MUST provide a function to enable the
propagation, from edge to edge of an MPLS-TP network, of information propagation, from edge to edge of an MPLS-TP network, of information
pertaining to a client (i.e., external to the MPLS-TP network) defect pertaining to a client (i.e., external to the MPLS-TP network) defect
or fault condition detected at an End Point of a PW or LSP, if the or fault condition detected at an End Point of a PW or LSP, if the
client layer OAM functionality does not provide an alarm client layer OAM functionality does not provide an alarm
notification/propagation functionality. notification/propagation functionality.
This function SHOULD be performed pro-actively. This function SHOULD be performed proactively.
This function SHOULD be performed between End Points of PWs and LSPs. This function SHOULD be performed between End Points of PWs and LSPs.
The protocol solution(s) developed to perform this function MUST also The protocol solution(s) developed to perform this function MUST also
apply to point-to-point associated bidirectional LSPs, point-to-point apply to point-to-point associated bidirectional LSPs, point-to-point
unidirectional LSPs and point-to-multipoint LSPs. unidirectional LSPs, and point-to-multipoint LSPs.
2.2.11. Packet Loss Measurement 2.2.11. Packet Loss Measurement
The MPLS-TP OAM toolset MUST provide a function to enable the 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.
The loss of a packet is defined in RFC2680 [6] (see section 2.4). The loss of a packet is defined in RFC2680 [6] (see Section 2.4).
This definition is used here. This definition is used here.
Packet loss ratio is defined here to be the ratio of the number of Packet-loss ratio is defined here to be the ratio of the number of
user packets lost to the total number of user packets sent during a user packets lost to the total number of user packets sent during a
defined time interval. defined time interval.
This function MAY either be performed pro-actively or on-demand. This function MAY either be performed proactively 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,
Sections. and Sections.
It SHOULD be possible to rely on user traffic to perform that It SHOULD be possible to rely on user traffic to perform this
functionality. functionality.
The protocol solution(s) developed to perform this function MUST also The protocol solution(s) developed to perform this function MUST also
apply to point-to-point associated bidirectional LSPs, point-to-point apply to point-to-point associated bidirectional LSPs, point-to-point
unidirectional LSPs and point-to-multipoint LSPs. unidirectional LSPs, and point-to-multipoint LSPs.
2.2.12. Packet Delay Measurement 2.2.12. Packet Delay Measurement
The MPLS-TP OAM toolset MUST provide a function to enable the 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 The one-way delay is defined in [7] to be the time elapsed from o The one-way delay is defined in [7] to be the time elapsed from
the start of transmission of the first bit of a packet by an End the start of transmission of the first bit of a packet by an End
Point until the reception of the last bit of that packet by the Point until the reception of the last bit of that packet by the
other End Point. other End Point.
o The two-way delay is defined in [8] to be the time elapsed from o The two-way delay is defined in [8] to be the time elapsed from
the start of transmission of the first bit of a packet by an End the start of transmission of the first bit of a packet by an End
Point until the reception of the last bit of that packet by the Point until the reception of the last bit of that packet by the
same End Point. same End Point.
Two-way delay may be quantified using data traffic loopback at the Two-way delay may be quantified using data traffic loopback at the
remote End Point of the PW, LSP or Section (see Section 2.2.5). remote End Point of the PW, LSP, or Section (see Section 2.2.5).
Accurate quantification of one-way delay may require clock Accurate quantification of one-way delay may require clock
synchronization, the means for which are outside the scope of this synchronization, the means for which are outside the scope of this
document. document.
This function SHOULD be performed on-demand and MAY be performed pro- This function SHOULD be performed on-demand and MAY be performed
actively. proactively.
This function SHOULD be performed between End Points of PWs, LSPs and This function SHOULD be performed between End Points of PWs, LSPs,
Sections. and Sections.
The protocol solution(s) developed to perform this function MUST also The protocol solution(s) developed to perform this function MUST also
apply to point-to-point associated bidirectional LSPs, point-to-point apply to point-to-point associated bidirectional LSPs, point-to-point
unidirectional LSPs and point-to-multipoint LSPs but only to enable unidirectional LSPs, and point-to-multipoint LSPs, but only to enable
the quantification of the one-way delay. 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 Packet Switched Network. packets from causing congestion in the Packet Switched Network.
4. Security Considerations 4. Security Considerations
This document, in 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.
OAM systems (network management stations) SHOULD be designed such OAM systems (network management stations) SHOULD be designed such
that OAM functions cannot be accessed without authorization. that OAM functions cannot be accessed without authorization.
OAM protocol solutions MUST include the facility for OAM messages to OAM protocol solutions MUST include the facility for OAM messages to
authenticated to prove their origin and to make sure that they are authenticated to prove their origin and to make sure that they are
destined for the receiving node. The use of such facilities MUST be destined for the receiving node. The use of such facilities MUST be
configurable. configurable.
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. Acknowledgements
There are no IANA actions required by this draft.
6. Acknowledgements
The editors gratefully acknowledge the contributions of Matthew The editors gratefully acknowledge the contributions of Matthew
Bocci, Italo Busi, Thomas Dietz, Annamaria Fulignoli, Huub van Bocci, Italo Busi, Thomas Dietz, Annamaria Fulignoli, Huub van
Helvoort, Enrique Hernandez-Valencia, Wataru Imajuku, Kam Lam, Marc Helvoort, Enrique Hernandez-Valencia, Wataru Imajuku, Kam Lam, Marc
Lasserre, Lieven Levrau, Han Li, Julien Meuric, Philippe Niger, Lasserre, Lieven Levrau, Han Li, Julien Meuric, Philippe Niger,
Benjamin Niven-Jenkins, Jing Ruiquan, Nurit Sprecher, Yuji Tochio, Benjamin Niven-Jenkins, Jing Ruiquan, Nurit Sprecher, Yuji Tochio,
Satoshi Ueno and Yaacov Weingarten. 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 6. References
7.1. Normative References 6.1. Normative References
[1] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., and [1] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., and
S. Ueno, "Requirements of an MPLS Transport Profile", RFC 5654, S. Ueno, "Requirements of an MPLS Transport Profile", RFC 5654,
September 2009. September 2009.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[3] ITU-T Recommendation G.806, "Characteristics of transport [3] ITU-T Recommendation G.806, "Characteristics of transport
equipment - Description methodology and generic functionality", equipment - Description methodology and generic functionality",
skipping to change at page 16, line 26 skipping to change at page 16, line 36
[6] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Packet [6] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Packet
Loss Metric for IPPM", RFC 2680, September 1999. Loss Metric for IPPM", RFC 2680, September 1999.
[7] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Delay [7] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Delay
Metric for IPPM", RFC 2679, September 1999. Metric for IPPM", RFC 2679, September 1999.
[8] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay [8] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay
Metric for IPPM", RFC 2681, September 1999. Metric for IPPM", RFC 2681, September 1999.
7.2. Informative References 6.2. Informative References
[9] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L. Berger, "A [9] Bocci, M., Ed., Bryant, S., Ed., Frost, D., Ed., Levrau, L.,
Framework for MPLS in Transport Networks", and L. Berger, "A Framework for MPLS in Transport Networks",
draft-ietf-mpls-tp-framework-10 (work in progress), Work in Progress, May 2010.
February 2010.
[10] ITU-T Supplement Y.Sup4, "ITU-T Y.1300-series: Supplement on [10] 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.
[11] Nadeau, T., Morrow, M., Swallow, G., Allan, D., and S. [11] 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.
[12] Allan, D., Busi, I., and B. Niven-Jenkins, "MPLS-TP OAM [12] Busi, I., Ed., Niven-Jenkins, B., Ed., and D. Allan, Ed.,
Framework", draft-ietf-mpls-tp-oam-framework-04 (work in "MPLS-TP OAM Framework", Work in Progress, April 2010.
progress), December 2009.
[13] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, "BFD [13] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, "BFD
For MPLS LSPs", draft-ietf-bfd-mpls-07 (work in progress), For MPLS LSPs", Work in Progress, June 2008.
June 2008.
[14] Nadeau, T. and C. Pignataro, "Bidirectional Forwarding [14] Nadeau, T., Ed. and C. Pignataro, Ed., "Bidirectional
Detection (BFD) for the Pseudowire Virtual Circuit Connectivity Forwarding Detection (BFD) for the Pseudowire Virtual Circuit
Verification (VCCV)", draft-ietf-pwe3-vccv-bfd-07 (work in Connectivity Verification (VCCV)", Work in Progress, July 2009.
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
David Ward (editor) David Ward (editor)
Juniper Networks Juniper Networks
Email: dward@juniper.net EMail: dward@juniper.net
Malcolm Betts (editor) Malcolm Betts (editor)
M. C. Betts Consulting Ltd. M. C. Betts Consulting Ltd.
Email: malcolm.betts@rogers.com EMail: malcolm.betts@rogers.com
 End of changes. 115 change blocks. 
213 lines changed or deleted 195 lines changed or added

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