Assessed Exercise: 2023-24

Date issued   20/02/24

Final submission deadline   11/03/2024

This is the main exercise for the ANS(H) module; it is worth 20% of the assessment for the course (the remaining 80% is for the Spring examination).

Description

You are asked to demonstrate and measure the effects of congestion occurring in the below networked topology using Mininet. Having multiple paths leading to the same destination offers redundancy and the possibility of exploring load balancing capabilities. However, a generic controller will not use such features if simply following the default flow rule installation. You need to modify the controller to achieve load-balancing through using all the available paths between s1 and s6.



The links should be configured with a maximum bandwidth of 10Mbps, a 2ms latency, and a queue size of 8. The above values will help demonstrate what would happen in links with limited capacity, as expected in a real network. The host IP and MAC addresses should be allocated according to their id with the prefix being 10.0.0.X and 00:00:00:00:00:0X, respectively, where X reflects the host id number (e.g., for host h5: 10.0.0.5, 00:00:00:00:00:05). The controller will be implemented using Ryu and OpenFlow1.3 to install/modify rules to the switches. You should use NetworkX to calculate paths and other routing decisions.

During the first stage of this assessment, you need to deploy the above topology and install the corresponding flow rules using the material from lab 5. Generate TCP and UDP traffic, initially with varying rates from one host, and then by simultaneously using more than one host. Multiplexing different types of traffic is not required. You can obtain the measurements either through using standard tools (e.g., iperf3, tc, tcpdump) or Ryu’s API. Report your findings on traffic patterns, losses, buffer overflows, and other statistics you think are important/interesting. The number of hosts and links that are tested does not need to be extensive, just enough to demonstrate congestion.

Once you have identified certain shortcomings stemming from the controller in-use, you need to re-write parts of the controller (or start from scratch, if you prefer) in order to mitigate the issues that impact performance. This is the second stage of the assessment. More specifically, you should use built-in load-balancing features that are enabled using specific OpenFlow tables and actions. Consult the documentation of Ryu API, the OpenFlow Specification, OvS, and NetworkX, as well as any official documentation publicly available from these sources.

You will need to write a brief report (2000 words max) which will include your findings, reasoning, how your code works, and the achieved results.

Hint

You should start from small-scale experiments before deploying your controller in the above topology. Installing CLI rules in the beginning can help you identify what is/isn’t working and will help you develop the controller with fewer launches of the entire setup and topology which can take time. When your controller is configured to enable load balancing, some measurements might not be impacted as much as you might have expected. You should provide an explanation of why this happens in the report.

Assessment

Implementation (70%):

Marks will be awarded based on the variety of the tools you have used to test and measure different aspects of congestion (losses, overflows, etc). Your load-balancing controller will be marked based on whether it achieves load-balancing, how quickly it calculates the rules and installs them, and how it can handle network changes and different topologies. Marks will also be awarded for professionally written code with comments, etc.

Report (30%): Marks will be awarded for coherent reports that address the main points of the relevant sections outlined above. Specifically, the issues that have been identified for the first/default controller configuration and the rationale behind your experiments. Explanations of how each tool was used to achieve the outcome are also expected. You should include measurements of the controller you developed and reflections on behaviour and performance. Report any omissions and incomplete implementations.

What to submit

Coursework will be submitted electronically via Moodle no later than 16.30 on Monday, 11th March 2024 Submission links will be provided on Moodle ANS page for the following items:

• Softcopy version of your system – all of the source code for your system (Python files, launch scripts, etc.) should be produced as a single .zip file, called <GUID>.zip. The archive should also contain a text file describing how your system should be tested starting from executing the source code included in the submitted .zip file, etc.

請(qǐng)加QQ：99515681  郵箱：99515681@qq.com   WX：codehelp