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

The information below is for an old version of the document
Document Type Active Internet-Draft (individual)
Last updated 2014-07-21
Replaced by draft-ietf-pce-rfc7150bis, rfc7470
Stream (None)
Intended RFC status (None)
Formats pdf htmlized bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                       Fatai Zhang
Internet-Draft                                                   Huawei
Intended status: Standards Track                              A. Farrel
Obsoletes: 7150 (if approved)                          Juniper Networks

Expires: January 21, 2015                                 July 21, 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.

   This document obsoletes RFC 7150.  The only change from that document
   is the allocation of a different code point for the

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that other
   groups may also distribute working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at

Farrel & Zhang             Expires January 2015                [Page 1]
draft-farrel-pce-rfc7150bis-00.txt                            July 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

Farrel & Zhang             Expires January 2015                [Page 2]
draft-farrel-pce-rfc7150bis-00.txt                            July 2014

   objective functions, and there is scope for this within the codepoint
Show full document text