Network Working Group I. Nishioka
Internet Draft NEC
Intended Status: Informational Daniel King
Expires: March 2009 Old Dog Consulting
September 29, 2008
The use of SVEC (Synchronization VECtor) list for Synchronized
dependent path computations
draft-ietf-pce-pcep-svec-list-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in
progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on March 29, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Nishioka & King Expires March 29, 2009 [Page 1]
Internet-Draft draft-ietf-pce-pcep-svec-list-00 September 2008
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.
This document describes the usage of multiple SVECs in the SVEC
list and its processing guideline, for the synchronized computation
of dependent paths.
Table of Contents
1. Terminology...............................................3
2. Introduction..............................................3
3. SVEC Association scenarios................................5
3.1. Synchronized computation for diverse path requests...5
3.2. Synchronized computation for point-to-multipoint path
requests..................................................6
4. Association among SVEC....................................6
4.1. Association among SVEC...............................6
4.2. Non-associated SVECs.................................7
5. Processing of SVEC list...................................8
5.1. Single PCE, single domain environments...............8
5.2. Multi-PCE, single domain environments................8
5.3. Multi-PCE, multi-domain environments.................9
6. Manageability considerations..............................9
6.1. Control of Function and Policy.......................9
6.2. Information and Data Models, e.g. MIB modules........9
6.3. Liveness Detection and Monitoring....................9
6.4. Verifying Correct Operation.........................10
6.5. Requirements on Other Protocols and Functional Components
.........................................................10
6.6. Impact on Network Operation.........................10
7. Security Considerations..................................10
8. IANA Considerations......................................10
9. References...............................................10
9.1. Normative References................................10
9.2. Informative References..............................11
Author's Addresses..........................................12
Intellectual Property Statement.............................13
Nishioka & King Expires March 29, 2009 [Page 2]
Internet-Draft draft-ietf-pce-pcep-svec-list-00 September 2008
Disclaimer of Validity......................................13
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC-2119.
1. Terminology
Terminology used in this document:
PCC (Path Computation Client): Any client application requesting a
path computation to be performed by a Path Computation
Element.
PCE (Path Computation Element): An entity (component, application,
or network node) that is capable of computing a network path
or route based on a network graph, and applying computational
constraints.
PCEP (PCE Communication Protocol) : The PCE communication Protocol.
PCEP Peer : A neighbor element involved in a PCEP session (i.e. a
PCC or a PCE).
GCO (Global Concurrent Optimization): A concurrent path
computation application where a set of TE paths is computed
concurrently in order to efficiently utilize network
resources.
Associated SVECs : A group of multiple SVECs (Synchronization
VECtors) to indicate a set of synchronized or concurrent path
computations.
2. Introduction
[ID.pce-pcep] describes the specifications for PCEP (Path
Computation Element communication Protocol). PCEP facilitates the
communication between a Path Computation Client(PCC) and a Path
Computation Element (PCE), or between two PCEs based on PCE
Nishioka & King Expires March 29, 2009 [Page 3]
Internet-Draft draft-ietf-pce-pcep-svec-list-00 September 2008
architecture [RFC4655]. PCEP interactions include path computation
requests and path computation replies.
[ID.pce-gco] specifies a global concurrent path computation
application for the efficient use of network resources, called GCO,
based on required objective functions (OFs). To compute a set of
traffic-engineered paths for the GCO application, PCEP supports
the synchronous and dependent path computation requests required
in [RFC4657]. When a PCC or PCE sends such path computation
requests to a PCE, Synchronization VECtor (SVEC) allows the PCC or
PCE to specify a list of multiple path computation requests that
must be synchronized along with a potential dependency.[ID.pce-
pcep] defines two synchronous path computation modes using SVEC.
o Bundle of a set of independent and synchronized path
computation requests,
o Bundle of a set of dependent and synchronized path computation
requests.
These are exclusive modes. If one of the dependency 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 path
computation requests with a dependency. In order to be
synchronized among multiple sets of path computation requests
with a dependency, it is necessary to use other SVECs.
It is important for the PCE, when performing path computations,
to synchronize any path computation requests with a dependency.
For example, consider a protected end-to-end service. Two diverse
path computation requests are needed to compute the disjointed
working and protected paths. 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 results for the second one, or fail to meet
the disjoint requirement altogether.
This document defines the handling of synchronous path
computation for PCE and multiple set of path computation request
with a dependency. The following scenarios are specifically
described:
o Single domain, single PCE, dependent and synchronized path
computation request.
o Multi-domain, multiple-PCE, dependent and synchronized path
computation request.
Nishioka & King Expires March 29, 2009 [Page 4]
Internet-Draft draft-ietf-pce-pcep-svec-list-00 September 2008
The association among multiple SVECs and the processing rules to
support multiple sets of synchronized dependent path computation
requests is also described in this document. Path computation
algorithms for the associated path computation requests are out
of scope in this document.
The SVEC association and its processing rule do not require any
extension to PCEP message and object formats, when computing a
GCO for multiple diverse paths. In addition, the use of multiple
SVECs is not restricted to only SRLG, Node and Link diversity
currently defined in the SVEC object, [ID.pce-pcep], but is also
available for other dependent path computation requests.
The SVEC association is available to both multiple PCE path
computations as well as a single PCE path computation.
3. SVEC association scenarios
This section clarifies several path computation scenarios, in
which SVEC association can be applied. Also, any combination of
scenarios described in this section could be applicable.
3.1. Synchronized computation for diverse path requests
When computing two or more point-to-point diverse paths, a PCE may
compute these diverse paths concurrently, in order to increase the
probability of meeting primary and secondary path disjoint
objective and network resource optimization objective.
Two scenarios can be considered for the SVEC association of point-
to-point diverse paths.
o Two or more end-to-end diverse paths
When concurrent path computation of two or more end-to-end
diverse paths is requested, SVEC association is needed among
diverse path requests. Note here that each diverse path request
consists of primary, secondary, and etc., in which are grouped
with one SVEC.
Example of this scenario: When there are two associated end-to-
end diverse path requests with primary and secondary, all
requests must be computed in a synchronized manner.
o End-to-end primary path and its segmented secondary paths
Nishioka & King Expires March 29, 2009 [Page 5]
Internet-Draft draft-ietf-pce-pcep-svec-list-00 September 2008
When concurrent path computation of an end-to-end primary path
and several segmented secondary paths is requested, SVEC
association is needed among primary/segmented secondary-1
request, primary/segmented secondary-2 request, and etc.
In this scenario, we assume that the primary path may be pre-
computed, which is used for specifying the segment for secondary
paths. Otherwise, segment for secondary path requests are
specified in advance, by using XRO and/or IOR constraints in the
primary request.
3.2. Synchronized computation for point-to-multipoint path requests
For point-to-multipoint path requests, SVEC association can be
applied.
o Two or more point-to-multipoint paths
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-
multipoint path computation requests can be associated for
concurrent path computation, in order to optimize network
resources.
o point-to-multipoint paths and its secondary paths
When concurrent path computation of a point-to-multipoint path
and its point-to-point secondary paths [RFC4875], or a point-to-
multipoint path and its point-to-multipoint secondary paths
[ID.p2mp-te-bypass] is requested, SVEC association is needed
among these requests.
In this scenario, we use the same assumption as "end-to-end
primary path and its segmented secondary paths scenario" in
section 3.1
4. Association among SVEC
This section describes the associations among SVECs in a SVEC list.
4.1. Association among SVEC
Associated SVECs mean that there are relationships among multiple
SVECs. Request-IDs in the SVEC objects are used to indicate the
association among SVEC objects. If the same request-IDs exist in
more than two SVECs, this indicates associated SVECs. When
Nishioka & King Expires March 29, 2009 [Page 6]
Internet-Draft draft-ietf-pce-pcep-svec-list-00 September 2008
associating among SVECs, only one request-ID may in the SVEC
object may be contained in the other SVEC object. This contributes
to reducing the message size of PCEP request. Even in this case,
all of the path computation requests are synchronized.
Below is an example of associated SVECs. In this example the first
SVEC and the other SVECs are associated, and path computation
requests from Request-ID#1 to Request-ID#Z must be synchronized.
<SVEC-list>
<SVEC> without dependency flags
Request-ID #1, Request-ID #3, Request-ID #4..., Request-ID #X
<SVEC> with one or more dependency flags
Request-ID #1, Request-ID #2
<SVEC> with one or more dependency flags
Request-ID #4, Request-ID #5
........
<SVEC> without dependency flag
Request-ID #X, Request-ID #Y, Request-ID #Z
Note that path computation requests that do not have other SVECs,
like Request-ID #3, may be contained in the associated SVEC. This
request is also synchronized.
4.2. Non-associated SVECs
Non-associated SVECs mean that there are no relationships among
SVECs. If SVEC objects in PECP request messages do not have the
same request-ID, the relationship among these SVECs is not
associated. Below is an example of non-associated SVECs that does
not contain any same request-IDs.
<SVEC-list>
<SVEC> with one or more dependency flags
Request-ID #1, Request-ID #2
<SVEC> with one or more dependency flags
Nishioka & King Expires March 29, 2009 [Page 7]
Internet-Draft draft-ietf-pce-pcep-svec-list-00 September 2008
Request-ID #4, Request-ID #5
........
<SVEC> without dependency flags
Request-ID #X, Request-ID #Y, Request-ID #Z
5. Processing of SVEC list
5.1. Single PCE, single domain environments
When PCEP receives PCReq messages with more than two SVEC objects
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 may be received in a single or multiple PCReq
message(s). In the later case, the PCE may start a SyncTimer as
recommended in [ID.pce-pcep]. After receiving the whole path
computation requests, the analysis for associated SVECs has to be
started.
If there are no matching request-IDs in the different SVEC objects,
these SVEC objects are not associated, and then each set of path
computation requests in the non-associated SVEC objects has to be
computed separately.
If there are matching request-IDs in the different SVEC objects,
these SVEC objects are associated, and then all path computation
requests in the associated SVEC objects are treated in a
synchronous manner for GCO application.
If the PCE does not have capability to handle the associated SVEC
objects, it may send a PCErr message with Error-Type="Capability
not supported".
5.2. Multi-PCE, single domain environments
Currently no mechanisms exist to manage co-ordination of dependent
SVEC requests between multiple PCE`s in the same domain. If a PCC
sends a path computation request to a PCE and then sends a second
service path computation request, which is required to be disjoint
from the first service, and this request is sent to a different
PCE in the domain, no SVEC object correlation function between the
PCEs is currently available. Equally, associated SVECs are not
sent to the different PCEs in the domain.
Nishioka & King Expires March 29, 2009 [Page 8]
Internet-Draft draft-ietf-pce-pcep-svec-list-00 September 2008
5.3. Multi-PCE, multi-domain environments
When more than two PCEs are used to concurrently compute a
protected end-to-end path across multiple domains, additional
processing may be required. If the PCReq message contains multiple
associated SVEC objects and these SVEC objects contain path
computation requests that will be sent to the next PCE along the
path computation chain. Intermediate PCEs receiving such PCReq
messages may re-construct associations among SVEC objects, and
then send PCReq messages to corresponding next PCEs. If the
associated SVECs are re-constructed at the intermediate PCE, the
PCE must not start path computation until all PCRep messages are
received from neighbor PCEs. In addition, it is not recommended
that SVEC objects coming from different PCReq messages are re-
constructed. This may contribute to resource optimization from
network operator`s point of view, but it is unrealistic in the
case of multiple PCE path computation.
6. Manageability considerations
This section describes manageability considerations specified in
[ID.pce-mngabl-reqs].
6.1. Control of Function and Policy
In addition to section 8.1 to [ID.pce-pcep], PCEP implementation
should allow the configuration of association among SVECs on PCCs.
o the capability to configure SVEC association.
6.2. Information and Data Models, e.g. MIB modules
There are no additional parameters for MIB modules.
6.3. Liveness Detection and Monitoring
The associated SVEC in this document allows PCEs to compute
optimal sets of diverse path. This type of path computation may
require more time to obtain its results. Therefore, it is
recommended for PCEP to support PCE monitoring mechanism specified
in [ID.pce-monitor].
Nishioka & King Expires March 29, 2009 [Page 9]
Internet-Draft draft-ietf-pce-pcep-svec-list-00 September 2008
6.4. Verifying Correct Operation
Section 8.4 in [ID.pce-pcep] provides the sufficient descriptions
for this document. So, there are no additional considerations.
6.5. Requirements on Other Protocols and Functional Components
This document does not require anything on other protocol and
functional components.
6.6. Impact on Network Operation
Section 8.6 in [ID.pce-pcep] provides the sufficient descriptions
for this document. So, there are no additional considerations.
7. Security Considerations
This document defines the usage of SVEC list, and does not have
any extensions for PCEP protocol. Therefore the security of this
document depends on that of PCEP protocol.
8. IANA Considerations
This document has no specific extension for PCEP messages, objects
and its parameters and does not require any registry assignment.
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels," BCP 14, RFC 2119, March 1997.
[RFC4655] A. Farrel, JP. Vasseur and J. Ash, "A Path Computation
Element (PCE)-Based Architecture," RFC 4655, September
2006.
[RFC4657] J. Ash and J.L. Le Roux, "Path Computation Element (PCE)
Communication Protocol Generic Requirements," RFC 4757,
September 2006.
Nishioka & King Expires March 29, 2009 [Page 10]
Internet-Draft draft-ietf-pce-pcep-svec-list-00 September 2008
[RFC4875] R. Aggarwal, D. Papadimitriou, and S. Yasukawa, "
Extensions to Resource Reservation Protocol - Traffic
Engineering (RSVP-TE) for Point-to-Multipoint TE Label
Switched Paths (LSPs)," RFCCC4875, May 2007.
9.2. Informative References
[ID.pce-pcep]
JP. Vasseur and JL. Le Roux, "Path Computation Element
(PCE) communication Protocol (PCEP) - Version 1," draft-
ietf-pce-pcep-15 Work in progress, Sep. 2008.
[ID.pce-gco]
Y. Lee, JL. Le Roux, D. King and E. Oki, "Path
Computation Element Communication Protocol (PCECP)
Requirements and Protocol Extensions In Support of
Global Concurrent Optimization," draft-ietf-pce-global-
concurrent-optimization-04 Work in progress, July. 2008.
[ID.pce-p2mp-ext]
M. Chaitou, JL. Le Roux, and Z. Ali, "Extensions to the
Path Computation Element Communication Protocol (PCEP)
for Point-to-Multipoint Traffic Engineering Label
Switched Paths," draft-ietf-pce-pcep-p2mp-extensions-00,
Work in progress, Sep. 2008.
[ID.p2mp-te-bypass]
JL. Le Roux, R. Aggarwal, J.P. Vasseur, and M. Vigoureux,
"P2MP MPLS-TE Fast Reroute with P2MP Bypass Tunnels,"
draft-ietf-mpls-p2mp-te-bypass-02," Work in progress,
Mar. 2008.
[ID.pce-mngabl-reqs]
A. Farrel, "Inclusion of Manageability Sections in PCE
Working Group Drafts," draft-ietf-pce-manageability-
requirements-04 Work in progress, June. 2008.
[ID.pce-monitor]
JP. Vasseur, JL. Le Roux and Y. Ikejiri, "A set of
monitoring tools for Path Computation Element based
Nishioka & King Expires March 29, 2009 [Page 11]
Internet-Draft draft-ietf-pce-pcep-svec-list-00 September 2008
Architecture," draft-ietf-pce-monitoring-02 Work in
progress, Sep. 2008.
Authors' Addresses
Itaru Nishioka
NEC Corp.
1753 Shimonumabe,
Kawasaki, 211-8555,
Japan
Phone: +81 44 396 3287
Email: i-nishioka@cb.jp.nec.com
Daniel King
Old Dog Consulting
UK
Phone: +44 7790 775187
Email: daniel@olddog.co.uk
Nishioka & King Expires March 29, 2009 [Page 12]
Internet-Draft draft-ietf-pce-pcep-svec-list-00 September 2008
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology
described in this document or the extent to which any license
under such rights might or might not be available; nor does it
represent that it has made any independent effort to identify any
such rights. Information on the procedures with respect to rights
in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention
any copyrights, patents or patent applications, or other
proprietary rights that may cover technology that may be required
to implement this standard. Please address the information to the
IETF at ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Nishioka & King Expires March 29, 2009 [Page 13]
