Qolyester’s virtual interface TER/Stage Maitrise informatique

8th June 2004 version 1.0

Benoit Bourdin Tutor: Khaldoun Al Agha

1

Introduction We already heard about wireless networks, nevertheless the research in this domain is still growing, especially at the LRI (Laboratoire de Recherche en Informatique), where I did my training period. It’s about ad-hoc networks : a wireless network which provides an efficient and intelligent routing. First, a routing protocol has been made for ad-hoc networking : OLSR (Optimized Link State Routing Protocol, see RFC 3626 for details). The team worked on an implementation of this protocol with additional functionalities : QOLSR, QoS (Quality Of Service) on OLSR. For example, choosing a best route to for a better bandwidth on the network. According to these concepts, a routing daemon has been programmed: Qolyester. Like any program, the team may run a lot of tests to debug and improve it. But here is the problem : it’s not simple to build a big network, whose nodes can be moving constantly, without having a lot of mobile devices (which is an expensive solution). That’s why my work was to develop a platform to simulate a big network at a low cost, on a single machine. I had to study the existent program in order to modify it and change the minimum. After this, I will present my solution to this problem and explain it in this present report. In agreement with my placement tutors, this report is in English, in order to be published on the Qolyester’s website (http://qolsr.lri.fr). I will thanks Ignacy Gawedzki, Khaldoun Al Agha and Hakim Badis for their help all along my training period.

2

1

Qolyester

In this this short part, we will summarise the analysis of Qolyester.

1.1

Basic networking

Qolyester’s network activity is very simple : send hello messages to all the network (broadcasting), and receive hellos from his neighbors. It only uses the UDP protocol. Also, the only routine we must implement is sending a packet manually to the Qolyesters neighbors.

1.2

Low-level interface

Qolyester uses system calls to communicate with the kernel layer, for only two kinds of operations : • Socket communication, the network link. • Netlink, to change kernel routing tables at runtime. The first one is localized in the classes Interface, InterfaceInfo and Socket. Also, for each one, we decided to create an alternative (VirtualInterface, VirtualInterfaceInfo, etc) for the virtual interface. The second is more simple : we must be sure there’s no Netlink order during our simulation, because we don’t want the system’s routing tables to be modified. All the Netlink classes are in the sys/linux folder. We created a sys/virtual folder, containing empty classes.

1.3

Modularity

The virtual interface in Qolyester can be activated at compilation time, using the parameter –enable-virtual to configure script. Each time we could, we preferred creating new classes instead of using #ifdef macros, which is a better object approach.

3

2

Communication

We will present here our solution and his data model.

2.1

Socket networking

Our goal is simple : communicate a packet from a process to another one on the same machine. We had the choice : • System V IPC : – Shared memory – Pipes – Signals • Sockets : – Standard SOCK DGRAM sockets, as already used in Qolyester – Unix sockets – Socket pairs System V IPCs wasn’t a good choice : it may cause some problems (for example, find a good id in shared memory) and needs to create a new protocol for data exchanges. Using sockets is a better solution : we can use the UDP interface and also SOCK DGRAM packets. Within the socket library, our choice will be unix sockets : simple to use, doesn’t have a port problem (with standard sockets), and doesn’t need we launch the other process ourselves (with socket pairs). Unlike standard sockets, we bind to a file (and not to a local port) and send to another socket file (and not to a specific IP/port). Moreover, we can be sure packets are not lost without having an error. However, there’s more than one network model to simulate a virtual network. We chose to create an external program, called Qolyester-switch, that is used to redistribute packets to the neighbors. As we can see on the figure below, each qolsr program sends its packets to the switch, which sends it to the appropriates processes.

2.2

Modelling

In order to test, the user could be able to specify a particular configuration : the network. The network is represented by a graph, given by the user as 4

a single configuration file. We chose a known format to represent the graph : the .dot format (http://www.graphviz.org). See a sample dot file in annex. Also, the switch program is the only one to see the entire graph, given by the user. Thus, it is possible for the switch to allocate IP addresses and specify which process will have which IP address.

Figure 1: The network model

2.3

The implemented protocol

In order to establish a communication between the switch and the clients (the Qolyester processes), we must have prepared a protocol. First, we decided that the switch will bind to a special filename (taken as argument of the command line), that must be specified later to each client, and begin to listen (by using receive()). When a client is launched, it binds to another filename (generated randomly) and sends a packet : either an empty packet, or an IP address to say ’I want this IP, is it possible ?’. The switch detects it’s a new client (unknown filename), finds an available IP address and sends it. The client receives it, and reply it by an acknowledgement (a boolean, true if ok, false otherwise). After this initialization (not unlike a three-way handshake), all packets are sent to the switch, which simply forwards to the other nodes. Anyway, on the other side we need to have a real IP address for the sender (to send to the core of Qolyester). Thus, the sender put his IP address in header, that is got on the other side, on the other Qolyester process.

5

Figure 2: Initialization

2.4

Evolutions

In the graph, we could add a cost to each arc. In practical terms, it can be a packet loss’ factor. Also, we added a percentage to each arc (0% by default, no loss). Each time the switch receive a packet, it sees randomly if the packet should be lost or not. The system primitives (rand(), srand()) to find pseudo-random integers need a (pseudo-random) seed (an integer) to be initialized. In that way, by giving the same seed, we got exactly the same behaviour. Thus, the user can enter a specific seed. This evolution is already implemented and tested. Moreover, we imagined to add another parameter for each arc, a variable bandwidth on each link. We could add too a possibility to use multiple interfaces : one Qolyester process could be connected by more than one interface/IP/socket to the same switch, and to more than one switch. We could add the ability to connect two switches and create a protocol between them. Another interesting evolution would be to allow the graph to be modified at runtime, as if the nodes could move. It would be important to test Qolyester. A GUI (Graphical User Interface) could be created for the switch, to be more simple to use, to see the network, move nodes at runtime and watch Qolyesters processes.

6

Annexes 1. Sample .dot file 2. Manual pages : • qolsrd (1) • qolsrswd (1)

7

sample.dot

# graphe name : test123 digraph test123 { # defining 3 nodes : a, b and c # IP (IPv6) and prefix a [IP="fec0::1", prefix=128]; b [IP="fec0::2", prefix=128]; c [IP="fec0::3", prefix=128]; # defining 2 arcs with 25% of packet loss a -> b [loss=25%]; a -> c [loss=25%]; # defining 2 arcs on a single line b -> c -> a; }

8

qolsrd(1)

qolsrd(1)

NAME qolsrd − Qolyester OLSR daemon

SYNOPSIS qolsrd -i interface[,...] [OPTION]...

DESCRIPTION qolsrd is the Qolyester daemon. Qolyester is an implementation of the Optimized Link-State Routing (OLSR) protocol for mobile ad hoc networks.

OPTIONS -i, --interfaces=NAME[=ADDR],... Specify the list of network interfaces to take part in the OLSR network. At least one network interface must be specified. Additionally, the address to use can be specified, but it must be set beforehand. In virtual mode, the name must be virt, num must be between 0 and 9. -f, --switch-sockfile=FILENAME Set the filename to be used for communication with the Qolyester’s switch. This will be the same socket filename given as argument to qolsrswd. -o, --other-networks=ADDRESS/PREFIX,... Declare the list of external networks to be announced to the OLSR network. -w, --willingness=WILL Set the initial willingness to become a MPR. WILL must be an integer between 0 (never) and 7 (always) or one of the following keywords: never, low, default, high, always. The default willingness is 3. -t, --tc-redundancy=REDUNDANCY Set the TC message redundancy. REDUNDANCY must be one of the following keywords: mprsel, mprsel+mpr or symset. The default is mprsel. -m, --mpr-coverage=COVERAGE Set the MPR coverage. COVERAGE must be a positive non-null integer. The default is 1. -v, --verbose Print various debugging messages. --error-file=FILE Set the file to which error messages are to be written. By default, error messages are printed on stderr. --warning-file=FILE Set the file to which warning messages are to be written. By default, warning messages are printed on stderr. --notice-file=FILE Set the file to which notice messages are to be written. By default, notice messages are printed on stderr. --dump-file=FILE Set the file to which debugging/illustrative dumps are written. By default, dumps are printed on stderr.

9

-h, --help Print brief usage instructions on stderr. -n, --no-detach Prevents the daemon from detaching from the control terminal. This is provided for debugging purposes. If any of the --dump-... flags is used, either -n is used as well or --dump-file is used to specify a file to which to dump.

qolsrd(1)

qolsrd(1)

--no-tables Prevents the daemon from modifying the routing tables. This is provided for testing purposes. --version Print current version information on stderr and exit. --dump-hello Dump contents of sent and received HELLO messages. --dump-tc Dump contents of sent and received TC messages. --dump-mid Dump contents of sent and received MID messages. --dump-hna Dump contents of sent and received HNA messages. --dump-all Dump contents of all sent and known received messages. --dump-state Dump the internal state every second. --dump-prof Prints the time in seconds spent in each event loop. --gc-period=MSEC Sets the garbage collecting interval to MSEC milliseconds instead of the compiled-in default.

BUGS There are certainly lots of bugs left. Please let me know. Qolyester only runs on Linux kernel 2.4 series for the moment, porting to *BSD is not my primary concern, but any external help in this direction is welcome.

AUTHOR Written by Ignacy Gawedzki .

COPYRIGHT Copyright (C) 2003 Laboratoire de Recherche en Informatique. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

SEE ALSO As of version 0.1, Qolyester conforms to the OLSR IETF draft version 11 which can be found at http://www.ietf.org/internet-drafts/draft-ietf-manet-olsr-11.txt . qolsrswd(1)

10

qolsrswd(1)

qolsrswd(1)

NAME qolsrswd − Qolyester’s switch

SYNOPSIS qolsrswd graphfile sockfile [random seed]

DESCRIPTION qolsrswd is the Qolyester’s switch daemon. It may be used with a qolsrd compiled with virtual networking. The Qolyester’s switch is used to simulate a network on a machine, and connect the Qolyester daemons using unix sockets.

OPTIONS graphfile Specify the emplacement of the configuration file, see below. sockfile Declare a socket filename to bind to. random seed Select a particular random seed to be given to srand().

CONFIGURATION The configuration file describes the network as a graph, not unlike dot format. See dot manual for more information. Each node must have the following attribute : IP="address", the IP address for this node. Each arc can have the following attribute : loss=x%, loss percentage for packets, must be >=0 and