Architecture for Interdomain MPLSGMPLS Traffic Engineering Overview and Performance

Please direct questions to archives@
Path-Computation-Element-Based Architecture for Interdomain MPLS/GMPLS Traffic Engineering: Overview and Performance
College of Engineering
Drexel E-Repository and Archive (iDEA) /
Drexel University Libraries
The following item is made available as a courtesy to scholars by the author(s) and Drexel University Library and may contain materials and content, including computer code and tags, artwork, text, graphics, images, and illustrations (Material) which may be protected by copyright law. Unless otherwise noted, the Material is made available for non profit and educational purposes, such as research, teaching and private study. For these limited purposes, you may reproduce (print, download or make copies) the Material without prior permission. All copies must include any copyright notice originally included with the Material. You must seek permission from the authors or copyright owners for all uses that are not allowed by fair use and other provisions of the U.S. Copyright Law. The responsibility for making an independent legal assessment and securing any necessary permission rests with persons desiring to reproduce or use the Material.
ቤተ መጻሕፍቲ ባይዱ
W
ith ever increasing requirements posed by significant advances in networking, service providers may use traffic engineering (TE) techniques to efficiently manage resources and provide consistent quality of service (QoS). Traffic engineering in multiprotocol label switching (MPLS) and generalized MPLS (GMPLS) networks are fundamentally based on constraint-based path computation. Briefly, constraint-based path computation involves the pruning of links that do not satisfy constraints and subsequently using the shortest path algorithm on the resulting subgraph [1]. This process is simple and efficient when the path involves only one domain, but can potentially become severely resource heavy, complex, and inefficient when multiple domains are involved. To address this problem, the Path Computation Element (PCE) Working Group (WG) of the Internet Engineering Task Force (IETF) has been developing an architecture that will allow multidomain path computation to be simple and efficient. The PCE architecture introduces a special computational entity that will cooperate with similar entities to compute the best possible path through multiple domains. A PCE is a node that has special path computation ability and receives path computation requests from entities known as path computation clients (PCCs). The PCE holds limited routing information from other domains, allowing it to possibly compute better and shorter interdomain paths than those obtained using the traditional per-domain approach. Among other purposes, PCEs are also being advocated for CPU-intensive computations, minimal-cost- based TE-LSP placement, backup path computations, and bandwidth protection. Along with the process
Sukrit Dasgupta and Jaudelice C. de Oliveira, Drexel University Jean-Philippe Vasseur, Cisco Systems Abstract
The Path Computation Element Working Group at the Internet Engineering Task Force is chartered to specify a PCE-based architecture for the path computation of interdomain MPLS- and GMPLS-based traffic engineered label switched paths. In this architecture, path computation does not occur at the head-end LSR, but on another path computation entity that may not be physically located on the headend LSR. This method is greatly different from the traditional “per-domain” approach to path computation. This article presents analysis and results that compare performance of the PCE architecture with the current state-of-the-art approach. Detailed simulations are undertaken on varied and realistic scenarios where preliminary results show several performance benefits from the deployment of PCE. To provide a complete overview of significant development taking place in this area, milestones and progress at the IETF PCE WG are also discussed.
of identifying the requirements and development of the architecture accordingly, a plethora of work is underway at the PCE WG on the new communication protocols that will make this architecture work. This includes the development of new interPCE communication protocols and introducing extensions to existing underlying routing protocols. Request for Comments (RFC) 4655 [2] specifies a PCE-based architecture. RFC 4657 [3] covers PCE communication protocol generic requirements, and RFC 4674 [4] discusses the requirements for PCE discovery. Several WG IETF drafts are currently underway to define PCE communication protocol in different scenarios, PCE-based interlayer TE, protocol extensions for Open Shortest Path First (OSPF) and Intermediate System to Intermediate System (ISIS) for PCE discovery, PCC-PCE communication, and policyenabled path computation. As is evident, a thorough performance study to justify and quantify the motivation for this new architecture is required. As the architecture is in its infancy, a detailed analysis comparing existing approaches to a PCE-based approach has never been undertaken. This article has been written with two goals in mind. First, it presents a brief review of the significant developments that have taken place in the PCE WG since it was conceived in the IETF. Second, it identifies the most significant performance metrics, and then presents detailed simulation results and accompanying analysis to contrast the performance of the existing approach with that of the PCE. The rest of the article is organized as follows. Several scenarios that motivate the use of a PCE-based architecture are highlighted. The PCE architecture is described. The two path computation approaches to be compared, PCE-based and per