AutoBAHN Adaptor

BonFIRE, starting from release 3.1, provides the experimenters with the possibility to request QoS-enabled network connectivity services with a guaranteed bandwidth (Bandwidth on Demand – BoD – services) to interconnect BonFIRE sites. Instead of relying on the best effort Internet connectivity, the cloud resources (storage, VMs) located in different BonFIRE sites can be interconnected through a dedicated network service with the bandwidth requested by the experimenter.

This feature is mainly targeted to the network-aware experiments that may need guaranteed bandwidth to achieve more than best-effort connections between computational resources. In fact, experimenters can obtain guarantees for the minimum bandwidth reserved to their experiment and be sure it will not be impacted by other coexisting experiments; similarly, they can obtain a maximum bandwidth guarantee, thus being capable of emulating the behaviour of a given link capacity or link congestions.

In BonFIRE the inter-site BoD services are provided by a third party network provider connecting the BonFIRE sites. In particular BonFIRE adopts the GÉANT Bandwidth on Demand (BoD) system (AutoBAHN BoD version 2.1.1), since GÉANT and the National R&E Networks (NRENs) are the primary network providers for most of the BonFIRE facility owners. In release 3.1, the offer for BoD services is limited to the interconnection between the EPCC and PSNC sites.


Figure 1 - Bandwidth on Demand services in BonFIRE

The interaction with the AutoBAHN system is managed by a specific end-point implemented in the enactor. The AutoBAHN end-point acts as a cloud-to-network adaptor to bridge the OCCI requests related to a site_link resource with the AutoBAHN BoD interface.

A site_link resource is the BonFIRE OCCI representation of a network connectivity service between two BonFIRE sites, and it can be requested as part of an experiment to interconnect VMs located on two different sites (EPCC and PSNC in this case) with guaranteed bandwidth.

Source code location

The AutoBAHN adaptor code is included in the enactor code, available on the BonFIRE SVN in folder /broker/Enactor/trunk. See section “AutoBAHN adaptor: software architecture” for further details.

APIs provided

The AutoBAHN adaptor is able to support three types of OCCI requests related to a single site_link resource: creation (POST request), retrieving of information (GET request) and cancellation (DELETE request). Requests related to the overall set of available site_link resources or request to modify an existing BoD service (PUT requests) are not supported.

The following list of parameters is included in a site_link resource:

  • <location>, <name>, <id>, <description>, <groups> - self explaining names of commonly used parameters in BonFIRE OCCI elements
  • <endpoint> - this attribute references to a BonFIRE site. For each BonFIRE site connected to GÉANT through a NREN deploying AutoBAHN for the automatic provisioning of BoD services (i.e. currently only PSNC and EPCC), a specific client port has been defined and configured in order to act as end-point for the BoD services in the associated site.
  • <bandwidth> - value of bandwidth (in Mbps) for symmetric network connections from “start” to “end” end-point
  • <state> - identifies the current status of the BoD service. The following values are possible: PENDING, RUNNING, FAILED, CANCELLED, SCHEDULED

The format of an OCCI site_link resource is the following:

OCCI site_link resource:

<site_link href =“/locations/autobahn/site_links/{{<ID>}}”>


                <location href=”/locations/{{siteA_id}}”>

                <location href=”/locations/{{siteB_id}}”>

        <link rel="location" href="/locations/autobahn"/>


AutoBAHN adaptor: software architecture

The AutoBAHN adaptor has been developed in the AutobahnEndPoint class (in package, extending the EndPointAbstractImpl class and following the common design pattern of the overall enactor. The AutoBAHN end-point is a stateless entity and its basic function is the translation of incoming OCCI requests for site_link resources related to autobahn locations into appropriate calls to AutoBAHN. In particular, the actual interaction with the BoD system is based on the exchange of SOAP messages over the User Access Point (UAP) interface exposed by AutoBAHN and it is mediated through an AutoBAHN UAP client developed within BonFIRE as a java library and imported within the enactor (see Figure 2).


Figure 2 - High level interaction diagram for BoD Adapter

The core of the AutoBAHN end-point receives the OCCI requests, translates the XML description of the site_link resource into internal data-structures mapping between site_link and AutoBAHN BoD service concepts, and executes the actions workflow associated to each type of supported HTTP request (POST, GET, and DELETE) composing the OCCI responses. Some information related to the site_link resource are not directly specified in the OCCI request. In particular, the duration of the resource reservation is inferred from the description of the experiment associated to resource itself and declared in the OCCI request, within the HTTP header. On the other hand, a simple network topology pre-configuration is required to univocally identify the client port associated to the each BonFIRE sites and used as access point towards the PIONIER or JANET network within the AutoBAHN system.

The AutoBAHN UAP client is a java library that exposes a set of synchronous methods to submit (messages 1-2 in the picture), query (3-4) and cancel (5-6) a BoD service hiding all the details of the related SOAP messages implementation. It implements the concept of AutoBAHN BoD service and takes care of the interaction with AutoBAHN acting as a SOAP client that implements the WSDL of the AutoBAHN UAP v2.1.1. The AutoBAHN UAP client java library is available in the lib directory of the enactor code, in lib/user-access-point-client-0.0.1-SNAPSHOT.jar , and it has dependences on Apache XML Beans 2.5.0 (

For each AutoBAHN-related OCCI message received at the enactor, a new AutoBAHN endpoint instance is created to process the incoming HTTP request, interact with AutoBAHN through the UAP interface and provide back the resulting HTTP response. Consequently, the AutoBAHN endpoint share its lifecycle with the lifecycle of the OCCI request/response pair. In order to support asynchronous actions beyond the OCCI request/response time life, suitable threads must be created and started. This approach is adopted for the monitoring functionalities to verify the status of the site_link and retrieve parameters that become available during the service setup (e.g. the VLAN IDs) only after the initial creation.

Message queue use

The monitoring thread, implemented in the AutobahnStatusPollingThread class, is used to generate notifications of events describing the evolution of the site_link resources. This notifications are sent to the Management Message Queue (MMQ) for the accounting of site_link resources usage. In particular, new events are generated in the following cases:

  1. a site_link becomes active
  2. a site_link is deleted
  3. the setup of a site_link fails

The class that manages the interaction with the MMQ is the MQAutobahnMessageProducer, in the mqmessageproducing package. This class extends the MQAutobahnMessageProducer abstract class and implements the methods to send the AutoBAHN related events, with the site_link information (see AutobahnSiteLinkObjectData class) to the MMQ.

The JSON format of the objectData field for a site_link is the following:

"objectData": {
        "name": "site-link-name",
        "description": "site-link-description",
        "end_point_A": "/locations/uk-epcc",
        "vlan_A": "2001",
        "end_point_Z": "/locations/pl-psnc",
        "vlan_Z": "2002",
        "bandwidth": "1000000",
        "experimentId": "/experiments/657"

Table Of Contents

Previous topic

Amazon Enactor Adaptor

Next topic

Wellness Enactor Adaptor

This Page