tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search     info

RFC 6373

Informational
Pages: 57
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: CCAMP

MPLS Transport Profile (MPLS-TP) Control Plane Framework

Part 1 of 4, p. 1 to 9
None       Next RFC Part

 


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

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       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       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       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       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       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       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       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 RFC Part