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 z1234567@unsw.edu.au where z1234567 is a student ID.

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:

Components

Type Sample Group allocation Others that you could implement
Classifier Tree 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
Fabric Banyan 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)
Scheduler Round Robin 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
Generator   Take real packet traces in pcap format and play out in simulation
Analyser   measure jitter

Preliminary marking criteria

(in order of increasing cumulative difficulty = marks):
  1. (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...
  2. (50-60%) The component works, e.g. fits into the framework and implements the component.
  3. (to 70%) The component is easy to understand in terms of documentation of parameters and how the software is written.
  4. (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
  5. (90%) The component is general/scalable, e.g. can handle varying numbers of ports (unlike the sample Banyan fabric)
  6. (95%) The component is robust, e.g. properly handles mal-formed inputs, e.g. letters in configuration file where numbers are expected
  7. (100%) Unexpected magic
("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.)

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:

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.