Network Working Group J.L. Le Roux
Internet Draft France Telecom
Category: Standard Track
Expires: January 2009 J.P. Vasseur
Cisco System Inc.
Y. Lee
Huawei
July 2008
Encoding of Objective Functions in Path Computation Element
communication Protocol (PCEP)
draft-ietf-pce-of-03.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Le Roux, Vasseur, Lee Encoding of Objective Functions in PCEP [Page 1]
Internet Draft draft-ietf-pce-of-03.txt July 2008
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 an objective function
(e.g. minimum cost path, widest path, etc.).
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 so
that a PCE can report in a path computation reply the objective
function that was used for path computation.
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 RFC-2119.
Table of Contents
Terminology.........................................................3
1. Introduction................................................3
2. Discovery of PCE Objective Functions........................5
2.1. OF-List TLV.................................................5
2.2. Elements of procedure.......................................6
3. Objective Function in PCEP Path Computation Request and
Reply Messages............................................6
3.1. OF Object...................................................6
3.1.1. Elements of Procedure.......................................7
3.2. Carrying The OF Object In a PCEP Message....................8
3.3. New RP Object Flag.........................................10
3.3.1. Elements Of Procedure......................................11
4. Objective Functions Definition.............................11
5. New Metric Types...........................................12
6. IANA Considerations........................................13
6.1. PCE Objective Function Sub-registry........................13
6.2. PCEP Code Points...........................................14
6.2.1. OF Object..................................................14
6.2.2. OF-List TLV................................................14
6.2.3. PCEP Error values..........................................14
6.2.4. RP Object Flag.............................................14
6.2.5. Metric Types...............................................15
Le Roux, Vasseur, Lee Encoding of Objective Functions in PCEP [Page 2]
Internet Draft draft-ietf-pce-of-03.txt July 2008
7. Security Considerations....................................15
8. Manageability Considerations...............................15
8.1. Control of Function and Policy.............................15
8.2. Information and Data Models................................15
8.3. Liveness Detection and Monitoring..........................16
8.4. Verify Correct Operations..................................16
8.5. Requirements On Other Protocols............................16
8.6. Impact On Network Operations...............................16
9. Acknowledgments............................................16
10. References.................................................16
10.1. Normative Feferences.......................................16
10.2. Informative References.....................................16
11. Authors' Addresses.........................................17
12. Intellectual Property Statement............................17
Terminology
Terminology used in this document
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 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 applying computational
constraints.
PCEP: Path Computation Element communication Protocol.
TE LSP: Traffic Engineered Label Switched Path.
1. Introduction
The PCE-based network architecture [RFC4655] defines a Path
Computation Element (PCE) as an entity capable of computing TE LSP
paths based on a network graph, and applying computational
constraints. A PCE services path computation requests sent by Path
Computation Clients (PCC).
The PCE communication Protocol (PCEP), defined in [PCEP], allows for
communication between a PCC and a PCE or between two PCEs, in
Le Roux, Vasseur, Lee Encoding of Objective Functions in PCEP [Page 3]
Internet Draft draft-ietf-pce-of-03.txt July 2008
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
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 allowing 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 [PCEP].
Note that IS-IS and OSPF based PCE Discovery mechanisms are defined
in ([RFC5089], [RFC5088]). 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.
A new PCEP object, the OF object, is defined in Section 3. The OF
object is carried within a PCReq message to indicate the
required/desired objective function to be applied by a PCE, or in a
PCRep message to indicate the objective function that was used for
path computation.
Le Roux, Vasseur, Lee Encoding of Objective Functions in PCEP [Page 4]
Internet Draft draft-ietf-pce-of-03.txt July 2008
Six mandatory objective functions that must be supported by PCEP are
listed in [RFC4657]. This document provides, in Section 4, 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 PCE Global Concurrent
Optimization (GCO) application, in [PCE-GCO]. This document also
provides, in Section 5, the definition of four new metric types that
apply to a set of synchronized requests.
2. Discovery of PCE Objective Functions
This section defines PCEP extensions (see [PCEP]) 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, in order for a PCE to
advertise to a PCEP peer the list of objective functions it supports,
during PCEP session setup phase.
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 [PCEP]. 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 four-octet alignment and padding is not included in the Length
field (e.g. a three 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: To be assigned by IANA (suggested value = 4 )
LENGTH: N * 2 (where N is the number of objective functions)
VALUE: list of 2-bytes 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Le Roux, Vasseur, Lee Encoding of Objective Functions in PCEP [Page 5]
Internet Draft draft-ietf-pce-of-03.txt July 2008
| OF Code #N | padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
OF Code (2 bytes): Objective Function code point identifier.
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
message sent to a PCEP peer, 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 [PCEP], 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 ([PCEP]) 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 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,
Le Roux, Vasseur, Lee Encoding of Objective Functions in PCEP [Page 6]
Internet Draft draft-ietf-pce-of-03.txt July 2008
or within a PCRep message so as to indicate the objective function
that was used by the PCE during path computation.
The OF object format is compliant with the PCEP object format defined
in [PCEP].
The OF Object-Class is to be assigned by IANA (recommended value=21).
The OF Object-Type is to be assigned by IANA (recommended value=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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Objective Function Code(IANA) | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Optional TLV(s) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Objective Function Code (2 bytes): The identifier of the Objective
Function. The IANA is requested to manage 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.
[PCEP] 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, Vasseur, Lee Encoding of Objective Functions in PCEP [Page 7]
Internet Draft draft-ietf-pce-of-03.txt July 2008
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 [PCEP], that is if the P bit is set, it
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 it 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 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" (defined in this document).
- If the objective function is supported but policy does not
allow applying it, and the P bit is cleared, the PCE SHOULD
apply another (default) objective function.
- If the objective function is supported and policy allows
applying it, then 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 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 object, and MUST NOT be repeated for each elementary request.
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.
Le Roux, Vasseur, Lee Encoding of Objective Functions in PCEP [Page 8]
Internet Draft draft-ietf-pce-of-03.txt July 2008
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:
<PCReq Message>::= <Common Header>
[<SVEC-list>]
<request-list>
where:
<svec-list>::=<SVEC>
[<OF>]
[<metric-list>]
[<svec-list>]
<request-list>::=<request>[<request-list>]
<request>::= <RP>
<END-POINTS>
[<LSPA>]
[<BANDWIDTH>]
[<metric-list>]
[<OF>]
[<RRO>]
[<IRO>]
[<LOAD-BALANCING>]
where:
<metric-list>::=<METRIC>[<metric-list>]
The OF object MAY be carried within a PCRep message to indicate the
objective function used by the PCE during path computation.
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
PCRep message MUST include the corresponding SVEC object directly
followed by the OF object, which MUST NOT be repeated for each
elementary request. If a metric is applicable to the set of paths,
the METRIC object MUST directly follow the SVEC object and MUST NOT
be repeated for each elementary request.
An OF object specifying an objective function used for an individual
path computation (non synchronized case) MUST follow the RP object
for which it applies.
Le Roux, Vasseur, Lee Encoding of Objective Functions in PCEP [Page 9]
Internet Draft draft-ietf-pce-of-03.txt July 2008
The format of the PCRep message is updated as follows:
<PCRep Message> ::= <Common Header>
[<svec-list>]
<response-list>
where:
<svec-list> ::=<SVEC>
[<OF>]
[<metric-list>]
[<svec-list>]
<response-list>::=<response>[<response-list>]
<response>::=<RP>
[<NO-PATH>]
[<path-list>]
<path-list>::=<path>[<path-list>]
<path>::= <ERO>
[<OF>]
[<LSPA>]
[<BANDWIDTH>]
[<metric-list>]
[<IRO>]
where:
<metric-list>::=<METRIC>[<metric-list>]
Note: The OF object MAY be associated to a negative reply, i.e.
a reply with a NO-PATH object.
3.3. New RP Object Flag
In some cases, where no objective function is specified in the
request, or an optional objective function is desired (P flag cleared
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
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
request for the inclusion in the path computation reply of the
objective function that was used by the PCE during path computation.
The following new bit flag of the RP object is defined:
Objective Function (OF) flag (1 bit): 0x200 (bit number 16)
(suggested value, to be assigned by IANA). When set in a PCReq
message, this indicates that the PCE MUST provide the applied
Le Roux, Vasseur, Lee Encoding of Objective Functions in PCEP [Page 10]
Internet Draft draft-ietf-pce-of-03.txt July 2008
objective function (should a path satisfying the constraints be found)
in the PCRep message. When set in a PCRep message this indicates that
the Objective Function that was used during path computation is
included.
3.3.1. Elements Of Procedure
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
the RP object.
On receipt of a PCReq message with the OF flag in the RP object set,
the PCE proceeds as follows:
- If policy permits it MUST include in the PCRep message an OF
object indicating the objective function it used during path
computation.
- 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 "objective function indication not allowed"
(defined in this document).
4. Objective Functions Definition
Six objective functions that must be supported by PCEP are listed in
[RFC4657]. Objective function codes should be assigned by IANA and
are suggested below.
Objective functions are formulated using the following terminology:
- 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 noted M(L), this can be the IGP metric the
TE metric, or any other metric.
- the cost of a path P is noted C(P),
C(P) = sum {M(Lpi), (i=1...K)}.
- residual bandwidth on link L is noted r(L)
- maximum reservable bandwidth on link L is noted R(L).
There are three objective functions that apply to the computation of
a single path:
Objective Function Code: 1 (suggested value, to be assigned by IANA)
Name: Minimum Cost Path (MCP)
Description: Find a path P such that C(P) is minimized.
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
Le Roux, Vasseur, Lee Encoding of Objective Functions in PCEP [Page 11]
Internet Draft draft-ietf-pce-of-03.txt July 2008
Objective Function Code: 3 (suggested value, to be assigned by IANA)
Name: Maximum residual Bandwidth Path (MBP)
Description: Find a path P such that ( Min { r(Lpi)), i=1...K } ) is
maximized.
There are three objective functions that apply to a set of path
computation requests the computation of which is synchronized:
Objective Function Code: 4 (suggested value, to be assigned by IANA)
Name: Minimize aggregate Bandwidth Consumption (MBC)
Description: Find a set of paths such that ( Sum {R(Li) - r(Li),
i=1...N} ) is minimized.
Objective Function Code: 5 (suggested value, to be assigned by IANA)
Name: Minimize the Load of the most loaded Link (MLL)
Description: Find a set of paths such that ( Max { (R(Li) - r(Li)) /
R(Li), i=1...N}) is minimized.
Objective Function Code: 6 (suggested value, to be assigned by IANA)
Name: Minimize the Cumulative Cost of a set of paths (MCC)
Description: Find a set of paths {P1...Pm} such that (Sum { C(Pi),
i=1...m}) is minimized.
Other objective functions may be defined in separate documents.
5. New Metric Types
Three metric types are defined in PCEP for the METRIC object: TE
metric, IGP metric and hop count. These metric types apply to an
individual request. Here we define four new metric types that apply
to a set of synchronized requests:
Type 4 (suggested value to be assigned by IANA) : Aggregate bandwidth
consumption
Type 5 (suggested value to be assigned by IANA) : Load of the most
loaded link
Type 6 (suggested value to be assigned by IANA) : Cumulative IGP
cost
Type 7 (suggested value to be assigned by IANA) : Cumulative TE cost
These metrics may be used to indicate a bound (B bit set in the
METRIC object) or a computed metric (C bit set in the METRIC object).
A METRIC object with one of these four types follows the SVEC object
for which it applies.
Le Roux, Vasseur, Lee Encoding of Objective Functions in PCEP [Page 12]
Internet Draft draft-ietf-pce-of-03.txt July 2008
6. IANA Considerations
6.1. PCE Objective Function Sub-registry
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 TLV.
IANA is requested to create and manage the 16-bit "PCE Objective
Function" code point registry, starting from 1 and continuing through
32767, as follows:
- Objective Function code point value
- Objective Function name
- Defining RFC
The same registry is applicable to the OF object and the OF-List TLV
defined in this document.
The guidelines (using terms defined in [RFC5226]) for the
assignment of objective function code point values are as follows:
- Function code value 0 is reserved.
- Function code values in the range 1-32767 are to be assigned as
follows:
- Function code values 1 through 1023 are to be assigned by
IANA using the "IETF Consensus" policy.
- Function code values 1024 through 32767 are to be
assigned by IANA, using the "First Come First Served"
policy.
- Function code values in the range 32768-65535 are for
"Private Use".
Six objective functions are defined in Section 4 of this document and
should be assigned by IANA:
Code Point Name Defining RFC
1 MCP this doc
2 MLP this doc
3 MBP this doc
4 MBC this doc
5 MLL this doc
6 MCC this doc
Le Roux, Vasseur, Lee Encoding of Objective Functions in PCEP [Page 13]
Internet Draft draft-ietf-pce-of-03.txt July 2008
6.2. PCEP Code Points
6.2.1. OF Object
The IANA has been requested to manage the PCEP Objects code point
registry (see [PCEP]).
This document defines a new PCEP object, the OF object, to be
carried in PCReq and PCRep messages. The IANA is requested to make
the following allocation (suggested value):
Object Name Object Name Reference
Class Type
21 OF 1 Objective (this document)
Function
6.2.2. OF-List TLV
IANA is requested to manage the PCEP TLV code point registry (see
[PCEP]).
This document defines a new PCEP TLV, the OF-List TLV, to be carried
in the OPEN object. The IANA is requested to make the following
allocation (suggested value):
Type TLV name References
----- -------- ----------
4 OF-List (This document)
6.2.3. PCEP Error values
Two new error values are defined for the error type "policy
violation" (type 5):
Error-type Meaning and error values Reference
5 Policy violation
Error-value=3: objective function not allowed (this doc)
(request rejected)
Error-value=4: OF bit of the RP object set (this doc)
(request rejected)
6.2.4. RP Object Flag
A new flag of the RP object (specified in [PCEP]) is defined in this
document. The IANA is requested to make the following allocation
(suggested value):
Le Roux, Vasseur, Lee Encoding of Objective Functions in PCEP [Page 14]
Internet Draft draft-ietf-pce-of-03.txt July 2008
Bit Hex Name Reference
Number
16 0x200 OF (this document)
6.2.5. Metric Types
Four new metric types are defined in this document for the METRIC
object (specified in [PCEP]). The IANA is requested to make the
following allocation (suggested values):
-Type 4 : Aggregate bandwidth consumption
-Type 5 : Load of the most loaded link
-Type 6 : Cumulative IGP cost
-Type 7 : Cumulative TE cost
7. Security Considerations
Mechanisms discussed in [PCEP] to secure a PCEP session can be used to
secure the PCEP OF object and OF list TLV as well.
8. Manageability Considerations
8.1. Control of Function and Policy
It MUST be possible to configure the activation/deactivation of
Objective Function Discovery in PCEP.
In addition to the parameters already listed in section 8.1 of [PCEP],
a PCEP implementation SHOULD allow configuring on a PCE a list of
authorized objective functions. This may apply to any session the
PCEP speaker participates in, to a specific session with a given PCEP
peer or to a specific group of sessions with a specific group of PCEP
peers.
Note that it is not mandatory for an implementation to support all
objective functions defined in Section 4.
It MUST be possible to configure a default objective function used
for path computation when a path request is received that requests to
use an optional objective function.
8.2. Information and Data Models
The PCEP MIB Module defined in [PCEP-MIB] SHOULD be extended to
include Objective Functions.
Le Roux, Vasseur, Lee Encoding of Objective Functions in PCEP [Page 15]
Internet Draft draft-ietf-pce-of-03.txt July 2008
8.3. Liveness Detection and Monitoring
Mechanisms defined in this document do not imply any new liveness
detection and monitoring requirements in addition to those already
listed in [PCEP].
8.4. Verify Correct Operations
Mechanisms defined in this document do not imply any new operation
verification requirements in addition to those already listed in
[PCEP].
8.5. Requirements On Other Protocols
Mechanisms defined in this document do not imply any requirements on
other protocols in addition to those already listed in [PCEP].
8.6. Impact On Network Operations
Mechanisms defined in this document do not have any impact on network
operations in addition to those already listed in [PCEP].
9. Acknowledgments
The authors would like to thank Jerry Ash, Fabien Verhaeghe and
Adrian Farrel for their useful comments.
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4655] Farrel, A., Vasseur, J.P., Ash, J., "Path Computation
Element (PCE)-based Architecture", RFC4655, august 2006.
[PCEP] Vasseur, Le Roux, et al., "Path Computation Element (PCE)
communication Protocol (PCEP)", draft-ietf-pce-pcep, work in
progress.
10.2. Informative References
[RFC4657] Ash, J., Le Roux, J.L., " PCE Communication Protocol
Generic Requirements", RFC4657, September 2006.
[RFC4674] Le Roux, J.L., et al. "Requirements for PCE discovery",
RFC4674, October 2006.
Le Roux, Vasseur, Lee Encoding of Objective Functions in PCEP [Page 16]
Internet Draft draft-ietf-pce-of-03.txt July 2008
[RFC5089] Le Roux, Vasseur, et al. "IS-IS protocol extensions for
Path Computation Element (PCE) Discovery", RFC5088, January 2008.
[RFC5088] Le Roux, Vasseur, et al. "OSPF protocol extensions for
Path Computation Element (PCE) Discovery", RFC5088, January 2008.
[PCE-GCO] Y. Lee, J.L. Le Roux, D. King, and E. Oki, "Path
Computation Element Communication Protocol (PCECP) Requirements and
Protocol Extensions In Support of Global Concurrent Optimization",
draft-ietf-pce-global-concurrent-optimization, work in
progress.
11. Authors' Addresses
Jean-Louis Le Roux
France Telecom
2, avenue Pierre-Marzin
22307 Lannion Cedex
FRANCE
Email: jeanlouis.leroux@orange-ftgroup.com
Jean-Philippe Vasseur
Cisco Systems, Inc.
1414 Massachusetts avenue
Boxborough , MA - 01719
USA
Email: jpv@cisco.com
Young Lee
Huawei Technologies, LTD.
1700 Alma Drive, Suite 100
Plano, TX 75075
USA
Email: ylee@huawei.com
12. Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
Le Roux, Vasseur, Lee Encoding of Objective Functions in PCEP [Page 17]
Internet Draft draft-ietf-pce-of-03.txt July 2008
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
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided
on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The IETF Trust (2008). This document is subject to the
rights, licenses and restrictions contained in BCP 78, and except as
set forth therein, the authors retain all their rights.
Le Roux, Vasseur, Lee Encoding of Objective Functions in PCEP [Page 18]
