 1/draftietfpceof03.txt 20080805 19:12:48.000000000 +0200
+++ 2/draftietfpceof04.txt 20080805 19:12:48.000000000 +0200
@@ 1,23 +1,23 @@

Network Working Group J.L. Le Roux
Internet Draft France Telecom
Category: Standard Track
Expires: January 2009 J.P. Vasseur
 Cisco System Inc.
+Created: August 5, 2008 J.P. Vasseur
+Expires: February 5, 2009 Cisco System Inc.
Y. Lee
Huawei
 Encoding of Objective Functions in Path Computation Element
 communication Protocol (PCEP)
 draftietfpceof03.txt
+ Encoding of Objective Functions in the Path Computation Element
+ Communication Protocol (PCEP)
+
+ draftietfpceof04.txt
Status of this Memo
By submitting this InternetDraft, 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.
InternetDrafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
@@ 32,109 +32,90 @@
http://www.ietf.org/ietf/1idabstracts.txt.
The list of InternetDraft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
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
+ specific optimization criteria, referred to as objective functions
(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.
+
+ In the Path Computation Element (PCE) architecture, a Path
+ Computation Client (PCC) may want a path to be computed for one or
+ more TE LSPs according to a specific objective function. Thus, the
+ PCC needs to instruct the PCE to use the correct objective function.
+ Furthermore, it is possible that not all PCEs support the same set of
+ objective functions, therefore it is useful for the PCC to be able to
+ automatically discover the set of objective functions supported by
+ each PCE.
+
This document defines extensions to the PCE communication Protocol
(PCEP) to allow a PCE to indicate the set of objective functions it
supports. Extensions are also defined so that a PCC can indicate in
a path computation request the required objective function, and 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 RFC2119.

Table of Contents
 Terminology.........................................................3
1. Introduction................................................3
+ 1.1. Terminology.................................................4
2. Discovery of PCE Objective Functions........................5
2.1. OFList 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
+ 3.3.1. Elements Of Procedure......................................10
4. Objective Functions Definition.............................11
5. New Metric Types...........................................12
6. IANA Considerations........................................13
6.1. PCE Objective Function Subregistry........................13
 6.2. PCEP Code Points...........................................14
 6.2.1. OF Object..................................................14
+ 6.2. PCEP Code Points...........................................13
+ 6.2.1. OF Object..................................................13
6.2.2. OFList TLV................................................14
6.2.3. PCEP Error values..........................................14
6.2.4. RP Object Flag.............................................14
6.2.5. Metric Types...............................................15
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.3. Liveness Detection and Monitoring..........................15
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.
+Conventions used in this document
 TE LSP: Traffic Engineered Label Switched Path.
+ 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
 The PCEbased 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
+ The Path Computation Elementbased network architecture [RFC4655]
+ defines a Path Computation Element (PCE) as an entity capable of
+ computing the paths of Traffic Engineered Label Switched Paths (TE
+ LSPs) based on a network graph, and 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
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
@@ 142,65 +123,86 @@
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 nonsynchronized 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
+ 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 ISIS and OSPF based PCE Discovery mechanisms are defined
+ Note that ISIS and OSPFbased 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 OFList TLV is defined in Section 2. The
OFList 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.
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 [PCEGCO]. This document also
 provides, in Section 5, the definition of four new metric types that
 apply to a set of synchronized requests.
+ listed in [RFC4657]. This document provides a definition of these six
+ mandatory objective functions. Additional objective functions may be
+ defined in other documents. Note that additional objective functions
+ are defined for PCE Global Concurrent Optimization (GCO) application,
+ in [PCEGCO].
+
+ This document also provides the definition of four new metric types
+ that apply to a set of synchronized requests.
+
+1.1. Terminology
+
+ LSR: Label Switching Router.
+
+ OF: Objective Function: A set of one or more optimization criteria
+ used for the computation of a single path (e.g. path cost
+ minimization), or 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.
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 OFList (Objective Function list) TLV is defined. The PCEP
OFList 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.
@@ 308,83 +310,81 @@
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.
+ 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.
+ [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.
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.
+ 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
+ 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 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 "policyviolation"
 (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 permit
+ applying it, and the P bit is set, the PCE MUST send a PCErr
+ message with the PCEP error type "policyviolation" (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 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.
+  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
+ requests, the METRIC object MUST follow the SVEC object and MUST NOT
be repeated for each elementary request. Note that metrics applied to
a set of synchronized requests are defined in section 5.
An OF object specifying an objective function that applies to an
individual path computation request (non synchronized case) MUST
follow the RP object for which it applies.
The format of the PCReq message is updated as follows:
::=
@@ 401,21 +400,22 @@
::=