draft-ietf-pce-comm-protocol-gen-reqs-02.txt   draft-ietf-pce-comm-protocol-gen-reqs-03.txt 
IETF Internet Draft PCE Working Group Jerry Ash (AT&T) IETF Internet Draft PCE Working Group Jerry Ash (AT&T)
Proposed Status: Informational Editor Proposed Status: Informational Editor
Expires: March 2006 J.L. Le Roux (France Telecom) Expires: June 2006 J.L. Le Roux (France Telecom)
Editor Editor
September 2005 December 2005
draft-ietf-pce-comm-protocol-gen-reqs-02.txt draft-ietf-pce-comm-protocol-gen-reqs-03.txt
PCE Communication Protocol Generic Requirements PCE Communication Protocol Generic Requirements
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 20, 2006. This Internet-Draft will expire on June 20, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2005).
Abstract Abstract
The PCE model is described in the "PCE Architecture" document and The PCE model is described in the "PCE Architecture" document and
facilitates path computation requests from Path Computation Clients facilitates path computation requests from Path Computation Clients
(PCCs) to Path Computation Elements (PCEs). This document specifies (PCCs) to Path Computation Elements (PCEs). This document specifies
skipping to change at page 2, line 11 skipping to change at page 2, line 11
PCEs, and also between PCEs where cooperation between PCEs is PCEs, and also between PCEs where cooperation between PCEs is
desirable. Subsequent documents will specify application-specific desirable. Subsequent documents will specify application-specific
requirements for the PCE communication protocol. requirements for the PCE communication protocol.
Table of Contents Table of Contents
1. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions used in this document . . . . . . . . . . . . . . . . 3 2. Conventions used in this document . . . . . . . . . . . . . . . . 3
3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
5. Overview of PCE Communication Protocol (PCECP) . . . . . . . . . 4 5. Overview of PCE Communication Protocol (PCECP) . . . . . . . . . 5
6. PCE Communication Protocol Generic Requirements . . . . . . . . . 5 6. PCE Communication Protocol Generic Requirements . . . . . . . . . 6
6.1 Basic Protocol Requirements . . . . . . . . . . . . . . . . . 7 6.1 Basic Protocol Requirements . . . . . . . . . . . . . . . . . 8
6.1.1 Commonality of PCC-PCE and PCE-PCE Communication . . . 7 6.1.1 Commonality of PCC-PCE and PCE-PCE Communication . . . 8
6.1.2 Client-Server Communication . . . . . . . . . . . . . . 7 6.1.2 Client-Server Communication . . . . . . . . . . . . . . 8
6.1.3 Transport . . . . . . . . . . . . . . . . . . . . . . . 7 6.1.3 Transport . . . . . . . . . . . . . . . . . . . . . . . 8
6.1.4 Path Computation Requests . . . . . . . . . . . . . . . 8 6.1.4 Path Computation Requests . . . . . . . . . . . . . . . 8
6.1.5 Path Computation Responses . . . . . . . . . . . . . . 9 6.1.5 Path Computation Responses . . . . . . . . . . . . . . 9
6.1.6 Cancellation of Pending Requests . . . . . . . . . . . 9 6.1.6 Cancellation of Pending Requests . . . . . . . . . . . 10
6.1.7 Multiple Requests and Responses . . . . . . . . . . . . 9 6.1.7 Multiple Requests and Responses . . . . . . . . . . . . 10
6.1.8 Reliable Message Exchange . . . . . . . . . . . . . . . 10 6.1.8 Reliable Message Exchange . . . . . . . . . . . . . . . 11
6.1.9 Secure Message Exchange . . . . . . . . . . . . . . . . 11 6.1.9 Secure Message Exchange . . . . . . . . . . . . . . . . 11
6.1.10 Request Prioritization . . . . . . . . . . . . . . . . 11 6.1.10 Request Prioritization . . . . . . . . . . . . . . . . 12
6.1.11 Unsolicited Notifications . . . . . . . . . . . . . . 11 6.1.11 Unsolicited Notifications . . . . . . . . . . . . . . 12
6.1.12 Asynchronous Communication . . . . . . . . . . . . . . 11 6.1.12 Asynchronous Communication . . . . . . . . . . . . . . 12
6.1.13 Communication Overhead Minimization . . . . . . . . . 12 6.1.13 Communication Overhead Minimization . . . . . . . . . 12
6.1.14 Extensibility . . . . . . . . . . . . . . . . . . . . 12 6.1.14 Extensibility . . . . . . . . . . . . . . . . . . . . 13
6.1.15 Scalability . . . . . . . . . . . . . . . . . . . . . 13 6.1.15 Scalability . . . . . . . . . . . . . . . . . . . . . 13
6.1.16 Constraints . . . . . . . . . . . . . . . . . . . . . 13 6.1.16 Constraints . . . . . . . . . . . . . . . . . . . . . 14
6.2 Deployment Support Requirements . . . . . . . . . . . . . . . 14 6.1.17 Objective Functions Supported . . . . . . . . . . . . 15
6.2.1 Support for Different Service Provider Environments . . 14 6.2 Deployment Support Requirements . . . . . . . . . . . . . . . 15
6.2.2 Policy Support . . . . . . . . . . . . . . . . . . . . 14 6.2.1 Support for Different Service Provider Environments . . 15
6.3 Detection & Recovery Requirements . . . . . . . . . . . . . . 15 6.2.2 Policy Support . . . . . . . . . . . . . . . . . . . . 15
6.3.1 Aliveness Detection . . . . . . . . . . . . . . . . . . 15 6.3 Detection & Recovery Requirements . . . . . . . . . . . . . . 16
6.3.2 PCC/PCE Failure Response . . . . . . . . . . . . . . . 15 6.3.1 Aliveness Detection . . . . . . . . . . . . . . . . . . 16
6.3.3 Protocol Recovery . . . . . . . . . . . . . . . . . . . 15 6.3.2 PCC/PCE Failure Response . . . . . . . . . . . . . . . 16
7. Security Considerations . . . . . . . . . . . . . . . . . . . . . 16 6.3.3 Protocol Recovery . . . . . . . . . . . . . . . . . . . 16
8. Manageability Considerations . . . . . . . . . . . . . . . . . . 16 6.3.4 LSP Rerouting & Reoptimization . . . . . . . . . . . . 17
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . . 17 7. Security Considerations . . . . . . . . . . . . . . . . . . . . . 17
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 17 8. Manageability Considerations . . . . . . . . . . . . . . . . . . 18
11. Normative References . . . . . . . . . . . . . . . . . . . . . . 17 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . . 19
12. Informational References . . . . . . . . . . . . . . . . . . . . 17 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 19
13. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 11. Normative References . . . . . . . . . . . . . . . . . . . . . . 19
Intellectual Property Statement . . . . . . . . . . . . . . . . . . 19 12. Informational References . . . . . . . . . . . . . . . . . . . . 19
Disclaimer of Validity . . . . . . . . . . . . . . . . . . . . . . . 19 13. Authors' & Contributors' Addresses . . . . . . . . . . . . . . . 20
Copyright Statement . . . . . . . . . . . . . . . . . . . . . . . . 20 Intellectual Property Statement . . . . . . . . . . . . . . . . . . 21
Disclaimer of Validity . . . . . . . . . . . . . . . . . . . . . . . 21
Copyright Statement . . . . . . . . . . . . . . . . . . . . . . . . 22
1. Contributors 1. Contributors
This document is the result of the PCE Working Group PCE This document is the result of the PCE Working Group PCE
Communication Protocol (PCECP) requirements design team joint effort. Communication Protocol (PCECP) requirements design team joint effort.
The following are the design team member authors that contributed to The following are the design team member authors that contributed to
the present document: the present document:
Jerry Ash (AT&T) Jerry Ash (AT&T)
Alia Atlas (Google, Inc.) Alia Atlas (Google, Inc.)
skipping to change at page 5, line 41 skipping to change at page 5, line 41
Support unsolicited communication PCE-PCC SHOULD 6.1.2 Support unsolicited communication PCE-PCC SHOULD 6.1.2
Maintain PCC-PCE session NON-RQMT 6.1.2 Maintain PCC-PCE session NON-RQMT 6.1.2
Use of existing transport protocol MAY 6.1.3 Use of existing transport protocol MAY 6.1.3
Transport protocol satisfy reliability & security Transport protocol satisfy reliability & security
requirements MAY 6.1.3 requirements MAY 6.1.3
Transport protocol limits size of message MUST NOT 6.1.3 Transport protocol limits size of message MUST NOT 6.1.3
Support path computation requests MUST 6.1.4 Support path computation requests MUST 6.1.4
include source & destination include source & destination
support path constraints (e.g., bandwidth, hops, support path constraints (e.g., bandwidth, hops,
affinities) to include/exclude MUST 6.1.4 affinities) to include/exclude MUST 6.1.4
Support path reoptimization & inclusion of a
previously computed path MUST 6.1.4
Allow to select/prefer from advertised list of Allow to select/prefer from advertised list of
standard objective functions/options MUST 6.1.4 standard objective functions/options MUST 6.1.4
Allow to customize objective function/options MUST 6.1.4 Allow to customize objective function/options MUST 6.1.4
Allow indicating the metric type (IGP or TE) to
be used for shortest path selection MUST 6.1.4
Allow indicating the set of aggregate path
attributes required in response message MUST 6.1.4
Allow indicating if load-balancing is allowed MUST 6.1.4
Support path computation responses MUST 6.1.5 Support path computation responses MUST 6.1.5
Negative response support reasons for failure, Negative response support reasons for failure,
constraints to relax to achieve positive result SHOULD 6.1.5 constraints to relax to achieve positive result SHOULD 6.1.5
Support inclusion of set of aggregate path
attributes MUST 6.1.5
Support inclusion of set of computed paths of a
load-balancing path group, as well as their
respective bandwidth MUST 6.1.5
Cancellation of pending requests MUST 6.1.6 Cancellation of pending requests MUST 6.1.6
Multiple requests and responses MUST 6.1.7 Multiple requests and responses MUST 6.1.7
Limit by configuration number of requests within Limit by configuration number of requests within
a message MUST 6.1.7 a message MUST 6.1.7
Support multiple computed paths in response MUST 6.1.7 Support multiple computed paths in response MUST 6.1.7
Support "continuation correlation" where related Support "continuation correlation" where related
requests or computed paths cannot fit within one requests or computed paths cannot fit within one
message MUST 6.1.7 message MUST 6.1.7
Maximum message size & maximum number of requests Maximum message size & maximum number of requests
per message exchanged through PCE messages to PCC, per message exchanged through PCE messages to PCC,
skipping to change at page 6, line 53 skipping to change at page 7, line 10
inter-provider, multi-layer path & virtual network inter-provider, multi-layer path & virtual network
topology path computation MUST 6.1.14 topology path computation MUST 6.1.14
Easily extensible to support future applications Easily extensible to support future applications
not in scope (e.g., P2MP path computations) SHOULD 6.1.14 not in scope (e.g., P2MP path computations) SHOULD 6.1.14
Scalability at least linearly with increase in Scalability at least linearly with increase in
number of PCCs, PCEs, PCCs communicating with a number of PCCs, PCEs, PCCs communicating with a
single PCE, PCEs communicated to by a single PCC, single PCE, PCEs communicated to by a single PCC,
PCEs communicated to by another PCE, domains, path PCEs communicated to by another PCE, domains, path
requests, handling bursts of requests MUST 6.1.15 requests, handling bursts of requests MUST 6.1.15
Support path computation constraints MUST 6.1.16 Support path computation constraints MUST 6.1.16
Support "unsynchronized" & "synchronized"
objective functions MUST 6.1.17
Support different service provider environments Support different service provider environments
(e.g., MPLS-TE and GMPLS networks, centralized & (e.g., MPLS-TE and GMPLS networks, centralized &
distributed PCE path computation, single & distributed PCE path computation, single &
multiple PCE path computation) MUST 6.2.1 multiple PCE path computation) MUST 6.2.1
Policy support for policies to accept/reject Policy support for policies to accept/reject
requests, PCC to determine reason for rejection, requests, PCC to determine reason for rejection,
notification of policy violation MUST 6.2.2 notification of policy violation MUST 6.2.2
Aliveness detection of PCCs/PCEs, partner failure Aliveness detection of PCCs/PCEs, partner failure
detection MUST 6.3.1 detection MUST 6.3.1
PCC/PCE failure response procedures defined for PCC/PCE failure response procedures defined for
skipping to change at page 7, line 26 skipping to change at page 7, line 36
PCE able to clear pending requests from a PCC PCE able to clear pending requests from a PCC
(e.g. when it detects PCC failure or request (e.g. when it detects PCC failure or request
buffer full) must 6.3.2 buffer full) must 6.3.2
Protocol recovery support resynchronization of Protocol recovery support resynchronization of
information & requests between sender & receiver MUST 6.3.3 information & requests between sender & receiver MUST 6.3.3
Minimize repeat data transfer, allow PCE to Minimize repeat data transfer, allow PCE to
respond to computation requests issued before respond to computation requests issued before
failure without requests being re-issued SHOULD 6.3.3 failure without requests being re-issued SHOULD 6.3.3
Stateful PCE able to resynchronize/recover Stateful PCE able to resynchronize/recover
states (e.g., LSP status, paths) after restart SHOULD 6.3.3 states (e.g., LSP status, paths) after restart SHOULD 6.3.3
Allow indicating if computation is for LSP
restoration (support inclusion of previously
computed path & failed element) MUST 6.3.4
Support inclusion in response message of upper
bound of a random waiting time for further
requests MAY 6.3.4
Support path reoptimization & inclusion of a
previously computed path MUST 6.3.4
6.1 Basic Protocol Requirements 6.1 Basic Protocol Requirements
6.1.1 Commonality of PCC-PCE and PCE-PCE Communication 6.1.1 Commonality of PCC-PCE and PCE-PCE Communication
A single protocol MUST be defined for PCC-PCE and PCE-PCE A single protocol MUST be defined for PCC-PCE and PCE-PCE
communication. A PCE requesting a path from another PCE can be communication. A PCE requesting a path from another PCE can be
considered as a PCC. considered as a PCC.
6.1.2 Client-Server Communication 6.1.2 Client-Server Communication
skipping to change at page 8, line 31 skipping to change at page 8, line 52
The message MUST support the inclusion of a set of one or more path The message MUST support the inclusion of a set of one or more path
constraints, including the requested bandwidth or resources (hops, constraints, including the requested bandwidth or resources (hops,
affinities, etc.) to include/exclude (e.g., a PCC requests the PCE to affinities, etc.) to include/exclude (e.g., a PCC requests the PCE to
exclude points of failure in the computation of the new path if an exclude points of failure in the computation of the new path if an
LSP setup fails). The actual inclusion of constraints is a choice LSP setup fails). The actual inclusion of constraints is a choice
for the PCC issuing the request. A list of core constraints that for the PCC issuing the request. A list of core constraints that
MUST be supported by the PCECP is supplied in Section 6.1.16. MUST be supported by the PCECP is supplied in Section 6.1.16.
Specification of constraints must be future-proofed as described in Specification of constraints must be future-proofed as described in
Section 6.1.14. Section 6.1.14.
The path computation request message MUST support TE LSP path
reoptimization and the inclusion of a previously computed path. This
will help ensure optimal routing of a reoptimized path, since it will
allow the PCE to avoid double bandwidth accounting and help reduce
blocking issues.
The requester MUST be allowed to select or prefer from an advertised The requester MUST be allowed to select or prefer from an advertised
list or minimal subset of standard objective functions and functional list or minimal subset of standard objective functions and functional
options. An objective function is used by the PCE to compute a path options. An objective function is used by the PCE to compute a path
metric in order to select the best candidate paths (e.g., minimum hop metric in order to select the best candidate paths (e.g., minimum hop
path), and corresponds to the optimization criteria used for the path), and corresponds to the optimization criteria used for the
computation of one path, or the synchronized computation of a set of computation of one path, or the synchronized computation of a set of
paths. In case of unsynchronized path computation, this can be, for paths. In case of unsynchronized path computation, this can be, for
example, the path cost or the residual bandwidth on the most loaded example, the path cost or the residual bandwidth on the most loaded
path link. In case of synchronized path computation, this can be, path link. In case of synchronized path computation, this can be,
for example, the global bandwidth consumption or the residual for example, the global bandwidth consumption or the residual
bandwidth on the most loaded network link. bandwidth on the most loaded network link.
A list of core objective functions that MUST be supported by the
PCECP is supplied in Section 6.1.17. Specification of objective
functions MUST be future-proofed as described in Section 6.1.14.
The shortest path selection may rely either on the TE metric or on
the IGP metric [METRIC]. Hence the PCECP request message MUST allow
indicating the metric type (IGP or TE) to be used for shortest path
selection. It MUST also allow indicating the set of aggregate path
attributes (hop-count, cumulated TE-metric, cumulated IGP-Metric)
that are required in the PCECP response message.
The request message MUST allow indicating if load-balancing is
allowed or not. It MUST also include the maximum number of paths in
a load-balancing path group, and the minimum path bandwidth in a
load-balancing path group.
The requester SHOULD also be able to select a vendor-specific or The requester SHOULD also be able to select a vendor-specific or
experimental objective function or functional option. Furthermore, experimental objective function or functional option. Furthermore,
the requester MUST be allowed to customize the function/options in the requester MUST be allowed to customize the function/options in
use. That is, individual objective functions will often have use. That is, individual objective functions will often have
parameters to be set in the request from PCC to PCE. Specification parameters to be set in the request from PCC to PCE. Specification
of objective functions and objective parameters is required in the of objective functions and objective parameters is required in the
protocol extensibility specified in Section 6.1.14. protocol extensibility specified in Section 6.1.14.
Note that a PCC MAY send a request that is based on the set of TE Note that a PCC MAY send a request that is based on the set of TE
parameters carried by the MPLS/GMPLS LSP setup signaling protocol, parameters carried by the MPLS/GMPLS LSP setup signaling protocol,
skipping to change at page 9, line 40 skipping to change at page 10, line 19
definition of strict hop, loose hop, and abstract node. definition of strict hop, loose hop, and abstract node.
A positive response from the PCE will include the paths that have A positive response from the PCE will include the paths that have
been computed. When a path satisfying the constraints cannot be been computed. When a path satisfying the constraints cannot be
found, or if the computation fails or cannot be performed, a found, or if the computation fails or cannot be performed, a
negative response MUST be sent. This response MAY include further negative response MUST be sent. This response MAY include further
details of the reason(s) for the failure, and potentially advice details of the reason(s) for the failure, and potentially advice
about which constraints might be relaxed to be more likely to achieve about which constraints might be relaxed to be more likely to achieve
a positive result. a positive result.
The PCECP response message MUST support the inclusion of a set of
aggregate path attributes.
The PCECP response message MUST support the inclusion of the set of
computed paths of a load-balancing path group, as well as their
respective bandwidth.
6.1.6 Cancellation of Pending Requests 6.1.6 Cancellation of Pending Requests
A PCC or PCE MUST be able to cancel a pending request, using an A PCC or PCE MUST be able to cancel a pending request, using an
appropriate notification between PCECP peers. A PCC that has sent a appropriate notification between PCECP peers. A PCC that has sent a
request to a PCE and no longer needs a response, for instance, request to a PCE and no longer needs a response, for instance,
because it received a satisfactory answer from another PCE, MUST be because it received a satisfactory answer from another PCE, MUST be
able to notify the PCE that it must clear the request (i.e. stop the able to notify the PCE that it must clear the request (i.e. stop the
computation, if already started, and clear the context). Similarly, computation, if already started, and clear the context). Similarly,
a PCE that received a request from a PCC that it cannot serve, for a PCE that received a request from a PCC that it cannot serve, for
example, due to congestion, MUST be able to notify the PCC, that the example, due to congestion, MUST be able to notify the PCC, that the
skipping to change at page 13, line 50 skipping to change at page 14, line 33
that constraint must not be supported. Note also that the provisions that constraint must not be supported. Note also that the provisions
of Section 6.1.14 mean that new constraints can be added to this list of Section 6.1.14 mean that new constraints can be added to this list
without impacting the protocol. without impacting the protocol.
Here is the list of generic constraints that MUST be supported: Here is the list of generic constraints that MUST be supported:
o MPLS-TE and GMPLS generic constraints: o MPLS-TE and GMPLS generic constraints:
- Bandwidth - Bandwidth
- Affinities inclusion/exclusion - Affinities inclusion/exclusion
- Link, Node, SRLG inclusion/exclusion - Link, Node, SRLG inclusion/exclusion
- Maximum end-to-end delay metrics - Maximum end-to-end IGP metric
- Hop Count - Hop Count
- Maximum end-to-end TE metric (cost) - Maximum end-to-end TE metric
- Multiple disjoint path computation to allow path protection - Multiple disjoint path computation to allow path protection
o MPLS-TE specific constraints o MPLS-TE specific constraints
- Class-type - Class-type
- Local protection - Local protection
- Node protection - Node protection
- Bandwidth protection - Bandwidth protection
o GMPLS specific constraints o GMPLS specific constraints
- Switching type, encoding type - Switching type, encoding type
- Link protection type - Link protection type
skipping to change at page 14, line 19 skipping to change at page 15, line 5
o GMPLS specific constraints o GMPLS specific constraints
- Switching type, encoding type - Switching type, encoding type
- Link protection type - Link protection type
Regarding affinities inclusion/exclusion, note the three categories Regarding affinities inclusion/exclusion, note the three categories
used in [RSVP-TE]: exclude-any, include-any, include-all. Regarding used in [RSVP-TE]: exclude-any, include-any, include-all. Regarding
link, node, SRLG inclusion/exclusion, note the mandatory and desired link, node, SRLG inclusion/exclusion, note the mandatory and desired
exclusion approach in [EXCLUDE-ROUTE]. exclusion approach in [EXCLUDE-ROUTE].
6.1.17 Objective Functions Supported
This section provides a list of generic objective functions that MUST
be supported by the PCECP. Other objectives functions MAY be added
to service specific applications as identified by separate
application-specific requirements documents.
Note that the absence of an objective function in this list does not
mean that the objective function may not be supported. Note also
that the provisions of Section 6.1.14 mean that new objective
functions MAY be added to this list without impacting the protocol.
The PCECP MUST support the following "unsynchronized" objective
functions:
o Minimum cost path (shortest path)
o Least loaded path (widest path)
o To be determined
Also the PCECP MUST support the following "synchronized" objective
functions:
o Minimize aggregate bandwidth consumption on all links
o Maximize the residual bandwidth on the most loaded link.
O Minimize the cumulative cost of a set of diverse paths.
6.2 Deployment Support Requirements 6.2 Deployment Support Requirements
6.2.1 Support for Different Service Provider Environments 6.2.1 Support for Different Service Provider Environments
The PCECP MUST operate in various different service provider network The PCECP MUST operate in various different service provider network
environments that utilize an IP-based control plane, including environments that utilize an IP-based control plane, including
- MPLS-TE and GMPLS networks - MPLS-TE and GMPLS networks
- packet and non-packet networks - packet and non-packet networks
skipping to change at page 16, line 5 skipping to change at page 17, line 14
The response to a computation request issued before the PCC is The response to a computation request issued before the PCC is
restarted will not be helpful and could be a waste of effort. Thus restarted will not be helpful and could be a waste of effort. Thus
it is better to allow the request to be re-issued in shorthand (e.g. it is better to allow the request to be re-issued in shorthand (e.g.
by request number) if the PCC remembers that it had previously issued by request number) if the PCC remembers that it had previously issued
it and is still interested in the response. it and is still interested in the response.
The PCECP SHOULD allow a PCE to respond to computation requests The PCECP SHOULD allow a PCE to respond to computation requests
issued before the failure without the requests being re-issued. issued before the failure without the requests being re-issued.
6.3.4 LSP Rerouting & Reoptimization
Upon LSP failure, due to link, node or SRLG failure, a head-end LSR
may send a request to the PCE so as to reroute the LSP over an
alternate path. So as to ease the computation such request should
include the previous path and the failed element (if it can be
identified).
Hence the request message MUST allow indicating if the computation is
for an LSP restoration, and MUST support the inclusion of the
previously computed path as well as the failed element. Note that
the old path is actually useful only if the old LSP is not torn down
yet. This is up to the PCC to decide if it includes the old path or
not.
Note that a network failure may impact a large number of LSPs. A
potentially large number of PCCs, are going to simultaneously send a
request to the PCE. Some jittering may be used on PCCs so as to delay
a request to the PCE, under network failure condition.
The PCECP MAY support the inclusion, in a response message to a PCC,
of an upper bound of a random waiting time to be used for further
requests to the PCE (e.g. the PCC will wait for a random value
between 0 and the upper bound before sending another request). This
upper bound would depend on the level of congestion of the PCE.
The path computation request message MUST support TE LSP path
reoptimization and the inclusion of a previously computed path. This
will help ensure optimal routing of a reoptimized path, since it will
allow the PCE to avoid double bandwidth accounting and help reduce
blocking issues.
7. Security Considerations 7. Security Considerations
The impact of the use of a PCECP MUST be considered in the light of The impact of the use of a PCECP MUST be considered in the light of
the impact that it has on the security of the existing routing and the impact that it has on the security of the existing routing and
signaling protocols and techniques in use within the network. signaling protocols and techniques in use within the network.
Intra-domain security is impacted since there is a new interface, Intra-domain security is impacted since there is a new interface,
protocol and element in the network. Any host in the network could protocol and element in the network. Any host in the network could
impersonate a PCC, and receive detailed information on network paths. impersonate a PCC, and receive detailed information on network paths.
Any host could also impersonate a PCE, both gathering information Any host could also impersonate a PCE, both gathering information
about the network before passing the request on to a real PCE, and about the network before passing the request on to a real PCE, and
skipping to change at page 17, line 52 skipping to change at page 19, line 41
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC [RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC
3667, February 2004. 3667, February 2004.
[RFC3668] Bradner, S., "Intellectual Property Rights in IETF [RFC3668] Bradner, S., "Intellectual Property Rights in IETF
Technology", BCP 79, RFC 3668, February 2004. Technology", BCP 79, RFC 3668, February 2004.
12. Informational References 12. Informational References
[METRIC] Le Faucheur, F., et. al., "Use of Interior Gateway Protocol
(IGP) Metric as a second MPLS Traffic Engineering (TE) Metric", BCP
87, RFC 3785, May 2004.
[PCE-DISC-REQ] Le Roux, JL, et. al., "Requirements for Path [PCE-DISC-REQ] Le Roux, JL, et. al., "Requirements for Path
Computation Element (PCE) Discovery," work in progress. Computation Element (PCE) Discovery," work in progress.
[RFC3209] Awduche, D., et. al., "RSVP-TE: Extensions to RSVP for LSP [RFC3209] Awduche, D., et. al., "RSVP-TE: Extensions to RSVP for LSP
Tunnels," RFC 3209, December 2001. Tunnels," RFC 3209, December 2001.
13. Authors' Addresses 13. Authors' & Contributors' Addresses
Jerry Ash Jerry Ash (Editor)
AT&T AT&T
Room MT D5-2A01 Room MT D5-2A01
200 Laurel Avenue 200 Laurel Avenue
Middletown, NJ 07748, USA Middletown, NJ 07748, USA
Phone: +1-(732)-420-4578 Phone: +1-(732)-420-4578
Email: gash@att.com Email: gash@att.com
Jean-Louis Le Roux (Editor)
France Telecom
2, avenue Pierre-Marzin
22307 Lannion Cedex, FRANCE
Email: jeanlouis.leroux@francetelecom.com
Alia K. Atlas Alia K. Atlas
Google Inc. Google Inc.
1600 Amphitheatre Parkway 1600 Amphitheatre Parkway
Mountain View, CA 94043 Mountain View, CA 94043
Email: akatlas@alum.mit.edu Email: akatlas@alum.mit.edu
Arthi Ayyangar Arthi Ayyangar
Juniper Networks, Inc. Juniper Networks, Inc.
1194 N.Mathilda Ave 1194 N.Mathilda Ave
Sunnyvale, CA 94089 USA Sunnyvale, CA 94089 USA
skipping to change at page 19, line 6 skipping to change at page 21, line 10
Email: durga.gangisetti@mci.com Email: durga.gangisetti@mci.com
Kenji Kumaki Kenji Kumaki
KDDI Corporation KDDI Corporation
Garden Air Tower Garden Air Tower
Iidabashi, Chiyoda-ku, Iidabashi, Chiyoda-ku,
Tokyo 102-8460, JAPAN Tokyo 102-8460, JAPAN
Phone: +81-3-6678-3103 Phone: +81-3-6678-3103
Email: ke-kumaki@kddi.com Email: ke-kumaki@kddi.com
Jean-Louis Le Roux
France Telecom
2, avenue Pierre-Marzin
22307 Lannion Cedex, FRANCE
Email: jeanlouis.leroux@francetelecom.com
Eiji Oki Eiji Oki
NTT NTT
Midori-cho 3-9-11 Midori-cho 3-9-11
Musashino-shi, Tokyo 180-8585, JAPAN Musashino-shi, Tokyo 180-8585, JAPAN
Email: oki.eiji@lab.ntt.co.jp Email: oki.eiji@lab.ntt.co.jp
Raymond Zhang Raymond Zhang
BT INFONET Services Corporation BT INFONET Services Corporation
2160 E. Grand Ave. 2160 E. Grand Ave.
El Segundo, CA 90245 USA El Segundo, CA 90245 USA
 End of changes. 27 change blocks. 
53 lines changed or deleted 154 lines changed or added

This html diff was produced by rfcdiff 1.28, available from http://www.levkowetz.com/ietf/tools/rfcdiff/