Network Working Group J.L. Le Roux
Internet Draft France Telecom
Category: Standard Track
Expires: September 2007 J.P. Vasseur
Cisco System Inc.
Y. Lee
Huawei
March 2007
Encoding of Objective Functions in Path Computation Element (PCE)
communication and discovery protocols
draft-leroux-pce-of-00.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 PCE Objective Functions Encoding [Page 1]
Internet Draft draft-leroux-pce-of-00.txt March 2007
Abstract
The computation of one or a series of Traffic Engineering Label
Switched Paths (TE LSP) in MultiProtocol Label Switching (MPLS) and
Generalized MPLS (GMPLS) networks, is subject to a set of one or more
specific optimization criteria(s), referred to as an objective
function (e.g. minimum cost path, widest path, etc.). A Path
Computation Element (PCE) may support one or multiple objective
functions, and it is desired for a Path Computation Client (PCC) to
automatically discover the set of objective functions supported by a
PCE. Furthermore, it may be useful for a PCC to specify in a path
computation request the required objective function used by the PCE
to compute a TE LSP or a set of TE LSPs. Thus the aim of this
document is to define extensions to the PCE Discovery (PCED) TLV
carried within the IS-IS Router Capability TLV and the OSPF Router
Information LSA so as to allow a PCC to discover the set of objective
functions supported by a PCE. Extensions to the PCE communication
Protocol (PCEP) are also specified allowing a PCC to indicate in a
path computation request the required objective function and a PCE to
indicate in a path computation reply the objective function actually
applied. The definition of objective functions is beyond the scope of
this document and will be covered in separate documents.
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
1. Terminology.................................................3
2. Introduction................................................4
3. PCE Discovery Extensions....................................5
3.1. IS-IS PCED Extensions.......................................5
3.1.1. IS-IS OF-List sub-TLV.......................................5
3.1.2. Elements of Procedure.......................................6
3.2. OSPF PCED Extensions........................................6
3.2.1. OSPF OF-List sub-TLV........................................6
3.2.2. Elements of Procedure.......................................7
4. PCEP Extensions.............................................8
4.1. OF Object...................................................8
4.1.1. Elements of Procedure.......................................9
4.2. Carrying the OF Object in a PCEP Message...................10
4.3. New RP Object Flag.........................................11
4.3.1. Elements of Procedure......................................12
5. IANA Considerations........................................12
5.1. PCE Objective Function Registry............................12
5.2. PCEP Code Points...........................................13
5.2.1. OF Object..................................................13
5.2.2. OF Object TLV Space........................................13
Le Roux, Vasseur, Lee PCE Objective Functions Encoding [Page 2]
Internet Draft draft-leroux-pce-of-00.txt March 2007
5.2.3. PCEP Error Values..........................................13
5.2.4. RP Object Flag.............................................14
5.3. IS-IS OF-List sub-TLV......................................14
5.4. OSPF OF-List sub-TLV.......................................14
6. Backward Compatibility.....................................15
7. Security Considerations....................................15
8. Manageability Considerations...............................15
9. Acknowledgments............................................15
10. References.................................................15
10.1. Normative References.......................................15
10.2. Informative References.....................................16
11. Author's Addresses:........................................16
12. Intellectual Property Statement............................16
1. Terminology
Terminology used in this document
IGP: Interior Gateway Protocol: Either of the two routing
protocols Open Shortest Path First (OSPF) or Intermediate System
to Intermediate system (IS-IS).
LSR: Label Switching Router.
OF: Objective Function: A set of one ore more optimization
criteria(s) 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.
PCED: PCE Discovery: Generic term to refer to a PCE Discovery
Mechanism.
IS-IS PCED: IS-IS based PCE Discovery.
OSPF PCED: OSFP based PCE Discovery.
PCEP: Path Computation Element communication Protocol.
TE LSP: Traffic Engineered Label Switched Path.
Le Roux, Vasseur, Lee PCE Objective Functions Encoding [Page 3]
Internet Draft draft-leroux-pce-of-00.txt March 2007
2. 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 serves 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 request and path
computation replies.
The IS-IS based PCE Discovery and OSFP based PCE Discovery mechanisms
defined respectively in [ISIS-PCED] and [OSPF-PCED], allow a PCC to
automatically discover a set of PCEs as well as some information
required for PCE selection, in compliance with requirements set forth
in [RFC4674].
The computation of one or a set of TE LSPs is subject to a set of one
or more optimization criteria(s), 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 path(s). 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
applies to a set of path computation requests the computation of
which is synchronized (e.g. minimize the aggregate bandwidth
consumption of all links, 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. For that purpose
this document specifies PCE Discovery (PCED) extensions in order to
allow a PCE advertising a list of supported objective functions.
As spelled out in [RFC4657], a PCC must be able to indicate in a path
computation request a required/desired objective function, as well as
optional function parameters. For that purpose this document extends
the PCE communication Protocol (PCEP), so as to carry the objective
function as well as function parameters. It thus complements the PCEP
specification.
Le Roux, Vasseur, Lee PCE Objective Functions Encoding [Page 4]
Internet Draft draft-leroux-pce-of-00.txt March 2007
Extensions to IS-IS and OSPF based PCE Discovery ([ISIS-PCED], [OSPF-
PCED]) are defined in section 3. A new sub-TLV, the OF-List sub-TLV
is defined, to be carried within the PCED TLV. It allows advertising
the list of objective functions supported by a PCE.
Extensions to PCEP ([PCEP]) are defined in section 4. A new PCEP
object, the OF object is defined, to be 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 actually applied by the PCE.
A common PCE Objective Function code point registry is defined for
both PCEP and PCED protocols, to be managed by IANA.
Note that the objective function examples provided above are just
listed for the sake of illustration and the aim of this document is
not to standardize such objective functions but rather to specify the
PCED and PCEP protocol extensions to discover the set of objective
functions supported by a PCE and to indicate in a path computation
request the objection function to be used and in a path computation
reply the objective function actually used. This document does not
define any objective functions. They will be defined in other
documents.
3. PCE Discovery Extensions
3.1. IS-IS PCED Extensions
3.1.1. IS-IS OF-List sub-TLV
The IS-IS Objective Function List (OF-List) sub-TLV is a new sub-TLV
carried within the IS-IS PCED sub-TLV defined in [ISIS-PCED]. It
allows advertising the list of objective functions supported by a
PCE.
The OF-List sub-TLV is an optional sub-TLV. It MAY be present
within the PCED sub-TLV. It MUST NOT be present more than once.
If present more than once, all instances except the first one MUST be
ignored.
The format of the IS-IS OF-List sub-TLV is the identical to the TLV
format used by the Traffic Engineering Extensions to IS-IS [RFC3784].
That is, the TLV is composed of 1 octet for the type, 1 octet
specifying the TLV length, and a value field. The Length field
defines the length of the value portion in octets.
Le Roux, Vasseur, Lee PCE Objective Functions Encoding [Page 5]
Internet Draft draft-leroux-pce-of-00.txt March 2007
The IS-IS OF-List sub-TLV has the following format:
TYPE: To be assigned by IANA (suggested value = 7)
LENGTH: N * 2 (where N is the number of objective functions)
VALUE: list of 2-bytes objective function code points,
identifying the supported objective functions.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OF Code #1 | OF Code #2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OF Code # N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
OF Code (2 bytes): Objective Function Identifier
The IANA is requested to manage the PCE objective function code point
registry (see IANA section).
3.1.2. Elements of Procedure
The OF-List sub-TLV is advertised within an IS-IS PCED sub-TLV
defined in [ISIS-PCED]. As such, elements of procedures are inherited
from those defined in [ISIS-PCED].
The OF-List sub-TLV is OPTIONAL. A PCE MAY include an OF-List sub-TLV
within the PCED sub-TLV so as to advertise a set of one or more
objective functions. When a PCED sub-TLV does not contain any OF-List
sub-TLV this means that the supported objective functions of that PCE
are unknown.
3.2. OSPF PCED Extensions
3.2.1. OSPF OF-List sub-TLV
The OSPF Objective Function List (OF-List) sub-TLV is a new sub-TLV
carried within the OSPF PCED TLV defined in [OSPF-PCED]. It allows
advertising the objectives function supported by a PCE. It includes a
list of 2-bytes objective function identifiers.
The OF-List sub-TLV is an optional TLV. It MAY be present
within the PCED TLV. It MUST NOT be present more than once.
If present more than once, all instances except the first one MUST be
ignored.
Le Roux, Vasseur, Lee PCE Objective Functions Encoding [Page 6]
Internet Draft draft-leroux-pce-of-00.txt March 2007
The format of the OSPF OF-List sub-TLV is the identical to the TLV
format used by the Traffic Engineering Extensions to OSPF
[RFC3630]. 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; padding is not included in the Length field
(so a two octet value would have a length of two, but the total size
of the TLV would be eight octets).
The OSPF OF-List sub-TLV has the following format:
TYPE: To be assigned by IANA (suggested value = 7)
LENGTH: N * 2 (where N is the number of objective functions)
VALUE: list of 2-bytes objective function code points,
identifying the supported objective functions.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OF Code #1 | OF Code #2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OF Code #N | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
OF Code (2 bytes): Objective Function Identifier
The IANA is requested to manage the PCE objective function code point
registry (see IANA section).
3.2.2. Elements of Procedure
The OF-List sub-TLV is advertised within an OSPF PCED TLV defined in
[OSPF-PCED]. As such, elements of procedures are inherited from those
defined in [OSPF-PCED].
The OF-List sub-TLV is OPTIONAL. A PCE MAY include an OF-List sub-TLV
within the PCED TLV so as to advertise a set of one or more objective
functions. When a PCED TLV does not contain any OF-List sub-TLV this
means that the supported objective functions of that PCE are unknown.
Le Roux, Vasseur, Lee PCE Objective Functions Encoding [Page 7]
Internet Draft draft-leroux-pce-of-00.txt March 2007
4. PCEP Extensions
This section defines extensions to PCEP ([PCEP]) so as to support the
communication of objective functions. 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
and within a PCRep message in order for the PCE to indicate the
objective function that has actually been applied by the PCE. A new
flag is defined in the RP object, so as to indicate in a PCRep
message that the inclusion of the objective function actually applied
by the PCE is required in the response. Also new PCEP error type and
value are defined.
4.1. OF Object
The PCEP OF (Objective Function) object is optional. It MAY be
carried within a PCReq message so as to indicate the desired/required
objective function to be applied by the PCE during path computation,
or within a PCRep message so as to indicate the objective function
that has been actually applied by the PCE.
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=18).
The OF Object-Types 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 IANA section).
Reserved (2 bytes): This field MUST be set to zero on transmission
and MUST be ignored on receipt.
Optional TLVs may be defined so as to encode objective function
parameters. The IANA is requested to create a registry for this TLVs'
name space.
Le Roux, Vasseur, Lee PCE Objective Functions Encoding [Page 8]
Internet Draft draft-leroux-pce-of-00.txt March 2007
4.1.1. Elements of Procedure
To specify an objective function to be applied by a PCE, a PCC MUST
include an OF object in the PCReq message.
A bit flag referred to as the P bit is defined in the common header
of each PCEP object that can be set by a PCC to enforce a PCE to take
into account the related information during the path computation. If
the objective function is mandatory (required objective function),
the P bit in the OF object MUST be set, else if it is optional
(desired objective function) the P bit MUST be cleared.
On receipt of a PCReq message with an OF object, a PCE has to 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 unknown/unsupported
object (type 3 and 4) else 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 a new PCEP
error type "objective function error" and error value
"unknown/unsupported objective function" (defined in this
document), 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.
Le Roux, Vasseur, Lee PCE Objective Functions Encoding [Page 9]
Internet Draft draft-leroux-pce-of-00.txt March 2007
4.2. Carrying the OF Object in a PCEP Message
The OF object MAY be carried within a PCReq message. An OF object
specifying an objective function that applies to a set of
synchronized path computation requests MUST be carried just after the
corresponding SVEC object, and MUST NOT be repeated for each
elementary request.
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>]
[<svec-list>]
<request-list>::=<request>[<request-list>]
<request>::= <RP>
<END-POINTS>
[<OF>]
[<LSPA>]
[<BANDWIDTH>]
[<metric-list>]
[<RRO>]
[<IRO>]
[<LOAD-BALANCING>]
where:
<metric-list>::=<METRIC>[<metric-list>]
Le Roux, Vasseur, Lee PCE Objective Functions Encoding [Page 10]
Internet Draft draft-leroux-pce-of-00.txt March 2007
The OF object MAY be carried within a PCRep message to indicate the
objective function that was actually applied by the PCE.
The format of the PCRep message is updated as follows:
<PCRep Message> ::= <Common Header>
<response-list>
where:
<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>]
4.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 bit cleared
in the OF object header) but the PCE does not follow the
recommendation, the PCC may desire to know the objective function
actually applied by the PCE. For that purpose, a new flag is defined
in the RP object, the OF flag, allowing a PCC to request for the
inclusion in the reply of the objective function actually applied by
the PCE.
The following new bit flag of the RP object is defined:
Objective Function (OF) flag (1 bit): 0x200 (suggested value, to be
assigned by IANA). When set in a PCReq message, this indicates that
the PCE must provide the applied 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 applied
by the PCE is included.
Le Roux, Vasseur, Lee PCE Objective Functions Encoding [Page 11]
Internet Draft draft-leroux-pce-of-00.txt March 2007
4.3.1. Elements of Procedure
If the PCC wants to know the objective function actually applied by a
PCE for a given request, it MUST set the OF flag in the RP object.
On receipt of a PCReq message with the OF flag in the RP object set,
the PCE has to proceed as follows:
- If policy permits it MUST include in the PCRep message an OF
object indicating the objective function it actually applied.
- 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).
5. IANA Considerations
5.1. PCE Objective Function Registry
This document defines a 16-bit PCE Objective Function identifier to
be carried within the PCEP OF object, as well as the ISIS and OSPF
OF-List sub-TLVs.
The 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 PCEP OF object and the ISIS
and OSPF OF-List sub-TLVs defined in this document.
The guidelines (using terms defined in [RFC2434]) for the
assignment of objective function code point values are as follows:
- Function code value 0 is reserved.
- Function code value 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".
Le Roux, Vasseur, Lee PCE Objective Functions Encoding [Page 12]
Internet Draft draft-leroux-pce-of-00.txt March 2007
5.2. PCEP Code Points
5.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
18 OF 1 Objective (this document)
Function
5.2.2. OF Object TLV Space
The new PCEP OF object referenced above includes optional TLVs that
encode objective function parameters. Each TLV includes a 16-bit type
identifier.
The IANA is requested to create a new registry, the "PCEP OF TLV"
registry, and manage TLV type identifiers as follows:
- TLV Type value
- TLV Name
- Defining RFC
Type values in the range 1-32767 are to be assigned as follows:
- Values 1 through 1023 are to be assigned by IANA using the
"IETF Consensus" policy.
- Values 1024 through 32767 are to be assigned by IANA, using the
"First Come First Served" policy.
Type values in the range 32768-65535 are for "Private Use".
5.2.3. PCEP Error Values
A new PCEP Error-Type is defined in this document, with two error
values (Error-Type and Error-value to be assigned by IANA):
Error-type Meaning and error values Reference
14 objective function error (this doc)
Error-value=1: unknown objective function
(request rejected)
Error-value=2: unsupported objective function
(request rejected)
Le Roux, Vasseur, Lee PCE Objective Functions Encoding [Page 13]
Internet Draft draft-leroux-pce-of-00.txt March 2007
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)
5.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):
Bit Hex Name Reference
Number
08 0x200 OF (this document)
When set, this indicates that the PCC requests the inclusion, in the
PCRep message, of the objective function actually used to compute the
path.
5.3. IS-IS OF-List sub-TLV
Once a registry for the IS-IS PCED sub-TLV defined in [ISIS-PCED]
will have been assigned, IANA will assign a new sub-TLV code-point
for the OF-List sub-TLV carried in the PCED sub-TLV. Here is the
suggested value:
Value TLV name References
----- -------- ----------
7 OF-List (This document)
5.4. OSPF OF-List sub-TLV
Once a registry for the OSPF PCED TLV defined in [OSPF-PCED] will
have been assigned, IANA will assign a new sub-TLV code-point for the
OF-List sub-TLV carried in the PCED TLV. Here is the suggested value:
Value TLV name References
----- -------- ----------
7 OF-List (This document)
Le Roux, Vasseur, Lee PCE Objective Functions Encoding [Page 14]
Internet Draft draft-leroux-pce-of-00.txt March 2007
6. Backward Compatibility
TBC
7. Security Considerations
TBC
8. Manageability Considerations
TBC
9. Acknowledgments
TBC
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.
[RFC2740] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6",
RFC 2740, December 1999.
[RFC3630] Katz, D., Yeung, D., Kompella, K., "Traffic Engineering
Extensions to OSPF Version 2", RFC 3630, September 2003.
[RFC3784] Li, T., Smit, H., "IS-IS extensions for Traffic
Engineering", RFC 3784, June 2004.
[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.
[ISIS-PCED] Le Roux, Vasseur, et al. "IS-IS protocol extensions for
Path Computation Element (PCE) Discovery", draft-ietf-pce-disco-
proto-isis, work in progress.
[OSPF-PCED] Le Roux, Vasseur, et al. "OSPF protocol extensions for
Path Computation Element (PCE) Discovery", draft-ietf-pce-disco-
proto-ospf, work in progress.
Le Roux, Vasseur, Lee PCE Objective Functions Encoding [Page 15]
Internet Draft draft-leroux-pce-of-00.txt March 2007
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.
11. Author's 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
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
Le Roux, Vasseur, Lee PCE Objective Functions Encoding [Page 16]
Internet Draft draft-leroux-pce-of-00.txt March 2007
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 (2007). 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 PCE Objective Functions Encoding [Page 17]