RFC 5921
A Framework for MPLS in Transport Networks
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 NetworksAbstract
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.
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.
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
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 50 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 50 7.1. Normative References . . . . . . . . . . . . . . . . . . . 50 7.2. Informative References . . . . . . . . . . . . . . . . . . 511. 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.
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
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
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.
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.
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.
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).
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.
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)
