Technical Summary
The computation of one or a set of Traffic Engineering Label
Switched Paths (TE LSPs) in MultiProtocol Label Switching (MPLS)
and Generalized MPLS (GMPLS) networks, is subject to a set of one
or more specific optimization criteria, referred to as objective
functions (e.g. minimum cost path, widest path, etc.).
In the Path Computation Element (PCE) architecture, a Path
Computation Client (PCC) may want a path to be computed for one or
more TE LSPs according to a specific objective function. Thus, the
PCC needs the ability to instruct the PCE to use the correct
objective function. Furthermore, it is possible that not all PCEs
support the same set of objective functions, therefore it is useful
for the PCC to be able to automatically discover the set of objective
functions supported by each PCE.
This document defines extensions to the PCE communication Protocol
(PCEP) to allow a PCE to indicate the set of objective functions it
supports. Extensions are also defined so that a PCC can indicate in
a path computation request the required objective function, and so
that a PCE can report in a path computation reply the objective
function that was used for path computation.
Working Group Summary
No controversy reported (see PROTO writeup by Adrian Farrel). The
I-D had a good level of review and discussion when it was first
introduced. However, the last year has been quiet and the working
group last call produced no comments. To be sure that there was
support, the working group was asked to provide explicit review
and approval. A number of participants responded supporting
publication.
Document Quality
A private survey has revealed several implementations of the
PCEP extensions defined in this document. Furthermore, there
are several further extensions in the pipeline that make use
of these extensions to enable new applications of PCE. The
document was updated in response to IETF last call comments.
Personnel
Adrian Farrel is the Document Shepherd for this document. Ross
Callon is the Responsible Area Director.
RFC Editor Note
Section 4., paragraph 7:
OLD
Objective Function Code: 2 (suggested value, to be assigned by IANA)
Name: Minimum Load Path (MLP)
Description: Find a path P such that
( Max {(R(Lpi) - r(Lpi) / R(Lpi), i=1...K } ) is minimized.
NEW
Objective Function Code: 2 (suggested value, to be assigned by IANA)
Name: Minimum Load Path (MLP)
Description: Find a path P such that
( Max {(R(Lpi) - r(Lpi)) / R(Lpi), i=1...K } ) is minimized.
Section 6.1
OLD
- Function code values 1 through 1023 are to be assigned by IANA
using the "IETF Consensus" policy.
NEW
- Function code values 1 through 1023 are to be assigned by IANA
using the "IETF Review" policy.
Section 6.1
OLD
Six objective functions are defined in Section 4 of this document
and should be assigned by IANA:
Code Point Name Defining RFC
NEW
Six objective functions are defined in Section 4 of this document
and should be assigned by IANA:
Code Point Name Reference