[Docs] [txt|pdf] [Tracker] [Email] [Nits] [IPR]

Versions: 00 01 02 draft-ietf-mpls-tp-oam-framework

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

                                                       October 27, 2008



                    MPLS-TP OAM Framework and Overview
                    draft-busi-mpls-tp-oam-framework-00


Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

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

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

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

   This Internet-Draft will expire on April 27, 2009.

Copyright Notice

   Copyright (C) The IETF Trust (2008).



Abstract

   Multi-Protocol Label Switching (MPLS) Transport Profile (MPLS-TP) is
   based on a profile of the MPLS and pseudowire (PW) procedures as



Busi et al.             Expires April 27, 2009                 [Page 1]


Internet-Draft    MPLS-TP OAM Framework and Overview       October 2008


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

   This document provides a framework for supporting the MPLS-TP OAM
   requirements .[10] in a manner that admits a comprehensive set of OAM
   procedures.

Conventions used in this document

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

Table of Contents

   1. Introduction...................................................3
      1.1. Contributing Authors......................................3
      1.2. Terminology...............................................3
      1.3. Definitions...............................................4
   2. Functional Components..........................................4
      2.1. Maintenance Entity........................................5
      2.2. Maintenance End Points (MEPs).............................6
      2.3. Maintenance Intermediate Points (MIPs)....................6
      2.4. Server MEPs...............................................6
   3. Reference Model................................................7
      3.1. MPLS-TP Section Monitoring................................9
      3.2. MPLS-TP LSP End-to-End Monitoring........................10
      3.3. MPLS-TP LSP Tandem Connection Monitoring.................11
      3.4. MPLS-TP PW Monitoring....................................12
      3.5. MPLS-TP MS-PW Tandem Connection Monitoring...............12
   4. OAM Functions for pro-active monitoring.......................13
      4.1. Continuity Check and Connectivity Verification...........13
         4.1.1. Applications for proactive CC & CV function.........15
      4.2. Remote Defect Indication.................................15
         4.2.1. Configuration considerations........................15
         4.2.2. Applications for Remote Defect Indication...........16
      4.3. Alarm Suppression........................................16
      4.4. Lock Indication..........................................17
      4.5. Packet Loss Measurement..................................17
      4.6. Client Signal Fail.......................................17
   5. OAM Functions for on-demand monitoring........................17
      5.1. Continuity Check and Connectivity Verification...........17
         5.1.1. Configuration considerations........................18


Busi et al.             Expires April 27, 2009                 [Page 2]


Internet-Draft    MPLS-TP OAM Framework and Overview       October 2008


      5.2. Packet Loss Measurement..................................18
      5.3. Diagnostic Test..........................................18
      5.4. Trace routing............................................18
      5.5. Packet Delay Measurement.................................18
   6. OAM Protocols Overview........................................18
   7. Security Considerations.......................................18
   8. IANA Considerations...........................................19
   9. Acknowledgments...............................................19
   10. References...................................................19
      10.1. Normative References....................................19
      10.2. Informative References..................................20
   Authors' Addresses...............................................20
   Contributing Authors' Addresses..................................20
   Intellectual Property Statement..................................21
   Disclaimer of Validity...........................................22


1. Introduction

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

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

   The MPLS-TP OAM framework must satisfy the MPLS-TP OAM requirements .
   [10] in a manner that provides for a comprehensive set of OAM
   procedures. In this regard, it is similar to existing SONET/SDH and
   OTH OAM mechanisms (e.g. .[12]).

1.1. Contributing Authors

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

1.2. Terminology

   LME   LSP Maintenance Entity



Busi et al.             Expires April 27, 2009                 [Page 3]


Internet-Draft    MPLS-TP OAM Framework and Overview       October 2008


   ME    Maintenance Entity

   MEP   Maintenance End Point

   MIP   Maintenance Intermediate Point

   PME   PW Maintenance Entity

   SME   Section Maintenance Entity

   TCME  Tandem Connection Maintenance Entity

   TPME  Tandem PW Maintenance Entity

1.3. Definitions

   MPLS Section: to be added in a future revision of this document.

   OAM flow: to be added in a future revision of this document.

   Tandem Connection: A tandem connection corresponds to a segment of a
   path.  This may be either a segment of an LSP (i.e. a sub-path), or
   one or more segment(s) of a PW.

2. Functional Components

   MPLS-TP OAM operates in the context of Maintenance Entities (MEs). A
   Maintenance Entity can be viewed as the association of two (or more)
   Maintenance End Points (MEPs), see below. The MEPS that form an ME
   should be configured and managed to limit the OAM responsibilities of
   an OAM flow within a network or sub-network in the specific layer
   network that is being monitored and managed. Each OAM flow is
   associated to a unique ME.

   Each MEP within an ME resides at the boundaries of that ME. An ME may
   also include a set of zero or more Maintenance Intermediate Points
   (MIPs), which reside within the Maintenance Entity.

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

   A MIP is capable of generating OAM messages only in reaction to
   received OAM packets.

   This functional model defines the relationships between all OAM
   entities from a maintenance perspective, to allow each Maintenance



Busi et al.             Expires April 27, 2009                 [Page 4]


Internet-Draft    MPLS-TP OAM Framework and Overview       October 2008


   Entity to monitor and manage the layer network under its
   responsibility and easily localize problems.

   MEPs and MIPs are configured either via the management plane and/or
   the control plane, and they are associated with a particular
   Maintenance Entity.

2.1. Maintenance Entity

   A Maintenance Entity can be viewed as the association of two (or
   more) Maintenance End Points (MEPs). The MEPs that form an ME should
   be configured and managed to limit the OAM responsibilities of an OAM
   flow within a network or sub-network, or a transport path or segment,
   in the specific layer network that is being monitored and managed.
   Any maintenance point in between the two MEPs is a Maintenance
   Intermediate Points (MIP).

   A Maintenance Entity may be defined to monitor and manage bi-
   directional or unidirectional point-to-point connectivity or point-
   to-multipoint connectivity in an MPLS-TP layer network.

   MPLS-TP OAM functions are designed to be applied either on an end-to-
   end basis, e.g., between the LERs of a given LSP or T-PEs of a given
   PW, or on a per tandem connection basis, e.g., between any LER/LSR of
   a given LSP or any T-PE/S-PE of a given PW.

   The end points of a tandem connection are MEPs because the tandem
   connection is by definition a Maintenance Entity.

   Therefore, in the context of MPLS-TP LSP or PW Maintenance Entity
   (defined below) LERs and T-PEs can be MEPs while LSRs and S-PEs can
   be MIPs. In the case of Tandem Connection Maintenance Entity (defined
   below), LSRs and S-PEs can be either MEPs or MIPs.

   The following properties apply to all MPLS-TP MEs:

   o  OAM entities can be nested but not overlapped.

   o  Each OAM flow is associated to a unique Maintenance Entity.

   o  OAM packets are subject to the same forwarding treatment (e.g.
      fate share) as the data traffic, but they can be distinguished
      from the data traffic using the GAL and GE-ACH constructs .[9] for
      LSP and the PW-ACH construct .[6] for (MS-)PW.





Busi et al.             Expires April 27, 2009                 [Page 5]


Internet-Draft    MPLS-TP OAM Framework and Overview       October 2008


2.2. Maintenance End Points (MEPs)

   Maintenance End Points (MEPs) are the end points of a pre-configured
   (through the management or control planes) ME.  MEPs are responsible
   for activating and controlling all of the OAM functionality for the
   ME. A MEP may initiate an OAM packet to be transferred to its
   corresponding MEP, or to an intermediate MIP that is part of the ME.

   A MEP terminates all the OAM packets that it receives corresponding
   to its ME and does not forward them further along the path.

   All OAM packets coming to a MEP source are tunnelled via label
   stacking and are not processed within the ME as they belong either to
   the client network layers or to an higher TCM level.

   A MEP in a tandem connection is not coincident with the termination
   of the MPLS-TP transport path (LSP or PW), though it can monitor its
   connectivity (e.g. count packets). A MEP of an MPLS-TP network
   transport path is coincident with transport path termination and
   monitors its connectivity (e.g. count packets).

   MPLS-TP MEP notifies a fault indication to the MPLS-TP client layer
   network.

2.3. Maintenance Intermediate Points (MIPs)

   A Maintenance Intermediate Point (MIP) is a point between the two
   MEPs in an ME that is capable of reacting to some OAM packets and
   forwarding all OAM packets while ensuring fate sharing with data
   plane packets.  A MIP belongs to only one ME.

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

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

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

2.4. Server MEPs

   A server MEP is a MEP of an ME that is defined in a layer network
   below the MPLS-TP layer network being referenced. A server MEP



Busi et al.             Expires April 27, 2009                 [Page 6]


Internet-Draft    MPLS-TP OAM Framework and Overview       October 2008


   coincides with either a MIP or a MEP in the client (MPLS-TP) layer
   network.

   For example, a server MEP can be either:

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

   o  An MPLS-TP Section MEP for MPLS-TP LSPs, defined in section .3.2.
      ;
   o  An MPLS-TP LSP MEP for MPLS-TP PWs, defined in section .3.4. ;

   o  An MPLS-TP TCM MEP for higher-level TCMs, defined in sections .
      3.3.  and .3.5.

   The server MEP can run appropriate OAM functions for fault detection,
   and notifies a fault indication to the MPLS-TP layer network.

3. Reference Model

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

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

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

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

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

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

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

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


Busi et al.             Expires April 27, 2009                 [Page 7]


Internet-Draft    MPLS-TP OAM Framework and Overview       October 2008




           Native  |<-------------------- PW15 --------------------->|  Native
           Layer   |                                                 |   Layer
          Service  |    |<-PSN13->|    |<-PSN3X->|    |<-PSNXZ->|    |  Service
           (AC1)   V    V   LSP   V    V   LSP   V    V   LSP   V    V   (AC2)
                   +----+   +-+   +----+         +----+   +-+   +----+
     +----+        |TPE1|   | |   |SPE3|         |SPEX|   | |   |TPEZ|       +----+
     |    |        |    |=========|    |=========|    |=========|    |       |    |
     | CE1|--------|........PW1........|...PW3...|........PW5........|-------|CE2 |
     |    |        |    |=========|    |=========|    |=========|    |       |    |
     +----+        | 1  |   |2|   | 3  |         | X  |   |Y|   | Z  |       +----+
                   +----+   +-+   +----+         +----+   +-+   +----+

                   |<- Subnetwork 123->|         |<- Subnetwork XYZ->|

                   .------------------- PW15  PME -------------------.
                   .----- PW1 TPME ----.         .---- PW5 TPME -----.
                        .---------.                   .---------.
                         PSN13 LME                     PSNXZ LME

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

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

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

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

   Figure 1 depicts a high-level reference model for the MPLS-TP OAM
   framework.  The  figure  depicts  portions  of  two  MPLS-TP  enabled
   subnetworks, Subnetwork 123 and Subnetwork XYZ. In Subnetwork 123,
   LSR 1 is adjacent to LSR 2 via the MPLS Section Sec12 and LSR2 is
   adjacent to LSR3 via the MPLS Section Sec23. Similarly, In Subnetwork
   XYZ, LSR X is adjacent to LSR Y via the MPLS Section SecXY and LSR Y
   is adjacent to LSR Z via the MPLS Section SecYZ. In addition, LSR 3
   is adjacent to LSR X via the MPLS Section 3X.

   Figure 1 also shows a bi-directional MS-PW (PW15) between AC1 on LSR
   1 (TPE1) and AC2 on LSR Z (TPEZ). The MS-PW consists of 3 bi-
   directional PW Segments: 1) PW Segment 1 (PW1) between LSR 1 (TPE1)
   and LSR 3 (SPE3) via the bi-directional PSN13 LSP, 2) PW Segment 3
   (PW3) between LSR 3 (SPE3) and LSR X (SPEX), and 3) PW Segment 5



Busi et al.             Expires April 27, 2009                 [Page 8]


Internet-Draft    MPLS-TP OAM Framework and Overview       October 2008


   (PW5) between LSR X (SPEX) and LSR Z (TPEZ) via the bi-directional
   PSNXZ LSP.

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

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

3.1. MPLS-TP Section Monitoring

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

   An SME is intended to be deployed for applications where it is
   preferable to monitor the link between the topologically adjacent
   MPLS (and MPLS-TP enabled) LSRs rather than monitoring the individual
   LSP or PW segments traversing the MPLS Section. A representative
   application is collecting link-level PM statistics at the node-to-
   node interfaces (NNI) in MPLS-TP sub-network domains.



                   |<-------------------- PW15 --------------------->|
                   |                                                 |
                   |    |<-PSN13->|    |<-PSN3X->|    |<-PSNXZ->|    |
                   V    V   LSP   V    V   LSP   V    V   LSP   V    V
                   +----+   +-+   +----+         +----+   +-+   +----+
     +----+        |TPE1|   | |   |SPE3|         |SPEX|   | |   |TPEZ|       +----+
     |    |  AC1   |    |=========|    |=========|    |=========|    |  AC2  |    |
     | CE1|--------|........PW1........|...PW3...|........PW5........|-------|CE2 |
     |    |        |    |=========|    |=========|    |=========|    |       |    |
     +----+        | 1  |   |2|   | 3  |         | X  |   |Y|   | Z  |       +----+
                   +----+   +-+   +----+         +----+   +-+   +----+

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

              Figure 2: Example of MPLS-TP Section MEs (SME)


Busi et al.             Expires April 27, 2009                 [Page 9]


Internet-Draft    MPLS-TP OAM Framework and Overview       October 2008


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

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

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

   An LME is intended to be deployed in scenarios where it is desirable
   to monitor the forwarding behaviour of an entire LSP between a pair
   of  MPLS  LERs,  rather  than,  say,  monitoring  individual  PWs.  A
   representative application is collecting PM statistics of PSN LSP
   that is being used to provide a "tunnelling services" for a number of
   other LSPs.

                   |<-------------------- PW15 --------------------->|
                   |                                                 |
                   |    |<-PSN13->|    |<-PSN3X->|    |<-PSNXZ->|    |
                   V    V   LSP   V    V   LSP   V    V   LSP   V    V
                   +----+   +-+   +----+         +----+   +-+   +----+
     +----+        |TPE1|   | |   |SPE3|         |SPEX|   | |   |TPEZ|       +----+
     |    |  AC1   |    |=========|    |=========|    |=========|    |  AC2  |    |
     | CE1|--------|........PW1........|...PW3...|........PW5........|-------|CE2 |
     |    |        |    |=========|    |=========|    |=========|    |       |    |
     +----+        | 1  |   |2|   | 3  |         | X  |   |Y|   | Z  |       +----+
                   +----+   +-+   +----+         +----+   +-+   +----+

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

                Figure 3: Examples of MPLS-TP LSP MEs (LME)

   Figure 3 depicts 2 LMEs configured in the path between AC1 and AC2:
   1) the PSN13 LME between LER 1 and LER 3, and 2) the PSNXZ LME
   between LER X and LER Y.






Busi et al.             Expires April 27, 2009                [Page 10]


Internet-Draft    MPLS-TP OAM Framework and Overview       October 2008


3.3. MPLS-TP LSP Tandem Connection Monitoring

   An MPLS-TP LSP Tandem Connection Monitoring ME (TLME) is an MPLS-TP
   maintenance entity intended to monitor the forwarding behaviour of an
   LSP Segment between a given pair of LSRs. Multiple TLME MAY BE
   configured on any LSP Segment. The LSR may or may not be immediately
   adjacent at the MPLS layer. TLME OAM packets fate share with the user
   data packets sent over the monitored LSP segment.

   A TLME can be defined between the following entities:

       o LER and any LSR of a given LSP.

       o Any two LSRs of a given LSP.

   A TLME is intended to be deployed in scenarios where it is preferable
   to monitor the behaviour of a segment of an LSP rather than the
   entire LSP itself. A representative application is when there is a
   need to monitor a segment of an LSP that extends beyond the
   administrative  boundaries  of  an  MPLS-TP  enabled  administrative
   domain.

                   |<--------------------- PW15 -------------------->|
                   |                                                 |
                   |    |<--------------PSN1Z LSP-------------->|    |
                   |    |<-PSN13->|    |<-PSN3X->|    |<-PSNXZ->|    |
                   V    V  S-LSP  V    V  S-LSP  V    V  S-LSP  V    V
                   +----+   +-+   +----+         +----+   +-+   +----+
     +----+        | PE1|   | |   | PB3|         | PBX|   | |   | PEZ|       +----+
     |    |  AC1   |    |=======================================|    |  AC2  |    |
     | CE1|--------|......................PW15.......................|-------|CE2 |
     |    |        |    |=======================================|    |       |    |
     +----+        | 1  |   |2|   | 3  |         | X  |   |Y|   | Z  |       +----+
                   +----+   +-+   +----+         +----+   +-+   +----+

                        .--------.                    .---------.
                        PSN13 TLME                    PSNXZ TLME

   PB: Provider Border LSR

        Figure 4: MPLS-TP LSP Tandem Conection Monitoring ME (TLME)

   Figure 4 depicts a variation of the reference model in Figure 1 where
   there is an end-to-end PSN LSP (PSN1Z LSP) between PE1 and PEZ. PSN1Z
   LSP consists of, at least, three stitched LSP Segments: PSN13, PSN3X
   and PSNXZ. In this scenario there are two separate TLMEs configured
   to monitor the forwarding behaviour of the PSN1Z LSP: 1) a TLME


Busi et al.             Expires April 27, 2009                [Page 11]


Internet-Draft    MPLS-TP OAM Framework and Overview       October 2008


   monitoring the PSN13 LSP Segment on Subnetwork 123 (PSN13 TLME), and
   2) a TLME monitoring the PSNXZ LSP Segment on Subnetwork XYZ (PSNXZ
   TLME).

3.4. MPLS-TP PW Monitoring

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

   A PME is intended to be deployed in scenarios where it is desirable
   to monitor the forwarding behaviour of an entire PW between a pair of
   MPLS-TP enabled T-PEs rather than monitoring the LSP aggregating
   multiple PWs between PEs. A representative application is on either
   SS-PW or MS-PW used to emulate traffic for which an SLA with QoS
   commitments may apply (e.g., an emulated DS1/E1 or the emulated CBR
   connection of an ATM VCC/VPC).

                   |<-------------------- PW15 --------------------->|
                   |                                                 |
                   |    |<-PSN13->|    |<-PSN3X->|    |<-PSNXZ->|    |
                   V    V   LSP   V    V   LSP   V    V   LSP   V    V
                   +----+   +-+   +----+         +----+   +-+   +----+
     +----+        |TPE1|   | |   |SPE3|         |SPEX|   | |   |TPEZ|       +----+
     |    |  AC1   |    |=========|    |=========|    |=========|    |  AC2  |    |
     | CE1|--------|........PW1........|...PW3...|........PW5........|-------|CE2 |
     |    |        |    |=========|    |=========|    |=========|    |       |    |
     +----+        | 1  |   |2|   | 3  |         | X  |   |Y|   | Z  |       +----+
                   +----+   +-+   +----+         +----+   +-+   +----+

                   .---------------------PW15 PME--------------------.


                       Figure 5: MPLS-TP PW ME (PME)

   Figure 5 depicts a MS-PW (PW15) consisting of three segments: PW1,
   PW3 and PW5 and its associated end-to-end PME (PW15 PME).

3.5. MPLS-TP MS-PW Tandem Connection Monitoring

   An MPLS-TP MS-PW Tandem Connection Monitoring ME (TPME) is an MPLS-TP
   maintenance entity intended to monitor the forwarding behaviour of
   one or more MS-PW segments between a given pair of PEs. Multiple
   TPMEs MAY be configured on any sub-path of a MS-PW. The PEs may or
   may not be immediately adjacent at the MS-PW layer. TPME OAM packets


Busi et al.             Expires April 27, 2009                [Page 12]


Internet-Draft    MPLS-TP OAM Framework and Overview       October 2008


   fate share with the user data packets sent over the monitored MS-PW
   Segment.

   A TPME can be defined between the following entities:

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

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

   A TPME is intended to be deployed in scenarios where it is preferable
   to monitor the behaviour of a segment of a MS-PW rather than the
   entire end-to-end PW itself. A representative application is to
   collect PM statistics for the MS-PW Segment within a given network
   domain of an inter-domain PW.

                   |<-------------------- PW15 --------------------->|
                   |                                                 |
                   |    |<-PSN13->|    |<-PSN3X->|    |<-PSNXZ->|    |
                   V    V   LSP   V    V   LSP   V    V   LSP   V    V
                   +----+   +-+   +----+         +----+   +-+   +----+
     +----+        |TPE1|   | |   |SPE3|         |SPEX|   | |   |TPEZ|       +----+
     |    |  AC1   |    |=========|    |=========|    |=========|    |  AC2  |    |
     | CE1|--------|........PW1........|...PW3...|........PW5........|-------|CE2 |
     |    |        |    |=========|    |=========|    |=========|    |       |    |
      +----+        | 1  |   |2|   | 3  |         | X  |   |Y|   | Z  |       +----+
                   +----+   +-+   +----+         +----+   +-+   +----+

                   .-----PW1 TPME------.         .------PW5 TPME------.


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

   Figure 6 depicts the same MS-PW (PW15) between AC1 and AC2 as in
   Figure 5. In this scenario there are two separate TPMEs configured to
   monitor the forwarding behaviour of PW15: 1) a TPME monitoring the
   PW1 MS-PW Segment on Subnetwork 123 (PW1 TPME), and 2) a TPME
   monitoring the PW4 MS-PW Segment on Subnetwork XYZ with (PW5 TPME).

4. OAM Functions for pro-active monitoring

4.1. Continuity Check and Connectivity Verification

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


Busi et al.             Expires April 27, 2009                [Page 13]


Internet-Draft    MPLS-TP OAM Framework and Overview       October 2008


   Proactive CC & CV is based upon the generation of OAM CC/CV packets,
   carrying a unique ME identifier, at a regular configurable timing
   rate and the detection of LOC when these packets do not arrive. If
   the received ME identifier does not match the expected ME identifier,
   a connectivity defect has occurred. The default CC/CV transmission
   periods are application dependent (see section .4.1.1. )

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

   In a bidirectional point-to-point connection, when a MEP is enabled
   to generate CC/CV packets with a configured transmission period, it
   also expects to receive CC/CV packets from its peer MEP with the same
   transmission period. In a unidirectional connection (point-to-point
   or point-to-multipoint), only the source MEP is enabled to generate
   packets with CC/CV information. This MEP does not expect to receive
   any packets with CC/CV information from its peer MEPs in the ME.

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

   When CC & CV is enabled, a MEP periodically transmits CC/CV packets
   with frequency of the configured transmission period.

   If no CC/CV packets from a peer MEP are received within the interval
   equal to 3.5 times the transmission period, loss of continuity (LOC)
   defect with the peer MEP is detected.

   When a CC/CV packet is received, a MEP is capable to detect a
   mis-connectivity defect (e.g. mismerge or misconnection) with another
   ME when either:

   o  It is enabled to received CC/CV packets and the received CC/CV
      packet carries an incorrect ME identifier

   o  It is not enabled to receive CC/CV packets

   If CC/CV packets are received with a transmission period different
   than expected, CC/CV period mis-configuration defect is detected.

   A receiving MEP notifies the equipment fault management process when
   it detects the above defect conditions.




Busi et al.             Expires April 27, 2009                [Page 14]


Internet-Draft    MPLS-TP OAM Framework and Overview       October 2008


4.1.1. Applications for proactive CC & CV function

   CC & CV is applicable for fault management, performance monitoring,
   or protection switching applications.

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

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

   o  Protection Switching: in order to achieve sub-50ms recovery time
      the default transmission period is 3.33ms (i.e. transmission rate
      of 300 packets/second) although a transmission period of 10ms can
      also be used. In some cases, when a slower recovery time is
      acceptable, it is also possible to relax the transmission period.

4.2. Remote Defect Indication

   The Remote Defect Indication (RDI) is an indicator that is
   transmitted by a MEP to communicate to its peer MEPs that a signal
   fail condition exists.  RDI is only used for bidirectional
   connections and is associated with proactive CC & CV packet
   generation.

   A MEP that has identified a signal fail related defect should include
   the RDI in all OAM CC/CV packets that it generates for the duration
   of the defect condition existence.  A MEP that receives the packets
   with the RDI information should determine that its peer MEP has
   encountered a defect condition associated with a signal fail.  MIPs
   should be transparent to the RDI indicator and should forward packets
   that include the indicator, i.e. the MIP should not perform any
   actions nor examine the indicator.

   When the signal condition clears, the MEP should clear the RDI
   indicator from subsequent transmission of OAM CC/CV packets.  Peer
   MEP, that have set the RDI condition, should clear the condition upon
   reception of a packet from the source MEP with the RDI indicator
   cleared.

4.2.1. Configuration considerations

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





Busi et al.             Expires April 27, 2009                [Page 15]


Internet-Draft    MPLS-TP OAM Framework and Overview       October 2008


4.2.2. Applications for Remote Defect Indication

   RDI is applicable for the following applications:

   o  Single-ended fault management - A receiving MEP detects the RDI
      defect condition, which when correlated with other defect
      conditions in the receiving MEP may become a fault case.

   o  Contribution to far-end performance monitoring - The indication of
      the far-end defect condition is used as input to the performance
      monitoring process.

4.3. Alarm Suppression

   Alarm Indication Signal function (AIS) is used to suppress alarms
   following detection of defect conditions at the server (sub) layer.

   o  Packets with AIS information can be issued at a MEP, including a
      Server MEP, upon detecting defect conditions.

   A server MEP is responsible for notifying the MPLS-TP layer network
   MEP upon fault detection in the server layer network to which the
   server MEP is associated.

   Only Server MEPs can issue MPLS-TP packets with AIS information. Upon
   detection of a signal fail condition the Server MEP can immediately
   start transmitting packets with AIS information periodically. A
   Server MEP continues to transmit periodic packets with AIS
   information until the signal fail condition is cleared.

   Upon receiving a packet with AIS information a MEP detects an AIS
   defect condition and suppresses loss of continuity alarms associated
   with all its peer MEPs.  A MEP resumes loss of continuity alarm
   generation upon detecting loss of continuity defect conditions in the
   absence of AIS condition.

   Specific configuration information required by a MEP to support AIS
   transmission is the following:

   o  PHB - identifies the per-hop behaviour of packet with AIS
      information.

   A MIP is transparent to packets with AIS information and therefore
   does not require any information to support AIS functionality.





Busi et al.             Expires April 27, 2009                [Page 16]


Internet-Draft    MPLS-TP OAM Framework and Overview       October 2008


4.4. Lock Indication

   To be incorporated in a future revision of this document

4.5. Packet Loss Measurement

   To be incorporated in a future revision of this document

4.6. Client Signal Fail

   To be incorporated in a future revision of this document

5. OAM Functions for on-demand monitoring

5.1. Continuity Check and Connectivity Verification

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

   An additional use of on-demand CC & CV would be to detect and locate
   a problem of connectivity when a problem is suspected or known based
   on other tools.  In this case the functionality will be triggered by
   the network management in response to a status signal or alarm
   indication.

   On-demand CC & CV is based upon generation of OAM CC & CV packets
   that should uniquely identify the ME that is being checked.  The on-
   demand functionality may be used to check either an entire ME (end-
   to-end) or between a MEP to a specific MIP.

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

   When invoking a periodic check of the ME, the source MEP should issue
   a burst of OAM CC/CV packets that uniquely identifies the ME being
   verified.  The number of packets and their transmission rate should
   be pre-configured and known to both the source MEP and the target MEP
   or MIP.  The source MEP should use the TTL field to indicate the
   number of hops necessary, when targeting a MIP and use the default
   value when performing an end-to-end.  The target MEP/MIP shall return


Busi et al.             Expires April 27, 2009                [Page 17]


Internet-Draft    MPLS-TP OAM Framework and Overview       October 2008


   a reply OAM CC/CV packet for each packet received.  If the expected
   number of OAM CC/CV reply packets is not received at source MEP, a
   LOC state is detected.

   When a connectivity problem is detected (e.g. via a pro-active CC&CV
   OAM tool), on demand CC&CV tool can be used to check the path.  The
   series should check CC&CV from MEP to peer MEP on the path, and if a
   fault is discovered, by lack of response, then additional checks may
   be performed to each of the intermediate MIP to locate the fault.

5.1.1. Configuration considerations

   For on-demand CC & CV the MEP should support configuration of number
   of packets to be transmitted/received in each burst of transmissions
   and the transmission rate should be either pre-configured or
   negotiated between the different nodes.

   In addition, when the CC & CV packet is checking connectivity toward
   a target MIP, the number of hops to reach the target MIP should be
   configured.

   The PHB of the CC & CV packets should be configured as well.

5.2. Packet Loss Measurement

   To be incorporated in a future revision of this document

5.3. Diagnostic Test

   To be incorporated in a future revision of this document

5.4. Trace routing

   To be incorporated in a future revision of this document

5.5. Packet Delay Measurement

   To be incorporated in a future revision of this document

6. OAM Protocols Overview

   To be incorporated in a future revision of this document

7. Security Considerations

   To be incorporated in a future revision of this document



Busi et al.             Expires April 27, 2009                [Page 18]


Internet-Draft    MPLS-TP OAM Framework and Overview       October 2008


8. IANA Considerations

   To be incorporated in a future revision of this document

9. Acknowledgments

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

10. References

10.1. Normative References

   [1]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels", BCP 14, RFC 2119, March 1997

   [2]   Rosen, E., Viswanathan, A., Callon, R., "Multiprotocol Label
         Switching Architecture", RFC 3031, January 2001

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

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

   [5]   Bryant, S., Pate, P., "Pseudo Wire Emulation Edge-to-Edge
         (PWE3) Architecture", RFC 3985, March 2005

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

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

   [8]   Bocci, M., et al., " A Framework for MPLS in Transport
         Networks", draft-blb-mpls-tp-framework-00 (work in progress),
         July 2008

   [9]   Vigoureux, M., Bocci, M., Swallow, G., Ward, D., Aggarwal, R.,
         " MPLS Generic Associated Channel ", draft-bocci-mpls-tp-gach-
         gal-00, October 2008



Busi et al.             Expires April 27, 2009                [Page 19]


Internet-Draft    MPLS-TP OAM Framework and Overview       October 2008


10.2. Informative References

   [10]  Vigoureux, M., Betts, M., Ward, D., "Requirements for OAM in
         MPLS Transport Networks", draft-vigoureux-mpls-tp-oam-
         requirements-00, July 2008

   [11]  Sprecher, N., Nadeau, T., van Helvoort, H., Weingarten, Y., "
         MPLS-TP OAM Analysis", draft-sprecher-mpls-tp-oam-analysis-02
         (work in progress), September 2008

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

Authors' Addresses

   Italo Busi (Editor)
   Alcatel-Lucent

   Email: italo.busi@alcatel-lucent.it


   Ben Niven-Jenkins (Editor)
   BT

   Email: benjamin.niven-jenkins@bt.com


Contributing Authors' Addresses

   Annamaria Fulignoli
   Ericsson

   Email: annamaria.fulignoli@ericsson.com


   Enrique Hernandez-Valencia
   Alcatel-Lucent

   Email: enrique@alcatel-lucent.com


   Lieven Levrau
   Alcatel-Lucent

   Email: llevrau@alcatel-lucent.com




Busi et al.             Expires April 27, 2009                [Page 20]


Internet-Draft    MPLS-TP OAM Framework and Overview       October 2008


   Dinesh Mohan (Editor)
   Nortel

   Email: mohand@nortel.com


   Vincenzo Sestito
   Alcatel-Lucent

   Email: vincenzo.sestito@alcatel-lucent.it


   Nurit Sprecher
   Nokia Siemens Networks

   Email: nurit.sprecher@nsn.com


   Huub van Helvoort
   Huawei Technologies

   Email: hhelvoort@huawei.com


   Martin Vigoureux
   Alcatel-Lucent

   Email: martin.vigoureux@alcatel-lucent.fr


   Yaacov Weingarten
   Nokia Siemens Networks

   Email: yaacov.weingarten@nsn.com


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights. Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.



Busi et al.             Expires April 27, 2009                [Page 21]


Internet-Draft    MPLS-TP OAM Framework and Overview       October 2008


   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard. Please address the information to the IETF at ietf-
   ipr@ietf.org.

Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.














Busi et al.             Expires April 27, 2009                [Page 22]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/