ICTON 2015 Th.B3.5 iONE: An Environment for Experimentally Assessing In-Operation Network Planning Algorithms Lluís Gifre 1,2* , Nacho Navarro 2 , Adrià Asensio 1 , Marc Ruiz 1 , and Luis Velasco 1 1 Optical Communications Group (GCO), Universitat Politècnica de Catalunya (UPC), Barcelona, Spain 2 Barcelona Supercomputing Center, Barcelona, Spain * e-mail: lgifre@ac.upc.edu ABSTRACT Huge amount of algorithmic research is being done in the field of optical networks, including Routing and Spectrum Allocation (RSA), elastic operations, spectrum defragmentation, and other re-optimization algorithms. Frequently, those algorithms are developed and executed on simulated environments, where many assumptions are done about network control and management issues. Those issues are relevant, since they might prevent algorithms to be deployed in real scenarios. To completely validate network-related algorithms, we developed an extensible control and management plane test-bed, named as iONE, for single layer and multilayer flexgrid- based optical networks. iONE is based on the Applications-Based Network Operations (ABNO) architecture currently under standardization by the IETF. iONE enables deploying and assessing the designed algorithms by defining workflows. This paper presents the iONE test-bed architecture, describes its components, and experimentally demonstrates its operation with a specific use-case. Keywords: flexgrid optical networks, path computation element, in-operation planning, network experiments. 1. INTRODUCTION The continuous growth of traffic in core networks is motivating to devise new strategies for providing bandwidth-on-demand connectivity. The recently standardized Applications-Based Network Operations (ABNO) architecture [1] proposes a generic control plane infrastructure enabling efficient vendor-agnostic service provisioning and network handling. The ABNO architecture is organized as several modules, whose central element is the Path Computation Element (PCE), having well-defined responsibilities and communication interfaces. In particular we consider an extended ABNO architecture where the PCE is split into a front-end PCE (fPCE) responsible for network handling and path provisioning and a back-end PCE (bPCE) responsible for running complex computations such as network re-optimizations, named as PLATON [2]. In this paper, we describe the iONE [3] environment as an implementation of the ABNO architecture with the front-end/back-end extension; then we present a use case of in-operation network re-optimization and its workflow using the iONE environment. Finally, we experimentally demonstrate the workflow showing the exchanged messages. 2. IONE ARCHITECTURE iONE is an implementation of the ABNO architecture for agile deployment of in-operation network planning workflows. One single generic software module, named as iONE module, has been developed in C/C++; this module can be configured using XML files to implement any of the ABNO modules. Furthermore, workflows can be defined through XML files, where the algorithms to be executed are dynamically loaded into the iONE module. The internal architecture of the module, depicted in Fig. 1, consists of 5 components. The communication interfaces are the gateway for all incoming and outgoing messages; these messages can be encoded using REST API, PCEP [4], and BGP-LS [5] protocols. iONE’s implementation of PCEP supports both active stateful and LSP initiate capabilities. An arbitrary number of interfaces for each protocol can be configured. Interfaces can be defined as server or client; when it is defined as server a list of trusted peer client IPs is provided, whereas for client ones, only the server peer must be configured. The configuration also enables protocol-defined parameters. The manager is responsible for configuring and coordinating the rest of components. A configurable sequence of startup actions can be configured to be executed at the iONE module start-up time; these actions include: setting up a protocol session on a specific interface, waiting for an incoming connection through a specific interface, introducing a specific delay in the startup sequence, etc. In addition, the manager collects incoming messages received by any communication interface and either redirects them to the proper component or uses them to update databases. The network databases component provides in-memory storage. Currently implemented databases include the TED and the LSP-DB. The databases can be pre-loaded by means of XML files and configured to synchronize their content through specific communication interfaces. For instance, a BGP-LS interface can be configured to handle BGPUpdate (BGPUpd) messages to synchronize the Traffic Engineering Database (TED), while a PCEP interface can synchronize the state of the Label Switched Path (LSP) Database (LSP-DB) using asynchronous PCReport (PCRpt) messages. 978-1-4673-7879-6/15/$31.00 ©2015 IEEE 1