Conveying Vendor-Specific Constraints in the Path Computation Element Protocol

The information below is for an old version of the document
Document Type Active Internet-Draft (pce WG)
Last updated 2013-04-16
Replaces draft-farrel-pce-vendor-constraints
Stream IETF
Intended RFC status (None)
Formats plain text pdf html bibtex
Stream WG state WG Document
Document shepherd None
IESG IESG state I-D Exists
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                       Fatai Zhang
Internet-Draft                                                   Huawei
Intended status: Standards Track                              A. Farrel
                                                       Juniper Networks

Expires: October 16, 2013                                April 16, 2013

            Conveying Vendor-Specific Constraints in the Path
                      Computation Element Protocol



   The Path Computation Element Protocol (PCEP) is used to convey path
   computation requests and responses between Path Computation Clients
   (PCCs) and Path Computation Elements (PCEs), and also 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.

   The mechanisms defined for indicating objective functions include
   the capability to convey vendor-specific objective functions. This
   document defines a facility to carry vendor-specific constraints in

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 October 2013                 [Page 1]
draft-ietf-pce-vendor-constraints-09.txt                     April 2013

Copyright Notice

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

Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC-2119 [RFC2119].

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 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 end points 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 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

Farrel & Zhang            Expires October 2013                 [Page 2]
draft-ietf-pce-vendor-constraints-09.txt                     April 2013

   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
Show full document text