Path Computation Element Working Group O. Dugeon Internet-Draft J. Meuric Intended status: Informational Orange Labs Expires: January 16, 2014 R. Douville Alcatel-Lucent R. Casellas CTTC O. Gonzalez de Dios Telefonica Investigacion y Desarrollo July 15, 2013 Path Computation Element (PCE) Database Requirements draft-dugeon-pce-ted-reqs-02 Abstract The Path Computation Element (PCE) working group (WG) has produced a set of RFCs to standardize the behavior of the Path Computation Element as a tool to help MPLS-TE and GMPLS LSP tunnels placement. In the PCE architecture, a main assumption has been done concerning the information that the PCE needs to perform its computation. In a fist approach, the PCE embeds a Traffic Engineering Database (TED) containing all pertinent and suitable information regarding the network that is in the scope of a PCE. Nevertheless, the TED requirements as well as the TED information have not yet been formalized. In addition, some recent RFC (like the Backward Recursive Path Computation procedure or PCE Hierarchy) or WG draft (like draft-ietf-pce-stateful-pce ...) suffer from a lack of information in the TED, leading to a non optimal result or to some difficulties to deploy them. This memo tries to identify some Database, at large, requirements for the PCE. It is split in two main sections: the identification of the specific information to be stored in the PCE Database and how it may be populated. Requirements Language 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]. 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 Dugeon, et al. Expires January 16, 2014 [Page 1] Internet-Draft PCE TED Req. July 2013 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 January 16, 2014. Copyright Notice Copyright (c) 2013 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. Table of Contents 1. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 1.1. PCE Assumption and Hypothesis . . . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2. PCED Requirements . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Intra-Domain . . . . . . . . . . . . . . . . . . . . . . 5 2.1.1. MPLS . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1.2. GMPLS . . . . . . . . . . . . . . . . . . . . . . . . 6 2.2. Inter-Domain . . . . . . . . . . . . . . . . . . . . . . 6 2.3. TE LSPs . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.4. Operational Information . . . . . . . . . . . . . . . . . 7 3. PCED model . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Intra-domain . . . . . . . . . . . . . . . . . . . . . . 7 3.1.1. MPLS . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1.2. GMPLS . . . . . . . . . . . . . . . . . . . . . . . . 7 3.2. Inter-domain . . . . . . . . . . . . . . . . . . . . . . 7 4. PCED Population . . . . . . . . . . . . . . . . . . . . . . . 8 4.1. Intra-domain . . . . . . . . . . . . . . . . . . . . . . 8 4.1.1. MPLS . . . . . . . . . . . . . . . . . . . . . . . . 9 4.1.2. GMPLS . . . . . . . . . . . . . . . . . . . . . . . . 9 4.2. Inter-Domain . . . . . . . . . . . . . . . . . . . . . . 9 4.2.1. Information exchange . . . . . . . . . . . . . . . . 10 Dugeon, et al. Expires January 16, 2014 [Page 2] Internet-Draft PCE TED Req. July 2013 4.3. TE-LSPs . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.4. Operational information . . . . . . . . . . . . . . . . . 11 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6.1. Intra-domain information . . . . . . . . . . . . . . . . 12 6.2. Inter-domain information . . . . . . . . . . . . . . . . 12 6.3. Operational information . . . . . . . . . . . . . . . . . 12 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 8.1. Normative References . . . . . . . . . . . . . . . . . . 12 8.2. Informative References . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 1. Problem Statement Looking to the different RFCs that describe the PCE architecture and in particular RFC 4655 [RFC4655], RFC 5440 [RFC5440], RFC 5441 [RFC5441] and RFC 6805 [RFC6805], the Path Computation Element (PCE) needs to acquire a set of information that is usually store in the Traffic Engineering Database (TED) in order to perform its path computation. Even if intra-domain topology acquisition is well documented and known (e.g. by listening to the IGP-TE protocol that runs inside the network), inter-domain topology information, PCE peer address, neighbor AS, existing MPLS-TE tunnels... that are necessary for the Global Concurrent Optimization, Backward Recursive Path Computation (BRPC) and the Hierarchical PCE are not documented and not completely standardized. The purpose of this memo is to inventory the required information that should be part of the PCE Database and the different mechanisms that allow an operator to populate it. 1.1. PCE Assumption and Hypothesis In some cases, both the path computation and the Database operations are slightly coupled: border node identification, endpoint localization, TE-LSP learning and domain sequence selection... to name a few in which an IGP-based TED may not be sufficient. It is also important to differentiate several environments with different requirements, especially for the multi-domain problem. The PCE is scoped for any kind of network, from transmission networks (TDM/WDM) with a rather limited number of domains, few interconnections, and few confidentiality issues; transmission networks with a large number of domains; MPLS networks with several administrative domains; and big IP/MPLS networks with a large number of domains with peering agreements. For each of them, a different solution for the multi- domain path computation may apply. A solution may not be scalable for one, but perfectly suitable for another. Dugeon, et al. Expires January 16, 2014 [Page 3] Internet-Draft PCE TED Req. July 2013 Up to now, PCE WG has based its work and standard on the assumption and hypothesis that the TED contains all pertinent information suitable for the PCE to compute an optimal TE-LSP placement, over one or several domains a PCE has visibility on or over a set of PCE- capable domains (e.g. using BRPC procedure). We could identify two major sources of information for the TED: o The intra-domain routing protocol like OSPF-TE or IS-IS-TE (including extensions for border links), o The inter-domain routing protocol, i.e. BGP for the inter-AS case. If the first source gives a precise and synchronize view of the controlled network, BGP typically just provides network reachability with only one AS path (unless using recent add path option). Nevertheless, to optimize inter-domain path computation, route diversity and a minimum set of Traffic Engineering information about the foreign domains could be helpful. Despite that it is possible to re-announce TE-LSP in the IGP-TE, the PCE needs also to have a precise knowledge of previous TE-LSP, not only for its stateful version [PCEP Extensions for Stateful PCE] [I-D.ietf-pce-stateful-pce], but also when performing a global concurrent optimization RFC5557 [RFC5557] of the previous TE-LSPs place on a given domain. Another source of information, mainly static information can be the management plane, e.g. using SNMP, CLI... So, it is necessary to classify the source of information by their frequency of update: static or dynamic, e.g. a domain ID is unlikely to change, while unreserved bandwidth of a link may be continuously changing. In this document, PCE Database (PCED) is used not only to refer to the standard Traffic Engineering Database information, but is extended to all pertinent information e.g. it also contains previous TE-LSPs establish in the domain and sometimes referred as LSP DB in other documents. 1.2. Terminology ABR: Area Border Routers. Routers used to connect two IGP areas (areas in OSPF or levels in IS-IS). ASBR: Autonomous System Border Router. Router used to connect together ASes of the same or different service providers via one or more inter-AS links. AS: Autonomous System Dugeon, et al. Expires January 16, 2014 [Page 4] Internet-Draft PCE TED Req. July 2013 Boundary Node (BN): a boundary node is either an ABR in the context of inter-area Traffic Engineering or an ASBR in the context of inter- AS Traffic Engineering. Domain: an Autonomous System Entry BN of domain(n): a BN connecting domain(n-1) to domain(n) along a determined sequence of domains. Exit BN of domain(n): a BN connecting domain(n) to domain(n+1) along a determined sequence of domains. Inter-area TE LSP: A TE LSP that crosses an IGP area boundary. Inter-AS TE LSP: A TE LSP that crosses an AS boundary. IGP-TE: Interior Gateway Protocol with Traffic Engineering support. Both OSPF-TE and IS-IS-TE are identified in this category. 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. PCE(i) is a PCE with the scope of domain(i). PCED: Path Computation Element Database TED: Traffic Engineering Database. 2. PCED Requirements This section made a first inventory of the main requirements of the PCED in term of information that the database should contains. 2.1. Intra-Domain This section describes the Intra-domain information that are suitable for the PCE Database including both MPLS and GMPLS. 2.1.1. MPLS A PCE is allowed to compute paths in one or several domains. Such PCE MUST be aware of the precise details of the network topology (or topologies) in order to compute optimal TE-LSP placements. The information needed in this case includes: o List of Internal Nodes identified by a reachable address: All nodes of the networks that are not border node, Dugeon, et al. Expires January 16, 2014 [Page 5] Internet-Draft PCE TED Req. July 2013 o List of Internal Links that rely nodes (both internal and border nodes), o Traffic Engineering information of the different links i.e. RFC 3630 [RFC3630] and RFC 5305 [RFC5305](with e.g. recent metric extensions proposal OSPF Traffic Engineering (TE) Metric Extensions [I-D.ietf-ospf-te-metric-extensions]) o Traffic Engineering information with GMPLS extensions of the different links i.e. RFC 4203 [RFC4203] and RFC 5307 [RFC5307], o Traffic Engineering information of the nodes. The information above mentioned is usually exchanged using the IGP-TE protocol (OSPF-TE or IS-IS-TE). 2.1.2. GMPLS To be provided later 2.2. Inter-Domain A PCE can also be allowed to take part to inter-domain path computation (e.g in per-domain path computation, BRPC or H-PCE relationship). Some inter-domain information is mandatory when operator intend to use the PCE to compute Inter-AS TE LSP path that cross domain boundary. For that purpose, the PCED SHOULD contains all information that allow the PCE to determine the optimal inter- domain path for the TE-LSP computation, which includes: o Border Nodes (BNs) of the foreign domain, o Links between BN, i.e. links between BN (n) to BN (n+1), including Traffic Engineering information, o Traffic Engineering performance between BN (n) to give performance indication on foreign domain n, o PCE (i) peer address associated with the domain number of the foreign domain (i), RFC 5316 [RFC5316] for IS-IS and RFC 5392 [RFC5392] for OSPF help to provide required PCED information in the case of inter-domain. PCED can also contain information about virtual links and abstract information. 2.3. TE LSPs Dugeon, et al. Expires January 16, 2014 [Page 6] Internet-Draft PCE TED Req. July 2013 For Stateful operation and Global Concurrent Optimization, the PCED should also contain information on TE-LSPs already enforce in the controlled domain. If some TE-LSP tunnels could be re-announce in the IGP-TE, the PCE could not learn from the IGP-TE all details of all TE LSPs: if TE information is known, detail of the ERO is lost as well as initial QoS parameters. The following information will be useful for the PCED to describe the TE-LSP: o Explicit Route Object (ERO), o End-points objects, o Initial and actual Metric objects, including extend metrics such as delay, jitter loss, Recent PCEP Extensions for Stateful PCE [I-D.ietf-pce-stateful-pce] provide new PCEP message to convey these kind of information. However, this capacity could be used disregarding the behavior (stateless or stateful) of the PCE. 2.4. Operational Information This part of the TED contains all others information pertinent for the PCE to compute TE LSP path but that are provided through the management system. 3. PCED model This section propose a basic model to store pertinent information regarding the different source of information. 3.1. Intra-domain 3.1.1. MPLS For intra-domain, there is no need to specify a particular model or schema for the PCED. Indeed, the model is directly based on the IGP- TE. Of course there is a difference between IS-IS and OSPF, but TE Link state are more of less similar in term of conveyed information and database description. No particular requirements are necessary as this stage. 3.1.2. GMPLS To be provided later. 3.2. Inter-domain Dugeon, et al. Expires January 16, 2014 [Page 7] Internet-Draft PCE TED Req. July 2013 Contrary to intra-domain where the PCE known the exact details of the underlying network, it is not possible to achieve a similar detail level for the inter-domain. And not only for scalability reasons, but mostly for confidentiality of the networks. This memo propose a basic schema that allows PCE to known sufficient details about the foreign domain while keeping confidential the internal information. For this purpose, we propose to describe a domain as a "Grey-Box" with inputs and outputs that correspond to the Border Nodes (BNs). Then Grey-Boxes are interconnected through inter-domain links between the BNs. Then, suitable performance indicators are given to cross the Grey-Boxes from an input BN to and output BN. Figure below gives as example of such model. +----------------+ +----------------+ | Domain (i) | | Domain (i+1) | Inter | | Inter | (BN)-- Inter Domain --(BN) | Domain | | Domain Link | (BN)--------(BN) (BN)-- Links | | Link | | +-----(BN)-------+ +----------------+ | | Inter-domain Link Example of the representation of 2 domains with the Grey-Box model With such inter-domain information, a PCE could look into the different inter-domain path (as the sum of inter-domain links and Grey-Box crossing performances) and select the most suitable one regarding the PCReq. If the inter-domain links between BN that connect the Grey-Boxes description are covered (see section 2.2), it is not the case for the internal links between BNs inside the Grey-Box. 4. PCED Population This section aims to provide best current practices when mechanisms are well-known and some hints when standard solutions exist to populate the PCE TED, and so give directions to extend them. In particular, we aim at providing input on whether the TED gets the information from the routing protocol and how it gets it, which specific routing protocols are suited, whether it gets it from an NMS, at what frequency the TED is updated... and if it needs extra information. 4.1. Intra-domain Dugeon, et al. Expires January 16, 2014 [Page 8] Internet-Draft PCE TED Req. July 2013 4.1.1. MPLS As the TED mainly contains the intra-domain topology graph, it is RECOMMENDED to link the PCE with the underlying IGP-TE (OSPF-TE or IS-IS-TE routing protocol). By adding the PCE into the IGP-TE routing intra-domain, it is possible to listen to the routing protocol and then acquired the complete topology graph as well as let the PCE announce itself (see RFC5088 and RFC5089). In addition, the TED will synchronize as fast as the routing protocol converges like any router in the domain. Best current practices are also of interest when a PCE compute path that spawn to several area / region. In that case, the PCE must be aware of the topology details of each area / region and not only the backbone area / region 1 with the summary of stub area / region 2. In addition, management tools may be used to complement the topology graph provided by the routing protocol. 4.1.2. GMPLS To be provided later. 4.2. Inter-Domain If for inter-area aspect of the inter-domain, actual IGP-TE protocol provide the aforementioned information without any particular extension, this is not the case for the inter-as scenario. First of all, RFC 5316 or RFC 5392 MUST be activated in the IGP-TE (respectively in IS-IS-TE or OSPF-TE) in order to advertise TE information on the inter-domain links. This give the advantage for the PCE to determine what could be feasible, during path computation, on the peering links. In MPLS, AS path and network reachability are obtained from BGP and routing tables. However, it is not straightforward to collect route diversity or TE information (i.e. bandwidth, transit delay, packet loss ratio, jitter ...) on a foreign domain. Right now, we have identified several methods, which have been tested to fill in the PCED with this kind of information: o Use of the management plane; o Use of the "North bound distribution of Link-State and TE Information using BGP" [I-D.ietf-idr-ls-distribution] proposal to exchange TE information about the foreign domain; Dugeon, et al. Expires January 16, 2014 [Page 9] Internet-Draft PCE TED Req. July 2013 o Use of PCNtf message to convey, inside vendor attribute (but in an extended way), TE information of foreign domain between PCE As well as some potential alternative mechanisms that would need more standardization effort: o A hierarchical TE that could help to advertise, at the AS level, TE information on an abstract/aggregate view of the foreign AS topology; o A PCEP extension to convey such TE information to the foreign PCE. 4.2.1. Information exchange The force of PCE is to be aware of the complete topology of the underlying network. With such knowledge, it could place efficiently the tunnel even if it not follows the route computed by the routing protocol. Same principles apply also for the inter-domain. But, in the Internet today, BGP summarize the route and the PCE should not be aware of the route diversity. In particular, it could not choose another AS path as the one selected and announced by BGP. In such case, the PCE will not be sufficiently aware of the route diversity and could not selected the optimal AS path when computing an inter- domain LSP. To avoid this and allows PCE known route diversity to reach a given foreign domain, the inter-domain information must be propagated between all PCEs without aggregation or summarization. In summary, PCEs need to synchronize part of their Database i.e. the inter-domain ones. Disregarding the protocol, two different solutions emerged to exchange inter-domain information: o Direct Distribution: Exchange TE information using BGP is part of this case. In this scenario, it is necessary to establish a BGP session between the different domains (whatever the platform used, a dedicated router, a PCE, another server ...). In the hierarchal PCE scenario, operators that provide child PCE, agree to establish a relation with foreign domain that provides the parent PCE. But, in BRPC, or in Hierarchical PCE where almost operators provide a parent PCE, BGP session must be establish between networks that have not necessary direct adjacency. However, operators should not agree to accept relation from other's not directly attached to their network. In addition, this scenario could conduct to establish a full mesh of BGP session between PCE which could lead into some scalability problems. o Flooding Distribution: In this case, the inter-domain information are flood between all PCE so that each PCE is aware about all foreign domain capabilities. This meets the requirement but doesn't provide the flexibility of BGP in term of filtering. Dugeon, et al. Expires January 16, 2014 [Page 10] Internet-Draft PCE TED Req. July 2013 Indeed, BGP allows through configuration to decide which information are announced and to whom. As a per session relation, a given operator is not oblige to announce the same capabilities to its foreign domain. With flooding distribution, where everybody redistribute what it has learned without modify it, it is not possible to specialize announcement based on foreign domain. So, the solution must provide the possibility to filter what is announce per foreign domain without authorized the summarization or aggregation while keeping a distributed relation between domains. In addition, a domain is responsible about the Grey-Box announcement and the advertisement information must not be modified by intermediate PCE. 4.3. TE-LSPs Up to know, the PCE could learn the tunnel already enforce in the controlled domain through dedicated NMS system. Recent works on state full extensions for PCEP propose to add new messages in order to collect information on TE-LSPs from the PCCs. 4.4. Operational information Most of the time operational information are provided through the management system of the operator, but some could be automatically discovered. In particular, in intra-domain, PCCs and PCEs can discover automatically reachable PCEs (as well as computation domains) through the deployment of RFC 5088 [RFC5088], for OSPF- controlled networks, and RFC 5089 [RFC5089] for IS-IS controlled networks. However, for the inter-PCE discovery at the inter-AS level, no mechanism has been standardized (unless ASes are owned by the same ISP). 5. IANA Considerations This document makes no request of IANA for the moment. Note to RFC Editor: this section may be removed on publication as an RFC. 6. Security Considerations Acquisition of information for the PCE TED is of course sensible from a security point of view, especially when acquiring information from others AS. This section aims at providing best practices to prevent some security threat when the PCE try to acquire TED information. Dugeon, et al. Expires January 16, 2014 [Page 11] Internet-Draft PCE TED Req. July 2013 6.1. Intra-domain information Same security considerations must be applied to the PCE when it is connected to an IGP-TE protocol as the routing protocol itself. Best practices observed and deployed by operators must also be taken into account when installing some PCEs. Indeed, even when deployed as a standalone server, PCEs must be considered as a typical router from the IGP-TE perspective. As a result, beyond OSPF or IS-IS themselves, the usual security rules must be applied, e.g. login/ passwd, authentication/digest... to protect the connectivity. 6.2. Inter-domain information Inter-domain relation and so information exchange are subject to high potential hijack and so need attention from the security point of view. To avoid disclosing or expose confidential information that two operators would exchange to fill in the TEDs of their respective PCEs, the relation SHOULD be protected by standard cryptography mechanism. E.g. using IPsec tunnel is RECOMMENDED to protect the connectivity between PCEs and the TED exchanges. 6.3. Operational information All operational information like PCE peer addresses are generally added manually to the TED and so do not need any particular protection nor subject to security. But, as this basic information is needed to connected the PCEs to their peers, it could potentially be associated to sensitive parameters like login and password. So, standard Best Practices are RECOMMENDED to avoid basic security exposition. 7. Acknowledgements The authors want to thanks PCE's WG members and in particular Daniel King for their inputs of this subject. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006. Dugeon, et al. Expires January 16, 2014 [Page 12] Internet-Draft PCE TED Req. July 2013 [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, March 2009. [RFC5441] Vasseur, JP., Zhang, R., Bitar, N., and JL. Le Roux, "A Backward-Recursive PCE-Based Computation (BRPC) Procedure to Compute Shortest Constrained Inter-Domain Traffic Engineering Label Switched Paths", RFC 5441, April 2009. 8.2. Informative References [I-D.ietf-idr-ls-distribution] Gredler, H., Medved, J., Previdi, S., Farrel, A., and S. Ray, "North-Bound Distribution of Link-State and TE Information using BGP", draft-ietf-idr-ls-distribution-03 (work in progress), May 2013. [I-D.ietf-ospf-te-metric-extensions] Giacalone, S., Ward, D., Drake, J., Atlas, A., and S. Previdi, "OSPF Traffic Engineering (TE) Metric Extensions", draft-ietf-ospf-te-metric-extensions-04 (work in progress), June 2013. [I-D.ietf-pce-stateful-pce] Crabbe, E., Medved, J., Minei, I., and R. Varga, "PCEP Extensions for Stateful PCE", draft-ietf-pce-stateful- pce-05 (work in progress), July 2013. [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003. [RFC4203] Kompella, K. and Y. Rekhter, "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4203, October 2005. [RFC5088] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, "OSPF Protocol Extensions for Path Computation Element (PCE) Discovery", RFC 5088, January 2008. [RFC5089] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, "IS-IS Protocol Extensions for Path Computation Element (PCE) Discovery", RFC 5089, January 2008. [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, October 2008. Dugeon, et al. Expires January 16, 2014 [Page 13] Internet-Draft PCE TED Req. July 2013 [RFC5307] Kompella, K. and Y. Rekhter, "IS-IS Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 5307, October 2008. [RFC5316] Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering", RFC 5316, December 2008. [RFC5392] Chen, M., Zhang, R., and X. Duan, "OSPF Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering", RFC 5392, January 2009. [RFC5557] Lee, Y., Le Roux, JL., King, D., and E. Oki, "Path Computation Element Communication Protocol (PCEP) Requirements and Protocol Extensions in Support of Global Concurrent Optimization", RFC 5557, July 2009. [RFC6805] King, D. and A. Farrel, "The Application of the Path Computation Element Architecture to the Determination of a Sequence of Domains in MPLS and GMPLS", RFC 6805, November 2012. Authors' Addresses Olivier Dugeon Orange Labs 2, Avenue Pierre Marzin Lannion 22307 France Email: olivier.dugeon@orange.com Julien Meuric Orange Labs 2, Avenue Pierre Marzin Lannion 22307 France Email: julien.meuric@orange.com Dugeon, et al. Expires January 16, 2014 [Page 14] Internet-Draft PCE TED Req. July 2013 Richard Douville Alcatel-Lucent Route de Villejust Nozay 91620 France Email: richard.douville@alcatel-lucent.com Ramon Casellas CTTC Av. Carl Friedrich FGauss n7 Castelldefels, Barcelona 08860 Spain Email: ramon.casellas@cttc.es Oscar Gonzalez de Dios Telefonica Investigacion y Desarrollo C/ Emilio Vargas 6 Madrid Spain Email: ogondio@tid.es Dugeon, et al. Expires January 16, 2014 [Page 15]