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.
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.