tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 6371

 
 
 

Operations, Administration, and Maintenance Framework for MPLS-Based Transport Networks

Part 2 of 3, p. 23 to 47
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 23 
4.  Reference Model

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

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

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

Top      Up      ToC       Page 24 
   o  An LSP Maintenance Entity Group (LMEG), allowing monitoring and
      management of an end-to-end LSP (between LERs).

   o  A PW Maintenance Entity Group (PMEG), allowing monitoring and
      management of an end-to-end Single-Segment Pseudowire (SS-PW) or
      MS-PW (between T-PEs).

   o  An LSP SPME ME Group (LSMEG), allowing monitoring and management
      of an SPME (between a given pair of LERs and/or LSRs along an
      LSP).

   o  A PW SPME ME Group (PSMEG), allowing monitoring and management of
      an SPME (between a given pair of T-PEs and/or S-PEs along an
      (MS-)PW).

   The MEGs specified in this MPLS-TP OAM framework are compliant with
   the architecture framework for MPLS-TP [8] that includes both MS-PWs
   [4] and LSPs [1].

   Hierarchical LSPs are also supported in the form of SPMEs.  In this
   case, each LSP in the hierarchy is a different sub-layer network that
   can be monitored, independently from higher- and lower-level LSPs in
   the hierarchy, on an end-to-end basis (from LER to LER) by an SPME.
   It is possible to monitor a portion of a hierarchical LSP by
   instantiating a hierarchical SPME between any LERs/LSRs along the
   hierarchical LSP.

Top      Up      ToC       Page 25 
    Native |<------------------ MS-PW1Z ---------------->|  Native
    Layer  |                                             |   Layer
   Service |    |<LSP13>|    |<-LSP3X->|    |<LSPXZ>|    |  Service
    (AC1)  V    V       V    V         V    V       V    V   (AC2)
           +----+ +---+ +----+         +----+ +---+ +----+
   +----+  |T-PE| |LSR| |S-PE|         |S-PE| |LSR| |T-PE|   +----+
   |    |  | 1  | | 2 | | 3  |         | X  | | Y | | Z  |   |    |
   |    |  |    |=======|    |=========|    |=======|    |   |    |
   | CE1|--|.......PW13......|...PW3X..|......PWXZ.......|---|CE2 |
   |    |  |    |=======|    |=========|    |=======|    |   |    |
   |    |  |    | |   | |    |         |    | |   | |    |   |    |
   +----+  |    | |   | |    |         |    | |   | |    |   +----+
           +----+ +---+ +----+         +----+ +---+ +----+
           .                 .         .                 .
           |                 |         |                 |
           |<--- Domain 1 -->|         |<--- Domain Z -->|
           ^----------------- PW1Z  PMEG ----------------^
           ^--- PW13 PSMEG --^         ^--- PWXZ PSMEG --^
                ^-------^                   ^-------^
                LSP13 LMEG                  LSPXZ LMEG
                ^--^ ^--^    ^---------^    ^--^ ^--^
               Sec12 Sec23      Sec3X      SecXY SecYZ
                SMEG  SMEG       SMEG       SMEG  SMEG

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

   T-PE 1: Terminating Provider Edge 1
   LSR 2:  Label Switching Router 2
   S-PE 3: Switching Provider Edge 3
   S-PE X: Switching Provider Edge X
   LSR Y:  Label Switching Router Y
   T-PE Z: Terminating Provider Edge Z

        Figure 5: Reference Model for the MPLS-TP OAM Framework

   Figure 5 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, T-PE 1 is
   adjacent to LSR 2 via the MPLS-TP Section Sec12, and LSR 2 is
   adjacent to S-PE 3 via the MPLS-TP Section Sec23.  Similarly, in
   Domain Z, S-PE X is adjacent to LSR Y via the MPLS-TP Section SecXY,
   and LSR Y is adjacent to T-PE Z via the MPLS-TP Section SecYZ.  In
   addition, S-PE 3 is adjacent to S-PE X via the MPLS-TP Section Sec3X.

Top      Up      ToC       Page 26 
   Figure 5 also shows a bidirectional MS-PW (MS-PW1Z) between AC1 on
   T-PE1 and AC2 on T-PE Z.  The MS-PW consists of three bidirectional
   PW path segments: 1) PW13 path segment between T-PE 1 and S-PE 3 via
   the bidirectional LSP13 LSP, 2) PW3X path segment between S-PE 3 and
   S-PE X via the bidirectional LSP3X LSP, and 3) PWXZ path segment
   between S-PE X and T-PE Z via the bidirectional LSPXZ LSP.

   The MPLS-TP OAM procedures that apply to a MEG are expected to
   operate independently from procedures on other MEGs.  Yet, this does
   not preclude that multiple MEGs may be affected simultaneously by the
   same network condition -- for example, a fiber cut event.

   Note that there are no constraints imposed by this OAM framework on
   the number or type (P2P, P2MP, LSP, or PW), of MEGs that may be
   instantiated on a particular node.  In particular, when looking at
   Figure 5, it should be possible to configure one or more MEPs on the
   same node if that node is the end point of one or more MEGs.

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

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

4.1.  MPLS-TP Section Monitoring (SMEG)

   An MPLS-TP Section MEG (SMEG) is an MPLS-TP maintenance entity
   intended to monitor an MPLS-TP Section.  An SMEG may be configured on
   any MPLS-TP section.  SMEG OAM packets must fate-share with the user
   data packets sent over the monitored MPLS-TP Section.

   An SMEG 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-TP LSRs rather than monitoring the
   individual LSP or PW path segments traversing the MPLS-TP Section and
   where the server-layer technology does not provide adequate OAM
   capabilities.

Top      Up      ToC       Page 27 
   Figure 5 shows five Section MEGs configured in the network between
   AC1 and AC2:

   1. Sec12 MEG associated with the MPLS-TP Section between T-PE 1 and
      LSR 2,

   2. Sec23 MEG associated with the MPLS-TP Section between LSR 2 and
      S-PE 3,

   3. Sec3X MEG associated with the MPLS-TP Section between S-PE 3 and
      S-PE X,

   4. SecXY MEG associated with the MPLS-TP Section between S-PE X and
      LSR Y, and

   5. SecYZ MEG associated with the MPLS-TP Section between LSR Y and
      T-PE Z

4.2.  MPLS-TP LSP End-to-End Monitoring Group (LMEG)

   An MPLS-TP LSP MEG (LMEG) is an MPLS-TP maintenance entity group
   intended to monitor an end-to-end LSP between its LERs.  An LMEG may
   be configured on any MPLS LSP.  LMEG OAM packets must fate-share with
   user data packets sent over the monitored MPLS-TP LSP.

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

   Figure 5 depicts two LMEGs configured in the network between AC1 and
   AC2: 1) the LSP13 LMEG between T-PE 1 and S-PE 3, and 2) the LSPXZ
   LMEG between S-PE X and T-PE Z.  Note that the presence of a LSP3X
   LMEG in such a configuration is optional, and hence, not precluded by
   this framework.  For instance, the network operator may prefer to
   monitor the MPLS-TP Section between the two LSRs rather than the
   individual LSPs.

4.3.  MPLS-TP PW Monitoring (PMEG)

   An MPLS-TP PW MEG (PMEG) is an MPLS-TP maintenance entity intended to
   monitor a SS-PW or MS-PW between its T-PEs.  A PMEG can be configured
   on any SS-PW or MS-PW.  PMEG OAM packets must fate-share with the
   user data packets sent over the monitored PW.

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

Top      Up      ToC       Page 28 
   Figure 5 depicts an MS-PW (MS-PW1Z) consisting of three path segments
   (PW13, PW3X, and PWXZ) and its associated end-to-end PMEG (PW1Z
   PMEG).

4.4.  MPLS-TP LSP SPME Monitoring (LSMEG)

   An MPLS-TP LSP SPME MEG (LSMEG) is an MPLS-TP SPME with an associated
   maintenance entity group intended to monitor an arbitrary part of an
   LSP between the MEPs instantiated for the SPME, independent from the
   end-to-end monitoring (LMEG).  An LSMEG can monitor an LSP path
   segment, and it may also include the forwarding engine(s) of the
   node(s) at the edge(s) of the path segment.

   When an SPME is established between non-adjacent LSRs, the edges of
   the SPME become adjacent at the LSP sub-layer network and any LSR
   that was previously in between becomes an LSR for the SPME.

   Multiple hierarchical LSMEGs can be configured on any LSP.  LSMEG OAM
   packets must fate-share with the user data packets sent over the
   monitored LSP path segment.

   A LSME can be defined between the following entities:

   o  The LER and LSR of a given LSP.

   o  Any two LSRs of a given LSP.

   An LSMEG is intended to be deployed in scenarios where it is
   preferable to monitor the behavior of a part of an LSP or set of LSPs
   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.

Top      Up      ToC       Page 29 
            |<-------------------- PW1Z ------------------->|
            |                                               |
            |    |<-------------LSP1Z LSP------------->|    |
            |    |<-LSP13->|    |<LSP3X>|    |<-LSPXZ->|    |
            V    V         V    V       V    V         V    V
            +----+  +---+  +----+       +----+  +---+  +----+
   +----+   | PE |  |LSR|  |DBN |       |DBN |  |LSR|  | PE |   +----+
   |    |   | 1  |  | 2 |  | 3  |       | X  |  | Y |  | Z  |   |    |
   |    |AC1|    |=====================================|    |AC2|    |
   | CE1|---|.....................PW1Z......................|---|CE2 |
   |    |   |    |=====================================|    |   |    |
   |    |   |    |  |   |  |    |       |    |  |   |  |    |   |    |
   +----+   |    |  |   |  |    |       |    |  |   |  |    |   +----+
            +----+  +---+  +----+       +----+  +---+  +----+
            .                   .       .                   .
            |                   |       |                   |
            |<---- Domain 1 --->|       |<---- Domain Z --->|

                 ^---------^                 ^---------^
                 LSP13 LSMEG                 LSPXZ LSMEG
                 ^-------------------------------------^
                                LSP1Z LMEG

   DBN: Domain Border Node

   PE 1:  Provider Edge 1
   LSR 2: Label Switching Router 2
   DBN 3: Domain Border Node 3
   DBN X: Domain Border Node X
   LSR Y: Label Switching Router Y
   PE Z:  Provider Edge Z

                 Figure 6: MPLS-TP LSP SPME MEG (LSMEG)

   Figure 6 depicts a variation of the reference model in Figure 5 where
   there is an end-to-end LSP (LSP1Z) between PE 1 and PE Z.  LSP1Z
   consists of, at least, three LSP Concatenated Segments: LSP13, LSP3X,
   and LSPXZ.  In this scenario, there are two separate LSMEGs
   configured to monitor the LSP1Z: 1) a LSMEG monitoring the LSP13
   Concatenated Segment on Domain 1 (LSP13 LSMEG), and 2) a LSMEG
   monitoring the LSPXZ Concatenated Segment on Domain Z (LSPXZ LSMEG).

   It is worth noticing that LSMEGs can coexist with the LMEG monitoring
   the end-to-end LSP and that LSMEG MEPs and LMEG MEPs can be
   coincident in the same node (e.g., PE 1 node supports both the LSP1Z
   LMEG MEP and the LSP13 LSMEG MEP).

Top      Up      ToC       Page 30 
4.5.  MPLS-TP MS-PW SPME Monitoring (PSMEG)

   An MPLS-TP MS-PW SPME Monitoring MEG (PSMEG) is an MPLS-TP SPME with
   an associated maintenance entity group intended to monitor an
   arbitrary part of an MS-PW between the MEPs instantiated for the
   SPME, independently of the end-to-end monitoring (PMEG).  A PSMEG can
   monitor a PW path segment, and it may also include the forwarding
   engine(s) of the node(s) at the edge(s) of the path segment.  A PSMEG
   is no different than an SPME; it is simply named as such to discuss
   SPMEs specifically in a PW context.

   When SPME is established between non-adjacent S-PEs, the edges of the
   SPME become adjacent at the MS-PW sub-layer network, and any S-PE
   that was previously in between becomes an LSR for the SPME.

   S-PE placement is typically dictated by considerations other than
   OAM.  S-PEs will frequently reside at operational boundaries such as
   the transition from distributed control plane (CP) to centralized
   Network Management System (NMS) control or at a routing area
   boundary.  As such, the architecture would appear not to have the
   flexibility that arbitrary placement of SPME segments would imply.
   Support for an arbitrary placement of PSMEG would require the
   definition of additional PW sub-layering.  Multiple hierarchical
   PSMEGs can be configured on any MS-PW.  PSMEG OAM packets fate-share
   with the user data packets sent over the monitored PW path Segment.

   A PSMEG does not add hierarchical components to the MPLS
   architecture; it defines the role of existing components for the
   purposes of discussing OAM functionality.

   A PSME can be defined between the following entities:

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

   o  Any two S-PEs of a given MS-PW.

   Note that, in line with the SPME description in Section 3.2, when a
   PW SPME is instantiated after the MS-PW has been instantiated, the
   TTL distance of the MIPs may change and MIPs in the PW SPME are no
   longer part of the encompassing MEG.  This means that the S-PE nodes
   hosting these MIPs are no longer S-PEs but P nodes at the SPME LSP
   level.  The consequences are that the S-PEs hosting the PSMEG MEPs
   become adjacent S-PEs.  This is no different than the operation of
   SPMEs in general.

   A PSMEG is intended to be deployed in scenarios where it is
   preferable to monitor the behavior of a part of an MS-PW rather than
   the entire end-to-end PW itself, for example, when monitoring an MS-

Top      Up      ToC       Page 31 
   PW path segment within a given network domain of an inter-domain MS-
   PW.

   Figure 5 depicts an MS-PW (MS-PW1Z) consisting of three path
   segments: PW13, PW3X, and PWXZ with two separate PSMEGs: 1) a PSMEG
   monitoring the PW13 MS-PW path segment on Domain 1 (PW13 PSMEG) and
   2) a PSMEG monitoring the PWXZ MS-PW path segment on Domain Z with
   (PWXZ PSMEG).

   It is worth noticing that PSMEGs can coexist with the PMEG monitoring
   the end-to-end MS-PW and that PSMEG MEPs and PMEG MEPs can be
   coincident in the same node (e.g., T-PE 1 node supports both the PW1Z
   PMEG MEP and the PW13 PSMEG MEP).

4.6.  Fate-Sharing Considerations for Multilink

   Multilink techniques are in use today and are expected to continue to
   be used in future deployments.  These techniques include Ethernet
   link aggregation [22] and the use of link bundling for MPLS [18]
   where the option to spread traffic over component links is supported
   and enabled.  While the use of link bundling can be controlled at the
   MPLS-TP layer, use of link aggregation (or any server-layer-specific
   multilink) is not necessarily under the control of the MPLS-TP layer.
   Other techniques may emerge in the future.  These techniques
   frequently share the characteristic that an LSP may be spread over a
   set of component links and therefore be reordered, but no flow within
   the LSP is reordered (except when very infrequent and minimally
   disruptive load rebalancing occurs).

   The use of multilink techniques may be prohibited or permitted in any
   particular deployment.  If multilink techniques are used, the
   deployment can be considered to be only partially MPLS-TP compliant;
   however, this is unlikely to prevent their use.

   The implications for OAM are that not all components of a multilink
   will be exercised, independent server-layer OAM being required to
   exercise the aggregated link components.  This has further
   implications for MIP and MEP placement, as per-interface MIPs or Down
   MEPs on a multilink interface are akin to a layer violation, as they
   instrument at the granularity of the server layer.  The implications
   for reduced OAM loss measurement functionality are documented in
   Sections 5.5.3 and 6.2.3.

Top      Up      ToC       Page 32 
5.  OAM Functions for Proactive Monitoring

   In this document, proactive monitoring refers to OAM operations that
   are either configured to be carried out periodically and continuously
   or preconfigured to act on certain events such as alarm signals.

   Proactive monitoring is usually performed "in-service".  Such
   transactions are universally MEP to MEP in operation, while
   notifications can be node to node (e.g., some MS-PW transactions) or
   node to MEPs (e.g., AIS).  The control and measurement considerations
   are:

   1. Proactive monitoring for a MEG is typically configured at the
      creation time of the transport path.

   2. The operational characteristics of in-band measurement
      transactions (e.g., CV, Loss Measurement (LM), etc.) are
      configured at the MEPs.

   3. Server-layer events are reported by OAM packets originating at
      intermediate nodes.

   4. The measurements resulting from proactive monitoring are typically
      reported outside of the MEG (e.g., to a management system) as
      notification events such as faults or indications of performance
      degradations (such as signal degrade conditions).

   5. The measurements resulting from proactive monitoring may be
      periodically harvested by an NMS.

   Proactive fault reporting is assumed to be subject to unreliable
   delivery and soft-state, and it needs to operate in cases where a
   return path is not available or faulty.  Therefore, periodic
   repetition is assumed to be used for reliability, instead of
   handshaking.

   Delay measurement also requires periodic repetition to allow
   estimation of the packet delay variation for the MEG.

   For statically provisioned transport paths, the above information is
   statically configured; for dynamically established transport paths,
   the configuration information is signaled via the control plane or
   configured via the management plane.

   The operator may enable/disable some of the consequent actions
   defined in Section 5.1.2.

Top      Up      ToC       Page 33 
5.1.  Continuity Check and Connectivity Verification

   Proactive Continuity Check functions, as required in Section 2.2.2 of
   RFC 5860 [11], are used to detect a loss of continuity (LOC) defect
   between two MEPs in a MEG.

   Proactive Connectivity Verification functions, as required in Section
   2.2.3 of RFC 5860 [11], are used to detect an unexpected connectivity
   defect between two MEGs (e.g., mismerging or misconnection), as well
   as unexpected connectivity within the MEG with an unexpected MEP.

   Both functions are based on the (proactive) generation, at the same
   rate, of OAM packets by the source MEP that are processed by the peer
   sink MEP(s).  As a consequence, in order to save OAM bandwidth
   consumption, CV, when used, is linked with CC into Continuity Check
   and Connectivity Verification (CC-V) OAM packets.

   In order to perform proactive Connectivity Verification, each CC-V
   OAM packet also includes a globally unique Source MEP identifier,
   whose value needs to be configured on the source MEP and on the peer
   sink MEP(s).  In some cases, to avoid the need to configure the
   globally unique Source MEP identifier, it is preferable to perform
   only proactive Continuity Check.  In this case, the CC-V OAM packet
   does not need to include any globally unique Source MEP identifier.
   Therefore, a MEG can be monitored only for CC or for both CC and CV.
   CC-V OAM packets used for CC-only monitoring are called CC OAM
   packets, while CC-V OAM packets used for both CC and CV are called CV
   OAM packets.

   As a consequence, it is not possible to detect misconnections between
   two MEGs monitored only for continuity as neither the OAM packet type
   nor the OAM packet content provides sufficient information to
   disambiguate an invalid source.  To expand:

   o  For a CC OAM packet leaking into a CC monitored MEG -
      undetectable.

   o  For a CV OAM packet leaking into a CC monitored MEG - reception of
      CV OAM packets instead of a CC OAM packets (e.g., with the
      additional Source MEP identifier) allows detecting the fault.

   o  For a CC OAM packet leaking into a CV monitored MEG - reception of
      CC OAM packets instead of CV OAM packets (e.g., lack of additional
      Source MEP identifier) allows detecting the fault.

   o  For a CV OAM packet leaking into a CV monitored MEG - reception of
      CV OAM packets with different Source MEP identifier permits fault
      to be identified.

Top      Up      ToC       Page 34 
   Having a common packet format for CC-V OAM packets would simplify
   parsing in a sink MEP to properly detect all the misconfiguration
   cases described above.

   MPLS-TP OAM supports different formats of MEP identifiers to address
   different environments.  When an alternative to IP addressing is
   desired (e.g., MPLS-TP is deployed in transport network environments
   where consistent operations with other transport technologies defined
   by the ITU-T are required), the ITU Carrier Code (ICC)-based format
   for MEP identification is used: this format is under definition in
   [25].  When MPLS-TP is deployed in an environment where IP
   capabilities are available and desired for OAM, the IP-based MEP
   identification is used: this format is described in [24].

   CC-V OAM packets are transmitted at a regular, operator-configurable
   rate.  The default CC-V transmission periods are application
   dependent (see Section 5.1.3).

   Proactive CC-V OAM packets are transmitted with the "minimum loss
   probability PHB" within the transport path (LSP, PW) they are
   monitoring.  For E-LSPs, this PHB is configurable on the network
   operator's basis, while for L-LSPs this is determined as per RFC 3270
   [23].  PHBs can be translated at the network borders by the same
   function that translates them for user data traffic.  The implication
   is that CC-V fate-shares with much of the forwarding implementation,
   but not all aspects of PHB processing are exercised.  Either on-
   demand tools are used for finer-grained fault finding or an
   implementation may utilize a CC-V flow per PHB to ensure a CC-V flow
   fate-shares with each individual PHB.

   In a co-routed or associated, bidirectional point-to-point transport
   path, when a MEP is enabled to generate proactive CC-V OAM packets
   with a configured transmission rate, it also expects to receive
   proactive CC-V OAM packets from its peer MEP at the same transmission
   rate.  This is because a common SLA applies to all components of the
   transport path.  In a unidirectional transport path (either point-to-
   point or point-to-multipoint), the source MEP is enabled only to
   generate CC-V OAM packets, while each sink MEP is configured to
   expect these packets at the configured rate.

   MIPs, as well as intermediate nodes not supporting MPLS-TP OAM, are
   transparent to the proactive CC-V information and forward these
   proactive CC-V OAM packets as regular data packets.

   During path setup and tear down, situations arise where CC-V checks
   would give rise to alarms, as the path is not fully instantiated.  In
   order to avoid these spurious alarms, the following procedures are
   recommended.  At initialization, the source MEP function (generating

Top      Up      ToC       Page 35 
   proactive CC-V packets) should be enabled prior to the corresponding
   sink MEP function (detecting continuity and connectivity defects).
   When disabling the CC-V proactive functionality, the sink MEP
   function should be disabled prior to the corresponding source MEP
   function.

   It should be noted that different encapsulations are possible for
   CC-V packets, and therefore it is possible that in case of
   misconfigurations or mis-connectivity, CC-V packets are received with
   an unexpected encapsulation.

   There are practical limitations to detecting unexpected
   encapsulation.  It is possible that there are misconfiguration or
   mis-connectivity scenarios where OAM packets can alias as payload,
   e.g., when a transport path can carry an arbitrary payload without a
   pseudowire.

   When CC-V packets are received with an unexpected encapsulation that
   can be parsed by a sink MEP, the CC-V packet is processed as if it
   were received with the correct encapsulation.  If it is not a
   manifestation of a mis-connectivity defect, a warning is raised (see
   Section 5.1.1.4).  Otherwise, the CC-V packet may be silently
   discarded as unrecognized and a LOC defect may be detected (see
   Section 5.1.1.1).

   The defect conditions are described in no specific order.

5.1.1.  Defects Identified by CC-V

   Proactive CC-V functions allow a sink MEP to detect the defect
   conditions described in the following subsections.  For all of the
   described defect cases, a sink MEP should notify the equipment fault
   management process of the detected defect.

   Sequential consecutive loss of CC-V packets is considered indicative
   of an actual break and not of congestive loss or physical-layer
   degradation.  The loss of 3 packets in a row (implying a detection
   interval that is 3.5 times the insertion time) is interpreted as a
   true break and a condition that will not clear by itself.

   A CC-V OAM packet is considered to carry an unexpected globally
   unique Source MEP identifier if it is a CC OAM packet received by a
   sink MEP monitoring the MEG for CV; it is a CV OAM packet received by
   a sink MEP monitoring the MEG for CC, or it is a CV OAM packet
   received by a sink MEP monitoring the MEG for CV but carrying a
   unique Source MEP identifier that is different that the expected one.
   Conversely, the CC-V packet is considered to have an expected
   globally unique Source MEP identifier; it is a CC OAM packet received

Top      Up      ToC       Page 36 
   by a sink MEP monitoring the MEG for CC, or it is a CV OAM packet
   received by a sink MEP monitoring the MEG for CV and carrying a
   unique Source MEP identifier that is equal to the expected one.

5.1.1.1.  Loss of Continuity Defect

   When proactive CC-V is enabled, a sink MEP detects a loss of
   continuity (LOC) defect when it fails to receive proactive CC-V OAM
   packets from the source MEP.

   o  Entry criteria:  If no proactive CC-V OAM packets from the source
      MEP (and in the case of CV, this includes the requirement to have
      the expected globally unique Source MEP identifier) are received
      within the interval equal to 3.5 times the receiving MEP's
      configured CC-V reception period.

   o  Exit criteria: A proactive CC-V OAM packet from the source MEP
      (and again in the case of CV, with the expected globally unique
      Source MEP identifier) is received.

5.1.1.2.  Mis-Connectivity Defect

   When a proactive CC-V OAM packet is received, a sink MEP identifies a
   mis-connectivity defect (e.g., mismerge, misconnection, or unintended
   looping) when the received packet carries an unexpected globally
   unique Source MEP identifier.

   o  Entry criteria: The sink MEP receives a proactive CC-V OAM packet
      with an unexpected globally unique Source MEP identifier or with
      an unexpected encapsulation.

   o  Exit criteria: The sink MEP does not receive any proactive CC-V
      OAM packet with an unexpected globally unique Source MEP
      identifier for an interval equal at least to 3.5 times the longest
      transmission period of the proactive CC-V OAM packets received
      with an unexpected globally unique Source MEP identifier since
      this defect has been raised.  This requires the OAM packet to
      self-identify the CC-V periodicity, as not all MEPs can be
      expected to have knowledge of all MEGs.

5.1.1.3.  Period Misconfiguration Defect

   If proactive CC-V OAM packets are received with the expected globally
   unique Source MEP identifier but with a transmission period different
   than the locally configured reception period, then a CC-V period
   misconfiguration defect is detected.

Top      Up      ToC       Page 37 
   o  Entry criteria: A MEP receives a CC-V proactive packet with the
      expected globally unique Source MEP identifier but with a
      transmission period different than its own CC-V-configured
      transmission period.

   o  Exit criteria: The sink MEP does not receive any proactive CC-V
      OAM packet with the expected globally unique Source MEP identifier
      and an incorrect transmission period for an interval equal at
      least to 3.5 times the longest transmission period of the
      proactive CC-V OAM packets received with the expected globally
      unique Source MEP identifier and an incorrect transmission period
      since this defect has been raised.

5.1.1.4.  Unexpected Encapsulation Defect

   If proactive CC-V OAM packets are received with the expected globally
   unique Source MEP identifier but with an unexpected encapsulation,
   then a CC-V unexpected encapsulation defect is detected.

   It should be noted that there are practical limitations to detecting
   unexpected encapsulation (see Section 5.1.1).

   o  Entry criteria: A MEP receives a CC-V proactive packet with the
      expected globally unique Source MEP identifier but with an
      unexpected encapsulation.

   o  Exit criteria: The sink MEP does not receive any proactive CC-V
      OAM packet with the expected globally unique Source MEP identifier
      and an unexpected encapsulation for an interval equal at least to
      3.5 times the longest transmission period of the proactive CC-V
      OAM packets received with the expected globally unique Source MEP
      identifier and an unexpected encapsulation since this defect has
      been raised.

5.1.2.  Consequent Action

   A sink MEP that detects any of the defect conditions defined in
   Section 5.1.1 declares a defect condition and performs the following
   consequent actions.

   If a MEP detects a mis-connectivity defect, it blocks all the traffic
   (including also the user data packets) that it receives from the
   misconnected transport path.

   If a MEP detects a LOC defect that is not caused by a period
   misconfiguration, 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.

Top      Up      ToC       Page 38 
   It is worth noticing that the OAM requirements document [11]
   recommends that CC-V proactive monitoring be enabled on every MEG in
   order to reliably detect connectivity defects.  However, CC-V
   proactive monitoring can be disabled by an operator for a MEG.  In
   the event of a misconnection between a transport path that is
   proactively monitored for CC-V and a transport path that is not, the
   MEP of the former transport path will detect a LOC defect
   representing a connectivity problem (e.g., a misconnection with a
   transport path where CC-V proactive monitoring is not enabled)
   instead of a continuity problem, with a consequence of delivery of
   traffic to an incorrect destination.  For these reasons, the traffic
   block consequent action is applied even when a LOC condition occurs.
   This block consequent action can be disabled through configuration.
   This deactivation of the block action may be used for activating or
   deactivating the monitoring when it is not possible to synchronize
   the function activation of the two peer MEPs.

   If a MEP detects a LOC defect (Section 5.1.1.1) or a mis-connectivity
   defect (Section 5.1.1.2), it declares a signal fail condition of the
   ME.

   It is a matter of local policy whether or not a MEP that detects a
   period misconfiguration defect (Section 5.1.1.3) declares a signal
   fail condition of the ME.

   The detection of an unexpected encapsulation defect does not have any
   consequent action: it is just a warning for the network operator.  An
   implementation able to detect an unexpected encapsulation but not
   able to verify the source MEP ID may choose to declare a mis-
   connectivity defect.

5.1.3.  Configuration Considerations

   At all MEPs inside a MEG, the following configuration information
   needs to be configured when a proactive CC-V function is enabled:

   o  MEG-ID: the MEG identifier to which the MEP belongs.

   o  MEP-ID: the MEP's own identity inside the MEG.

   o  list of the other MEPs in the MEG.  For a point-to-point MEG, the
      list would consist of the single MEP ID from which the OAM packets
      are expected.  In case of the root MEP of a P2MP MEG, the list is
      composed of all the leaf MEP IDs inside the MEG.  In case of the
      leaf MEP of a P2MP MEG, the list is composed of the root MEP ID
      (i.e., each leaf needs to know the root MEP ID from which it
      expects to receive the CC-V OAM packets).

Top      Up      ToC       Page 39 
   o  PHB for E-LSPs.  It identifies the per-hop behavior of a 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 translated at the network borders.

   o  transmission rate.  The default CC-V transmission periods are
      application dependent (depending on whether they are used to
      support fault management, performance monitoring, or protection-
      switching applications):

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

      *  Performance Management: default transmission period is 100 ms
         (i.e., transmission rate of 10 packets/second).  CC-V
         contributes to the accuracy of performance monitoring
         statistics by permitting the defect-free periods to be properly
         distinguished as described in Sections 5.5.1 and 5.6.1.

      *  Protection Switching: If protection switching with CC-V, defect
         entry criteria of 12 ms is required (for example, in
         conjunction with the requirement to support 50 ms recovery time
         as indicated in RFC 5654 [5]), then an implementation should
         use a default transmission period of 3.33 ms (i.e.,
         transmission rate of 300 packets/second).  Sometimes, the
         requirement of 50 ms recovery time is associated with the
         requirement for a CC-V defect entry criteria period of 35 ms;
         in these cases a transmission period of 10 ms (i.e.,
         transmission rate of 100 packets/second) can be used.
         Furthermore, when there is no need for so small CC-V defect
         entry criteria periods, a larger transmission period can be
         used.

   It should be possible for the operator to configure these
   transmission rates for all applications, to satisfy specific network
   requirements.

   Note that the reception period is the same as the configured
   transmission rate.

   For management-provisioned transport paths, the above parameters are
   statically configured; for dynamically signaled transport paths, the
   configuration information is distributed via the control plane.

   The operator should be able to enable/disable some of the consequent
   actions.  Which consequent actions can be enabled/disabled is
   described in Section 5.1.2.

Top      Up      ToC       Page 40 
5.2.  Remote Defect Indication

   The Remote Defect Indication (RDI) function, as required in Section
   2.2.9 of RFC 5860 [11], is an indicator that is transmitted by a sink
   MEP to communicate to its source MEP that a signal fail condition
   exists.  In case of co-routed and associated bidirectional transport
   paths, RDI is associated with proactive CC-V, and the RDI indicator
   can be piggy-backed onto the CC-V packet.  In case of unidirectional
   transport paths, the RDI indicator can be sent only using an out-of-
   band return path if it exists and its usage is enabled by policy
   actions.

   When a MEP detects a signal fail condition (e.g., in case of a
   continuity or connectivity defect), it should begin transmitting an
   RDI indicator to its peer MEP.  When incorporated into CC-V, the RDI
   information will be included in all proactive CC-V packets that it
   generates for the duration of the signal fail condition's existence.

   A MEP that receives packets from a peer MEP with the RDI information
   should determine that its peer MEP has encountered a defect condition
   associated with a signal fail condition.

   MIPs as well as intermediate nodes not supporting MPLS-TP OAM are
   transparent to the RDI indicator and forward OAM 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 signal fail condition clears, the MEP should stop
   transmitting the RDI indicator to its peer MEP.  When incorporated
   into CC-V, the RDI indicator will not be set for subsequent
   transmission of proactive CC-V packets.  A MEP should clear the RDI
   defect upon reception of an RDI indicator cleared.

5.2.1.  Configuration Considerations

   In order to support RDI, the indication may be carried in a unique
   OAM packet or may be embedded in a CC-V packet.  The in-band RDI
   transmission rate and PHB of the OAM packets carrying RDIs should be
   the same as that configured for CC-V to allow both far-end and near-
   end defect conditions being resolved in a timeframe that has the same
   order of magnitude.  This timeframe is application specific as
   described in Section 5.1.3.  Methods of the out-of-band return paths
   will dictate how out-of-band RDIs are transmitted.

Top      Up      ToC       Page 41 
5.3.  Alarm Reporting

   The Alarm Reporting function, as required in Section 2.2.8 of RFC
   5860 [11], relies upon an Alarm Indication Signal (AIS) packet to
   suppress alarms following detection of defect conditions at the
   server (sub-)layer.

   When a server MEP asserts a signal fail condition, it notifies that
   to the co-located MPLS-TP client/server adaptation function that then
   generates OAM packets with AIS information in the downstream
   direction to allow the suppression of secondary alarms at the MPLS-TP
   MEP in the client (sub-)layer.

   The generation of packets with AIS information starts immediately
   when the server MEP asserts a signal fail condition.  These periodic
   OAM packets, with AIS information, continue to be transmitted until
   the signal fail condition is cleared.

   It is assumed that to avoid spurious alarm generation a MEP detecting
   a loss of continuity defect (see Section 5.1.1.1) will wait for a
   hold-off interval prior to asserting an alarm to the management
   system.  Therefore, upon receiving an OAM packet with AIS
   information, an MPLS-TP MEP enters an AIS defect condition and
   suppresses reporting of alarms to the NMS on the loss of continuity
   with its peer MEP, but it does not block traffic received from the
   transport path.  A MEP resumes loss of continuity alarm generation
   upon detecting loss of continuity defect conditions in the absence of
   AIS condition.

   MIPs, as well as intermediate nodes, do not process AIS information
   and forward these AIS OAM packets as regular data packets.

   For example, let's consider a fiber cut between T-PE 1 and LSR 2 in
   the reference network of Figure 5.  Assuming that all of the MEGs
   described in Figure 5 have proactive CC-V enabled, a LOC defect is
   detected by the MEPs of Sec12 SMEG, LSP13 LMEG, PW1 PSMEG, and PW1Z
   PMEG; however, in a transport network, only the alarm associated to
   the fiber cut needs to be reported to an NMS, while all secondary
   alarms should be suppressed (i.e., not reported to the NMS or
   reported as secondary alarms).

   If the fiber cut is detected by the MEP in the physical layer (in LSR
   2), LSR 2 can generate the proper alarm in the physical layer and
   suppress the secondary alarm associated with the LOC defect detected
   on Sec12 SMEG.  As both MEPs reside within the same node, this
   process does not involve any external protocol exchange.  Otherwise,

Top      Up      ToC       Page 42 
   if the physical layer does not have enough OAM capabilities to detect
   the fiber cut, the MEP of Sec12 SMEG in LSR 2 will report a LOC
   alarm.

   In both cases, the MEP of Sec12 SMEG in LSR 2 notifies the adaptation
   function for LSP13 LMEG that then generates AIS packets on the LSP13
   LMEG in order to allow its MEP in S-PE 3 to suppress the LOC alarm.
   S-PE 3 can also suppress the secondary alarm on PW13 PSMEG because
   the MEP of PW13 PSMEG resides within the same node as the MEP of
   LSP13 LMEG.  The MEP of PW13 PSMEG in S-PE 3 also notifies the
   adaptation function for PW1Z PMEG that then generates AIS packets on
   PW1Z PMEG in order to allow its MEP in T-PE Z to suppress the LOC
   alarm.

   The generation of AIS packets for each MEG in the MPLS-TP client
   (sub-)layer is configurable (i.e., the operator can enable/disable
   the AIS generation).

   The AIS condition is cleared if no AIS packet has been received in
   3.5 times the AIS transmission period.

   The AIS transmission period is traditionally one per second, but an
   option to configure longer periods would be also desirable.  As a
   consequence, OAM packets need to self-identify the transmission
   period such that proper exit criteria can be established.

   AIS packets are transmitted with the "minimum loss probability PHB"
   within a single network operator.  For E-LSPs, this PHB is
   configurable on network operator's basis, while for L-LSPs, this is
   determined as per RFC 3270 [23].

5.4.  Lock Reporting

   The Lock Reporting function, as required in Section 2.2.7 of RFC 5860
   [11], relies upon a Lock Report (LKR) packet used to suppress alarms
   following administrative locking action in the server (sub-)layer.

   When a server MEP is locked, the MPLS-TP client (sub-)layer
   adaptation function generates packets with LKR information to allow
   the suppression of secondary alarms at the MEPs in the client
   (sub-)layer.  Again, it is assumed that there is a hold-off for any
   loss of continuity alarms in the client-layer MEPs downstream of the
   node originating the Lock Report.  In case of client (sub-)layer co-
   routed bidirectional transport paths, the LKR information is sent on
   both directions.  In case of client (sub-)layer unidirectional
   transport paths, the LKR information is sent only in the downstream
   direction.  As a consequence, in case of client (sub-)layer point-to-
   multipoint transport paths, the LKR information is sent only to the

Top      Up      ToC       Page 43 
   MEPs that are downstream from the server (sub-)layer that has been
   administratively locked.  Client (sub-)layer associated bidirectional
   transport paths behave like co-routed bidirectional transport paths
   if the server (sub-)layer that has been administratively locked is
   used by both directions; otherwise, they behave like unidirectional
   transport paths.

   The generation of packets with LKR information starts immediately
   when the server MEP is locked.  These periodic packets, with LKR
   information, continue to be transmitted until the locked condition is
   cleared.

   Upon receiving a packet with LKR information, an MPLS-TP MEP enters
   an LKR defect condition and suppresses the loss of continuity alarm
   associated with its peer MEP but does not block traffic received from
   the transport path.  A MEP resumes loss of continuity alarm
   generation upon detecting loss of continuity defect conditions in the
   absence of the LKR condition.

   MIPs, as well as intermediate nodes, do not process the LKR
   information; they forward these LKR OAM packets as regular data
   packets.

   For example, let's consider the case where the MPLS-TP Section
   between T-PE 1 and LSR 2 in the reference network of Figure 5 is
   administratively locked at LSR 2 (in both directions).

   Assuming that all the MEGs described in Figure 5 have proactive CC-V
   enabled, a LOC defect is detected by the MEPs of LSP13 LMEG, PW1
   PSMEG, and PW1Z PMEG; however, in a transport network all these
   secondary alarms should be suppressed (i.e., not reported to the NMS
   or reported as secondary alarms).

   The MEP of Sec12 SMEG in LSR 2 notifies the adaptation function for
   LSP13 LMEG that then generates LKR packets on the LSP13 LMEG in order
   to allow its MEPs in T-PE 1 and S-PE 3 to suppress the LOC alarm.
   S-PE 3 can also suppress the secondary alarm on PW13 PSMEG because
   the MEP of PW13 PSMEG resides within the same node as the MEP of
   LSP13 LMEG.  The MEP of PW13 PSMEG in S-PE 3 also notifies the
   adaptation function for PW1Z PMEG that then generates AIS packets on
   PW1Z PMEG in order to allow its MEP in T-PE Z to suppress the LOC
   alarm.

   The generation of LKR packets for each MEG in the MPLS-TP client
   (sub-)layer is configurable (i.e., the operator can enable/disable
   the LKR generation).

Top      Up      ToC       Page 44 
   The locked condition is cleared if no LKR packet has been received
   for 3.5 times the transmission period.

   The LKR transmission period is traditionally one per second, but an
   option to configure longer periods would be also desirable.  As a
   consequence, OAM packets need to self-identify the transmission
   period such that proper exit criteria can be established.

   LKR packets are transmitted with the "minimum loss probability PHB"
   within a single network operator.  For E-LSPs, this PHB is
   configurable on network operator's basis, while for L-LSPs, this is
   determined as per RFC 3270 [23].

5.5.  Packet Loss Measurement

   Packet Loss Measurement (LM) is one of the capabilities supported by
   the MPLS-TP Performance Monitoring (PM) function in order to
   facilitate reporting of Quality of Service (QoS) information for a
   transport path as required in Section 2.2.11 of RFC 5860 [11].  LM is
   used to exchange counter values for the number of ingress and egress
   packets transmitted and received by the transport path monitored by a
   pair of MEPs.

   Proactive LM is performed by periodically sending LM OAM packets from
   a MEP to a peer MEP and by receiving LM OAM packets from the peer MEP
   (if a co-routed or associated bidirectional transport path) during
   the lifetime of the transport path.  Each MEP performs measurements
   of its transmitted and received user data packets.  These
   measurements are then correlated in real time with the peer MEP in
   the ME to derive the impact of packet loss on a number of performance
   metrics for the ME in the MEG.  The LM transactions are issued such
   that the OAM packets will experience the same PHB scheduling class as
   the measured traffic while transiting between the MEPs in the ME.

   For a MEP, near-end packet loss refers to packet loss associated with
   incoming data packets (from the far-end MEP), while far-end packet
   loss refers to packet loss associated with egress data packets
   (towards the far-end MEP).

   Proactive LM can be operated in two ways:

   o  One-way: a MEP sends an LM OAM packet to its peer MEP containing
      all the required information to facilitate near-end packet loss
      measurements at the peer MEP.

   o  Two-way: a MEP sends an LM OAM packet with an LM request to its
      peer MEP, which replies with an LM OAM packet as an LM response.
      The request/response LM OAM packets contain all the required

Top      Up      ToC       Page 45 
      information to facilitate both near-end and far-end packet loss
      measurements from the viewpoint of the originating MEP.

   One-way LM is applicable to both unidirectional and bidirectional
   (co-routed or associated) transport paths, while two-way LM is
   applicable only to bidirectional (co-routed or associated) transport
   paths.

   MIPs, as well as intermediate nodes, do not process the LM
   information; they forward these proactive LM OAM packets as regular
   data packets.

5.5.1.  Configuration Considerations

   In order to support proactive LM, the transmission rate and, for
   E-LSPs, the PHB class (associated with the LM OAM packets originating
   from a MEP) need to be configured as part of the LM provisioning.  LM
   OAM packets should be transmitted with the PHB that yields the lowest
   drop precedence within the measured PHB Scheduling Class (see RFC
   3260 [17]), in order to maximize reliability of measurement within
   the traffic class.

   If that PHB class is not an ordered aggregate where the ordering
   constraint is all packets with the PHB class being delivered in
   order, LM can produce inconsistent results.

   Performance monitoring (e.g., LM) is only relevant when the transport
   path is defect free.  CC-V contributes to the accuracy of PM
   statistics by permitting the defect-free periods to be properly
   distinguished.  Therefore, support of proactive LM has implications
   on the CC-V transmission period (see Section 5.1.3).

5.5.2.  Sampling Skew

   If an implementation makes use of a hardware forwarding path that
   operates in parallel with an OAM processing path, whether hardware or
   software based, the packet and byte counts may be skewed if one or
   more packets can be processed before the OAM processing samples
   counters.  If OAM is implemented in software, this error can be quite
   large.

5.5.3.  Multilink Issues

   If multilink is used at the ingress or egress of a transport path,
   there may not be a single packet-processing engine where an LM packet
   can be injected or extracted as an atomic operation while having
   accurate packet and byte counts associated with the packet.

Top      Up      ToC       Page 46 
   In the case where multilink is encountered along the route of the
   transport path, the reordering of packets within the transport path
   can cause inaccurate LM results.

5.6.  Packet Delay Measurement

   Packet Delay Measurement (DM) is one of the capabilities supported by
   the MPLS-TP PM function in order to facilitate reporting of QoS
   information for a transport path as required in Section 2.2.12 of RFC
   5860 [11].  Specifically, proactive DM is used to measure the long-
   term packet delay and packet delay variation in the transport path
   monitored by a pair of MEPs.

   Proactive DM is performed by sending periodic DM OAM packets from a
   MEP to a peer MEP and by receiving DM OAM packets from the peer MEP
   (if a co-routed or associated bidirectional transport path) during a
   configurable time interval.

   Proactive DM can be operated in two ways:

   o  One-way: a MEP sends a DM OAM packet to its peer MEP containing
      all the required information to facilitate one-way packet delay
      and/or one-way packet delay variation measurements at the peer
      MEP.  Note that this requires precise time synchronization at
      either MEP by means outside the scope of this framework.

   o  Two-way: a MEP sends a DM OAM packet with a DM request to its peer
      MEP, which replies with a DM OAM packet as a DM response.  The
      request/response DM OAM packets contain all the required
      information to facilitate two-way packet delay and/or two-way
      packet delay variation measurements from the viewpoint of the
      originating MEP.

   One-way DM is applicable to both unidirectional and bidirectional
   (co-routed or associated) transport paths, while two-way DM is
   applicable only to bidirectional (co-routed or associated) transport
   paths.

   MIPs, as well as intermediate nodes, do not process the DM
   information; they forward these proactive DM OAM packets as regular
   data packets.

5.6.1.  Configuration Considerations

   In order to support proactive DM, the transmission rate and, for
   E-LSPs, the PHB (associated with the DM OAM packets originating from
   a MEP) need to be configured as part of the DM provisioning.  DM OAM
   packets should be transmitted with the PHB that yields the lowest

Top      Up      ToC       Page 47 
   drop precedence within the measured PHB Scheduling Class (see RFC
   3260 [17]).

   Performance monitoring (e.g., DM) is only relevant when the transport
   path is defect free.  CC-V contributes to the accuracy of PM
   statistics by permitting the defect-free periods to be properly
   distinguished.  Therefore, support of proactive DM has implications
   on the CC-V transmission period (see Section 5.1.3).

5.7.  Client Failure Indication

   The Client Failure Indication (CFI) function, as required in Section
   2.2.10 of RFC 5860 [11], is used to help process client defects and
   propagate a client signal defect condition from the process
   associated with the local attachment circuit where the defect was
   detected (typically the source adaptation function for the local
   client interface).  It is propagated to the process associated with
   the far-end attachment circuit (typically the source adaptation
   function for the far-end client interface) for the same transmission
   path, in case the client of the transport path does not support a
   native defect/alarm indication mechanism, e.g., AIS.

   A source MEP starts transmitting a CFI to its peer MEP when it
   receives a local client signal defect notification via its local
   client signal fail indication.  Mechanisms to detect local client
   signal fail defects are technology specific.  Similarly, mechanisms
   to determine when to cease originating client signal fail indication
   are also technology specific.

   A sink MEP that has received a CFI reports this condition to its
   associated client process via its local CFI function.  Consequent
   actions toward the client attachment circuit are technology specific.

   There needs to be a 1:1 correspondence between the client and the
   MEG; otherwise, when multiple clients are multiplexed over a
   transport path, the CFI packet requires additional information to
   permit the client instance to be identified.

   MIPs, as well as intermediate nodes, do not process the CFI
   information; they forward these proactive CFI OAM packets as regular
   data packets.

5.7.1.  Configuration Considerations

   In order to support CFI indication, the CFI transmission rate and,
   for E-LSPs, the PHB of the CFI OAM packets should be configured as
   part of the CFI configuration.


Next RFC Part