Fisheye Routing protocol TCN 6275 – MOBILE COMPUTING Topic: Fisheye Routing protocol Presenter: Devon Sterling

OVERVIEW – WIRELESS MOBILE COMMUNICATION 2 Distinct approaches to mobile wireless comm. Fixed network infrastructure Eg: Cellular technologies – GSM, UMTS, WIMAX Ethernet – Wireless LAN Satellite No fixed infrastructure Ad-hoc network Both types need routing protocol to route messages thru network

Overview of Routing Protocols Multi-hop network => need for routing/protocol Routing protocol functions to find efficient source- destination route 2 Broad categories: On-demand: Route discovery mechanism create route when needed Table-driven: Each node maintains table(s) of routing info. To every other node in network.

Overview of Routing Protocols 2 main types of table driven protocols: Distance Vector: Entire routing table is sent to neighbors periodically Neighbors compare routing table for shorter routes Link State: Each node maintains a topology DB, essentially a view of the entire network When topology changes only state of specific affected link needs to be sent to update topology Each node creates it’s routing table by running SP algorithm on topology DB to create a SP tree of network with itself as center Link State is better in terms of performance

WHAT IS AD-HOC NETWORKING? No centralized infrastructure Each node is both a router & a host Wireless nodes discover each other (based on Tx range) & forms network Mobility causes changing network topology Nodes join/quit network at any time No centralized network admin Nodes can have limited resources: CPU, storage, power, BW – not unlike sensor networking

DESIRABLE PROPERTIES FOR AN AD-HOC NETWORK ROUTING PROTOCOL Distributed operations: no centralized controlling node Fast convergence: New routes quickly calculated after network changes Optimal routes: Shortest or least-cost routes Loop free: Avoid routing loops leading to degraded performance Low overhead: Minimize message size and frequency Traditional DV & LS protocol –developed for fixed infrastructure networks – falls short

FISHEYE ROUTING PROTOCOL- A PROTOCOL FOR AD-HOC NETWORKS Design: Borrows heavily from LS & lightly from DV routing protocol Employs a novel approach to its view of the network hence info. dissemination Like LS, each node maintain an overall view of the entire network However it only focus on maintaining correct routing info. With a smaller view of the network – hence the ‘ fisheye’ appearance & terminology

DESIGN

DESIGN To accomplish this: Each node maintains accurate info. with neighbors within a configurable distance (x) from itself by exchange frequent updates While maintaining “not so accurate” info with the rest of the network by only sending infrequent updates Updates are also periodic (configurable) instead of event driven

HOW DOES IT WORK? Recall: each node maintains entire view of network However, accurate info is only maintain with close-by neighbors In any route, the next hop will always be a close-by neighbor The message will be 1-hop closer to the destination, and this node will have an accurate view of the network 1-step closer to the destination The process is repeated until the destination is reached

PERFORMANCE OF FISHEYE With each node focusing on maintaining accurate info with only a portion of the network, overhead is significantly reduced. However the size of the fisheye affects the performance of the protocol in terms of accurate routes Periodic updates also further reduce network overhead but also at a cost.

CONCLUSION The design of fisheye routing protocol makes it a good choice for ad-hoc networking Trade-off between protocol performance and network overhead

REFERENCES A.C. Sun, “ Design & implementation of Fisheye Routing Protocol for Mobile Ad Hoc Networks”, 1992 <http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.24.7367> G. Pei, et al., “Fisheye State Routing in Mobile Ad Hoc Networks” <http://nrlweb.cs.ucla.edu/publication/download/203/05_75_fisheye-state-routing-in.pdf> M. Gerla, et al., Fisheye State Routing Protocol (FRS) for Ad Hoc Networks”, IETF MANET Working Group, June 17, 2002 <http://tools.ietf.org/html/draft-ietf- manet-fsr-03