Optimized Link State Routing Protocol: Difference between revisions

Revision as of 12:51, 27 May 2013

Revision as of 20:23, 27 May 2013

Line 1:

The '''Optimized Link State Routing Protocol''' ('''OLSR''')<ref>RFC 3626</ref> is an [[Internet Protocol|IP]] routing protocol optimized for [[mobile ad-hoc network]]s, which can also be used on other [[wireless ad-hoc network]]s. OLSR is a proactive [[link-state routing protocol]], which uses ''hello'' and ''topology control'' (TC) messages to discover and then disseminate link state information throughout the [[mobile ad-hoc network]]. Individual nodes use this topology information to compute next hop destinations for all nodes in the network using shortest hop forwarding paths. [[File:Olsr-overview.pdf|thumb|Diagram of OLSR data flow.]]

== Features specific to OLSR ==

Line 18:

The original definition of OLSR does not include any provisions for sensing of link quality; it simply assumes that a link is up if a number of hello packets have been received recently. This assumes that links are bi-modal (either working or failed), which is not necessarily the case on wireless networks, where links often exhibit intermediate rates of packet loss. Implementations such as the open source OLSRd (commonly used on [[Linux]]-based mesh routers) have been extended (as of v. 0.4.8) with link quality sensing.

Being a proactive protocol, OLSR uses power and network resources in order to propagate data about possibly unused routes. While this is not a problem for wired access points, and laptops, it makes OLSR unsuitable for sensor networks that try to sleep most of the time.

For small scale wired access points with low CPU power, the open source [http://www.olsr.org OLSRd] project showed that large scale mesh networks can run with OLSRd on thousands of nodes with very little CPU power on {{val|200|ul=MHz}} embedded devices.

Being a link-state protocol, OLSR requires a reasonably large amount of bandwidth and CPU power to compute optimal paths in the network. In the typical networks where OLSR is used (which rarely exceed a few hundreds of nodes), this does not appear to be a problem.

By only using MPRs to flood topology information, OLSR removes some of the redundancy of the flooding process, which may be a problem in networks with moderate to large packet loss rates<ref>{{cite journal|author=M. Abolhasan, B. Hagelstein, J. C.-P. Wang|title=Real-world performance of current proactive multi-hop mesh protocols|year=2009|url=http://ro.uow.edu.au/infopapers/736/}}</ref> – however the MPR mechanism is self-pruning (which means that in case of packet losses, some nodes that would not have retransmitted a packet, may do so).

Line 35:

== Other approaches ==

The problem of routing in ad-hoc wireless networks is actively being researched, and OLSR is but one of several proposed solutions. To many, it is not clear whether a whole new protocol is needed, or whether [[OSPF]] could be extended with support for wireless interfaces.<ref>Extensions to OSPF to Support Mobile Ad Hoc Networking, Madhavi Chandra, Abhay Roy, Mar-10, RFC 5820</ref><ref>MANET Extension of OSPF using CDS Flooding, Richard Ogier, Phil Spagnolo, Aug-09, RFC 5614</ref>

In bandwidth- and power-starved environments, it is interesting to keep the network silent when there is no traffic to be routed. Reactive routing protocols do not maintain routes, but build them on demand. As link-state protocols require database synchronisation, such protocols typically use the distance vector approach, as in [[AODV]] and [[DSDV]], or more ad-hoc approaches that do not necessarily build optimal paths, such as [[Dynamic Source Routing]].

Line 44:

OLSRv2 is currently being developed within the IETF. It maintains many of the key features of the original including MPR selection and dissemination. Key differences are the flexibility and modular design using shared components: packet format packetbb, and neighborhood discovery protocol NHDP. These components are being designed to be common among next generation IETF MANET protocols. Differences in the handling of multiple address and interface enabled nodes is also present between OLSR and OLSRv2.

== Implementations ==

* [http://www.olsr.org/ OLSR.ORG] – Downloadable code for OLSR on GNU/Linux, Windows, Mac OS X, FreeBSD and NetBSD systems. Features a great deal of documentation, including an informative survey of related work.

* [http://cs.itd.nrl.navy.mil/work/olsr/index.php NRL-OLSR] – Open source code of NRL-OLSR. Works on Windows, MacOS, Linux, and various embedded PDA systems such as Arm/Zaurus and PocketPC as well as simulation environments [[ns2]] and OPNET., http://cs.itd.nrl.navy.mil/focus/

Line 54:

== References ==

{{reflist|2}}

== External links ==

* [http://ietf.org IETF Home Page] The Internet Engineering Task Force standards body

* [http://olsr.funkfeuer.at olsr.funkfeuer.at] currently advancing the olsr.org implementation to improve scalability