[Docs] [txt|pdf|xml|html] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: (draft-blb-mpls-tp-framework) 00 01 02 03 04 05 06 07 08 09 10 11 12 RFC 5921

MPLS Working Group                                         M. Bocci, Ed.
Internet-Draft                                            Alcatel-Lucent
Intended status: Standards Track                          S. Bryant, Ed.
Expires: January 11, 2010                                  Cisco Systems
                                                               L. Levrau
                                                           July 10, 2009

               A Framework for MPLS in Transport Networks

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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on January 11, 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 in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Bocci, et al.           Expires January 11, 2010                [Page 1]

Internet-Draft              MPLS TP Framework                  July 2009


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

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   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 of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Motivation and Background  . . . . . . . . . . . . . . . .  3
     1.2.  Applicability  . . . . . . . . . . . . . . . . . . . . . .  4
     1.3.  Scope  . . . . . . . . . . . . . . . . . . . . . . . . . .  5
     1.4.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  6
   2.  Introduction to Requirements . . . . . . . . . . . . . . . . .  6
   3.  Transport Profile Overview . . . . . . . . . . . . . . . . . .  7
     3.1.  Packet Transport Services  . . . . . . . . . . . . . . . .  7
     3.2.  Architecture . . . . . . . . . . . . . . . . . . . . . . .  8
     3.3.  MPLS-TP Forwarding Domain  . . . . . . . . . . . . . . . . 10
     3.4.  MPLS-TP LSP Clients  . . . . . . . . . . . . . . . . . . . 12
       3.4.1.  Network Layer Transport Service  . . . . . . . . . . . 12
     3.5.  Identifiers  . . . . . . . . . . . . . . . . . . . . . . . 16
     3.6.  Operations, Administration and Maintenance (OAM) . . . . . 17
     3.7.  Generic Associated Channel (G-ACh) . . . . . . . . . . . . 21
     3.8.  Control Plane  . . . . . . . . . . . . . . . . . . . . . . 24
       3.8.1.  PW Control Plane . . . . . . . . . . . . . . . . . . . 26
       3.8.2.  LSP Control Plane  . . . . . . . . . . . . . . . . . . 26
     3.9.  Static Operation of LSPs and PWs . . . . . . . . . . . . . 27
     3.10. Survivability  . . . . . . . . . . . . . . . . . . . . . . 27
     3.11. Network Management . . . . . . . . . . . . . . . . . . . . 28
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 29
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 30
   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 30
     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 30
     7.2.  Informative References . . . . . . . . . . . . . . . . . . 33

Bocci, et al.           Expires January 11, 2010                [Page 2]

Internet-Draft              MPLS TP Framework                  July 2009

1.  Introduction

1.1.  Motivation and Background

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

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

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

   o  Applications with various bandwidth and Quality of Service (QoS)

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

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

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

   o  A high level of protection and availability.

   o  Quality of service.

   o  Extended OAM capabilities.

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

Bocci, et al.           Expires January 11, 2010                [Page 3]

Internet-Draft              MPLS TP Framework                  July 2009

   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 a
   common set of new functions that are applicable to both MPLS networks
   in general, and those belonging to the MPLS-TP profile.

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

1.2.  Applicability

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

Bocci, et al.           Expires January 11, 2010                [Page 4]

Internet-Draft              MPLS TP Framework                  July 2009

                                    MPLS-TP Solution exists
                                       over this spectrum

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

                      Figure 1: MPLS-TP Applicability

   The diagram above shows the spectrum of services that can be
   supported by MPLS.  MPLS-TP solutions are primarily intended for
   packet transport applications.  These can be deployed using a profile
   of MPLS that is strictly connection oriented and does not rely on IP
   forwarding or routing (shown on the right hand side of the figure),
   or in conjunction with an MPLS network that does use IP forwarding
   and that supports a broader range of IP services.  This is the multi-
   service solution in the centre of the figure.

1.3.  Scope

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

   This document describes the architecture for MPLS-TP when the LSP
   client is a pseudowire, and when the LSP is providing a network layer
   transport service.

Bocci, et al.           Expires January 11, 2010                [Page 5]

Internet-Draft              MPLS TP Framework                  July 2009

1.4.  Terminology

   Term    Definition
   ------- -------------------------------------------------------------
   LSP     Label Switched Path
   MPLS-TP MPLS Transport profile
   SDH     Synchronous Digital Hierarchy
   ATM     Asynchronous Transfer Mode
   OTN     Optical Transport Network
   cl-ps   Connectionless - Packet Switched
   co-cs   Connection Oriented - Circuit Switched
   co-ps   Connection Oriented - Packet Switched
   OAM     Operations, 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
   MPLS-TP MPLS Transport Profile.  The set of MPLS functions that meet
           the requirements in [I-D.ietf-mpls-tp-requirements].

   Detailed definitions and additional terminology may be found in

2.  Introduction to Requirements

   The requirements for MPLS-TP are specified in
   [I-D.ietf-mpls-tp-requirements], [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.  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.  Any new mechanisms
   and capabilities added to support transport networks and packet
   transport services must be able to inter-operate with existing MPLS
   and pseudowire control and forwarding planes.

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

Bocci, et al.           Expires January 11, 2010                [Page 6]

Internet-Draft              MPLS TP Framework                  July 2009

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

   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 be possible without any dependencies on 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.

   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

Bocci, et al.           Expires January 11, 2010                [Page 7]

Internet-Draft              MPLS TP Framework                  July 2009

      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.

3.2.  Architecture

   [Editors' Note Section 3.2 needs to generalized to include the
   architecture when PWs are not being transported and the client is IP,
   MPLS or a network layer service over MPLS-TP LSPs as described in
   section 3.4]

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

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

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

Bocci, et al.           Expires January 11, 2010                [Page 8]

Internet-Draft              MPLS TP Framework                  July 2009

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

                  MPLS-TP Architecture (Multi-Segment PW)

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

   This document describes the architecture for MPLS-TP when the LSP
   client is a PW.  The transport of IP and MPLS, other than carried
   over a PW, is outside the scope of this document.  This does not
   preclude the use of LSPs conforming to the MPLS transport profile
   from being used to carry IP or other MPLS LSPs by general purpose
   MPLS networks.  LSP hierarchy MAY be used within the MPLS-TP network,
   so that more than one LSP label MAY appear in the label stack.

Bocci, et al.           Expires January 11, 2010                [Page 9]

Internet-Draft              MPLS TP Framework                  July 2009

             |       Native service      |
             H     PW Encapsulation      H \   <---- PW Control word
             H---------------------------H  \  <---- Normalised client
             H         PW OAM            H     MPLS-TP channel
             H---------------------------H  /
             H     PW Demux (S=1)        H /
             H---------------------------H \
             H         LSP OAM           H  \
             H---------------------------H  / MPLS-TP Path(s)
             H     LSP Demultiplexer(s)  H /
             |           Server          |

        Figure 3: Domain of MPLS-TP Layer Network using Pseudowires

   Figure (Figure 3) illustrates the protocol stack to be used when
   pseudowires are carried over MPLS-TP LSPs.

   When providing a VPWS, VPLS, VPMS or IPLS, pseudowires MUST be used
   to carry a client service.  For compatibility with transport
   nomenclature, the PW may be referred to as the MPLS-TP Channel and
   the LSP may be referred to as the MPLS-TP Path.

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

   PW OAM, PSN OAM and PW client data are mutually exclusive and never
   exist in the same packet.

   The MPLS-TP definition applies to the following two domains:

   o  MPLS-TP Forwarding Domain

   o  MPLS-TP Transport Domain

3.3.  MPLS-TP Forwarding Domain

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

Bocci, et al.           Expires January 11, 2010               [Page 10]

Internet-Draft              MPLS TP Framework                  July 2009

   payload carried by the MPLS-TP PW packet.

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

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

   During forwarding a label is pushed to associate a forwarding
   equivalence class (FEC) with the LSP or PW.  This 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, in which case the packet may be inspected and either
   discarded or subjected to further processing within the LSR.  TTL
   expiry causes an exception which forces a packet to be further
   inspected and processed.  While this occurs, the forwarding of
   succeeding packets continues without interruption.  Therefore, the
   only way to cause a P (intermediate) LSR to inspect a packet (for
   example for OAM purposes) is to set the TTL to expire at that LSR.

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

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

   The MPLS encapsulation format is as defined in RFC 3032[RFC3032].
   Per-platform label space is used for PWs.  Either per-platform or
   per-interface label space may be used for LSPs.

   Point to point MPLS-TP LSPs can be either unidirectional or
   bidirectional.  Point-to-multipoint MPLS-TP LSPs are unidirectional.
   Point-to-multipont PWs are currently being defined in the IETF and
   may be incorporated in MPLS-TP if required.

   It MUST be possible to configure an MPLS-TP LSP such that the forward

Bocci, et al.           Expires January 11, 2010               [Page 11]

Internet-Draft              MPLS TP Framework                  July 2009

   and backward directions of a bidirectional MPLS-TP LSP are co-routed
   i.e. they follow the same path.  The pairing relationship between the
   forward and the backward directions must be known at each LSR or LER
   on a bidirectional LSP.

   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.

   Both E-LSP and L-LSP are supported in MPLS-TP, as defined in RFC 3270

3.4.  MPLS-TP LSP Clients

   This document specifies the architecture for two types of client:

   o  A PW

   o  A network layer transport service

   When the client is a PW, the MPLS-TP transport domain consists of the
   PW encapsulation mechanisms, including the PW control word.  When the
   client is operating at the network layer the mechanism described in
   Section 3.4.1 is used.

3.4.1.  Network Layer Transport Service

   MPLS-TP LSPs can be used to deliver a network level transport
   service.  Such a network layer transport service (NLTS) can be used
   to transport any network layer protocol between service interfaces.
   Example of network layer protocols include IP, MPLS and even MPLS-TP.

   With network layer transport, the MPLS-TP domain provides a
   bidirectional point-to-point connection between two customer edge
   (CE) MPLS-TP nodes.  Point-to- multipoint service is for further
   study.  As shown in Figure 4, there is an attachment circuit between
   the CE node on the left and its corresponding provider edge (PE) node
   that 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.

Bocci, et al.           Expires January 11, 2010               [Page 12]

Internet-Draft              MPLS TP Framework                  July 2009

                     :    +--------------------+    :
                     :    |   +------------+   |    :
                     :    |   | Management |   |    :
            +------+ :    |   |  system(s) |   |    : +------+
            |  C   | :    |   +------------+   |    : |  CE  |  +------+
            |device| :    |                    |    : |device|--|  C   |
            +------+ :    |                +------+ : |  of  |  |device|
                |    :    |                |      x=:=|SVC  A|  +------+
                |    :    |                |      | : +------+
            +------+ :    |                |  PE  | :
  +------+  |  CE  | :    |                |device| :
  |  C   |  |device| : +------+  +------+  |      | :
  |device|--|  of  |=:=x      |--|      |--|      | :
  +------+  |SVC  A| : |      |  |      |  +------+ :
            +------+ : |  PE  |  |  P   |      |    :
            +------+ : |device|  |device|      |    :
  +------+  | CE   | : |      |  |      |  +------+ :
  |  C   |--|device|=:=x      |--|      |--|      | :
  |device|  | of   | : +------+  +------+  |      | :
  +------+  |SVC  B| :    |                |  PE  | :
            +------+ :    |                |device| :
               |     :    |                |      | : +------+
               |     :    |                |      x=:=|  CE  |  +------+
            +------+ :    |                +------+ : |device|  |  C   |
            |  C   | :    |                    |    : |  of  |--|device|
            |device| :    |                    |    : |SVC  B|  +------+
            +------+ :    |                    |    : +------+
                     :    |                    |    :
                Customer  |                    |  Customer
                interface |      MPLS-TP       |  interface
                          |<---- Provider ---->|
                          |      network       |

     Key:   ==== attachment circuit
            x    service interface
            ---- link

           Figure 4: Network Layer Transport Service Components

   At the service interface the PE transforms the ingress packet to the
   format that will be carry over the transport network, and similarly
   the corresponding service interface at the egress PE transforms the
   packet to the format needed by the attached CE.  The attachment
   circuits may be heterogeneous (e.g., any combination of SDH, PPP,
   frame relay etc) and network layer protocol payloads arrive at the
   service interface encapsulated in the L1/L2 encoding defined for that
   access link type.  It should be noted that the set of network layer

Bocci, et al.           Expires January 11, 2010               [Page 13]

Internet-Draft              MPLS TP Framework                  July 2009

   protocols includes MPLS and hence MPLS encoded packets with an MPLS
   label stack (the client MPLS stack), may appear at the service

   Within the MPLS-TP transport network, the network layer protocols are
   carried over the MPLS-TP LSP using a 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 5 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 service over an MPLS-TP
   transport network.

         |        MPLS-TP LSP label(s) (S=0)  | n*4 octets
         .                                    . (four octets per label)
         |      Service label (s=1)           |   4 octets
         |       Client Network               |
         |       Layer Protocol               |
         |           Stack.                   |

      Note that the Client Network Layer Protocol
      Stack may include an MPLS label stack
      with the S bit set (S=1).

         Figure 5: Network Layer Transport Service Protocol Stack

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

   Service labels are typically carried over an MPLS-TP edge-to-edge
   LSP, which is also shown in Figure 5.  The use of an edge-to-edge LSP
   is RECOMMENDED when more than one protocol payload type is to be
   transported.  For example, if only MPLS is carried then a single
   Service Label would be used to provided both payload type indication
   and the MPLS-TP edge-to-edge LSP.  Alternatively, if both IP and MPLS
   is to be carried then two Service Labels would be mapped on to a
   common MPLS-TP edge-to-edge LSP.

Bocci, et al.           Expires January 11, 2010               [Page 14]

Internet-Draft              MPLS TP Framework                  July 2009

   As noted above, any 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 not transported across the MPLS-TP
   network.  This enables the use of different L2/L1 technologies at two
   service interfaces.

   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 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.  (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 or OSPF some care
   should be taken to configure the routing protocols to use 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.]

   The CE to CE service types and corresponding labels may be configured
   or signaled.  When they are signaled the CE 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 [REF-TBD].
   There are a number of methods that can be used to carry this

   o  It can be carried via an out-of-band control channel.  (As 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 the attachment circuit with MPLS using a
      normal label that is agreed between CE and PE.

Bocci, et al.           Expires January 11, 2010               [Page 15]

Internet-Draft              MPLS TP Framework                  July 2009

   o  It could be carried over the attachment circuit in an ACH.

   o  It could be carried over the attachment circuit in IP.

   In the MPLS and ACH cases above, this label value is used to carry
   LSP signaling without any further encapsulation.  This signaling
   channel is always point-to-point and MUST use local CE and PE

   The method(s) to be used will be described in a future version of the

3.5.  Identifiers

   Identifiers 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].  The MPLS-TP requirements
   [I-D.ietf-mpls-tp-requirements] require that the elements and objects
   in an MPLS-TP environment are able to be configured and managed
   without a control plane.  In such an environment many conventions for
   defining identifiers are possible.  However it is also anticipated
   that operational environments where MPLS-TP objects, LSPs and PWs
   will be signaled via existing protocols such as the Label
   Distribution Protocol [RFC4447] and the Resource Reservation Protocol
   as it is applied to Generalized Multi-protocol Label Switching (
   [RFC3471] and [RFC3473]) (GMPLS).
   [draft-swallow-mpls-tp-identifiers-00] defines a set of identifiers
   for 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
   the network, and identifiers used for demultiplexing and forwarding.

   Whilst IP addressing is used by default, MPLS-TP must be able to
   operate in environments where IP is not used in the forwarding plane.
   Therefore, the default mechanism for OAM demultiplexing in MPLS-TP
   LSPs and PWs is the generic associated channel.  Forwarding based on
   IP addresses for user or OAM packets is not REQUIRED for MPLS-TP.

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

Bocci, et al.           Expires January 11, 2010               [Page 16]

Internet-Draft              MPLS TP Framework                  July 2009

3.6.  Operations, Administration and Maintenance (OAM)

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

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

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

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

Bocci, et al.           Expires January 11, 2010               [Page 17]

Internet-Draft              MPLS TP Framework                  July 2009

========================== End to End LSP OAM ==========================
     .....                     .....         .....            .....
     '''''                     '''''         '''''            '''''

     |<-------- 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)
      .....   .....   .....  ..........   ..........  .....    .....
      '''''   '''''   '''''  ''''''''''   ''''''''''  '''''    '''''
      <------------ ME ----------><--- ME ----><------- ME -------->

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

                     Figure 6: Example of MPLS-TP OAM

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

Bocci, et al.           Expires January 11, 2010               [Page 18]

Internet-Draft              MPLS TP Framework                  July 2009

   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|     +---+
|   |      |    |=========|    |=========|    |=========|    |     |   |
|   |      |    |=========|    |=========|    |=========|    |     |   |
+---+      | 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 7: MPLS-TP OAM archtecture

   The following MPLS-TP MEs are specified in

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

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

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

Bocci, et al.           Expires January 11, 2010               [Page 19]

Internet-Draft              MPLS TP Framework                  July 2009

   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 be independent of
      the OAM function(s) operated on the end-to-end LSP.  This can be
      achieved by including a label representing the LTCME on one or
      more LSP label stacks for 1:1 or N:1 monitoring of LSPs,
      respectively.  Note that the term Tandem Connection Monitoring has
      historical significance dating back to the early days of the
      telephone network, but is equally applicable to the hierarchal
      architectures commonly employed in todays packet networks.

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

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

   The MPLS-TP OAM architecture support a wide range of OAM functions,
   including the following

   o  Continuity Check

   o  Connectivity Verification

   o  Performance monitoring (e.g. loss and delay)

   o  Alarm suppression

   o  Remote Integrity

   These are applicable to any layer defined within MPLS-TP, i.e.  MPLS
   Section, LSP and PW.

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

Bocci, et al.           Expires January 11, 2010               [Page 20]

Internet-Draft              MPLS TP Framework                  July 2009

   addressable network.

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

3.7.  Generic Associated Channel (G-ACh)

   For correct operation of the OAM it is important that the OAM packets
   fate share with the data packets.  In addition in MPSL-TP it is
   necessary to discriminate between user data payloads and other types
   of payload.  For example the packet may contain a Signaling
   Communication Channel (SCC), or a channel used for Automatic
   Protection Switching (APS) data.  Such packets are carried on a
   control channel associated to the LSP, Section or PW.  This is
   achieved by carrying such packets on a generic control channel
   associated to the 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 LSPs or PWs.  The G-ACH is defined
   in [RFC5586] and it is similar to the Pseudowire Associated Channel
   [RFC4385], which is used 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 a packets belonging to the associated channel, as described
   in[RFC4385].  When the first nibble of a packet, immediately
   following the label at the bottom of stack, has a value of one, then
   this packet belongs to a G-ACh.  The first 32 bits following the
   bottom of stack label then have a defined format called an associated
   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 a discriminator for the type of G-ACh traffic.

   When the OAM, or a similar message is carried over an LSP, rather
   than over a pseudowire, it is necessary to provide an indication in
   the packet that the payload is something other than a user data
   packet.  This is 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

Bocci, et al.           Expires January 11, 2010               [Page 21]

Internet-Draft              MPLS TP Framework                  July 2009

   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 that 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 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 are in accordance with [RFC3031] and

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

   The G-ACH MUST only be used for channels that are an adjunct to the
   data service.  Examples of these are OAM, APS, MCC and SCC, but the
   use is not restricted to those names services.  The G-ACH MUST NOT be
   used 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 the LSP, PW or section.  Protocols using the
   G-ACh must therefore take into consideration the impact they have on
   the user data that they are sharing resources with.  In addition,
   protocols using the G-ACh MUST conform to the security and congestion
   considerations described in [RFC5586]. .

   Figure 8 shows the reference model depicting how the control channel
   is associated with the pseudowire protocol stack.  This is based on
   the reference model for VCCV shown in Figure 2 of [RFC5085].

Bocci, et al.           Expires January 11, 2010               [Page 22]

Internet-Draft              MPLS TP Framework                  July 2009

          +-------------+                                +-------------+
          |  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 8: PWE3 Protocol Stack Reference Model including the G-ACh

   PW associated channel messages are encapsulated using the PWE3
   encapsulation, so that they are handled and processed in the same
   manner (or in some cases, an analogous manner) as the PW PDUs for
   which they provide a control channel.

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

Bocci, et al.           Expires January 11, 2010               [Page 23]

Internet-Draft              MPLS TP Framework                  July 2009

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

      Figure 9: MPLS Protocol Stack Reference Model including the LSP
                        Associated Control Channel

3.8.  Control Plane

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

   Figure 10 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.

Bocci, et al.           Expires January 11, 2010               [Page 24]

Internet-Draft              MPLS TP Framework                  July 2009

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

      1) NMS may be centralised or distributed. Control plane is
      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 LSP or a G-ACh.

           Figure 10: 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 control
   plane for MPLS-TP LSPs [RFC3471].  Some of the RSVP-TE functions that
   are required for LSP signaling for MPLS-TP are based on GMPLS.

   The distributed MPLS-TP control plane provides the following

   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

Bocci, et al.           Expires January 11, 2010               [Page 25]

Internet-Draft              MPLS TP Framework                  July 2009

   (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 e.g. for fault detection and localization in the event of
   a failure in order to efficiently restore failed transport paths.

   The MPLS-TP control plane supports all MPLS-TP data plane
   connectivity patterns that are needed for establishing transport
   paths including protected paths as described in the survivability
   section Section 3.10 of this document.  Examples of the MPLS-TP data
   plane connectivity patterns are LSPs utilizing 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] ).  The
   setup and maintenance of single-segment or multi- segment pseudowires
   uses the Label Distribution Protocol (LDP) as per [RFC4447] and
   extensions for MS-PWs [I-D.ietf-pwe3-segmented-pw] and

3.8.2.   LSP Control Plane

   MPLS-TP provider edge nodes 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)
   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

   o  OSPF-TE or ISIS-TE for routing

   RSVP-TE signaling in support of GMPLS, as defined in [RFC3473], is

Bocci, et al.           Expires January 11, 2010               [Page 26]

Internet-Draft              MPLS TP Framework                  July 2009

   used for the setup, modification, and release of MPLS-TP transport
   paths and protection paths.  It supports unidirectional, bi-
   directional and multicast types of LSPs.  The route of a transport
   path is typically calculated in the ingress node of a domain and the
   RSVP explicit route object (ERO) is utilized for the setup of the
   transport path exactly following the given route.  GMPLS based
   MPLS-TP LSPs must be able to 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 as defined in [RFC5307] is used for
   carrying link state information in a MPLS-TP network.

3.9.  Static Operation of LSPs and PWs

   A PW or LSP may be statically configured without the support of a
   dynamic control plane.  This may be either by direct configuration of
   the PEs/LSRs, or via a network management system.  The collateral
   damage that loops can cause during the time taken to detect the
   failure may be severe.  When static configuration mechanisms are
   used, care must be taken to ensure that loops to not form.

3.10.  Survivability

   Survivability requirements for MPLS-TP are specified in

   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 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 concurrent traffic
   paths (1+1), one active and one standby path with guaranteed
   bandwidth on both paths (1:1) or one active path and a standby path
   that is shared by one or more other active paths (shared protection).

Bocci, et al.           Expires January 11, 2010               [Page 27]

Internet-Draft              MPLS TP Framework                  July 2009

   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

   o  Optimised for linear, ring or meshed topologies.

   o  Use OAM mechanisms to detect and localize 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 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.

3.11.  Network Management

   The network management architecture and requirements for MPLS-TP are
   specified in [I-D.ietf-mpls-tp-nm-req].  It derives 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 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 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 MPLS-TP NE, there is no restriction on which management protocol
   should be used.  It is used to provision and manage an end-to-end
   connection across a network where some segments are create/managed,

Bocci, et al.           Expires January 11, 2010               [Page 28]

Internet-Draft              MPLS TP Framework                  July 2009

   for examples by 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
   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 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
   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
   or proactively.

4.  Security Considerations

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

Bocci, et al.           Expires January 11, 2010               [Page 29]

Internet-Draft              MPLS TP Framework                  July 2009

   considerations of that additional functionality also apply.

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

   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

   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

7.  References

7.1.  Normative References

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

Bocci, et al.           Expires January 11, 2010               [Page 30]

Internet-Draft              MPLS TP Framework                  July 2009

                                        requirements"", 2005.

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

Bocci, et al.           Expires January 11, 2010               [Page 31]

Internet-Draft              MPLS TP Framework                  July 2009

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

Bocci, et al.           Expires January 11, 2010               [Page 32]

Internet-Draft              MPLS TP Framework                  July 2009

                                        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.

7.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-mpls-tp-nm-req]            Mansfield, S. and K. Lam, "MPLS
                                        TP Network Management
                                        (work in progress), June 2009.

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

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

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

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

   [I-D.ietf-pwe3-dynamic-ms-pw]        Martini, L., Bocci, M., Bitar,
                                        N., Shah, H., Aissaoui, M., and

Bocci, et al.           Expires January 11, 2010               [Page 33]

Internet-Draft              MPLS TP Framework                  July 2009

                                        F. Balus, "Dynamic Placement of
                                        Multi Segment Pseudo Wires",
                                        (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-
                                        (work in progress),
                                        February 2009.

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

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

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

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

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

Bocci, et al.           Expires January 11, 2010               [Page 34]

Internet-Draft              MPLS TP Framework                  July 2009

Authors' Addresses

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

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

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

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

   Lieven Levrau
   7-9, Avenue Morane Sulnier
   Velizy  78141

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

Bocci, et al.           Expires January 11, 2010               [Page 35]

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