doc: Add RFC documents

1 files changed, 1011 insertions, 0 deletions

diff --git a/doc/rfc/rfc6007.txt b/doc/rfc/rfc6007.txt
new file mode 100644
index 0000000..5763531
--- /dev/null
+++ b/doc/rfc/rfc6007.txt
@@ -0,0 +1,1011 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                       I. Nishioka
+Request for Comments: 6007                                     NEC Corp.
+Category: Informational                                          D. King
+ISSN: 2070-1721                                       Old Dog Consulting
+                                                          September 2010
+
+
+           Use of the Synchronization VECtor (SVEC) List for
+                Synchronized Dependent Path Computations
+
+Abstract
+
+   A Path Computation Element (PCE) may be required to perform dependent
+   path computations.  Dependent path computations are requests that
+   need to be synchronized in order to meet specific objectives.  An
+   example of a dependent request would be a PCE computing a set of
+   services that are required to be diverse (disjointed) from each
+   other.  When a PCE computes sets of dependent path computation
+   requests concurrently, use of the Synchronization VECtor (SVEC) list
+   is required for association among the sets of dependent path
+   computation requests.  The SVEC object is optional and carried within
+   the Path Computation Element Communication Protocol (PCEP) PCRequest
+   (PCReq) message.
+
+   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
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Not all documents
+   approved by the IESG are a candidate for any level of Internet
+   Standard; see Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc6007.
+
+
+
+
+
+
+Nishioka & King               Informational                     [Page 1]
+
+RFC 6007             SVEC List for Path Computations      September 2010
+
+
+Copyright Notice
+
+   Copyright (c) 2010 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+   This document may contain material from IETF Documents or IETF
+   Contributions published or made publicly available before November
+   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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Nishioka & King               Informational                     [Page 2]
+
+RFC 6007             SVEC List for Path Computations      September 2010
+
+
+Table of Contents
+
+   1. Introduction ....................................................3
+      1.1. SVEC Object ................................................4
+      1.2. Application of SVEC Lists ..................................5
+   2. Terminology .....................................................6
+   3. SVEC Association Scenarios ......................................7
+      3.1. Synchronized Computation for Diverse Path Requests .........7
+      3.2. Synchronized Computation for Point-to-Multipoint
+           Path Requests ..............................................8
+   4. SVEC Association ................................................9
+      4.1. SVEC List ..................................................9
+      4.2. Associated SVECs ...........................................9
+      4.3. Non-Associated SVECs ......................................10
+   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 ............................13
+      6.1. Disjoint VSPT .............................................13
+      6.2. Disjoint VSPT Encoding ....................................14
+      6.3. Path Computation Procedure ................................15
+   7. Manageability Considerations ...................................15
+      7.1. Control of Function and Policy ............................15
+      7.2. Information and Data Models (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. References .....................................................16
+      9.1. Normative References ......................................16
+      9.2. Informative References ....................................17
+   10. Acknowledgements ..............................................18
+
+1.  Introduction
+
+   [RFC5440] describes the specifications for the Path Computation
+   Element Communication Protocol (PCEP).  PCEP specifies the
+   communication between a Path Computation Client (PCC) and a Path
+   Computation Element (PCE), or between two PCEs based on the PCE
+   architecture [RFC4655].  PCEP interactions include path computation
+   requests and path computation replies.
+
+   The PCE may be required to compute independent and dependent path
+   requests.  Path computation requests are said to be independent if
+   they are not related to each other and therefore not required to be
+
+
+
+Nishioka & King               Informational                     [Page 3]
+
+RFC 6007             SVEC List for Path Computations      September 2010
+
+
+   synchronized.  Conversely, a set of dependent path computation
+   requests is such that their computations cannot be performed
+   independently of each other, and the requests must be synchronized.
+   The Synchronization VECtor (SVEC) with a list of the path computation
+   request identifiers carried within the request message allows the PCC
+   or PCE to specify a list of multiple path computation requests that
+   must be synchronized.  Section 1.1 ("SVEC Object") describes the SVEC
+   object.  Section 1.2 ("Application of SVEC Lists") describes the
+   application of SVEC lists in certain scenarios.
+
+   This informational document clarifies the handling of dependent and
+   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.
+
+1.1.  SVEC Object
+
+   When a PCC or PCE sends path computation requests to a PCE, a PCEP
+   Path Computation Request (PCReq) message may carry multiple requests,
+   each of which has a unique path computation request identifier.  The
+   SVEC with a list of the path computation request identifiers carried
+   within the request message allows the PCC or PCE to specify a list 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 specific 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 Shared Risk Link Group (SRLG)
+   diverse flags) in the SVEC:
+
+   o  A set of independent and synchronized path computation requests.
+
+   o  A set of dependent and synchronized path computation requests.
+
+   See [RFC5440] for more details on dependent, independent, and
+   synchronous path computation.
+
+   These computation modes are exclusive to each other in a single SVEC.
+   If one of the dependency flags in a SVEC is set, it indicates that a
+   set of synchronous path computation requests has a dependency and
+   does not allow any other path computation requests.  In order to be
+   synchronized with other path computation requests with a dependency,
+   it is necessary to associate them.
+
+
+
+Nishioka & King               Informational                     [Page 4]
+
+RFC 6007             SVEC List for Path Computations      September 2010
+
+
+   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 Request Parameters (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
+   synchronize any path computation requests with a dependency.  For
+   example, consider two protected end-to-end services:
+
+   o  It would be beneficial for each back-up path to be disjointed so
+      they do not share the same links and nodes as the working path.
+
+   o  Two diverse path computation requests would be needed to compute
+      the working and disjointed 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 either providing sub-optimal path disjoint results for the
+   protected path or failing to meet the end-to-end disjoint requirement
+   altogether.
+
+   Additionally, SVEC can be applied to end-to-end diverse path
+   computations that traverse multiple domains.  [RFC5441] describes two
+   approaches, synchronous (i.e., simultaneous) and 2-step approaches,
+   for end-to-end diverse path computation across a chain of domains.
+   The path computation procedure is specified for the 2-step approaches
+   in [RFC5521], but no guidelines are provided for the synchronous
+   approach described in this document.
+
+   The following scenarios are specifically described within this
+   document:
+
+   o  Single-domain, single-PCE, dependent and synchronized path
+      computation request.
+
+   o  Single-domain, multi-PCE, dependent and synchronized path request.
+
+   o  Multi-domain, dependent and synchronized path computation request,
+      including end-to-end diverse path computation.
+
+
+
+
+
+
+Nishioka & King               Informational                     [Page 5]
+
+RFC 6007             SVEC List for Path Computations      September 2010
+
+
+   The association among multiple SVECs for multiple sets of
+   synchronized dependent path computations is also described in this
+   document, as well as the disjoint Virtual Shortest Path Tree (VSPT)
+   encoding rule for end-to-end diverse path computation across domains.
+   Path computation algorithms for these path computation scenarios are
+   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 objective
+   function (OF) or a set of 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 document
+   do not require any extension to PCEP messages and object formats,
+   when computing a GCO for multiple or end-to-end 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
+   [RFC5440], but is also available for other dependent path computation
+   requests.
+
+   The SVEC association and disjoint VSPT are available to both single-
+   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 trees.
+
+   GCO (Global Concurrent Optimization): A concurrent path computation
+      application, defined in [RFC5557], where a set of traffic
+      engineered (TE) paths is computed concurrently in order to
+      efficiently utilize network resources.
+
+
+
+
+
+
+
+Nishioka & King               Informational                     [Page 6]
+
+RFC 6007             SVEC List for Path Computations      September 2010
+
+
+   Synchronized: Describes a set of path computation requests that the
+      PCE associates and that the PCE does not compute independently of
+      each other.
+
+   VSPT: Virtual Shortest Path Tree, defined in [RFC5441].
+
+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
+
+   A PCE may compute two or more point-to-point diverse paths
+   concurrently, in order to increase the probability of meeting primary
+   and secondary path diversity (or disjointness) objectives and network
+   resource optimization objectives.
+
+   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 tertiary (and beyond) path requests, in which
+   all path requests are grouped with one SVEC association.
+
+   Consider two end-to-end services that are to be kept separate by
+   using diverse paths.  The path computation requests would need to be
+   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
+
+   When concurrent path computation for segment recovery paths, as shown
+   in Figure 1, is requested, SVEC association is needed between a
+   primary path and several segmented secondary paths.
+
+
+
+
+
+
+
+
+Nishioka & King               Informational                     [Page 7]
+
+RFC 6007             SVEC List for Path Computations      September 2010
+
+
+                   <------------ 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-computed
+   and used for specifying the segment for secondary paths.  Otherwise,
+   the segment for secondary path requests is specified in advance, by
+   using Exclude Route Object (XRO) and/or Include Route Object (IRO)
+   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 path computation request is represented
+      as a set of point-to-point paths [RFC6006], 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 their 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 is
+      requested, SVEC association is needed among these requests.  In
+      this scenario, we use the same assumption as the "end-to-end
+      primary path and its segmented secondary paths" scenario in
+      Section 3.1.
+
+
+
+
+
+
+
+
+
+
+
+Nishioka & King               Informational                     [Page 8]
+
+RFC 6007             SVEC List for Path Computations      September 2010
+
+
+4.  SVEC Association
+
+   This section describes the associations among SVECs in a SVEC list.
+
+4.1.  SVEC List
+
+   PCEP provides the capability to carry one or more SVEC objects in a
+   PCReq message, and this set of SVEC objects within the PCReq message
+   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" means that there are relationships among multiple
+   SVECs in a 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
+   SVEC objects, this indicates these SVEC objects are associated.  When
+   associating among SVEC objects, at least one request identifier must
+   be shared between associated SVECs.  The SVEC objects can be
+   associated regardless of the dependency flags in each SVEC object,
+   but it is recommended to use a single SVEC if the dependency flags
+   are not set in all SVEC objects.  Similarly, when associating among
+   SVEC objects with dependency flags, it is recommended to construct
+   them using a minimum set of associated SVECs, thus avoiding complex
+   relational associations.
+
+   Below is an example of associated SVECs.  In this example, the first
+   SVEC is associated with the other SVECs, and all of the path
+   computation requests contained in the associated SVECs (i.e.,
+   Request-IDs #1, #2, #3, #4, #X, #Y, and #Z) must be synchronized.
+
+      <SVEC-list>
+
+          <SVEC> without dependency flags
+
+           Request-ID #1, Request-ID #3, Request-ID #X
+
+          <SVEC> with one or more dependency flags
+
+           Request-ID #1, Request-ID #2
+
+
+
+Nishioka & King               Informational                     [Page 9]
+
+RFC 6007             SVEC List for Path Computations      September 2010
+
+
+          <SVEC> with one or more dependency flags
+
+           Request-ID #3, Request-ID #4
+
+          <SVEC> without dependency flag
+
+           Request-ID #X, Request-ID #Y, Request-ID #Z
+
+4.3.  Non-Associated SVECs
+
+   "Non-associated SVECs" means that there are no relationships among
+   SVECs.  If none of the SVEC objects in the SVEC list on a PCReq
+   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 do not contain any
+   common request-IDs.
+
+      <SVEC-list>
+
+          <SVEC> with one or more dependency flags
+
+           Request-ID #1, Request-ID #2
+
+          <SVEC> with one or more dependency flags
+
+           Request-ID #3, Request-ID #4
+
+          <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
+
+   In this environment, there is a single PCE within the domain.
+
+   When a PCE receives PCReq messages with more than one SVEC object in
+   the SVEC list, PCEP has to first check the request-IDs in all SVEC
+   objects in order to identify any associations among them.
+
+   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.
+
+
+
+
+Nishioka & King               Informational                    [Page 10]
+
+RFC 6007             SVEC List for Path Computations      September 2010
+
+
+   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 a PCE that is unable to handle the associated SVEC finds the
+   common request-IDs in multiple SVEC objects, the PCE should cancel
+   the path computation request and respond to the PCC with the PCErr
+   message Error-Type="Capability not supported".
+
+   In the case that M path computation requests are sent across multiple
+   PCReq messages, the PCE may start a SyncTimer as recommended in
+   Section 7.13.3 ("Handling of the SVEC Object") of [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 subsequent PCReq messages are
+   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
+
+   There are multiple PCEs in a domain, to which PCCs can communicate
+   directly, and PCCs can choose an appropriate PCE for load-balanced
+   path computation requests.  In this environment, it is possible that
+   dependent path computation requests are sent to different PCEs.
+
+   However, if a PCC sends path computation requests to a PCE, and then
+   sends a further path computation request to a different PCE using the
+   SVEC list to show that the further request is dependent on the first
+   requests, 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].  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
+
+   In this environment, there are multiple domains in which PCEs are
+   located in each domain, and end-to-end dependent paths (i.e., diverse
+   paths) are computed using multiple PCEs.  Note that we assume a chain
+   of PCEs is predetermined and the Backward-Recursive PCE-Based
+   Computation (BRPC) procedure [RFC5441] is in use.
+
+   The SVECs can be applied to end-to-end diverse path computations that
+   traverse multiple domains.  [RFC5441] describes two approaches,
+   synchronous (i.e., simultaneous) and 2-step approaches, for
+
+
+
+Nishioka & King               Informational                    [Page 11]
+
+RFC 6007             SVEC List for Path Computations      September 2010
+
+
+   end-to-end diverse path computation across a chain of domains.  In
+   the 2-step approaches described in [RFC5521], it is not necessary to
+   use the associated SVECs if any of the dependency flags in a SVEC
+   object are not set.  On the other hand, the simultaneous approach may
+   require the associated SVEC because at least one of the dependency
+   flags is required to be set in a SVEC object.  Thus, a use case of
+   the simultaneous approach is described in this environment.
+
+   When a chain of PCEs located in separate domains is used for
+   simultaneous path computations, additional path computation
+   processing is required, as described in Section 6 of this document.
+
+   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 the path
+   computation requests in a PCReq message, it is not necessary to
+   reconstruct associations among SVEC objects.  Thus, the PCReq message
+   is passed to the tail-end PCE.  When a PCReq message contains more
+   than one SVEC object with the dependency flag set, the contained
+   SVECs may then be associated.  PCEs receiving the associated SVECs
+   must maintain their association and must consider their relationship
+   when performing path computations after receiving a corresponding
+   PCReply (PCRep) message.
+
+   When a chain of PCEs is different, it is required that intermediate
+   PCEs receiving such PCReq messages may reconstruct associations among
+   SVEC objects, and then send PCReq messages to corresponding PCEs
+   located in neighboring domains.  If the associated SVECs are
+   reconstructed 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 an open issue and is
+   currently being discussed in [H-PCE], which proposes a hierarchical
+   PCE architecture.
+
+
+
+
+
+
+
+
+
+
+
+
+Nishioka & King               Informational                    [Page 12]
+
+RFC 6007             SVEC List for Path Computations      September 2010
+
+
+6.  End-to-End Diverse Path Computation
+
+   In this section, the synchronous approach is provided to compute
+   primary and secondary paths simultaneously.
+
+6.1.  Disjoint VSPT
+
+   The BRPC procedure constructs a VSPT to inform the enquiring PCE of
+   potential paths to the destination node.
+
+   In the end-to-end diverse path computation, diversity (or
+   disjointness) information among the potential paths must be preserved
+   in the VSPT to ensure an end-to-end disjoint path.  In order to
+   preserve diversity (or disjointness) information, disjoint VSPTs 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
+   each VSPT contains a potential set of primary and secondary paths.
+
+   Figure 2 shows an example network.  Here, transit nodes in domains
+   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
+   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
+   VSPT, which is indicated in a PCRep to PCE1.  When receiving the
+   disjoint VSPT, PCE1 recognizes the disjoint request and disjoint VSPT
+   information.  PCE1 will then continue to process the request and
+   compute the diverse path using the BRPC procedure [RFC5441].
+   Encoding for the disjoint VSPT is described in Section 6.2.
+
+              Domain1          Domain2
+
+           +----------+     +----------+
+
+           |   PCE1   |     |   PCE2   |    S1: Source node
+
+           |         BN1---BN4         |    D1: Destination node
+
+           | S1      BN2---BN5      D1 |    BN1-BN6: Border nodes
+
+           |         BN3---BN6         |
+
+           +----------+     +----------+
+
+          Figure 2.  Example Network for Diverse Path Computation
+
+
+
+
+Nishioka & King               Informational                    [Page 13]
+
+RFC 6007             SVEC List for Path Computations      September 2010
+
+
+               VSPT1:            VSPT2:              VSPT3:
+
+                 D1                D1                  D1
+
+                / \               / \                 / \
+
+             BN4   BN5         BN4   BN6           BN5   BN6
+
+                Figure 3.  Disjoint VSPTs from PCE2 to PCE1
+
+6.2.  Disjoint VSPT Encoding
+
+   Encoding for the disjoint VSPT follows the definition of PCEP message
+   encoding in [RFC5440].
+
+   The PCEP PCRep message returns a disjoint VSPT as <path list> for
+   each RP object (Request Parameter object).  The order of <path> in
+   <path list> among <responses> implies a set of primary Explicit Route
+   Objects (EROs) and secondary EROs.
+
+   A PCE sending a PCRep with a disjoint VSPT can reply with a partial
+   disjoint VSPT based on its network operation policy, but the order of
+   <path> in <path list> must be aligned correctly.
+
+   If confidentiality is required between domains, the path key
+   mechanism defined in [RFC5520] is used for a disjoint VSPT.
+
+   Below are the details of the disjoint VSPT encoding (in Figure 3),
+   when a primary path and a secondary path are requested from S1 to D1.
+
+      o  Request ID #1 (Primary)
+
+         - ERO1 BN4(TE route ID)- ...-D1(TE-Router ID)  [for VSPT1]
+
+         - ERO2 BN4(TE route ID)- ...-D1(TE-Router ID)  [for VSPT2]
+
+         - ERO3 BN5(TE route ID)- ...-D1(TE-Router ID)  [for VSPT3]
+
+      o  Request ID #2 (Secondary)
+
+         - ERO4 BN5(TE route ID)- ...-D1(TE-Router ID)  [for VSPT1]
+
+         - ERO5 BN6(TE route ID)- ...-D1(TE-Router ID)  [for VSPT2]
+
+         - ERO6 BN6(TE route ID)- ...-D1(TE-Router ID)  [for VSPT3]
+
+
+
+
+
+
+Nishioka & King               Informational                    [Page 14]
+
+RFC 6007             SVEC List for Path Computations      September 2010
+
+
+6.3.  Path Computation Procedure
+
+   For end-to-end diverse path computation, the same mode of operation
+   as that of the BRPC procedure can be applied (i.e., Step 1 to Step n
+   in Section 4.2 of [RFC5441]).  A question that must be considered is
+   how to recognize disjoint VSPTs.
+
+   The recognition of disjoint VSPTs is achieved by the PCE sending a
+   PCReq to its neighbor PCE, which maintains the path computation
+   request (PCReq) information.  If the PCReq has one or more SVEC
+   object(s) with the appropriate dependency flags, the received PCRep
+   will contain the disjoint VSPT.  If not, the received VSPT is a
+   normal VSPT based on the shortest path computation.
+
+   Note that the PCE will apply a suitable algorithm for computing
+   requests with disjoint VSPTs.  The selection and application of the
+   appropriate algorithm is out of scope in this document.
+
+7.  Manageability Considerations
+
+   This section describes manageability considerations specified in
+   [PCE-MNG-REQS].
+
+7.1.  Control of Function and Policy
+
+   In addition to [RFC5440], PCEP implementations should allow the PCC
+   to be responsible for mapping the requested paths to computation
+   requests.  The PCC should construct the SVECs to identify and
+   associate SVEC relationships.
+
+7.2.  Information and Data Models (MIB Modules)
+
+   There are currently no additional parameters for MIB modules.  There
+   would be 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
+
+   The associated SVEC in this document allows PCEs to compute optimal
+   sets of diverse paths.  This type of path computation may require
+   more time to obtain its results.  Therefore, it is recommended for
+   PCEP to support the PCE monitoring mechanism specified in [RFC5886].
+
+7.4.  Verifying Correct Operation
+
+   [RFC5440] provides a sufficient description for this document.  There
+   are no additional considerations.
+
+
+
+
+Nishioka & King               Informational                    [Page 15]
+
+RFC 6007             SVEC List for Path Computations      September 2010
+
+
+7.5.  Requirements on Other Protocols and Functional Components
+
+   This document does not require any other protocol and functional
+   components.
+
+7.6.  Impact on Network Operation
+
+   [RFC5440] provides descriptions for the mechanisms discussed in this
+   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
+
+   This document describes the usage of the SVEC list, and does not have
+   any extensions for PCEP.  The security of the procedures described in
+   this document depends on PCEP [RFC5440].  However, a PCE that
+   supports associated SVECs may be open to Denial-of-Service (DoS)
+   attacks 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  Applying provisioning to PCEs, e.g., for a given number of
+      simultaneous services (recommended).
+
+   o  Using a 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.  References
+
+9.1.  Normative References
+
+   [RFC4655]      Farrel, A., Vasseur, J.-P., and J. Ash, "A Path
+                  Computation Element (PCE)-Based Architecture",
+                  RFC 4655, August 2006.
+
+   [RFC4657]      Ash, J., Ed., and J. Le Roux, Ed., "Path Computation
+                  Element (PCE) Communication Protocol Generic
+                  Requirements", RFC 4657, September 2006.
+
+
+
+
+Nishioka & King               Informational                    [Page 16]
+
+RFC 6007             SVEC List for Path Computations      September 2010
+
+
+   [RFC4875]      Aggarwal, R., Ed., Papadimitriou, D., Ed., and S.
+                  Yasukawa, Ed., "Extensions to Resource Reservation
+                  Protocol - Traffic Engineering (RSVP-TE) for Point-to-
+                  Multipoint TE Label Switched Paths (LSPs)", RFC 4875,
+                  May 2007.
+
+   [RFC5440]      Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path
+                  Computation Element (PCE) Communication Protocol
+                  (PCEP)", RFC 5440, March 2009.
+
+   [RFC5441]      Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le
+                  Roux, "A Backward-Recursive PCE-Based Computation
+                  (BRPC) Procedure to Compute Shortest Constrained
+                  Inter-Domain Traffic Engineering Label Switched
+                  Paths", RFC 5441, April 2009.
+
+   [RFC5520]      Bradford, R., Ed., Vasseur, JP., and A. Farrel,
+                  "Preserving Topology Confidentiality in Inter-Domain
+                  Path Computation Using a Path-Key-Based Mechanism",
+                  RFC 5520, April 2009.
+
+   [RFC5521]      Oki, E., Takeda, T., and A. Farrel, "Extensions to the
+                  Path Computation Element Communication Protocol (PCEP)
+                  for Route Exclusions", RFC 5521, April 2009.
+
+   [RFC5557]      Lee, Y., Le Roux, JL., King, D., and E. Oki, "Path
+                  Computation Element Communication Protocol (PCEP)
+                  Requirements and Protocol Extensions in Support of
+                  Global Concurrent Optimization", RFC 5557, July 2009.
+
+9.2.  Informative References
+
+   [H-PCE]        King, D., Ed., and A. Farrel, Ed., "The Application of
+                  the Path Computation Element Architecture to the
+                  Determination of a Sequence of Domains in MPLS &
+                  GMPLS", Work in Progress, December 2009.
+
+   [PCE-MNG-REQS] Farrel, A., "Inclusion of Manageability Sections in
+                  PCE Working Group Drafts", Work in Progress, July
+                  2009.
+
+   [RFC5886]      Vasseur, JP., Ed., Le Roux, JL., and Y. Ikejiri, "A
+                  Set of Monitoring Tools for Path Computation Element
+                  (PCE)-Based Architecture", RFC 5886, June 2010.
+
+
+
+
+
+
+
+Nishioka & King               Informational                    [Page 17]
+
+RFC 6007             SVEC List for Path Computations      September 2010
+
+
+   [RFC6006]      Zhao, Q., Ed., King, D., Ed., Verhaeghe, F., Takeda,
+                  T., Ali, Z., and J. Meuric, "Extensions to the Path
+                  Computation Element Communication Protocol (PCEP) for
+                  Point-to-Multipoint Traffic Engineering Label Switched
+                  Paths", RFC 6006, September 2010.
+
+10.  Acknowledgements
+
+   The authors would like to thank Adrian Farrel, Julien Meuric, and
+   Filippo Cugini for their valuable comments.
+
+Authors' Addresses
+
+   Itaru Nishioka
+   NEC Corp.
+   1753 Shimonumabe,
+   Kawasaki, 211-8666,
+   Japan
+
+   Phone: +81 44 396 3287
+   EMail: i-nishioka@cb.jp.nec.com
+
+
+   Daniel King
+   Old Dog Consulting
+   United Kingdom
+
+   Phone: +44 7790 775187
+   EMail: daniel@olddog.co.uk
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Nishioka & King               Informational                    [Page 18]
+