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]