140 likes | 375 Views
Simulation of the OLSRv2 Protocol. First Report Presentation. Agenda. Project Description Problem Solution Routing Protocols OSPF Protocol OLSRv2 Protocol Simulation Overview Simulation Parameters Output Analysis Expected Results Main Modules GUI Screenshot Schedule.
E N D
Simulation of the OLSRv2 Protocol First Report Presentation
Agenda • Project Description • Problem • Solution • Routing Protocols • OSPF Protocol • OLSRv2 Protocol • Simulation Overview • Simulation Parameters • Output Analysis • Expected Results • Main Modules • GUI Screenshot • Schedule
Project Description Problem • Wireless networks are growing in size • Limited bandwidth • High rate of topological changes • Inconsistency of information in different parts of the network
Project Description Solution • Minimize the overhead of network control traffic • Avoid flooding messages excessively in the network • That’s what OLSRv2 is trying to achieve!
Routing Protocols • A routing protocol is a protocol that specifies how routers communicate with each other. • The choice of the route being done by routing algorithms based on the type of routing protocols • One type of routing protocols is Link-State . • In Link-State protocols, Every node constructs a map of the connectivity to the network in a distributed manner, in the form of a graph, showing which nodes are connected to which other nodes, in other words, every node keeps a database of all state-links. • Proactive routing approach • Based on periodic exchange of control messages • Some are sent locally to enable a node to know its local neighborhood • And some are sent in the entire network. • Permits to exchange the knowledge of topology among all the nodes of the network. • Immediately provides the required routes when needed. • Cons: high cost of bandwidth – when sending frequent periodic updates of topology.
OSPF Protocol Routing Protocols OSPF • "Hello" packets sent periodically on all OSPF-enabled interfaces • become "neighbors" • establishes that link can carry data • used to determine if neighbor is up • Topology information is packaged in a "link state announcement “ (LSA) (analog to TC in OLSR) • Each router receives LSAs, adds them into its database, and passes the information along to its neighbors • Each router builds identical link-state database • Runs SPF algorithm on the database to build SPF tree • Routing table built from SPF tree
OLSRv2 Protocol Routing Protocols OLSRv2 • Distributed • Proactive(Table Driven) • Periodic exchange of messages to maintain topology information using “Hello” messages (inherited from NHDP) and “TC” (Topology Control) messages. • Compacts the size of information sent in the messages compared to other MANET protocols. • Reduces the number of retransmissions of messages in the network (using MPRs)
Simulation Overview • Event Driven • User determines the simulation configurations (next slide) and parameters using the GUI • Events are generated according to those parameters and configurations by the EVENT GENERATOR module • The output of the simulation will be presented on the GUI which will show the status of each node whether it has a full map of the network (stable) or not. Other data outputs will be presented straight on the interface of the user. • Graphs are produced using the output of the simulation • Total intersected time where all nodes are stable. • Total Control Messages sent in OLSRv2 (TC). • Total Control Messages sent in OSPF (LSA's).
Simulation Parameters The parameters that the user chooses include the following: • Routing Protocol: two protocols are available in this simulation OLSRv2 and OSPF • Number of Nodes: the user enters the number of nodes in the Network that we simulate. • Hearing Range: the user enters one value (in meters) for the Hearing Range of Network’s Routers. • Rate of movement: the user enters one value (in meter per second) for the Velocity of the Network’s Routers. • Simulation Time: the user enters the Simulation Time in seconds.
Output Analysis • We will determine at which configuration we'll gain extreme values, hence we'll determine at which configurations the protocol is beneficial and also when should we avoid using it. • Since we are comparing it to OSPF we can determine and see the changes in performance that OLSRv2 will achieve over OSPF.
Expected Results • We are expecting to gain a major improvement in stability and route availability in OLSRv2 when the Movement Rate is Low. • We are expecting to gain a major improvement in throughput and route availability in OLSRv2 over OSPF – because the idea of using MPR resembles a huge optimization of broadcasting overhead.
Schedule • 18.11.2009 – First Report Submission • 15.12.2009 – Coding • 20.12.2009 – Testing • 30.12.2009 – Project Review. • 15.1.2010 – Project Presentation and Final Report Submission