Network Working Group Y. Lee Internet-Draft Huawei Technologies (USA) Intended status: Standards Track D. King Expires: April 14, 2007 Aria Networks E. Oki NTT October 11, 2006 Path Computation Element Communication Protocol (PCECP) Requirements for Support of Global Concurrent Optimization draft-lee-pce-global-concurrent-optimization-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 April 14, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Lee, et al. Expires April 14, 2007 [Page 1] Internet-Draft PCE Global Concurrent Optimization October 2006 Abstract The Path Computation Element (PCE) is a network component, application, or node that is capable of performing path computations at the request of Path Computation Clients (PCCs). The PCE is applied in Multiprotocol Label Switching Traffic Engineering (MPLS-TE) networks and in Generalized MPLS (GMPLS) networks to determine the routes of Label Switched Paths (LSPs) through the network. The Path Computation Element Communication Protocol (PCECP) is specified for communications between PCCs and PCEs, and between cooperating PCEs. This document provides application-specific requirements for the PCECP in support of a large-scale concurrent path computation application. Table of Contents 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Applicability for Global Concurrent Path Computation . . . . . 6 3.1. Greenfield Traffic Engineering . . . . . . . . . . . . . . 6 3.2. Re-optimization of Existing Networks . . . . . . . . . . . 6 3.2.1. Traffic Migration . . . . . . . . . . . . . . . . . . 6 3.3. Multi-layer Traffic Engineering . . . . . . . . . . . . . 7 3.4. Reconfiguration of the Virtual Network Topology (VNT) . . 7 3.5. The PCE Application Architecture . . . . . . . . . . . . . 7 4. PCECP Requirements . . . . . . . . . . . . . . . . . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 8.1. Normative References . . . . . . . . . . . . . . . . . . . 15 8.2. Informative References . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Intellectual Property and Copyright Statements . . . . . . . . . . 17 Lee, et al. Expires April 14, 2007 [Page 2] Internet-Draft PCE Global Concurrent Optimization October 2006 1. Terminology The terminology explained herein complies with [RFC4655]. 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. TED: Traffic Engineering Database which contains the topology and resource information of the domain. The TED may be fed by IGP extensions or potentially by other means. PCECP: The PCE Communications Protocol that is used to communicate path computation requests from PCCs to a PCE, and to return computed paths from the PCE to the PCCs. The PCECP can also be used between cooperating PCEs. Although this is not a protocol specification, 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 [RFC2119] for clarity of specification of requirements. Lee, et al. Expires April 14, 2007 [Page 3] Internet-Draft PCE Global Concurrent Optimization October 2006 2. Introduction [RFC4655] defines the PCE Architecture and explains how a PCE may compute the paths of Multiprotocol Label Switching Traffic Engineering (MPLS-TE) and Generalized MPLS (GMPLS) Label Switched Paths (LSPs) at the request of PCCs. A PCC is shown to be any network component that makes such a request and may be a Label Switching Router (LSR) or a Network Management Station (NMS). The PCE, itself, is shown to be located anywhere within the network, and may be within an LSR, an NMS or Operational Support System (OSS), or may be an independent network server. The PCECP is the communications protocol used between PCC and PCE, and may also be used between cooperating PCEs. [RFC4657] sets out the common protocol requirements for the PCECP. Additional application-specific requirements for PCECP are deferred to separate documents. This document provides the PCECP extension requirements in support of a large-scale concurrent path computation application that may arise during network operations. A large-scale concurrent path computation is a path computation application where a large number of TE paths need to be computed concurrently in order to efficiently utilize network resources. The computation method involved with a large- scale concurrent path computation is referred to as global concurrent optimization in this document. Appropriate computation algorithms to perform this type of optimization are out of scope of this document. As new LSPs are added sequentially or removed from the network over time, the global network resources become fragmented and the network no longer provides the optimal use of the available capacity. A large-scale global concurrent path computation would be able to simultaneously consider the entire topology of the network and the complete set of existing LSPs, and their respective constraints, and look to re-optimize the entire network to satisfy all constraints for all LSPs. The need for large-scale concurrent path computation may also arise when network operators need to set up a large number of TE LSPs in their network planning process. All large-scale path computation is typically an off-line computation. This document does not exclude the possibility that network operators might require on-line computation for large-scale concurrent path computation in the event of catastrophic network failures, where large numbers of TE LSPs need to be optimally rerouted in real-time. The off-line computation requirements to support a large number of TE LSPs are quite different from on-line path computation requirements. Lee, et al. Expires April 14, 2007 [Page 4] Internet-Draft PCE Global Concurrent Optimization October 2006 While on-line path computation is focused on finding a single best path in a timely manner given the prevailing network conditions, a large-scale off-line path computation application involves finding paths for a large number of TE LSPs concurrently to meet a global objective. While off-line computation may not require such stringent time constraints as on-line path computation, the key objective associated with large-scale off-line computation is to efficiently allocate network resources from a global network perspective. While on-line path computation is tactical, off-line large-scale path computation is strategic. As the PCE is envisioned to provide solutions in all path computation matters, it is anticipated that the PCE would provide solutions for large-scale global concurrent path computation needs. Specific algorithms that the PCE may employ are beyond the scope of this document. The main focus of this document is to highlight the PCC-PCE communication needs in support of a large-scale concurrent path computation application. The PCE-PCC requirements addressed herein are specific to the context where the PCE is a specialized PCE that is capable of solving large- scale concurrent path computation applications. Discovery of such capabilities might be desirable and could be achieved through extensions to the PCE discovery mechanisms [PCE-DISCO], but that is out of the scope of this document. Lee, et al. Expires April 14, 2007 [Page 5] Internet-Draft PCE Global Concurrent Optimization October 2006 3. Applicability for Global Concurrent Path Computation This section discusses scenarios for which global concurrent path computation may be applied. It also discusses how these scenarios apply to the PCE architecture. 3.1. Greenfield Traffic Engineering When a new TE network needs to be provisioned from a green-field perspective, large numbers of TE LSPs need to be created based on traffic demand, network topology, service constraints, and network resources. Under this scenario, concurrent computation ability is highly desirable, or required, to utilize network resources in an optimal manner. Sequential path computation could potentially result in sub-optimal use of network resources. 3.2. Re-optimization of Existing Networks The need for global concurrent path computation may also arise in existing networks. When an existing TE LSP network experiences sub- optimal use of its resources, the need for re-optimization or reconfiguration may arise. The scope of re-optimization and reconfiguration may vary depending on particular situations. The scope of re-optimization may be limited to bandwidth modification to an existing TE LSP. However, it could well be that a large number of TE LSPs may need to be re-optimized concurrently. In an extreme case, the TE LSPs may need to be globally re-optimized. Note that sequential re-optimization of such TE LSPs is unlikely to produce substantial improvements in overall network optimization except in very sparsely utilized networks. 3.2.1. Traffic Migration When migrating from one set of TE LSPs to a reoptimized set of TE LSPs it is important that the traffic be moved without causing disruption. Various techniques exist in MPLS and GMPLS, such as make before break [RFC3209], to establish the new LSPs before tearing down the old LSPs. When multiple LSP routes are changed according to the computed results, some of LSPs may be disrupted due to the resource constraints. Make-before-break action can be considered. PCE may be able to give NMS the orders of LSP rerouting action so that make- before-break can be performed within the limited resources. However, it may be the case that the reoptimization is radical. This could mean that it is not possible to apply make before break in order to migrate from the old LSPs to the new LSPs. In this case a migration strategy is required. A PCE might indicate the order in which reoptimized LSPs must be established and take over from the old Lee, et al. Expires April 14, 2007 [Page 6] Internet-Draft PCE Global Concurrent Optimization October 2006 LSP, or the PCE might perform the global reoptimization as a series of sub-reoptimizations. 3.3. Multi-layer Traffic Engineering When an optical transport layer provides lower-layer traffic engineered LSPs for upper-layer client LSPs via the Hierarchical LSP (H-LSP) mechanism, the operator may desire to pre-establish optical LSPs in the optical transport network [MLN-REQ], this whole multilayer network can be managed using PCE [PCE-MLN]. In this scenario, it is anticipated that a large number of H-LSPs would be created concurrently in such a way as to efficiently utilize network resources in the lower-layer network. Again, concurrent path computation capability would result in more efficient network resource utilization than sequential path computation. 3.4. Reconfiguration of the Virtual Network Topology (VNT) A set of one or more of lower-layer LSPs providing information for efficient path handling in upper-layer(s) can be described as a virtual network topology (VNT)[MLN-REQ]. Reconfiguration of the VNT [MLN-REQ] is another application scenario where global concurrent path computation may be applicable. Triggers for VNT reconfiguration, such as traffic demand changes, network failures, and topological configuration changes, may require a large set of existing LSPs to be re-computed. Again, concurrent path computation capability would result in more efficient network resource utilization than sequential path computation. 3.5. The PCE Application Architecture Figure 1 shows how the aforementioned functionality applies to the PCE architecture. It must be observed that the PCC is not necessarily an LSR [RFC4655]. Although Figure 1 shows the PCE as remote from the NMS, it might be collocated with the NMS. Upon receipt of an application request (e.g., traffic demand matrix is provided to the NMS by operator's planning procedure), the NMS requests a global concurrent path computation to the PCE. The PCE would then compute the requested paths concurrently applying some algorithm(s). When the requested path computation completes, the PCE would then send the resulting paths back to the NMS. The NMS would supply the the head-end LSR with a fully computed explicit path for each TE LSP that needs to be established. Lee, et al. Expires April 14, 2007 [Page 7] Internet-Draft PCE Global Concurrent Optimization October 2006 ----------- Application | ----- | Request | | TED | | | | ----- | v | | | ------------- Request/ | v | | | Response| ----- | | NMS |<--------+> | PCE | | | | | ----- | ------------- ----------- Service | Request | v ---------- Signaling ---------- | Head-End | Protocol | Adjacent | | Node |<---------->| Node | ---------- ---------- Figure 1 Lee, et al. Expires April 14, 2007 [Page 8] Internet-Draft PCE Global Concurrent Optimization October 2006 4. PCECP Requirements This section provides the PCECP requirements in support of a large- scale concurrent path computation application. The requirements specified herein should be regarded as application-specific requirements and are justifiable based on the extensibility clause found in section 6.1.14 of [RFC4657]: The PCECP MUST support the requirements specified in the application- specific requirements documents. The PCECP MUST also allow extensions as more PCE applications will be introduced in the future. It is also to be noted that some of the requirements discussed in this section have discussed in the PCECP requirement document [RFC4657]. For example, Section 5.1.16 in [RFC4657] provides a list of generic constraints while Section 5.1.17 in [RFC4657] provides a list of generic objective functions that MUST be supported by the PCECP. While using such generic requirements as the baseline, this section provides application-specific requirements in the context of global concurrent path computation. The PCECP SHOULD support the following capabilities either via creation of new objects and/or modification of existing objects where applicable. o An indicator to convey that the request is a global concurrent path computation. This indicator is necessary to ensure consistency in applying global objectives and global constraints in all path computations. o Global Objective Function (GOF) field in which to specify the global objective function. The global objective function is the overarching objective function to which all individual path computation requests are subjected in order to find a globally optimal solution. A list of available global objective functions SHOULD include the following objective functions at the minimum and SHOULD be expandable for future addition: * Minimize the sum of all TE LSP costs (min cost) * Minimize the most utilized TE LSP (min max utilization) o Global Constraints (GC) field in which to specify the list of global constraints to which all the requested path computations should be subjected. This list SHOULD include the following constraints at the minimum and SHOULD be expandable for future addition: Lee, et al. Expires April 14, 2007 [Page 9] Internet-Draft PCE Global Concurrent Optimization October 2006 * Maximum link utilization parameter indicators for all links (Note: to avoid floating point number, indicators may be integer values that indicate maximum link utilization to which all links should be subjected. Granularity and other details are subject to further study) * Minimum link utilization parameter indicators for all links (Note: same as above) * Maximum number of hops for all the LSPs * Exclusion of links/nodes in all LSP path computation (i.e., All LSPs should not include the specified links/nodes in the path) * An indication should be available in a path computation response that further reoptimization may only become available once existing traffic has been moved to the new LSPs. * A list of existing or known TE LSPs should be kept intact without any modification, i.e. LSPs that are not subject to reoptimization computation. This capability would be useful in minimizing disruption when a global reconfiguration may need to takes place. o Global Concurrent Vector (GCV) field in which to specify all the individual path computation requests that are subject to concurrent path computation and subject to the global objective function and all of the global constraints. o An indicator field in which to indicate the outcome of the request. When the PCE could not find a feasible solution with the initial request, the reason for infeasibility SHOULD be indicated. The following indicators SHOULD be supported at the minimum: * no feasible solution found * memory overflow * PCE too busy * PCE not capable of concurrent reoptimization * no data migration path available * administrative privileges do not allow global reoptimization Lee, et al. Expires April 14, 2007 [Page 10] Internet-Draft PCE Global Concurrent Optimization October 2006 o Multi-Session Indicator field in the case where the original request is sub-divided into multiple sessions. This case may arise when the reason for infeasibility of the original request is due to mathematically infeasible, or due to memory overflow, the PCC may follow up with subsequent actions under a local policy. The PCC may decide to scale down the original request into several sessions and make requests to the PCE in several sessions. The reason for this is to find a partial feasible solution in the absence of optimal solution. * Multi-Session Indicator * The list of existing TE LSPs that should be kept without any modification. Note that this may be indicated in the aforementioned Global Constraints (GC) field. During multiple sessions of path computation, the successfully computed paths from the PCE to the PCC in a session should be indicated as the constraint (i.e., as the TE LSPs that should be kept) in the next session computation by the PCE so that the PCE may avoid double booking. If the PCE is stateless PCE, this indication is essential. Lee, et al. Expires April 14, 2007 [Page 11] Internet-Draft PCE Global Concurrent Optimization October 2006 5. Security Considerations When global re-optimization is applied to an active network, it could be extremely disruptive. Although the real security and policy issues apply at the NMS, if the wrong results are returned to the NMS, the wrong actions may be taken in the network. Therefore, it is very important that the operator issuing the commands has sufficient authority and is authenticated, and that the computation request is subject to appropriate policy. Lee, et al. Expires April 14, 2007 [Page 12] Internet-Draft PCE Global Concurrent Optimization October 2006 6. Acknowledgements We would like to thank Adrian Farrel, Jerry Ash and Lucy Yong for their useful comments and suggestions. Lee, et al. Expires April 14, 2007 [Page 13] Internet-Draft PCE Global Concurrent Optimization October 2006 7. IANA Considerations There are no IANA actions requested in this specification. Lee, et al. Expires April 14, 2007 [Page 14] Internet-Draft PCE Global Concurrent Optimization October 2006 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006. [RFC4657] Ash, J. and J. Le Roux, "Path Computation Element (PCE) Communication Protocol Generic Requirements", RFC 4657, September 2006. 8.2. Informative References [MLN-REQ] Shiomoto, K., Ed., "Requirements for GMPLS-based multi- region and multi-layer networks (MRN/MLN)", draft-ietf-ccamp-gmpls-mln-reqs, work in progress. [PCE-DISCO] Le Roux, J., "Requirements for Path Computation Element (PCE) Discovery", draft-ietf-pce-discovery-reqs, work in progress. [PCE-MLN] Oki, E., Le Roux, J., and A. Farrel, "Framework for PCE- based inter-layer MPLS and GMPL traffic engineering", draft-ietf-pce-inter-layer-frwk, work in progress. Lee, et al. Expires April 14, 2007 [Page 15] Internet-Draft PCE Global Concurrent Optimization October 2006 Authors' Addresses Young Lee Huawei Technologies (USA) 1700 Alma Drive, Suite 100 Plano, TX 75075 US Phone: +1 972 509 5599 x2240 Fax: +1 469 229 5397 Email: ylee@huawei.com Daniel King Aria Networks 44/45 Market Place Chippenham SN15 3HU United Kingdom Phone: +44 7790 775187 Fax: +44 1249 446530 Email: daniel.king@aria-networks.com Eiji Oki NTT Midori 3-9-11 Musashino, Tokyo 180-8585 JAPAN Email: oki.eiji@lab.ntt.co.jp Lee, et al. Expires April 14, 2007 [Page 16] Internet-Draft PCE Global Concurrent Optimization October 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). 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 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 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Lee, et al. Expires April 14, 2007 [Page 17]