Internet DRAFT - draft-dugeon-pce-ted-reqs
draft-dugeon-pce-ted-reqs
Path Computation Element Working Group O. Dugeon
Internet-Draft J. Meuric
Intended status: Informational Orange
Expires: August 18, 2014 R. Douville
Alcatel-Lucent
R. Casellas
CTTC
O. Gonzalez de Dios
Telefonica Investigacion y Desarrollo
February 14, 2014
Path Computation Element (PCE) Database Requirements
draft-dugeon-pce-ted-reqs-03
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 August 18, 2014 [Page 1]
Internet-Draft PCE TED Req. February 2014
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 August 18, 2014.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3
1.1. PCE Assumption and Hypothesis . . . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2. PCE DataBase Requirements . . . . . . . . . . . . . . . . . . 6
2.1. Intra-Domain . . . . . . . . . . . . . . . . . . . . . . 6
2.1.1. MPLS . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.2. GMPLS . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2. Inter-Domain . . . . . . . . . . . . . . . . . . . . . . 7
2.3. TE LSPs . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4. Operational Information . . . . . . . . . . . . . . . . . 8
3. PCE-DB model . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1. Intra-domain . . . . . . . . . . . . . . . . . . . . . . 8
3.1.1. MPLS . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1.2. GMPLS . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2. Inter-domain . . . . . . . . . . . . . . . . . . . . . . 8
4. PCE-DB Population . . . . . . . . . . . . . . . . . . . . . . 10
4.1. Intra-domain . . . . . . . . . . . . . . . . . . . . . . 10
4.1.1. MPLS . . . . . . . . . . . . . . . . . . . . . . . . 10
4.1.2. GMPLS . . . . . . . . . . . . . . . . . . . . . . . . 11
4.2. Inter-Domain . . . . . . . . . . . . . . . . . . . . . . 11
4.2.1. Information exchange . . . . . . . . . . . . . . . . 12
Dugeon, et al. Expires August 18, 2014 [Page 2]
Internet-Draft PCE TED Req. February 2014
4.3. TE-LSPs . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.4. Complementary information . . . . . . . . . . . . . . . . 13
4.5. Operationnal and synchronisation constraints . . . . . . 13
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
6.1. Intra-domain information . . . . . . . . . . . . . . . . 14
6.2. Inter-domain information . . . . . . . . . . . . . . . . 15
6.3. Operational information . . . . . . . . . . . . . . . . . 15
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.1. Normative References . . . . . . . . . . . . . . . . . . 15
8.2. Informative References . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
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
Dugeon, et al. Expires August 18, 2014 [Page 3]
Internet-Draft PCE TED Req. February 2014
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:
o The intra-domain routing protocol like OSPF-TE or IS-IS-TE
(including extensions for inter-domain links),
o The inter-domain routing protocol, i.e. BGP,
o TED synchronization protocols, e.g., BGP-LS,
o 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"
[I-D.ietf-idr-ls-distribution]. 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]
[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.
Dugeon, et al. Expires August 18, 2014 [Page 4]
Internet-Draft PCE TED Req. February 2014
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.
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
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 or IGP Area
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.
Dugeon, et al. Expires August 18, 2014 [Page 5]
Internet-Draft PCE TED Req. February 2014
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 Base
TED: Traffic Engineering Database.
2. PCE DataBase Requirements
This section made a first inventory of the main requirements of the
PCE Data Base 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 with a particular mention for border node
(see next section),
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 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
Dugeon, et al. Expires August 18, 2014 [Page 6]
Internet-Draft PCE TED Req. February 2014
When dealing with a (G)MPLS network, the PCE MUST be aware of the
complementary information:
o Traffic Engineering information with GMPLS extensions of the
different links i.e. RFC 4203 [RFC4203] and RFC 5307 [RFC5307],
To be completed latter
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 PCE-DB 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 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.
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 remote domain n (See section 3.2 on PCE-DB model for
the inter-domain part)
o PCE (i) peer address associated with the domain number and
identity of the remote domain (i),
RFC 5316 [RFC5316] for IS-IS and RFC 5392 [RFC5392] 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.
2.3. TE LSPs
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:
Dugeon, et al. Expires August 18, 2014 [Page 7]
Internet-Draft PCE TED Req. February 2014
o Explicit Route Object (ERO),
o End-points objects,
o Initial and actual Metric objects, including extend metrics such
as delay, jitter, packet 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. Indeed, if it is mandatory for
stateful PCE, these information are of great importance then
performing Global Concurrent Optimization, even with a stateless PCE.
2.4. Operational Information
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.
3. PCE-DB model
This section inventory the database model(s) 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 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.
3.1.2. GMPLS
To be provided later.
3.2. Inter-domain
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.
Dugeon, et al. Expires August 18, 2014 [Page 8]
Internet-Draft PCE TED Req. February 2014
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 (B) | | Domain (C) |
Inter | | Inter | (BN)-- Inter
Domain --(BN) | Domain | | Domain
Link | (BN)--------(BN) (BN)-+ Links
| | Link | | |
+-----(BN)-------+ +----------------+ |
| |
| Inter-domain Link |
+-----(BN)-------+ +------(BN)------+ |
| Domain (A) | | Domain (D) | |
Inter | | Inter | (BN)-+ Inter
Domain --(BN) | Domain | | Domain
Link | (BN)--------(BN) (BN)-- Links
| | Link | |
+-----(BN)-------+ +----------------+
|
| Inter-domain Link
Example of the representation of 3 domains with the Grey-Box 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):
o Crossing B cost 100, D cost 50, C cost 75, A cost 50
o Inter-domain links costs: A to B = 10, B to C = 20, A to D = 10, D
to C = 50
PCE 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.
Dugeon, et al. Expires August 18, 2014 [Page 9]
Internet-Draft PCE TED Req. February 2014
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.
4. PCE-DB 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
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.
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"
[I-D.ietf-idr-ls-distribution]. 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.
Dugeon, et al. Expires August 18, 2014 [Page 10]
Internet-Draft PCE TED Req. February 2014
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 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" [I-D.farrel-interconnected-te-info-exchange].
Right now, we have identified several methods, which have been tested
to fill in the PCE-DB 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 remote domain;
o Use of PCNtf message to convey, inside vendor attribute (but in an
extended way), TE information of remote domain between PCE
Dugeon, et al. Expires August 18, 2014 [Page 11]
Internet-Draft PCE TED Req. February 2014
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 view of the remote AS topology;
o A PCEP extension to convey such TE information to the remote PCE.
4.2.1. Information exchange
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:
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 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.
o 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,
Dugeon, et al. Expires August 18, 2014 [Page 12]
Internet-Draft PCE TED Req. February 2014
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.
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. Complementary information
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
[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).
4.5. Operationnal and synchronisation constraints
Even if acquired TE information is solved, it remains two major
problems from an operational point of view.
Dugeon, et al. Expires August 18, 2014 [Page 13]
Internet-Draft PCE TED Req. February 2014
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" [I-D.clemm-netmod-yang-network-topo] is
mandatory from an operation point of view to allow automatic tools
easily configure the TE parameters of a network on the routers.
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.
6.1. Intra-domain information
Dugeon, et al. Expires August 18, 2014 [Page 14]
Internet-Draft PCE TED Req. February 2014
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.
[RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element
(PCE) Communication Protocol (PCEP)", RFC 5440, March
2009.
Dugeon, et al. Expires August 18, 2014 [Page 15]
Internet-Draft PCE TED Req. February 2014
[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.clemm-netmod-yang-network-topo]
Clemm, A., Ananthakrishnan, H., Medved, J., Tkacik, T.,
Varga, R., and N. Bahadur, "A YANG Data Model for Network
Topologies", draft-clemm-netmod-yang-network-topo-01 (work
in progress), October 2013.
[I-D.farrel-interconnected-te-info-exchange]
Farrel, A., Drake, J., Bitar, N., Swallow, G., and D.
Ceccarelli, "Problem Statement and Architecture for
Information Exchange Between Interconnected Traffic
Engineered Networks", draft-farrel-interconnected-te-info-
exchange-02 (work in progress), October 2013.
[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-04
(work in progress), November 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-05 (work
in progress), December 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-08 (work in progress), February 2014.
[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.
Dugeon, et al. Expires August 18, 2014 [Page 16]
Internet-Draft PCE TED Req. February 2014
[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.
[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
2, Avenue Pierre Marzin
Lannion 22307
France
Email: olivier.dugeon@orange.com
Julien Meuric
Orange
2, Avenue Pierre Marzin
Lannion 22307
France
Email: julien.meuric@orange.com
Dugeon, et al. Expires August 18, 2014 [Page 17]
Internet-Draft PCE TED Req. February 2014
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 August 18, 2014 [Page 18]
