PCE Working Group Y. Lee Internet Draft Huawei Intended Status: Informational H. Zheng Huawei October 24, 2014 Expires: January 2015 PCE in Support of Transporting Traffic Engineering Data draft-lee-pce-transporting-te-data-01.txt Abstract In order to compute and provide optimal paths, Path Computation Elements (PCEs) require an accurate and timely Traffic Engineering Database (TED). Traditionally this TED has been obtained from a link state routing protocol supporting traffic engineering extensions. This document discusses possible alternatives and enhancements to the existing approach to TED creation. This document gives architectural alternatives for these alternatives and their potential impacts on network nodes, routing protocols, and PCEP. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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. This Internet-Draft will expire on April 24, 2015. Copyright Notice Copyright (c) 2014 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 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. Lee & Zheng Expires January 24, 2015 [Page 1] Internet-Draft PCE TED transport July 2014 Table of Contents 1. Introduction...................................................2 1.1. TED Creation and Maintenance via IGP-TEs..................5 2. Alternative TED Creation & Maintenance for a PCE...............6 2.1. Architecture Options......................................8 2.1.1. Nodes Send TE Info to all PCEs......................12 2.1.2. Nodes Send TE Info via an Intermediate System.......12 2.1.3. Nodes Send TE Info to At Least One PCE..............13 2.2. Nodes Finding PCEs.......................................13 2.3. Node TE Information Update Procedures....................14 2.4. PCE TED Maintenance Procedures...........................14 3. Standardization and Protocol Considerations...................15 3.1. Architecture Specific Standardization Aspects............16 4. Security Considerations.......................................16 5. IANA Considerations...........................................17 6. Conclusions...................................................17 7. Acknowledgments...............................................17 8. References....................................................17 8.1. Normative References.....................................17 8.2. Informative References...................................18 Author's Addresses...............................................19 Disclaimer of Validity...........................................20 1. Introduction In Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS), a Traffic Engineering Database (TED) is used in computing paths for connection oriented packet services and for circuits. The TED contains all relevant information that a Path Computation Lee & Zheng Expires January 24, 2015 [Page 2] Internet-Draft PCE TED transport July 2014 Element (PCE) needs to perform its computations. It is important that the TED should be complete and accurate anytime so that the PCE can perform path computations. In MPLS and GMPLS networks, Interior Gateway routing Protocols (IGPs) have been used to create and maintain a copy of the TED at each node. One of the benefits of the PCE architecture [RFC4655] is the use of computationally more sophisticated path computation algorithms and the realization that these may need enhanced processing power not necessarily available at each node participating in an IGP. Section 4.3 of [RFC4655] describes the potential load of the TED on a network node and proposes an architecture where the TED is maintained by the PCE rather than the network nodes. However it did not describe how a PCE would obtain the information needed to populate its TED. PCE may construct its TED by participating in the IGP ([RFC3630] and [RFC5305] for MPLS-TE; [RFC4203] and [RFC5307] for GMPLS). An alternative is offered by BGP-LS [I-D.ietf-idr-ls- distribution]. In this document we propose approaches for creating and maintaining the TED directly on a PCE as an alternative to IGPs and BGP transport and investigate on the impact from the PCE, routing protocol, and node perspective. There are two main applicability of this alternative proposed by this draft: o Where there is no IGP-TE or BGP-LS running at the PCE to learn TED. o Where there is IGP-TE or BGP-LS running but with a need for a faster TED population and convergence at the PCE. * A PCE may receive partial information (say basic TE) from IGP- TE and other information (optical and impairment) from PCEP. * A PCE may receive full information from both IGP-TE and PCEP. A PCC may further choose to send only local TE information or both local and remote learned TED information. How a PCE manages the TED Lee & Zheng Expires January 24, 2015 [Page 3] Internet-Draft PCE TED transport July 2014 information is implementation specific and thus out of scope of this document. PCEP extensions to support this idea is pursued in a separate draft [PCEP-TE]. New application areas for GMPLS and PCE in optical transport networks include Wavelength Switched Optical Networking (WSON) and Optical Transport Networks (OTN). WSON scenarios can be divided into routing wavelength assignment (RWA) problems where a PCE requires detailed information about switching node asymmetries and wavelength constraints as well as detailed up to date information on wavelength usage per link [WSON-Frame]. As more data is anticipated to be made available to PCE with addition of OTN [Reference] and Flex-grid [Reference] and possible with some optical impairment data [WSON- IMP-Info] even with the minimum set specified in [G.680], the total amount of data requires significantly more information to be held in the TED than is required for other traffic engineered networks. Related to this issue published by [HWANG] indicated that long convergence time and large number of LSAs flooded in the network might cause scalability problems in OSPF-TE and impose limitations on OSPF-TE applications. In some circumstances such additional information could "bog down" the routing protocols on the nodes from a data processing, a storage, or communications perspective. In environments where PCEs are external to the nodes running the routing protocol, and where the information in the TED is not used by the switching nodes it makes sense to investigate alternative methods to create and maintain the TED at its place of use, i.e., the PCE. Recent development of a stateful PCE Model [PCE-Initiated] changes the PCE operation from path computation alone to include the support of PCE-initiated LSPs. With a stateful PCE model, it is also noted that LSP-DB is maintained by the PCE. For LSP state synchronization of stateful PCEs in GMPLS networks, the LSP attributes, such as its bandwidth, associated route as well as protection information etc, should be updated by PCCs to PCE LSP database (LSP-DB) [S-PCE-GMPLS]. To support all these recent changes in a stateful PCE model, a direct PCE interface to each PCC has to be supported. Relevant TED information can also be transported from each node to PCE using this PCC-PCE interface. Any resource changes in the node and links can also be quickly updated to PCE using this interface. Convergence time of IGP in GMPLS networks may not be quick enough to support on- line dynamic connectivity required for some applications. Lee & Zheng Expires January 24, 2015 [Page 4] Internet-Draft PCE TED transport July 2014 This draft does not advocate that the alternative methods specified in this draft should completely replace the IGP-TE as the method of creating the TED. The split between the data to be distributed via an IGP and the information conveyed via one of the alternatives in this document depends on the nature of the network situation. One could potentially choose to have some traffic engineering information distributed via an IGP while other more specialized traffic information is only conveyed to the PCEs via an alternative interface discussed here. In addition, the methods specified in this draft is only relevant to a set of architecture options where routing decisions are wholly or partially made in the PCE. However, the networks that do not support IGP-TE/BGP-LS, the method proposed by this draft may be very relevant. 1.1. TED Creation and Maintenance via IGP-TEs Routing protocols, in particular, IGP-TEs such as Open Shortest Path First (OSPF) and Intermediate system to intermediate system (IS-IS), take on a number of roles with respect to the control and data planes for IP, MPLS, and GMPLS. In all three technology families the underlying control plane communications technology is IP and hence all utilize the IGPs ability to control and run the IP data plane. For the IP layer, the IGP directly establishes data plane connectivity. In the MPLS and GMPLS cases separate signaling protocols are used to directly control the data plane connectivity and in these cases the prime purpose of the routing protocol is to furnish network topology and resource status information used by path computation algorithms on the nodes or PCEs. Hence in the IP case the IGP is directly service impacting, while in the MPLS/GMPLS case it is only indirectly service impacting. The IP layer information and the MPLS/GMPLS data plane layer information may be kept by the IGPs in two different information stores. These are referred to as databases but are not necessarily relational databases. In OSPF the information directly related to IP connectivity (and hence the control communications plane for all three technologies) and non-IP advertisements are kept in the link state database (LSDB), while information related to traffic engineering used by MPLS and GMPLS is kept in a (conceptually) separate TED which can be considered a subset of the LSDB. This TED information is distributed in a different data structure (Opaque LSA [RFC5250]). When we talk about adding additional technology-specific GMPLS information used for path computation we are only talking about adding to the TED and not the IP portion of the LSDB. Lee & Zheng Expires January 24, 2015 [Page 5] Internet-Draft PCE TED transport July 2014 There are three main functions performed by an IGP: (a) hello protocol, (b) database synchronization (with neighbors), (c) database updates. Data Plane | Hello Protocol | Database Sync Technologies | | & Updates -------------------------------------------------------------- IP | Establish Control & Data | LSDB | Plane Adjacencies | -------------------------------------------------------------- MPLS | Establish Control & Data | LSDB & TED | Plane Adjacencies | -------------------------------------------------------------- GMPLS | Establish Control Plane | LSDB & TED | Adjacencies (only) | -------------------------------------------------------------- Table 1 Main Functions of an IGP for various technologies The procedures for maintaining LSDBs and TEDs in IGP-TEs have been very successful and well proven over time. These consist of: 1. Ageing the individual pieces of information in the TED (including discarding them when the information gets too old) to remove stale information from the TED. 2. Originator of the information being required to periodically resend TED information to prevent it from being discarded. 3. Originator of the information sending updates of information as needed, but subject to limits on how many/often these can be sent to keep the TED up-to-date, but to avoid swamping the network. 4. Reliable method for getting this information to other peers (flooding) to ensure that the information is delivered to all participants. 5. An efficient database synchronization mechanism for sharing info with a newly established peer. 2. Alternative TED Creation & Maintenance for a PCE Given that nodes, by their position and role in the network, have accurate traffic engineering information concerning their local link ends and switching properties, it seems natural that, if other nodes in the network cannot make use of this information or do not want Lee & Zheng Expires January 24, 2015 [Page 6] Internet-Draft PCE TED transport July 2014 it, the information should only be conveyed to interested PCEs. In such case the flooding of TE information to all nodes may not be very efficient in terms of memory, CPU, bandwidth, etc. In addition, one could potentially choose to have some traffic engineering information distributed via an IGP-TE protocol while other more specialized traffic information is only conveyed to the PCEs. For example, it makes sense to distribute "static" (rarely modified) and sizable data (e.g., NE switching asymmetry structure) via methods other than IGP-TE while more frequently changed data via IGP-TE. This could significantly decrease the IGP-TE information and its footprint on all nodes. The benefits of such an approach include: o Node: reduced storage demands (doesn't keep the entire TED) o Node: reduced processing demands for TED updates and synchronization o Control Plane: reduced overall communication demands since the TED is not being updated and maintained on all nodes in the network. o PCE: More timely TED updates are possible. o Information distribution constraints, such as seen in [Imp-Frame] can be met. To quantify the previous advantages requires a bit more detail on how such an approach could actually be accomplished. The key pieces needed to implement such an approach include: o Multiple PCEs must be supported for robustness and load sharing. o Nodes must be able to find a PCE to which to send their traffic engineering information. o Nodes must have procedures and a mechanism (protocols) with which to communicate their TE information to a PCE. PCEs must have procedures and a mechanism (protocols) with which to receive this TE information from nodes. o Efficient mechanisms must exist in the multi-PCE case to ensure all PCEs have the same TED. Lee & Zheng Expires January 24, 2015 [Page 7] Internet-Draft PCE TED transport July 2014 The advantages of using an alternative to IGP-TE comes at the cost of: o Additional protocols to be configured and secured. Recall that we still must have an IP IGP for control plane communications. o Any new protocols/implementations for alternative TED creation still must support many IGP-TE like features such as removal of stale information, reliable delivery of updates to all participants, recovery after reboots/crashes/upgrades, etc. It should also work along with IGP-TE/BGP-LS TED mechanism with some information in the TED received from existing mechanisms. o Mechanisms to discover PCEs that are capable and willing to accept direct TED updates. 2.1. Architecture Options There are three general architectural alternatives based on how nodes get their local TED information to the PCEs: (1) Nodes send local information to all PCEs; (2) Nodes send local information to an intermediate server that will send to all PCEs; (3) Nodes send local information to at least one PCE and have the PCEs share this information with each other. An important functionality that needs to be addressed in each of these approaches is how a new PCE gets initialized in a reasonably timely fashion. Figures 1-3 show examples of three options for nodes to share local TED information with multiple PCEs. As in the IGP case we assume that switching nodes know their local properties and state including the state of all their local links. In these figures the data plane links are shown with the character "o"; TE information flow from nodes to PCE by the characters "|", "-", "/", or "\"; and PCE to PCE TE information, if any, by the character "i". Lee & Zheng Expires January 24, 2015 [Page 8] Internet-Draft PCE TED transport July 2014 ---- ---- // \\ // \\ / \ / \ | PCE \ | PCE | | |\ / | | X \ / \ / |\\ // \ \ / /|\ /X | --+-\ \ \ /// | -+-- \ | | \\ \ \\ // | | \ | | \\ \ // | | \ | | \\ \ / | | \ | | \ \\ \// | | \ | | \ \\ /\/ | | \ | | \ /X\/\ | | \ | | \ / /\ \ | | \ | | X/ / \\\ | | \ | | / \ / \\ | | \ | | // \ / \\| | \ | | / X \\\ | \ | | // /\ |\\\\| \ | +----+-/-+ / \ |+-\-|----+ \ | | | / \ || | \ | | N1 ooooooooooooooooooo N2 oo \ | | ooooooooooooooooooo ooo \ | | | / \ | | |ooo \ | +---oo---+/ \ | +------\-+ ooo \ | ooo / \ | \ ooo \ | ooo / \ | \ ooo \ | oo / * \ | \ ooo \ | oo / \ | \ ooo \ | ooo / \ | \\ ooo \ | oo / * \ \ ooo \ | ooo / \ \ ooo \ | oo / |\ \ ooo\ ++--oo-/-+ |\ * \+---oo-\-+ | | | \ \ | | oooo | \ oooo Nn | | N3 ooooooooo +-+---\--+ ooooooooo | | | ooooooooo | | oooooooooo | | +--------+ oooooooo N4 oooooooo +--------+ oooo oooo | | +--------+ Figure 1 . Nodes send local TE information directly to all PCEs Lee & Zheng Expires January 24, 2015 [Page 9] Internet-Draft PCE TED transport July 2014 ---- ---- ---- // \\ // \\ // \\ / \ / \ / \ | PCE | | PCE | | PCE | | | | | | | \ -- \ / \ / \\ // -- \\ // --\\ // ---- --- /--- ---- ---- -- / ---- --- / --- -- --/- ---- --/ \\ ---- / -- | Pub/ | -+ Sub | --- X --- -- / \\ // ---- +--- / -+--\ ----+ +-----+--+ / | \ +--+-----+ | | / | \\ | | | N1 ooooooooooooooooooooooooo N2 oooo | ooooooooooooooooooooooooo oooo | | / | \\ | | oo +---oo---+ / | \+--------+ oo oo / | \ oo oo / | \ oo oo / | \\ oo oo / | \ oo oo / * | \ oo oo / | \ oo oo / | \\ oo oo / *| \ oo oo / | \ oo oo / | \\ oo +---oo-/-+ | * \+---oo---+ | | | \ | | oooo | oooo Nn | | N3 oooooooo +---+----+ ooooooooo | | | oooooo | | ooooooooooo | | +--------+ oooooooo N4 ooooooooo +--------+ ooooo oooo | | +--------+ Figure 2 . Nodes send local TE information to PCEs via an intermediary (publish/subscribe)server Lee & Zheng Expires January 24, 2015 [Page 10] Internet-Draft PCE TED transport July 2014 iiiiiiiiiiiiiiiiii iiiiii ---- iii iiiii ---- ii ii// \\i iiiiiiii/ \\ ii / \ / \ i | PCE1 | | PCE2 | i | | | |ii i \ / X / ii i \\ // // \\ // ii i -//- / --+- i i // // | i i +-----/--+ +----/---+ | i i | | | | | i i | N1 ooooooooooooooooooooooooo N2 oooo | i i | ooooooooooooooooooooooooo oooo | i i | | | | oo | i i +---oo---+ +--------+ oo | i i oo oo | i i oo oo | i i oo * oo | i i oo oo | i i oo oo | i i oo * oo | i i oo oo | i i +---oo---+ * +---oo-+-+ i i | | | | i i | oooo oooo Nn | i i | N3 oooooooo +--------+ ooooooooo | i ii | | oooooo | | ooooooooooo | | ii i +---\----+ oooooooo N4 ooooooooo +--------+ i i \ ooooo oooo i ii \ | | i i \\ +--------+ ii ii \ --- i ii \ ---- --- i ii \// \-- i ii / \ ii ii | PCE3 | iiii iiiii| | iiiii \ / iii \\ // iiiiiiiii iii ---- iiiiiiiiiiiiiiiiiii Figure 3 . Nodes send local TE information to at least one PCE and have the PCEs share TED information Lee & Zheng Expires January 24, 2015 [Page 11] Internet-Draft PCE TED transport July 2014 2.1.1. Nodes Send TE Info to all PCEs Architectural alternative 1 shown in Figure 1, illustrates nodes sending their local TE information to all PCEs within their domain. As the number of PCEs grows we have scalability concerns. However, if we are only talking about 2-3 PCEs, then we do not have this scalability concern. In particular each node needs to keep track of which PCE it has sent information to and update that information periodically. If a new PCE is added to the domain the node must send all its local TED information to that PCE rather than just sending status updates. 2.1.2. Nodes Send TE Info via an Intermediate System Architecture alternative 2 is shown in Figure 2. This architecture reduces the burden on switching nodes by having the nodes send TE information to an intermediate system. This general approach is typically described in the software literature as a publish/subscribe paradigm. Here the nodes send their local TED information to an intermediate entity whose job is to insure that all PCEs receive this information. The nodes in this case being the publishers of the information and the PCEs the subscribers of the information. Publish/subscribe functionality can be found in general messaging oriented middleware such as the Java Messaging Service [JMS] and many others. A routing specific example of this approach is seen in BGP route reflectors [RFC4456]. Note that the publish/subscribe entity can be collocated with a PCE. This would then looks like a master/slave type system architecture. If a new PCE is added then the intermediate server will need to work with this new PCE to initialize its TED. Hence the publish/subscribe entity will need to also keep a copy of the entire TED and for reliability purposes a redundant server would be required. The publish/subscribe entity itself can be a PCE. Architecture alternative 2 could be useful when there are a number of PCEs in the network and as such there is the scaling issue with each of the NEs talking to all the PCEs. The advantage of this alternative would diminish when we are dealing only with only a few PCEs. Lee & Zheng Expires January 24, 2015 [Page 12] Internet-Draft PCE TED transport July 2014 2.1.3. Nodes Send TE Info to At Least One PCE In this architectural alternative, shown in Figure 3, each node would be associated with at least one PCE. This implies that each PCE will only have partial TED information directly from the nodes. It would be the responsibility of a node to get its local TED information to its associated PCE, then the PCEs within a domain would then need to share the partial TED information they learned from their associated nodes with each other so that they can create and maintain the complete TED. As we have seen in section 1.1. this is very similar to part of the functionality provided by a link state protocol, but in this case the protocol would be used between PCEs so that they can share the information they have obtained from their associated switching nodes (rather than from attached links as in a regular link state protocol). To allow for this sharing of information PCEs would need to peer with each other. PCE discovery extensions [RFC4674] could be used to allow PCEs to find other PCEs. If a new PCE is added to the domain it would need to peer with at least one other PCE and then link state protocol procedures for TED synchronization could then be used to initialize the new PCEs TED. A number of approaches can be used to ensure control plane resilience in this architecture. (1) Each node can be configured with a primary and a secondary PCE to send its information to; In case of failure of communications with the primary PCE the node would send its information to a secondary PCE (warm standby). (2) Each node could be configured to send its information to two different PCEs (hot standby). 2.2. Nodes Finding PCEs In cases 1 and 3 nodes need to send TE information directly to PCEs. Path Computation Clients (PCCs) and network nodes participating in an IGP (with or without TE extensions) have a mechanism to discover a PCE and its capabilities. [RFC4674] outlines the general requirements for this mechanism and extensions have been defined to provide information so that PCCs can obtain key details about available PCEs in OSPF [RFC5088] and in IS-IS [RFC5089]. After finding candidate PCEs, a node would need to see which if any of the PCEs actually want to receive TE information directly from this node. In architectural alternative 2 (publish/subscribe) the location of intermediate system would either need to be configured or PCE discovery could be extended so that a when a node asks a PCE if it Lee & Zheng Expires January 24, 2015 [Page 13] Internet-Draft PCE TED transport July 2014 wants to hear TE info the PCE points it to the intermediate publish/subscribe system. 2.3. Node TE Information Update Procedures First a node must establish an association between itself and a PCE or intermediate system that will be maintaining a TED. It is the responsibility of the node to share TE information concerning its local environment, e.g., links and node properties. General and technology specific information models would specify the content of this information while the specific protocols would determine the format. Note that a node would not be sending to the PCE information it might be passed from neighbor nodes. Note that data plane neighbor information would be passed to the PCE embedded in TE link information. There will be cases where the node would have to send to the PCE only a subset of TE link information depending on the path computation option. For instance, if the node is responsible for routing while the PCE is responsible for wavelength assignment for the route, the node would only need to send the PCE the WSON link usage information. This path computation option is referred to as separate Fouting (R) and Wavelength Assignment (WA) option in [PCE- WSON]. 2.4. PCE TED Maintenance Procedures The PCE is responsible for creating and maintaining the TED that it will use. Key functions include: 1. Establishing and authenticating communications between the PCE and sources of TED information. 2. Timely updates of the TED with information received from nodes, peers or other entities. 3. Verifying the validity of information in the TED,i.e., ensure that the network information obtained from nodes or elsewhere is relatively timely, or not stale. By analogy with similar functionality provided by IGPs this can be done via a process where discrete "chunks" of TED information are "aged" and discard when expired. This combined with nodes periodically resending their local TE information leads to a timely TED. Lee & Zheng Expires January 24, 2015 [Page 14] Internet-Draft PCE TED transport July 2014 3. Standardization and Protocol Considerations In the previous section we examined a number of architectural alternatives for TED creation and maintenance between PCE(s) and the network. Here we examine aspects of these alternatives that could be suitable for standardization. First there are a number of functions which are independent of the particular architectural alternatives, these include: o An information model for the TED o Basic PCE TED creation and maintenance procedures o Information packaging for use in TED creation, maintenance and exchange o NE to PCE (or Pub/Sub) communication of TED information --- interface and protocol (e.g. PCEP) o NEs discovering PCE (or Pub/Sub) for TED creation and maintenance purposes By the "information model" for the TED we mean the raw information that a path computation algorithm would work with somewhat independent of how it might be packaged for TED maintenance and creation. Initial efforts along these lines have started at CCAMP for wavelength switched optical networks for non-impairment RWA [WSON-Info] and impairment aware RWA [WSON-IMP-Info]. Given a TED information model if we can agree on basic PCE TED creation and maintenance procedures we can then come up with a standardized way to package the information for use in such procedures. The analogy here is with an IGPs database maintenance procedures such as aging and the packaging of link state information information into LSA (link state advertisements). LSAs form the basic chunks of an IGP's database. OSPF LSAs include an age field to assist in the ageing procedure and also has an advertising router field that aids in redistribution decisions, i.e., flooding. However the detailed TE information is encoded in LSAs via type length value (TLV) structures and it is this information that is used in path computation. From there we could standardize the interface between a NE and a PCE for communication of TE information. This interface includes NE and PCE behaviors as well as a communications protocol. Lee & Zheng Expires January 24, 2015 [Page 15] Internet-Draft PCE TED transport July 2014 Finally for the common behaviors we need a way for the NEs to find the PCEs or an intermediate publish/subscribe system to which they will send their TE information. As was previously pointed out this could be based on small enhancements to existing PCE discovery mechanisms. 3.1. Architecture Specific Standardization Aspects Case 1: NEs send to all PCEs This case has commonalities with both cases 2 and 3 and does not appear to have unique standardization aspects. As pointed out in section 2.1. We do need to consider when a new PCE comes online. Case 2: Publish/Subscribe Server In this case we would need to additionally standardize 1. how a new PCE coming online synchronizes with the publish/subscribe server 1. how PCEs and publish subscribe server communicate 2. Redundancy for publish subscribe server Case 3: PCE to PCE sharing TE information learned from NEs Here we would need the following additional mechanisms standardized: 1. The PCE to PCE interface and protocol 2. The method for PCEs to discover PCEs for the purpose of TE information sharing 3. PCE to PCE association for information sharing, in particular sharing update information. 4. Security Considerations This draft discusses an alternative technique for PCEs to build and maintain a traffic engineering database. In this approach network nodes would directly send traffic engineering information to a PCE. It may be desirable to protect such information from disclosure to unauthorized parties in addition it may be desirable to protect such communications from interference (modification) since they can be critical to the operation of the network. In particular, this information is the same or similar to that which would be Lee & Zheng Expires January 24, 2015 [Page 16] Internet-Draft PCE TED transport July 2014 disseminated via a link state routing protocol with traffic engineering extensions. 5. IANA Considerations This version of this document does not introduce any items for IANA to consider. 6. Conclusions This document introduced several alternative architectures for PCEs to create and maintain a traffic engineering database (TED) via information directly or indirectly received from network elements and identified common aspects of these approaches. The TED is a critical piece of the overall PCE architecture since without it path computations cannot proceed. Though not explicitly out of scope the PCE working group does not have a work item or study item devoted to TED creation and maintenance. Such a work item can lead to enhanced interoperability and simplicity of PCE implementations. This document identified several common areas within these alternatives that could be standardized. In addition, the alternative approaches to TED creation and maintenance discussed here offloads both the network nodes and routing protocols from either some or all TED creation and maintenance duties at the same time it does not add significant new processing to a PCE that has already been participating in IGP based TED creation and maintenance. 7. Acknowledgments We would like to thank Adrian Farrel for his useful comments and suggestions. 8. References 8.1. Normative References [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006. [RFC4674] Le Roux, J., Ed., "Requirements for Path Computation Element (PCE) Discovery", RFC 4674, October 2006. [RFC5088] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. Zhang, "OSPF Protocol Extensions for Path Computation Element (PCE) Discovery", RFC 5088, January 2008. Lee & Zheng Expires January 24, 2015 [Page 17] Internet-Draft PCE TED transport July 2014 [RFC5089] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. Zhang, "IS-IS Protocol Extensions for Path Computation Element (PCE) Discovery", RFC 5089, January 2008. [RFC5250] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The OSPF Opaque LSA Option", RFC 5250, July 2008. 8.2. Informative References [JMS] Java Message Service, Version 1.1, April 2002, Sun Microsystems. [PCE-Initiated] E. Crabbe, et. al., "PCEP Extensions for PCE- initiated LSP Setup in a Stateful PCE Model", draft-ietf- pce-pce-initiated-lsp, work in progress. [S-PCE-GMPLS] X. Zhang, et. al, "Path Computation Element (PCE) Protocol Extensions for Stateful PCE Usage in GMPLS- controlled Networks", draft-ietf-pce-pcep-stateful-pce- gmpls, work in progress. [PCE-WSON] Y. Lee, G. Bernstein, "PCEP Requirements for the support of Wavelength Switched Optical Networks (WSON)", work in progress, draft-lee-pce-wson-routing-wavelength- 05.txt, February 2009. [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP)", RFC 4456, April 2006. [Imp-Frame] G. Bernstein, Y. Lee, D. Li, A Framework for the Control and Measurement of Wavelength Switched Optical Networks (WSON) with Impairments, Work in Progress, October 2008. [WSON-Frame] Y. Lee, G. Bernstein, W. Imajuku, "Framework for GMPLS and PCE Control of Wavelength Switched Optical Networks", work in progress: draft-ietf-ccamp-wavelength- switched-framework. [PCEP-TE] D. Dhody, Y. Lee, "PCEP Extension for Transporting TE Data", work in progress: draft-dhodylee-pce-pcep-te-data- extn. [WSON-IMP-Info] Y. Lee, G. Bernstein, "Information Model for Impaired Optical Path Validation", work in progress: draft-bernstein-wson-impairment-info-02.txt, March 2009. Lee & Zheng Expires January 24, 2015 [Page 18] Internet-Draft PCE TED transport July 2014 [HWANG] S. Hwang, et al, "An Experimental Analysis on OSPF-TE Convergence Time", Proc. SPIE 7137, Network Architectures, Management, and Applications, November 19, 2008. Author's Addresses Young Lee Huawei Technologies 5340 Legacy Drive, Building 3 Plano, TX 75023, USA Phone: (469) 277-5838 Email: leeyoung@huawei.com Haomian Zheng Huawei Technologies Co., Ltd. F3-1-B R&D Center, Huawei Base, Bantian, Longgang District Shenzhen 518129 P.R.China Phone: +86-755-28979835 Email: zhenghaomian@huawei.com Lee & Zheng Expires January 24, 2015 [Page 19] Internet-Draft PCE TED transport July 2014 Contributor's Addresses Dhruv Dhody Huawei Technologies Leela Palace Bangalore, Karnataka 560008 India EMail: dhruv.ietf@gmail.com Xian Zhang Huawei Technologies Co., Ltd. F3-1-B R&D Center, Huawei Base, Bantian, Longgang District Shenzhen 518129 P.R.China Phone: +86-755-28979835 Email: zhangxian@huawei.com 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Lee & Zheng Expires January 24, 2015 [Page 20]