Tech-invite3GPPspaceIETF RFCsSIP
929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 6373

MPLS Transport Profile (MPLS-TP) Control Plane Framework

Pages: 57
Informational
Part 1 of 4 – Pages 1 to 9
None   None   Next

Top   ToC   RFC6373 - Page 1
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 Framework

Abstract

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.
Top   ToC   RFC6373 - Page 2
   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
Top   ToC   RFC6373 - Page 3
      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.
Top   ToC   RFC6373 - Page 4

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.
Top   ToC   RFC6373 - Page 5
      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.
Top   ToC   RFC6373 - Page 6
     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.
Top   ToC   RFC6373 - Page 7
       |< ---- 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.)
Top   ToC   RFC6373 - Page 8
       |< ------- 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.
Top   ToC   RFC6373 - Page 9
   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)

Next Section