Tech-invite  3GPPspecsRELsGlossariesSIPRFCs
8887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100

in Index   Prev   Next

RFC 8623

Stateful Path Computation Element (PCE) Protocol Extensions for Usage with Point-to-Multipoint TE Label Switched Paths (LSPs)

Pages: 33
Proposed Standard
Part 1 of 3 – Pages 1 to 10
None   None   Next

Top   ToC   RFC8623 - Page 1
Internet Engineering Task Force (IETF)                          U. Palle
Request for Comments: 8623                                      D. Dhody
Category: Standards Track                            Huawei Technologies
ISSN: 2070-1721                                                Y. Tanaka
                                                      NTT Communications
                                                               V. Beeram
                                                        Juniper Networks
                                                               June 2019


      Stateful Path Computation Element (PCE) Protocol Extensions
   for Usage with Point-to-Multipoint TE Label Switched Paths (LSPs)

Abstract

The Path Computation Element (PCE) has been identified as an appropriate technology for the determination of the paths of point- to-multipoint (P2MP) TE Label Switched Paths (LSPs). This document provides extensions required for the Path Computation Element Communication Protocol (PCEP) so as to enable the usage of a stateful PCE capability in supporting P2MP TE LSPs. Status of This Memo This is an Internet Standards Track document. 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). Further information on Internet Standards is available in Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8623.
Top   ToC   RFC8623 - Page 2
Copyright Notice

   Copyright (c) 2019 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
   (https://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. Requirements Language . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Supporting P2MP TE LSPs for Stateful PCE . . . . . . . . . . 4 3.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Objectives . . . . . . . . . . . . . . . . . . . . . . . 5 4. Functions to Support P2MP TE LSPs for Stateful PCEs . . . . . 5 5. Architectural Overview of Protocol Extensions . . . . . . . . 6 5.1. Extension of PCEP Messages . . . . . . . . . . . . . . . 6 5.2. Capability Advertisement . . . . . . . . . . . . . . . . 7 5.3. IGP Extensions for Stateful PCE P2MP Capabilities Advertisement . . . . . . . . . . . . . . . . . . . . . . 7 5.4. State Synchronization . . . . . . . . . . . . . . . . . . 8 5.5. LSP Delegation . . . . . . . . . . . . . . . . . . . . . 8 5.6. LSP Operations . . . . . . . . . . . . . . . . . . . . . 9 5.6.1. Passive Stateful PCE . . . . . . . . . . . . . . . . 9 5.6.2. Active Stateful PCE . . . . . . . . . . . . . . . . . 9 5.6.3. PCE-Initiated LSP . . . . . . . . . . . . . . . . . . 9 5.6.3.1. P2MP TE LSPs Instantiation . . . . . . . . . . . 9 5.6.3.2. P2MP TE LSPs Deletion . . . . . . . . . . . . . . 10 5.6.3.3. Adding and Pruning Leaves for the P2MP TE LSP . . 10 5.6.3.4. P2MP TE LSPs Delegation and Cleanup . . . . . . . 10 6. PCEP Message Extensions . . . . . . . . . . . . . . . . . . . 11 6.1. The PCRpt Message . . . . . . . . . . . . . . . . . . . . 11 6.2. The PCUpd Message . . . . . . . . . . . . . . . . . . . . 13 6.3. The PCReq Message . . . . . . . . . . . . . . . . . . . . 14 6.4. The PCRep Message . . . . . . . . . . . . . . . . . . . . 15 6.5. The PCInitiate Message . . . . . . . . . . . . . . . . . 16 6.6. Example . . . . . . . . . . . . . . . . . . . . . . . . . 17
Top   ToC   RFC8623 - Page 3
       6.6.1.  P2MP TE LSPs Update Request . . . . . . . . . . . . .  17
       6.6.2.  P2MP TE LSP Report  . . . . . . . . . . . . . . . . .  17
       6.6.3.  P2MP TE LSPs Initiation Request . . . . . . . . . . .  18
   7.  PCEP Object Extensions  . . . . . . . . . . . . . . . . . . .  19
     7.1.  LSP Object Extension  . . . . . . . . . . . . . . . . . .  19
       7.1.1.  P2MP-LSP-IDENTIFIERS TLV  . . . . . . . . . . . . . .  19
     7.2.  S2LS Object . . . . . . . . . . . . . . . . . . . . . . .  22
   8.  Message Fragmentation . . . . . . . . . . . . . . . . . . . .  23
     8.1.  Report Fragmentation Procedure  . . . . . . . . . . . . .  23
     8.2.  Update Fragmentation Procedure  . . . . . . . . . . . . .  23
     8.3.  PCInitiate Fragmentation Procedure  . . . . . . . . . . .  24
   9.  Nonsupport of P2MP TE LSPs for Stateful PCE . . . . . . . . .  24
   10. Manageability Considerations  . . . . . . . . . . . . . . . .  25
     10.1.  Control of Function and Policy . . . . . . . . . . . . .  25
     10.2.  Information and Data Models  . . . . . . . . . . . . . .  25
     10.3.  Liveness Detection and Monitoring  . . . . . . . . . . .  25
     10.4.  Verify Correct Operations  . . . . . . . . . . . . . . .  26
     10.5.  Requirements on Other Protocols  . . . . . . . . . . . .  26
     10.6.  Impact on Network Operations . . . . . . . . . . . . . .  26
   11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  26
     11.1.  PCE Capabilities in IGP Advertisements . . . . . . . . .  26
     11.2.  STATEFUL-PCE-CAPABILITY TLV  . . . . . . . . . . . . . .  26
     11.3.  LSP Object . . . . . . . . . . . . . . . . . . . . . . .  27
     11.4.  PCEP-ERROR Object  . . . . . . . . . . . . . . . . . . .  27
     11.5.  PCEP TLV Type Indicators . . . . . . . . . . . . . . . .  28
     11.6.  PCEP Object  . . . . . . . . . . . . . . . . . . . . . .  28
     11.7.  S2LS Object  . . . . . . . . . . . . . . . . . . . . . .  28
   12. Security Considerations . . . . . . . . . . . . . . . . . . .  29
   13. References  . . . . . . . . . . . . . . . . . . . . . . . . .  29
     13.1.  Normative References . . . . . . . . . . . . . . . . . .  29
     13.2.  Informative References . . . . . . . . . . . . . . . . .  31
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  32
   Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  32
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  33

1. Introduction

As per [RFC4655], the Path Computation Element (PCE) is an entity that is capable of computing a network path or route based on a network graph and applying computational constraints. A Path Computation Client (PCC) may make requests to a PCE for paths to be computed. [RFC4875] describes how to set up point-to-multipoint (P2MP) Traffic Engineering Label Switched Paths (TE LSPs) for use in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. [RFC5671] examines the applicability of PCE for the path computation for P2MP TE LSPs.
Top   ToC   RFC8623 - Page 4
   The PCEP is designed as a communication protocol between PCCs and
   PCEs for point-to-point (P2P) path computations and is defined in
   [RFC5440].  The extensions of PCEP to request path computation for
   P2MP TE LSPs are described in [RFC8306].

   Stateful PCEs are shown to be helpful in many application scenarios,
   in both MPLS and GMPLS networks, as illustrated in [RFC8051].  These
   scenarios apply equally to P2P and P2MP TE LSPs.  [RFC8231] provides
   the fundamental extensions to PCEP needed for stateful PCE to support
   general functionality for P2P TE LSP.  [RFC8281] provides extensions
   to PCEP needed for stateful PCE-initiated P2P TE LSP.  This document
   complements that work by focusing on PCEP extensions that are
   necessary in order for the deployment of stateful PCEs to support
   P2MP TE LSPs.  This document describes the setup, maintenance, and
   teardown of PCE-initiated P2MP LSPs under the stateful PCE model.

1.1. Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

2. Terminology

Terminology used in this document is the same as terminology used in [RFC8231], [RFC8281], and [RFC8306].

3. Supporting P2MP TE LSPs for Stateful PCE

3.1. Motivation

[RFC8051] presents several use cases, demonstrating scenarios that benefit from the deployment of a stateful PCE including optimization, recovery, etc., which are equally applicable to P2MP TE LSPs. [RFC8231] defines the extensions to PCEP needed for stateful operation of P2P TE LSPs. This document complements the previous work by focusing on extensions that are necessary in order for the deployment of stateful PCEs to support P2MP TE LSPs. In addition to that, the stateful nature of a PCE simplifies the information conveyed in PCEP messages since it is possible to refer to the LSPs via a PCEP-specific LSP identifier (PLSP-ID) ([RFC8231]). For P2MP, where the size of the message is much larger, this is an added advantage. When using a stateless PCE, a request to modify an existing P2MP tree requires that all the leaves are presented in the PCEP messages along with all the path information. But when using a
Top   ToC   RFC8623 - Page 5
   stateful PCE, the PCEP messages can use a PLSP-ID to represent all
   information about the LSP that has previously been exchanged in PCEP
   messages, and it is only necessary to encode the modifications (such
   as new or removed leaf nodes).  The PLSP-ID provides an index into
   the LSP-DB at the PCE and identifies the LSP at the PCC.

   In environments where the P2MP TE LSPs placement needs to change in
   response to application demands, it is useful to support dynamic
   creation and tear down of P2MP TE LSPs.  The ability for a PCE to
   trigger the creation of P2MP TE LSPs on demand can be seamlessly
   integrated into a controller-based network architecture where
   intelligence in the controller can determine when and where to set up
   paths.  Section 3 of [RFC8281] further describes the motivation
   behind the PCE-Initiation capability, which is equally applicable to
   P2MP TE LSPs.

3.2. Objectives

The objectives for the protocol extensions to support P2MP TE LSPs for stateful PCE are the same as the objectives described in Section 3.2 of [RFC8231].

4. Functions to Support P2MP TE LSPs for Stateful PCEs

[RFC8231] specifies new functions to support a stateful PCE. It also specifies that a function can be initiated either from a PCC towards a PCE (C-E) or from a PCE towards a PCC (E-C). This document extends these functions to support P2MP TE LSPs: Capability Advertisement (E-C,C-E): Both the PCC and the PCE must announce during PCEP session establishment that they support Stateful PCE extensions for P2MP using mechanisms defined in Section 5.2. LSP State Synchronization (C-E): After the session between the PCC and a stateful PCE with P2MP capability is initialized, the PCE must learn the state of a PCC's P2MP TE LSPs before it can perform path computations or update LSP attributes in a PCC. LSP Update Request (E-C): A stateful PCE with P2MP capability requests modification of attributes on a PCC's P2MP TE LSPs. LSP State Report (C-E): A PCC sends an LSP state report to a PCE whenever the state of a P2MP TE LSP changes.
Top   ToC   RFC8623 - Page 6
   LSP Control Delegation (C-E,E-C):  A PCC grants to a PCE the right to
      update LSP attributes on one or more P2MP TE LSPs; the PCE becomes
      the authoritative source of the LSP's attributes as long as the
      delegation is in effect (See Section 5.7 of [RFC8231]); the PCC
      may withdraw the delegation or the PCE may give up the delegation
      at any time.

   PCE-initiated LSP instantiation (E-C):  A PCE sends an LSP Initiate
      Message to a PCC to instantiate or delete a P2MP TE LSP [RFC8281].

5. Architectural Overview of Protocol Extensions

5.1. Extension of PCEP Messages

Two new PCEP messages are defined in [RFC8231] to support stateful PCE for P2P TE LSPs. In this document, these messages are extended as follows to support P2MP TE LSPs. Path Computation State Report (PCRpt): Each P2MP TE LSP State Report in a PCRpt message contains the actual P2MP TE LSP path attributes, the LSP status, etc. An LSP State Report carried in a PCRpt message is also used in delegation or revocation of control of a P2MP TE LSP to/from a PCE. The extension of PCRpt messages is described in Section 6.1. Path Computation Update Request (PCUpd): Each P2MP TE LSP Update Request in a PCUpd message MUST contain all LSP parameters that a PCE wishes to set for a given P2MP TE LSP. An LSP Update Request carried in a PCUpd message is also used to return LSP delegations if at any point the PCE no longer desires control of a P2MP TE LSP. The PCUpd message is described in Section 6.2. Further, a new PCEP message is defined in [RFC8281] to support stateful PCE instantiation of P2P TE LSPs. In this document, this message is extended as follows to support P2MP TE LSPs. Path Computation LSP Initiate Message (PCInitiate): PCInitiate is a PCEP message sent by a PCE to a PCC to trigger the instantiation or deletion of a P2MP TE LSP. The PCInitiate message is described in Section 6.5. The Path Computation Request (PCReq) and Path Computation Reply (PCRep) messages are also extended to support passive stateful PCE for P2P TE LSPs in [RFC8231]. In this document, these messages are extended to support P2MP TE LSPs as well.
Top   ToC   RFC8623 - Page 7

5.2. Capability Advertisement

During the PCEP initialization phase, as per Section 7.1.1 of [RFC8231], PCEP speakers advertise Stateful capability via the STATEFUL-PCE-CAPABILITY TLV in the OPEN object. Various flags are defined for the STATEFUL-PCE-CAPABILITY TLV defined in [RFC8231] and updated in [RFC8281] and [RFC8232]. Three new flags, N (P2MP-CAPABILITY), M (P2MP-LSP-UPDATE-CAPABILITY), and P (P2MP-LSP-INSTANTIATION-CAPABILITY), are added in this document: N (P2MP-CAPABILITY flag - 1 bit): If set to 1 by a PCC, the N Flag indicates that the PCC is willing to send P2MP LSP State Reports whenever there's a change to the parameters or operational status of the P2MP LSP; if set to 1 by a PCE, the N Flag indicates that the PCE is interested in receiving LSP State Reports whenever there is a parameter or operational status change to the P2MP LSP. The P2MP-CAPABILITY Flag MUST be advertised by both a PCC and a PCE for the P2MP extension (as per this document) of the PCRpt messages to be allowed on a PCEP session. M (P2MP-LSP-UPDATE-CAPABILITY flag - 1 bit): If set to 1 by a PCC, the M Flag indicates that the PCC allows modification of P2MP LSP parameters; if set to 1 by a PCE, the M Flag indicates that the PCE is capable of updating P2MP LSP parameters. The P2MP-LSP- UPDATE-CAPABILITY Flag MUST be advertised by both a PCC and a PCE for the P2MP extension (as per this document) of the PCUpd messages to be allowed on a PCEP session. P (P2MP-LSP-INSTANTIATION-CAPABILITY flag - 1 bit): If set to 1 by a PCC, the P Flag indicates that the PCC allows instantiation of a P2MP LSP by a PCE. If set to 1 by a PCE, the P flag indicates that the PCE supports P2MP LSP instantiation. The P2MP-LSP- INSTANTIATION-CAPABILITY flag MUST be set by both PCC and PCE in order to support PCE-initiated P2MP LSP instantiation. A PCEP speaker should continue to advertise the basic P2MP capability via mechanisms as described in [RFC8306].

5.3. IGP Extensions for Stateful PCE P2MP Capabilities Advertisement

When the PCC is a Label Switching Router (LSR) participating in the IGP (either OSPF or IS-IS), and PCEs are either LSRs or servers also participating in the IGP, an effective mechanism for PCE discovery within an IGP routing domain consists of utilizing IGP
Top   ToC   RFC8623 - Page 8
   advertisements.  Extensions for the advertisement of PCE discovery
   information are defined for OSPF and for IS-IS in [RFC5088] and
   [RFC5089], respectively.

   The PCE-CAP-FLAGS sub-TLV, defined in [RFC5089], is an optional sub-
   TLV used to advertise PCE capabilities.  It MAY be present within the
   PCE Discovery (PCED) TLV carried by OSPF or IS-IS.  [RFC5088] and
   [RFC5089] provide the description and processing rules for this sub-
   TLV when carried within OSPF and IS-IS, respectively.

   The format of the PCE-CAP-FLAGS sub-TLV is included below for easy
   reference:

   Type: 5

   Length: Multiple of 4

   Value: This contains an array of units of 32-bit flags with the most
   significant bit as 0.  Each bit represents one PCE capability.

   PCE capability bit flags are defined in [RFC5088].  This document
   defines new capability bits for the stateful PCE with P2MP as
   follows:

               Bit                  Capability
               13                   Active Stateful PCE with P2MP
               14                   Passive Stateful PCE with P2MP
               15                   PCE-Initiation with P2MP

   Note that, while active, passive, or initiation stateful PCE
   capabilities for P2MP may be advertised during discovery, PCEP
   Speakers that wish to use stateful PCEP for P2MP TE LSPs MUST
   advertise stateful PCEP capabilities during PCEP session setup, as
   specified in the current document.  A PCC MAY initiate stateful PCEP
   P2MP capability advertisement at PCEP session setup even if it did
   not receive any IGP PCE capability advertisements.

5.4. State Synchronization

State Synchronization operations (described in Section 5.6 of [RFC8231]) are applicable for the P2MP TE LSPs as well. The optimizations described in [RFC8232] can also be applied for P2MP TE LSPs.

5.5. LSP Delegation

LSP delegation operations (described in Section 5.7 of [RFC8231]) are applicable for P2MP TE LSPs as well.
Top   ToC   RFC8623 - Page 9

5.6. LSP Operations

5.6.1. Passive Stateful PCE

LSP operations for passive stateful PCE (described in Section 5.8.1 of [RFC8231]) are applicable for P2MP TE LSPs as well. The PCReq and PCRep message format for P2MP TE LSPs is described in Sections 3.4 and 3.5 of [RFC8306], respectively. The PCReq and PCRep message for P2MP TE LSPs are extended to support encoding of the LSP object so that it is possible to refer to an LSP with a unique identifier and simplify the PCEP message exchange. For example, in case of modification of one leaf in a P2MP tree, there should be no need to carry the full P2MP tree in a PCReq message. The extensions for the Request and Response message for passive stateful operations on P2MP TE LSPs are described in Sections 6.3 and 6.4. The extension for the Path Computation LSP State Report (PCRpt) message is described in Section 6.1.

5.6.2. Active Stateful PCE

LSP operations for active stateful PCE (described in Section 5.8.2 of [RFC8231]) are applicable for P2MP TE LSPs as well. The extension for the Path Computation LSP Update (PCUpd) message for active stateful operations on P2MP TE LSPs is described in Section 6.2.

5.6.3. PCE-Initiated LSP

As per Section 5.1 of [RFC8281], the PCE sends a Path Computation LSP Initiate Request (PCInitiate) message to the PCC to suggest instantiation or deletion of a P2P TE LSP. This document extends the PCInitiate message to support P2MP TE LSPs (see details in Section 6.5). The instantiation and deletion operations for P2MP TE LSPs are the same as for P2P LSPs as described in Sections 5.3 and 5.4 of [RFC8281].
5.6.3.1. P2MP TE LSPs Instantiation
The instantiation operation of P2MP TE LSPs is the same as the LSP instantiation operation defined in Section 5.3 of [RFC8281]; this includes the handling of the PLSP-ID, SYMBOLIC-PATH-NAME TLV, etc. The processing rules and use of error codes remain unchanged. The N
Top   ToC   RFC8623 - Page 10
   (P2MP) flag (Section 7.1) MUST be set in the LSP object in the
   PCInitiate message by the PCE to specify that the instantiation is
   for P2MP TE LSPs.  Like the PLSP-ID (as per [RFC8281]), the P2MP-LSP-
   IDENTIFIERS TLV SHOULD NOT be included in the LSP object in
   PCInitiate messages and MUST be ignored on receipt.  These
   identifiers are generated by the PCC on receipt of the PCInitiate
   message and reported via a PCRpt message to the PCE.

5.6.3.2. P2MP TE LSPs Deletion
The deletion operation of P2MP TE LSPs is the same as the LSP deletion operation defined in Section 5.4 of [RFC8281]; this entails sending an LSP Initiate Message with an LSP object carrying the PLSP- ID of the LSP to be removed as well as a Stateful PCE Request Parameter (SRP) object with the R flag set (LSP-REMOVE as per Section 5.2 of [RFC8281]). The processing rules and error codes remain unchanged.
5.6.3.3. Adding and Pruning Leaves for the P2MP TE LSP
The adding of new leaves and pruning of old leaves for the PCE- initiated P2MP TE LSP MUST be carried in a PCUpd message as per Section 6.2 for P2MP TE LSP extensions. As defined in [RFC8306], leaf type = 1 is used for adding new leaves, and leaf type = 2 is used for pruning old leaves of P2MP END-POINTS Objects. PCC MAY use the Incremental State Update mechanism as described in [RFC4875] to signal the adding and pruning of leaves. Section 3.10 of [RFC8306] defines the error-handling procedures when adding new leaves to or removing old leaves from the existing P2MP tree for PCReq messages. The same error handling and error codes are also applicable to the stateful PCE messages as described in this document.
5.6.3.4. P2MP TE LSPs Delegation and Cleanup
P2MP TE LSPs delegation and cleanup operations are the same as the LSP delegation and cleanup operations defined in Section 6 of [RFC8281]. The processing rules and error codes remain unchanged.


(next page on part 2)

Next Section