draft-ietf-pce-pcep-svec-list-03.txt   draft-ietf-pce-pcep-svec-list-04.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: March 2010 Old Dog Consulting Created: February 10, 2010 Old Dog Consulting
September 23, 2009 Expires: August 10, 2010
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-03.txt draft-ietf-pce-pcep-svec-list-04.txt
Abstract Abstract
A Path Computation Element (PCE) performing dependent path A Path Computation Element (PCE) may be required to perform
computations, for instance calculating a diverse working and dependent path computations. Dependent path computations are
protected path not sharing common network points, would need to requests that need to be synchronized in order to meet specific
synchronize the computations in order to increase the probability of objectives. An example of a dependent request would be a PCE
meeting the working and protected path diversity (or disjointness) computing a set of services which are required to be diverse
objective and network resource optimization objective. When a PCE (disjointed) from each other. When a PCE computes sets of dependent
computes multiple sets of dependent path computation requests path computation requests concurrently, it is required to use the
concurrently, it is required to use Synchronization VECtor (SVEC) Synchronization VECtor (SVEC) list for association among the sets of
list for association among the sets of dependent path computation dependent path computation requests. The SVEC object is optional and
requests. SVEC is also applicable to end-to-end diverse path carried within the Path Computation Element Protocol (PCEP)
computation across multiple domains. This document describes the PCRequest (PCReq) message.
usage of SVECs in the SVEC list and diverse path computation
guideline, for the synchronized computation of dependent paths. This document does not specify the PCEP SVEC object or procedure.
This informational document clarifies the use of the SVEC list for
synchronized path computations when computing dependent requests.
The document also describes a number of usage scenarios for SVEC
lists within single domain and multi-domain environments.
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
the provisions of BCP 78 and BCP 79. 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.
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 documents and may be updated, replaced, or obsoleted by other documents at any
at any time. It is inappropriate to use Internet-Drafts as time. It is inappropriate to use Internet-Drafts as reference
reference material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 23, 2009. This Internet-Draft will expire on August 10, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 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 in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your publication of this document. Please review these documents
rights and restrictions with respect to this document. carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
Table of Contents document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
1. Terminology...................................................3 warranty as described in the Simplified BSD License.
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. SVEC association..............................................7
4.1. Associated SVECs.........................................7
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....................9
5.3. Single PCE, multi-domain environments....................9
6. End-to-end diverse path computation...........................9
6.1. Disjoint VSPT...........................................10
6.2. Disjoint VSPT encoding..................................11
6.3. Path computation procedure..............................12
7. Manageability considerations.................................12
7.1. Control of Function and Policy..........................12
7.2. Information and Data Models, e.g. MIB modules...........12
7.3. Liveness Detection and Monitoring.......................12
7.4. Verifying Correct Operation.............................13
7.5. Requirements on Other Protocols and Functional Components13
7.6. Impact on Network Operation.............................13
8. Security Considerations......................................13
9. IANA Considerations..........................................13
10. References..................................................13
10.1. Normative References...................................13
10.2. Informative References.................................14
11 Acknowledgements .............................................14
1. Terminology
This document uses PCE terminology defined in [RFC4655],[RFC4875],
and [RFC5440].
GCO (Global Concurrent Optimization): A concurrent path computation
application, defined in [RFC5557], where a set of TE paths is
computed concurrently in order to efficiently utilize network
resources.
Associated SVECs: A group of multiple SVECs (Synchronization This document may contain material from IETF Documents or IETF
VECtors), defined in this document, to indicate a set of Contributions published or made publicly available before November
synchronized or concurrent path computations. 10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s)
controlling the copyright in such materials, this document may not
be modified outside the IETF Standards Process, and derivative works
of it may not be created outside the IETF Standards Process, except
to format it for publication as an RFC or to translate it into
languages other than English.
VSPT: Virtual Shortest Path Tree defined in [RFC5441]. Table of Contents
Disjoint VSPT : A set of VSPTs, defined in this document, to 1. Introduction ..................................................3
indicate a set of virtual diverse path tree. 1.1. SVEC Object ...................................................4
1.2. Application of SVEC Lists .....................................4
2. Terminology ...................................................6
3. SVEC association scenarios ....................................6
3.1. Synchronized computation for diverse path requests ............6
3.2. Synchronized computation for point-to-multipoint path
requests ......................................................8
4. SVEC association ..............................................8
4.1. SVEC list .....................................................8
4.2. Associated SVECs ..............................................8
4.3. Non-associated SVECs ..........................................9
5. Processing of SVEC list ......................................10
5.1. Single PCE, single domain environments .......................10
5.2. Multi-PCE, single domain environments ........................11
5.3. Multi-PCE, multi-domain environments .........................11
6. End-to-end diverse path computation ..........................12
6.1. Disjoint VSPT ................................................12
6.2. Disjoint VSPT encoding .......................................14
6.3. Path computation procedure ...................................14
7. Manageability considerations .................................15
7.1. Control of Function and Policy ...............................15
7.2. Information and Data Models, e.g. MIB modules ................15
7.3. Liveness Detection and Monitoring ............................15
7.4. Verifying Correct Operation ..................................15
7.5. Requirements on Other Protocols and Functional Components.....16
7.6. Impact on Network Operation ..................................16
8. Security Considerations ......................................16
9. IANA Considerations ..........................................17
10. References ..................................................17
10.1. Normative References ........................................17
10.2. Informative References ......................................18
11. Acknowledgements ............................................18
2. Introduction 1. Introduction
[RFC5440] describes the specifications for PCEP (Path Computation [RFC5440] describes the specifications for PCEP (Path Computation
Element communication Protocol). PCEP specifies 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 the 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 Optimization (GCO) path The PCE may be required to compute independent and dependent path
computation mechanism. The GCO application provides the capability requests. Path computation requests are said to be independent if
to re-optimize a set of services within the network, in order to they are not related to each other, and therefore not required to be
maximize efficient use of network resources. A single or set of synchronized. Equally a set of dependent path computation requests,
objective functions (OFs) can be applied to a GCO. To compute a set that are required to be synchronized, cannot be performed
of such traffic-engineered paths for the GCO application, PCEP independently of each other. The Synchronization VECtor (SVEC) with
supports the synchronous and dependent path computation requests a list of the path computation request identifiers carried within
required in [RFC4657]. When a PCC or PCE sends such path computation the request message allows the PCC or PCE to specify a list of
requests to a PCE, Synchronization VECtor (SVEC) allows the PCC or multiple path computation requests that must be synchronized.
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 along with a potential dependency. [RFC5440] (Application of SVEC Lists) describes the application of SVEC lists
defines two synchronous path computation modes using SVEC. in certain scenarios.
o Bundle a set of independent and synchronized path computation This informational document clarifies the handling of dependent and
requests, synchronized path computation requests, using the SVEC list, based
on the PCE architecture [RFC4655] and PCEP [RFC5440]. The document
also describes a number of usage scenarios for SVEC lists within
single domain and multi-domain environments. This document is not
intended to specify the procedure when using SVEC lists for
dependent and synchronized path computation requests.
o Bundle a set of dependent and synchronized path computation 1.1. SVEC Object
requests.
These are exclusive modes in a single SVEC. If one of the dependency When a PCC or PCE sends path computation requests to a PCE, a PCEP
flags (i.e. Node, Link or Shared Risk Link Groups (SRLG) diverse Path Computation Request (PCReq) message may carry multiple requests
flags) in a SVEC is set, the SVEC indicates a set of synchronous each of which has a unique path computation request identifier. The
path computation requests with a dependency. In order to be SVEC with a list of the path computation request identifiers carried
synchronized among multiple sets of path computation requests with a within the request message allows the PCC or PCE to specify a list
dependency, it is necessary to use other SVECs. of multiple path computation requests that must be synchronized, and
also allows the specification of any dependency relationships
between the paths. The path computation requests listed in the SVEC
must be handled in a relation to each other (i.e. synchronized).
[RFC5440] defines two synchronous path computation modes for
dependent or independent path computation requests specified by the
dependency flags (i.e. Node, Link or SRLG diverse flags) in the SVEC.
(See [RFC5440] for more details of dependent, independent and
synchronous path computation.)
o A set of independent 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.
If one of the dependency flags in a SVEC is set, it indicates 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,
it is necessary to associate them.
The aim of the SVEC object carried within a PCReq message is to
request the synchronization of M path computation requests. Each
path computation request is uniquely identified by the Request-ID-
number carried within the respective RP object. The SVEC object
also contains a set of flags that specify the synchronization type.
The SVEC Object is defined in Section 7.13 (SVEC Object) of
[RFC5440].
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 a protected end-to-end service. Two diverse path example, consider two protected end-to-end services:
computation requests are needed to compute the disjointed working
and protected paths. If the diverse path requests are computed o It would be beneficial for each back-up path to be disjointed so
sequentially, fulfillment of the initial diverse path computation they do not share the same links and nodes as the working path.
without consideration of the second diverse path computation and
disjoint constraint may result in the PCE providing sub-optimal o Two diverse path computation requests would be needed to compute
results for the second one, or may fail to meet the disjoint the working and disjointed protected paths.
requirement altogether.
If the diverse path requests are computed sequentially, fulfillment
of the initial diverse path computation without consideration of the
second diverse path computation and disjoint constraint may result in
the PCE providing sub-optimal path disjoint results for the protected
path, or may fail to meet the end-to-end disjoint requirement
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 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 which is described in this document.
This document defines the handling of synchronous path computation The following scenarios are specifically described within this
for PCE and multiple set of path computation request with a document:
dependency, based on the PCE architecture [RFC4655]. 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 Single domain, multi-PCE, dependent and synchronized path o Single domain, multi-PCE, dependent and synchronized path
computation 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 computation is also described in this
document, as well as disjoint Virtual Shortest Path Tree (VSPT) document, as well as 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 Global Concurrent Optimization (GCO) path computation mechanism
specified in [RFC5557]. The GCO application provides the capability
to optimize a set of services within the network, in order to
maximize efficient use of network resources. A single or set of
objective functions (OFs) can be applied to a GCO. To compute a set
of such traffic-engineered paths for the GCO application, PCEP
supports the synchronous and dependent path computation requests
required in [RFC4657].
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 messages 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 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
This document uses PCE terminology defined in [RFC4655], [RFC4875],
and [RFC5440].
Associated SVECs: A group of multiple SVECs (Synchronization
VECtors), defined in this document, to indicate a set of
synchronized or concurrent path computations.
Disjoint VSPT: A set of VSPTs, defined in this document, to indicate
a set of virtual diverse path tree.
GCO (Global Concurrent Optimization): A concurrent path computation
application, defined in [RFC5557], where a set of TE paths is
computed concurrently in order to efficiently utilize network
resources.
Synchronized: A set of path computation requests is said to be
synchronized if the PCE associates the requests, and does not
compute each request independently of each other.
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
skipping to change at page 6, line 8 skipping to change at page 7, line 29
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
all path requests are grouped with one SVEC association. all path requests are grouped with one SVEC association.
Example of this scenario: When there are two associated end-to-end Consider two end-to-end services that are to be kept separate by
diverse path requests with primary and secondary, all requests must using diverse paths. The path computation requests would need to be
be computed in a synchronized manner. associated so that diversity could be assured. Consider further that
each of these services requires a backup path that can protect
against any failure in the primary path. These backup paths must be
computed using requests that are associated with the primary paths
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 of an end-to-end primary path and When concurrent path computation for segment recovery paths, as
several segmented secondary paths is requested, SVEC association is shown in figure 1, is requested, SVEC association is needed between
needed among primary/segmented secondary-1 request, a primary path and several segmented secondary paths.
primary/segmented secondary-2 request, and etc.
<------------ primary ----------->
A------B------C---D------E------F
\ / \ /
P---Q---R X---Y---Z
<--secondary1--> <--secondary2-->
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, 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, the segment for secondary path requests are
in advance, by using Exclude Route Object (XRO) and/or Include Route specified in advance, by using Exclude Route Object (XRO) and/or
Object (IRO) constraints in the primary request. Include Route 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 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 this
scenario, we use the same assumption as "end-to-end primary path and scenario, we use the same assumption as "end-to-end primary 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. SVEC list
"Associated SVECs" means that there are relationships among multiple PCEP provides the capability to carry one or more SVEC objects in a
SVECs. Request-IDs in the SVEC objects are used to indicate the 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
distinct group of path computation requests. When requesting
association among such distinct groups, associated SVECs described
in this document are used.
4.2. Associated SVECs
"Associated SVECs" defines that there are relationships among
multiple SVECs in SVEC list. Note that there is no automatic
association in [RFC5440] between the members of one SVEC and the
members of another SVEC in the same SVEC list. The associated SVEC
is introduced to associate these SVECs, especially for correlating
among SVECs with dependency flags.
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
more than two SVECs, this indicates associated SVECs. When SVEC objects, this indicates these SVEC objects are associated. When
associating among SVECs, only one request-ID in the SVEC object may associating among SVEC objects, at least one request identifier must
be contained in the other SVEC object. This contributes to reducing be shared between associated SVECs. The SVEC objects can be
the message size of PCEP request. Even in this case, all the path associated regardless of the dependency flags in each SVEC object,
computation requests are synchronized. but it is recommended to use a single SVEC if the dependency flags
are not set in all SVEC objects.
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 path computation SVEC is associated with the other SVECs, and all of path computation
requests from Request-ID#1 to Request-ID#Z must be synchronized. requests contained in the associated SVECs (i.e. Request-ID#1,#2,#3,
#4, #X, #Y) must be synchronized.
<SVEC-list>
<SVEC> without dependency flags <SVEC-list>
Request-ID #1, Request-ID #3, ..., Request-ID #X <SVEC> without dependency flags
<SVEC> with one or more dependency flags Request-ID #1, Request-ID #3, Request-ID #X
Request-ID #1, Request-ID #2 <SVEC> with one or more dependency flags
<SVEC> with one or more dependency flags Request-ID #1, Request-ID #2
Request-ID #3, Request-ID #4 <SVEC> with one or more dependency flags
........ 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.2. Non-associated SVECs 4.3. 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 same SVECs. If none of the SVEC objects in the SVEC list on a PCReq
request-ID, the relationship among these SVECs is not associated. message contains a common request-ID, there is no association
between the SVECs and so no association between the requests in one
SVEC and 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 does not contain
any same request-IDs. any 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
<SVEC> with one or more dependency flags Request-ID #1, Request-ID #2
Request-ID #3, Request-ID #4 <SVEC> with one or more dependency flags
........ 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 a PCE receives PCReq messages with more than two SVEC objects In this environment, there is a single PCE within the domain.
When a PCE receives PCReq messages with more than one SVEC objects
in the SVEC list, PCEP has to first check the request-IDs in all in the SVEC list, PCEP has to first check the request-IDs in all
SVEC objects in order to identify any associations among them. The SVEC objects in order to identify any associations among them.
SVEC objects may be received in a single or multiple PCReq
message(s). In the latter case, the PCE may start a SyncTimer as
recommended in [RFC5440]. After receiving the entire set of path
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".
In the case that M path computation requests are sent across
multiple PCReq messages, the PCE may start a SyncTimer as
recommended in Section 7.13.3 (Handling of the SVEC Object)
[RFC5440]. In this case, the associated SVECs should also be handled
as described in [RFC5440]. I.E. after receiving the entire set of M
path computation requests associated by SVECs, the computation
should start at one. If the SyncTimer has expired or the following
PCReq messages have been malformed; the PCE should cancel the path
computation request and respond to the PCC with the relevant PCErr
message.
5.2. Multi-PCE, single domain environments 5.2. Multi-PCE, single domain environments
Currently no mechanisms exist to manage co-ordination of dependent There are multiple PCEs in a domain, to which PCCs can communicate
SVEC requests between multiple PCEs in the same domain. If a PCC directly, and PCCs can choose an appropriate PCE for load balanced
sends a path computation request to a PCE and then sends a second path computation requests. In this environment it is possible
service path computation request, which is required to be disjoint dependent path computation requests are sent to different PCEs.
from the first service, and this request is sent to a different PCE
in the domain, no SVEC object correlation function between the PCEs If a PCC sends path computation requests to a PCE and then sends
is currently available. Equally, associated SVECs are not sent to another path computation requests, which are dependent on the first
the different PCEs in the domain. requests and has been associated by using a SVEC list. There is no
method for the PCE to correlate the dependent requests sent to
different PCEs. No SVEC object correlation function between the PCEs
is specified in [RFC5440]. As indentified, no mechanism exists to
resolve this problem and the issue is open for future study.
Therefore, a PCC must not send dependent path computation requests
associated by SVECs to different PCEs.
5.3. Multi-PCE, multi-domain environments 5.3. Multi-PCE, multi-domain environments
When multiple PCEs located in separate domains are used to In this environment, there are multiple domains in which PCEs are
concurrently compute an end-to-end diverse path across multiple located in each domain, and end-to-end dependent paths (i.e. diverse
domains, additional processing may be required. The path computation path) is computed using multiple PCEs. Note that we assume a chain
process for the end-to-end diverse path is described in Section 6. of PCEs are pre-determined and the BRPC procedure [RFC5441] is in
use.
Furthermore, if the PCReq message contains multiple associated SVEC The SVECs can be applied to end-to-end diverse path computations
objects and these SVEC objects contain path computation requests that traverse multiple domains. [RFC5441] describes two approaches,
that will be sent to the next PCE along the path computation chain, synchronous (i.e. simultaneous) and 2-step approaches, for the end-
the following procedure is applied. Intermediate PCEs receiving such to-end diverse path computation across a chain of domains. In the 2-
PCReq messages may re-construct associations among SVEC objects, and step approaches described in [RFC5521], it is not necessary to use
then send PCReq messages to corresponding PCEs located in the associated SVECs because any of dependency flags in a SVEC
neighboring domains. If the associated SVECs are re-constructed at object are not set. On one hand, the simultaneous approach may
the intermediate PCE, the PCE must not start path computation until require the associated SVEC because at least one of dependency flags
all PCRep messages have been received from all neighbor PCEs. In is required in a SVEC object. Thus, a use case of the simultaneous
addition, it is not recommended that SVEC objects coming from approach is described in this environment.
different PCReq messages are re-constructed. This may contribute to
resource optimization from network operator's point of view, but it When a chain of PCEs located in separate domains are used for
is unrealistic in the case of multiple PCE path computation simultaneous path computations, additional path computation
scenarios. processing is required. It is described in this document (Section 6).
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, the following
procedures are applied.
When a chain of PCEs is a unique sequence for all of path
computation requests in a PCReq message, it is not necessary to re-
construct associations among SVEC objects. Thus, the PCReq message
is passed to the tail end PCE. When a PCReq message contains more
than one SVEC objects with the dependency flag set, the contained
SVECs may then be associated. PCEs receiving the associated SVECs
must maintain their association, and consider their relationship in
path computing after receiving a corresponding PCRep message.
When a chain of PCEs is different, it is required that 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 its path
computation until all PCRep messages have been received from all
neighbor PCEs. However, a complex PCE implementation is required for
SVEC reconstruction, and waiting mechanisms must be implemented.
Therefore, it is not recommended to associate path computation
requests with different PCE chains. This is open issue and is
currently being discussed in [ID.h-pce] which proposes a
hierarchical PCE architecture.
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, In this section, the synchronous approach is provided to compute
which do not share common network resources across domains. To primary and secondary paths simultaneously.
compute the end-to-end diverse path, the BRPC procedure can be used.
[RFC5441] 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 computes primary and
secondary paths sequentially, using XRO, and its procedure is
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 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 in the VSPT to ensure end-to-end disjoint path. In order preserved in the VSPT to ensure end-to-end disjoint path. In order
to preserve diversity (or disjointness) information, disjoint VSPTs to preserve diversity (or disjointness) information, disjoint VSPTs
are sent in the PCEP PCRep message. are sent in the PCEP PCRep message. The PCReq containing a SVEC
object with the appropriate diverse flag set would signal that the
PCE 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-1 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 2, 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 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---BN5 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 2: Example network for diverse path computation
VSPT1: VSPT2: VSPT3:
D1 D1 D1 VSPT1: VSPT2: VSPT3:
/ \ / \ / \ D1 D1 D1
BN4 BN5 BN4 BN6 BN5 BN6 / \ / \ / \
Figure-2: Disjoint VSPT from PCE2 to PCE1 BN4 BN5 BN4 BN6 BN5 BN6
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 (Request Parameter object). The order of <path> in <path RP object (Request Parameter object). The order of <path> in <path
list> among <responses> implies a set of primary EROs (Explicit list> among <responses> implies a set of primary EROs (Explicit
Route Objects) and secondary EROs. 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.
Detailed 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 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 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 dependency flags, the received PCRep will
the disjoint VSPT. If not, the received VSPT is a normal VSPT based contain the disjoint VSPT. If not, the received VSPT is a normal
on the shortest path computation. 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
disjoint VSPT. The selection and application of the appropriate requests with disjoint VSPT. The selection and application of the
algorithm is out of scope in this draft. appropriate 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 implementations should allow the PCC
In addition to [RFC5440], PCEP implementation should allow the to be responsible for mapping the requested paths to computation
configuration of association among SVECs on PCCs. requests. The PCC should construct the SVECs to indentify and
associate SVEC relationships.
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 currently no additional parameters for MIB modules. There
is value in a MIB module that details the SVEC association. 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 PCE monitoring mechanism specified in [ID.pce-
monitor]. monitor].
7.4. Verifying Correct Operation 7.4. Verifying Correct Operation
skipping to change at page 13, line 17 skipping to change at page 15, line 35
[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 descriptions for the mechanisms discussed in this
there are no additional considerations. document. There is value in considering that large associated SVECs
will require greater PCE resources, compared to non-associated SVECs.
Additionally, the sending of large associated SVECs within multiple
PCReq messages will require more network resources. Solving these
specific issues is out of scope of this document.
8. Security Considerations 8. Security Considerations
This document defines the usage of SVEC list, and does not have any This document describes the usage of SVEC list, and does not have
extensions for PCEP protocol. Therefore, the security of the any extensions for PCEP protocol. The security of the procedures
procedures described in this document depends on PCEP protocol. described in this document depends on PCEP protocol [RFC5440].
However, a PCE that supports associated SVECs may be open to DoS
attack from a rogue PCC. A PCE may be made to queue large numbers of
requests waiting for other requests that will never arrive.
Additionally a PCE might be made to compute exceedingly complex
associated SVEC computations. These DoS attacks may be mitigated
with the use of practical SVEC list limits, as well as:
o Using the same number of simultaneous service provisioning
would be 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
through PCE access policy control.
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
[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)," RFC4875, May 2007. Switched Paths (LSPs)," RFC4875, May 2007.
[RFC5440] Ayyangar, A., Farrel, A., Oki, E., Atlas, A., Dolganow A. [RFC5440] Ayyangar, A., Farrel, A., Oki, E., Atlas, A., Dolganow A.
Ikejiri, Y., Kumaki, K., Vasseur, J., and J. Roux, "Path Ikejiri, Y., Kumaki, K., Vasseur, J., and J. Roux, "Path
Computation Element (PCE) communication Protocol (PCEP)," Computation Element (PCE) communication Protocol (PCEP),"
RFC5440, March. 2009. RFC5440, March. 2009.
[RFC5441] JP. Vasseur, R. Zhang, N. Bitar and JL. Le Roux, "A [RFC5441] JP. Vasseur, R. Zhang, N. Bitar and JL. Le Roux, "A
Backward Recursive PCE-based Computation (BRPC) Procedure Backward Recursive PCE-based Computation (BRPC) Procedure
to Compute Shortest Constrained Inter-domain Traffic to Compute Shortest Constrained Inter-domain Traffic
Engineering Label Switched Paths," RFC5441, April 2009. Engineering Label Switched Paths," RFC5441, April 2009.
[RFC5520] R. Bradford, JP. Vasseur, and A. Farrel, "Preserving [RFC5520] R. Bradford, JP. Vasseur, and A. Farrel, "Preserving
Topology Confidentiality in Inter-Domain Path Computations Topology Confidentiality in Inter-Domain Path Computations
Using a Path-Key-Based mechanism," RFC5520, April 2009. Using a Path-Key-Based mechanism," RFC5520, April 2009.
[RFC5521] E. Oki, T. Takeda and A. Farrel, "Extensions to the Path [RFC5521] E. Oki, T. Takeda and A. Farrel, "Extensions to the Path
Computation Element Communication Protocol (PCEP) for Computation Element Communication Protocol (PCEP) for
Route Exclusions," RFC5521, April 2009. Route Exclusions," RFC5521, April 2009.
[RFC5557] Y. Lee, JL. Le Roux, D. King and E. Oki, "Path Computation [RFC5557] Y. Lee, JL. Le Roux, D. King and E. Oki, "Path Computation
Element Communication Protocol (PCECP) Requirements and Element Communication Protocol (PCECP) Requirements and
Protocol Extensions In Support of Global Concurrent Protocol Extensions In Support of Global Concurrent
Optimization," RFC5557, July 2009. Optimization," RFC5557, July 2009.
10.2. Informative References 10.2. Informative References
[ID.pce-p2mp-ext] Takeda, T., Chaitou M., Le Roux, J.L., Ali Z.,Zhao, [ID.pce-p2mp-ext] Takeda, T., Chaitou M., Le Roux, J.L., Ali Z.,Zhao,
Q., King, D., "Extensions to the Path Computation Element Q., King, D., "Extensions to the Path Computation Element
Communication Protocol (PCEP) for Point-to-Multipoint Communication Protocol (PCEP) for Point-to-Multipoint
Traffic Engineering Label Switched Paths," draft-ietf-pce- Traffic Engineering Label Switched Paths," draft-ietf-pce-
pcep-p2mp-extensions, work in progress, August, 2009. pcep-p2mp-extensions, work in progress, February, 2010.
[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.h-pce] King, D., Farrel, A. "The Application of the Path
monitoring tools for Path Computation Element based Computation Element Architecture to the Determination of a
Architecture," draft-ietf-pce-monitoring, work in Sequence of Domains in MPLS & GMPLS", draft-king-pce-
progress.txt, July. 2009. hierarchy-fwk, work in progress, December 2009.
11. Acknowledgements 11. Acknowledgements
The authors would like to thank Julien Meuric and Filippo Cugini The authors would like to thank Adrian Farrel, Julien Meuric and
for their valuable comments 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-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
 End of changes. 102 change blocks. 
281 lines changed or deleted 449 lines changed or added

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