Cicn

From fd.io
Revision as of 09:51, 24 February 2017 by Acompagn (Talk | contribs)

Jump to: navigation, search
CICN Facts

Project Lead: Luca Muscariello
Committers:

  • Luca Muscariello
  • Jim Gibson
  • Jordan Augé
  • Michele Papalini
  • Mauro Sardara
  • Alberto Compagno

Repository: git clone https://gerrit.fd.io/r/cicn
Mailing List: cicn-dev@lists.fd.io
Jenkins: jenkins silo
Gerrit Patches: code patches/reviews
Bugs: CICN bugs

Get Involved

Introduction

Information-centric networking (ICN) is an approach to evolve the Internet infrastructure to directly support data-centric and location independent communications by introducing uniquely named data as a core Internet principle. Data access becomes independent from location, application and storage, enabling in-network caching and and anchor-less mobility. The expected benefits are improved efficiency, better scalability with respect to information/bandwidth demand and better robustness in challenging communication scenarios. These concepts are known under different terms, including but not limited to: Content-Centric Networking (CCN), Named Data Networking (NDN), the network of information (Netinf) and Publish/Subscribe Networking (PSIRP).

In this project the focus is on the Content-Centric Networking implementation (CCNx 1.0) that is under specification in a number of documents of the IRTF ICN research group [1], [2]. The seminal papers describing the CCN architecture [3] and NDN [4] report in great detail the characteristics of the two systems. Differences among the two architectures, especially between CCNx 1.0 and NDN are minor and currently object of a converge effort at the IRTF [5]. The current project scope is on CCNx 1.0 in view of the evolutions driven by the harmonization effort. The architecture evolution is community driven and the implementation would focus on the harmonization work made by the community as a whole. The project will also provide a number of applications that can be used by the community to demonstrate the concept as well as run experiments at scale to evaluate the advantages and benefits of the ICN concept in concrete use cases like video delivery across 5G networks.

The project scope includes CCN network architecture implementation: packet processing as well as networking socket API. Packet processing will be made available through two main forwarders one based on the VPP framework and one based on sockets to deploy CCN in non VPP environments. The project will focus on the CCNx 1.0 specification [1] as a reference implementation, but would evolve by keeping track of the work done in the convergence group at the IRTF [5]. While the main focus is on the VPP plugin, the socket based forwarder will be used to enable end-to-end chains testing, supporting end devices that do not support VPP. Moreover, for the VPP forwarder, CCNx 1.0 packets will be transported using IPv4 encapsulation in the first place. This encapsulation will constitute the main focus for the VPP plugin while the socket-based forwarder could also support Ethernet encapsulation as an additional transport example.


In more detail, early releases would include:

  • 1. A VPP forwarder plugin,
  • 2. A socket-based forwarder,
  • 3. The consumer/producer API,
  • 4. A number of support libraries,
  • 5. Examples of CCN applications, including but not limited to an end-to-end example for HTTP ABR video delivery (player and server),
  • 6. Tools suitable to assist with development and testing.

Code organisation

The repository is organized in several orphaned branches (technically they have a common empty root), each one containing a sub-project. The naming convention naming branches is described in this document.


Branch naming conventions

Project cicn contains several sub-projects. Sub-project subp has a master branch with name origin/subp/master. All commits associated to sub-project subp will belong to the orphaned branch origin/subp. All branches associated to subp must be named as subp/branch-name.

Sub projects contained in the cicn git repository

  1. cicn-plugin
  2. sb-forwarder
  3. libicnet
  4. cframework
  5. ccnxlib
  6. http-server
  7. viper
  8. vicn
  9. android-sdk

Sub projects description

Name Description Language and style
1. cicn-plugin VPP forwarder C GNU style
2. sb-forwarder socket-based forwarder C99 Google style
3. libicnet socket API C++11 Google style
4. cframework C framework C99 Google style
5. ccnxlibs CCNx libraries C99 Google style
6. http-server HTTP server C++11 Google style
7. viper Qt/QML video player C++/QML Qt style
8. vicn vICN framework python-3 and bash
9. android-sdk Android SDK for ICN cmake

Example:

How to manage different master branches

It is suggested to clone each subproject branch in a different workspace to avoid error prone operations. The cicn git repo stores several projects which are independent one to another. While access control and isolation is guaranteed at a certain level by gerrit, using one single workspace is discouraged.

git clone -b cicn-plugin/master  https://gerrit.fd.io/r/cicn cicn-plugin;
git clone -b sb-forwarder/master https://gerrit.fd.io/r/cicn sb-forwarder;
git clone -b libicnet/master     https://gerrit.fd.io/r/cicn libicnet;
git clone -b cframework/master   https://gerrit.fd.io/r/cicn cframework;
git clone -b ccnxlibs/master     https://gerrit.fd.io/r/cicn ccnxlibs;
git clone -b http-server/master  https://gerrit.fd.io/r/cicn http-server;
git clone -b viper/master        https://gerrit.fd.io/r/cicn viper;
git clone -b vicn/master         https://gerrit.fd.io/r/cicn vicn;
git clone -b android-sdk         https://gerrit.fd.io/r/cicn android-sdk;

For committers

By having multiple sub-projects in the same repo, it is highly recommended to use the following approach while using branches and pushing patch sets.

$ subp = cicn-plugin
$ committer = user

$ git clone -b $subp/master ssh://$committer@gerrit.fd.io:29418/cicn $subp;
$ scp -p -P 29418 $committer@gerrit.fd.io:hooks/commit-msg $subp/.git/hooks/;

If you use an email alias like user+fdio@email.com that is registered in the gerrit frontend it is recommended to set the following kind of configuration.

$ git config --local user.email "$committer+fdio@email.com"
$ git config --local alias.push-for-review "push origin HEAD:refs/for/$subp/master"

This allows to avoid pushing for review to different sub-project branches using the command

$ git push-for-review


References