Conveying Vendor-Specific Constraints in the Path Computation Element Communication Protocol
RFC 7150

Document Type RFC - Proposed Standard (March 2014; No errata)
Obsoleted by RFC 7470
Authors Fatai Zhang  , Adrian Farrel 
Last updated 2018-12-20
Replaces draft-farrel-pce-vendor-constraints
Stream IETF
Formats plain text html pdf htmlized bibtex
Stream WG state Submitted to IESG for Publication
Document shepherd Julien Meuric
Shepherd write-up Show (last changed 2013-10-31)
IESG IESG state RFC 7150 (Proposed Standard)
Consensus Boilerplate Yes
Telechat date
Responsible AD Stewart Bryant
Send notices to (None)
IANA IANA review state IANA OK - Actions Needed
IANA action state RFC-Ed-Ack
Internet Engineering Task Force (IETF)                          F. Zhang
Request for Comments: 7150                                        Huawei
Category: Standards Track                                      A. Farrel
ISSN: 2070-1721                                         Juniper Networks
                                                              March 2014

           Conveying Vendor-Specific Constraints in the Path
               Computation Element Communication Protocol


   The Path Computation Element communication Protocol (PCEP) is used to
   convey path computation requests and responses both between Path
   Computation Clients (PCCs) and Path Computation Elements (PCEs) and
   between cooperating PCEs.  In PCEP, the path computation requests
   carry details of the constraints and objective functions that the PCC
   wishes the PCE to apply in its computation.

   This document defines a facility to carry vendor-specific information
   in PCEP using a dedicated object and a new Type-Length-Variable that
   can be carried in any existing PCEP object.

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 5741.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at

Zhang & Farrel               Standards Track                    [Page 1]
RFC 7150           Vendor-Specific Constraints in PCE         March 2014

Copyright Notice

   Copyright (c) 2014 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
   ( 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.

1.  Introduction

   A Path Computation Element (PCE) is an entity (component,
   application, or network node) that is capable of computing a network
   path or route based on a network graph and applying computational
   constraints.  An architecture for the use of PCEs is defined in

   The Path Computation Element communication Protocol (PCEP) is defined
   in [RFC5440] to exchange path computation requests and responses
   between Path Computation Clients (PCCs) and PCEs.  It is also used
   between cooperating PCEs.

   Path computations performed by a PCE depend on a set of constraints
   indicated by the PCC.  These constraints include the endpoints of the
   path to compute (source and destination) and may include other simple
   constraints such as bandwidth requirements and metric maxima (for
   example, a maximum threshold for the hop count or the Traffic
   Engineering (TE) metric of the computed path).

   The PCE also needs to use an objective function to qualify the path
   it selects as meeting the requirements of the PCC.  The PCE may have
   a default objective function, but the PCC can also indicate which
   objective function it wants applied by placing an Objective Function
   object in the path computation request message [RFC5541].  A core set
   of objective functions to be supported in PCEP messages is defined in
   the base PCEP requirements [RFC4657], and [RFC5541] defines each of
   these functions as an abstract formula.

   The registry of codepoints used to indicate objective functions is
   managed by IANA and new assignments can be made according to "IETF
   Review" and "First Come First Served" policies [RFC5226].  PCE
   implementations may also choose to offer proprietary, vendor-specific

Zhang & Farrel               Standards Track                    [Page 2]
RFC 7150           Vendor-Specific Constraints in PCE         March 2014

   objective functions, and there is scope for this within the codepoint
   registry created by [RFC5541] using the codepoints that are flagged
   as "Reserved for Private Use".

   Proprietary objective functions may operate on non-standard
   constraints or metrics.  The PCEP METRIC Object defined in [RFC5440]
   has scope for the definition of new, standardized metrics, but no
   facility for the definition of vendor-specific metrics.  At the same
   time, there is no mechanism in PCEP for carrying other, more complex,
   vendor-specific information.
Show full document text