Services‎ > ‎Usage scenarios‎ > ‎

Physical network

Extended cloud with complex physical network implications

Motivation & Objectives

The main goal of this scenario is to federate the BonFIRE infrastructure with a variety of external facilities which may themselves be federations. Federating BonFIRE with existing testbeds would have the following advantages:

  • Better scaling capabilities could be achieved
  • Access to different resource types could be provided (e.g, wireless, sensors, servers, new network devices) contributing to a richer environment offering to the user

It would facilitate (new) standards definition, e.g. resource description, protocols and monitoring mechanisms. In this scenario we will investigate how BonFIRE’s cloud infrastructure could federate with Federica Slices and AutoBAHN. Once the possibilities of federation with these facilities have been studied and analyzed, we will initiate the federation following the best ways and mechanisms that have been identified. This scenario is the most complex and will aim to be supported later in the BonFIRE project.

Background

FEDERICA is a European Project of the 7th Framework Program whos main goal is to deploy an e-Infrastructure (composed by routers, switches and computers) for researchers on Future Internet. Resources of this e-Infrastructure can be allocated to multiple slices and assigned to different network researchers. FEDERICA will allow the researchers to have the complete control of the resources in their slice, enabling disruptive experiments. AutoBAHN (Automated Bandwidth Allocation across Heterogeneous Networks) is the BoD framework for the GÉANT and NREN networks. It reserves resources in heterogeneous, multi-domain environments, allowing immediate and advance circuit reservations. The project was developed as a pilot in the GN2 project and is currently continued in GN3 to move to the production phase the Bandwidth on Demand service for the GÉANT community.

Enabling Technologies

The core of a BonFIRE site in this scenario is the same as in the other scenarios. Extending the previous scenarios to include external federation must take account of facilities used in the external facilities.

FEDERICA

In FEDERICA, all the devices that compose the infrastructure are sliced using different techniques. Routers are sliced into “logical routers”, that are partitions of a physical router that acts as a separate router (different routing domains), sharing the hardware but without interfering with each other. Switches are virtualized using Virtual LAN and the protocol QinQ to manage them. For virtualization of computers a hypervisor software that virtualizes hardware (interfaces, CPU, RAM) and allows different operating systems to be run in the same host at the same time has been used. Each instance that is running an OS is called Virtual Machine (VM). The hypervisor selected to manage VMs is VMWare ESXi that has a good remote management API. Finally, FEDERICA also manage software routers: a VM with some software installed that makes it work as a router. In the case of FEDERICA the VMs are equipped with Ubuntu Server as the main OS and Xorp as the routing tool.

AutoBAHN

Unlike FEDERICA, AutoBAHN does not provide compute resources, but rather allows to provision bandwidth on demand across administrative domains. The AutoBAHN instance deployed in a domain consists of three main software components. All these components form an AutoBAHN instance operating within single administrative domain:

  • The Inter-Domain Manager (IDM), which is responsible for inter-domain signaling and routing information distribution. Each IDM exposes UAP interface for handling its clients’ requests and coordinates the implementations of its clients’ circuits in the multi-domain environment.
  • The Domain Manager (DM), which is responsible for provisioning within each domain and providing to the IDM all the necessary information for the inter-domain setup.
  • The Technology Proxy (TP) module handles generic requests for setting up or removing a specific circuit within domain and it configures network devices using specific technology, protocols, etc. Depending on the domain policy, devices capabilities or presence of other configuration tools, TP may configure the network with one or more techniques:
    • directly by contacting the devices, 
    • by using an already existing Network Management System (NMS) 
    • through resource reservation signaling protocols.

AutoBAHN IDM and DM components are generic and independent from the underlying network technology, while the TP needs to be adopted and customized from the existing solutions or implemented from scratch.

AutoBAHN high level architecture
Figure 1: AutoBAHN high level architecture.

AutoBAHN has demonstrated its interoperation with similar BoD systems developed in the US, like OSCARS by ESnet and Internet2, both using the DICE IDCP protocol which will be replaced by the NSI (ref. next subsection). AutoBAHN is currently in the pilot service stage within the European NREN community, and, in particular, its consolidation towards live operation in production NRENs is carried out through the GN3 project. Among the NRENs participating in the GÉANT AutoBAHN pilot there are Pionier (PL), Janet (UK), Renateur (FR) which are the network providers for some of the institutions operating BonFIRE sites.