draft-ietf-pce-pcep-svec-list-00.txt   draft-ietf-pce-pcep-svec-list-01.txt 
Internet Engineering Task Force I. Nishioka
Network Working Group I. Nishioka Internet-Draft NEC
Internet Draft NEC
Intended Status: Informational Daniel King Intended Status: Informational Daniel King
Expires: March 2009 Old Dog Consulting Created: March 9, 2009 Old Dog Consulting
September 29, 2008 Expires: September 9, 2009
The use of SVEC (Synchronization VECtor) list for Synchronized The use of SVEC (Synchronization VECtor) list for Synchronized
dependent path computations dependent path computations
draft-ietf-pce-pcep-svec-list-00.txt draft-ietf-pce-pcep-svec-list-01.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with
applicable patent or other IPR claims of which he or she is aware the provisions of BCP 78 and BCP 79.
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six months
months and may be updated, replaced, or obsoleted by other and may be updated, replaced, or obsoleted by other documents at any
documents at any time. It is inappropriate to use Internet-Drafts time. It is inappropriate to use Internet-Drafts as reference
as reference material or to cite them other than as "work in material or to cite them other than as "work in progress."
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 29, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract Abstract
A Path Computation Element (PCE) performing dependent path A Path Computation Element (PCE) performing dependent path
computations, for instance calculating a diverse working and computations, for instance calculating a diverse working and
protected path do not share common network points, would need to protected path do not share common network points, would need to
synchronize the computations in order to increase the probability synchronize the computations in order to increase the probability of
of meeting the working and protected path disjoint objective and meeting the working and protected path disjoint objective and
network resource optimization objective. When a PCE computes network resource optimization objective. When a PCE computes
multiple sets of dependent path computation requests concurrently, multiple sets of dependent path computation requests concurrently,
it is required to use Synchronization VECtor (SVEC) list for it is required to use Synchronization VECtor (SVEC) list for
association among the sets of dependent path computation requests. association among the sets of dependent path computation requests.
This document describes the usage of multiple SVECs in the SVEC SVEC is also applicable to end-to-end diverse path computation
list and its processing guideline, for the synchronized computation across multiple domains. This document describes the usage of SVECs
of dependent paths. in the SVEC list and diverse path computation guideline, for the
synchronized computation of dependent paths.
Table of Contents
1. Terminology...............................................3
2. Introduction..............................................3
3. SVEC Association scenarios................................5
3.1. Synchronized computation for diverse path requests...5
3.2. Synchronized computation for point-to-multipoint path
requests..................................................6
4. Association among SVEC....................................6
4.1. Association among SVEC...............................6
4.2. Non-associated SVECs.................................7
5. Processing of SVEC list...................................8
5.1. Single PCE, single domain environments...............8
5.2. Multi-PCE, single domain environments................8
5.3. Multi-PCE, multi-domain environments.................9
6. Manageability considerations..............................9
6.1. Control of Function and Policy.......................9
6.2. Information and Data Models, e.g. MIB modules........9
6.3. Liveness Detection and Monitoring....................9
6.4. Verifying Correct Operation.........................10
6.5. Requirements on Other Protocols and Functional Components
.........................................................10
6.6. Impact on Network Operation.........................10
7. Security Considerations..................................10
8. IANA Considerations......................................10
9. References...............................................10
9.1. Normative References................................10
9.2. Informative References..............................11
Author's Addresses..........................................12
Intellectual Property Statement.............................13
Disclaimer of Validity......................................13
Conventions used in this document Contents
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 1. Terminology....................................................
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 2. Introduction...................................................
this document are to be interpreted as described in RFC-2119. 3. SVEC association scenarios.....................................
3.1. Synchronized computation for diverse path requests.........
3.2. Synchronized computation for point-to-multipoint
path requests..............................................
4. SVEC association...............................................
4.1. Associated SVECs...........................................
4.2. Non-associated SVECs.......................................
5. Processing of SVEC list........................................
5.1. Single PCE, single domain environments.....................
5.2. Multi-PCE, single domain environments......................
5.3. Single PCE, Multi-domain environments......................
6. End-to-end diverse path computation............................
6.1. Disjoint VSPTs.............................................
6.2. Disjoint VSPTs Encoding....................................
6.3. Path commutation in PCE....................................
7. Manageability considerations...................................
7.1. Control of Function and Police.............................
7.2. Information and Data Models, e.g. MIB modules..............
7.3. Liveness Detection and Monitoring..........................
7.4. Verifying Correct Operation................................
7.5. Requirements on Other Protocols and Functional Components..
7.6. Impact on Network Operation................................
8. Security Considerations........................................
9. IANA Considerations............................................
10. References....................................................
10.1. Normative References......................................
10.2. Informative References....................................
11. Authors Addresses.............................................
12. Intellectual Property Consideration...........................
12. Disclaimer of Validity........................................
13. Full Copyright Statement......................................
1. Terminology 1. Terminology
Terminology used in this document: This document uses PCE terminology defined in [RFC4655],
[RFC4875], and [RFC5440].
PCC (Path Computation Client): Any client application requesting a
path computation to be performed by a Path Computation
Element.
PCE (Path Computation Element): An entity (component, application,
or network node) that is capable of computing a network path
or route based on a network graph, and applying computational
constraints.
PCEP (PCE Communication Protocol) : The PCE communication Protocol.
PCEP Peer : A neighbor element involved in a PCEP session (i.e. a
PCC or a PCE).
GCO (Global Concurrent Optimization): A concurrent path GCO (Global Concurrent Optimization): A
computation application where a set of TE paths is computed concurrent path computation application where a set of TE paths is
concurrently in order to efficiently utilize network computed concurrently in order to efficiently utilize network
resources. resources.
Associated SVECs : A group of multiple SVECs (Synchronization Associated SVECs : A group of multiple SVECs (Synchronization
VECtors) to indicate a set of synchronized or concurrent path VECtors) to indicate a set of synchronized or concurrent path
computations. computations.
VSPT: Virtual Shortest Path Tree
2. Introduction 2. Introduction
[ID.pce-pcep] describes the specifications for PCEP (Path [RFC5440] describes the specifications for PCEP (Path Computation
Computation Element communication Protocol). PCEP facilitates the Element communication Protocol). PCEP facilitates the communication
communication between a Path Computation Client(PCC) and a Path between a Path Computation Client(PCC) and a Path Computation Element
Computation Element (PCE), or between two PCEs based on PCE (PCE), or between two PCEs based on PCE architecture [RFC4655]. PCEP
architecture [RFC4655]. PCEP interactions include path computation interactions include path computation requests and path computation
requests and path computation replies. replies.
[ID.pce-gco] specifies a global concurrent path computation [ID.pce-gco] specifies a global concurrent path computation
application for the efficient use of network resources, called GCO, application for the efficient use of network resources, called GCO,
based on required objective functions (OFs). To compute a set of based on required objective functions (OFs). To compute a set of
traffic-engineered paths for the GCO application, PCEP supports traffic-engineered paths for the GCO application, PCEP supports the
the synchronous and dependent path computation requests required synchronous and dependent path computation requests required in
in [RFC4657]. When a PCC or PCE sends such path computation [RFC4657]. When a PCC or PCE sends such path computation requests to
requests to a PCE, Synchronization VECtor (SVEC) allows the PCC or a PCE, Synchronization VECtor (SVEC) allows the PCC or PCE to
PCE to specify a list of multiple path computation requests that specify a list of multiple path computation requests that must be
must be synchronized along with a potential dependency.[ID.pce- synchronized along with a potential dependency.[RFC5440] defines
pcep] defines two synchronous path computation modes using SVEC. two synchronous path computation modes using SVEC.
o Bundle of a set of independent and synchronized path o Bundle of a set of independent and synchronized path computation
computation requests, requests.
o Bundle of a set of dependent and synchronized path computation o Bundle of a set of dependent and synchronized path computation
requests. requests.
These are exclusive modes. If one of the dependency flags (i.e. These are exclusive modes. If one of the dependency flags (i.e.
Node, Link or Shared Risk Link Groups (SRLG) diverse flags) in a Node, Link or Shared Risk Link Groups (SRLG) diverse flags) in a SVEC
SVEC is set, the SVEC indicates a set of synchronous path is set, the SVEC indicates a set of synchronous path computation
computation requests with a dependency. In order to be requests with a dependency. In order to be synchronized among
synchronized among multiple sets of path computation requests multiple sets of path computation requests with a dependency, it is
with a dependency, it is necessary to use other SVECs. necessary to use other SVECs.
It is important for the PCE, when performing path computations, It is important for the PCE, when performing path computations, to
to synchronize any path computation requests with a dependency. synchronize any path computation requests with a dependency. For
For example, consider a protected end-to-end service. Two diverse example, consider a protected end-to-end service. Two diverse path
path computation requests are needed to compute the disjointed computation requests are needed to compute the disjointed working and
working and protected paths. If the diverse path requests are protected paths. If the diverse path requests are computed
computed sequentially, fulfillment of the initial diverse path sequentially, fulfillment of the initial diverse path computation
computation without consideration of the second diverse path without consideration of the second diverse path computation and
computation and disjoint constraint, may result in the PCE disjoint constraint, may result in the PCE providing sub-optimal
providing sub-optimal results for the second one, or fail to meet results for the second one, or fail to meet the disjoint requirement
the disjoint requirement altogether. altogether.
This document defines the handling of synchronous path Additionally SVEC can be applied to an end-to-end diverse path
computation for PCE and multiple set of path computation request computation that traverse multiple domains. [ID.pce-brpc] describes
with a dependency. The following scenarios are specifically two approaches, synchronous (i.e. simultaneous) and 2-step
described: approaches, for the end-to-end diverse path computation across a
chain of domains. The path computation procedure is specified for
the 2-step approaches in [ID.xro], but no guidelines are provided
for a synchronous approach.
This document defines the handling of synchronous path computation
for PCE and multiple set of path computation request with a
dependency. The following scenarios are specifically described:
o Single domain, single PCE, dependent and synchronized path o Single domain, single PCE, dependent and synchronized path
computation request. computation request.
o Multi-domain, multiple-PCE, dependent and synchronized path o Single domain, multiple-PCE, dependent and synchronized path
computation request. computation request.
o Multi-domain, dependent and synchronized path computation
request, including end-to-end diverse path computation.
The association among multiple SVECs and the processing rules to The association among multiple SVECs and the processing rules to
support multiple sets of synchronized dependent path computation support multiple sets of synchronized dependent path computation
requests is also described in this document. Path computation requests is also described in this document. Path computation
algorithms for the associated path computation requests are out algorithms for the associated path computation requests are out of
of scope in this document. scope in this document.
The SVEC association and its processing rule do not require any The SVEC association and its processing rule do not require any
extension to PCEP message and object formats, when computing a extension to PCEP message and object formats, when computing a GCO
GCO for multiple diverse paths. In addition, the use of multiple for multiple diverse paths. In addition, the use of multiple SVECs is
SVECs is not restricted to only SRLG, Node and Link diversity not restricted to only SRLG, Node and Link diversity currently
currently defined in the SVEC object, [ID.pce-pcep], but is also defined in the SVEC object, [RFC5440], but is also available for
available for other dependent path computation requests. other dependent path computation requests.
The SVEC association is available to both multiple PCE path The SVEC association is available to both multiple PCE path
computations as well as a single PCE path computation. computations as well as a single PCE path computation.
3. SVEC association scenarios 3. SVEC association scenarios
This section clarifies several path computation scenarios, in This section clarifies several path computation scenarios, in which
which SVEC association can be applied. Also, any combination of SVEC association can be applied. Also, any combination of scenarios
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
When computing two or more point-to-point diverse paths, a PCE may When computing two or more point-to-point diverse paths, a PCE may
compute these diverse paths concurrently, in order to increase the compute these diverse paths concurrently, in order to increase the
probability of meeting primary and secondary path disjoint probability of meeting primary and secondary path disjoint objective
objective and network resource optimization objective. and network resource optimization objective.
Two scenarios can be considered for the SVEC association of point- Two scenarios can be considered for the SVEC association of
to-point diverse paths. point-to-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 When concurrent path computation of two or more end-to-end diverse
diverse paths is requested, SVEC association is needed among paths is requested, SVEC association is needed among diverse path
diverse path requests. Note here that each diverse path request requests. Note here that each diverse path request consists of
consists of primary, secondary, and etc., in which are grouped primary, secondary, and etc., in which are grouped with one SVEC.
with one SVEC.
Example of this scenario: When there are two associated end-to- Example of this scenario: When there are two associated end-to-end
end diverse path requests with primary and secondary, all diverse path requests with primary and secondary, all requests must
requests must be computed in a synchronized manner. be computed in a synchronized manner.
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 of an end-to-end primary path
and several segmented secondary paths is requested, SVEC When concurrent path computation of an end-to-end primary path and
association is needed among primary/segmented secondary-1 several segmented secondary paths is requested, SVEC association is
request, primary/segmented secondary-2 request, and etc. needed among primary/segmented secondary-1 request, primary/segmented
secondary-2 request, and etc.
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, which is used for specifying the segment for secondary computed, which is used for specifying the segment for secondary
paths. Otherwise, segment for secondary path requests are paths. Otherwise, segment for secondary path requests are specified
specified in advance, by using XRO and/or IOR constraints in the in advance, by using XRO and/or IOR constraints in the primary
primary request. 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 If a point-to-multipoint paths request is represented as a set of
of point-to-point paths [ID.pce-p2mp-ext], two or more point-to- point-to-point paths [ID-pce-p2mp-ext], two or more point-to-
multipoint path computation requests can be associated for multipoint path computation requests can be associated for concurrent
concurrent path computation, in order to optimize network path computation, in order to optimize network resources.
resources.
o point-to-multipoint paths and its secondary paths o point-to-multipoint paths and its secondary paths
When concurrent path computation of a point-to-multipoint path When concurrent path computation of a point-to-multipoint path and
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 multipoint path and its point-to-multipoint secondary paths
[ID.p2mp-te-bypass] is requested, SVEC association is needed [ID.p2mp-te-bypass] is requested, SVEC association is needed among
among these requests. these requests.
In this scenario, we use the same assumption as "end-to-end In this scenario, we use the same assumption as "end-to-end primary
primary path and its segmented secondary paths scenario" in path and its segmented secondary paths scenario" in section 3.1
section 3.1
4. Association among SVEC 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. Association among SVEC 4.1. Associated SVECs
Associated SVECs mean that there are relationships among multiple Associated SVECs mean that there are relationships among multiple
SVECs. Request-IDs in the SVEC objects are used to indicate the SVECs. Request-IDs 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 more
more than two SVECs, this indicates associated SVECs. When than two SVECs, this indicates associated SVECs. When associating
associating among SVECs, only one request-ID may in the SVEC among SVECs, only one request-ID may in the SVEC object may be
object may be contained in the other SVEC object. This contributes contained in the other SVEC object. This contributes to reducing the
to reducing the message size of PCEP request. Even in this case, message size of PCEP request. Even in this case, all of the path
all of the path computation requests are synchronized. computation requests are synchronized.
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 and the other SVECs are associated, and path computation SVEC is associating the other SVECs, and path computation requests
requests from Request-ID#1 to Request-ID#Z must be synchronized. from Request-ID#1 to Request-ID#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 #4..., 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 #4, Request-ID #5
........ ........
<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
Note that path computation requests that do not have other SVECs,
like Request-ID #3, may be contained in the associated SVEC. This
request is also synchronized.
4.2. Non-associated SVECs 4.2. Non-associated SVECs
Non-associated SVECs mean that there are no relationships among Non-associated SVECs mean that there are no relationships among
SVECs. If SVEC objects in PECP request messages do not have the SVECs. If SVEC objects in PECP request messages do not have the same
same request-ID, the relationship among these SVECs is not request-ID, the relationship among these SVECs is not associated.
associated. Below is an example of non-associated SVECs that does Below is an example of non-associated SVECs that does not contain any
not contain any same request-IDs. same 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 #4, Request-ID #5 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
When PCEP receives PCReq messages with more than two SVEC objects When PCEP receives PCReq messages with more than two SVEC objects 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. The objects in order to identify any associations among them. The SVEC
SVEC objects may be received in a single or multiple PCReq objects may be received in a single or multiple PCReq message(s). In
message(s). In the later case, the PCE may start a SyncTimer as the later case, the PCE may start a SyncTimer as recommended in
recommended in [ID.pce-pcep]. After receiving the whole path [RFC5440]. After receiving the whole path computation requests,
computation requests, the analysis for associated SVECs has to be the analysis for associated SVECs has to be started.
started.
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 requests in the associated SVEC objects are treated in a synchronous
synchronous manner for GCO application. manner for GCO application.
If the PCE does not have capability to handle the associated SVEC If the PCE does not have capability to handle the associated SVEC
objects, it may send a PCErr message with Error-Type="Capability objects, it may send a PCErr message with Error-Type="Capability not
not supported". supported".
5.2. Multi-PCE, single domain environments 5.2. Multi-PCE, single domain environments
Currently no mechanisms exist to manage co-ordination of dependent Currently no mechanisms exist to manage co-ordination of dependent
SVEC requests between multiple PCE`s in the same domain. If a PCC SVEC requests between multiple PCE`s in the same domain. If a PCC
sends a path computation request to a PCE and then sends a second sends a path computation request to a PCE and then sends a second
service path computation request, which is required to be disjoint service path computation request, which is required to be disjoint
from the first service, and this request is sent to a different from the first service, and this request is sent to a different PCE
PCE in the domain, no SVEC object correlation function between the in the domain, no SVEC object correlation function between the PCEs
PCEs is currently available. Equally, associated SVECs are not is currently available. Equally, associated SVECs are not sent to the
sent to the different PCEs in the domain. different PCEs in the domain.
5.3. Multi-PCE, multi-domain environments 5.3. Single PCE, Multi-domain environments
When more than two PCEs are used to concurrently compute a When multiple PCEs located in separate domains are used to
protected end-to-end path across multiple domains, additional concurrently compute an end-to-end diverse path across multiple
processing may be required. If the PCReq message contains multiple domains, additional processing may be required. The path computation
associated SVEC objects and these SVEC objects contain path process for the end-to-end diverse path is described in Section 6.
computation requests that will be sent to the next PCE along the
path computation chain. Intermediate PCEs receiving such PCReq
messages may re-construct associations among SVEC objects, and
then send PCReq messages to corresponding next PCEs. If the
associated SVECs are re-constructed at the intermediate PCE, the
PCE must not start path computation until all PCRep messages are
received from neighbor PCEs. In addition, it is not recommended
that SVEC objects coming from different PCReq messages are re-
constructed. This may contribute to resource optimization from
network operator`s point of view, but it is unrealistic in the
case of multiple PCE path computation.
6. Manageability considerations Furthermore, if the PCReq message contains multiple associated SVEC
objects and these SVEC objects contain path computation requests that
will be sent to the next PCE along the path computation chain.
Intermediate PCEs receiving such PCReq messages may re-construct
associations among SVEC objects, and then send PCReq messages to
corresponding PCEs located in neighboring domains. If the associated
SVECs are re-constructed at the intermediate PCE, the PCE must not
start path computation until all PCRep messages have been received
from neighbor PCEs. In addition, it is not recommended that SVEC
objects coming from different PCReq messages are re-constructed. This
may contribute to resource optimization from network operator`s point
of view, but it is unrealistic in the case of multiple PCE path
computation scenarios.
6. End-to-end diverse path computation
End-to-end diverse path is a set of primary path and secondary paths,
which do not share common network resources across domains. To
compute the end-to-end diverse path, BRPC procedure can be used.
[ID.pce-brpc] describes two approaches, synchronous (i.e.
simultaneous)and 2-step approaches, for the end-to-end diverse
path computation across a chain of domains. The 2-step approach is
described in [ID.xro]. This section provides how to compute end-to
-end diverse path in the synchronous approach.
6.1. Disjoint VSPTs
BRPC procedure constructs a VSPT (virtual shortest path tree) to
inform the enquiring PCE of potential paths to the destination node.
In the end-to-end diverse path computation, disjoint information
among the potential paths must be preserved in the VSPT to ensure end
-to-end disjoint path. In order to preserve disjoint information,
disjoint VSPTs are sent in the PCEP PCRep message.
A definition of the disjoint VSPTs is a collection of VSPTs, in which
each VSPT contains a potential set of primary and secondary paths.
Figure 1 is an example network and its disjoint VSPTs when primary
path and secondary path are requested. Here, transit nodes within
domains are not depicted, and PCE1 and PCE2 may be embedded in
boarder nodes.
Example network:
Domain1 Domain2
+----------+ +----------+
| PCE1 | | PCE2 | S1: Source node
| BN1---BN4 | D1: Destination node
| S1 BN2---BR5 D1 | BN1-BN6: Border nodes
| BN3---BN6 |
| | | |
+----------+ +----------+
VSPTs from PCE2:
VSPT1; VSPT2; VSPT3;
D1 D1 D1
/ \ / \ / \
BR4 BR5 BR4 BR6 BR5 BR6
Figure 1: An example of diverse path computation
6.2. Disjoint VSPT Encoding
Encoding for disjoint VSPTs follows the definition of PCEP message
encoding in [RFC5440].
PCEP PCRep message returns disjoint VSPTs as <path list> for each RP
object. The order of <path> in <path list> among <responses> implies
a set of primary EROs and secondary EROs.
Below shows simple example in Figure 1 if a primary path and a
secondary path are requested.
o Request ID #1 (Primary)
- ERO1 BR4(TE route ID)- ...-D1(TE-Router ID) [for VSPT1]
- ERO2 BR4(TE route ID)- ...-D1(TE-Router ID) [for VSPT2]
- ERO3 BR5(TE route ID)- ...-D1(TE-Router ID) [for VSPT3]
O Request ID #2 (Secondary)
- ERO4 BR5(TE route ID)- ...-D1(TE-Router ID) [for VSPT1]
- ERO5 BR6(TE route ID)- ...-D1(TE-Router ID) [for VSPT2]
- ERO6 BR6(TE route ID)- ...-D1(TE-Router ID) [for VSPT2]
6.3. Path computation procedure
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
4.2 [ID.pce-brpc]). During this procedure, a questions is how to
recognize disjoint VSPTs.
The recognition of disjoint VSPT is achieved by the PCE sending PCreq
to its neighbor PCE which maintains the path computation request
(PCReq) information. If PCreq has one or more SVEC object(s) with the
appropriate diverse flags, the received PCrep will contain the
disjoint VSPT. If not, the received VSTP is a normal VSPT based on
the shortest path computation.
Note that the PCE can apply a suitable algorithm for computing
disjoint VSPT. Selection and application of the appropriate
algorithm is out of scope in this draft.
7. Manageability considerations
This section describes manageability considerations specified in This section describes manageability considerations specified in
[ID.pce-mngabl-reqs]. [ID.pce-mngabl-reqs].
6.1. Control of Function and Policy 7.1. Control of Function and Policy
In addition to section 8.1 to [ID.pce-pcep], PCEP implementation In addition to section 8.1 to [RFC5440], PCEP implementation
should allow the configuration of association among SVECs on PCCs. should allow the configuration of association among SVECs on PCCs.
o the capability to configure SVEC association. o the capability to configure SVEC association.
6.2. Information and Data Models, e.g. MIB modules 7.2. Information and Data Models, e.g. MIB modules
There are no additional parameters for MIB modules. There are no additional parameters for MIB modules.
6.3. Liveness Detection and Monitoring 7.3. Liveness Detection and Monitoring
The associated SVEC in this document allows PCEs to compute The associated SVEC in this document allows PCEs to compute optimal
optimal sets of diverse path. This type of path computation may sets of diverse path. This type of path computation may require more
require more time to obtain its results. Therefore, it is time to obtain its results. Therefore, it is recommended for PCEP to
recommended for PCEP to support PCE monitoring mechanism specified support PCE monitoring mechanism specified in [ID.pce-monitor].
in [ID.pce-monitor].
6.4. Verifying Correct Operation 7.4. Verifying Correct Operation
Section 8.4 in [ID.pce-pcep] provides the sufficient descriptions Section 8.4 in [RFC5440] provides the sufficient descriptions
for this document. So, there are no additional considerations. for this document. So, there are no additional considerations.
6.5. Requirements on Other Protocols and Functional Components 7.5. Requirements on Other Protocols and Functional Components
This document does not require anything on other protocol and This document does not require anything on other protocol and
functional components. functional components.
6.6. Impact on Network Operation 7.6. Impact on Network Operation
Section 8.6 in [ID.pce-pcep] provides the sufficient descriptions Section 8.6 in [RFC5440] provides the sufficient descriptions
for this document. So, there are no additional considerations. for this document. So, there are no additional considerations.
7. Security Considerations 8. Security Considerations
This document defines the usage of SVEC list, and does not have This document defines the usage of SVEC list, and does not have any
any extensions for PCEP protocol. Therefore the security of this extensions for PCEP protocol. Therefore the security of this document
document depends on that of PCEP protocol. depends on that of PCEP protocol.
8. IANA Considerations 9. IANA Considerations
This document has no specific extension for PCEP messages, objects This document has no specific extension for PCEP messages, objects
and its parameters and does not require any registry assignment. and its parameters and does not require any registry assignment
9. References
9.1. Normative References 10. References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 10.1. Normative References
Requirement Levels," BCP 14, RFC 2119, March 1997.
[RFC4655] A. Farrel, JP. Vasseur and J. Ash, "A Path Computation [RFC4655] A. Farrel, JP. Vasseur and J. Ash, "A Path Computation
Element (PCE)-Based Architecture," RFC 4655, September Element (PCE)-Based Architecture," RFC 4655, September
2006. 2006.
[RFC4657] J. Ash and J.L. Le Roux, "Path Computation Element (PCE) [RFC4657] J. Ash and J.L. Le Roux, "Path Computation Element (PCE)
Communication Protocol Generic Requirements," RFC 4757, Communication Protocol Generic Requirements," RFC 4757,
September 2006. September 2006.
[RFC4875] R. Aggarwal, D. Papadimitriou, and S. Yasukawa, " [RFC4875] R. Aggarwal, D. Papadimitriou, and S. Yasukawa, "
Extensions to Resource Reservation Protocol - Traffic Extensions to Resource Reservation Protocol - Traffic
Engineering (RSVP-TE) for Point-to-Multipoint TE Label Engineering (RSVP-TE) for Point-to-Multipoint TE Label
Switched Paths (LSPs)," RFCCC4875, May 2007. Switched Paths (LSPs)," RFCCC4875, May, 2007.
9.2. Informative References
[ID.pce-pcep]
JP. Vasseur and JL. Le Roux, "Path Computation Element 10.2. Informative References
(PCE) communication Protocol (PCEP) - Version 1," draft-
ietf-pce-pcep-15 Work in progress, Sep. 2008.
[ID.pce-gco] [RFC5440] Ayyangar, A., Farrel, A., Oki, E., Atlas, A., Dolganow,
A., Ikejiri, Y., Kumaki, K., Vasseur, J., and J. Roux,
"Path Computation Element (PCE) Communication Protocol
(PCEP)", RFC 5440, March 2009.
Y. Lee, JL. Le Roux, D. King and E. Oki, "Path [ID.pce-gco] Y. Lee, JL. Le Roux, D. King and E. Oki, "Path
Computation Element Communication Protocol (PCECP) Computation Element Communication Protocol (PCECP)
Requirements and Protocol Extensions In Support of Requirements and Protocol Extensions In Support of
Global Concurrent Optimization," draft-ietf-pce-global- Global Concurrent Optimization," draft-ietf-pce-global-
concurrent-optimization-04 Work in progress, July. 2008. concurrent-optimization-08 Work in progress, Jan. 2009.
[ID.pce-p2mp-ext] [ID.pce-brpc] JP. Vasseur, R. Zhang, N. Bitar and JL. Le Roux, "A
Backward Recursive PCE-based Computation (BRPC)
Procedure To Compute Shortest Constrained Inter-
domain Traffic Engineering Label Switched Paths,"
draft-ietf-pce-brpc-09, Work in progress, April 2008.
M. Chaitou, JL. Le Roux, and Z. Ali, "Extensions to the [ID.xro] E. Oki, T. Takeda and A. Farrel, "Extensions to the
Path Computation Element Communication Protocol (PCEP) Path Computation Element Communication Protocol (PCEP)
for Point-to-Multipoint Traffic Engineering Label for Route Exclusions," draft-ietf-pce-pcep-xro-06,
Switched Paths," draft-ietf-pce-pcep-p2mp-extensions-00, Work in progress, July 2008.
Work in progress, Sep. 2008.
[ID.p2mp-te-bypass]
JL. Le Roux, R. Aggarwal, J.P. Vasseur, and M. Vigoureux,
"P2MP MPLS-TE Fast Reroute with P2MP Bypass Tunnels,"
draft-ietf-mpls-p2mp-te-bypass-02," Work in progress,
Mar. 2008.
[ID.pce-mngabl-reqs] [ID-pce-p2mp-ext] Takeda, T., Chaitou M., Le Roux, J.L., Ali Z.,Zhao,
Q., King, D.,"draft-ietf-pce-pcep-p2mp-extensions-
01,work in progress, October , 2008.
A. Farrel, "Inclusion of Manageability Sections in PCE [ID.p2mp-te-bypass] JL. Le Roux, R. Aggarwal, J.P. Vasseur,
Working Group Drafts," draft-ietf-pce-manageability- and M. Vigoureux, "P2MP MPLS-TE Fast
requirements-04 Work in progress, June. 2008. Reroute with P2MP Bypass Tunnels," draft-
ietf-mpls-p2mp-te-bypass-02," Work in progress, Mar.
2008.
[ID.pce-monitor] [ID.pce-mngabl-reqs] A. Farrel, "Inclusion of Manageability
Sections in PCE Working
Group Drafts," draft-ietf-pce-manageability-
requirements-06 Work in progress, Jan. 2009.
JP. Vasseur, JL. Le Roux and Y. Ikejiri, "A set of [ID.pce-monitor] JP. Vasseur, JL. Le Roux and Y. Ikejiri, "A set of
monitoring tools for Path Computation Element based monitoring tools for Path Computation Element based
Architecture," draft-ietf-pce-monitoring-02 Work in Architecture," draft-ietf-pce-monitoring-04 Work in
progress, Sep. 2008. progress, Jan. 2009.
Authors' Addresses 11. Authors' Addresses
Itaru Nishioka Itaru Nishioka
NEC Corp. NEC Corp.
1753 Shimonumabe, 1753 Shimonumabe,
Kawasaki, 211-8555, Kawasaki, 211-8555,
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
UK UK
Phone: +44 7790 775187 Phone: +44 7790 775187
Email: daniel@olddog.co.uk Email: daniel@olddog.co.uk
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any 12. Intellectual Property Consideration
Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology The IETF Trust takes no position regarding the validity or scope of
described in this document or the extent to which any license any Intellectual Property Rights or other rights that might be
claimed to pertain to the implementation or use of the technology
described in any IETF Document or the extent to which any license
under such rights might or might not be available; nor does it under such rights might or might not be available; nor does it
represent that it has made any independent effort to identify any represent that it has made any independent effort to identify any
such rights. Information on the procedures with respect to rights such rights.
in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any Copies of Intellectual Property disclosures made to the IETF
assurances of licenses to be made available, or the result of an Secretariat and any assurances of licenses to be made available, or
attempt made to obtain a general license or permission for the use the result of an attempt made to obtain a general license or
of such proprietary rights by implementers or users of this permission for the use of such proprietary rights by implementers or
specification can be obtained from the IETF on-line IPR repository users of this specification can be obtained from the IETF on-line IPR
at http://www.ietf.org/ipr. repository at http://www.ietf.org/ipr
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
any standard or specification contained in an IETF Document. Please
address the information to the IETF at ietf-ipr@ietf.org.
The IETF invites any interested party to bring to its attention The definitive version of an IETF Document is that published by, or
any copyrights, patents or patent applications, or other under the auspices of, the IETF. Versions of IETF Documents that are
proprietary rights that may cover technology that may be required published by third parties, including those that are translated into
to implement this standard. Please address the information to the other languages, should not be considered to be definitive versions
IETF at ietf-ipr@ietf.org. of IETF Documents. The definitive version of these Legal Provisions
is that published by, or under the auspices of, the IETF. Versions of
these Legal Provisions that are published by third parties, including
those that are translated into other languages, should not be
considered to be definitive versions of these Legal Provisions.
Disclaimer of Validity For the avoidance of doubt, each Contributor to the IETF Standards
Process licenses each Contribution that he or she makes as part of
the IETF Standards Process to the IETF Trust pursuant to the
provisions of RFC 5378. No language to the contrary, or terms,
conditions or rights that differ from or are inconsistent with the
rights and licenses granted under RFC 5378, shall have any effect and
shall be null and void, whether published or posted by such
Contributor, or included with or in such Contribution.
This document and the information contained herein are provided on 13. Disclaimer of Validity
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
All IETF Documents and the information contained therein are provided
on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE. FOR A PARTICULAR PURPOSE.
Copyright Statement 14. Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
Acknowledgment Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
Funding for the RFC Editor function is currently provided by the This document is subject to BCP 78 and the IETF Trust's Legal
Internet Society. Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your
rights and restrictions with respect to this document.
 End of changes. 100 change blocks. 
313 lines changed or deleted 382 lines changed or added

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