PCE TED Alternatives

Alternative Approaches to Traffic Engineering Database Creation and Maintenance for Path Computation Elements

Abstract

Path Computation Elements (PCEs) require an accurate and timely Traffic Engineering Database (TED). Traditionally this TED has been obtained from a link state routing protocol supporting traffic engineering extensions. This document discusses possible alternatives and enhancements to such an approach and their potential impacts on network nodes, routing protocols, and PCEs.
 

Background

In Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS), a traffic engineering database (TED) is used in computing paths for connection oriented packet services and for circuits. The TED contains all relevant information that a Path Computation Element (PCE) needs to perform its computations. It is important that the TED be complete and accurate at the time of the computation.

In MPLS and GMPLS, interior gateway routing protocols (IGPs) have been used to create and maintain a copy of the TED at each node running the IGP. One of the benefits of the PCE architecture [RFC4655] is the advantages of computationally more sophisticated path computation algorithms and the realization that these may need enhanced processing power not necessarily available at each node participating in an IGP.

Section 4.3 [RFC4655] describes the potential load of the TED on a network node and proposes an architecture where the TED is maintained by the PCE rather than the network nodes. What isn't discussed is how a PCE would obtain the information needed to populate its TED. In this document we propose approaches for creating and maintaining the TED on a PCE and look at the impacts from the PCE, IGP, and node perspective.  

 Status

This revision addresses some questions/issues from the last IETF meeting in San Francisco (March 2009) and provides further motivation from the area of impairment aware routing and wavelength assignment for optical networks.