MPLS Working Group                                     M. Vigoureux (Editor)
Internet Draft Vigoureux, Ed.
Internet-Draft                                            Alcatel-Lucent
Intended status: Informational                              D. Ward, Ed.
Expires: May September 10, 2009                                      D. Ward (Editor)                          Cisco Systems, Inc.
                                                           M. Betts (Editor) Betts, Ed.
                                                         Nortel Networks

                                                      November 28, 2008
                                                           March 9, 2009

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

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.

   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 May 28, September 10, 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 in of MPLS networks that are used for
   packet transport services and network operations. Transport
   Profile.  These requirements are derived from the set of requirements specified
   by ITU-T apply to pseudowires, Label Switched
   Paths, and first published in the ITU-T Supplement Y.Sup4 [5].

Conventions used Sections.  Architectural, functional and operational
   requirements are covered in this document 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...................................................2  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1. Terminology...............................................3  Definitions  . . . . . . . . . . . . . . . . . . . . . . .  5
     1.2. Definitions...............................................3
      1.3. Context and Motivations...................................4  Contributing Authors . . . . . . . . . . . . . . . . . . .  5
   2.  OAM Requirements...............................................5 Requirements . . . . . . . . . . . . . . . . . . . . . . .  5
     2.1.  Architectural Requirements................................5
      2.2. Functional Requirements...................................7
         2.2.1. General requirements.................................8
         2.2.2. Connectivity Requirements . . . . . . . . . . . . . . . .  6
       2.1.1.  Independence . . . . . . . . . . . . . . . . . . . . .  6
       2.1.2.  Addressing, Routing and Forwarding . . . . . . . . . .  6
       2.1.3.  Interoperability and Interworking  . . . . . . . . . .  6
       2.1.4.  Data Plane . . . . . . . . . . . . . . . . . . . . . .  7
       2.1.5.  Scope  . . . . . . . . . . . . . . . . . . . . . . . .  7
     2.2.  Functional Requirements  . . . . . . . . . . . . . . . . .  7
       2.2.1.  General Requirements . . . . . . . . . . . . . . . . .  8
       2.2.2.  Continuity Verification.............8 Checks  . . . . . . . . . . . . . . . . . .  8
       2.2.3. Client Failure Indication............................8  Connectivity Verifications . . . . . . . . . . . . . .  9
       2.2.4. Remote Defect Indication.............................8  Diagnostic . . . . . . . . . . . . . . . . . . . . . .  9
       2.2.5. Alarm Suppression....................................8  Adjacency  . . . . . . . . . . . . . . . . . . . . . .  9
       2.2.6. Packet Loss..........................................9  Route Tracing  . . . . . . . . . . . . . . . . . . . . 10
       2.2.7. Delay Measurement....................................9  Lock . . . . . . . . . . . . . . . . . . . . . . . . . 10
       2.2.8. Route Determination..................................9  Alarm Notification . . . . . . . . . . . . . . . . . . 10
       2.2.9. Diagnostic..........................................10  Client Failure Indication  . . . . . . . . . . . . . . 11
       2.2.10. Remote Defect Indication . . . . . . . . . . . . . . . 11
       2.2.11. Packet Loss  . . . . . . . . . . . . . . . . . . . . . 11
       2.2.12. Delay Measurement  . . . . . . . . . . . . . . . . . . 12
     2.3.  Operational Requirements.................................10
      2.4. Performance Requirements.................................11 Requirements . . . . . . . . . . . . . . . . . 12
   3. Security Considerations.......................................11
   4.  Congestion Considerations.....................................12 Considerations  . . . . . . . . . . . . . . . . . . 14
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14
   5.  IANA Considerations...........................................12 Considerations  . . . . . . . . . . . . . . . . . . . . . 14
   6. Acknowledgments...............................................12  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
   7. References....................................................13  References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
     7.1.  Normative References.....................................13 References . . . . . . . . . . . . . . . . . . . 15
     7.2.  Informative References...................................13
   Authors' Addresses...............................................13
   Contributing References . . . . . . . . . . . . . . . . . . 15
   Authors' Addresses..................................14
   Intellectual Property Statement..................................15
   Disclaimer of Validity...........................................16
   Copyright Statement..............................................17 Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16

1.  Introduction

   This document lists

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

   o  as a network-oriented mechanism (used by a transport services and network operations.

1.1. Terminology

   AC    Attachment Circuit

   CSF   Client Signal Fail

   FCAPS Fault, Configuration, Accounting, Performance, Security

   LER   Label Edge Router

   LSP   Label Switched Path

   LSR   Label Switching Router

   ME    Maintenance Entity

   MEP   Maintenance End Point

   MIP   Maintenance Intermediate Point

   MP    Maintenance Point

   MS-PW Multi Segment Pseudowire

   OAM   Operations, Administration
      operator) to monitor his network infrastructure and Maintenance

   PE    Provider Edge

   PSN   Packet Switched Network

   PW    Pseudowire

   SLA   Service Level Agreement

   SS-PW Single Segment Pseudowire

   S-PE  PW Switching Provider Edge

   T-PE  PW Terminating Provider Edge

   TCME  Tandem Connection Maintenance Entity

1.2. Definitions

   In this document we refer to a fault as implement
      internal mechanisms in order to enhance the inability general behaviour and
      the level of a function
   to perform a required action. This does not include an inability due
   to preventive maintenance, lack performance of external resources, or planned
   actions. See also ITU-T G.806 [3].

   In this document we refer to a defect as the situation for which
   density his network (e.g., protection
      mechanism in case of anomalies has reached a level where the ability to perform
   a required function has been interrupted. See also ITU-T G.806 [3].

   In this document, we refer node or link failure).  For example fault
      localization is typically associated to MPLS Transport Profile (MPLS-TP) this use case.

   o  as the
   set of MPLS functions used to support packet a service-oriented mechanism (used by a transport service
      provider) to monitor offered services and
   network operations.

   In this document we refer to a MPLS Section as a network segment
   between two LSRs that are immediately adjacent at the MPLS layer.

   For definitions of OAM functional components such as Maintenance
   Point, Maintenance End Point and Maintenance Intermediate Point,
   please refer end customers in order to [7].
   Additional definitions can also
      be found able to react rapidly in [8].

1.3. Context and Motivations

   Important attributes case of MPLS-TP are that

   o  it is a problem and to be able to function regardless
      verify some of which client signals are the Service Level Agreements (SLAs) parameters
      (e.g., using its connectivity performance monitoring) negotiated with the end
      customer.  Note that a transport service or could be provided over which transmission media it
      several networks or administrative domains that may not be all
      owned and managed by the same transport service provider.

   More generally, OAM is running. The client, an important and fundamental functionality in
   transport network networks as it contributes to:

   o  the reduction of operational complexity and server layers are,
      from a functional point costs, by allowing
      efficient and automatic detection, localisation, handling, and
      diagnosis of view, independent layer networks. That
      is, demarcation points exist between MPLS-TP defects, and by minimizing service interruptions and
      operational repair times.

   o  the client layer, enhancement of network availability, by ensuring that defects,
      for example resulting in misdirected customer traffic, and between MPLS-TP faults,
      are detected, diagnosed and the underlying server layer.

   o  it provides means to commit to Service Level Agreements (SLAs)
      negotiated with customers, as well as means to monitor compliance
      with these SLAs.

   o  it is consistent dealt with existing transport network before a customer reports
      the problem.

   o  meet service and performance objectives, by running OAM models.

   In
      functionality which allows SLA verification in a multi-maintenance
      domain environment and allows the context determination of MPLS-TP, service
      degradation due, for example, to packet delay or packet loss.

   This document lists the rationale requirements for the OAM mechanisms functionality of
   MPLS-TP.  These requirements apply to pseudowires (PWs), Label
   Switched Paths (LSPs), and Sections.

   These requirements are
   twofold as they can serve:

   o  as derived from a network-oriented mechanism (used set of requirements specified
   by a transport network
      operator) to monitor his network infrastructure ITU-T and to implement
      internal mechanisms first published 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 fault localization
      is typically associated to this use case.

   o ITU-T Supplement Y.Sup4 [7].

   By covering transport specificities, these requirements stand as a service-oriented mechanism (used by a transport service
      provider) to monitor his offered services
   complement to end customers those identified in
      order to be able RFC 4377 [8].

1.1.  Definitions

   In this document we refer to react rapidly in case a fault as the inability of a problem and function
   to be
      able perform a required action.  This does not include an inability due
   to verify some 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 SLA parameters (i.e. performance
      monitoring) negotiated with situation for which
   density of anomalies has reached a level where the end customer. Note that ability to perform
   a
      transport service could be provided over several networks required function has been interrupted.  See also ITU-T G.806 [2].

   In this document we refer to a Label Edge Router (LER), for a given
   LSP or
      administrative domains that may not be all owned Section, and managed by
      the same transport service provider.

   More generally, OAM is to a PW Terminating Provider Edge (T-PE), for a
   given PW, as an important End Point.  Further, we refer to a Label Switching
   Router (LSR), for a given LSP, and fundamental functionality in
   transport networks to a PW Switching Provider Edge
   (S-PE), for a given PW, as an Intermediate Point.  This document does
   not make any distinction between End Points (e.g., source and
   destination) as it contributes to:

   o can be inferred from the reduction of operational complexity and costs, by allowing
      efficient and automatic detection, localisation, handling, and
      diagnosis context 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 are
      detected, diagnosed and dealt with before a customer reports sentences.

   In this document we use the
      problem.

   o  meet service and performance objectives, by running OAM
      functionality which allows SLA verification in term "node" as a multi-maintenance
      domain environment general referral to End
   Points and allows the determination of service
      degradation due to, for example, packet delay or packet loss.

   This is achieved through Intermediate Points.

   Other definitions, relating to MPLS-TP, can be found in [6].

1.2.  Contributing Authors

   The editors gratefully acknowledge the support contributions of FCAPS functionality, as
   described in ITU-T M.3400 [2], itself relying on OAM related
   information. 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.

2.  OAM Requirements

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

   The requirements listed below may be met by one or more OAM
   protocols,
   protocols; the definition or selection of these protocols is outside
   the scope of this document. However, the specified solution MUST
   inter-work with the existing MPLS and PW OAM protocols.

2.1.  Architectural Requirements

2.1.1.  Independence

   OAM functions SHOULD be independent of the underlying tunnelling or
   point-to-point technology or transmission media.

   OAM functions SHOULD be independent of the service a pseudowire PW may emulate.

   The set of OAM functions operated on each Maintenance Entity SHOULD operated on a PW, LSP or Section SHOULD be
   independent of the set of OAM functions operated on a different PW,
   LSP or Section.  In other words, only the OAM functions available for
   e.g., a LSP should be independent one from another. used to achieve the OAM objectives for that
   LSP.  Note that independence should not be understood here in terms
   of isolation but as there can be interactions between OAM functions
   operated on e.g., a LSP and on another LSP or on a PW.

   OAM functions MUST operate and be configurable even in terms the absence of separate running processes. There should be
   one
   a control plane.  Conversely, OAM process running per Maintenance Entity but different functions SHOULD be configurable as
   part of connectivity (e.g., LSP or PW) management.  Means for
   configuring OAM
   running processes could interact (e.g. alarm summarization). functions and for connectivity management are outside
   the scope of this document.

2.1.2.  Addressing, Routing and Forwarding

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

   o  In some of these environments (e.g., IP/MPLS environments), IP routing and
      forwarding capabilities are inherently
   present (e.g. IP/MPLS) and present.  In this case, the
      OAM functionality MUST also support
   their use. Other deployment scenarios exist where the use of IP routing and
      forwarding capabilities.

   o  In some environments (e.g., MPLS-TP environments), IP routing and
      forwarding capabilities are may not necessarily present (e.g. MPLS-TP). be present.  In these latter cases, this
      case, the operation of OAM functions and their operation MUST NOT rely require
      relying on IP routing and forwarding capabilities. Further, it is REQUIRED by
   this document that OAM interoperability is achieved across these
   environments. It is also REQUIRED by this document that the two above
   requirements are still met and still hold when interoperability is
   achieved.

   Furthermore, in

   In case OAM packets messages need to incorporate identification information
   (e.g., of source and/or destination nodes, nodes), the protocol solution
   MUST at least support an IP addressing structure MUST be supported.

   When MPLS-TP is run with IP routing and forwarding capabilities, all
   existing IP/MPLS OAM functionality (e.g. LSP-Ping, BFD and VCCV) MUST also be able
   extensible to operate seamlessly.

   OAM functions MUST operate support additional addressing schemes.

2.1.3.  Interoperability and be configurable even in the absence of
   a control plane. Conversely, Interworking

   It is REQUIRED by this document that OAM functions SHOULD be configurable as
   part of connectivity (LSP or PW) management. Note interoperability is achieved
   across the environments described in Section 2.1.2.  It is also
   REQUIRED by this document that means for
   configuring OAM functions and for connectivity management are outside the scope two first requirements of this document.

   The service emulated by a single segment or a multi-segment
   pseudowire may span multiple domains. A LSP may also span multiple
   domains. It Section
   2.1.2 still hold and MUST thus still be possible to perform OAM functions on a per domain
   basis met when interoperability is
   achieved.

   When MPLS-TP is run with IP routing and across multiple domains. More generally forwarding capabilities, it
   MUST be possible to perform OAM functions between operate any two switching elements of a the existing IP/MPLS and PW
   or of a LSP. This is referred OAM
   functionalities (e.g., LSP-Ping [3], MPLS-BFD [9], VCCV [4] and VCCV-
   BFD [10]).

   The protocol solution(s) developed to as segment (or tandem connection)
   monitoring (see [7]). Furthermore, in case of a fault or defect on meet the service, means requirements listed in
   this document MUST be available for the service provider to be
   informed of the fault even if interwork with the fault is located outside of his
   domain. existing IP/MPLS and PW OAM
   protocols.

2.1.4.  Data Plane

   OAM functions operate in the data plane.  OAM packets MUST run in-
   band. That
   band; that is, OAM packets for a specific Maintenance Entity PW, LSP or Section MUST
   follow the exact same data path as user traffic of that Maintenance
   Entity. This is known as fate sharing. PW, LSP or
   Section.

   It MUST be possible to discriminate data 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 MIPs or MEPs nodes targeted by these OAM packets.

   As part of the design of OAM mechanisms protocol solutions for MPLS-TP, a
   mechanism that
   enables the realization of a channel for general purpose signalling,
   e.g. for control, management enabling to encapsulate and differentiate OAM information, associated with the
   data plane paths, messages, on
   a PW, LSP or Section, MUST be provided.  Such mechanism SHOULD MUST also
   support the
   operation encapsulation and differentiation of existing IP/MPLS OAM. and
   PW OAM functions 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 able possible to be used for PWs, LSPs and Sections.
   Furthermore, since LSPs MAY be stacked, perform OAM functions on a per domain basis and
   across multiple domains.  More generally it MUST be able possible to
   run on each LSP, regardless
   perform OAM functions between any two switching elements (e.g., LSR
   or S-PE) of the label stack depth. a LSP or of PW.  This is referred to as (concatenated)
   segment monitoring.

2.2.  Functional Requirements

   Hereafter are listed the required functions composing the MPLS-TP OAM
   tool-set.
   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 functions, in the future. Furthermore, the

   The design of OAM mechanisms mechanisms, for MPLS-TP MPLS-TP, MUST allow the ability to
   support vendor specific and experimental OAM functions. Vendor specific and
   experimental OAM  These
   functions MUST be disabled by default and explicitly
   enabled by a service provider or network operator, between nodes that
   support them.

   Moreover, the default.

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

   It is RECOMMENDED by this document that a 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 the table in Section 2.3, for that function.

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

   Note that the functions listed below can serve the purpose of be used for fault
   and/or
   management, performance management. 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 management monitoring application through its
   contribution to the evaluation of performance metrics (e.g. (e.g.,
   unavailability time).  Nevertheless, it is outside the scope of this
   document to specify which function should be used for which
   application.

2.2.1.  General requirements Requirements

   If a defect or fault occurs, 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 SHOULD be taken according
   to the type of defect or fault.

   In

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

2.2.2.  Continuity Checks

   The MPLS-TP OAM toolset MUST provide a function to enable service
   providers and network operators to detect loss 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 be available to parameterize 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 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 case connectivity of the PW Maintenance Entity, OAM mechanisms a PW,
   LSP or Section.

   This function SHOULD be
   provided 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 function is sometime referred to ensure that customers do not have as loopback as End
   Points expect to detect faults. receive some level of information as a result of
   their action.

2.2.4.  Diagnostic

   The MPLS-TP OAM functions SHOULD allow the toolset MAY provide a function to enable service provider
   providers and network operators to automatically
   detect perform diagnostic tests (e.g.,
   verify bandwidth throughput) on a PW, LSP or Section.

   This function SHOULD be performed on-demand.

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

   This function MAY be provided as part of the faults associated with a PW Maintenance Entity.

2.2.2. Connectivity and Continuity Verification
   Verifications function (see Section 2.2.3).

2.2.5.  Adjacency

   The MPLS-TP OAM tool-set toolset MUST provide a function to enable service
   providers an End
   Point to detect loss request, to, and receive from, any node along a PW, LSP or
   Section, a certain level of continuity but also mis-connectivity information (e.g., identification,
   distance in hops).

   This function SHOULD be performed on-demand.

   This function SHOULD be performed between two points End Points and any node of
   a Maintenance Entity.

2.2.3. Client Failure Indication 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 tool-set toolset MUST provide a function to enable a MEP to
   propagate a client failure indication service
   providers and network operators to its peer MEP when alarm
   suppression in the client layer is not supported.

   In cases where the OAM of trace the native service of an AC or route a PW type
   does not provide mechanisms PW, LSP or
   Section.  The information collected SHOULD include identifiers
   related to propagate failure condition
   information, while a downstream indication of such state is needed,
   MPLS-TP OAM the nodes composing that route and MAY include interface
   identifiers.

   This function SHOULD be performed on-demand.

   This function SHOULD provide mechanisms for propagating AC failures be performed between End Points and
   their clearance across a MPLS-TP domain.

2.2.4. Remote Defect Indication 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.  Lock

   The MPLS-TP OAM tool-set MUST toolset MAY provide a function enabling to enable
   administratively shut down a MEP PW, LSP or Section; that is, to
   notify its peer MEP of the detection of a defect on a bi-directional
   connection stop
   user traffic being sent over that PW, LSP or Section.

   This function SHOULD be performed on-demand.

   This function SHOULD be performed between them.

2.2.5. End Points of PWs, LSPs and
   Sections.

2.2.8.  Alarm Suppression Notification

   The MPLS-TP OAM tool-set toolset MUST provide a function to enable a server
   layer MEP End Points to notify a failure fault condition or an administrative
   locking to its the client layer MEP(s) in order End Points affected by this status.  This
   would enable to suppress alarms that may be generated by maintenance domains of in the client
   layer as a result of the failure fault condition or of the administrative
   locking in the server layer.

   The MPLS-TP OAM tool-set toolset MUST allow for the client layer to differentiate distinction between a defect
   fault condition and an administrative locking action at
   the server layer ME. action.

   The server layer MEP End Points generating the notification and the
   client layer MEPs MAY reside on End Points receiving the same
   node notification may or on different may not be
   the same nodes.  A mechanism MUST be provided for to support both cases.

   An alarm suppression

   This function SHOULD be performed pro-actively.

   This function SHOULD be performed between the End Points of PWs, LSPs
   and summarization mechanism 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

   The MPLS-TP OAM toolset MUST be provided.
   For example, provide a function to enable the
   propagation of client fault detected at condition information, across the LSP level MUST NOT trigger
   various alarms at MPLS-TP
   network, if the PW level.

2.2.6. Packet Loss 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 and
   Sections.

2.2.10.  Remote Defect Indication

   The MPLS-TP OAM tool-set toolset MUST provide a function to enable service
   providers to measure packet loss ratio to enable an End
   Point to notify its associated End Point of the detection of a fault
   or defect that it detects on a PW, LSP or Section between them.

   This function SHOULD be performed pro-actively.

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

2.2.11.  Packet Loss

   Packet loss ratio is the ratio of the user-plane user packets not delivered to
   the total number of user-plane user packets transmitted during a defined time
   interval.  The number of user-plane user packets not delivered is the difference
   between the number of user-plane user packets transmitted by
   the source node an End Point and
   the number of user-plane 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 or Section.

   This OAM function MUST support the
   destination node.

2.2.7. configurability of the interval of
   time during which the measure is performed.

   This function SHOULD be performed pro-actively.

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

2.2.12.  Delay Measurement

   The MPLS-TP OAM tool-set toolset MUST provide a function to enable service
   providers and network operators to measure the one-way or two-way one-way, and if
   appropriate, the two-way, delay of a packet
   transmission between a pair of MEPs. Where, PW, LSP or Section.

   o  One-way packet delay is the time elapsed from the start of transmission
      of the first bit of the an OAM packet by a source node an End Point until the
      reception of the last bit of that OAM packet by the destination
      node. other End
      Point.

   o  Two-way packet delay is the time elapsed from the start of transmission
      of the first bit of the an OAM packet by a source node End Point until the
      reception of the last bit of the loop-backed that OAM packet by the same source node, End
      Point, when the loopback is performed at the packet's
      destination node.

2.2.8. Route Determination

   The MPLS-TP OAM tool-set MUST provide a other End Point.

   This function to enable service
   providers to determine the route of a connection across the MPLS
   transport network.

2.2.9. Diagnostic

   The MPLS-TP OAM tool-set MUST provide a SHOULD be performed on-demand.

   This function to enable service
   providers to verify bandwidth throughput (and other diagnostic tests) SHOULD be performed between a pair End Points of MEPs. PWs, LSPs and
   Sections.

2.3.  Operational Requirements

   The OAM functions such as connectivity and continuity verification MUST NOT rely on user traffic. Dedicated traffic to achieve their
   objectives; that is, dedicated OAM messages MUST be used.

   Some OAM flows 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 used to
   detect connectivity and such that
   it accounts, at the design phase, for various possible network
   conditions (e.g., the continuity defects. See also ITU-T G.806 .
   [3]. 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, function.
   However, it is RECOMMENDED that connectivity and MPLS-TP enables continuity
   verification is checks to
   be performed on every Maintenance Entity PW, LSP and Section in order to reliably detect
   connectivity defects. defects and faults.

   OAM functions MUST be applicable to bidirectional point-to-point
   connections, PWs,
   LSPs and Sections, and a subset of these OAM functions MUST be
   applicable to unidirectional point-to-point and point-to-multipoint connections.
   PWs, LSPs and Sections.  This subset is based on the nature of both
   the OAM functions and the connections to which they can apply.

   The following table describes how, on which Maintenance Entity and between which points of the Maintenance Entity PWs, LSPs
   and Sections SHOULD the required OAM functions be applied.  In these tables, MEP
   tables U stands for monitoring
   from MEP to MEP, MIP unidirectional; B stands for monitoring from MEP to MIP, U bidirectional; EP
   stands for unidirectional, B an OAM function being performed between End Points; IP
   stands for bidirectional. an OAM function being performed between End Points and
   Intermediate Points.  Crosses (x) indicate the way the considered
   function should be applied, applied; numbers indicate the way the considered
   function should be applied while pointing to a footnote providing
   additional details.
                          +-------------------------------------------+
                          |      on-demand      |      proactive      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  |
   +----------------------+--+--+----+--+--+----+--+--+----+--+--+----|
   | cc verification c. checks            |  |  |  |x    |  |  |x  |    |x |x | x  |  |  |    |
   |----------------------+--+--+----+--+--+----+--+--+----+--+--+----|
   | client fail. indic. c. verifications     |1 |x | 1  |1 |x | 1  |  |  |    |  |  |x  |    |
   |----------------------+--+--+----+--+--+----+--+--+----+--+--+----|
   | diagnostic           |x |x | x  |2 |2 | 2  |
   |----------------------+--+--+----+--+--+----+--+--+----+--+--+----|  | remote defect indic.  |    |  |  |    |
   |----------------------+--+--+----+--+--+----+--+--+----+--+--+----|
   | adjacency            |1 |x | 1  |1 |x | 1  |  |  |    |  |  |    |
   |----------------------+--+--+----+--+--+----+--+--+----+--+--+----|
   | alarm suppression route tracing        |1 |x | 1  |1 |x | 1  |  |  |    |  |  |    |
   |----------------------+--+--+----+--+--+----+--+--+----+--+--+----|
   | lock                 |x |x | x  |  |  |    |  |  |    |  |  |    |
   |----------------------+--+--+----+--+--+----+--+--+----+--+--+----|
   | packet loss measure alarm notification   |  |  |1  |    |  |  |    |x |2 |x | x  |  |  |    |
   |----------------------+--+--+----+--+--+----+--+--+----+--+--+----|
   | delay measurement    |x |3 client fail. indic.  | x  |  |    |  |  |    |2 |x | 2  |  |  |    |
   |----------------------+--+--+----+--+--+----+--+--+----+--+--+----|
   | route determination remote defect indic. |  |x  |  |  |x    |  |  |    |1 |x | 1  |  |  |    |
   |----------------------+--+--+----+--+--+----+--+--+----+--+--+----|
   | diagnostic           |x packet loss          |2 |3 | 2  |  |  |    |x |4 | x  |  |  |    |
   |----------------------+--+--+----+--+--+----+--+--+----+--+--+----|
   | delay measurement    |x |x | x  |  |  |    |
   +----------------------+-------------------------------------------+
   1: single-ended packet loss measurements

   2: in both directions of the bi-directional connection

   3: one-way and two-way packet delay measurements

         Table 1 : OAM functions and their applicability scope

2.4. Performance Requirements

   OAM functions SHOULD continue to meet their objectives regardless of
   congestion conditions. See also ITU-T Y.1541 [4].

   Additional requirements will be incorporated in a future revision of
   this document.

3. Security Considerations

   Mechanisms SHOULD be provided to ensure that unauthorized access is
   prevented from triggering any OAM function.

   OAM messages MAY be authenticated.

   An OAM packet for a Maintenance Entity MUST NOT leak out of the ME,
   i.e. go beyond the terminating MEP.

4. Congestion Considerations

   A mechanism (e.g. rate limiting) MUST    |2 |2 | 2  |  |  |    |
   +----------------------+--+--+----+--+--+----+--+--+----+--+--+----+
   1: the function MAY be provided to prevent OAM
   messages from causing congestion in the PSN.

5. IANA Considerations

   There are no IANA actions required by this draft.

6. Acknowledgments

   The authors would like to thank all members of the teams (the Joint
   Working Team, if a return path exists
   2: the MPLS Interoperability Design Team in IETF and function MAY be performed
   3: the
   T-MPLS Ad Hoc Group in ITU-T) involved function SHOULD be performed in one direction
   4: the definition and
   specification of MPLS Transport Profile.

7. References

7.1. Normative References

   [1]   Bradner, S., "Key words for use function SHOULD be performed in RFCs to Indicate Requirement
   [2]   ITU-T Recommendation M.3400 (2000), TMN management functions

   [3]   ITU-T Recommendation G.806 (2006), Characteristics of transport
         equipment - Description methodology and generic functionality

   [4]   ITU-T Recommendation Y.1541 (2006), Network performance
         objectives for IP-based services

   [5]   ITU-T Supplement Y.Sup4 (2008), Transport Requirements for T-
         MPLS OAM and considerations for the application of IETF MPLS
         Technology

7.2. Informative References

   [6]   Nadeau, T., et al., "Operations and Management (OAM)
         Requirements for Multi-Protocol Label Switched (MPLS)
         Networks", RFC 4377, February 2006

   [7]   Busi, I., Niven-Jenkins, B., "MPLS-TP both directions

                OAM Framework functions and
         Overview", draft-busi-mpls-tp-oam-framework, October 2008

   [8]   Niven-Jenkins, B., Brungard, D., Betts, M., "MPLS-TP
         Requirements", draft-ietf-mpls-tp-requirements, November 2008

Authors' Addresses

   Martin Vigoureux
   Alcatel-Lucent

   Email: martin.vigoureux@alcatel-lucent.com

   David Ward
   Cisco Systems, Inc.

   Email: dward@cisco.com
   Malcolm Betts
   Nortel Networks

   Email: betts01@nortel.com

Contributing Authors' Addresses

   Matthew Bocci
   Alcatel-Lucent

   Email: matthew.bocci@alcatel-lucent.com

   Italo Busi
   Alcatel-Lucent

   Email: italo.busi@alcatel-lucent.it

   Huub van Helvoort
   Huawei Technologies Co.Ltd.

   Email: hhelvoort@huawei.com

   Marc Lasserre
   Alcatel-Lucent

   Email: mlasserre@alcatel-lucent.com

   Lieven Levrau
   Alcatel-Lucent

   Email: llevrau@alcatel-lucent.com

   Han Li
   China Mobile Communications Corporation (CMCC)
   Email: lihan@chinamobile.com
   Julien Meuric
   Orange

   Email: julien.meuric@orange-ftgroup.com

   Philippe Niger
   Orange

   Email: philippe.niger@orange-ftgroup.com

   Benjamin Niven-Jenkins
   BT

   Email: benjamin.niven-jenkins@bt.com

   Jing Ruiquan
   China Telecom
   Email: jingrq@ctbri.com.cn

   Nurit Sprecher
   Nokia-Siemens Networks

   Email: nurit.sprecher@nsn.com

   Yuji Tochio
   Fujitsu

   Email: tochio@jp.fujitsu.com

   Yaacov Weingarten
   Nokia-Siemens Networks

   Email: yaacov.weingarten@nsn.com

Intellectual Property Statement

   The IETF Trust takes no position regarding the validity or their applicability scope of
   any Intellectual Property Rights or other rights that might

3.  Congestion Considerations

   A mechanism (e.g., rate limiting) MUST be
   claimed to pertain provided to the implementation or use of the technology
   described prevent OAM
   packets from causing congestion in any IETF Document or the extent to which any license
   under such rights might or might not be available; nor PSN.

4.  Security Considerations

   This document, as itself, does it
   represent that it has made not imply any independent effort security consideration
   but OAM, as such, is subject to identify any several security considerations.  OAM
   messages can reveal sensitive information such rights.

   Copies of Intellectual Property disclosures made to the IETF
   Secretariat as passwords,
   performance data and any assurances of licenses to be made available, or
   the result of an attempt made to obtain a general license or
   permission for details about e.g., the use network topology.

   The nature of such proprietary rights by implementers or
   users OAM therefore suggests having some form of this specification can be obtained
   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 IETF on-line IPR
   repository at http://www.ietf.org/ipr

   The IETF invites any interested party to bring
   transport network.

   In general, mechanisms SHOULD be provided to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology ensure that may OAM
   functions cannot be required accessed unauthorized.

   Further, OAM messages MAY be authenticated to implement
   any standard or specification contained in an IETF Document. Please
   address the information prove their origin and
   to the IETF at ietf-ipr@ietf.org

   The definitive version of an IETF Document is make sure that published by, or
   under they are destined for the auspices of, receiving node.

   An OAM packet received over a PW, LSP or Section MUST NOT be
   forwarded beyond the IETF. Versions End Point of IETF Documents that are
   published by third parties, including those that are translated into
   other languages, should not be considered PW, LSP or Section, so as to be definitive versions
   of IETF Documents. The definitive version of these Legal Provisions
   is
   avoid that published by, or under the auspices of, OAM packet leaves the IETF. Versions of
   these Legal Provisions that current administrative domain.

5.  IANA Considerations

   There are published no IANA actions required by third parties, including
   those that are translated into other languages, should not be
   considered this draft.

6.  Acknowledgements

   The authors would like to be definitive versions thank all members of these Legal Provisions.

   For the avoidance of doubt, each Contributor to teams (the Joint
   Working Team, the MPLS Interoperability Design Team in IETF Standards
   Process licenses each Contribution that he or she makes as part of and the IETF Standards Process to
   MPLS-TP Ad Hoc Group in ITU-T) involved in the IETF Trust pursuant definition and
   specification of MPLS-TP.

7.  References

7.1.  Normative References

   [1]   Bradner, S., "Key words for use in RFCs to the
   provisions 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 5378. No language to the contrary, or terms,
   conditions or rights that differ from or are inconsistent with the
   rights 4379, February 2006.

   [4]   Nadeau, T. and licenses granted under C. Pignataro, "Pseudowire Virtual Circuit
         Connectivity Verification (VCCV): A Control Channel for
         Pseudowires", RFC 5378, shall have any effect 5085, December 2007.

7.2.  Informative References

   [5]   Bocci, M., Bryant, S., and
   shall be null 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 void, whether published or posted by such
   Contributor, or included with or
         S. Ueno, "MPLS-TP Requirements",
         draft-ietf-mpls-tp-requirements-04 (work in such Contribution.

Disclaimer progress),
         February 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 Validity

   All IETF Documents MPLS technology", 2008.

   [8]   Nadeau, T., Morrow, M., Swallow, G., Allan, D., and the information contained therein are provided
   on an "AS IS" basis S.
         Matsushima, "Operations and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
   IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
   WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
   WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE
   ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
   FOR A PARTICULAR PURPOSE.

Copyright Statement

   Copyright (c) 2008 IETF Trust Management (OAM) Requirements for
         Multi-Protocol Label Switched (MPLS) Networks", RFC 4377,
         February 2006.

   [9]   Aggarwal, R., Kompella, K., Nadeau, T., and the persons identified as the
   document authors. All rights reserved.

   This document is subject to BCP 78 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 IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) Pseudowire Virtual Circuit
         Connectivity Verification (VCCV)", draft-ietf-pwe3-vccv-bfd-03
         (work 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. progress), February 2009.

Authors' Addresses

   Martin Vigoureux (editor)
   Alcatel-Lucent

   Email: martin.vigoureux@alcatel-lucent.com

   David Ward (editor)
   Cisco Systems, Inc.

   Email: dward@cisco.com

   Malcolm Betts (editor)
   Nortel Networks

   Email: betts01@nortel.com