draft-ietf-pce-pcep-svec-list-02.txt   draft-ietf-pce-pcep-svec-list-03.txt 
Network Working Group I. Nishioka Network Working Group I. Nishioka
Internet Draft NEC Internet Draft NEC
Intended status: Informational Daniel King Intended status: Informational Daniel King
Expires: February 2010 Old Dog Consulting Expires: March 2010 Old Dog Consulting
August 28, 2009 September 23, 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-02.txt draft-ietf-pce-pcep-svec-list-03.txt
Abstract
A Path Computation Element (PCE) performing dependent path
computations, for instance calculating a diverse working and
protected path not sharing common network points, would need to
synchronize the computations in order to increase the probability of
meeting the working and protected path diversity (or disjointness)
objective and network resource optimization objective. When a PCE
computes multiple sets of dependent path computation requests
concurrently, it is required to use Synchronization VECtor (SVEC)
list for association among the sets of dependent path computation
requests. SVEC is also applicable to end-to-end diverse path
computation across multiple domains. This document describes the
usage of SVECs in the SVEC list and diverse path computation
guideline, for the synchronized computation of dependent paths.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with This Internet-Draft is submitted to IETF in full conformance with
the provisions of BCP 78 and BCP 79. the provisions of BCP 78 and 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.
skipping to change at page 1, line 27 skipping to change at page 2, line 4
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 and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress." reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on February 28, 2009. This Internet-Draft will expire on March 23, 2009.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 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 in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your Please review these documents carefully, as they describe your
rights and restrictions with respect to this document. rights and restrictions with respect to this document.
Abstract
A Path Computation Element (PCE) performing dependent path
computations, for instance calculating a diverse working and
protected path do not share common network points, would need to
synchronize the computations in order to increase the probability of
meeting the working and protected path disjoint objective and
network resource optimization objective. When a PCE computes
multiple sets of dependent path computation requests concurrently,
it is required to use Synchronization VECtor (SVEC) list for
association among the sets of dependent path computation requests.
SVEC is also applicable to end-to-end diverse path computation
across multiple domains. This document describes the usage of SVECs
in the SVEC list and diverse path computation guideline, for the
synchronized computation of dependent paths.
Table of Contents Table of Contents
1. Terminology...................................................3 1. Terminology...................................................3
2. Introduction..................................................3 2. Introduction..................................................3
3. SVEC association scenarios....................................5 3. SVEC association scenarios....................................5
3.1. Synchronized computation for diverse path requests.......5 3.1. Synchronized computation for diverse path requests.......5
3.2. Synchronized computation for point-to-multipoint path 3.2. Synchronized computation for point-to-multipoint path
requests......................................................6 requests......................................................6
4. SVEC association..............................................6 4. SVEC association..............................................7
4.1. Associated SVECs.........................................7 4.1. Associated SVECs.........................................7
4.2. Non-associated SVECs.....................................7 4.2. Non-associated SVECs.....................................7
5. Processing of SVEC list.......................................8 5. Processing of SVEC list.......................................8
5.1. Single PCE, single domain environments...................8 5.1. Single PCE, single domain environments...................8
5.2. Multi-PCE, single domain environments....................8 5.2. Multi-PCE, single domain environments....................9
5.3. Single PCE, multi-domain environments....................9 5.3. Single PCE, multi-domain environments....................9
6. End-to-end diverse path computation...........................9 6. End-to-end diverse path computation...........................9
6.1. Disjoint VSPT............................................9 6.1. Disjoint VSPT...........................................10
6.2. Disjoint VSPT encoding..................................11 6.2. Disjoint VSPT encoding..................................11
6.3. Path computation procedure..............................11 6.3. Path computation procedure..............................12
7. Manageability considerations.................................12 7. Manageability considerations.................................12
7.1. Control of Function and Policy..........................12 7.1. Control of Function and Policy..........................12
7.2. Information and Data Models, e.g. MIB modules...........12 7.2. Information and Data Models, e.g. MIB modules...........12
7.3. Liveness Detection and Monitoring.......................12 7.3. Liveness Detection and Monitoring.......................12
7.4. Verifying Correct Operation.............................12 7.4. Verifying Correct Operation.............................13
7.5. Requirements on Other Protocols and Functional Components12 7.5. Requirements on Other Protocols and Functional Components13
7.6. Impact on Network Operation.............................13 7.6. Impact on Network Operation.............................13
8. Security Considerations......................................13 8. Security Considerations......................................13
9. IANA Considerations..........................................13 9. IANA Considerations..........................................13
10. References..................................................13 10. References..................................................13
10.1. Normative References...................................13 10.1. Normative References...................................13
10.2. Informative References.................................14 10.2. Informative References.................................14
11 Acknowledgements .............................................14
1. Terminology 1. Terminology
This document uses PCE terminology defined in [RFC4655],[RFC4875], This document uses PCE terminology defined in [RFC4655],[RFC4875],
and [RFC5440]. and [RFC5440].
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 TE paths is
computed concurrently in order to efficiently utilize network computed concurrently in order to efficiently utilize network
resources. resources.
skipping to change at page 3, line 31 skipping to change at page 3, line 34
synchronized or concurrent path computations. synchronized or concurrent path computations.
VSPT: Virtual Shortest Path Tree defined in [RFC5441]. VSPT: Virtual Shortest Path Tree defined in [RFC5441].
Disjoint VSPT : A set of VSPTs, defined in this document, to Disjoint VSPT : A set of VSPTs, defined in this document, to
indicate a set of virtual diverse path tree. indicate a set of virtual diverse path tree.
2. Introduction 2. Introduction
[RFC5440] describes the specifications for PCEP (Path Computation [RFC5440] describes the specifications for PCEP (Path Computation
Element communication Protocol). PCEP facilitates the communication Element communication Protocol). PCEP specifies the communication
between a Path Computation Client(PCC) and a Path Computation between a Path Computation Client (PCC) and a Path Computation
Element (PCE), or between two PCEs based on PCE architecture Element (PCE), or between two PCEs based on the PCE architecture
[RFC4655]. PCEP interactions include path computation requests and [RFC4655]. PCEP interactions include path computation requests and
path computation replies. path computation replies.
[RFC5557] specifies the Global Concurrent (GCO) path computation [RFC5557] specifies the Global Concurrent Optimization (GCO) path
mechanism. The GCO application provides the capability to re- computation mechanism. The GCO application provides the capability
optimize a set of service within the network, in order to maximize to re-optimize a set of services within the network, in order to
efficient use of network resources. A single or set of objective maximize efficient use of network resources. A single or set of
functions (OFs) can be applied to a GCO. To compute a set of such objective functions (OFs) can be applied to a GCO. To compute a set
traffic-engineered paths for the GCO application, PCEP supports the of such traffic-engineered paths for the GCO application, PCEP
synchronous and dependent path computation requests required in supports the synchronous and dependent path computation requests
[RFC4657]. When a PCC or PCE sends such path computation requests to required in [RFC4657]. When a PCC or PCE sends such path computation
a PCE, Synchronization VECtor (SVEC) allows the PCC or PCE to requests to a PCE, Synchronization VECtor (SVEC) allows the PCC or
specify a list of multiple path computation requests that must be PCE to specify a list of multiple path computation requests that
synchronized along with a potential dependency. [RFC5440] defines must be synchronized along with a potential dependency. [RFC5440]
two synchronous path computation modes using SVEC. defines two synchronous path computation modes using SVEC.
o Bundle of a set of independent and synchronized path computation o Bundle a set of independent and synchronized path computation
requests, requests,
o Bundle of a set of dependent and synchronized path computation o Bundle a set of dependent and synchronized path computation
requests. requests.
These are exclusive modes in a single SVEC. If one of the dependency These are exclusive modes in a single SVEC. If one of the dependency
flags (i.e. Node, Link or Shared Risk Link Groups (SRLG) diverse flags (i.e. Node, Link or Shared Risk Link Groups (SRLG) diverse
flags) in a SVEC is set, the SVEC indicates a set of synchronous flags) in a SVEC is set, the SVEC indicates a set of synchronous
path computation requests with a dependency. In order to be path computation requests with a dependency. In order to be
synchronized among multiple sets of path computation requests with a synchronized among multiple sets of path computation requests with a
dependency, it is necessary to use other SVECs. dependency, it is necessary to use other SVECs.
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 a protected end-to-end service. Two diverse path example, consider a protected end-to-end service. Two diverse path
computation requests are needed to compute the disjointed working computation requests are needed to compute the disjointed working
and protected paths. If the diverse path requests are computed and protected paths. If the diverse path requests are computed
sequentially, fulfillment of the initial diverse path computation sequentially, fulfillment of the initial diverse path computation
without consideration of the second diverse path computation and without consideration of the second diverse path computation and
disjoint constraint may result in the PCE providing sub-optimal disjoint constraint may result in the PCE providing sub-optimal
results for the second one, or may fail to meet the disjoint results for the second one, or may fail to meet the disjoint
requirement altogether. requirement altogether.
Additionally, SVEC can be applied to end-to-end diverse path Additionally, SVEC can be applied to end-to-end diverse path
computation that traverses 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 the end-to-end diverse path computation across a chain of
domains. The path computation procedure is specified for the 2-step domains. The path computation procedure is specified for the 2-step
approaches in [RFC5521], but no guidelines are provided for a approaches in [RFC5521], but no guidelines are provided for a
synchronous approach. synchronous approach.
This document defines the handling of synchronous path computation This document defines the handling of synchronous path computation
for PCE and multiple set of path computation request with a for PCE and multiple set of path computation request with a
dependency, based on the PCE architecture [RFC4655]. The following dependency, based on the PCE architecture [RFC4655]. The following
scenarios are specifically described: 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 Single domain, multiple-PCE, dependent and synchronized path o Single domain, multi-PCE, dependent and synchronized path
computation request. computation request.
o Multi-domain, dependent and synchronized path computation o Multi-domain, dependent and synchronized path computation request,
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 and disjoint VSPT encoding synchronized dependent path computation is also described in this
rule for end-to-end diverse path computation across domains are also document, as well as disjoint Virtual Shortest Path Tree (VSPT)
described in this document. Path computation algorithms for these encoding rule for end-to-end diverse path computation across domains.
path computation scenarios are out of scope in this document. Path computation algorithms for these path computation scenarios are
out of the scope of this document.
The SVEC association and the disjoint VSPT described in this The SVEC association and the disjoint VSPT described in this
document do not require any extension to PCEP message and object document do not require any extension to PCEP message and object
formats, when computing a GCO for multiple or end-to-end diverse formats, when computing a GCO for multiple or end-to-end diverse
paths. In addition, the use of multiple SVECs is not restricted to paths. In addition, the use of multiple SVECs is not restricted to
only SRLG, Node and Link diversity currently defined in the SVEC only SRLG, Node and Link diversity currently defined in the SVEC
object [RFC5440], but is also available for other dependent path object [RFC5440], but is also available for other dependent path
computation requests. computation requests.
The SVEC association and disjoint VSPT are available to both The SVEC association and disjoint VSPT are available to both single
multiple PCE path computations as well as a single PCE path PCE path computation and multi-PCE path computation.
computation.
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
When computing two or more point-to-point diverse paths, a PCE may A PCE may compute two or more point-to-point diverse paths,
compute these diverse paths concurrently, in order to increase the concurrently, in order to increase the probability of meeting
probability of meeting primary and secondary path disjoint objective primary and secondary path diversity (or disjointness) objective and
and network resource optimization objective. 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 point-
to-point diverse paths. 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 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
skipping to change at page 6, line 19 skipping to change at page 6, line 22
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 When concurrent path computation of an end-to-end primary path and
several segmented secondary paths is requested, SVEC association is several segmented secondary paths is requested, SVEC association is
needed among primary/segmented secondary-1 request, needed among primary/segmented secondary-1 request,
primary/segmented secondary-2 request, and etc. 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 specified paths. Otherwise, segment for secondary path requests are specified
in advance, by using XRO and/or IOR constraints in the primary in advance, by using Exclude Route Object (XRO) and/or Include Route
request. Object (IRO) 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 paths request is represented as a set 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 path computation, in order to optimize network resources. concurrent path computation, in order to optimize network resources.
o point-to-multipoint paths and its 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 requested, SVEC association is needed among these requests. In this
this scenario, we use the same assumption as "end-to-end primary scenario, we use the same assumption as "end-to-end primary path and
path and its segmented secondary paths scenario" in section 3.1 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. Associated SVECs 4.1. Associated SVECs
Associated SVECs mean that there are relationships among multiple "Associated SVECs" means 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 than two SVECs, this indicates associated SVECs. When more than two SVECs, this indicates associated SVECs. When
associating among SVECs, only one request-ID may in the SVEC object associating among SVECs, only one request-ID in the SVEC object may
may be contained in the other SVEC object. This contributes to be contained in the other SVEC object. This contributes to reducing
reducing the message size of PCEP request. Even in this case, all of the message size of PCEP request. Even in this case, all the path
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 is associating the other SVECs, and path computation requests SVEC is associated with the other SVECs, and path computation
from Request-ID#1 to Request-ID#Z must be synchronized. requests 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 #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
skipping to change at page 8, line 20 skipping to change at page 8, line 25
........ ........
<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 in When a PCE receives PCReq messages with more than two SVEC objects
the SVEC list, PCEP has to first check the request-IDs in all SVEC in the SVEC list, PCEP has to first check the request-IDs in all
objects in order to identify any associations among them. The SVEC SVEC objects in order to identify any associations among them. The
objects may be received in a single or multiple PCReq message(s). In SVEC objects may be received in a single or multiple PCReq
the latter case, the PCE may start a SyncTimer as recommended in message(s). In the latter case, the PCE may start a SyncTimer as
[RFC5440]. After receiving the whole path computation requests, the recommended in [RFC5440]. After receiving the entire set of path
analysis for associated SVECs has to be started. computation requests, the analysis for associated SVECs has to be
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 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 the PCE does not have capability to handle the associated SVEC
objects, it may send a PCErr message with Error-Type="Capability not objects, it may send a PCErr message with Error-Type="Capability 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 PCEs 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 PCE from the first service, and this request is sent to a different PCE
in the domain, no SVEC object correlation function between the PCEs in the domain, no SVEC object correlation function between the PCEs
is currently available. Equally, associated SVECs are not sent to is currently available. Equally, associated SVECs are not sent to
the different PCEs in the domain. the different PCEs in the domain.
5.3. Single PCE, multi-domain environments 5.3. Multi-PCE, multi-domain environments
When multiple PCEs located in separate domains are used to When multiple PCEs located in separate domains are used to
concurrently compute an end-to-end diverse path across multiple concurrently compute an end-to-end diverse path across multiple
domains, additional processing may be required. The path computation domains, additional processing may be required. The path computation
process for the end-to-end diverse path is described in Section 6. process for the end-to-end diverse path is described in Section 6.
Furthermore, if the PCReq message contains multiple associated SVEC Furthermore, if the PCReq message contains multiple associated SVEC
objects and these SVEC objects contain path computation requests objects and these SVEC objects contain path computation requests
that will be sent to the next PCE along the path computation chain. that will be sent to the next PCE along the path computation chain,
Intermediate PCEs receiving such PCReq messages may re-construct the following procedure is applied. Intermediate PCEs receiving such
associations among SVEC objects, and then send PCReq messages to PCReq messages may re-construct associations among SVEC objects, and
corresponding PCEs located in neighboring domains. If the associated then send PCReq messages to corresponding PCEs located in
SVECs are re-constructed at the intermediate PCE, the PCE must not neighboring domains. If the associated SVECs are re-constructed at
start path computation until all PCRep messages have been received the intermediate PCE, the PCE must not start path computation until
from neighbor PCEs. In addition, it is not recommended that SVEC all PCRep messages have been received from all neighbor PCEs. In
objects coming from different PCReq messages are re-constructed. addition, it is not recommended that SVEC objects coming from
This may contribute to resource optimization from network operator`s different PCReq messages are re-constructed. This may contribute to
point of view, but it is unrealistic in the case of multiple PCE resource optimization from network operator's point of view, but it
path computation scenarios. is unrealistic in the case of multiple PCE path computation
scenarios.
6. End-to-end diverse path computation 6. End-to-end diverse path computation
End-to-end diverse path is a set of primary path and secondary paths, End-to-end diverse path is a set of primary path and secondary paths,
which do not share common network resources across domains. To which do not share common network resources across domains. To
compute the end-to-end diverse path, the BRPC procedure can be used. compute the end-to-end diverse path, the BRPC procedure can be used.
[RFC5441] describes two approaches, synchronous (i.e. simultaneous) [RFC5441] describes two approaches, synchronous (i.e. simultaneous)
and 2-step approaches, for the end-to-end diverse path computation and 2-step approaches, for the end-to-end diverse path computation
across a chain of domains. The 2-step approach is described in across a chain of domains. The 2-step approach computes primary and
[RFC5521]. This section provides how to compute end-to-end diverse secondary paths sequentially, using XRO, and its procedure is
path in the synchronous approach. described in [RFC5521]. In this section, the synchronous approach is
provided to compute primary and secondary paths simultaneously.
6.1. Disjoint VSPT 6.1. Disjoint VSPT
The BRPC procedure constructs a VSPT (virtual shortest path tree) to The BRPC procedure constructs a VSPT to inform the enquiring PCE of
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, disjoint information In the end-to-end diverse path computation, diversity (or
among the potential paths must be preserved in the VSPT to ensure disjointness) information among the potential paths must be
end-to-end disjoint path. In order to preserve disjoint information, preserved in the VSPT to ensure end-to-end disjoint path. In order
disjoint VSPTs are sent in the PCEP PCRep message. to preserve diversity (or disjointness) information, disjoint VSPTs
are sent in the PCEP PCRep message.
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-1 shows an example network. Here, transit nodes in domains Figure-1 shows an example network. Here, transit nodes in domains
are not depicted, and PCE1 and PCE2 may be located in boarder 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 2, when the primary path and secondary diverse paths shown in Figure 2, 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 replied to PCE1. When receiving the disjoint VSPT,
PCE1 recognizes the disjoint request and disjoint VSPT information. PCE1 recognizes the disjoint request and disjoint VSPT information.
PCE1 will then continue to process the request and compute the PCE1 will then continue to process the request and compute the
diverse path using the BRPC procedure [RFC5441]. The detail encoding diverse path using the BRPC procedure [RFC5441]. The detail encoding
for the disjoint VSPT is described in Section 6.2. 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---BR5 D1 | BN1-BN6: Border nodes | S1 BN2---BN5 D1 | BN1-BN6: Border nodes
| BN3---BN6 | | BN3---BN6 |
+----------+ +----------+ +----------+ +----------+
Figure-1; Example network for diverse path computation Figure-1: Example network for diverse path computation
VSPT1: VSPT2: VSPT3:
VSPT1; VSPT2; VSPT3;
D1 D1 D1 D1 D1 D1
/ \ / \ / \ / \ / \ / \
BR4 BR5 BR4 BR6 BR5 BR6 BN4 BN5 BN4 BN6 BN5 BN6
Figure-2; Disjoint VSPT from PCE2 to PCE1 Figure-2: Disjoint VSPT 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 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 PCEP PCRep message returns a disjoint VSPT as <path list> for each
RP object. The order of <path> in <path list> among <responses> RP object (Request Parameter object). The order of <path> in <path
implies a set of primary EROs and secondary EROs. list> among <responses> implies a set of primary EROs (Explicit
Route Objects) and secondary EROs.
A PCE sending PCRep with a disjoint VSPT can reply with a partial A PCE sending 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 <path> in <path list> must be aligned correctly. of <path> in <path list> must be aligned correctly.
If confidentiality is required between domains, path key mechanism If confidentiality is required between domains, path key mechanism
defined in [RFC5520] is used for a disjoint VSPT. defined in [RFC5520] is used for a disjoint VSPT.
Detail disjoint VSPT encoding in Figure-2 is shown below, when a Detailed disjoint VSPT encoding in Figure-2 is shown below, when a
primary path and a secondary path are requested from S1 to D1. primary path and a secondary path are requested from S1 to D1.
o Request ID #1 (Primary) o Request ID #1 (Primary)
- ERO1 BR4(TE route ID)- ...-D1(TE-Router ID) [for VSPT1] - ERO1 BN4(TE route ID)- ...-D1(TE-Router ID) [for VSPT1]
- ERO2 BR4(TE route ID)- ...-D1(TE-Router ID) [for VSPT2] - ERO2 BN4(TE route ID)- ...-D1(TE-Router ID) [for VSPT2]
- ERO3 BR5(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 BR5(TE route ID)- ...-D1(TE-Router ID) [for VSPT1] - ERO4 BN5(TE route ID)- ...-D1(TE-Router ID) [for VSPT1]
- ERO5 BR6(TE route ID)- ...-D1(TE-Router ID) [for VSPT2] - ERO5 BN6(TE route ID)- ...-D1(TE-Router ID) [for VSPT2]
- ERO6 BR6(TE route ID)- ...-D1(TE-Router ID) [for VSPT2] - 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 BRPC procedure can be applied (i.e. Step 1 to Step n in Section
4.2 [RFC5441]). During this procedure, a question is how to 4.2 [RFC5441]). During this procedure, a question is how to
recognize disjoint VSPTs. recognize disjoint VSPTs.
The recognition of disjoint VSPT is achieved by the PCE sending The recognition of disjoint VSPT is achieved by the PCE sending
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 PCReq has one or more SVEC object(s)
with the appropriate diverse flags, the received PCrep will contain with the appropriate diverse flags, the received PCRep will contain
the disjoint VSPT. If not, the received VSTP is a normal VSPT based the disjoint VSPT. If not, the received VSPT is a normal VSPT based
on the shortest path computation. 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
disjoint VSPT. The selection and application of the appropriate disjoint VSPT. The selection and application of the appropriate
algorithm is out of scope in this draft. algorithm is out of scope in this draft.
7. Manageability considerations 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].
7.1. Control of Function and Policy 7.1. Control of Function and Policy
In addition to [RFC5440], PCEP implementation should allow the In addition to [RFC5440], PCEP implementation should allow the
configuration of association among SVECs on PCCs. configuration of association among SVECs on PCCs.
o the capability to configure SVEC association.
7.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.
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 path. This type of path computation may require more sets of diverse paths. This type of path computation may require
time to obtain its results. Therefore, it is recommended for PCEP to more time to obtain its results. Therefore, it is recommended for
support PCE monitoring mechanism specified in [ID.pce-monitor]. PCEP to support PCE monitoring mechanism specified in [ID.pce-
monitor].
7.4. Verifying Correct Operation 7.4. Verifying Correct Operation
[RFC5440] provides the sufficient descriptions for this document. So, [RFC5440] provides the sufficient descriptions for this document. So,
there are no additional considerations. there 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 the sufficient descriptions for this document. So, [RFC5440] provides the sufficient descriptions for this document. So,
there are no additional considerations. there are no additional considerations.
8. Security Considerations 8. Security Considerations
This document defines the usage of SVEC list, and does not have any This document defines the usage of SVEC list, and does not have any
extensions for PCEP protocol. Therefore the security of this extensions for PCEP protocol. Therefore, the security of the
document depends on that of PCEP protocol. procedures described in this document depends on PCEP protocol.
9. 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.
10. References 10. References
10.1. Normative References 10.1. Normative References
skipping to change at page 15, line 5 skipping to change at page 15, line 5
[ID.pce-mngabl-reqs] A. Farrel, "Inclusion of Manageability Sections [ID.pce-mngabl-reqs] A. Farrel, "Inclusion of Manageability Sections
in PCE Working Group Drafts," draft-ietf-pce- in PCE Working Group Drafts," draft-ietf-pce-
manageability-requirements, work in progress, July. 2009. manageability-requirements, work in progress, July. 2009.
[ID.pce-monitor] 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, work in Architecture," draft-ietf-pce-monitoring, work in
progress.txt, July. 2009. progress.txt, July. 2009.
11. Acknowledgements
The authors would like to thank Julien Meuric and Filippo Cugini
for their valuable comments
Authors' Addresses 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 United Kingdom
Phone: +44 7790 775187 Phone: +44 7790 775187
Email: daniel@olddog.co.uk Email: daniel@olddog.co.uk
 End of changes. 55 change blocks. 
138 lines changed or deleted 146 lines changed or added

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