Tech-invite   3GPPspecs   Glossaries   IETFRFCs   Groups   SIP   ABNFs   Ti+   Search in Tech-invite

in Index   Prev   Next
in Index   Prev   Next  Group: PCE

RFC 8623

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

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

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