draft-ietf-pce-of-05.txt   draft-ietf-pce-of-06.txt 
Network Working Group J.L. Le Roux Network Working Group J.L. Le Roux
Internet Draft France Telecom Internet Draft France Telecom
Category: Standard Track Category: Standard Track
Created: September 6, 2008 J.P. Vasseur Created: December 27, 2008 J.P. Vasseur
Expires: March 6, 2009 Cisco System Inc. Expires: June 27, 2009 Cisco System Inc.
Y. Lee Y. Lee
Huawei Huawei
Encoding of Objective Functions in the Path Computation Element Encoding of Objective Functions in the Path Computation Element
Communication Protocol (PCEP) Communication Protocol (PCEP)
draft-ietf-pce-of-05.txt draft-ietf-pce-of-06.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with
applicable patent or other IPR claims of which he or she is aware the provisions of BCP 78 and BCP 79.
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 Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
skipping to change at page 2, line 12 skipping to change at page 2, line 12
automatically discover the set of objective functions supported by 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 so
that a PCE can report in a path computation reply the objective that a PCE can report in a path computation reply the objective
function that was used for path computation. function that was used for path computation.
This document defines objective function code types for six
objective functions previously listed in the PCE requirments work,
and provides the definition of four new metric types that apply to a
set of synchronized requests.
Table of Contents Table of Contents
1. Introduction................................................3 1. Introduction................................................3
1.1. Terminology.................................................4 1.1. Terminology.................................................4
1.2. Message Formats.............................................5 1.2. Message Formats.............................................5
2. Discovery of PCE Objective Functions........................5 2. Discovery of PCE Objective Functions........................5
2.1. OF-List TLV.................................................5 2.1. OF-List TLV.................................................5
2.2. Elements of procedure.......................................6 2.2. Elements of procedure.......................................6
3. Objective Function in PCEP Path Computation Request and 3. Objective Function in PCEP Path Computation Request and
Reply Messages............................................6 Reply Messages............................................6
3.1. OF Object...................................................6 3.1. OF Object...................................................6
3.1.1. Elements of Procedure.......................................7 3.1.1. Elements of Procedure.......................................7
3.2. Carrying The OF Object In a PCEP Message....................8 3.2. Carrying The OF Object In a PCEP Message....................8
3.3. New RP Object Flag.........................................10 3.3. New RP Object Flag.........................................10
3.3.1. Elements Of Procedure......................................10 3.3.1. Elements Of Procedure......................................10
4. Objective Functions Definition.............................11 4. Objective Functions Definition.............................11
5. New Metric Types...........................................12 5. New Metric Types...........................................12
6. IANA Considerations........................................13 6. IANA Considerations........................................13
6.1. PCE Objective Function Sub-registry........................13 6.1. PCE Objective Function Sub-registry........................13
6.2. PCEP Code Points...........................................13 6.2. PCEP Code Points...........................................14
6.2.1. OF Object..................................................13 6.2.1. OF Object..................................................14
6.2.2. OF-List TLV................................................14 6.2.2. OF-List TLV................................................14
6.2.3. PCEP Error values..........................................14 6.2.3. PCEP Error values..........................................15
6.2.4. RP Object Flag.............................................14 6.2.4. RP Object Flag.............................................15
6.2.5. Metric Types...............................................15 6.2.5. Metric Types...............................................15
7. Security Considerations....................................15 7. Security Considerations....................................16
8. Manageability Considerations...............................15 8. Manageability Considerations...............................16
8.1. Control of Function and Policy.............................15 8.1. Control of Function and Policy.............................16
8.2. Information and Data Models................................15 8.2. Information and Data Models................................16
8.3. Liveness Detection and Monitoring..........................15 8.3. Liveness Detection and Monitoring..........................16
8.4. Verify Correct Operations..................................16 8.4. Verify Correct Operations..................................17
8.5. Requirements On Other Protocols............................16 8.5. Requirements On Other Protocols............................17
8.6. Impact On Network Operations...............................16 8.6. Impact On Network Operations...............................17
9. Acknowledgments............................................16 9. Acknowledgments............................................17
10. References.................................................16 10. References.................................................17
10.1. Normative Feferences.......................................16 10.1. Normative Feferences.......................................17
10.2. Informative References.....................................16 10.2. Informative References.....................................17
11. Authors' Addresses.........................................17 11. Authors' Addresses.........................................18
12. Intellectual Property Statement............................17
Conventions used in this document Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. 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]
skipping to change at page 7, line 18 skipping to change at page 7, line 18
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 | |Objective Function Code(IANA) | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
// Optional TLV(s) // // Optional TLV(s) //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Objective Function Code (2 bytes): The identifier of the Objective Objective Function Code (2 bytes): The identifier of the Objective
Function. The IANA is requested to manage the PCE objective function Function. IANA is requested to manage the PCE objective function code
code point registry (see Section 6). point registry (see Section 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
skipping to change at page 8, line 50 skipping to change at page 8, line 50
be repeated for each elementary request. Note that metrics applied to be repeated for each elementary request. Note that metrics applied to
a set of synchronized requests are defined in section 5. 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:
<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>]
<request-list> ::= <request> [<request-list>] <request-list> ::= <request> [<request-list>]
<request> ::= <RP> <request> ::= <RP>
<END-POINTS> <END-POINTS>
[<LSPA>] [<LSPA>]
[<BANDWIDTH>] [<BANDWIDTH>]
[<metric-list>] [<metric-list>]
[<OF>] [<OF>]
[<RRO>] [<RRO>[<BANDWIDTH>]]
[<IRO>] [<IRO>]
[<LOAD-BALANCING>] [<LOAD-BALANCING>]
and where: and where:
<metric-list> ::= <METRIC>[<metric-list>] <metric-list> ::= <METRIC>[<metric-list>]
The OF object MAY be carried within a PCRep message to indicate the The OF object MAY be carried within a PCRep message to indicate the
objective function used by the PCE during path computation. objective function used by the PCE during path computation.
skipping to change at page 10, line 8 skipping to change at page 10, line 8
where: where:
<svec-list> ::= <SVEC> <svec-list> ::= <SVEC>
[<OF>] [<OF>]
[<metric-list>] [<metric-list>]
[<svec-list>] [<svec-list>]
<response-list> ::= <response> [<response-list>] <response-list> ::= <response> [<response-list>]
<response> ::= <RP> <response> ::= <RP>
[<NO-PATH>] [<NO-PATH>]
[<attribute-list>]
[<path-list>] [<path-list>]
<path-list> ::= <path> [<path-list>] <path-list> ::= <path> [<path-list>]
<path> ::= <ERO> <path> ::= <ERO>
[<OF>] <attribute-list>
and where:
<attribute-list> ::= [<OF>]
[<LSPA>] [<LSPA>]
[<BANDWIDTH>] [<BANDWIDTH>]
[<metric-list>] [<metric-list>]
[<IRO>] [<IRO>]
and where:
<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 (1 bit): 0x200 (bit number 16) Objective Function (OF) flag (bit number 24) (suggested value, to be
(suggested value, to be assigned by IANA). 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 object
indicating the objective function it used during path computation. 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" (defined in this
document). document).
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
Section 7.4.1 of [PCEP], the legacy PCE will ignore the unknown flag
resulting in it sending a PCRep that does not contain an OF object.
In this case, the PCC's beahvior is an implementation choice. The PCC
might:
- Discard the PCRep because it really wanted the OF object returned.
- Accept the PCRep without the knowledge of the OF that was applied.
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
Function identifier that the PCC does not recognize. In this
situation the PCC behavior is dependent on implementaiton and
configuration. The PCC could choose any of the following (or some
other action):
- Ignore the OF object and use the computed path.
- Add the Objective Function to its view of the PCE's repetoire for
inclusion in future computation requests.
- Discard the PCRep (i.e., the computed path) and send a PCReq to
another PCE.
- Discard the PCRep (i.e., the computed path) and send another PCReq
to the same PCE explicitly requiring the use of some other
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 should be assigned by IANA and
are suggested below. are suggested 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)} - a path P is a list of K links {Lpi,(i=1...K)}
skipping to change at page 11, line 42 skipping to change at page 12, line 17
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 (suggested value, to be assigned by IANA)
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 (suggested value, to be assigned by IANA)
Name: Minimum Load Path (MLP) Name: Minimum Load Path (MLP)
Description: Find a path P such that ( Max {(R(Lpi) - r(Lpi)) / Description: Find a path P such that
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 (suggested value, to be assigned by IANA)
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 ( Min { r(Lpi), i=1...K } ) is
maximized. 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 (suggested value, to be assigned by IANA)
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 ( Sum {R(Li) - r(Li),
i=1...N} ) is minimized. i=1...N} ) is minimized.
skipping to change at page 13, line 53 skipping to change at page 14, line 21
2 MLP this doc 2 MLP this doc
3 MBP this doc 3 MBP this doc
4 MBC this doc 4 MBC this doc
5 MLL this doc 5 MLL this doc
6 MCC this doc 6 MCC this doc
6.2. PCEP Code Points 6.2. PCEP Code Points
6.2.1. OF Object 6.2.1. OF Object
The IANA has been requested to manage the PCEP Objects code point IANA manages the PCEP Objects code point registry (see [PCEP]). This
registry (see [PCEP]). is maintained as the "PCEP Objects" sub-registry of the "Path
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. The IANA is requested to make the in PCReq and PCRep messages. IANA is requested to make the following
following allocation (suggested value): 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 (this document)
6.2.2. OF-List TLV 6.2.2. OF-List TLV
IANA is requested to manage the PCEP TLV code point registry (see IANA manages the PCEP TLV code point registry (see [PCEP]). This is
[PCEP]). maintained as the "PCEP TLV Type Indicators" sub-registry of the
"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. The IANA is requested to make the following in the OPEN object. IANA is requested to make the following
allocation (suggested value): allocation (suggested value):
Type TLV name References Type TLV name References
----- -------- ---------- ----- -------- ----------
4 OF-List (This document) 4 OF-List (This document)
6.2.3. PCEP Error values 6.2.3. PCEP Error values
Two new error values are defined for the error type "policy IANA maintains a registry of Error-types and Error-values for use in
PCEP messages. This is maintained as the "PCEP-ERROR Object Error
Types and Values" sub-registry of the "Path Computation Element
Protocol (PCEP) Numbers" registry.
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 (this doc) 5 Policy violation
Error-value=3: objective function not (this doc) Error-value=3: objective function not (this doc)
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 (this doc)
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 [PCEP]) is defined in this
document. The IANA is requested to make the following allocation document. IANA maintains a registry of RP object flags in the "RP
(suggested value): Object Flag Field" sub-registry of the "Path Computation Element
Protocol (PCEP) Numbers" registry.
Bit Hex Name Reference IANA is requested to make the following allocation (suggested value):
Number
16 0x200 OF (this document) Bit Description Reference
24 Supply OF on response This document
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]). The IANA is requested to make the object (specified in [PCEP]). IANA maintains a registry of metric
following allocation (suggested values): types in the "METRIC Object T Field" sub-registry of the "Path
Computation Element Protocol (PCEP) Numbers" registry.
IANA is requested to make the following allocation (suggested
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
Mechanisms discussed in [PCEP] to secure a PCEP session can be used PCEP security mechanisms are described in [PCEP] and are used to
to secure the PCEP OF object and OF list TLV as well. secure entire PCEP messages. Nothing in this document changes the
message flows or introduces any new messages, so the security
mechanisms set out in [PCEP] continue to be applicable.
This document introduces a single new object that may optionally be
carried on PCEP messages and will be automatically secured using the
mechanims described in [PCEP].
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
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
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 [PCEP], a PCEP implementation SHOULD allow configuring on a PCE a
skipping to change at page 15, line 44 skipping to change at page 16, line 45
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] SHOULD 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 [PCEP].
8.4. Verify Correct Operations 8.4. Verify Correct Operations
skipping to change at page 16, line 23 skipping to change at page 17, line 23
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 [PCEP].
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 [PCEP].
9. Acknowledgments 9. Acknowledgments
The authors would like to thank Jerry Ash, Fabien Verhaeghe, and The authors would like to thank Jerry Ash, Fabien Verhaeghe,
Adrian Farrel for their useful comments. Robert 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., Ash, J., "Path Computation
Element (PCE)-based Architecture", RFC4655, august 2006. Element (PCE)-based Architecture", RFC4655, august 2006.
skipping to change at page 17, line 46 skipping to change at page 18, line 50
USA USA
Email: jpv@cisco.com Email: jpv@cisco.com
Young Lee Young Lee
Huawei Technologies, LTD. Huawei Technologies, LTD.
1700 Alma Drive, Suite 100 1700 Alma Drive, Suite 100
Plano, TX 75075 Plano, TX 75075
USA USA
Email: ylee@huawei.com Email: ylee@huawei.com
12. Intellectual Property Statement Full Copyright 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 Copyright (c) 2008 IETF Trust and the persons identified as the
copyrights, patents or patent applications, or other proprietary document authors. All rights reserved.
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 is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.
This document and the information contained herein are provided All IETF Documents and the information contained therein are provided
on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE. FOR A PARTICULAR PURPOSE.
Copyright Statement Intellectual Property
Copyright (C) The IETF Trust (2008). This document is subject to the The IETF Trust takes no position regarding the validity or scope of
rights, licenses and restrictions contained in BCP 78, and except as any Intellectual Property Rights or other rights that might be
set forth therein, the authors retain all their rights. claimed to pertain to the implementation or use of the technology
described in any IETF 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.
Copies of Intellectual Property 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
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
any standard or specification contained in an IETF Document. Please
address the information to the IETF at ietf-ipr@ietf.org.
The definitive version of an IETF Document is that published by, or
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
Process licenses each Contribution that he or she makes as part of
the IETF Standards Process to the IETF Trust pursuant to the
provisions of RFC 5378. No language to the contrary, or terms,
conditions or rights that differ from or are inconsistent with the
rights and licenses granted under RFC 5378, shall have any effect and
shall be null and void, whether published or posted by such
Contributor, or included with or in such Contribution.
 End of changes. 37 change blocks. 
89 lines changed or deleted 129 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/