CAN201 Introduction to Networking

Networking Project

Contribution to Overall Marks	40%
Submission Deadline of Part I	15th Nov. 2024, 23:59
Submission Deadline of Part II	13th Dec. 2024, 23:59
Type	Team coursework
Learning Outcome	[A] [B] [C] [D]

How the work should be submitted?

●    SOFT COPY ONLY!

●    Every team leader must submit the work through Learning Mall.

Specification of Part II (20% of overall marks)

This part of the networking project aims to use Mininet to create a simple SDN network topology and emulate a traffic control function through using the SDN flow entry. Assuming that the client side only knows the service running on server 1 and communicates with server 1 (without knowing the existence of the service on server 2). However, the SDN controller can manipulate (forward/redirect) the traffic without the awareness of the client. The detailed project tasks are specified as follows. For Part II, the client side program and server side program will be given.

Figure 1. A simple SDN network topology

Use Mininet Python library to create a Python file to build a simple SDN network topology as Fig. 1 shows. Note that Client uses IP address 10.0.1.5/24, Server1 uses IP address 10.0.1.2/24, and Server2 uses 10.0.1.3/24. Also, Client, Server1 and Server2 need to use the MAC address as Fig. 1 presents.

Task 2

Program and run an SDN controller application using Ryu framework (see Task 4.1 and Task 5.1) and make sure every node (i.e., Client, Server1 and Server2) are reachable with each other. In other words, they can ‘ping ’ with each other. Notice that any flow entry (excluding the table-miss flow entry) should set an idle timeout of 5 seconds.

Task 3

Apply the given socket client program (client.py) and the given socket server program (server.py) to this SDN network topology. Specifically, run server.py on both Server1 and Server2, and run client.py on Client. With that, use the socket client side on Client to send traffic to the socket server side on Server1. Notice that wait 5 seconds after ping (the idle timeout mentioned in Task 2) and then start run the client.py, which is to make sure that the flow entry caused by ICMP ping packets has been removed.

Task 4

4.1. Program an SDN controller application that is able to create a flow entry after receiving the first  (TCP SYN segment  caused)  Packet_In SDN packet (from the  SDN  switch to the  SDN controller), then install the flow entry to the SDN switch, and then send out the Packet_Out SDN packet that contains the TCP SYN segment, whereby all the following traffic sent from Client to Server1 is forwarded to Server1.

4.2. With task 4.1, use Wireshark/Tcpdump on Client to capture the packets and then calculate the networking latency (from the first SYN segment till the last ACK segment indicating the TCP 3- way handshake is done).

Task 5

5.1. Program an SDN controller application that is able to create a flow entry after receiving the first  (TCP SYN segment  caused) Packet_In  SDN packet  (from the  SDN  switch to the  SDN controller), then install the flow entry to the SDN switch, and then send out the Packet_Out SDN packet that contains the TCP SYN segment, whereby all the following traffic sent from Client to Server1 is redirected to Server2.

5.2. With task 5.1, use Wireshark/Tcpdump on Client to capture the packets and then calculate the networking latency (from the first SYN segment till the last ACK segment indicating the TCP 3- way handshake is done).

Submission:

Codes:

●    >= Python 3.6;

●    The whole implementation includes multiple Python scripts as follows:

1)  Network topology Python file (which is used to create the SDN network topology for completing Task 1). Please name it “networkTopo.py” .

2)  The Ryu SDN controller Python program (for performing Task 2 and Task 4.1). Please name it “ryu_forward.py” .

3)  The Ryu SDN controller Python program (for performing Task 2 and Task 5.1). Please name it “ryu_redirect.py” .

Project Report:

●    A cover page with your full names (pinyin for Chinese student; name on your passport for international student) and student IDs of the whole team;

●    4 ~  6 pages (including everything  such as the reference while excluding the cover page), double columns, using the IEEE conference template provided;

●    PDF format, LaTeX is recommended, IEEE conference template:

https://www.overleaf.com/latex/templates/ieee-conference-template/grfzhhncsfqn;

●    Including:

-       Abstract

-       Introduction: project task specification (introduce some background about SDN and describe the task of this project, do not copy from this document and use your own words), challenge (identify the research/development problems you are going to address), practice relevance (come up with the potential applications with your proposal, e.g., load balance, secure traffic control, etc.), contributions (key points that you did for this coursework).

-       Related Work: research papers, technical reports, or similar applications that solve or facilitate network traffic redirection.

-       Design: the design of you solution, which should include the network system design diagram (and you need to describe it using your own words) based on Fig. 1, the workflow of your solution (in particular, the steps of creating the flow entry, installing the flow entry, etc.), the algorithm (i.e., the kernel pseudo codes of the network traffic redirection function) for the SDN controller.

-       Implementation: the host environment where you develop the implementation, such as the host CPU, Memory, Operating System, etc. Also, the development softwares or tools, like the IDE, the  Python  libraries,  the  SDN  controller   software  (i.e.,  Ryu  here),  etc.   Further,   steps  of implementation (e.g., program flow charts), programming skills (OOP, Parallel, etc.) you used, and the actual implementation of the traffic redirection function. In addition, the difficulties you met and how did you solve them.

-       Testing  and  Results:  testing  environment  (can  be  more  or  less  the  same  with  your  host implementation environment), testing steps (the steps of using the developed Python programs to complete the project tasks  1-4, including snapshots),  and testing results, i.e., the networking latency comparison between the forwarding case (Task 4.2) and the redirection case (Task 5.2), and you should apply figures of bars or curves for showing average performance.

-       Conclusion: what you did for this project and any future work for improvement.

-       Acknowledgement: individual contribution percentage should be clarified here if the project is

a  teamwork  by  using  this  format:  Student1’s  name  (ID)  contributes  XX%  to  the  project,

Student2’s name (ID) contributes XX% to the project, and Student3’s name (ID) contributes XX% to the project, etc. If there is no clarification of individual contribution, it is considered that all

the individual team contributes the same percentage to the project.

-       Reference [IEEE format]

Meanwhile, you have to follow the compulsory requirement (no tolerance):

●    Only ZIP file is allowed to submit;

●    The   ZIP  file   should  be  named  as:  CAN201-CW-Part-II-Student1name-Student2name- Student3name-Student4name-Student5name

●    The ZIP file includes two folders, i.e., “Codes” and “Report” . The Codes folder includes all the Python files, and the Report folder includes the report file;

●    Python files are: networkTopo.py, ryu_forward.py, ryu_redirect.py;

●    The report file should be named as: Report_Part_II.pdf;

Allowed Python modules:

os, sys, shutil, socket, struct, hashlib, math, tqdm, numpy, threading, multiprocessing, gzip, zlib, zipfile, time, mininet, ryu.

Marking Criteria

The following marking scheme is for the team, and every team member shall contribute to the project. Also, several specific rules should be followed:

1.   Every team should use the “ACKNOWLEDGMENT” section of the IEEE template to describe the individual contribution(s) using the following format: Student1’s name (ID) contributes XX% to the project, Student2’s name (ID) contributes XX% to the project, and Student3’s name (ID) contributes XX% to the project, etc.

2.   If there is no clarification about the individual contributions, it is considered that every team member in the same team has the same contribution percentage and will have the same mark of the CW project.

3.   The individual contribution must be in a range: for a 5-person team, it must be 10% - 30% (15% and 30% are included); for a 4-person team, it must be 15% - 35% (15% and 35% are included). If any individual  contribution  percentage  of a  team  is  out  of the  range  (e.g.,  a  5-person  team  has  the contributions like: 60%, 10%, 10%, 10%, 10%), the team may go through a review by the module leader about the contribution discrepancy.

4.   The algorithm for calculating individual mark as follows:

a.   Assuming the 5-person team’s mark is m, student1 contributes x%, student2 contributes y% and student3 contributes z%, student4 contributes u%, student5 contributes v%.

b.   The student who gets the most contribution will get mark m.

c.    Student 1’s mark will bex/max(x,y,z,u,v)*m. d.   Student 2’s mark will bey/max(x,y,z,u,v)*m. e.    Student 3’s mark will be z/max(x,y,z,u,v)*m. f.    Student 4’s mark will be u/max(x,y,z,u,v)*m. g.   Student 5’s mark will bev/max(x,y,z,u,v)*m.

Report (50%)

Marking Criteria	Item	Mark
Contents (40%)	Abstract	3%
	Introduction	5%
	Related Work	4%
	Design	8%
	Implementation	7%
	Testing and Results	7%
	Conclusion	3%
	Reference	3%
Typography (5%)	Report structure, style, and format	5%
Writing (5%)	Language	5%

Marking Scheme:

1.    Contents (40%)

1.1. Abstract (3%)

-    Good (3%)

-    Appropriate (1-2%)

-    No abstract (0%) 

1.2. Introduction (5%)

-    Excellent (5%)

-    Lack of necessary parts (1%-4%)

-    No introduction (0%) 1.3. Related Work (4%)

-    Sufficient (4%)

-    Not enough (1%-3%)

-    No introduction (0%) 1.4. Design (8%)

-    Excellent: adequate and accurate figures and text description (8%)

-    Reasonable: clear figures and text description (4%-7%)

-    Incomplete: unclear figures and text description (1%-3%)

-    No design (0%)

1.5. Implementation (7%)

-    Excellent: sufficient details of implementation (7%)

-    Reasonable: clear description of implementation (4%-6%)

-    Incomplete: unclear description of implementation (1%-3%)

-    No implementation (0%) 1.6. Testing and Results (7%)

-    Excellent: sufficient testing description, correct experimental results using figures with clear text description and analysis (7%)

-    Acceptable:   clear   testing  description,  appropriate  experimental  results  using  figures  with acceptable text description and analysis (3%-6%)

-    Incomplete: lack of testing description, experimental results with figures, or text description and analysis (1%-2%)

-    No testing and results (0%) 1.7. Conclusion (3%)

-    Excellent conclusion (3%)

-    Acceptable conclusion (1%-2%)

-    No conclusion (0%) 1.8. Reference (3%)

-    Excellent reference with the correct IEEE format (3%)

-    Incorrect or inconsistent reference format (1%-2%)

-    No reference (0%)

2.    Typography (5%)

-    Beautiful and clear typography: 5%

-    Acceptable typography: 2%-4%

-    Bad typography: 0% ~ 1%

3.    Writing (5%)

-    Accurate and concise language: 3%-5%

-    Unclear and confusing language: 1% ~ 2%

Codes (50%)

Program testing steps:

1．Forwarding case:

1.1 Run the networkTopo.py to create the SDN network topology. Check Client, Server1, and Server2 use the correct IP addresses and MAC addresses.

1.2. Run ryu_forward.py on Controller, and use  Client to ping  Server1’s IP address  and Server2’s IP address.

1.3. Run server.py on both Server1 and Server2, and also run client.py on Client after the previous ICMP ping incurred flow entry’s idle timeout (i.e., 5 seconds).

a.   Show the flow table on Switch.

b.   Show Server1 receives the traffic sent from Client.

2．Redirection case:

2.1 Run the networkTopo.py to create the SDN network topology. Check Client, Server1, and Server2 use the correct IP addresses MAC addresses.

2.2. Run ryu_redirect.py on Controller,  and use  Client  to ping  Server1’s  IP address  and Server2’s IP address.

2.3. Run server.py on both Server1 and Server2, and also run client.py on Client after the previous ICMP ping incurred flow entry’s idle timeout (i.e., 5 seconds).

c.   Show the flow table on Switch.

d.   Show Server2 receives the traffic sent from Client.

Marking scheme:

1.   Step 1.1 and 2.1 (10%)

-    Complete topology with correct IP addresses: 10%

-       Incomplete topology or incorrect IP addresses: 3%-9% (3 MAC and 3 IP addresses, 1 for hostnames)

-    No networkTopo.py or not executable networkTopo.py: 0%-2%

Note: if no networkTopo.py or the networkTopo.py is not executable, the marking stops here.

2.   Step 1.2 (5%)

-    The program ryu_forward.py can work and Client can ping Server1 and Server2: 5%

-    If ryu_forward.py can work but Client cannot ping Server1 or Server2: 3%-4%

-    If no ryu_forward.py or ryu_forward.py is not executable: 0%-1%

Note: if no ryu_forward.py or ryu_forward.py is not executable, no marking for Step 1.3.

3.   Step 1.3 (10%)

-    The flow entry can be shown correctly and Server1 can receive traffic: 10%

-    The flow entry cannot be shown correctly or Server1 cannot receive traffic: 5%

-    Neither the above: 0%

4.   Step 2.2 (10%)

-    The program ryu_redirect.py can work and Client can ping Server1 and Server2: 10%

-    If ryu_redirect.py can work but Client cannot ping Server1 or Server2: 6%-8%

-    If no ryu_redirect.py or ryu_redirect.py is not executable: 0%-3%

Note: if no ryu_redirect.py or ryu_redirect.py is not executable, no marking for Step 2.3.

5.   Step 2.3 (15%)

-    The flow entry can be shown correctly and Server2 can receive traffic: 15%

-    The flow entry cannot be shown correctly or Server2 cannot receive traffic: 7%

-    Neither the above: 0%