Network Working Group                                        N. Sprecher
Internet-Draft                                    Nokia Siemens Networks
Intended status: Informational                             E. Bellagamba
Expires: January 5, July 6, 2011                                           Ericsson
                                                           Y. Weingarten
                                                  Nokia Siemens Networks
                                                            July 4, 2010

                                                         January 2, 2011

             OAM Analysis
                 draft-ietf-mpls-tp-oam-analysis-02.txt functions in MPLS based transport network


   This document analyzes describes the outcome of the discussions on the
   necessary OAM functionality for the first release of MPLS based
   transport networks.  The discussion is based on the set of
   requirements for Operations, Administration, and Maintenance (OAM)
   for the Transport Profile of
   MPLS(MPLS-TP) MPLS based transport networks as defined in [MPLS-TP OAM Reqs], Reqs].
   An important aspect was to evaluate whether existing OAM tools (either from
   the current MPLS toolset or from the
   ITU-T documents) protocol suite can be applied used to fulfill these
   requirements.  Eventually, the purpose of the document is to map the
   set of functions to a set of tools based on the existing OAM toolset. tool-

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at

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

   This Internet-Draft will expire on January 5, July 6, 2011.

Copyright Notice

   Copyright (c) 2010 2011 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.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Scope  . . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.2.  Organization of the document . . . . . . . . . . . . . . .  4  5
     1.3.  Contributing Authors . . . . . . . . . . . . . . . . . . .  5
     1.4.  Acronyms . . . . . . . . . . . . . . . . . . . . . . . . .  5
   2.  Basic OAM infrastructure functionality . . . . . . . . . . . .  5
   3.  MPLS-TP OAM Functions  . . . . . . . . . . . . . . . . . . . .  6  7
     3.1.  Continuity Check and Connectivity Verification . . . . . .  7
       3.1.1.  Documents for CC-V tools . . . . . . . . . . . . . . .  7
     3.2.  Remote Defect Indication . . . . . . . . . . . . . . . . .  7
       3.2.1.  Documents for RDI  . . . . . . . . . . . . . . . . . .  7  8
     3.3.  Route Tracing  . . . . . . . . . . . . . . . . . . . . . .  7  8
       3.3.1.  Documents for Route Tracing  . . . . . . . . . . . . .  8
     3.4.  Alarm Reporting  . . . . . . . . . . . . . . . . . . . . .  8
       3.4.1.  Documents for Alarm Reporting  . . . . . . . . . . . .  8
     3.5.  Lock Reporting . . . . . . . . . . . . . . . . . . . . . .  8
       3.5.1.  Documents for Lock Reporting . . . . . . . . . . . . .  8
     3.6.  Diagnostic . . . . . . . . . . . . . . . . . . . . . . . .  8
       3.6.1.  Documents for Diagnostic Testing . . . . . . . . . . .  9
     3.7.  Lock Instruct  . . . . . . . . . . . . . . . . . . . . . .  9
       3.6.1.  Documents for Lock Instruct  . . . . . . . . . . . . .  9
     3.7.  Client Failure Indication  . . . . . . . . . . . . . . . .  9
       3.7.1.  Documents for CFI  . . . . . . . . . . . . . . . . . .  9
     3.8.  Packet Loss Measurement  . . . . . . . . . . . . . . . . .  9
       3.8.1.  Documents for Packet Loss Measurement  . . . . . . . . 10
     3.10.  9
     3.9.  Packet Delay Measurement . . . . . . . . . . . . . . . . . 10
       3.9.1.  Documents for Delay Measurement  . . . . . . . . . . . 10
   4.  MPLS-TP OAM documents guide  . . . . . . . . . . . . . . . . . 10
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
   5. 11
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
   6. 11
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
   7.  Informative
   8.  Normative References . . . . . . . . . . . . . . . . . . . . 11 . 12
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 13

1.  Introduction

1.1.  Scope

   OAM (Operations, Administration, and Maintenance) plays a significant
   role in carrier networks, providing methods for fault management and
   performance monitoring in both the transport and the service layers
   in order to improve their ability to support services with guaranteed
   and strict Service Level Agreements (SLAs) while reducing their
   operational costs.

   [MPLS-TP Reqs] in general, and [MPLS-TP OAM Reqs] in particular
   define a set of requirements for OAM functionality in MPLS-Transport
   Profile (MPLS-TP) for MPLS-TP Segments, Label Switched Paths (LSPs)
   (network infrastructure) and Pseudowires (PWs) (services).  One of
   the mandates of

   The OAM solution developed by the joint (IETF IETF and ITU-T) ITU-T MPLS-TP work-item is the
   objective of developing a Transport Profile is to base the toolset
   project has three objectives:

   o  The OAM tool-set should be developed based on existing MPLS technologies.  In addition, [MPLS-TP Reqs] indicates
      architecture, technology, and tool-sets.

   o  It should be verified that the need OAM tool-set for MPLS transport
      networks should be aligned with the comparable tool-set in legacy
      transport networks as much as possible.

   o  The OAM toolset tool-set developed for MPLS-TP MPLS based transport networks needs
      to be fully interoperable inter-operable with existing MPLS OAM tools. tools as
      documented in [MPLS-TP OAM Reqs].

   The purpose of this document is to outline discussion on the recommendations of needed OAM tool-set took place, mainly, in the
   MPLS-TP design team
   MPLS Interoperability Design Team (the MEAD).  A tool-set was agreed
   upon and confirmed by was reported to the MPLS working group in Stockholm (July
   2009) during the IETF meetings.  This was also judged to be the
   working group consensus.

   This document outlines these recommendations for the
   toolset tool-set that
   should be defined to fulfill the OAM functionality requirements as
   documented in [MPLS-TP OAM Reqs] and [MPLS-TP OAM Frwk].  Based on
   the principles objectives cited above, it was determined to base the MPLS-TP OAM toolset
   tool-set on the following existing MPLS tools:

   o  LSP-Ping as defined in [LSP Ping].

   o  Bidirectional Forwarding Detection (BFD) as defined in [BASE BFD]
      and refined in [MPLS BFD].

   o  ITU-T OAM for Ethernet toolset tool-set as defined in [Y.1731] this will
      be used for functionality guidelines for the performance
      measurement tools that are not currently supported in MPLS.

   It should be noted that certain extensions and adjustments may be
   made to the existing MPLS tools, in order to conform to the transport
   environment and the requirements of MPLS-TP. MPLS based transport networks.

1.2.  Organization of the document

   Section 2 of the document provides references to reviews the basic OAM tools
   that are provided requirements for MPLS-TP OAM. OAM
   and shows how they are addressed by the top-level architectural RFCs

   Section 3 outlines the different functional tools that are required
   for MPLS-TP OAM and references the documents that will define the
   appropriate tools based on the principles outlined above.

   Section 4 provides the user with a cross-reference, pointing out
   which tools are addressed by each of the OAM solutions RFCs.

1.3.  Contributing Authors

   Yaakov Stein (Rad), Annamaria Fulignoli (Ericsson), Italo Busi
   (Alcatel Lucent), Huub van Helvoort (Huawei)

1.4.  Acronyms

   This draft uses the following acronyms:

   ACH     Associated Channel Header
   BFD     Bidirectional Forwarding Detection
   CC-V    Continuity Check and Connectivity Verification
   G-ACH   Generic Associated Channel Header
   LSP     Label Switched Path
   MPLS-TP Transport Profile for MPLS
   OAM     Operations, Administration, and Maintenance
   PW      Pseudowire
   RDI     Remote Defect Indication
   SLA     Service Level Agreement
   TLV     Type, Length, Value
   VCCV    Virtual Circuit Connectivity Verification

2.  Basic OAM infrastructure functionality

   [MPLS-TP OAM Reqs] defines a set of requirements on OAM architecture
   and general principles of operations which are evaluated below:


   [MPLS-TP OAM Reqs] requires that

   o  OAM mechanisms in MPLS-TP are independent of the transmission
      media and of the client service being emulated by the PW.

   o  [MPLS-TP OAM Reqs] requires that  the MPLS-TP OAM must be able to support both an IP based and
      non-IP based environment.  If the network is IP based, i.e.  IP
      routing and forwarding are available, then the MPLS-TP OAM toolset tool-
      set should rely on the IP routing and forwarding capabilities.  On
      the other hand, in environments where IP functionality is not
      available, the OAM tools must still be able to operate without
      dependence on IP forwarding and routing.

   o  [MPLS-TP OAM Reqs] requires that  all OAM protocols support identification information, at least in
      the form of IP addressing structure and be extensible to support
      additional identification schemes.

   o  It is also required that  OAM packets and the user traffic are congruent (i.e.  OAM packets
      are transmitted in-band) and there is a need to differentiate OAM
      packets from user-plane ones.  Inherent in this requirement is the
      principle that MPLS-TP OAM be independent of any existing control-plane, control-
      plane, although it should not preclude use of the control-plane

   o  [MPLS-TP OAM Reqs] requires  a single OAM technology and consistent OAM capabilities for LSPs,
      PWs, and Sections.

   o  [MPLS-TP OAM Reqs] requires allowing  OAM packets to may be directed to an intermediate point of a LSP/PW.

   The following comprise the document-set that addresses the basic
   requirements listed above:

   o  The [MPLS-TP OAM Frwk] document describes the architecural architectural
      framework for conformance to the basic requirements listed above.
      It also defines the basic relationships between the MPLS
      structures, e.g.  LSP, PW, and the structures necessary for OAM
      functionality, i.e. the Managed Entity Group, its End-points, and
      Intermediate Points.

   o  The [MPLS G-ACH] document specifies the use of the MPLS-TP in-
      band control channel.  This is modeled after the VCCV channel
      described in [PW ACH] and allows transporting the OAM messages
      congruently with the data traffic while allowing the required
      identification of the packets.  It is expected that all of the OAM
      protocols will be used in conjunction with this Generic Associated

   o  The [MPLS-TP ACH TLV] document specifies a basic set of TLV fields
      that could be used by different OAM messages, in conjunction with
      the Generic Associated Channel, to supply the additional parameter
      values necessary for the proper functionality.

   o  The [MPLS TP Idents] document addresses the need of MPLS-TP to
      support different addressing spaces.  This document describes
      different formats for addresses that could be used to identify the
      transport entities in the network and referenced by the different
      OAM protocols.

3.  MPLS-TP OAM Functions

   The following sections discuss the required OAM functions that were
   identified are required in
   [MPLS-TP OAM Reqs] and expanded upon in [MPLS-TP OAM Frwk].

3.1.  Continuity Check and Connectivity Verification

   Continuity Check and Connectivity Verification (CC-V) are OAM
   operations generally used in tandem, and compliment each other.
   These functions are generally run proactively, pro-actively, but may also be used
   on-demand, either due to bandwidth considerations or for diagnoses of
   a specific condition.  Proactively  Pro-actively [MPLS-TP OAM Reqs] states that
   the function should allow the MEPs to monitor the liveness and
   connectivity of a transport path.  In on-demand mode, this function
   should support monitoring between the MEPs and, in addition, between
   a MEP and MIP.

   The [MPLS-TP OAM Frwk] highlights the need for the CC-V messages to
   include unique identification of the MEG that is being monitored and
   the MEP that originated the message.  The function, both proactively pro-actively
   and in on-demand mode, need needs to be transmitted at regular
   transmission rates pre-
   configured pre-configured by the operator.

3.1.1.  Documents for CC-V tools

   [Pro CC-V] defines the BFD extensions that will be used for proactive
   CC-V applications.  While [Demand CV] provides the LSP-Ping
   extensions that will be used to implement on-demand Connectivity
   Verification.  Both of these tools will be used together with the
   basic tools mentioned above in section 2 2.

3.2.  Remote Defect Indication

   Remote Defect Indication (RDI) is used by a path end-point to report
   to its peer end-point that a defect is detected on a bi-directional
   connection between them.  [MPLS-TP OAM Reqs] points out that this
   function may be applied to a unidirectional LSP only if there a
   return path exists.  [MPLS-TP OAM Frwk] points out that this function
   is associated with the proactive CC-V function function.

3.2.1.  Documents for RDI

   The [Pro CC-V] document includes and an extension for BFD that would
   include the RDI indication in the BFD format, and a specification of
   how this indication is to be used.

3.3.  Route Tracing

   [MPLS-TP OAM Reqs] defines that there is a need for functionality
   that would allow a path end-point to identify the intermediate and
   end-points of the path.  This function would be used in on-demand
   mode.  Normally, this path will be used for bidirectional PW, LSP,
   and sections, however, unidirectional paths may be supported only if
   a return path exists.

3.3.1.  Documents for Route Tracing

   The [Demand CV] document that specifies the LSP-Ping enhancements for
   MPLS-TP on-demand Connectivity Verification includes information on
   the use of LSP-Ping for route tracing of a MPLS-TP transport path.

3.4.  Alarm Reporting

   Alarm Reporting is a function used by an intermediate point of a
   path, that becomes aware of a fault on the path, to report to the
   end-points of the path.  [MPLS-TP OAM Frwk] states that this may
   occur as a result of a defect condition discovered at a server sub-
   layer.  This generates an Alarm Indication Signal (AIS) that
   continues until the fault is cleared.  The consequent action of this
   function is detailed in [MPLS-TP OAM Frwk].

3.4.1.  Documents for Alarm Reporting

   MPLS-TP defines a new protocol to address this functionality that is
   documented in [Fault Mng].  This protocol uses all of the basic
   mechanisms detailed in Section 2.

3.5.  Lock Reporting

   Lock reporting, defined in [MPLS-TP OAM Reqs], is similar to the
   Alarm Reporting function described above.  It is used by an
   intermediate point to notify the end points of a transport path that
   an administrative lock condition exists for this transport path.

3.5.1.  Documents for Lock Reporting

   MPLS-TP defines a new protocol to address this functionality that is
   documented in [Fault Mng].  This protocol uses all of the basic
   mechanisms detailed in Section 2.

3.6.  Diagnostic

   The [MPLS-TP OAM Reqs] indicates that there is need to provide a OAM
   function that would enable conducting different diagnostic tests on a
   PW, LSP, or Section.  The [MPLS-TP OAM Frwk] provides two types of
   specific tests to be used through this functionality:

   o  Throughput Estimation - allowing the provider to verify the
      bandwidth/throughput of a transport path.  This is an out-of-
      service tool, that uses special packets of varying sizes to test
      the actual bandwidth and/or throughput of the path.

   o  Data-plane loopback - this out-of-service tool that causes all
      traffic that reaches the target node, either a MEP or MIP, to be
      looped back to the originating MEP.  For targeting MIPs, a
      corouted bi-directional path is required.

3.6.1.  Documents for Diagnostic Testing

   These diagnostic functions are being defined in a merge of existing
   separate individual drafts.  The merged document will define a new
   G-ACH based protocol message that addresses the Throughput Estimation
   tool, and also provide various flavors of loopback functionality.

3.7.  Lock Instruct

   The Lock Instruct function is an administrative control tool that
   allows a path end-point to instruct its peer end-point to lock the
   path.  The tool is necessary to support single-side provisioning for
   administrative locking, according to . [MPLS-TP OAM Frwk].  This
   function is used on-

3.7.1. on-demand.

3.6.1.  Documents for Lock Instruct

   Work is being done on a

   The [LiLoopback] document that will specify describes the details of a new ACH based
   protocol format for this tool.

3.8. functionality.

3.7.  Client Failure Indication

   Client Failure Indication (CFI) is defined in [MPLS-TP OAM Reqs] to
   allow the propagation information from one edge of the network to the
   other.  The information concerns a defect to a client, in the case
   that the client does not support alarm notification.


3.7.1.  Documents for CFI


   A new ACH-based protocol is being done on a document described in [MPLS-TP CSF] that will specify addresses
   the new ACH based
   protocol format functionality defined for this tool.

3.9. client failure indication.

3.8.  Packet Loss Measurement

   Packet Loss Measurement is required, by [MPLS-TP OAM Reqs] to provide
   a quantification of the packet loss ratio on a transport path.  This
   is the ratio of the number of user packets lost to the total number
   of user packets during a defined time interval.  To employ this
   function, [MPLS-TP OAM Frwk] defines that the two end-points of the
   transport path should exchange counters of messages transmitted and
   received within a time period bounded by loss-measurement messages.
   The framework warns that there may be small errors in the computation
   that result from various issues.


3.8.1.  Documents for Packet Loss Measurement

   The [Loss-Delay] document describes the protocol formats and
   procedures for using the tool.  The tool logic is based on the
   behavior of the parallel function described in [Y.1731].


3.9.  Packet Delay Measurement

   Packet Delay Measurement is a function that is used to measure one-
   way or two-way delay of a packet transmission between a pair of the
   end-points of a path (PW, LSP, or Section), as described in [MPLS-TP
   OAM Reqs].  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 last bit of that packet by the destination

   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.

   [MPLS-TP OAM Frwk] describes how the tool could be performed (both in
   proactive and on-demand modes) for either one-way or two-way
   measurement.  However, it warns that the one-way delay option
   requires precise time synchronization between the end-points.


3.9.1.  Documents for Delay Measurement

   The [Loss-Delay] document describes the protocol formats and
   procedures for using the tool.  The tool logic is based on the
   behavior of the parallel function described in [Y.1731].

4.  MPLS-TP OAM documents guide

   The complete MPLS-TP OAM protocol suite is covered by a small set of
   existing IETF documents.  This set of documents may be expanded in
   the future to cover additional OAM functionality. in order, to allow
   the reader to understand this set of documents a cross-reference of
   the existing documents for the initial phase of the specification of
   MPLS based transport networks is provided.

   [MPLS G-ACH] provides a specification of the basic structure of
   protocol messages for in-band data plane OAM in an MPLS environment.

   [MPLS TP Idents] provides definitions of different formats that may
   be used within OAM protocol messages to identify the network elements
   of a MPLS based transport network.

   [Pro CC-V] addresses the requirements for proactive use of Continuity
   Check, Connectivity Verification, and Remote Defect Indication
   functionality for MPLS transport networks.

   [Demand CV] addresses the requirements for activation of the
   Connectivity Verification functionality between endpoints or between
   an endpoint and intermediate point of a monitored domain of a
   transport path.

   [Fault Mng] specifies protocol messages that support the
   functionality required to support Alarm Indication Signal and Lock
   Reporting required for MPLS transport networks.

   [MPLS-TP CSF] addresses the requirements to support a Client Signal
   Fail indication by clients that are being emulated by the MPLS
   transport services.

   [LiLoopback] specifies protocol messages that support the
   functionality required for the Lock Instruct command and activation
   of the Loopback functionality for transport paths in MPLS networks.

   [Loss-Delay] addresses the requirements for performance measurement
   functionality for MPLS transport networks.  The protocol defined
   supports both loss and delay measurement functions for the transport

5.  IANA Considerations

   This document makes no request of IANA.

   Note to RFC Editor: this section may be removed on publication as an


6.  Security Considerations

   This document does not by itself raise any particular security

6.  Security considerations for each function in the OAM
   tool-set need to be documented in the document that specifies the
   particular functionality.

7.  Acknowledgements

   The editors wish to thank the MPLS-TP Design Team members, from both
   the IETF and ITU-T leadership teams, in formulating the
   recommendations documented here.  In particular, we would like to
   thank Loa Andersson, Huub van Helvoort, and the Area Directors for
   their suggestions and enhancements to the text.

7.  Informative

8.  Normative References

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

   [PW ACH]   Bryant, S., Swallow, G., Martini, L., and D. McPherson,
              "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for
              Use over an MPLS PSN", RFC 4385, February 2006.

              Katz, D. and D. Ward, "Bidirectional Forwarding
              Detection", RFC 5880, February 2009.

              Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow,
              "BFD For MPLS LSPs", RFC 5884, June 2008.

   [MPLS TP Idents]
              Bocci, M. and G. Swallow, "MPLS-TP Identifiers",
              ID draft-ietf-mpls-tp-identifiers-01.txt, March 2010.

   [Pro CC-V]
              Allan, D. and G. Swallow, "Proactive Connection
              Verification, Continuity Check and Remote Defect
              indication for MPLS Transport Profile",
              ID draft-ietf-mpls-tp-cc-cv-rdi-00.txt, June 2010.

   [Demand CV]
              Bahadur, N., Aggarwal, R., Boutros, S., and E. Gray, "MPLS
              on-demand Connectivity Verification, Route Tracing and
              Adjacency Verification",
              ID draft-ietf-mpls-tp-on-demand-cv-00, June 2010.

   [MPLS-TP OAM Reqs]
              Vigoureux, M., Betts, M., and D. Ward, "Requirements for
              OAM in MPLS Transport Networks",
              ID draft-ietf-mpls-tp-oam-requirements-05, April 2009.

   [MPLS-TP OAM Frwk]
              Busi, I., Niven-Jenkins, B., and D. Allan, "MPLS-TP OAM
              Framework and Overview",
              ID draft-ietf-mpls-tp-oam-framework-07, July 2010.

   [MPLS-TP Reqs]
              Niven-Jenkins, B., Nadeau, T., and C. Pignataro,
              "Requirements for the Trasport Transport Profile of MPLS",
              ID draft-ietf-mpls-tp-requirements-06, April 2009.

              Bocci, M., Bryant, S., and M. Vigoureux, "MPLS Generic
              Associated Channel", RFC 5586, June 2009.

              Boutros, S., Bryant, S., Sivabalan, S., Swallow, G., and
              D. Ward, "Definition of ACH TLV Structure",
              ID draft-ietf-mpls-tp-ach-tlv-00, June 2009.

   [Fault Mng]
              Swallow, G., Fulignoli, A., and M. Vigoureux, "MPLS Fault
              Management OAM", ID draft-ietf-mpls-tp-fault-00,
              March 2010.

              Boutros, S., Sivabalan, S., Aggarwal, R., Vigoureux, M.,
              and X. Dai, "MPLS Transport Profile Lock Instruct and
              Loopback Functions", ID draft-ietf-mpls-tp-li-lb-00,
              September 2010.

              He, J., LI, H., and E. Bellagamba, "Indication of Client
              Failure in MPLS-TP", ID draft-he-mpls-tp-csf-00,
              July 2010.

              Frost, D. and S. Bryant, "Packet Loss and Delay
              Measurement for the MPLS Transport Profile",
              ID draft-frost-mpls-tp-loss-delay-00, draft-ietf-mpls-tp-loss-delay-00, April 2010.

   [Y.1731]   International Telecommunications Union - Standardization,
              "OAM functions and mechanisms for Ethernet based
              networks", ITU Y.1731, May 2006.

Authors' Addresses

   Nurit Sprecher
   Nokia Siemens Networks
   3 Hanagar St. Neve Ne'eman B
   Hod Hasharon,   45241

   Elisa Bellagamba
   6 Farogatan St
   Stockholm,   164 40

   Phone: +46 761440785

   Yaacov Weingarten
   Nokia Siemens Networks
   3 Hanagar St. Neve Ne'eman B
   Hod Hasharon,   45241

   Phone: +972-9-775 1827