MPLS Working Group                                     M. Vigoureux, Ed.
Internet-Draft                                            Alcatel-Lucent
Intended status: Informational Standards Track                            D. Ward, Ed.
Expires: September 10, December 30, 2009                           Cisco Systems, Inc.
                                                           M. Betts, Ed.
                                                         Nortel Networks
                                                           March 9,
                                                                  Huawei
                                                           June 28, 2009

            Requirements for OAM in MPLS Transport Networks
                 draft-ietf-mpls-tp-oam-requirements-01
                 draft-ietf-mpls-tp-oam-requirements-02

Status of this Memo

   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
   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". progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on September 10, December 30, 2009.

Copyright Notice

   Copyright (c) 2009 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 in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Abstract

   This document lists the requirements for the Operations,
   Administration and Maintenance functionality of MPLS Transport
   Profile.  These requirements apply to pseudowires, Label Switched
   Paths, and Sections.  Architectural, functional  Architectural and operational functional requirements are
   covered in this document.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [1].

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4  3
     1.1.  Definitions  . . . . . . . . .  Requirements Language and Terminology  . . . . . . . . . .  4
   2.  OAM Requirements . . . .  5
     1.2.  Contributing Authors . . . . . . . . . . . . . . . . . . .  5
   2.  OAM  4
     2.1.  Architectural Requirements . . . . . . . . . . . . . . . .  5
       2.1.1.  Scope of OAM . . . . . . .  5
     2.1.  Architectural Requirements . . . . . . . . . . . . . . . .  6
       2.1.1.  5
       2.1.2.  Independence . . . . . . . . . . . . . . . . . . . . .  6
       2.1.2.  5
       2.1.3.  Addressing, Routing and Forwarding . . . . . . . . . .  6
       2.1.3.
       2.1.4.  Interoperability and Interworking  . . . . . . . . . .  6
       2.1.4.
       2.1.5.  Data Plane . . . . . . . . . . . . . . . . . . . . . .  7
       2.1.5.  Scope  . . . . . . . . . . . . . . . . . . . . . . . .  7
     2.2.  Functional Requirements  . . . . . . . . . . . . . . . . .  7
       2.2.1.  General Requirements . . . . . . . . . . . . . . . . .  8
       2.2.2.  Continuity Checks  . . . . . . . . . . . . . . . . . .  8
       2.2.3.  Connectivity Verifications . . . . . . . . . . . . . .  9  8
       2.2.4.  Diagnostic . . . . . . . . . . . . . . . . . . . . . .  9  8
       2.2.5.  Adjacency  . .  Route Tracing  . . . . . . . . . . . . . . . . . . . .  9
       2.2.6.  Route Tracing  Lock Instruct  . . . . . . . . . . . . . . . . . . . . 10  9
       2.2.7.  Lock Reporting . . . . . . . . . . . . . . . . . . . . . . . . . 10  9
       2.2.8.  Alarm Notification Reporting  . . . . . . . . . . . . . . . . . . . 10
       2.2.9.  Client Failure  Remote Defect Indication . . . . . . . . . . . . . . 11 . 10
       2.2.10. Remote Defect Client Failure Indication  . . . . . . . . . . . . . . . 11 10
       2.2.11. Packet Loss  . . . . . . . . . . . . . . . . . . . . . 11 10
       2.2.12. Delay Measurement  . . . . . . . . . . . . . . . . . . 12
     2.3.  Operational Requirements . . . . . . . . . . . . . . . . . 12 11
   3.  Congestion Considerations  . . . . . . . . . . . . . . . . . . 14 11
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14 11
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14 12
   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 12
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 12
     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 15 12
     7.2.  Informative References . . . . . . . . . . . . . . . . . . 15 13
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 13

1.  Introduction

   In the context of MPLS Transport Profile (MPLS-TP, see [5] and [6]),
   the rationales for Operations, Administration and Maintenance (OAM)
   mechanisms are twofold as they can serve:

   o  as a network-oriented mechanism (used by a transport network
      operator) to monitor his network infrastructure and to implement
      internal mechanisms in order to enhance the general behaviour and
      the level of performance of his network (e.g., protection
      mechanism in case of node or link failure).  For example example, fault
      localization is typically associated to with this use case.

   o  as a service-oriented mechanism (used by a transport service
      provider) to monitor offered 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 Agreements (SLAs) parameters
      (e.g., using performance monitoring) negotiated with the end
      customer.
      customers.  Note that a transport service could be provided over
      several networks or administrative domains that may not be 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, localisation, handling, and
      diagnosis of defects, and by minimizing service interruptions and
      operational repair times.

   o  the enhancement of network availability, by ensuring that defects,
      for example resulting in misdirected customer traffic, and faults,
      are detected, diagnosed and dealt with before a customer reports
      the problem.

   o  meet service and performance objectives, by running as the OAM functionality which
      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.

   This document lists the 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 a the set of requirements specified
   by ITU-T and first published in the ITU-T Supplement Y.Sup4 [7].

   By covering transport specificities, these requirements stand as a complement to
   those identified in RFC 4377 [8].

1.1.  Definitions

   In

   Note that the OAM functionalities identified in this document we refer to a may be
   used for fault as management, performance monitoring and/or protection
   switching applications.  For example, connectivity verification can
   be used for fault management application by detecting failure
   conditions, but may also be used for performance monitoring
   application through its contribution to the inability evaluation of performance
   metrics (e.g., unavailability time).  Nevertheless, it is outside the
   scope of this document to specify which functionality should be used
   for which application.

1.1.  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 [1].

   In this document we refer to the inability of a function to perform a
   required action. 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 [2].

   In this document we refer to a defect as the situation for in which the density of
   anomalies has reached a level where the ability to perform a required
   function has been interrupted. interrupted, as a defect.  See also ITU-T G.806
   [2].

   In this document we refer to a Label Edge Router (LER), for a given
   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 any 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 referral reference to End
   Points and Intermediate Points.

   Other definitions,

   In this document we refer to both segment and concatenated segments
   as segments (see [6] for definitions relating to MPLS-TP, can be found in [6].

1.2.  Contributing Authors

   The editors gratefully acknowledge the contributions of Matthew
   Bocci, Italo Busi, Thomas Dietz, Huub van Helvoort, Wataru Imajuku,
   Marc Lasserre, Lieven Levrau, Han Li, Julien Meuric, Philippe Niger,
   Benjamin Niven-Jenkins, Jing Ruiquan, Nurit Sprecher, Yuji Tochio,
   Satoshi Ueno and Yaacov Weingarten. term "segment"
   as well as for other definitions relating to MPLS-TP).

2.  OAM Requirements

   This section lists the requirements by which the OAM functionality of
   MPLS-TP should abide.  Note that some requirements for this
   application of MPLS are similar to some of those listed in RFC 4377
   [8].

   The requirements listed below may be met by one or more OAM
   protocols; the definition or selection of these protocols is outside
   the scope of this document.

2.1.  Architectural Requirements

2.1.1.  Independence

   OAM functions SHOULD be independent  Scope of OAM

   The protocol solutions developed to meet the underlying tunnelling or requirements identified
   in this document MUST be applicable to point-to-point technology or transmission media.

   OAM functions bidirectional
   PWs, point-to-point bidirectional LSPs, and point-to-point
   bidirectional Sections and SHOULD additionaly be independent of the applicable to
   unidirectional point-to-point and point-to-multipoint LSPs.

   The service emulated by a single segment or a multi-segment PW may emulate.

   The set of OAM functions operated on a PW,
   span multiple domains.  An LSP or Section SHOULD may also span multiple domains.  It
   MUST be
   independent of the set of possible to operate OAM functions operated on a different PW,
   LSP or Section.  In other words, only per domain basis.
   More generally, the OAM functions available for
   e.g., protocol solutions MUST be applicable end-to-end
   and to segments.

   Since LSPs may be stacked, the protocol solutions 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 PWs or LSPs segments.

2.1.2.  Independence

   The protocol solutions SHOULD be independent of the underlying
   tunnelling or point-to-point technology or transmission media.

   The protocol solutions SHOULD be independent of the service a PW may
   emulate.

   Any OAM function operated on a PW, LSP or Section SHOULD be
   independent of the OAM function(s) operated on a different PW, LSP or
   Section.  In other words, only the OAM functions operated on e.g., a
   given LSP should be used to achieve the OAM objectives for that LSP.
   Note that independence should not be understood here in terms of
   isolation as there can be interactions between OAM functions operated
   on e.g., a LSP an LSP, and on another LSP or on a PW.

   Likewise, any OAM function applied to segment(s) of a PW or LSP
   SHOULD be independent of the OAM function(s) operated on the end-to-
   end PW or LSP.  It SHOULD also be possible to distinguish an OAM
   packet running over a segment of a PW or LSP from another OAM packet
   running on the end-to-end PW or LSP.  Furthermore, any OAM function
   applied to segment(s) of a PW or LSP SHOULD be independent of the OAM
   function(s) applied to other segment(s) of the same PW or LSP.
   Finally, the protocol solutions MUST support the capability to be
   concurrently and independently operated end-to-end and on segments.

   OAM functions MUST operate and be configurable even in the absence of
   a control plane.  Conversely, OAM functions it SHOULD be configurable possible to enable/disable
   the capability to operate OAM functions as part of connectivity (e.g., LSP or PW) management.  Means for
   configuring
   management and it SHOULD also be possible to enable/disable the
   capability to operate OAM functions and for after connectivity management are outside has been
   established.  In the scope of this document.

2.1.2.  Addressing, Routing and Forwarding

   The latter case, the customer MUST NOT perceive
   service degradation as a result of OAM enabling/disabling.  Ideally
   OAM enabling/disabling should take place without introducing any
   customer impairments (e.g., no customer packet losses).  Procedures
   aimed to prevent any traffic impairment MUST be defined for the
   enabling/disabling of OAM functions.  Means for configuring OAM
   functions and for connectivity management are outside the scope of
   this document.

2.1.3.  Addressing, Routing and Forwarding

   The OAM functionality may be deployed in a variety of environments.

   o  In some environments (e.g., IP/MPLS environments), IP routing and
      forwarding capabilities are inherently present. present in the forwarding
      plane.  In this case, the
      OAM functionality it MUST support be possible to operate the use of OAM
      functions by relying on IP routing and forwarding capabilities.

   o  In some environments (e.g., MPLS-TP environments), IP routing and
      forwarding capabilities may not necessarily be present. present in the user
      plane.  In this case, it MUST be possible to operate the OAM
      functions and their operation MUST NOT require without relying on IP routing and forwarding
      capabilities.

   In case cases where OAM messages need to incorporate identification
   information (e.g., of source and/or destination nodes), the protocol solution
   solution(s) MUST at least support an IP addressing structure and MUST
   also be extensible to support additional addressing identification schemes.

2.1.3.

2.1.4.  Interoperability and Interworking

   It is REQUIRED by this document that OAM interoperability is achieved across the
   environments described in Section 2.1.2. 2.1.3.  It is also REQUIRED by this document that
   the two first requirements of Section
   2.1.2 2.1.3 still hold and MUST thus 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
   functionalities
   protocols (e.g., LSP-Ping [3], MPLS-BFD [9], VCCV [4] and VCCV-
   BFD VCCV-BFD
   [10]).

   The protocol solution(s) developed to meet the requirements listed in
   this document MUST interwork with the existing IP/MPLS and PW OAM
   protocols.

2.1.4.

2.1.5.  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, treatment to OAM packets,
   at the nodes targeted by these OAM packets.

   As part of the design of OAM protocol solutions solution(s) for MPLS-TP, a
   mechanism
   mechanism, for enabling to encapsulate the encapsulation and differentiate differentiation of OAM messages,
   messages on a PW, LSP or Section, MUST be provided.  Such mechanism MUST
   SHOULD also support the encapsulation and differentiation of existing
   IP/MPLS and PW OAM messages.

2.1.5.  Scope

   The service emulated by a single segment or a multi-segment PW may
   span multiple domains.  A LSP may also span multiple domains.  It
   MUST be possible to perform OAM functions on a per domain basis and
   across multiple domains.  More generally it MUST be possible to
   perform OAM functions between any two switching elements (e.g., LSR
   or S-PE) of a LSP or of PW.  This is referred to as (concatenated)
   segment monitoring.

2.2.  Functional Requirements

   Hereafter are listed the required functions 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 functions, functionalities, in the future.

   The design of OAM mechanisms, mechanisms for MPLS-TP, MUST allow for the ability
   to support vendor specific and experimental OAM functions.  These functions MUST be
   disabled by default.

   The use of any OAM function MUST be optional for the service provider
   or network operator and a network operator or service provider it MUST be able possible
   to choose which OAM function(s) to use and on which PW, LSP or
   Section to apply it(them) to.

   It is RECOMMENDED by this document that a the protocol solution,
   realizing a given function, effectively provides a fully featured
   function, i.e., a function which is applicable to all the cases
   identified in meeting one or more
   functional requirement(s), be the table in Section 2.3, same for that function.

   The OAM functions MUST be able to be operated on PWs, LSPs and Sections.

   Note

   It is RECOMMENDED that the functions listed below can be used for fault
   management, performance monitoring and/or protection switching
   applications.  For example, connectivity verification can be used for
   fault management application by detecting failure conditions, but may
   also be used for performance monitoring application through its
   contribution protocol solution, meeting one or more
   functional requirement(s), effectively provides a fully featured
   function; that is, a function which is applicable to all the evaluation of performance metrics (e.g.,
   unavailability time).  Nevertheless, it is outside cases
   identified for that functionality.  In that context, protocol
   solution(s) MUST state their applicability.

   Unless otherwise stated, the scope of this
   document to specify which function should OAM functionalities MUST NOT rely on
   user traffic; that is, only OAM messages MUST be used for which
   application. to achieve the
   objectives.

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 entities.  Corrective actions nodes.  Mechanisms SHOULD exist such that corrective
   actions can be taken according
   to the type of defect or fault. taken.

   Furthermore, in case of a fault or defect, affecting a service
   provided by a service provider, mechanisms MUST be available for the a service provider to
   be informed of the a fault or defect affecting the service(s) it
   provides, even if the fault or defect is located outside of his
   domain.

   The protocol solution(s) developed to meet these requirements may
   rely on information exchange.  Information exchange between various
   nodes involved in the operation of an OAM function SHOULD be reliable
   such that, for example, defects or faults are properly detected or
   that state changes are effectively known by the appropriate nodes.

2.2.2.  Continuity Checks

   The MPLS-TP OAM toolset MUST provide a function functionality to enable service
   providers and network operators to detect loss the
   verification of the continuity of continuity, but
   also unintended connectivity, on a PW, LSP or Section.

   This function SHOULD be performed pro-actively.

   This function SHOULD be performed between End Points of PWs, LSPs and
   Sections.

   Means MUST

   This function SHOULD be available performed pro-actively.

2.2.3.  Connectivity Verifications

   The MPLS-TP OAM toolset MUST provide functionality to parameterize enable the frequency at which is
   performed this function as well as to parameterize the criteria, if
   any (e.g., number of consecutive OAM messages not received), based on
   which loss
   verification of continuity or unintended connectivity is detected.  A
   default value MAY be defined.

2.2.3.  Connectivity Verifications

   The MPLS-TP OAM toolset MUST provide a function to enable service
   providers and network operators to verify the connectivity of a PW, LSP or Section.

   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.

   Note that, this

   This function is sometime referred to as loopback as SHOULD be performed on-demand.  This function SHOULD be
   performed pro-actively only between End Points expect to receive some level of information as a result of
   their action. PWs, LSPs and
   Sections.

2.2.4.  Diagnostic

   The MPLS-TP OAM toolset MAY provide a function functionality to enable service
   providers and network operators to perform the
   conduction of diagnostic tests (e.g.,
   verify bandwidth throughput) on a PW, LSP or Section.  An example
   of such diagnotic test would consist in looping the traffic at an
   Intermediate Point, back to the End Point it originates from.
   Another example of such diagnotic test would consist in estimating
   the bandwidth of e.g., an LSP.

   This function SHOULD be performed on-demand.

   This function SHOULD be performed between End Points and Intermediate
   Points of PWs and LSPs, and between End Points of PWs, LSPs and
   Sections.

   This function MAY be provided as part of the Connectivity
   Verifications function (see Section 2.2.3).

2.2.5.  Adjacency  Route Tracing

   The MPLS-TP OAM toolset MUST provide a function functionality to enable an End
   Point to request, to, discover the Intermediate (if any) and receive from, any node End Point(s) along a
   PW, LSP or Section, a certain level of information (e.g., identification,
   distance in hops).

   This function SHOULD be performed on-demand.

   This function SHOULD be performed between End Points and any node of
   a PW, LSP and Section.

   This function MAY be provided jointly with the Route Tracing function
   (see Section 2.2.6).

2.2.6.  Route Tracing

   The MPLS-TP OAM toolset MUST provide a function to enable service
   providers and network operators more generaly to trace the route of a PW, LSP
   or Section.  The information collected SHOULD MUST include identifiers
   related to the nodes and interfaces composing that route and MAY include interface
   identifiers. 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.

   This function MAY be provided jointly with the Adjacency function
   (see Section 2.2.5).

2.2.7.

2.2.6.  Lock Instruct

   The MPLS-TP OAM toolset MAY MUST provide a function enabling functionality to
   administratively shut down enable an End
   Point of a PW, LSP or Section; that is, Section to stop
   user traffic being sent over that instruct its associated End Point(s)
   to lock the PW, LSP or Section.

   This function SHOULD be performed on-demand.

   This function  Note that lock corresponds to an
   administrative status in which forwarding traffic on and from the PW,
   LSP or Section is disabled.

   This function SHOULD be performed on-demand.

   This function SHOULD be performed between End Points of PWs, LSPs and
   Sections.

2.2.8.  Alarm Notification

2.2.7.  Lock Reporting

   The MPLS-TP OAM toolset MUST provide a function functionality to enable server
   layer End Points to notify an
   Intermediate Point of a fault condition PW or an administrative
   locking LSP to the client layer End Points affected by this status.  This
   would enable report, to suppress alarms that may be generated in the client
   layer as a result an End Point of the fault condition that
   same PW or of the administrative
   locking in the server layer.

   The MPLS-TP OAM toolset MUST allow for the distinction between a
   fault condition and LSP, an administrative locking action.

   The server layer End Points generating the notification and the
   client layer End Points receiving the notification may external lock condition affecting that PW or may not be
   the same nodes.  A mechanism MUST be provided to support both cases. LSP.

   This function SHOULD be performed pro-actively.

   This function SHOULD be performed between the End Intermediate Points of PWs, LSPs and Sections and the End
   Points of the PWs and/or LSPs affected by
   the fault condition or administrative locking.

2.2.9.  Client Failure Indication and LSPs.

2.2.8.  Alarm Reporting

   The MPLS-TP OAM toolset MUST provide a function functionality to enable the
   propagation an
   Intermediate Point of client a PW or LSP to report, to an End Point of that
   same PW or LSP, a fault or defect condition information, across the MPLS-TP
   network, if the client layer OAM mechanisms do not provide an alarm
   notification/propagation mechanism. affecting that PW or LSP.

   This function SHOULD be performed pro-actively.

   This function SHOULD be performed between Intermediate Points and End
   Points of PWs, LSPs PWs and
   Sections.

2.2.10. LSPs.

2.2.9.  Remote Defect Indication

   The MPLS-TP OAM toolset MUST provide a function functionality to enable an End
   Point to notify report, to its associated End Point of the detection of Point, a fault or defect
   condition that it detects on a PW, LSP or Section between them. for which they are
   the End Points.

   This function SHOULD be performed pro-actively.

   This function SHOULD be performed between End Points of PWs, LSPs and
   Sections.

2.2.11.  Packet Loss

   Packet loss ratio is

2.2.10.  Client Failure Indication

   The MPLS-TP OAM toolset MUST provide functionality to enable the ratio
   propagation, across an MPLS-TP network, of the user packets not delivered information pertaining to
   the total number of user packets transmitted during
   a defined time
   interval.  The number of user packets not delivered is the difference
   between the number client defect of user packets transmitted by fault condition detected at an End Point and
   the number of user packets received at an End Point.

   The MPLS-TP OAM toolset MUST provide a function to enable service
   providers and network operators to derive packet loss ratio over a
   PW, LSP PW
   or Section.

   This OAM function MUST support the configurability of the interval of
   time during which LSP, if the measure is performed. client layer OAM mechanisms do not provide an alarm
   notification/propagation mechanism.

   This function SHOULD be performed pro-actively.

   This function SHOULD be performed between End Points of PWs, LSPs PWs and
   Sections.

2.2.12.  Delay Measurement LSPs.

2.2.11.  Packet Loss

   The MPLS-TP OAM toolset MUST provide a function functionality to enable service
   providers and network operators to measure the one-way, and if
   appropriate, the two-way, delay
   quantification of packet loss ratio over a PW, LSP or Section.

   o  One-way delay

   Note that packet loss ratio is the time elapsed from the start of transmission ratio of the first bit of an OAM packet by an End Point until user packets not
   delivered to the
      reception total number of the last bit user packets transmitted during a
   defined time interval.  The number of that OAM packet by the other End
      Point.

   o  Two-way delay user packets not delivered is
   the time elapsed from the start of transmission
      of difference between the first bit number of an OAM packet user packets transmitted by a an
   End Point until the
      reception of and the last bit number of that OAM packet by the same End
      Point, when the loopback is performed user packets received at the other an End Point.

   This function SHOULD MAY either be performed pro-actively or on-demand.

   This function SHOULD be performed between End Points of PWs, LSPs and
   Sections.

2.3.  Operational Requirements

   The OAM functions MUST NOT rely on user traffic to achieve their
   objectives; that is, dedicated OAM messages MUST be used.

   Some OAM functions require certain parameters for their operation.
   These parameters MUST be configurable.  A default value MAY be
   defined.

   The specification of certain parameters' values SHOULD be such that
   it accounts, at the design phase, for various possible network
   conditions (e.g., the continuity check function should continue to
   meet its objective (i.e. detect failures) even in the context of high
   traffic load (e.g., congestion)).

   This document does not mandate the use of a particular OAM function.
   However, it is RECOMMENDED that MPLS-TP enables continuity checks to
   be performed on every PW, LSP and Section in order to reliably detect
   connectivity defects and faults.

   OAM functions MUST be applicable to bidirectional point-to-point PWs,
   LSPs and Sections, and a subset of these OAM functions MUST be
   applicable to unidirectional point-to-point and point-to-multipoint Points of PWs, LSPs and
   Sections.  This subset is based

   It SHOULD be possible to rely on user-plane traffic to achieve that
   functionality.

2.2.12.  Delay Measurement

   The MPLS-TP OAM toolset MUST provide functionality to enable the nature
   quantification of both the OAM functions one-way, and if appropriate, the connections to which they can apply.

   The following table describes how, between which points two-way, delay
   of PWs, LSPs
   and Sections SHOULD a PW, LSP or Section.

   o  One-way delay is the required OAM functions be applied.  In these
   tables U stands for unidirectional; B stands for bidirectional; EP
   stands for an OAM function being performed between End Points; IP
   stands for time elapsed from the start of transmission
      of the first bit of a packet by an OAM function being performed between End Points and
   Intermediate Points.  Crosses (x) indicate Point until the way reception
      of the considered
   function should be applied; numbers indicate last bit of that packet by the other End Point.

   o  Two-way delay is the way time elapsed from the considered
   function should be applied while pointing to start of transmission
      of the first bit of a footnote providing
   additional details.
                          +-------------------------------------------+
                          |      on-demand      |      pro-active     |
                          |---------------------+----------+----------|
                          |    MEP   |   MIP    |    MEP   |   MIP    |
                          |----------+----------+----------+----------|
                          | P2P |P2MP| P2P |P2MP| P2P |P2MP| P2P |P2MP|
                          |-----+----+----------+----------+-----+----|
                          |U |B | U  |U |B | U  |U |B | U  |U |B | U  |
   +----------------------+--+--+----+--+--+----+--+--+----+--+--+----|
   | c. checks            |  |  |    |  |  |    |x |x | x  |  |  |    |
   |----------------------+--+--+----+--+--+----+--+--+----+--+--+----|
   | c. verifications     |1 |x | 1  |1 |x | 1  |  |  |    |  |  |    |
   |----------------------+--+--+----+--+--+----+--+--+----+--+--+----|
   | diagnostic           |x |x | x  |2 |2 | 2  |  |  |    |  |  |    |
   |----------------------+--+--+----+--+--+----+--+--+----+--+--+----|
   | adjacency            |1 |x | 1  |1 |x | 1  |  |  |    |  |  |    |
   |----------------------+--+--+----+--+--+----+--+--+----+--+--+----|
   | route tracing        |1 |x | 1  |1 |x | 1  |  |  |    |  |  |    |
   |----------------------+--+--+----+--+--+----+--+--+----+--+--+----|
   | lock                 |x |x | x  |  |  |    |  |  |    |  |  |    |
   |----------------------+--+--+----+--+--+----+--+--+----+--+--+----|
   | alarm notification   |  |  |    |  |  |    |x |x | x  |  |  |    |
   |----------------------+--+--+----+--+--+----+--+--+----+--+--+----|
   | client fail. indic.  |  |  |    |  |  |    |2 |x | 2  |  |  |    |
   |----------------------+--+--+----+--+--+----+--+--+----+--+--+----|
   | remote defect indic. |  |  |    |  |  |    |1 |x | 1  |  |  |    |
   |----------------------+--+--+----+--+--+----+--+--+----+--+--+----|
   | packet loss          |2 |3 | 2  |  |  |    |x |4 | x  |  |  |    |
   |----------------------+--+--+----+--+--+----+--+--+----+--+--+----|
   | delay measurement    |x |x | x  |  |  |    |2 |2 | 2  |  |  |    |
   +----------------------+--+--+----+--+--+----+--+--+----+--+--+----+
   1: the function MAY be provided if by a return path exists
   2: End Point until the function MAY be reception of
      the last bit of that packet by the same End Point, when loopback
      is performed
   3: at the other End Point.

   This function SHOULD be performed in one direction
   4: the on-demand and MAY be perform pro-
   actively.

   This function SHOULD be performed in both directions

                OAM functions between End Points of PWs, LSPs and their applicability scope
   Sections.

   It SHOULD be possible to rely on user-plane traffic to achieve that
   functionality.

3.  Congestion Considerations

   A mechanism (e.g., rate limiting) MUST be provided to prevent OAM
   packets from causing congestion in the PSN.

4.  Security Considerations

   This document, as 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.

   In general, mechanisms SHOULD be provided to ensure that OAM
   functions cannot be accessed unauthorized.

   Further, OAM messages MAY be authenticated to prove their origin and
   to make sure that they are destined for the receiving node.

   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.  IANA Considerations

   There are no IANA actions required by this draft.

6.  Acknowledgements

   The editors gratefully acknowledge the contributions of Matthew
   Bocci, Italo Busi, Thomas Dietz, Huub van Helvoort, Wataru Imajuku,
   Marc Lasserre, Lieven Levrau, Han Li, Julien Meuric, Philippe Niger,
   Benjamin Niven-Jenkins, Jing Ruiquan, Nurit Sprecher, Yuji Tochio,
   Satoshi Ueno and Yaacov Weingarten.

   The authors would like to thank all members of the teams (the Joint
   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.

7.  References

7.1.  Normative References

   [1]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels", BCP 14, RFC 2119, March 1997.

   [2]   ITU-T Recommendation G.806, "Characteristics of transport
         equipment - Description methodology and generic functionality",
         2009.

   [3]   Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label
         Switched (MPLS) Data Plane Failures", RFC 4379, February 2006.

   [4]   Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit
         Connectivity Verification (VCCV): A Control Channel for
         Pseudowires", RFC 5085, December 2007.

7.2.  Informative References

   [5]   Bocci, M., Bryant, S., and L. Levrau, "A Framework for MPLS in
         Transport Networks", draft-ietf-mpls-tp-framework-00 (work in
         progress), November 2008.

   [6]   Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., and
         S. Ueno, "MPLS-TP Requirements",
         draft-ietf-mpls-tp-requirements-04
         draft-ietf-mpls-tp-requirements-09 (work in progress),
         February
         June 2009.

   [7]   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.

   [8]   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.

   [9]   Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, "BFD
         For MPLS LSPs", draft-ietf-bfd-mpls-07 (work in progress),
         June 2008.

   [10]  Nadeau, T. and C. Pignataro, "Bidirectional Forwarding
         Detection (BFD) for the Pseudowire Virtual Circuit
         Connectivity Verification (VCCV)", draft-ietf-pwe3-vccv-bfd-03 draft-ietf-pwe3-vccv-bfd-05
         (work in progress), February June 2009.

Authors' Addresses

   Martin Vigoureux (editor)
   Alcatel-Lucent
   Route de Villejust
   Nozay,   91620
   France

   Email: martin.vigoureux@alcatel-lucent.com
   David Ward (editor)
   Cisco Systems, Inc.
   170 W. Tasman Dr.
   San Jose, CA  95134
   USA

   Email: dward@cisco.com

   Malcolm Betts (editor)
   Nortel Networks
   Huawei

   Email: betts01@nortel.com malcolm.betts@huawei.com