Download Link State Routing Algorithm-Data Communication Network-Lab Mannual and more Exercises Data Communication Systems and Computer Networks in PDF only on Docsity!
Link State Routing Algorithm
Please read the complete problem statement and strictly comply with the requirements.
Objectives
In this project you are required to implement the Link State Routing Algorithm (LSR Algorithm). LS Algorithm is a dynamic and distributed routing algorithm implemented by routers to find the optimal routes to all other routers (and consequently to all the destinations) in a network. These routes are then used for transferring packets from a source to destination.
You are required to use the OMNET++ environment to implement LSR algorithm in the project. You will design and implement a router node that, when started in conjunction with a topology of other nodes (using OMNET++), will discover network topology and then apply LSR to create routing tables at each node.
Specification
This project requires you to create a node process that implements Link State algorithm which needs to adapt to changing network conditions. In addition, the node process needs to store its changing routing tables in a log file once the change is triggered in order to track the router’s ability as the networks condition change.
(Please read the relevant sections of the textbook to understand the working of the algorithm. We also recommend reading relevant sections from Pattersons and Davie’s and Tanenbaum’s books)
Through LS algorithm the packet are switched on the optimal path (least-cost path) from source to the destination. To each link there is a cost attached. Since in a real-world scenario the packet switches have to “discover” their neighbors and cost of the associated links leading to them so at startup each node would send the HELLO packets to its neighbors. The RTT should give you a hint how to calculate the cost attached to the link (You have already studied how to calculate cost attached to a link).
Once the neighbors have been discovered the packet-switches have to create the LS Packets and then flood them to disseminate the local information. When each router has the global knowledge of connections then the LS algorithm works to find the least-cost path. From then on the actual packets are sent through this optimal route. You should also cater for the changing network conditions: e.g. what if a link breaks, how would a router come to know of it? What if a new router comes up reporting new links?
HELLO Packets:
At the start each router has to “meet” its neighbors, discover their names and costs to reach them. For this purpose each router sends out HELLO packets to each of its neighbor. Each neighbor has the responsibility to send these packets back immediately. Now the sending node can calculate the cost to the neighbor (RTT?). There are interesting issues and we encourage you to discuss them with your group fellows and come up with a solutions to them; like should a router rely on information gathered only through one HELLO Packet OR should send few packets and then use the average of the cost gathered through them? Accuracy vs. Less Network Load?
LS: (This part is the heart of the algorithm so design it carefully)
The link state algorithm MUST BE implemented as described in the lectures and the course reader. If you read through the recommended readings, you will find out that adding sequence numbers to the LSPs ensure that duplicate/old LSPs can be identified. (sequence numbers would wrap around, so how large they should be?)
Which protocol you would use to flood your LSPs; send an LSP to the neighbor that it should reply OR wait for its LSP. In the first approach how would you discover that the neighbor/link has failed. You might need to add add few fields in case you take latter approach e.g age. Design your LSPs and data structures to hold them, considering these issues. Also, as discussed in class, the size of the LSPs should be justifiable. Another issue is should the LSPs be acknowledged or not?
At the start, all the nodes should build initial LSPs and flood them to the neighbors. Regarding subsequent LSPs, there are issues whether LSPs should be sent periodically (how frequently?) or only when there is change in link cost, neighbor goes down, new neighbor comes up. Would you like you use a mixture of both because you might have to care for decrementing age on the other “side”. Make sure that the SEND_PERIOD could be set through omnetpp.ini file.
Measurements:
Of course after doing so much work you would be really excited to see the packets being transferred from source to destination. So you have to attach the few source and destination (traffic generators? Recall your lab) that would transmit packets and this would show whether the routers have actually learned the optimal routes. In this part you would also take measurements of the performance i.e. THROUGHPUT vs. OFFERED_LOAD and DELAY vs. PERFORMANCE.
Testing and Grading
You are responsible for testing your code to ensure that it complies with the specifications given in this document. Thoroughly test your program’s functionality before handing it in. Do not assume you will get partial credit for a partially functioning application.
In order to grade the MPs, you will be required to have each node print out its routing table after every change. There will be no test cases or automated testing facilities. Instead, the responsibility lies on you to make sure, in the face of changing network environments, your algorithms perform correctly.
Hand In
You have to submit the source code (.cpp, .h) files for all the classes that you implement. In addition to that you have to submit the topology files that you have tested and the omnetpp.ini file. In addition to these do submit your log file. In addition to this you have to submit the Design Document (details of it to be seen below).
Design Document:
This document should specify your design technique and your implementation in detail.
Ambition 2: Make the LS Algorithm Load Sensitive
LS is a load insensitive protocol. You can make it load sensitive so that it can increase the cost of the heavily loaded links. The optimal routes would now adapt to changing network conditions. This would make the LS Algorithm Load Sensitive.
Grading:
Design Document – 20 Points Source Code Implementation – 20 Points Testing and Validation – 20 Points
Bonus 1 – 20 Points Bonus 2 – 20 Points
Deadline: as announced in class, but would be known soon
Deliverables: (till now two deliverables are identified, subsequent deliverables would be
announced soon)
Deliverable 1: Deadline April 26, 2007 (This would be discussed with and marked in your lab sessions on April 27/28)
You should give initial design document:
- identifying your modules
- your complete LS protocol considering all the issues
- structure of the packets (HELLO, LSPs, any other that you might need)
Deliverable 2: May 2, 2007
Implementation of rudimentary routers sending HELLO packets and finding costs. And a design document that should give all the detail that you are in process of implementing your LS algorithm i.e LSPs structures Data structures to hold your LSPs
Resources:
Recall routing example we did in lab. This would give you sufficient ideas how you should start. Start by identifying what simple modules would be there in your network and what algorithms they would be running (of course there are routers and traffic generators). What are different messages they can send? Design messages keeping in mind the design issues.
Acknowledgements:
This document has been written taking ideas from Computer Networks by Andrew S. Tanenbaum and Computer Networking by Kurose and Ross.
