Reference no: EM132866755

COSC 364 Internet Technologies and Engineering - University of Canterbury

Administrivia

This assignment is part of the COSC 364 assessment process. It is worth 30% of the final grade. It is a programming project in which you implement parts of the RIP routing protocol [1] and run several instances of a RIP demon under the Linux operating system on the same machine (no virtual machines involved!) - each instance runs as a separate process, and processes communicate through local sockets. You will emulate a small network and explore the response of the RIP protocol to di↵erent types of faults.

You will work in groups of two persons, it is not an option to work alone or in larger groups, unless you have very convincing reasons (mere convenience is not convincing) and have obtained explicit approval by me (normally by e-mail). Submissions by individuals or larger groups without such approval will not be marked. I will help with pairing.

You can use Python, Java or C, and you have to use the socket interface implementation that is available for your programming language. Your program has to be executable under Linux (more precisely: it should run on the machines in Lab 4).

It is quite likely that the problem description below leaves a lot of things unclear to you. Please do not hesitate to use the "Question and Answer Forum" on the Learn platform for raising and discussing any unclear issues.

Important: Before reading the following problem description in more de- tail, it is absolutely essential that you read the RIP specification [1]. The scope of this project is essentially given by Section 3 of [1], none of the extensions in Section 4 is to be included (if you do nonetheless, no credit will be given).

Problem Description

You will implement a "routing demon" as a normal userspace program under Linux. Instead of sending its routing packets over real network interfaces, your routing demon will communicate with its peer demons (which run in parallel on the same machine) through local sockets.1 Your program should be a text mode program, no credit will be given for providing a graphical user interface.

Roughly speaking, your program will operate in three stages:

At the beginning it reads a configuration file (whose name has to be sup- plied as a command line parameter - please avoid any interactive reading of the filename) which contains a unique identification for the routing demon instance, the port numbers on which the demon receives routing packets from peer demons (input ports), and specifications of the out- puts towards neighbored routers. Clearly, any output port declared for one router should be an input port of another router. The information in the configuration file is only meant to inform demons about links, the demons internal routing table is still empty at this stage.

Next the demon creates as many UDP sockets as it has input ports and binds one socket to each input port - no sockets are created for outputs, these only refer to input ports of neighbored routers. One of the input sockets can be used for sending UDP datagrams to neighbors.

Finally, you will enter an infinite loop in which you react to incoming events (check out the select() system call or its equivalent in your fa- vorite programming language.2) An incoming event is either a routing packet received from a peer (upon which you might need to update your own routing table, print it on the screen, or possibly send own routing messages to your peers), or it is a timer event upon which you send an unsolicited RIP response message to your peers. Please ensure that you handle each event atomically, i.e. the processing of one event (e.g. a re- ceived packet) must not be interrupted by processing another event (e.g. a timer).

All the routing demons will be instantiated on the same Linux machine, so you will have to use the IP address for the local host (127.0.0.1). You should use the UDP protocol for routing messages.

One hint for your design: many protocol specifications (and even more so their implementations) are expressed using the formalism of extended finite state is not absolutely and strictly necessary to run each demon as a separate process, it is also legitimate to have several threads in the same process. However, it is strictly necessary to have the ability to stop and machines or finite automata (i.e. state machines / automata that have variables added and where transitions can be conditioned on both an event and the value of one or more variables). This can be a very useful design framework. You would have to identify all possible events, the set of variables, and the set of states. You then have to specify for each state what will happen when when an event comes in. This has to be done for each event.

The Configuration File

Your program should be a single executable which can be started with a single command line parameter. This parameter will be the filename of a configuration file. The configuration file should be an ASCII file that can be read and edited by humans. I recommend to choose a very simple syntax for the configuration file and to keep the parser very easy, no extra credits will be given for an elaborate syntax (nothing XMLish or any other similarly baroque format!), fancy parsing code or the like. However, basic syntax and consistency checks (when a number is expected it should be checked that indeed a number is present and is in the allowed range) should be made. Each instance of the router demon will be started with a separate configuration file.

The configuration file should allow users to set at least the following param- eters (one parameter per line, please allow for empty lines and comments):
Router id, which is the unique id of this router. A suggested format for this parameter is:

router-id 1

The router id is a positive integer between 1 and 64000. Each router must have its own unique router-id, and thus each router configuration file must have a di↵erent value for this parameter.

Input port numbers: this is the set of port numbers (and underlying sock- ets) on which the instance of the routing demon will listen for incoming routing packets from peer routing demons. There needs to be a separate input port for each neighbor the router has. A suggested format for this parameter is:
input-ports 6110, 6201, 7345

i.e. the port numbers could be separated by commas. You do not have to follow precisely this format, but your parser for the configuration should ensure that:
- All port numbers are positive integers x with 1024 x 64000 (find out why 1024 was chosen as lower bound!)
- You can specify arbitrarily many such entries, but all in one line
- Each port number occurs at most once.

Outputs: here you specify the "contact information" for neighboured routers, i.e. routers to which a direct link should exist and with which you exchange routing information. A suggested format for this parameter is:
outputs 5000-1-1, 5002-5-4

As before, di↵erent outputs are separated by commas. For one output, for example 5002-5-4, the first number 5002 specifies the input port number of the peer router, i.e. the port number on which the peer router will listen to packets from the current instance. The second number 5 represents the metric value for the link to the peer router. The third number 4 represents the router-id of the peer router, so that your instance knows which router is really behind this link. The port numbers given here must satisfy the same conditions as the port numbers given for the input-ports parameter. Furthermore, none of the port numbers given for the outputs parameter should be listed for the input-ports parameter. The metric values should conform to the conditions given in [1].

Values for the timers you are using in your implementation. It is wise to use timer values (for periodic updates and timeouts) smaller than the ones given in the standard, since this can shorten experimentation times. However, please ensure that the ratio of the timer values remains the same (180/30 = 6 for timeout vs. periodic, similarly for garbage collection).

The first three parameters (router-id, input-ports, outputs) are mandatory, if one of them is missing your program should stop with an error message. When you set up several configuration files (one for each router), you must ensure manually that the following conditions are met:

• The router-id's of all routers are distinct
• When you want two routers A and B to be neighbored, you should:
- provide an input port x at B that is also listed as output port of A
- provide an input port y at A that is also listed as output port of B
- ensure no other host than A has listed port x as an output port
- ensure no other host than B has listed port y as an output port
- ensure no other host than A has listed port y as an input port
- ensure no other host than B has listed port x as an input

- and finally, ensure that the metrics that A specifies for its output with port number x is the same as the metric that B specifies for its output port y.

Exchanging Routing Packets and Route Computations

In this section it is assumed that you are already intimately familiar with the RIP protocol specification [1]. Here we will just give a few hints on which parts of the specification can be ignored, should be simplified, or need to be modified. Scope of implementation is essentially Section 3 of [1]. None of the extensions in section 4 is to be included (no extra credit).

Please implement split-horizon with poisoned reverse. This means that for any update message or unsolicited response a separate packet needs to be created for each neighbor.

Implement triggered updates only when routes become invalid (i.e. when a router sets the routes metric to 16 for whatever reason, compare end of page 24 and beginning of page 25 in [1]), not for other metric updates or new routes.
Do not use the UDP port specified in [1], but the port numbers from the configuration file.

Do not implement request messages, you should use only the periodic and triggered updates.
• The version number is always 2.
You do not route to subnetworks and do not handle IPv4 addresses, but you only route to the various routers (as identified by their router-id). You also do not need to take care of default addresses, host routes or subnet masks.

RIP response packets always include the entire routing table, and to each neighbor a separate copy of this table is sent (according to the split- horizon-with poisoned reverse rule, which implies that each neighbor might get a di↵erent view of the table).

Do not multicast response messages, just send them to the intended peer through its input port.
• Packet format:
- Ignore the issue of network byte order

- Please use the 16-bit wide all-zero field in the RIP packet common header for the router-id (since otherwise you would have no identifi- cation of the router sending out an update. Furthermore, you should also work with router-id's instead of IPv4 addresses.
- Please perform consistency checks on incoming packets: have fixed fields the right values? Is the metric in the right range? Non- conforming packets should be dropped (and perhaps a message printed, this helps your debugging).

Regarding periodic updates: You need to find out how to generate periodic timer events and how to write own handlers for this event. This depends on your choice of programming language. It could also be useful to introduce some randomness to the periodic updates, for example by setting the timer in question randomly to a value that is uniformly distributed over the range [0.8•period, 1.2•period]. Why could such a randomization be useful?
Some other things:

If a demon has several input ports, it needs to listen to all of them simul- taneously. This can be achieved through the select() system call or its equivalent in your chosen programming language.

It goes without saying that you should perform various tests with your setup. These tests should show that your routing protocol design and implementation converge to the "right" routing tables (which you will have to establish from inspection) and respond "in the right way" to certain failure events (e.g. one process is shut down and re-started later). To properly conduct these tests it is also important to formulate in advance which behaviour your implementation should show and to compare the actual outcome against it.

Attachment:- Internet Technologies and Engineering.rar