MPLS Working Group                                         M. Bocci, Ed.
Internet-Draft                                            Alcatel-Lucent
Intended status: Informational Standards Track                          S. Bryant, Ed.
Expires: May December 31, 2009                                 Cisco Systems
                                                               L. Levrau, Ed. Levrau
                                                          Alcatel-Lucent
                                                       November 27, 2008
                                                           June 29, 2009

               A Framework for MPLS in Transport Networks
                    draft-ietf-mpls-tp-framework-00
                    draft-ietf-mpls-tp-framework-01

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

   This Internet-Draft is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, submitted to IETF in accordance full conformance with Section 6 the
   provisions of BCP 78 and BCP 79.

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

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

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

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

   This Internet-Draft will expire on May December 31, 2009.

Copyright Notice

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

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

Abstract

   This document specifies an archiectectural framework for the
   application of MPLS in transport networks.  It describes a profile of
   MPLS that enables operational models typical in transport networks
   networks, while providing additional OAM, survivability and other
   maintenance functions not currently supported by MPLS.

Requirements Language

   The

   Although this document is not a protocol specification, 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 RFC2119 [1]. [RFC2119] and are to be
   interpreted as instructions to the protocol designers producing
   solutions that satisfy the architectural concepts set out in this
   document..

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Motivation and Background  . . . . . . . . . . . . . . . .  3
     1.2.  Applicability  . . . . . . . . . . . . . . . . . . . . . .  4
     1.3.  Scope  . . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.3.  5
     1.4.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  4  6
   2.  Summary of  Introduction to Requirements . . . . . . . . . . . . . . . . . . .  5  6
   3.  Transport Profile Overview . . . . . . . . . . . . . . . . . .  5  7
     3.1.  Architecture  Packet Transport Services  . . . . . . . . . . . . . . . .  7
     3.2.  Architecture . . . . . . .  5
     3.2.  Addressing . . . . . . . . . . . . . . . .  7
     3.3.  MPLS-TP Forwarding Domain  . . . . . . . .  6
     3.3.  Forwarding . . . . . . . . 10
     3.4.  MPLS-TP Transport Domain . . . . . . . . . . . . . . . .  8
     3.4.  Operations, Administration and Maintenance (OAM) . 11
     3.5.  Addressing . . . . .  9
       3.4.1.  Generic Associated Channel (G-ACH) . . . . . . . . . . 13
       3.4.2.  Generic Alert Label (GAL) . . . . . . . . . 11
     3.6.  Operations, Administration and Maintenance (OAM) . . . . . 15
     3.5. 13
     3.7.  Generic Associated Channel (G-ACh) . . . . . . . . . . . . 17
     3.8.  Control Plane  . . . . . . . . . . . . . . . . . . . . . . 16
       3.5.1. 20
       3.8.1.  PW Control Plane . . . . . . . . . . . . . . . . . . . 18
       3.5.2. 22
       3.8.2.  LSP Control Plane  . . . . . . . . . . . . . . . . . . 18
     3.6. 22
     3.9.  Static Operation of LSPs and PWs . . . . . . . . . . . . . 19
     3.7. 23
     3.10. Survivability  . . . . . . . . . . . . . . . . . . . . . . 19
     3.8. 23
     3.11. Network Management . . . . . . . . . . . . . . . . . . . . 21 24
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 22 25
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 22 26
   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 26
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 26
     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 23 26
     7.2.  Informative References . . . . . . . . . . . . . . . . . . 24 29

1.  Introduction

1.1.  Motivation and Background

   Existing transport technologies (e.g.  SDH, ATM, OTN) have been
   designed with specific characteristics:

   o  Strictly connection oriented

      *  Long-lived connections

      *  Manually provisioned connections

   o  High level

   This document describes a framework for a Multiprotocol Label
   Switching Transport Profile (MPLS-TP).  It presents the architectural
   framework for MPLS-TP, definining those elements of protection and availability

   o  Quality MPLS applicable
   to supporting the requirements in [I-D.ietf-mpls-tp-requirements] and
   what new protocol elements are required.

   Bandwidth demand continues to grow worldwide, stimulated by the
   accelerating growth and penetration of service new packet based services and
   multimedia applications:

   o  Extended OAM capabilities

   The development  Packet-based services such as Ethernet, Voice over IP (VoIP),
      Layer 2 (L2)/Layer 3 (L3) Virtual Private Networks (VPNs), IP
      Television (IPTV), Radio Access Network (RAN) backhauling, etc.,

   o  Applications with various bandwidth and Quality of MPLS-TP Service (QoS)
      requirements.

   This growth in demand has been driven by resulted in dramatic increases in access
   rates that are, in turn, driving dramatic increases in metro and core
   network bandwidth requirements.

   Over the past two decades, the evolving optical transport
   infrastructure (Synchronous Optical Networking (SONET)/Synchronous
   Digital Hierarchy (SDH), Optical Transport Network (OTN)) has
   provided carriers needing with a high benchmark for reliability and
   operational simplicity.  To achieve this, these existing transport
   technologies have been designed with specific characteristics :

   o  Strictly connection-oriented connectivity, which may be long-lived
      and may be provisioned manually or by network management.

   o  A high level of protection and availability.

   o  Quality of service.

   o  Extended OAM capabilities.

   Carriers are looking to evolve SONET/SDH such transport networks to support
   packet based services and networks, and the desire to take advantage of the
   flexibility and cost benefits of packet switching technology.  While
   MPLS is a maturing packet technology that is already playing an
   important role in transport networks and services, not all of MPLS's
   capabilities and mechanisms are needed and/or consistent with
   transport network operations.  There are also transport technology
   characteristics that are not currently reflected in MPLS.

   The types of packet transport services delivered by transport
   networks are very similar to Layer 2 Virtual Private Networks defined
   by the IETF.

   There are three objectives: thus two objectives for MPLS-TP:

   1.  To enable MPLS to be deployed in a transport network and operated
       in a similar manner to existing transport technologies.

   2.  To enable MPLS to support packet transport services with a
       similar degree of predictability to that found in existing
       transport networks.

   3.  To

   In order to achieve these objectives, there is a need to create a
   common set of new functions that are applicable to both MPLS networks
   in general, and those blonging to the MPLS-TP profile.

   MPLS-TP therefore defines a profile of MPLS targeted at transport applications.
   applications and networks.  This profile specifies the specific MPLS
   characteristics and extensions required to meet transport
   requirements.  An equipment conforming to MPLS-TP must MUST support this
   profile.  An MPLS-TP conformant equipment MAY support additional MPLS
   features.  A carrier may deploy some of those additional features in
   the transport layer of their network if they find them to be
   beneficial.

1.2.  Applicability

   Figure 1 illustrates the range of services that MPLS-TP is intended
   to address.  Networks supporting  MPLS-TP are is intended to support a range of layer 1,layer 1, layer
   2 and layer 3 services, and are is not limited to layer 3 services only.
   Networks implementing MPLS-TP may choose to only support a subset of
   these services.

                                          MPLS-TP Solution exists
                                           over this spectrum
                                  |<-------------------------------->|

cl-ps                      Multi-Service                     co-cs & co-ps
                          (cl-ps & co-ps)                      (Label is
  |                               |                        service context)
  |                               |                                  |
  |<------------------------------|--------------------------------->|
  |                               |                                  |
L3 Only                 L1, L2, L3 Services                 L1, L2 Services
                        Pt-Pt, Pt-MP, MP-MP                Pt-Pt and Pt-MP

                      Figure 1: MPLS-TP Service Spectrum

1.2.  Scope

   This document specifies Applicability

   The diagram above shows the high-level functionality spectrum of services that can be
   supported by MPLS.  MPLS-TP
   required solutions are primarily intended for adding transport-oriented capabilities to
   packet transport applications.  These can be deployed using a profile
   of MPLS

1.3.  Terminology that is strictly connection oriented and does not rely on IP
   forwarding or routing (shown on the right hand side of the figure),
   or in conjunction with an MPLS network that does use IP forwarding
   and that supports a broader range of IP services.  This is the multi-
   service solution in the centre of the figure.

1.3.  Scope

   This document describes a framework for a Tranport Profile of
   Multiprotocol Label Switching (MPLS-TP).  It presents the
   architectural framework for MPLS-TP, definining those elements of
   MPLS applicable to supporting the requirements in
   [I-D.ietf-mpls-tp-requirements] and what new protocol elements are
   required.

   This document describes the architecture for MPLS-TP when the LSP
   client is a PW.  The transport of IP and MPLS, other than carried
   over a PW, is outside the scope of this document.  This does not
   preclude the use of LSPs conforming to the MPLS transport profile
   from being used to carry IP or other MPLS LSPs by general purpose
   MPLS networks.

1.4.  Terminology

   Term    Definition
   ------- -----------------------------------------
   LSP     Label Switched Path
   MPLS-TP MPLS Transport profile
   SDH     Synchronous Digital Hierarchy
   ATM     Asynchronous Transfer Mode
   OTN     Optical Transport Network
   cl-ps   Connectionless - Packet Switched
   co-cs   Connection Oriented - Circuit Switched
   co-ps   Connection Oriented - Packet Switched
   OAM     Operations, Adminitration and Maintenance
   G-ACH
   G-ACh   Generic Associated Channel Header
   GAL     Generic Alert Label
   MEP     Maintenance End Point
   MIP     Maintenance Intermediate Point
   APS     Automatic Protection Switching
   SCC     Signaling Communication Channel
   MCC     Management Communication Channel
   EMF     Equipment Management Function
   FM      Fault Management
   CM      Configuration Management
   PM      Performance Management

   Detailed definitions and additional terminology may be found in
   [I-D.ietf-mpls-tp-requirements].

2.  Summary of  Introduction to Requirements

   This section summarizes the

   The requirements for the MPLS transport
   profile.  Such requirements MPLS-TP are specified in more detail in [20],
   [21],
   [I-D.ietf-mpls-tp-requirements], [I-D.ietf-mpls-tp-oam-requirements],
   and [22].

   Solutions [I-D.ietf-mpls-tp-nm-req].  This section provides a brief
   reminder to guide the reader.  It is not intended as a substitute for
   these documents.

   MPLS-TP MUST NOT modify the MPLS forwarding architecture.

   Solutions architecture and MUST be
   based on existing pseudowire and LSP constructs.

   New  Any new mechanisms
   and capabilities added to support transport networks and packet
   transport services must be able to interoperate or interwork with existing MPLS
   and pseudowire control and forwarding planes.

   Point to point LSPs MAY be unidirectional or bi-directional.  It bi-directional, and it
   MUST be possible to construct congruent Bi-directional LSPs.  Point
   to multipoint LSPs are unidirectional.

   MPLS-TP LSPs do not merge with other LSPs at an MPLS-TP LSR.  It is LSR and it
   MUST be possible to detect that if a merged LSP has been created.

   It MUST be possible to forward packets solely based on switching the
   MPLS or PW label.  It MUST also be possible to establish and maintain
   LSPs and/or pseudowires both in the absence or presence of a dynamic
   control plane.  When static provisioning is used, there MUST be no
   dependency on dynamic routing or signaling.

   OAM, protection and forwarding of data packets MUST be able to
   operate without IP forwarding support.

   It MUST be possible to monitor LSPs and pseudowires through the use
   of OAM in the absence of control plane or routing functions.  In this
   case information gained from the OAM functions is used to initiate
   path recovery actions at either the PW or LSP layers.

3.  Transport Profile Overview

3.1.  Architecture  Packet Transport Services

   The architecture for a transport profile types of packet transport services provided by existing transport
   networks are similar to MPLS (MPLS-TP) Layer 2 VPNs.  A key characteristic of
   packet transport services is based
   on that the MPLS-TE [2], pseudowire [3], and multi-segment pseudowire [4]
   architectures, as illustrated network used to provide the
   service does not participate in Figure 2.  The primary constructs of the any IP routing protocols present
   in the client, or use the IP addresses in client packets to forward
   those packets.  The network is therefore transparent to IP in the
   client service.

   MPLS-TP MUST use one of the Layer 2 VPN services defined in [PPVPN
   architecture] to provide a packet transport service.

   MPLS-TP LSPs MAY also be used to transport profie traffic for MPLS are LSPs, while PWs are which the primary
   immediate client layer. of the MPLS-TP LSP is not a Layer 2 VPN.  However,
   for the purposes of this document, we do not refer to these traffic
   types as belonging to a packet transport service.  Such clients
   include IP and MPLS LSPs.

3.2.  Architecture

   The architecture for a transport profile of MPLS (MPLS-TP) is based
   on the MPLS [RFC3031], pseudowire [RFC3985], and multi-segment
   pseudowire [I-D.ietf-pwe3-ms-pw-arch] architectures, as illustrated
   in Figure 2.

              |<-------------- Emulated Service ---------------->|
              |                                                  |
              |          |<------- Pseudo Wire ------>|          |
              |          |                            |          |
              |          |    |<-- PSN Tunnel -->|    |          |
              |          V    V                  V    V          |
              V    AC    +----+                  +----+     AC   V
        +-----+    |     | PE1|==================| PE2|     |    +-----+
        |     |----------|............PW1.............|----------|     |
        | CE1 |    |     |    |                  |    |     |    | CE2 |
        |     |----------|............PW2.............|----------|     |
        +-----+  ^ |     |    |==================|    |     | ^  +-----+
              ^  |       +----+                  +----+     | |  ^
              |  |   Provider Edge 1         Provider Edge 2  |  |
              |  |                                            |  |
        Customer |                                            | Customer
        Edge 1   |                                            | Edge 2
                 |                                            |
                 |                                            |
           Native service                               Native service

            Figure 2: MPLS-TP Architecture (Single Segment PW)

          Native  |<------------Pseudowire-------------->|  Native
          Service |         PSN              PSN         |  Service
           (AC)   |     |<--cloud->|     |<-cloud-->|    |   (AC)
             |    V     V          V     V          V    V     |
             |    +----+           +-----+          +----+     |
      +----+ |    |TPE1|===========|SPE1 |==========|TPE2|     | +----+
      |    |------|..... PW.Seg't1.........PW.Seg't3.....|-------|    |
      | CE1| |    |    |           |     |          |    |     | |CE2 |
      |    |------|..... PW.Seg't2.........PW.Seg't4.....|-------|    |
      +----+ |    |    |===========|     |==========|    |     | +----+
           ^      +----+     ^     +-----+     ^    +----+       ^
           |                 |                 |                 |
           |              TE LSP            TE LSP               |
           |                                                     |
           |                                                     |
           |<---------------- Emulated Service ----------------->|

                      Figure 2:

                  MPLS-TP Architecture (Multi-Segment PW)

   The above figures illustrates the MPLS-TP architecture used to
   provide a point-to-point packet transport service, or VPWS.  In this
   case, the MPLS-TP forwarding plane is a profile of the MPLS LSP PW, and
   SS-PW or MS-PW forwarding architecture as detailed in section
   Section 3.3.

   This document describes the architecture for MPLS-TP supports when the LSP
   client is a comprehensive set PW.  The transport of OAM IP and protection-switching
   capabilities for packet transport applications, with equivalent
   capabilities to existing SONET/SDH OAM and protection, as described
   in sections Section 3.4 and Section 3.7.  MPLS-TP may be operated
   with centralized Network Management Systems with or without MPLS, other than carried
   over a PW, is outside the
   support scope of a distributed control plane as described in sections
   Section 3.5 and Section 3.8.

   MPLS-TP defines mechanisms this document.  This does not
   preclude the use of LSPs conforming to differentiate specific packets (e.g.
   OAM, APS, MCC or SCC) from those carrying user data packets on the
   same LSP.  These mechanisms are described in sections
   Section 3.4.2and Section 3.4.1.

3.2.  Addressing

   MPLS-TP distinguishes between adressing MPLS transport profile
   from being used to identify nodes in carry IP or other MPLS LSPs by general purpose
   MPLS networks.  LSP hierarchy MAY be used within the MPLS-TP network, and identifiers used for demultiplexing and forwarding.
   This distinction is illustrated in Figure 3.

                             NMS                   Control/Signalling
                                 .....         .....
                            [Address]|         |   [Address]
                                     |         |
                               +-----+---------+------+
       Address = Node          |     |         |      |
       ID
   so that more than one LSP label MAY appear in forwarding plane  |     V         V      |
                               |                      |
                               |     MEP or MIP       |
                               | dmux                 |
                               | svcid                |
                               | src the label stack.

             +---------------------------+
             |
                               +--^-------------------+     PW Native service     |
      OAM:
             /===========================\
             H     PW Encapsulation      H \   <---- PW Control word
             H---------------------------H  \  <---- Normalised client
             H         PW OAM            H     MPLS-TP channel
             H---------------------------H  /
             H     PW Demux (S=1)        H /
             H---------------------------H \
             H         LSP OAM           H  \
             H---------------------------H  / MPLS-TP Path(s)
             H     LSP Demultiplexer(s)  H /
             \===========================/
             |
        dmux= [GAL/GACH]...........
                 or       ________________________________________
                IP       (________________________________________)
        svc context=ID/FEC             PWE=ID1
        SRC=IP                           .
                                         .
                                        IDx           Server          |
             +---------------------------+

        Figure 3: Addressing in Domain of MPLS-TP

   Ediror's note: The figure above arose from discussions in Layer Network using Pseudowires

   Figure (Figure 3) illustrates the MPLS-TP
   design team.  It will protocol stack to be clarified in a future verson of this draft.

   IPv4 or IPv6 addresses used when
   pseudowires are carried over MPLS-TP LSPs.

   When providing a VPWS, VPLS, VPMS or IPLS, pseudowires MUST be used
   to identify MPLS-TP nodes by default
   for network management and signaling purposes.

   In the forwarding plane, identfiers are required for the service
   context (provided by the FEC), and for OAM.  OAM requires both carry a
   demultiplexer and an address for client service.  For compatibility with transport
   nomenclature, the source of PW may be referred to as the OAM packet.

   For MPLS in general where IP addressing is used, IPv4 or IPv6 is used
   by default.  However, MPLS-TP must Channel and
   the LSP may be able referred to operate as the MPLS-TP Path.

   Note that in MPLS-TP environments where IP is not used in the forwarding plane.  Therefore, the default
   mechanism for OAM demultiplexing in MPLS-TP LSPs and PWs is the
   generic associated channel.  Forwarding based on IP addresses for
   user control or OAM packets is NOT REQUIRED for MPLS-TP.

   RFC 4379 [23]and BFD for MPLS LSPs [24] have defined alert mechanisms
   that enable a MPLS LSR to identify and process MPLS OAM packets when
   the OAM packets are encapsulated in an IP header.  These alert
   mechanisms are based on TTL expiration and/or use an
   purposes, IP destination
   address in the range 127/8.  These mechanisms are MAY be carried over the default
   mechanisms for MPLS networks in general for identifying MPLS OAM
   packets when LSP demultiplexers as per
   RFC3031 [RFC3031], or directly over the server.

   PW OAM, PSN OAM packets and PW client data are encapsulated in an IP header.
   MPLS-TP must not rely on these mechanisms, mutually exclusive and thus relies on never
   exist in the
   GACH/GAL same packet.

   The MPLS-TP definition applies to demultiplex OAM packets.

3.3. the following two domains:

   o  MPLS-TP Forwarding Domain

   o  MPLS-TP LSPs Transport Domain

3.3.  MPLS-TP Forwarding Domain

   A set of client-to-MPLS-TP adaptation functions interface the client
   to MPLS-TP.  For pseudowires, this adaptation function is the PW
   forwarder shown in Figure 4a of [RFC3985].  The PW label is used for
   forwarding in this case and is always at the bottom of the label
   stack.  The operation of the MPLS-TP network is independent of the
   payload carried by the MPLS-TP PW packet.

   MPLS-TP is itself a client of an underlying server layer.  MPLS-TP is
   thus bounded by a set of adaptation functions to this server layer
   network.  These adaptation functions provide encapsulation of the
   MPLS-TP frames and for the transparent transport of those frames over
   the server layer network.  The MPLS-TP client inherits its QoS from
   the MPLS-TP network, which in turn inherits its QoS from the server
   layer.  The server layer must therefore provide the neccesary Quality
   of Service (QoS) to ensure that the MPLS-TP client QoS commitments
   are satisfied.

   MPLS-TP LSPs use the MPLS label switching operations defined in [2].
   [RFC3031].  These operations are highly optimized for performance and
   are not modified by the MPLS-TP profile.

   During forwarding a label is pushed to describe associate a forwarding
   equivalence class (FEC) with the LSP or PW.  This specifies the
   processing operaton to be performed at by the next hop at that level of
   encapsulation.  A swap of this label is an atomic operation in which
   the contents of the packet after the swapped label are opaque to the
   forwarder.  The only circumstance event that disrupts interrupts a swap operation is TTL
   expiry, in which case the packet may be inspected and either
   discarded or subjected to further scrutinity processing within the LSR.  Operations on  TTL
   expiry causes an exception which forces a packet with an
   expired TTL are asynchronous to be further
   inspected and processed.  While this occurs, the other forwarding of
   succeeding packets in the LSP.  Thus continues without interruption.  Therefore, the
   only way to cause a P (intermediate) LSR to inspect a packet (for
   example for OAM purposes) is to set the TTL to expiry expire at that LSR.

   MPLS-TP PWs support the PW and MS-PW forwarding operations defined
   in[3]
   in[RFC3985] and [4]. [I-D.ietf-pwe3-ms-pw-arch].

   The Traffic Class field (former (formerly the MPLS EXP field) follows the
   definition and processing rules of [5] [RFC5462] and [6]. [RFC3270].  Only the
   pipe and short-pipe models are supported in MPLS-TP.

   The MPLS encapsulation format is as defined in RFC 3032[7].  Per-
   platform 3032[RFC3032].
   Per-platform label space is used for PWs.  Either per-platform or the
   per-interface label space can may be selected.  Standard
   PW encapsulation mechanisms are applicable used for LSPs.

   Point to the different client
   layers as defined by the IETF PWE3 WG. point MPLS-TP LSPs can be either unidirectional or bidirectional point-to-point.
   As for MPLS, point-to-multipoint
   bidirectional.  Point-to-multipoint MPLS-TP LSPs are unidirectional.
   Point-to-multipont PWs are currently in definition being defined in the IETF and
   may be incorporated in MPLS-TP if required.

   It MUST be possible to configure an MPLS-TP LSP such that the forward
   and backward directions of a bidirectional MPLS-TP LSPs congruent: LSP are co-routed
   i.e. they follow the same path.  The pairing relationship between the
   forward and the backward directions must be known at each MEP, MIP LSR or
   segment protection endpoint LER
   on a bidirectional LSP.

   Per-packet equal cost multi-path (ECMP) load balancing is not
   applicable to MPLS-TP LSPs, however PWs or LSPs that emulate link
   bundles may be employed, for example [25] LSPs.

   Penultimate hop popping (PHP) is disabled on MPLS-TP LSPs by default.
   The applicability of PHP to both MPLS-TP LSPs and MPLS networks in
   general providing paket transport services will be clarified in a
   future version of this draft.

   Both E-LSP and L-LSP are supported in MPLS-TP, as defined in RFC 3270
   [6].
   [RFC3270]

3.4.  Operations, Administration and Maintenance (OAM)  MPLS-TP requires [21] that a set of OAM capabilities is available to
   perform fault management (e.g. fault detection and localization) and
   performance monitoring (e.g. signal quality measurement) of Transport Domain

   This document specifies the
   MPLS-TP network and architecture when the services.  These capabilities are applicable
   at client of the section, LSP and PW layer.  The framework for OAM in
   MPLS-TP LSP is specified in [26].

   OAM and monitoring a PW.  Note, however, that in MPLS-TP environments
   where IP is based on used for control or OAM purposes, IP MAY be carried over
   the concept of maintenance
   entities, the LSPs or directly over the server, as described in [26].  A Maintenance Entity can be viewed
   as
   Section 3.2.  In this case, the association MPLS-TP transport domain consists of two (or more) Maintenance End Points (MEPs)
   (see example in Figure 4 ).  The MEPS that form an ME should be
   configured and managed to limit
   the OAM responsibilities PW encapsulation mechanisms, including the PW control word.

3.5.  Addressing

   Editor's note: This section will be updated after publication of an OAM
   flow within a network or sub-network the
   MPLS-TP Addressing Architecture draft.

   MPLS-TP distinguishes between adressing used to identify nodes in the specific layer network
   that is being monitored
   network, and managed.  Each OAM flow identifiers used for demultiplexing and forwarding.
   This distinction is associated to
   a unique ME.  Each illustrated in Figure 4.

                             NMS                   Control/Signalling
                                 .....         .....
                            [Address]|         |   [Address]
                                     |         |
                               +-----+---------+------+
       Address = Node          |     |         |      |
       ID in forwarding plane  |     V         V      |
                               |                      |
                               |     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.  Maintenance end points (MEPs) are capable of sourcing and
   sinking OAM flows, while maintenance intermediate points (MIPs) can
   only sink or respond to OAM flows.

========================== End to End LSP OAM ============================
     .....                     .....         .....            .....
-----|MIP|---------------------|MIP|---------|MIP|------------|MIP|-----
     '''''                     '''''         '''''            '''''

     |<-------- Carrier 1 --------->|        |<----- Carrier 2 ----->|
      ----     ---     ---      ----          ----     ---     ----
 NNI |    |   |   |   |   |    |    |  NNI   |    |   |   |   |    | NNI
-----| PE |---| P |---| P |----| PE |--------| PE |---| P |---| PE |-----
     |    |   |   |   |   | MIP       |
                               | dmux                 |
                               | svcid                |
                               | src                  |
                               +--^-------------------+
                                  |
      ----     ---     ---      ----          ----     ---     ----

      ==== Segment LSP OAM ======  == Seg't ==  === Seg't LSP OAM ===
            (Carrier 1)             LSP OAM         (Carrier 2)
                                (inter-carrier)
      .....   .....   .....  ..........   ..........  .....    .....
      |MEP|---|MIP|---|MIP|--|MEP||MEP|---|MEP||MEP|--|MIP|----|MEP|
      '''''   '''''   '''''  ''''''''''   ''''''''''  '''''    '''''

Note: MEPs for End-to-end LSP
      OAM:                OAM exist outside of the scope of this figure.     |
        dmux= [GAL/GACH]...........
                 or       ________________________________________
                IP       (________________________________________)
        svc context=ID/FEC             PWE=ID1
        SRC=IP                           .
                                         .
                                        IDx

                      Figure 4: Example of Addressing in MPLS-TP OAM

   Editor's note: The figure above diagram arose from discussions in the MPLS-TP
   design team.  It will be clarified in the next
   version a future verson of this draft.

   The

   IPv4 or IPv6 addresses are used to identify MPLS-TP nodes by default
   for network management and signaling purposes.

   In the forwarding plane, identfiers are required for the service
   context (provided by the FEC), and for OAM.  OAM architecture requires both a
   demultiplexer and an address for MPLS-TP is illustrated the source of the OAM packet.

   For MPLS in Figure 5.

     Native  |<-------------------- PW15 --------------------->| Native
      Layer  |                                                 |  Layer
    Service  |    |<-PSN13->| general where IP addressing is used, IPv4 or IPv6 is used
   by default.  However, MPLS-TP must be able to operate in environments
   where IP is not used in the forwarding plane.  Therefore, the default
   mechanism for OAM demultiplexing in MPLS-TP LSPs and PWs is the
   generic associated channel.  Forwarding based on IP addresses for
   user or OAM packets is NOT REQUIRED for MPLS-TP.

   RFC 4379 [RFC4379]and BFD for MPLS LSPs [I-D.ietf-bfd-mpls] have
   defined alert mechanisms that enable a MPLS LSR to identify and
   process MPLS OAM packets when the OAM packets are encapsulated in an
   IP header.  These alert mechanisms are based on TTL expiration and/or
   use an IP destination address in the range 127/8.  These mechanisms
   are the default mechanisms for MPLS networks in general for
   identifying MPLS OAM packets when the OAM packets are encapsulated in
   an IP header.  MPLS-TP must not rely on these mechanisms, and thus
   relies on the GACH/GAL to demultiplex OAM packets.

3.6.  Operations, Administration and Maintenance (OAM)

   MPLS-TP supports a comprehensive set of OAM capabilities for packet
   transport applications, with equivalent capabilities to those
   provided in SONET/SDH.

   MPLS-TP defines mechanisms to differentiate specific packets (e.g.
   OAM, APS, MCC or SCC) from those carrying user data packets on the
   same LSP.  These mechanisms are described in RFC5586 [RFC5586].

   MPLS-TP requires [I-D.ietf-mpls-tp-oam-requirements] that a set of
   OAM capabilities is available to perform fault management (e.g. fault
   detection and localization) and performance monitoring (e.g. packet
   delay and loss measurement) of the LSP, PW or section.  The framework
   for OAM in MPLS-TP is specified in [I-D.ietf-mpls-tp-oam-framework].

   OAM and monitoring in MPLS-TP is based on the concept of maintenance
   entities, as described in [I-D.ietf-mpls-tp-oam-framework].  A
   Maintenance Entity can be viewed as the association of two (or more)
   Maintenance End Points (MEPs) (see example in Figure 5 ).  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.

   Each OAM flow is associated with a single 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.  Maintenance end points (MEPs) are
   capable of sourcing and sinking OAM flows, while maintenance
   intermediate points (MIPs) can only sink or respond to OAM flows.

========================== End to End LSP OAM ============================
     .....                     .....         .....            .....
-----|MIP|---------------------|MIP|---------|MIP|------------|MIP|-----
     '''''                     '''''         '''''            '''''

     |<-------- Carrier 1 --------->|        |<--- Carrier 2 ----->|
      ----     ---     ---      ----          ----     ---     ----
 NNI |    |   |   |   |   |    |    |  NNI   |    |   |   |   |    | NNI
-----| PE |---| P |---| P |----| PE |--------| PE |---| P |---| PE |-----
     |    |   |   |   |   |    |    |        |    |   |   |   |    |
      ----     ---     ---      ----          ----     ---     ----

      ==== Segment LSP OAM ======  == Seg't ==  === Seg't LSP OAM ===
            (Carrier 1)             LSP OAM         (Carrier 2)
                                (inter-carrier)
      .....   .....   .....  ..........   ..........  .....    .....
      |MEP|---|MIP|---|MIP|--|MEP||MEP|---|MEP||MEP|--|MIP|----|MEP|
      '''''   '''''   '''''  ''''''''''   ''''''''''  '''''    '''''
      <------------ ME ----------><--- ME ----><------- ME -------->

Note: MEPs for End-to-end LSP OAM exist outside of the scope of this figure.

                     Figure 5: Example of MPLS-TP OAM

   Figure 6 illustrates how the concept of Maintenance Entities can be
   mapped to sections, LSPs and PWs in an MPLS-TP network that uses MS-
   PWs.

     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 PTCME ----.         .---- PW5 TPME -----. PTCME ---.
                  .---------.                   .---------.
                   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

SME: Section Maintenance Entity
LME: LSP Maintenance Entity
PME: PW Maintenance Entity

                     Figure 5: 6: MPLS-TP OAM archtecture

   The following MPLS-TP MEs are specified in [26]:
   [I-D.ietf-mpls-tp-oam-framework]:

   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), (LTCME), 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), (PTCME), allows monitoring and
      management of a SS/MS-PW Tandem Connection (or PW Segment) between
      any T-PE/S-PE along the (MS-)PW.  Note that the term Tandem
      Connection Monitoring has historical significance dating back to
      the early days of the telephone network, but is equally applicable
      to the two-level hierarchal architectures commonly employed in
      todays packet networks.

   Individual MIPs along the path of an LSP or PW are addressed by
   setting the appropriate TTL in the label for the OAM packet, as per
   [27].
   [I-D.ietf-pwe3-segmented-pw].  Note that this works when the location
   of MIPs along the LSP or PW path is known by the MEP.  There may be
   cases where this is not the case in general MPLS networks e.g.
   following restoration using a facility bypass LSP.

   The following is a high level summary of the classes of OAM functions
   that MPLS-TP supports.  These are intended to be applicable to any
   layer defined within MPLS- TP, i.e.  MPLS Section, LSP and PW:

   o  Continuity Check

   o  Connectivity verification

   o  Performance monitoring

   o  Alarm suppression

   o  Remote Integrity

   For all of the above listed functions except alarm suppression, both
   "continuous" and "on-demand" operation SHOULD be supported.

   Performance monitoring includes means for both "packet loss
   measurement" and "delay measurement".

   It is REQUIRED that

   MPLS-TP OAM packets share the same fate as their corresponding data packets
   packets, and that are identified through the Generic Associated Channel
   mechanism [RFC5586].  This uses a means exists combination of an Associated
   Channel Header (ACH) and a Generic Alert Label (GAL) to identify OAM
   packets. create a
   control channel associated to an LSP, Section or PW.

   The document[8] proposes specific mechanisms relying on the
   combination MPLS-TP OAM architecture support a wide range of OAM functions,
   including the 'Generic Alert Label (GAL)' and Generic Associated
   Channel Header for MPLS Sections and LSPs following

   o  Continuity Check

   o  Connectivity Verification

   o  Performance monitoring (e.g. loss and using the Generic
   Associated Channel Header only for delay)

   o  Alarm suppression

   o  Remote Integrity

   These are applicable to any layer defined within MPLS- TP, i.e.  MPLS PWs.  This is described in
   more detail elsewhere in this document Section 3.4.1
   Section, LSP and
   Section 3.4.2. PW.

   The MPLS-TP OAM toolset needs to be able to operate without relying
   on a dynamic control plane or IP functionality in the datapath.  In
   the case of MPLS-TP deployment with IP functionality, all existing
   IP-MPLS OAM functions, e.g.  LSP-Ping, BFD and VCCV, may be used.
   This does not preculde the use of other OAM tools in an IP
   addressable network.

   One use of OAM mechanisms is to detect link failures, node failures
   and performance outside the required specification which then may be
   used to trigger recovery actions, according to the requirements of
   the service.

3.4.1.  Generic Associated Channel (G-ACH)

   MPLS-TP makes use of a generic associated channel (G-ACH) to support
   Fault, Configuration, Accounting, Performance and Security (FCAPS)
   functions by carrying packets related to OAM, APS, SCC, MCC or other
   packet types in band over LSPs or PWs.  The G-ACH is defined in
   [8]and it is similar to the PWE3 Associated Channel, which is used to
   carry OAM packets across pseudowires.  The G-ACH is indicated by a
   generic associated channel header, similar to the PWE3 VCCV control
   word, and this is present for all LSPs and PWs making use of FCAPS
   functions supported by the G-ACH.

   The G-ACH MUST only be used for channels that are an adjunct to the
   data service.  Examples of these are OAM, APS, MCC and SCC, but the
   use is not resticted to those names services.  The G-ACH MUST NOT be
   used to carry additional data for preculde the use of other OAM tools in an IP
   addressable network.

   One use of OAM mechanisms is to detect link failures, node failures
   and performance outside the forwarding path, i.e. it
   MUST NOT required specification which then may be
   used as an alternative to a PW control word, or to define
   a PW type.

   The messages transfered over the G-ACH MUST conform trigger recovery actions, according to the security
   and congestion considerations described in [8].  They must also take
   into consideration the throughput, latency and congestion requirements of
   the main data channel.

   Figure 1 shows service.

3.7.  Generic Associated Channel (G-ACh)

   For correct operation of the reference model depicting how OAM it is important that the OAM packets
   fate share with the data packets.  In addition in MPSL-TP it is
   necessary to discriminate between user data payloads and other types
   of payload.  For example the packet may contain a Signaling
   Communication Channel (SCC), or a channel used for Automatic
   Protecton Switching (APS) data.  Such packetets are carried on a
   control channel
   is associated with to the pseudowire protocol stack, as per [9].

          +-------------+                                +-------------+
          |  Layer2     |                                |  Layer2     |
          |  Emulated   |       < Emulated Service >     |  Emulated   |
          |  Services   |                                |  Services   |
          +-------------+                                +-------------+
          |             |            VCCV/PW             |             |
          |Demultiplexer|    < Associated Channel >      |Demultiplexer|
          +-------------+                                +-------------+
          |    PSN      |          < PSN Tunnel >        |    PSN      |
          +-------------+                                +-------------+
          |  Physical   |                                |  Physical   |
          +-----+-------+                                +-----+-------+
                |                                              |
                |             ____     ___       ____          |
                |           _/    \___/   \    _/    \__       |
                |          /               \__/         \_     |
                |         /                               \    |
                +--------|      MPLS/MPLS-TP Network       |---+
                          \                               /
                           \   ___      ___     __      _/
                            \_/   \____/   \___/  \____/

      Figure 6: PWE3 Protocol Stack Reference Model including LSP, Section or PW.  This is
   achieved by carrying such packets on a generic control channel
   associated to the LSP, PW
                        Associated Control Channel

   PW or section.

   MPLS-TP makes use of such a generic associated channel messages are encapsulated using the PWE3
   encapsulation, so that they are handled (G-ACh) to
   support Fault, Configuration, Accounting, Performance and processed Security
   (FCAPS) functions by carrying packets related to OAM, APS, SCC, MCC
   or other packet types in the same
   manner (or band over LSPs or PWs.  The G-ACH is defined
   in some cases, an analogous manner) as [RFC5586]and it is similar to the PW PDUs for Pseudowire Associated Channel
   [RFC4385], which they provide is used to carry OAM packets across pseudowires.
   The G-ACH is indicated by a control channel.

   Figure 2 shows the reference model depicting how generic associated channel header (ACH),
   similar to the Pseudowire VCCV control channel word, and this is associated with the LSP protocol stack.

          +-------------+                                +-------------+
          |             |                                |             |
          |  Payload    |          < Service >           |   Payload   |
          |  Services   |                                |             |
          +-------------+                                +-------------+
          |             |            LSP                 |             |
          |Demultiplexer|     < Associated Channel >     |Demultiplexer|
          +-------------+                                +-------------+
          |    GAL      |                                |    GAL      |
          +-------------+                                +-------------+
          |    PSN      |            < LSP >             |    PSN      |
          +-------------+                                +-------------+
          |  Physical   |                                |  Physical   |
          +-----+-------+                                +-----+-------+
                |                                              |
                |             ____     ___       ____          |
                |           _/    \___/   \    _/    \__       |
                |          /               \__/         \_     |
                |         /                               \    |
                +--------|      MPLS/MPLS-TP Network       |---+
                          \                               /
                           \   ___      ___     __      _/
                            \_/   \____/   \___/  \____/

      Figure 7: MPLS Protocol Stack Reference Model including present for
   all Sections, LSPs and PWs making use of FCAPS functions supported by
   the G-ACH.

   For pseudowires, the G-ACh use the first nibble of the pseudowire
   control word to provide the initial discrimination between data
   packets a packets belonging to the LSP
                        Associated Control Channel

   LSP associated channel messages are encapsulated using channel, as described
   in[RFC4385].  When the first nibble of a generic packet, immediately
   following the label at the bottom of stack, has a value of one, then
   this packet belongs to a G-ACh.  The first 32 bits following the
   bottom of stack label then have a defined format called an associated control
   channel header (G-ACH).  The presence (ACH), which further defines the content of the GE-
   packet.  The ACH is indicated by therefore both a demultiplexer for G-ACh traffic
   on the PW, and a discriminator for the inclusion type of G-ACh traffic.

   When the OAM, or a similar message is carried over an additional LSP, rather
   than over a pseudowire, it is necessary to provide an indication in
   the packet that the payload is something other than a user data
   packet.  This is acheived by including a reserved label with a value
   of 13 in the label stack.  This reserved label is referred to as the
   'Generic Alert Label (GAL)'.  This arrangement means that both normal data packets (GAL)', and packets carrying is defined in [RFC5586].  When a GAL
   is found anywhere within the label stack it indicates that the
   payload begins with an ACH.  The GAL is thus a demultiplexer for
   G-ACh traffic on the LSP, and the ACH are carried over LSPs in is a similar
   manner. discriminator for the type
   of traffic carried on the G-ACh.  Note however that MPLS-TP
   forwarding follows the normal MPLS model, and that where a traffic engineered LSP GAL is used invisible
   to an LSR unless it is the top label iin the label stack.  The only
   other circumstance under which the paths will label stack may be
   identical.  If inspected for any reason a non-traffic engineered path (for
   example an LDP path) were to be used
   GAL is when the ECMP behaviour may be
   modified by TTL has expired.  Any MPLS-TP component that
   intentionally performs this inspection must assume that it is
   asynchronous with respect to the presence forwarding of other packets.  All
   operations on the GAL.

3.4.2.  Generic label stack arein accordance with [RFC3031] and
   [RFC3032].

   In MPLS-TP, the 'Generic Alert Label (GAL)

   For correct operation of (GAL)' always appears at the OAM it is important that
   bottom of the OAM packets
   fate share with label stack (i.e.  S bit set to 1), however this does
   not preclude its use elsewhere in the data packets.  In addition label stack in MPSL-TP it is
   necessary to indicate other
   applications.

   The G-ACH MUST only be used for channels that the payload carried over are an LSP is not
   user data.  For example adjunct to the packet may contain Signaling
   Communication Channel (SCC), or Automatic Protecton Switching (APS)
   data.  The presence
   data service.  Examples of these are OAM, APS, MCC and SCC, but the ACH indicates that the packet
   use is not user resticted to those names services.  The G-ACH MUST NOT be
   used to carry additional data and identifies its type.

   PWE3 uses the first nibble of for use in the forwarding path, i.e. it
   MUST NOT be used as an alternative to a PW control word word, or to provide define
   a PW type.

   Since the initial
   discrimination between G-ACh traffic is indistinguishable from the user data packets
   traffic at the server layer, bandwidth and "other" packets [10].  When QoS commitments apply to
   the first nibble of a pseudwire packet has a value of one, then gross traffic on the
   first 32 bits that follow LSP, PW or section.  Protocols using the
   G-ACh must therefore take into consideration the bottom of stack impact they have a defined format
   called an ACH, and which further defines on
   the content of user data that they are sharing resources with.  In addition,
   protocols using the
   pseudowire packet.  For MPLS-TP this mechanism is further generalized
   to apply to also apply G-ACh MUST conform to LSPs and MPLS sections [8].

   When the OAM, or a similar message is carried over an LSP, rather
   than over a pseudowire, it is necessary to provide an indication security and congestion
   considerations described in [RFC5586]. .

   Figure 7 shows the packet that reference model depicting how the payload is something other than a regular data
   packet.  This control channel
   is acheived by including ia new reserved label in associated with the
   label pseudowire protocol stack.  This reserved label is referred to as based on
   the 'Generic
   Alert Label (GAL)', and is defined reference model for VCCV shown in [8].  When a GAL is found
   anywhere within the label stack it indicates that Figure 2 of [RFC5085].

          +-------------+                                +-------------+
          |  Payload    |       < Service / FCAPS >      |  Payload    |
          +-------------+                                +-------------+
          |   Demux /   |       < CW / ACH for PWs >     |   Demux /   |
          |Discriminator|                                |Discriminator|
          +-------------+                                +-------------+
          |     PW      |             < PW >             |     PW      |
          +-------------+                                +-------------+
          |    PSN      |             < LSP >            |    PSN      |
          +-------------+                                +-------------+
          |  Physical   |                                |  Physical   |
          +-----+-------+                                +-----+-------+
                |                                              |
                |             ____     ___       ____          |
                |           _/    \___/   \    _/    \__       |
                |          /               \__/         \_     |
                |         /                               \    |
                +--------|      MPLS/MPLS-TP Network       |---+
                          \                               /
                           \   ___      ___     __      _/
                            \_/   \____/   \___/  \____/

     Figure 7: PWE3 Protocol Stack Reference Model including the payload begins
   with an ACH.  Note however that MPLS-TP forwarding follows G-ACh

   PW associated channel messages are encapsulated using the normal
   MPLS model, and PWE3
   encapsulation, so that a GAL is invisible to an LSR unless it is they are handled and processed in the
   label being popped.  The only circumstance under which same
   manner (or in some cases, an analogous manner) as the label
   stack may be inspected PW PDUs for
   which they provide a GAL is when control channel.

   Figure 8 shows the TTL has expired.  Any
   MPLS-TP component which intentionally triggers this inspection must
   assume that reference model depicting how the inspection to be asynchronous control channel
   is associated with respect to the
   forwarding of other packets.

   In MPLS-TP, the 'Generic Alert Label (GAL)' always appears at the
   bottom of the label stack (i.e.  S bit set to 1), however this does
   not preclude its use elsewhere in LSP protocol stack.

          +-------------+                                +-------------+
          |  Payload    |          < Service >           |   Payload   |
          +-------------+                                +-------------+
          |Discriminator|         < ACH on LSP >         |Discriminator|
          +-------------+                                +-------------+
          |Demultiplexer|         < GAL on LSP >         |Demultiplexer|
          +-------------+                                +-------------+
          |    PSN      |            < LSP >             |    PSN      |
          +-------------+                                +-------------+
          |  Physical   |                                |  Physical   |
          +-----+-------+                                +-----+-------+
                |                                              |
                |             ____     ___       ____          |
                |           _/    \___/   \    _/    \__       |
                |          /               \__/         \_     |
                |         /                               \    |
                +--------|      MPLS/MPLS-TP Network       |---+
                          \                               /
                           \   ___      ___     __      _/
                            \_/   \____/   \___/  \____/

      Figure 8: MPLS Protocol Stack Reference Model including the label stack in other
   applications.

3.5. LSP
                        Associated Control Channel

3.8.  Control Plane

   The

   MPLS-TP should be capable of being operated with centralized Network
   Management Systems (NMS).  The NMS may utilize be supported by a distributed
   control plane, but MPLS-TP can operated in the absense of such a
   control plane.  A distributed control plane may be used to enable fast,
   dynamic and reliable service provisioning in multi-vendor and multi-
   domain multi-domain
   environments using standardized protocols that guarantee
   interoperability.  Where the requirements specified in
   [I-D.ietf-mpls-tp-requirements] can be met, the MPLS transport
   profile uses existing control plane protocols for LSPs and PWs.

   Figure 8 9 illustrates the relationshop between the MPLS-TP control
   plane, the forwarding plane, the management plane, and OAM. OAM for point-
   to-point MPLS-TP LSPs or PWs.

 +------------------------------------------------------------------------+
 |                                                                        |
 |                   Network Management System and/or                     |
 |                                                                        |
 |           Control Plane for Point to Point Connections                 |
 |                                                                        |
 +------------------------------------------------------------------------+
              |      |           |       |          |    |
  ............|......|.....  ....|.......|....  ....|....|...............
            +---+    |    :  : +---+     |   :  : +---+  |              :
  :         |OAM|    |    :  : |OAM|     |   :  : |OAM|  |              :
  :         +---+    |    :  : +---+     |   :  : +---+  |              :
  :           |      |    :  :   |       |   :  :   |    |              :
 \: +----+   +----------+ :  : +----------+  :  : +----------+   +----+ :/
--+-|Edge|<->|Forwarding|<---->|Forwarding|<----->|Forwarding|<->|Edge|-+--
 /: +----+   |          | :  : |          |  :  : |          |   +----+ :\
  :          +----------+ :  : +----------+  :  : +----------+          :
  '''''''''''''''''''''''''  '''''''''''''''''   ''''''''''''''''''''''''

Note:
   1) NMS may be centralised or distributed. Control plane is distributed
   2) 'Edge' functions refers to those functions present at the edge of
      a PSN domain, e.g. NSP or classification.
   3) OAM functions are described in more detail below.

           Figure 8: 9: MPLS-TP Control Plane Architecture Context

   The MPLS-TP control plane is based on a combination of the MPLS LDP-based
   control plane for pseudowires [RFC4447] and the GMPLS RSVP-TE based control
   plane for MPLS-TP
   LSPs, respectively.  More specifically, LDP is used for PW signaling
   and GMPLS based LSPs [RFC3471].  Some of the RSVP-TE functions that
   are required for LSP signaling. signaling for MPLS-TP are based on GMPLS.

   The distributed MPLS-TP control plane provides the following basic
   functions:

   o  Signaling

   o  Routing

   o  Traffic engineering and constraint-based path computation

   In a multi-domain environment, the MPLS-TP control plane may provide supports
   different types of interfaces at domain boundaries or within the
   domains such as UNI, I-NNI,
   domains.  These include the User-Network Interface (UNI), Internal
   Network Node Interface (I-NNI), and E-NNI where External Network Node Interface
   (E-NNI).  Note that different policies are in
   place may be defined that control what kind of
   the information is exchanged across these
   different types of interfaces.

   Editor's note: Isn't the following a managment plane operation.  I
   can't think of a routing protocol triggering an OAM message.  Or do
   we mean that the control plane is capable of reacting to OAM events?
   Control plane and OAM are independent. interface types.

   The MPLS-TP control plane is capable of activating MPLS-TP OAM
   functions as described in the OAM section of this document
   Section 3.4 3.6 e.g. for fault detection and localization in the event of
   a failure in order to efficiently restore failed transport paths.

   The MPLS-TP control plane supports all MPLS-TP data plane
   connectivity patterns that are needed for establishing transport
   paths including protected paths as described in the survivability
   section Section 3.7 3.10 of this document.  Examples of the MPLS-TP data
   plane connectivity patterns are LSPs utilizing the fast reroute
   backup methods as defined in [11] [RFC4090] and ingress-to-egress 1+1 or
   1:1 protected LSPs.

   Moreover, the MPLS-TP control plane needs to be capable of performing
   fast restoration in the event of network failures.

   The MPLS-TP control plane provides features functions to ensure its own
   survivavbility
   survivability and to enable it to recover gracefully from failures
   and degredations.  These include graceful restart and hot redundant
   configurations.  The MPLS-TP  Depending on how the control plane is largely decoupled from
   the MPLS-TP data plane such that failures in transported,
   varying degrees of decoupling between the control plane do not
   impact the and data
   plane and vice versa.

3.5.1. may be achieved.

3.8.1.  PW Control Plane

   An MPLS-TP packet transport network provides many of its transport services in the form of using
   single-segment or multi-segment pseudowires
   following pseudowires, in compliance with the
   PWE3 architecture as defined in [3] ([RFC3985] and [4] . [I-D.ietf-pwe3-ms-pw-arch] ).  The
   setup and maintenance of single-segment or multi- segment pseudowires
   is based on
   uses the Label Distribution Protocol (LDP) as per [12] [RFC4447] and the
   use of LDP in this manner is applicable to PWs used to provide MPLS
   transport services.

   It shall be noted that multi-segment pseudowire signaling is still
   work in progress.  The control plane supporting multi-segment
   pseudowires is based on [13].

3.5.2.
   extensions for MS-PWs [I-D.ietf-pwe3-segmented-pw] and
   [I-D.ietf-pwe3-dynamic-ms-pw].

3.8.2.   LSP Control Plane

   Editors note: The following must be reviewed by a CP specialist.  Lou
   will review and provide comments.

   MPLS-TP provider edge nodes aggregate multiple pseudowires and carry
   them across the MPLS-TP network through MPLS-TP tunnels (MPLS-TP
   LSPs).  The generalized  Applicable functions from the Generalized MPLS (GMPLS)
   protocol suite already supports supporting packet-switched capable (PSC) technologies and is therefore
   are used as the control plane for MPLS-TP transport paths (LSPs).

   The LSP control plane includes:

   o  RSVP-TE for signalling

   o  OSPF-TE for routing

   o or ISIS-TE for routing

   RSVP-TE signaling in support of GMPLS GMPLS, as defined in [14]is [RFC4872], is
   used for the setup, modification, and release of MPLS-TP transport
   paths and protection paths.  It supports unidirectional, bi-directional bi-
   directional and multicast types of LSPs.  The route of a transport
   path is typically calculated in the ingress node of a domain and the
   RSVP explicit route object (ERO) is utilized for the setup of the
   transport path exactly following the given route.  GMPLS based
   MPLS-TP LSPs must be able to interoperate with RSVP-TE based MPLS-TE
   LSPs, as per [28] [RFC5146]

   OSPF-TE routing in support of GMPLS as defined in [15] [RFC4203] is used
   for carrying link state information in a MPLS-TP network.

   For  ISIS-TE
   routing scalability reasons, parallel physical links in an MPLS-
   TP network are typically bundled into TE-links support of GMPLS as defined in [16]and
   the OSPF-TE routing protocol disseminates [RFC5307] is used for
   carrying link state information on in a
   TE-link basis.

3.6. MPLS-TP network.

3.9.  Static Operation of LSPs and PWs

   Where a control plane is not used to set up and manage PWs

   A PW or LSPs, LSP may be statically configured without the following considerations apply.  Static configuration support of the PW
   or LSP, a
   dynamic control plane.  This may be either by direct configuration of
   the PEs/LSRs, or via a network management station must take care that loops to not form on
   an active LSP. system.  The OAM would normally detect a break in end to end
   connectivity as a consequence of a loop, and withdraw the LSP from
   use.  However the colateral
   damage that a loop loops can cause during the time taken to detect the
   failure is may be severe.  Therefore an LSP should not  When static configuration mechanisms are
   used, care must be brought into operation until it certain taken to ensure that loops do to not exist.

3.7. form.

3.10.  Survivability

   Survivability requirements for MPLS-TP are apecified specified in [29].
   [I-D.ietf-mpls-tp-survive-fwk].

   A wide variety of resiliency schemes have been developed to meet the
   various network and service survivability objectives.  For example,
   as part of the MPLS/PW paradigms, MPLS provides methods for local
   repair using back-up LSP tunnels ([11]), ([RFC4090]), while pseudowire
   redundancy
   [17]supports [I-D.ietf-pwe3-redundancy] supports scenarios where the
   protection for the PW can not be fully provided by the PSN layer
   (i.e. where the backup PW terminates on a different target PE node
   than the working PW).  Additionally, GMPLS provides a well known set
   of control plane driven well known protection and restoration mechanisms [14].  Finally, as part of the transport
   networks and applications paradigms, APS-based
   [RFC4872].  MPLS-TP provides additional protection mechansisms that
   are optimised for both linear topologies and ring
   protection mechanisms are defined topologies, and
   that operate in [18]and [30]. the absense of a dynamic control plane.  These are
   specified in [I-D.ietf-mpls-tp-survive-fwk].

   Different protection schemes have apply to different scopes.  They are protecting against
   link and/or node failures deployment topologies
   and can be applied end-to-end or on a
   segment of the considered connection.

   These operational considerations.  Such protection schemes propose may provide
   different levels of resiliency (e.g.
   1+1, 1:1, shared). resiliency.  For example, two concurrent traffic
   paths (1+1), one active and one standby path with guaranteed
   bandwidth on both paths (1:1) or one active path and a standby path
   that is shared by one or more other active paths (shared protection).
   The applicability of any given scheme to meet specific requirements
   is outside the current scope of this document.

   The characteristics of MPLS-TP resiliency mechanisms characteristics are listed below
   below.

   o  Linear,  Optimised for linear, ring and or meshed protection schemes are supported. topologies.

   o  As with all network layer protection schemes, MPLS-TP recovery
      mechanisms (protection and restoration), rely on  Use OAM mechanisms to detect and localize network faults or
      service degenerations.

   o  APS-based protection mechanisms (linear and ring) rely on MPLS-TP
      APS  Include protection mechanisms to coordinate and trigger protection
      switching
      actions. actions in the absense of a dynamic control plane.  This
      is known as an Automatic Protection Switching (APS) mechanism.

   o  MPLS-TP recovery schemes are designed to be applicable at various to all levels (MPLS in the
      MPLS-TP domain (i.e.  MPLS section, LSP and PW), providing segment
      and end-to- end recovery.

   o  MPLS-TP recovery mechanisms support means for avoiding the coordination of protection
      switching at multiple levels to prevent race conditions in switching activity triggered by occuring
      between a fault condition
      detected both at server layer client and at MPLS-TP its server layer.

   o  MPLS-TP recovery mechanisms can be data plane, control plane or
      management plane based.

   o  MPLS-TP allows for supports revertive and non-revertive behavior

   o  Multiple resiliency mechanisms can be applied to any connection

3.8. behavior.

3.11.  Network Management

   The network management architecture and requirements for MPLS-TP are
   specified in [22]. [I-D.ietf-mpls-tp-nm-req].  It derives from the generic
   specifications described in ITU-T G.7710/Y.1701 [19]for [G.7710] for
   transport technologies.  It also leverages on incorporates the OAM requirements
   for MPLS Networks [31] [RFC4377] and MPLS-TP Networks [21]and
   [I-D.ietf-mpls-tp-oam-requirements] and expands on the those requirements
   to cover the modifications necessary for fault, configuration,
   performance, and
   security. security in a transport network.

   The Equipment Management Function (EMF) of a MPLS-TP NE Network Element
   (NE) (i.e.  LSR, LER, PE, S-PE or T-PE) provides the means through
   which a management system manages the NE.  The Management
   Communication Channel (MCC), realized by the G-ACH, G-ACh, provides a
   logical operations channel between NEs for transferring Management
   information.  For the management interface from a management system
   to a MPLS-TP NE, there is no restriction on which management protocol
   should be used.  It is allowed used to provision and manage an end-to-end
   connection across a network where some segments are create/managed,
   for examples by Netconf or SNMP and other segments by XML or CORBA
   interfaces.  It is allowed to run
   maintenance  Maintenance operations are run on a connection which (LSP or
   PW) in a manner that is independent of the provisioning mechanism.

   An MPLS-TP NE is not required to offer more than one standard
   management interface.  In MPLS-TP. MPLS-TP, the EMF MUST must be capable of
   statically provisioning LSPs for an LSR or LER, and PWs for a PE, as
   per Section 3.6.

   The 3.9.

   Fault Management (FM) functions within the EMF of an MPLS-TP NE
   enable the supervision, detection, validation, isolation, correction,
   and alarm handling of abnormal operation of conditions in the MPLS-TP network and
   its environment.  Supervision  FM must provide for the supervision of transmission
   (such as continuity, connectivity, etc.), software processing,
   hardware, and environment
   are essential for FM. environment.  Alarm handling includes alarm severity
   assignment, alarm suppression/aggregation/correlation, alarm
   reporting control, and alarm reporting.

   Configuration Management (CM) provides functions to exercise control
   over, control,
   identify, collect data from, and provide data to MPLS-TP NEs.  In
   addition to general configuration for hardware, software protection
   switching, alarm reporting control, and date/time setting, the EMF of
   the MPLS-TP NE also supports the configuration of maintenance entity
   identifiers (such as MEP ID and MIP ID).  The EMF also supports the
   configuration of the OAM parameters as a part of connectivity management
   to meet specific operational requirements,
   such as requirements.  These may specify whether
   the operational mode is one-time on-demand or periodically based on is periodic at a
   specified frequency.

   The Performance Management (PM) functions within the EMF of an MPLS-
   TP NE supports support the evaluation and reporting upon of the behaviour of the
   equipment, NE,
   NEs and network with the objective of providing network.  One particular requirement for PM is to provide
   coherent and consistent interpretation of the network behaviour, behaviour in particular
   for a
   hybrid network which consists of that uses multiple transport technologies.  Packet
   loss measurement and delay measurement are collected so that
   they can measurements may be collected and used to
   detect performance degradation.  Performance
   degradation  This is reported via fault
   management for to enable corrective actions to be taken (e.g. protection switch)
   switching), and via performance monitoring for Service Level
   Agreement (SLA) verification and billing.  The  Collection mechanisms for
   performance data
   collection mechanisms should be flexible to should be configured to operate capable of operating on-demand
   or proactively.

4.  Security Considerations

   The introduction of MPLS-TP into transport networks means that the
   security considerations applicable to both MPLS and PWE3 apply to
   those transport networks.  Furthermore, when general MPLS networks
   that utilise functionality outside of the strict MPLS-TP profile are
   used to support packet transport services, the security
   considerations of that additional functionality also apply.

   Specific

   The security considerations for of [RFC3985] and
   [I-D.ietf-pwe3-ms-pw-arch] apply.

   Each MPLS-TP will be detailed in
   documents covering specific aspects on solution must specify the MPLS-TP architecture. addtional security
   considerations that apply.

5.  IANA Considerations

   IANA considerations resulting from specific elements of MPLS-TP
   functionality will be detailed in the documents specifying that
   functionality.

   This document introduces no additional IANA considerations in itself.

6.  Acknowledgements

   The editors wish to thank the following for their contribution to
   this document:

   o  Dieter Beller

   o  Italo Busi

   o  Hing-Kam Lam

   o  Marc Lasserre

   o  Vincenzo Sestito

   o  Martin Vigoureux

   o  Malcolm Betts

7.  References

7.1.  Normative References

   [1]

   [G.7710]                             "ITU-T Recommendation G.7710/
                                        Y.1701 (07/07), "Common
                                        equipment management function
                                        requirements"", 2005.

   [I-D.ietf-mpls-cosfield-def]         Andersson, L. and R. Asati,
                                        "Multi-Protocol Label Switching
                                        (MPLS) label stack entry: "EXP"
                                        field renamed  to "Traffic
                                        Class" field",
                                        draft-ietf-mpls-cosfield-def-08
                                        (work in progress),
                                        December 2008.

   [I-D.ietf-pwe3-ms-pw-arch]           Bocci, M. and S. Bryant, "An
                                        Architecture for Multi-Segment
                                        Pseudowire Emulation Edge-to-
                                        Edge",
                                        draft-ietf-pwe3-ms-pw-arch-06
                                        (work in progress),
                                        February 2009.

   [I-D.ietf-pwe3-redundancy]           Muley, P. and M. Bocci,
                                        "Pseudowire (PW) Redundancy",
                                        draft-ietf-pwe3-redundancy-01
                                        (work in progress),
                                        September 2008.

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

   [2]

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

   [3]   Bryant, S.

   [RFC3032]                            Rosen, E., Tappan, D., Fedorkow,
                                        G., Rekhter, Y., Farinacci, D.,
                                        Li, T., and P. Pate, "Pseudo Wire Emulation Edge-to-Edge
         (PWE3) Architecture", A. Conta, "MPLS
                                        Label Stack Encoding", RFC 3985, March 2005.

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

   [5]   Andersson, L. and R. Asati, ""EXP field" renamed to "Traffic
         Class field"", draft-ietf-mpls-cosfield-def-07 (work in
         progress), November 2008.

   [6] 3032,
                                        January 2001.

   [RFC3270]                            Le Faucheur, F., Wu, L., Davie,
                                        B., Davari, S., Vaananen, P.,
                                        Krishnan, R., Cheval, P., and J.
                                        Heinanen, "Multi-Protocol Label
                                        Switching (MPLS) Support of
                                        Differentiated Services",
                                        RFC 3270, May 2002.

   [7]   Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci,
         D., Li, T., and A. Conta, "MPLS

   [RFC3471]                            Berger, L., "Generalized Multi-
                                        Protocol Label Stack Encoding", Switching (GMPLS)
                                        Signaling Functional
                                        Description", RFC 3032, 3471,
                                        January 2001.

   [8]   Vigoureux, M., Bocci, M., Ward, D., 2003.

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

   [RFC4090]                            Pan, P., Swallow, G., and R.
         Aggarwal, "MPLS Generic Associated Channel",
         draft-bocci-mpls-tp-gach-gal-00 (work A.
                                        Atlas, "Fast Reroute Extensions
                                        to RSVP-TE for LSP Tunnels",
                                        RFC 4090, May 2005.

   [RFC4201]                            Kompella, K., Rekhter, Y., and
                                        L. Berger, "Link Bundling in progress),
                                        MPLS Traffic Engineering (TE)",
                                        RFC 4201, October 2008.

   [9]   Nadeau, T. 2005.

   [RFC4203]                            Kompella, K. and C. Pignataro, "Pseudowire Virtual Circuit
         Connectivity Verification (VCCV): A Control Channel for
         Pseudowires", Y. Rekhter,
                                        "OSPF Extensions in Support of
                                        Generalized Multi-Protocol Label
                                        Switching (GMPLS)", RFC 5085, December 2007.

   [10] 4203,
                                        October 2005.

   [RFC4385]                            Bryant, S., Swallow, G.,
                                        Martini, L., and D. McPherson,
                                        "Pseudowire Emulation Edge-to-Edge Edge-to-
                                        Edge (PWE3) Control Word for Use
                                        over an MPLS PSN", RFC 4385,
                                        February 2006.

   [11]  Pan, P., Swallow, G., and A. Atlas, "Fast Reroute Extensions to
         RSVP-TE for LSP Tunnels", RFC 4090, May 2005.

   [12]

   [RFC4447]                            Martini, L., Rosen, E., El-Aawar, El-
                                        Aawar, N., Smith, T., and G.
                                        Heron, "Pseudowire Setup and
                                        Maintenance Using the Label
                                        Distribution Protocol (LDP)",
                                        RFC 4447, April 2006.

   [13]  Martini, L., Bocci, M., Bitar, N., Shah, H., Aissaoui, M., and
         F. Balus, "Dynamic Placement of Multi Segment Pseudo Wires",
         draft-ietf-pwe3-dynamic-ms-pw-08 (work in progress), July 2008.

   [14]

   [RFC4872]                            Lang, J., Rekhter, Y., and D.
                                        Papadimitriou, "RSVP-TE
                                        Extensions in Support of End-to-End End-to-
                                        End Generalized Multi-Protocol
                                        Label Switching (GMPLS)
                                        Recovery", RFC 4872, May 4872, May 2007.

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

   [15]

   [RFC5307]                            Kompella, K. and Y. Rekhter, "OSPF
                                        "IS-IS Extensions in Support of
                                        Generalized Multi-Protocol Label
                                        Switching (GMPLS)", RFC 4203, 5307,
                                        October 2005.

   [16]  Kompella, K., Rekhter, Y., and 2008.

   [RFC5462]                            Andersson, L. Berger, "Link Bundling in
         MPLS Traffic Engineering (TE)", RFC 4201, October 2005.

   [17]  Muley, P. and M. R. Asati,
                                        "Multiprotocol Label Switching
                                        (MPLS) Label Stack Entry: "EXP"
                                        Field Renamed to "Traffic Class"
                                        Field", RFC 5462, February 2009.

   [RFC5586]                            Bocci, "Pseudowire (PW) Redundancy",
         draft-ietf-pwe3-redundancy-01 (work in progress),
         September 2008.

   [18]  "ITU-T Recommendation G.8131/Y.1382 (02/07) " Linear protection
         switching for Transport MPLS (T-MPLS) networks"", 2005.

   [19]  "ITU-T Recommendation G.7710/Y.1701 (07/07), "Common equipment
         management function requirements"", 2005.

7.2.  Informative References

   [20]  Niven-Jenkins, B., Brungard, D., Betts, M., and N. Sprecher,
         "MPLS-TP Requirements",
         draft-jenkins-mpls-mpls-tp-requirements-01 (work in progress),
         October 2008.

   [21] Vigoureux, M., Ward, D., Betts, M., Bocci, M., and I. Busi,
         "Requirements for OAM in MPLS Transport Networks",
         draft-vigoureux-mpls-tp-oam-requirements-01 (work in progress),
         November 2008.

   [22]  Mansfield, S.
                                        Bryant, "MPLS Generic Associated
                                        Channel", RFC 5586, June 2009.

7.2.  Informative References

   [I-D.bryant-filsfils-fat-pw]         Bryant, S., Lam, K., Filsfils, C., Drafz,
                                        U., Kompella, V., Regan, J., and E. Gray, "MPLS TP Network
         Management Requirements", draft-gray-mpls-tp-nm-req-01
                                        S. Amante, "Flow Aware Transport
                                        of MPLS Pseudowires",
                                        draft-bryant-filsfils-fat-pw-03
                                        (work in progress), October 2008.

   [23]  Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label
         Switched (MPLS) Data Plane Failures", RFC 4379, February 2006.

   [24] March 2009.

   [I-D.ietf-bfd-mpls]                  Aggarwal, R., Kompella, K.,
                                        Nadeau, T., and G. Swallow, "BFD
                                        For MPLS LSPs",
                                        draft-ietf-bfd-mpls-07 (work in
                                        progress), June 2008.

   [25]  Bryant, S., Filsfils, C.,

   [I-D.ietf-mpls-tp-nm-req]            Mansfield, S. and U. Drafz, "Load Balancing Fat
         MPLS Pseudowires", draft-bryant-filsfils-fat-pw-02 K. Lam, "MPLS
                                        TP Network Management
                                        Requirements",
                                        draft-ietf-mpls-tp-nm-req-02
                                        (work in progress), July 2008.

   [26] June 2009.

   [I-D.ietf-mpls-tp-oam-framework]     Busi, I. and B. Niven-Jenkins,
                                        "MPLS-TP OAM Framework and
                                        Overview", draft-busi-mpls-tp-oam-framework-00 draft-ietf-mpls-tp-
                                        oam-framework-00 (work in
                                        progress), March 2009.

   [I-D.ietf-mpls-tp-oam-requirements]  Vigoureux, M., Ward, D., and M.
                                        Betts, "Requirements for OAM in
                                        MPLS Transport Networks", draft-
                                        ietf-mpls-tp-oam-requirements-02
                                        (work in progress), June 2009.

   [I-D.ietf-mpls-tp-requirements]      Niven-Jenkins, B., Brungard, D.,
                                        Betts, M., Sprecher, N., and S.
                                        Ueno, "MPLS-TP Requirements", dr
                                        aft-ietf-mpls-tp-requirements-09
                                        (work in progress), June 2009.

   [I-D.ietf-mpls-tp-survive-fwk]       Sprecher, N., Farrel, A., and H.
                                        Shah, "Multiprotocol Label
                                        Switching Transport Profile
                                        Survivability Framework", draft-
                                        ietf-mpls-tp-survive-fwk-00
                                        (work in progress), April 2009.

   [I-D.ietf-pwe3-dynamic-ms-pw]        Martini, L., Bocci, M., Bitar,
                                        N., Shah, H., Aissaoui, M., and
                                        F. Balus, "Dynamic Placement of
                                        Multi Segment Pseudo Wires",
                                        draft-ietf-pwe3-dynamic-ms-pw-09
                                        (work in progress), October 2008.

   [27] March 2009.

   [I-D.ietf-pwe3-segmented-pw]         Martini, L., Nadeau, T., Metz,
                                        C., Duckett, M., Bocci, M.,
                                        Balus, F., and L.
         Martini, M. Aissaoui,
                                        "Segmented Pseudo Wire",
         draft-ietf-pwe3-segmented-pw-09 (work in progress), July 2008.

   [28]  Kumaki, K., "Interworking Requirements to Support Operation of
         MPLS-TE over GMPLS Networks", RFC 5146, March 2008.

   [29]  Sprecher, N., Farrel, A., and V. Kompella, "Multiprotocol Label
         Switching Transport Profile Survivability Framework",
         draft-sprecher-mpls-tp-survive-fwk-00 Pseudowire",
                                        draft-ietf-pwe3-segmented-pw-12
                                        (work in progress),
         July 2008.

   [30]  "Draft ITU-T Recommendation G.8132/Y.1382, "T-MPLS shared
         protection ring",
         http://www.itu.int/md/T05-SG15-080211-TD-PLEN-0501/en", 2005.

   [31] June 2009.

   [RFC4377]                            Nadeau, T., Morrow, M., Swallow,
                                        G., Allan, D., and S.
                                        Matsushima, "Operations and
                                        Management (OAM) Requirements
                                        for Multi-Protocol Label
                                        Switched (MPLS) Networks",
                                        RFC 4377, February 2006.

   [RFC4379]                            Kompella, K. and G. Swallow,
                                        "Detecting Multi-Protocol Label
                                        Switched (MPLS) Data Plane
                                        Failures", RFC 4379,
                                        February 2006.

   [RFC5146]                            Kumaki, K., "Interworking
                                        Requirements to Support
                                        Operation of MPLS-TE over GMPLS
                                        Networks", RFC 5146, March 2008.

Authors' Addresses

   Matthew Bocci (editor)
   Alcatel-Lucent
   Voyager Place, Shoppenhangers Road
   Maidenhead, Berks  SL6 2PJ
   United Kingdom

   Phone: +44-207-254-5874
   EMail: matthew.bocci@alcatel-lucent.com

   Stewart Bryant (editor)
   Cisco Systems
   250 Longwater Ave
   Reading  RG2 6GB
   United Kingdom

   Phone: +44-208-824-8828
   EMail: stbryant@cisco.com

   Lieven Levrau (editor)
   Alcatel-Lucent
   7-9, Avenue Morane Sulnier
   Velizy  78141
   France

   Phone: +33-6-33-86-1916
   EMail: lieven.levrau@alcatel-lucent.com

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

   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.

Intellectual Property

   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.

   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.