The purpose of this week's labsheet is to introduce you to some basic Network Layer routing concepts, and to help you understand the importance of the separation of the responsibilities of protocol layers.

The Linux directory /cslinux/examples/CITS3230/Lab4 contains cnet implementations of 3 Network Layer flooding algorithms of increasing complexity and efficiency.

1. Create a new directory for this labsheet, and take a copy of all files from /cslinux/examples/CITS3230/Lab4. Before examining any source code files, read the two files 1st.README and 2nd.README.

2. Next, run each of the flooding implementations with, for example, the command cnet FLOODING1.

   Observe how the number of messages per unit time and the delivery efficiency improves with each successive protocol. Use the provided getfloodstats shellscript to automate the execution of each protocol, and the plotfloodstats.gp GNUPLOT script to plot the results.

3. All 3 flooding implementations share a number of source code files - notably code to implement a basic Data Link Layer and code to implement a simple Network Layer routing table. Each cnet topology file indicates which source files are to be compiled to build one of the 3 flooding implementations.

   Examine the implementation of dll_basic.c, which provides a minimal reliable Data Link layer. It avoids any frame loss and corruption at the Physical layer (it cheats!) by calling CNET_write_physical_reliable() instead of CNET_write_physical(). Because "nothing can go wrong", we don't need to manage any sequence numbers or buffers of frames in this layer, and our DLL_FRAME structure can consist of just its payload (the NL's packets). Of course, this is rather unrealistic.

   Replace the implementation of dll_basic.c with a stopandwait protocol, as seen in earlier labsheets. Making such a change to a single file should then provide more realistic implementations of all 3 flooding protocols. Note, that each node will require an instance of the stopandwait protocol to execute on each of its links.

   Before making extensive changes to the provided code, carefully consider what changes you may need to make to support the stopandwait protocol.

4. HARD: All 3 flooding protocols limit the maximum distance travelled by any single message, through the use of the constant MAXHOPS. This is set to 4 for AUSTRALIA.MAP, but for a larger map, such as WORLD.MAP, such a limitation will actually prevent distant nodes from communicating at all.

   Can you devise a modification to the flooding3 protocol to support topologies with lengthy paths?

Chris McDonald

April 2008.