draft-ietf-pce-of-06.txt   rfc5541.txt 
Network Working Group J.L. Le Roux
Internet Draft France Telecom
Category: Standard Track
Created: December 27, 2008 J.P. Vasseur
Expires: June 27, 2009 Cisco System Inc.
Network Working Group JL. Le Roux
Request for Comments: 5541 France Telecom
Category: Standards Track JP. Vasseur
Cisco System Inc.
Y. Lee Y. Lee
Huawei Huawei
Encoding of Objective Functions in the
Path Computation Element Communication Protocol (PCEP)
Encoding of Objective Functions in the Path Computation Element Status of This Memo
Communication Protocol (PCEP)
draft-ietf-pce-of-06.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with This document specifies an Internet standards track protocol for the
the provisions of BCP 78 and BCP 79. 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.
Internet-Drafts are working documents of the Internet Engineering Copyright Notice
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 Copyright (c) 2009 IETF Trust and the persons identified as the
and may be updated, replaced, or obsoleted by other documents at any document authors. All rights reserved.
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 This document is subject to BCP 78 and the IETF Trust's Legal
http://www.ietf.org/ietf/1id-abstracts.txt. 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.
The list of Internet-Draft Shadow Directories can be accessed at This document may contain material from IETF Documents or IETF
http://www.ietf.org/shadow.html. 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.
Abstract Abstract
The computation of one or a set of Traffic Engineering Label Switched The computation of one or a set of Traffic Engineering Label Switched
Paths (TE LSPs) in MultiProtocol Label Switching (MPLS) and Paths (TE LSPs) in MultiProtocol Label Switching (MPLS) and
Generalized MPLS (GMPLS) networks, is subject to a set of one or more Generalized MPLS (GMPLS) networks is subject to a set of one or more
specific optimization criteria, referred to as objective functions specific optimization criteria, referred to as objective functions
(e.g. minimum cost path, widest path, etc.). (e.g., minimum cost path, widest path, etc.).
In the Path Computation Element (PCE) architecture, a Path In the Path Computation Element (PCE) architecture, a Path
Computation Client (PCC) may want a path to be computed for one or Computation Client (PCC) may want a path to be computed for one or
more TE LSPs according to a specific objective function. Thus, the more TE LSPs according to a specific objective function. Thus, the
PCC needs to instruct the PCE to use the correct objective function. 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 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 objective functions; therefore, it is useful for the PCC to be able
automatically discover the set of objective functions supported by to automatically discover the set of objective functions supported by
each PCE. each PCE.
This document defines extensions to the PCE communication Protocol This document defines extensions to the PCE communication Protocol
(PCEP) to allow a PCE to indicate the set of objective functions it (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 supports. Extensions are also defined so that a PCC can indicate in
a path computation request the required objective function, and so a path computation request the required objective function, and a PCE
that a PCE can report in a path computation reply the objective can report in a path computation reply the objective function that
function that was used for path computation. was used for path computation.
This document defines objective function code types for six This document defines objective function code types for six objective
objective functions previously listed in the PCE requirments work, functions previously listed in the PCE requirements work, and
and provides the definition of four new metric types that apply to a provides the definition of four new metric types that apply to a set
set of synchronized requests. of synchronized requests.
Table of Contents Table of Contents
1. Introduction................................................3 1. Introduction ....................................................3
1.1. Terminology.................................................4 1.1. Conventions Used in This Document ..........................5
1.2. Message Formats.............................................5 1.2. Terminology ................................................5
2. Discovery of PCE Objective Functions........................5 1.3. Message Formats ............................................6
2.1. OF-List TLV.................................................5 2. Discovery of PCE Objective Functions ............................6
2.2. Elements of procedure.......................................6 2.1. OF-List TLV ................................................6
3. Objective Function in PCEP Path Computation Request and 2.2. Elements of Procedure ......................................7
Reply Messages............................................6 3. Objective Function in PCEP Path Computation Request and Reply
3.1. OF Object...................................................6 Messages ........................................................7
3.1.1. Elements of Procedure.......................................7 3.1. OF Object ..................................................7
3.2. Carrying The OF Object In a PCEP Message....................8 3.1.1. Elements of Procedure ...............................8
3.3. New RP Object Flag.........................................10 3.2. Carrying The OF Object In a PCEP Message ...................9
3.3.1. Elements Of Procedure......................................10 3.3. New RP Object Flag ........................................12
4. Objective Functions Definition.............................11 3.3.1. Elements Of Procedure ..............................12
5. New Metric Types...........................................12 4. Objective Functions Definition .................................13
6. IANA Considerations........................................13 5. New Metric Types ...............................................14
6.1. PCE Objective Function Sub-registry........................13 6. IANA Considerations ............................................15
6.2. PCEP Code Points...........................................14 6.1. PCE Objective Function Sub-Registry .......................15
6.2.1. OF Object..................................................14 6.2. PCEP Code Points ..........................................16
6.2.2. OF-List TLV................................................14 6.2.1. OF Object ..........................................16
6.2.3. PCEP Error values..........................................15 6.2.2. OF-List TLV ........................................16
6.2.4. RP Object Flag.............................................15 6.2.3. PCEP Error Values ..................................16
6.2.5. Metric Types...............................................15 6.2.4. RP Object Flag .....................................17
7. Security Considerations....................................16 6.2.5. Metric Types .......................................17
8. Manageability Considerations...............................16 7. Security Considerations ........................................17
8.1. Control of Function and Policy.............................16 8. Manageability Considerations ...................................18
8.2. Information and Data Models................................16 8.1. Control of Function and Policy ............................18
8.3. Liveness Detection and Monitoring..........................16 8.2. Information and Data Models ...............................18
8.4. Verify Correct Operations..................................17 8.3. Liveness Detection and Monitoring .........................18
8.5. Requirements On Other Protocols............................17 8.4. Verify Correct Operations .................................18
8.6. Impact On Network Operations...............................17 8.5. Requirements On Other Protocols ...........................19
9. Acknowledgments............................................17 8.6. Impact On Network Operations ..............................19
10. References.................................................17 9. Acknowledgments ................................................19
10.1. Normative Feferences.......................................17 10. References ....................................................19
10.2. Informative References.....................................17 10.1. Normative References .....................................19
11. Authors' Addresses.........................................18 10.2. Informative References ...................................19
Appendix A. RBNF Code Fragments ...................................21
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. Introduction 1. Introduction
The Path Computation Element-based network architecture [RFC4655] The Path Computation Element-based network architecture [RFC4655]
defines a Path Computation Element (PCE) as an entity capable of defines a Path Computation Element (PCE) as an entity capable of
computing the paths of Traffic Engineered Label Switched Paths (TE computing the paths of Traffic Engineered Label Switched Paths (TE
LSPs) based on a network graph, and applying computational LSPs) based on a network graph and of applying computational
constraints. A PCE services path computation requests sent by Path constraints. A PCE services path computation requests that are sent
Computation Clients (PCC). by Path Computation Clients (PCC).
The PCE communication Protocol (PCEP), defined in [PCEP], allows for The PCE communication Protocol (PCEP), defined in [RFC5440], allows
communication between a PCC and a PCE or between two PCEs, in for communication between a PCC and a PCE or between two PCEs, in
compliance with requirements and guidelines set forth in [RFC4657]. compliance with requirements and guidelines set forth in [RFC4657].
Such interactions include path computation requests and path Such interactions include path computation requests and path
computation replies. computation replies.
The computation of one or a set of TE LSPs is subject to a set of one 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 or more optimization criteria, called an objective function. An
objective function is used by the PCE, when it computes a path or a 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 set of paths in order to select the "best" candidate paths. There is
a variety of objective functions: an objective function could apply a variety of objective functions: an objective function could apply
either to a set of non-synchronized path computation requests, or to either to a set of non-synchronized path computation requests, or to
a set of synchronized path computation requests. In the former case, a set of synchronized path computation requests. In the former case,
the objective function refers to an individual path computation the objective function refers to an individual path computation
request (e.g. computation of the shortest constrained path where the request (e.g., computation of the shortest constrained path where the
metric is the IGP metric, computation of the least loaded constrained metric is the IGP metric, computation of the least loaded constrained
path, etc.). Conversely in the latter case, the objective function path, etc.). Conversely, in the latter case, the objective function
refers to a set of path computation requests the computation of which refers to a set of path computation requests the computation of which
is synchronized (e.g., minimize the aggregate bandwidth consumption is synchronized (e.g., minimize the aggregate bandwidth consumption
of all LSPs, minimize the sum of the delays for two diverse paths, or of all LSPs, minimize the sum of the delays for two diverse paths or
the delta between those delays, etc.). Moreover, some objective of the delta between those delays, etc.). Moreover, some objective
functions relate to the optimization of a single metric and others to functions relate to the optimization of a single metric and others to
the optimization of a set of metrics (organized in a hierarchical the optimization of a set of metrics (organized in a hierarchical
manner, using a weighted function, etc.). manner, using a weighted function, etc.).
As spelled out in [RFC4674], it may be useful for a PCC to discover As spelled out in [RFC4674], it may be useful for a PCC to discover
the set of objective functions supported by a PCE. Furthermore, the set of objective functions supported by a PCE. Furthermore,
[RFC4657] requires the ability for a PCC to indicate in a path [RFC4657] requires the ability for a PCC to indicate in a path
computation request a required/desired objective function, as well as computation request a required/desired objective function, as well as
optional function parameters. optional function parameters.
For these purposes, this document extends the PCE communication For these purposes, this document extends the PCE communication
Protocol (PCEP). It defines PCEP extensions allowing a PCE to Protocol (PCEP). It defines PCEP extensions that allow a PCE to
advertise a list of supported objective functions, as well as advertise a list of supported objective functions, as well as
extensions to carry the objective function in PCEP request and reply extensions to carry the objective function in PCEP request and reply
messages. It complements the PCEP base specification [PCEP]. messages. It complements the PCEP base specification [RFC5440].
Note that IS-IS and OSPF-based PCE Discovery mechanisms are defined Note that OSPF- and IS-IS-based PCE discovery mechanisms are defined
in ([RFC5089], [RFC5088]). These mechanisms are dedicated to the in [RFC5088] and [RFC5089]. These mechanisms are dedicated to the
discovery of a few generic parameters while more detailed PCE discovery of a few generic parameters, while more detailed PCE
parameters should be discovered using the PCE communication Protocol. parameters should be discovered using the PCE communication Protocol.
Objective functions are in this second category; thus the Objective Objective functions are in this second category; thus, the objective
Function discovery procedure is handled by PCEP. function discovery procedure is handled by PCEP.
A new PCEP TLV, named the OF-List TLV is defined in Section 2. The 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 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 list, during PCEP session-setup phase, the objective functions that
it supports. it supports.
A new PCEP object, the OF object, is defined in Section 3. The OF A new PCEP object, the OF object, is defined in Section 3. The OF
object is carried within a PCReq message to indicate the object is carried within a PCReq (Path Computation Request) message
required/desired objective function to be applied by a PCE, or in a to indicate the required/desired objective function to be applied by
PCRep message to indicate the objective function that was used for a PCE, or in a PCRep (Path Computation Reply) message to indicate the
path computation. objective function that was used for path computation.
Six mandatory objective functions that must be supported by PCEP are Six mandatory objective functions that must be supported by PCEP are
listed in [RFC4657]. This document provides a definition of these six listed in [RFC4657]. This document provides a definition of these
mandatory objective functions. Additional objective functions may be six mandatory objective functions. Additional objective functions
defined in other documents. Note that additional objective functions may be defined in other documents. Note that additional objective
are defined for PCE Global Concurrent Optimization (GCO) application, functions are defined for the PCE Global Concurrent Optimization
in [PCE-GCO]. (GCO) application, in [PCE-GCO].
This document also provides the definition of four new metric types This document also provides the definition of four new metric types
that apply to a set of synchronized requests. that apply to a set of synchronized requests.
1.1. Terminology 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. LSR: Label Switching Router.
OF: Objective Function: A set of one or more optimization criteria OF: Objective Function. A set of one or more optimization
used for the computation of a single path (e.g. path cost criteria used for the computation of a single path (e.g.,
minimization), or the synchronized computation of a set of paths path cost minimization) or for the synchronized computation
(e.g., aggregate bandwidth consumption minimization, etc.). of a set of paths (e.g., aggregate bandwidth consumption
minimization, etc.).
PCC: Path Computation Client: Any client application requesting a PCC: Path Computation Client. Any client application requesting a
path computation to be performed by a Path Computation Element. path computation to be performed by a Path Computation
Element.
PCE: Path Computation Element: An entity (component, application, or PCE: Path Computation Element. An entity (component, application,
network node) that is capable of computing a network path or route or network node) that is capable of computing a network path
based on a network graph, and applying computational constraints. or route based on a network graph and of applying
computational constraints.
PCEP: Path Computation Element communication Protocol. PCEP: Path Computation Element communication Protocol.
TE LSP: Traffic Engineered Label Switched Path. TE LSP: Traffic Engineered Label Switched Path.
1.2. Message Formats 1.3. Message Formats
Message formats in this document are expressed using Reduced BNF as Message formats in this document are expressed using Reduced BNF as
used in [PCEP] and defined in [RBNF]. used in [RFC5440] and defined in [RFC5511].
2. Discovery of PCE Objective Functions 2. Discovery of PCE Objective Functions
This section defines PCEP extensions (see [PCEP]) so as to support This section defines PCEP extensions (see [RFC5440]) so as to support
the advertisement of the objective functions supported by a PCE. the advertisement of the objective functions supported by a PCE.
A new PCEP OF-List (Objective Function list) TLV is defined. The PCEP A new PCEP OF-List (Objective Function list) TLV is defined. The
OF-List TLV is carried within an OPEN object, in order for a PCE to PCEP OF-List TLV is carried within an OPEN object. This way, during
advertise to a PCEP peer the list of objective functions it supports, PCEP session-setup phase, a PCE can advertise to a PCEP peer the list
during PCEP session setup phase. of objective functions it supports.
2.1. OF-List TLV 2.1. OF-List TLV
The PCEP OF-List TLV is optional. It MAY be carried within an OPEN 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 object sent by a PCE in an Open message to a PCEP peer so as to
indicate the list of supported objective functions. indicate the list of supported objective functions.
The OF-List TLV format is compliant with the PCEP TLV format defined The OF-List TLV format is compliant with the PCEP TLV format defined
in [PCEP]. That is, the TLV is composed of 2 octets for the type, 2 in [RFC5440]. That is, the TLV is composed of 2 octets for the type,
octets specifying the TLV length, and a value field. The Length field 2 octets specifying the TLV length, and a Value field. The Length
defines the length of the value portion in octets. The TLV is padded field defines the length of the value portion in octets. The TLV is
to four-octet alignment and padding is not included in the Length padded to 4-octet alignment, and padding is not included in the
field (e.g. a three octet value would have a length of three, but the Length field (e.g., a 3-octet value would have a length of three, but
total size of the TLV would be eight octets). the total size of the TLV would be eight octets).
The PCEP OF-List TLV has the following format: The PCEP OF-List TLV has the following format:
TYPE: To be assigned by IANA (suggested value = 4 ) TYPE: 4
LENGTH: N * 2 (where N is the number of objective functions) LENGTH: N * 2 (where N is the number of objective functions)
VALUE: list of 2-bytes objective function code points, identifying VALUE: list of 2-byte objective function code points, identifying
the objective functions supported by the sender of the Open message. the objective functions supported by the sender of the Open
message.
0 1 2 3 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 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 #1 | OF Code #2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// // // //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OF Code #N | padding | | OF Code #N | padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
OF Code (2 bytes): Objective Function code point identifier. IANA
manages the "PCE Objective Function" code point registry (see Section
6).
OF Code (2 bytes): Objective Function code point identifier. 2.2. Elements of Procedure
IANA is requested to manage 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 A PCE MAY include an OF-List TLV within an OPEN object in an Open
message sent to a PCEP peer, to advertise a set of one or more message sent to a PCEP peer in order to advertise a set of one or
objective functions. The OF-List TLV MUST NOT appear more than once more objective functions. The OF-List TLV MUST NOT appear more than
in an OPEN object. If it appears more than once the PCEP session MUST once in an OPEN object. If it appears more than once, the PCEP
be rejected with error type 1 and error value 1 (PCEP session session MUST be rejected with error type 1 and error value 1 (PCEP
establishment failure / Reception of an invalid Open message). session establishment failure / Reception of an invalid Open
The absence of the OF-List TLV in an OPEN object MUST be interpreted message). The absence of the OF-List TLV in an OPEN object MUST be
as an absence of information on the list of supported objective interpreted as an absence of information on the list of supported
functions by the PCE. objective functions by the PCE.
As specified in [PCEP], a PCEP peer that does not recognize the OF- As specified in [RFC5440], a PCEP peer that does not recognize the
List TLV will silently ignore it. OF-List TLV will silently ignore it.
3. Objective Function in PCEP Path Computation Request and Reply 3. Objective Function in PCEP Path Computation Request and Reply
Messages Messages
This section defines PCEP extensions ([PCEP]) so as to support the This section defines PCEP extensions [RFC5440] so as to support the
communication of objective functions in PCEP path computation request communication of objective functions in PCEP path computation request
and reply messages. A new PCEP OF (Objective Function) object is 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 defined, to be carried within a PCReq message in order for the PCC to
indicate the required/desired objective function. indicate the required/desired objective function.
The PCEP OF Object may also be carried within a PCRep message in 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 order for the PCE to indicate the objective function that was used by
the PCE. the PCE.
A new flag is defined in the RP object. The flag is used in a PCReq A new flag is defined in the RP (Request Parameters) object. The
message to indicate that the PCE MUST include an OF object in the flag is used in a PCReq message to indicate that the PCE MUST include
PCRep message to indicate the objective function that was used during an OF object in the PCRep message to indicate the objective function
path computation. that was used during path computation.
Also, new PCEP error types and values are defined. Also, new PCEP error types and values are defined.
3.1. OF Object 3.1. OF Object
The PCEP OF (Objective Function) object is optional. It MAY be The PCEP OF (Objective Function) object is optional. It MAY be
carried within a PCReq message so as to indicate the desired/required carried within a PCReq message so as to indicate the desired/required
objective function to be applied by the PCE during path computation, objective function to be applied by the PCE during path computation
or within a PCRep message so as to indicate the objective function or within a PCRep message so as to indicate the objective function
that was used by the PCE during path computation. that was used by the PCE during path computation.
The OF object format is compliant with the PCEP object format defined The OF object format is compliant with the PCEP object format defined
in [PCEP]. in [RFC5440].
The OF Object-Class is to be assigned by IANA (recommended value=21). The OF Object-Class is 21.
The OF Object-Type is to be assigned by IANA (recommended value=1). The OF Object-Type is 1.
The format of the OF object body is: The format of the OF object body is:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Objective Function Code(IANA) | Reserved | | OF Code | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
// Optional TLV(s) // // Optional TLV(s) //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Objective Function Code (2 bytes): The identifier of the Objective OF Code (2 bytes): The identifier of the objective function. IANA
Function. IANA is requested to manage the PCE objective function code manages the "PCE Objective Function" code point registry (see Section
point registry (see Section 6). 6).
Reserved (2 bytes): This field MUST be set to zero on transmission Reserved (2 bytes): This field MUST be set to zero on transmission
and MUST be ignored on receipt. and MUST be ignored on receipt.
Optional TLVs may be defined in the future so as to encode objective Optional TLVs may be defined in the future so as to encode objective
function parameters. function parameters.
3.1.1. Elements of Procedure 3.1.1. Elements of Procedure
To request the use of a specific objective function by the PCE, a PCC To request the use of a specific objective function by the PCE, a PCC
includes an OF object in the PCReq message. includes an OF object in the PCReq message.
[PCEP] specifies a bit flag, referred to as the P bit, carried in the [RFC5440] specifies a bit flag, referred to as the P bit, carried in
common PCEP object header. The P bit is set by a PCC to mandate that the common PCEP object header. The P bit is set by a PCC to mandate
a PCE must take the information carried in the object into account that a PCE must take the information carried in the object into
during the path computation. account during the path computation.
If the P bit is set in the OF object, the objective function is If the P bit is set in the OF object, the objective function is
mandatory (required objective function) and the PCE MUST use the mandatory (required objective function) and the PCE MUST use the
objective function during path computation. If the P bit is clear objective function during path computation. If the P bit is clear in
in the OF object, the objective function is optional (desired the OF object, the objective function is optional (desired objective
objective function) and the PCE SHOULD apply the function if it is function) and the PCE SHOULD apply the function if it is supported
supported, but MAY choose to apply a different objective function but MAY choose to apply a different objective function, according to
according to local capabilities and policies. local capabilities and policies.
On receipt of a PCReq message with an OF object, a PCE MUST proceed On receipt of a PCReq message with an OF object, a PCE MUST proceed
as follows: as follows:
- If the OF object is unknown/unsupported, the PCE MUST follow - If the OF object is unknown/unsupported, the PCE MUST follow
procedures defined in [PCEP], that is if the P bit is set, it sends procedures defined in [RFC5440]. That is, if the P bit is set, the
a PCErr message with error type 3 or 4 (Unknown / Not supported PCE sends a PCErr message with error type 3 or 4 (Unknown / Not
object) and error value 1 or 2 (unknown / unsupported object class supported object) and error value 1 or 2 (unknown / unsupported
/ object type), and the related path computation request MUST be object class / object type), and the related path computation
discarded. If the P bit is cleared it is free to ignore the object. 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 - 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 set, the PCE MUST send a PCErr message with error type 3 or 4
(Unknown / Not supported Object) and error value 4 (Unrecognized / (Unknown / Not supported object) and error value 4
Unsupported parameter), and the related path computation request (Unrecognized/Unsupported parameter), and the related path
MUST be discarded. computation request MUST be discarded.
- If the objective function is unknown / unsupported and the P bit is - If the objective function is unknown / unsupported and the P bit is
cleared, the PCE SHOULD apply another (default) objective function. cleared, the PCE SHOULD apply another (default) objective function.
- If the objective function is supported but policy does not permit - If the objective function is supported but policy does not permit
applying it, and the P bit is set, the PCE MUST send a PCErr 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 message with the PCEP error type "policy-violation" (type 5) and a
new error value "objective function not allowed" (defined in this new error value, "objective function not allowed", which is defined
document). in this document.
- If the objective function is supported but policy does not allow - If the objective function is supported but policy does not allow
applying it, and the P bit is cleared, the PCE SHOULD apply another applying it and if the P bit is cleared, the PCE SHOULD apply
(default) objective function. another (default) objective function.
- If the objective function is supported and policy allows applying - If the objective function is supported and policy allows applying
it, then if the P bit is set the PCE MUST apply the requested it and if the P bit is set, the PCE MUST apply the requested
objective function, else if the P bit is cleared the PCE is free to objective function. Otherwise, if the P bit is cleared, the PCE is
apply any other objective function. free to apply any other objective function.
The default objective function may be locally configured. The default objective function may be locally configured.
3.2. Carrying The OF Object In a PCEP Message 3.2. Carrying The OF Object In a PCEP Message
The OF object MAY be carried within a PCReq message. If an objective 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 function is to be applied to a set of synchronized path computation
requests, the OF object MUST be carried just after the corresponding requests, the OF object MUST be carried just after the corresponding
SVEC object, and MUST NOT be repeated for each elementary request. SVEC (Synchronization VECtor) object and MUST NOT be repeated for
each elementary request.
Similarly if a metric is to be applied to a set of synchronized 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 requests, the METRIC object MUST follow the SVEC object and MUST NOT
be repeated for each elementary request. Note that metrics applied to be repeated for each elementary request. Note that metrics applied
a set of synchronized requests are defined in section 5. to a set of synchronized requests are defined in Section 5.
An OF object specifying an objective function that applies to an An OF object specifying an objective function that applies to an
individual path computation request (non synchronized case) MUST individual path computation request (non-synchronized case) MUST
follow the RP object for which it applies. follow the RP object for which it applies.
The format of the PCReq message is updated as follows: 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.
<PCReq Message> ::= <Common Header> <PCReq Message> ::= <Common Header>
[<svec-list>] [<svec-list>]
<request-list> <request-list>
where: where:
<svec-list> ::= <SVEC> <svec-list> ::= <SVEC>
[<OF>] [<OF>]
[<metric-list>] [<metric-list>]
[<svec-list>] [<svec-list>]
skipping to change at page 9, line 38 skipping to change at page 11, line 6
When the PCE wants to indicate to the PCC the objective function that When the PCE wants to indicate to the PCC the objective function that
was used for the synchronized computation of a set of paths, the was used for the synchronized computation of a set of paths, the
PCRep message MUST include the corresponding SVEC object directly PCRep message MUST include the corresponding SVEC object directly
followed by the OF object, which MUST NOT be repeated for each followed by the OF object, which MUST NOT be repeated for each
elementary request. If a metric is applicable to the set of paths, elementary request. If a metric is applicable to the set of paths,
the METRIC object MUST directly follow the SVEC object and MUST NOT the METRIC object MUST directly follow the SVEC object and MUST NOT
be repeated for each elementary request. be repeated for each elementary request.
An OF object specifying an objective function used for an individual An OF object specifying an objective function used for an individual
path computation (non synchronized case) MUST follow the RP object path computation (non-synchronized case) MUST follow the RP object
for which it applies. for which it applies.
The format of the PCRep message is updated as follows: The format of the PCRep 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.
<PCRep Message> ::= <Common Header> <PCRep Message> ::= <Common Header>
[<svec-list>] [<svec-list>]
<response-list> <response-list>
where: where:
<svec-list> ::= <SVEC> <svec-list> ::= <SVEC>
[<OF>] [<OF>]
[<metric-list>] [<metric-list>]
skipping to change at page 10, line 32 skipping to change at page 12, line 8
[<IRO>] [<IRO>]
<metric-list> ::= <METRIC> [<metric-list>] <metric-list> ::= <METRIC> [<metric-list>]
Note: The OF object MAY be associated to a negative reply, i.e., a Note: The OF object MAY be associated to a negative reply, i.e., a
reply with a NO-PATH object. reply with a NO-PATH object.
3.3. New RP Object Flag 3.3. New RP Object Flag
In some cases, where no objective function is specified in the In some cases, where no objective function is specified in the
request, or an optional objective function is desired (P flag cleared request or an optional objective function is desired (P flag cleared
in the OF object common header) but the PCE does not follow the in the OF object common header) but the PCE does not follow the
request, the PCC may desire to know the objective function that was request, the PCC may desire to know the objective function that was
used by the PCE during path computation. To that end, a new flag is used by the PCE during path computation. To that end, a new flag is
defined in the RP object, named the OF flag, allowing a PCC to defined in the RP object, named the OF flag, allowing a PCC to
request for the inclusion in the path computation reply of the request for the inclusion in the path computation reply of the
objective function that was used by the PCE during path computation. objective function that was used by the PCE during path computation.
The following new bit flag of the RP object is defined: The following new bit flag of the RP object is defined:
Objective Function (OF) flag (bit number 24) (suggested value, to be The Supply OF on response flag (bit number 24). When set in a PCReq
assigned by IANA). When set in a PCReq message, this indicates that message, this indicates that the PCE MUST provide the applied
the PCE MUST provide the applied objective function (should a path objective function (should a path satisfying the constraints be
satisfying the constraints be found) in the PCRep message. When set found) in the PCRep message. When set in a PCRep message, this
in a PCRep message this indicates that the Objective Function that indicates that the objective function that was used during path
was used during path computation is included. computation is included.
3.3.1. Elements Of Procedure 3.3.1. Elements Of Procedure
If the PCC wants to know the objective function used by the PCE If the PCC wants to know the objective function used by the PCE
during path computation for a given request, it sets the OF flag in during path computation for a given request, it sets the OF flag in
the RP object. the RP object.
On receipt of a PCReq message with the OF flag in the RP object set, On receipt of a PCReq message with the OF flag in the RP object set,
the PCE proceeds as follows: the PCE proceeds as follows:
- If policy permits it MUST include in the PCRep message an OF object - If policy permits, it MUST include in the PCRep message an OF
indicating the objective function it used during path computation. object indicating the objective function it used during path
computation.
- If policy does not permit, it MUST send a PCErr message with the - If policy does not permit, it MUST send a PCErr message with the
PCEP error code "policy-violation" (type 5) and a new error value PCEP error code "policy-violation" (type 5) and a new error value,
"objective function indication not allowed" (defined in this "objective function indication not allowed", which is defined in
document). this document.
Note that a legacy PCE might not recognize the OF flag in the RP Note that a legacy PCE might not recognize the OF flag in the RP
object. According to the definition of the RP object Flag Field in object. According to the definition of the Flags field for the RP
Section 7.4.1 of [PCEP], the legacy PCE will ignore the unknown flag object (Section 7.4.1 of [RFC5440]), the legacy PCE will ignore the
resulting in it sending a PCRep that does not contain an OF object. unknown flag, resulting in it sending a PCRep that does not contain
In this case, the PCC's beahvior is an implementation choice. The PCC an OF object. In this case, the PCC's behavior is an implementation
might: choice. The PCC might:
- Discard the PCRep because it really wanted the OF object returned. - Discard the PCRep because it really wanted the OF object returned.
- Accept the PCRep without the knowledge of the OF that was applied. - Accept the PCRep without the knowledge of the OF that was applied.
Note also that these procedures can give rise to the situation where Note also that these procedures can give rise to the situation where
a PCC receives a PCRep that contains an OF object with an Objective a PCC receives a PCRep that contains an OF object with an objective
Function identifier that the PCC does not recognize. In this function identifier that the PCC does not recognize. In this
situation the PCC behavior is dependent on implementaiton and situation, the PCC behavior is dependent on implementation and
configuration. The PCC could choose any of the following (or some configuration. The PCC could choose any of the following (or some
other action): other action):
- Ignore the OF object and use the computed path. - Ignore the OF object and use the computed path.
- Add the Objective Function to its view of the PCE's repetoire for
- Add the objective function to its view of the PCE's repertoire for
inclusion in future computation requests. inclusion in future computation requests.
- Discard the PCRep (i.e., the computed path) and send a PCReq to - Discard the PCRep (i.e., the computed path) and send a PCReq to
another PCE. another PCE.
- Discard the PCRep (i.e., the computed path) and send another PCReq - Discard the PCRep (i.e., the computed path) and send another PCReq
to the same PCE explicitly requiring the use of some other to the same PCE explicitly requiring the use of some other
Objective Function (i.e., by setting the P bit in the OF object). objective function (i.e., by setting the P bit in the OF object).
4. Objective Functions Definition 4. Objective Functions Definition
Six objective functions that must be supported by PCEP are listed in Six objective functions that must be supported by PCEP are listed in
[RFC4657]. Objective function codes should be assigned by IANA and [RFC4657]. Objective function codes have been assigned by IANA and
are suggested below. are described below.
Objective functions are formulated using the following terminology: Objective functions are formulated using the following terminology:
- a network comprises a set of N links {Li, (i=1...N)} - A network comprises a set of N links {Li, (i=1...N)}.
- a path P is a list of K links {Lpi,(i=1...K)}
- metric of link L is denoted M(L), this can be the IGP metric the TE
metric, or any other metric.
- the cost of a path P is denoted C(P), where
C(P) = sum {M(Lpi), (i=1...K)}.
- residual bandwidth on link L is denoted r(L) - A path P is a list of K links {Lpi,(i=1...K)}.
- maximum reservable bandwidth on link L is denoted R(L).
- Metric of link L is denoted M(L). This can be the IGP metric, the
TE metric, or any other metric.
- The cost of a path P is denoted C(P), where C(P) = sum {M(Lpi),
(i=1...K)}.
- Residual bandwidth on link L is denoted r(L).
- Maximum reservable bandwidth on link L is denoted R(L).
There are three objective functions that apply to the computation of There are three objective functions that apply to the computation of
a single path: a single path:
Objective Function Code: 1 (suggested value, to be assigned by IANA) Objective Function Code: 1
Name: Minimum Cost Path (MCP) Name: Minimum Cost Path (MCP)
Description: Find a path P such that C(P) is minimized. Description: Find a path P such that C(P) is minimized.
Objective Function Code: 2 (suggested value, to be assigned by IANA) Objective Function Code: 2
Name: Minimum Load Path (MLP) Name: Minimum Load Path (MLP)
Description: Find a path P such that Description: Find a path P such that
( Max {(R(Lpi) - r(Lpi) / R(Lpi), i=1...K } ) is minimized. ( Max {(R(Lpi) - r(Lpi)) / R(Lpi), i=1...K } ) is minimized.
Objective Function Code: 3 (suggested value, to be assigned by IANA) Objective Function Code: 3
Name: Maximum residual Bandwidth Path (MBP) Name: Maximum residual Bandwidth Path (MBP)
Description: Find a path P such that ( Min { r(Lpi), i=1...K } ) is Description: Find a path P such that
maximized. ( Min { r(Lpi), i=1...K } ) is maximized.
There are three objective functions that apply to a set of path There are three objective functions that apply to a set of path
computation requests the computation of which is synchronized: computation requests the computation of which is synchronized:
Objective Function Code: 4 (suggested value, to be assigned by IANA) Objective Function Code: 4
Name: Minimize aggregate Bandwidth Consumption (MBC) Name: Minimize aggregate Bandwidth Consumption (MBC)
Description: Find a set of paths such that ( Sum {R(Li) - r(Li), Description: Find a set of paths such that
i=1...N} ) is minimized. ( Sum {R(Li) - r(Li), i=1...N} ) is minimized.
Objective Function Code: 5 (suggested value, to be assigned by IANA) Objective Function Code: 5
Name: Minimize the Load of the most loaded Link (MLL) Name: Minimize the Load of the most loaded Link (MLL)
Description: Find a set of paths such that ( Max { (R(Li) - r(Li)) / Description: Find a set of paths such that
R(Li), i=1...N}) is minimized. ( Max { (R(Li) - r(Li)) / R(Li), i=1...N}) is minimized.
Objective Function Code: 6 (suggested value, to be assigned by IANA) Objective Function Code: 6
Name: Minimize the Cumulative Cost of a set of paths (MCC) Name: Minimize the Cumulative Cost of a set of paths (MCC)
Description: Find a set of paths {P1...Pm} such that (Sum { C(Pi), Description: Find a set of paths {P1...Pm} such that
i=1...m}) is minimized. (Sum { C(Pi), i=1...m}) is minimized.
Other objective functions may be defined in separate documents. Other objective functions may be defined in separate documents.
5. New Metric Types 5. New Metric Types
Three metric types are defined in PCEP for the METRIC object: TE Three metric types are defined in PCEP for the METRIC object: TE
metric, IGP metric and hop count. These metric types apply to an metric, IGP metric, and hop count. These metric types apply to an
individual request. Here we define four new metric types that apply individual request. Here, we define four new metric types that apply
to a set of synchronized requests: to a set of synchronized requests:
Type 4 (suggested value to be assigned by IANA) : Aggregate Type 4: Aggregate bandwidth consumption.
bandwidth consumption.
Type 5 (suggested value to be assigned by IANA) : Load of the most Type 5: Load of the most loaded link.
loaded link.
Type 6 (suggested value to be assigned by IANA) : Cumulative IGP Type 6: Cumulative IGP cost.
cost.
Type 7 (suggested value to be assigned by IANA) : Cumulative TE Type 7: Cumulative TE cost.
cost.
These metrics may be used to indicate a bound (B bit set in the These metrics may be used in a PCReq to indicate a bound (B bit set
METRIC object) or a computed metric (C bit set in the METRIC in the METRIC object) or to request the computation of a metric (C
object). bit set in the METRIC object), or in a PCRep to indicate a computed
metric.
A METRIC object with one of these four types follows the SVEC object A METRIC object with one of these four types follows the SVEC object
for which it applies. for which it applies.
6. IANA Considerations 6. IANA Considerations
6.1. PCE Objective Function Sub-registry 6.1. PCE Objective Function Sub-Registry
This document defines a 16-bit PCE Objective Function identifier to This document defines a 16-bit PCE objective function identifier to
be carried within the PCEP OF object, as well as the PCEP OF-List be carried within the PCEP OF object, and also defines the PCEP OF-
TLV. List TLV.
IANA is requested to create and manage the 16-bit "PCE Objective IANA created and now manages the 16-bit "PCE Objective Function" code
Function" code point registry, starting from 1 and continuing through point registry, starting from 1 and continuing through 32767, as
32767, as follows: follows:
- Objective Function code point value - Objective Function code point value
- Objective Function name - Objective Function name
- Defining RFC - Defining RFC
The same registry is applicable to the OF object and the OF-List TLV The same registry is applicable to the OF object and the OF-List TLV
defined in this document. that are defined in this document.
The guidelines (using terms defined in [RFC5226]) for the The guidelines (using terms defined in [RFC5226]) for the assignment
assignment of objective function code point values are as follows: of objective function code point values are as follows:
- Function code value 0 is reserved. - Function code value 0 is reserved.
- Function code values in the range 1-32767 are to be assigned as
follows: - Function code values in the range 1-32767 are assigned as follows:
- Function code values 1 through 1023 are to be assigned by IANA
using the "IETF Consensus" policy. o Function code values 1 through 1023 are assigned by IANA using
- Function code values 1024 through 32767 are to be assigned by the "IETF Review" policy.
IANA, using the "First Come First Served" policy.
- Function code values in the range 32768-65535 are for "Private o Function code values 1024 through 32767 are assigned by IANA,
using the "First Come First Served" policy.
o Function code values in the range 32768-65535 are for "Private
Use". Use".
Six objective functions are defined in Section 4 of this document and Six objective functions are defined in Section 4 of this document and
should be assigned by IANA: have been assigned by IANA:
Code Point Name Defining RFC
1 MCP this doc Code Point Name Reference
2 MLP this doc -------------------------------------------------------
3 MBP this doc 1 MCP RFC 5541
4 MBC this doc 2 MLP RFC 5541
5 MLL this doc 3 MBP RFC 5541
6 MCC this doc 4 MBC RFC 5541
5 MLL RFC 5541
6 MCC RFC 5541
6.2. PCEP Code Points 6.2. PCEP Code Points
6.2.1. OF Object 6.2.1. OF Object
IANA manages the PCEP Objects code point registry (see [PCEP]). This IANA manages the PCEP Objects code point registry (see [RFC5440]).
is maintained as the "PCEP Objects" sub-registry of the "Path This is maintained as the "PCEP Objects" sub-registry of the "Path
Computation Element Protocol (PCEP) Numbers" registry. Computation Element Protocol (PCEP) Numbers" registry.
This document defines a new PCEP object, the OF object, to be carried This document defines a new PCEP object, the OF object, to be carried
in PCReq and PCRep messages. IANA is requested to make the following in PCReq and PCRep messages. IANA has made the following allocation:
allocation (suggested value):
Object Name Object Name Reference Object Name Object Name Reference
Class Type Class Type
------------------------------------------------------------
21 OF 1 Objective Function (this document) 21 OF 1 Objective Function RFC 5541
6.2.2. OF-List TLV 6.2.2. OF-List TLV
IANA manages the PCEP TLV code point registry (see [PCEP]). This is IANA manages the PCEP TLV code point registry (see [RFC5440]). This
maintained as the "PCEP TLV Type Indicators" sub-registry of the is maintained as the "PCEP TLV Type Indicators" sub-registry of the
"Path Computation Element Protocol (PCEP) Numbers" registry. "Path Computation Element Protocol (PCEP) Numbers" registry.
This document defines a new PCEP TLV, the OF-List TLV, to be carried This document defines a new PCEP TLV, the OF-List TLV, to be carried
in the OPEN object. IANA is requested to make the following in the OPEN object. IANA has made the following allocation:
allocation (suggested value):
Type TLV name References Type TLV name References
----- -------- ---------- -----------------------------------------------
4 OF-List (This document) 4 OF-List RFC 5541
6.2.3. PCEP Error values 6.2.3. PCEP Error Values
IANA maintains a registry of Error-types and Error-values for use in IANA maintains a registry of Error-types and Error-values for use in
PCEP messages. This is maintained as the "PCEP-ERROR Object Error PCEP messages. This is maintained as the "PCEP-ERROR Object Error
Types and Values" sub-registry of the "Path Computation Element Types and Values" sub-registry of the "Path Computation Element
Protocol (PCEP) Numbers" registry. Protocol (PCEP) Numbers" registry.
Two new Error-values are defined for the Error-type "policy Two new Error-values are defined for the Error-type "policy
violation" (type 5): violation" (type 5):
Error-type Meaning and error values Reference Error-type Meaning and error values Reference
------------------------------------------------------------------
5 Policy violation 5 Policy violation
Error-value=3: objective function not (this doc) Error-value=3: objective function not RFC 5541
allowed (request rejected) allowed (request rejected)
Error-value=4: OF bit of the RP object (this doc) Error-value=4: OF bit of the RP object RFC 5541
set (request rejected) set (request rejected)
6.2.4. RP Object Flag 6.2.4. RP Object Flag
A new flag of the RP object (specified in [PCEP]) is defined in this A new flag of the RP object (specified in [RFC5440]) is defined in
document. IANA maintains a registry of RP object flags in the "RP this document. IANA maintains a registry of RP object flags in the
Object Flag Field" sub-registry of the "Path Computation Element "RP Object Flag Field" sub-registry of the "Path Computation Element
Protocol (PCEP) Numbers" registry. Protocol (PCEP) Numbers" registry.
IANA is requested to make the following allocation (suggested value): IANA has made the following allocation:
Bit Description Reference Bit Description Reference
-------------------------------------------
24 Supply OF on response This document 24 Supply OF on response RFC 5541
6.2.5. Metric Types 6.2.5. Metric Types
Four new metric types are defined in this document for the METRIC Four new metric types are defined in this document for the METRIC
object (specified in [PCEP]). IANA maintains a registry of metric object (specified in [RFC5440]). IANA maintains a registry of metric
types in the "METRIC Object T Field" sub-registry of the "Path types in the "METRIC Object T Field" sub-registry of the "Path
Computation Element Protocol (PCEP) Numbers" registry. Computation Element Protocol (PCEP) Numbers" registry.
IANA is requested to make the following allocation (suggested IANA has made the following allocations:
values):
- Type 4 : Aggregate bandwidth consumption - Type 4 : Aggregate bandwidth consumption
- Type 5 : Load of the most loaded link - Type 5 : Load of the most loaded link
- Type 6 : Cumulative IGP cost - Type 6 : Cumulative IGP cost
- Type 7 : Cumulative TE cost - Type 7 : Cumulative TE cost
7. Security Considerations 7. Security Considerations
PCEP security mechanisms are described in [PCEP] and are used to PCEP security mechanisms are described in [RFC5440] and are used to
secure entire PCEP messages. Nothing in this document changes the secure entire PCEP messages. Nothing in this document changes the
message flows or introduces any new messages, so the security message flows or introduces any new messages, so the security
mechanisms set out in [PCEP] continue to be applicable. mechanisms set out in [RFC5440] continue to be applicable.
This document introduces a single new object that may optionally be This document introduces a single new object that may optionally be
carried on PCEP messages and will be automatically secured using the carried on PCEP messages and will be automatically secured using the
mechanims described in [PCEP]. mechanisms described in [RFC5440].
If a PCEP message is vulnerable to attack, for example because the If a PCEP message is vulnerable to attack (for example, because the
security mechanisms are not used, then the OF object could be used as security mechanisms are not used), then the OF object could be used
part of an attack, however, it is likely that other objects will as part of an attack; however, it is likely that other objects will
provide far more significant ways of attacking a PCE or PCC in this provide far more significant ways of attacking a PCE or PCC in this
case. case.
8. Manageability Considerations 8. Manageability Considerations
8.1. Control of Function and Policy 8.1. Control of Function and Policy
It MUST be possible to configure the activation/deactivation of It MUST be possible to configure the activation/deactivation of
Objective Function Discovery in PCEP. objective function discovery in PCEP.
In addition to the parameters already listed in section 8.1 of In addition to the parameters already listed in Section 8.1 of
[PCEP], a PCEP implementation SHOULD allow configuring on a PCE a [RFC5440], a PCEP implementation SHOULD allow configuring a list of
list of authorized objective functions. This may apply to any session authorized objective functions on a PCE. This may apply to any
the PCEP speaker participates in, to a specific session with a given session the PCEP speaker participates in, to a specific session with
PCEP peer or to a specific group of sessions with a specific group of a given PCEP peer, or to a specific group of sessions with a specific
PCEP peers. group of PCEP peers.
Note that it is not mandatory for an implementation to support all Note that it is not mandatory for an implementation to support all
objective functions defined in Section 4. objective functions defined in Section 4.
It MUST be possible to configure a default objective function used It MUST be possible to configure a default objective function used
for path computation when a path request is received that requests to for path computation when a path request is received that requests to
use an optional objective function. use an optional objective function.
8.2. Information and Data Models 8.2. Information and Data Models
The PCEP MIB Module defined in [PCEP-MIB] could be extended to The PCEP MIB Module defined in [PCEP-MIB] could be extended to
include Objective Functions. include objective functions.
8.3. Liveness Detection and Monitoring 8.3. Liveness Detection and Monitoring
Mechanisms defined in this document do not imply any new liveness Mechanisms defined in this document do not imply any new liveness
detection and monitoring requirements in addition to those already detection and monitoring requirements in addition to those already
listed in [PCEP]. listed in [RFC5440].
8.4. Verify Correct Operations 8.4. Verify Correct Operations
Mechanisms defined in this document do not imply any new operation Mechanisms defined in this document do not imply any new operation
verification requirements in addition to those already listed in verification requirements in addition to those already listed in
[PCEP]. [RFC5440].
8.5. Requirements On Other Protocols 8.5. Requirements On Other Protocols
Mechanisms defined in this document do not imply any requirements on Mechanisms defined in this document do not imply any requirements on
other protocols in addition to those already listed in [PCEP]. other protocols in addition to those already listed in [RFC5440].
8.6. Impact On Network Operations 8.6. Impact On Network Operations
Mechanisms defined in this document do not have any impact on network Mechanisms defined in this document do not have any impact on network
operations in addition to those already listed in [PCEP]. operations in addition to those already listed in [RFC5440].
9. Acknowledgments 9. Acknowledgments
The authors would like to thank Jerry Ash, Fabien Verhaeghe, The authors would like to thank Jerry Ash, Fabien Verhaeghe, Robert
Robert Sparks, and Adrian Farrel for their useful comments. Sparks, and Adrian Farrel for their useful comments.
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4655] Farrel, A., Vasseur, J.P., Ash, J., "Path Computation [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path
Element (PCE)-based Architecture", RFC4655, august 2006. Computation Element (PCE)-Based Architecture", RFC 4655,
August 2006.
[PCEP] Vasseur, Le Roux, et al., "Path Computation Element (PCE) [RFC5440] Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path Computation
communication Protocol (PCEP)", draft-ietf-pce-pcep, work Element (PCE) Communication Protocol (PCEP)", RFC 5440,
in progress. March 2009.
10.2. Informative References 10.2. Informative References
[RFC4657] Ash, J., Le Roux, J.L., " PCE Communication Protocol [RFC4657] Ash, J., Ed., and J. Le Roux, Ed., "Path Computation
Generic Requirements", RFC4657, September 2006. Element (PCE) Communication Protocol Generic
Requirements", RFC 4657, September 2006.
[RFC4674] Le Roux, J.L., et al. "Requirements for PCE discovery", [RFC4674] Le Roux, J., Ed., "Requirements for Path Computation
RFC4674, October 2006. Element (PCE) Discovery", RFC 4674, October 2006.
[RFC5088] Le Roux, Vasseur, et al. "OSPF protocol extensions for [RFC5088] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R.
Path Computation Element (PCE) Discovery", RFC5088, January Zhang, "OSPF Protocol Extensions for Path Computation
2008. Element (PCE) Discovery", RFC 5088, January 2008.
[RFC5089] Le Roux, Vasseur, et al. "IS-IS protocol extensions for [RFC5089] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R.
Path Computation Element (PCE) Discovery", RFC5089, January Zhang, "IS-IS Protocol Extensions for Path Computation
2008. Element (PCE) Discovery", RFC 5089, January 2008.
[RFC5226] Narten, T. and Alverstrand, H., "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, May IANA Considerations Section in RFCs", BCP 26, RFC 5226,
2008. May 2008.
[PCE-GCO] Y. Lee, J.L. Le Roux, D. King, and E. Oki, "Path [PCE-GCO] Lee, Y., Le Roux, JL., King, D., and E. Oki, "Path
Computation Element Communication Protocol (PCECP) Computation Element Communication Protocol (PCEP)
Requirements and Protocol Extensions In Support of Global Requirements and Protocol Extensions in Support of Global
Concurrent Optimization", draft-ietf-pce-global-concurrent- Concurrent Optimization", Work in Progress, March 2009.
optimization, work in progress.
[PCEP-MIB] Koushik, K., and Stephan, E., "PCE communication protocol [PCEP-MIB] Koushik, K., and E. Stephan, "PCE Communication Protocol
(PCEP) Management Information Base", draft-kkoushik-pce- (PCEP) Management Information Base", Work in Progress,
pcep-mib, work in progress. January 2009.
[RBNF] A. Farrel, "Reduced Backus-Naur Form (RBNF) - A Syntax Used [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF) - A Syntax
in Various Protocol Specifications", draft-farrel-rtg- Used to Form Encoding Rules in Various Routing Protocol
common-bnf, work in progress. Specifications", RFC 5511, April 2009.
11. Authors' Addresses Appendix A. RBNF Code Fragments
Jean-Louis Le Roux This appendix contains the full set of code fragments defined in this
France Telecom document.
2, avenue Pierre-Marzin
22307 Lannion Cedex
FRANCE
Email: jeanlouis.leroux@orange-ftgroup.com
Jean-Philippe Vasseur Copyright (c) 2009 IETF Trust and the persons identified as authors
Cisco Systems, Inc. of the code. All rights reserved.
1414 Massachusetts avenue
Boxborough , MA - 01719
USA
Email: jpv@cisco.com
Young Lee Redistribution and use in source and binary forms, with or without
Huawei Technologies, LTD. modification, are permitted provided that the following conditions
1700 Alma Drive, Suite 100 are met:
Plano, TX 75075
USA
Email: ylee@huawei.com
Full Copyright Statement o Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
Copyright (c) 2008 IETF Trust and the persons identified as the o Redistributions in binary form must reproduce the above copyright
document authors. All rights reserved. notice, this list of conditions and the following disclaimer in the
documentation and/or other materials provided with the
distribution.
This document is subject to BCP 78 and the IETF Trust's Legal o Neither the name of Internet Society, IETF or IETF Trust, nor the
Provisions Relating to IETF Documents names of specific contributors, may be used to endorse or promote
(http://trustee.ietf.org/license-info) in effect on the date of products derived from this software without specific prior written
publication of this document. Please review these documents permission.
carefully, as they describe your rights and restrictions with respect
to this document.
All IETF Documents and the information contained therein are provided THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
FOR A PARTICULAR PURPOSE. DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
Intellectual Property <PCReq Message> ::= <Common Header>
[<svec-list>]
<request-list>
The IETF Trust takes no position regarding the validity or scope of <PCRep Message> ::= <Common Header>
any Intellectual Property Rights or other rights that might be [<svec-list>]
claimed to pertain to the implementation or use of the technology <response-list>
described in any IETF Document or the extent to which any license <svec-list> ::= <SVEC>
under such rights might or might not be available; nor does it [<OF>]
represent that it has made any independent effort to identify any [<metric-list>]
such rights. [<svec-list>]
Copies of Intellectual Property disclosures made to the IETF <request-list> ::= <request> [<request-list>]
Secretariat and any assurances of licenses to be made available, or
the result of an attempt made to obtain a general license or
permission for the use of such proprietary rights by implementers or
users of this specification can be obtained from the IETF on-line IPR
repository at http://www.ietf.org/ipr
The IETF invites any interested party to bring to its attention any <request> ::= <RP>
copyrights, patents or patent applications, or other proprietary <END-POINTS>
rights that may cover technology that may be required to implement [<LSPA>]
any standard or specification contained in an IETF Document. Please [<BANDWIDTH>]
address the information to the IETF at ietf-ipr@ietf.org. [<metric-list>]
[<OF>]
[<RRO>[<BANDWIDTH>]]
[<IRO>]
[<LOAD-BALANCING>]
The definitive version of an IETF Document is that published by, or <metric-list> ::= <METRIC>[<metric-list>]
under the auspices of, the IETF. Versions of IETF Documents that are
published by third parties, including those that are translated into
other languages, should not be considered to be definitive versions
of IETF Documents. The definitive version of these Legal Provisions
is that published by, or under the auspices of, the IETF. Versions of
these Legal Provisions that are published by third parties, including
those that are translated into other languages, should not be
considered to be definitive versions of these Legal Provisions.
For the avoidance of doubt, each Contributor to the IETF Standards <response-list> ::= <response> [<response-list>]
Process licenses each Contribution that he or she makes as part of
the IETF Standards Process to the IETF Trust pursuant to the <response> ::= <RP>
provisions of RFC 5378. No language to the contrary, or terms, [<NO-PATH>]
conditions or rights that differ from or are inconsistent with the [<attribute-list>]
rights and licenses granted under RFC 5378, shall have any effect and [<path-list>]
shall be null and void, whether published or posted by such
Contributor, or included with or in such Contribution. <path-list> ::= <path> [<path-list>]
<path> ::= <ERO>
<attribute-list>
<attribute-list> ::= [<OF>]
[<LSPA>]
[<BANDWIDTH>]
[<metric-list>]
[<IRO>]
Authors' Addresses
JL Le Roux
France Telecom
2, Avenue Pierre-Marzin
Lannion 22307
France
EMail: jeanlouis.leroux@orange-ftgroup.com
Jean-Philippe Vasseur
Cisco Systems, Inc
11, Rue Camille Desmoulins
L'Atlantis
92782 Issy Les Moulineaux
France
EMail: jpv@cisco.com
Young Lee
Huawei Technologies, LTD.
1700 Alma Drive, Suite 100
Plano, TX 75075
USA
EMail: ylee@huawei.com
 End of changes. 158 change blocks. 
420 lines changed or deleted 430 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/