[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02 03 04 05 RFC 6007

 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
 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-
    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
    The list of current Internet-Drafts can be accessed at
    The list of Internet-Draft Shadow Directories can be accessed at
    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
     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
    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
       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",
    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
    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
    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
    Associated SVECs : A group of multiple SVECs (Synchronization
         VECtors) to indicate a set of synchronized or concurrent path
 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
      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
      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
     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
     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> 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> 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
     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
 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
     [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
              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.
              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.
              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.
              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.
              A. Farrel, "Inclusion of Manageability Sections in PCE
               Working Group Drafts," draft-ietf-pce-manageability-
               requirements-04 Work in progress, June. 2008.
              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,
    Phone: +81 44 396 3287
    Email: i-nishioka@cb.jp.nec.com
    Daniel King
    Old Dog Consulting
    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
 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.
    Funding for the RFC Editor function is currently provided by the
    Internet Society.
 Nishioka & King         Expires March 29, 2009                [Page 13]

Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/