| Path Computation Element Working Group | O.D. Dugeon |
| Internet-Draft | J. Meuric |
| Intended status: Informational | Orange Labs |
| Expires: September 04, 2012 | March 5, 2012 |
Path Computation Element (PCE) Traffic Engineering Database (TED) Requirements
draft-dugeon-pce-ted-reqs-00
During the past 4 years, Path Computation Element (PCE) WG has produced a set of RFCs to standardize the behavior of the Path Computation Element as a tool to help MPLS-TE LSP tunnels placement. In the PCE architecture, a main assumption has been done concerning the information that the PCE needs to perform its computation: the Traffic Engineering Database (TED) contains all pertinent and suitable information regarding the networks that is in the scope of a PCE. Nevertheless, requirements and inventory of TED information have not been formalized. In addition, some recent RFC (like BRPC RFC 5441) or WG draft (like draft-ietf-pce-hierarchy ...) suffer from a lack of information coming from the TED resulting to a non optimal result or some difficulties to deploy them. This memo tries to identity all TED requirements for the PCE as well as provides some helps to operators to fulfill the PCE TED.
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].
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 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 September 04, 2012.
Copyright (c) 2012 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.
Looking to the different RFCs that describe the PCE architecture and in particular RFC 4655 [RFC4655], RFC 5440 [RFC5440] and RFC 5441 [RFC5441] as well as the draft H-PCE [I-D.ietf-pce-hierarchy-fwk], the Path Computation Element (PCE) need to acquire a set of information that are 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 listen to the IGP-TE protocol that runs inside the network), inter-domain topology information, PCE peer address, neighbor AS ... that are necessary for the Backward Recursive Path Computation (BRPC) and the Hierarchical PCE are not documented and not well standardized.
The purpose of this memo is to inventory the required information that should be part of the PCE TED and the different mechanism that allow an operator to fulfill it.
In some cases both functions (path computation and TED management) are slightly coupled: border node identification, endpoint localization and topology aggregation for 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 for the multidomain problem. The PCE is scoped for any kind of network, from transport networks (TDM/WDM) with a rather limited number of domains, few interconnections, and few confidentiality issues, transport 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 perfect 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 MPLS-TE LSP placement over the networks the PCE controls or a set of domains through BRPC algorithm. We could identify two major sources of information for the TED:
If the first source gives a precise and synchronize view of the controlled network, BGP just provides network reachability with only one AS path (unless using recent add path option). Nevertheless, to optimize inter-domain path computation, like BRPC, route diversity and a minimum set of Traffic Engineering information about the foreign domains could be helpful.
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
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 indentify 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).
TED: Traffic Engineering Database.
This section made a first inventory of the main requirements of the PCE TED in term of information that the database should contains
This section describes the IP layer information that are suitable for the PCE TED.
This is the main part of the TED. As the PCE controls the underlying networks, it MUST be aware of the precise details of the networks topology in order to compute the optimal Inter-area TE LSP path. For that purpose, the TED MUST contains all information that allow the PCE to reconstitute the topology graph of the networks and at least:
All these information are exchange between the IGP-TE protocol (OSPF-TE or IS-IS-TE).
Inter-domain information are mandatory when operator intend to use the PCE to compute Inter-AS TE LSP path that cross AS boundary. For that purpose, the TED SHOULD contains all information that allow the PCE to determine the optimal AS path for the MPLS-TE LSP computation and at least:
Unfortunately, only RFC 5316 and RFC 5392 could help to provide required TED information in the case of inter-domain.
To be provided latter.
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 aims to provide Best Current Practices when mechanisms are well-known and some hints when to standard solution exists to manage the PCE TED, and so give help to fulfill it.
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 configuring the PCE as a source sink only, it is possible to listen to the routing protocol and then acquired the complete topology graph. In addition, the TED will synchronize as fast as the routing protocol converges like any router in the domain.
In addition, management tools like network vendors management system SHOULD be used to complement the topology graph provided by the routing protocol.
First of all, RFC 5316 and RFC 5392 MUST be activated in the IGP-TE (respectively in IS-IS-TE and OSPF-TE) in order to collect 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.
AS path and network reachability are of course obtain from the BGP and routing tables. But, it is not possible to collect neither route diversity nor TE information on foreign domain.
So, the main part of the inter-domain topology, like route diversity and TE information (i.e. transit delay, packet loss ratio, transit jitter ...) on a foreign domain could not be obtain easely. Right now, we have identified several know methods to fulfill the TED with these kind of information:
As well as some potential new mechanisms that needs some standardization effort:
To be provided latter.
Most of the time operationals information are provided through the management system of the operator. But some could be automatically discovered. In particular, in intra-domain, PCE could discover automatically its peer through the deployment of RFC
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 a PCE. In fact, the PCE itself, when deployed as a standalone server, must be considered as a standard router regarding the IGP-TE. So, disregarding OSPF or IS-IS, same security rules must be app lied e.g. login/passwd 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 fulfil the TED of their respective PCE, the relation SHOULD be protected by standard cryptography mechanism. E.g. using IPsec tunnel is RECOMMENDED to protect the connectivity between PCE and TED exchange.
All operational information like PCE peer addresses are generaly added manually to the TED and so don't need any particular protection nor subject to security. But, as these based information are needed to let PCE connected to its peers, is could potentially contains sensitive parameters like login and password. So, standard Best Practices are RECOMMENEDED to avoid basic security exposition.
The authors want to thanks PCE's WG members and in particular Ramon Casellas, Oscar Gonzalez de Dios and Daniel King for their inputs of this subject.
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |
| [RFC4655] | Farrel, A., Vasseur, J.-P. 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. |
| [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. |