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

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 March 15, 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.

Abstract

This document specifies an architectural framework for the application of Multi Protocol Label Switching (MPLS) in transport networks, by enabling the construction of packet switched equivalents to 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 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 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [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
    1.1.  Motivation and Background
    1.2.  Scope
    1.3.  Terminology
        1.3.1.  MPLS Transport Profile.
        1.3.2.  MPLS-TP Label Switched Path
        1.3.3.  MPLS-TP Label Switching Router and Label Edge Router
        1.3.4.  Additional Definitions and Terminology
    1.4.  Applicability
2.  Introduction to Requirements
3.  Transport Profile Overview
    3.1.  Packet Transport Services
    3.2.  Architecture
    3.3.  MPLS-TP Forwarding Domain
    3.4.  MPLS-TP LSP Clients
        3.4.1.  Network Layer Transport Service
    3.5.  Identifiers
    3.6.  Operations, Administration and Maintenance (OAM)
    3.7.  Generic Associated Channel (G-ACh)
    3.8.  Control Plane
        3.8.1.  PW Control Plane
        3.8.2.  LSP Control Plane
    3.9.  Static Operation of LSPs and PWs
    3.10.  Survivability
    3.11.  Network Management
4.  Security Considerations
5.  IANA Considerations
6.  Acknowledgements
7.  References
    7.1.  Normative References
    7.2.  Informative References

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] (Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., and S. Ueno, “MPLS-TP Requirements,” August 2009.) and what new protocol elements are required.

Historically the 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 transport technologies have been designed with specific characteristics :

• Strictly connection-oriented connectivity, which may be long-lived and may be provisioned manually or by network management.
• A high level of protection and availability.
• Quality of service.
• Extended OAM capabilities.

Carriers wish 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 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 beneficial.

1.2.  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] (Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., and S. Ueno, “MPLS-TP Requirements,” August 2009.) and what new protocol elements are required.

1.3.  Terminology

1.3.1.  MPLS Transport Profile.

The MPLS Transport Profile (MPLS-TP) is the set of MPLS functions that meet the requirements in [I‑D.ietf‑mpls‑tp‑requirements] (Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., and S. Ueno, “MPLS-TP Requirements,” August 2009.). Note that MPLS is defined to include any present and future MPLS capability specified by the IETF, include those capabilities specifically added to support the transport network requirement [I‑D.ietf‑mpls‑tp‑requirements] (Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., and S. Ueno, “MPLS-TP Requirements,” August 2009.).

1.3.2.  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 [I‑D.ietf‑mpls‑tp‑requirements] (Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., and S. Ueno, “MPLS-TP Requirements,” August 2009.). 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] (Allan, D., Busi, I., Niven-Jenkins, B., Fulignoli, A., Hernandez-Valencia, E., Levrau, L., Mohan, D., Sestito, V., Sprecher, N., Helvoort, H., Vigoureux, M., Weingarten, Y., and R. Winter, “MPLS-TP OAM Framework,” April 2010.).
2. Supports only 1+1, 1:1, and 1:N protection functions.
3. Is traffic engineered.
4. Is established and maintained using GMPLS protocols when a control plane is used.
5. LSPs can only be point to point or point to multipoint, i.e. the merging of LSPs is not permitted.

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

1.3.3.  MPLS-TP Label Switching Router and Label Edge Router

An MPLS-TP Label Switching Router (MPLS-TP LSR) is either an MPLS-TP Provider Edge (MPLS-TP PE) or an MPLS-TP Provider (MPLS-TP P Router) router as defined below. The terms MPLS-TP PE and MPLS-TP P router describe functions and specific node may undertake both roles. 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.3.1.  MPLS-TP Provider Edge Router

An MPLS-TP Provider Edge is an MPLS-TP LSR that adapts client traffic and encapsulate it to be carried 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.

A layer network is defined in [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,” October 2009.).

1.3.3.2.  MPLS-TP Provider Router

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

1.3.4.  Additional Definitions and Terminology

Detailed definitions and additional terminology may be found in . (Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., and S. Ueno, “MPLS-TP Requirements,” August 2009.) [I‑D.ietf‑mpls‑tp‑requirements].

1.4.  Applicability

MPLS-TP can be used to construct a packet transport networks and is therefore applicable in any packet transport network application. It is also as an alternative architecture for subsets of a packet network where the transport network model is deemed attractive.

These two modes can be considered vertical and horizontal applicability models. In the first case an MPLS-TP network is viewed as below the IP packet network i.e. provides the data link layer service for an IP network; in the second mode it is viewed as part of the IP/MPLS network and peers/interconnects directly to it. These models are not mutually exclusive.

2.  Introduction to Requirements

The requirements for MPLS-TP are specified in [I‑D.ietf‑mpls‑tp‑requirements] (Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., and S. Ueno, “MPLS-TP Requirements,” August 2009.), [I‑D.ietf‑mpls‑tp‑oam‑requirements] (Vigoureux, M. and D. Ward, “Requirements for OAM in MPLS Transport Networks,” March 2010.), and [I‑D.ietf‑mpls‑tp‑nm‑req] (Mansfield, S. and K. Lam, “MPLS TP Network Management Requirements,” October 2009.). 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.

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 [I‑D.ietf‑mpls‑tp‑requirements] (Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., and S. Ueno, “MPLS-TP Requirements,” August 2009.).

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

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.

                                 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

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.

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]

EDITOR'S NOTE Comment received from Dan Frost that we need to address:

========

- Sections 3.2 (Architecture) - 3.4 (MPLS-TP Forwarding Domain)

The organisation of these sections is confusing. It appears as if the current content of Sec. 3.2 should be relocated to a new Sec. 3.4.1 (MPLS-TP PW Client), making the current 3.4.1 become 3.4.2, and be trimmed accordingly.

A new Sec. 3.2 on the overall architecture can then be written, which can perhaps be quite short and straightforward, leaving the fancy diagrams for 3.4.1-2.

At the end of the current Sec. 3.2, we find that:

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

o MPLS-TP Forwarding Domain

o MPLS-TP Transport Domain

Neither term is defined. The first appears only as the name of the next subsection, while the second appears only in the text at the beginning of Section 3.4. As well as proper definitions, there's probably a real need for better terminology here; maybe "service" and "transport", or "service" and "forwarding", or "adaptation" and "forwarding".

. Suggestions for a new Section 3.2 (Architecture)

In a previous comment it was suggested to relocate the current content of Section 3.2 to a new PW subsection of Section 3.4. Following are the items it would be nice to see in a new Section 3.2 covering the overall architecture:

- summary of the device roles in an MPLS-TP network (CE, PE, P) - summary of the principal transport entities in an MPLS-TP network: Sections, LSPs (list/describe different types), PWs - summary of control plane options and protocols, provisioning methods - summary of key OAM functions - summary of survivability options - explanation of client-to-LSP mapping (see below) - summary of inter-domain transport options (see below)

=========

The architecture for a transport profile of MPLS (MPLS-TP) that uses PWs is based on the MPLS [RFC3031] (Rosen, E., Viswanathan, A., and R. Callon, “Multiprotocol Label Switching Architecture,” January 2001.), pseudowire [RFC3985] (Bryant, S. and P. Pate, “Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture,” March 2005.), and multi-segment pseudowire [I‑D.ietf‑pwe3‑ms‑pw‑arch] (Bocci, M. and S. Bryant, “An Architecture for Multi-Segment Pseudowire Emulation Edge-to-Edge,” July 2009.) architectures, as illustrated in Figure 3 (MPLS-TP Architecture (Single Segment PW)).

EDITORS'S NOTE - WE HAVE MODIFIED THE FIGS BELOW TO INCLUDE P ROUTERS AND HAVE ADDED THE IP/MPLS LSP CASE. WE NEED TO REWRITE THE TEXT IN THIS SECTION TO ALIGN WITH THE CONTENTS OF THE FIGURES.

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

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

               |<------------Pseudowire-------------->|
               |            encapsulated              |
               |           Pkt Xport Service          |
               |                                      |
               |         PSN              PSN         |
         AC    |     |<--tun1->|     |<--tun2--->|    |    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 ----------------->|

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 (MPLS-TP Forwarding Domain).

EDITORS NOTE reword next and add text to describe the IP/MPLS cases

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.

          +---------------------------+
          |       Client service      |
          /===========================\  <---- Normalised client
          H     Service LSP OAM       H \
          H---------------------------H  } MPLS-TP channel
          H   Svc LSP Demux (S=1)     H /
          H---------------------------H \
          H         LSP OAM           H  \
          H---------------------------H  / MPLS-TP Path(s)
          H     LSP Demultiplexer(s)  H /
          \===========================/
          |           Server          |
          +---------------------------+

          +---------------------------+
          |       Client 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 (Domain of MPLS-TP Layer Network using Pseudowires) 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] (Rosen, E., Viswanathan, A., and R. Callon, “Multiprotocol Label Switching Architecture,” January 2001.), 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:

• MPLS-TP Forwarding Domain
• 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] (Bryant, S. and P. Pate, “Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture,” March 2005.). The PW label is used for forwarding in this case and is always at the bottom of the label stack. The operation of the MPLS-TP network is independent of the payload carried by the MPLS-TP PW packet.

MPLS-TP is itself a client of an underlying server layer. MPLS-TP is thus bounded by a set of adaptation functions to this server layer network. These adaptation functions provide encapsulation of the MPLS-TP frames and for the transparent transport of those frames over the server layer network. The MPLS-TP client inherits its QoS from the MPLS-TP network, which in turn inherits its QoS from the server layer. The server layer must therefore provide the 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] (Rosen, E., Viswanathan, A., and R. Callon, “Multiprotocol Label Switching Architecture,” January 2001.) for point-to-point LSPs and [RFC5332] (Eckert, T., Rosen, E., Aggarwal, R., and Y. Rekhter, “MPLS Multicast Encapsulations,” August 2008.) 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] (Bryant, S. and P. Pate, “Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture,” March 2005.) and [I‑D.ietf‑pwe3‑ms‑pw‑arch] (Bocci, M. and S. Bryant, “An Architecture for Multi-Segment Pseudowire Emulation Edge-to-Edge,” July 2009.).

The Traffic Class field (formerly the MPLS EXP field) follows the definition and processing rules of [RFC5462] (Andersson, L. and R. Asati, “Multiprotocol Label Switching (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic Class" Field,” February 2009.) and [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,” May 2002.). Only the pipe and short-pipe models are supported in MPLS-TP.

The MPLS encapsulation format is as defined in RFC 3032[RFC3032] (Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, “MPLS Label Stack Encoding,” January 2001.). 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 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 [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,” May 2002.)

3.4.  MPLS-TP LSP Clients

This document specifies the architecture for two types of client:

• A PW
• 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 (Network Layer Transport Service) 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. Examples of network layer protocols include IP, MPLS and 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 6 (Network Layer Transport Service Components), 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.

                     :    +--------------------+    :
                     :    |   +------------+   |    :
                     :    |   | 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

At the service interface the PE transforms the ingress packet to the format that will be carried 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 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.

EDITOR'S NOTE John, Lou and Rahul please note that this next para has been added.

Note the case where either or both the attachment circuits are a LAN needs additional specification which is outside the scope of this document. This mode of operation requires that the PE participated in the client network for example to execute neighbor discover protocols such as ARP and IPv6 neighbor discovery. Operation can be achieved through the mechanisms described in [I‑D.ietf‑l2vpn‑arp‑mediation] (Rosen, E., Shah, H., Smith, T., Heron, G., Augustyn, W., Malis, A., Kompella, V., Wright, S., and S. Khandekar, “ARP Mediation for IP Interworking of Layer 2 VPN,” February 2010.), which includes the case of static configuration of the CE IP addresses on the PEs.

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] (Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, “MPLS Label Stack Encoding,” January 2001.), the bottom label, with the 'bottom of stack' bit set to '1', defines the network layer protocol being transported. Figure 7 (Network Layer Transport Service Protocol Stack) 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).

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 7 (Network Layer Transport Service Protocol Stack). The mapping between protocol payload type and Service Label is either configured or signaled.

Service labels are typically carried over an MPLS-TP edge-to-edge LSP, which is also shown in Figure 7 (Network Layer Transport Service Protocol Stack). 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.

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 signalling:

• It can be carried via an out-of-band control channel. (As is commonly done in today's GMPLS controlled transport networks.)
• It could be carried over the attachment circuit with MPLS using a reserved label.
• It could be carried over the attachment circuit with MPLS using a normal label that is agreed between CE and PE.
• It could be carried over the attachment circuit in an ACH.
• 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 addressing.

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

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] (Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., and S. Ueno, “MPLS-TP Requirements,” August 2009.) 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] (Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. Heron, “Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP),” April 2006.) and the Resource Reservation Protocol as it is applied to Generalized Multi-protocol Label Switching ( [RFC3471] (Berger, L., “Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description,” January 2003.) and [RFC3473] (Berger, L., “Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions,” January 2003.)) (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] (Kompella, K. and G. Swallow, “Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures,” February 2006.)and BFD for MPLS LSPs [I‑D.ietf‑bfd‑mpls] (Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, “BFD For MPLS LSPs,” June 2008.) 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.

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] (Bocci, M., Vigoureux, M., and S. Bryant, “MPLS Generic Associated Channel,” June 2009.).

MPLS-TP requires [I‑D.ietf‑mpls‑tp‑oam‑requirements] (Vigoureux, M. and D. Ward, “Requirements for OAM in MPLS Transport Networks,” March 2010.) 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] (Allan, D., Busi, I., Niven-Jenkins, B., Fulignoli, A., Hernandez-Valencia, E., Levrau, L., Mohan, D., Sestito, V., Sprecher, N., Helvoort, H., Vigoureux, M., Weingarten, Y., and R. Winter, “MPLS-TP OAM Framework,” April 2010.).

OAM and monitoring in MPLS-TP is based on the concept of maintenance entities, as described in [I‑D.ietf‑mpls‑tp‑oam‑framework] (Allan, D., Busi, I., Niven-Jenkins, B., Fulignoli, A., Hernandez-Valencia, E., Levrau, L., Mohan, D., Sestito, V., Sprecher, N., Helvoort, H., Vigoureux, M., Weingarten, Y., and R. Winter, “MPLS-TP OAM Framework,” April 2010.). A Maintenance Entity can be viewed as the association of two (or more) Maintenance End Points (MEPs) (see example in Figure 8 (Example of MPLS-TP OAM ) ). The MEPs that form an ME should be configured and managed to limit the OAM responsibilities of an OAM flow within a network or sub- network, or a transport path or segment, in the specific layer network that is being monitored and managed.

Each OAM flow is associated with a single ME. Each MEP within an ME resides at the boundaries of that ME. An ME may also include a set of zero or more Maintenance Intermediate Points (MIPs), which reside within the Maintenance Entity. Maintenance end points (MEPs) are capable of sourcing and sinking OAM flows, while maintenance intermediate points (MIPs) can only sink or respond to OAM flows.

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

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

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

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

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

   Native  |<-------------------- PW15 --------------------->| Native
    Layer  |                                                 |  Layer
  Service  |    |<-PSN13->|    |<-PSN3X->|    |<-PSNXZ->|    | Service
     (AC1) V    V   LSP   V    V   LSP   V    V   LSP   V    V  (AC2)
           +----+   +-+   +----+         +----+   +-+   +----+
+---+      |TPE1|   | |   |SPE3|         |SPEX|   | |   |TPEZ|     +---+
|   |      |    |=========|    |=========|    |=========|    |     |   |
|CE1|------|........PW1.....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

The following MPLS-TP MEs are specified in [I‑D.ietf‑mpls‑tp‑oam‑framework] (Allan, D., Busi, I., Niven-Jenkins, B., Fulignoli, A., Hernandez-Valencia, E., Levrau, L., Mohan, D., Sestito, V., Sprecher, N., Helvoort, H., Vigoureux, M., Weingarten, Y., and R. Winter, “MPLS-TP OAM Framework,” April 2010.):

• A Section Maintenance Entity (SME), allowing monitoring and management of MPLS-TP Sections (between MPLS LSRs).
• A LSP Maintenance Entity (LME), allowing monitoring and management of an end-to-end LSP (between LERs).
• A PW Maintenance Entity (PME), allowing monitoring and management of an end-to-end SS/MS-PWs (between T-PEs).
• 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] (Martini, L., Nadeau, T., Metz, C., Bocci, M., Aissaoui, M., Balus, F., and M. Duckett, “Segmented Pseudowire,” April 2010.). 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] (Bocci, M., Vigoureux, M., and S. Bryant, “MPLS Generic Associated Channel,” June 2009.). 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

• Continuity Check
• Connectivity Verification
• Performance monitoring (e.g. loss and delay)
• Alarm suppression
• 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 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] (Bocci, M., Vigoureux, M., and S. Bryant, “MPLS Generic Associated Channel,” June 2009.) and it is similar to the Pseudowire Associated Channel [RFC4385] (Bryant, S., Swallow, G., Martini, L., and D. McPherson, “Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN,” February 2006.), 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] (Bryant, S., Swallow, G., Martini, L., and D. McPherson, “Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN,” February 2006.). 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] (Bocci, M., Vigoureux, M., and S. Bryant, “MPLS Generic Associated Channel,” June 2009.). 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 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] (Rosen, E., Viswanathan, A., and R. Callon, “Multiprotocol Label Switching Architecture,” January 2001.) and [RFC3032] (Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, “MPLS Label Stack Encoding,” January 2001.).

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

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] (Bocci, M., Vigoureux, M., and S. Bryant, “MPLS Generic Associated Channel,” June 2009.). .

Figure 10 (PWE3 Protocol Stack Reference Model including the G-ACh ) 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] (Nadeau, T. and C. Pignataro, “Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires,” December 2007.).

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

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 11 (MPLS Protocol Stack Reference Model including the LSP Associated Control Channel ) shows the reference model depicting how the control channel is associated with the LSP protocol stack.

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

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] (Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., and S. Ueno, “MPLS-TP Requirements,” August 2009.) can be met, the MPLS transport profile uses existing control plane protocols for LSPs and PWs.

Figure 12 (MPLS-TP Control Plane Architecture Context) 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
   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.

The MPLS-TP control plane is based on a combination of the LDP-based control plane for pseudowires [RFC4447] (Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. Heron, “Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP),” April 2006.) and the RSVP-TE based control plane for MPLS-TP LSPs [RFC3471] (Berger, L., “Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description,” January 2003.). 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 functions:

• Signaling
• Routing
• 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 (Operations, Administration and Maintenance (OAM)) 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 (Survivability) of this document. Examples of the MPLS-TP data plane connectivity patterns are LSPs utilizing the fast reroute backup methods as defined in [RFC4090] (Pan, P., Swallow, G., and A. Atlas, “Fast Reroute Extensions to RSVP-TE for LSP Tunnels,” May 2005.) 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] (Bryant, S. and P. Pate, “Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture,” March 2005.) and [I‑D.ietf‑pwe3‑ms‑pw‑arch] (Bocci, M. and S. Bryant, “An Architecture for Multi-Segment Pseudowire Emulation Edge-to-Edge,” July 2009.) ). The setup and maintenance of single-segment or multi- segment pseudowires uses the Label Distribution Protocol (LDP) as per [RFC4447] (Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. Heron, “Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP),” April 2006.) and extensions for MS-PWs [I‑D.ietf‑pwe3‑segmented‑pw] (Martini, L., Nadeau, T., Metz, C., Bocci, M., Aissaoui, M., Balus, F., and M. Duckett, “Segmented Pseudowire,” April 2010.) and [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 Y. Seo, “Dynamic Placement of Multi Segment Pseudo Wires,” October 2009.).

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:

• RSVP-TE for signalling
• OSPF-TE or ISIS-TE for routing

RSVP-TE signaling in support of GMPLS, as defined in [RFC3473] (Berger, L., “Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions,” January 2003.), is 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] (Kumaki, K., “Interworking Requirements to Support Operation of MPLS-TE over GMPLS Networks,” March 2008.)

OSPF-TE routing in support of GMPLS as defined in [RFC4203] (Kompella, K. and Y. Rekhter, “OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS),” October 2005.) is used for carrying link state information in a MPLS-TP network. ISIS-TE routing in support of GMPLS as defined in [RFC5307] (Kompella, K. and Y. Rekhter, “IS-IS Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS),” October 2008.) 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 [I‑D.ietf‑mpls‑tp‑survive‑fwk] (Sprecher, N. and A. Farrel, “Multiprotocol Label Switching Transport Profile Survivability Framework,” April 2010.).

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] (Pan, P., Swallow, G., and A. Atlas, “Fast Reroute Extensions to RSVP-TE for LSP Tunnels,” May 2005.)), while pseudowire redundancy [I‑D.ietf‑pwe3‑redundancy] (Muley, P. and V. Place, “Pseudowire (PW) Redundancy,” October 2009.) 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] (Lang, J., Rekhter, Y., and D. Papadimitriou, “RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery,” May 2007.). 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] (Sprecher, N. and A. Farrel, “Multiprotocol Label Switching Transport Profile Survivability Framework,” April 2010.).

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

• Optimised for linear, ring or meshed topologies.
• Use OAM mechanisms to detect and localize network faults or service degenerations.
• 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.
• 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.
• 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.
• MPLS-TP recovery mechanisms can be data plane, control plane or management plane based.
• 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] (Mansfield, S. and K. Lam, “MPLS TP Network Management Requirements,” October 2009.). It derives from the generic specifications described in ITU-T G.7710/Y.1701 [G.7710] (, “ITU-T Recommendation G.7710/Y.1701 (07/07), "Common equipment management function requirements",” 2005.) for transport technologies. It also incorporates the OAM requirements for MPLS Networks [RFC4377] (Nadeau, T., Morrow, M., Swallow, G., Allan, D., and S. Matsushima, “Operations and Management (OAM) Requirements for Multi-Protocol Label Switched (MPLS) Networks,” February 2006.) and MPLS-TP Networks [I‑D.ietf‑mpls‑tp‑oam‑requirements] (Vigoureux, M. and D. Ward, “Requirements for OAM in MPLS Transport Networks,” March 2010.) 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, 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 (Static Operation of LSPs and PWs ).

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 considerations of that additional functionality also apply.

The security considerations of [RFC3985] (Bryant, S. and P. Pate, “Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture,” March 2005.) and [I‑D.ietf‑pwe3‑ms‑pw‑arch] (Bocci, M. and S. Bryant, “An Architecture for Multi-Segment Pseudowire Emulation Edge-to-Edge,” July 2009.) 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 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:

• Rahul Aggarwal
• Dieter Beller
• Lou Berger
• Malcolm Betts
• Italo Busi
• John E Drake
• Hing-Kam Lam
• Marc Lasserre
• Vincenzo Sestito
• Martin Vigoureux

7.  References

7.1. Normative References

7.2. Informative References

Authors' Addresses