MPLS Working Group                                         M. Bocci, Ed.
Internet-Draft                                            Alcatel-Lucent
Intended status: Standards Track Informational                            S. Bryant, Ed.
Expires: April 19, June 25, 2010                                          D. Frost
                                                           Cisco Systems
                                                               L. Levrau
                                                          Alcatel-Lucent
                                                        October 16,
                                                               L. Berger
                                                                    LabN
                                                       December 22, 2009

               A Framework for MPLS in Transport Networks
                    draft-ietf-mpls-tp-framework-06
                    draft-ietf-mpls-tp-framework-07

Abstract

   This document specifies an architectural framework for the
   application of Multiprotocol Label Switching (MPLS) to the
   construction of packet-switched equivalents of traditional circuit-
   switched carrier networks.  It describes a common set of protocol
   functions - the MPLS Transport Profile (MPLS-TP) - that supports the
   operational models and capabilities typical of such networks,
   including signaled or explicitly provisioned bi-directional
   connection-oriented paths, protection and restoration mechanisms,
   comprehensive Operations, Administration and Maintenance (OAM)
   functions, and network operation in the absence of a dynamic control
   plane or IP forwarding support.  Some of these functions are defined
   in existing MPLS specifications, while others require extensions to
   existing specifications to meet the requirements of the MPLS-TP.

   This document defines the subset of the MPLS-TP applicable in general
   and to point-to-point paths.  The remaining subset, applicable
   specifically to point-to-multipoint paths, are out of scope of this
   document.

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

Status of This Memo

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

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

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

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

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

   This Internet-Draft will expire on April 19, June 25, 2010.

Copyright Notice

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

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

Abstract

   This  Code Components extracted from this document specifies an architectural framework for the
   application of Multi Protocol Label Switching (MPLS) must
   include Simplified BSD License text as described in transport
   networks, by enabling the construction of packet switched equivalents
   to traditional circuit switched carrier networks.  It describes a
   common set Section 4.e of protocol functions - the MPLS Transport Profile
   (MPLS-TP) - that supports
   the operational models Trust Legal Provisions and capabilities
   typical of such networks for point-to-point paths, including signaled
   or explicitly provisioned bi-directional connection-oriented paths,
   protection and restoration mechanisms, comprehensive Operations,
   Administration and Maintenance (OAM) functions, and network operation
   in the absence of a dynamic control plane or IP forwarding support.
   Some of these functions exist in existing MPLS specifications, while
   others require extensions to existing specifications to meet the
   requirements of the MPLS-TP.

Requirements Language

   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 [RFC2119].

   Although this document is not a protocol specification, these key
   words are to be interpreted as instructions to the protocol designers
   producing solutions that satisfy the architectural concepts set out
   in this document.

Table are provided without warranty as
   described in the BSD License.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Motivation and Background  . . . . . . . . . . . . . . . .  4
     1.2.  Scope  . . . . . . . . . . . . . . . . . . . . . . . . . .  5
     1.3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  6
       1.3.1.  MPLS  Transport Profile. Network  . . . . . . . . . . . . . . . . . .  6
       1.3.2.  MPLS Transport Profile . . . . . . . . . . . . . . . .  7
       1.3.3.  MPLS-TP Section  . . . . . . . . . . . . . . . . . . .  6
       1.3.3.  7
       1.3.4.  MPLS-TP Label Switched Path  . . . . . . . . . . . . .  6
       1.3.4.  7
       1.3.5.  MPLS-TP Label Switching Router (LSR) and Label
               Edge Router (LER)  . . . . . . . . . . . . . . . . . .  7
       1.3.5.  MPLS-TP
       1.3.6.  Customer Edge (CE) . . . . . . . . . . . . . . . . . .  8
       1.3.6.
       1.3.7.  Additional Definitions and Terminology . . . . . . . .  8
     1.4.  Applicability  . . . . . . . . . . . . . . . . . . . . . .  8
   2.  Introduction to  MPLS Transport Profile Requirements  . . . . . . . . . . . . . . . . . 10 11
   3.  MPLS Transport Profile Overview  . . . . . . . . . . . . . . . . . . 11 12
     3.1.  Packet Transport Services  . . . . . . . . . . . . . . . . 11 12
     3.2.  Scope of the MPLS Transport Profile  . . . . . . . . . . . . . 12 13
     3.3.  Architecture . . . . . . . . . . . . . . . . . . . . . . . 12 14
       3.3.1.  MPLS-TP Client Adaptation Functions  . . . . . . . . . 14
       3.3.2.  MPLS-TP Forwarding Functions . . . . . . . . . 13
       3.3.2.  MPLS-TP Forwarding Functions . . . . 15
     3.4.  MPLS-TP Native Services  . . . . . . . . . 13
     3.4.  MPLS-TP Client Adaptation . . . . . . . . 16
       3.4.1.  MPLS-TP Client/Server Relationship . . . . . . . . 15
       3.4.1. . . 17
       3.4.2.  Pseudowire Adaptation using Pseudowires  . . . . . . . . . . . . . 15
       3.4.2. . . . 17
       3.4.3.  Network Layer Clients  . Adaptation . . . . . . . . . . . . . . . 18 20
     3.5.  Identifiers  . . . . . . . . . . . . . . . . . . . . . . . 21 24
     3.6.  Operations, Administration and Maintenance (OAM)  Generic Associated Channel (G-ACh) . . . . . 22
       3.6.1.  OAM Architecture . . . . . . . 24
     3.7.  Operations, Administration and Maintenance (OAM) . . . . . 27
       3.7.1.  OAM Architecture . . . . . . . 22
       3.6.2.  OAM Functions . . . . . . . . . . . . 28
       3.7.2.  OAM Functions  . . . . . . . . 25
     3.7.  Generic Associated Channel (G-ACh) . . . . . . . . . . . . 26 31
     3.8.  Control Plane  . . . . . . . . . . . . . . . . . . . . . . 29 32
       3.8.1.  PW Control Plane . . . . . . . . . . . . . . . . . . . 31 34
       3.8.2.  LSP Control Plane  . . . . . . . . . . . . . . . . . . 31 34
     3.9.  Static Operation of LSPs and PWs . . . . . . . . . . . . . 32 35
     3.10. Survivability  . . . . . . . . . . . . . . . . . . . . . . 32 35
     3.11. Network Management . . . . . . . . . . . . . . . . . . . . 33 37
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 34 38
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 35 38
   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35 38
   7.  Open Issues  . . . . . . . . . . . . . . . . . . . . . . . . . 36 39
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 36 40
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 36 40
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 38 42

1.  Introduction

1.1.  Motivation and Background

   This document describes a an architectural framework for a Multiprotocol Label
   Switching Transport Profile (MPLS-TP).  It presents the architectural
   framework for MPLS-TP, defining those elements
   application of MPLS applicable to
   supporting the construction of packet-switched transport
   networks.  It specifies the common set of protocol functions that
   meet the requirements in [RFC5654] [RFC5654], and what new protocol
   elements that together constitute the
   MPLS Transport Profile (MPLS-TP) for point-to-point paths.  The
   remaining MPLS-TP functions, applicable specifically to point-to-
   multipoint paths, are required. out of scope of this document.

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

   o  Strictly connection-oriented connectivity, which may be long-lived
      and may be provisioned manually (i.e. configuration of the node
      via a command line interface) or by network management.

   o  A high level of protection and availability.

   o  Quality of service.

   o  Extended  Extensive OAM capabilities.

   Carriers wish to evolve such transport networks to support packet
   based services, and to take advantage of
   the flexibility and cost benefits of packet switching technology. technology and
   to support packet based services more efficiently.  While MPLS is a
   maturing packet technology that is already playing plays an important role in
   transport networks and services, not all of MPLS's MPLS capabilities and
   mechanisms are needed and/or in or consistent with the transport network
   operations.
   operational model.  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 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.

   In order to achieve these objectives, there is a need to create define a
   common set of new MPLS protocol functions - an MPLS Transport Profile -
   for the use of MPLS in transport networks and applications.  Some of
   the necessary functions that are provided by existing MPLS specifications,
   while others require additions to the MPLS tool-set.  Such additions
   should, wherever possible, be applicable to both MPLS networks in general, and general
   as well as those belonging that conform strictly to the MPLS-TP profile.

   MPLS-TP therefore defines transport network
   model.

   This document is a profile product of a joint Internet Engineering Task Force
   (IETF) / International Telecommunications Union Telecommunications
   Standardization Sector (ITU-T) effort to include an MPLS targeted at transport
   applications and networks.  This profile specifies Transport
   Profile within the specific IETF MPLS
   characteristics and extensions required PWE3 architectures to meet support the
   capabilities and functionalities of a packet transport
   requirements. network as
   defined by the ITU-T.

1.2.  Scope

   This document describes an architectural framework for the
   application of MPLS to the construction of packet-switched transport
   networks.  It specifies the common set of protocol functions that
   meet the requirements in [RFC5654], and that together constitute the
   MPLS Transport Profile (MPLS-TP).
   The architecture (MPLS-TP) for point-to-point MPLS-TP paths is described. transport
   paths.  The
   architecture for remaining MPLS-TP functions, applicable specifically to
   point-to-multipoint paths is outside the transport paths, are out of scope of this
   document.

1.3.  Terminology

   Term       Definition
   ---------------- ------------------------------------------
   ---------- ----------------------------------------------------------
   LSP        Label Switched Path
   MPLS-TP    MPLS Transport profile 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, Administration and Maintenance
   G-ACh      Generic Associated Channel
   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
   LSR        Label Switch Router. Switching Router
   MPLS-TP PE MPLS-TP Provider Edge LSR
   MPLS-TP P Router An  MPLS-TP Provider (P) router LSR
   PW         Pseudowire
   Adaptation The mapping of client information into a format suitable
              for transport by the server layer
   Native     The traffic belonging to the client of the MPLS-TP network
   Service
   T-PE       PW Terminating Provider Edge
   S-PE       PW Switching provider Edge

1.3.1.  Transport Network

   A Transport Network provides transparent transmission of client user
   plane traffic between attached client devices by establishing and
   maintaining point-to-point or point-to-multipoint connections between
   such devices.  The architecture of networks supporting point to
   multipoint connections is out of scope of this document.  A Transport
   Network is independent of any higher-layer network that may exist
   between clients, except to the extent required to supply this
   transmission service.  In addition to client traffic, a Transport
   Network may carry traffic to facilitate its own operation, such as
   that required to support connection control, network management, and
   Operations, Administration and Maintenance (OAM) functions.

   See also the definition of Packet Transport Service in Section 3.1.

1.3.2.  MPLS Transport Profile. Profile

   The MPLS Transport Profile (MPLS-TP) is the subset of MPLS functions
   that meet the requirements in [RFC5654].  Note that MPLS is defined
   to include any present and future MPLS capability specified by the
   IETF, including those capabilities specifically added to support the
   transport network requirement requirements [RFC5654].

1.3.2.

1.3.3.  MPLS-TP Section

   An MPLS-TP Section is defined in Section 1.1.2 1.2.2 of [RFC5654].

1.3.3.

1.3.4.  MPLS-TP Label Switched Path

   An MPLS-TP Label Switched Path (MPLS-TP LSP) is an LSP that uses a
   subset of the capabilities of an MPLS LSP in order to meet the
   requirements of an MPLS transport network as set out in [RFC5654].
   The characteristics of an MPLS-TP LSP are primarily that it:

   1.  Uses a subset of the MPLS OAM tools defined as described in
       [I-D.ietf-mpls-tp-oam-framework].

   2.  Supports only 1+1, 1:1, and 1:N protection functions.

   3.  Is traffic engineered.

   4.  Is  May be established and maintained via the management plane, or
       using GMPLS protocols when a control plane is used.

   5.  LSPs can only be point to point  Is either point-to-point or point-to-multipoint.  Multipoint to
       point and multipoint to multipoint, i.e. the
       merging of multipoint LSPs is are not permitted.

   Note that an MPLS LSP is defined to include any present and future
   MPLS capability include capability, including those specifically added to support the
   transport network requirements.

1.3.4.

1.3.5.  MPLS-TP Label Switching Router (LSR) and Label Edge Router (LER)

   Editor's Note: These terms are here for clarity - but this is not the
   authoritative definition - (need to find a definition)

   An MPLS-TP Label Switching Router (MPLS-TP LSR) (LSR) is either an MPLS-TP Provider
   Edge (MPLS-TP PE) (PE) router or an MPLS-TP Provider (MPLS-TP P Router) (P) router for a given LSP,
   as defined below.  The terms MPLS-TP PE router and MPLS-TP P router
   describe functions and logical functions; a specific node may undertake
   both roles. only one of
   these roles on a given LSP.

   Note that the use of the term "router" in this context is historic
   and neither requires nor precludes the ability to perform IP
   forwarding.

1.3.4.1.

1.3.5.1.  MPLS-TP Provider Edge Router (PE) Router

   An MPLS-TP Provider Edge Router (PE) router is an MPLS-TP LSR that adapts
   client traffic and encapsulates it to be carried transported over an MPLS-TP
   LSP.  Encapsulation may be as simple as pushing a label, or it may
   require the use of a pseudowire.  An MPLS-TP PE exists at the
   interface between a pair of layer networks.  For an MS-PW, an MPLS-TP
   PE may be either an S-PE or a T-PE. T-PE, as defined in [RFC5659].

   A layer network is defined in [G.805].

1.3.4.2.

1.3.5.2.  MPLS-TP Provider Router (P) Router

   An MPLS-TP Provider router is an MPLS-TP LSR that does not provide
   MPLS-TP PE functionality. functionality for a given LSP.  An MPLS-TP P router
   switches LSPs which carry client traffic, but do does not adapt the client
   traffic and encapsulate it to be carried over an MPLS-TP LSP.

1.3.5.  MPLS-TP

1.3.6.  Customer Edge (CE)

   An MPLS-TP

   A Customer Edge (CE) is the client function sourcing or sinking
   client
   native service traffic to or from the MPLS-TP network.  CEs on either
   side of the MPLS-TP network are peers and view the MPLS-TP network as
   a single point to point point-to-point or point to multi-point point-to-multipoint link.  These clients
   have no knowledge of the presence of the interveining MPLS-TP
   network.

1.3.6.

1.3.7.  Additional Definitions and Terminology

   Detailed definitions and additional terminology may be found in
   [RFC5654].

1.4.  Applicability

   MPLS-TP can be used to construct a packet transport networks and is
   therefore applicable in any packet transport network application. context.  It is
   also as an alternative architecture for applicable to subsets of a packet network where the transport
   network operational model is deemed attractive.  The following are
   examples of MPLS-TP applicability models:

   1.  MPLS-TP provided by a network that only supports MPLS-TP, MPLS-TP LSPs and
       PWs (i.e.  Only MPLS-TP LSPs and PWs exist between the PEs or
       LSRs), acting as a server for other layer 1, layer 2 and layer 3
       networks (Figure 1).

   2.  MPLS-TP provided by a network that also supports non-MPLS-TP
       functions, LSPs
       and PWs (i.e. both LSPs and PWs that conform to the transport
       profile and those that do not, exist between the PEs), acting as
       a server for other layer 1, layer 2 and layer 3 networks
       (Figure 2).

   3.  MPLS-TP as a server layer for client layer traffic of IP or MPLS
       networks which do not use functions of the MPLS transport profile
       profile.  For MPLS traffic, the MPLS-TP server layer network uses
       PW switching or LSP stitching at the PE that terminates the
       MPLS-TP server layer (Figure 3). - See notes in word document -
       ref = rfc5150

   These models are not mutually exclusive.

MPLS-TP LSP, provided by a network that only supports MPLS-TP, acting as
    a server for other layer 1, layer 2 and layer 3 networks.

            |<-- L1/2/3 -->|<-- MPLS-TP-->|<-- L1/2/3 -->|
                                 Only

                               MPLS-TP
                         +---+   LSP    +---+
          +---+  Client  |   |----------|   | Client   +---+
          |CE1|==Traffic=|PE2|==========|PE3|=Traffic==|CE1|
          +---+          |   |----------|   |          +---+
                         +---+          +---+

  Example  a)  [Ethernet]     [Ethernet]     [Ethernet]
  layering                    [   PW   ]
                              [-TP LSP ]

           b)  [   IP   ]     [  IP    ]     [  IP   ]
                              [  LSP Demux  ]
                              [-TP LSP ]

                  Figure 1: MPLS-TP Server Layer Example

   MPLS-TP LSP, provided by a network that also supports non-MPLS-TP
       functions, acting as a server for other layer 1, layer 2 and
       layer 3 networks.

               |<-- L1/2/3 -->|<-- MPLS -->|<-- L1/2/3 -->|

                                  MPLS-TP
                            +---+   LSP    +---+
             +---+  Client  |   |----------|   | Client   +---+
             |CE1|==Traffic=|PE2|==========|PE3|=Traffic==|CE1|
             +---+          |   |----------|   |          +---+
                            +---+          +---+

   Example  a)  [Ethernet]       [Ethernet]     [Ethernet]
   layering                      [   PW   ]
                                 [-TP LSP ]

            b)  [   IP   ]       [  IP    ]     [  IP   ]
                                 [  LSP Demux  ]
                                 [-TP LSP ]

                 Figure 2: MPLS-TP in MPLS Network Example

MPLS-TP as a server layer for client layer traffic of IP or MPLS
    networks which do not use functions of the MPLS transport
    profile.

              |<-- MPLS ---->|<-- MPLS-TP-->|<--- MPLS --->|
                                   Only

  +---+   +---+   +----+  Non-TP  +---+  +----+  MPLS-TP +---+ +----+  Non-TP  +----+   +---+
  |CE1|---|T-PE|====LSP===|S-PE|====LSP===|S-PE|====LSP===|S-PE|---|CE2|
  +---+
  |CE1|---|PE1|====LSP===|PE2|====LSP===|PE3|====LSP===|PE4|-----|CE2|
  +---+   +---+          +---+          +---+          +---+   +----+          +----+          +----+          +----+   +---+
                       (PW switching)  (PW switching)

(a)  [ Eth ]   [   Eth  ]       [  Eth   ]     [   Eth  ]     [ Eth ]
               [ MS-PW ]      [ MS-PW  ]     [ MS-PW ]
               [PW Seg't]       [PW Seg't]     [PW Seg't]
               [   LSP  ]       [-TP LSP ]     [   LSP  ]

(a)

             |<-- MPLS ---->|<-- MPLS-TP-->|<--- MPLS --->|
                                  Only

  +---+   +----+  Non-TP  +----+  MPLS-TP +----+  Non-TP  +----+   +---+
  |CE1|---| PE |====LSP===| PE |====LSP===| PE |====LSP===| PE |---|CE2|
  +---+   +----+          +----+          +----+          +----+   +---+
                       (LSP stitching) (LSP stitching)

(b)  [ IP ]      [  IP  ]       [   IP   ]     [  IP   ]     [ IP  ]
                 [  LSP ]       [-TP LSP ]     [  LSP  ]

           Figure 3: MPLS-TP Transporting Client Service Traffic

2.  Introduction to  MPLS Transport Profile Requirements

   The requirements for MPLS-TP are specified in [RFC5654],
   [I-D.ietf-mpls-tp-oam-requirements], and [I-D.ietf-mpls-tp-nm-req].
   This section provides a brief reminder to guide the reader and is
   therefore not normative.  It is not intended as a substitute for
   these documents.

   MPLS-TP must not modify the MPLS forwarding architecture and must be
   based on existing pseudowire and LSP constructs.

   Point to point LSPs may be unidirectional or bi-directional, and it
   must be possible to construct congruent Bi-directional LSPs.

   MPLS-TP LSPs do not merge with other LSPs at an MPLS-TP LSR and it
   must be possible to detect 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.  MPLS Transport Profile Overview

3.1.  Packet Transport Services

   One objective of MPLS-TP is to enable MPLS networks to provide packet
   transport services with a similar degree of predictability to that
   found in existing transport networks.  Such packet transport services
   inherit a number of characteristics, defined in [RFC5654]:

   o  In an environment where an MPLS-TP layer network is supporting a
      client layer network, and the MPLS-TP layer network is supported
      by a server layer network then operation of the MPLS-TP layer
      network MUST must be possible without any dependencies on either the
      server or client layer network.

   o  The service provided by the MPLS-TP network to the client is
      guaranteed not to fall below the agreed level regardless of other
      client activity.

   o  The control and management planes of any client network layer that
      uses the service is isolated from the control and management
      planes of the MPLS-TP layer network, where the client network
      layer is considered to be the native service of the MPLS-TP
      network.

   o  Where a client network makes use of an MPLS-TP server that
      provides a packet transport service, the level of co-ordination
      required between the client and server layer networks is minimal
      (preferably no co-ordination will be required).

   o  The complete set of packets generated by a client MPLS(-TP) layer
      network using the packet transport service, which may contain
      packets that are not MPLS packets (e.g.  IP or CNLS packets used
      by the control/management plane of the client MPLS(-TP) layer
      network), are transported by the MPLS-TP server layer network.

   o  The packet transport service enables the MPLS-TP layer network
      addressing and other information (e.g. topology) to be hidden from
      any client layer networks using that service, and vice-versa.

   Therefore,

   These characteristics imply that a packet transport service doe does not
   support a connectionless packet switched packet-switched forwarding mode.  However,
   this does not preclude it carrying client traffic associated with a
   connectionless service.

   Such packet transport services are very similar to Layer 2 Virtual
   Private Networks as defined by the IETF.

3.2.  Scope of the MPLS Transport Profile

   Figure 4 illustrates the scope of MPLS-TP.  MPLS-TP solutions are
   primarily intended for packet transport applications.  MPLS-TP is a
   strict sub-set subset of MPLS, and comprises only those functions that are
   necessary to meet the requirements of [RFC5654].  This includes MPLS
   functions that were defined prior to [RFC5654] but that meet the
   requirements of [RFC5654], together with additional functions defined
   to meet those requirements.  Some MPLS functions defined before
   [RFC5654] e.g. such as Equal Cost Multi-Path, LDP signaling used in such a
   way that it creates multi-point to point multipoint-to-point LSPs, and IP forwarding in
   the data plane are explicitly excluded from MPLS-TP by that
   requirements specification.

   Note that this does not preclude the future definition of MPLS as a whole will continue to evolve to include
   additional functions that do not meet conform to the requirements of [RFC5654] MPLS Transport
   Profile or its requirements, and thus fall outside the scope of MPLS-TP as defined by this document.

                                        {Additional Transport Functions}
                           |<============== MPLS-TP ==================>|
   MPLS-TP.

  |<============================== MPLS ==============================>|

  |<============= Pre-RFC5654 MPLS ================>|
    {      ECMP       }
    { LDP/non-TE LSPs }
    { ECMP, mp2p LDP,     IP fwd      }
  |<====== Pre-RFC5654 MPLS ===========>|
  |<============================== MPLS ==============================>|

                        Figure 4: Scope of

                      |<================ MPLS-TP

3.3. ====================>|
                                                      { Additional }
                                                      {  Transport }
                                                      {  Functions }

                        Figure 4: Scope of MPLS-TP

3.3.  Architecture

   MPLS-TP comprises the following architectural elements:

   o  Sections, LSPs and PWs that provide a packet transport service for
      a client network.

   o  Proactive and on demand Operations on-demand Operations, Administration and Maintenance
      (OAM) functions to monitor and diagnose the MPLS-TP network. e.g. network, such
      as connectivity check, connectivity verification, and performance
      monitoring.
      monitoring and fault localisation.

   o  Optional control planes for LSPs and PWs, as well as support for
      static provisioning and configuration.

   o  Path  Optional path protection mechanisms to ensure that the packet
      transport service survives anticipated failures and degradations
      of the MPLS-TP network.

   o  Network management functions.

   The MPLS-TP architecture for LSPs and PWs includes the the following two
   sets of functions:

   o  MPLS-TP client adaptation

   o  MPLS-TP forwarding

   The adaptation functions interface the client native service to MPLS-TP.
   This includes the case where the client native service is an MPLS-TP LSP.

   The forwarding functions comprise the mechanisms required for
   forwarding the encapsulated client traffic over an MPLS-TP server
   layer
   network E.g. network, for example PW label and LSP label. labels.

3.3.1.  MPLS-TP Client Adaptation Functions

   The MPLS-TP native service adaptation interfaces functions interface the client
   service to MPLS-TP.  For pseudowires, these adaptation functions are
   the payload encapsulation
   shown described in Figure 7 Section 4.4 of [RFC3985] and Figure 7
   Section 6 of
   [I-D.ietf-pwe3-ms-pw-arch]. [RFC5659].  For network layer client services, the
   adaptation function uses the MPLS encapsulation format as defined in
   RFC 3032[RFC3032].
   [RFC3032].

   The purpose of this encapsulation is to abstract the client service
   data plane from the MPLS-TP data plane, thus contributing to the
   independent operation of the MPLS-TP network.

   MPLS-TP is itself a client of an underlying server layer.  MPLS-TP is
   thus also bounded by a set of adaptation functions to this server
   layer network, which may itself be MPLS-TP.  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 Quality of Service (QoS) from the
   MPLS-TP network, which in turn inherits its QoS from the server
   layer.  The server layer must therefore provide the necessary Quality of Service (QoS) QoS to
   ensure that the MPLS-TP client QoS commitments are can be satisfied.

3.3.2.  MPLS-TP Forwarding Functions

   The forwarding functions comprise the mechanisms required for
   forwarding the encapsulated client over an MPLS-TP server layer
   network E.g.
   network, for example PW label and LSP label. labels.

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

   In addition, MPLS-TP PWs use the PW SS-PW and MS-PW forwarding
   operations defined in[RFC3985] in [RFC3985] and [I-D.ietf-pwe3-ms-pw-arch]. [RFC5659].  The PW label is
   processed by a PW forwarder and is always at the bottom of the label
   stack for a given MPLS-TP layer network.

   Per-platform label space is used for PWs.  Either per-platform, per-
   interface or other context-specific label space [RFC5331] may be used
   for LSPs.

   MPLS-TP forwarding is based on the label that identifies the
   transport path (LSP or PW).  The label value specifies the processing
   operation to be performed 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 event that interrupts a swap operation is TTL
   expiry.  This is a fundamental architectural construct of MPLS to be
   taken into account when design designing protocol extensions that requires require
   packets (e.g.  OAM packets) to be sent to an intermediate LSR.

   Further processing to determine the context of a packet occurs when a
   swap operation is interrupted in this manner, or a pop operation
   exposes a specific reserved label at the top of the stack.  Otherwise
   the packet is forwarded according to the procedures in [RFC3032].

   Point to point

   Point-to-point MPLS-TP LSPs can be either unidirectional or
   bidirectional.

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

   In normal conditions, all the packets sent over a PW or an LSP follow
   the same path through the network and those that belong to a common
   ordered aggregate are delivered in order.  For example per-packet
   equal cost multi-path (ECMP) load balancing is not applicable to
   MPLS-TP LSPs.

   Penultimate hop popping (PHP) is disabled on MPLS-TP LSPs by default.

   MPLS-TP supports Quality of Service capabilities via the MPLS
   Differentiated Services (DiffServ) architecture [RFC3270].  Both
   E-LSP and L-LSP MPLS DiffServ modes are supported in MPLS-TP, as defined in
   [RFC3270]. supported.  The Traffic Class
   field (formerly the MPLS EXP field) of an MPLS label follows the
   definition and processing rules of [RFC5462] and [RFC3270].  Note
   that packet reordering between flows belonging to different traffic
   classes may occur if more than one traffic class is supported on a
   single LSP.

   Only the pipe Pipe and short-pipe Short Pipe DiffServ tunnelling and TTL processing
   models described in [RFC3270] and [RFC3443] are supported in MPLS-TP.

3.4.  MPLS-TP Client Adaptation Native Services

   This document specifies the architecture for two types of client native
   service adaptation:

   o  A PW: PW Demultiplexer and PW encapsulation

   o  An MPLS Label

   When

   A PW can carry any emulated service defined by the client is IETF to be
   provided by a PW, for example Ethernet, Frame Relay, or PPP/HDLC.  A
   registry of PW types is maintained by IANA.  When the MPLS-TP client
   adaptation functions
   include is via a PW, the PW encapsulation mechanisms, including mechanisms described in Section 3.4.2 are
   used.

   An MPLS LSP Label can also be used as the PW control
   word. adaptation, in which case
   any network layer client supported by MPLS is allowed, for example an
   MPLS LSP, PW, or IP.  When the client adaptation is operating at the network layer via an MPLS
   label, the
   mechanism mechanisms described in Section 3.4.2 is 3.4.3 are used.

3.4.1.  Adaptation using Pseudowires  MPLS-TP Client/Server Relationship

   The architecture for a transport profile relationship of MPLS-TP to its clients is illustrated in
   Figure 5.

      PW-Based                          MPLS Labelled
      Services                            Services

   Emulated             PW              LSP             IP
   Service
                  +------------+
                  | PW Payload |
 +------------+   +------------+  +------------+               (CLIENTS)
 | PW Payload |   |PW Lbl(S=1) |  |     IP     |
~~~~~~~~~~~~~~~~~ +------------+  +------------+  +------------+
 |PW Lbl (S=1)| | |LSP Lbl(S=0)|  |LSP Lbl(S=1)|  |     IP     |
 +------------+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 |LSP Lbl(S=0)|   |LSP Lbl(S=0)|  |LSP Lbl(S=0)|  |LSP Lbl(S=1)|
 +------------+   +------------+  +------------+  +------------+

                                                               (MPLS-TP)

~~~~~~~~~~~ = Client - MPLS-TP layer boundary

                  Figure 5: MPLS-TP - Client Relationship

   The data plane behaviour of MPLS-TP is the same as the best current
   practise for MPLS.  This includes the setting of the S-Bit.  In each
   case, the S-bit is set to indicate the bottom (i.e. inner-most) label
   in the label stack that is contiguous between the MPLS-TP server and
   the client layer.

   Note that this best current practise differs slightly from [RFC3032]
   which uses the S-bit to identify when MPLS label processing stops and
   network layer processing starts.

   Note that the label stacks shown above are those inside MPLS-TP
   network.  They illustrate the smallest number of labels possible.
   These label stacks could also include more labels.

3.4.2.  Pseudowire Adaptation

   The architecture for an MPLS-TP client adaptation that uses PWs is
   based on the MPLS [RFC3031] and pseudowire [RFC3985] architectures.
   If multi-segment pseudowires are used to provide a packet transport
   service, motivated by, for example, the requirements specified in [RFC5254]
   [RFC5254], then the MS-PW architecture
   [I-D.ietf-pwe3-ms-pw-arch] [RFC5659] also applies.

   Figure 5 6 shows the architecture for an MPLS-TP network using single-
   segment PWs.

              |<--------------

            |<--------------- Emulated Service ---------------->| ----------------->|
            |                                                    |
            |          |<-------          |<-------- Pseudowire ------->| -------->|          |
            |          |      encapsulated packet     |          |
            |          |     Pkt Xport Service      transport service       |          |
            |          |                              |          |
            |          |    |<-- PSN Tunnel -->|    |<------ LSP ------->|    |          |
            |          V    V                    V    V          |
            V    AC    +----+      +---+      +-----+       +----+     AC   V
      +-----+    |     | PE1|======:=X=:=======| PE1|=======\   /========| PE2|     |    +-----+
      |     |----------|...........:PW1:............|----------|     |----------|.......PW1.| \ / |............|----------|     |
      | CE1 |    |     |    |      |   :  X  |       |    |     |    | CE2 |
      |     |----------|...........:PW2:............|----------|     |----------|.......PW2.| / \ |............|----------|     |
      +-----+  ^ |     |    |======:=X=:=======|    |=======/   \========|    |     | ^  +-----+
            ^  |       +----+      +---+      +-----+       +----+       | |  ^
            |  |   Provider Edge 1    ^     Provider Edge 2   |  |
            |  |                      |                       |  |
     Customer  |                  P Router                    | Customer
      Edge 1   |                                              |  Edge 2
               |                                              |
               |                                              |
         Native service                                 Native service

            Figure 5: 6: MPLS-TP Architecture (Single Segment PW)

   Figure 6 7 shows the architecture for an MPLS-TP network when multi-
   segment pseudowires are used.  Note that as in the SS-PW case,
   P-routers may also exist.

            |<-------------------Pseudowire-------------------->|
           |

           |<----------- Pseudowire encapsulated ------------->|
           |             packet transport service              |
           |                 Pkt Xport Service                                                   |
           |                                                   |
           |                                       PSN                                                   |
        AC |     |<------- PSN tun1------>|    |<--tun2-->|     |<-------- LSP1 -------->|    |<--LSP2-->|    | AC
         | V     V                        V    V          V    V |
         | +----+              +-----+    +----+          +----+ |
   +---+ | |TPE1|===============\   /=====|SPE1|==========|TPE2| | +---+
   |   |---|......PW.Seg't1... | \ / | ......X...PW.Seg't3.....|---|   |
   |CE1| | |    |              |  X  |    |    |          |    | | |CE2|
   |   |---|......PW.Seg't2... | / \ | ......X...PW.Seg't4.....|---|   |
   +---+ | |    |===============/   \=====|    |==========|    | | +---+
       ^   +----+     ^        +-----+    +----+     ^    +----+   ^
       |              |          ^                   |             |
       |           TE LSP        |                TE LSP           |
       |                      P-router                             |
       |                                                           |
       |<-------------------- Emulated Service ------------------->|

             Figure 6: 7: MPLS-TP Architecture (Multi-Segment PW)

   The corresponding domain of the MPLS-TP protocol stack including PWs
   is shown in Figure 7. 8.

 +-------------------+
 |  Client Layer     |
 /===================\     /===================\
 H     PW Encap      H     H     PW OAM        H
 H-------------------H     H-------------------H   /===================\
 H   PW Demux (S=1)  H     H PW Demux (S=1)    H   H      LSP OAM      H
 H-------------------H     H-------------------H   H-------------------H
 H     LSP Demux(s)  H     H  LSP Demux(s)     H   H  LSP Demux(s)     H
 \===================/     \===================/   \===================/
 |    Server Layer   |     |   Server Layer    |   |   Server Layer    |
 +-------------------+     +-------------------+   +-------------------+

     User Traffic                 PW OAM                  LSP OAM

Note: Transport Service Layer = PW Demux
      Transport Path Layer = LSP Demux

             Figure 7: 8: MPLS-TP Layer Network using Pseudowires

   When providing a Virtual Private Wire Service (VPWS), Virtual Private
   Local Area Network Service (VPLS), Virtual Private Multicast Service
   (VPMS) or Internet Protocol Local Area Network Service (IPLS),
   pseudowires MUST must be used to carry the client service.  These

   [Editors' note add references for the terms in this para].

   PWs can and their underlying labels may be configured either statically or via the control plane defined in
   [RFC4447].

   Note that in MPLS-TP environments where IP is used signaled.  See
   Section 3.9 for control or OAM
   purposes, IP MAY be carried over the LSP demultiplexers as per
   RFC3031 [RFC3031], or directly over the server.

3.4.2. additional details related to configured service
   types.  See Section 3.8 for additional details related to signaled
   service types.

3.4.3.  Network Layer Clients Adaptation

   MPLS-TP LSPs can be used to transport network layer clients.  Any
   network layer protocol can be transported between service interfaces.
   Examples of network layer protocols include IP, MPLS and MPLS-TP.

   With
   Support for network layer clients follows the MPLS architecture for
   support of network layer protocols as defined in [RFC3031] and
   supported in [RFC3032].

   With network layer transport, adaptation, the MPLS-TP domain provides a
   bidirectional point-to-point connection between two PEs in order to
   deliver a packet transport service to attached customer edge (CE)
   nodes.  Note that  For example, a CE may be an an IP, MPLS or MPLS-TP node.  As
   shown in Figure 8, 9, there is an attachment circuit between the CE node
   on the left and its corresponding provider edge (PE) node that which
   provides the service interface, a bidirectional LSP across the
   MPLS-TP service network to the corresponding PE node on the right, and an
   attachment circuit between that PE node and the corresponding CE node
   for this service.

              |<------------- Client Network Layer-------------->|
              |                                                  |
              |          |<---- Pkt Xport Service --->|
              |          |                            |          |
              |          |    |<-- PSN Tunnel -->|    |          |
              |          V    V                  V    V          |
              V     AC   +----+      +---+       +----+    AC    V
        +-----+     |    |PE1 |      |   |       |PE2 | PE1|======:=X=:=======| PE2|    |     +-----+
        |     |----------|...........:LSP:............|----------|     |     |LSP | CE1    |      |   |       |    |   :    |     |     |
        | CE1 |----------|    |========X=========|    |----------| CE2 |
        |     |----------|...........: IP:............|----------|     |
        +-----+  ^  |IP  |    |  ^   |   |    |======:=X=:=======|   ^   |    |    |  ^  |     |
        +-----+  |  |    |    |  |   |   |   |   |    |    |  |  +-----+
              ^  |       +----+  |   +---+   |   +----+    |  |  ^
              |  |      Provider Edge 1 |     ^     |  Provider Edge 2      |  |
              |  |       Edge    |     |     |   Edge         |  |
        Customer |                 P Router        1      | P-router  |    2           | Customer
        Edge 1   |             TE           TE                | Edge 2
                 |             LSP          LSP               |
                 |                                            |
           Native service                               Native service

         Figure 8: 9: MPLS-TP Architecture for Network Layer Clients

   At the ingress service interface interface, the PE transforms pushes one or more labels
   onto the ingress packet
   to the format that will be carried packets which are label switched over the transport
   network, and similarly the corresponding service interface at the
   egress PE
   transforms pops any labels added by the packet to MPLS-TP networks and delivers
   the format needed by packets to the attached CE.  The attachment circuits may be
   heterogeneous (e.g., any combination of SDH, PPP, Frame Relay etc) Relay, etc.)
   and network layer protocol payloads arrive at the service interface
   encapsulated in the Layer1/Layer2 encoding defined for that access
   link type.  It should be noted that the set of network layer
   protocols includes MPLS and hence MPLS encoded packets with an MPLS
   label stack (the client MPLS stack), may appear at the service
   interface.

 +-------------------+
 |  Client Layer     |
 /===================\     /===================\
 H    Encap Label (S=1)    H     H     SvcLSP OAM    H
 H-------------------H     H-------------------H   /===================\
 H   SvcLSP Demux    H     H SvcLSP Demux (S=1)H   H      LSP OAM      H
 H-------------------H     H-------------------H   H-------------------H
 H     LSP Demux(s)  H     H  LSP Demux(s)     H   H  LSP Demux(s)     H
 \===================/     \===================/   \===================/
 |   Server Layer    |     |   Server Layer    |   |   Server Layer    |
 +-------------------+     +-------------------+   +-------------------+

     User Traffic            Service LSP OAM                  LSP OAM

Note: Transport Service Layer = SvcLSP Demux
      Transport Path Layer = LSP Demux

Note that the functions of the Encap label and the Service Label may be
represented by a single label or omitted. Additionally, the S-bit will
always be zero when the client layer is MPLS labelled.

     Figure 9: 10: Domain of MPLS-TP Layer Network for IP and LSP Clients

   Within the MPLS-TP transport network, the network layer protocols are
   carried over the MPLS-TP LSP network using a logically separate MPLS
   label stack (the server stack).  The server stack is entirely under
   the control of the nodes within the MPLS-TP transport network and it
   is not visible outside that network.  In accordance with [RFC3032], the bottom
   label, with the 'bottom of stack' bit set to '1', defines the network
   layer protocol being transported.  Figure 9 10 shows how an a client
   network protocol stack (which may be an MPLS label stack and payload)
   is carried over as a network layer transport client service over an MPLS-TP
   transport network.

   A label per network layer protocol payload type that is to be
   transported is REQUIRED. required.  Such labels are referred to as "Service
   "Encapsulation Labels", one of which is shown in Figure 9.  The mapping between
   protocol payload type and Service 10.
   Encapsulation Label is either configured or signaled.

   A Service labels are typically carried over an MPLS-TP edge-to-edge
   LSP, which is also shown in Figure 9.  The use of an edge-to-edge LSP
   is RECOMMENDED Label should be used when a particular packet transport
   service is supporting more than one network layer protocol payload
   type (and more than one Encapsulation Label is to used).  An example
   Service Label is shown in Figure 10.  A Service Label may be
   transported. omitted
   when only one encapsulation label is used in support of a particular
   service.  For example, if only MPLS is labelled packets are carried over
   a service, then a single
   Service Encapsulation Label would be used to provided provide
   both payload type indication and the MPLS-TP edge-to-edge LSP. service identification.
   Alternatively, if both IP and MPLS is to be carried carried, as shown in
   Figure 9, then two Service Encapsulation Labels could be mapped on to a
   common Service Label.

   Service labels are typically carried over an MPLS-TP edge-to-edge (or
   transport path layer) LSP, which is also shown in Figure 10.  The use
   of an edge-to-edge LSP is recommended when more than one service
   exists between two PEs.  An edge-to-edge LSP may be omitted when only
   one service label is used in between two PEs.  For example, if only
   one service is carried between two PEs then a single Service Label
   could be used to provided both service indication and the MPLS-TP
   edge-to-edge LSP.  Alternatively, if multiple services exist between
   a pair of PEs then a per-client Service Label would be mapped on to a
   common MPLS-TP edge-to-edge LSP.

   As noted above, any the layer 2 and layer 1 protocols used to carry the
   network layer protocol over the attachment circuit is terminated at
   the service interface and is circuits are not
   transported across the MPLS-TP network.  This enables the use of
   different layer 2 / and layer 1
   technologies at protocols on the two service interfaces. attachment
   circuits.

   At each service interface, Layer 2 addressing must be used to ensure
   the proper delivery of a network layer packet to the adjacent node.
   This is typically only an issue for LAN media technologies (e.g.,
   Ethernet) which have Media Access Control (MAC) addresses.  In cases
   where a MAC address is needed, the sending node MUST must set the
   destination MAC address to an address that ensures delivery to the
   adjacent node.  That is the CE sets the destination MAC address to an
   address that ensures delivery to the PE, and the PE sets the
   destination MAC address to an address that ensures delivery to the
   CE.  The specific address used is technology type specific and is not
   covered in this document.  In some technologies the MAC address will
   need to be configured (Examples for the Ethernet case include a
   configured unicast MAC address for the adjacent node, or even using
   the broadcast MAC address when the CE-PE service interface is
   dedicated.  The configured address is then used as the MAC
   destination address for all packets sent over the service interface.)

   Note that when the two CEs operating over the network layer transport
   service are running a routing protocol such as ISIS IS-IS or OSPF some
   care should be taken to configure the routing protocols to use point- to-
   point
   to-point adjacencies.  The specifics of such configuration is outside
   the scope of this document.

   [Editors Note we need to confer with ISIS and OSPF WG to verify that
   the cautionary note above is necessary and sufficient.]  See [RFC5309] for additional details.

   The CE to CE service types and corresponding labels may be configured
   or signaled.  When they are  See Section 3.9 for additional details related to
   configured service types.  See Section 3.8 for additional details
   related to signaled the CE service types.

3.5.  Identifiers

   Identifiers are used to PE control channel may
   be either out-of-band or in-band.  An out-of-band control channel
   uses standard GMPLS out-of-band signaling techniques.  There uniquely distinguish entities in an MPLS-TP
   network.  These include operators, nodes, LSPs, pseudowires, and
   their associated maintenance entities.
   [I-D.ietf-mpls-tp-identifiers] defines a set of identifiers that are
   compatible with existing MPLS control plane identifiers, as well as a
   number
   set of methods identifiers that can may be used to carry this signalling:

   o  It can be carried via an out-of-band when no IP control channel.  (As plane is
      commonly done in today's GMPLS controlled transport networks.)

   o  It could be carried over the attachment circuit with MPLS using a
      reserved label.

   o  It could be carried over
   available.

3.6.  Generic Associated Channel (G-ACh)

   For correct operation of the attachment circuit with MPLS using a
      normal label OAM it is important that the OAM packets
   fate-share with the data packets.  In addition in MPLS-TP it is agreed
   necessary to discriminate between CE user data payloads and PE.

   o  It could other types
   of payload.  For example, a packet may be carried over associated with a Signaling
   Communication Channel (SCC), or a channel used for Automatic
   Protection Switching (APS) data.  This is achieved by carrying such
   packets on a generic control channel associated to the attachment circuit in an ACH.

   o  It could be carried LSP, PW or
   section.

   MPLS-TP makes use of such 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 the attachment circuit LSPs or PWs.  The G-ACh is defined
   in IP.

   In the MPLS [RFC5586] and ACH cases above, this label value is similar to the Pseudowire Associated Channel
   [RFC4385], which is used to carry
   LSP signaling without any further encapsulation.  This signaling OAM packets over pseudowires.  The
   G-ACh is indicated by a generic associated channel header (ACH),
   similar to the Pseudowire VCCV control word; this header is always point-to-point present
   for all Sections, LSPs and MUST PWs making use local CE of FCAPS functions
   supported by the G-ACh.

   For pseudowires, the G-ACh uses the first four bits of the pseudowire
   control word to provide the initial discrimination between data
   packets and PE
   addressing.

   The method(s) packets belonging to be used will be the associated channel, as described
   in a future version [RFC4385].  When this first nibble of a packet, immediately
   following the
   document.

3.5.  Identifiers

   Identifiers label at the bottom of stack, has a value of '1', then
   this packet belongs to be used in within MPLS-TP where compatibility with
   existing MPLS control plane conventions are necessary are described
   in [draft-swallow-mpls-tp-identifiers-00]. a G-ACh.  The MPLS-TP requirements
   [RFC5654] require that first 32 bits following the elements and objects in
   bottom of stack label then have a defined format called an MPLS-TP
   environment are able to be configured associated
   channel header (ACH), which further defines the content of the
   packet.  The ACH is therefore both a demultiplexer for G-ACh traffic
   on the PW, and managed without a discriminator for the type of G-ACh traffic.

   When the OAM or other control
   plane.  In such message is carried over an environment many conventions for defining
   identifiers are possible.  However LSP, rather
   than over a pseudowire, it is also anticipated necessary to provide an indication in
   the packet that
   operational environments where MPLS-TP objects, LSPs and PWs will be
   signaled via existing protocols such the payload is something other than a user data
   packet.  This is achieved 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 Distribution
   Protocol [RFC4447] (GAL)', and the Resource Reservation Protocol as is defined in [RFC5586].  When a GAL
   is found, it indicates that the payload begins with an ACH.  The GAL
   is
   applied to Generalized Multi-protocol Label Switching ( [RFC3471] thus a demultiplexer for G-ACh traffic on the LSP, and
   [RFC3473]) (GMPLS). [draft-swallow-mpls-tp-identifiers-00] defines the ACH is
   a
   set of identifiers discriminator for the type of traffic carried on the G-ACh.  Note
   however that MPLS-TP which are both compatible with those
   protocols and applicable to MPLS-TP management and OAM functions.

   MPLS-TP distinguishes between addressing used to identify nodes in forwarding follows the network, and identifiers used for demultiplexing normal MPLS model, and forwarding.

   Whilst IP addressing
   that a GAL is used by default, MPLS-TP must be able invisible to
   operate in environments where IP an LSR unless it is not used the top label in the forwarding plane.
   Therefore,
   label stack.  The only other circumstance under which the default mechanism label stack
   may be inspected for OAM demultiplexing in MPLS-TP
   LSPs and PWs a GAL is when the generic associated channel.  Forwarding based on
   IP addresses for user or OAM packets is not REQUIRED for MPLS-TP.

   [RFC4379]and BFD for MPLS LSPs [I-D.ietf-bfd-mpls] have defined alert
   mechanisms TTL has expired.  Any MPLS-TP
   component that enable an MPLS LSR intentionally performs this inspection must assume
   that it is asynchronous with respect to identify and process MPLS OAM
   packets when the OAM packets are encapsulated in an IP header.  These
   alert mechanisms are based forwarding of other
   packets.  All operations on TTL expiration and/or use an IP
   destination address in the range 127/8.  These mechanisms label stack are the
   default mechanisms for MPLS networks in general for identifying MPLS
   OAM packets when accordance with
   [RFC3031] and [RFC3032].

   In MPLS-TP, the OAM packets 'G-ACh Alert Label (GAL)' always appears at the
   bottom of the label stack (i.e.  S bit set to 1).

   The G-ACh must only be used for channels that are encapsulated in an IP header.
   MPLS-TP is unable adjunct to rely on the availability
   data service.  Examples of IP these are OAM, APS, MCC and thus uses SCC, but the
   GACH/GAL
   use is not restricted 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 these services.  The G-ACh must not be used
   to differentiate specific packets (e.g.
   OAM, APS, MCC or SCC) from those carrying user carry additional data packets on the
   same LSP.  These mechanisms are described for use in [RFC5586].

   MPLS-TP requires [I-D.ietf-mpls-tp-oam-requirements] that the forwarding path, i.e. it must
   not be used as an alternative to a set of
   OAM capabilities is available PW control word, or to perform fault management (e.g. fault
   detection and localization) and performance monitoring (e.g. packet
   delay define a PW
   type.

   At the server layer, bandwidth and loss measurement) of QoS commitments apply to the gross
   traffic on the LSP, PW or section.  The framework
   for OAM in MPLS-TP  Since the G-ACh traffic is specified in [I-D.ietf-mpls-tp-oam-framework].

   MPLS-TP OAM packets share
   indistinguishable from the same fate as their corresponding user data
   packets, and are identified through traffic, protocols using the Generic Associated Channel
   mechanism [RFC5586].  This
   G-ACh must take into consideration the impact they have on the user
   data that they are sharing resources with.  Conversely, capacity must
   be made available for important G-ACh uses a combination of an Associated
   Channel Header (ACH) such as protection and a Generic Alert Label (GAL)
   OAM.  In addition, protocols using the G-ACh must conform to create a the
   security and congestion considerations described in [RFC5586].

   Figure 11 shows the reference model depicting how the control channel
   is associated to an LSP, Section or PW.

3.6.1.  OAM Architecture

   OAM and monitoring in MPLS-TP with the pseudowire protocol stack.  This is based on
   the concept reference model for VCCV shown in Figure 2 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 10 ).  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 [RFC5085].

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

      ==== 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 10: Example of MPLS-TP OAM
                |         /                               \    |
                +--------|      MPLS/MPLS-TP Network       |---+
                          \                               /
                           \   ___      ___     __      _/
                            \_/   \____/   \___/  \____/

    Figure 11 illustrates how 11: PWE3 Protocol Stack Reference Model including the concept of Maintenance Entities can be
   mapped to sections, LSPs G-ACh

   PW associated channel messages are encapsulated using the PWE3
   encapsulation, so that they are handled and PWs processed in the same
   manner (or in some cases, an MPLS-TP network that uses MS-
   PWs.

   Native  |<-------------------- PW15 --------------------->| Native
    Layer analogous manner) as the PW PDUs for
   which they provide a control channel.

   Figure 12 shows the reference model depicting how the control channel
   is associated with the LSP protocol stack.

          +-------------+                                +-------------+
          |  Payload    |  Layer          < Service >           |    |<-PSN13->|    |<-PSN3X->|    |<-PSNXZ->|   Payload   | Service
     (AC1) V    V   LSP   V    V
          +-------------+                                +-------------+
          |Discriminator|         < ACH on LSP   V    V >         |Discriminator|
          +-------------+                                +-------------+
          |Demultiplexer|         < GAL on LSP   V    V  (AC2)
           +----+   +-+   +----+         +----+   +-+   +----+
+---+      |TPE1|   | |   |SPE3|         |SPEX|   | |   |TPEZ|     +---+
|   | >         |Demultiplexer|
          +-------------+                                +-------------+
          |    |=========|    |=========|    |=========|    PSN      |            < LSP >             |    PSN      |
|CE1|------|........PW1.....X..|...PW3...|.X......PW5........|-----|CE2|
          +-------------+                                +-------------+
          |  Physical   |                                |    |=========|    |=========|    |=========|  Physical   |
          +-----+-------+                                +-----+-------+
                |                                              |
+---+
                | 1             ____     ___       ____          |   |2|
                | 3           _/    \___/   \    _/    \__       |
                | X          /               \__/         \_     |   |Y|
                | Z         /                               \    |     +---+
           +----+   +-+   +----+         +----+   +-+   +----+

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

           .------------------- PW15  PME -------------------.
           .---- PW1 PTCME ----.         .---- PW5 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
                +--------|      MPLS/MPLS-TP Network       |---+
                          \                               /
                           \   ___      ___     __      _/
                            \_/   \____/   \___/  \____/

     Figure 11: MPLS-TP OAM archtecture

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

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

   o  A LSP Maintenance Entity (LME), allowing monitoring and management
      of an end-to-end Protocol Stack Reference Model including the LSP (between LERs).

   o  A PW Maintenance Entity (PME), allowing monitoring
                        Associated Control Channel

3.7.  Operations, Administration and management
      of an end-to-end SS/MS-PWs (between T-PEs).

   o  An LSP Tandem Connection Maintenance Entity (LTCME), allowing
      estimation of OAM fault and performance metrics of a single LSP
      segment or of an aggregate of LSP segments.  It also enables any
      OAM function applied to segment(s) of an LSP to (OAM)

   MPLS-TP must be independent of able to operate in environments where IP is not used
   in the OAM function(s) operated on forwarding plane.  Therefore, the end-to-end LSP.  This can be
      achieved by including a label representing default mechanism for OAM
   demultiplexing in MPLS-TP LSPs and PWs is the LTCME Generic Associated
   Channel (Section 3.6).  Forwarding based on one IP addresses for user or
      more LSP label stacks
   OAM packets is not required for 1:1 or N:1 monitoring of LSPs,
      respectively.  Note MPLS-TP.

   [RFC4379] and BFD for MPLS LSPs [I-D.ietf-bfd-mpls] have defined
   alert mechanisms that the term Tandem Connection Monitoring has
      historical significance dating back to the early days of the
      telephone network, but is equally applicable enable an MPLS LSR to identify and process MPLS
   OAM packets when the hierarchal
      architectures commonly employed OAM packets are encapsulated in todays packet networks.

   Individual MIPs along the path of an LSP or PW IP header.
   These alert mechanisms are addressed by
   setting the appropriate based on TTL expiration and/or use an IP
   destination address in the label range 127/8 for the OAM packet, as per
   [I-D.ietf-pwe3-segmented-pw].  Note IPv4 and that this works when the location
   of MIPs along same range
   embedded as IPv4 mapped IPv6 addresses for IPv6 [RFC4379].  When the LSP or PW path is known by
   OAM packets are encapsulated in an IP header, these mechanisms are
   the MEP.  There may default mechanisms for MPLS networks in general for identifying
   MPLS OAM packets.  MPLS-TP must be
   cases able to operate in an environments
   where this IP forwarding is not supported, and thus the case GACH/GAL is the
   default mechanism to demultiplex OAM packets in general MPLS networks e.g.
   following restoration using MPLS-TP.

   MPLS-TP supports a facility bypass LSP.  In these cases,
   tools to trace the path comprehensive set of the LSP may be used to determine the
   appropriate setting OAM capabilities for the TTL packet
   transport applications, with equivalent capabilities to reach a those
   provided in SONET/SDH.

   MPLS-TP defines mechanisms to differentiate specific MIP.

   Within an LSR packets (e.g.
   OAM, APS, MCC or PE, MEPs and MIPs can only be placed where MPLS
   layer processing is performed SCC) from those carrying user data packets on a packet.  The architecture mandates
   that this must occur at least once.

   There is only one MIP on an the
   same transport path (i.e. section, LSP or PW PW).  These mechanisms are
   described in each node.  That MIP is for
   all applicable [RFC5586].

   MPLS-TP requires [I-D.ietf-mpls-tp-oam-requirements] that a set of
   OAM functions on its associated LSP or PW.  This
   document does not specify the default position capabilities is available to perform fault management (e.g. fault
   detection and localisation) and performance monitoring (e.g. packet
   delay and loss measurement) of the MIP within the
   node.  Therefore, this document does not specify where the exception
   mechanism resides (i.e. at the ingress interface, the egress
   interface, LSP, PW or some other location within section.  The framework
   for OAM in MPLS-TP is specified in [I-D.ietf-mpls-tp-oam-framework].

   MPLS-TP OAM packets share the node).  An optional
   protocol may be developed that sets same fate as their corresponding data
   packets, and are identified through the position of Generic Associated Channel
   mechanism [RFC5586].  This uses a MIP along the
   path combination of an LSP or PW within the node (and thus determines the
   exception processing location).

   MEPs may only act as Associated
   Channel Header (ACH) and a sink of OAM packets when the label Generic Alert Label (GAL) to create a
   control channel associated
   with the LSP to an LSP, Section or PW for that ME PW.

3.7.1.  OAM Architecture

   OAM and monitoring in MPLS-TP is popped.  MIPs can only be placed
   where an exception to based on the normal forwarding operation occurs. concept of maintenance
   entities, as described in [I-D.ietf-mpls-tp-oam-framework].  A MEP
   may act
   Maintenance Entity can be viewed as a source the association of two
   Maintenance End Points (MEPs) (see example in Figure 13 ).  Another
   OAM packets whereever a label construct is referred to as Maintenance Entity Group (MEG), which
   is pushed or
   swapped.  For example, on a MS-PW, a MEP may source OAM within an
   S-PE or a T-PE, but a MIP may only be associated with a S-PE and a
   sink MEP can only be associated with a T-PE.

3.6.2.  OAM Functions

   The MPLS-TP OAM architecture support a wide range collection of OAM functions,
   including one or more MEs that belongs to the following
   o  Continuity Check

   o  Connectivity Verification

   o  Performance monitoring (e.g. loss same transport
   path and delay)

   o  Alarm suppression

   o  Remote Integrity

   These that are applicable to any layer defined within MPLS-TP, i.e.  MPLS
   Section, LSP maintained and PW. monitored as a group.  The MPLS-TP OAM toolset needs to MEPs that
   form an ME should be able configured and managed to operate without relying
   on a dynamic control plane or IP functionality in the datapath.  In limit 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 preclude the use
   responsibilities 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 flow within the service.

3.7.  Generic Associated Channel (G-ACh)

   For correct operation domain of a transport path
   or segment, in the OAM it is important specific layer network that the is being monitored and
   managed.

   Each OAM packets
   fate share flow is associated with a single ME.  Each MEP within an ME
   resides at the data packets.  In addition in MPSL-TP it is
   necessary to discriminate between user data payloads and other types boundaries of payload.  For example the packet that ME.  An ME may contain a Signaling
   Communication Channel (SCC), or a channel used for Automatic
   Protection Switching (APS) data.  Such packets are carried on also include a
   control channel associated to the LSP, Section set
   of zero or PW.  This is
   achieved by carrying such packets on a generic control channel
   associated to more Maintenance Intermediate Points (MIPs), which reside
   within the LSP, PW or section.

   MPLS-TP makes use Maintenance Entity.  Maintenance End Points (MEPs) are
   capable of such a generic associated channel (G-ACh) to
   support Fault, Configuration, Accounting, Performance sourcing and Security
   (FCAPS) functions by carrying packets related to OAM, APS, SCC, MCC
   or other packet types in band over LSPs sinking OAM flows, while Maintenance
   Intermediate Points (MIPs) can only sink or PWs.  The G-ACH is defined
   in [RFC5586] and it is similar to the Pseudowire Associated Channel
   [RFC4385], which is used respond to carry OAM packets across pseudowires.
   The G-ACH is indicated by a generic associated channel header (ACH),
   similar to the Pseudowire VCCV control word, and this is 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 flows from
   within a packets belonging to the associated channel, MEG, or originate notifications as described
   in[RFC4385].  When the first nibble of a packet, immediately
   following the label at the bottom of stack, has a value result of one, then
   this packet belongs specific
   network conditions.

========================== End to a G-ACh.  The first 32 bits following the
   bottom 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 stack label then have a defined format called an associated
   channel header (ACH), which further defines the content scope
      of the
   packet.  The ACH is therefore both a demultiplexer for G-ACh traffic
   on the PW, this figure.

   Figure 13: Example of MPLS-TP OAM showing end-to-end and a discriminator for segment OAM

   Figure 14 illustrates how the type concept of G-ACh traffic.

   When the OAM, or a similar message is carried over an LSP, rather
   than over a pseudowire, it is necessary Maintenance Entities can be
   mapped to provide an indication sections, LSPs and PWs in
   the packet that the payload is something other than a user data
   packet.  This is achieved 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)', and 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 is a discriminator for the type
   of traffic carried on the G-ACh.  Note however 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.....X..|...PW3...|.X......PW5........|-----|CE2|
|   |      |    |=========|    |=========|    |=========|    |     |   |
+---+      | 1  |   |2|   | 3  |         | X  |   |Y|   | Z  |     +---+
           +----+   +-+   +----+         +----+   +-+   +----+

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

           .------------------- PW15  PME -------------------.
           .---- PW1 PTCME ----.         .---- PW5 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 14: MPLS-TP
   forwarding follows the normal MPLS model, and that a GAL is invisible
   to an LSR unless it is the top label in the label stack.  The only
   other circumstance under which the label stack may be inspected for a
   GAL is when the TTL has expired.  Any OAM architecture showing PWs, LSPs and Sections

   The following MPLS-TP component that
   intentionally performs this inspection must assume that it is
   asynchronous with respect to the forwarding of other packets.  All
   operations on the label stack MEs are specified in accordance with [RFC3031]
   [I-D.ietf-mpls-tp-oam-framework]:

   o  A Section Maintenance Entity (SME), allowing monitoring and
   [RFC3032].

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

   The G-ACH MUST only be used for channels that are an adjunct to the
   data service.  Examples MPLS-TP Sections (between MPLS LSRs).

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

   o  A PW Maintenance Entity (PME), allowing monitoring and SCC, but the
   use is not restricted to those names services.  The management
      of an end-to-end SS/MS-PWs (between T-PEs).

   o  An LSP Tandem Connection Maintenance Entity (LTCME).

   A G-ACH MUST NOT packet may be
   used directed to carry additional data for use in the forwarding path, i.e. it
   MUST NOT be used as an alternative to a PW control word, or to define
   a PW type.

   Since the G-ACh traffic is indistinguishable from the user data
   traffic at the server layer, bandwidth and QoS commitments apply to
   the gross traffic on individual MIP along the LSP, PW path of
   an LSP or section.  Protocols using the
   G-ACh must therefore take into consideration MS-PW by setting the impact they have on appropriate TTL in the user data that they are sharing resources with.  In addition,
   protocols using label for the G-ACh MUST conform to
   G-ACH packet, as per the security traceroute mode of LSP Ping [RFC4379] and congestion
   considerations described in [RFC5586]. .

   Figure 12 shows
   the reference model depicting how vccv-trace mode of[I-D.ietf-pwe3-segmented-pw].  Note that this
   works when the control channel location of MIPs along the LSP or PW path is associated with known by
   the pseudowire protocol stack.  This MEP.  There may be circumstances where this is based on not the reference model for VCCV shown in Figure 2 case, e.g.
   following restoration using a facility bypass LSP.  In these cases,
   tools to trace the path 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 12: PWE3 Protocol Stack Reference Model including the G-ACh

   PW associated channel messages are encapsulated using LSP may be used to determine the PWE3
   encapsulation, so that they are handled and processed in
   appropriate setting for the same
   manner (or in some cases, TTL to reach a specific MIP.

   Within an analogous manner) LSR or PE, MEPs and MIPs can only be placed where MPLS
   layer processing is performed on a packet.  The architecture mandates
   that this must occur at least once.

   MEPs may only act as the PW PDUs for
   which they provide a control channel.

   Figure 13 shows the reference model depicting how sink of OAM packets when the control channel
   is label associated
   with the LSP protocol stack.

          +-------------+                                +-------------+
          |  Payload    |          < Service >           |   Payload   |
          +-------------+                                +-------------+
          |Discriminator|         < ACH on LSP >         |Discriminator|
          +-------------+                                +-------------+
          |Demultiplexer|         < GAL or PW for that ME is popped.  MIPs can only be placed
   where an exception to the normal forwarding operation occurs.  A MEP
   may act as a source of OAM packets wherever a label is pushed or
   swapped.  For example, on LSP >         |Demultiplexer|
          +-------------+                                +-------------+
          |    PSN      |            < LSP >             |    PSN      |
          +-------------+                                +-------------+
          |  Physical   |                                |  Physical   |
          +-----+-------+                                +-----+-------+
                |                                              |
                |             ____     ___       ____          |
                |           _/    \___/   \    _/    \__       |
                |          /               \__/         \_     |
                |         /                               \    |
                +--------|      MPLS/MPLS-TP Network       |---+
                          \                               /
                           \   ___      ___     __      _/
                            \_/   \____/   \___/  \____/

     Figure 13: MPLS Protocol Stack Reference Model an MS-PW, a MEP may source OAM within an
   S-PE or a T-PE, but a MIP may only be associated with a S-PE and a
   sink MEP can only be associated with a T-PE.

3.7.2.  OAM Functions

   The MPLS-TP OAM architecture supports a wide range of OAM functions,
   including the LSP
                        Associated Control Channel

3.8.  Control Plane following:

   o  Continuity Check

   o  Connectivity Verification

   o  Performance Monitoring (e.g. packet loss and delay measurement)

   o  Alarm Suppression

   o  Remote Integrity

   These functions are applicable to any layer defined within MPLS-TP,
   i.e. to MPLS-TP should be capable of being operated with centralized Network
   Management Systems (NMS). Sections, LSPs and PWs.

   The NMS may MPLS-TP OAM tool-set must be supported by able to operate without relying on a distributed
   dynamic control plane, but MPLS-TP can operated plane or IP functionality in the absence datapath.  In the
   case of such an MPLS-TP deployment in a network in which IP functionality
   is available, all existing IP/MPLS OAM functions, e.g.  LSP-Ping, BFD
   and VCCV, may be used.

   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.8.  Control Plane

   Editors note: This section will be updated based on text supplied by
   the control plane. plane framework draft editors.

   A distributed dynamic control plane may be used to enable dynamic
   service provisioning in multi-vendor and multi-domain
   environments using standardized protocols that guarantee
   interoperability. an MPLS-TP network.  Where the requirements
   specified in [RFC5654] can be met, the MPLS transport profile Transport Profile uses
   existing standard control plane protocols for LSPs and PWs.

   Note that a dynamic control plane is not required in an MPLS-TP
   network.  See Section 3.9 for further details on statically
   configured and provisioned MPLS-TP services.

   Figure 14 15 illustrates the relationship between the MPLS-TP control
   plane, the forwarding plane, the management plane, and 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|<->|Forward-|<---->|Forward-|<----->|Forward-|<->|Edge|-+--
    /: +----+   |ing     | :  : |ing     |  :  : |ing     |   +----+ :\
     :          +--------+ :  : +--------+  :  : +--------+          :
     '''''''''''''''''''''''  '''''''''''''''  '''''''''''''''''''''''

   Note:
      1) NMS may be centralised or distributed. Control plane is
         distributed
         distributed.
      2) 'Edge' functions refers to those functions present at
         the edge of a PSN domain, e.g. NSP or classification.
      3) The control plane may be transported over the server
         layer, and an LSP or a G-ACh.

           Figure 14: 15: MPLS-TP Control Plane Architecture Context

   The MPLS-TP control plane is based on a combination of the LDP-based
   control plane for pseudowires [RFC4447] and the RSVP-TE based RSVP-TE-based control
   plane for MPLS-TP LSPs [RFC3471].  Some of the RSVP-TE functions that
   are required for MPLS-TP LSP signaling for MPLS-TP are based on GMPLS. Generalized MPLS
   (GMPLS) ([RFC3945], [RFC3471], [RFC3473]).

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

   o  Signaling

   o  Routing

   o  Traffic engineering and constraint-based path computation

   In a multi-domain environment, the MPLS-TP control plane supports
   different types of interfaces at domain boundaries or within the
   domains.  These include the User-Network Interface (UNI), Internal
   Network Node Interface (I-NNI), and External Network Node Interface
   (E-NNI).  Note that different policies may be defined that control
   the information exchanged across these 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.6 3.7, e.g. for fault detection and localization localisation 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
   paths, including protected paths as described in the survivability
   section Section 3.10 of this document. 3.10.
   Examples of the MPLS-TP data plane connectivity patterns are LSPs utilizing
   utilising the fast reroute backup methods as defined in [RFC4090] and
   ingress-to-egress 1+1 or 1:1 protected LSPs.

   The MPLS-TP control plane provides functions to ensure its own
   survivability and to enable it to recover gracefully from failures
   and degradations.  These include graceful restart and hot redundant
   configurations.  Depending on how the control plane is transported,
   varying degrees of decoupling between the control plane and data
   plane may be achieved.

3.8.1.  PW Control Plane

   An MPLS-TP network provides many of its transport services using
   single-segment or multi-segment pseudowires, in compliance with the
   PWE3 architecture ([RFC3985] and [I-D.ietf-pwe3-ms-pw-arch] ). [RFC5659]).  The setup and
   maintenance of single-segment or multi- segment multi-segment pseudowires uses the
   Label Distribution Protocol (LDP) as per [RFC4447] and extensions for
   MS-PWs [I-D.ietf-pwe3-segmented-pw] ([I-D.ietf-pwe3-segmented-pw] and
   [I-D.ietf-pwe3-dynamic-ms-pw].
   [I-D.ietf-pwe3-dynamic-ms-pw]).

3.8.2.  LSP Control Plane

   MPLS-TP provider edge nodes Provider Edge LSRs aggregate multiple pseudowires and carry
   them across the MPLS-TP network through MPLS-TP tunnels (MPLS-TP
   LSPs).  Applicable functions from the Generalized MPLS (GMPLS)
   ([RFC3945]) protocol suite supporting packet-switched capable (PSC)
   technologies are used as the control plane for MPLS-TP transport
   paths (LSPs).

   The LSP control plane includes:

   o  RSVP-TE for signalling signaling

   o  OSPF-TE or ISIS-TE for routing
   RSVP-TE signaling in support of GMPLS, as defined in [RFC3473], is
   used for the setup, modification, and release of MPLS-TP transport
   paths and protection paths.  It supports unidirectional, bi-
   directional unidirectional and multicast types of
   bidirectional point-to-point LSPs as well as unidirectional point-to-
   multipoint LSPs.  The architecture for MPLS-TP supporting point-to-
   multipoint packet transport services is out of scope of this
   document.

   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 utilised
   for the setup of the transport path exactly following the given
   route.  GMPLS based  GMPLS-based MPLS-TP LSPs must be able to inter-operate with RSVP-TE based MPLS-TE
   LSPs, as per [RFC5146]

   OSPF-TE routing in support of GMPLS as defined in [RFC4203] is used
   for carrying link state information in a MPLS-TP network.  ISIS-TE
   routing in support of GMPLS inter-operate with
   RSVP-TE-based MPLS-TE LSPs, as defined in [RFC5307] is per [RFC5146]

   OSPF and IS-IS for GMPLS ([RFC4203] and [RFC5307]) are used for
   carrying link state routing information in a an MPLS-TP network.

3.9.  Static Operation of LSPs and PWs

   A PW or

   An MPLS-TP LSP or PW may be statically configured without the support
   of a dynamic control plane.  This may be either by direct
   configuration of the PEs/LSRs, LSRs, or via a network management system.  The collateral
   damage that
   Static operation is independent of a specific PW or LSP instance -
   for example it should be possible for a PW to be statically
   configured, while the LSP supporting it setup by a dynamic control
   plane.

   Persistent forwarding loops can cause during the time taken to detect significant additional resource
   utilisation, above that budgeted for the
   failure may be severe.  When transport path.  Therefore,
   when static configuration mechanisms are used, care must be taken to
   ensure that loops to do not form.

3.10.  Survivability

   Editors note: This section will be updated based on text supplied by
   the survivability draft editors.

   Survivability requirements for MPLS-TP are specified in
   [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 ([RFC4090]), while pseudowire
   redundancy [I-D.ietf-pwe3-redundancy] supports scenarios where the
   protection for the PW can not cannot 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 protection and restoration mechanisms [RFC4872].
   MPLS-TP provides additional protection mechanisms that are optimised
   for both linear topologies and ring topologies, and that operate in
   the absence of a dynamic control plane.  These are specified in
   [I-D.ietf-mpls-tp-survive-fwk].

   Different protection schemes apply to different deployment topologies
   and operational considerations.  Such protection schemes may provide
   different levels of resiliency.  For example, two resiliency, for example:

   o  Two concurrent traffic paths (1+1), (1+1).

   o  one active and one standby path with guaranteed bandwidth on both
      paths (1:1) or (1:1).

   o  one active path and a standby path
   that is the resources or which are
      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 are listed
   below. as follows:

   o  Optimised for linear, ring or meshed topologies.

   o  Use OAM mechanisms to detect and localize localise network faults or
      service degenerations.

   o  Include protection mechanisms to coordinate and trigger protection
      switching actions in the absence of a dynamic control plane.  This
      is known as an Automatic Protection Switching (APS) mechanism.

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

   o  MPLS-TP recovery mechanisms support the coordination of protection
      switching at multiple levels to prevent race conditions occurring
      between a client and its server layer.

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

   o  MPLS-TP supports revertive and non-revertive behavior. behaviour.

3.11.  Network Management

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

   The Equipment Management Function (EMF) of a an MPLS-TP 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 realised by the G-ACh, provides a
   logical operations channel between NEs for transferring Management
   information.  For the management interface from a management system
   to a an MPLS-TP NE, there is no restriction on which management
   protocol
   should be is used.  It  The MCC is used to provision and manage an end-to-end end-to-
   end connection across a network where some segments are create/managed, created/
   managed by, for examples by example, Netconf or SNMP and other segments by XML or
   CORBA interfaces.  Maintenance operations are run on a connection
   (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, the EMF must be capable
   of statically provisioning LSPs for an LSR or LER, and PWs for a PE,
   as well as any associated MEPs and MIPs, as per Section 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 conditions in the MPLS-TP network and
   its environment.  FM must provide for the supervision of transmission
   (such as continuity, connectivity, etc.), software processing,
   hardware, and environment.  Alarm handling includes alarm severity
   assignment, alarm suppression/aggregation/correlation, alarm
   reporting control, and alarm reporting.

   Configuration Management (CM) provides functions to 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 OAM parameters as a part of connectivity management
   to meet specific operational requirements.  These may specify whether
   the operational mode is one-time on-demand or is periodic at a
   specified frequency.

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

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 MPLS Transport
   Profile are used to support packet transport services, the security
   considerations of that additional functionality also apply.

   For pseudowires, the security considerations of [RFC3985] and
   [I-D.ietf-pwe3-ms-pw-arch]
   [RFC5659] apply.

   Packets that arrive on an interface with a given label value should
   not be forwarded unless that label value was previously is assigned to an LSP or PW
   to a peer LSR or PE that it is reachable via that interface.

   Each MPLS-TP solution must specify the additional 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  Rahul Aggarwal
   o  Dieter Beller

   o  Lou Berger

   o  Malcolm Betts

   o  Italo Busi

   o  John E Drake

   o  Hing-Kam Lam

   o  Marc Lasserre

   o  Vincenzo Sestito

   o  Martin Vigoureux

   o  The participants of ITU-T SG15

7.  Open Issues

   This section contains a list of issues that must be resolved before
   last call.

   o  Add addition detail on survivability architectures.

   o  Consider whether there is too much detail in the OAM, network
      management, identifiers and control plane sections.  Should this
      framework document reduce the discussion on these topics in order
      to minimise the dependency on other components not yet ready for
      publication.

   o  There is some text missing from the network layer clients section.
      Text is invited covering the use of out of band signaling on
      associated with the AC.

   o  Need text to address how the LSR next hop MAC address is
      determined for Ethernet link layers when no IP (i.e.  ARP) is
      available.  If statically configured, what is the default?

   o  Are there any other invariants of a typical LSR/PE architecture
      that need to 181209:
      this will be clarified addressed in the context of MPLS-TP. normative data plane draft

   o  Need to add section (Appendix) describing stack optizations for
      LSP and PWs

   o  Add a section clarify what options are used for interdomain
      operation e.g. inter-AS TE LSPs, MS-PW, LSP stitching, back-to-
      back ACs

   o  Text reduction for the OAM, survivability and NM sections.

   o  Include summarised PST text

8.  References
8.1.  Normative References

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

   [G.805]                              "ITU-T Recommendation G.805
                                        (11/95), "Generic Functional
                                        Architecture of Transport
                                        Networks"", November 1995.

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

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

   [RFC3032]                            Rosen, E., Tappan, D., Fedorkow,
                                        G., Rekhter, Y., Farinacci, D.,
                                        Li, T., and A. Conta, "MPLS
                                        Label Stack Encoding", RFC 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.

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

   [RFC3473]                            Berger, L., "Generalized Multi-
                                        Protocol Label Switching (GMPLS)
                                        Signaling Resource ReserVation
                                        Protocol-Traffic Engineering
                                        (RSVP-TE) Extensions", RFC 3473,
                                        January 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 A.
                                        Atlas, "Fast Reroute Extensions
                                        to RSVP-TE for LSP Tunnels",
                                        RFC 4090, May 2005.

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

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

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

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

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

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

   [RFC5332]                            Eckert, T., Rosen, E., Aggarwal,
                                        R., and Y. Rekhter, "MPLS
                                        Multicast Encapsulations",
                                        RFC 5332, August 2008.

   [RFC5462]                            Andersson, L. and R. Asati,
                                        "Multiprotocol Label Switching
                                        (MPLS) Label Stack Entry: "EXP"
                                        Field Renamed to "Traffic Class"
                                        Field", RFC 5462, February 2009.

   [RFC5586]                            Bocci, M., Vigoureux, M., and S.
                                        Bryant, "MPLS Generic Associated
                                        Channel", RFC 5586, June 2009.

8.2.  Informative References

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

   [I-D.ietf-l2vpn-arp-mediation]       Rosen, E., Shah, H., Heron, G.,

   [I-D.ietf-mpls-tp-identifiers]       Bocci, M. and V. Kompella, "ARP Mediation
                                        for IP Interworking of Layer 2
                                        VPN", draft-ietf-l2vpn-arp-
                                        mediation-12 G. Swallow,
                                        "MPLS-TP Identifiers", draft-
                                        ietf-mpls-tp-identifiers-00
                                        (work in progress),
                                        June
                                        November 2009.

   [I-D.ietf-mpls-tp-nm-req]

   [I-D.ietf-mpls-tp-nm-framework]      Mansfield, S., Gray, E., and H.
                                        Lam, "MPLS-TP Network Management
                                        Framework", draft-ietf-mpls-tp-
                                        nm-framework-02 (work in
                                        progress), November 2009.

   [I-D.ietf-mpls-tp-nm-req]            Mansfield, S., S. and K. Lam, "MPLS
                                        TP Network Management
                                        Requirements",
                                        draft-ietf-mpls-tp-nm-req-05
                                        draft-ietf-mpls-tp-nm-req-06
                                        (work in progress),
                                        September
                                        October 2009.

   [I-D.ietf-mpls-tp-oam-framework]     Allan, D., Busi, I. I., and B.
                                        Niven-Jenkins, "MPLS-TP OAM Framework and
                                        Overview",
                                        Framework", draft-ietf-mpls-tp-
                                        oam-framework-01
                                        oam-framework-04 (work in
                                        progress), July December 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-03
                                        (work in progress), August 2009.

   [I-D.ietf-mpls-tp-rosetta-stone]     Helvoort, H., Andersson, L., and
                                        N. Sprecher, "A Thesaurus for
                                        the Terminology used in
                                        Multiprotocol Label Switching
                                        Transport Profile (MPLS-TP)
                                        drafts/RFCs and ITU-T's
                                        Transport Network
                                        Recommendations.", draft-ietf-
                                        mpls-tp-rosetta-stone-00
                                        ietf-mpls-tp-oam-requirements-04
                                        (work in progress), June
                                        December 2009.

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

   [I-D.ietf-pwe3-dynamic-ms-pw]        Martini, L., Bocci, M., Balus,
                                        F., Bitar, N., Shah, H.,
                                        Aissaoui, M., Rusmisel, J.,
                                        Serbest, Y., Malis, A., Metz,
                                        C., McDysan, D., Sugimoto, J.,
                                        Duckett, M., Loomis, M., Doolan,
                                        P., Pan, P., Pate, P., Radoaca,
                                        V., Wada, Y., and
                                        F. Balus, Y. Seo,
                                        "Dynamic Placement of Multi
                                        Segment Pseudo Wires",
                                        draft-ietf-pwe3-dynamic-ms-pw-09
                                        (work in progress), March 2009.

   [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-07
                                        draft-ietf-pwe3-dynamic-ms-pw-10
                                        (work in progress), July
                                        October 2009.

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

   [I-D.ietf-pwe3-segmented-pw]         Martini, L., Nadeau, T., Metz,
                                        C., Duckett, M., Bocci, M.,
                                        Balus, F., and M. Aissaoui,
                                        "Segmented Pseudowire",
                                        draft-ietf-pwe3-segmented-pw-13
                                        (work in progress), August 2009.

   [RFC0826]                            Plummer, D., "Ethernet Address
                                        Resolution Protocol: Or
                                        converting network protocol
                                        addresses to 48.bit Ethernet
                                        address for transmission on
                                        Ethernet hardware", STD 37,
                                        RFC 826, November 1982.

   [RFC2390]                            Bradley, T., Brown, C.,

   [RFC3443]                            Agarwal, P. and A.
                                        Malis, "Inverse Address
                                        Resolution Protocol", B. Akyol, "Time
                                        To Live (TTL) Processing in
                                        Multi-Protocol Label Switching
                                        (MPLS) Networks", RFC 2390,
                                        September 1998.

   [RFC2461]                            Narten, T., Nordmark, 3443,
                                        January 2003.

   [RFC3945]                            Mannie, E., and W.
                                        Simpson, "Neighbor Discovery for
                                        IP Version 6 (IPv6)", RFC 2461,
                                        December 1998.

   [RFC3122]                            Conta, A., "Extensions to IPv6
                                        Neighbor Discovery for Inverse
                                        Discovery Specification", "Generalized Multi-
                                        Protocol Label Switching (GMPLS)
                                        Architecture", RFC 3122, June 2001. 3945,
                                        October 2004.

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

   [RFC5254]                            Bitar, N., Bocci, M., and L.
                                        Martini, "Requirements for
                                        Multi-Segment Pseudowire
                                        Emulation Edge-to-Edge (PWE3)",
                                        RFC 5254, October 2008.

   [RFC5309]                            Shen, N. and A. Zinin, "Point-
                                        to-Point Operation over LAN in
                                        Link State Routing Protocols",
                                        RFC 5309, October 2008.

   [RFC5331]                            Aggarwal, R., Rekhter, Y., and
                                        E. Rosen, "MPLS Upstream Label
                                        Assignment and Context-Specific
                                        Label Space", RFC 5331,
                                        August 2008.

   [RFC5654]                            Niven-Jenkins, B., Brungard, D.,
                                        Betts, M., Sprecher, N., and S.
                                        Ueno, "Requirements of an MPLS
                                        Transport Profile", RFC 5654,
                                        September 2009.

   [RFC5659]                            Bocci, M. and S. Bryant, "An
                                        Architecture for Multi-Segment
                                        Pseudowire Emulation Edge-to-
                                        Edge", RFC 5659, October 2009.

Authors' Addresses

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

   Phone:
   EMail: matthew.bocci@alcatel-lucent.com

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

   Phone:
   EMail: stbryant@cisco.com

   Dan Frost
   Cisco Systems

   Phone:
   Fax:
   EMail: danfrost@cisco.com
   URI:

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

   Phone:
   EMail: lieven.levrau@alcatel-lucent.com
   Lou Berger
   LabN

   Phone: +1-301-468-9228
   Fax:
   EMail: lberger@labn.net
   URI: