draft-ietf-pce-pcep-svec-list-05.txt   rfc6007.txt 
Network Working Group Itaru Nishioka
Internet Draft NEC Corp.
Intended Status: Informational Daniel King
Expires: December 6, 2010 Old Dog Consulting
June 6, 2010
The use of SVEC (Synchronization VECtor) list for Synchronized Internet Engineering Task Force (IETF) I. Nishioka
dependent path computations Request for Comments: 6007 NEC Corp.
Category: Informational D. King
ISSN: 2070-1721 Old Dog Consulting
September 2010
draft-ietf-pce-pcep-svec-list-05.txt Use of the Synchronization VECtor (SVEC) List for
Synchronized Dependent Path Computations
Abstract Abstract
A Path Computation Element (PCE) may be required to perform A Path Computation Element (PCE) may be required to perform dependent
dependent path computations. Dependent path computations are path computations. Dependent path computations are requests that
requests that need to be synchronized in order to meet specific need to be synchronized in order to meet specific objectives. An
objectives. An example of a dependent request would be a PCE example of a dependent request would be a PCE computing a set of
computing a set of services which are required to be diverse services that are required to be diverse (disjointed) from each
(disjointed) from each other. When a PCE computes sets of dependent other. When a PCE computes sets of dependent path computation
path computation requests concurrently, it is required to use the requests concurrently, use of the Synchronization VECtor (SVEC) list
Synchronization VECtor (SVEC) list for association among the sets of is required for association among the sets of dependent path
dependent path computation requests. The SVEC object is optional and computation requests. The SVEC object is optional and carried within
carried within the Path Computation Element Protocol (PCEP) the Path Computation Element Communication Protocol (PCEP) PCRequest
PCRequest (PCReq) message. (PCReq) message.
This document does not specify the PCEP SVEC object or procedure. This document does not specify the PCEP SVEC object or procedure.
This informational document clarifies the use of the SVEC list for This informational document clarifies the use of the SVEC list for
synchronized path computations when computing dependent requests. synchronized path computations when computing dependent requests.
The document also describes a number of usage scenarios for SVEC The document also describes a number of usage scenarios for SVEC
lists within single domain and multi-domain environments. lists within single-domain and multi-domain environments.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and 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 Status of This Memo
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 This document is not an Internet Standards Track specification; it is
http://www.ietf.org/ietf/1id-abstracts.txt. published for informational purposes.
The list of Internet-Draft Shadow Directories can be accessed at This document is a product of the Internet Engineering Task Force
http://www.ietf.org/shadow.html. (IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
This Internet-Draft will expire on December 6, 2010. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6007.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with carefully, as they describe your rights and restrictions with respect
respect to this document. Code Components extracted from this to this document. Code Components extracted from this document must
document must include Simplified BSD License text as described in include Simplified BSD License text as described in Section 4.e of
Section 4.e of the Trust Legal Provisions and are provided without the Trust Legal Provisions and are provided without warranty as
warranty as described in the Simplified BSD License. described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this 10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) Without obtaining an adequate license from the person(s) controlling
controlling the copyright in such materials, this document may not the copyright in such materials, this document may not be modified
be modified outside the IETF Standards Process, and derivative works outside the IETF Standards Process, and derivative works of it may
of it may not be created outside the IETF Standards Process, except not be created outside the IETF Standards Process, except to format
to format it for publication as an RFC or to translate it into it for publication as an RFC or to translate it into languages other
languages other than English. than English.
Table of Contents Table of Contents
1. Introduction ..................................................3 1. Introduction ....................................................3
1.1. SVEC Object ...............................................4 1.1. SVEC Object ................................................4
1.2. Application of SVEC Lists .................................4 1.2. Application of SVEC Lists ..................................5
2. Terminology ...................................................6 2. Terminology .....................................................6
3. SVEC association scenarios ....................................6 3. SVEC Association Scenarios ......................................7
3.1. Synchronized computation for diverse path requests ........6 3.1. Synchronized Computation for Diverse Path Requests .........7
3.2. Synchronized computation for point-to-multipoint path 3.2. Synchronized Computation for Point-to-Multipoint
requests ..................................................8 Path Requests ..............................................8
4. SVEC association ..............................................8 4. SVEC Association ................................................9
4.1. SVEC list .................................................8 4.1. SVEC List ..................................................9
4.2. Associated SVECs ..........................................8 4.2. Associated SVECs ...........................................9
4.3. Non-associated SVECs ......................................9 4.3. Non-Associated SVECs ......................................10
5. Processing of SVEC list .......................................10 5. Processing of SVEC List ........................................10
5.1. Single PCE, single domain environments ....................10 5.1. Single-PCE, Single-Domain Environments ....................10
5.2. Multi-PCE, single domain environments .....................11 5.2. Multi-PCE, Single-Domain Environments .....................11
5.3. Multi-PCE, multi-domain environments ......................11 5.3. Multi-PCE, Multi-Domain Environments ......................11
6. End-to-end diverse path computation ...........................12 6. End-to-End Diverse Path Computation ............................13
6.1. Disjoint VSPT .............................................12 6.1. Disjoint VSPT .............................................13
6.2. Disjoint VSPT encoding ....................................13 6.2. Disjoint VSPT Encoding ....................................14
6.3. Path computation procedure ................................14 6.3. Path Computation Procedure ................................15
7. Manageability considerations ..................................14 7. Manageability Considerations ...................................15
7.1. Control of Function and Policy ............................14 7.1. Control of Function and Policy ............................15
7.2. Information and Data Models, e.g. MIB modules .............15 7.2. Information and Data Models (MIB Modules) .................15
7.3. Liveness Detection and Monitoring .........................15 7.3. Liveness Detection and Monitoring .........................15
7.4. Verifying Correct Operation ...............................15 7.4. Verifying Correct Operation ...............................15
7.5. Requirements on Other Protocols and Functional Components..15 7.5. Requirements on Other Protocols and Functional
7.6. Impact on Network Operation ...............................15 Components ................................................16
8. Security Considerations .......................................15 7.6. Impact on Network Operation ...............................16
9. IANA Considerations ...........................................16 8. Security Considerations ........................................16
10. References ...................................................16 9. References .....................................................16
10.1. Normative References .....................................16 9.1. Normative References ......................................16
10.2. Informative References ...................................17 9.2. Informative References ....................................17
11. Acknowledgements .............................................17 10. Acknowledgements ..............................................18
12. Authors' Addresses ...........................................17
1. Introduction 1. Introduction
[RFC5440] describes the specifications for PCEP (Path Computation [RFC5440] describes the specifications for the Path Computation
Element communication Protocol). PCEP specifies the communication Element Communication Protocol (PCEP). PCEP specifies the
between a Path Computation Client (PCC) and a Path Computation communication between a Path Computation Client (PCC) and a Path
Element (PCE), or between two PCEs based on the PCE architecture Computation Element (PCE), or between two PCEs based on the PCE
[RFC4655]. PCEP interactions include path computation requests and architecture [RFC4655]. PCEP interactions include path computation
path computation replies. requests and path computation replies.
The PCE may be required to compute independent and dependent path The PCE may be required to compute independent and dependent path
requests. Path computation requests are said to be independent if requests. Path computation requests are said to be independent if
they are not related to each other, and therefore not required to be they are not related to each other and therefore not required to be
synchronized. Equally a set of dependent path computation requests, synchronized. Conversely, a set of dependent path computation
that are required to be synchronized, cannot be performed requests is such that their computations cannot be performed
independently of each other. The Synchronization VECtor (SVEC) with independently of each other, and the requests must be synchronized.
a list of the path computation request identifiers carried within The Synchronization VECtor (SVEC) with a list of the path computation
the request message allows the PCC or PCE to specify a list of request identifiers carried within the request message allows the PCC
multiple path computation requests that must be synchronized. or PCE to specify a list of multiple path computation requests that
Section 1.1 (SVEC Object) describes the SVEC object. Section 1.2 must be synchronized. Section 1.1 ("SVEC Object") describes the SVEC
(Application of SVEC Lists) describes the application of SVEC lists object. Section 1.2 ("Application of SVEC Lists") describes the
in certain scenarios. application of SVEC lists in certain scenarios.
This informational document clarifies the handling of dependent and This informational document clarifies the handling of dependent and
synchronized path computation requests, using the SVEC list, based synchronized path computation requests, using the SVEC list, based on
on the PCE architecture [RFC4655] and PCEP [RFC5440]. The document the PCE architecture [RFC4655] and PCEP [RFC5440]. The document also
also describes a number of usage scenarios for SVEC lists within describes a number of usage scenarios for SVEC lists within single-
single domain and multi-domain environments. This document is not domain and multi-domain environments. This document is not intended
intended to specify the procedure when using SVEC lists for to specify the procedure when using SVEC lists for dependent and
dependent and synchronized path computation requests. synchronized path computation requests.
1.1. SVEC Object 1.1. SVEC Object
When a PCC or PCE sends path computation requests to a PCE, a PCEP When a PCC or PCE sends path computation requests to a PCE, a PCEP
Path Computation Request (PCReq) message may carry multiple requests Path Computation Request (PCReq) message may carry multiple requests,
each of which has a unique path computation request identifier. The each of which has a unique path computation request identifier. The
SVEC with a list of the path computation request identifiers carried SVEC with a list of the path computation request identifiers carried
within the request message allows the PCC or PCE to specify a list within the request message allows the PCC or PCE to specify a list of
of multiple path computation requests that must be synchronized, and multiple path computation requests that must be synchronized, and
also allows the specification of any dependency relationships also allows the specification of any dependency relationships between
between the paths. The path computation requests listed in the SVEC the paths. The path computation requests listed in the SVEC must be
must be handled in a relation to each other (i.e. synchronized). handled in a specific relation to each other (i.e., synchronized).
[RFC5440] defines two synchronous path computation modes for [RFC5440] defines two synchronous path computation modes for
dependent or independent path computation requests specified by the dependent or independent path computation requests specified by the
dependency flags (i.e. Node, Link or SRLG diverse flags) in the SVEC. dependency flags (i.e., Node, Link, or Shared Risk Link Group (SRLG)
(See [RFC5440] for more details of dependent, independent and diverse flags) in the SVEC:
synchronous path computation.)
o A set of independent and synchronized path computation requests, o A set of independent and synchronized path computation requests.
o A set of dependent and synchronized path computation requests. o A set of dependent and synchronized path computation requests.
These computation modes are exclusive each other in a single SVEC. See [RFC5440] for more details on dependent, independent, and
If one of the dependency flags in a SVEC is set, it indicates a set synchronous path computation.
of synchronous path computation requests has a dependency and does
not allow any other path computation requests. In order to be These computation modes are exclusive to each other in a single SVEC.
If one of the dependency flags in a SVEC is set, it indicates that a
set of synchronous path computation requests has a dependency and
does not allow any other path computation requests. In order to be
synchronized with other path computation requests with a dependency, synchronized with other path computation requests with a dependency,
it is necessary to associate them. it is necessary to associate them.
The aim of the SVEC object carried within a PCReq message is to The aim of the SVEC object carried within a PCReq message is to
request the synchronization of M path computation requests. Each request the synchronization of M path computation requests. Each
path computation request is uniquely identified by the Request-ID- path computation request is uniquely identified by the Request-ID-
number carried within the respective RP object. The SVEC object number carried within the respective Request Parameters (RP) object.
also contains a set of flags that specify the synchronization type. The SVEC object also contains a set of flags that specify the
The SVEC Object is defined in Section 7.13 (SVEC Object) of synchronization type. The SVEC object is defined in Section 7.13
[RFC5440]. ("SVEC Object") of [RFC5440].
1.2. Application of SVEC Lists 1.2. Application of SVEC Lists
It is important for the PCE, when performing path computations, to It is important for the PCE, when performing path computations, to
synchronize any path computation requests with a dependency. For synchronize any path computation requests with a dependency. For
example, consider two protected end-to-end services: example, consider two protected end-to-end services:
o It would be beneficial for each back-up path to be disjointed so o It would be beneficial for each back-up path to be disjointed so
they do not share the same links and nodes as the working path. they do not share the same links and nodes as the working path.
o Two diverse path computation requests would be needed to compute o Two diverse path computation requests would be needed to compute
the working and disjointed protected paths. the working and disjointed protected paths.
If the diverse path requests are computed sequentially, fulfillment If the diverse path requests are computed sequentially, fulfillment
of the initial diverse path computation without consideration of the of the initial diverse path computation without consideration of the
second diverse path computation and disjoint constraint may result in second diverse path computation and disjoint constraint may result in
the PCE providing sub-optimal path disjoint results for the protected the PCE either providing sub-optimal path disjoint results for the
path, or may fail to meet the end-to-end disjoint requirement protected path or failing to meet the end-to-end disjoint requirement
altogether. altogether.
Additionally, SVEC can be applied to end-to-end diverse path Additionally, SVEC can be applied to end-to-end diverse path
computations that traverse multiple domains. [RFC5441] describes two computations that traverse multiple domains. [RFC5441] describes two
approaches, synchronous (i.e. simultaneous) and 2-step approaches, approaches, synchronous (i.e., simultaneous) and 2-step approaches,
for the end-to-end diverse path computation across a chain of for end-to-end diverse path computation across a chain of domains.
domains. The path computation procedure is specified for the 2-step The path computation procedure is specified for the 2-step approaches
approaches in [RFC5521], but no guidelines are provided for a in [RFC5521], but no guidelines are provided for the synchronous
synchronous approach which is described in this document. approach described in this document.
The following scenarios are specifically described within this The following scenarios are specifically described within this
document: document:
o Single domain, single PCE, dependent and synchronized path o Single-domain, single-PCE, dependent and synchronized path
computation request. computation request.
o Single domain, multi-PCE, dependent and synchronized path o Single-domain, multi-PCE, dependent and synchronized path request.
request.
o Multi-domain, dependent and synchronized path computation request, o Multi-domain, dependent and synchronized path computation request,
including end-to-end diverse path computation. including end-to-end diverse path computation.
The association among multiple SVECs for multiple sets of The association among multiple SVECs for multiple sets of
synchronized dependent path computation is also described in this synchronized dependent path computations is also described in this
document, as well as disjoint Virtual Shortest Path Tree (VSPT) document, as well as the disjoint Virtual Shortest Path Tree (VSPT)
encoding rule for end-to-end diverse path computation across domains. encoding rule for end-to-end diverse path computation across domains.
Path computation algorithms for these path computation scenarios are Path computation algorithms for these path computation scenarios are
out of the scope of this document. out of the scope of this document.
The clarifications and use cases in this document are applicable to The clarifications and use cases in this document are applicable to
the Global Concurrent Optimization (GCO) path computation mechanism the Global Concurrent Optimization (GCO) path computation mechanism
specified in [RFC5557]. The GCO application provides the capability specified in [RFC5557]. The GCO application provides the capability
to optimize a set of services within the network, in order to to optimize a set of services within the network, in order to
maximize efficient use of network resources. A single or set of maximize efficient use of network resources. A single objective
objective functions (OFs) can be applied to a GCO. To compute a set function (OF) or a set of OFs can be applied to a GCO. To compute a
of such traffic-engineered paths for the GCO application, PCEP set of such traffic-engineered paths for the GCO application, PCEP
supports the synchronous and dependent path computation requests supports the synchronous and dependent path computation requests
required in [RFC4657]. required in [RFC4657].
The SVEC association and the disjoint VSPT described in this The SVEC association and the disjoint VSPT described in this document
document do not require any extension to PCEP messages and object do not require any extension to PCEP messages and object formats,
formats, when computing a GCO for multiple or end-to-end diverse when computing a GCO for multiple or end-to-end diverse paths. In
paths. In addition, the use of multiple SVECs is not restricted to addition, the use of multiple SVECs is not restricted to only SRLG,
only SRLG, Node and Link diversity currently defined in the SVEC node, and link diversity currently defined in the SVEC object
object [RFC5440], but is also available for other dependent path [RFC5440], but is also available for other dependent path computation
computation requests. requests.
The SVEC association and disjoint VSPT are available to both single The SVEC association and disjoint VSPT are available to both single-
PCE path computation and multi-PCE path computation. PCE path computation and multi-PCE path computation.
2. Terminology 2. Terminology
This document uses PCE terminology defined in [RFC4655], [RFC4875], This document uses PCE terminology defined in [RFC4655], [RFC4875],
and [RFC5440]. and [RFC5440].
Associated SVECs: A group of multiple SVECs (Synchronization Associated SVECs: A group of multiple SVECs (Synchronization
VECtors), defined in this document, to indicate a set of VECtors), defined in this document, to indicate a set of
synchronized or concurrent path computations. synchronized or concurrent path computations.
Disjoint VSPT: A set of VSPTs, defined in this document, to indicate Disjoint VSPT: A set of VSPTs, defined in this document, to indicate
a set of virtual diverse path tree. a set of virtual diverse path trees.
GCO (Global Concurrent Optimization): A concurrent path computation GCO (Global Concurrent Optimization): A concurrent path computation
application, defined in [RFC5557], where a set of TE paths is application, defined in [RFC5557], where a set of traffic
computed concurrently in order to efficiently utilize network engineered (TE) paths is computed concurrently in order to
resources. efficiently utilize network resources.
Synchronized: A set of path computation requests is said to be Synchronized: Describes a set of path computation requests that the
synchronized if the PCE associates the requests, and does not PCE associates and that the PCE does not compute independently of
compute each request independently of each other. each other.
VSPT: Virtual Shortest Path Tree defined in [RFC5441]. VSPT: Virtual Shortest Path Tree, defined in [RFC5441].
3. SVEC association scenarios 3. SVEC Association Scenarios
This section clarifies several path computation scenarios, in which This section clarifies several path computation scenarios in which
SVEC association can be applied. Also, any combination of scenarios SVEC association can be applied. Also, any combination of scenarios
described in this section could be applicable. described in this section could be applicable.
3.1. Synchronized computation for diverse path requests 3.1. Synchronized Computation for Diverse Path Requests
A PCE may compute two or more point-to-point diverse paths, A PCE may compute two or more point-to-point diverse paths
concurrently, in order to increase the probability of meeting concurrently, in order to increase the probability of meeting primary
primary and secondary path diversity (or disjointness) objective and and secondary path diversity (or disjointness) objectives and network
network resource optimization objective. resource optimization objectives.
Two scenarios can be considered for the SVEC association of point- Two scenarios can be considered for the SVEC association of point-to-
to-point diverse paths. point diverse paths.
o Two or more end-to-end diverse paths o Two or more end-to-end diverse paths
When concurrent path computation of two or more end-to-end diverse When concurrent path computation of two or more end-to-end diverse
paths is requested, SVEC association is needed among diverse path paths is requested, SVEC association is needed among diverse path
requests. Note here that each diverse path request consists of requests. Note here that each diverse path request consists of
primary, secondary, and tertiary and beyond path requests, in which primary, secondary, and tertiary (and beyond) path requests, in which
all path requests are grouped with one SVEC association. all path requests are grouped with one SVEC association.
Consider two end-to-end services that are to be kept separate by Consider two end-to-end services that are to be kept separate by
using diverse paths. The path computation requests would need to be using diverse paths. The path computation requests would need to be
associated so that diversity could be assured. Consider further that associated so that diversity could be assured. Consider further that
each of these services requires a backup path that can protect each of these services requires a backup path that can protect
against any failure in the primary path. These backup paths must be against any failure in the primary path. These backup paths must be
computed using requests that are associated with the primary paths computed using requests that are associated with the primary paths,
giving rise to a set of four associated requests. giving rise to a set of four associated requests.
o End-to-end primary path and its segmented secondary paths o End-to-end primary path and its segmented secondary paths
When concurrent path computation for segment recovery paths, as When concurrent path computation for segment recovery paths, as shown
shown in figure 1, is requested, SVEC association is needed between in Figure 1, is requested, SVEC association is needed between a
a primary path and several segmented secondary paths. primary path and several segmented secondary paths.
<------------ primary -----------> <------------ primary ----------->
A------B------C---D------E------F A------B------C---D------E------F
\ / \ / \ / \ /
P---Q---R X---Y---Z P---Q---R X---Y---Z
<--secondary1--> <--secondary2--> <--secondary1--> <--secondary2-->
Figure 1: Segment Recovery Paths Figure 1. Segment Recovery Paths
In this scenario, we assume that the primary path may be pre- In this scenario, we assume that the primary path may be pre-computed
computed, which is used for specifying the segment for secondary and used for specifying the segment for secondary paths. Otherwise,
paths. Otherwise, the segment for secondary path requests are the segment for secondary path requests is specified in advance, by
specified in advance, by using Exclude Route Object (XRO) and/or using Exclude Route Object (XRO) and/or Include Route Object (IRO)
Include Route Object (IRO) constraints in the primary request. constraints in the primary request.
3.2. Synchronized computation for point-to-multipoint path requests 3.2. Synchronized Computation for Point-to-Multipoint Path Requests
For point-to-multipoint path requests, SVEC association can be For point-to-multipoint path requests, SVEC association can be
applied. applied.
o Two or more point-to-multipoint paths o Two or more point-to-multipoint paths
If a point-to-multipoint paths request is represented as a set of If a point-to-multipoint path computation request is represented
point-to-point paths [ID.pce-p2mp-ext], two or more point-to- as a set of point-to-point paths [RFC6006], two or more point-to-
multipoint path computation requests can be associated for multipoint path computation requests can be associated for
concurrent path computation, in order to optimize network resources. concurrent path computation, in order to optimize network
resources.
o Point-to-multipoint paths and their secondary paths o Point-to-multipoint paths and their secondary paths
When concurrent path computation of a point-to-multipoint path and When concurrent path computation of a point-to-multipoint path and
its point-to-point secondary paths [RFC4875], or a point-to- its point-to-point secondary paths [RFC4875], or a point-to-
multipoint path and its point-to-multipoint secondary paths is multipoint path and its point-to-multipoint secondary paths is
requested, SVEC association is needed among these requests. In this requested, SVEC association is needed among these requests. In
scenario, we use the same assumption as "end-to-end primary path and this scenario, we use the same assumption as the "end-to-end
its segmented secondary paths scenario" in section 3.1. primary path and its segmented secondary paths" scenario in
Section 3.1.
4. SVEC association 4. SVEC Association
This section describes the associations among SVECs in a SVEC list. This section describes the associations among SVECs in a SVEC list.
4.1. SVEC list 4.1. SVEC List
PCEP provides the capability to carry one or more SVEC objects in a PCEP provides the capability to carry one or more SVEC objects in a
PCReq message, and this set of SVEC objects within the PCReq message PCReq message, and this set of SVEC objects within the PCReq message
is termed a SVEC list. Each SVEC object in the SVEC list contains a is termed a SVEC list. Each SVEC object in the SVEC list contains a
distinct group of path computation requests. When requesting distinct group of path computation requests. When requesting
association among such distinct groups, associated SVECs described association among such distinct groups, associated SVECs described in
in this document are used. this document are used.
4.2. Associated SVECs 4.2. Associated SVECs
"Associated SVECs" defines that there are relationships among "Associated SVECs" means that there are relationships among multiple
multiple SVECs in SVEC list. Note that there is no automatic SVECs in a SVEC list. Note that there is no automatic association in
association in [RFC5440] between the members of one SVEC and the [RFC5440] between the members of one SVEC and the members of another
members of another SVEC in the same SVEC list. The associated SVEC SVEC in the same SVEC list. The associated SVEC is introduced to
is introduced to associate these SVECs, especially for correlating associate these SVECs, especially for correlating among SVECs with
among SVECs with dependency flags. dependency flags.
Request identifiers in the SVEC objects are used to indicate the Request identifiers in the SVEC objects are used to indicate the
association among SVEC objects. If the same request-IDs exist in association among SVEC objects. If the same request-IDs exist in
SVEC objects, this indicates these SVEC objects are associated. When SVEC objects, this indicates these SVEC objects are associated. When
associating among SVEC objects, at least one request identifier must associating among SVEC objects, at least one request identifier must
be shared between associated SVECs. The SVEC objects can be be shared between associated SVECs. The SVEC objects can be
associated regardless of the dependency flags in each SVEC object, associated regardless of the dependency flags in each SVEC object,
but it is recommended to use a single SVEC if the dependency flags but it is recommended to use a single SVEC if the dependency flags
are not set in all SVEC objects. Similarly, when associating among are not set in all SVEC objects. Similarly, when associating among
SVEC objects with dependency flags, it is recommended to construct SVEC objects with dependency flags, it is recommended to construct
them using a minimum set of associated SVECs, thus avoiding complex them using a minimum set of associated SVECs, thus avoiding complex
relational associations. relational associations.
Below is an example of associated SVECs. In this example, the first Below is an example of associated SVECs. In this example, the first
SVEC is associated with the other SVECs, and all of path computation SVEC is associated with the other SVECs, and all of the path
requests contained in the associated SVECs (i.e. Request-ID#1,#2,#3, computation requests contained in the associated SVECs (i.e.,
#4,#X,#Y,#Z) must be synchronized. Request-IDs #1, #2, #3, #4, #X, #Y, and #Z) must be synchronized.
<SVEC-list> <SVEC-list>
<SVEC> without dependency flags <SVEC> without dependency flags
Request-ID #1, Request-ID #3, Request-ID #X Request-ID #1, Request-ID #3, Request-ID #X
<SVEC> with one or more dependency flags <SVEC> with one or more dependency flags
Request-ID #1, Request-ID #2 Request-ID #1, Request-ID #2
<SVEC> with one or more dependency flags <SVEC> with one or more dependency flags
Request-ID #3, Request-ID #4 Request-ID #3, Request-ID #4
<SVEC> without dependency flag <SVEC> without dependency flag
Request-ID #X, Request-ID #Y, Request-ID #Z Request-ID #X, Request-ID #Y, Request-ID #Z
4.3. Non-associated SVECs 4.3. Non-Associated SVECs
Non-associated SVECs mean that there are no relationships among "Non-associated SVECs" means that there are no relationships among
SVECs. If none of the SVEC objects in the SVEC list on a PCReq SVECs. If none of the SVEC objects in the SVEC list on a PCReq
message contains a common request-ID, there is no association message contains a common request-ID, there is no association between
between the SVECs and so no association between the requests in one the SVECs and so no association between the requests in one SVEC and
SVEC and the requests in another SVEC. the requests in another SVEC.
Below is an example of non-associated SVECs that does not contain Below is an example of non-associated SVECs that do not contain any
any common request-IDs. common request-IDs.
<SVEC-list> <SVEC-list>
<SVEC> with one or more dependency flags <SVEC> with one or more dependency flags
Request-ID #1, Request-ID #2 Request-ID #1, Request-ID #2
<SVEC> with one or more dependency flags <SVEC> with one or more dependency flags
Request-ID #3, Request-ID #4 Request-ID #3, Request-ID #4
<SVEC> without dependency flags <SVEC> without dependency flags
Request-ID #X, Request-ID #Y, Request-ID #Z Request-ID #X, Request-ID #Y, Request-ID #Z
5. Processing of SVEC list 5. Processing of SVEC List
5.1. Single PCE, single domain environments 5.1. Single-PCE, Single-Domain Environments
In this environment, there is a single PCE within the domain. In this environment, there is a single PCE within the domain.
When a PCE receives PCReq messages with more than one SVEC objects When a PCE receives PCReq messages with more than one SVEC object in
in the SVEC list, PCEP has to first check the request-IDs in all the SVEC list, PCEP has to first check the request-IDs in all SVEC
SVEC objects in order to identify any associations among them. objects in order to identify any associations among them.
If there are no matching request-IDs in the different SVEC objects, If there are no matching request-IDs in the different SVEC objects,
these SVEC objects are not associated, and then each set of path these SVEC objects are not associated, and then each set of path
computation requests in the non-associated SVEC objects has to be computation requests in the non-associated SVEC objects has to be
computed separately. computed separately.
If there are matching request-IDs in the different SVEC objects, If there are matching request-IDs in the different SVEC objects,
these SVEC objects are associated, and then all path computation these SVEC objects are associated, and then all path computation
requests in the associated SVEC objects are treated in a synchronous requests in the associated SVEC objects are treated in a synchronous
manner for GCO application. manner for GCO application.
If the PCE does not have capability to handle the associated SVEC If a PCE that is unable to handle the associated SVEC finds the
objects, it may send a PCErr message with Error-Type="Capability not common request-IDs in multiple SVEC objects, the PCE should cancel
supported". the path computation request and respond to the PCC with the PCErr
message Error-Type="Capability not supported".
In the case that M path computation requests are sent across In the case that M path computation requests are sent across multiple
multiple PCReq messages, the PCE may start a SyncTimer as PCReq messages, the PCE may start a SyncTimer as recommended in
recommended in Section 7.13.3 (Handling of the SVEC Object) Section 7.13.3 ("Handling of the SVEC Object") of [RFC5440]. In this
[RFC5440]. In this case, the associated SVECs should also be handled case, the associated SVECs should also be handled as described in
as described in [RFC5440]. I.E. after receiving the entire set of M [RFC5440], i.e., after receiving the entire set of M path computation
path computation requests associated by SVECs, the computation requests associated by SVECs, the computation should start at one.
should start at one. If the SyncTimer has expired or the following If the SyncTimer has expired or the subsequent PCReq messages are
PCReq messages have been malformed; the PCE should cancel the path malformed, the PCE should cancel the path computation request and
computation request and respond to the PCC with the relevant PCErr respond to the PCC with the relevant PCErr message.
message.
5.2. Multi-PCE, single domain environments 5.2. Multi-PCE, Single-Domain Environments
There are multiple PCEs in a domain, to which PCCs can communicate There are multiple PCEs in a domain, to which PCCs can communicate
directly, and PCCs can choose an appropriate PCE for load balanced directly, and PCCs can choose an appropriate PCE for load-balanced
path computation requests. In this environment it is possible path computation requests. In this environment, it is possible that
dependent path computation requests are sent to different PCEs. dependent path computation requests are sent to different PCEs.
If a PCC sends path computation requests to a PCE and then sends However, if a PCC sends path computation requests to a PCE, and then
another path computation requests, which are dependent on the first sends a further path computation request to a different PCE using the
requests and has been associated by using a SVEC list. There is no SVEC list to show that the further request is dependent on the first
method for the PCE to correlate the dependent requests sent to requests, there is no method for the PCE to correlate the dependent
different PCEs. No SVEC object correlation function between the PCEs requests sent to different PCEs. No SVEC object correlation function
is specified in [RFC5440]. As indentified, no mechanism exists to between the PCEs is specified in [RFC5440]. No mechanism exists to
resolve this problem and the issue is open for future study. resolve this problem, and the issue is open for future study.
Therefore, a PCC must not send dependent path computation requests Therefore, a PCC must not send dependent path computation requests
associated by SVECs to different PCEs. associated by SVECs to different PCEs.
5.3. Multi-PCE, multi-domain environments 5.3. Multi-PCE, Multi-Domain Environments
In this environment, there are multiple domains in which PCEs are In this environment, there are multiple domains in which PCEs are
located in each domain, and end-to-end dependent paths (i.e. diverse located in each domain, and end-to-end dependent paths (i.e., diverse
path) is computed using multiple PCEs. Note that we assume a chain paths) are computed using multiple PCEs. Note that we assume a chain
of PCEs are pre-determined and the BRPC procedure [RFC5441] is in of PCEs is predetermined and the Backward-Recursive PCE-Based
use. Computation (BRPC) procedure [RFC5441] is in use.
The SVECs can be applied to end-to-end diverse path computations The SVECs can be applied to end-to-end diverse path computations that
that traverse multiple domains. [RFC5441] describes two approaches, traverse multiple domains. [RFC5441] describes two approaches,
synchronous (i.e. simultaneous) and 2-step approaches, for the end- synchronous (i.e., simultaneous) and 2-step approaches, for
to-end diverse path computation across a chain of domains. In the 2- end-to-end diverse path computation across a chain of domains. In
step approaches described in [RFC5521], it is not necessary to use the 2-step approaches described in [RFC5521], it is not necessary to
the associated SVECs because any of dependency flags in a SVEC use the associated SVECs if any of the dependency flags in a SVEC
object are not set. On one hand, the simultaneous approach may object are not set. On the other hand, the simultaneous approach may
require the associated SVEC because at least one of dependency flags require the associated SVEC because at least one of the dependency
is required in a SVEC object. Thus, a use case of the simultaneous flags is required to be set in a SVEC object. Thus, a use case of
approach is described in this environment. the simultaneous approach is described in this environment.
When a chain of PCEs located in separate domains are used for When a chain of PCEs located in separate domains is used for
simultaneous path computations, additional path computation simultaneous path computations, additional path computation
processing is required. It is described in this document (Section 6). processing is required, as described in Section 6 of this document.
If the PCReq message contains multiple associated SVEC objects and If the PCReq message contains multiple associated SVEC objects and
these SVEC objects contain path computation requests that will be these SVEC objects contain path computation requests that will be
sent to the next PCE along the path computation chain, the following sent to the next PCE along the path computation chain, the following
procedures are applied. procedures are applied.
When a chain of PCEs is a unique sequence for all of path When a chain of PCEs is a unique sequence for all of the path
computation requests in a PCReq message, it is not necessary to re- computation requests in a PCReq message, it is not necessary to
construct associations among SVEC objects. Thus, the PCReq message reconstruct associations among SVEC objects. Thus, the PCReq message
is passed to the tail end PCE. When a PCReq message contains more is passed to the tail-end PCE. When a PCReq message contains more
than one SVEC objects with the dependency flag set, the contained than one SVEC object with the dependency flag set, the contained
SVECs may then be associated. PCEs receiving the associated SVECs SVECs may then be associated. PCEs receiving the associated SVECs
must maintain their association, and consider their relationship in must maintain their association and must consider their relationship
path computing after receiving a corresponding PCRep message. when performing path computations after receiving a corresponding
PCReply (PCRep) message.
When a chain of PCEs is different, it is required that intermediate When a chain of PCEs is different, it is required that intermediate
PCEs receiving such PCReq messages may re-construct associations PCEs receiving such PCReq messages may reconstruct associations among
among SVEC objects, and then send PCReq messages to corresponding SVEC objects, and then send PCReq messages to corresponding PCEs
PCEs located in neighboring domains. If the associated SVECs are re- located in neighboring domains. If the associated SVECs are
constructed at the intermediate PCE, the PCE must not start its path reconstructed at the intermediate PCE, the PCE must not start its
computation until all PCRep messages have been received from all path computation until all PCRep messages have been received from all
neighbor PCEs. However, a complex PCE implementation is required for neighbor PCEs. However, a complex PCE implementation is required for
SVEC reconstruction, and waiting mechanisms must be implemented. SVEC reconstruction, and waiting mechanisms must be implemented.
Therefore, it is not recommended to associate path computation Therefore, it is not recommended to associate path computation
requests with different PCE chains. This is open issue and is requests with different PCE chains. This is an open issue and is
currently being discussed in [ID.h-pce] which proposes a currently being discussed in [H-PCE], which proposes a hierarchical
hierarchical PCE architecture. PCE architecture.
6. End-to-end diverse path computation 6. End-to-End Diverse Path Computation
In this section, the synchronous approach is provided to compute In this section, the synchronous approach is provided to compute
primary and secondary paths simultaneously. primary and secondary paths simultaneously.
6.1. Disjoint VSPT 6.1. Disjoint VSPT
The BRPC procedure constructs a VSPT to inform the enquiring PCE of The BRPC procedure constructs a VSPT to inform the enquiring PCE of
potential paths to the destination node. potential paths to the destination node.
In the end-to-end diverse path computation, diversity (or In the end-to-end diverse path computation, diversity (or
disjointness) information among the potential paths must be disjointness) information among the potential paths must be preserved
preserved in the VSPT to ensure end-to-end disjoint path. In order in the VSPT to ensure an end-to-end disjoint path. In order to
to preserve diversity (or disjointness) information, disjoint VSPTs preserve diversity (or disjointness) information, disjoint VSPTs are
are sent in the PCEP PCRep message. The PCReq containing a SVEC sent in the PCEP PCRep message. The PCReq containing a SVEC object
object with the appropriate diverse flag set would signal that the with the appropriate diverse flag set would signal that the PCE
PCE should compute a disjoint VSPT. should compute a disjoint VSPT.
A definition of the disjoint VSPT is a collection of VSPTs, in which A definition of the disjoint VSPT is a collection of VSPTs, in which
each VSPT contains a potential set of primary and secondary paths. each VSPT contains a potential set of primary and secondary paths.
Figure 2 shows an example network. Here, transit nodes in domains Figure 2 shows an example network. Here, transit nodes in domains
are not depicted, and PCE1 and PCE2 may be located in border nodes. are not depicted, and PCE1 and PCE2 may be located in border nodes.
In this network, there are three VSPTs for the potential set of In this network, there are three VSPTs for the potential set of
diverse paths shown in Figure 3, when the primary path and secondary diverse paths, shown in Figure 3, when the primary path and secondary
path are requested from S1 to D1. These VSPTs consist of a disjoint path are requested from S1 to D1. These VSPTs consist of a disjoint
VSPT, which is replied to PCE1. When receiving the disjoint VSPT, VSPT, which is indicated in a PCRep to PCE1. When receiving the
PCE1 recognizes the disjoint request and disjoint VSPT information. disjoint VSPT, PCE1 recognizes the disjoint request and disjoint VSPT
PCE1 will then continue to process the request and compute the information. PCE1 will then continue to process the request and
diverse path using the BRPC procedure [RFC5441]. The detail encoding compute the diverse path using the BRPC procedure [RFC5441].
for the disjoint VSPT is described in Section 6.2. Encoding for the disjoint VSPT is described in Section 6.2.
Domain1 Domain2 Domain1 Domain2
+----------+ +----------+ +----------+ +----------+
| PCE1 | | PCE2 | S1: Source node | PCE1 | | PCE2 | S1: Source node
| BN1---BN4 | D1: Destination node | BN1---BN4 | D1: Destination node
| S1 BN2---BN5 D1 | BN1-BN6: Border nodes | S1 BN2---BN5 D1 | BN1-BN6: Border nodes
| BN3---BN6 | | BN3---BN6 |
+----------+ +----------+ +----------+ +----------+
Figure 2: Example network for diverse path computation Figure 2. Example Network for Diverse Path Computation
VSPT1: VSPT2: VSPT3:
VSPT1: VSPT2: VSPT3:
D1 D1 D1 D1 D1 D1
/ \ / \ / \ / \ / \ / \
BN4 BN5 BN4 BN6 BN5 BN6 BN4 BN5 BN4 BN6 BN5 BN6
Figure 2: Disjoint VSPT from PCE2 to PCE1 Figure 3. Disjoint VSPTs from PCE2 to PCE1
6.2. Disjoint VSPT encoding 6.2. Disjoint VSPT Encoding
Encoding for disjoint VSPT follows the definition of PCEP message Encoding for the disjoint VSPT follows the definition of PCEP message
encoding in [RFC5440]. encoding in [RFC5440].
PCEP PCRep message returns a disjoint VSPT as <path list> for each The PCEP PCRep message returns a disjoint VSPT as <path list> for
RP object (Request Parameter object). The order of <path> in <path each RP object (Request Parameter object). The order of <path> in
list> among <responses> implies a set of primary EROs (Explicit <path list> among <responses> implies a set of primary Explicit Route
Route Objects) and secondary EROs. Objects (EROs) and secondary EROs.
A PCE sending PCRep with a disjoint VSPT can reply with a partial A PCE sending a PCRep with a disjoint VSPT can reply with a partial
disjoint VSPT based on its network operation policy, but the order disjoint VSPT based on its network operation policy, but the order of
of <path> in <path list> must be aligned correctly. <path> in <path list> must be aligned correctly.
If confidentiality is required between domains, path key mechanism If confidentiality is required between domains, the path key
defined in [RFC5520] is used for a disjoint VSPT. mechanism defined in [RFC5520] is used for a disjoint VSPT.
Detailed disjoint VSPT encoding in Figure 2 is shown below, when a Below are the details of the disjoint VSPT encoding (in Figure 3),
primary path and a secondary path are requested from S1 to D1. when a primary path and a secondary path are requested from S1 to D1.
o Request ID #1 (Primary) o Request ID #1 (Primary)
- ERO1 BN4(TE route ID)- ...-D1(TE-Router ID) [for VSPT1] - ERO1 BN4(TE route ID)- ...-D1(TE-Router ID) [for VSPT1]
- ERO2 BN4(TE route ID)- ...-D1(TE-Router ID) [for VSPT2] - ERO2 BN4(TE route ID)- ...-D1(TE-Router ID) [for VSPT2]
- ERO3 BN5(TE route ID)- ...-D1(TE-Router ID) [for VSPT3] - ERO3 BN5(TE route ID)- ...-D1(TE-Router ID) [for VSPT3]
O Request ID #2 (Secondary) o Request ID #2 (Secondary)
- ERO4 BN5(TE route ID)- ...-D1(TE-Router ID) [for VSPT1] - ERO4 BN5(TE route ID)- ...-D1(TE-Router ID) [for VSPT1]
- ERO5 BN6(TE route ID)- ...-D1(TE-Router ID) [for VSPT2] - ERO5 BN6(TE route ID)- ...-D1(TE-Router ID) [for VSPT2]
- ERO6 BN6(TE route ID)- ...-D1(TE-Router ID) [for VSPT3] - ERO6 BN6(TE route ID)- ...-D1(TE-Router ID) [for VSPT3]
6.3. Path computation procedure 6.3. Path Computation Procedure
For end-to-end diverse path computation, the same mode of operation For end-to-end diverse path computation, the same mode of operation
as BRPC procedure can be applied (i.e. Step 1 to Step n in Section as that of the BRPC procedure can be applied (i.e., Step 1 to Step n
4.2 [RFC5441]). During this procedure, a question is how to in Section 4.2 of [RFC5441]). A question that must be considered is
recognize disjoint VSPTs. how to recognize disjoint VSPTs.
The recognition of disjoint VSPT is achieved by the PCE sending The recognition of disjoint VSPTs is achieved by the PCE sending a
PCReq to its neighbor PCE which maintains the path computation PCReq to its neighbor PCE, which maintains the path computation
request (PCReq) information. If PCReq has one or more SVEC object(s) request (PCReq) information. If the PCReq has one or more SVEC
with the appropriate dependency flags, the received PCRep will object(s) with the appropriate dependency flags, the received PCRep
contain the disjoint VSPT. If not, the received VSPT is a normal will contain the disjoint VSPT. If not, the received VSPT is a
VSPT based on the shortest path computation. normal VSPT based on the shortest path computation.
Note that the PCE will apply a suitable algorithm for computing Note that the PCE will apply a suitable algorithm for computing
requests with disjoint VSPT. The selection and application of the requests with disjoint VSPTs. The selection and application of the
appropriate algorithm is out of scope in this draft. appropriate algorithm is out of scope in this document.
7. Manageability considerations 7. Manageability Considerations
This section describes manageability considerations specified in This section describes manageability considerations specified in
[ID.pce-mngabl-reqs]. [PCE-MNG-REQS].
7.1. Control of Function and Policy
7.1. Control of Function and Policy
In addition to [RFC5440], PCEP implementations should allow the PCC In addition to [RFC5440], PCEP implementations should allow the PCC
to be responsible for mapping the requested paths to computation to be responsible for mapping the requested paths to computation
requests. The PCC should construct the SVECs to indentify and requests. The PCC should construct the SVECs to identify and
associate SVEC relationships. associate SVEC relationships.
7.2. Information and Data Models, e.g. MIB modules 7.2. Information and Data Models (MIB Modules)
There are currently no additional parameters for MIB modules. There There are currently no additional parameters for MIB modules. There
is value in a MIB module that details the SVEC association. This would be value in a MIB module that details the SVEC association.
work is currently out of scope of this document. This work is currently out of scope of this document.
7.3. Liveness Detection and Monitoring 7.3. Liveness Detection and Monitoring
The associated SVEC in this document allows PCEs to compute optimal The associated SVEC in this document allows PCEs to compute optimal
sets of diverse paths. This type of path computation may require sets of diverse paths. This type of path computation may require
more time to obtain its results. Therefore, it is recommended for more time to obtain its results. Therefore, it is recommended for
PCEP to support PCE monitoring mechanism specified in [ID.pce- PCEP to support the PCE monitoring mechanism specified in [RFC5886].
monitor].
7.4. Verifying Correct Operation 7.4. Verifying Correct Operation
[RFC5440] provides the sufficient descriptions for this document. So, [RFC5440] provides a sufficient description for this document. There
there are no additional considerations. are no additional considerations.
7.5. Requirements on Other Protocols and Functional Components 7.5. Requirements on Other Protocols and Functional Components
This document does not require any other protocol and functional This document does not require any other protocol and functional
components. components.
7.6. Impact on Network Operation 7.6. Impact on Network Operation
[RFC5440] provides descriptions for the mechanisms discussed in this [RFC5440] provides descriptions for the mechanisms discussed in this
document. There is value in considering that large associated SVECs document. There is value in considering that large associated SVECs
will require greater PCE resources, compared to non-associated SVECs. will require greater PCE resources, compared to non-associated SVECs.
Additionally, the sending of large associated SVECs within multiple Additionally, the sending of large associated SVECs within multiple
PCReq messages will require more network resources. Solving these PCReq messages will require more network resources. Solving these
specific issues is out of scope of this document. specific issues is out of scope of this document.
8. Security Considerations 8. Security Considerations
This document describes the usage of SVEC list, and does not have This document describes the usage of the SVEC list, and does not have
any extensions for PCEP protocol. The security of the procedures any extensions for PCEP. The security of the procedures described in
described in this document depends on PCEP protocol [RFC5440]. this document depends on PCEP [RFC5440]. However, a PCE that
However, a PCE that supports associated SVECs may be open to DoS supports associated SVECs may be open to Denial-of-Service (DoS)
attack from a rogue PCC. A PCE may be made to queue large numbers of attacks from a rogue PCC. A PCE may be made to queue large numbers
requests waiting for other requests that will never arrive. of requests waiting for other requests that will never arrive.
Additionally a PCE might be made to compute exceedingly complex Additionally, a PCE might be made to compute exceedingly complex
associated SVEC computations. These DoS attacks may be mitigated associated SVEC computations. These DoS attacks may be mitigated
with the use of practical SVEC list limits, as well as: with the use of practical SVEC list limits, as well as:
o Using the same number of simultaneous service provisioning o Applying provisioning to PCEs, e.g., for a given number of
would be recommended. simultaneous services (recommended).
o Priority-based multi-queuing mechanism in which path
computation requests with a smaller SVEC list are prioritized
for path computation processing
o Specifying which PCCs may request large SVEC associations o Using a priority-based multi-queuing mechanism in which path
through PCE access policy control. computation requests with a smaller SVEC list are prioritized for
path computation processing.
9. IANA Considerations o Specifying which PCCs may request large SVEC associations through
PCE access policy control.
This document has no specific extension for PCEP messages, objects 9. References
and its parameters and does not require any registry assignment.
10. References 9.1. Normative References
10.1. Normative References [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path
Computation Element (PCE)-Based Architecture",
RFC 4655, August 2006.
[RFC4655] A. Farrel, JP. Vasseur and J. Ash, "A Path Computation [RFC4657] Ash, J., Ed., and J. Le Roux, Ed., "Path Computation
Element (PCE)-Based Architecture," RFC 4655, September Element (PCE) Communication Protocol Generic
2006. Requirements", RFC 4657, September 2006.
[RFC4657] J. Ash and J.L. Le Roux, "Path Computation Element (PCE) [RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S.
Communication Protocol Generic Requirements," RFC 4757, Yasukawa, Ed., "Extensions to Resource Reservation
September 2006. Protocol - Traffic Engineering (RSVP-TE) for Point-to-
Multipoint TE Label Switched Paths (LSPs)", RFC 4875,
May 2007.
[RFC4875] R. Aggarwal, D. Papadimitriou, and S. Yasukawa, [RFC5440] Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path
"Extensions to Resource Reservation Protocol - Traffic Computation Element (PCE) Communication Protocol
Engineering (RSVP-TE) for Point-to-Multipoint TE Label (PCEP)", RFC 5440, March 2009.
Switched Paths (LSPs)," RFC4875, May 2007.
[RFC5440] Ayyangar, A., Farrel, A., Oki, E., Atlas, A., Dolganow A. [RFC5441] Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le
Ikejiri, Y., Kumaki, K., Vasseur, J., and J. Roux, "Path Roux, "A Backward-Recursive PCE-Based Computation
Computation Element (PCE) communication Protocol (PCEP)," (BRPC) Procedure to Compute Shortest Constrained
RFC5440, March. 2009. Inter-Domain Traffic Engineering Label Switched
Paths", RFC 5441, April 2009.
[RFC5441] JP. Vasseur, R. Zhang, N. Bitar and JL. Le Roux, "A [RFC5520] Bradford, R., Ed., Vasseur, JP., and A. Farrel,
Backward Recursive PCE-based Computation (BRPC) Procedure "Preserving Topology Confidentiality in Inter-Domain
to Compute Shortest Constrained Inter-domain Traffic Path Computation Using a Path-Key-Based Mechanism",
Engineering Label Switched Paths," RFC5441, April 2009. RFC 5520, April 2009.
[RFC5520] R. Bradford, JP. Vasseur, and A. Farrel, "Preserving [RFC5521] Oki, E., Takeda, T., and A. Farrel, "Extensions to the
Topology Confidentiality in Inter-Domain Path Computations Path Computation Element Communication Protocol (PCEP)
Using a Path-Key-Based mechanism," RFC5520, April 2009. for Route Exclusions", RFC 5521, April 2009.
[RFC5521] E. Oki, T. Takeda and A. Farrel, "Extensions to the Path [RFC5557] Lee, Y., Le Roux, JL., King, D., and E. Oki, "Path
Computation Element Communication Protocol (PCEP) for Computation Element Communication Protocol (PCEP)
Route Exclusions," RFC5521, April 2009. Requirements and Protocol Extensions in Support of
Global Concurrent Optimization", RFC 5557, July 2009.
[RFC5557] Y. Lee, JL. Le Roux, D. King and E. Oki, "Path Computation 9.2. Informative References
Element Communication Protocol (PCECP) Requirements and
Protocol Extensions In Support of Global Concurrent
Optimization," RFC5557, July 2009.
10.2. Informative References [H-PCE] King, D., Ed., and A. Farrel, Ed., "The Application of
the Path Computation Element Architecture to the
Determination of a Sequence of Domains in MPLS &
GMPLS", Work in Progress, December 2009.
[ID.pce-p2mp-ext] Takeda, T., Chaitou M., Le Roux, J.L., Ali Z.,Zhao, [PCE-MNG-REQS] Farrel, A., "Inclusion of Manageability Sections in
Q., King, D., "Extensions to the Path Computation Element PCE Working Group Drafts", Work in Progress, July
Communication Protocol (PCEP) for Point-to-Multipoint 2009.
Traffic Engineering Label Switched Paths," draft-ietf-pce-
pcep-p2mp-extensions, work in progress, February, 2010.
[ID.pce-mngabl-reqs] A. Farrel, "Inclusion of Manageability Sections [RFC5886] Vasseur, JP., Ed., Le Roux, JL., and Y. Ikejiri, "A
in PCE Working Group Drafts," draft-ietf-pce- Set of Monitoring Tools for Path Computation Element
manageability-requirements, work in progress, July 2009. (PCE)-Based Architecture", RFC 5886, June 2010.
[ID.h-pce] King, D., Farrel, A. "The Application of the Path [RFC6006] Zhao, Q., Ed., King, D., Ed., Verhaeghe, F., Takeda,
Computation Element Architecture to the Determination of a T., Ali, Z., and J. Meuric, "Extensions to the Path
Sequence of Domains in MPLS & GMPLS", draft-king-pce- Computation Element Communication Protocol (PCEP) for
hierarchy-fwk, work in progress, December 2009. Point-to-Multipoint Traffic Engineering Label Switched
Paths", RFC 6006, September 2010.
11. Acknowledgements 10. Acknowledgements
The authors would like to thank Adrian Farrel, Julien Meuric and The authors would like to thank Adrian Farrel, Julien Meuric, and
Filippo Cugini for their valuable comments. Filippo Cugini for their valuable comments.
12. Authors' Addresses Authors' Addresses
Itaru Nishioka Itaru Nishioka
NEC Corp. NEC Corp.
1753 Shimonumabe, 1753 Shimonumabe,
Kawasaki, 211-8666, Kawasaki, 211-8666,
Japan Japan
Phone: +81 44 396 3287 Phone: +81 44 396 3287
Email: i-nishioka@cb.jp.nec.com EMail: i-nishioka@cb.jp.nec.com
Daniel King Daniel King
Old Dog Consulting Old Dog Consulting
United Kingdom United Kingdom
Phone: +44 7790 775187 Phone: +44 7790 775187
Email: daniel@olddog.co.uk EMail: daniel@olddog.co.uk
 End of changes. 178 change blocks. 
469 lines changed or deleted 464 lines changed or added

This html diff was produced by rfcdiff 1.39. The latest version is available from http://tools.ietf.org/tools/rfcdiff/