Skip to the content.

NetDevice Up/Down Consistency and Event Chain

This is a summary of what was done as part of Google Summer of Code 2020 during June 2020 to August 2020 with the organization ns-3.

Student: Ananthakrishnan S

Mentor: Tommaso Pecorella

I would like to thank Dr. Mohit P. Tahiliani for motivating me to apply for the program, my mentor Tommaso Pecorella for the guidance throughout the program. I would also like to thank Tom Henderson, Rediet and all the others who helped me increase the quality of my work.

Introduction

Network device or netdevice is the representation of Network Interface Card (NIC). Any network transaction is made through a Network device, that is, a device that is able to exchange data with other hosts. Usually, a Network device is a hardware device, but it might also be a pure software device, like the loopback interface. A network device is in charge of sending and receiving data packets, driven by the network subsystem of the kernel, without knowing how individual transactions map to the actual packets being transmitted. Many network connections (especially those using TCP) are stream-oriented, but network devices are, usually, designed around the transmission and receipt of packets. It resides in L2 (Link layer) in the Linux network stack. NICs are of different types that enable communication with different types of networks. For example, if you want to connect your computer into a LAN, your computer needs an Ethernet card installed on it. Same goes for Wifi, LTE, etc.

Ns-3 offers a rich set of Network devices which helps simulate various types of network. Some of the netdevices in ns-3 include WifiNetDevice that enables simulation of wireless networks, PointToPointNetDevice that can be used to simulate point-to-point networks, CsmaNetDevice that can be used to simulate Ethernet topologes, LteNetDevice for LTE networks, etc.

States of a Net device

Linux distinguishes between the administrative and operational state of an interface (netdevice). Administrative state reflects whether the administrator wants to use the device for traffic. A device can be in UP or DOWN administrative state. The administrative state can be change using commands such as ifconfig or ip. For example, ip link set dev eno1 up sets netdevice eno1 to UP state and ip link set dev eno1 down sets netdevice eno1 to DOWN state. When a device is plugged in, it is automatically configured for use.

However, an interface is not usable just because the admin enabled it - ethernet requires to be plugged into the switch and, depending on a site’s networking policy and configuration, an 802.1X authentication to be performed before user data can be transferred. The operational state shows the ability of an interface to transmit this user data.

RFC 2863: The Interfaces Group MIB defines operational states for a netdevice. It is clearly described in linux kernel documentation as follows:

IP layer, DHCP, FIB, etc listen to any state changes happening in a netdevice and takes appropriate measures upon detection of state change. For example, When the administrative device of a Net device is set to DOWN, IP needs to be disabled for that device and routes associated with the device needs to be updated so that those routes are no longer used.

Problem Statement

Objectives

This project aims to do the following:

Project Overview

The project is divided into three phases as follows:

Phase 1: Define behavior of NetDevice API and correct PointToPointNetDevice.

In this phase, Linux kernel code was examined to get a glimpse of the working of netdevice states and on the basis of that an architecture was created. All throughout the coding period, the architecture went through several changes as suggested by mentors. As a result, the final proposal is modeled after RFC 2863: The Interfaces Group MIB.

A useful document describing the working of device states and notifications in Linux prepared as part of this project can be found here.

First iteration of NeDeviceState architecture can be found here.

Differences between how states change in Linux and the proposal (not final) can be found here.

The final proposal of NetDeviceState architecture that is agreed upon by everyone can be found here.

A new class NetDeviceState is designed that contains administrative and operational states of a Net device. It also has trace sources that allow higher layer protocols to listen in on state changes. A netdevice wanting to use this feature can aggregate the object of this class using ns-3’s object aggregation system. These features are enclosed in a new class because it is decided that not all netdevices would want to use this feature. There are two ways to aggregate NetDeviceState object to a netdevice:

Some of the operational states described in RFC 2863 is not relevant to ns-3. They are excluded from the implementation. They are:

A merge request was generated for this work. At the time of writing this report, it needs to be merged.

It was decided that instead of extending NetDeviceState class for PointToPointNetDevice, it would be better to extend it for CsmaNetDevice. This is because there are functions in CsmaNetDevice that can be used to attach, detach and reattach the device from the channel and it would be more suitable than PointToPointNetDevice to test the architecture.

Phase 2: Correct CsmaNetDevice and WifiNetDevice.

CSMA Module

Csma module was examined and following problems were identified:

The following changes were made in csma-module to properly change operational states:

Other additions include:

A merge request is generated for this work which is under review.

Wifi Module

Out of all the netdevices that are selected to correct as part of this project, WifiNetDevice is the best when it comes to state changes. Without the NetDeviceState architecture, Wifi uses the existing facilities in ns-3 to change link state when connected/ disconnected from a channel. Changes made in wifi-module is as follows:

A merge request has been made to merge this work which is under review.

Phase 3

In Phase 3, it was planned to examine higher layer protocols such as IPV4, IPv6, DHCP, ARP etc to see whether they are correctly reacting to state changes happening in the Net device. Unfortunately I was not able to do that. IT was decided to work on PointToPointNetDevice that was postponed in Phase 1.

PointToPointNetDevice always stays in UP state. This device cannot be detached from the channel; It has no functions present to detach and reattach itself to a channel. Some problems need to be solved before extending NetDeviceState architecture to PointToPointNetDevice.

At the time of writing this report, last two issues have been addressed and is under testing.

What is next?

Unfortunately, not all goals as described in the project are accomplished. The following goals are remaining and will be completed in coming days: