This is a group project. Groups were formed pseudo-randomly, based on the 2nd last digit of your student ID:
You can contact members of your group by emailing them using addresses of the form firstname.lastname@example.org where z1234567 is a student ID.
- Group 0,5: 5103908
- Group 1,8: 5126611
- Group 2,6: 3463420
- Group 3: 5138734
- Group 4,7: 5103448
- Group 9: 5086296
For the TELE9751 programming project you will write a module for a software-based switch. Software-based switching can be used with a PC and multiple interface cards to implement a low-performance switch, or can support processor virtualization, as in the following article: Look, Ma, No Hardware: Cisco's Virtual Switch
The module will work in the framework of the software switch developed by Dan Iuliano as a 4th year thesis. His thesis is available here (Fig. "c" on p. 44 gives a good overview of how the software modules interact) and his software that shows the framework and gives examples of a tree classifier, Banyan fabric, and round robin scheduler is available here
You can use just about any language you like to write your module, except not Matlab since an aim of this is to develop a module that is similar to what could be used in a production software switch, and nobody wants to have to include a large simulation environment with each installation of their switch. The language must support sockets in order to work with other modules of the software switch.
The framework has some existing bugs:
- Banyan fabric: Element is marked as used only if packet is going down, not if going up
- Generator: To work with the classifier, the generator needs a smaller range of addresses s.t. likely that generated addresses are stored in classifier. Might achieve by configuration file listing IP addresses, or ranges (e.g. with prefix length).
||Others that you could implement
||Group 0,5: Trie with one 5b stride then 2b strides
Group 1,8: Hashing (write your own hashing function rather than using a library)
|Trie, Bridge that populates classifier by learning from traffic
||Group 2,6: Batcher-Banyan (you can achieve 90% of the marks by using a normal software sorting algorithm rather than simulating a batcher sorting network)
Group 3: Crossbar with knockout
|Clos (circuit-switched emphasis may require rethinking classifier), Crossbar with scheduler (PIM or iSLIP)
||Group 4,7: Weighted Round Robin
Group 9: Weighted Fair Queueing
|The types of components below are more basic => you might be asked to implement 2 of them
||Take real packet traces in pcap format and play out in simulation
Preliminary marking criteria (in order of increasing cumulative difficulty = marks):
("to" indicates that I thought the percentage was a little high. Obviously real submissions won't fit neatly into this cumulative ranking, e.g. something might be robust but not well instrumented. These are just guidelines.)
- (30%) The component demonstrates some understanding of the function being implemented, e.g. a Banyan fabric has log2P stages, each with P/2 2x2 switches...
- (50-60%) The component works, e.g. fits into the framework and implements the component.
- (to 70%) The component is easy to understand in terms of documentation of parameters and how the software is written.
- (to 80%) The component is well instrumented, e.g. shows what implementation cost there might be. e.g. number of instructions executed, amount of memory needed, etc
- (90%) The component is general/scalable, e.g. can handle varying numbers of ports (unlike the sample Banyan fabric)
- (95%) The component is robust, e.g. properly handles mal-formed inputs, e.g. letters in configuration file where numbers are expected
- (100%) Unexpected magic
You should attempt to measure the (simulated) performance of your module, and show trade-offs between dimensions of the module and its performance (e.g. for a buffering module: between the size of a buffer and its packet loss rate).
All members of a group will receive the same mark, since the marking is of the component, rather than the process within your group that led to the component. Each group should, internally, distribute the workload in an equitable manner. If you have difficulties with the internal operation of your group, then first try to resolve them within your group, and if that fails, contact the lecturer.
Extending the framework
Tasks relating to the framework that may attract bonus marks:
- system for generating a network topology and instantiating it with nodes (like tcl scripts in ns2), rather than current static assignment of port numbers to files for particular switches. Extra bonus: do so in a distributed fashion - i.e. rather than running switch emulators on one PC, run each emulator on a different PC.
- Write test generators that exercise component features, e.g. cause blocking in a Banyan fabric, cause trie classifier to require many steps
- Control processor component that can configure other components (e.g. choose type for that component and set parameters). This would involve standardising formats for configuring components (e.g. how to add/remove info from the classifier)
- interface with ns2 simulator
- interface with live network interfaces
Submitting your project
One student per group should email a .zip file containing project files and a report of up to 2 A4 pages of 12 point text to the lecturer. The report should document how your software works, both in terms of providing a user guide and describing the main functions and data structures that it contains. It should also present results of your testing of your module. The 2 pages of text can be supplemented with any number of pages of figures and references, but they must be on separate pages to enable the amount of text to be measured.