Directions
MCIT Online 553 Project 1
Link State and Distance Vector Routing
You must work in groups of 4 for this project. Please regularly check Ed Discussion through out this course for project specification clarifications. You are required to version control your code, but please only use the GitHub repository created for you by the 553 staff. Do not work in public GitHub reposito- ries! Please avoid publishing this project at any time, even post-submission, to observe course integrity policies. If you are caught using code from other groups or any sources from public code reposito- ries, your entire group will receive ZERO for this assignment, and will be sent to the Office of Student Conduct where there will be additional sanctions imposed by the university.
Copyright By PowCoder代写 加微信 powcoder
In this assignment, you will implement two routing protocols: link state and distance vector routing. Your ns-3 implementation should be able to read network topology files and calculate routing table based on the LS and the DV algorithms. There will be commands to bring up/down a node or a link, your code should handle the update and reflect on the output in a timely manner. We also provide an auto-grader and test files to validate your implementation.
1 Specification
We will be using the ns-3 discrete network simulator to teach core principles of network routing protocol design and implementation. Your assignment is to extend ns-3 to support efficient routing using link- state and distance-vector protocols.
An important goal of this project is to provide you the opportunity to read and understand a sizable piece of software and extend it. Hence, we have deliberately not included all the details about the ns-3 code, particularly on specific APIs.
Please be aware that no amount of documentation can replace actual reading and running of the code itself. So rather than spend hours digesting this document without looking at the code, make sure you treat this document as a reference guide while you run the simulator and step through the control flow of various interacting software modules. To get into the habit of working as a team, we encourage you to spend a day or two to get your entire group together to try to understand the code as a team, and help each other out.
2 Project Specifications 2.1 Milestone 1 (12%)
In this milestone 1, you will work in teams to develop basic neighbor discovery capabilities to each node. The goals of this first milestone are to become familiar with the ns-3 development environment
and understand the TA’s skeleton code. Before you write any code, make sure you read in detail the code documentation, understand the API and structure of the relevant parts of the ns-3 code.
All your code should go inside the upenn cis553 directory and you should not modify other files in the ns-3 directory. You are free to add new packet types to ls-message.cc and dv-message.cc. Feel free to structure your own code, for instance, introduce your own helper files, or have one neighbor discovery module shared by both LS and DV.
You will finish the following tasks: 1. Neighbor Discovery.
2. Output neighbor table.
Expected Output. Once you finished the above tasks, you should be able to generate the Neighbor List by calling ”DUMP NEIGHBORS” command. The first row of Neighbor List is the total number of the neighbors for that node. Then followed by a series of neighbor entries. Each neighbor entry should include
For example, output of command ”1 LS DUMP NEIGHBORS” for 10-ls.sce and 10.topo should be
**************** Neighbor List ******************** NeighborNumber NeighborAddr InterfaceAddr
0 10.0.0.1 10.0.0.2
8 10.0.6.2 10.0.6.1
Submission for milestone 1. Generate a tar file project1.tar.gz containing all your source code and upload onto Gradescope. Only one person in the team needs to submit. Be sure to include all other team members in the Gradescope submission (look for the add teammates feature in the top right corner).
2.2 Milestone 2 (88%)
Your assignment is to extend your node to support efficient routing by implementing two protocols: link-state and distance-vector routing. If your implementation works, you will be able to route packets hop-by-hop through the network, having packets propagate through a path, only involving nodes on the route to the destination.
2.2.1 Link-state routing
Your node must implement link-state routing to construct a routing table, and use this routing table to forward packets towards their destination. You should read about link-state routing in the Peterson textbook and in our lecture slides. The link-state protocol generally involves four steps (See more details in the code guidelines):
1. Neighbor discovery. (Built in MS1) 2. Link-state flooding.
3. Shortest-path calculation.
4. Forwarding.
2.2.2 Distance-vector routing
The second routing protocol you have to implement is the distance-vector routing protocol, described in our lecture notes and in the Peterson’s textbook. Your solution should address the count-to-infinity problem by bounding the distance to a maximum of 16 hops. Note that we are not implementing the entire RIP protocol, but a simple distance vector routing protocol that consists of the following four steps (more details in the code guidelines):
1. Neighbor discovery. (Built in MS1) 2. Distance-vector exchange.
3. Route calculation.
4. Forwarding.
Expected Output: Your output should be able to pass the auto-grader test. For example, when you test for 10 nodes topology with the command:
If you passed, you will get this message for each of the tests.
XXX is correct
Submission for milestone 2: Submit a tar file project1.tar.gz and upload onto Gradescope separately for LS and DV for small and large topologies. We strongly recommend you ensure that your implementation passes the local autograder first before submitting to Gradescope. As before, make sure you include all your teammates.
3 Extra Credits (submit together with milestone 2)
Doing extra credit is entirely optional. We offer extra-credit problems as a way of providing challenges for those students with both the time and interest to pursue certain issues in more depth. You should only attempt the extra credits after you have completed the regular portions of the project. Do note that if your regular credit LS and DV do not work correctly, we reserve the right not to award extra credit points. Hence, we recommend that you only start working on extra credits after you have finished the regular credits.
Submit your extra credits together with the same deadline as milestone 2. We will provide a separate submission folder on Gradescope for this submission. You can add your own custom command line arguments to showcase a given extra credit feature. You are free to make any changes to any part of the ns-3 code-based for extra credits.
There is no autograder for extra credit. You will need to schedule a meeting with a TA to demonstrate your extra credits. After the deadline, TAs will reach out to schedule a meeting with your group.
Here are some example extra credits that you can implement. For extra credit, you are responsible for providing your own test cases:
• Path vector protocol (5%) Similar to distance vector protocol, except that complete paths are advertised. To avoid the count-to-infinity problem, cycles must be explicitly checked.
• Hazy sighted link state (HSLS) (15%) HSLS is another variant of Link state routing for mobile ad-hoc networks. You can search online to read up more on this protocol. To get the full 15%
$ ./build/scratch/simulator-main -routing=LS -scenario=scratch/scenarios/10-ls.sce -inet- topo=scratch/topologies/10.topo -result-check=scratch/results/10-ls.output
credit, you have to demonstrate a working implementation running an actual mobile ad-hoc net- work (i.e. replace our current pt-to-pt network with an ns-3 MANET setup). For another 10% credit, you can demonstrate a working implementation of another MANET routing protocol not currently available in ns-3 (talk to instructors to get your protocol approved).
• Delaytolerantnetworking(15%)Implementsummary-basedepidemicroutingprotocol.Demon- strate actual implement in a highly disconnected wireless network where nodes are connected to each other infrequently. Like HSLS, you will need to read up outside of course material on this protocol.
• Metric-basedlink-stateordistancevectorprotocol(5%)Insteadofcomputingroutesbasedon fewest hop count, allow routes to be selected based on link metrics (e.g. lower loss rates, lower latency, higher bandwidth are all reasonable choices). Your design can and should make use of the facilities defined above (link state advertisements). Link metrics should be syntactically generated and imported into our simulator. You can get full credit either with an link-state or distance vector protocol implementation.
• IncrementalDijkstracomputation(10%)Givenarouteupdate,insteadofrecomputingDijkstra from scratch for all entries, perform incremental recomputation that only updates routes relevant to the shortest path. To demonstrate working implementation, you need to demonstrate that your simulation can run significantly faster for the same network size (while computing the correct routes of course!).
• Measurements (10%) Use ns-3’s built-in measurement facilities to generate PCAP traces. Based on the traces, plot the following graphs for LS and DV:
– Per-nodebandwidthutilization(forjustcontrolplanemessages)vsnumberofnodes(5,10,20,25,30). – Convergence vs number of nodes (5,10,20,25,30).
• Your proposal (X%) If you have a cool extension in mind, feel free to contact the teaching staff to discuss feasibility and points awarded.
程序代写 CS代考 加微信: powcoder QQ: 1823890830 Email: powcoder@163.com