Network Working Group Y. Lee Internet-Draft Huawei Intended status: Standards Track JL. Le Roux Expires: August 2, 2007 France Telecom D. King Aria Networks E. Oki NTT January 29, 2007 Path Computation Element Communication Protocol (PCECP) Requirements and Protocol Extensions In Support of Global Concurrent Optimization draft-lee-pce-global-concurrent-optimization-01.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 August 2, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Lee, et al. Expires August 2, 2007 [Page 1] Internet-Draft PCE Global Concurrent Optimization January 2007 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 (PCEP) is specified for communications between PCCs and PCEs, and between cooperating PCEs. When computing or re-optimizing the routes of a set of LSPs through a network it may be advantageous to perform bulk path computations in order to avoid blocking problems and to achieve more optimal network- wide solutions. Such bulk optimization is termed Global Concurrent Optimization. This document provides application-specific requirements and the PCEP extensions in support of a global concurrent path computation application. Lee, et al. Expires August 2, 2007 [Page 2] Internet-Draft PCE Global Concurrent Optimization January 2007 Table of Contents 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Applicability of Global Concurrent Path Computation . . . . . 7 3.1. Greenfield Optimization . . . . . . . . . . . . . . . . . 7 3.1.1. Single-layer Traffic Engineering . . . . . . . . . . . 7 3.1.2. Multi-layer Traffic Engineering . . . . . . . . . . . 8 3.2. Re-optimization of Existing Networks . . . . . . . . . . . 8 3.2.1. Reconfiguration of the Virtual Network Topology (VNT) . . . . . . . . . . . . . . . . . . . . . . . . 8 3.2.2. Traffic Migration . . . . . . . . . . . . . . . . . . 8 3.3. Application of the PCE Architecture . . . . . . . . . . . 9 4. PCECP Requirements . . . . . . . . . . . . . . . . . . . . . . 11 5. Protocol extensions for support of global concurrent optimization . . . . . . . . . . . . . . . . . . . . . . . . . 15 5.1. Global Concurrent Optimization Indication . . . . . . . . 16 5.2. Global Objective Function (GOF) Specification . . . . . . 16 5.3. Indication of Global Concurrent Requests . . . . . . . . . 17 5.4. Request for the order of LSP . . . . . . . . . . . . . . . 17 5.5. The Order Response . . . . . . . . . . . . . . . . . . . . 18 5.6. Global Constraints (GC) Object . . . . . . . . . . . . . . 20 5.7. Multi-Session Processing . . . . . . . . . . . . . . . . . 21 5.8. Error Indicator . . . . . . . . . . . . . . . . . . . . . 23 5.9. NO-PATH Indicator . . . . . . . . . . . . . . . . . . . . 23 6. Manageability Considerations . . . . . . . . . . . . . . . . . 25 6.1. Control of Function and Policy . . . . . . . . . . . . . . 25 6.2. Information and Data Models, e.g. MIB module . . . . . . . 25 6.3. Liveness Detection and Monitoring . . . . . . . . . . . . 25 6.4. Verifying Correct Operation . . . . . . . . . . . . . . . 25 6.5. Requirements on Other Protocols and Functional Components . . . . . . . . . . . . . . . . . . . . . . . . 25 6.6. Impact on Network Operation . . . . . . . . . . . . . . . 25 6.7. Other Considerations . . . . . . . . . . . . . . . . . . . 25 7. Security Considerations . . . . . . . . . . . . . . . . . . . 26 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 10.1. Normative References . . . . . . . . . . . . . . . . . . . 29 10.2. Informative References . . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 Intellectual Property and Copyright Statements . . . . . . . . . . 31 Lee, et al. Expires August 2, 2007 [Page 3] Internet-Draft PCE Global Concurrent Optimization January 2007 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 Communication Protocol: PCECP is the generic abstract idea of a 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. PCEP: The PCE communication Protocol: PCEP is the actual protocol that implements the PCECP idea. 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]. These terms are also used in the parts of this document that specify requirements for clarity of specification of those requirements. Lee, et al. Expires August 2, 2007 [Page 4] Internet-Draft PCE Global Concurrent Optimization January 2007 2. Introduction [RFC4655] defines the PCE based 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 System (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 communication 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 a set of PCECP extension requirements and solutions in support of concurrent path computation applications that may arise during network operations. A concurrent path computation is a path computation application where a set of TE paths are computed concurrently in order to efficiently utilize network resources. The computation method involved with a 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 the 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 global concurrent path computation is 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. Alternatively, the application may consider a subset of the LSPs and/or a subset of the network topology. The need for a gloabl concurrent path computation may also arise when network operators need to set up a large number of TE LSPs in their network planning process. A global concurrent path computation is typically an off-line computation. This document does not exclude the possibility that network operators might require on-line computation for a global concurrent path computation in the event of catastrophic network failures, where a set of TE LSPs need to be optimally rerouted in real-time. The off-line computation requirements to support a set of TE LSPs are quite different from on-line path computation requirements. While Lee, et al. Expires August 2, 2007 [Page 5] Internet-Draft PCE Global Concurrent Optimization January 2007 on-line path computation is focused on finding a single best path in a timely manner given the prevailing network conditions, an off-line path computation application involves finding paths for a set 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 off-line computation is to efficiently allocate network resources from a global network perspective. While on-line path computation is tactical, off-line 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 global concurrent path computation needs. The main focus of this document is to highlight the PCC-PCE communication needs in support of a concurrent path computation application and to define protocol extensions to meet those needs. The PCC-PCE requirements addressed herein are specific to the context where the PCE is a specialized PCE that is capable of solving global concurrent path computation applications. Discovery of such capabilities might be desirable and could be achieved through extensions to the PCE discovery mechanisms [RFC4674], but that is out of the scope of this document. Lee, et al. Expires August 2, 2007 [Page 6] Internet-Draft PCE Global Concurrent Optimization January 2007 3. Applicability of 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 Optimization When a new TE network needs to be provisioned from a green-field perspective, a set 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 and avoid blocking risks. Sequential path computation could potentially result in sub-optimal use of network resources or even blocking issues. 3.1.1. Single-layer Traffic Engineering Greenfield optimization can be applied when layer-specific TE LSPs need to be created from a green-field perspective. For example, MPLS-TE network can be established based on layer 3 specific traffic demand, network topology, and network resources. Greenfield optimization for single-layer traffic engineering can be applied to lower layer networks such as SDH/Sonet, Ethernet Transport, WDM, etc. 3.1.1.1. Pre-establishment of the Hierarchical-LSP (H-LSP)in the Transport Network 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 multi- layer network can be managed using PCE [PCE-MLN]. In this scenario, it is anticipated that a set 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.1.1.2. VNT Configuration 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]. When the VNT [MLN-REQ] is configured for the first time, greenfield concurrent optimization may well be applied to find a set of LSPs Lee, et al. Expires August 2, 2007 [Page 7] Internet-Draft PCE Global Concurrent Optimization January 2007 more efficiently than sequential path computation. 3.1.2. Multi-layer Traffic Engineering Greenfield optimization is not limited to single-layer traffic engineering. It can also be applied in multi-layer traffic engineering. Both the client and the server layers network resources and topology can be considered simultaneously in setting up a set of TE LSPs that traverse the layer boundary. 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. Reconfiguration of the Virtual Network Topology (VNT) 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.2.2. 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 the LSPs may be disrupted due to the resource constraints. In other words, it may prove to be impossible to perform a direct migration from the old LSPs to the new optimal LSPs without disrupting traffic because there are insufficient network resources to support both sets of LSPs when make-before-break is used. However, the PCE may be able determine an order of LSP Lee, et al. Expires August 2, 2007 [Page 8] Internet-Draft PCE Global Concurrent Optimization January 2007 rerouting actions 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 any order to migrate from the old LSPs to the new LSPs. In this case a migration strategy is required that may necessitate LSPs being rerouted using make-before-break onto temporary paths in order to make space for the full reoptimization. A PCE might indicate the order in which reoptimized LSPs must be established and take over from the old LSPs, and may indicate a series of different temporary paths that must be used. Alternatively, the PCE might perform the global reoptimization as a series of sub-reoptimizations by reoptimizing subsets of the total set of LSPs. Note also that during reoptimization, traffic disruption may be allowed for some LSPs carrying low priority services (e.g., Internet traffic) and not allowed for some LSPs carrying mission critical services (e.g., voice traffic). 3.3. Application of the PCE Architecture Figure 1 shows how the aforementioned functionality applies within 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., a traffic demand matrix is provided to the NMS by the operator's network planning procedure), the NMS requests a global concurrent path computation from the PCE. The PCE then computes the requested paths concurrently applying some algorithms. When the requested path computation completes, the PCE sends the resulting paths back to the NMS. The NMS then supplies the head-end LSRs with a fully computed explicit path for each TE LSP that needs to be established. Lee, et al. Expires August 2, 2007 [Page 9] Internet-Draft PCE Global Concurrent Optimization January 2007 ----------- Application | ----- | Request | | TED | | | | ----- | v | | | ------------- Request/ | v | | | Response| ----- | | NMS |<--------+> | PCE | | | | | ----- | ------------- ----------- Service | Request | v ---------- Signaling ---------- | Head-End | Protocol | Adjacent | | Node |<---------->| Node | ---------- ---------- Figure 1: PCE-Based Architecture for Global Concurrent Optimization Lee, et al. Expires August 2, 2007 [Page 10] Internet-Draft PCE Global Concurrent Optimization January 2007 4. PCECP Requirements This section provides the PCECP requirements to support large-scale concurrent path computation applications. The requirements specified here 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 already been 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 and in a more detail level than the generic requirements. The PCEP 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 for a global concurrent path computation. This indicator is necessary to ensure consistency in applying global objectives and global constraints in all path computations. Note: This requirement is covered by "synchronized path computation" in [RFC4655] and [RFC4657]. However, an explicit indicator to request a global concurrent optimization is a new requirement. o A 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. Note that this requirement is covered by "synchronized objective functions" in section 5.1.7 [RFC4657]. 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) Lee, et al. Expires August 2, 2007 [Page 11] Internet-Draft PCE Global Concurrent Optimization January 2007 * Maximize the residual bandwidth on the most loaded link * Evenly allocate the network load to achieve the most uniform link utilization across all links (this can be achieved by the following objective function: minimize max over all links {(C(i)-A(i))/C(i)} where C(i) is the link capacity for link i and A(i) is the total bandwidth allocated on link i. o A 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: * Maximum link utilization value -- This value indicates the highest possible link utilization percentage set for each link. (Note: to avoid floating point numbers, the values should be integer values.) * Minimum link utilization value -- This value indicates the lowest possible link utilization percentage set for each link. (Note: same as above) * Overbooking Factor -- The overbooking factor allows the reserved bandwidth to be overbooked on each link beyond its physical capacity limit. * Maximum number of hops for all the LSPs -- This is the largest number of hops that any LSP can have. Note that this constraint can also be provided on a per LSP basis (as requested in [RFC4657] and defined in [PCEP]). * Exclusion of links/nodes in all LSP path computation (i.e., all LSPs should not include the specified links/nodes in their paths). Note that this constraint can also be provided on a per LSP basis (as requested in [RFC4657] and defined in [PCEP]). * 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. o A 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. Note that this requirement is partially fulfilled by the SVEC object in the PCEP specification [PCEP]. Since the SVEC object as defined in [PCEP] Lee, et al. Expires August 2, 2007 [Page 12] Internet-Draft PCE Global Concurrent Optimization January 2007 allows identifying a set of concurrent path requests, the SVEC can be reused to specify all the individual concurrent path requests for a global concurrent optimization. This can be achieved by defining a new flag in the SVEC object to indicate that this is a global concurrent optimization. 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 failure SHOULD be indicated. This requirement is partially covered by [RFC4657], but not in this level of detail. The following indicators SHOULD be supported at the minimum: * no feasible solution found. Note that this is already covered in [PCEP]. * memory overflow * PCE too busy. Note that this is already covered in [PCEP]. * PCE not capable of concurrent reoptimization * no migration path available * administrative privileges do not allow global reoptimization o A 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 failure of the original request is due to mathematical infeasibility, or memory overflow. The PCC may follow up with subsequent actions under a local policy. The motivation for multi-session application is to find a partial feasible solution in the absence of the optimal solution. When the PCC decides to scale down the original request into several sessions, the PCC sends the first session path computation request to the PCE. The next session path computation request is held until the results from the first session would be available. Once the results from the first session are available, the PCC then sends the second session path computation request to the PCE. The same procedure is repeated until the last session of the multiple session has been completed. To support this requirement, it is required that the PCE keep in memory the previously computed paths until all paths of the multi-session have been computed. * Multi-Session Indicator * Multi-Session Sequence Number Lee, et al. Expires August 2, 2007 [Page 13] Internet-Draft PCE Global Concurrent Optimization January 2007 * The Indication of the Final Session o In order to minimize disruption associated with bulk path provisioning, the following requirements MUST be supported: * The request message MUST allow requesting the PCE to provide the order in which LSPs should be reoptimized (i.e., the migration path) in order to minimize traffic disruption during the migration. That is the request message MUST allow indicating the PCE that the set of paths that will be provided in the response message (PCRep) has to be ordered. * In response to the "ordering" request from the PCC, the PCE MUST be able to indicate in the response message (PCRep) the order in which LSPs should be reoptimized so as to minimize traffic disruption. It should indicate for each request the order in which the old LSP should be removed and the order in which the new LSP should be setup. If the removal order is lower than the setup order this means that make-before-break cannot be done for this request. * As stated in RFC 4657, the request for a reoptimization MUST support the inclusion of the set of previously computed paths along with their bandwidth. This is to avoid double bandwidth accounting and also this allows running an algorithm that minimizes perturbation and that can compute a migration path (LSP setup/removal orders). This is particularly required for stateless PCEs. * During a migration it may not be possible to do a make-before- break for all existing LSPs. The request message must allow indicating for each request whether make-before-break is required (e.g. Voice traffic) or break-before-make is acceptable (e.g. Internet traffic). The response message must allow indicating LSPs for which make-before-break reoptimization is not possible (this will be deduced from the LSP setup and deletion orders). * During a reoptimization it may be required to move a LSP several times so as to avoid traffic disruption. The response message must allow indicating the path sequence for each request. Lee, et al. Expires August 2, 2007 [Page 14] Internet-Draft PCE Global Concurrent Optimization January 2007 5. Protocol extensions for support of global concurrent optimization This section provides protocol extensions for support of global concurrent optimization. Protocol extensions discussed in this section are built on [PCEP]. The format of a PCReq message is currently as follows per [PCEP]: ::= [] where: ::= [] ::= [] ::= [] [] [] [] [] [] [] The format of a PCReq message after incorporating new requirements for support of global concurrent optimization is as follows: ::= [] The is changed as follows: :: = [] [] [] [] Note that in the SVEC-list two new optional objects have been defined: the GOF (Global Objective Function) Object and the GC (Global Constraints) Object. Note also that the XRO is also added as an optional Object in the list. Details of this change will be discussed in the following sections. Lee, et al. Expires August 2, 2007 [Page 15] Internet-Draft PCE Global Concurrent Optimization January 2007 5.1. Global Concurrent Optimization Indication A global concurrent path computation request from other types of computation request can be implicitly indicated by the presence of the GOF object in the new SVEC-list as defined in the previous section. That is when the SVEC-list includes the GOF object, it indicates a request for global concurrent optimization. It can also be explicitly indicated by the C flag in the SVEC object. 5.2. Global Objective Function (GOF) Specification The global objective function can be specified in the GOF object. The format of the GOF object body that includes the global objective function is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Objective Function ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: GOF body object format The Objective Function ID (16 bit) identifies the objective function for global concurrent request. Currently three global objective functions are identified. Other objective functions may be defined later. 1: Minimize the sum of all TE LSP costs (min cost) 2: Maximize the residual bandwidth on the most loaded link 3: Evenly allocate the network load to achieve the most uniform link utilization across all links (this can be achieved by the following objective function: minimize max over all links {(C(i)- A(i))/C(i)} where C(i) is the link capacity for link i and A(i) is the total bandwidth allocated on link i. GOF Object-Class is to be assigned by IANA. GOF Object-Type is to be assigned by IANA. Lee, et al. Expires August 2, 2007 [Page 16] Internet-Draft PCE Global Concurrent Optimization January 2007 5.3. Indication of Global Concurrent Requests All the path requests in this application should be indicated so that the global objective function and all of the global constraints are applied to each of the requested path computation. In order to support this requirement, the SVEC object should be modified as follows. C flag (1 bit): This is a new flag in the SVEC object. When C flag is set, this indicates that all of the path request listed in the body of the SVEC object should be computed applying the global constraints and the global objective function. When the C Flag is set in the SVEC Object, the GOF and the GC objects should directly follow the SVEC Object. Therefore, the format of the PCReq is modified as follows: ::= [] The is changed as follows: ::= [] [] [] [] 5.4. Request for the order of LSP In order to minimize disruption associated with bulk path provisioning, the PCC MAY indicate to the PCE that the response MUST be ordered. That is, it MUST include the order in which LSPs MUST be moved so as to minimize traffic disruption. Such indication can be included in the RP object which is revised as follows: Lee, et al. Expires August 2, 2007 [Page 17] Internet-Draft PCE Global Concurrent Optimization January 2007 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Flags |D|M|F|O|B|R| Pri | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Request-ID-number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // Optional TLV(s) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: RP object body format in the PCReq Message D bit (orDer - 1 bit): when set, in a PCReq message, the requesting PCC requires the PCE to specify in the PCRep message the order in which this particular path request is to be provisioned relative to other requests. M bit (Make-before-break - 1 bit): when set, this indicates that a make-before-break reoptimization is required for this request. When M bit is not set, this implies that this request is allowed to a break-before-make reoptimization. Note that M bit can be set only if the R and D flags are set. All other fields are unchanged from [PCEP]. 5.5. The Order Response The PCE MUST specify the order number in response to the Order Request made by the PCC in the PCReq message if so requested by the setting of the D bit in the RP object in the PCReq message. The format of the RP object body to be included in the PCRep message is modified as follows: Lee, et al. Expires August 2, 2007 [Page 18] Internet-Draft PCE Global Concurrent Optimization January 2007 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Flags |D|M|F|O|B|R| Pri | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Request-ID-number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // Order TLV (Optional TLV) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7: RP object body format in the PCRep Message The Order TLV is an optional TLV in the RP object, that indicates the order in which the old LSP must be removed and the new LSP must be setup during a reoptimization. It is carried in the PCRep message in response to a reoptimization request. The Order TLV SHOULD be included in the RP object in the PCRep message if the D bit is set in the RP object in the PCReq message. The format of the Order TLV is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Delete Order | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Setup Order | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type To be defined by IANA (suggested value = ) Length Variable Value Orders in which the old path should be removed and the new path should be setup Figure 8: The Order TLV in the RP object in the PCRep Message Delete Order: 32 bit integer that indicates the order in which the old LSP should be removed Lee, et al. Expires August 2, 2007 [Page 19] Internet-Draft PCE Global Concurrent Optimization January 2007 Setup Order: 32 bit integer that indicates the order in which the new LSP should be setup The delete order should not be equal to the setup order. If the delete order is higher than the setup order, this means that the reoptimization can be done in a make-before-break manner, else it cannot be done in a make-before-break manner. To illustrate, consider a network with two established requests: R1 with path P1 and R2 with path P2. During a reoptimization the PCE may provide the following ordered reply: R1, path P1', remove order 1, setup order 4 R2, path P2', remove order 3, setup order 2 This indicates that the NMS should do the following sequence of tasks: 1: Remove path P1 2: Setup path P2' 3: Remove path P2 4: Setup path P1' That is, R1 is reoptimized in a break-before-make manner and R2 in a make-before-break manner. 5.6. Global Constraints (GC) Object The Global Constraints (GC) Object is used in a PCReq message to specify the necessary global constraints that should be applied to all individual path computations for a global concurrent path optimization request. The format of the GC object body that includes the global constraints is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MU | mU | OB | MH | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // Optional TLV(s) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Lee, et al. Expires August 2, 2007 [Page 20] Internet-Draft PCE Global Concurrent Optimization January 2007 Figure 11: GC body object format MU (Max Utilization) (8 bits) : 8 bit integer that indicates the upper bound utilization percentage by which all link should be bound. Utilization = (Link Capacity - Allocated Bandwidth on the Link)/ Link Capacity mU (minimum Utilization) (8 bits) : 8 bit integer that indicates the lower bound utilization percentage by which all link should be bound. OB (Over Booking factor) (8 bits) : 8 bit integer that indicates the overbooking percentage that allows the reserved bandwidth to be overbooked on each link beyond its physical capacity limit. The value, for example, 10% means that 110 Mbps can be reserved on a 100Mbps link. MH (Max Hop) (8 bits): 8 bit integer that indicates the maximum hop count for all the LSPs. GC Object-Class is to be assigned by IANA. GC Object-Type is to be assigned by IANA. The exclusion of the list of nodes/links from a global path computation can be done by including the XRO object following the GC object in the new SVEC definition. 5.7. Multi-Session Processing When the initial global concurrent path computation request fails due to scaling issues or memory overflow as indicated in the PCEP-ERROR object in the PCRep message, multi-session processing may be proceeded in an attempt to find a feasible solution in the absence of an optimal solution. This should be driven by local policy decision. How to divide up the original global concurrent optimization problem into a number of smaller-scale optimization problems is out of the scope of this document. In order to meet these multi-session requirements, a new object, the Multi-Session (MS) object is required. This object should be defined on a per message basis. The message is modified as follows: ::= [] [] Lee, et al. Expires August 2, 2007 [Page 21] Internet-Draft PCE Global Concurrent Optimization January 2007 The format of the MSO object is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |F| Reserved | Multi-Session ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 13: MSO object body format Multi-Session ID (16 bits): 16 bit integer that identifies the multi- session computation. The Multi-Session ID will allow to map all request messages for the same global computation. Sequence Number (16 bits): 16 bit integer that indicates the sequence number of the current multi-session request. This should be incremented for each new request message during a multi-session request until the final request is performed. F (Final session - 1 bit): When set, the requesting PCC indicates that the PCReq message is the final session of a multi-session request. When it is not set, the PCE SHOULD keep in memory all the computed paths until the final session of a multi-session is completed. This is necessary to correctly account for already computed LSPs. MS Object-Class is to be assigned by IANA. MS Object-Type is to be assigned by IANA. For PCE not able to temporarily maintain previously computed paths, the multi-session capability can be provided by simply adding the ERO object and the Bandwidth object following the RP object in the PCReq message. The ERO and the Bandwidth objects together provide all of the previously computed paths by the PCE. In order to distinguish a previously computed request from a new request, a new flag in the RP object is required. A (Already computed request - 1 bit): When set, this indicates that the request has already been computed in a previous session, and its result (as indicated by the ERO and the Bandwidth Object following Lee, et al. Expires August 2, 2007 [Page 22] Internet-Draft PCE Global Concurrent Optimization January 2007 the RP object) must be taken account in the current session. 5.8. Error Indicator To indicate errors associated with the global concurrent path optimization request, a new Error-Type (11) and subsequent error- values are defined as follows for inclusion in the PCEP-ERROR object: A new Error-Type (11) and subsequent error-values are defined as follows: Error-Type=14 and Error-Value=1: if a PCE receives a global concurrent path optimization request and the PCE is not capable of the request due to insufficient memory, the PCE MUST send a PCErr message with a PCEP ERROR object (Error-Type=14) and an Error-Value (Error-Value=1). The corresponding global concurrent path optimization request MUST be cancelled. Error-Type=14; Error-Value=2: if a PCE receives a global concurrent path optimization request and the PCE is not capable of global concurrent optimization, the PCE MUST send a PCErr message with a PCEP-ERROR Object (Error-Type=14) and an Error-Value (Error-Value=2). The corresponding global concurrent path optimization MUST be cancelled. Error-Type=14; Error-Value=3: if a PCE receives a global concurrent path optimization request which is not compliant with administrative privileges (i.e., the PCE policy does not support global concurrent optimization), the PCE send a PCErr message with a PCEP-ERROR Object (Error-Type=14) and an Error-Value (Error-Value=3). The corresponding global concurrent path computation MUST be cancelled. 5.9. NO-PATH Indicator To communicate the reason(s) for not being able to find global concurrent path computation, the NO-PATH object can be used in the PCRep message. The format of the NO-PATH object body is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |C|G|M| Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // Optional TLV(s) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Lee, et al. Expires August 2, 2007 [Page 23] Internet-Draft PCE Global Concurrent Optimization January 2007 Figure 14: NO-PATH object format Flags (16 bits). The C flag is defined in [PCEP]. Two additional flags are defined to support other reasons why the path computation fails: G flag (1 bit) and M flag (1 bit). M flag (1 bit): when set, the PCE indicates that no migration path was found. G flag (1 bit): when set, the PCE indicates no feasible solution was found that meets all the constraints associated with global concurrent path optimization in the PCRep message. When either M or G flag is set in the PCRep Message, a subsequent multi-session feature may be triggered if the PCC's local policy allows it. The multi-session feature allows the original global concurrent optimization to be split into a number of multiple sessions so that the PCE would compute a number of smaller-scale optimizations in a sequential manner. The trade-off is that a partial feasible solution may be obtained using this approach which is better than not having any solution at all, although such solution might not be a global optimal solution. How to divide up the original large-scale global concurrent optimization into a multiple number of smaller-scale optimizations is out of the scope of this document. See Section 5.7 for multi-session processing details. Lee, et al. Expires August 2, 2007 [Page 24] Internet-Draft PCE Global Concurrent Optimization January 2007 6. Manageability Considerations Manageability of Global Concurrent Path Computation with PCE must address the following considerations: 6.1. Control of Function and Policy This sub-section will describe the configurable items that exist for the control of global concurrent optimization functions or policies. 6.2. Information and Data Models, e.g. MIB module This sub-section will describe the information and data models necessary for the protocol or the protocol extensions. This includes, but is not necessarily limited to, the MIB modules developed specifically for the protocol functions specified in the document. 6.3. Liveness Detection and Monitoring This sub-section will describe liveness detection and monitoring requirements for both the control plane and the data plane. 6.4. Verifying Correct Operation This sub-section will describe Operations and Management (OAM) features and functions for verifying the correct operation. 6.5. Requirements on Other Protocols and Functional Components This sub-section will describe requirements or refer to the sections that discuss the impact of global concurrent optimization on existing protocols. 6.6. Impact on Network Operation This sub-section will discuss the impact on the operation of existing networks. 6.7. Other Considerations This sub-section will cover those manageability requirements not specifically in previous sub-sections. Lee, et al. Expires August 2, 2007 [Page 25] Internet-Draft PCE Global Concurrent Optimization January 2007 7. 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. The mechanisms defined in [PCEP] to secure a PCEP session (MD-5 authentication, etc.) apply here as well. Lee, et al. Expires August 2, 2007 [Page 26] Internet-Draft PCE Global Concurrent Optimization January 2007 8. Acknowledgements We would like to thank Jerry Ash, Adrian Farrel, Ning So and Lucy Yong for their useful comments and suggestions. Lee, et al. Expires August 2, 2007 [Page 27] Internet-Draft PCE Global Concurrent Optimization January 2007 9. IANA Considerations A future revision of this document will present requests to IANA for codepoint allocation. Lee, et al. Expires August 2, 2007 [Page 28] Internet-Draft PCE Global Concurrent Optimization January 2007 10. References 10.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. 10.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-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.". [PCEP] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation Element (PCE) communication Protocol (PCEP) - Version 1, draft-ietf-pce-pcep-04.txt, work in progress". [RFC4674] Le Roux, J., "Requirements for Path Computation Element (PCE) Discovery, draft-ietf-pce-discovery-reqs, work in progress.". Lee, et al. Expires August 2, 2007 [Page 29] Internet-Draft PCE Global Concurrent Optimization January 2007 Authors' Addresses Young Lee Huawei 1700 Alma Drive, Suite 100 Plano, TX 75075 US Phone: +1 972 509 5599 x2240 Fax: +1 469 229 5397 Email: ylee@huawei.com JL Le Roux France Telecom 2, Avenue Pierre-Marzin Lannion 22307 FRANCE Email: jeanlouis.leroux@orange-ftgroup.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 August 2, 2007 [Page 30] Internet-Draft PCE Global Concurrent Optimization January 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 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 August 2, 2007 [Page 31]