At the core of every link-state protocol is a distributed, replicated database. The database describes the routing topology -- the collection of routers in the routing domain and how they are interconnected. Each router in the routing domain is responsible for describing its local routing topology (e.g., status of its direct links, the cost associated with each link ...) to all other routers. The local routing topology information is reliably distributed to all other routers in Link State Advertisements (LSAs). Taken together, the collection of LSAs generated by all the routers form the Link State Database (LSD). Using the information contained in the database, each router builds a map of the current network topology. Armed with this map, each router uses a shortest path routing algorithm, typically Dijkstra's Shortest Path First, to calculate its routing table, thereby enabling forwarding of network traffic between end systems. The purpose of the project is to design and implement a simpleLink-State Routing Protocol (sLSRP). The protocol has the following main components:
In the following sections, the main messages and basic functionality of sLSRP are describe.
In order to accommodate sLSRP functionalities, the protocol defines three types of messages, namely “Neighbor Acquisition” messages, “Alive” messages, “Link Cost” messages, and “LSA” messages. The general format of sLSRP message is depicted in Figure 1.
2.1 Neighbor Acquisition Messages
The neighbor acquisition messages are used by two adjacent routers to establish “neighborhood” relationship for routing information exchange. This class of messages include “Be_Neighbors_Request”, “Be_Neighbors_Confirm”, “Be_Neighbors_Refuse”, “Cease_Neighbors_Request”, and “Cease_Neighbors_Confirm”.
The Be_Neighbors_Request message is used by one router to invite another router to become neighbors. In addition to the standard fields, the message contains initial values for the Hello_Interval, the Update_Interval, Router_ID, and any other parameter you see fit in the initialization process. The value of the Hello_Interval determines the amount of time a router waits before it tests if the neighbor is still alive. The Update_Interval determines the maximum frequency of the local link state updates. Additional parameters may include maximum packet length, if required, cost metrics, encryption keys, etc.
Upon receiving a Be_Neighbors_Request message, the invited router can either accept the invitation, in which case it replies by sending a Be_Neighbors_Confirm message, or reject the invitation by issuing a Be_Neighbors_Refuse message. The choice of accepting or rejecting a neighborhood request is made by the system administrator, and included in a policy management file. The router accepts or refuses neighborhood requests based on the content of the policy management file. The neighborhood decision is initially made during the router configuration phase, but can be modified any time thereafter. A router may also refuse an invitation to become a neighbor if it does not run the same version of the LSRP protocol as the requesting router’s version. In case of acceptance, the values of the initial parameters that govern the communication and LSA packet exchange between the routers are negotiated during this phase to accommodate the profile and capability of each router.
2.2 Alive Messages
The “Alive” messages are sent periodically by one router to test whether the neighbor is still alive. The period is determined by the value of the Hello_Interval parameter, agreed upon during negotiation.
2.3 Link Cost Messages
In order to estimate the link cost, the router uses a routine, typically implemented as a thread, to periodically measure the round-trip time to send a packet and receive an acknowledgement over a link to an adjacent router. The measurements over an Update_Interval are averaged out and mapped into relative cost, between 1 and Max_Cost, where high cost means heavily congested link and low cost means lightly congested link. How refined is the characterization of the link congestion is implementation dependent. The cost of links are then flooded to all routers in the networks, using a LSA message.
2.4 Link State Advertisement Messages
Each LSRP router originates one or more LSAs to describe its local part of the routing topology domain. The format of an LSA is depicted in Figure 2.
Link state databases are exchanged between neighboring routers soon after the routers have discovered each other. After initial discovery, the link state database remains synchronized through a procedure called reliable flooding. The flooding procedure starts when a router wishes to update its self-originated LSA. This may be because it is time to refresh an LSA, based on Update_Interval, or because the router’s local state has changed. Changes may occur when one of the interfaces may have become nonoperational or one of the failed interfaces has become operational.
When a neighbor receives an LSA, the neighbor examines the LSA to verify that is not corrupted, checks that the LSA is more recent that the neighbor’s own database copy and installs the new LSA in its link state database. The neighbor then sends an acknowledgment to the sender and repackages the LSA within a new packet and sends out all interfaces, except the one that received the LSA in the first place. In order to achieve reliability, a sending router will periodically retransmit the LSA sent to a neighbor until the neighbor acknowledges the receipt of the LSA.
As a minimum requirement, sLSRP must:
The first milestone of the project deals with the design of the protocol architecture. Prior to implementing the system, you must submit an initial Design Report. The report should include the following:
The proposed design and architecture report will be evaluated and either approved or recommended for modifications. It is only after approval that the team can start the second phase of the project.
The second milestone of the project is concerned with the implementation of the approved protocol design and architecture. You need to implement all the features and operations of the protocol for full credit. In addition to making the implementation source code, header files and parameter files available in a directory accessible to the instructor and the TAs, you need to submit:
You will be required to schedule a session at the end of the term to demonstrate the functionalities of your protocol
Assignment Writing Help
Engineering Assignment Services
Do My Assignment Help
Write My Essay Services