Tech-invite3GPPspaceIETF RFCsSIP
93929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 5921

A Framework for MPLS in Transport Networks

Pages: 56
Informational
Updated by:  62157274
Part 1 of 3 – Pages 1 to 12
None   None   Next

Top   ToC   RFC5921 - 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.
Top   ToC   RFC5921 - 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   ToC   RFC5921 - 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   RFC5921 - 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   RFC5921 - 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   RFC5921 - 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   RFC5921 - 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   RFC5921 - 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   RFC5921 - 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   RFC5921 - 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   RFC5921 - 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   RFC5921 - 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 Section