RFC 6373
MPLS Transport Profile (MPLS-TP) Control Plane Framework
Pages: 57
Informational
Informational
Part 1 of 4 – Pages 1 to 9
Internet Engineering Task Force (IETF) L. Andersson, Ed. Request for Comments: 6373 Ericsson Category: Informational L. Berger, Ed. ISSN: 2070-1721 LabN L. Fang, Ed. Cisco N. Bitar, Ed. Verizon E. Gray, Ed. Ericsson September 2011 MPLS Transport Profile (MPLS-TP) Control Plane FrameworkAbstract
The MPLS Transport Profile (MPLS-TP) supports static provisioning of transport paths via a Network Management System (NMS) and dynamic provisioning of transport paths via a control plane. This document provides the framework for MPLS-TP dynamic provisioning and covers control-plane addressing, routing, path computation, signaling, traffic engineering, and path recovery. MPLS-TP uses GMPLS as the control plane for MPLS-TP Label Switched Paths (LSPs). MPLS-TP also uses the pseudowire (PW) control plane for pseudowires. Management- plane functions are out of 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/rfc6373. Copyright Notice Copyright (c) 2011 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 ....................................................3 1.1. Scope ......................................................4 1.2. Basic Approach .............................................4 1.3. Reference Model ............................................6 2. Control-Plane Requirements ......................................9 2.1. Primary Requirements .......................................9 2.2. Requirements Derived from the MPLS-TP Framework ...........18 2.3. Requirements Derived from the OAM Framework ...............20 2.4. Security Requirements .....................................25 2.5. Identifier Requirements ...................................25 3. Relationship of PWs and TE LSPs ................................26 4. TE LSPs ........................................................27 4.1. GMPLS Functions and MPLS-TP LSPs ..........................27 4.1.1. In-Band and Out-of-Band Control ....................27 4.1.2. Addressing .........................................29 4.1.3. Routing ............................................29 4.1.4. TE LSPs and Constraint-Based Path Computation ......29 4.1.5. Signaling ..........................................30 4.1.6. Unnumbered Links ...................................30 4.1.7. Link Bundling ......................................30 4.1.8. Hierarchical LSPs ..................................31 4.1.9. LSP Recovery .......................................31 4.1.10. Control-Plane Reference Points (E-NNI, I-NNI, UNI) .......................................32 4.2. OAM, MEP (Hierarchy), MIP Configuration and Control .......32 4.2.1. Management-Plane Support ...........................33 4.3. GMPLS and MPLS-TP Requirements Table ......................34
4.4. Anticipated MPLS-TP-Related Extensions and Definitions ....37
4.4.1. MPLS-TE to MPLS-TP LSP Control-Plane Interworking ..37
4.4.2. Associated Bidirectional LSPs ......................38
4.4.3. Asymmetric Bandwidth LSPs ..........................38
4.4.4. Recovery for P2MP LSPs .............................38
4.4.5. Test Traffic Control and Other OAM Functions .......38
4.4.6. Diffserv Object Usage in GMPLS .....................39
4.4.7. Support for MPLS-TP LSP Identifiers ................39
4.4.8. Support for MPLS-TP Maintenance Identifiers ........39
5. Pseudowires ....................................................39
5.1. LDP Functions and Pseudowires .............................39
5.1.1. Management-Plane Support ...........................40
5.2. PW Control (LDP) and MPLS-TP Requirements Table ...........40
5.3. Anticipated MPLS-TP-Related Extensions ....................44
5.3.1. Extensions to Support Out-of-Band PW Control .......44
5.3.2. Support for Explicit Control of PW-to-LSP Binding ..45
5.3.3. Support for Dynamic Transfer of PW
Control/Ownership ..................................45
5.3.4. Interoperable Support for PW/LSP Resource
Allocation .........................................46
5.3.5. Support for PW Protection and PW OAM
Configuration ......................................46
5.3.6. Client Layer and Cross-Provider Interfaces
to PW Control ......................................47
5.4. ASON Architecture Considerations ..........................47
6. Security Considerations ........................................47
7. Acknowledgments ................................................48
8. References .....................................................48
8.1. Normative References ......................................48
8.2. Informative References ....................................51
9. Contributing Authors ...........................................56
1. Introduction
The Multiprotocol Label Switching Transport Profile (MPLS-TP) is
defined as a joint effort between the International Telecommunication
Union (ITU) and the IETF. The requirements for MPLS-TP are defined
in the requirements document, see [RFC5654]. These requirements
state that "A solution MUST be defined to support dynamic
provisioning of MPLS-TP transport paths via a control plane". This
document provides the framework for such dynamic provisioning. 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 functions of a
packet transport network as defined by the ITU-T.
1.1. Scope
This document covers the control-plane functions involved in establishing MPLS-TP Label Switched Paths (LSPs) and pseudowires (PWs). The control-plane requirements for MPLS-TP are defined in the MPLS-TP requirements document [RFC5654]. These requirements define the role of the control plane in MPLS-TP. In particular, Section 2.4 of [RFC5654] and portions of the remainder of Section 2 of [RFC5654] provide specific control-plane requirements. The LSPs provided by MPLS-TP are used as a server layer for IP, MPLS, and PWs, as well as other tunneled MPLS-TP LSPs. The PWs are used to carry client signals other than IP or MPLS. The relationship between PWs and MPLS-TP LSPs is exactly the same as between PWs and MPLS LSPs in an MPLS Packet Switched Network (PSN). The PW encapsulation over MPLS-TP LSPs used in MPLS-TP networks is also the same as for PWs over MPLS in an MPLS network. MPLS-TP also defines protection and restoration (or, collectively, recovery) functions; see [RFC5654] and [RFC4427]. The MPLS-TP control plane provides methods to establish, remove, and control MPLS-TP LSPs and PWs. This includes control of Operations, Administration, and Maintenance (OAM), data-plane, and recovery functions. A general framework for MPLS-TP has been defined in [RFC5921], and a survivability framework for MPLS-TP has been defined in [RFC6372]. These documents scope the approaches and protocols that are the foundation of MPLS-TP. Notably, Section 3.5 of [RFC5921] scopes the IETF protocols that serve as the foundation of the MPLS-TP control plane. The PW control plane is based on the existing PW control plane (see [RFC4447]) and the PWE3 architecture (see [RFC3985]). The LSP control plane is based on GMPLS (see [RFC3945]), which is built on MPLS Traffic Engineering (TE) and its numerous extensions. [RFC6372] focuses on the recovery functions that must be supported within MPLS-TP. It does not specify which control-plane mechanisms are to be used. The remainder of this document discusses the impact of the MPLS-TP requirements on the GMPLS signaling and routing protocols that are used to control MPLS-TP LSPs, and on the control of PWs as specified in [RFC4447], [RFC6073], and [MS-PW-DYNAMIC].1.2. Basic Approach
The basic approach taken in defining the MPLS-TP control-plane framework includes the following: 1) MPLS technology as defined by the IETF is the foundation for the MPLS Transport Profile.
2) The data plane for MPLS-TP is a standard MPLS data plane
[RFC3031] as profiled in [RFC5960].
3) MPLS PWs are used by MPLS-TP including the use of targeted
Label Distribution Protocol (LDP) as the foundation for PW
signaling [RFC4447]. This also includes the use of Open
Shortest Path First with Traffic Engineering (OSPF-TE),
Intermediate System to Intermediate System (IS-IS) with Traffic
Engineering (ISIS-TE), or Multiprotocol Border Gateway Protocol
(MP-BGP) as they apply for Multi-Segment Pseudowire (MS-PW)
routing. However, the PW can be encapsulated over an MPLS-TP
LSP (established using methods and procedures for MPLS-TP LSP
establishment) in addition to the presently defined methods of
carrying PWs over LSP-based PSNs. That is, the MPLS-TP domain
is a PSN from a PWE3 architecture perspective [RFC3985].
4) The MPLS-TP LSP control plane builds on the GMPLS control plane
as defined by the IETF for transport LSPs. The protocols
within scope are Resource Reservation Protocol with Traffic
Engineering (RSVP-TE) [RFC3473], OSPF-TE [RFC4203] [RFC5392],
and ISIS-TE [RFC5307] [RFC5316]. Automatically Switched
Optical Network (ASON) signaling and routing requirements in
the context of GMPLS can be found in [RFC4139] and [RFC4258].
5) Existing IETF MPLS and GMPLS RFCs and evolving Working Group
Internet-Drafts should be reused wherever possible.
6) If needed, extensions for the MPLS-TP control plane should
first be based on the existing and evolving IETF work, and
secondly be based on work by other standard bodies only when
IETF decides that the work is out of the IETF's scope. New
extensions may be defined otherwise.
7) Extensions to the control plane may be required in order to
fully automate functions related to MPLS-TP LSPs and PWs.
8) Control-plane software upgrades to existing equipment are
acceptable and expected.
9) It is permissible for functions present in the GMPLS and PW
control planes to not be used in MPLS-TP networks.
10) One possible use of the control plane is to configure, enable,
and generally control OAM functionality. This will require
extensions to existing control-plane specifications that will
be usable in MPLS-TP as well as MPLS networks.
11) The foundation for MPLS-TP control-plane requirements is
primarily found in Section 2.4 of [RFC5654] and relevant
portions of the remainder of Section 2 of [RFC5654].
1.3. Reference Model
The control-plane reference model is based on the general MPLS-TP
reference model as defined in the MPLS-TP framework [RFC5921] and
further refined in [RFC6215] on the MPLS-TP User-to-Network and
Network-to-Network Interfaces (UNI and NNI, respectively). Per the
MPLS-TP framework [RFC5921], the MPLS-TP control plane is based on
GMPLS with RSVP-TE for LSP signaling and targeted LDP for PW
signaling. In both cases, OSPF-TE or ISIS-TE with GMPLS extensions
is used for dynamic routing within an MPLS-TP domain.
Note that in this context, "targeted LDP" (or T-LDP) means LDP as
defined in RFC 5036, using Targeted Hello messages. See Section
2.4.2 ("Extended Discovery Mechanism") of [RFC5036]. Use of the
extended discovery mechanism is specified in Section 5 ("LDP") of
[RFC4447].
From a service perspective, MPLS-TP client services may be supported
via both PWs and LSPs. PW client interfaces, or adaptations, are
defined on an interface-technology basis, e.g., Ethernet over PW
[RFC4448]. In the context of MPLS-TP LSP, the client interface is
provided at the network layer and may be controlled via a GMPLS-based
UNI, see [RFC4208], or statically provisioned. As discussed in
[RFC5921] and [RFC6215], MPLS-TP also presumes an NNI reference
point.
The MPLS-TP end-to-end control-plane reference model is shown in
Figure 1. The figure shows the control-plane protocols used by MPLS-
TP, as well as the UNI and NNI reference points, in the case of a
Single-Segment PW supported by an end-to-end LSP without any
hierarchical LSPs. (The MS-PW case is not shown.) Each service
provider node's participation in routing and signaling (both GMPLS
RSVP-TE and PW LDP) is represented. Note that only the service end
points participate in PW LDP signaling, while all service provider
nodes participate in GMPLS TE LSP routing and signaling.
|< ---- client signal (e.g., IP / MPLS / L2) -------- >| |< --------- SP1 ---------- >|< ------- SP2 ----- >| |< ---------- MPLS-TP End-to-End PW --------- >| |< -------- MPLS-TP End-to-End LSP ------ >| +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ |CE1|-|-|PE1|--|P1 |--|P2 |--|PE2|-|-|PEa|--|Pa |--|PEb|-|-|CE2| +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ UNI NNI UNI GMPLS TE-RTG, |<-----|------|------|-------|------|----->| & RSVP-TE PW LDP |< ---------------------------------------- >| Figure 1. End-to-End MPLS-TP Control-Plane Reference Model Legend: CE: Customer Edge Client signal: defined in MPLS-TP Requirements L2: Any layer 2 signal that may be carried over a PW, e.g., Ethernet NNI: Network-to-Network Interface P: Provider PE: Provider Edge SP: Service Provider TE-RTG: GMPLS OSPF-TE or ISIS-TE UNI: User-to-Network Interface Note: The MS-PW case is not shown. Figure 2 adds three hierarchical LSP segments, labeled as "H-LSPs". These segments are present to support scaling, OAM, and Maintenance Entity Group End Points (MEPs), see [RFC6371], within each provider domain and across the inter-provider NNI. (H-LSPs are used to implement Sub-Path Maintenance Elements (SPMEs) as defined in [RFC5921].) The MEPs are used to collect performance information, support diagnostic and fault management functions, and support OAM triggered survivability schemes as discussed in [RFC6372]. Each H-LSP may be protected or restored using any of the schemes discussed in [RFC6372]. End-to-end monitoring is supported via MEPs at the end-to-end LSP and PW end points. Note that segment MEPs may be co- located with MIPs of the next higher-layer (e.g., end-to-end) LSPs. (The MS-PW case is not shown.)
|< ------- client signal (e.g., IP / MPLS / L2) ----- >| |< -------- SP1 ----------- >|< ------- SP2 ----- >| |< ----------- MPLS-TP End-to-End PW -------- >| |< ------- MPLS-TP End-to-End LSP ------- >| |< -- H-LSP1 ---- >|<-H-LSP2->|<- H-LSP3 ->| +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ |CE1|-|-|PE1|--|P1 |--|P2 |--|PE2|-|-|PEa|--|Pa |--|PEb|-|-|CE2| +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ UNI NNI UNI ..... ..... End2end |MEP|--------------------------------------|MEP| PW OAM ''''' ''''' ..... ..... ..... ..... End2end |MEP|----------------|MIP|---|MIP|---------|MEP| LSP OAM ''''' ''''' ''''' ''''' ..... ..... ..... ......... ......... ..... ..... Segment |MEP|-|MIP|-|MIP|-|MEP|MEP|-|MEP|MEP|-|MIP|-|MEP| LSP OAM ''''' ''''' ''''' ''''''''' ''''''''' ''''' ''''' H-LSP GMPLS TE-RTG |<-----|------|----->||<---->||<-----|----->| &RSVP-TE (within an MPLS-TP network) E2E GMPLS TE-RTG |< ------------------|--------|------------>| &RSVP-TE PW LDP |< ---------------------------------------- >| Figure 2. MPLS-TP Control-Plane Reference Model with OAM Legend: CE: Customer Edge Client signal: defined in MPLS-TP Requirements E2E: End-to-End L2: Any layer 2 signal that may be carried over a PW, e.g., Ethernet H-LSP: Hierarchical LSP MEP: Maintenance Entity Group End Point MIP: Maintenance Entity Group Intermediate Point NNI: Network-to-Network Interface P: Provider PE: Provider Edge SP: Service Provider TE-RTG: GMPLS OSPF-TE or ISIS-TE Note: The MS-PW case is not shown.
While not shown in the figures above, the MPLS-TP control plane must support the addressing separation and independence between the data, control, and management planes. Address separation between the planes is already included in GMPLS. Such separation is also already included in LDP as LDP session end point addresses are never automatically associated with forwarding.
(page 9 continued on part 2)