doc: Add RFC documents

1 files changed, 955 insertions, 0 deletions

diff --git a/doc/rfc/rfc5860.txt b/doc/rfc/rfc5860.txt
new file mode 100644
index 0000000..4a66798
--- /dev/null
+++ b/doc/rfc/rfc5860.txt
@@ -0,0 +1,955 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                 M. Vigoureux, Ed.
+Request for Comments: 5860                                Alcatel-Lucent
+Category: Standards Track                                   D. Ward, Ed.
+ISSN: 2070-1721                                         Juniper Networks
+                                                           M. Betts, Ed.
+                                             M. C. Betts Consulting Ltd.
+                                                                May 2010
+
+
+   Requirements for Operations, Administration, and Maintenance (OAM)
+                       in MPLS Transport Networks
+
+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
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (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.
+
+   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 (c) 2010 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+
+
+
+Vigoureux, et al.            Standards Track                    [Page 1]
+
+RFC 5860              OAM Requirements for MPLS-TP              May 2010
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+     1.1.  Scope of This Document . . . . . . . . . . . . . . . . . .  3
+     1.2.  Requirements Language and Terminology  . . . . . . . . . .  4
+   2.  OAM Requirements . . . . . . . . . . . . . . . . . . . . . . .  5
+     2.1.  Architectural Requirements . . . . . . . . . . . . . . . .  6
+       2.1.1.  Scope of OAM . . . . . . . . . . . . . . . . . . . . .  6
+       2.1.2.  Independence . . . . . . . . . . . . . . . . . . . . .  6
+       2.1.3.  Data Plane . . . . . . . . . . . . . . . . . . . . . .  7
+       2.1.4.  OAM and IP Capabilities  . . . . . . . . . . . . . . .  7
+       2.1.5.  Interoperability and Interworking  . . . . . . . . . .  8
+       2.1.6.  Configuration  . . . . . . . . . . . . . . . . . . . .  8
+     2.2.  Functional Requirements  . . . . . . . . . . . . . . . . .  9
+       2.2.1.  General Requirements . . . . . . . . . . . . . . . . .  9
+       2.2.2.  Continuity Checks  . . . . . . . . . . . . . . . . . . 10
+       2.2.3.  Connectivity Verifications . . . . . . . . . . . . . . 10
+       2.2.4.  Route Tracing  . . . . . . . . . . . . . . . . . . . . 11
+       2.2.5.  Diagnostic Tests . . . . . . . . . . . . . . . . . . . 11
+       2.2.6.  Lock Instruct  . . . . . . . . . . . . . . . . . . . . 11
+       2.2.7.  Lock Reporting . . . . . . . . . . . . . . . . . . . . 12
+       2.2.8.  Alarm Reporting  . . . . . . . . . . . . . . . . . . . 12
+       2.2.9.  Remote Defect Indication . . . . . . . . . . . . . . . 13
+       2.2.10. Client Failure Indication  . . . . . . . . . . . . . . 13
+       2.2.11. Packet Loss Measurement  . . . . . . . . . . . . . . . 13
+       2.2.12. Packet Delay Measurement . . . . . . . . . . . . . . . 14
+   3.  Congestion Considerations  . . . . . . . . . . . . . . . . . . 15
+   4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 15
+   5.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
+   6.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
+     6.1.  Normative References . . . . . . . . . . . . . . . . . . . 16
+     6.2.  Informative References . . . . . . . . . . . . . . . . . . 16
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Vigoureux, et al.            Standards Track                    [Page 2]
+
+RFC 5860              OAM Requirements for MPLS-TP              May 2010
+
+
+1.  Introduction
+
+   In the context of MPLS Transport Profile (MPLS-TP, see [9] and [1]),
+   the rationales for Operations, Administration, and Maintenance (OAM)
+   are twofold as it can serve:
+
+   o  as a network-oriented functionality, used by a transport network
+      operator to monitor his network infrastructure and to implement
+      internal mechanisms in order to enhance the general behavior and
+      the level of performance of his network (e.g., protection
+      mechanism in case of node or link failure).  As an example, fault
+      localization is typically associated with this use case.
+
+   o  as a service-oriented functionality, used by a transport service
+      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
+      verify some of the Service Level Agreement (SLA) parameters (e.g.,
+      using performance monitoring) negotiated with the end customers.
+      Note that a transport service could be provided over several
+      networks or administrative domains that may not all be owned and
+      managed by the same transport service provider.
+
+   More generally, OAM is an important and fundamental functionality in
+   transport networks as it contributes to:
+
+   o  the reduction of operational complexity and costs, by allowing for
+      efficient and automatic detection, localization, and handling and
+      diagnosis of defects, as well as by minimizing service
+      interruptions and operational repair times.
+
+   o  the enhancement of network availability, by ensuring that defects
+      (for example, those resulting in misdirected customer traffic) and
+      faults are detected, diagnosed, and dealt with before a customer
+      reports the problem.
+
+   o  meeting service and performance objectives, as the OAM
+      functionality allows for SLA verification in a multi-maintenance
+      domain environment and allows for the determination of service
+      degradation due, for example, to packet delay or packet loss.
+
+1.1.  Scope of This Document
+
+   This document lists architectural and functional requirements for the
+   OAM functionality of MPLS-TP.  These requirements apply to
+   pseudowires (PWs), Label Switched Paths (LSPs), and Sections.
+
+   These requirements are derived from the set of requirements specified
+   by ITU-T and published in the ITU-T Supplement Y.Sup4 [10].
+
+
+
+Vigoureux, et al.            Standards Track                    [Page 3]
+
+RFC 5860              OAM Requirements for MPLS-TP              May 2010
+
+
+   By covering transport specificities, these requirements complement
+   those identified in RFC 4377 [11]; yet, some requirements may be
+   similar.
+
+   This document only lists architectural and functional OAM
+   requirements.  It does not detail the implications of their
+   applicability to the various types (e.g., point-to-point, point-to-
+   multipoint, unidirectional, bidirectional, etc.) of PWs, LSPs, and
+   Sections.  Furthermore, this document does not provide requirements
+   on how the protocol solution(s) should behave to achieve the
+   functional objectives.  Please see [12] for further information.
+
+   Note that the OAM functions identified in this document may be used
+   for fault-management, performance-monitoring, and/or protection-
+   switching applications.  For example, connectivity verification can
+   be used for fault management by detecting failure conditions, but may
+   also be used for performance monitoring through its contribution to
+   the evaluation of performance metrics (e.g., unavailability time).
+   Nevertheless, it is outside the scope of this document to specify
+   which function should be used for which application.
+
+   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
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [2].
+   Although this document is not a protocol specification, the use of
+   this language clarifies the instructions to protocol designers
+   producing solutions that satisfy the requirements set out in this
+   document.
+
+   In this document, we:
+
+   o  refer to the inability of a function to perform a required action
+      as a fault.  This does not include an inability due to preventive
+      maintenance, lack of external resources, or planned actions.  See
+      also ITU-T G.806 [3].
+
+   o  refer to the situation in which the density of 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 [3].
+
+
+
+
+
+
+Vigoureux, et al.            Standards Track                    [Page 4]
+
+RFC 5860              OAM Requirements for MPLS-TP              May 2010
+
+
+   o  refer to OAM actions that are carried out continuously or at least
+      over long periods of time, permitting proactive reporting of fault
+      and/or performance results as proactive OAM.
+
+   o  refer to OAM actions that are initiated via manual intervention
+      for a limited time to carry out troubleshooting as on-demand OAM.
+
+   o  refer to a Label Edge Router (LER), for a given LSP or Section,
+      and to a PW Terminating Provider Edge (T-PE), for a given PW, as
+      an End Point.  Further, we refer to a Label Switching Router
+      (LSR), for a given LSP, and to a PW Switching Provider Edge
+      (S-PE), for a given PW, as an Intermediate Point.  This document
+      does not make a distinction between End Points (e.g., source and
+      destination) as it can be inferred from the context of the
+      sentences.
+
+   o  use the term "node" as a general reference to End Points and
+      Intermediate Points.
+
+   o  refer to both segment and concatenated segments as segments (see
+      [1] for definitions relating to the term "segment" as well as for
+      other definitions relating to MPLS-TP).
+
+   o  refer to both single segment PWs and multi-segment PWs as PWs.
+
+   o  refer to both bidirectional associated LSPs and bidirectional co-
+      routed LSPs as bidirectional LSPs.
+
+2.  OAM Requirements
+
+   This section lists the requirements by which the OAM functionality of
+   MPLS-TP should abide.
+
+   The requirements listed below may be met by one or more OAM
+   protocols; the definition or selection of these protocols is outside
+   the scope of this document.
+
+   RFC 5654 [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.
+
+
+
+
+
+Vigoureux, et al.            Standards Track                    [Page 5]
+
+RFC 5860              OAM Requirements for MPLS-TP              May 2010
+
+
+2.1.  Architectural Requirements
+
+2.1.1.  Scope of OAM
+
+   The protocol solution(s) developed to meet the requirements
+   identified in this document MUST at least be applicable to point-to-
+   point bidirectional PWs, point-to-point co-routed bidirectional LSPs,
+   and point-to-point bidirectional Sections.  Section 2.2 provides
+   additional information with regard to the applicability to point-to-
+   point associated bidirectional LSPs, point-to-point unidirectional
+   LSPs, and point-to-multipoint LSPs.
+
+   The service emulated by a PW may span multiple domains.  An LSP may
+   also span multiple domains.  The protocol solution(s) 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
+   multiple domains.
+
+   Since LSPs may be stacked, the protocol solution(s) MUST be
+   applicable on any LSP, regardless of the label stack depth.
+   Furthermore, it MUST be possible to estimate OAM fault and
+   performance metrics of a single PW or LSP segment or of an aggregate
+   of PW or LSP segments.
+
+2.1.2.  Independence
+
+   The protocol solution(s) SHOULD be independent of the underlying
+   tunneling or point-to-point technology or transmission media.
+
+   The protocol solution(s) SHOULD be independent of the service a PW
+   may emulate.
+
+   Any OAM function operated on a PW, LSP, or Section SHOULD be
+   independent of the OAM function(s) operated on a different PW, LSP,
+   or Section.  In other words, only the OAM functions operated on a
+   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
+   concurrently and independently operated end-to-end and on segments.
+   Therefore, any OAM function applied to segment(s) of a PW or LSP
+   SHOULD be independent of the OAM function(s) operated on the end-to-
+   end PW or LSP.  It SHOULD also be possible to distinguish an OAM
+   packet running over a segment of a PW or LSP from another OAM packet
+   running on the end-to-end PW or LSP.
+
+
+
+
+
+
+Vigoureux, et al.            Standards Track                    [Page 6]
+
+RFC 5860              OAM Requirements for MPLS-TP              May 2010
+
+
+   Furthermore, any OAM function applied to segment(s) of a PW or LSP
+   SHOULD be independent of the OAM function(s) applied to other
+   segment(s) of the same PW or LSP.
+
+      Note: Independence should not be understood in terms of isolation
+      as there can be interactions between OAM functions operated, for
+      example, on two different LSPs.
+
+2.1.3.  Data Plane
+
+   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
+   follow the exact same data path as user traffic of that PW, LSP, or
+   Section.  This is often referred to as fate sharing.
+
+   It MUST be possible to discriminate user traffic from OAM packets.
+   This includes a means to differentiate OAM packets from user traffic
+   as well as the capability to apply specific treatment to OAM packets,
+   at the nodes processing these OAM packets.
+
+   As part of the design of OAM protocol solution(s) for MPLS-TP, a
+   mechanism for enabling the encapsulation and differentiation of OAM
+   messages on a PW, LSP, or Section, MUST be provided.  Such mechanism
+   SHOULD also support the encapsulation and differentiation of existing
+   IP/MPLS and PW OAM messages.
+
+2.1.4.  OAM and IP Capabilities
+
+   There are environments where IP capabilities are present in the data
+   plane.  IP/MPLS environments are examples of such environments.
+   There are also environments where IP capabilities may not be present
+   in the data plane.  MPLS-TP environments are examples of environments
+   where IP capabilities might or might not be present.
+
+      Note: Presence or absence of IP capabilities is deployment
+      scenario dependent.
+
+   It MUST be possible to deploy the OAM functionality in any of these
+   environments.  As a result, it MUST be possible to operate OAM
+   functions with or without relying on IP capabilities, and it MUST be
+   possible to choose to make use of IP capabilities when these are
+   present.
+
+   Furthermore, the mechanism required for enabling the encapsulation
+   and differentiation of OAM messages (see Section 2.1.3) MUST support
+   the capability to differentiate OAM messages of an OAM function
+
+
+
+
+
+Vigoureux, et al.            Standards Track                    [Page 7]
+
+RFC 5860              OAM Requirements for MPLS-TP              May 2010
+
+
+   operated by relying on IP capabilities (e.g., using encapsulation in
+   an IP header) from OAM messages of an OAM function operated without
+   relying on any IP capability.
+
+   Note that IP capabilities include the capability to form a standard
+   IP header, to encapsulate a payload in an IP header, to parse and
+   analyze the fields of an IP header, and to take actions based on the
+   content of these fields.
+
+   For certain functions, OAM messages need to incorporate
+   identification information (e.g., of source and/or destination
+   nodes).  The protocol solution(s) MUST at least support
+   identification information in the form of an IP addressing structure
+   and MUST also be extensible to support additional identification
+   schemes.
+
+2.1.5.  Interoperability and Interworking
+
+   It is REQUIRED that OAM interoperability is achieved between distinct
+   domains materializing the environments described in 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.
+
+   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
+   protocols (e.g., LSP-Ping [4], MPLS-BFD [13], VCCV [5], and VCCV-BFD
+   [14]).
+
+2.1.6.  Configuration
+
+   OAM functions MUST operate and be configurable even in the absence of
+   a control plane.  Conversely, it SHOULD be possible to configure as
+   well as enable/disable the capability to operate OAM functions as
+   part of connectivity management, and it SHOULD also be possible to
+   configure as well as enable/disable the capability to operate OAM
+   functions after connectivity has been established.
+
+   In the latter case, the customer MUST NOT perceive service
+   degradation as a result of OAM enabling/disabling.  Ideally, OAM
+   enabling/disabling should take place without introducing any customer
+   impairments (e.g., no customer packet losses).  Procedures aimed to
+   prevent any traffic impairment MUST be defined for the enabling/
+   disabling of OAM functions.
+
+   Means for configuring OAM functions and for connectivity management
+   are outside the scope of this document.
+
+
+
+
+
+Vigoureux, et al.            Standards Track                    [Page 8]
+
+RFC 5860              OAM Requirements for MPLS-TP              May 2010
+
+
+2.2.  Functional Requirements
+
+   Hereafter are listed the required functionalities composing the
+   MPLS-TP OAM toolset.  The list may not be exhaustive and as such the
+   OAM mechanisms developed in support of the identified requirements
+   SHALL be extensible and thus SHALL NOT preclude the definition of
+   additional OAM functionalities, in the future.
+
+   The design of OAM mechanisms for MPLS-TP, MUST allow for the ability
+   to support experimental OAM functions.  These functions MUST be
+   disabled by default.
+
+   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
+   Section.
+
+   It is RECOMMENDED that any protocol solution, meeting one or more
+   functional requirement(s), be the same for PWs, LSPs, and Sections.
+
+   It is RECOMMENDED that any protocol solution, meeting one or more
+   functional requirement(s), effectively provides a fully featured
+   function; that is, a function that is applicable to all the cases
+   identified for that functionality.  In that context, protocol
+   solution(s) MUST state their applicability.
+
+   Unless otherwise stated, the OAM functionalities MUST NOT rely on
+   user traffic; that is, only OAM messages MUST be used to achieve the
+   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
+
+   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
+   appropriate nodes.  Mechanisms SHOULD exist such that corrective
+   actions can be taken.
+
+   Furthermore, mechanisms MUST be available for a service provider to
+   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.
+
+
+
+
+
+
+
+
+Vigoureux, et al.            Standards Track                    [Page 9]
+
+RFC 5860              OAM Requirements for MPLS-TP              May 2010
+
+
+   Protocol solution(s) developed to meet these requirements may rely on
+   information exchange.  Information exchange between various nodes
+   involved in the operation of an OAM function SHOULD be reliable such
+   that, for example, defects or faults are properly detected or that
+   state changes are effectively known by the appropriate nodes.
+
+2.2.2.  Continuity Checks
+
+   The MPLS-TP OAM toolset MUST provide a function to enable an End
+   Point to monitor the liveness of a PW, LSP, or Section.
+
+   This function SHOULD be performed between End Points of PWs, LSPs,
+   and Sections.
+
+   This function SHOULD be performed proactively.
+
+   The protocol solution(s) developed to perform this function MUST also
+   apply to point-to-point associated bidirectional LSPs, point-to-point
+   unidirectional LSPs, and point-to-multipoint LSPs.
+
+2.2.3.  Connectivity Verifications
+
+   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(s) by means of the expected PW, LSP, or Section.
+
+   This function SHOULD be performed proactively between End Points of
+   PWs, LSPs, and Sections.
+
+   This function SHOULD be performed on-demand between End Points and
+   Intermediate Points of PWs and LSPs, and between End Points of PWs,
+   LSPs, and Sections.
+
+   The protocol solution(s) developed to perform this function
+   proactively MUST also apply to point-to-point associated
+   bidirectional LSPs, point-to-point unidirectional LSPs, and point-to-
+   multipoint LSPs.
+
+   The protocol solution(s) developed to perform this function on-demand
+   MAY also apply to point-to-point associated bidirectional LSPs, to
+   point-to-point unidirectional LSPs, and point-to-multipoint LSPs in
+   case a return path exists.
+
+
+
+
+
+
+
+
+
+Vigoureux, et al.            Standards Track                   [Page 10]
+
+RFC 5860              OAM Requirements for MPLS-TP              May 2010
+
+
+2.2.4.  Route Tracing
+
+   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
+   PW, LSP, or Section, and more generally to trace the route of a PW,
+   LSP, or Section.  The information collected MUST include identifiers
+   related to the nodes and interfaces composing that route.
+
+   This function SHOULD be performed on-demand.
+
+   This function SHOULD be performed between End Points and Intermediate
+   Points of PWs and LSPs, and between End Points of PWs, LSPs, and
+   Sections.
+
+   The protocol solution(s) developed to perform this function MAY also
+   apply to point-to-point associated bidirectional LSPs, to point-to-
+   point unidirectional LSPs, and point-to-multipoint LSPs in case a
+   return path exists.
+
+2.2.5.  Diagnostic Tests
+
+   The MPLS-TP OAM toolset MUST provide a function to enable conducting
+   diagnostic tests on a PW, LSP, or Section.  An example of such a
+   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
+   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 between End Points and Intermediate
+   Points of PWs and LSPs, and between End Points of PWs, LSPs, and
+   Sections.
+
+   The protocol solution(s) developed to perform this function MAY also
+   apply to point-to-point associated bidirectional LSPs, to point-to-
+   point unidirectional LSPs and point-to-multipoint LSPs, in case a
+   return path exists.
+
+2.2.6.  Lock Instruct
+
+   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) to lock the PW, LSP, or Section.  Note that lock corresponds
+   to an administrative status in which it is expected that only test
+   traffic, if any, and OAM (dedicated to the PW, LSP, or Section) can
+   be mapped on that PW, LSP, or Section.
+
+
+
+
+Vigoureux, et al.            Standards Track                   [Page 11]
+
+RFC 5860              OAM Requirements for MPLS-TP              May 2010
+
+
+   This function SHOULD be performed on-demand.
+
+   This function SHOULD be performed between End Points of PWs, LSPs,
+   and Sections.
+
+   The protocol solution(s) developed to perform this function MUST also
+   apply to point-to-point associated bidirectional LSPs, point-to-point
+   unidirectional LSPs, and point-to-multipoint LSPs.
+
+2.2.7.  Lock Reporting
+
+   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)
+   of another LSP on which the former is mapped/tunneled.  Further, it
+   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
+   this document, the Intermediate Point(s) of the PW or LSP may be
+   aware of this condition.  The MPLS-TP OAM toolset MUST provide a
+   function to enable an Intermediate Point of a PW or LSP to report, to
+   an End Point of that same PW or LSP, a lock condition indirectly
+   affecting that PW or LSP.
+
+   This function SHOULD be performed proactively.
+
+   This function SHOULD be performed between Intermediate Points and End
+   Points of PWs and LSPs.
+
+   The protocol solution(s) developed to perform this function MUST also
+   apply to point-to-point associated bidirectional LSPs, point-to-point
+   unidirectional LSPs, and point-to-multipoint LSPs.
+
+2.2.8.  Alarm Reporting
+
+   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)
+   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
+   fault on that tunnel LSP.  By means outside of the scope of this
+   document, the Intermediate Point(s) of the PW or LSP may be aware of
+   this condition.  The MPLS-TP OAM toolset MUST provide functionality
+   to enable an Intermediate Point of a PW or LSP to report, to an End
+   Point of that same PW or LSP, a fault or defect condition indirectly
+   affecting that PW or LSP.
+
+   This function SHOULD be performed proactively.
+
+   This function SHOULD be performed between Intermediate Points and End
+   Points of PWs and LSPs.
+
+
+
+Vigoureux, et al.            Standards Track                   [Page 12]
+
+RFC 5860              OAM Requirements for MPLS-TP              May 2010
+
+
+   The protocol solution(s) developed to perform this function MUST also
+   apply to point-to-point associated bidirectional LSPs, point-to-point
+   unidirectional LSPs, and point-to-multipoint LSPs.
+
+2.2.9.  Remote Defect Indication
+
+   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
+   condition that it detects on a PW, LSP, or Section for which they are
+   the End Points.
+
+   This function SHOULD be performed proactively.
+
+   This function SHOULD be performed between End Points of PWs, LSPs,
+   and Sections.
+
+   The protocol solution(s) developed to perform this function MUST also
+   apply to point-to-point associated bidirectional LSPs and MAY also
+   apply to point-to-point unidirectional LSPs and point-to-multipoint
+   LSPs in case a return path exists.
+
+2.2.10.  Client Failure Indication
+
+   The MPLS-TP OAM toolset MUST provide a function to enable the
+   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
+   or fault condition detected at an End Point of a PW or LSP, if the
+   client layer OAM functionality does not provide an alarm
+   notification/propagation functionality.
+
+   This function SHOULD be performed proactively.
+
+   This function SHOULD be performed between End Points of PWs and LSPs.
+
+   The protocol solution(s) developed to perform this function MUST also
+   apply to point-to-point associated bidirectional LSPs, point-to-point
+   unidirectional LSPs, and point-to-multipoint LSPs.
+
+2.2.11.  Packet Loss Measurement
+
+   The MPLS-TP OAM toolset MUST provide a function to enable the
+   quantification of packet loss ratio over a PW, LSP, or Section.
+
+   The loss of a packet is defined in RFC2680 [6] (see Section 2.4).
+   This definition is used here.
+
+
+
+
+
+
+Vigoureux, et al.            Standards Track                   [Page 13]
+
+RFC 5860              OAM Requirements for MPLS-TP              May 2010
+
+
+   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
+   defined time interval.
+
+   This function MAY either be performed proactively or on-demand.
+
+   This function SHOULD be performed between End Points of PWs, LSPs,
+   and Sections.
+
+   It SHOULD be possible to rely on user traffic to perform this
+   functionality.
+
+   The protocol solution(s) developed to perform this function MUST also
+   apply to point-to-point associated bidirectional LSPs, point-to-point
+   unidirectional LSPs, and point-to-multipoint LSPs.
+
+2.2.12.  Packet Delay Measurement
+
+   The MPLS-TP OAM toolset MUST provide a function to enable the
+   quantification of the one-way, and if appropriate, the two-way, delay
+   of a PW, LSP, or Section.
+
+   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
+      Point until the reception of the last bit of that packet by the
+      other End Point.
+
+   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
+      Point until the reception of the last bit of that packet by the
+      same 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).
+
+   Accurate quantification of one-way delay may require clock
+   synchronization, the means for which are outside the scope of this
+   document.
+
+   This function SHOULD be performed on-demand and MAY be performed
+   proactively.
+
+   This function SHOULD be performed between End Points of PWs, LSPs,
+   and Sections.
+
+
+
+
+
+
+
+Vigoureux, et al.            Standards Track                   [Page 14]
+
+RFC 5860              OAM Requirements for MPLS-TP              May 2010
+
+
+   The protocol solution(s) developed to perform this function MUST also
+   apply to point-to-point associated bidirectional LSPs, point-to-point
+   unidirectional LSPs, and point-to-multipoint LSPs, but only to enable
+   the quantification of the one-way delay.
+
+3.  Congestion Considerations
+
+   A mechanism (e.g., rate limiting) MUST be provided to prevent OAM
+   packets from causing congestion in the Packet Switched Network.
+
+4.  Security Considerations
+
+   This document, in itself, does not imply any security consideration
+   but OAM, as such, is subject to several security considerations.  OAM
+   messages can reveal sensitive information such as passwords,
+   performance data and details about, e.g., the network topology.
+
+   The nature of OAM therefore suggests having some form of
+   authentication, authorization, and encryption in place.  This will
+   prevent unauthorized access to MPLS-TP equipment and it will prevent
+   third parties from learning about sensitive information about the
+   transport network.
+
+   OAM systems (network management stations) SHOULD be designed such
+   that OAM functions cannot be accessed without authorization.
+
+   OAM protocol solutions MUST include the facility for OAM messages to
+   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
+   forwarded beyond the End Point of that PW, LSP, or Section, so as to
+   avoid that the OAM packet leaves the current administrative domain.
+
+5.  Acknowledgements
+
+   The editors gratefully acknowledge the contributions of Matthew
+   Bocci, Italo Busi, Thomas Dietz, Annamaria Fulignoli, Huub van
+   Helvoort, Enrique Hernandez-Valencia, Wataru Imajuku, Kam Lam, Marc
+   Lasserre, Lieven Levrau, Han Li, Julien Meuric, Philippe Niger,
+   Benjamin Niven-Jenkins, Jing Ruiquan, Nurit Sprecher, Yuji Tochio,
+   Satoshi Ueno, and Yaacov Weingarten.
+
+   The authors would like to thank all members of the teams (the Joint
+   Working Team, the MPLS Interoperability Design Team in IETF, and the
+   MPLS-TP Ad Hoc Group in ITU-T) involved in the definition and
+   specification of MPLS-TP.
+
+
+
+Vigoureux, et al.            Standards Track                   [Page 15]
+
+RFC 5860              OAM Requirements for MPLS-TP              May 2010
+
+
+6.  References
+
+6.1.  Normative References
+
+   [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.
+
+   [3]   ITU-T Recommendation G.806, "Characteristics of transport
+         equipment - Description methodology and generic functionality",
+         2009.
+
+   [4]   Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label
+         Switched (MPLS) Data Plane Failures", RFC 4379, February 2006.
+
+   [5]   Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit
+         Connectivity Verification (VCCV): A Control Channel for
+         Pseudowires", RFC 5085, December 2007.
+
+   [6]   Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Packet
+         Loss Metric for IPPM", RFC 2680, September 1999.
+
+   [7]   Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Delay
+         Metric for IPPM", RFC 2679, September 1999.
+
+   [8]   Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay
+         Metric for IPPM", RFC 2681, September 1999.
+
+6.2.  Informative References
+
+   [9]   Bocci, M., Ed., Bryant, S., Ed., Frost, D., Ed., Levrau, L.,
+         and L. Berger, "A Framework for MPLS in Transport Networks",
+         Work in Progress, May 2010.
+
+   [10]  ITU-T Supplement Y.Sup4, "ITU-T Y.1300-series: Supplement on
+         transport requirements for T-MPLS OAM and considerations for
+         the application of IETF MPLS technology", 2008.
+
+   [11]  Nadeau, T., Morrow, M., Swallow, G., Allan, D., and S.
+         Matsushima, "Operations and Management (OAM) Requirements for
+         Multi-Protocol Label Switched (MPLS) Networks", RFC 4377,
+         February 2006.
+
+   [12]  Busi, I., Ed., Niven-Jenkins, B., Ed., and D. Allan, Ed.,
+         "MPLS-TP OAM Framework", Work in Progress, April 2010.
+
+
+
+Vigoureux, et al.            Standards Track                   [Page 16]
+
+RFC 5860              OAM Requirements for MPLS-TP              May 2010
+
+
+   [13]  Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, "BFD
+         For MPLS LSPs", Work in Progress, June 2008.
+
+   [14]  Nadeau, T., Ed. and C. Pignataro, Ed., "Bidirectional
+         Forwarding Detection (BFD) for the Pseudowire Virtual Circuit
+         Connectivity Verification (VCCV)", Work in Progress, July 2009.
+
+Authors' Addresses
+
+   Martin Vigoureux (editor)
+   Alcatel-Lucent
+   Route de Villejust
+   Nozay  91620
+   France
+
+   EMail: martin.vigoureux@alcatel-lucent.com
+
+
+   David Ward (editor)
+   Juniper Networks
+
+   EMail: dward@juniper.net
+
+
+   Malcolm Betts (editor)
+   M. C. Betts Consulting Ltd.
+
+   EMail: malcolm.betts@rogers.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Vigoureux, et al.            Standards Track                   [Page 17]
+