Path Computation Element (PCE) Database
RequirementsOrange Labs2, Avenue Pierre MarzinLannion22307Franceolivier.dugeon@orange.comOrange Labs2, Avenue Pierre MarzinLannion22307Francejulien.meuric@orange.comAlcatel-LucentRoute de VillejustNozay91620Francerichard.douville@alcatel-lucent.comCTTCAv. Carl Friedrich FGauss n7CastelldefelsBarcelona08860Spainramon.casellas@cttc.esTelefonica Investigacion y DesarrolloC/ Emilio Vargas 6MadridSpainogondio@tid.es
Routing Area
Path Computation Element Working GroupDraftThe 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.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.Looking to the different RFCs that describe the PCE architecture and
in particular RFC 4655, RFC 5440, RFC
5441 and RFC 6805, 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.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.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:The intra-domain routing protocol like OSPF-TE or IS-IS-TE
(including extensions for border links),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], but also when performing a global concurrent
optimization 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.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 SystemBoundary 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 SystemEntry 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 DatabaseTED: Traffic Engineering Database.This section made a first inventory of the main requirements of the
PCED in term of information that the database should contains.This section describes the Intra-domain information that are
suitable for the PCE Database including both MPLS and GMPLS.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:List of Internal Nodes identified by a reachable address: All
nodes of the networks that are not border node,List of Internal Links that rely nodes (both internal and
border nodes),Traffic Engineering information of the different links i.e.
RFC 3630 and RFC 5305(with e.g. recent metric
extensions proposal OSPF Traffic
Engineering (TE) Metric Extensions)Traffic Engineering information with GMPLS extensions of the
different links i.e. RFC 4203 and
RFC 5307,Traffic Engineering information of the nodes.The information above mentioned is usually exchanged using the
IGP-TE protocol (OSPF-TE or IS-IS-TE).To be provided laterA 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:Border Nodes (BNs) of the foreign domain,Links between BN, i.e. links between BN (n) to BN (n+1),
including Traffic Engineering information,Traffic Engineering performance between BN (n) to give
performance indication on foreign domain n,PCE (i) peer address associated with the domain number of the
foreign domain (i),RFC 5316 for IS-IS and RFC 5392 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.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:Explicit Route Object (ERO),End-points objects,Initial and actual Metric objects, including extend metrics
such as delay, jitter loss,Recent PCEP Extensions for
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.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.This section propose a basic model to store pertinent information
regarding the different source of information.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.To be provided later.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.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. 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.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.To be provided later.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:Use of the management plane;Use of the "North
bound distribution of Link-State and TE Information using
BGP" proposal to exchange TE information about the foreign
domain;Use of PCNtf message to convey, inside vendor attribute (but in
an extended way), TE information of foreign domain between PCEAs well as some potential alternative mechanisms that would
need more standardization effort:A hierarchical TE that could help to advertise, at the AS
level, TE information on an abstract/aggregate view of the foreign
AS topology;A PCEP extension to convey such TE information to the foreign
PCE.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: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.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. 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.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.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, for
OSPF-controlled networks, and RFC 5089
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).This document makes no request of IANA for the moment.Note to RFC Editor: this section may be removed on publication as an
RFC.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.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.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.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.The authors want to thanks PCE's WG members and in particular Daniel
King for their inputs of this subject.