Browsed by
Category: Blog

ICN Testbed Federation

ICN Testbed Federation

One of the main goals of the ICN2020 project is taking information-centric networking from the research ecosystem directly to the real-world. It is done by of course the exploration of use-case scenarios and application development, but also and in particular by creating an environment that supports experimentation using global-scale platforms.

In the past years various ICN testbeds were proposed but, except some notable cases, the overall result is to obtain a closed environment and limited scenarios.

ICN2020 project efforts are not in the direction of proposing yet another testbed but instead to provide a platform as open as possible, enabling the possibility to interconnecting and federate existing testbeds, regardless of the specific ICN implementation or the software/hardware available.

The key tool for this ambitious goal is GÈANT Testbed Service (we already talked about GTS in a previous post).

The key features that makes GTS suitable for federated testbeds are:

  • complete control on the virtual machine deployed;
  • possibility to access external resources via “External Domain Port” resources.

The current efforts in the direction of a federated testbeds takes in consideration two of the main ICN Testbeds actually deployed, the NDN testbed (primarily in the US but with several nodes deployed all over the world too) and the CUTEi testbed (deployed in Japan and a few more countries ). Using GTS two primarly goals are intended to achieve by the ICN2020 project:

  • extend CUTEi testbed’s coverage, especially in Europe;
  • interconnect CUTEi nodes with NDN Testbed nodes, implementing special gateway inside GTS when needed.

 

Some demonstrations were already held to show the effectiveness of ICN deployments on the GTS service and the possibility of testbed’s federation:

 

References:

 

For further updates, follow ICN2020 project on twitter and/or facebook.

 

Cisco takes CCN back to the “community”

Cisco takes CCN back to the “community”

Cisco has recently started a new open-source project within the FD.IO community in the Linux Foundation: CICN.
The name stands for Community ICN and reflects the main goal of the project: foster the convergence of various ICN flavors (CCN and NDN) into a single harmonized version of ICN.
And Cisco seems to have a pretty clear plan to achieve that. The first step was acquiring the CCN code base from PARC, now freely released as part of the CICN project.
In addition, the CICN code development follows the specifications released by the IRTF ICN Research Group.

Focus on applications and experiments

But the project is not limited to the architectural code: several tools and plugins are also included, that will speed up the development of ICN application and experiments.
A special attention deserves the VPP forwarder plugin, an ICN forwarder that uses the VPP platform by Cisco and released as open-source as part of FD.IO too.
Early release of the CICN project targets Linux, Android and Apple systems, and includes:

  • METIS, the socket based forwarder,
  • The VPP forwarder plugin,
  • The consumer/producer API,
  • The consumer/producer API,
  • A number of supported libraries,
  • Examples of CCB applications, including but not limited to an end-to-end example for HTTP ABR video delivery (player and server),
  • Tools suitable to assist the development and testing phase.

How to contribute

The community is invited to be actively involved in the evolution of the project using the mailing list and participating to weekly web meetings, other than contributing in the project’s code.
More information on the project can be found at http://wiki.fd.io/view/Cicn, with links to the source code repositories, project’s documentation and tutorials.

How to use GEANT Testbed Service to easily create ICN testbeds

How to use GEANT Testbed Service to easily create ICN testbeds

One of the main goal of the ICN2020 projects is to identify and/or create proper tools and services to enable global-scale experiments.
The availability of proper testbeds is often one of the key aspects to influence the success of a research, particularly in networking.
The truth is that building a testbed is not a simple task and, other than a lot of time and efforts,
requires transversal skills not always possessed by network researchers and the proper hardware infrastructure.
So the choice often fall into simulation softwares or pre-existing testbeds, where customization of aspects like topology of internal behavior is not always feasible.

In this post we propose the use of GEANT Testbed Service to easily create an ICN testbed.

What is GTS

GEANT Testbed Service (GTS) is an innovative service to build personalized and isolated testbeds for networking experiments.
The idea is to exploit the “as-a-service” also for network testbed: multiple isolated testbeds can be hosted to the same hardware tanks to virtualization of the resources.
The architecture behind the service is a mix of cloud infrastructure and links virtualization, in conjunction with an orchestration service and an intuitive way to describe network topologies.
GTS allows the deployment of real global-scale experiments through its several hosts deployed in different countries,
and ensures isolation of experiments using virtualization technics (Virtual Machines, Virtual Switches, VLANs, etc.).

Why use GTS

The concept of “shared resources” is behind many new technologies that allow normal users to easily deploy and maintain complex systems, without the burden of the infrastructure management.
A testbed is often a complex infrastructure, and generally used only for a limited amount of time, making it the perfect candidate to become a shared resource.
On the other side, concentrate the efforts of building a unique platform for networks experiments gives the unprecedented opportunity to create a huge infrastructure,
otherwise impossible for a small organization.

How it works

After the successful registration to the service, a user is assigned to a project (several users can be assigned to the same project).
Each project has a fixed amount of resources assigned, and users can create their own testbed topology using a Domain Specific Language.
The first action required is the reservation of the resources:
if the reservation process succeed, the testbed resources are blocked until the reservation time expires or the resources are explicitly released by the user.
After that, is possible to access the reserved resources (e.g.: virtual machines or virtual switches) and configure them.
The internal network of the testbed , and the testbed’ s resources, can be accessed trough a VPN connection (each project has a unique VPN associated).

Where to start

The GTS homepage contains all the documentation needed to understand the GTS infrastructure and start working with it.
At the moment, the registration process is not automatic, but implies an email request to the GTS project maintainers with a description of the project to be hosted and the amount of resources needed.