Network Working Group Fatai Zhang Internet-Draft Xian Zhang Intended status: Informational Young Lee Huawei Ramon Casellas CTTC Oscar Gonzalez de Dios Telefonica I+D Expires: April 17, 2013 October 18, 2012 Applicability of Stateful Path Computation Element (PCE) draft-zhang-pce-stateful-pce-app-02.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and 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 17, 2013. Abstract Zhang Expires January 2013 [Page 1] draft-zhang-pce-stateful-pce-app-02.txt October 2012 The Path Computation Element (PCE) provides a solution for Traffic Engineering (TE) based path calculation in large, multi-domain, multi-region, or multi-layer networks. Depending on whether a PCE keeps information about LSPs and reserved resource usage in the network or not, it can be categorized as either stateful or stateless. This memo describes general considerations for stateful PCE(s) and examines its applicability through a number of typical scenarios. It shows how stateful PCE(s) can be applied to facilitate these applications. PCEP extensions required for stateful PCE usage are covered in separate document(s). 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 RFC-2119 [RFC2119]. Table of Contents Table of Contents .............................................. 2 1. Introduction ................................................ 3 2. General Considerations....................................... 5 2.1. Architectural Considerations............................ 5 2.2. LSP State Synchronization............................... 5 2.2.1. Single Domain...................................... 6 2.2.2. Multi-domain....................................... 6 2.2.3. Multi-layer........................................ 8 2.3. PCE Survivability/Reliability........................... 8 2.4. Delegation and Policy................................... 9 2.4.1. Use of Under-construction LSPs Information......... 9 3. Application Scenarios....................................... 11 3.1. Impairment-Aware Routing and Wavelength Assignment (IA-RWA) ........................................................... 11 3.2. Defragmentation in Flexible Grid Networks ..............12 3.3. Recovery .............................................. 13 3.3.1. Protection........................................ 13 3.3.2. Restoration....................................... 14 3.4. SRLG Diversity ........................................ 15 3.5. Maintenance of Virtual Network Topology (VNT).......... 15 3.6. Global Concurrent Optimization (GCO)................... 16 3.7. Point-to-Multipoint (P2MP) Application................. 16 3.8. Time-based Scheduling.................................. 17 4. Manageability Considerations................................ 17 Zhang Expires April 2013 [Page 2] draft-zhang-pce-stateful-pce-app-02.txt October 2012 4.1. Information and Data Models............................ 18 5. Security Considerations..................................... 18 6. References ................................................. 18 6.1. Normative References................................... 18 6.2. Informative References................................. 18 7. Contributors' Address....................................... 20 Authors' Addresses ............................................ 21 1. Introduction [RFC 4655] defines the architecture for a Path Computation Element (PCE)-based model for the computation of Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering Label Switched Paths (TE LSPs). To perform such a constrained computation, a PCE stores the network topology (i.e., TE links and nodes) and resource information (i.e., TE attributes) in its TE Database (TED). To request path computation services to a PCE, [RFC 5440] defines the PCE Communication Protocol (PCEP) for communications between a Path Computation Client (PCC) and a PCE, or between two PCEs. A PCC can initiate a path computation request to a PCE through a Path Computation Request (PCReq) message, and then the PCE will return the computed path to the requesting PCC in response to a previously received PCReq message through a PCEP Path Computation Reply (PCRep) message. As per [RFC 4655], a PCE can be either stateful or stateless. Compared to a stateless PCE, a stateful PCE stores not only the network states, but also the set of computed paths and reserved resources in use in the network. In other words, the ''state'' in a stateful PCE is determined not only by the TED but also by the set of active LSPs and their corresponding reserved resources. Furthermore, a stateful PCE might also retain the information of LSPs under construction in order to reduce resource contention. Such augmented state allows the PCE to compute constrained paths while considering individual LSPs and their interaction. Note that [RFC4655] further specifies that the TED contains link state and bandwidth availability as distributed by the IGPs or collected via other methods. Even if such information can provide increased granularity and more detail, it is not state information in the PCE context and so a model that uses it is still described as a stateless PCE. PCE capability is specified for both MPLS and GMPLS networks [RFC4655]. Although initial efforts only covers MPLS in [RFC5440], [RFc5441] PCEP extension in support of GMPLS is currently being standardized [PCEP-GMPLS]. Therefore, stateful extension of PCE Zhang Expires April 2013 [Page 3] draft-zhang-pce-stateful-pce-app-02.txt October 2012 should also cover both types of networks. For example, transport networks, such as SDH, OTN and WDM, should be able to take advantage of stateful PCE ability for a variety of purposes, such as traffic optimization. As described in section 6.8 of [RFC 4655], there are many applications which can benefit from stateful PCE(s), e.g.: o Minimum perturbation: stateful PCE(s) can minimize the number of existing TE LSPs that are affected and preempted by a higher- priority TE LSP request in a crowded network. o Virtual Network Topology (VNT) maintenance: the information of existing LSPs in the higher layer is used as an input for setting up/tearing down the LSPs in the lower layer (i.e., VNT modification). Besides these scenarios, there are some additional scenarios that should be investigated further, especially for GMPLS networks. For instance, in impairment-aware Wavelength Switched Optical Networks (WSON) [WSON-Impairment], stateful PCEs could be used to perform Impairment-Aware Routing and Wavelength Assignment (IA-RWA) procedures. In this case, PCE(s) need to know the detailed information of the existing LSPs so that the new LSP(s) will not impact them. Such PCE(s) would maintain the existing LSPs states (e.g., route, wavelength and speed) to perform impairment aware RWA procedures simpler and with less protocol overhead. [RFC 4655] also discusses potential scalability and synchronization issues in order to implement stateful PCE(s). The main problem pointed out by [RFC 4655] is that a PCE would be constrained if the states of all the TE LSPs in a network are to be maintained by a PCE. Moreover, such state, when there are multiple PCEs, needs to be properly synchronized. These issues are especially relevant in packet networks, such as MPLS-TE networks, given a potentially large number of LSPs. Nonetheless, it is expected that in transport networks, such as OTN networks, the number of the LSPs will be much smaller, which makes stateful PCEs more applicable. Finally, with the increasing power and memory of the hardware platforms that a PCE may run, the number of LSPs that can be managed by a PCE is significantly large. Hence, there is lesser scaling issue for a PCE to store all the LSPs' states, especially for a transport network. This document presents general considerations for stateful PCE(s) and several examples of its application scenarios. It exhibits the utility of stateful PCE(s) in effective support of these applications to obtain better performance. Protocol specific extensions are covered in separate documents [stateful-PCEP-mpls], [stateful-PCE-gmpls]. Zhang Expires April 2013 [Page 4] draft-zhang-pce-stateful-pce-app-02.txt October 2012 2. General Considerations 2.1. Architectural Considerations Several PCE architectures are described in Section 5 of [RFC4655]. A stateful PCE needs to maintain a large amount of data and potentially incur in a very high amount of control plane overhead. Moreover, there might be high computational demands on stateful PCE entities to effectively support the applications listed in Section 3. Therefore, the composite PCE architecture is NOT RECOMMENDED to support stateful PCEs. It does not exclude the possibility that multiple PCEs with different capabilities are included in the network. For example, both stateless and stateful PCEs can co-exist to be in charge of path computation of different types. In all cases, the stateful capability of PCE should be made known within the domain. 2.2. LSP State Synchronization As suggested by the definition, a stateful PCE maintains two databases for path computation. The first one is the Traffic Engineering Database (TED) which includes the topology and resource in the network. TED can be obtained through participating in routing distribution of TE information or other means as explained in Section 6.7 of [RFC4655]. The other database is the LSP state Database (LSP-DB), in which a PCE stores attributes of all existing LSPs in the network, such as payload signal, switching types and bandwidth/resource usage etc. In order for PCE to support GMPLS control plane, [RFC5440] needs extensions with regard to the features of GMPLS networks. Similarly, for LSP state synchronization, the attributes of LSP pertaining to GMPLS should be captured in PCECP extensions. A stateful PCE should gather the LSP information either from the network management system (NMS) or from the nodes in the network. For a NMS-based PCE, if the PCE is not co-located with the NMS, a standard communication protocol is needed for LSP state synchronization; otherwise, proprietary APIs can be used. If a PCE relies on network nodes for state synchronization, the strategies may vary depending on the network scenarios in which the PCE is applied to (i.e., single domain, multiple domain or multi-layer networks.) as well as the adoption of PCE computation model. Zhang Expires April 2013 [Page 5] draft-zhang-pce-stateful-pce-app-02.txt October 2012 2.2.1. Single Domain In a single domain network, LSP state information is maintained locally by the nodes initiating LSP(s). Therefore, PCE(s) should gather the LSP state information either passively or actively from the nodes in the network they have visibility. With a centralized stateful PCE computation model, it is straightforward that all nodes in the domain could communicate with the PCE for its LSP-DB synchronization. As for distributed stateful PCE computation model (i.e., there are multiple stateful PCEs in the network), there are several alternatives for synchronization: o Every node can update the PCE LSP-DBs by sending the LSP state information to each of the PCEs in the network separately. o Another feasible strategy is to choose one of the PCEs (i.e., a designated PCE) for synchronization with all the nodes in the network and the designated PCE also updates the LSP-DBs of all the other PCE(s). o A mixed of these two methods listed above can also be considered in which more than one PCEs (e.g., two PCEs) are chosen to interact directly with nodes in the network for state synchronization while other PCEs are updated via these PCEs. 2.2.2. Multi-domain In a multi-domain network with a centralized PCE model, the LSP state synchronization is similar to that of a single domain scenario. If there is a stateful PCE responsible for performing path computation within each domain, the LSPs (segments) traversing the domain/layer should be synchronized to the PCE. Zhang Expires April 2013 [Page 6] draft-zhang-pce-stateful-pce-app-02.txt October 2012 As described in [RFC4726], there are four methods to set up a LSP traversing multiple domains: LSP nesting, contiguous LSP, LSP stitching and hybrid methods, respectively. Hence, the ingress nodes of a LSP traversing a domain may exist in another domain (e.g., a contiguous LSP spanning across multiple domains). In this case, the border node of a domain (i.e., an intermediate node of a LSP), could be responsible for synchronizing the LSP segment in the domain to the PCE. +---------------------+---------------------+ | +----+ | +----+ | | |PCE1| | |PCE2| | | +----+ | +----+ | | Domain 1 | Domain 2 | | +--+ +--+ +--+ | +--+ +--+ +--+ | | |N1+---+N2+---+N3+---+N7+---+N8+---+N9| | | +-++ +--+ +-++ | +-++ +--+ +-++ | | | | | | | | | | | | | | | | +-++ +--+ +-++ | +-+-+ +--++ | | |N4+---+N5+---+N6+---+N10+--------+N11| | | +--+ +--+ +--+ | +---+ +---+ | +---------------------+---------------------+ Figure 1: Multi-domain Scenario Figure 1 shows an example of multi-domain scenario. Suppose a contiguous LSP traverses N1-N2-N3-N7-N8-N9. Then in domain 1, the ingress node of the LSP (i.e., N1) SHOULD synchronize the state of the LSP segment N1-N2-N3 to PCE1. In domain 2, the border node (i.e., N7) SHOULD synchronize the state of the LSP segment N7-N8-N9 to PCE2. This approach requires that N7 has a PCEP adjacency with its PCE (PCE2), i.e. setting up a PCEP session, for LSP state synchronization purpose even if no path computation expansions are required. N7 needs to check whether its RSVP-TE upstream node belongs to another domain and notify the PCE when the LSP is released. Note that synchronization may require detailed information of the LSP (e.g., a full record route, the actual reserved resources) which may only be available during Resv message processing. Alternatively, inter-PCE communication strategy can be adopted for LSP-DB synchronization. For instance, in Figure 1, upon the notification of the setup of LSP N1-N2-N3-N7-N8-N9, PCE1 can establish a PCEP adjacency to inform PCE2 to update its LSP-DB. This method SHOULD be preferred only when PCE1 has sufficient and valid information of the across-domain LSP, such as explicit LSP information. Otherwise, the method in which the border node(s) are in charge of LSP state update is more appropriate. For example, Zhang Expires April 2013 [Page 7] draft-zhang-pce-stateful-pce-app-02.txt October 2012 Backward Recursive Path Computation (BRPC) [RFC5441] in conjunction with path-key-based mechanism [RFC5520] can be adopted for inter- domain path computation. If this is the case with the example in Figure 1, PCE1 only acquires a loose LSP path (e.g., N1-N2-N3-N7- KEY1, where KEY1 can be interpreted only by PCE2). Since it depends on the local policy that how long a Path-Key should be stored, KEY1 might not be valid anymore when it is used by PCE1 for PCE2 LSP-DB update notification. In this case, N7 will need to request PCE2 to unlock the Path-Key in order to complete the signaling process. Therefore, it is possible to use N7 instead for updating PCE2 LSP-DB. Note that a timely synchronization of PCEs and these two databases is a prerequisite to maintaining a good performance of a stateful PCE. To benefit from stateful PCE, during inter-domain path computation procedure, PCC and cooperating PCEs should try to select stateful PCE when multiple PCEs (stateful and stateless) are available in the domain. This will enable correct end-to-end path computation using of TED and LDP-DB in all domains. In case of unavailability of stateful PCE, stateless PCE can still be used to provide the inter- domain path computation. The inter-domain LSP synchronization as explained in this section is still applicable if some domain does not have stateful PCE support. All the domains with a stateful PCE present should synchronize their segment at the least. 2.2.3. Multi-layer In multi-layer scenarios, one node/domain may have multiple switching capabilities. For instance, Optical Transport Network (OTN) nodes may have both of electrical (e.g., ODU1, ODU2, ODU3) and optical switch capabilities. ODU LSPs and wavelength LSPs may be established in an OTN network. In such networks, a PCE may have the capability of performing single layer path computation or multi-layer path computation. If a stateful PCE has single layer path computation capability, the nodes should be aware of information pertaining to which layer should be synchronized to a specific PCE. Otherwise, the state of the LSPs in all layers should be synchronized to the single stateful PCE. 2.3. PCE Survivability/Reliability Since a PCE supports a centralized path computation model, its survivability should be carefully considered to ensure its proper operation. If a multiple stateful PCE model is used and these PCEs Zhang Expires April 2013 [Page 8] draft-zhang-pce-stateful-pce-app-02.txt October 2012 have a consistent view of the network, they can act as a hot backup for each other. Otherwise, other backup strategies SHOULD be present if only one PCE is deployed in the network to avoid a single point of failure. 2.4. Impact on Existing PCEP Operations For a stateful PCE, LSP state information is readily available. Thus, it is possible to allow a lighter information exchange of PCC and PCE for path computation, as compared to that of a stateless PCE. For instance, instead of detailed LSP information (such as route, bandwidth information etc.), only an global unique identifier is required for a stateful PCE to process the request. Therefore, due to this simplification, modification of the operations specified in [RFC5440] should be captured. This is specified in protocol-specific extension document [stateful-PCEP-gmpls]. 2.5. Delegation and Policy Stateful PCE(s) are still subject to policies when performing path computation based on TED and LSP-DB as well as in what concerns LSP- DB organization and maintenance. For LSP-DB maintenance, a basic function of stateful PCEs that SHOULD be supported is the ability to keep LSP state information in the network within which they have visibility. This is termed as a passive stateful PCE in [stateful-PCEP-mpls]. OPTIONALLY, a stateful PCE can also extend its ability to support modification of LSP state information. This can be realized by obtaining the temporal LSP state control through negotiation with LSRs (i.e., LSP delegation). This is termed as an active stateful PCE in [stateful-PCEP-mpls]. Please note that LSP state delegation should comply with the policy imposed by LSP state owner (i.e., LSRs) as well as the policy imposed upon PCE(s). 2.5.1. Use of Under-construction LSPs Information The TED and/or LSP-DB information retained by a stateful PCE might be out-of-syn. If this is the case, it might cause resource contention when the PCE computes paths based of the out-of-date information. Some sources of the potential TED/LSP-DB inaccuracy are: o Control plane link latencies. Such latencies may be increased due to several factors such as: a) The time required for a PCC to obtain the paths after a successful computation, requiring several Round-Trip-Times (RTT) as per TCP; Zhang Expires April 2013 [Page 9] draft-zhang-pce-stateful-pce-app-02.txt October 2012 b) The setup delay; c) The time it takes for the PCE to update the local TED given IGP update times; o The routing and topology dissemination protocol (i.e. OSPF-TE), which may operate with timers for LSA updates, to avoid excessive control plane overhead. o Concurrent requests that arrive during the time window, between a response is sent and the LSP is setup and the topology changes are flooded. Even for very fast networks with low latency, there may be a batched of requests: several path computation requests within a PCReq message or, in dynamic restoration without pre-planning, several LSPs that need to be rerouted so as to avoid a failed link. o Local PCE contention, where the PCE needs to concurrently serve path computation requests and update the LSA (e.g. parsing OSPF-TE LSA updates). A PCE implementation may need to find a trade-off, when synchronizing access to the local TED: favor OSPF-TE parsing which means that some path computations are slightly delayed to allow an 'update' to be processed, or give strict priority to computation requests. In consequence, a PCE may assign the same (or a subset of the same) resources to several requests. Thus, it may result in contention and degraded network performance since it might cause path setup failure and excessive crank-backs. Therefore, information of the LSPs that are under construction can be used together with the TED and LSP-DB by a stateful PCE to reduce the path blocking and crank-backs issues. For example, the PCE can retain some context from paths it has recently computed so that it avoids suggesting the use of the same resources for other TE LSPs, using heuristics / statistic or forecasting for improved resource (i.e. wavelength) allocation. In other words, a given PCE implementation may decide to perform additional book-keeping and management of resources strategies using the information of under construction LSPs, deploying policies that prevent sub-optimal allocations. For instance, a PCE may compute the mean time used to update the TED based on the previous calculated TE-LSPs and TED updates. Those kinds of mechanisms may reduce the TED inaccuracy but in all cases they cannot infer the PCC use of the TE-path. Zhang Expires April 2013 [Page 10] draft-zhang-pce-stateful-pce-app-02.txt October 2012 3. Application Scenarios In this section, several examples exploiting the capabilities of stateful PCE(s) are presented, although the application of stateful PCE(s) is not limited to them. In general, stateful PCE(s) can be deployed for applications where LSP state as well as traffic engineering information in the network are necessary inputs to achieve one or multiple of the following goals: o Improving the performance such as reducing network blocking probability, achieving load balancing, improve network resources utilization or increasing the route computation success rate; o Reducing the complexity of the relevant procedure(s) associated with the application(s); o Lowering resource consumption; As discussed in [PSU-WSON] and [LCA-Stateless], some of the objectives can be achieved through limited LSP awareness in stateless PCE by exploiting objects defined in existing protocols, such as the SVEC object defined in [RFC5440] and/or XRO object defined in [RFC5521]. These methods are considered as transitional solutions because of two reasons. Firstly, these methods only have local/partial/temporal LSP related information and thus have limited utility in terms of achieving the goals, particularly for objectives set at a network level. Secondly, it might incur a substantial amount of overhead since it requires frequent message exchanges among PCC and PCE entities. 3.1. Impairment-Aware Routing and Wavelength Assignment (IA-RWA) In WSON networks [RFC6163], a wavelength-switched LSP traverses one or multiple fiber links. The bit rates of the client signals carried by the wavelength LSPs may be the same or different. Hence, a fiber link may transmit a number of wavelength LSPs with equal or mixed bit rate signals. For example, a fiber link may multiplex the wavelengths with only 10G signals, mixed 10G and 40G signals, or mixed 40G and 100G signals. IA-RWA in WSONs refers to the RWA process (i.e., lightpath computation) that takes into account the optical layer/transmission imperfections by considering as additional (i.e., physical layer) constraints. To be more specific, linear and non-linear effects associated with the optical network elements should be incorporated into the route and wavelength assignment procedure. For example, the physical imperfection can result in the interference of two adjacent lightpaths. Thus, a guard band should be reserved between them to Zhang Expires April 2013 [Page 11] draft-zhang-pce-stateful-pce-app-02.txt October 2012 alleviate these effects. The width of the guard band between two adjacent wavelengths depends on their characteristics, such as modulation formats and bit rates. Two adjacent wavelengths with different characteristics (e.g., different bit rates) may need a wider guard band and with same characteristics may need a narrower guard band. For example, 50GHz spacing may be acceptable for two adjacent wavelengths with 40G signals. But for two adjacent wavelengths with different bit rates (e.g., 10G and 40G), a larger spacing such as 300GHz spacing may be needed. Hence, the characteristics (states) of the existing wavelength LSPs SHOULD be considered for a new RWA request in WSON. In summary, when stateful PCE(s) are used to perform the IA-RWA procedure, it needs to know the characteristics of the existing wavelength LSPs. The impairment information relating to existing and to-be-established LSPs can be obtained by nodes in WSON networks via external configuration or other means such as monitoring or estimation based on a vendor-specific impair model. However, WSON related routing protocols, i.e., [GEN-OSPF] and [WSON-OSPF], only advertise limited information (i.e., availability) of the existing wavelengths, without defining the supported client bit rates. It will incur substantial amount of control plane overhead if routing protocols are extended to support dissemination of the new information relevant for the IA-RWA process. In this scenario, stateful PCE(s) would be a more appropriate mechanism to solve this problem. Stateful PCE(s) can exploit impairment information of LSPs stored in LSP-DB to provide accurate RWA calculation. 3.2. Defragmentation in Flexible Grid Networks Traditionally, in Dense Wavelength Division Multiplexing (DWDM) networks, the frequency and channel spacing for a single wavelength allocated to an optical connection is fixed, in terms of a fixed channel spacing grid. With the development of mixed-rate transmission and the increase in the speed of optical signal, the issue of poor optical spectrum usage needs to be addressed. Flexible grid is proposed to solve this problem [G.FLEXIGRID]. In Flexible grid networks, LSPs with different slot widths (such as 12.5G, 25G etc.) can co-exist so as to accommodate the services with different bandwidth requests. Yet another problem arises in this type of DWDM networks. Since in flexible grid networks LSPs are dynamically allocated and released over time, the optical spectrum resource becomes fragmented. The overall available spectrum resource on a link might be sufficient for a new LSP request. But if the available spectra are not continuous, the request would be rejected. In order to perform frequency defragmentation procedure, stateful PCE(s) COULD be used, Zhang Expires April 2013 [Page 12] draft-zhang-pce-stateful-pce-app-02.txt October 2012 since existing TE LSPs information (i.e., slot width and spectrum location information associated with TE LSPs) is required to accurately assess spectrum resources on the LSPs, and perform de- fragmentation while ensuring a minimal disruption of the network, e.g., based on active LSP priorities. [Editor's note: it is not suggested to start PCEP extensions on this application until the data plane technology and the corresponding GMPLS control is mature.] 3.3. Recovery 3.3.1. Protection For protection purposes, a PCC may send a request to a PCE for computing a set of paths for a given LSP. Alternatively, the PCC can send multiple requests to the PCE, asking for working and backup LSPs separately. In either way, the resources bound to backup paths can be shared by different LSPs to improve the overall network efficiency. If resource sharing is supported for LSP protection, the information relating to existing LSPs is required to avoid allocation of shared protection resources to two LSPs that might fail together and cause protection contention issues. If such information is required on each network node, extensions to existing signaling or routing protocols are needed in order to carry the necessary information for avoiding allocating shared protection resources for two non-disjoint working LSPs. However, stateful PCE(s) can easily accommodate this need using the information stored in its LSP-DB, without requiring extensions to existing routing protocols. +----+ |PCE | +----+ +------+ +------+ +------+ | N1 +----------+ N2 +----------+ N3 | +--+---+ +---+--+ +---+--+ | | | | +---------+ | | | | | +--+---+ +------+ | +-----+ N5 +----------+ N4 +-----+ +------+ +------+ Figure 2: Example Network Zhang Expires April 2013 [Page 13] draft-zhang-pce-stateful-pce-app-02.txt October 2012 For example, in the network depicted in Figure 2, suppose there exists LSP1 (N1->N5) with backup route following N1->N2->N5. A request arrives asking for a working and backup path pair to be computed for a request from N2 to N5. If the PCE decides N2->N1->N5 to be the best working route, then the backup path should not use the same protection resource with LSP1 since the new LSP shares part of its resource with LSP1 (i.e., these two LSPs are in the same shared risk group). Alternatively, there is no such constraint if N2->N3->N4->N5 is chosen to be the right candidate for undertaking the request. 3.3.2. Restoration In case of a link failure, such as fiber cut, multiple LSPs may fail at the same time. Thus, the source nodes of the affected LSPs will be informed of the failure by the nodes detecting the failure. These source nodes will send requests to a PCE for rerouting. In order to reuse the resource taken by an existing LSP, the source node can send a PCReq message including the XRO object with F bit set, together with RRO object, as specified in [RFC5521]. If a stateless PCE is exploited, it might respond to the rerouting requests separately if they arrive at different times. Thus, it might result in sub-optimal resource usage. Even worse, it might unnecessarily block some of the rerouting requests due to insufficient resources for later-arrived rerouting messages. If a stateful PCE is used to fulfill this task, it can re-compute the affected LSPs concurrently while reusing part of the existing LSPs resources when it is informed of the failed link identifier provided by the first request. This is made possible since the stateful PCE can check what other LSPs are affected by the failed link and their route information by inspecting its LSP-DB. As a result, a better performance, such as better resource usage, minimal probability of blocking upcoming new rerouting requests sent as a result of the link failure, can be achieved. In order to further reduce the amount of LSP rerouting messages flow in the network, the notification can be performed at the node(s) which detect the link failure. For example, suppose there are two LSPs in the network as shown in Figure 2: (i) LSP1: N1->N5->N4->N3; (ii) LSP2: N2->N5->N4. They traverse the failed link between N5-N4. When N4 detects the failure, it can send a notification message to a stateful PCE. Note that the stateful PCE stores the path information of the LSPs that are affected by the link failure, so it does not need to acquire this information from N4. Moreover, it can make use of the bandwidth resources occupied by the affected LSPs when performing path recalculation. After N4 receives the new paths from the PCE, it notifies the ingress nodes of the LSPs, i.e., N1 and N2, Zhang Expires April 2013 [Page 14] draft-zhang-pce-stateful-pce-app-02.txt October 2012 and specifies the new paths which should be used as the rerouting paths. To support this, it would require extensions to existing signaling protocol. Alternatively, if the target is to avoid resource contention within the time-window of high LSP requests, a stateful PCE can retain the under-construction LSP resource usage information for a given time and exclude it from being used for forthcoming LSPs' request. In this way, it can ensure that the resource will not be double-booked and thus the issue of resource contention and computation crank- backs can be resolved. 3.4. SRLG Diversity A common requirement is to maintain SRLG disjointness between LSPs. This can be achieved at provisioning time, if the routes of all the LSPs are requested together, using a synchronized computation of the different LSPs with SRLG disjointness constraint. If the LSPs need to be provisioned at different times, (more general, the routes are requested at different times, e.g. in the case of a restoration), the PCC can specify, as constraints to the path computation a set of Shared Risk Link Groups (SRLGs) using the Explicit route Object [RFC 5521]. However, for the latter to be effective, it is needed that the entity that requests the route to the PCE maintains updated SRLG information of all the LSPs to which it must maintain the disjointness. Using a stateful PCE allows the maintenance of the updated SRLG information of the established LSPs in a centralized manner. Having such information in the PCE facilitates the PCC to specify, as constraint to the path computation, the SRLG disjointess of a set of already established LSPs by only providing LSPs' identifiers. 3.5. Maintenance of Virtual Network Topology (VNT) In Multi-Layer Networks (MLN), a Virtual Network Topology (VNT) [RFC5212] consists of a set of one or more TE LSPs in the lower layer to provide TE links to the upper layer. In [RFC5623], the PCE- based architecture is proposed to support path computation in MLN networks in order to achieve inter-layer TE. The establishment/teardown of a TE link in VNT needs to take into consideration the state of existing LSPs and/or new LSP request(s) in the higher layer. Traditionally, a VNT manager (VNTM) is in charge of the topology in the upper layer by connections in the lower layer. Hence, when a stateless PCE is requested to compute a Zhang Expires April 2013 [Page 15] draft-zhang-pce-stateful-pce-app-02.txt October 2012 new TE link, it will need interaction with VNTM for detailed TE link information. To be more specific, without detailed LSP information, this process would be inefficient or even infeasible for stateless PCE(s), unless with cooperation with VNTM. On the other hand, a stateful PCE seems more suitable to make the decision of when and how to modify the VNT either to accommodate new LSP requests or to re-optimize resource use across layers irrespective of PCE models. As described in Section 2.2, path computation for a VNT change can be performed by the PCE if a single PCE model is adopted. On the other hand, if a per-layer PCE model is more appropriate, coordination between PCEs is required. 3.6. Global Concurrent Optimization (GCO) GCO is introduced in [RFC5557] to calculate multiple paths concurrently so as to improve network resource efficiency. By taking into consideration the network topology as well as existing TE LSPs information, GCO can (re)optimize the entire network simultaneously. Alternatively, GCO can be applied to (re)optimize one or a subset of existing TE LSPs or plan for forthcoming LSP(s) with specific objectives. GCO can also support off-line one-time optimization (i.e., planning) given a traffic matrix and network topology. Due to its complexity and potentially high computational demand, it is recommended to be performed in a centralized way (e.g., based on a management-based PCE). In case of a stateless PCE, in order to optimize network resource usage dynamically through online planning, PCC (e.g., NMS) should send a request to PCE together with detailed path/bandwidth information of the LSPs that need to be concurrently optimized. This would require a PCC (e.g., NMS) to determine when and which LSPs should be optimized. Given all of the existing LSP state information kept at a stateful PCE, it allows automation of this process without the PCC (e.g. NMS) to supply the existing LSP state information. Moreover, since a stateful PCE can maintain the information regarding to all LSPs that are currently under signaling, it makes the optimization procedures be performed more intelligently and effectively. 3.7. Point-to-Multipoint (P2MP) Application Route computation for P2MP application involves selection of branching points together with calculating multiple sub-LSPs with certain objective(s) such as minimizing the overall cost of the P2MP tree. Moreover, egress nodes addition and removal in a P2MP tree necessitates (re)optimization. Besides these, there are also some constraints and policies that make the P2MP tree computation hard, Zhang Expires April 2013 [Page 16] draft-zhang-pce-stateful-pce-app-02.txt October 2012 requiring high computation power. Therefore, PCE is proposed to support P2MP application [RFC5671]. If a stateless PCE is used for P2MP calculation or optimization under constraints such as load balancing or path disjointedness, then a large amount of sub-LSP information might need to be exchanged between the PCE and the requesting entities. Moreover, if the requesting entity cannot provide complete information of sub- LSPs pertaining to the P2MP tree, then the performance of stateless PCE will be sub-optimal. On the contrary, a stateful PCE can support the P2MP tree computation/optimization with reduced overhead and improved efficiency. 3.8. Time-based Scheduling Time-based scheduling allows network operators to reserve resources in advance upon request from the customers to transmit large bulk of data with specified starting time and duration, such as in support of scheduled data transmission between data centers. Traditionally, this can be supported by NMS operation through path pre-establishment and activation on the agreed starting time. However, this does not provide efficient network usage since the established paths exclude the possibility of being used by other services even when they are not used for undertaking any service. It can also be accomplished through GMPLS protocol extensions by carrying the related request information (e.g., starting time and duration) across the network. Nevertheless, this method inevitably increases the complexity of signaling and routing process. A stateful PCE can support this application with better efficiency since it can alleviate the burden of processing on network elements as well as enable the flexibility of resources usage by only excluding the time slot(s) reserved for time-based scheduling requests. In order to support this application, a stateful PCE should also maintain a database that stores all the reserved information with time reference. This can be achieved either by maintaining a separate database or incorporated into LSP-DB. The details of organizing time-based scheduling related information as well as its impact on LSP-DB is subject to network provider's policy and administrative consideration and thus outside of the scope of this document. 4. Manageability Considerations The description and functionality specifications presented related to stateful PCE(s) should also comply with the manageability specifications covered in Section 8 of [RFC4655]. Furthermore, a Zhang Expires April 2013 [Page 17] draft-zhang-pce-stateful-pce-app-02.txt October 2012 further list of manageability issues presented in [Stateful-PCEP- mpls] may also be considered. Information and Data Models A Management Information Base (MIB) module for management of the PCEP is being specified in a separate document [PCEP-MIB]. That MIB module allows examination of individual PCEP messages, in particular requests, responses and errors. The MIB module MUST be extended to include the ability to view stateful PCE PCEP extensions defined in relevant documents. 5. Security Considerations The security issues presented in [RFC5440] still applies to this document. In addition, the security concerns raised by [Stateful- PCEP-mpls] may also be considered. 6. References 6.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to indicate requirements levels", RFC 2119, March 1997. [RFC4655] Farrel, A., Vasseur, J.-P., and Ash, J., "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006. [RFC5440] Vasseur, J.-P., and Le Roux, JL., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, March 2009. [RFC6163] Lee, Y., Bernstein, G., "Framework for GMPLS and Path Computation Element (PCE) Control of Wavelength Switched Optical Networks (WSONs)", RFC 6163, April, 2011. [RFC5521] Oki, E., Farrel, A., "Extensions to the Path Computation Element Communication Protocol (PCEP) for Route Exclusions", RFC5521, April 2009. 6.2. Informative References [WSON-Impairment] Lee, Y., Bernstein, G., Li, D., Martinelli, G., "A Framework for the Control of Wavelength Switched Optical Network (WSON) with Impairments", draft-ietf-ccamp-wson- impairments, work in progress. Zhang Expires April 2013 [Page 18] draft-zhang-pce-stateful-pce-app-02.txt October 2012 [RFC4726] Farrel, A., Vasseur, J.-P., Ayyangar, A., "A Framework for Inter-Domain Multiprotocol Label Switching Traffic Engineering", RFC 4726, November 2006. [RFC5520] Bradford, R., Vasseur, JP., Farrel, A., "Preserving Topology Confidentiality in Inter-Domain Path Computation Using a Path-Key-Based Mechanism", RFC 5520, April 2009. [RFC5441] Vasseur, J.-P., Zhang, R., Bitar, N., Le Roux, JL., "A Backward-Recursive PCE-Based Computation (BRPC) Procedure to Compute Shortest Constrained Inter-Domain Traffic Engineering Label Switched Paths", RFC 5441, April 2009. [PSU-WSON] Giorgetti, A, Cugini, G, et al, "Path state-based update of PCE traffic engineering database in wavelength switched optical networks", IEEE Com. Let., June 2010. [LCA-Stateless] Gonzalez de Dios, O., et al, "Benefits of limited context awareness in stateless PCE", Optical Fiber Communication Conference, March 2011. [WSON-OSPF] Lee, Y., Bernstein, G., "GMPLS OSPF Enhancement for Signal and Network Element Compatibility for Wavelength Switched Optical Networks", draft-ietf-ccamp-wson-signal- compatibility-ospf-07, October 2011. [GEN-OSPF] Zhang, Fatai, Lee, Y., Han, Jianrui, Bernstein, G., Xu, Yunbin, "OSPF-TE Extensions for General Network Element Constraints", draft-ietf-ccamp-gmpls-general-constraints- ospf-te-02, September 2011. [G.FLEXIGRID] Draft revised G.694.1 version 1.3, Unpublished ITU-T Study Group 15, Question 6. [RFC5212] Shiomoto, K., Papadimitriou, D., Le Roux, JL., Vigoureux, M., Brungard, D., "Requirements for GMPLS-Based Multi- Region and Multi-Layer Networks (MRN/MLN)", RFC 5212, July 2008. [RFC5557] Lee, Y., Le Roux, JL., King, D., Oki E., "Path Computation Element Communication Protocol (PCEP) Requirements and Protocol Extensions in Support of Global Concurrent Optimization", RFC 5557, July, 2009. [RFC5671] Yasukawa, S., Farrel, A., "Applicability of the Path Computation Element (PCE) to Point-to-Multipoint (P2MP) MPLS and GMPLS Traffic Engineering (TE)", October, 2009. Zhang Expires April 2013 [Page 19] draft-zhang-pce-stateful-pce-app-02.txt October 2012 [RFC5623] Oki, E., Takeda, T., Le Roux, JL., Farrel, A., "Framework for PCE-Based Inter-Layer MPLS and GMPLS Traffic Engineering", RFC5623, September 2009. [stateful-PCEP-mpls] Crabbe, E., Medved, J., Varga, R., Minei, I., ''PCEP Extensions for Stateful PCE'', draft-ietf-pce- stateful-pce, work in progress. [stateful-PCEP-gmpls] Zhang, X., Lee, Y., Casellas, R., Gonzalez de Dios, O., '' Path Computation Element (PCE) Protocol Extension for Stateful PCE Usage in GMPLS Networks'', draft-zhang-pce-pcep-stateful-pce-gmpls, work in progress [PCEP-MIB] Kiran Koushik, A S., Stephan, E., Zhao, Q., King, D., "PCE communication protocol (PCEP) Management Information Base", draft-ietf-pce-pcep-mib, work in progress [PCEP-GMPLS] C. Margaria O. Gonzalez de Dios F. Zhang ''PCEP extensions for GMPLS'' draft-ietf-pce-gmpls-pcep- extensions-06 work in progress. Contributors' Address Zhang Expires April 2013 [Page 20] draft-zhang-pce-stateful-pce-app-02.txt October 2012 Dhruv Dhody Huawei Technology Leela Palace Bangalore, Karnataka 560008 INDIA EMail: dhruvd@huawei.com Xiaobing Zi Huawei Technologies F3-5-B R&D Center, Huawei Base Bantian, Longgang District Shenzhen 518129 P.R.China Phone: +86-755-28973229 Email: zixiaobing@huawei.com Authors' Addresses Fatai Zhang Huawei Technologies F3-5-B R&D Center, Huawei Base Bantian, Longgang District Shenzhen 518129 P.R.China Phone: +86-755-28972912 Email: zhangfatai@huawei.com Xian Zhang Huawei Technologies F3-5-B R&D Center, Huawei Base Bantian, Longgang District Shenzhen 518129 P.R.China Phone: +86-755-28972913 Email: zhang.xian@huawei.com Young Lee Huawei 1700 Alma Drive, Suite 100 Plano, TX 75075 US Zhang Expires April 2013 [Page 21] draft-zhang-pce-stateful-pce-app-02.txt October 2012 Phone: +1 972 509 5599 x2240 Fax: +1 469 229 5397 EMail: ylee@huawei.com Ramon Casellas CTTC - Centre Tecnologic de Telecomunicacions de Catalunya Av. Carl Friedrich Gauss n7 Castelldefels, Barcelona 08860 Spain Phone: Email: ramon.casellas@cttc.es Oscar Gonzalez de Dios Telefonica Investigacion y Desarrollo Emilio Vargas 6 Madrid, 28045 Spain Phone: +34 913374013 Email: ogondio@tid.es Intellectual Property The IETF Trust 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 any IETF 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. Copies of Intellectual Property 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 Zhang Expires April 2013 [Page 22] draft-zhang-pce-stateful-pce-app-02.txt October 2012 any standard or specification contained in an IETF Document. Please address the information to the IETF at ietf-ipr@ietf.org. The definitive version of an IETF Document is that published by, or under the auspices of, the IETF. Versions of IETF Documents that are published by third parties, including those that are translated into other languages, should not be considered to be definitive versions of IETF Documents. The definitive version of these Legal Provisions is that published by, or under the auspices of, the IETF. Versions of these Legal Provisions that are published by third parties, including those that are translated into other languages, should not be considered to be definitive versions of these Legal Provisions. For the avoidance of doubt, each Contributor to the IETF Standards Process licenses each Contribution that he or she makes as part of the IETF Standards Process to the IETF Trust pursuant to the provisions of RFC 5378. No language to the contrary, or terms, conditions or rights that differ from or are inconsistent with the rights and licenses granted under RFC 5378, shall have any effect and shall be null and void, whether published or posted by such Contributor, or included with or in such Contribution. Disclaimer of Validity All IETF Documents and the information contained therein 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 THEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Full Copyright Statement Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with Zhang Expires April 2013 [Page 23] draft-zhang-pce-stateful-pce-app-02.txt October 2012 respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Zhang Expires April 2013 [Page 24]