GSoC-2017: Implementation of Ethernet Principal by Saurav Kumar

gsoc.md

AIM: During GSoC-2017, I was allocated the task to implement the Ethernet Principal which represents interfaces in Linux-XIA meta-architecture. This was supposed to be placed as an TCP/IP architecture's layer 2 counterpart, currently implemented as HID principal(Host-ID). Every time that a packet had to be sent to a neighbour the layer-2 header had to be created again and again. So to avoid that Ethernet principal caches those headers and even updates them when needed, so as to decrease the overheads of creating packet headers.

XIA-for-Linux Code Repo
XIACONF Code Repo

DELIVERED: I have successfully implemented the Ethernet Principal in the kernel code along with the user-space code to handle its routing tables. My work was split into 3 phases:

• The first part was to work in the kernel code where XIA implements each principal as a separate module, thus, making it easier to work on a new principal. As visible by going through the commits, we can see there are 5 parts to the coding:
  1. Making a basic template of the principal using XIA's wiki page on making a new principal.
  2. Interfaces are represented as ether_interface in the code and as soon as they are up, the eth_ptr added inside the net_device struct is initialized and as it goes down, it is initialized to NULL. This representation of interfaces separately inside Ethernet principal helps us to easily keep a track of what neighbours can be reached through a given interface.
  3. Next two commits represent the two type of fib-xid-tables that each principal has: local and main. The local table holds the list of interfaces that are on that host, whereas main table has enteries representing a host's neighbour over its LAN.Each table has 4 functions associated with them: newroute,delroute,dump,free. Newroute adds a new entry, delroute deletes an entry from the table, dump returns all the enteries available inside the table, and free removes an entry from the kernel memory.
  4. The main step of the coding was to add cached headers to the main-table enteries and their updation upon the host interface MAC address change event. As soon as an main table entry was added its cached header was initialized. Cached header is always up to date with the host interface MAC address as the NETDEV_CHANGEADDR event has been registered to call a function to update the headers associated with that interface.
  5. Next step was to add the delivery function which will use the cached header to forward the packet instead of reforming the header again and again. When an interface goes down, the cached headers become invalid as their header len's are initialized to 0 and is a necessary condition to forward the packet.
• After completing my kernel code, I had to add a new command to Xiaconf, controls the principal tables from userspace, so as to manipulate the tables from the userspace as can be seen by the commits. This required the use of rtnetlink messages.
  1. First step was to create a basic template using the XIA wiki page.
  2. Now i had to add the local table functionality to add or delete a local interface by providing its ifname and the application will on its own create a fib-xid using the ifindex and its MAC address and accordingly send a rtnetlink request to the kernel.
  3. Similarly i added the main table functionality to xiaconf ether command which needed a neighbour MAC address too along with the interface name used to reach it. The last step was to add the dumping functions which will fetch all the enteries inside the local or the main table.
• The last and the most part of the project was to run,debug,re-evaluate and do the same process again. This required me to ponder over the issues and try and find a roundabout way around them. My commits in the development branch of the code show how many times the code had to be updated and re-compiled to resolve the issues.
  1. The main tool used for checking the main and local table functionality was Xiaconf and nltrace. Nltrace allowed me to view the rtnetlink message requests that were being sent to the kernel and allowed me to understand whether the bug was inside the user-space code or the kernel-space. Eventually a working table was obtained as can be seen in the image.
  2. The delivery system was evaluated using linux-containers, net-echo scripts and net-eval scripts. The containers were setup in two topologies along with 2 containers in each one:
     • Connected topology was the one where each container was connected to each other as well as the router(host-machine) through a single bridge xia0br. One was setup as client and another as host and successful communication was established between them.
     • Star topology had two containers connected to the router through different bridges and were not connected to each other like a V shape with each corner representing a machine. Here the packets went through the router and the router was set to forward packets accordingly.

After coding and evaluation from my side were finished, mentors reviewed my code for styling and other errors as can be seen by following pull request links for XIA-for-Linux and Xiaconf.

FUTURE WORK: Right now the ethernet principal can forward the packets and maintain the tables but needs to be provided with info like the neighbour MAC address and the interface required to reach that neighbour. So a neighbourhood watch protocol, i.e., NWP has to be implemented in the user-space which will keep a track of the neighbours that are connecting, or disconnecting and what enteries need to be deleted from the tables.