Path Computation Element (PCE) Database
RequirementsOrange2, Avenue Pierre MarzinLannion22307Franceolivier.dugeon@orange.comOrange2, 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
several major sources of information for the TED:The intra-domain routing protocol like OSPF-TE or IS-IS-TE
(including extensions for inter-domain links),The inter-domain routing protocol, i.e. BGP,TED synchronization protocols, e.g., BGP-LS,Through manual and or management configuration.If the first source gives a precise and synchronize view of
the controlled network, i/eBGP typically just provides network
reachability with only one AS path (unless using recent add path
option). Now, the TE information traditionally flooded by the IGPs can
also be communicated through a BGP sessions, as described in "North bound distribution of
Link-State and TE Information using BGP". Nevertheless, to
optimize inter-domain path computation, route diversity and a minimum
set of Traffic Engineering information about the remote 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.The last source of information, mainly static, information can be
the management plane, e.g. using SNMP, Netconf, 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. Finally,
all sources of information are pertinent and must be take into account
to fulfil the PCE database at large.In this document, PCE Data Base (namely PCE-DB in the rest of the
document) is used not only to refer to the usual notion of Traffic
Engineering Database information, but also encompasses all relevant
information. E.g., the phrase also refers to the list of TE-LSPs running in
the domain, sometimes referred as LSP-DB in other documents. Note that this
PCE-DB may be implemented over multiple independant DBs.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 System or IGP AreaEntry 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).PCE-DB: Path Computation Element Data BaseTED: Traffic Engineering Database.This section made a first inventory of the main requirements of the
PCE Data Base 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 with a particular mention for border node
(see next section),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 of the nodes.The information above mentioned is usually exchanged using the
IGP-TE protocol (OSPF-TE or IS-IS-TE).When dealing with a (G)MPLS network, the PCE MUST be aware of the
complementary information:Traffic Engineering information with GMPLS extensions of the
different links i.e. RFC 4203 and
RFC 5307,To be completed latterA 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 PCE-DB 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 domain. A distinction could be made
between ALL domains and Neighbor domains only. In the document, we
consider ALL domains to be sure that the PCE has the complete
visibility of the path diversity.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 remote domain n (See section 3.2 on
PCE-DB model for the inter-domain part)PCE (i) peer address associated with the domain number and
identity of the remote domain (i),RFC 5316 for IS-IS and RFC 5392 for OSPF help to provide required
PCE-DB information in the case of inter-domain. PCE-DB can also
contain information about virtual links and abstract information.For stateful operation and Global Concurrent Optimization, the
PCE-DB 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 PCE-DB to describe the TE-LSP:Explicit Route Object (ERO),End-points objects,Initial and actual Metric objects, including extend metrics
such as delay, jitter, packet 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. Indeed, if it is
mandatory for stateful PCE, these information are of great importance
then performing Global Concurrent Optimization, even with a stateless
PCE.This part of the TED contains all others information, and in
particular the PCE policy, pertinent for the PCE to compute TE LSP
path but that are provided through the management system.This section inventory the database model(s) 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 PCE-DB. 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 remote
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 C is reachable from domain A through domain B or domain D.
For a PCE, with such model, it becomes easy to compute a constraint
shortest path by combining the resources availability on Inter-Domain
links and cost to cross the different domain. For example, with these
figures (note that we take only one measured to illustrate the purpose
and that multiple constraints are used in reality):Crossing B cost 100, D cost 50, C cost 75, A cost 50Inter-domain links costs: A to B = 10, B to C = 20, A to D =
10, D to C = 50PCE A could not choose between B or D as the Inter-domain
link costs are equal. With the proposed model, it could compute that
going through B cost 130 (= 10 + 100 20) and through D cost 110 (= 10
+ 50 + 50) and choose D path even if the last Inter-domain links is
costly.Today, when trying to compute an inter-domain TE LSP, the PCE may
failed in its computation and used crank back facilities to find a
suitable path. 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 avoiding crank back and achieve possibly, better
results as it explore all possible inter-domain paths.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.Note that linking the PCE with the underlying IGP-TE may also be
accomplished through receiving BGP-LS updates as described in "North bound distribution of
Link-State and TE Information using BGP". Although joining
the IGP is good enough, BGP-LS is not precluded for use intra-domain
and can be a nice way to have a uniform mechanism to acquire the TED
e.g. from a Route Reflector that also listen to the IGP.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 protocol
provide in general the aforementioned information without any
particular extension, this is not the case for the inter-as scenario
and sometimes an issue for inter-area.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 gives 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. In addition, domain or sequence path could be
specified in the PCE Request. However, when inter-domain path is not
known or could not retrieve from an external entities, it could be of
interest for a PCE to have the possibility to compute the inter-domain
path prior to the intra-domain part. Again, the PCE needs
corresponding information in its PCE-DB. But, it is not
straightforward to collect route diversity or TE information (i.e.
bandwidth, transit delay, packet loss ratio, jitter ...) on a remote
domain. Of course, for confidentiality and scalability issues, the PCE
MUST NOT learn all details of the remote TED, it just needs an
abstract view like proposed in "Problem Statement
and Architecture for Information Exchange Between Interconnected
Traffic Engineered Networks".Right now, we have identified several methods, which have been
tested to fill in the PCE-DB 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 remote
domain;Use of PCNtf message to convey, inside vendor attribute (but in
an extended way), TE information of remote 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 view of the remote AS
topology;A PCEP extension to convey such TE information to the remote
PCE.The force of PCE is to be aware of the complete topology of the
underlying network where it is connected. With such knowledge, it
could place efficiently the tunnel even if it not follows the route
computed by the IGP 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. A way to bypass this restriction is to specify
the AS-path in the PCE Request IRO. In all other cases, the PCE will
not be sufficiently aware of the route diversity and can not
select the optimal AS path when computing an inter-domain LSP. To
avoid this and allow PCE to know route diversity to reach a given
remote 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 part. 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 remote 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 remote 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 remote domain. With flooding distribution,
where everybody redistribute what it has learned without modify
it, it is not possible to specialize announcement based on
remote domain.So, the solution must provide the possibility to filter
what is announce per remote 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, static information, including PCE Policy, are
provided through the management system of the operator or by means of
static configuration (e.g. command line option, configuration file
...), 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).Even if acquired TE information is solved, it remains two major
problems from an operational point of view.First of all, the PCE-DB MUST be synchronised with the underlying
network topology. This synchronisation is not only mandatory for the
efficiency of the answer of the PCE, but more to handle the graceful
restart step of the PCE as well as crash situation. Indeed, for divert
reasons (maintenance, scheduled operation, failure ...), when the PCE
start or restart, it MUST acquired the information of the PCE-DB and
then maintain it synchronised to the underlying network. For the
stateful version of the PCE, this synchronisation is mandatory as
TE-LSP tunnel could be setup manually or by the management plane
independently from the PCE. But, the PCE MUST be aware of them as well
as when the PCE restart is MUST be aware of TE-LSP it previously
setup.The second point come from the distributed nature of the TED
information located in the underlying network. Indeed, TE information
are not located in one place, but distributed amongst all the router
of the network. Each router manage its links, and, consequently, the
TE information attached to these links. Thus, modifying a TE
information on large scale network could become quickly a nightmare
for operational without any tools to help them. For that purpose, a TE
Netconf model like proposed in "A YANG Data Model for
Network Topologies" is mandatory from an operation point of
view to allow automatic tools easily configure the TE parameters of a
network on the routers.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.