[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 draft-ietf-mpls-tp-oam-requirements

MPLS Working Group                                M. Vigoureux (Editor)
Internet Draft                                           Alcatel-Lucent
Intended status: Informational
Expires: January 2009                                  D. Ward (Editor)
                                                    Cisco Systems, Inc.

                                                     M. Betts (Editor)
                                                       Nortel Networks

                                                           July 7, 2008



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


Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of 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".

   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 January 7, 2009.

Copyright Notice

   Copyright (C) The IETF Trust (2008).







Vigoureux et al.       Expires January 7, 2009                 [Page 1]


Internet-Draft       OAM Requirements for MPLS-TP             July 2008


Abstract

   This document specifies requirements for OAM (Operations and
   Management) functionality in MPLS networks that are used for packet
   transport services and network operations. The use of the term MPLS
   in this document refers to both MPLS PSNs and pseudowire
   technologies.

   These requirements are derived from the set of requirements specified
   by ITU-T and first published in the ITU-T Supplement Y.Sup4 [6].

Conventions used in this document

   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...................................................3
      1.1. Terminology...............................................3
      1.2. Definitions...............................................4
      1.3. Context and Motivations...................................5
         1.3.1. Transport Profile of MPLS............................5
         1.3.2. Motivations..........................................6
   2. OAM Requirements...............................................7
      2.1. Architectural Requirements................................8
      2.2. Functional Requirements...................................9
      2.3. Performance Requirements.................................12
   3. Security Considerations.......................................12
   4. Congestion Considerations.....................................12
   5. IANA Considerations...........................................12
   6. Acknowledgments...............................................13
   APPENDIX A :   OAM Functions Information.........................14
      A.1. Continuity Check.........................................14
      A.2. Connectivity Verification................................14
      A.3. Alarm Suppression........................................14
      A.4. Lock Indication..........................................15
      A.5. Packet Loss Measurement..................................15
      A.6. Diagnostic Test..........................................15
      A.7. Trace-route..............................................15
      A.8. Delay Measurement........................................16
      A.9. Remote Defect Indication.................................16
      A.10. Client Signal Fail......................................16
   APPENDIX B :   Mapping between RFC 4377, Y.Sup4 and this document17
   7. References....................................................18
      7.1. Normative References.....................................18


Vigoureux et al.       Expires January 7, 2009                 [Page 2]


Internet-Draft       OAM Requirements for MPLS-TP             July 2008


      7.2. Informative References...................................18
   Authors' Addresses...............................................18
   Contributing Authors' Addresses..................................19
   Intellectual Property Statement..................................20
   Disclaimer of Validity...........................................21

1. Introduction

   This document specifies requirements for OAM (Operations and
   Management) functionality in MPLS networks that are used for packet
   transport services and network operations. The use of the term MPLS
   in this document refers to both MPLS PSNs and pseudowire
   technologies.

   These requirements may be met by one or more toolsets. The definition
   or selection of these toolsets is outside the scope of this document.

1.1. Terminology

   AC    Attachment Circuit

   CSF   Client Signal Fail

   FCAPS Fault, Configuration, Accounting, Performance, Security

   LER   Label Edge Router

   LSP   Label Switch 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 and Management

   PE    Provider Edge

   PSN   Packet Switched Network



Vigoureux et al.       Expires January 7, 2009                 [Page 3]


Internet-Draft       OAM Requirements for MPLS-TP             July 2008


   PW    Pseudowire

   SLA   Service Level Agreement

   SS-PW Single Segment Pseudowire

   S-PE  Switching Provider Edge

   T-PE  Terminating Provider Edge

   TCME  Tandem Connection Maintenance Entity

1.2. Definitions

   In this document we refer to a fault as the inability of a function
   to perform a required action. This does not include an inability due
   to preventive maintenance, lack of external resources, or planned
   actions. See also ITU-T G.806 [3].

   In this document we refer to a defect to as the situation for which
   density 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 to MPLS Transport Profile (MPLS-TP) as a
   set of MPLS functions used to support packet transport 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.

   OAM packets can be inserted and extracted at various reference
   points, referred to as Maintenance Points (MP). These MPs are further
   characterized with regard to their position along the entity being
   monitored. The MPs can be end-points (Maintenance End Point, MEP) or
   intermediate points (Maintenance Intermediate Point, MIP). A MEP is
   capable of initiating and terminating OAM packets for fault
   management and performance monitoring. A MIP is capable of reacting
   to some OAM packets but does not initiate OAM packets. Therefore,
   LERs and T-PEs can be MEPs while LSRs and S-PEs can be MIPs. In case
   of Tandem Connection Maintenance Entity (defined below), LSRs and S-
   PEs can be MEPs.

   This document defines the following Maintenance Entities:

   o  The PW Maintenance Entity, corresponding to end-to-end PW
      monitoring (between T-PEs).



Vigoureux et al.       Expires January 7, 2009                 [Page 4]


Internet-Draft       OAM Requirements for MPLS-TP             July 2008


   o  The LSP Maintenance Entity, corresponding to end-to-end LSP
      monitoring (between LERs).

   o  The Tandem Connection Maintenance Entity (TCME), corresponding to
      one or more segment(s) of a PW or to a segment (a.k.a. sub-path)
      of a LSP.
      Note that:
      - A TCME could be defined between the two T-PEs of a SS-PW but
      there is no specific relevance to define such a TCME as it
      corresponds to the PW Maintenance Entity.
      - A TCME can be defined between a T-PE and any S-PE (and vice-
      versa) or between any two S-PEs on a given MS-PW. A TCME can span
      several PW segments, i.e. the PEs (T-PEs or S-PEs) where MEPs are
      located need not be adjacent on the MS-PW.
      - A TCME can be defined between a LER and any LSR (and vice-versa)
      or between any two LSRs, for that LSP. These points (LERs, LSRs)
      where MEPS are located do not need to be adjacent on the LSP. A
      TCME defined between the two LERs of a LSP corresponds to the LSP
      Maintenance Entity.
      - The LSP or MS-PW segment(s) that the TCME covers may however be
      dependant on administrative boundaries in case the LSP or the MS-
      PW spans multiple domains.
      - End-points of a TCME are MEPs, not MIPs.

   A Maintenance Entity can be viewed as the association of two (or
   more) Maintenance End Points that should be provisioned and managed.
   Each OAM flow is associated to a unique ME. MEPs of a given ME
   generate and/or terminate the OAM messages associated to the ME.

   The monitoring of a Maintenance Entity can only be performed at
   points where the Label associated with the Maintenance Entity is the
   top most label of the stack.

   TCMEs MAY be nested but MUST NOT overlap.

1.3. Context and Motivations

1.3.1. Transport Profile of MPLS

   This section does not give any requirement on MPLS-TP. Its sole
   intent is to describe the context in which the OAM requirements could
   fit and is for information only. The authors intend to move it to
   another draft at a later stage.

   A transport network must provide a means to commit, to the client
   signal, the quality of service and availability objectives. These
   objectives can be expressed in the form of a Service Level Agreement


Vigoureux et al.       Expires January 7, 2009                 [Page 5]


Internet-Draft       OAM Requirements for MPLS-TP             July 2008


   (SLA). A transport network must also provide a means to monitor
   compliance to an agreed quality of service.

   Two important attributes of MPLS-TP (as in any transport network
   technology) are that

   o  it is independent from both client and server networks. That is,
      demarcation points exist between MPLS-TP and the customer layer,
      and between MPLS-TP and the underlying tunnelling or point-to-
      point technology.

   o  it is consistent with existing transport network operations and
      management models [8].

   The purpose of a transport network is to transparently carry client
   signals (i.e. the stream of client PDUs or client bits), across the
   network, between ingress and egress (typically over several nodes). A
   key characteristic of transport networks is their ability to monitor
   and therefore maintain the integrity of the client signal between
   ingress and egress ports of the transport network.

   Networks deploying MPLS-TP are configured so as not to use specific
   MPLS capabilities such as ECMP, label merging (i.e. for mp2p
   purposes) and PHP. In the case of bidirectional connectivity, the
   forward and backward directions are congruent (i.e. they follow the
   same path and the pairing relationship between the forward and the
   backward directions is known in each node traversed by bidirectional
   LSPs).

   Just as for other transport technologies and associated transport
   networks, the presence of a distributed control plane in support of
   network operations is optional, and the absence of such control plane
   should not affect the ability to operate the network and to use MPLS-
   TP forwarding, OAM and protection capabilities.

   Finally, some MPLS-TP specific recovery mechanisms are independent of
   a control plane. They rely on OAM capabilities such as APS to trigger
   protection switching in the absence of a control plane.

1.3.2. Motivations

   In the context of MPLS Transport Profile the rationales for OAM
   mechanisms are twofold as they can serve as:






Vigoureux et al.       Expires January 7, 2009                 [Page 6]


Internet-Draft       OAM Requirements for MPLS-TP             July 2008


   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 performances 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  As a service-oriented mechanism (used by a transport service
      provider) to monitor his offered services to end customers it
      order to be able to react rapidly in case of a problem and to be
      able to verify some of the SLA parameters (i.e. performance
      monitoring) negotiated with the end customer. A transport service
      could be provided over several networks or administrative domains
      that may not be all owned and managed by the 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
      efficient and automatic detection, localisation, handling, and
      diagnosis of defects, and by minimizing service interruptions,
      operational repair times, and operational resources.

   o  the enhancement of network availability, by ensuring that defects
      resulting in misdirected customer traffic are detected/diagnosed
      and can lead to appropriate consequent actions minimizing the
      number of defects that are not detected automatically before a
      customer reports the problem.

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

   This is achieved through the support of FCAPS functionality, as
   described in ITU-T M.3400 [2], itself relying on OAM related
   information.

2. OAM Requirements

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

   The requirements listed below may be met by one or more toolsets, the
   definition or selection of these toolsets is outside the scope of


Vigoureux et al.       Expires January 7, 2009                 [Page 7]


Internet-Draft       OAM Requirements for MPLS-TP             July 2008


   this document. However, it is required that the specified solution
   MUST inter-work with the existing MPLS and PW OAM toolset.

2.1. Architectural Requirements

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

   OAM functions SHOULD be independent of the service a pseudowire may
   emulate (e.g. Ethernet).

   The set of OAM functions operated on each Maintenance Entity SHOULD
   be independent one from another. The set of OAM functions must be a
   self-sufficient set that does not require external capabilities to
   achieve the OAM objectives.
   Note that independence should not be understood here in terms of
   isolation but in terms of separate running processes. There should be
   one OAM process running per Maintenance Entity but different OAM
   running processes could interact (e.g. alarm summarization).

   OAM functions MUST operate and be configurable even in the absence of
   a control plane. Conversely, OAM functions SHOULD be configurable as
   part of connectivity (LSP or PW) management. Note that means for
   configuring OAM functions and connectivity management are outside the
   scope of this document.

   The service emulated by a single segment of multi-segment pseudowire
   may span multiple domains. The LSP itself, supporting the pseudo-
   wire(s), may span multiple domains. It MUST be possible to perform
   OAM functions on a per domain basis and across multiple domains.
   Furthermore, in case of a fault or defect on the service, means MUST
   be available for the service provider to be informed of the fault
   even if the fault is located outside its domain.

   OAM functions operate at the data plane. OAM packets MUST run in-
   band. That is, OAM packets for a specific destination MUST follow the
   same data path as data traffic for this destination. This is known as
   fate sharing.

   It MUST be possible to discriminate data traffic from OAM packets.
   This includes a means to differentiate OAM packets from data traffic
   as well as the capability to apply specific treatment to OAM packets.

   OAM functionality MUST NOT be dependent on IP routing and forwarding
   capabilities as these may not be available in networks where MPLS-TP
   is deployed.



Vigoureux et al.       Expires January 7, 2009                 [Page 8]


Internet-Draft       OAM Requirements for MPLS-TP             July 2008


   OAM functions MUST be able to be used for PWs and LSPs and Section.
   Furthermore, since LSPs MAY be stacked, OAM functions MUST be able to
   be run at each network layer (i.e. any level of the label stack).

   OAM functions MUST be applicable to bidirectional point-to-point
   connections, and a subset of these OAM functions MUST be applicable
   to unidirectional point-to-point and point-to-multipoint connections.
   This subset is based on the nature of both the OAM functions and the
   connections to which they can apply. The tables below (Table 1 and
   Table 2) summarize the applicability of OAM functions.

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

2.2. Functional Requirements

   In cases where the OAM of the native service of an AC or a PW type
   does not provide mechanisms to propagate failure conditions
   information, while a downstream indication of such state is needed,
   MPLS-TP OAM SHOULD provide mechanisms for propagating AC failures and
   their clearance across a MPLS-TP domain.

   If a defect or fault occurs, 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 the case of the PW Maintenance Entity, OAM mechanisms provided
   SHOULD ensure that customers do not have to detect faults. The OAM
   functions SHOULD allow the service provider to automatically detect
   and notify the faults associated with a PW Maintenance Entity.

   An alarm suppression and summarization mechanism MUST be provided.
   For example, a fault detected at the LSP level MUST NOT trigger
   various alarms at the PW level.

   The following two tables describe the required OAM functions
   constituting the MPLS-TP OAM toolset for Fault Management and
   Performance Management applications. In these tables, MEP stands for
   monitoring from MEP to MEP, MIP stands for monitoring from MEP to
   MIP, U stands for unidirectional, B stands for bidirectional. Crosses
   (x) indicate a required function, numbers indicate a required
   function while pointing to a footnote providing additional details.

   Appendix A provides a short description of the OAM functions
   typically supported in ITU-T defined transport networks. It is the
   expectation that MPLS-TP will provide an equivalent set.


Vigoureux et al.       Expires January 7, 2009                 [Page 9]


Internet-Draft       OAM Requirements for MPLS-TP             July 2008


                         +-------------------------------------------+
                         |              Fault Management             |
                         |-------------------------------------------|
                         |      on-demand      |      proactive      |
                         |---------------------+----------+----------|
                         |    MEP   |   MIP    |    MEP   |   MIP    |
                         |----------+----------+----------+----------|
                         | P2P |P2MP| P2P |P2MP| P2P |P2MP| P2P |P2MP|
                         |-----+----+----------+----------+-----+----|
                         |U |B | U  |U |B | U  |U |B | U  |U |B | U  |
   +---------------------+--+--+----+--+--+----+--+--+----+--+--+----|
   |continuity check     |  |x |    |  |x |    |x |x | x  |  |  |    |
   |---------------------+--+--+----+--+--+----+--+--+----+--+--+----|
   |connectivity verif.  |  |x |    |  |x |    |x |x | x  |  |  |    |
   |---------------------+--+--+----+--+--+----+--+--+----+--+--+----|
   |alarm suppression    |  |  |    |  |  |    |x |x | x  |  |  |    |
   |---------------------+--+--+----+--+--+----+--+--+----+--+--+----|
   |lock indication      |  |  |    |  |  |    |x |x | x  |  |  |    |
   |---------------------+--+--+----+--+--+----+--+--+----+--+--+----|
   |packet loss meas.    |  |  |    |  |  |    |x |2 | x  |  |  |    |
   |---------------------+--+--+----+--+--+----+--+--+----+--+--+----|
   |diagnostic test      |x |1 | x  |  |  |    |  |  |    |  |  |    |
   |---------------------+--+--+----+--+--+----+--+--+----+--+--+----|
   |trace-route          |  |x |    |  |x |    |  |  |    |  |  |    |
   |---------------------+--+--+----+--+--+----+--+--+----+--+--+----|
   |delay measurement    |  |  |    |  |  |    |  |  |    |  |  |    |
   |---------------------+--+--+----+--+--+----+--+--+----+--+--+----|
   |remote defect indic. |  |  |    |  |  |    |  |x |    |  |  |    |
   +---------------------+-------------------------------------------+


   1: unidirectional and bidirectional test

   2: in both directions of the bi-directional connection

              Table 1 : OAM Functions for Fault Management













Vigoureux et al.       Expires January 7, 2009                [Page 10]


Internet-Draft       OAM Requirements for MPLS-TP             July 2008


                         +-------------------------------------------+
                         |          Performance Management           |
                         |-------------------------------------------|
                         |      on-demand      |      proactive      |
                         |---------------------+----------+----------|
                         |    MEP   |   MIP    |    MEP   |   MIP    |
                         |----------+----------+----------+----------|
                         | P2P |P2MP| P2P |P2MP| P2P |P2MP| P2P |P2MP|
                         |-----+----+----------+----------+-----+----|
                         |U |B | U  |U |B | U  |U |B | U  |U |B | U  |
   +---------------------+--+--+----+--+--+----+--+--+----+--+--+----|
   |continuity check     |  |  |    |  |  |    |x |x | x  |  |  |    |
   |---------------------+--+--+----+--+--+----+--+--+----+--+--+----|
   |connectivity verify. |  |  |    |  |  |    |x |x | x  |  |  |    |
   |---------------------+--+--+----+--+--+----+--+--+----+--+--+----|
   |alarm suppression    |  |  |    |  |  |    |  |  |    |  |  |    |
   |---------------------+--+--+----+--+--+----+--+--+----+--+--+----|
   |lock indication      |  |  |    |  |  |    |  |  |    |  |  |    |
   |---------------------+--+--+----+--+--+----+--+--+----+--+--+----|
   |packet loss meas.    |  |1 |    |  |  |    |x |3 | x  |  |  |    |
   |---------------------+--+--+----+--+--+----+--+--+----+--+--+----|
   |diagnostic test      |  |  |    |  |  |    |  |  |    |  |  |    |
   |---------------------+--+--+----+--+--+----+--+--+----+--+--+----|
   |trace-route          |  |  |    |  |  |    |  |  |    |  |  |    |
   |---------------------+--+--+----+--+--+----+--+--+----+--+--+----|
   |delay measurement    |x |2 |x   |  |  |    |  |  |    |  |  |    |
   |---------------------+--+--+----+--+--+----+--+--+----+--+--+----|
   |remote defect indic. |  |  |    |  |  |    |  |x |    |  |  |    |
   +---------------------+-------------------------------------------+


   1: single-ended packet loss measurements

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

   3: in both directions of the bi-directional connection

Table 2 : OAM Functions for Performance Management

   Note: In case a misconnection is detected, proactive Performance
   Management MUST be suspended until the misconnection has been
   repaired; i.e. all request/response OAM needs to be treated with
   caution as it cannot be assumed to function reliably, e.g. if traffic
   is leaking in a unidirectional sense with no return path.

   The use of OAM functions SHOULD be optional for the operator. A
   network operator SHOULD be able to choose which OAM functions to use


Vigoureux et al.       Expires January 7, 2009                [Page 11]


Internet-Draft       OAM Requirements for MPLS-TP             July 2008


   and which Maintenance Entity to apply them to. However, it is
   recommended that connectivity verification is performed on every
   Maintenance Entity in order to reliably detect connectivity defects.

   OAM functions such as Continuity Check (CC) and Connectivity
   Verification (CV) MUST NOT rely on user traffic. Dedicated OAM CV and
   CC flows SHOULD be used to detect continuity and connectivity
   defects. See also ITU-T G.806 [3].

   As part of the design of OAM mechanisms for MPLS-TP, a mechanism MUST
   be provided enabling the realization of a channel for general purpose
   signalling, e.g. for control, management and OAM information, that is
   associated with the data plane paths.

   The design of OAM mechanisms for MPLS-TP MUST allow the ability to
   support vendor specific and experimental OAM functions.

   Finally, the OAM mechanisms in support of these requirements SHALL be
   extensible and thus SHALL NOT preclude additional OAM functions in
   the future.

2.3. Performance Requirements

   To 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.

   Architectural aspects for security concerning MPLS-TP are described
   in Clause 13 of ITU-T G.8110.1 [5].

4. Congestion Considerations

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

5. IANA Considerations

   There are no IANA actions required by this draft.



Vigoureux et al.       Expires January 7, 2009                [Page 12]


Internet-Draft       OAM Requirements for MPLS-TP             July 2008


6. Acknowledgments

   The authors would like to thank all members of the teams (the Joint
   Working Team, the MPLS Interoperability Design Team in IETF and the
   T-MPLS Ad Hoc Group in ITU-T) involved in the definition and
   specification of MPLS Transport Profile.











































Vigoureux et al.       Expires January 7, 2009                [Page 13]


Internet-Draft       OAM Requirements for MPLS-TP             July 2008


APPENDIX A : OAM Functions Information

   This Appendix provides a short description of the OAM functions
   typically supported in ITU-T defined transport networks.

A.1. Continuity Check

   Continuity Check (CC) is a function that is used to detect loss of
   continuity between MEPs.

   CC is useful for applications like Fault Management, Performance
   Monitoring and Protection Switching, etc.

   CC should be supported both in pro-active and on-demand modes. In
   pro-active mode it may be supported for both bidirectional and
   unidirectional connections.

   In on-demand mode, CC should be supported for bidirectional
   connections both between MEPs and between a MEP and a particular MIP
   along the connection.

A.2. Connectivity Verification

   Connectivity Verification (CV) is a function that is used to check
   connectivity between MEPs in a single maintenance domain.

   CV should be supported both in pro-active and on-demand modes. In
   pro-active mode it may be supported for both unidirectional and bi-
   directional connections.

   In on-demand mode, CV should be supported for bidirectional
   connections both between MEPs and between a MEP and a particular MIP
   along the connection.

A.3. Alarm Suppression

   Alarm Suppression is a function that is used by a server layer MEP to
   notify a failure condition to its client layer MEP(s) in order to
   suppress alarms that may be generated by maintenance domains of the
   client layer as a result of the failure condition in the server
   layer.

   Alarm Suppression should be supported in proactive mode only, for all
   both unidirectional and bi-directional connections.





Vigoureux et al.       Expires January 7, 2009                [Page 14]


Internet-Draft       OAM Requirements for MPLS-TP             July 2008


A.4. Lock Indication

   Lock Indication is a function that is used to indicate an
   administrative locking of a server layer MEP which may result in
   consequential interruption of data traffic forwarding towards the
   client layer MEP(s) expecting this traffic. The reception of a Lock
   Indication allows a MEP to differentiate between a defect condition
   and an administrative locking action at the server layer MEP.

   Lock indication should be supported in pro-active mode only.

A.5. Packet Loss Measurement

   Packet Loss Measurement is a function that is used to measure packet
   loss ratio between a pair of MEPs. Packet Loss Ratio is the ratio of
   the service packets not delivered to the total number of service
   packets transmitted during a set time interval. The number of service
   packets not delivered is the difference between the number of service
   packets transmitted by the source node and the number of service
   packets received at the destination node.

   Packet loss Measurements can be performed by a MEP to measure near-
   end packet loss on unidirectional connections and near-end and far-
   end packet loss on bidirectional connections. Where, near-end packet
   loss refers to packet loss associated with ingress data packets while
   far-end packet loss refers to packet loss associated with egress data
   packets.

   The measurement of packet loss ratio should be supported in pro-
   active mode for both unidirectional and bi-directional connections.

A.6. Diagnostic Test

   A diagnostic test is a function that is used between MEPs to verify
   bandwidth throughput, packet loss, bit errors, etc.

   This function may be used in on-demand mode for either unidirectional
   or bi-directional connections.

A.7. Trace-route

   Trace-route is a function that is used to determine the route of a
   connection across the MPLS transport network.

   Trace-route should be supported in on-demand mode for bi-directional
   connections between a pair of MEPs or between a MEP and a MIP.



Vigoureux et al.       Expires January 7, 2009                [Page 15]


Internet-Draft       OAM Requirements for MPLS-TP             July 2008


A.8. Delay Measurement

   Delay Measurement is a function that is used to measure one-way or
   two-way delay of a packet transmission between a pair of MEPs. Where,

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

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

   This function may be used in on-demand mode.

A.9. Remote Defect Indication

   Remote Defect Indication (RDI) is a function that used by a MEP to
   notify its peer MEP of a detection of a defect on a bi-directional
   connection between them.

   This function should be supported in pro-active mode.

A.10. Client Signal Fail

   Client Signal Fail function (CSF) is used to propagate a Client
   Failure indication to the far-end sink when alarm suppression in the
   client layer is not supported. Upon receiving a packet with CSF
   information a MEP detects a client-layer failure condition and
   notifies its client-layer.

   Upon receiving signal fail indication from its client-layer the MEP
   should immediately start transmitting periodic packets with CSF
   information. A MEP should continue to transmit periodic packets with
   CSF information until the client-layer failure indication is removed.

   Transmission of packets with CSF information can be enabled or
   disabled on a MEP.








Vigoureux et al.       Expires January 7, 2009                [Page 16]


Internet-Draft       OAM Requirements for MPLS-TP             July 2008


APPENDIX B : Mapping between RFC 4377, Y.Sup4 and this document

   To be defined at a later stage.














































Vigoureux et al.       Expires January 7, 2009                [Page 17]


Internet-Draft       OAM Requirements for MPLS-TP             July 2008


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 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 Recommendation G.8110.1/Y.1370.1 (2007), Architecture of
         Transport MPLS (T-MPLS) Layer Network

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

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

   [8]   Response to liaisons on G.8110.1 (from ITU-T SG 15 to IETF)
         https://datatracker.ietf.org/liaison/265/

Authors' Addresses

   Martin Vigoureux
   Alcatel-Lucent

   Email: martin.vigoureux@alcatel-lucent.com


   David Ward
   Cisco Systems, Inc.

   Email: dward@cisco.com






Vigoureux et al.       Expires January 7, 2009                [Page 18]


Internet-Draft       OAM Requirements for MPLS-TP             July 2008


   Malcolm Betts
   Nortel Networks

   Email: betts01@nortel.com


Contributing Authors' Addresses

   Matthew Bocci
   Alcatel-Lucent

   Email: matthew.bocci@alcatel-lucent.co.uk


   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








Vigoureux et al.       Expires January 7, 2009                [Page 19]


Internet-Draft       OAM Requirements for MPLS-TP             July 2008


   Julien Meuric
   Orange

   Email: julien.meuric@orange-ftgroup.com


   Philippe Niger
   Orange

   Email: philippe.niger@orange-ftgroup.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 takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights. Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.




Vigoureux et al.       Expires January 7, 2009                [Page 20]


Internet-Draft       OAM Requirements for MPLS-TP             July 2008


   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard. Please address the information to the IETF at ietf-
   ipr@ietf.org.

Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis 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 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.














Vigoureux et al.       Expires January 7, 2009                [Page 21]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/