Network Working Group                                        N. Sprecher, Ed. Sprecher
Internet-Draft                                    Nokia Siemens Networks
Intended status: Informational                      H. van Helvoort, Ed.
Expires: September 5, 2010                                        Huawei                             E. Bellagamba
Expires: January 5, 2011                                        Ericsson
                                                           Y. Weingarten
                                                  Nokia Siemens Networks
                                                           March
                                                            July 4, 2010

                          MPLS-TP OAM Analysis
                 draft-ietf-mpls-tp-oam-analysis-01.txt
                 draft-ietf-mpls-tp-oam-analysis-02.txt

Abstract

   This document analyzes the set of requirements for Operations,
   Administration, and Maintenance (OAM) for the Transport Profile of
   MPLS(MPLS-TP) as defined in [MPLS-TP OAM Reqs], to evaluate whether
   existing OAM tools (either from the current MPLS toolset or from the
   ITU-T documents) can be applied to these requirements.  Eventually,
   the purpose of the document is to recommend which of the existing
   tools should be extended and what new tools should be defined to
   support map the set of OAM requirements for MPLS-TP.  This document
   reports the conclusions functions to a set
   of tools based on the MPLS-TP design team discussions
   concerning the MPLS-TP existing OAM tools at IETF75. toolset.

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. (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts.
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   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 September January 5, 2010. 2011.

Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

   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
     1.3.  Contributing Authors . . . . . . . . . . . . . . . . . . .  5
     1.4.  LSP Ping  Acronyms . . . . . . . . . . . . . . . . . . . . . . . . .  5
     1.5.  MPLS BFD . . .
   2.  Basic OAM infrastructure functionality . . . . . . . . . . . .  5
   3.  MPLS-TP OAM Functions  . . . . . . . . . .  6
     1.6.  PW VCCV . . . . . . . . . .  6
     3.1.  Continuity Check and Connectivity Verification . . . . . .  7
       3.1.1.  Documents for CC-V tools . . . . . . . . .  7
     1.7.  IETF Performance Measurement . . . . . .  7
     3.2.  Remote Defect Indication . . . . . . . . .  8
     1.8.  ITU Recommendation Y.1731 . . . . . . . .  7
       3.2.1.  Documents for RDI  . . . . . . . .  9
     1.9.  Acronyms . . . . . . . . . .  7
     3.3.  Route Tracing  . . . . . . . . . . . . . . . 11
   2.  Architectural requirements and general principles of
       operation . . . . . . .  7
       3.3.1.  Documents for Route Tracing  . . . . . . . . . . . . .  8
     3.4.  Alarm Reporting  . . . . . . 11
     2.1.  Architectural and Principles of Operation -
           Recommendations and Guidelines . . . . . . . . . . . . . . 13
   3.  MPLS-TP OAM Functions .  8
       3.4.1.  Documents for Alarm Reporting  . . . . . . . . . . . .  8
     3.5.  Lock Reporting . . . . . . . 15
     3.1.  Continuity Check and Connectivity Verification . . . . . . 15
       3.1.1.  Existing tools . . . . . . . . .  8
       3.5.1.  Documents for Lock Reporting . . . . . . . . . . . 15
       3.1.2.  Gap analysis . .  8
     3.6.  Diagnostic . . . . . . . . . . . . . . . . . . . 16
       3.1.3.  Recommendations and Guidelines . . . . .  8
       3.6.1.  Documents for Diagnostic Testing . . . . . . . 17
     3.2.  Alarm Reporting . . . .  9
     3.7.  Lock Instruct  . . . . . . . . . . . . . . . . . 17
       3.2.1.  Existing tools . . . . .  9
       3.7.1.  Documents for Lock Instruct  . . . . . . . . . . . . .  9
     3.8.  Client Failure Indication  . . 17
       3.2.2.  Recommendations and Guidelines . . . . . . . . . . . . 17
     3.3.  Diagnostic . .  9
       3.8.1.  Documents for CFI  . . . . . . . . . . . . . . . . . .  9
     3.9.  Packet Loss Measurement  . . . . 17
       3.3.1.  Existing tools . . . . . . . . . . . . .  9
       3.9.1.  Documents for Packet Loss Measurement  . . . . . . . 17
       3.3.2.  Recommendations and Guidelines . 10
     3.10. Packet Delay Measurement . . . . . . . . . . . 18
     3.4.  Route Tracing . . . . . . 10
       3.10.1. Documents for Delay Measurement  . . . . . . . . . . . 10
   4.  IANA Considerations  . . . . . 18
       3.4.1.  Existing tools . . . . . . . . . . . . . . . . 10
   5.  Security Considerations  . . . . 18
       3.4.2.  Recommendations and Guidelines . . . . . . . . . . . . 18
     3.5.  Loopback tool . . . 10
   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . 18
     3.6.  Lock Instruct  . . . . . . . . . . . . . . . . . . . . . . 18
       3.6.1.  Existing tools . . . . . . . . . . . . . . . . . . . . 19
       3.6.2.  Recommendations and Guidelines . . . . . . . . . . . . 19
     3.7.  Lock Reporting . . . . . . . . . . . . . . . . . . . . . . 19
       3.7.1.  Existing tools . . . . . . . . . . . . . . . . . . . . 19
       3.7.2.  Recommendations and Guidelines . . . . . 11
   7.  Informative References . . . . . . . 19
     3.8.  Remote Defect Indication . . . . . . . . . . . . . 11
   Authors' Addresses . . . . 19
       3.8.1.  Existing tools . . . . . . . . . . . . . . . . . . . . 19
       3.8.2.  Recommendations 12

1.  Introduction

1.1.  Scope

   OAM (Operations, Administration, and Guidelines . . . . . . . . . . . . 20
     3.9.  Client Failure Indication  . . . . . . . . . . . . . . . . 20
       3.9.1.  Existing tools . . . . . . . . . . . . . . . . . . . . 20
       3.9.2.  Recommendations Maintenance) plays a significant
   role in carrier networks, providing methods for fault management and Guidelines . . . . . . . . . . . . 20
     3.10. Packet Loss Measurement  . . . . . . . . . . . . . . . . . 20
       3.10.1. Existing tools . . . . . . . . . . . . . . . . . . . . 21
       3.10.2. Recommendations
   performance monitoring in both the transport and Guidelines . . . . . . . . . . . . 21
     3.11. Packet Delay Measurement . . . . . . . . . . . . . . . . . 21
       3.11.1. Existing tools . . . . . . . . . . . . . . . . . . . . 22
       3.11.2. Recommendations and Guidelines . . . . . . . . . . . . 22
   4.  Recommendations  . . . . . . . . . . . . . . . . . . . . . . . 22
   5.  MPLS-TP OAM Documents Organization . . . . . . . . . . . . . . 24
     5.1.  Document 1: "Encapsulation of BFD and LspPing in ACH"  . . 24
     5.2.  Document 2: "Extended BFD" . . . . . . . . . . . . . . . . 25
     5.3.  Document 3: "Extended LSP Ping"  . . . . . . . . . . . . . 25
     5.4.  Document 4: "Extensions for Lock Instruct" . . . . . . . . 26
     5.5.  Document 5: "AIS and Lock Reporting" . . . . . . . . . . . 26
     5.6.  Document 6: "Client Fault Indication"  . . . . . . . . . . 26
     5.7.  Document 7: "Packet Loss"  . . . . . . . . . . . . . . . . 27
     5.8.  Document 8: "Packet Delay" . . . . . . . . . . . . . . . . 27
     5.9.  Document 9: "Diagnostic Tests" . . . . . . . . . . . . . . 27
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 27
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 27
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27
   Appendix A.     Proactive CC and CV BFD tool analysis  . . . . . . 27
   Appendix A.1.   Possible Solution  . . . . . . . . . . . . . . . . 28
   Appendix A.2.   Backward compatibility . . . . . . . . . . . . . . 29
   Appendix A.3.   Definition of BFDv2  . . . . . . . . . . . . . . . 29
   Appendix A.3.1. New semantic for Discriminator fields  . . . . . . 29
   Appendix A.3.2. New MEP ID field . . . . . . . . . . . . . . . . . 30
   Appendix A.4.   Two different ACH encapsulation of OAM tool  . . . 30
   Appendix A.4.1. New tool based on current BFD  . . . . . . . . . . 31
   Appendix A.4.2. New tool based on the extended BFD . . . . . . . . 31
   Appendix A.4.3. New tool like Y.1731 CCM . . . . . . . . . . . . . 31
   Appendix A.5.   Remote Defect Indication . . . . . . . . . . . . . 31
   Appendix A.6.   Point to Multipoint transport paths  . . . . . . . 32
   Appendix A.7.   Security Considerations  . . . . . . . . . . . . . 32
   9.  Informative References . . . . . . . . . . . . . . . . . . . . 32
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34

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 Label Switched Paths (LSPs) (network
   infrastructure) and Pseudowires (PWs) (services).

   The purpose of this document is to analyze the OAM requirements and
   evaluate whether existing OAM tools defined for MPLS can be used to
   meet the requirements, identify which tools need to be extended to
   comply with the requirements, and which new tools need to be defined.
   We also take the ITU-T OAM toolset, as defined in [Y.1731], as a
   candidate to base these new tools upon.  The existing tools that are
   evaluated include LSP Ping (defined in [LSP Ping]), MPLS Bi-
   directional Forwarding Detection (BFD) (defined in [BASE BFD]) and
   Virtual Circuit Connectivity Verification (VCCV) (defined in [PW
   VCCV] and [VCCV BFD]), and the ITU-T OAM toolset defined in [Y.1731].

   This document reports the conclusions of the MPLS-TP design team
   discussions on the MPLS-TP OAM tools at IETF75 and the guidelines
   that were agreed.  The guidelines refer to a set of existing OAM
   tools that need to be enhanced to fully support the MPLS-TP OAM
   requirements and identify new tools that need to be defined.  The
   organizational structure of the documents on MPLS-TP OAM tools was
   also discussed and agreed at IETF75 and is described later in this
   document.

1.2.  Organization of the document

   Sections 1.4 - 1.8 provide an overview of the existing MPLS tools.

   Section 2 of the document analyzes the requirements that are
   documented in [MPLS-TP OAM Reqs] and provides basic principles of
   operation for the OAM functionality that is required.

   Section 3 evaluates which existing tools can provide coverage for the
   different OAM functions that are required to support MPLS-TP.

   The recommendations are summarized in section 4, and reflect the
   guidelines which were agreed by the MPLS-TP design team during the
   meetings at IETF 75.  These guidelines relate to the functionality
   could be covered by the existing toolset and what extensions or new
   tools would be needed in order to provide full coverage of the OAM
   functionality for MPLS-TP.

   The OAM tools for MPLS-TP OAM will be defined in a set of documents.
   Section 5 describes the organization of this set of documents as
   agreed by the MPLS-TP design team at IETF75.

1.3.  Contributing Authors

   Yaakov Stein (Rad), Annamaria Fulignoli (Ericsson), Italo Busi
   (Alcatel Lucent)

1.4.  LSP Ping

   LSP Ping is a variation of ICMP Ping and traceroute [ICMP] adapted to
   the needs of MPLS LSP.  Forwarding, of the LSP Ping packets, is based
   upon the LSP Label and label stack, in order to guarantee that the
   echo messages are switched in-band (i.e. over the same data route) of
   the LSP.  However, it should be noted that the messages are
   transmitted using IP/UDP encapsulation and IP addresses in the 127/8
   (loopback) range.  The use of the loopback range guarantees that the
   LSP Ping messages will be terminated, by a loss of connectivity or
   inability to continue on the path, without being transmitted beyond
   the LSP.  For a bi-directional LSP (either associated or co-routed)
   the return message of the LSP Ping could be sent on the return LSP.
   For unidirectional LSPs and in some case for bi-directional LSPs, the
   return message may be sent using IP forwarding to the IP address of
   the LSP ingress node.

   LSP Ping extends the basic ICMP Ping operation (of data-plane
   connectivity and continuity check) with functionality to verify data-
   plane vs. control-plane consistency for a Forwarding Equivalence
   Class (FEC) and also Maximum Transmission Unit (MTU) problems.  The
   traceroute functionality may be used to isolate and localize the MPLS
   faults, using the Time-to-live (TTL) indicator to incrementally
   identify the sub-path of the LSP that is successfully traversed
   before the faulty link or node.

   As mentioned above, LSP Ping requires the presence of the MPLS
   control plane when verifying the consistency of the data-plane
   against the control-plane.  However, LSP Ping is not dependent on the
   MPLS control-plane for its operation, i.e. even though the
   propagation of the LSP label may be performed over the control-plane
   via the Label Distribution Protocol (LDP).

   It should be noted that LSP Ping does support unique identification
   of the LSP within an addressing domain.  The identification is
   checked using the full FEC identification.  LSP Ping is easily
   extensible to include additional information needed to support new
   functionality, by use of Type-Length-Value (TLV) constructs.

   LSP Ping can be activated both in on-demand and pro-active
   (asynchronous) modes, as defined in [MPLS-TP OAM Reqs].

   [P2MP LSP Ping] clarifies the applicability of LSP Ping to MPLS P2MP
   LSPs, and extends the techniques and mechanisms of LSP Ping to the
   MPLS P2MP environment.

   [MPLS LSP Ping] extends LSP Ping to operate over MPLS tunnels or for
   a stitched LSP.

   As pointed out above, TTL exhaust is the method used to terminate
   flows at intermediate LSRs.  This is used as part of the traceroute
   of a path and to locate a problem that was discovered previously.

   Some of the drawbacks identified with LSP Ping include - LSP Ping is
   considered to be computational intensive as pointed out in [MPLS
   BFD].  The applicability for a pro-active mode of operation is
   analyzed in the sections below.  Use of the loopback address range
   (to protect against leakage outside the LSP) assumes that all of the
   intermediate nodes support some IP functionality.  Note that ECMP is
   not supported in MPLS-TP, therefore its implication on OAM
   capabilities is not analyzed in this document.

1.5.  MPLS BFD

   BFD (Bidirectional Forwarding Detection) [BASE BFD] is a mechanism
   that is defined for fast fault detection for point-to-point
   connections.  BFD defines a simple packet that may be transmitted
   over any protocol, dependent on the application that is employing the
   mechanism.  BFD is dependent upon creation of a session that is
   agreed upon by both ends of the link (which may be a single link,
   LSP, etc.) that is being checked.  The session is assigned a separate
   identifier by each end of the path being monitored.  This session
   identifier is by nature only unique within the context of node that
   assigned it.  As part of the session creation, the end-points
   negotiate an agreed transmission rate for the BFD packets.  BFD
   supports an echo function to check the continuity, and verify the
   reachability of the desired destination.  BFD does not support
   neither a discovery mechanism nor a traceroute capability for fault
   localization, these must be provided by use of other mechanisms.  The
   BFD packets support authentication between the routers being checked.

   BFD can be used in pro-active (asynchronous) and on-demand modes, as
   defined in [MPLS-TP OAM Reqs], of operation.

   [MPLS BFD] defines the use of BFD for P2P LSP end-points and is used
   to verify data-plane continuity.  It uses a simple hello protocol
   which can be easily implemented in hardware.  The end-points of the
   LSP exchange hello packets at negotiated regular intervals and an
   end-point is declared down when expected hello packets do not show
   up.  Failures in each direction can be monitored independently using
   the same BFD session.  The use of the BFD echo function and on-demand
   activation are outside the scope of the MPLS BFD specification.

   The BFD session mechanism requires an additional (external) mechanism
   to bootstrap and bind the session to a particular LSP or FEC.  LSP
   Ping is designated by [MPLS BFD] as the bootstrap mechanism for the
   BFD session in an MPLS environment.  The implication is that the
   session establishment BFD messages for MPLS are transmitted using a
   IP/UDP encapsulation.

   In order to be able to identify certain extreme cases of mis-
   connectivity, it is necessary that each managed connection have its
   own unique identifiers.  BFD uses Discriminator values to identify
   the connection being verified, at both ends of the path.  These
   discriminator values are set by each end-node to be unique only in
   the context of that node.  This limited scope of uniqueness would not
   identify a misconnection of crossing paths that could assign the same
   discriminators to the different sessions.

1.6.  PW VCCV

   [PW VCCV] provides end-to-end fault detection and diagnostics for PWs
   (regardless of the underlying tunneling technology).  The VCCV
   switching function provides a control channel associated with each PW
   (based on the PW Associated Channel Header (ACH) which is defined in
   [PW ACH]), and allows sending OAM packets in-band with PW data (using
   CC Type 1: In-band VCCV)

   VCCV currently supports the following OAM mechanisms: ICMP Ping, LSP
   Ping, and BFD.  ICMP and LSP Ping are IP encapsulated before being
   sent over the PW ACH.  BFD for VCCV supports two modes of
   encapsulation - either IP/UDP encapsulated (with IP/UDP header) or
   PW-ACH encapsulated (with no IP/UDP header) and provides support to
   signal the AC status.  The use of the VCCV control channel provides
   the context, based on the MPLS-PW label, required to bind and
   bootstrap the BFD session to a particular pseudo wire (FEC),
   eliminating the need to exchange Discriminator values.

   VCCV consists of two components: (1) signaled component to
   communicate VCCV capabilities as part of VC label, and (2) switching
   component to cause the PW payload to be treated as a control packet.

   VCCV is not directly dependent upon the presence of a control plane.
   The VCCV capability negotiation may be performed as part of the PW
   signaling when LDP is used.  In case of manual configuration of the
   PW, it is the responsibility of the operator to set consistent
   options at both ends.

1.7.  IETF Performance Measurement

   OWAMP (One-Way Active Measurement Protocol) [RFC4656] enables
   measurement of unidirectional characteristics of IP networks, such as
   packet loss and one-way delay.  For its proper operation OWAMP
   requires accurate time of day setting at its end points.

   TWAMP (Two-Way Active Measurement Protocol) [RFC5357] is a similar
   protocol that enables measurement of two-way (round trip)
   characteristics.  TWAMP does not require accurate time of day, and,
   furthermore, allows the use of a simple session reflector, making it
   an attractive alternative to OWAMP.

   Both OWAMP and TWAMP consist of inter-related control and test
   protocols, although "TWAMP Light" eliminates the need for the control
   protocol.

   OWAMP and TWAMP control protocols run over TCP, while the test
   protocols run over UDP.  The purpose of the control protocols is to
   initiate, start, and stop test sessions, and for OWAMP to fetch
   results.  The test protocols introduce test packets (which contain
   sequence numbers and timestamps) along the IP path under test
   according to a schedule, and record statistics of packet arrival.
   Multiple sessions may be simultaneously defined, each with a session
   identifier, and defining the number of packets to be sent, the amount
   of padding to be added (and thus the packet size), the start time,
   and the send schedule (which can be either a constant time between
   test packets or exponentially distributed pseudo-random).  Statistics
   recorded conform to the relevant IPPM RFCs.

   OWAMP defines the following logical roles: Session-Sender, Session-
   Receiver, Server, Control-Client, and Fetch-Client.  The Session-
   Sender originates test traffic that is received by the Session-
   receiver.  The Server configures and manages the session, as well as
   returning the results.  The Control-Client initiates requests for
   test sessions, triggers their start, and may trigger their
   termination.  The Fetch-Client requests the results of a completed
   session.  Multiple roles may be combined in a single host - for
   example, one host may play the roles of Control-Client, Fetch-Client,
   and Session-Sender, and a second playing the roles of Server and
   Session-Receiver.

   In a typical OWAMP session the Control-Client establishes a TCP
   connection to port 861 of the Server, which responds with a server
   greeting message indicating supported security/integrity modes.  The
   Control-Client responds with the chosen communications mode and the
   Server accepts the modes.  The Control-Client then requests and fully
   describes a test session to which the Server responds with its
   acceptance and supporting information.  More than one test session
   may be requested with additional messages.  The Control-Client then
   starts a test session and the Server acknowledges.  The Session-
   Sender then sends test packets with pseudorandom padding to the
   Session-Receiver until the session is complete or until the Control-
   Client stops the session.  Once finished, the Fetch-Client sends a
   fetch request to the server, which responds with an acknowledgement
   and immediately thereafter the result data.

   TWAMP defines the following logical roles: session-sender, session-
   reflector, server, and control-client.  These are similar to the
   OWAMP roles, except that the Session-Reflector does not collect any
   packet information, and there is no need for a Fetch-Client.

   In a typical TWAMP session the Control-Client establishes a TCP
   connection to port 862 of the Server, and mode is negotiated as in
   OWAMP.  The Control-Client then requests sessions and starts them.
   The Session-Sender sends test packets with pseudorandom padding to
   the Session-Reflector which returns them with insertion of
   timestamps.

   OWAMP and TWAMP test traffic is designed with security in mind.  Test
   packets are hard to detect because they are simply UDP streams
   between negotiated port numbers, with potentially nothing static in
   the packets.  OWAMP and TWAMP also include optional authentication
   and encryption for both control and test packets.

1.8.  ITU Recommendation Y.1731

   [Y.1731] specifies a set of OAM procedures and related packet data
   unit (PDU) formats that meet the transport network requirements for
   OAM.  These PDU and procedures address similar requirements to those
   outlined in [MPLS-TP OAM Reqs].

   The PDU and procedures defined in [Y.1731] are described for an
   Ethernet environment, with the appropriate encapsulation for that
   environment.  However, the actual PDU formats are technology agnostic
   and could be carried over different encapsulations, e.g.  VCCV
   control channel.  The OAM procedures, likewise, could be supported by
   MPLS-TP nodes just as they are supported by Ethernet nodes.

   [Y.1731] describes procedures to support the following OAM functions:

   o  Connectivity and Continuity Monitoring - for pro-active mode end-
      to-end checking

   o  Loopback functionality - to verify connectivity to intermediate
      nodes in an on-demand mode

   o  Link Trace - provides information on the intermediate nodes of the
      path being monitored, may be used for fault localization.  This is
      activated in an on-demand mode.

   o  Alarm Indication Signaling - for alarm suppression in case of
      faults that are detected at the server layer, activated pro-
      actively.

   o  Remote Defect Indication - as part of the Connectivity and
      Continuity Monitoring packets, performed pro-actively

   o  Locked Signal - for alarm suppression in case of administrative
      locking at the server layer.  This function is performed pro-
      actively.

   o  Performance monitoring - including measurement of packet delays
      both uni and bi-directional (on-demand), measurement of the ratio
      of lost packets (pro-active), the effective bandwidth that is
      supported without packet loss, and throughput measurement.

   The PDU defined in [Y.1731] includes various information elements
   (fields) including information on the MEG-Level, etc.  Addressing of
   the PDU as defined in [Y.1731] is based on the MAC Address of the
   nodes, which would need to be adjusted to support other addressing
   schemes.  The addressing information is carried in <Type, Length,
   Value> (TLV) fields that follow the actual PDU.  In the LBM PDU the
   MAC address is used to identify the MIP to which the message is
   intended

1.9.  Acronyms

   This draft uses the following acronyms:

   AC      Attachment Circuit
   ACH     Associated Channel Header
   BFD     Bidirectional Forwarding Detection
   CC-V    Continuity Check and Connectivity Verification
   FEC     Forwarding Equivalence Class
   G-ACH   Generic Associated Channel Header
   LDP     Label Distribution Protocol
   LSP     Label Switched Path
   MPLS-TP Transport Profile for MPLS
   OAM     Operations, Administration, and Maintenance
   OWAMP   One Way Active Measurement Protocol
   PDU     Packet Data Unit
   PW      Pseudowire
   RDI     Remote Defect Indication
   SLA     Service Level Agreement
   TLV     Type, Length, Value
   TTL     Time-to-live
   TWAMP   Two Way Active Measurement Protocol
   VCCV    Virtual Circuit Connectivity Verification

2.  Architectural requirements and general principles of operation

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

   o  [MPLS-TP OAM Reqs] requires that OAM mechanisms in MPLS-TP are
      independent of the transmission media and of the client service
      being emulated by the PW.  The existing tools comply with this
      requirement.

   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 MUST be able to operate by
      relying on the IP routing and forwarding capabilities.  All of the
      existing MPLS tools (i.e.  LSP Ping, VCCV Ping, MPLS BFD, and VCCV
      BFD) can support this functionality.  The Y.1731 toolset does not
      specifically support this functionality, but rather relies on
      underlying technologies for forwarding.  The forwarding could also
      be supported over IP, e.g. by using a VCCV extension.  Note that
      some of the MPLS-TP tools such as Alarm Report are very transport
      oriented and may not support IP functionality.

   o  [MPLS-TP OAM Reqs] requires that MPLS-TP OAM MUST be able to
      operate without IP functionality and without relying on control
      and/or management planes.  It is required that OAM functionality
      MUST NOT be dependent on IP routing and forwarding capabilities.
      Except for the LSP Ping operation of verifying the data-plane vs.
      the control-plane, the existing tools do not rely on control
      and/or management plane, however the following should be observed
      regarding the reliance on IP functionality:

      *  LSP Ping, VCCV Ping, and MPLS BFD make use of IP header
         (UDP/IP) and do not completely comply with the requirement.  In
         the on-demand mode, LSP Ping also may use IP forwarding to
         reply back to the source router.  This dependence on IP, has
         further implications concerning the use of LSP Ping as the
         bootstrap mechanism for BFD for MPLS.  There are extensions to
         LSP-Ping that are under discussion that allow LSP-Ping to
         restrict replies to the backside of a bidirectional LSP.

      *  VCCV BFD supports the use of PW-ACH encapsulated BFD sessions
         for PWs and can comply with the requirement.

      *  Y.1731 PDU are technology agnostic and thereby not dependent on
         IP functionality.  These PDU could be carried by VCCV or G-ACH
         control channels.

   o  [MPLS-TP OAM Reqs] requires that OAM tools for fault management do
      not rely on user traffic, and the existing MPLS OAM tools and
      Y.1731 already comply with this requirement.

   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.

      *  For PWs, VCCV provides a control channel that can be associated
         with each PW which allows sending OAM packets in band of PWs
         and allow the receiving end-point to intercept, interpret, and
         process them locally as OAM messages.  VCCV defines different
         VCCV Connectivity Verification Types for MPLS (like ICMP Ping,
         LSP Ping and IP/UDP encapsulated BFD and PW-ACH encapsulated
         BFD).

      *  Currently there is no distinct OAM payload identifier in MPLS
         shim.  BFD and LSP Ping packets for LSPs are carried over
         UDP/IP and are addressed to the loopback address range.  The
         router at the end-point intercepts, interprets, and processes
         the packets.  [MPLS G-ACH] generalizes the use of the PW ACH
         and enables provision of control channels at the MPLS LSP and
         sections levels.  This new mechanism would support carrying the
         existing MPLS OAM messages or the Y.1731 messages at the LSP
         and the section levels to be transmitted over the G-ACH.

   o  [MPLS-TP OAM Reqs] requires that the MPLS-TP OAM mechanism allows
      the propagation of AC (Attachment Circuit) failures and their
      clearance across a MPLS-TP domain

      *  BFD for VCCV supports a mechanism for "Fault detection and
         AC/PW Fault status signaling."  This can be used for both IP/
         UDP encapsulated or PW-ACH encapsulated BFD sessions, i.e. by
         setting the appropriate VCCV Connectivity Verification
         Type.This mechanism could support this requirement.  Note that
         in the PWE3 WG there are two proposals regarding how to
         transmit the AC failures over an ACH that may be applicable to
         this requirement.

   o  [MPLS-TP OAM Reqs] requires a single OAM technology and consistent
      OAM capabilities for LSPs, PWs, and Sections.  The existing set of
      tools defines a different way of operating the OAM functions (e.g.
      LSP Ping to bootstrap MPLS BFD vs. VCCV).  Currently, the Y.1731
      functionality is defined for Ethernet paths, and the procedures
      could readily be redefined for the various MPLS-TP path concepts.

   o  [MPLS-TP OAM Reqs] requires allowing OAM packets to be directed to
      an intermediate point of a LSP/PW.  Technically, this could be
      supported by the proper setting of the TTL value.  It is also
      recommended to include the identifier of the intermediate point
      within the OAM message to allow the intermediate point to validate
      that the message is really intended for it.  The information can
      be included in an ACH-TLV according to the definitions in [MPLS-TP
      ACH TLV].  The applicability of such a solution needs to be
      examined per OAM function.  For details, see below.

   o  [MPLS-TP OAM Reqs] suggests that OAM messages MAY be
      authenticated.  BFD defines support for optional authentication
      fields using different authentication methods as defined in [BASE
      BFD].  Other tools should support this capability as well.  Y.1731
      functionality uses the identification of the path for
      authentication.  Authentication information could be included in
      an optional TLV field according to the definitions in [MPLS-TP ACH
      TLV] when not available in the OAM PDU.

2.1.  Architectural and Principles of Operation - Recommendations and
      Guidelines

   Based on the requirements analysis above, the following guidelines
   should be followed to create an OAM environment that could more fully
   support the requirements cited:

   o  Define a generalized addressing scheme that can also support
      unique identification of the monitored paths (or connections).

   o  Use G-ACH for LSP and section levels.

   o  Define architectural element that is based on LSP hierarchy to
      apply the mechanisms to segments and concatenated segments.

   o  Apply BFD to these new mechanisms using the control channel
      encapsulation, as defined above - allowing use of BFD for MPLS-TP
      independent of IP functionality.  This could be used to address
      the CC-V functionality, described below.

   o  Similarly, LSP Ping could be extended to use only the LSP path (in
      both directions) without IP Forwarding.  Addressing for PW can be
      included by using the VCCV mechanism.  LSP Ping could be used to
      address the CC-V, Route Tracing, RDI, and Lock/Alarm Reporting
      functionality cited in the requirements.

   o  The Y.1731 PDU set could be used as a basis for defining the
      information units to be transmitted over the G-ACH.  The actual
      procedures and addressing schemes would need to be adjusted for
      the MPLS-TP environment.

   o  Define a mechanism that could be used to idnetify an intermediate
      point of a path in a unique way, to support the maintenance
      functions.  This addressing should be flexible to allow support
      for different addressing schemes, and would supplement the TTL
      exception mechanism to allow an OAM packet to be intercepted by
      intermediate nodes.

   Creating these extensions/mechanisms would fulfill the following
   architectural requirements, mentioned above:

   o  Independence of IP forwarding and routing, when needed.

   o  OAM packets should be transmitted in-band.

   o  Support a single OAM technology for LSP, PW, and Sections.

   In addition, the following additional requirements can be satisfied:

   o  Provide the ability to carry other types of communications (e.g.,
      APS, Management Control Channel (MCC), Signaling Control Channel
      (SCC)), by defining new types of communication channels for PWs,
      Sections, and LSPs.

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

3.  MPLS-TP OAM Functions

   The following sections discuss the required OAM functions that were
   identified in [MPLS-TP OAM Reqs].

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 may be split into separate mechanisms.  Together they
   are used to detect loss of traffic continuity and misconnections
   between path end-points and are useful for applications like Fault
   Management, Performance Monitoring and Protection Switching, etc.  To
   guarantee that CC-V can identify misconnections from cross-
   connections it is necessary that the tool use network-wide unique
   identifiers for the path that is being checked in the session.

3.1.1.  Existing tools

   LSP Ping provides much of the functionality required for co-routed
   bidirectional LSPs.  As observed above, LSP Ping may be operated in
   both asynchronous and on-demand mode.  Addressing is based on the
   full FEC identification that provides a unique identifier, and the
   basic functionality only requires support for the loopback address
   range in each node on the LSP path.

   BFD defines functionality that can be used to support the pro-active
   OAM CC-V function when operated in the asynchronous mode.  However,
   the current definition of basic BFD is dependent on use of LSP Ping
   to bootstrap the BFD session.  Regarding the connectivity functional
   aspects, basic BFD has a limitation that it uses only locally unique
   (to each node) session identifiers.

   VCCV can be used to carry either LSP Ping or BFD packets that are not
   IP/UDP encapsulated for CC-V on a PW.  Note that PW termination/
   switching points use only locally unique (to each node) labels.  The
   PW label identifies the path uniquely only at the LSP level.

   Y.1731 provides functionality for all aspects of CC-V for an Ethernet
   environment, this could be translated for the MPLS-TP environment.
   The CCM PDU defined in [Y.1731] includes the ability to set the
   frequency of the messages that are transmitted, and provides for
   attaching the address of the path (in the Ethernet case - the MEG
   Level) and a sequencing number to verify that CCM messages were not
   dropped.

3.1.2.  Gap analysis

   LSP Ping could be used to cover the cases of co-routed bidirectional
   LSPs.  However, there is a certain amount of computational overhead
   involved with use of LSP Ping (as was observed in sec 1.1), the
   verification of the control-plane, and the need to support the
   loopback functionality at each intermediate node.  LSP Ping uses a
   fully qualified LSP identifier, and when used in conjunction with
   VCCV would use the PW label to identify the transport path.  LSP Ping
   can be extended to bypass the verification of the control plane

   BFD could be extended to fill the gaps indicated above.  The
   extension would include:

   o  A mechanism should be defined to carry BFD packets over LSP
      without reliance on IP functionality.

   o  A mechanism should be defined to bootstrap BFD sessions for MPLS
      that is not dependent on UDP.

   o  BFD needs to be used in conjunction with "globally" unique
      identifiers for the path or ME being checked to allow connectivity
      verfication support.  There are two possibilities, to allow BFD to
      support this new type of identifier -

      *  Change the semantics of the two Discriminator fields that exist
         in BFD and have each node select the ME unique identifier.
         This may have backward compatibility implications.

      *  Create a new optional field in the packet carrying the BFD that
         would identify the path being checked, in addition to the
         existing session identifiers.

   o  Extensions to BFD would be needed to cover P2MP connections.

   Use of the Y.1731 functionality is another option that could be
   considered.  The basic PDU for CCM includes (in the flags field) an
   indication of the frequency of the packets [eliminating the need to
   "negotiate" the frequency between the end-points], and also a flag
   used for RDI.  The procedure itself would need adaptation to comply
   with the MPLS environment.

   An additional option would be to create a new tool that would give
   coverage for both aspects of CC-V according to the requirements and
   the principles of operation (see section 2.1).  This option is less
   preferable.

3.1.3.  Recommendations and Guidelines

   Extend LSP Ping to fully support the on-demand Connectivity
   Verification function resolving the gaps described above.  Extend BFD
   to support proactive Continuity Check & Connectivity Verification
   (CC-V) resolving the gaps described above.

   Note that [MPLS BFD] defines a method for using BFD to provide
   verification of multipoint or multicast connectivity.

3.2.  Alarm Reporting

   Alarm Reporting is a function that is used by an intermediate point
   in a path to notify the end-points of the path of a fault or defect
   condition indirectly affecting that path.  Such information may be
   used by the endpoints, for example, to suppress alarms that may be
   generated by maintenance end-points of the path.  This function
   should also have the capability to differentiate an administrative
   lock from a failure condition at a different execution level.

3.2.1.  Existing tools

   There is no mechanism defined in the IETF to support this function.
   Y.1731 does define a PDU and procedure for this functionality.

3.2.2.  Recommendations and Guidelines

   Define a new tool and PDU to support Alarm Reporting.  The PDU should
   be transmitted over a G-ACH.  The frequency of transmision after the
   alarm is raised and the continued frequency until it is cleared
   should be indicated in the definition.

   Describe also how the Alarm Reporting functionality may be supported
   in the control-plane and management-plane.

3.3.  Diagnostic

   A diagnostic test is a function that is used between path end-points
   to verify bandwidth throughput, packet loss, bit errors, etc.  This
   is usually performed by sending packets of varying sizes at
   increasing rates (until the limits of the service level) to measure
   the actual utilization.

3.3.1.  Existing tools

   There is no mechanism defined in the IETF to support this function.
   [Y.1731] describes a function that is dependent on sending a series
   of TST packets (this is a PDU whose size can be varied) at differing
   frequencies.

3.3.2.  Recommendations and Guidelines

   Define a new tool and PDU to support Diagnostic.

3.4.  Route Tracing

   Functionality of route determination is used to determine the route
   of a connection across the MPLS transport network.  [MPLS-TP OAM
   Reqs] defines that this functionality MUST allow a path end-point to
   identify the intermediate and end-points of the path.  This
   functionality MUST support co-routed bidirectional paths, and MAY
   support associated bidirectional and unidirectional p2p paths, as
   well as p2mp unidirectional paths.  Unidirectional path support is
   dependent on the existence of a return path to allow the original
   end-point to receive the trace information.

3.4.1.  Existing tools

   LSP Ping supports a trace route function that could be used for
   bidirectional paths.  Support of unidirectional paths would be
   dependent on the ability of identifying a return path.

3.4.2.  Recommendations and Guidelines

   Extend LSP Ping to support the Route Trace functionality and to
   address additional options, i.e.  PW and p2mp unidirectional LSP.

3.5.  Loopback tool

   Editor's note: In recent discussions a requirement was raised to
   support multiple maintenance points on a single node and the
   definition of the Loopback function that would appropriately test
   theconnectivity of these MP in order to identify fault location.
   This functionality must be more fully specified in the OAM Framework
   document before further analysis.

3.6.  Lock Instruct

   The Lock instruct function allows the system to block off
   transmission of data along a LSP.  When a path end-point receives a
   command, e.g. from the management system, that the path is blocked,
   the end-point informs the far-end that the path has been locked and
   that no data should be transmitted.  This function is used on-demand.

3.6.1.  Existing tools

   There is no mechanism defined in the IETF to support this function,
   but LSP Ping could be extended to support this functionality between
   the path endpoints.  Y.1731 does define a PDU and procedure for this
   functionality.

3.6.2.  Recommendations and Guidelines

   Extend LSP Ping to support Lock instruct.  The frequency at which
   these messages are transmitted until the lock situation is cleared,
   should be clearly indicated.

3.7.  Lock Reporting

   Lock reporting is used by an intermediate point to notify the end
   points of a transport path (that the intermediate point is a member
   of) that an external lock condition exits for this transport path.
   This function is used proactively.

3.7.1.  Existing tools

   There is no mechanism defined in neither the IETF nor in Y.1731 to
   support this function.

3.7.2.  Recommendations and Guidelines

   Define a new tool and PDU to support Lock reporting.  This tool could
   be designed similarly to the Alarm Reporting tool (described above),
   but would need to be initiated by an intermediate point of the
   transport path.

3.8.  Remote Defect Indication

   Remote Defect Indication (RDI) is used by a path end-point to notify
   its peer end-point that a defect, usually a unidirectional defect, is
   detected on a bi-directional connection between them.

   This function should be supported in pro-active mode.

3.8.1.  Existing tools

   There is no mechanism defined in the IETF to fully support this
   functionality, however BFD supports a mechanism of informing the far-
   end that the session has gone down, and the Diagnostic field
   indicates the reason.  Similarly, when LSP Ping is used for a co-
   routed bidirectional LSP the far-end LER could notify that there was
   a misconnectivity.

   In [Y.1731] this functionality is defined as part of the CC-V
   function as a flag in the PDU.

3.8.2.  Recommendations and Guidelines

   Extend BFD (which is recommended to be used for proactive CC-V) to
   transmit the signal of Remote Defect Indication without disrupting
   the CC-V functionality.  Such an extension could be similar to that
   suggested by the ITU recommendation.

3.9.  Client Failure Indication

   Client Failure Indication (CFI) function is used to propagate an
   indication of a failure to the far-end sink when alarm suppression in
   the client layer is not supported.

3.9.1.  Existing tools

   There is a possibility of using the BFD over VCCV mechanism for
   "Fault detection and AC/PW Fault status signaling".  However, there
   is a need to differentiate between faults on the AC and the PW.  In
   the PWE3 WG there are some proposals regarding how to transmit the
   CFI over an ACH.

3.9.2.  Recommendations and Guidelines

   Use PWE3 tool to propagate Client Fail Indication via an ACH.

3.10.  Packet Loss Measurement

   Packet Loss Measurement is a function that is used to verify the
   quality of the service.  This function indicates the ratio of packets
   that are not delivered out of all packets that are transmitted by the
   path source.

   There are two possible ways of determining this measurement -

   o  Using OAM packets, it is possible to compute the statistics based
      on a series of OAM packets.  This, however, has the disadvantage
      of being artificial, and may not be representative since part of
      the packet loss may be dependent upon packet sizes.

   o  Sending delimiting messages for the start and end of a measurement
      period during which the source and sink of the path count the
      packets transmitted and received.  After the end delimiter, the
      ratio would be calculated by the path OAM entity.

3.10.1.  Existing tools

   There is no mechanism defined in the IETF to support this function.
   [Y.1731] describes a function that is based on sending the CCM
   packets [used for CC-V support (see sec 3.1)] for proactive support
   and specialized loss-measurement packets for on-demand measurement.
   These packets include information (in the additional TLV fields) of
   packet counters that are maintained by each of the end-points of a
   path.  These counters maintain a count of packets transmitted by the
   ingress end-point and the count of packets received from the far-end
   of the path by the egress end-point.

3.10.2.  Recommendations and Guidelines

   One possibility is to define a mechanism to support Packet Loss
   Measurement, based on the delimiting messages.  This would include a
   way for delimiting the periods for monitoring the packet
   transmissions to measure the loss ratios, and computation of the
   ratio between received and transmitted packets.

   A second possibility would be to define a functionality based on the
   description of the loss-measurement function defined in [Y.1731] that
   is dependent on the counters maintained, by the MPLS LSR (as
   described in [RFC3813], of received and transmitted octets.  Define a
   new PDU for the message that utilizes G-ACH.  This option appears
   more suitable for performance monitoring statistics, which in
   transport applications are based on the continuous monitoring of the
   traffic interested (100 ms gating).

3.11.  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).  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
      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.

   Similarly to the packet loss measurement this could be performed in
   one of two ways -
   o  Using OAM packets - checking delay (either one-way or two-way) in
      transmission of OAM packets.  May not fully reflect delay of
      larger packets, however, gives feedback on general service level.

   o  Using delimited periods of transmission - may be too intrusive on
      the client traffic.

3.11.1.  Existing tools

   There is no mechanism defined in the IETF toolset that fulfills all
   of the MPLS-TP OAM requirements.

   [Y.1731] describes a function in which specific OAM packets are sent
   with a transmission time-stamp from one end of the managed path to
   the other end (these are transparent to the intermediate nodes).  The
   delay measurement is supported for both one-way and two-way
   measurement of the delay.  It should be noted that the functionality
   on the one-way delay measurement is dependent upon a certain degree
   of synchronization between the time clocks of the two-ends of the
   transport path.

3.11.2.  Recommendations and Guidelines

   Define a mechanism that would support Packe Delay Measurement, based
   on the procedures defined in [Y.1731].  The mechanism should be based
   on measurement of the delay layers
   in transmission and reception of OAM
   packets, transmitted in-band with normal traffic.  Define an
   appropriate PDU that would utilize the G-ACH.

4.  Recommendations

   As indicated above, LSP-Ping could easily be extended order to support some
   of the functionality between the path end-points and between an end-
   point of a path and an intermediate point.  BFD could also be
   extended improve their ability to support some of the functions between the end-points of a
   path.  Some of the OAM functions defined in [Y.1731] (especially for
   performance monitoring) could also be adapted.

   The guidelines that are used in this document are as follows:

   o  Re-use/extend existing IETF protocols wherever applicable.

   o  Define new message format for each of the rest of the OAM
      functions, which are aligned services with the ACH guaranteed
   and ACH-TLV definitions, strict Service Level Agreements (SLAs) while reducing their
   operational costs.

   [MPLS-TP Reqs] in general, and includes only relevant information.

   o  Adapt Y.1731 functionality where applicable (mainly for
      performance monitoring).

   The recommendations on the MPLS-TP [MPLS-TP OAM tools are as follows:

   o  Define Reqs] in particular
   define a maintenance entity that could be applied both to LSPs and
      PWs that would support management set of a sub-path.  This entity
      should allow requirements for transmission of traffic by means of label
      stacking and proper TTL setting.

   o  Extend the control and the management planes to support the
      configuration of the OAM maintenance entities functionality in MPLS-Transport
   Profile (MPLS-TP) for MPLS-TP Segments, Label Switched Paths (LSPs)
   (network infrastructure) and the set Pseudowires (PWs) (services).  One of
      functions to be supported by these entities.

   o  Define a mechanism that would allow
   the unique addressing mandates of the
      elements that need to be monitored, e.g., the connections, end-
      points, joint (IETF and intermediate points ITU-T) MPLS-TP work-item is the
   objective of developing a path.  This mechanism needs
      to be flexible enough Transport Profile is to support different addressing schemes,
      e.g.  IP addresses, NSAP, connection names.  As pointed out above,
      LSP Ping uses the full FEC identifier for base the LSP - this could
      easily be applied to Section OAM since this would be considered as
      a stacked LSP.

   o  The appropriate assignment of network-wide unique identifiers for
      transport paths, needed to support connectivity verification,
      should be considered.

   o  Extend toolset on
   existing MPLS tools to disengage from IP forwarding
      mechanisms.

   o  Extend BFD to support the proactive CC-V functionalities.  The
      extensions should address the gaps described above.

   o  Extend LSP Ping to support the on-demand Connectivity Verification
      functionality.  The extensions should address the gaps described
      above.

   o  Define a new PDU which will be transmitted over G-ACH to support
      the Alarm Reporting functionality for data-plane implementations.
      Describe how Alarm Reporting can be supported by a control-plane
      and by a management-plane.

   o  Define a new PDU which will be transmitted over G-ACH to support
      the Lock Reporting functionality.  Use the same procedures as for
      Alarm Reporting.

   o  Extend BFD to support technologies.  In addition, [MPLS-TP Reqs] indicates
   the Remote Defect Indication (RDI)
      functionality.  The extensions should address need for the gaps described
      above.

   o  Extend LSP-Ping OAM toolset for MPLS-TP to support the Route tracing functionality. be fully interoperable
   with existing MPLS OAM tools.

   The
      extensions should address the gaps described above.

   o  Extend LSP-Ping purpose of this document is to support outline the Lock Instruct functionality between
      end-points recommendations of a path.  The extensions should address the gaps
      described above.

   o  Use PWE3 tool to transmit Client Fault Indication (CFI) via ACH.
      There are already some proposals in
   MPLS-TP design team and confirmed by the PWE3 WG.

   o  Define a new PDU which will working group for the
   toolset that should be transmitted over G-ACH defined to support
      the Packet Loss Measurement functionality.  Base fulfill the OAM functionality
   requirements as documented in [MPLS-TP OAM Reqs] and [MPLS-TP OAM
   Frwk].  Based on the procedures defined in Y.1731.

   o  Define a new PDU which be transmitted over G-ACH principles cited above, it was determined to support the
      Packet Delay Measurement functionality.  Base
   base the functionality MPLS-TP OAM toolset on the procedures following existing MPLS tools:

   o  LSP-Ping as defined in Y.1731.  For one-way delay measurement
      define mechanisms to ensure a certain degree of synchronization
      between the time clocks of the two-ends of the transport path. [LSP Ping].

   o  Define a new PDU which  Bidirectional Forwarding Detection (BFD) as defined in [BASE BFD]
      and refined in [MPLS BFD].

   o  ITU-T OAM for Ethernet toolset as defined in [Y.1731] this will be transmitted over G-ACH to support
      used for functionality guidelines for the
      Diagnostic functionality.

   o  The performance measurement
      tools that are not currently supported in MPLS.

   It should be noted that certain extensions and adjustments may have the capability be
   made to authenticate the messages.
      The information may be carried existing MPLS tools, in a G-ACH TLV.

5.  MPLS-TP OAM Documents Organization

   The following paragraphs list the set of documents necessary order to conform to cover the OAM functionalities analyzed above.  This compilation transport
   environment and the requirements of
   documents is one MPLS-TP.

1.2.  Organization of the outcomes document

   Section 2 of the MEAD team discussions that
   took place during IETF75 in Stockholm.

   It should be noted that the various document titles listed here may
   not reflect provides references to the draft titles basic OAM tools
   that will be chosen at are provided for MPLS-TP OAM.

   Section 3 outlines the time different tools that the
   drafts are written, but they serve just as a topic pointer from the
   current analysis.

5.1.  Document 1: "Encapsulation of BFD required for MPLS-TP
   OAM and LspPing in ACH"

   The scope of references the document is to documents that will define the usage of LSP Ping and BFD
   in both IP and IP-less environments.  As described in appropriate
   tools based on the principles outlined above.

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
   paragraphs, acronyms:

   ACH     Associated Channel Header
   BFD     Bidirectional Forwarding Detection
   CC-V    Continuity Check and Lsp Ping need to be extended in order to be
   compliant with 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].  However, this document should be
   focused Reqs] defines a set of requirements on the existing Lsp Ping OAM architecture
   and BFD, without necessarily
   referring to their extended versions.

   The draft "nitinb-mpls-tp-lsp-ping-bfd-procedures" will be considered
   as the starting point for this definition.

   In particular, the following sections will be taken into account for
   the scope: general principles of operations which are evaluated below:

   o  nitinb-mpls-tp-lsp-ping-bfd-procedures section 2 ("LSP-Ping
      extensions") for addressing the "Lsp Ping encapsulation  [MPLS-TP OAM Reqs] requires that OAM mechanisms in ACH"

   o  nitinb-mpls-tp-lsp-ping-bfd-procedures section 5 ("Running BFD
      over MPLS-TP LSPs") for addressing are
      independent of the "BFD encapsulation in ACH"

5.2.  Document 2: "Extended BFD"

   The scope transmission media and of the document is client service
      being emulated by the PW.

   o  [MPLS-TP OAM Reqs] requires that the MPLS-TP OAM must be able to define
      support both an IP based and non-IP based environment.  If the BFD extension
      network is IP based, i.e.  IP routing and behavior
   to meet forwarding are
      available, then the requirements for MPLS-TP proactive Continuity Check and
   Connectivity Verification functionality OAM toolset should rely on the IP
      routing and forwarding capabilities.  On the RDI functionality as
   defined 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].

   The document will likely take Reqs] requires that all OAM protocols support
      identification information, at least in the name
   "draft-asm-mpls-tp-bfd-cc-cv-00" form of IP addressing
      structure and will be formed by the merging of
   the following two drafts:

   o  draft-fulignoli-mpls-tp-bfd-cv-proactive-and-rd

   o  draft-boutros-mpls-tp-cc-cv-01.txt

5.3.  Document 3: "Extended LSP Ping"

   The scope of the document is extensible to define: support additional identification
      schemes.

   o  A place holder for On Demand Connectivity Verification if LSP Ping
      needs to be enhanced over  It is also required that OAM packets and above the encapsulations changes
      (defined in Document 1 "Encapsulation of BFD and LSP Ping in
      ACH").

   o  Usage of LSP Ping with MIPs user traffic are
      congruent (i.e.  OAM packets are transmitted in-band) and MEPs, which there is partially covered
      a need to differentiate OAM packets from user-plane ones.
      Inherent in nitinb-mpls-tp-lsp-ping-bfd-procedures. this requirement is the principle that MPLS-TP OAM be
      independent of any existing control-plane, although it should not
      preclude use of the control-plane functionality.

   o  Route Trace.  This topic has already been partially covered in
      "draft-boutros-mpls-tp-path-trace-00"  [MPLS-TP OAM Reqs] requires a single OAM technology and "nitinb-mpls-tp-lsp-
      ping-bfd-procedures", which will be considered as starting point consistent
      OAM capabilities for the Route Trace functionality included in Document 3.  The
      Route Trace section should also cover these aspects:

      *  LSP Ping Loose ends.  This section will describe what to do
         when receiving an LSP Ping with MIP LSPs, PWs, and MEP ids.

      *  In an IP-Less environment Route Trace works only in co-routed
         bidirectional LSP.

      *  In Y.1731 Sections.

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

   The following comprise the CV function is separate from document-set that addresses the Route Trace
         function, it should be captured how LSP Ping works for Route
         Trace using TTL.

5.4.  Document 4: "Extensions for Lock Instruct"

   A new basic
   requirements listed above:

   o  The [MPLS-TP OAM Frwk] document describing describes the LSP Ping extensions architecural
      framework for conformance to accomplish the
   Lock Instruct desired behavior is needed.  Some material useful for
   this scope can be found in "draft-boutros-mpls-tp-loopback-02".

5.5.  Document 5: "AIS and Lock Reporting"

   A new document is need for basic requirements listed above.
      It also defines the definition of basic relationships between the AIS MPLS
      structures, e.g.  LSP, PW, and Lock
   Reporting, however the document definition has been temporarily
   deferred by structures necessary for OAM
      functionality, i.e. the MEAD team.  Therefore this paragraph will be updated
   in future versions.

5.6.  Document 6: "Client Fault Indication"

   A new document describing Client Fault Indication procedure needs to
   be defined.

   The following two drafts indicating a client fault indication
   transported across MPLS-TP network will be compared Managed Entity Group, its End-points, and merged in the
   new document:
      Intermediate Points.

   o  "draft-he-mpls-tp-csf", which describes a tool to propagate a
      client failure indication across an MPLS-TP network in case  The [MPLS G-ACH] document specifies the
      propagation use of failure status in the client layer MPLS-TP in-
      band control channel.  This is not
      supported.

   o  "draft-martini-pwe3-static-pw-status", which describes modeled after the usage
      of PW associated VCCV channel to signal PW status messages
      described in case a
      static PW is used without a control plane [PW ACH] and allows transporting the OAM messages
      congruently with the data traffic while allowing the required
      identification of the packets.  It is worth noting expected that a Client Failure Indication is used if all of the
   client does not support its own OAM (IP and MPLS as clients use their
   own).  It has been also agreed
      protocols will be used in conjunction with this Generic Associated
      Channel.

   o  The [MPLS-TP ACH TLV] document specifies a basic set of TLV fields
      that CFI is could be used on PW and not on
   client directly mapped on LSP MPLS-TP.

5.7.  Document 7: "Packet Loss"

   A new 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 needs to be defined in order addresses the need of MPLS-TP to describe a stand alone
   tool
      support different addressing spaces.  This document describes
      different formats for Packet Loss measurements addresses that can work both proactively and
   on demand.  The tool will could be functionally based on Y.1731.

5.8.  Document 8: "Packet Delay"

   A new document needs used to be defined about identify the Packet Delay measurement
   which will be based on Y.1731 from
      transport entities in the functionality point of view.
   Moreover, network and referenced by the different
      OAM protocols.

3.  MPLS-TP OAM Functions

   The following sections discuss the required OAM functions that were
   identified in [MPLS-TP OAM Frwk] needs to be updated Reqs] and expanded upon in order [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, but may also be used
   on-demand, either due to clarify
   the functionality behavior expected from this tool.

5.9.  Document 9: "Diagnostic Tests"

   One bandwidth considerations or more new documents are needed for diagnoses of
   a specific condition.  Proactively [MPLS-TP OAM Reqs] states that the tools definition for
   Diagnostic Tests.  However,
   function should allow the documents definition has been
   temporarily deferred by MEPs to monitor the MEAD team until a clearer definition liveness and
   connectivity of
   "diagnostic test" 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 Reqs].

6.  IANA Considerations

   This document makes no request of IANA.

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

7.  Security Considerations

   This document does not by itself raise any particular security
   considerations.

8.  Acknowledgements

   The authors wish to thank Frwk] highlights the MEAD team need for their review and proposed
   enhancements the CC-V messages to
   include unique identification of the text.

Appendix A.  Proactive CC and CV BFD tool analysis

   This appendix MEG that is focused on analyzing possible solutions being monitored and
   evaluating their pros&cons for defining an MPLS-TP OAM mechanism BFD
   based,to meet
   the requirements for proactive Continuity Check MEP that originated the message.  The function, both proactively
   and
   Connectivity Verification functionality as required in [MPLS-TP OAM
   Reqs].

   The BFD tool needs on-demand mode, need to be extended for the CV functionality transmitted at regular rates pre-
   configured by the
   addition of a unique identifier in order to meet operator.

3.1.1.  Documents for CC-V tools

   [Pro CC-V] defines the requirements.
   Proactive Continuity Check (CC) and Continuity Verification (CV)
   function are BFD extensions that will be used for proactive
   CC-V applications.  While [Demand CV] provides the LSP-Ping
   extensions that will be used together to detect loss implement on-demand Connectivity
   Verification.  Both of continuity (LOC),
   unintended connectivity between two MEs (e.g. mismerging or
   misconnection) as well as unintended connectivity within the ME these tools will be used together with
   an unexpected MEP.  It MUST operate both in bidirectional p2p and in
   unidirectional p2mp connection.

   The mechanism MUST foresee the configuration of the transmit
   frequency.

   The mechanism
   basic tools mentioned above in section 2

3.2.  Remote Defect Indication

   Remote Defect Indication (RDI) is RECOMMENDED be the same for LSP, (MS-)PW and Section
   (See 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])

Appendix A.1.  Possible Solution

   Several solutions have been analyzed:

   1.  Define Reqs] points out that this
   function may be applied to a new BFD version (BFDv2) unidirectional LSP only if there a
   return path exists.  [MPLS-TP OAM Frwk] points out that extends this function
   is associated with the current BFD
       (BFDv1) to support also CV functionality. proactive CC-V function

3.2.1.  Documents for RDI

   The new [Pro CC-V] document includes and extension for BFD version
       can be obtained by:

       *  changing that would
   include the semantic of MY discriminator and Your
          discriminator fields [BASE BFD],

       *  adding a new globally unique source MEP ID field RDI indication in the BFD
          packet for the CV functionality format, and a specification of
   how this indication is to the existing session
          identifier.

   2.  Define two separate tools, running with two different ACH
       encapsulations (i.e. two different ACH channel types):

       *  the current BFD with only CC be used.

3.3.  Route Tracing

   [MPLS-TP OAM Reqs] defines that there is a need for functionality however profiled in
          behavior
   that would allow a path end-point to meet identify the CC MPLS-TP requirement;

       * 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 new tool return path exists.

3.3.1.  Documents for Route Tracing

   The [Demand CV] document that meet all specifies the LSP-Ping enhancements for
   MPLS-TP OAM proactive CV
          requirement.

   The new tool can be:

   1.  based on-demand Connectivity Verification includes information on current BFD;

   2.  an extension of
   the ACH encapsulation use of LSP-Ping for the current BFD;

   3.  a new tool like Y.1731 CCM;

   All analyzed solutions imply extension route tracing of CV types, foreseen by [PW
   VCCV] yet extended by [VCCV BFD], in order to include the a MPLS-TP OAM
   mechanism too.  This transport path.

3.4.  Alarm Reporting

   Alarm Reporting is due to the fact a function used by an intermediate point of a
   path, that VCCV also includes
   mechanisms for negotiating becomes aware of a fault on the control channel and connectivity
   verification (i.e.  OAM functions) between PEs.

Appendix A.2.  Backward compatibility

   For backward compatibility, it is possible path, to report to run the current BFD
   that supports only CC functionality on some transport paths and
   end-points of the
   new tool that supports CC and proactive CV functionality on other
   transport paths.  In any case only one tool for path.  [MPLS-TP OAM instance Frwk] states that this may
   occur as a result of a defect condition discovered at time,
   configurable by operator, can run.

   A MEP a server sub-
   layer.  This generates an Alarm Indication Signal (AIS) that
   continues until the fault is configured 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 support proactive CV address this functionality MUST
   be capable to receive existing BFD packets (encapsulated with GAL/
   G-ACH or PW-ACH) that supports only CC functionality and MUST
   consider them as an unexpected packet, i.e. detect a misconnection
   defect and vice versa.

   The context is
   documented in [Fault Mng].  This protocol uses all of MPLS-TP the basic
   mechanisms detailed in Section 2.

3.5.  Lock Reporting

   Lock reporting, defined in [MPLS-TP OAM packets Reqs], is based on MPLS label and G-ACH,
   eliminating in the BFD the need to exchange Discriminator values.  An
   MPLS-TP node that desires similar to interoperate with a current BFD can
   apply the same discriminator field semantic as
   Alarm Reporting function described in [BASE
   BFD] or:

   o above.  It MUST set the My discriminator field is used by an
   intermediate point to a nonzero value (it can
      be a fixed value);

   o  It MUST reflect back notify the received value end points of My discriminator field
      into the transmitted Your discriminator field, or set it 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 zero
      if address this functionality that value is unknown.

Appendix A.3.  Definition
   documented in [Fault Mng].  This protocol uses all of BFDv2

   Common to both solutions the basic
   mechanisms detailed in this section are the following
   considerations:

   o Section 2.

3.6.  Diagnostic

   The Channel Type field of the G-ACH [MPLS-TP OAM Reqs] indicates that there is the one proposed by [VCCV
      BFD], i.e. 0x0007, indicating the raw BFD control packet;

   o need to provide a OAM
   function that would enable conducting different diagnostic tests on a
   PW, LSP, or Section.  The version number [MPLS-TP OAM Frwk] provides two types of the protocol needs to be updated to protocol
      version 2 respect
   specific tests to protocol version 1 defined in [BASE BFD].

Appendix A.3.1.  New semantic for Discriminator fields

   A possible BFD extension can be obtained changing the semantic of used through this functionality:

   o  Throughput Estimation - allowing the
   two 32 bit fields, My Discriminator and Your Discriminator, provider to form a
   one 64 bit field carrying the globally unique MEP Identifier.

   One of verify the disadvantages
      bandwidth/throughput of this solution a transport path.  This is on the too limited
   number of octets available for the globally unique MEP ID field: an out-of-
      service tool, that
   doesn't allow the possibility to have different format uses special packets of ME
   identifier.

Appendix A.3.2.  New MEP ID field

   This solution adds the new field required for the CV functionality,
   i.e. a globally unique MEP Identifier section, after varying sizes to test
      the mandatory
   section actual bandwidth and/or throughput of a BFD control packet and before the optional
   Authentication section.

   The advantages of path.

   o  Data-plane loopback - this solution are out-of-service tool that causes all
      traffic that reaches the discriminator behavior
   of target node, either a MEP or MIP, to be
      looped back to the current BFD protocol as 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 [BASE BFD] is unchanged and
   on the variable length a merge of existing
   separate individual drafts.  The merged document will define a new
   G-ACH based protocol message that addresses the MEP ID Section.

Appendix A.4.  Two different ACH encapsulation Throughput Estimation
   tool, and also provide various flavors of OAM tool loopback functionality.

3.7.  Lock Instruct

   The current BFD, with only CC functionality, Lock Instruct function is encapsulated in the
   G-ACh using as Channel type code point the 0x0007 value as described
   in [VCCV BFD].  This mechanism can be also extended an administrative control tool that
   allows a path end-point to Section OAM
   and LSP OAM.

   In order instruct its peer end-point to meet lock the MPLS-TP OAM proactive CV requirement, a new
   path.  The tool
   has is necessary to be introduced, encapsulated into the G-ACh with a new channel
   type code point.  Common support single-side provisioning for
   administartive locking, according to all solutions detailed below are .  This function is used on-
   demand.

3.7.1.  Documents for Lock Instruct

   Work is being done on a document that will specify the
   following G-ACh format:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |0 0 0 1|0 0 0 0|0 0 0 0 0 0 0 0| MPLS-TP CC-CV proactive       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                        Figure 1: new ACH Encapsulation

   - first nibble: set based
   protocol format for this tool.

3.8.  Client Failure Indication

   Client Failure Indication (CFI) is defined in [MPLS-TP OAM Reqs] to 0001b
   allow the propagation information from one edge of the network to indicate a channel associated with a
   PW, a LSP or the
   other.  The information concerns a Section;

   - Version and Reserved fields are set defect to 0;

   - G-ACH Channel Type field with a new TBD code point meaning "MPLS-TP
   CC-CV proactive" indicating client, in the case
   that the client does not support alarm notification.

3.8.1.  Documents for CFI

   Work is being done on a document that will specify the message new ACH based
   protocol format for this tool.

3.9.  Packet Loss Measurement

   Packet Loss Measurement is an MPLS-TP required, by [MPLS-TP OAM CC-CV
   proactive message.  The value MUST be assigned

   The sections below describe the format Reqs] to provide
   a quantification of the different possible new
   tool.

Appendix A.4.1.  New tool based packet loss ratio on current BFD

   A new tool can be obtained introducing a globally unique MEP
   Identifier TLV between transport path.  This
   is the ACH and ratio of the current BFD (defined in [BASE
   BFD]) Control packet.

   The benefit number of this solution is user packets lost to maintain the basic state machine
   and protocol version total number
   of BFD as user packets during a defined in [BASE BFD] and
   [bfdMultipoint]; considerations on the optional Authentication
   Section is described in section Appendix A.7.

Appendix A.4.2.  New tool based on time interval.  To employ this
   function, [MPLS-TP OAM Frwk] defines that the extended BFD

   The solutions and considerations are two end-points of the same
   transport path should exchange counters of what described messages transmitted and
   received within a time period bounded by loss-measurement messages.
   The framework warns that there may be small errors in
   section Appendix A.3.2 except the ACH Channel type code, rather than computation
   that result from various issues.

3.9.1.  Documents for Packet Loss Measurement

   The [Loss-Delay] describes the Version field, distinguishes between existing BFD (supporting CC) protocol formats and procedures for
   using the new tools (supporting both CC&CV). tool.  The Version field in this case is set to 0 (this tool logic is based on the first version
   for this tool).

Appendix A.4.3.  New tool like Y.1731 CCM

   To be inserted

Appendix A.5.  Remote Defect Indication

   Remote Defect Indication (RDI) behavior of the
   parallel function described in [Y.1731].

3.10.  Packet Delay Measurement

   Packet Delay Measurement is used by a MEP to notify its peer
   MEP function that a defect is detected on a bi-directional connection between
   them).  RDI is only used for bidirectional connections and is
   associated with proactive CC & CV packet generation.[MPLS-TP OAM
   Frwk] The Diagnostic (Diag) field to measure one-
   way or two-way delay of a packet transmission between a pair of the Current BFD can be used for
   this functionality.  However, there isn't
   end-points of a total correspondence
   among path (PW, LSP, or Section), as described in [MPLS-TP
   OAM Reqs].  Where:

   o  One-way packet delay is the values foreseen by [BASE BFD] and time elapsed from the defect conditions
   detected start of
      transmission of the first bit of the packet by a source node until
      the proactive CC-CV tool that require reception of the RDI function.

   A solution could be that any defect last bit of that requires the RDI information
   being sent to packet by the peer MEP destination
      node.

   o  Two-way packet delay is encoded in the Diagnostic (Diag) field
   with the value 1 (corresponding to time elapsed from the "Control Detection Time
   Expired" in [BASE BFD].  The value 0 indicates RDI condition has been
   cleared.

   For start of
      transmission of the solution in section Appendix A.4.3 , RDI is foreseen in first bit of the packet format with by a single bit.

Appendix A.6.  Point to Multipoint transport paths

   Solution described in section Appendix A.4.3 is valid for both
   bidirectional and unidirectional connection: in unidirectional
   connection only source MEP is enabled only to generate CC/CV OAM
   packets and sink MEP is enabled only to receive CC/CV OAM packets.

   The BFD tool has a straightforward state machine for bidirectional
   path.  Anyway node until
      the behavior and state machine need to be modified for reception of the unidirectional connection; this last bit of the loop-backed packet by the
      same source node, when the loopback is described in [bfdMultipoint].

Appendix A.7.  Security Considerations

   Base BFD [BASE BFD] foresees an optional authentication section; that
   can be extended even to performed at the packet's
      destination node.

   [MPLS-TP OAM Frwk] describes how the tool proposed could be performed (both in this document.

   Authentication methods
   proactive and on-demand modes) for either one-way or two-way
   measurement.  However, it warns that require checksum calculation on the
   outgoing packet must extend one-way delay option
   requires precise time synchronization between the end-points.

3.10.1.  Documents for Delay Measurement

   The [Loss-Delay] describes the protocol formats and procedures for
   using the checksum even tool.  The tool logic is based on the ME Identifier
   Section.  This is possible but seems uncorrelated with behavior of the solution
   proposed in section Appendix A.4.1
   parallel function described in [Y.1731].

4.  IANA Considerations

   This document makes no request of IANA.

   Note to RFC Editor: this case it could section may be better removed on publication as an
   RFC.

5.  Security Considerations

   This document does not by itself raise any particular security
   considerations.

6.  Acknowledgements

   The editors wish to
   use thank the simple password authentication method.

   It is also worth noticing that MPLS-TP Design Team members, from both
   the interactions between
   authentication IETF and connectivity verification need further analysis.

9. 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 References

   [RFC 2119]
              Bradner, S., "Internet Control Message Protocol", BCP 14,
              RFC 2119, March 1997.

   [ICMP]     Postel, J., "Internet Control Message Protocol", STD 5,
              RFC 792, Sept 1981.

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

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

   [BASE BFD]
              Katz, D. and D. Ward, "Bidirectional Forwarding
              Detection", ID draft-ietf-bfd-base-09.txt, RFC 5880, February 2009.

   [MPLS BFD]
              Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow,
              "BFD For MPLS LSPs", ID draft-ietf-bfd-mpls-07.txt, RFC 5884, June 2008.

   [VCCV BFD]
              Nadeau, T.

   [MPLS TP Idents]
              Bocci, M. and C. Pignataro, "Bidirectional Forwarding
              Detection (BFD) for the Pseudowire Virtual Circuit
              Connectivity Verification (VCCV)", G. Swallow, "MPLS-TP Identifiers",
              ID draft-ietf-pwe3-vccv-bfd-07.txt, February 2008.

   [bfdMultipoint]
              Katz, D. and draft-ietf-mpls-tp-identifiers-01.txt, March 2010.

   [Pro CC-V]
              Allan, D. Ward, "Bidirectional Forwarding Detection
              for Multipoint Networks",
              ID draft-katz-ward-bfd-multipoint-02.txt, February 2009.

   [P2MP LSP Ping]
              Nadeau, T. and A. Farrel, "Detecting Data Plane Failures
              in Point-to-Multipoint Multiprotocol Label Switching
              (MPLS) - Extensions to LSP Ping",
              ID draft-ietf-mpls-p2mp-lsp-ping-06.txt, June 2008.

   [MPLS LSP Ping]
              Bahadur, N. G. Swallow, "Proactive Connection
              Verification, Continuity Check and K. Kompella, "Mechanism Remote Defect
              indication for performing
              LSP-Ping over MPLS tunnels", Transport Profile",
              ID draft-ietf-mpls-lsp-ping-enhanced-dsmap-00, draft-ietf-mpls-tp-cc-cv-rdi-00.txt, June 2008.

   [RFC4656]  Shalunov, 2010.

   [Demand CV]
              Bahadur, N., Aggarwal, R., Boutros, S., Teitelbaum, B., Karp, A., Boote, J., and M.
              Zekauskas, "A One-way Active Measurement Protocol",
              RFC 4656, September 2006.

   [RFC5357]  Hedayat, K., Krzanowski, R., Morton, A., Yum, K., E. Gray, "MPLS
              on-demand Connectivity Verification, Route Tracing and J.
              Babiarz, "A Two-Way Active Measurement Protocol",
              RFC 5357, Oct 2008.
              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-01, draft-ietf-mpls-tp-oam-requirements-05, April 2009.

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

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

   [MPLS G-ACH]
              Bocci, M., Bryant, S., and M. Vigoureux, "MPLS Generic
              Associated Channel", RFC 5586, June 2009.

   [MPLS-TP ACH TLV]
              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.

   [RFC3813]  Srinivasan, C., Viswanathan,

   [Fault Mng]
              Swallow, G., Fulignoli, A., and T. Nadeau,
              "Multiprotocol Label Switching (MPLS) Label Switching
              Router (LSR) M. Vigoureux, "MPLS Fault
              Management Information Base (MIB)", RFC 3813,
              June 2004. OAM", ID draft-ietf-mpls-tp-fault-00,
              March 2010.

   [Loss-Delay]
              Frost, D. and S. Bryant, "Packet Loss and Delay
              Measurement for the MPLS Transport Profile",
              ID draft-frost-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 (editor)
   Nokia Siemens Networks
   3 Hanagar St. Neve Ne'eman B
   Hod Hasharon,   45241
   Israel

   Email: nurit.sprecher@nsn.com

   Huub van Helvoort (editor)
   Huawei
   Kolkgriend 38, 1356 BC Almere
   Netherlands

   Phone: +31 36 5316076
   Email: hhelvoort@huawei.com
   Elisa Bellagamba
   Ericsson
   6 Farogatan St
   Stockholm,   164 40
   Sweden

   Phone: +46 761440785
   Email: elisa.bellagamba@ericsson.com

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

   Phone: +972-9-775 1827
   Email: yaacov.weingarten@nsn.com