ACINO: Application-Centric IP/Optical Network Orchestration (D1.1)
This deliverable is a general presentation of the ACINO project.
reference: D. Siracusa, “ACINO: Application-Centric IP/Optical Network Orchestration”, ACINO public presentation (2015).
Final report on use cases and application requirements, and preliminary techno-economic evaluation of ACINO concepts (D2.2)
To evaluate ACINO’s application-centric approach, it is necessary to have a characterization of the most relevant applications today as well as the emerging applications in the future that make valuable use of such application-centric multi-layer IP-optical networks. Therefore the most dominant and demanding (in terms of service requirements) applications are identified and categorized according to:
a) Broadband services and cloud services, which include the current OTT, broadband access, social media and cloud services,
b) Machine-based services, which include all the emerging machine-type communications related to the operation and content update of data centres as well as the IoT monitoring services,
c) Advanced new services, including primarily the emerging 5G services that are envisioned today. The services are characterized in terms of: bandwidth requirements, usage and location, latency requirements, availability (or equally protection) requirements and security requirements.
The network architecture, where the applications will be transported, is based on packet/optical networks. The packet equipment is deployed end to end in the network and optical networks are being deployed closer to the end-user to increase the network capacity. This reference architecture has also been used to identify the multi-layer network operations that the ACINO orchestrator must perform in order to configure and adapt the resources to the application requirements.
Once we have clarified the applications and the network operations, some some applications and relevant network operations have been selected to illustrate, with specific use cases, the value proposition of application centric IP/optical networks: five case studies are explained in detail in this document:
1) Application-based data center interconnection,
2) Enabling dynamic 5G services,
3) Application-specific protection strategies,
4) Secure transmission as a service,
5) Dynamic virtual CDN deployment, and
6) Application-centric in-operation network planning.
The case studies are representative examples to demonstrate the value added by the ACINO concept, since they consider not only the network but also the application layer.
This deliverable also includes an overview of the reference network architecture that will be used in the planning and techno-economic studies of the project. The multi-layer network architecture is defined based on the information available for the IP and optical layer infrastructure of the Spanish national network. A reference network is extracted and describes the national backbone and regional networks. This is accompanied by the related traffic load data and predictions for future load increase. The reference network is important in ACINO for the network performance evaluation studies of the ACINO resource allocation frameworks as well as the cost evaluation studies that will follow in the upcoming deliverables of WP2.
A network cost model is extracted by combining data from the FP7 ICT-STRONGEST project, FP7 ICT-FOX-C project and the open list price of IP and Optical equipment by Cisco. Based on cost model comparisons and studies it is concluded that the final cost model will follow the FOX-C model which will be updated with the latest technology solutions available. In order to evaluate the cost of the network, a cost evaluation module was developed in Net2Plan and is connected with the ACINO resource allocation and optimization framework developed in WP3. It is designed to be linked with excel spreadsheet in order to allow a simple and fast update of the cost data if needed. A detailed reporting function is also included for extracting cost statistics. Preliminary cost evaluation studies have been carried out considering two application classes, one with strict latency and availability requirements and a best effort class. The results show that the added cost required for the ACINO case in order to provide application awareness is less than 5% compared to a multi-layer resource optimization case without application aware features. In addition the optimization function achieves a cost benefit in the use of network resources around 16% compared to a non-optimized solution.
ACINO’s Framework for the Application-Centric Network Orchestrator (D3.1)
This deliverable describes the requirements and proposed architecture of the ACINO orchestrator. It gives an overview of the main elements of the architecture, and then the detailed requirements for each of these components. It provides an overview of existing SDN frameworks with the intent of identifying candidates for controlling the IP/MPLS network, the optical network, or realizing the ACINO orchestrator. The document also surveys several multi-layer network models, proposed in multiple standardization bodies, and identifies a potential candidate for the ACINO orchestrator along with an initial list of extensions required.
The document identifies ONOS as the candidate framework for developing the ACINO architecture, outlines the mapping of the elements of the ACINO architecture on existing ONOS components, and presents the
new components that would be developed in the ACINO project.
Report on the design of programmability elements for in-operation network control (D3.2)
This deliverable 2 presents the work performed in task T3.2 “Design of the programmability elements for in-operation network control” to design the northbound interface of the ACINO orchestrator. The document begins with a review of the requirements of the northbound interface, derived from previous work done related to use cases and application requirements (see ACINO deliverable D2.1) and the expected properties of the ACINO framework (see ACINO deliverable D3.1).
The northbound interface of the orchestrator uses the intent paradigm: applications request what they want (in term of service properties), not how the requested services should be set up. This paradigm makes the interface potentially independent of the orchestrator, as it does not rely on the technical implementation of the control plane. Adopting an Intent-based interface as a standard for the orchestrator could make Software-Defined Networks much more popular, as applications communicating with them would:
1) Be easier to write (no knowledge of network technology required), and
2) Not be tied to a specific orchestrator implementation.
A review of the state of the art on the subject is presented in chapter 3.
The document defines two northbound interfaces: the Dynamic Intent-driven Service Management Interface or DISMI, which allows applications to request network services, and the Multi-Layer Topology and Planning Interface or MLTPI, which is an interface used for management purposes (e.g. interfacing with Network Management Systems (NMS)).
The network primitives exposed to applications through the DISMI are defined. Using the provided grammar, applications can combine them to build intents. The main types of primitives are:
a) Actions, which describe the type of connection requested: point-to-point, point-to-multipoint or multipoint-to-multipoint, uni- or bi-directional;
b) Nouns, which describe the network end points;
c) Constraints, which specify the properties of the requested network service (bandwidth, delay, encryption, …);
d) Selectors, which allow discriminating traffic at the network end points and routing it over application-specific services.
The architecture of the intent framework is presented. As defined, DISMI is independent of ONOS, and the framework itself could be implemented as a component separate from ONOS. It is however integrated to the orchestrator to provide a full orchestrator implementation. The framework implements:
a) The DISMI module, which performs the intent resolution: all the parameters and primitives of the intent are checked and validated;
b) The various intent compilers (one per intent) that decompose intents and find a way to install them as sets of network requirements, then send them to ONOS for actual installation.
The network primitives exposed to applications through the MLTPI are defined. Network Management Systems can use them to pose questions, such as what-if questions (“what if this link fails?”) or re-optimization questions (“what is the benefit of a re-optimization with regard to energy usage?”). The result of such re-optimizations can be applied to the network or discarded. MLTPI is an extension of DISMI: it adds a set of primitives and methods to the DISMI, that are only visible to privileged applications. Some of these primitives are to send questions; others provide the answers from the framework. Similarly to DISMI, a RESTful HTTP API is defined for MLTPI.
Finally, summarizing the design work presented in this report, four areas are identified in the network controller used as the base for the ACINO orchestrator, where programmability elements need to be modified or introduced to implement the functionalities described in this document.
Cross layer planning and optimization strategies (D3.3)
This document highlights the defined strategies for the cross-layer planning procedures which will in turn define the algorithmic functions and approaches for the development of the multi-layer optimization module, the online planning tool module and their interfaces with the rest of the modules in the ACINO orchestrator. The terms “cross-layer” and “multi-layer” are used interchangeably with the same meaning; the former conforms to the original task name, while the latter is more prevalent in the existing literature.
We first define the problem and present the existing work in the field. Then we show the flow of information in the ACINO architecture pertaining to multi-layer optimization. Following this the strategies for the implementation of the multi-layer processes and modules are described in detailed. The simulation environment and some preliminary results are shown at the end of the document.
Application-centric routing and resource allocation algorithms for online operation (D3.4)
This document describes the outcomes of the design, development and evaluation of the ACINO application-aware resource allocation and optimization framework. The developed algorithms apply to both the IP and the optical network layers, and accommodate each application’s requirements in a dynamic setting where application connection requests arrive and depart at different times. This work builds on the work presented in Deliverable D3.3.
The document first specifies the service requirements that will be optimized for. These are, in addition to bandwidth (BW) in Gb/s, latency, availability, protection, and Wavelength Division Multiplexing (WDM) class used for separating traffic flows for security purposes. A network equipped with the ACINO algorithm must be able to satisfy all service requirements for each network.
To satisfy the requests, an algorithmic framework is presented and extensively tested on a model network with simulations. The framework consists of three modules: IPP (IP layer provisioning), IP-OPT (IP layer optimization) and OPP (optical layer provisioning). IPP tries to accommodate the connection request by finding a path through the network only in the IP layer. IP-OPT moves existing IP connections to accommodate new requests, minimize the number of active IP equipment to save energy, and balance the IP link load. OPP sets up new optical connections. The framework thus calls IPP, IP-OPT, and IP-OPT in a particular sequence to accommodate as many requests as possible while minimizing energy consumption. The modules are implemented as Java code that runs as an algorithm for the Net2Plan open-source network simulator. The code can be run in a graphical user interface or in command line for batch runs.
To investigate the effectiveness of the ACINO framework, we define benchmark algorithms to compare against, the traffic scenarios, and the quantities to be compared. The main benchmark algorithm in this document is very close to the ACINO algorithm, which performs dynamic multi-layer optimization but without considering the defined service requirements. We refer to such an algorithm as application-unaware. To make the comparison fair, the benchmark is not a simplistic algorithm, but instead carefully deals with the problem of multi-layer optimization in a dynamic setting. The traffic scenarios involve an increasing number of traffic classes, each class having a distinctive set of requirements. The percentage of traffic classes and their service requirements are varied to get an insight into their impact on the algorithm performance. The performance is measured in several comparable quantities, namely the amount of blocked connection requests, the amount of requests whose requirements are not satisfied (referred to as SLA (Service-Level Agreement) violations), the number of the relatively slow optical connection setups, and the amount of network resources measured as the number of IP links.
The numerical results demonstrate the advantage of the ACINO framework over the benchmark algorithm. ACINO achieves its guarantee of no SLA violations and in most scenarios no blocking while requiring virtually no additional network resources compared to the benchmark case. In the scenarios involving ACINO blocking, it is found to be much lower compared to the application-unaware blocking and SLA violations. ACINO can thus achieve much greater application centricity. This achievement, in some scenarios, is traded off for a greater responsivity from the ACINO-equipped optical network and orchestrator, i.e. the ACINO network must be able to set up and tear down connections faster. In addition, we test the role of IP-OPT on both the ACINO and the unaware network. We find that an unaware network with no IP-OPT has less blocking and violations for the unaware case, but the decrease requires additional network resources. With ACINO, a network with IP-OPT needs less network resources compared to one without, so IP-OPT is justified.
Finally, the software tool developed for the dynamic simulation is demonstrated in network planning scenarios. Here the same framework and its software implementation are used to predict the impact of a hypothetical connection request and the effects of network component failures. The network operator can thus use the tool to prepare the network for future expected or unexpected events.
Definition of test-bed scenarios and use-cases (D5.1)
This document describes the test-bed set-up which will be used for the experimental validation and the mechanism to demonstrate the use-cases defined in WP2 on this set-up. The document also contains preliminary tests that help the project validate initial prototypes of the ACINO orchestrator on a real setup. Finally, the deliverable provides the main functional tests to validate the ACINO orchestrator’s and controller’s requirements.
The deliverable starts with presenting three preliminary tests:
a) Demonstration of the orchestrator with the primary objective to test the interaction with the physical set-up,
b) Demonstration of differentiated network restoration based on the policy requested by the client application, and
c) Demonstration of the DISMI intent interface.
The test-bed description presents an overview of the Data Communication Network (DCN) that is used to interconnect partner sites, the physical and the emulated test-beds. The physical testbed comprises three Juniper routers, three ADVA nodes, and VMs to control the network devices. The consortium also has access to an emulated environment which enables functional tests on a larger set-up.
The definition of the use case validation covers the setup to demonstrate:
1) Service differentiation based on intents,
2) Enabling of dynamic services using the intent interface,
3) Encrypted application delivery,
4) vCDN adaptation and
5) In-operation network planning.
Finally, the document contains functional test cases to validate the requirements on the IP and optical controllers, as well as the ACINO orchestrator. The functional tests cover the provisioning, topology, monitoring and path computation capabilities of the IP, optical controllers and orchestrator (including DISMI and NetRap). The document also provides initial performance parameters for some of these functional tests.
Project Website and Communication Kit (D6.1)
This deliverable presents a brief overview of the public ACINO webpage and provides a short description of the content of the web page. The objective of the project website is to promote the ACINO project and communicate about it to the rest of the world. It is also used as a collaborative space among the project members. The deliverable also provides information about the project twitter account (@acinoH2020) and the communication kit.
This document also communicates that the project website is up and running.
ACINO Data Management Plan (D6.2)
Producing the Data Management Plan (DMP) within the project is a part of the Horizon 2020 pilot action on open access to research data in which ACINO participates. The purpose of the DMP is to describe the main elements of the data management policy that will be used by the ACINO project with regard to all the datasets to be generated by the project.
In other words, the Data Management Plan describes the format and the way to store, archive and share the data created within the project as well as the use of the plan itself by the project participants. The data may include, but is not limited to, code, publications as well as measured data, for example, from field trials. The Plan is a living document whose content concerning the data management is updated from its creation (June 2015) to the end of the project (January 2018).
First year report on dissemination and communication activities (D6.3)
This deliverable presents the communication and dissemination activities performed by the ACINO consortium during the first year of the project. The consortium has developed communication instruments to support such activities for the duration of the project:
a) A graphical profile has been developed for ACINO, as well as document models for reports and presentations;
b) A web site has been set up, describing the project, the challenges we are looking at, and our approach to solve them;
c) A Twitter account has been set up to ensure presence in the social media and to allow a more dynamic communication;
d) A fact sheet and a flyer have been developed.
The project has also held two further communication actions: a press release and an interview in a magazine.
The dissemination activities have been based on the participation in public events where the goals and concepts of ACINO were presented via publications, presentation, workshops, courses and demonstrations.
Overall, fifteen different dissemination activities have been performed:
a) Four articles were published in conferences: at ICTON, ECOC and Photonics in Switching;
b) Four presentations were held at conferences: at EUCNC, the OSA Advanced Photonics Conference, CTTE and OFC;
c) The project participated to the organization of the Workshop on Network Function Virtualization and Programmable Networks at EUCNC;
d) A tutorial entitled “Control Architectures for Multi-layer Networking: Distributed, centralized, or something in between?” was held at OFC;
e) A course entitled “SC411: Multi-layer Interaction in the Age of Agile Optical Networking” was held at OFC;
f) Three booths were held at OFC, ONS and the SDN & OpenFlow World Congress, where demonstrations were run;
g) The project started contributing back to the Open Source Software community maintaining the Netphony controller.
Contacts have also been taken with several Open Source Software communities and European projects for future collaboration.
Finally, the project has devised detailed plans for its dissemination activities for the coming year.
Second year report on dissemination and communication activities (D6.4)
This deliverable presents the communication and dissemination activities performed by the consortium during the first two years of the project. We have communicated using our website, Twitter account and by various communication actions:
a) The website saw over 3000 unique visitors during the first year and over 4000 during the second year;
b) The consortium Twitter account had 49 followers at the end of the first year and 80 at the end of the second year. We posted 50 tweets during the first year and 40 more during the second year;
c) We also held a press release and an interview in a magazine during the first year, and had three more similar communication actions during the second year.
The dissemination activities have been composed of participation in public events where the goals and concepts of ACINO were presented via publications, presentation, workshops, courses and demonstrations. Overall, over forty different dissemination activities have been performed:
a) An article has been published in peer-reviewed, open access Journal of Green Engineering;
b) Eighteen articles have been published in conferences: four during the first year and fourteen during the second. One of them was a post-deadline and six were invited papers;
c) We have co-organised three workshops: the workshop on Network Function Virtualization and Programmable Networks at EUCNC 2015, the first Workshop on Multi-Layer Network Orchestration (NetOrch) at ICTON 2016 and the stand-alone ONOS/CORD workshop;
d) We have held 16 talks, tutorial, courses and demonstrations;
e) Consortium members have won two prizes for work related to ACINO: a team of developers won the 3rd prize of the ONOS Build Hackathon, and Telefónica won the Best SDN-NFV solution award at the LTE and 5G World conference by presenting a solution in which Sedona Systems was involved;
f) We have contributed to six IETF standardisation documents and done some implementation and test of these standards.
g) We have contributed to two open source projects: the NetPhony and ONOS controllers, with the implementation of main features being accepted and merged to the core code of these open source projects.
Finally, the project has devised detailed plans for its dissemination activities for the last year of the project. We have:
a) Confirmed plans for the organisation of a workshop, the second edition of the NetOrch workshop, co-located with the ICTON conference;
b) A solid plan for continued dissemination in conferences (already five accepted conference papers, five talk invitations and a list of conferences of interest) and in peer-reviewed journals, with one article accepted for publication in the Journal of Lightwave Technology, two articles under review and plans for four more;
c) Some more planned contribution to open source projects.