Multi-partner Demonstration of BGPLS enabled multi-domain EON control and instantiation with H-PCE

The control of multidomain elastic optical networks (EONs) is possible by combining Hierarchical Path Computation Element (H-PCE)-based computation, Border Gateway Protocol with Extensions for Traffic Engineering Link State Information (BGP-LS) topology discovery, remote instantiation via Path Computation Element Communication Protocol (PCEP), and signaling via Resource Reservation Protocol with Extensions for Traffic Engineering (RSVP-TE). Two evolutionary architectures are considered, one based on stateless H-PCE, PCEP instantiation, and end-to-end RSVP-TE signaling (SL-E2E), and a second one based on stateful active H-PCE with per-domain instantiation and stitching. This paper presents the first multiplatform demonstration that fully validates both control architectures achieving multiprotocol interoperability. SL-E2E leads to slightly faster provisioning but needs to keep the state of the stitching of the end-to-end label-switched paths in the parent PCE

A Survey on the Contributions of Software-Defined Networking to Traffic Engineering

Since the appearance of OpenFlow back in 2008, software-defined networking (SDN) has gained momentum. Although there are some discrepancies between the standards developing organizations working with SDN about what SDN is and how it is defined, they all outline traffic engineering (TE) as a key application. One of the most common objectives of TE is the congestion minimization, where techniques such as traffic splitting among multiple paths or advanced reservation systems are used. In such a scenario, this manuscript surveys the role of a comprehensive list of SDN protocols in TE solutions, in order to assess how these protocols can benefit TE. The SDN protocols have been categorized using the SDN architecture proposed by the open networking foundation, which differentiates among data-controller plane interfaces, application-controller plane interfaces, and management interfaces, in order to state how the interface type in which they operate influences TE. In addition, the impact of the SDN protocols on TE has been evaluated by comparing them with the path computation element (PCE)-based architecture. The PCE-based architecture has been selected to measure the impact of SDN on TE because it is the most novel TE architecture until the date, and because it already defines a set of metrics to measure the performance of TE solutions. We conclude that using the three types of interfaces simultaneously will result in more powerful and enhanced TE solutions, since they benefit TE in complementary ways.European Commission through the Horizon 2020 Research and Innovation Programme (GN4) under Grant 691567 Spanish Ministry of Economy and Competitiveness under the Secure Deployment of Services Over SDN and NFV-based Networks Project S&NSEC under Grant TEC2013-47960-C4-3-

A Survey on the Path Computation Element (PCE) Architecture

Quality of Service-enabled applications and services rely on Traffic Engineering-based (TE) Label Switched Paths (LSP) established in core networks and controlled by the GMPLS control plane. Path computation process is crucial to achieve the desired TE objective. Its actual effectiveness depends on a number of factors. Mechanisms utilized to update topology and TE information, as well as the latency between path computation and resource reservation, which is typically distributed, may affect path computation efficiency. Moreover, TE visibility is limited in many network scenarios, such as multi-layer, multi-domain and multi-carrier networks, and it may negatively impact resource utilization. The Internet Engineering Task Force (IETF) has promoted the Path Computation Element (PCE) architecture, proposing a dedicated network entity devoted to path computation process. The PCE represents a flexible instrument to overcome visibility and distributed provisioning inefficiencies. Communications between path computation clients (PCC) and PCEs, realized through the PCE Protocol (PCEP), also enable inter-PCE communications offering an attractive way to perform TE-based path computation among cooperating PCEs in multi-layer/domain scenarios, while preserving scalability and confidentiality. This survey presents the state-of-the-art on the PCE architecture for GMPLS-controlled networks carried out by research and standardization community. In this work, packet (i.e., MPLS-TE and MPLS-TP) and wavelength/spectrum (i.e., WSON and SSON) switching capabilities are the considered technological platforms, in which the PCE is shown to achieve a number of evident benefits

Coordinated Computation of Multi-layer Paths via Inter-layer PCE Communication: Standards, Interoperability and Deployment

The Path Computation Element (PCE) is positioned nowadays as one of the solutions that almost every carrier will eventually deploy. The PCE architecture as well as a number of components, including the PCE Communication Protocol (PCEP), have been standardized by the IETF. However, a number of challenges remain to be solved on its way from standards to deployment. In particular, the existing proposals for multilayer path computation within the PCE framework need to be further developed and tested, before considering their possible integration into operational networks. This is especially true for the interoperability of the various PCE implementations and the extensions such as the Virtual Network Topology Manager (VNTM) which cannot be taken for granted. This paper presents a functional implementation of coordinated computation of multilayer paths supported through inter-layer PCE communication, where one PCE is developed by industry and the other as an open-source effort. To this end, we consider an IP/MPLS network deployed over a Wavelength Switched Optical Network (WSON), each of which deploying its own PCE, in an attempt to create an inter-operable multilayer solution. We discuss the key challenges that the research community will face in this area, which in turn will drive a considerable part of the upcoming efforts in terms of standardizationPostprint (published version

Shortest Constrained Inter-Domain Traffic Engineering Label Switched Paths Status of This Memo

This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards " (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (c) 2009 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 in effect on the date of publication of this documen

Evaluación de las prestaciones ofrecidas por el protocolo PCEP (PATH Computation Element Protocol) en las redes de transporte de datos con tecnología de trasmisión GMPLS

En este trabajo se hace un análisis del protocolo PCEP (Path Computación Element Protocol),es un protocolo petición/respuesta que permite la comunicación entre redes multicapa, multidominio, y con diferentes áreas, GMPLS es una evolución del plano de control de MPLS hacia un Plano de Control Común que simplifica el funcionamiento y mantenimiento de una red multicapa con cualquier sistema de transporte (incluso mixto), asegurando la interoperabilidad entre los dispositivos de alto nivel (routers) y los de bajo nivel(OXC, PXC, etc.). GMPLS consiste es un método que contiene una serie de especificaciones usadas para enrutar los paquetes a través de una red por medio de datos adicionales que se encuentran en unas etiquetas añadidas a los paquetes IP. Esto hace que los routers sepan porque camino exactamente deben enviar los datos que le lleguen aumentando la calidad del servicio, el desempeño de las redes y la estabilidad. El PCEP está basado en un modelo cliente-servidor en el cual un PCC(Path Computation Client) puede enviar un mensaje de petición de cálculo a un PCE(Path Computation Element) y éste responde con otro mensaje que contiene la ruta calculada. PCE calcula la ruta aplicando un algoritmo de computación denominado Dijkstra. Este algoritmo tiene dos fases, en la primera fase se comparan los requisitos demandados con los recursos disponibles, y se construye una Constrained-TEDase de datos de ingeniería de tráfico) GMPLS puede verse por tanto, como un integrador de tecnologías, permitiendo la transmisión de información entre los diferentes tipos de redes y unificando el control del tráfico. Con la evolución de la tecnología se da paso al mejoramiento de las redes de trasporte las cuales son muy relevantes ante la necesidad de sistemas más flexibles y unificados. Por tanto con el análisis de la tecnología GMPLS se estudiara que con la implementación de este medio de transporte en los diferentes tipos de redes la información transmitida sea lo más transparente posible frente al despliegue de nuevas aplicaciones de interés para los usuarios, es decir que sean válidas para cualquier nueva aplicación sin cambios significativos y retardos que puedan impedir cumplir las expectativas de los usuarios. GMPLS está basado en enrutamiento IP y modelos de direccionamiento. Esto asume que las direcciones IPv4 y/o IPv6 se usan para identificar interfaces pero también se usan protocolos de enrutamiento IP tradicionales tales como OSPF y el IS IS. El OSPF utiliza el algoritmo Ruta de acceso más corta primero (SPF, Shortest Path First) para calcular rutas en la tabla de enrutamiento. El algoritmo SPF calcula las rutas de acceso más cortas (menos costo) entre el enrutador y todas las redes de la interconexión. Las rutas calculadas mediante SPF nunca presentan bucles, IS-IS y OSPF, son protocolos de estado de enlaces que utilizan el Algoritmo de Dijkstra para encontrar el mejor camino a través de la red. Ambos soportan máscaras de subred de diferente longitud, pueden usar multicast para encontrar routers vecinos mediante paquetes hello y pueden soportar autentificación de actualizaciones de encaminamiento. El protocolo OSPF bien podría ser el más utilizado en redes corporativas grandes, mientras que el protocolo IS-IS es más común en redes de proveedores de servicios. OSPF solamente enruta paquetes IP dentro de un único dominio