Network Working Group I. Nishioka Internet Draft NEC Intended Status: Standard Track Daniel King Expires: January 2008 Aria Networks July 2007 The use of SVEC (Synchronization VECtor) list for Synchronized dependent path computations draft-nishioka-pce-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. Copyright Notice Copyright (C) The IETF Trust (2007). All rights reserved. Nishioka & King Expires January, 2008 [Page 1] Internet-Draft draft-nishioka-pce-svec-list-00.txt July 2007 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. This document describes the usage of multiple Synchronization VECtors (SVECs) in the SVEC list. When a PCE computes multiple sets of dependent path computation requests, it is required to use SVEC list for association among the sets of dependent path computation requests. The aim of this document is to define the association among SVECs and its processing rule. 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 [RFC2119]. Table of Contents 1. Terminology.....................................................3 2. Introduction....................................................3 3. Association among SVEC..........................................4 3.1 Associated SVECs ..............................................4 3.2 Un-associated SVECs ...........................................4 4. Processing of SVEC list ........................................5 5. Manageability Considerations ..................................5 6. Security Considerations ........................................5 7. IANA Considerations ............................................5 8. References .....................................................5 8.1. Normative references ..........................................5 8.2. Informative references ........................................6 9. Authors' Addresses ............................................6 Nishioka & King Expires January, 2008 [Page 2] Internet-Draft draft-nishioka-pce-svec-list-00.txt July 2007 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 Peer: an element involved in a PCEP session (i.e. a PCC or a PCE). 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 architecture [RFC4655]. PCEP interactions include path computation requests and path computation replies. PCEP supports the synchronous and dependent path computation Requests required in [RFC4657], when a PCC or PCE sends path computation requests to a PCE. For requesting the synchronous and dependent path computation, SVEC 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. Nishioka & King Expires January, 2008 [Page 3] Internet-Draft draft-nishioka-pce-svec-list-00.txt July 2007 It is important for the PCE, when performing path optimizations, to synchronize the multiple sets of path computation requests with a dependency. For example, consider that two diverse sets of path computation requests are computed for end-to-end path protection/ restoration. If they are computed sequentially, the first set of requests may give negative impacts on the second set of requests. This document defines the synchronous path computation for the multiple sets of path computation requests with dependencies below. o Bundle of multiple sets of dependent and synchronized path computation requests that must be synchronized. This document describes the association among multiple SVECs and its processing rules to support multiple set of dependent path computation requests to be synchronized. The SVEC association and its processing rule do not require any extension on PCEP message and object formats. In addition, the use of multiple SVEC does not restrict to SRLG, Node and Link diversity currently defined in the SVEC object, [ID.pce-pcep], but is also available for other dependent path computation requests. In this version of the document, the problem the authors describe is limited to single PCE and single domain synchronized path computation. In a future version of this document there will be an analysis of multi-PCE and multi-Domain synchronized path computations. 3. Association among SVECs This section describes the associations among SVECs in a SVEC list. 3.1 Associated SVECs 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 associating among SVECs, only one request-ID may in the SVEC object may be contained in the other SVEC object. This contributes to reduce 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. Nishioka & King Expires January, 2008 [Page 3] Internet-Draft draft-nishioka-pce-svec-list-00.txt July 2007 without dependency flags Request-ID #1, Request-ID #3, Request-ID #4... , Request-ID #X with one or more dependency flags Request-ID #1, Request-ID #2 with one or more dependency flags Request-ID #4, Request-ID #5 ........ without dependency flag Request-ID #X, Request-ID #Y, Request-ID #Z Note here 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. 3.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. with one or more dependency flags Request-ID #1, Request-ID #2 with one or more dependency flags Request-ID #4, Request-ID #5 ........ without dependency flags Request-ID #X, Request-ID #Y, Request-ID #Z Nishioka & King Expires January, 2008 [Page 4] Internet-Draft draft-nishioka-pce-svec-list-00.txt July 2007 4. Processing of SVEC list When PCEP receives PCReq messages with more than two SVEC objects in the SVEC list, PCEP MUST check request-IDs in all SVEC objects firstly, to obtain the association among them. The SVEC objects MAY be received in a single or multiple PCReq message(s). In the later case, PCE start SynTimer as defined in [ID.pce-pcep]. After receiving the whole path computation requests, the analysis for associated SVECs MUST be started. If there are no same 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 MUST be computed separately. If there are the same request-IDs in the different SVEC objects, these SVEC objects are associated, and then all path computation requests in the associated SVEC objects MUST be computed with synchronous manner. 4. Manageability considerations This document does not describe any specific protocol extensions to PCEP. Other manageability considerations specified in [ID.pce-mngabl-reqs] still need to be discussed, and any requirements will be included in future versions of this document. 5. 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. 6. IANA Considerations This document does not describe any specific protocol extensions to PCEP and not require any registry assignment. Nishioka & King Expires January, 2008 [Page 5] Internet-Draft draft-nishioka-pce-svec-list-00.txt July 2007 7. References 7.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. 7.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-07 Work in progress Mar. 2007. [ID.pce-mngabl-reqs] A. Farrel, "Requirements for Manageability Sections in PCE Working Group Drafts," draft-ietf-pce-manageability- requirements-01 (Work in progress) Feb. 2007. 8. Authors' Addresses Itaru Nishioka NEC Corp. 1753 Shimonumabe, Kawasaki, Kanagawa 211-8555 Japan Phone: +81 44 396 3287 Email: i-nishioka@cb.jp.nec.com Daniel King Aria Networks 44/45 Market Place, Chippenham, SN15 3HU, United Kingdom Phone: +44 7790 775187 Email: daniel.king@aria-networks.com Nishioka & King Expires January, 2008 [Page 5] Internet-Draft draft-nishioka-pce-svec-list-00.txt July 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). 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. 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. 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. Nishioka & King Expires January, 2008 [Page 6]