Network Working Group JL. Le Roux
Request for Comments: 5541 France Telecom
Category: Standards Track JP. Vasseur
Cisco System Inc.
Y. Lee
Huawei
June 2009
Encoding of Objective Functions in the
Path Computation Element Communication Protocol (PCEP)
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (c) 2009 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 (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Le Roux, et al. Standards Track [Page 1]
RFC 5541 Objective Functions in PCEP June 2009
Abstract
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 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 a PCE
can report in a path computation reply the objective function that
was used for path computation.
This document defines objective function code types for six objective
functions previously listed in the PCE requirements work, and
provides the definition of four new metric types that apply to a set
of synchronized requests.
Le Roux, et al. Standards Track [Page 2]
RFC 5541 Objective Functions in PCEP June 2009
Table of Contents
1. Introduction ....................................................3
1.1. Conventions Used in This Document ..........................5
1.2. Terminology ................................................5
1.3. Message Formats ............................................6
2. Discovery of PCE Objective Functions ............................6
2.1. OF-List TLV ................................................6
2.2. Elements of Procedure ......................................7
3. Objective Function in PCEP Path Computation Request and Reply
Messages ........................................................7
3.1. OF Object ..................................................7
3.1.1. Elements of Procedure ...............................8
3.2. Carrying The OF Object In a PCEP Message ...................9
3.3. New RP Object Flag ........................................12
3.3.1. Elements Of Procedure ..............................12
4. Objective Functions Definition .................................13
5. New Metric Types ...............................................14
6. IANA Considerations ............................................15
6.1. PCE Objective Function Sub-Registry .......................15
6.2. PCEP Code Points ..........................................16
6.2.1. OF Object ..........................................16
6.2.2. OF-List TLV ........................................16
6.2.3. PCEP Error Values ..................................16
6.2.4. RP Object Flag .....................................17
6.2.5. Metric Types .......................................17
7. Security Considerations ........................................17
8. Manageability Considerations ...................................18
8.1. Control of Function and Policy ............................18
8.2. Information and Data Models ...............................18
8.3. Liveness Detection and Monitoring .........................18
8.4. Verify Correct Operations .................................18
8.5. Requirements On Other Protocols ...........................19
8.6. Impact On Network Operations ..............................19
9. Acknowledgments ................................................19
10. References ....................................................19
10.1. Normative References .....................................19
10.2. Informative References ...................................19
Appendix A. RBNF Code Fragments ...................................21
1. Introduction
The Path Computation Element-based network architecture [RFC4655]
defines a Path Computation Element (PCE) as an entity capable of
computing the paths of Traffic Engineered Label Switched Paths (TE
LSPs) based on a network graph and of applying computational
constraints. A PCE services path computation requests that are sent
by Path Computation Clients (PCC).
Le Roux, et al. Standards Track [Page 3]
RFC 5541 Objective Functions in PCEP June 2009
The PCE communication Protocol (PCEP), defined in [RFC5440], allows
for communication between a PCC and a PCE or between two PCEs, in
compliance with requirements and guidelines set forth in [RFC4657].
Such interactions include path computation requests and path
computation replies.
The computation of one or a set of TE LSPs is subject to a set of one
or more optimization criteria, called an objective function. An
objective function is used by the PCE when it computes a path or a
set of paths in order to select the "best" candidate paths. There is
a variety of objective functions: an objective function could apply
either to a set of non-synchronized path computation requests, or to
a set of synchronized path computation requests. In the former case,
the objective function refers to an individual path computation
request (e.g., computation of the shortest constrained path where the
metric is the IGP metric, computation of the least loaded constrained
path, etc.). Conversely, in the latter case, the objective function
refers to a set of path computation requests the computation of which
is synchronized (e.g., minimize the aggregate bandwidth consumption
of all LSPs, minimize the sum of the delays for two diverse paths or
of the delta between those delays, etc.). Moreover, some objective
functions relate to the optimization of a single metric and others to
the optimization of a set of metrics (organized in a hierarchical
manner, using a weighted function, etc.).
As spelled out in [RFC4674], it may be useful for a PCC to discover
the set of objective functions supported by a PCE. Furthermore,
[RFC4657] requires the ability for a PCC to indicate in a path
computation request a required/desired objective function, as well as
optional function parameters.
For these purposes, this document extends the PCE communication
Protocol (PCEP). It defines PCEP extensions that allow a PCE to
advertise a list of supported objective functions, as well as
extensions to carry the objective function in PCEP request and reply
messages. It complements the PCEP base specification [RFC5440].
Note that OSPF- and IS-IS-based PCE discovery mechanisms are defined
in [RFC5088] and [RFC5089]. These mechanisms are dedicated to the
discovery of a few generic parameters, while more detailed PCE
parameters should be discovered using the PCE communication Protocol.
Objective functions are in this second category; thus, the objective
function discovery procedure is handled by PCEP.
A new PCEP TLV, named the OF-List TLV, is defined in Section 2. The
OF-List TLV is carried in the PCEP OPEN object and allows a PCE to
list, during PCEP session-setup phase, the objective functions that
it supports.
Le Roux, et al. Standards Track [Page 4]
RFC 5541 Objective Functions in PCEP June 2009
A new PCEP object, the OF object, is defined in Section 3. The OF
object is carried within a PCReq (Path Computation Request) message
to indicate the required/desired objective function to be applied by
a PCE, or in a PCRep (Path Computation Reply) message to indicate the
objective function that was used for path computation.
Six mandatory objective functions that must be supported by PCEP are
listed in [RFC4657]. This document provides a definition of these
six mandatory objective functions. Additional objective functions
may be defined in other documents. Note that additional objective
functions are defined for the PCE Global Concurrent Optimization
(GCO) application, in [PCE-GCO].
This document also provides the definition of four new metric types
that apply to a set of synchronized requests.
1.1. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
1.2. Terminology
LSR: Label Switching Router.
OF: Objective Function. A set of one or more optimization
criteria used for the computation of a single path (e.g.,
path cost minimization) or for the synchronized computation
of a set of paths (e.g., aggregate bandwidth consumption
minimization, etc.).
PCC: Path Computation Client. Any client application requesting a
path computation to be performed by a Path Computation
Element.
PCE: Path Computation Element. An entity (component, application,
or network node) that is capable of computing a network path
or route based on a network graph and of applying
computational constraints.
PCEP: Path Computation Element communication Protocol.
TE LSP: Traffic Engineered Label Switched Path.
Le Roux, et al. Standards Track [Page 5]
RFC 5541 Objective Functions in PCEP June 2009
1.3. Message Formats
Message formats in this document are expressed using Reduced BNF as
used in [RFC5440] and defined in [RFC5511].
2. Discovery of PCE Objective Functions
This section defines PCEP extensions (see [RFC5440]) so as to support
the advertisement of the objective functions supported by a PCE.
A new PCEP OF-List (Objective Function list) TLV is defined. The
PCEP OF-List TLV is carried within an OPEN object. This way, during
PCEP session-setup phase, a PCE can advertise to a PCEP peer the list
of objective functions it supports.
2.1. OF-List TLV
The PCEP OF-List TLV is optional. It MAY be carried within an OPEN
object sent by a PCE in an Open message to a PCEP peer so as to
indicate the list of supported objective functions.
The OF-List TLV format is compliant with the PCEP TLV format defined
in [RFC5440]. That is, the TLV is composed of 2 octets for the type,
2 octets specifying the TLV length, and a Value field. The Length
field defines the length of the value portion in octets. The TLV is
padded to 4-octet alignment, and padding is not included in the
Length field (e.g., a 3-octet value would have a length of three, but
the total size of the TLV would be eight octets).
The PCEP OF-List TLV has the following format:
TYPE: 4
LENGTH: N * 2 (where N is the number of objective functions)
VALUE: list of 2-byte objective function code points, identifying
the objective functions supported by the sender of the Open
message.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OF Code #1 | OF Code #2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OF Code #N | padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Le Roux, et al. Standards Track [Page 6]
RFC 5541 Objective Functions in PCEP June 2009
OF Code (2 bytes): Objective Function code point identifier. IANA
manages the "PCE Objective Function" code point registry (see Section
6).
2.2. Elements of Procedure
A PCE MAY include an OF-List TLV within an OPEN object in an Open
message sent to a PCEP peer in order to advertise a set of one or
more objective functions. The OF-List TLV MUST NOT appear more than
once in an OPEN object. If it appears more than once, the PCEP
session MUST be rejected with error type 1 and error value 1 (PCEP
session establishment failure / Reception of an invalid Open
message). The absence of the OF-List TLV in an OPEN object MUST be
interpreted as an absence of information on the list of supported
objective functions by the PCE.
As specified in [RFC5440], a PCEP peer that does not recognize the
OF-List TLV will silently ignore it.
3. Objective Function in PCEP Path Computation Request and Reply
Messages
This section defines PCEP extensions [RFC5440] so as to support the
communication of objective functions in PCEP path computation request
and reply messages. A new PCEP OF (Objective Function) object is
defined, to be carried within a PCReq message in order for the PCC to
indicate the required/desired objective function.
The PCEP OF object may also be carried within a PCRep message in
order for the PCE to indicate the objective function that was used by
the PCE.
A new flag is defined in the RP (Request Parameters) object. The
flag is used in a PCReq message to indicate that the PCE MUST include
an OF object in the PCRep message to indicate the objective function
that was used during path computation.
Also, new PCEP error types and values are defined.
3.1. OF Object
The PCEP OF (Objective Function) object is optional. It MAY be
carried within a PCReq message so as to indicate the desired/required
objective function to be applied by the PCE during path computation
or within a PCRep message so as to indicate the objective function
that was used by the PCE during path computation.
Le Roux, et al. Standards Track [Page 7]
RFC 5541 Objective Functions in PCEP June 2009
The OF object format is compliant with the PCEP object format defined
in [RFC5440].
The OF Object-Class is 21.
The OF Object-Type is 1.
The format of the OF object body is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OF Code | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Optional TLV(s) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
OF Code (2 bytes): The identifier of the objective function. IANA
manages the "PCE Objective Function" code point registry (see Section
6).
Reserved (2 bytes): This field MUST be set to zero on transmission
and MUST be ignored on receipt.
Optional TLVs may be defined in the future so as to encode objective
function parameters.
3.1.1. Elements of Procedure
To request the use of a specific objective function by the PCE, a PCC
includes an OF object in the PCReq message.
[RFC5440] specifies a bit flag, referred to as the P bit, carried in
the common PCEP object header. The P bit is set by a PCC to mandate
that a PCE must take the information carried in the object into
account during the path computation.
If the P bit is set in the OF object, the objective function is
mandatory (required objective function) and the PCE MUST use the
objective function during path computation. If the P bit is clear in
the OF object, the objective function is optional (desired objective
function) and the PCE SHOULD apply the function if it is supported
but MAY choose to apply a different objective function, according to
local capabilities and policies.
Le Roux, et al. Standards Track [Page 8]
RFC 5541 Objective Functions in PCEP June 2009
On receipt of a PCReq message with an OF object, a PCE MUST proceed
as follows:
- If the OF object is unknown/unsupported, the PCE MUST follow
procedures defined in [RFC5440]. That is, if the P bit is set, the
PCE sends a PCErr message with error type 3 or 4 (Unknown / Not
supported object) and error value 1 or 2 (unknown / unsupported
object class / object type), and the related path computation
request MUST be discarded. If the P bit is cleared, the PCE is
free to ignore the object.
- If the objective function is unknown/unsupported and the P bit is
set, the PCE MUST send a PCErr message with error type 3 or 4
(Unknown / Not supported object) and error value 4
(Unrecognized/Unsupported parameter), and the related path
computation request MUST be discarded.
- If the objective function is unknown/unsupported and the P bit is
cleared, the PCE SHOULD apply another (default) objective function.
- If the objective function is supported but policy does not permit
applying it and if the P bit is set, the PCE MUST send a PCErr
message with the PCEP error type "policy-violation" (type 5) and a
new error value, "objective function not allowed", which is defined
in this document.
- If the objective function is supported but policy does not allow
applying it and if the P bit is cleared, the PCE SHOULD apply
another (default) objective function.
- If the objective function is supported and policy allows applying
it and if the P bit is set, the PCE MUST apply the requested
objective function. Otherwise, if the P bit is cleared, the PCE is
free to apply any other objective function.
The default objective function may be locally configured.
3.2. Carrying The OF Object In a PCEP Message
The OF object MAY be carried within a PCReq message. If an objective
function is to be applied to a set of synchronized path computation
requests, the OF object MUST be carried just after the corresponding
SVEC (Synchronization VECtor) object and MUST NOT be repeated for
each elementary request.
Le Roux, et al. Standards Track [Page 9]
RFC 5541 Objective Functions in PCEP June 2009
Similarly, if a metric is to be applied to a set of synchronized
requests, the METRIC object MUST follow the SVEC object and MUST NOT
be repeated for each elementary request. Note that metrics applied
to a set of synchronized requests are defined in Section 5.
An OF object specifying an objective function that applies to an
individual path computation request (non-synchronized case) MUST
follow the RP object for which it applies.
The format of the PCReq message is updated as follows. Please see
Appendix A for a full set of RBNF fragments defined in this document
and the necessary code license.
::=
[]
where:
::=
[]
[]
[]
::= []
::=
RFC, FYI, BCP