MPLS Working Group                                        I. Busi (Ed)
Internet Draft                                          Alcatel-Lucent
Intended status: Informational
                                                 B. Niven-Jenkins (Ed)
                                                                   BT

Expires: September 2009                                 March 26, January 2010                                    July 13, 2009

                           MPLS-TP OAM Framework and Overview
                  draft-ietf-mpls-tp-oam-framework-00.txt
                  draft-ietf-mpls-tp-oam-framework-01.txt

                            Status of this Memo

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

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that other
   groups may also distribute working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress".

   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

Copyright Notice

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

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document. document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Abstract

   Multi-Protocol Label Switching (MPLS) Transport Profile (MPLS-TP) is
   based on a profile of the MPLS and pseudowire (PW) procedures as
   specified in the MPLS Traffic Engineering (MPLS-TE), pseudowire (PW)
   and multi-segment PW (MS-PW) architectures complemented with
   additional Operations, Administration and Maintenance (OAM)
   procedures for fault, performance and protection-switching management
   for packet transport applications that do not rely on the presence of
   a control plane.

   This document provides a framework that supports a comprehensive set
   of OAM procedures that fulfills the MPLS-TP OAM requirements [11].

Table of Contents

   1. Introduction.................................................3
      1.1. Contributing Authors....................................3 Authors....................................4
   2. Conventions used in this document............................3 document............................4
      2.1. Terminology.............................................3 Terminology.............................................4
      2.2. Definitions.............................................4 Definitions.............................................5
   3. Functional Components........................................5 Components........................................7
      3.1. Maintenance Entity......................................6 Entity......................................9
      3.2. Point-to-multipoint scenario............................9
      3.3. Maintenance End Points (MEPs)...........................7
      3.3. (MEPs)..........................10
      3.4. Maintenance Intermediate Points (MIPs)..................8
      3.4. (MIPs).................12
      3.5. Server MEPs.............................................9 MEPs............................................12
   4. Reference Model.............................................10 Model.............................................13
      4.1. MPLS-TP Section Monitoring.............................12 Monitoring.............................15
      4.2. MPLS-TP LSP End-to-End Monitoring......................13 Monitoring......................16
      4.3. MPLS-TP LSP Tandem Connection Monitoring...............14 Monitoring...............17
      4.4. MPLS-TP PW Monitoring..................................16 Monitoring..................................19
      4.5. MPLS-TP MS-PW Tandem Connection Monitoring.............16 Monitoring.............19
   5. OAM Functions for pro-active monitoring.....................17 monitoring.....................21
      5.1. Continuity Check and Connectivity Verification.........17 Verification.........21
         5.1.1. Defects identified by CC-V........................22
            5.1.1.1. Loss Of Continuity defect....................22
            5.1.1.2. Mis-connectivity defect......................22
            5.1.1.3. MEP misconfiguration defect..................23
            5.1.1.4. Period Misconfiguration defect...............23
         5.1.2. Consequent action.................................23
         5.1.3. Configuration considerations......................24
         5.1.4. Applications for proactive CC & CV function.......20 CC-V...................25
      5.2. Remote Defect Indication...............................20 Indication...............................26
         5.2.1. Configuration considerations......................21 considerations......................26
         5.2.2. Applications for Remote Defect Indication.........21 Indication.........26
      5.3. Alarm Suppression......................................21 Reporting........................................27
      5.4. Lock Indication........................................23 Reporting.........................................28
      5.5. Packet Loss Measurement................................23 Lock Indication........................................29
      5.6. Packet Loss............................................29
         5.6.1. Configuration considerations......................29
         5.6.2. Applications for Packet Loss......................30
      5.7. Client Signal Fail.....................................23 Failure Indication..............................30
         5.7.1. Configuration considerations......................31
         5.7.2. Applications for Remote Defect Indication.........31
      5.8. Delay Measurement......................................31
         5.8.1. Configuration considerations......................32
         5.8.2. Applications for Packet Loss......................32
   6. OAM Functions for on-demand monitoring......................23 monitoring......................32
      6.1. Continuity Check and Connectivity Verification.........23 Verification..............................32
         6.1.1. Configuration considerations......................24 considerations......................33
      6.2. Packet Loss Measurement................................24 Loss............................................34
         6.2.1. Configuration considerations......................34
         6.2.2. Applications for On-demand Packet Loss............34
      6.3. Diagnostic Test........................................24 Diagnostic.............................................34
      6.4. Trace routing..........................................24 Route Tracing..........................................35
      6.5. Packet Delay Measurement...............................25 Measurement......................................35
         6.5.1. Configuration considerations......................35
         6.5.2. Applications for Delay Measurement................35
      6.6. Lock Instruct..........................................36
   7. OAM Protocols Overview......................................25
   8. Security Considerations.....................................25
   9. Considerations.....................................36
   8. IANA Considerations.........................................25 Considerations.........................................36
   9. Acknowledgments.............................................36
   10. Acknowledgments............................................25
   11. References.................................................26
      11.1. References.................................................37
      10.1. Normative References..................................26
      11.2. References..................................37
      10.2. Informative References................................26 References................................37

1. Introduction

   As noted in the MPLS-TP framework [8], the overall architecture of MPLS-TP is based on defines a profile of the MPLS-TE and (MS-)PW
   architectures defined in RFC 3031 [2], RFC 3985 [5] and [6] [7]
   complemented with additional OAM procedures for fault, performance
   and protection-switching management for packet transport applications
   that do not rely on the presence
   applications.

   [Editor's note - The draft needs to be reviewed to ensure support of a control plane.
   OAM for p2mp transport paths]

   In line with [12], existing MPLS OAM mechanisms will be used wherever
   possible and extensions or new OAM mechanisms will be defined only
   where existing mechanisms are not sufficient to meet the
   requirements.

   The MPLS-TP OAM framework defined in this document provides a
   comprehensive set of OAM procedures while satisfying that satisfy the MPLS-TP OAM
   requirements [11]. In this regard, it is similar to existing
   SONET/SDH and OTH OAM mechanisms (e.g. [14]). [16]).

1.1. Contributing Authors

   Italo Busi, Ben Niven-Jenkins, Annamaria Fulignoli, Enrique
   Hernandez-Valencia, Lieven Levrau, Dinesh Mohan, Vincenzo Sestito,
   Nurit Sprecher, Huub van Helvoort, Martin Vigoureux, Yaacov
   Weingarten, Rolf Winter

2. Conventions used in this document

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

2.1. Terminology

   DBN  Domain Border Node

   LME  LSP Maintenance Entity

   LTCME LSP Tandem Connection Maintenance Entity

   [Editor's note - Difference or similarity between tandem connection
   monitoring (TCM)_and Path Segment Tunnel (PST) need to be defined and
   agreed]

   ME   Maintenance Entity

   [Editor's note - There is a need to define whether to support OAM on
   p2mp transport path there is a need to introduce the MEG concept]

   MEP  Maintenance End Point

   MIP  Maintenance Intermediate Point

   PHB  Per-hop Behavior

   PME  PW Maintenance Entity

   PTCME PW Tandem Connection Maintenance Entity

   SME  Section Maintenance Entity

2.2. Definitions

   Concatenated Segment: see [10]

   Co-routed bidirectional path: see [10]

   Domain Border Node: see [13]

   Layer network: see [10]

   Section: see [10]

   ME: The collection of MEPs and MIPs and their association (details in
   section 3.1).

   MEP: A MEP is capable of initiating (MEP Source) and terminating (MEP
   Sink) OAM messages for fault management and performance monitoring.
   MEPs reside at the boundaries of an ME (details in section 3.3).

   MEP Source: A MEP acts as MEP source for the OAM messages that it
   originates and inserts into its associated ME.

   MEP Sink: A MEP acts as a MEP sink for the OAM messages that it
   terminates and processes from its associated ME.

   MIP: A MIP terminates and processes OAM messages and generates OAM
   messages in reaction to received OAM messages. A MIP resides within a
   ME between MEPs (details in section 3.4).

   OAM domain: A domain, as defined in [10], whose entities are grouped
   for the purpose of keeping the OAM confined within that domain.

   Note - within the rest of this document the term "domain" is used to
   indicate an "OAM domain"

   OAM flow: An OAM flow is a traffic flow of OAM packets between a pair of MEPs
   or a MEP and a MIP that is used to monitor and maintain a ME
   [Editor's note - a MEG depending on what we decide for this point]. The
   An OAM flow is associated to a unique ME and contains the OAM
   monitoring, signalling and notification messages necessary to monitor
   and maintain that ME. The exact mix of message types in an OAM flow
   will be dependent on the technology being monitored and the exact
   deployment scenario of that technology (e.g. some deployments may
   proactively monitor the connectivity of all transport paths whereas
   other deployments may only reactively monitor transport paths)

   MIP: A MIP terminates and processes paths).

   OAM messages and generates OAM
   messages in reaction to received OAM messages.

   MEP Source: A MEP acts as MEP source for the OAM flow that it
   originates and inserts into its associated ME.

   MEP Sink: A MEP acts as a MEP sink for the OAM flow that it
   terminates and processes from it associated ME.

   OAM Message: An Message: An OAM information element that performs some OAM
   functionality (e.g. continuity check and connectivity verification)

   OAM Packet: A packet that carries one or more OAM messages (i.e. OAM
   information elements).

   Path: See Transport Path

   Signal Fail: A condition when the data associated with a transport
   path has failed in the sense that a defect condition (not being a
   degraded defect) is detected.

   Segment: see [10]

   Sublayer: see [10]

   Tandem Connection: see [10]

   Transport Path: see [10]

   Unidirectional path: see [10]

3. Functional Components

   MPLS defines the use of Label Switched Paths (LSPs) and Pseudowires
   (PWs)([2], [5] and [7]) that are used to connect service end points.
   MPLS-TP builds on this framework the need to transport service
   traffic, based on certain performance and quality measurements.  In
   order to verify and maintain these performance and quality
   measurements, we need to use the OAM functionality not only on A tandem connection is an
   transport paths (e.g. LSP or MS-PW), but also on arbitrary parts part of
   transport paths, defined as Tandem Connections in [10], between any
   two arbitrary points along a path.

   MPLS-TP OAM operates in the context of Maintenance Entities (MEs).

   A Maintenance Entity
   transport path that can be viewed as monitored (via OAM) independently from the association
   end-to-end monitoring (OAM).  It may be a monitored segment or a
   monitored concatenated segment of two (or
   more) Maintenance End Points (MEPs), see below. a transport path.  The MEPs that form an
   ME are configured and managed to limit tandem
   connection may also include the scope forwarding engine(s) of an OAM flow
   within the ME the MEPs belong to.

   Each MEP resides node(s)
   at the boundaries edge(s) of the ME that they are part of.
   An ME may also include a set of zero segment or more Maintenance Intermediate
   Points (MIPs), which reside within the Maintenance Entity, between
   the MEPs.

   A MEP is capable of initiating and terminating OAM messages for fault
   management and performance monitoring. concatenated segment.

   The following terms are defined in [10] as follows:

   Associated bidirectional path: A MIP is capable of terminating OAM messages but it generates OAM
   messages only path that supports traffic flow in reaction to received OAM messages.

   This functional model defines the relationships between all OAM
   entities
   both directions but which is constructed from a maintenance perspective, to allow pair of
   unidirectional paths (one for each Maintenance
   Entity to monitor and manage the layer network under its
   responsibility and easily localize problems.

   MEPs and MIPs direction) which are associated
   with a particular Maintenance Entity.

   When a control plane is not present, one another at the management plane configures
   MEPs path's ingress/egress points.  The forward
   and MIPs. Otherwise backward directions are setup, monitored and protected
   independently.  As a consequence they can be configured either by the
   management plane may or by the control plane.

   [Editor's note - Need to align the two paragraphs above with the
   outcome of the on-going discussion on may not follow the mailing list regarding same
   route (links and nodes) across the
   usage of control plane to configure OAM]

3.1. Maintenance Entity network.

   Concatenated Segment: A Maintenance Entity can be viewed serial-compound link connection as the association of two (or
   more) Maintenance End Points (MEPs). An example of an ME with more
   than two MEPs defined in
   G.805 [17].  A concatenated segment is a point-to-multipoint ME monitoring a point-to-
   multipoint transport path (or point-to-multipoint tandem connection).
   The MEPs that form an ME should be configured and managed to limit
   the OAM responsibilities contiguous part of an OAM flow within a network or sub-
   network, LSP or
   multi-segment PW that comprises a transport path or segment, set of segments and their
   interconnecting nodes in sequence.  See also "Segment".

   Co-routed bidirectional path: A path where the specific layer
   network that is being forward and backward
   directions follow the same route (links and nodes) across the
   network.  Both directions are setup, monitored and managed. Any maintenance point in
   between MEPs is protected as a Maintenance Intermediate Points (MIP).
   single entity.  A Maintenance Entity transport network path is typically co-routed.

   Layer network: Layer network is defined in G.805 [17]. A layer
   network provides for the transfer of client information and
   independent operation of the client OAM.  A Layer Network may be defined
   described in a service context as follows: one layer network may
   provide a (transport) service to monitor and manage
   unidirectional point-to-point or point-to-multipoint transport paths
   or tandem connections, or co-routed bidirectional point-to-point
   transport paths higher client layer network and tandem connections may,
   in an MPLS-TP turn, be a client to a lower layer network.

   MPLS-TP OAM functions are designed  A layer network is a
   logical construction somewhat independent of arrangement or
   composition of physical network elements.  A particular physical
   network element may topologically belong to be applied either more than one layer
   network, depending on an end-to-
   end basis, e.g., between the LERs actions it takes on the encapsulation
   associated with the logical layers (e.g. the label stack), and thus
   could be modeled as multiple logical elements.  A layer network may
   consist of a given LSP one or T-PEs of more sublayers.  Section 1.3 provides a given
   PW, or on more
   detailed overview of what constitutes a per tandem connection basis, e.g., between any LER/LSR layer network.  For
   additional explanation of how layer networks relate to the OSI
   concept of layering see Appendix I of Y.2611 [19].

   Section Layer Network: A section layer is a given LSP server layer (which may
   be MPLS-TP or any T-PE/S-PE of a given PW.

   The end points different technology) which provides for the transfer
   of a tandem connection are MEPs because the tandem
   connection is by definition a Maintenance Entity.

   Therefore, section layer client information between adjacent nodes in the context
   transport path layer or transport service layer.  A section layer may
   provide for aggregation of multiple MPLS-TP LSP or PW Maintenance Entity
   (defined below) LERs and T-PEs can be MEPs while LSRs and S-PEs may
   be MIPs. In clients.  Note that G.805
   [17] defines the case of Tandem Connection Maintenance Entity (defined
   below), LSRs and S-PEs can be either MEPs or MIPs.

   The following properties apply to all MPLS-TP MEs:

   o They can be nested but not overlapped, e.g. a ME may cover a
      segment or a concatenated segment section layer as one of another ME, and may also
      include the forwarding engine(s) of two layer networks in a
   transmission media layer network.  The other layer network is the node(s) at
   physical media layer network.

   Path: See Transport Path

   Segment: A link connection as defined in G.805 [17]. A segment is the edge(s)
   part of
      the segment an LSP that traverses a single link or concatenated segment, but all its MEPs and MIPs are
      no longer the part of the encompassing ME. It a PW that
   traverses a single link (i.e. that connects a pair of adjacent
   {Switching|Terminating} Provider Edges). See also "Concatenated
   Segment".

   Sublayer: Sublayer is defined in G.805 [17]. The distinction between
   a layer network and a sublayer is possible that MEPs a sublayer is not directly
   accessible to clients outside of
      nested MEs reside on its encapsulating layer network and
   offers no direct transport service for a single node.

   o Each higher layer (client)
   network

   Transport Path Layer: A (sub-)layer network that provides
   point-to-point or point-to-multipoint transport paths.  It provides
   independent (of the client) OAM when transporting its clients.

   Unidirectional path: A path that supports traffic flow in only one
   direction.

   The term 'Domain Border Node' is associated with defined in [14] as follows:

   Domain Border Node: To be defined

   [Editor's note - There is no definition of Domain Border Node in RFC
   5151]

   The term 'Per-hop Behavior' is defined in [13] as follows:

   Per-hop Behavior: a single Maintenance Entity.

   o OAM packets are subject to description of the same externally observable
   forwarding treatment (e.g.
      fate share) as the data traffic, but they can be distinguished
      from applied at a differentiated services-compliant
   node to a behavior aggregate.

3. Functional Components

   MPLS-TP defines a profile of the data MPLS and PW architectures ([2], [5]
   and [7]) that is designed to transport service traffic using the GAL complying with
   certain performance and ACH constructs [9] for LSP quality requirements. In order to verify and
   maintain these performance and quality requirements, there is a need
   to not only apply OAM functionality on a transport path granularity
   (e.g. LSP or MS-PW), but also on arbitrary parts of transport paths,
   defined as Tandem Connections, between any two arbitrary points along
   a path.

   MPLS-TP OAM operates in the ACH construct [6] [9] for (MS-)PW.

3.2. context of Maintenance End Points (MEPs) Entities (MEs).

   A Maintenance Entity is the collection of two (or more) Maintenance
   End Points (MEPs) are the end points of a ME. and their association. The MEPs that form an ME are
   responsible for activating
   configured and controlling all of the OAM
   functionality for managed to limit the ME. A MEP may initiate scope of an OAM packet to be
   transferred flow within the
   ME the MEPs belong to its corresponding MEP, (i.e. within the domain of the transport path
   or to an intermediate MIP segment, in the specific layer network, that is part being monitored
   and managed).

   An example of the ME. an ME with more than two MEPs prevent OAM packets corresponding to is a point-to-multipoint
   ME from leaking outside
   that ME:

   o A monitoring a point-to-multipoint transport path (or point-to-
   multipoint tandem connection).

   Each MEP sink terminates all resides at the OAM packets boundaries of the ME that it receives
      corresponding to its they are part of.
   An ME and does not forward them further along may also include a set of zero or more Maintenance Intermediate
   Points (MIPs), which reside within the path. If Maintenance Entity, between
   the pro-active CC&CV OAM tool detects MEPs.

   MEPs and MIPs are associated with only one Maintenance Entity.

   The abstract reference model for a ME with MEPs and MIPs is described
   in Figure 1 below:

                            +-+    +-+    +-+    +-+
                            |A|----|B|----|C|----|D|
                            +-+    +-+    +-+    +-+

                   Figure 1 ME Abstract Reference Model

   The instantiation of this abstract model to different MPLS-TP
   entities is described in section 4. In this model, nodes A, B, C and
   D can be LER/LSR for an unintended
      connectivity, all traffic on LSP or the path is blocked (i.e. all
      received packets are dropped, including user-data packets).

   o {S|T}-PEs for a MS-PW. Nodes A MEP source tunnels all and
   D are MEPs while B and C are MIPs. The links connecting adjacent
   nodes can be either physical links or lower-level LSPs.

   This functional model defines the relationships between all OAM packets that it receives,
      upstream
   entities from the associated ME, via label stacking. These packets
      are not processed within the ME as they belong to another ME.

   [Editor's - Need to rephrase the bullet above to clarify what it
   actually means]

   MPLS-TP MEP notifies a fault indication maintenance perspective, to allow each Maintenance
   Entity to monitor and manage the MPLS-TP client layer
   network.

   A MEP of network under its
   responsibility and to localize problems efficiently.

   When a tandem connection control plane is not necessarily coincident with present, the
   termination of management plane configures
   MEPs and MIPs. Otherwise they can be configured either by the MPLS-TP transport path (LSP
   management plane or PW), though it can by the control plane.

3.1. Maintenance Entity

   A Maintenance Entity may be defined to monitor it for failures or fault and
   performance degradation (e.g. count
   packets) within the boundary of the management unidirectional point-to-point or point-to-
   multipoint transport paths or tandem connection.

   [Editor's note - The MEP connections, or co-routed
   bidirectional point-to-point transport paths and tandem connections
   in an MPLS-TP layer network.

   In case of associated bi-directional paths, two independent
   Maintenance Entities are define to independently monitor each
   direction.

   An MPLS-TP maintenance entity can be either the whole end-to-end
   transport path or a TCM monitors Tandem Connection of the transport paths'
   connectivity within path.

   The following properties apply to all MPLS-TP MEs:

   o They can be nested but not overlapped, e.g. a ME may cover a
      segment or a concatenated segment of another ME, and may also
      include the scope forwarding engine(s) of the TCM. This means that failures or
   performance degradations within node(s) at the TCM are detected by edge(s) of
      the TCM MEP
   while failures segment or performance degradations outside the TCM concatenated segment, but all its MEPs and MIPs are not
   detected by the TCM MEP.

   Is
      no longer part of the text above sufficient to explain this concept?]

   A MEP encompassing ME. It is possible that MEPs of an MPLS-TP transport path coincides with transport path
   termination and monitors it for failures or performance degradation
      nested MEs reside on an end-to-end scope (e.g. count packets). Note that both MEP
   source and MEP sink coincide with transport paths' source and sink
   terminations.

   [Editor's note - Add some text regarding MEP identification as well
   as about what a MEP should do if it receives an unexpected single node.

   o Each OAM
   packet]

3.3. Maintenance Intermediate Points (MIPs)

   A Maintenance Intermediate Point (MIP) flow is associated with a point between the two
   MEPs in an ME that is capable of reacting to some single Maintenance Entity.

   o OAM packets and
   forwarding all are subject to the other OAM packets while ensuring same forwarding treatment (e.g.
      fate sharing with share) as the data plane packets.  A MIP belongs to only one ME.

   A MIP does not initiate unsolicited OAM packets, traffic, but may they can be addressed
   by OAM packets initiated by one of distinguished
      from the MEPs of data traffic using the ME. A MIP can
   generate OAM packets only GAL and ACH constructs [9] for LSP
      and the ACH construct [6]and [9] for (MS-)PW.

3.2. Point-to-multipoint scenario

   The reference model for the p2mp scenario is represented in response to Figure 4.

                                                 +-+
                                              /--|D|
                                             /   +-+
                                          +-+
                                       /--|C|
                            +-+    +-+/   +-+\   +-+
                            |A|----|B|        \--|E|
                            +-+    +-+\   +-+    +-+
                                       \--|F|
                                          +-+

                     Figure 2 Reference Model for p2mp

   In case of p2mp transport paths, the OAM packets that measurements are sent on
   the ME it belongs to.

   [Editor's note different
   for each [Root, Leaf] relationship (A-D, A-E and A-F):

   o Fault conditions - It is needed to describe about how this depending from where the failure is achieved
   (e.g. TTL expiry). Is this description in located

   o Packet loss - depending from where the scope of this
   document?]

   MIPs packets are unaware of any OAM flows running between MEPs or between
   MEPs and other MIPs. MIPs can only receive lost

   o Packet delay - depending on different paths

   Each leaf (i.e. D, E and process F) terminates OAM packets
   addressed messages to monitor its
   own [Root, Leaf] relationship while the MIP itself.

   A MIP takes no action on root (i.e. A) generates OAM
   messages to monitor all the MPLS-TP [Root, Leaf] relationships of p2mp
   transport path.

   [Editor's note - Add some text Further considerations regarding MIP identification as well
   as about what the p2mp case will
   be added in a MIP should do if it receives an unexpected OAM
   packet]

3.4. Server MEPs

   A server MEP is a MEP future version of an ME that is either:

   o defined in a layer network below this document]

3.3. Maintenance End Points (MEPs)

   Maintenance End Points (MEPs) are the MPLS-TP layer network being
      referenced, or

   o defined in a sub-layer end points of the MPLS-TP layer network that is below
      the sub-layer being referenced.

   A server MEP coincides with either a MIP or a MEP in ME.

   In the client
   (MPLS-TP) layer network.

   For example, a server MEP can be either:

   o A termination point context of a physical link (e.g. 802.3), an SDH VC or
      OTH ODU for the MPLS-TP Section layer network, defined in section
      4.1. ;

   o An MPLS-TP Section MEP for MPLS-TP LSPs, defined in section 4.2. ;

   o An MPLS-TP LSP MEP for MPLS-TP PWs, defined LSP, only LERs can be MEPs while in section 4.4. ;

   o An MPLS-TP the
   context of an LSP Tandem Connection MEP for higher-level LTCMEs,
      defined in section 4.3. ;

   o An both LERs and LSRs can be MEPs.

   In the context of MPLS-TP PW, only T-PEs can be MEPs while in the
   context of a PW Tandem Connection MEP for higher-level PTCMEs,
      defined in section 0
   The server MEP both T-PEs and S-PEs can run appropriate OAM functions be MIPs.

   MEPs are responsible for fault detection
   within the server (sub-)layer network, activating and notifies a fault
   indication to controlling all of the MPLS-TP layer network.

4. Reference Model

   The reference model OAM
   functionality for the MPLS-TP framework builds upon the concept ME. A MEP is capable of an ME, initiating and its associated MEPs
   terminating OAM messages for fault management and MIPs, performance
   monitoring.

   MEPs prevent OAM packets corresponding to support the functional
   requirements specified in [11].

   The following MPLS-TP MEs are specified in this document:

   o A Section Maintenance Entity (SME), allowing monitoring and
      management of MPLS-TP Sections (between MPLS LSRs).

   o A LSP Maintenance Entity (LME), allowing monitoring and management
      of an end-to-end LSP (between LERs). a ME from leaking outside
   that ME:

   o A PW Maintenance Entity (PME), allowing monitoring and management
      of an end-to-end SS/MS-PWs (between T-PEs).

   o An LSP Tandem Connection Maintenance Entity (LTCME), allowing
      monitoring and management of an LSP Tandem Connection between any
      LER/LSR along MEP sink terminates all the LSP.

   o A MS-PW Tandem Connection Maintenance Entity (PTCME), allows
      monitoring OAM packets that it receives
      corresponding to its ME and management of a SS/MS-PW Tandem Connection between
      any T-PE/S-PE does not forward them further along
      the (MS-)PW.

   The MEs specified in this MPLS-TP framework are compliant with path. If the
   architecture framework for MPLS MS-PWs [7] and MPLS LSPs [2].

   Hierarchical LSPs pro-active CC-V OAM tool detects an unintended
      connectivity, all traffic on the path is blocked (i.e. all
      received packets are also supported. In this case, each LSP Tunnel dropped, including user-data packets).

   [Editor's note - Need to discuss whether to keep the last sentence in
   the hierarchy is a different sub-layer network bullet above regarding the MEP behavior in case of
   misconnections]

   o A MEP source tunnels all the OAM packets that can be
   monitored, independently it receives,
      upstream from higher and lower level LSP tunnels in the hierarchy, end-to-end (from LER to LER) by an LME. Tandem
   Connection monitoring associated ME, via LTCME label stacking. These packets
      are applicable on not processed within the ME as they belong to another ME.

   [Editor's - Need to rephrase the bullet above to clarify what it
   actually means]

   MPLS-TP MEP passes a fault indication to its client (sub-)layer
   network.

   A MEP of a tandem connection is not necessarily coincident with the
   termination of the MPLS-TP transport path (LSP or PW). Within the
   boundary of the tandem connection it can monitor the MPLS-TP
   transport path for failures or performance degradation (e.g. count
   packets).

   [Editor's note - The MEP of a TCM monitors the transport paths'
   connectivity within the scope of the TCM. This means that failures or
   performance degradations within the TCM are detected by the TCM MEP
   while failures or performance degradations outside the TCM are not
   detected by the TCM MEP.

   Improve the text above to explain this concept.]

   A MEP of an MPLS-TP transport path coincides with transport path
   termination and monitors it for failures or performance degradation
   (e.g. based on packet counts) in an end-to-end scope. Note that both
   MEP source and MEP sink coincide with transport paths' source and
   sink terminations.

   [Editor's note - Add some text regarding MEP identification as well
   as about what a MEP should do if it receives an unexpected OAM
   packet]

3.4. Maintenance Intermediate Points (MIPs)

   A Maintenance Intermediate Point (MIP) is a point between the two
   MEPs in an ME.

   In the context of an MPLS-TP LSP and LSP Tandem Connections, LSRs can
   be MIPs.

   In the context of MPLS-TP PW and PW Tandem Connection, S-PEs can be
   MIPs.

   A MIP is capable of reacting to some OAM packets and forwarding all
   the other OAM packets while ensuring fate sharing with data plane
   packets.

   A MIP does not initiate unsolicited OAM packets, but may be addressed
   by OAM packets initiated by one of the MEPs of the ME. A MIP can
   generate OAM packets only in response to OAM packets that are sent on
   the ME it belongs to.

   [Editor's note - It is needed to provide an high-level description
   about how this is achieved (e.g. TTL expiry).]

   MIPs are unaware of any OAM flows running between MEPs or between
   MEPs and other MIPs. MIPs can only receive and process OAM packets
   addressed to the MIP itself.

   A MIP takes no action on the MPLS-TP transport path.

   [Editor's note - Add some text regarding MIP identification as well
   as about what a MIP should do if it receives an unexpected OAM
   packet]

3.5. Server MEPs

   A server MEP is a MEP of an ME that is either:

   o defined in a layer network below the MPLS-TP layer network being
      referenced, or

   o defined in a sub-layer of the MPLS-TP layer network that is below
      the sub-layer being referenced.

   A server MEP can coincide with a MIP or a MEP in the client (MPLS-TP)
   layer network.

   A server MEP provides also client/server adaptation function between
   the client (MPLS-TP) layer network and the server layer network. As a
   consequence the server MEP is aware of the MPLS-TP transport paths
   that are setup over that server layer's transport path.

   For example, a server MEP can be either:

   o A termination point of a physical link (e.g. 802.3), an SDH VC or
      OTH ODU for the MPLS-TP Section layer network, defined in section
      4.1;

   o An MPLS-TP Section MEP for MPLS-TP LSPs, defined in section 4.2;

   o An MPLS-TP LSP MEP for MPLS-TP PWs, defined in section 4.4;

   o An MPLS-TP LSP Tandem Connection MEP for higher-level LTCMEs,
      defined in section 4.3;

   o An MPLS-TP PW Tandem Connection MEP for higher-level PTCMEs,
      defined in section 4.5.

   The server MEP can run appropriate OAM functions for fault detection
   within the server (sub-)layer network, and notifies a fault
   indication to its client MPLS-TP layer network. Server MEP OAM
   functions are outside the scope of this document.

4. Reference Model

   The reference model for the MPLS-TP framework builds upon the concept
   of an ME, and its associated MEPs and MIPs, to support the functional
   requirements specified in [11].

   The following MPLS-TP MEs are specified in this document:

   o A Section Maintenance Entity (SME), allowing monitoring and
      management of MPLS-TP Sections (between MPLS LSRs).

   o A LSP Maintenance Entity (LME), allowing monitoring and management
      of an end-to-end LSP (between LERs).

   o A PW Maintenance Entity (PME), allowing monitoring and management
      of an end-to-end SS/MS-PWs (between T-PEs).

   o An LSP Tandem Connection Maintenance Entity (LTCME), allowing
      monitoring and management of an LSP Tandem Connection between any
      LER/LSR along the LSP.

   o A MS-PW Tandem Connection Maintenance Entity (PTCME), allows
      monitoring and management of a SS/MS-PW Tandem Connection between
      any T-PE/S-PE along the (MS-)PW.

   The MEs specified in this MPLS-TP framework are compliant with the
   architecture framework for MPLS MS-PWs [7] and MPLS LSPs [2].

   Hierarchical LSPs are also supported. In this case, each LSP Tunnel
   in the hierarchy is a different sub-layer network that can be
   monitored independently from higher and lower level LSP tunnels in
   the hierarchy, end-to-end (from LER to LER) by an LME. Tandem
   Connection monitoring via LTCME are applicable on each LSP Tunnel Tunnel in
   the hierarchy.

           Native  |<------------------- MS-PW1Z ------------------->|  Native
           Layer   |                                                 |   Layer
          Service  |    |<-PSN13->|    |<-PSN3X->|    |<-PSNXZ->|    |  Service
           (AC1)   V    V   LSP   V    V   LSP   V    V   LSP   V    V   (AC2)
                   +----+   +-+   +----+         +----+   +-+   +----+
     +----+        |TPE1|   | |   |SPE3|         |SPEX|   | |   |TPEZ|       +----+
     |    |        |    |=========|    |=========|    |=========|    |       |    |
     | CE1|--------|........PW13.......|...PW3X..|........PWXZ.......|-------|CE2 |
     |    |        |    |=========|    |=========|    |=========|    |       |    |
     +----+        | 1  |   |2|   | 3  |         | X  |   |Y|   | Z  |       +----+
                   +----+   +-+   +----+         +----+   +-+   +----+
                   .                   .         .                   .
                   |                   |         |                   |
                   |<---- Domain 1 --->|         |<---- Domain Z --->|
                   .------------------- PW1Z  PME -------------------.
                   .---- PW13 PTCME ---.         .---- PWXZ PTCME ---.
                        .---------.                   .---------.
                         PSN13 LME                     PSNXZ LME

                        .---. .---.    .---------.    .---. .---.
                        Sec12 Sec23       Sec3X       SecXY SecYZ
                         SME   SME         SME         SME   SME

   TPE1: Terminating Provider Edge 1                 SPE2: Switching Provider Edge 3
   TPEX: Terminating Provider Edge X                 SPEZ: Switching Provider Edge Z

   .---. ME    .     MEP   ====   LSP      .... PW

           Figure 3 Reference Model for the MPLS-TP OAM Framework
   Figure 3 depicts a high-level reference model for the MPLS-TP OAM
   framework. The figure depicts portions of two MPLS-TP enabled network
   domains, Domain 1 and Domain Z. In Domain 1, LSR1 is adjacent to LSR2
   via the MPLS Section Sec12 and LSR2 is adjacent to LSR3 via the MPLS
   Section Sec23. Similarly, in Domain Z, LSRX is adjacent to LSRY via
   the MPLS Section SecXY and LSRY is adjacent to LSRZ via the MPLS
   Section SecYZ. In addition, LSR3 is adjacent to LSRX via the MPLS
   Section 3X.

   Figure 3 also shows a bi-directional MS-PW (PW1Z) between AC1 on TPE1
   and AC2 on TPEZ. The MS-PW consists of three bi-directional PW
   Segments: 1) PW13 segment between T-PE1 and S-PE3 via the bi-
   directional PSN13 LSP, 2) PW3X segment between S-PE3 and S-PEX, and
   3) PWXZ segment between S-PEX and T-PEZ via the bi-directional PSNXZ
   LSP.

   The MPLS-TP OAM procedures that apply to an instance of a given ME
   are expected to operate independently from procedures on other
   instances of the same ME and certainly of other MEs. Yet, this does
   not preclude that multiple MEs may be affected simultaneously by the
   same network condition, for example, a fibre cut event.

   Note that there are no constrains imposed by this OAM framework on
   the number, or type, of MEs that may be instantiated on a particular
   node. In particular, when looking at Figure 1, it should be possible
   to configure one or more MEPs on the same node if that node is the
   endpoint of one or more MEs.

   Figure 3 does not describe a PW3X PTCME because typically TCMs are
   used to monitor an OAM domain (like PW13 and PWXZ PTCMEs)   rather
   than the segment between two OAM domains. However the OAM framework
   does not pose any constraints on the way TCM are instantiated as long
   as they are not overlapping.

   The subsections below define the MEs specified in this MPLS-TP OAM
   architecture  framework  document.  Unless  otherwise  stated,  all
   references to domains, LSRs, MPLS Sections, LSP, pseudowires and MEs
   in this Section are made in relation to those shown in Figure 3.

4.1. MPLS-TP Section Monitoring

   An MPLS-TP Section ME (SME) is an MPLS-TP maintenance entity intended
   to monitor the forwarding behaviour of an MPLS Section as defined in
   [10]. An SME may be configured on any MPLS section. SME OAM packets
   fate share with the user data packets sent over the monitored MPLS
   Section.

   [Editor's note - Is OAM monitoring only the forwarding behaviour? If
   not, we need to clarify what it is monitoring]

   An SME is intended to be deployed for applications where it is
   preferable to monitor the link between topologically adjacent (next
   hop in this layer network) MPLS (and MPLS-TP enabled) LSRs rather
   than monitoring the individual LSP or PW segments traversing the MPLS
   Section and the server layer technology does not provide adequate OAM
   capabilities.

                   |<------------------- MS-PW1Z ------------------->|
                   |                                                 |
                   |    |<-PSN13->|    |<-PSN3X->|    |<-PSNXZ->|    |
                   V    V   LSP   V    V   LSP   V    V   LSP   V    V
                   +----+   +-+   +----+         +----+   +-+   +----+
     +----+        |TPE1|   | |   |SPE3|         |SPEX|   | |   |TPEZ|       +----+
     |    |  AC1   |    |=========|    |=========|    |=========|    |  AC2  |    |
     | CE1|--------|........PW13.......|...PW3X..|.......PWXZ........|-------|CE2 |
     |    |        |    |=========|    |=========|    |=========|    |       |    |
     +----+        | 1  |   |2|   | 3  |         | X  |   |Y|   | Z  |       +----+
                   +----+   +-+   +----+         +----+   +-+   +----+

                        .--.  .--.     .--------.     .--.  .--.
                        Sec12 Sec23       Sec3X       SecXY SecYZ
                         SME   SME         SME         SME   SME

          Figure 4 Reference Example of MPLS-TP Section MEs (SME)

   Figure 4 shows 5 Section MEs configured in the path between AC1 and
   AC2: 1) Sec12 ME associated with the MPLS Section between LSR 1 and
   LSR 2, 2) Sec23 ME associated with the MPLS Section between LSR 2 and
   LSR 3, 3) Sec3X ME associated with the MPLS Section between LSR 3 and
   LSR X, 4) SecXY ME associated with the MPLS Section between LSR X and
   LSR Y, and 5) SecYZ ME associated with the MPLS Section between LSR Y
   and LSR Z.

4.2. MPLS-TP LSP End-to-End Monitoring

   An MPLS-TP LSP ME (LME) is an MPLS-TP maintenance entity intended to
   monitor the forwarding behaviour of an end-to-end LSP between two
   (e.g., a point-to-point LSP) or more (e.g., a point-to-multipoint
   LSP) LERs. An LME may be configured on any MPLS LSP. LME OAM packets
   fate share with user data packets sent over the monitored MPLS-TP
   LSP.

   An LME is intended to be deployed in scenarios where it is desirable
   to monitor the forwarding behaviour of an entire LSP between its
   LERs, rather than, say, monitoring individual PWs.

                   |<------------------- MS-PW1Z ------------------->|
                   |                                                 |
                   |    |<-PSN13->|    |<-PSN3X->|    |<-PSNXZ->|    |
                   V    V   LSP   V    V   LSP   V    V   LSP   V    V
                   +----+   +-+   +----+         +----+   +-+   +----+
     +----+        |TPE1|   | |   |SPE3|         |SPEX|   | |   |TPEZ|       +----+
     |    |  AC1   |    |=========|    |=========|    |=========|    |  AC2  |    |
     | CE1|--------|........PW13.......|...PW3X..|........PWXZ.......|-------|CE2 |
     |    |        |    |=========|    |=========|    |=========|    |       |    |
     +----+        | 1  |   |2|   | 3  |         | X  |   |Y|   | Z  |       +----+
                   +----+   +-+   +----+         +----+   +-+   +----+

                        .---------.                   .---------.
                         PSN13 LME                     PSNXZ LME

                Figure 5 Examples of MPLS-TP LSP MEs (LME)

   Figure 5 depicts 2 LMEs configured in the path between AC1 and AC2:
   1) the PSN13 LME between LER 1 and LER 3, and 2) the PSNXZ LME
   between LER X and LER Y. Note that the presence of a PSN3X LME in
   such a configuration is optional, hence, not precluded by this
   framework. For instance, the SPs may prefer to monitor the MPLS-TP
   Section between the two LSRs rather than the individual LSPs.

4.3. MPLS-TP LSP Tandem Connection Monitoring

   An MPLS-TP LSP Tandem Connection Monitoring ME (LTCME) is an MPLS-TP
   maintenance entity intended to monitor the forwarding behaviour of an
   arbitrary part of an LSP between a given pair of LSRs independently
   from the end-to-end monitoring (LME). An LTCME can monitor an LSP
   segment  or  concatenated  segment  and  it  may  also  include  the
   forwarding engine(s) of the node(s) at the edge(s) of the segment or
   concatenated segment.

   Multiple LTCMEs MAY be configured on any LSP. The LSRs that terminate
   the LTCME may or may not be immediately adjacent at the MPLS-TP
   layer. LTCME OAM packets fate share with the user data packets sent
   over the monitored LSP segment.

   A LTCME can be defined between the following entities:

        o LER and any LSR of a given LSP.

        o Any two LSRs of a given LSP.

   An LTCME is intended to be deployed in scenarios where it is
   preferable to monitor the behaviour of a part of an LSP rather than
   the entire LSP itself, for example when there is a need to monitor a
   part of an LSP that extends beyond the administrative boundaries of
   an MPLS-TP enabled administrative domain.

   Note that LTCMEs are equally applicable to hierarchical LSPs.

                   |<--------------------- PW1Z -------------------->|
                   |                                                 |
                   |    |<--------------PSN1Z LSP-------------->|    |
                   |    |<-PSN13->|    |<-PSN3X->|    |<-PSNXZ->|    |
                   V    V  S-LSP  V    V  S-LSP  V    V  S-LSP  V    V
                   +----+   +-+   +----+         +----+   +-+   +----+
     +----+        | PE1|   | |   |DBN3|         |DBNX|   | |   | PEZ|       +----+
     |    |  AC1   |    |=======================================|    |  AC2  |    |
     | CE1|--------|......................PW1Z.......................|-------|CE2 |
     |    |        |    |=======================================|    |       |    |
     +----+        | 1  |   |2|   | 3  |         | X  |   |Y|   | Z  |       +----+
                   +----+   +-+   +----+         +----+   +-+   +----+
                   .                   .         .                   .
                   |                   |         |                   |
                   |<---- Domain 1 --->|         |<---- Domain Z --->|

                        .---------.                   .---------.
                        PSN13 LTCME                   PSNXZ LTCME
                        .---------------------------------------.
                                        PSN1Z LME

   DBN: Domain Border Node

        Figure 6 MPLS-TP LSP Tandem Connection Monitoring ME (LTCME)

   Figure 6 depicts a variation of the reference model in Figure 3 where
   there is an end-to-end PSN LSP (PSN1Z LSP) between PE1 and PEZ. PSN1Z
   LSP consists of, at least, three stitched LSP Segments: PSN13, PSN3X
   and PSNXZ. In this scenario there are two separate LTCMEs configured
   to monitor the forwarding behaviour of the PSN1Z LSP: 1) a LTCME
   monitoring the PSN13 LSP Segment on Domain 1 (PSN13 LTCME), and 2) a
   LTCME monitoring the PSNXZ LSP Segment on Domain Z (PSNXZ LTCME).

   It is worth noticing that LTCMEs can coexist with the LME monitoring
   the end-to-end LSP and that LTCME MEPs and LME MEPs can be coincident
   in the same node (e.g. PE1 node supports both the PSN1Z LME MEP and
   the PSN13 LTCME MEP).

4.4. MPLS-TP PW Monitoring

   An MPLS-TP PW ME (PME) is an MPLS-TP maintenance entity intended to
   monitor the end-to-end forwarding behaviour of a SS-PW or MS-PW
   between a pair of T-PEs. A PME MAY be configured on any SS-PW or MS-
   PW. PME OAM packets fate share with the user data packets sent over
   the monitored PW.

   A PME is intended to be deployed in scenarios where it is desirable
   to monitor the forwarding behaviour of an entire PW between a pair of
   MPLS-TP enabled T-PEs rather than monitoring the LSP aggregating
   multiple PWs between PEs.

                   |<------------------- MS-PW1Z ------------------->|
                   |                                                 |
                   |    |<-PSN13->|    |<-PSN3X->|    |<-PSNXZ->|    |
                   V    V   LSP   V    V   LSP   V    V   LSP   V    V
                   +----+   +-+   +----+         +----+   +-+   +----+
     +----+        |TPE1|   | |   |SPE3|         |SPEX|   | |   |TPEZ|       +----+
     |    |  AC1   |    |=========|    |=========|    |=========|    |  AC2  |    |
     | CE1|--------|........PW13.......|...PW3X..|........PWXZ.......|-------|CE2 |
     |    |        |    |=========|    |=========|    |=========|    |       |    |
     +----+        | 1  |   |2|   | 3  |         | X  |   |Y|   | Z  |       +----+
                   +----+   +-+   +----+         +----+   +-+   +----+

                   .---------------------PW1Z PME--------------------.

                       Figure 7 MPLS-TP PW ME (PME)

   Figure 7 depicts a MS-PW (MS-PW1Z) consisting of three segments:
   PW13, PW3X and PWXZ and its associated end-to-end PME (PW1Z PME).

4.5. MPLS-TP MS-PW Tandem Connection Monitoring

   An MPLS-TP MS-PW Tandem Connection Monitoring ME (PTCME) is an MPLS-
   TP maintenance entity intended to monitor the forwarding behaviour of
   an  arbitrary  part  of  an  MS-PW  between  a  given  pair  of  PEs
   independently from the end-to-end monitoring (PME). An PTCME can
   monitor a PW segment or concatenated segment and it may alos include
   the forwarding engine(s) of the node(s) at the edge(s) of the segment
   or concatenated segment.

   Multiple PTCMEs MAY be configured on any MS-PW. The PEs may or may
   not be immediately adjacent at the MS-PW layer. PTCME OAM packets
   fate share with the user data packets sent over the monitored PW
   Segment.

   A PTCME can be defined between the following entities:

   o T-PE and any S-PE of a given MS-PW

   o Any two S-PEs of a given MS-PW. It can span several PW segments.

   A PTCME is intended to be deployed in scenarios where it is
   preferable to monitor the hierarchy.

           Native behaviour of a part of a MS-PW rather than
   the entire end-to-end PW itself, for example to monitor an MS-PW
   Segment within a given network domain of an inter-domain MS-PW.

                   |<------------------- MS-PW1Z ------------------->|  Native
           Layer
                   |                                                 |   Layer
          Service
                   |    |<-PSN13->|    |<-PSN3X->|    |<-PSNXZ->|    |  Service
           (AC1)
                   V    V   LSP   V    V   LSP   V    V   LSP   V    V   (AC2)
                   +----+   +-+   +----+         +----+   +-+   +----+
     +----+        |TPE1|   | |   |SPE3|         |SPEX|   | |   |TPEZ|       +----+
     |    |  AC1   |    |=========|    |=========|    |=========|    |  AC2  |    |
     | CE1|--------|........PW13.......|...PW3X..|........PWXZ.......|-------|CE2 |
     |    |        |    |=========|    |=========|    |=========|    |       |    |
     +----+        | 1  |   |2|   | 3  |         | X  |   |Y|   | Z  |       +----+
                   +----+   +-+   +----+         +----+   +-+   +----+
                   .                   .         .                   .
                   |                   |         |                   |
                   |<----

                   .---- PW1 PTCME ----.         .---- PW5 PTCME ----.
                   .---------------------PW1Z PME--------------------.

        Figure 8 MPLS-TP MS-PW Tandem Connection Monitoring (PTCME)

   Figure 8 depicts the same MS-PW (MS-PW1Z) between AC1 and AC2 as in
   Figure 7. In this scenario there are two separate PTCMEs configured
   to monitor the forwarding behaviour of MS-PW1Z: 1) a PTCME monitoring
   the PW13 MS-PW Segment on Domain 1 --->|         |<---- (PW13 PTCME), and 2) a PTCME
   monitoring the PWXZ MS-PW Segment on Domain Z --->|
                   .------------------- with (PWXZ PTCME).

   It is worth noticing that PTCMEs can coexist with the PME monitoring
   the end-to-end MS-PW and that PTCME MEPs and PME MEPs can be
   coincident in the same node (e.g. TPE1 node supports both the PW1Z
   PME -------------------.
                   .---- MEP and the PW13 PTCME ---.         .---- PWXZ PTCME ---.
                        .---------.                   .---------.
                         PSN13 LME                     PSNXZ LME

                        .---. .---.    .---------.    .---. .---.
                        Sec12 Sec23       Sec3X       SecXY SecYZ
                         SME   SME         SME         SME   SME

   TPE1: Terminating Provider Edge 1                 SPE2: Switching Provider Edge 3
   TPEX: Terminating Provider Edge X                 SPEZ: Switching Provider Edge Z

   .---. MEP).

5. OAM Functions for pro-active monitoring

5.1. Continuity Check and Connectivity Verification

   [Editor's note - There is a need to decide whether pro-active CC and
   CV functions need to be combined in the same tool or separated into
   different tools. This version of the document combines the two
   functions. Future versions will be aligned with the decision taken
   about whether to combine or not CC and CV.]

   Proactive Continuity Check and Connectivity Verification (CC-V)
   functions are used to detect a loss of continuity (LOC), an
   unexpected connectivity between two MEs (e.g. mismerging or
   misconnection), as well as unexpected connectivity within the ME    . with
   an unexpected MEP.

   Execution of proactive CC-V is based on the (proactive) generation of
   CC-V OAM packets by the source MEP   ====   LSP      .... PW

           Figure 1 Reference Model for that are processed by the MPLS-TP sink
   MEP.  Each CC-V OAM Framework

   Figure 1 depicts packet MUST include a high-level reference model for the MPLS-TP OAM
   framework. globally unique ME
   identifier, and MUST be transmitted at a regular, operator's
   configurable, rate. The figure depicts portions of two MPLS-TP enabled default CC-V transmission periods are
   application dependent (see section 5.1.4).

   Proactive CC-V OAM packets are transmitted with the "minimum loss
   probability PHB" within a single network
   domains, Domain 1 and Domain Z. In Domain 1, LSR 1 operator. This PHB is adjacent to LSR
   2 via
   configurable on network operator's basis. PHBs can be translated at
   the MPLS Section Sec12 network borders.

   [Editor's note - Describe the relation between the previous paragraph
   and LSR2 is adjacent to LSR3 via the
   MPLS Section Sec23. Similarly, fate sharing requirement. Need to clarify also in Domain Z, LSR X the
   requirement document that for proactive CC-V the fate sharing is adjacent
   related to LSR
   Y via the MPLS Section SecXY forwarding behavior and LSR Y is adjacent not to LSR Z via the
   MPLS Section SecYZ. QoS behavior]

   In addition, LSR 3 a bidirectional point-to-point transport path, when a MEP is adjacent
   enabled to LSR X via the
   MPLS Section 3X.

   Figure 1 also shows generate pro-active CC-V OAM packets with a bi-directional MS-PW (MS-PW1Z) between AC1 on
   LSR 1 (TPE1) and AC2 on LSR Z (TPEZ). The MS-PW consists of 3 bi-
   directional PW Segments: 1) PW Segment 13 (PW13) between LSR 1 (TPE1)
   and LSR 3 (SPE3) via configured
   transmission rate, it also expects to receive pro-active CC-V OAM
   packets from its peer MEP at the bi-directional PSN13 LSP, 2) PW Segment 3X
   (PW3X) between LSR 3 (SPE3) and LSR X (SPEX), and 3) PW Segment XZ
   (PWXZ) between LSR X (SPEX) same transmission rate. In a
   unidirectional transport path (either point-to-point or point-to-
   multipoint), only the source MEP is enabled to generate CC-V OAM
   packets and LSR Z (TPEZ) via only the bi-directional
   PSNXZ LSP.

   The sink MEP is configured to expect these packets
   at the configured rate.

   MIPs, as well as intermediate nodes not supporting MPLS-TP OAM procedures that apply OAM, are
   transparent to an instance of the pro-active CC-V information and forward these pro-
   active CC-V OAM packets as regular data packets.

   To initialize the proactive CC-V monitoring on a given configured ME
   are expected
   without affecting traffic, the MEP source function (generating pro-
   active CC-V packets) should be enabled prior to operate independently from procedures on other
   instances of the same ME corresponding MEP
   sink function (detecting continuity and certainly of other MEs. Yet, this does
   not preclude that multiple MEs may connectivity defects).  When
   disabling the CC-V proactive functionality, the MEP sink function
   should be affected simultaneously by disabled prior to the
   same network condition, for example, corresponding MEP source function.

5.1.1. Defects identified by CC-V

   Pro-active CC-V functions allow a fiber cut event.

   Note that sink MEP to detect the following
   defect conditions.

   For all of these defect cases, the sink MEP SHOULD notify the
   equipment fault management process of the detected defect.

   [Editor's note - Investigate whether in case there are no constrains imposed by this OAM framework is a
   misconfiguration on the number, or type, of MEs that may minimum loss probability PHB on the two MEPs
   a defect can be instantiated useful to notify the misconfiguration to the
   operator.]

5.1.1.1. Loss Of Continuity defect

   When proactive CC-V is enabled, a particular
   node. In particular, sink MEP detects a loss of
   continuity (LOC) defect when looking at Figure 1, it should be possible fails to configure one or more MEPs receive pro-active CC-V OAM
   packets from the same node if the same node is peer MEP.

   o Entry criteria:  if no pro-active CC-V OAM packets from the endpoint of one or more MEs.

   The subsections below define peer
      MEP (i.e. with the MEs specified in this MPLS-TP OAM
   architecture  framework  document.  Unless  otherwise  stated,  all
   references to domains, LSRs, MPLS Sections, LSP, pseudowires correct ME and MEs
   in this Section peer MEP identifiers) are made in relation
      received within the interval equal to those shown in Figure 1.

4.1. MPLS-TP Section Monitoring

   An MPLS-TP Section 3.5 times the receiving
      MEP's configured CC-V transmission period.

   o Exit criteria: a pro-active CC-V OAM packet from the peer MEP
      (i.e. with the correct ME (SME) and peer MEP identifiers) is received.

5.1.1.2. Mis-connectivity defect

   When a pro-active CC-V OAM packet is received, a sink MEP identifies
   a mis-connectivity defect (e.g. mismerge or misconnection) with its
   peer source MEP when the received packet carries an MPLS-TP maintenance entity intended
   to monitor incorrect ME
   identifier.

   o Entry criteria: the forwarding behaviour of sink MEP receives a pro-active CC-V OAM packet
      with an MPLS Section as defined in
   [10]. An SME may be configured on incorrect ME ID.

   o Exit criteria: the sink MEP does not receive any MPLS section. SME pro-active CC-V
      OAM packets
   fate share packet with the user data packets sent over the monitored MPLS
   Section.

   An SME is intended to be deployed an incorrect ME ID for applications where it is
   preferable an interval equal at least
      to monitor 3.5 times the link between longest transmission period of the topologically adjacent
   (next hop in pro-active
      CC-V OAM packets received with an incorrect ME ID since this layer network) MPLS (and MPLS-TP enabled) LSRs
   rather than monitoring
      defect has been raised.

5.1.1.3. MEP misconfiguration defect

   When a pro-active CC-V packet is received, a sink MEP identifies a
   MEP misconfiguration defect with its peer source MEP when the individual LSP or PW segments traversing
   received packet carries a correct ME Identifier but an unexpected
   peer MEP Identifier which includes the MPLS Section and MEP's own MEP Identifier.

   o Entry criteria: the server layer technology sink MEP receives a CC-V pro-active packet
      with correct ME ID but with unexpected MEP ID.

   o Exit criteria: the sink MEP does not provide
   adequate receive any pro-active CC-V
      OAM capabilities.

                   |<------------------- MS-PW1Z ------------------->|
                   |                                                 |
                   |    |<-PSN13->|    |<-PSN3X->|    |<-PSNXZ->|    |
                   V    V   LSP   V    V   LSP   V    V   LSP   V    V
                   +----+   +-+   +----+         +----+   +-+   +----+
     +----+        |TPE1|   | |   |SPE3|         |SPEX|   | |   |TPEZ|       +----+
     |    |  AC1   |    |=========|    |=========|    |=========|    |  AC2  |    |
     | CE1|--------|........PW13.......|...PW3X..|.......PWXZ........|-------|CE2 |
     |    |        |    |=========|    |=========|    |=========|    |       |    |
     +----+        | 1  |   |2|   | 3  |         | X  |   |Y|   | Z  |       +----+
                   +----+   +-+   +----+         +----+   +-+   +----+

                        .--.  .--.     .--------.     .--.  .--.
                        Sec12 Sec23       Sec3X       SecXY SecYZ
                         SME   SME         SME         SME   SME

          Figure 2 Reference Example packet with a correct ME ID and unexpected MEP ID for an
      interval equal at least to 3.5 times the longest transmission
      period of MPLS-TP Section MEs (SME)

   Figure 2 shows 5 Section MEs configured in the path between AC1 and
   AC2: 1) Sec12 ME associated pro-active CC-V OAM packets received with the MPLS Section between LSR 1 and
   LSR 2, 2) Sec23 a correct
      ME associated with the MPLS Section between LSR 2 ID and
   LSR 3, 3) Sec3X unexpected MEP ID since this defect has been raised.

5.1.1.4. Period Misconfiguration defect

   If pro-active CC-V OAM packets is received with a correct ME associated and MEP
   identifiers but with a transmission period different than its own
   configured transmission period, then a CC-V period mis-configuration
   defect is detected

   o Entry criteria: a MEP receives a CC-V pro-active packet with the MPLS Section between LSR 3 and
   LSR X, 4) SecXY
      correct ME associated with the MPLS Section between LSR X ID and
   LSR Y, and 5) SecYZ ME associated MEP ID but with a Period field value different
      than its own CC-V configured transmission period.

   o Exit criteria: the MPLS Section between LSR Y
   and LSR Z.

4.2. MPLS-TP LSP End-to-End Monitoring

   An MPLS-TP LSP sink MEP does not receive any pro-active CC-V
      OAM packet with a correct ME (LME) is and MEP IDs and an MPLS-TP maintenance entity intended incorrect
      transmission period for an interval equal at least to
   monitor 3.5 times
      the forwarding behaviour longest transmission period of an end-to-end LSP between two
   (e.g., a point-to-point LSP) or more (e.g., a point-to-multipoint
   LSP) LERs. An LME may be configured on any MPLS LSP. LME the pro-active CC-V OAM packets
   fate share
      received with user data packets sent over the monitored MPLS-TP
   LSP.

   An LME is intended to be deployed in scenarios where it is desirable
   to monitor the forwarding behaviour of an entire LSP between its
   LERs, rather than, say, monitoring individual PWs.

                   |<------------------- MS-PW1Z ------------------->|
                   |                                                 |
                   |    |<-PSN13->|    |<-PSN3X->|    |<-PSNXZ->|    |
                   V    V   LSP   V    V   LSP   V    V   LSP   V    V
                   +----+   +-+   +----+         +----+   +-+   +----+
     +----+        |TPE1|   | |   |SPE3|         |SPEX|   | |   |TPEZ|       +----+
     |    |  AC1   |    |=========|    |=========|    |=========|    |  AC2  |    |
     | CE1|--------|........PW13.......|...PW3X..|........PWXZ.......|-------|CE2 |
     |    |        |    |=========|    |=========|    |=========|    |       |    |
     +----+        | 1  |   |2|   | 3  |         | X  |   |Y|   | Z  |       +----+
                   +----+   +-+   +----+         +----+   +-+   +----+

                        .---------.                   .---------.
                         PSN13 LME                     PSNXZ LME

                Figure 3 Examples a correct ME and MEP IDs and an incorrect
      transmission period since this defect has been raised.

5.1.2. Consequent action

   A sink MEP that detects one of MPLS-TP LSP MEs (LME)

   Figure 3 depicts 2 LMEs configured the defect conditions defined in
   section 5.1.1 MUST perform the path between AC1 and AC2:
   1) following consequent actions. Some of
   these consequent actions SHOULD be enabled/disabled by the PSN13 LME between LER 1 and LER 3, operator
   depending upon the application used (see section 5.1.4).

   If a MEP detects an unexpected ME Identifier, or an unexpected MEP,
   it MUST block all the traffic (including also the user data packets)
   that it receives from the misconnected transport path.

   If a MEP detects LOC defect and 2) the PSNXZ LME CC-V monitoring is enabled it
   SHOULD block all the traffic (including also the user data packets)
   that it receives from the transport path if this consequent action
   has been enabled by the operator.

   It is worth noticing that the OAM requirements document [11]
   recommends that CC-V proactive monitoring is enabled on every ME in
   order to reliably detect connectivity defects. However, CC-V
   proactive monitoring MAY be disabled by an operator on a ME. In the
   event of a misconnection between LER X and LER Y. Note a transport path that is pro-
   actively monitored for CC-V and a transport path which is not, the presence
   MEP of the former transport path will detect a PSN3X LME in
   such LOC defect
   representing a configuration connectivity problem (e.g. a misconnection with a
   transport path where CC-V proactive monitoring is optional, hence, not precluded by this
   framework. enabled)
   instead of a continuity problem, with a consequent wrong traffic
   delivering. For instance, these reasons, the traffic block consequent action is
   applied even when a LOC condition occurs. This block consequent
   action MAY be disabled through configuration. This deactivation of
   the SPs block action, may prefer to monitor the MPLS-TP
   Section between the two LSRs rather than be used for activating or deactivating the individual LSPs.

4.3. MPLS-TP LSP Tandem Connection Monitoring

   An MPLS-TP LSP Tandem Connection Monitoring ME (LTCME)
   monitoring when it is an MPLS-TP
   maintenance entity intended not possible to monitor synchronize the forwarding behaviour function
   activation of the two peer MEPs.

   If a MEP detects a LOC defect, an
   arbitrary part of unexpected ME Identifier, or an LSP between
   unexpected MEP it MUST declare a given pair of LSRs independently
   from signal fail condition at the end-to-end monitoring (LME). An LTCME can monitor
   transport path level.

   If a MEP detects an LSP
   segment  or  concatenated  segment  and Unexpected Period defect it  may  also  include  the
   forwarding engine(s) of the node(s) SHOULD declare a
   signal fail condition at the edge(s) of transport path level.

   [Editor's note - Transport equipment also performs defect correlation
   (as defined in G.806) in order to properly report failures to the segment or
   concatenated segment.

   Multiple LTCMEs MAY BE configured on any LSP.
   transport NSM. The LSRs that terminate
   the LTCME may or may not be immediately adjacent at the MPLS-TP
   layer. LTCME OAM packets fate share with the user data packets sent
   over the monitored LSP segment.

   A LTCME can current working assumption, to be defined between further
   investigated, is that defect correlations are outside the following entities:

        o LER and any LSR of a given LSP.

        o Any two LSRs scope of a given LSP.

   An LTCME is intended
   this document and to be deployed defined in scenarios where it ITU-T documents.]

5.1.3. Configuration considerations

   At all MEPs inside a ME, the following configuration information need
   to be configured when pro-active CC-V function is
   preferable enabled:

   o ME ID; the ME identifier to monitor which the behaviour MEP belongs;

   o MEP-ID; the MEP's own identity inside the ME;
   o list of peer MEPs inside the ME. For a part point-to-point ME the list
      would consist of an LSP rather than the entire LSP itself, for example when there is a need to monitor a
   part single peer MEP ID from which the OAM packets
      are expected. In case of an LSP that extends beyond the administrative boundaries root MEP of
   an MPLS-TP enabled administrative domain.

   Note that LTCMEs are equally applicable to hierarchical LSPs.

                   |<--------------------- PW1Z -------------------->|
                   |                                                 |
                   |    |<--------------PSN1Z LSP-------------->|    |
                   |    |<-PSN13->|    |<-PSN3X->|    |<-PSNXZ->|    |
                   V    V  S-LSP  V    V  S-LSP  V    V  S-LSP  V    V
                   +----+   +-+   +----+         +----+   +-+   +----+
     +----+        | PE1|   | |   |DBN3|         |DBNX|   | |   | PEZ|       +----+
     |    |  AC1   |    |=======================================|    |  AC2  |    |
     | CE1|--------|......................PW1Z.......................|-------|CE2 |
     |    |        |    |=======================================|    |       |    |
     +----+        | 1  |   |2|   | 3  |         | X  |   |Y|   | Z  |       +----+
                   +----+   +-+   +----+         +----+   +-+   +----+
                   .                   .         .                   .
                   |                   |         |                   |
                   |<---- Domain 1 --->|         |<---- Domain Z --->|

                        .---------.                   .---------.
                        PSN13 LTCME                   PSNXZ LTCME
                        .---------------------------------------.
                                        PSN1Z LME

   DBN: Domain Border Node

        Figure 4 MPLS-TP LSP Tandem Connection Monitoring ME (LTCME)

   Figure 4 depicts a variation of p2mp ME, the reference model in Figure 1 where
   there list is an end-to-end PSN LSP (PSN1Z LSP) between PE1 and PEZ. PSN1Z
   LSP consists of, at least, three stitched LSP Segments: PSN13, PSN3X
   and PSNXZ. In this scenario there are two separate LTCMEs configured
   to monitor
      composed by all the forwarding behaviour of leaf MEP IDs inside the PSN1Z LSP: 1) a LTCME
   monitoring ME. In case of the PSN13 LSP Segment on Domain 1 (PSN13 LTCME), and 2)
      leaf MEP of a
   LTCME monitoring p2mp ME, the PSNXZ LSP Segment on Domain Z (PSNXZ LTCME).

   It list is worth noticing that LTCMEs can coexist with composed by the LME monitoring root MEP ID
      (i.e. each leaf MUST know the end-to-end LSP and that LTCME MEPs and LME MEPs root MEP ID from which it expect to
      receive the CC-V OAM packets).

   o transmission rate; the default CC-V transmission periods are
      application dependent (see section 5.1.4)

   o PHB; it identifies the per-hop behaviour of CC-V packet. Proactive
      CC-V packets are transmitted with the "minimum loss probability
      PHB" previously configured within a single network operator. This
      PHB is configurable on network operator's basis. PHBs can be coincident
   in
      translated at the same node (e.g. PE1 node supports both network borders.

   For statically provisioned transport paths the PSN1Z LME MEP and above information are
   statically configured; for dynamically established transport paths
   the PSN13 LTCME MEP).

4.4. MPLS-TP PW Monitoring

   An MPLS-TP PW ME (PME) configuration information are signaled via the control plane.

5.1.4. Applications for proactive CC-V

   CC-V is an MPLS-TP maintenance entity intended applicable for fault management, performance monitoring, or
   protection switching applications.

   o Fault Management: default transmission period is 1s (i.e.
      transmission rate of 1 packet/second)

   o Performance Monitoring: default transmission period is 100ms (i.e.
      transmission rate of 10 packets/second)

   o Protection Switching: in order to achieve sub-50ms recovery time
      the default transmission period is 3.33ms (i.e. transmission rate
      of 300 packets/second) although a transmission period of 10ms can
      also be used. In some cases, when a slower recovery time is
      acceptable, it is also possible to
   monitor lengthen the end-to-end forwarding behaviour of a SS-PW or MS-PW
   between a pair of T-PEs. A PME MAY transmission rate.

   It SHOULD be configured on any SS-PW or MS-
   PW. PME OAM packets fate share with the user data packets sent over possible for the monitored PW.

   A PME is intended operator to configure these
   transmission rates for all applications, to satisfy his internal
   requirements.

   In addition, the operator should be deployed in scenarios where it is desirable able to monitor define the forwarding behaviour consequent
   action to be performed for each of these applications.

5.2. Remote Defect Indication

   The Remote Defect Indication (RDI) is an entire PW between a pair of
   MPLS-TP enabled T-PEs rather than monitoring the LSP aggregating
   multiple PWs between PEs.

                   |<------------------- MS-PW1Z ------------------->|
                   |                                                 |
                   |    |<-PSN13->|    |<-PSN3X->|    |<-PSNXZ->|    |
                   V    V   LSP   V    V   LSP   V    V   LSP   V    V
                   +----+   +-+   +----+         +----+   +-+   +----+
     +----+        |TPE1|   | |   |SPE3|         |SPEX|   | |   |TPEZ|       +----+
     |    |  AC1   |    |=========|    |=========|    |=========|    |  AC2  |    |
     | CE1|--------|........PW13.......|...PW3X..|........PWXZ.......|-------|CE2 |
     |    |        |    |=========|    |=========|    |=========|    |       |    |
     +----+        | 1  |   |2|   | 3  |         | X  |   |Y|   | Z  |       +----+
                   +----+   +-+   +----+         +----+   +-+   +----+

                   .---------------------PW1Z PME--------------------.

                       Figure 5 MPLS-TP PW ME (PME)

   Figure 5 depicts indicator that is
   transmitted by a MS-PW (MS-PW1Z) consisting of three segments:
   PW13, PW3X and PWXZ and MEP to communicate to its associated end-to-end PME (PW1Z PME).

4.5. MPLS-TP MS-PW Tandem Connection Monitoring

   An MPLS-TP MS-PW Tandem Connection Monitoring ME (PTCME) peer MEPs that a signal
   fail condition exists.  RDI is only used for bidirectional
   connections and is an MPLS-
   TP maintenance entity intended to monitor associated with proactive CC-V activation. The RDI
   indicator is piggy-backed onto the forwarding behaviour of
   an  arbitrary  part  of  an  MS-PW  between CC-V packet.

   When a  given  pair MEP detects a signal fail condition (e.g. in case of  PEs
   independently from the end-to-end monitoring (PME). An PTCME can
   monitor a PW segment
   continuity or concatenated segment and connectivity defect or an AIS condition is detected),
   it may alos include should begin transmitting an RDI indicator to its peer MEP.  The
   RDI information will be included in all pro-active CC-V packets that
   it generates for the forwarding engine(s) duration of the node(s) at signal fail condition's
   existence.

   [Editor's note - Add some forward compatibility information to cover
   the edge(s) of case where future OAM mechanisms that contributes to the segment
   or concatenated segment.

   Multiple PTCMEs MAY be configured on any MS-PW. The PEs may or may
   not be immediately adjacent at signal
   fail detection (and RDI generation) are defined.]

   A MEP that receives the MS-PW layer. PTCME OAM packets
   fate share with the user data RDI information should
   determine that its peer MEP has encountered a defect condition
   associated with a signal fail.

   MIPs as well as intermediate nodes not supporting MPLS-TP OAM are
   transparent to the RDI indicator and forward these proactive CC-V
   packets sent over that include the monitored MS-PW
   Segment.

   A PTCME can be defined between RDI indicator as regular data packets, i.e.
   the following entities:

   o T-PE and MIP should not perform any S-PE of a given MS-PW

   o Any two S-PEs actions nor examine the indicator.

   When the signal fail defect condition clears, the MEP should clear
   the RDI indicator from subsequent transmission of a given MS-PW. It can span several PW segments. pro-active CC-V
   packets.  A PTCME is intended to be deployed in scenarios where it is
   preferable to monitor MEP should clear the behaviour RDI defect upon reception of a pro-
   active CC-V packet from the source MEP with the RDI indicator
   cleared.

5.2.1. Configuration considerations

   In order to support RDI indication, the RDI transmission rate and PHB
   of the MEP should be configured as part of a MS-PW rather than the entire end-to-end PW itself, CC-V configuration.

5.2.2. Applications for example to monitor Remote Defect Indication

   RDI is applicable for the following applications:

   o Single-ended fault management - A MEP that receives an MS-PW
   Segment within RDI
      indication from its peer MEP, can report a given network domain of an inter-domain MS-PW.

                   |<------------------- MS-PW1Z ------------------->|
                   |                                                 |
                   |    |<-PSN13->|    |<-PSN3X->|    |<-PSNXZ->|    |
                   V    V   LSP   V    V   LSP   V    V   LSP   V    V
                   +----+   +-+   +----+         +----+   +-+   +----+
     +----+        |TPE1|   | |   |SPE3|         |SPEX|   | |   |TPEZ|       +----+
     |    |  AC1   |    |=========|    |=========|    |=========|    |  AC2  |    |
     | CE1|--------|........PW13.......|...PW3X..|........PWXZ.......|-------|CE2 |
     |    |        |    |=========|    |=========|    |=========|    |       |    |
     +----+        | 1  |   |2|   | 3  |         | X  |   |Y|   | Z  |       +----+
                   +----+   +-+   +----+         +----+   +-+   +----+

                   .---- PW1 PTCME ----.         .---- PW5 PTCME ----.
                   .---------------------PW1Z PME--------------------.

        Figure 6 MPLS-TP MS-PW Tandem Connection Monitoring (PTCME)

   Figure 6 depicts far-end defect
      condition (i.e. the same MS-PW (MS-PW1Z) between AC1 and AC2 as peer MEP has detected a signal fail condition
      in
   Figure 5. In this scenario there are two separate PTCMEs configured the traffic direction from the MEP that receives the RDI
      indication to monitor the forwarding behaviour of MS-PW1Z: 1) a PTCME monitoring peer MEP that has sent the PW13 MS-PW Segment on Domain 1 (PW13 PTCME), and 2) a PTCME RDI information).

   o Contribution to far-end performance monitoring - The indication of
      the PWXZ MS-PW Segment on Domain Z with (PWXZ PTCME).

   It far-end defect condition is worth noticing that PTCMEs can coexist with used as a contribution to the PME
      bidirectional performance monitoring process.

5.3. Alarm Reporting

   Alarm Reporting function relies upon an Alarm Indication Signal (AIS)
   message used to suppress alarms following detection of defect
   conditions at the end-to-end MS-PW and server (sub) layer.

   o A server MEP that PTCME MEPs and PME MEPs detects a signal fail conditions in the server
      (sub-)layer, can be
   coincident generate packets with AIS information in a
      direction opposite to its peers MEPs to allow the same node (e.g. TPE1 node supports both suppression of
      secondary alarms at the PW1Z
   PME MEP and in the PW13 PTCME MEP).

5. OAM Functions client (sub-)layer.

   A server MEP is responsible for pro-active monitoring

5.1. Continuity Check and Connectivity Verification

   Proactive Continuity and Connectivity Verification (CC & CV) function notifying the MPLS-TP layer network
   MEP upon fault detection in the server layer network to which the
   server MEP is used associated.

   Only Server MEPs can issue MPLS-TP packets with AIS information. Upon
   detection of a signal fail condition the Server MEP can immediately
   start transmitting periodic packets with AIS information. These
   periodic packets, with AIS information, continue to detect be transmitted
   until the signal fail condition is cleared.

   Upon receiving a packet with AIS information an MPLS-TP MEP detects
   an AIS defect condition and suppresses loss of continuity (LOC), unexpected connectivity
   between two MEs (e.g. mismerging or misconnection) as well as
   unexpected connectivity within the ME alarms
   associated with an unexpected MEP.

   Proactive CC & CV is based all its peer MEPs.  A MEP resumes loss of continuity
   alarm generation upon detecting loss of continuity defect conditions
   in the generation absence of OAM pro-active
   CC/CV packets, carrying a unique ME identifier, at AIS condition.

   For example, let's consider a regular
   configurable timing rate fiber cut between LSR 1 and LSR 2 in
   the detection reference network of LOC when these packets
   do not arrive. If the received ME identifier does not match Figure 3. Assuming that all the
   expected ME identifier, MEs
   described in Figure 3 have pro-active CC-V enabled, a connectivity LOC defect has occurred. The
   default CC/CV transmission periods are application dependent (see
   section 5.1.1. )

   Proactive CC & CV packets are transmitted with the "minimum loss
   probability PHB" within a single network operator. This PHB is
   configurable on network operator's basis.

   [Editor's note - Describe the relation between
   detected by the previous paragraph MEPs of Sec12 SME, PSN13 LME, PW1 PTCME and the fate sharing requirement. Need to clarify also PW1Z PME,
   however in transport network only the
   requirement document that for proactive CC&CV the fate sharing is
   related alarm associate to the forwarding behavior and not fiber
   cut needs to the QoS behavior]

   For statically provisioned transport paths, the transmission period
   and the ME identifier are statically configured at both MEPs. For
   dynamically established transport paths, the transmission period and
   the ME identifier are signaled via the control plane.

   In a bidirectional point-to-point transport path, when a MEP is
   enabled be reported to generate pro-active CC/CV packets with a configured
   transmission period, it also expects NMS while all these secondary alarms
   should be suppressed (i.e. not reported to receive pro-active CC/CV
   packets from its peer MEP with the same transmission period. In a
   unidirectional transport path (point-to-point NMS or point-to-
   multipoint), only reported as
   secondary alarms).

   If the source MEP fiber cut is enabled to detected by the MEP in the physical layer (in
   LSR2), LSR2 can generate packets the proper alarm in the physical layer and
   suppress the secondary alarm associated with
   CC/CV information. This MEP the LOC defect detected
   on Sec12 SME. As both MEPs reside within the same node, this process
   does not expect to receive involve any packets
   with CC/CV information from its peer MEPs in external protocol exchange. Otherwise, if the ME.

   MIPs as well as intermediate nodes
   physical layer has not supporting MPLS-TP enough OAM are
   transparent capabilities to detect the pro-active CC/CV information and forward pro-
   active CC/CV packets as regular data packets.

   When CC & CV is enabled, fiber
   cut, the MEP of Sec12 SME in LSR2 will report a LOC alarm.

   In both cases, the MEP periodically transmits pro-active
   CC/CV of Sec12 SME in LSR 2 generates AIS packets with frequency on
   the PSN13 LME in order to allow its MEP in LSR3 to suppress the LOC
   alarm.

   LSR3 can also suppress the secondary alarm on PW1 PTCME because the
   MEP of PW1 PTCME resides within the same node as the configured transmission period.

   When CC & CV is enabled, a MEP detects loss of continuity (LOC)
   defect with a peer PSN13
   LME.

   The MEP when it receives no pro-active CC/CV of PW1 PTCME in LSR3 also generates AIS packets on PW1Z PME
   in order to allow its MEP in LSRZ to suppress the LOC alarm.

   The generation of AIS packets
   from for each MEs in the peer MEP within client (sub-)layer
   is configurable (i.e. the interval equal to 3.5 times operator can enable/disable the
   transmission period.

   When AIS
   generation).

   AIS packets are transmitted with the "minimum loss probability PHB"
   within a pro-active CC/CV packet single network operator. This PHB is received, a MEP configurable on network
   operator's basis.

   A MIP is able transparent to detect a
   mis-connectivity defect (e.g. mismerge or misconnection) with another
   ME when the received packet carries an incorrect ME identifier.

   If pro-active CC/CV packets are received with a transmission period
   different than expected, CC/CV period mis-configuration defect is
   detected. AIS information and therefore
   does not require any information to support AIS functionality.

5.4. Lock Reporting

   [Editor's note - Need Requirements for Lock Indication and Lock Reporting
   are still under discussion in draft-ietf-mpls-tp-oam-requirement-02.

   Lock Indication is not required by draft-ietf-mpls-tp-oam-
   requirement-02 This section will be aligned according to add the defect clearing conditions and
   complete final
   decision regarding the description requirement.]
   To be incorporated in a future revision of consequent actions] this document

5.5. Lock Indication

   [Editor's note - Transport equipment also performs defect correlation
   (as defined in G.806) Requirements for Lock Indication and Lock Reporting
   are still under discussion in order to properly report failures draft-ietf-mpls-tp-oam-requirement-02.

   Lock Indication is not required by draft-ietf-mpls-tp-oam-
   requirement-02 This section will be aligned according to the
   transport NSM. final
   decision regarding the requirement.]

   The current working assumption, to be further
   investigated, Locked Indication Signal (LIS) is that defect correlations are outside the scope of
   this document and used to be defined in ITU-T documents.]

   A receiving propagate an
   administrative locking of a source MEP notifies the equipment fault management process when
   it detects and consequential interruption
   of data forwarding towards the above sink MEP. It allows a sink MEP
   receiving LIS to differentiate between a defect conditions.

   If condition and an
   administrative locking action at the source MEP. An example
   application that requires administrative locking of a MEP detects an unexpected connectivity it MUST block all is the
   traffic (including also out-
   of-service test.

5.6. Packet Loss

   Packet Loss (LM) is one of the user data packets) that it receives from capabilities supported by the misconnected MPLS-TP
   Performance Monitoring (PM) function in order to facilitate reporting
   of QoS information for a transport path.

   It is worth noticing that the OAM requirements document [11]
   recommends that CC-CV proactive monitoring LM is enabled on every ME in
   order used to reliably detect connectivity defects.

   However, CC-CV proactive monitoring can be disabled exchange
   counter values for the number of ingress and egress packets
   transmitted and received by an operator on
   a ME. In this case a LOC defect can be a connectivity problem (e.g. a
   misconnection with a the transport path where CC-CV proactive monitoring monitored by a pair of
   MEPs.

   Pro-active LM is not enabled) and not necessarily performed by periodically sending LM OAM packets
   from a continuity problem, with MEP to a
   consequent wrong traffic delivering.

   For these reasons, peer MEP and by receiving LM OAM packets from the traffic block consequent action is applied
   even when
   peer MEP (if a LOC condition occurs.

   The activation of the traffic block consequent action is configurable
   (i.e. bidirectional transport path) during the operator can enable/disable life time of
   the consequent action) in case transport path. Each MEP performs measurements of LOC condition.

   In order its transmitted
   and received packets. These measurements are then correlated to enable
   derive the proactive CC-CV monitoring impact of packet loss on a configured ME
   in number of performance metrics
   for the transport path.

   For a not traffic affecting way, MEP, near-end packet loss refers to packet loss associated with
   incoming data packets (from the MEP source function (generating
   pro-active CC&CV packets) should be enabled before far-end MEP) while far-end packet
   loss refers to packet loss associated with egress data packets
   (towards the far-end MEP).

5.6.1. Configuration considerations

   In order to support pro-active LM, the corresponding
   MEP sink function (detecting continuity transmission rate and connectivity defects).
   Vice versa, when disabling PHB
   associated with the CC-CV proactive functionality, LM OAM packets originating from a MEP
   sink function need be
   configured as part of the LM provisioning procedures. LM OAM packets
   should be disabled before transmitted with the corresponding MEP source
   function.

   If it is not possible to synchronize both direction on PHB that yields the peer MEPs, lowest packet loss
   performance among the traffic can be preserved even disabling/re-enabling PHB Scheduling Classes or Ordered Aggregates
   (see RFC 3260 [14]) in the traffic
   block consequent action due to a LOC defect.

5.1.1. monitored transport path for the relevant
   network domain(s).

5.6.2. Applications for proactive CC & CV function

   CC & CV Packet Loss

   LM is applicable relevant for fault management, performance monitoring,
   or protection switching applications.

   o Fault Management: default transmission period is 1s (i.e.
      transmission rate of 1 packet/second) the following applications:

   o Performance Monitoring: default transmission period is 100ms (i.e.
      transmission rate Single or double-end performance monitoring: determination of 10 packets/second)

   o Protection Switching: in order to achieve sub-50ms recovery time the default transmission period is 3.33ms (i.e. transmission rate
      packet loss performance of 300 packets/second) although a transmission period transport path for SLS verification
      purposes.

   o Single or double-end performance monitoring: determination of 10ms can
      also be used. In some cases, when a slower recovery time is
      acceptable, it is also possible to relax the transmission period.

5.2. Remote Defect Indication

   The Remote Defect Indication (RDI) is an indicator that is
   transmitted by
      packet loss performance of a MEP to communicate to its peer MEPs that PHB Scheduling Class or Ordered
      Aggregate within a signal
   fail condition exists.  RDI is only used for bidirectional
   connections transport path

   o Contribution to service unable time. Both near-end and is associated with proactive CC & CV far-end
      packet
   generation.

   A MEP detects a signal fail condition (and thus starts transmitting
   an RDI indication loss measurements contribute to performance metrics such as
      near-end severely errored seconds (Near-End SES) and far-end
      severely errored seconds (Far-End SES) respectively, which
      together contribute to its peer MEP) unavailable time, in case of a continuity or
   connectivity defect or an AIS condition manner similar to
      Recommendation G.826 [19] and Recommendation G.7710 [20].

5.7. Client Failure Indication

   The Client Failure Indication (CSF) function is detected.

   [Editor's note - Add some forward compatibility information used to cover help process
   client defects and propagate a client signal defect condition from
   the case process associated with the local attachment circuit where future OAM mechanisms that contributes to the signal
   fail detection (and RDI generation) are defined.]

   A sink MEP that has identified a signal fail should report this
   defect was detected (typically the source adaptation function for the
   local client interface) to the process associated with the far-end
   attachment circuit (typically the source MEP that should include adaptation function for the RDI information in
   all pro-active CC/CV packets that it generates
   far-end client interface) for the duration same transmission path in case the
   client of the signal fail condition existence. transmission path does not support a native
   defect/alarm indication mechanism, e.g. FDI/AIS.

   A source MEP that receives the packets with the RDI information should
   determine that starts transmitting a CSF indication to its peer MEP has encountered a defect condition
   associated with
   when it receives a local client signal fail.

   MIPs as well as intermediate nodes not supporting MPLS-TP OAM are
   transparent defect notification via its
   local CSF function. Mechanisms to the RDI indicator and forward pro-active CC/CV packets
   that include the RDI indicator as regular data packets, i.e. the MIP
   should not perform any actions nor examine the indicator.

   When the detect local client signal fail defect condition clears, the MEP should clear
   the RDI indicator from subsequent transmission of pro-active CC/CV
   packets.
   defects are technology specific.

   A sink MEP also clears the RDI defect upon reception of that has received a pro-active CC/CV
   packet from the source MEP with CSF indication report this condition
   to its associated client process via its local CSF function.
   Consequent actions toward the RDI indicator cleared.

5.2.1. client attachment circuit are
   technology specific.

5.7.1. Configuration considerations

   In order to support RDI RCSF indication, the RDI CSF transmission rate and
   PHB of the MEP CSF OAM packet should be configured as part of the CC & CV CSF
   configuration.

5.2.2.

5.7.2. Applications for Remote Defect Indication

   RDI

   CSF is applicable for the following applications:

   o Single-ended fault management - A MEP that receives an RDI a CSF
      indication from its peer MEP, can report a far-end client defect
      condition (i.e. the peer MEP has detected a been informed of local client
      signal fail condition in the traffic direction from the MEP that receives the RDI
      indication client to
      the peer MEP that has sent transmitted the RDI information). CSF).

   o Contribution to far-end performance monitoring - The indication of
      the far-end defect condition is may be used as a to account on network
      operator contribution to the bidirectional performance monitoring
      process.

5.3. Alarm Suppression

   Alarm Indication Signal

   CSF supports the application described in Appendix VIII of ITU-T
   G.806 [18].

5.8. Delay Measurement

   Delay Measurement (DM) is one of the capabilities supported by the
   MPLS-TP PM function (AIS) in order to facilitate reporting of QoS
   information for a transport path. Specifically, pro-active DM is used
   to suppress alarms
   following detection of defect conditions at measure the server (sub) layer.

   o A server MEP that detects a signal fail conditions long-term packet delay and packet delay variation in
   the server
      (sub-)layer, can generate transport path monitored by a pair of MEPs.

   Pro-active DM is performed by sending periodic DM OAM packets with AIS information from a
   MEP to allow
      the suppression of secondary alarms at a peer MEP and by receiving DM OAM packets from the peer MEP
   (if a bidirectional transport path) during a configurable time
   interval.

   Pro-active DM can be operated in the client (sub-
      )layer.

   A server two ways:

   o One-way: a MEP is responsible for notifying the MPLS-TP layer network sends DM OAM packet to its peer MEP upon fault detection in containing all
      the server layer network required information to which facilitate one-way packet delay and/or
      one-way packet delay variation measurements at the
   server peer MEP.

   o Two-way: a MEP is associated.

   Only Server MEPs can issue MPLS-TP packets sends DM OAM packet with AIS information. Upon
   detection of a signal fail condition the Server MEP can immediately
   start transmitting packets DM request to its peer
      MEP, which replies with AIS an DM OAM packet as a DM response. The
      request/response DM OAM packets containing all the required
      information periodically. A
   Server MEP continues to transmit periodic packets with AIS
   information until facilitate two-way packet delay and/or two-way
      packet delay variation measurements from the viewpoint of the
      source MEP.

5.8.1. Configuration considerations

   In order to support pro-active DM, the signal fail condition is cleared.

   Upon receiving a packet with AIS information a MEP detects an AIS
   defect condition transmission rate and suppresses loss of continuity alarms PHB
   associated with all its peer MEPs.  A the DM OAM packets originating from a MEP resumes loss need be
   configured as part of continuity alarm
   generation upon detecting the LM provisioning procedures. DM OAM packets
   should be transmitted with the PHB that yields the lowest packet loss of continuity defect conditions in
   performance among the
   absence of AIS condition.

   For example a fiber cut between LSR 1 and LSR 2 PHB Scheduling Classes or Ordered Aggregates
   (see RFC 3260 [14]) in the reference monitored transport path for the relevant
   network domain(s).

5.8.2. Applications for Packet Loss

   DM is relevant for the following applications:

   o Single or double-end performance monitoring: determination of Figure 1 can be considered. Assuming that all the MEs
   described in Figure 1 have pro-active CC&CV enable,
      delay performance of a LOC defect is
   detected by transport path for SLS verification
      purposes.

   o Single or double-end performance monitoring: determination of the MEPs
      delay performance of Sec12 SME, PSN13 LME, PW1 PTCME and PW1Z PME,
   however in a PHB Scheduling Class or Ordered Aggregate
      within a transport network only the alarm associate to the fiber
   cut needs path

6. OAM Functions for on-demand monitoring

6.1. Connectivity Verification

   In order to preserve network resources, e.g. bandwidth, processing
   time at switches, it may be reported preferable to NMS while all these secondary alarms
   should be suppressed (i.e. not reported use pro-active CC-V.
   In order to the NMS or reported as
   secondary alarms).

   If the fiber cut perform fault management functions network management may
   invoke periodic on-demand bursts of on-demand CV packets.  Use of on-
   demand CV is detected by dependent on the MEP in existence of a bi-directional
   connection ME, because it requires the physical layer (in
   LSR2), LSR2 can generate presence of a return path in
   the proper alarm data plane.

   [Editor's note - Clarify in the physical layer sentence above and
   suppress the secondary alarm associated with the LOC defect detected
   on Sec12 SME. As both MEPs reside within the same node, this process
   does not involve any external protocol exchange. Otherwise, if
   paragraph that on-demand CV requires a return path to send back the
   physical layer has not enough OAM capabilities
   reply to on-demand CV packets]

   An additional use of on-demand CV would be to detect the fiber
   cut, the MEP and locate a
   problem of Sec12 SME in LSR2 will report connectivity when a LOC alarm. problem is suspected or known based on
   other tools.  In both cases, this case the MEP of Sec12 SME in LSR 2 generates AIS packets on functionality will be triggered by the PSN13 LME in order to allow its MEP
   network management in LSR3 response to suppress the LOC
   alarm.

   LSR3 can also suppress the secondary a status signal or alarm on PW1 PTCME because the
   MEP
   indication.

   On-demand CV is based upon generation of PW1 PTCME resides within the same node as on-demand CV packets that
   should uniquely identify the ME that is being checked.  The on-demand
   functionality may be used to check either an entire ME (end-to-end)
   or between a MEP to a specific MIP.

   On-demand CV may generate a one-time burst of PSN13
   LME. on-demand CV packets,
   or be used to invoke periodic, non-continuous, bursts of on-demand CV
   packets.  The number of packets generated in each burst is
   configurable at the MEPs, and should take into account normal packet-
   loss conditions.

   When invoking a periodic check of the ME, the source MEP should issue
   a burst of PW1 PTCME in LSR3 also generates AIS on-demand CV packets on PW1Z PME
   in order to allow its MEP in LSRZ to suppress that uniquely identifies the LOC alarm. ME being
   verified.  The generation number of AIS packets for each MEs in and their transmission rate should
   be pre-configured and known to both the client (sub-)layer
   is configurable (i.e. source MEP and the operator can enable/disable target MEP
   or MIP.  The source MEP should use the AIS
   generation).

   AIS packets are transmitted with TTL field to indicate the "minimum loss probability PHB"
   within
   number of hops necessary, when targeting a single network operator. This PHB is configurable on network
   operator's basis.

   A MIP and use the default
   value when performing an end-to-end check [IB => This is transparent to quite
   generic for addressing packets with AIS information to MIPs and therefore
   does not require any information MEPs so it is better to support AIS functionality.

5.4. Lock Indication

   To be incorporated in a future revision of this document

5.5. Packet Loss Measurement

   To be incorporated in a future revision of
   move this document

5.6. Client Signal Fail

   To be incorporated text in section 2].  The target MEP/MIP shall return a future revision of this document

6. OAM Functions for on-demand monitoring

6.1. Continuity Check and Connectivity Verification

   In order to preserve network resources, e.g. bandwidth, processing
   time at switches, it may be preferable to not use continual pro-
   active CC & CV.  In order to perform fault management functions
   network management may invoke periodic on-demand bursts of
   reply on-demand
   CC/CV packets.  Use CV packet for each packet received.  If the expected
   number of on-demand CC & CV reply packets is dependent on the
   existence of not received at source MEP, a bi-directional connection ME.

   An additional use
   LOC state is detected.

   [Editor's note - We need to add some text for the usage of on-demand CC &
   CV would be with different packet sizes, e.g. to detect and locate discover MTU problems.]

   When a problem of connectivity when a problem is suspected or known based detected (e.g. via a pro-active CC-V
   OAM tool), on other tools.  In this case the functionality will demand CV tool can be triggered by used to check the network management in response path.  The
   series should check CV from MEP to peer MEP on the path, and if a status signal or alarm
   indication.

   On-demand CC & CV
   fault is based upon generation discovered, by lack of response, then additional checks may
   be performed to each of the intermediate MIP to locate the fault.

6.1.1. Configuration considerations

   For on-demand CC/CV CV the MEP should support configuration of number of
   packets
   that to be transmitted/received in each burst of transmissions and
   their packet size. The transmission rate should uniquely identify be either pre-
   configured or negotiated between the ME that different nodes.

   In addition, when the CV packet is being checked.  The on-
   demand functionality may be used to check either an entire ME (end-
   to-end) or between connectivity toward
   a MEP target MIP, the number of hops to a specific MIP.

   On-demand CC & reach the target MIP should be
   configured.

   The PHB of the on-demand CV may generate a one-time burst packets should be configured as well.

   [Editor's note - We need to be better define the reason for such
   configuration]

6.2. Packet Loss

   On-demand Packet Loss (LM) is one of the capabilities supported by
   the MPLS-TP Performance Monitoring function in order to facilitate
   diagnostic of QoS performance for a transport path. As Pro-active LM,
   on-demand CC/CV
   packets, or be LM is used to invoke periodic, non-continuous, bursts of on-
   demand CC/CV packets.  The exchange counter values for the number of
   ingress and egress packets generated in each burst
   is configurable at the MEPs, transmitted and should take into account normal
   packet-loss conditions.

   When invoking received by the transport
   path monitored by a periodic check pair of MEPs.

   On-demand LM is performed by periodically sending LM OAM packets from
   a MEP to a peer MEP and by receiving LM OAM packets from the ME, the source peer MEP should issue
   (if a burst bidirectional transport path) during a pre-defined monitoring
   period. Each MEP performs measurements of on-demand CC/CV packets that uniquely identifies its transmitted and
   received packets. These measurements are then correlated evaluate the ME
   being verified.  The number
   packet loss performance metrics of packets the transport path.

6.2.1. Configuration considerations

   In order to support on-demand LM, the beginning and their duration of the
   LM procedures,the transmission rate
   should be pre-configured and known to both PHB associated with the source LM
   OAM packets originating from a MEP and must be configured as part of the
   target MEP or MIP.  The source MEP
   on-demand LM provisioning procedures. LM OAM packets should use be
   transmitted with the PHB that yields the lowest packet loss
   performance among the PHB Scheduling Classes or Ordered Aggregates
   (see RFC 3260 [14]) in the monitored transport path for the relevant
   network domain(s).

6.2.2. Applications for On-demand Packet Loss

   On-demand LM is relevant for the following applications:

   o Single-end performance monitoring: diagnostic of the packet loss
      performance of a transport path for SLS trouble shooting purposes.

   o Single-end performance monitoring: diagnostic of the packet loss
      performance of a PHB Scheduling Class or Ordering Aggregate within
      a transport path for QoS trouble shooting purposes.

6.3. Diagnostic

   To be incorporated in a future revision of this document

6.4. Route Tracing

   To be incorporated in a future revision of this document

6.5. Delay Measurement

   Delay Measurement (DM) is one of the TTL field to
   indicate capabilities supported by the number
   MPLS-TP PM function in order to facilitate reporting of hops necessary, when targeting a MIP and use
   the default value when performing an end-to-end check [IB => This is
   quite generic QoS
   information for addressing packets to MIPs and MEPs so it is better
   to move this text in section 2].  The target MEP/MIP shall return a
   reply transport path. Specifically, on-demand CC/CV DM is used
   to measure packet for each delay and packet received.  If delay variation in the
   expected number of on-demand CC/CV reply packets is not received at
   source MEP, transport
   path monitored by a LOC state is detected.

   [Editor's note - We need to add some text for the usage pair of on-demand
   CC&CV with different packet sizes, e.g. to discover MTU problems.]

   When MEPs during a connectivity problem pre-defined monitoring
   period.

   On-Demand DM is detected (e.g. via a pro-active CC&CV performed by sending periodic DM OAM tool), on demand CC&CV tool can be used to check the path.  The
   series should check CC&CV packets from a
   MEP to a peer MEP on the path, and if a
   fault is discovered, by lack of response, then additional checks may receiving DM OAM packets from the peer MEP
   (if a bidirectional transport path) during a configurable time
   interval.

   On-demand DM can be performed operated in two ways:

   o One-way: a MEP sends DM OAM packet to each of its peer MEP containing all
      the intermediate MIP required information to locate the fault.

6.1.1. Configuration considerations

   For on-demand CC & CV facilitate one-way packet delay and/or
      one-way packet delay variation measurements at the peer MEP.

   o Two-way: a MEP should support configuration of number
   of packets sends DM OAM packet with a DM request to be transmitted/received in each burst of transmissions
   and the transmission rate should be either pre-configured or
   negotiated between the different nodes.

   In addition, when the CC & CV its peer
      MEP, which replies with an DM OAM packet is  used to check connectivity
   toward as a target MIP, DM response. The
      request/response DM OAM packets containing all the number of hops required
      information to reach facilitate two-way packet delay and/or two-way
      packet delay variation measurements from the target MIP
   should be configured.

   The PHB viewpoint of the
      source MEP.

6.5.1. Configuration considerations

   In order to support on-demand CC/CV DM, the beginning and duration of the
   DM procedures, the transmission rate and PHB associated with the DM
   OAM packets should originating from a MEP need be configured as well.

   [Editor's note - We need to part of the
   LM provisioning procedures. DM OAM packets should be better define transmitted with
   the reason PHB that yields the lowest packet delay performance among the PHB
   Scheduling Classes or Ordering Aggregates (see RFC 3260 [14]) in the
   monitored transport path for such
   configuration]

6.2. Packet Loss the relevant network domain(s).

6.5.2. Applications for Delay Measurement

   To be incorporated in a future revision

   DM is relevant for the following applications:

   o Single or double-end performance monitoring: determination of this document

6.3. Diagnostic Test

   To be incorporated in a future revision the
      packet delay and/or delay variation performance of this document

6.4. Trace routing

   To be incorporated in a future revision transport
      path for SLS verification purposes.

   o Single or double-end performance monitoring: determination of this document

6.5. the
      packet delay and/or delay variation a PHB Scheduling Class or
      Ordering Aggregate within a transport path

   o Contribution to service unable time. Packet Delay Measurement delay measurements may
      contribute to performance metrics such as near-end severely
      errored seconds (Near-End SES) and far-end severely errored
      seconds (Far-End SES), which together contribute to unavailable
      time.

6.6. Lock Instruct

   To be incorporated in a future revision of this document

7. OAM Protocols Overview

   To be incorporated in a future revision of this document

8. Security Considerations

   A number of security considerations important in the context of OAM
   applications.

   OAM traffic can reveal sensitive information such as passwords,
   performance data and details about e.g. the network topology. The
   nature of OAM data therefore suggests to have some form of
   authentication, authorization and encryption in place. This will
   prevent unauthorized access to vital equipment and it will prevent
   third parties from learning about sensitive information about the
   transport network.

   Mechanisms that the framework does not specify might be subject to
   additional security considerations.

9.

8. IANA Considerations

   No new IANA considerations.

10.

9. Acknowledgments

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

   This document was prepared using 2-Word-v2.0.template.dot.

11.

10. References

11.1.

10.1. Normative References

   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
   [2]  Rosen, E., Viswanathan, A., Callon, R., "Multiprotocol Label
         Switching Architecture", RFC 3031, January 2001

   [3]  Rosen, E., et al., "MPLS Label Stack Encoding", RFC 3032,
         January 2001

   [4]  Agarwal, P., Akyol, B., "Time To Live (TTL) Processing in
         Multi-Protocol Label Switching (MPLS) Networks", RFC 3443,
         January 2003

   [5]  Bryant, S., Pate, P., "Pseudo Wire Emulation Edge-to-Edge
   [6]  Nadeau, T., Pignataro, S., "Pseudowire Virtual Circuit
         Connectivity Verification (VCCV): A Control Channel for
         Pseudowires", RFC 5085, December 2007

   [7]  Bocci, M., Bryant, S., "An Architecture for Multi-Segment
         Pseudo Wire Emulation Edge-to-Edge", draft-ietf-pwe3-ms-pw-
         arch-05 (work in progress), September 2008

   [8]  Bocci, M., et al., "A Framework for MPLS in Transport
         Networks", draft-ietf-mpls-tp-framework-00 draft-ietf-mpls-tp-framework-01 (work in progress),
         November 2008
   [9]  Vigoureux, M., Bocci, M., Swallow, G., Ward, D., Aggarwal, R.,
         "MPLS Generic Associated Channel ", draft-ietf-mpls-tp-gach-
         gal-02 (work in progress), February 2009

11.2.

10.2. Informative References

   [10] Niven-Jenkins, B., Brungard, D., Betts, M., sprecher, N., Ueno,
         S., "MPLS-TP Requirements", draft-ietf-mpls-tp-requirements-05 draft-ietf-mpls-tp-requirements-09
   [11] Vigoureux, M., Betts, M., Ward, D., "Requirements for OAM in
         MPLS Transport Networks", draft-ietf-mpls-tp-oam-requirements-
   [12] Sprecher, N., Nadeau, T., van Helvoort, H., Weingarten, Y.,
         "MPLS-TP OAM Analysis", draft-sprecher-mpls-tp-oam-analysis-02
         (work in progress), September 2008 draft-sprecher-mpls-tp-oam-analysis-04
   [13] Nichols, K., Blake, S., Baker, F., Black, D., "Definition of
         the Differentiated Services Field (DS Field) in the IPv4 and
         IPv6 Headers", RFC 2474, December 1998

   [14] Grossman, D., "New terminology and clarifications for
         Diffserv", RFC 3260, April 2002.

   [15] Farrel, A., Ayyangar, A., Vasseur, JP., "Inter-Domain MPLS and
         GMPLS Traffic Engineering -- Resource Reservation Protocol-
         Traffic Engineering (RSVP-TE) Extensions", RFC 5151, February
         2008

   [14]

   [16] ITU-T Recommendation G.707/Y.1322 (01/07), "Network node
         interface for the synchronous digital hierarchy (SDH)", January
         2007

   [17] ITU-T Recommendation G.805 (03/00), "Generic functional
   [18] ITU-T Recommendation G.806 (01/09), "Characteristics of
         transport equipment - Description methodology and generic
         functionality ", January 2009

   [19] ITU-T Recommendation G.826 (12/02), "End-to-end error
         performance parameters and objectives for international,
         constant bit-rate digital paths and connections", December 2002

   [20] ITU-T Recommendation G.7710 (07/07), "Common equipment
   [21] ITU-T Recommendation Y.2611 (06/12), " High-level architecture
         of future packet-based networks", 2006

Authors' Addresses

   Italo Busi (Editor)
   Alcatel-Lucent

   Email: Italo.Busi@alcatel-lucent.it
   Ben Niven-Jenkins (Editor)
   BT

   Email: benjamin.niven-jenkins@bt.com

Contributing Authors' Addresses

   Annamaria Fulignoli
   Ericsson

   Email: annamaria.fulignoli@ericsson.com

   Enrique Hernandez-Valencia
   Alcatel-Lucent

   Email: enrique@alcatel-lucent.com

   Lieven Levrau
   Alcatel-Lucent

   Email: llevrau@alcatel-lucent.com

   Dinesh Mohan
   Nortel

   Email: mohand@nortel.com

   Vincenzo Sestito
   Alcatel-Lucent

   Email: vincenzo.sestito@alcatel-lucent.it

   Nurit Sprecher
   Nokia Siemens Networks

   Email: nurit.sprecher@nsn.com
   Huub van Helvoort
   Huawei Technologies

   Email: hhelvoort@huawei.com

   Martin Vigoureux
   Alcatel-Lucent

   Email: martin.vigoureux@alcatel-lucent.fr

   Yaacov Weingarten
   Nokia Siemens Networks

   Email: yaacov.weingarten@nsn.com

   Rolf Winter
   NEC

   Email: Rolf.Winter@nw.neclab.eu