SFA interface available for FEDERICA

As it has been introduced in previous posts, one of the main objectives of NOVI project is to demonstrate the federation mechanisms using them over FEDERICA and PlanetLab platforms. With this proposal and due to other sensible reasons, it was decided to adapt FEDERICA platform to SFA (Slice Federation Architecture). This could sound as an easy task but it wasn’t. Given the Web Services (WSs) for FEDERICA used to virtualize the resources, we wanted to offer the common API that PlanetLab is already using. However, different problems appeared during this development. Not only both languages were different (Python vs Java), but the SFA implementation was too PlanetLab dependent and we had problems to find information on this implementation. We should thank partners providing answers to all our questions!

So, how did we start? There was one thing clear: the information is provided by means of the RSpec, which is an XML based document that can be extended if needed. Two of our NOVI partners, NTUA and GARR, are responsible for adapting the existing GENI RSpec to the FEDERICA resources. UPC and i2CAT were the partners in charge of this SFA adaptation, the ones that knew better the use of the WSs and they were helping in all different actions taken under this task. In order to describe the network resources offered by FEDERICA to the RSpec, it was decided to adapt them to the existing ones defined by Protogeni (more information here). Each of the network resources (switch, router or virtual machine) is considered a node, and this nodes are connected each other through links.

Once we knew how data is represented, it was possible to start to build the advertisement RSpec and to build slices from an RSpec request. In order to build an initial working SFA, the security was for the moment omitted. It was decided that security considerations will be taken into account in a later version. So, we created an XMLRPC server with simple user and password security able to receive the SFA calls and return the appropriate RSpec. In between, the different calls to the WSs are done.

At this point, our partners from IRNIA informed us that they were collaborating in another project, OpenLab, and that within their effort there, they had started to develop a Generic SFA. They’ve realized that the SFA development used on PlanetLab was too MyPLC/PlanetLab dependent, and consequently, it was difficult to adapt it to other kind of testbeds. That was perfect for our goals, as the work done till the moment, was specifically FEDERICA dependent.

The following figure shows the first generic SFA with two different testbeds.

Generic SFA Schema

As we can see, there is a new driver for each of the testbeds. This is testbed specific and it’s where the work done within NOVI project is placed. The rest of the SFA AM, is in charge of more generic SFA actions: receiving incoming calls for authentication and management of neighbours, for instance.

That’s the way two different projects put together their efforts for achieving the same goal, and we can say that finally FEDERICA testbed has an SFA interface.


This entry was posted in Ongoing Projects and tagged , , , . Bookmark the permalink.