tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 5921

Informational
Pages: 56
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: MPLS

A Framework for MPLS in Transport Networks

Part 1 of 3, p. 1 to 12
None       Next RFC Part

Updated by:    6215    7274


Top       ToC       Page 1 
Internet Engineering Task Force (IETF)                     M. Bocci, Ed.
Request for Comments: 5921                                Alcatel-Lucent
Category: Informational                                   S. Bryant, Ed.
ISSN: 2070-1721                                            D. Frost, Ed.
                                                           Cisco Systems
                                                               L. Levrau
                                                          Alcatel-Lucent
                                                               L. Berger
                                                                    LabN
                                                               July 2010


               A Framework for MPLS in Transport Networks

Abstract

   This document specifies an architectural framework for the
   application of Multiprotocol Label Switching (MPLS) to the
   construction of packet-switched transport 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
   bidirectional connection-oriented paths, protection and restoration
   mechanisms, comprehensive Operations, Administration, and Maintenance
   (OAM) functions, and network operation in the absence of a dynamic
   control plane or IP forwarding support.  Some of these functions are
   defined in existing MPLS specifications, while others require
   extensions to existing specifications to meet the requirements of the
   MPLS-TP.

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

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

Page 2 
Status of This Memo

   This document is not an Internet Standards Track specification; it is
   published for informational purposes.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Not all documents
   approved by the IESG are a candidate for any level of Internet
   Standard; see Section 2 of RFC 5741.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   http://www.rfc-editor.org/info/rfc5921.

Copyright Notice

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

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Top       Page 3 
Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Motivation and Background  . . . . . . . . . . . . . . . .  4
     1.2.  Scope  . . . . . . . . . . . . . . . . . . . . . . . . . .  5
     1.3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  5
       1.3.1.  Transport Network  . . . . . . . . . . . . . . . . . .  7
       1.3.2.  MPLS Transport Profile . . . . . . . . . . . . . . . .  7
       1.3.3.  MPLS-TP Section  . . . . . . . . . . . . . . . . . . .  7
       1.3.4.  MPLS-TP Label Switched Path  . . . . . . . . . . . . .  7
       1.3.5.  MPLS-TP Label Switching Router . . . . . . . . . . . .  8
       1.3.6.  Customer Edge (CE) . . . . . . . . . . . . . . . . . . 10
       1.3.7.  Transport LSP  . . . . . . . . . . . . . . . . . . . . 10
       1.3.8.  Service LSP  . . . . . . . . . . . . . . . . . . . . . 10
       1.3.9.  Layer Network  . . . . . . . . . . . . . . . . . . . . 10
       1.3.10. Network Layer  . . . . . . . . . . . . . . . . . . . . 10
       1.3.11. Service Interface  . . . . . . . . . . . . . . . . . . 10
       1.3.12. Native Service . . . . . . . . . . . . . . . . . . . . 11
       1.3.13. Additional Definitions and Terminology . . . . . . . . 11
   2.  MPLS Transport Profile Requirements  . . . . . . . . . . . . . 11
   3.  MPLS Transport Profile Overview  . . . . . . . . . . . . . . . 12
     3.1.  Packet Transport Services  . . . . . . . . . . . . . . . . 12
     3.2.  Scope of the MPLS Transport Profile  . . . . . . . . . . . 13
     3.3.  Architecture . . . . . . . . . . . . . . . . . . . . . . . 14
       3.3.1.  MPLS-TP Native Service Adaptation Functions  . . . . . 14
       3.3.2.  MPLS-TP Forwarding Functions . . . . . . . . . . . . . 15
     3.4.  MPLS-TP Native Service Adaptation  . . . . . . . . . . . . 16
       3.4.1.  MPLS-TP Client/Server Layer Relationship . . . . . . . 16
       3.4.2.  MPLS-TP Transport Layers . . . . . . . . . . . . . . . 17
       3.4.3.  MPLS-TP Transport Service Interfaces . . . . . . . . . 18
       3.4.4.  Pseudowire Adaptation  . . . . . . . . . . . . . . . . 25
       3.4.5.  Network Layer Adaptation . . . . . . . . . . . . . . . 28
     3.5.  Identifiers  . . . . . . . . . . . . . . . . . . . . . . . 33
     3.6.  Generic Associated Channel (G-ACh) . . . . . . . . . . . . 33
     3.7.  Operations, Administration, and Maintenance (OAM)  . . . . 36
     3.8.  Return Path  . . . . . . . . . . . . . . . . . . . . . . . 38
       3.8.1.  Return Path Types  . . . . . . . . . . . . . . . . . . 39
       3.8.2.  Point-to-Point Unidirectional LSPs . . . . . . . . . . 39
       3.8.3.  Point-to-Point Associated Bidirectional LSPs . . . . . 40
       3.8.4.  Point-to-Point Co-Routed Bidirectional LSPs  . . . . . 40
     3.9.  Control Plane  . . . . . . . . . . . . . . . . . . . . . . 40
     3.10. Inter-Domain Connectivity  . . . . . . . . . . . . . . . . 43
     3.11. Static Operation of LSPs and PWs . . . . . . . . . . . . . 43
     3.12. Survivability  . . . . . . . . . . . . . . . . . . . . . . 44
     3.13. Sub-Path Maintenance . . . . . . . . . . . . . . . . . . . 45
     3.14. Network Management . . . . . . . . . . . . . . . . . . . . 47
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 48
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 49

Top      ToC       Page 4 
   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 50
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 50
     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 50
     7.2.  Informative References . . . . . . . . . . . . . . . . . . 51

1.  Introduction

1.1.  Motivation and Background

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

   Historically, the optical transport infrastructure -- Synchronous
   Optical Network/Synchronous Digital Hierarchy (SONET/SDH) and 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:

   o  Strictly connection-oriented connectivity, which may be long-lived
      and may be provisioned manually, for example, by network
      management systems or direct node configuration using a command
      line interface.

   o  A high level of availability.

   o  Quality of service.

   o  Extensive Operations, Administration, and Maintenance (OAM)
      capabilities.

   Carriers wish to evolve such transport networks to take advantage of
   the flexibility and cost benefits of packet switching technology and
   to support packet-based services more efficiently.  While MPLS is a
   maturing packet technology that already plays an important role in
   transport networks and services, not all MPLS capabilities and
   mechanisms are needed in, or consistent with, the transport network
   operational model.  There are also transport technology
   characteristics that are not currently reflected in MPLS.

Top      ToC       Page 5 
   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 define a
   common set of MPLS protocol functions -- an MPLS Transport Profile --
   for the use of MPLS in transport networks and applications.  Some of
   the necessary functions are provided by existing MPLS specifications,
   while others require additions to the MPLS tool-set.  Such additions
   should, wherever possible, be applicable to MPLS networks in general
   as well as those that conform strictly to the transport network
   model.

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

1.2.  Scope

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

1.3.  Terminology

   Term       Definition
   ---------- ----------------------------------------------------------
   AC         Attachment Circuit
   ACH        Associated Channel Header
   Adaptation The mapping of client information into a format suitable
              for transport by the server layer
   APS        Automatic Protection Switching
   ATM        Asynchronous Transfer Mode
   BFD        Bidirectional Forwarding Detection
   CE         Customer Edge

Top      ToC       Page 6 
   CL-PS      Connectionless - Packet Switched
   CM         Configuration Management
   CO-CS      Connection Oriented - Circuit Switched
   CO-PS      Connection Oriented - Packet Switched
   DCN        Data Communication Network
   EMF        Equipment Management Function
   FCAPS      Fault, Configuration, Accounting, Performance, and
              Security
   FM         Fault Management
   G-ACh      Generic Associated Channel
   GAL        G-ACh Label
   LER        Label Edge Router
   LSP        Label Switched Path
   LSR        Label Switching Router
   MAC        Media Access Control
   MCC        Management Communication Channel
   ME         Maintenance Entity
   MEG        Maintenance Entity Group
   MEP        Maintenance Entity Group End Point
   MIP        Maintenance Entity Group Intermediate Point
   MPLS       Multiprotocol Label Switching
   MPLS-TP    MPLS Transport Profile
   MPLS-TP P  MPLS-TP Provider LSR
   MPLS-TP PE MPLS-TP Provider Edge LSR
   MS-PW      Multi-Segment Pseudowire
   Native     The traffic belonging to the client of the MPLS-TP network
   Service
   OAM        Operations, Administration, and Maintenance (see
              [OAM-DEF])
   OSI        Open Systems Interconnection
   OTN        Optical Transport Network
   PDU        Protocol Data Unit
   PM         Performance Monitoring
   PSN        Packet Switching Network
   PW         Pseudowire
   SCC        Signaling Communication Channel
   SDH        Synchronous Digital Hierarchy
   S-PE       PW Switching Provider Edge
   SPME       Sub-Path Maintenance Element
   SS-PW      Single-Segment Pseudowire
   T-PE       PW Terminating Provider Edge
   TE LSP     Traffic Engineered Label Switched Path
   VCCV       Virtual Circuit Connectivity Verification

Top      ToC       Page 7 
1.3.1.  Transport Network

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

   See also the definition of packet transport service in Section 3.1.

1.3.2.  MPLS Transport Profile

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

1.3.3.  MPLS-TP Section

   MPLS-TP sections are defined in [DATA-PLANE].  See also the
   definition of "section layer network" in Section 1.2.2 of [RFC5654].

1.3.4.  MPLS-TP Label Switched Path

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

   1.  Uses a subset of the MPLS OAM tools defined in [OAM-FRAMEWORK].

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

   3.  Is traffic engineered.

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

   5.  Is either point-to-point or point-to-multipoint.  Multipoint-to-
       point and multipoint-to-multipoint LSPs are not supported.

Top      ToC       Page 8 
   6.  It is either unidirectional, associated bidirectional, or co-
       routed bidirectional (i.e., the forward and reverse components of
       a bidirectional LSP follow the same path, and the intermediate
       nodes are aware of their association).  These are further defined
       in [DATA-PLANE].

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

   See [DATA-PLANE] for further details on the types and data-plane
   properties of MPLS-TP LSPs.

   The lowest server layer provided by MPLS-TP is an MPLS-TP LSP.  The
   client layers of an MPLS-TP LSP may be network-layer protocols, MPLS
   LSPs, or PWs.  The relationship of an MPLS-TP LSP to its client
   layers is described in detail in Section 3.4.

1.3.5.  MPLS-TP Label Switching Router

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

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

1.3.5.1.  Label Edge Router

   An MPLS-TP Label Edge Router (LER) is an LSR that exists at the
   endpoints of an LSP and therefore pushes or pops the LSP label, i.e.,
   does not perform a label swap on the particular LSP under
   consideration.

1.3.5.2.  MPLS-TP Provider Edge Router

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

Top      ToC       Page 9 
   The term Provider Edge refers to the node's role within a provider's
   network.  A provider edge router resides at the edge of a given
   MPLS-TP network domain, in which case it has links to another MPLS-TP
   network domain or to a CE, except for the case of a pseudowire
   switching provider edge (S-PE) router, which is not restricted to the
   edge of an MPLS-TP network domain.

1.3.5.3.  MPLS-TP Provider Router

   An MPLS-TP Provider router is an MPLS-TP LSR that does not provide
   MPLS-TP PE functionality for a given LSP.  An MPLS-TP P router
   switches LSPs that carry client traffic, but does not adapt client
   traffic and encapsulate it to be carried over an MPLS-TP LSP.  The
   term Provider Router refers to the node's role within a provider's
   network.  A provider router does not have links to other MPLS-TP
   network domains.

1.3.5.4.  Pseudowire Switching Provider Edge Router (S-PE)

   RFC 5659 [RFC5659] defines an S-PE as:

      A PE capable of switching the control and data planes of the
      preceding and succeeding PW segments in an MS-PW.  The S-PE
      terminates the PSN tunnels of the preceding and succeeding
      segments of the MS-PW.  It therefore includes a PW switching point
      for an MS-PW.  A PW switching point is never the S-PE and the T-PE
      for the same MS-PW.  A PW switching point runs necessary protocols
      to set up and manage PW segments with other PW switching points
      and terminating PEs.  An S-PE can exist anywhere a PW must be
      processed or policy applied.  It is therefore not limited to the
      edge of a provider network.

      Note that it was originally anticipated that S-PEs would only be
      deployed at the edge of a provider network where they would be
      used to switch the PWs of different service providers.  However,
      as the design of MS-PW progressed, other applications for MS-PW
      were recognized.  By this time S-PE had become the accepted term
      for the equipment, even though they were no longer universally
      deployed at the provider edge.

1.3.5.5.  Pseudowire Terminating Provider Edge (T-PE) Router

   RFC 5659 [RFC5659] defines a T-PE as:

      A PE where the customer-facing attachment circuits (ACs) are bound
      to a PW forwarder.  A terminating PE is present in the first and
      last segments of an MS-PW.  This incorporates the functionality of
      a PE as defined in RFC 3985.

Top      ToC       Page 10 
1.3.6.  Customer Edge (CE)

   A Customer Edge (CE) is the client function that sources or sinks
   native service traffic to or from the MPLS-TP network.  CEs on either
   side of the MPLS-TP network are peers and view the MPLS-TP network as
   a single link.

1.3.7.  Transport LSP

   A Transport LSP is an LSP between a pair of PEs that may transit zero
   or more MPLS-TP provider routers.  When carrying PWs, the Transport
   LSP is equivalent to the PSN tunnel LSP in [RFC3985] terminology.

1.3.8.  Service LSP

   A service LSP is an LSP that carries a single client service.

1.3.9.  Layer Network

   A layer network is defined in [G.805] and described in [RFC5654].  A
   layer network provides for the transfer of client information and
   independent operation of the client OAM.  A layer network may be
   described in a service context as follows: one layer network may
   provide a (transport) service to a higher client layer network and
   may, in turn, be a client to a lower-layer network.  A layer network
   is a logical construction somewhat independent of arrangement or
   composition of physical network elements.  A particular physical
   network element may topologically belong to more than one layer
   network, depending on the actions it takes on the encapsulation
   associated with the logical layers (e.g., the label stack), and thus
   could be modeled as multiple logical elements.  A layer network may
   consist of one or more sublayers.

1.3.10.  Network Layer

   This document uses the term Network Layer in the same sense as it is
   used in [RFC3031] and [RFC3032].  Network-layer protocols are
   synonymous with those belonging to Layer 3 of the Open System
   Interconnect (OSI) network model [X.200].

1.3.11.  Service Interface

   The packet transport service provided by MPLS-TP is provided at a
   service interface.  Two types of service interfaces are defined:

   o  User-Network Interface (UNI) (see Section 3.4.3.1).

   o  Network-Network Interface (NNI) (see Section 3.4.3.2).

Top      ToC       Page 11 
   A UNI service interface may be a Layer 2 interface that carries only
   network layer clients.  MPLS-TP LSPs are both necessary and
   sufficient to support this service interface as described in
   Section 3.4.3.  Alternatively, it may be a Layer 2 interface that
   carries both network-layer and non-network-layer clients.  To support
   this service interface, a PW is required to adapt the client traffic
   received over the service interface.  This PW in turn is a client of
   the MPLS-TP server layer.  This is described in Section 3.4.2.

   An NNI service interface may be to an MPLS LSP or a PW.  To support
   this case, an MPLS-TP PE participates in the service interface
   signaling.

1.3.12.  Native Service

   The native service is the client layer network service that is
   transported by the MPLS-TP network, whether a pseudowire or an LSP is
   used for the adaptation (see Section 3.4).

1.3.13.  Additional Definitions and Terminology

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

2.  MPLS Transport Profile Requirements

   The requirements for MPLS-TP are specified in [RFC5654], [RFC5860],
   and [NM-REQ].  This section provides a brief reminder to guide the
   reader.  It is not normative or intended as a substitute for these
   documents.

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

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

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

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

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

Top      ToC       Page 12 
   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.



(page 12 continued on part 2)

Next RFC Part