tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search     info

RFC 6371

 Errata 
Informational
Pages: 62
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: MPLS

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

Part 1 of 3, p. 1 to 23
None       Next RFC Part

Updated by:    6435


Top       ToC       Page 1 
Internet Engineering Task Force (IETF)                      I. Busi, Ed.
Request for Comments: 6371                                Alcatel-Lucent
Category: Informational                                    D. Allan, Ed.
ISSN: 2070-1721                                                 Ericsson
                                                          September 2011


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

Abstract

   The Transport Profile of Multiprotocol Label Switching (MPLS-TP) is a
   packet-based transport technology based on the MPLS Traffic
   Engineering (MPLS-TE) and pseudowire (PW) data-plane architectures.

   This document describes a framework to support a comprehensive set of
   Operations, Administration, and Maintenance (OAM) procedures that
   fulfill the MPLS-TP OAM requirements for fault, performance, and
   protection-switching management and that do not rely on the presence
   of a control plane.

   This document is a product of a joint Internet Engineering Task Force
   (IETF) / International Telecommunications Union Telecommunication
   Standardization Sector (ITU-T) effort to include an MPLS Transport
   Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge
   (PWE3) architectures to support the capabilities and functionalities
   of a packet transport network as defined by the ITU-T.

Status of This Memo

   This document is not an Internet Standards Track specification; it is
   published for informational purposes.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Not all documents
   approved by the IESG are a candidate for any level of Internet
   Standard; see Section 2 of RFC 5741.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   http://www.rfc-editor.org/info/rfc6371.

Page 2 
Copyright Notice

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

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

Table of Contents

   1. Introduction ....................................................3
   2. Conventions Used in This Document ...............................5
      2.1. Terminology ................................................5
      2.2. Definitions ................................................7
   3. Functional Components ..........................................10
      3.1. Maintenance Entity and Maintenance Entity Group ...........10
      3.2. MEG Nesting: SPMEs and Tandem Connection Monitoring .......13
      3.3. MEG End Points (MEPs) .....................................14
      3.4. MEG Intermediate Points (MIPs) ............................18
      3.5. Server MEPs ...............................................20
      3.6. Configuration Considerations ..............................21
      3.7. P2MP Considerations .......................................21
      3.8. Further Considerations of Enhanced Segment Monitoring .....22
   4. Reference Model ................................................23
      4.1. MPLS-TP Section Monitoring (SMEG) .........................26
      4.2. MPLS-TP LSP End-to-End Monitoring Group (LMEG) ............27
      4.3. MPLS-TP PW Monitoring (PMEG) ..............................27
      4.4. MPLS-TP LSP SPME Monitoring (LSMEG) .......................28
      4.5. MPLS-TP MS-PW SPME Monitoring (PSMEG) .....................30
      4.6. Fate-Sharing Considerations for Multilink .................31
   5. OAM Functions for Proactive Monitoring .........................32
      5.1. Continuity Check and Connectivity Verification ............33
           5.1.1. Defects Identified by CC-V .........................35
           5.1.2. Consequent Action ..................................37
           5.1.3. Configuration Considerations .......................38
      5.2. Remote Defect Indication ..................................40
           5.2.1. Configuration Considerations .......................40
      5.3. Alarm Reporting ...........................................41
      5.4. Lock Reporting ............................................42
      5.5. Packet Loss Measurement ...................................44
           5.5.1. Configuration Considerations .......................45

Top      ToC       Page 3 
           5.5.2. Sampling Skew ......................................45
           5.5.3. Multilink Issues ...................................45
      5.6. Packet Delay Measurement ..................................46
           5.6.1. Configuration Considerations .......................46
      5.7. Client Failure Indication .................................47
           5.7.1. Configuration Considerations .......................47
   6. OAM Functions for On-Demand Monitoring .........................48
      6.1. Connectivity Verification .................................48
           6.1.1. Configuration Considerations .......................49
      6.2. Packet Loss Measurement ...................................50
           6.2.1. Configuration Considerations .......................50
           6.2.2. Sampling Skew ......................................50
           6.2.3. Multilink Issues ...................................50
      6.3. Diagnostic Tests ..........................................50
           6.3.1. Throughput Estimation ..............................51
           6.3.2. Data-Plane Loopback ................................52
      6.4. Route Tracing .............................................54
           6.4.1. Configuration Considerations .......................54
      6.5. Packet Delay Measurement ..................................54
           6.5.1. Configuration Considerations .......................55
   7. OAM Functions for Administration Control .......................55
      7.1. Lock Instruct .............................................55
           7.1.1. Locking a Transport Path ...........................56
           7.1.2. Unlocking a Transport Path .........................56
   8. Security Considerations ........................................57
   9. Acknowledgments ................................................58
   10. References ....................................................58
      10.1. Normative References .....................................58
      10.2. Informative References ...................................59
   11. Contributing Authors ..........................................60

1.  Introduction

   As noted in the MPLS Transport Profile (MPLS-TP) framework RFCs (RFC
   5921 [8] and RFC 6215 [9]), MPLS-TP is a packet-based transport
   technology based on the MPLS Traffic Engineering (MPLS-TE) and
   pseudowire (PW) data-plane architectures defined in RFC 3031 [1], RFC
   3985 [2], and RFC 5659 [4].

   MPLS-TP utilizes a comprehensive set of Operations, Administration,
   and Maintenance (OAM) procedures for fault, performance, and
   protection-switching management that do not rely on the presence of a
   control plane.

   In line with [15], 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.  Some extensions discussed in this framework may end up

Top      ToC       Page 4 
   as aspirational capabilities and may be determined to be not
   tractably realizable in some implementations.  Extensions do not
   deprecate support for existing MPLS OAM capabilities.

   The MPLS-TP OAM framework defined in this document provides a
   protocol-neutral description of the required OAM functions and of the
   data-plane OAM architecture to support a comprehensive set of OAM
   procedures that satisfy the MPLS-TP OAM requirements of RFC 5860
   [11].  In this regard, it defines similar OAM functionality as for
   existing Synchronous Optical Network / Synchronous Digital Hierarchy
   (SONET/SDH) and Optical Transport Network (OTN) OAM mechanisms (e.g.,
   [19]).

   The MPLS-TP OAM framework is applicable to Sections, Label Switched
   Paths (LSPs), Multi-Segment Pseudowires (MS-PWs), and Sub-Path
   Maintenance Elements (SPMEs).  It supports co-routed and associated
   bidirectional P2P transport paths as well as unidirectional P2P and
   P2MP transport paths.

   OAM packets that instrument a particular direction of a transport
   path are subject to the same forwarding treatment (i.e., fate-share)
   as the user data packets and in some cases, where Explicitly TC-
   encoded-PSC LSPs (E-LSPs) are employed, may be required to have
   common per-hop behavior (PHB) Scheduling Class (PSC) End-to-End (E2E)
   with the class of traffic monitored.  In case of Label-Only-Inferred-
   PSC LSP (L-LSP), only one class of traffic needs to be monitored, and
   therefore the OAM packets have common PSC with the monitored traffic
   class.

   OAM packets can be distinguished from the used data packets using the
   Generic Associated Channel Label (GAL) and Associated Channel Header
   (ACH) constructs of RFC 5586 [7] for LSP, SPME, and Section, or the
   ACH construct of RFC 5085 [3] and RFC 5586 [7] for (MS-)PW.  OAM
   packets are never fragmented and are not combined with user data in
   the same packet payload.

   This framework makes certain assumptions as to the utility and
   frequency of different classes of measurement that naturally suggest
   different functions are implemented as distinct OAM flows or packets.
   This is dictated by the combination of the class of problem being
   detected and the need for timeliness of network response to the
   problem.  For example, fault detection is expected to operate on an
   entirely different time base than performance monitoring, which is
   also expected to operate on an entirely different time base than in-
   band management transactions.

Top      ToC       Page 5 
   The remainder of this memo is structured as follows:

   Section 2 covers the definitions and terminology used in this memo.

   Section 3 describes the functional component that generates and
   processes OAM packets.

   Section 4 describes the reference models for applying OAM functions
   to Sections, LSP, MS-PW, and their SPMEs.

   Sections 5, 6, and 7 provide a protocol-neutral description of the
   OAM functions, defined in RFC 5860 [11], aimed at clarifying how the
   OAM protocol solutions will behave to achieve their functional
   objectives.

   Section 8 discusses the security implications of OAM protocol design
   in the MPLS-TP context.

   The OAM protocol solutions designed as a consequence of this document
   are expected to comply with the functional behavior described in
   Sections 5, 6, and 7.  Alternative solutions to required functional
   behaviors may also be defined.

   OAM specifications following this OAM framework may be provided in
   different documents to cover distinct OAM functions.

   This document is a product of a joint Internet Engineering Task Force
   (IETF) / International Telecommunication Union Telecommunication
   Standardization Sector (ITU-T) effort to include an MPLS Transport
   Profile within the IETF MPLS and PWE3 architectures to support the
   capabilities and functionalities of a packet transport network as
   defined by the ITU-T.

2.  Conventions Used in This Document

2.1.  Terminology

   AC     Attachment Circuit

   AIS    Alarm Indication Signal

   CC     Continuity Check

   CC-V   Continuity Check and Connectivity Verification

   CV     Connectivity Verification

   DBN    Domain Border Node

Top      ToC       Page 6 
   E-LSP  Explicitly TC-encoded-PSC LSP

   ICC    ITU Carrier Code

   LER    Label Edge Router

   LKR    Lock Report

   L-LSP  Label-Only-Inferred-PSC LSP

   LM     Loss Measurement

   LME    LSP Maintenance Entity

   LMEG   LSP ME Group

   LSP    Label Switched Path

   LSR    Label Switching Router

   LSME   LSP SPME ME

   LSMEG  LSP SPME ME Group

   ME     Maintenance Entity

   MEG    Maintenance Entity Group

   MEP    Maintenance Entity Group End Point

   MIP    Maintenance Entity Group Intermediate Point

   NMS    Network Management System

   PE     Provider Edge

   PHB    Per-Hop Behavior

   PM     Performance Monitoring

   PME    PW Maintenance Entity

   PMEG   PW ME Group

   PSC    PHB Scheduling Class

   PSME   PW SPME ME

Top      ToC       Page 7 
   PSMEG  PW SPME ME Group

   PW     Pseudowire

   SLA    Service Level Agreement

   SME    Section Maintenance Entity

   SMEG   Section ME Group

   SPME   Sub-Path Maintenance Element

   S-PE   Switching Provider Edge

   TC     Traffic Class

   T-PE   Terminating Provider Edge

2.2.  Definitions

   This document uses the terms defined in RFC 5654 [5].

   This document uses the term 'per-hop behavior' as defined in RFC 2474
   [16].

   This document uses the term 'LSP' to indicate either a service LSP or
   a transport LSP (as defined in RFC 5921 [8]).

   This document uses the term 'Section' exclusively to refer to the n=0
   case of the term 'Section' defined in RFC 5960 [10].

   This document uses the term 'Sub-Path Maintenance Element (SPME)' as
   defined in RFC 5921 [8].

   This document uses the term 'traffic profile' as defined in RFC 2475
   [13].

   Where appropriate, the following definitions are aligned with ITU-T
   recommendation Y.1731 [21] in order to have a common, unambiguous
   terminology.  They do not however intend to imply a certain
   implementation but rather serve as a framework to describe the
   necessary OAM functions for MPLS-TP.

   Adaptation function: The adaptation function is the interface between
   the client (sub-)layer and the server (sub-)layer.

   Branch Node: A node along a point-to-multipoint transport path that
   is connected to more than one downstream node.

Top      ToC       Page 8 
   Bud Node: A node along a point-to-multipoint transport path that is
   at the same time a branch node and a leaf node for this transport
   path.

   Data-plane loopback: An out-of-service test where a transport path at
   either an intermediate or terminating node is placed into a data-
   plane loopback state, such that all traffic (including both payload
   and OAM) received on the looped back interface is sent on the reverse
   direction of the transport path.

      Note: The only way to send an OAM packet to a node that has been
      put into data-plane loopback mode is via Time to Live (TTL)
      expiry, irrespective of whether the node is hosting MIPs or MEPs.

   Domain Border Node (DBN): An intermediate node in an MPLS-TP LSP that
   is at the boundary between two MPLS-TP OAM domains.  Such a node may
   be present on the edge of two domains or may be connected by a link
   to the DBN at the edge of another OAM domain.

   Down MEP: A MEP that receives OAM packets from, and transmits them
   towards, the direction of a server layer.

   Forwarding Engine: An abstract functional component, residing in an
   LSR, that forwards the packets from an ingress interface toward the
   egress interface(s).

   In-Service: The administrative status of a transport path when it is
   unlocked.

   Interface: An interface is the attachment point to a server
   (sub-)layer, e.g., a MPLS-TP Section or MPLS-TP tunnel.

   Intermediate Node: An intermediate node transits traffic for an LSP
   or a PW.  An intermediate node may originate OAM flows directed to
   downstream intermediate nodes or MEPs.

   Loopback: See data-plane loopback and OAM loopback definitions.

   Maintenance Entity (ME): Some portion of a transport path that
   requires management bounded by two points (called MEPs), and the
   relationship between those points to which maintenance and monitoring
   operations apply (details in Section 3.1).

   Maintenance Entity Group (MEG): The set of one or more maintenance
   entities that maintain and monitor a section or a transport path in
   an OAM domain.

Top      ToC       Page 9 
   MEP: A MEG End Point (MEP) is capable of initiating (source MEP) and
   terminating (sink MEP) OAM packets for fault management and
   performance monitoring.  MEPs define the boundaries of an ME (details
   in Section 3.3).

   MIP: A MEG intermediate point (MIP) terminates and processes OAM
   packets that are sent to this particular MIP and may generate OAM
   packets in reaction to received OAM packets.  It never generates
   unsolicited OAM packets itself.  A MIP resides within a MEG between
   MEPs (details in Section 3.3).

   OAM domain: A domain, as defined in [5], whose entities are grouped
   for the purpose of keeping the OAM confined within that domain.  An
   OAM domain contains zero or more MEGs.

      Note: Within the rest of this document, the term "domain" is used
      to indicate an "OAM domain".

   OAM flow: The set of all OAM packets originating with a specific
   source MEP that instrument one direction of a MEG (or possibly both
   in the special case of data-plane loopback).

   OAM loopback: The capability of a node to be directed by a received
   OAM packet to generate a reply back to the sender.  OAM loopback can
   work in-service and can support different OAM functions (e.g.,
   bidirectional on-demand connectivity verification).

   OAM Packet: A packet that carries OAM information between MEPs and/or
   MIPs in a MEG to perform some OAM functionality (e.g., connectivity
   verification).

   Originating MEP: A MEP that originates an OAM transaction packet
   (toward a target MIP/MEP) and expects a reply, either in-band or out-
   of-band, from that target MIP/MEP.  The originating MEP always
   generates the OAM request packets in-band and expects and processes
   only OAM reply packets returned by the target MIP/MEP.

   Out-of-Service: The administrative status of a transport path when it
   is locked.  When a path is in a locked condition, it is blocked from
   carrying client traffic.

   Path Segment: It is either a segment or a concatenated segment, as
   defined in RFC 5654 [5].

   Signal Degrade: A condition declared by a MEP when the data
   forwarding capability associated with a transport path has
   deteriorated, as determined by performance monitoring (PM).  See also
   ITU-T recommendation G.806 [14].

Top      ToC       Page 10 
   Signal Fail: A condition declared by a MEP when the data forwarding
   capability associated with a transport path has failed, e.g., loss of
   continuity.  See also ITU-T recommendation G.806 [14].

   Sink MEP: A MEP acts as a sink MEP for an OAM packet when it
   terminates and processes the packets received from its associated
   MEG.

   Source MEP: A MEP acts as source MEP for an OAM packet when it
   originates and inserts the packet into the transport path for its
   associated MEG.

   Tandem Connection: A tandem connection is an arbitrary part of a
   transport path that can be monitored (via OAM) independent of the
   end-to-end monitoring (OAM).  The tandem connection may also include
   the forwarding engine(s) of the node(s) at the boundaries of the
   tandem connection.  Tandem connections may be nested but cannot
   overlap.  See also ITU-T recommendation G.805 [20].

   Target MEP/MIP: A MEP or a MIP that is targeted by OAM transaction
   packets and that replies to the originating MEP that initiated the
   OAM transactions.  The target MEP or MIP can reply either in-band or
   out-of-band.  The target sink MEP function always receives the OAM
   request packets in-band, while the target source MEP function only
   generates the OAM reply packets that are sent in-band.

   Up MEP: A MEP that transmits OAM packets towards, and receives them
   from, the direction of the forwarding engine.

3.  Functional Components

   MPLS-TP is a packet-based transport technology based on the MPLS and
   PW data plane architectures ([1], [2], and [4]) and is capable of
   transporting service traffic where the characteristics of information
   transfer between the transport path end points can be demonstrated to
   comply with certain performance and quality guarantees.

   In order to describe the required OAM functionality, this document
   introduces a set of functional components.

3.1.  Maintenance Entity and Maintenance Entity Group

   MPLS-TP OAM operates in the context of Maintenance Entities (MEs)
   that define a relationship between two points of a transport path to
   which maintenance and monitoring operations apply.  The two points
   that define a maintenance entity are called Maintenance Entity Group
   End Points (MEPs).  The collection of one or more MEs that belongs to
   the same transport path and that are maintained and monitored as a

Top      ToC       Page 11 
   group are known as a Maintenance Entity Group (MEG).  In between
   MEPs, there are zero or more intermediate points, called Maintenance
   Entity Group Intermediate Points (MIPs).  MEPs and MIPs are
   associated with the MEG and can be shared by more than one ME in a
   MEG.

   An abstract reference model for an ME is illustrated 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 Figure 1, nodes A and D can
   be Label Edge Routers (LERs) for an LSP or the Terminating Provider
   Edges (T-PEs) for an MS-PW, nodes B and C are LSRs for an LSP or
   Switching PEs (S-PEs) for an MS-PW.  MEPs reside in nodes A and D,
   while MIPs reside in nodes B and C and may reside in A and D.  The
   links connecting adjacent nodes can be physical links, (sub-)layer
   LSPs/SPMEs, or server-layer paths.

   This functional model defines the relationships between all OAM
   entities from a maintenance perspective and it allows each
   Maintenance Entity to provide monitoring and management for the
   (sub-)layer network under its responsibility and efficient
   localization of problems.

   An MPLS-TP Maintenance Entity Group may be defined to monitor the
   transport path for fault and/or performance management.

   The MEPs that form a MEG bound the scope of an OAM flow to the MEG
   (i.e., within the domain of the transport path that is being
   monitored and managed).  There are two exceptions to this:

   1) A misbranching fault may cause OAM packets to be delivered to a
      MEP that is not in the MEG of origin.

   2) An out-of-band return path may be used between a MIP or a MEP and
      the originating MEP.

   In case of a unidirectional point-to-point transport path, a single
   unidirectional Maintenance Entity is defined to monitor it.

Top      ToC       Page 12 
   In case of associated bidirectional point-to-point transport paths,
   two independent unidirectional Maintenance Entities are defined to
   independently monitor each direction.  This has implications for
   transactions that terminate at or query a MIP, as a return path from
   MIP to the originating MEP does not necessarily exist in the MEG.

   In case of co-routed bidirectional point-to-point transport paths, a
   single bidirectional Maintenance Entity is defined to monitor both
   directions congruently.

   In case of unidirectional point-to-multipoint transport paths, a
   single unidirectional Maintenance Entity for each leaf is defined to
   monitor the transport path from the root to that leaf.

   In all cases, portions of the transport path may be monitored by the
   instantiation of SPMEs (see Section 3.2).

   The reference model for the P2MP MEG is represented in Figure 2.

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

                 Figure 2: Reference Model for P2MP MEG

   In the case of P2MP transport paths, the OAM measurements are
   independent for each ME (A-D, A-E, and A-F):

   o  Fault conditions - some faults may impact more than one ME
      depending on where the failure is located;

   o  Packet loss - packet dropping may impact more than one ME
      depending from where the packets are lost;

   o  Packet delay - will be unique per ME.

   Each leaf (i.e., D, E, and F) terminates OAM flows to monitor the ME
   between itself and the root while the root (i.e., A) generates OAM
   packets common to all the MEs of the P2MP MEG.  All nodes may
   implement a MIP in the corresponding MEG.

Top      ToC       Page 13 
3.2.  MEG Nesting: SPMEs and Tandem Connection Monitoring

   In order to verify and maintain performance and quality guarantees,
   there is a need to apply OAM functionality not only 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 transport path.

   Sub-Path Maintenance Elements (SPMEs), as defined in [8], are
   hierarchical LSPs instantiated to provide monitoring of a portion of
   a set of transport paths (LSPs or MS-PWs) that follow the same path
   between the ingress and the egress of the SPME.  The operational
   aspects of instantiating SPMEs are out of scope of this memo.

   SPMEs can also be employed to meet the requirement to provide tandem
   connection monitoring (TCM), as defined by ITU-T Recommendation G.805
   [20].

   TCM for a given path segment of a transport path is implemented by
   creating an SPME that has a 1:1 association with the path segment of
   the transport path that is to be monitored.

   In the TCM case, this means that the SPME used to provide TCM can
   carry one and only one transport path, thus allowing direct
   correlation between all fault management and performance monitoring
   information gathered for the SPME and the monitored path segment of
   the end-to-end transport path.

   There are a number of implications to this approach:

   1) The SPME would use the uniform model [23] of Traffic Class (TC)
      code point copying between sub-layers for Diffserv such that the
      E2E markings and PHB treatment for the transport path were
      preserved by the SPMEs.

   2) The SPME normally would use the short-pipe model for TTL handling
      [6] (no TTL copying between sub-layers) such that the TTL distance
      to the MIPs for the E2E entity would not be impacted by the
      presence of the SPME, but it should be possible for an operator to
      specify use of the uniform model.

   Note that points 1 and 2 above assume that the TTL copying mode and
   TC copying modes are independently configurable for an LSP.

   The TTL distance to the MIPs plays a critical role for delivering
   packets to these MIPs as described in Section 3.4.

Top      ToC       Page 14 
   There are specific issues with the use of the uniform model of TTL
   copying for an SPME:

   1. A MIP in the SPME sub-layer is not part of the transport-path MEG;
      hence, only an out-of-band return path for OAM originating in the
      transport-path MEG that addressed an SPME MIP might be available.

   2. The instantiation of a lower-level MEG or protection-switching
      actions within a lower-level MEG may change the TTL distances to
      MIPs in the higher-level MEGs.

   The end points of the SPME are MEPs and limit the scope of an OAM
   flow within the MEG that the MEPs belong to (i.e., within the domain
   of the SPME that is being monitored and managed).

   When considering SPMEs, it is important to consider that the
   following properties apply to all MPLS-TP MEGs (regardless of whether
   they instrument LSPs, SPMEs, or MS-PWs):

   o  They can be nested but not overlapped, e.g., a MEG may cover a
      path segment of another MEG and may also include the forwarding
      engine(s) of the node(s) at the edge(s) of the path segment.
      However, when MEGs are nested, the MEPs and MIPs in the SPME are
      no longer part of the encompassing MEG.

   o  It is possible that MEPs of MEGs that are nested reside on a
      single node but again are implemented in such a way that they do
      not overlap.

   o  Each OAM flow is associated with a single MEG.

   o  When an SPME is instantiated after the transport path has been
      instantiated, the TTL distance to the MIPs may change for the
      short-pipe model of TTL copying, and may change for the uniform
      model if the SPME is not co-routed with the original path.

3.3.  MEG End Points (MEPs)

   MEG End Points (MEPs) are the source and sink points of a MEG.  In
   the context of an MPLS-TP LSP, only LERs can implement MEPs, while in
   the context of an SPME, any LSR of the MPLS-TP LSP can be an LER of
   SPMEs that contributes to the overall monitoring infrastructure of
   the transport path.  Regarding PWs, only T-PEs can implement MEPs;
   while for SPMEs supporting one or more PWs, both T-PEs and S-PEs can
   implement SPME MEPs.  Any MPLS-TP LSR can implement a MEP for an
   MPLS-TP Section.

Top      ToC       Page 15 
   MEPs are responsible for originating almost all of the proactive and
   on-demand monitoring OAM functionality for the MEG.  There is a
   separate class of notifications (such as Lock Report (LKR) and Alarm
   Indication Signal (AIS)) that are originated by intermediate nodes
   and triggered by server-layer events.  A MEP is capable of
   originating and terminating OAM packets for fault management and
   performance monitoring.  These OAM packets are carried within the
   Generic Associated Channel (G-ACh) with the proper encapsulation and
   an appropriate channel type as defined in RFC 5586 [7].  A MEP
   terminates all the OAM packets it receives from the MEG it belongs to
   and silently discards those that do not.  (Note that in the
   particular case of Connectivity Verification (CV) processing, a CV
   packet from an incorrect MEG will result in a mis-connectivity defect
   and there are further actions taken.)  The MEG the OAM packet belongs
   to is associated with the MPLS or PW label, whether the label is used
   to infer the MEG or the content of the OAM packet is an
   implementation choice.  In the case of an MPLS-TP Section, the MEG is
   inferred from the port on which an OAM packet was received with the
   GAL at the top of the label stack.

   OAM packets may require the use of an available "out-of-band" return
   path (as defined in [8]).  In such cases, sufficient information is
   required in the originating transaction such that the OAM reply
   packet can be constructed and properly forwarded to the originating
   MEP (e.g., IP address).

   Each OAM solution document will further detail the applicability of
   the tools it defines as a proactive or on-demand mechanism as well as
   its usage when:

   o  The "in-band" return path exists and it is used.

   o  An "out-of-band" return path exists and it is used.

   o  Any return path does not exist or is not used.

   Once a MEG is configured, the operator can configure which proactive
   OAM functions to use on the MEG, but the MEPs are always enabled.

   MEPs terminate all OAM packets received from the associated MEG.  As
   the MEP corresponds to the termination of the forwarding path for a
   MEG at the given (sub-)layer, OAM packets never leak outside of a MEG
   in a properly configured fault-free implementation.

Top      ToC       Page 16 
   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 the source MEP and sink MEP coincide with transport paths'
   source and sink terminations.

   The MEPs of an SPME are not necessarily coincident with the
   termination of the MPLS-TP transport path.  They are used to monitor
   a path segment of the transport path for failures or performance
   degradation (e.g., based on packet counts) only within the boundary
   of the MEG for the SPME.

   An MPLS-TP sink MEP passes a fault indication to its client
   (sub-)layer network as a consequent action of fault detection.  When
   the client layer is not MPLS-TP, the consequent actions in the client
   layer (e.g., ignore or generate client-layer-specific OAM
   notifications) are outside the scope of this document.

   A node hosting a MEP can either support per-node MEP or per-interface
   MEP(s).  A per-node MEP resides in an unspecified location within the
   node, while a per-interface MEP resides on a specific side of the
   forwarding engine.  In particular, a per-interface MEP is called an
   "Up MEP" or a "Down MEP" depending on its location relative to the
   forwarding engine.  An "Up MEP" transmits OAM packets towards, and
   receives them from, the direction of the forwarding engine, while a
   "Down MEP" receives OAM packets from, and transmits them towards, the
   direction of a server layer.

Top      ToC       Page 17 
         Source node Up MEP             Destination node Up MEP
       ------------------------         ------------------------
      |                        |       |                        |
      |-----              -----|       |-----              -----|
      | MEP |            |     |       |     |            | MEP |
      |     |    ----    |     |       |     |    ----    |     |
      | In  |->-| FW |->-| Out |->- ->-| In  |->-| FW |->-| Out |
      | i/f |    ----    | i/f |       | i/f |    ----    | i/f |
      |-----              -----|       |-----              -----|
      |                        |       |                        |
       ------------------------         ------------------------
                  (1)                               (2)

         Source node Down MEP           Destination node Down MEP
       ------------------------         ------------------------
      |                        |       |                        |
      |-----              -----|       |-----              -----|
      |     |            | MEP |       | MEP |            |     |
      |     |    ----    |     |       |     |    ----    |     |
      | In  |->-| FW |->-| Out |->- ->-| In  |->-| FW |->-| Out |
      | i/f |    ----    | i/f |       | i/f |    ----    | i/f |
      |-----              -----|       |-----              -----|
      |                        |       |                        |
       ------------------------         ------------------------
                  (3)                               (4)

                Figure 3: Examples of Per-Interface MEPs

   Figure 3 describes four examples of per-interface Up MEPs: an Up
   Source MEP in a source node (case 1), an Up Sink MEP in a destination
   node (case 2), a Down Source MEP in a source node (case 3), and a
   Down Sink MEP in a destination node (case 4).

   The usage of per-interface Up MEPs extends the coverage of the ME for
   both fault and performance monitoring closer to the edge of the
   domain and determines that the location of a failure or performance
   degradation is within a node or on a link between two adjacent nodes.

   Each OAM solution document will further detail the implications of
   the tools it defines when used with per-interface or per-node MEPs,
   if necessary.

   It may occur that multiple MEPs for the same MEG are on the same
   node, and are all Up MEPs, each on one side of the forwarding engine,
   such that the MEG is entirely internal to the node.

Top      ToC       Page 18 
   It should be noted that an ME may span nodes that implement per-node
   MEPs and per-interface MEPs.  This guarantees backward compatibility
   with most of the existing LSRs that can implement only a per-node
   MEP.  In fact, in many current implementations, label operations are
   largely performed on the ingress interface; hence, the exposure of
   the GAL as top label will occur at the ingress interface.

   Note that a MEP can only exist at the beginning and end of a
   (sub-)layer in MPLS-TP.  If there is a need to monitor some portion
   of that LSP or PW, a new sub-layer (in the form of an SPME) must be
   created that permits MEPs and associated MEGs to be created.

   In the case where an intermediate node sends an OAM packet to a MEP,
   it uses the top label of the stack at that point.

3.4.  MEG Intermediate Points (MIPs)

   A MEG Intermediate Point (MIP) is a function located at a point
   between the MEPs of a MEG for a PW, LSP, or SPME.

   A MIP is capable of reacting to some OAM packets and forwarding all
   the other OAM packets while ensuring fate-sharing with user data
   packets.  However, a MIP does not initiate unsolicited OAM packets,
   but may be addressed by OAM packets initiated by one of the MEPs of
   the MEG.  A MIP can generate OAM packets only in response to OAM
   packets that it receives from the MEG it belongs to.  The OAM packets
   generated by the MIP are sent to the originating MEP.

   An intermediate node within a MEG can either:

   o  support per-node MIPs (i.e., a single MIP per node in an
      unspecified location within the node); or

   o  support per-interface MIPs (i.e., two or more MIPs per node on
      both sides of the forwarding engine).

   Support of per-interface or per-node MIPs is an implementation
   choice.  It is also possible that a node could support per-interface
   MIPs on some MEGs and per-node MIPs on other MEGs for which it is a
   transit node.

Top      ToC       Page 19 
                            Intermediate node
                        ------------------------
                       |                        |
                       |-----              -----|
                       | MIP |            | MIP |
                       |     |    ----    |     |
                    ->-| In  |->-| FW |->-| Out |->-
                       | i/f |    ----    | i/f |
                       |-----              -----|
                       |                        |
                        ------------------------

                Figure 4: Example of Per-Interface MIPs

   Figure 4 describes an example of two per-interface MIPs at an
   intermediate node of a point-to-point MEG.

   Using per-interface MIPs allows the network operator to determine
   that the location of a failure or performance degradation is within a
   node or on a link between two adjacent nodes.

   When sending an OAM packet to a MIP, the source MEP should set the
   TTL field to indicate the number of hops necessary to reach the node
   where the MIP resides.

   The source MEP should also include target MIP information in the OAM
   packets sent to a MIP to allow proper identification of the MIP
   within the node.  The MEG the OAM packet belongs to is associated
   with the MPLS label, whether the label is used to infer the MEG or
   the content of the OAM packet is an implementation choice.  In the
   latter case, the MPLS label is checked to be the expected one.

   The use of TTL expiry to deliver OAM packets to a specific MIP is not
   a fully reliable delivery mechanism because the TTL distance of a MIP
   from a MEP can change.  Any MPLS-TP node silently discards any OAM
   packet that is received with an expired TTL and that is not addressed
   to any of its MIPs or MEPs.  An MPLS-TP node that does not support
   OAM is also expected to silently discard any received OAM packet.

   Packets directed to a MIP may not necessarily carry specific MIP
   identification information beyond that of TTL distance.  In this
   case, a MIP would promiscuously respond to all MEP queries on its
   MEG.  This capability could be used for discovery functions (e.g.,
   route tracing as defined in Section 6.4) or when it is desirable to
   leave to the originating MEP the job of correlating TTL and MIP
   identifiers and noting changes or irregularities (via comparison with
   information previously extracted from the network).

Top      ToC       Page 20 
   MIPs are associated to the MEG they belong to, and their identity is
   unique within the MEG.  However, their identity is not necessarily
   unique to the MEG, e.g., all nodal MIPs in a node can have a common
   identity.

   A node hosting a MEP can also support per-interface Up MEPs and per-
   interface MIPs on either side of the forwarding engine.

   Once a MEG is configured, the operator can enable/disable the MIPs on
   the nodes within the MEG.  All the intermediate nodes and possibly
   the end nodes host MIP(s).  Local policy allows them to be enabled
   per function and per MEG.  The local policy is controlled by the
   management system, which may delegate it to the control plane.  A
   disabled MIP silently discards any received OAM packets.

3.5.  Server MEPs

   A server MEP is a MEP of a MEG that is either:

   o  defined in a layer network that is "below", which is to say
      encapsulates and transports the MPLS-TP layer network being
      referenced; or

   o  defined in a sub-layer of the MPLS-TP layer network that is
      "below", which is to say encapsulates and transports the sub-layer
      being referenced.

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

   A server MEP also provides server-layer OAM indications to the
   client/server adaptation function between the client (MPLS-TP)
   (sub-)layer network and the server (sub-)layer network.  The
   adaptation function maintains state on the mapping of MPLS-TP
   transport paths that are set up over that server (sub-)layer's
   transport path.

   For example, a server MEP can be:

   o  a non-MPLS MEP at a termination point of a physical link (e.g.,
      802.3, an SDH Virtual Circuit, or OTN Optical Data Unit (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.3;

Top      ToC       Page 21 
   o  an MPLS-TP SPME MEP used for LSP path segment monitoring, as
      defined in Section 4.4, for MPLS-TP LSPs or higher-level SPMEs
      providing LSP path segment monitoring; or

   o  an MPLS-TP SPME MEP used for PW path segment monitoring, as
      defined in Section 4.5, for MPLS-TP PWs or higher-level SPMEs
      providing PW path segment monitoring.

   The server MEP can run appropriate OAM functions for fault detection
   within the server (sub-)layer network and provides a fault indication
   to its client MPLS-TP layer network via the client/server adaptation
   function.  When the server layer is not MPLS-TP, server MEP OAM
   functions are simply assumed to exist but are outside the scope of
   this document.

3.6.  Configuration Considerations

   When a control plane is not present, the management plane configures
   these functional components.  Otherwise, they can be configured by
   either the management plane or the control plane.

   Local policy allows disabling the usage of any available "out-of-
   band" return path, as defined in [8], irrespective of what is
   requested by the node originating the OAM packet.

   SPMEs are usually instantiated when the transport path is created by
   either the management plane or the control plane (if present).
   Sometimes an SPME can be instantiated after the transport path is
   initially created.

3.7.  P2MP Considerations

   All the traffic sent over a P2MP transport path, including OAM
   packets generated by a MEP, is sent (multicast) from the root to all
   the leaves.  As a consequence:

   o  To send an OAM packet to all leaves, the source MEP can send a
      single OAM packet that will be delivered by the forwarding plane
      to all the leaves and processed by all the leaves.  Hence, a
      single OAM packet can simultaneously instrument all the MEs in a
      P2MP MEG.

   o  To send an OAM packet to a single leaf, the source MEP sends a
      single OAM packet that will be delivered by the forwarding plane
      to all the leaves but contains sufficient information to identify
      a target leaf, and therefore is processed only by the target leaf
      and can be silently discarded by the other leaves.

Top      ToC       Page 22 
   o  To send an OAM packet to a single MIP, the source MEP sends a
      single OAM packet with the TTL field indicating the number of hops
      necessary to reach the node where the MIP resides.  This packet
      will be delivered by the forwarding plane to all intermediate
      nodes at the same TTL distance of the target MIP and to any leaf
      that is located at a shorter distance.  The OAM packet must
      contain sufficient information to identify the target MIP and
      therefore is processed only by the target MIP and can be silently
      discarded by the others.

   o  In order to send an OAM packet to M leaves (i.e., a subset of all
      the leaves), the source MEP sends M different OAM packets targeted
      to each individual leaf in the group of M leaves.  Aggregating or
      subsetting mechanisms are outside the scope of this document.

   A bud node with a Down MEP or a per-node MEP will both terminate and
   relay OAM packets.  Similar to how fault coverage is maximized by the
   explicit utilization of Up MEPs, the same is true for MEPs on a bud
   node.

   P2MP paths are unidirectional; therefore, any return path to an
   originating MEP for on-demand transactions will be out-of-band.  A
   mechanism to target "on-demand" transactions to a single MEP or MIP
   is required as it relieves the originating MEP of an arbitrarily
   large processing load and of the requirement to filter and discard
   undesired responses.  This is because normally TTL exhaustion will
   address all MIPs at a given distance from the source, and failure to
   exhaust TTL will address all MEPs.

3.8.  Further Considerations of Enhanced Segment Monitoring

   Segment monitoring, like any in-service monitoring, in a transport
   network should meet the following network objectives:

   1. The monitoring and maintenance of existing transport paths has to
      be conducted in service without traffic disruption.

   2. Segment monitoring must not modify the forwarding of the segment
      portion of the transport path.

   SPMEs defined in Section 3.2 meet the above two objectives, when they
   are pre-configured or pre-instantiated as exemplified in Section 3.6.
   However, sometimes pre-design and pre-configuration of all the
   considered patterns of SPME are not preferable in real operation due
   to the burden of design works, a number of header consumptions,
   bandwidth consumption, and so on.

Top      ToC       Page 23 
   When SPMEs are configured or instantiated after the transport path
   has been created, network objective (1) can be met: application and
   removal of SPME to a faultless monitored transport entity can be
   performed in such a way as not to introduce any loss of traffic,
   e.g., by using a non-disruptive "make before break" technique.

   However, network objective (2) cannot be met due to new assignment of
   MPLS labels.  As a consequence, generally speaking, the results of
   SPME monitoring are not necessarily correlated with the behavior of
   traffic in the monitored entity when it does not use SPME.  For
   example, application of SPME to a problematic/faulty monitoring
   entity might "fix" the problem encountered by the latter -- for as
   long as SPME is applied.  And vice versa, application of SPME to a
   faultless monitored entity may result in making it faulty -- again,
   as long as SPME is applied.

   Support for a more sophisticated segment-monitoring mechanism
   (temporal and hitless segment monitoring) to efficiently meet the two
   network objectives may be necessary.

   One possible option to instantiate non-intrusive segment monitoring
   without the use of SPMEs would require the MIPs selected as
   monitoring end points to implement enhanced functionality and state
   for the monitored transport path.

   For example, the MIPs need to be configured with the TTL distance to
   the peer or with the address of the peer, when out-of-band return
   paths are used.

   A further issue that would need to be considered is events that
   result in changing the TTL distance to the peer monitoring entity,
   such as protection events that may temporarily invalidate OAM
   information gleaned from the use of this technique.

   Further considerations on this technique are outside the scope of
   this document.



(page 23 continued on part 2)

Next RFC Part