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
|
|
|---|---|---|---|
| Last updated | 2015-10-14 | ||
| Replaces | draft-farrel-pce-vendor-constraints | ||
| Stream | IETF | ||
| Formats | plain text pdf html bibtex | ||
| Reviews | |||
| 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
Abstract
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
http://www.rfc-editor.org/info/rfc7150.
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
(http://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.
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
[RFC4655].
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
Show full document text