draft-ietf-mpls-tp-oam-requirements-03.txt   draft-ietf-mpls-tp-oam-requirements-04.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: March 4, 2010 Cisco Systems, Inc. Expires: June 19, 2010 Cisco Systems, Inc.
M. Betts, Ed. M. Betts, Ed.
Huawei Huawei
August 31, 2009 December 16, 2009
Requirements for OAM in MPLS Transport Networks Requirements for OAM in MPLS Transport Networks
draft-ietf-mpls-tp-oam-requirements-03 draft-ietf-mpls-tp-oam-requirements-04
Abstract
This document lists architectural and functional requirements for the
Operations, Administration and Maintenance of MPLS Transport Profile.
These requirements apply to pseudowires, Label Switched Paths, and
Sections.
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 42
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 4, 2010. This Internet-Draft will expire on June 19, 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
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
This document lists architectural and functional requirements for the described in the BSD License.
Operations, Administration and Maintenance of MPLS Transport Profile.
These requirements apply to pseudowires, Label Switched Paths, and
Sections.
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 . . . . . . . . . . . . . . . . 5 2.1. Architectural Requirements . . . . . . . . . . . . . . . . 6
2.1.1. Scope of OAM . . . . . . . . . . . . . . . . . . . . . 5 2.1.1. Scope of OAM . . . . . . . . . . . . . . . . . . . . . 6
2.1.2. Independence . . . . . . . . . . . . . . . . . . . . . 6 2.1.2. Independence . . . . . . . . . . . . . . . . . . . . . 6
2.1.3. OAM and IP Capabilities . . . . . . . . . . . . . . . 6 2.1.3. OAM and IP Capabilities . . . . . . . . . . . . . . . 7
2.1.4. Interoperability and Interworking . . . . . . . . . . 7 2.1.4. Interoperability and Interworking . . . . . . . . . . 7
2.1.5. Data Plane . . . . . . . . . . . . . . . . . . . . . . 7 2.1.5. Data Plane . . . . . . . . . . . . . . . . . . . . . . 7
2.1.6. Configuration . . . . . . . . . . . . . . . . . . . . 7 2.1.6. Configuration . . . . . . . . . . . . . . . . . . . . 8
2.2. Functional Requirements . . . . . . . . . . . . . . . . . 8 2.2. Functional Requirements . . . . . . . . . . . . . . . . . 8
2.2.1. General Requirements . . . . . . . . . . . . . . . . . 8 2.2.1. General Requirements . . . . . . . . . . . . . . . . . 9
2.2.2. Continuity Checks . . . . . . . . . . . . . . . . . . 9 2.2.2. Continuity Checks . . . . . . . . . . . . . . . . . . 9
2.2.3. Connectivity Verifications . . . . . . . . . . . . . . 9 2.2.3. Connectivity Verifications . . . . . . . . . . . . . . 10
2.2.4. Diagnostic Tests . . . . . . . . . . . . . . . . . . . 9 2.2.4. Route Tracing . . . . . . . . . . . . . . . . . . . . 10
2.2.5. Route Tracing . . . . . . . . . . . . . . . . . . . . 10 2.2.5. Diagnostic Tests . . . . . . . . . . . . . . . . . . . 10
2.2.6. Lock Instruct . . . . . . . . . . . . . . . . . . . . 10 2.2.6. Lock Instruct . . . . . . . . . . . . . . . . . . . . 11
2.2.7. Lock Reporting . . . . . . . . . . . . . . . . . . . . 11 2.2.7. Lock Reporting . . . . . . . . . . . . . . . . . . . . 11
2.2.8. Alarm Reporting . . . . . . . . . . . . . . . . . . . 11 2.2.8. Alarm Reporting . . . . . . . . . . . . . . . . . . . 12
2.2.9. Remote Defect Indication . . . . . . . . . . . . . . . 12 2.2.9. Remote Defect Indication . . . . . . . . . . . . . . . 12
2.2.10. Client Failure Indication . . . . . . . . . . . . . . 12 2.2.10. Client Failure Indication . . . . . . . . . . . . . . 13
2.2.11. Packet Loss Measurement . . . . . . . . . . . . . . . 12 2.2.11. Packet Loss Measurement . . . . . . . . . . . . . . . 13
2.2.12. Packet Delay Measurement . . . . . . . . . . . . . . . 13 2.2.12. Packet Delay Measurement . . . . . . . . . . . . . . . 13
3. Congestion Considerations . . . . . . . . . . . . . . . . . . 13 3. Congestion Considerations . . . . . . . . . . . . . . . . . . 14
4. Security Considerations . . . . . . . . . . . . . . . . . . . 13 4. Security Considerations . . . . . . . . . . . . . . . . . . . 14
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
7.1. Normative References . . . . . . . . . . . . . . . . . . . 14 7.1. Normative References . . . . . . . . . . . . . . . . . . . 15
7.2. Informative References . . . . . . . . . . . . . . . . . . 15 7.2. Informative References . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
In the context of MPLS Transport Profile (MPLS-TP, see [5] and [6]), In the context of MPLS Transport Profile (MPLS-TP, see [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 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). 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.
skipping to change at page 3, line 52 skipping to change at page 3, line 52
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 [7]. 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 [8], 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 ...) 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 [9] 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
implement OAM message handling in hardware. Although not a
requirement, this fact could be taken as a design consideration.
1.2. Requirements Language and Terminology 1.2. Requirements Language and Terminology
Although this document is not a protocol specification, the key words Although this document is not a protocol specification, the key words
"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be
interpreted as described in RFC 2119 [1] and are to be interpreted as interpreted as described in RFC 2119 [2] and are to be interpreted as
instructions to the protocol designers producing solutions that instructions to the protocol designers producing solutions that
satisfy the requirements set out in this document. 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 [3].
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]. [3].
In this document we refer to OAM actions which are carried out
continuously or at least on long periods of time, permitting
proactive reporting of fault and/or performance results, as proactive
OAM.
In this document we refer to OAM actions which are initiated via
manual intervention for a limited time to carry out troubleshooting,
as on-demand OAM.
In this document we refer to a Label Edge Router (LER), for a given In this document we refer to a Label Edge Router (LER), for a given
LSP or Section, and to a PW Terminating Provider Edge (T-PE), for a LSP or Section, and to a PW Terminating Provider Edge (T-PE), for a
given PW, as an End Point. Further, we refer to a Label Switching given PW, as an End Point. Further, we refer to a Label Switching
Router (LSR), for a given LSP, and to a PW Switching Provider Edge Router (LSR), for a given LSP, and to a PW Switching Provider Edge
(S-PE), for a given PW, as an Intermediate Point. This document does (S-PE), for a given PW, as an Intermediate Point. This document does
not make 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 [1] 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- In this document we refer to both single segment PWs and multi-
segment PWs as PWs. segment PWs as PWs.
In this document we refer to both bidirectional associated LSPs and In this document we refer to both bidirectional associated LSPs and
bidirectional co-routed LSPs as bidirectional LSPs. 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
far as reasonably possible reuse existing MPLS standards. This
general requirement applies to MPLS-TP OAM. MPLS-TP OAM is defined
in this document through a set of functional requirements. These
requirements will be met by protocol solutions defined in other
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
functions SHOULD be as similar as possible to the mechanisms and
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 regards to the applicability to point-to-
point associated bidirectional LSPs, point-to-point undirectional 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 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.
skipping to change at page 7, line 18 skipping to change at page 7, line 42
2.1.4. Interoperability and Interworking 2.1.4. 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.3. domains materializing the environments described in Section 2.1.3.
It is also REQUIRED that the first two requirements of Section 2.1.3 It is also REQUIRED that the first two requirements of Section 2.1.3
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 [3], MPLS-BFD [10], VCCV [4] and VCCV-BFD protocols (e.g., LSP-Ping [4], MPLS-BFD [13], VCCV [5] and VCCV-BFD
[11]). [14]).
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 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.
skipping to change at page 8, line 39 skipping to change at page 9, line 15
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 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.
For the on-demand OAM functions, the result of which may vary
depending on packet size, it SHOULD be possible to perform these
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 determine whether or not it receives traffic on a PW, LSP or Point to monitor the liveness of a PW, LSP or Section.
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 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 of a PW, LSP or Section to determine whether or not the Point to determine whether or not it is connected to specific End
connectivity provided to an other node through a PW, LSP or Section Point(s) by means of the expected 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 pro-actively between End Points of This function SHOULD be performed pro-actively 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 pro-
actively MUST also apply to point-to-point associated bidirectional actively MUST also apply to point-to-point associated bidirectional
LSPs, point-to-point unidirectional LSPs and point-to-multipoint LSPs, point-to-point unidirectional LSPs and point-to-multipoint
LSPs. 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. Diagnostic Tests 2.2.4. Route Tracing
The MPLS-TP OAM toolset MUST provide a function to enable conducting The MPLS-TP OAM toolset MUST provide functionality to enable an End
diagnostic tests on a PW, LSP or Section. An example of such Point to discover the Intermediate (if any) and End Point(s) along a
diagnostic test consists in looping the traffic at an Intermediate PW, LSP or Section, and more generally to trace the route of a PW,
Point back to the originating End Point. Another example of such LSP or Section. The information collected MUST include identifiers
diagnostic test consists in estimating the bandwidth of e.g., an LSP. 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. Route Tracing 2.2.5. Diagnostic Tests
The MPLS-TP OAM toolset MUST provide functionality to enable an End The MPLS-TP OAM toolset MUST provide a function to enable conducting
Point to discover the Intermediate (if any) and End Point(s) along a diagnostic tests on a PW, LSP or Section. An example of such
PW, LSP or Section, and more generally to trace the route of a PW, diagnostic test consists of performing a loop-back function at a node
LSP or Section. The information collected MUST include identifiers such that all OAM and data traffic are looped back to the originating
related to the nodes and interfaces composing that route. 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 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
skipping to change at page 12, line 49 skipping to change at page 13, line 32
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.
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.
See also [6].
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 traffic to perform that It SHOULD be possible to rely on user traffic to perform that
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.
Note that
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. See also
[7].
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. See also [8].
is performed at the other End Point. 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).
This function SHOULD be performed on-demand and MAY be performed 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.
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
skipping to change at page 14, line 11 skipping to change at page 14, line 44
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.
In general, mechanisms SHOULD be provided to ensure that OAM OAM systems (network management stations) SHOULD be designed such
functions cannot be accessed unauthorized. that OAM functions cannot be accessed without authorization.
Further, OAM messages MAY be authenticated to prove their origin and OAM protocol solutions MUST include the facility for OAM messages to
to make sure that they are destined for the receiving node. authenticated to prove their origin and to make sure that they are
destined for the receiving node. The use of such facilities MUST be
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. IANA Considerations
There are no IANA actions required by this draft. There are no IANA actions required by this draft.
6. Acknowledgements 6. Acknowledgements
skipping to change at page 14, line 42 skipping to change at page 15, line 31
The authors would like to thank all members of the teams (the Joint The authors would like to thank all members of the teams (the Joint
Working Team, the MPLS Interoperability Design Team in IETF and the Working Team, the MPLS Interoperability Design Team in IETF and the
MPLS-TP Ad Hoc Group in ITU-T) involved in the definition and MPLS-TP Ad Hoc Group in ITU-T) involved in the definition and
specification of MPLS-TP. specification of MPLS-TP.
7. References 7. References
7.1. Normative References 7.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [1] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., and
S. Ueno, "Requirements of an MPLS Transport Profile", RFC 5654,
September 2009.
[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.
[2] 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",
2009. 2009.
[3] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label [4] 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 [5] 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 [6] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Packet
Loss Metric for IPPM", RFC 2680, September 1999.
[5] Bocci, M., Bryant, S., and L. Levrau, "A Framework for MPLS in [7] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Delay
Transport Networks", draft-ietf-mpls-tp-framework-03 (work in Metric for IPPM", RFC 2679, September 1999.
progress), August 2009.
[6] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., and [8] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay
S. Ueno, "MPLS-TP Requirements", Metric for IPPM", RFC 2681, September 1999.
draft-ietf-mpls-tp-requirements-10 (work in progress),
August 2009.
[7] ITU-T Supplement Y.Sup4, "ITU-T Y.1300-series: Supplement on 7.2. Informative References
[9] Bocci, M., Bryant, S., Frost, D., and L. Levrau, "A Framework
for MPLS in Transport Networks",
draft-ietf-mpls-tp-framework-06 (work in progress),
October 2009.
[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.
[8] 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.
[9] Busi, I. and B. Niven-Jenkins, "MPLS-TP OAM Framework and [12] Allan, D., Busi, I., and B. Niven-Jenkins, "MPLS-TP OAM
Overview", draft-ietf-mpls-tp-oam-framework-01 (work in Framework", draft-ietf-mpls-tp-oam-framework-04 (work in
progress), July 2009. progress), December 2009.
[10] 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", draft-ietf-bfd-mpls-07 (work in progress),
June 2008. June 2008.
[11] Nadeau, T. and C. Pignataro, "Bidirectional Forwarding [14] Nadeau, T. and C. Pignataro, "Bidirectional Forwarding
Detection (BFD) for the Pseudowire Virtual Circuit Detection (BFD) for the Pseudowire Virtual Circuit Connectivity
Connectivity Verification (VCCV)", draft-ietf-pwe3-vccv-bfd-07 Verification (VCCV)", draft-ietf-pwe3-vccv-bfd-07 (work in
(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
 End of changes. 51 change blocks. 
93 lines changed or deleted 138 lines changed or added

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