Difference between revisions of "OLSR"
Onnowpurbo (talk | contribs) |
Onnowpurbo (talk | contribs) |
||
Line 33: | Line 33: | ||
Olsrd mendukung penggunaan plugin yang dapat di load. Hal ini dapat digunakan untuk menangani paket khusus yang dapat di bawa oleh skema OLSR MPR flooding atau fungsi lain yang di inginkan. | Olsrd mendukung penggunaan plugin yang dapat di load. Hal ini dapat digunakan untuk menangani paket khusus yang dapat di bawa oleh skema OLSR MPR flooding atau fungsi lain yang di inginkan. | ||
+ | |||
+ | |||
+ | ==Lebih Jauh Dengan OLSR== | ||
+ | |||
+ | |||
+ | |||
+ | Optimized Link State Routing Protocol | ||
+ | From Wikipedia, the free encyclopedia | ||
+ | (Redirected from OLSR) | ||
+ | Jump to: navigation, search | ||
+ | |||
+ | The Optimized Link State Routing Protocol (OLSR)[1] is an IP routing protocol optimized for mobile ad-hoc networks, which can also be used on other wireless ad-hoc networks. 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. | ||
+ | Contents | ||
+ | |||
+ | 1 Features specific to OLSR | ||
+ | 2 Benefits | ||
+ | 3 Criticisms | ||
+ | 4 Messages | ||
+ | 4.1 Hello | ||
+ | 4.2 Topology control (TC) | ||
+ | 5 Other approaches | ||
+ | 6 OLSR version 2 | ||
+ | 7 Implementations | ||
+ | 8 See also | ||
+ | 9 References | ||
+ | 10 External links | ||
+ | |||
+ | Features specific to OLSR | ||
+ | |||
+ | Link-state routing protocols such as Open Shortest Path First (OSPF) and IS-IS elect a designated router on every link to perform flooding of topology information. In wireless ad-hoc networks, there is different notion of a link, packets can and do go out the same interface; hence, a different approach is needed in order to optimize the flooding process. Using Hello messages the OLSR protocol at each node discovers 2-hop neighbor information and performs a distributed election of a set of multipoint relays (MPRs). Nodes select MPRs such that there exists a path to each of its 2-hop neighbors via a node selected as an MPR. These MPR nodes then source and forward TC messages that contain the MPR selectors. This functioning of MPRs makes OLSR unique from other link state routing protocols in a few different ways: The forwarding path for TC messages is not shared among all nodes but varies depending on the source, only a subset of nodes source link state information, not all links of a node are advertised but only those that represent MPR selections. | ||
+ | |||
+ | Since link-state routing requires the topology database to be synchronized across the network, OSPF and IS-IS perform topology flooding using a reliable algorithm. Such an algorithm is very difficult to design for ad-hoc wireless networks, so OLSR doesn't bother with reliability; it simply floods topology data often enough to make sure that the database does not remain unsynchronized for extended periods of time. | ||
+ | Benefits | ||
+ | |||
+ | Being a proactive protocol, routes to all destinations within the network are known and maintained before use. Having the routes available within the standard routing table can be useful for some systems and network applications as there is no route discovery delay associated with finding a new route. | ||
+ | |||
+ | The routing overhead generated, while generally greater than that of a reactive protocol, does not increase with the number of routes being created. | ||
+ | |||
+ | Default and network routes can be injected into the system by HNA messages allowing for connection to the internet or other networks within the OLSR MANET cloud. Network routes are something reactive protocols do not currently execute well. | ||
+ | |||
+ | Timeout values and validity information is contained within the messages conveying information allowing for differing timer values to be used at differing nodes. | ||
+ | Criticisms | ||
+ | |||
+ | 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 OLSRd project showed that large scale mesh networks can run with OLSRd on thousands of nodes with very little CPU power on 200 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[2] – 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). | ||
+ | Messages | ||
+ | |||
+ | OLSR makes use of "Hello" messages to find its one hop neighbors and its two hop neighbors through their responses. The sender can then select its multipoint relays (MPR) based on the one hop node that offers the best routes to the two hop nodes. Each node has also an MPR selector set, which enumerates nodes that have selected it as an MPR node. OLSR uses topology control (TC) messages along with MPR forwarding to disseminate neighbor information throughout the network. Host and network association (HNA) messages are used by OLSR to disseminate network route advertisements in the same way TC messages advertise host routes. | ||
+ | Hello | ||
+ | |||
+ | Olsr-hello-packet.png | ||
+ | Topology control (TC) | ||
+ | |||
+ | Olsr-tc-packet.png | ||
+ | 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.[3][4] | ||
+ | |||
+ | 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. | ||
+ | |||
+ | For more information see the list of ad-hoc routing protocols. | ||
+ | OLSR version 2 | ||
+ | |||
+ | 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 | ||
+ | |||
+ | 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. | ||
+ | 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/ | ||
+ | SOURCEFORGE.NET-OLSR – Created by MOVIQUITY and based on studies within the project Workpad, it offers a code in C# to deploy a MANET (Ad-Hoc, Meshnet) with protocol OLSR. Developed for WM 6, Win XP and can be adapted to other platforms using NET Framework and Compact http://sourceforge.net/projects/wmolsr/ | ||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
Revision as of 09:58, 21 August 2012
olsr.org OLSR daemon adalah sebuah implementasi dari protokol Optimized Link State Routing. Sehingga memungkinkan sebuah device jaringan untuk melakukan mesh routing.
OLSR bisa dijalankan jika card WiFi mendukung mode ad-hoc dan juga pada device ethernet biasa. OLSR adalah salah satu dari dua standard Internet untuk Jaringan Mesh. OSLR banyak digunakan dan sudah teruji keandalannya.
Karena OLSR bekerja di lapisan / layer 3, dia sangat portable. Saat ini dapat dijalankan di
- Windows (XP and Vista, Windows 7)
- Linux (i386, arm, alpha, mips, xscale)
- OS X (powerpc, intel, xscale, iPhone)
- VxWorks
- NetBSD
- FreeBSD
- OpenBSD
- Nokia N900
- Google phone (Android, G1)
- linux wifi phones (WIP)
- laptop
- Intel Classmate
OLSR sangat cepat dan menggunakan sedikit CPU time sehingga dapat menghemat batere dari embedded dan portable device.
OLSR sangat scalable. OLSR di jalankan di jaringan komunitas wireless mesh dengan 2000 nodes (Athens wireless network), ~ 600 nodes (berlin FreiFunk.net), Leipzig Freifunk net, ~ 400 nodes (FunkFeuer.at). Sebagai protokol mesh routing yang di operasikan di lapangan, OLSR sering menerima stress test dan cukup solid sejak versi 0.5.6-r7 terlepas apa yang dikatakan oleh protokol lain. Tentunya masih banyak ruang untuk perbaikan.
OLSR di released menggunakan lisensi BSD. Oleh karenanya OLSR sangat mudah untuk dimasukan ke projek anda, terima kasih untuk lisensi yang sangat liberal.
OLSR adalah sebuah project open source, sangat di sarankan agar anda tergabung & ikut aktif mengembangkan.
OLSR adalah routing protocol untuk jaringan mobile ad-hoc. Protokol tersebut bersifat pro-active, table driven dan menggunakan teknik multipoint relaying untuk optimized message flooding. olsrd juga menjalankan link quality extension.
Olsrd dibuat dengan cara terstruktur dan terimplementasi dengan baik sehingga mudah di maintain. di expand dan di porting ke platform lain. Olsrd mempunyai arsitektur plugin yang sangat flexibel.
Mengimplementasikan RFC3626 baik untuk core maupun fungsi tambahannya.
Olsrd mendukung penggunaan plugin yang dapat di load. Hal ini dapat digunakan untuk menangani paket khusus yang dapat di bawa oleh skema OLSR MPR flooding atau fungsi lain yang di inginkan.
Lebih Jauh Dengan OLSR
Optimized Link State Routing Protocol From Wikipedia, the free encyclopedia
(Redirected from OLSR)
Jump to: navigation, search
The Optimized Link State Routing Protocol (OLSR)[1] is an IP routing protocol optimized for mobile ad-hoc networks, which can also be used on other wireless ad-hoc networks. 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. Contents
1 Features specific to OLSR 2 Benefits 3 Criticisms 4 Messages 4.1 Hello 4.2 Topology control (TC) 5 Other approaches 6 OLSR version 2 7 Implementations 8 See also 9 References 10 External links
Features specific to OLSR
Link-state routing protocols such as Open Shortest Path First (OSPF) and IS-IS elect a designated router on every link to perform flooding of topology information. In wireless ad-hoc networks, there is different notion of a link, packets can and do go out the same interface; hence, a different approach is needed in order to optimize the flooding process. Using Hello messages the OLSR protocol at each node discovers 2-hop neighbor information and performs a distributed election of a set of multipoint relays (MPRs). Nodes select MPRs such that there exists a path to each of its 2-hop neighbors via a node selected as an MPR. These MPR nodes then source and forward TC messages that contain the MPR selectors. This functioning of MPRs makes OLSR unique from other link state routing protocols in a few different ways: The forwarding path for TC messages is not shared among all nodes but varies depending on the source, only a subset of nodes source link state information, not all links of a node are advertised but only those that represent MPR selections.
Since link-state routing requires the topology database to be synchronized across the network, OSPF and IS-IS perform topology flooding using a reliable algorithm. Such an algorithm is very difficult to design for ad-hoc wireless networks, so OLSR doesn't bother with reliability; it simply floods topology data often enough to make sure that the database does not remain unsynchronized for extended periods of time. Benefits
Being a proactive protocol, routes to all destinations within the network are known and maintained before use. Having the routes available within the standard routing table can be useful for some systems and network applications as there is no route discovery delay associated with finding a new route.
The routing overhead generated, while generally greater than that of a reactive protocol, does not increase with the number of routes being created.
Default and network routes can be injected into the system by HNA messages allowing for connection to the internet or other networks within the OLSR MANET cloud. Network routes are something reactive protocols do not currently execute well.
Timeout values and validity information is contained within the messages conveying information allowing for differing timer values to be used at differing nodes. Criticisms
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 OLSRd project showed that large scale mesh networks can run with OLSRd on thousands of nodes with very little CPU power on 200 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[2] – 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). Messages
OLSR makes use of "Hello" messages to find its one hop neighbors and its two hop neighbors through their responses. The sender can then select its multipoint relays (MPR) based on the one hop node that offers the best routes to the two hop nodes. Each node has also an MPR selector set, which enumerates nodes that have selected it as an MPR node. OLSR uses topology control (TC) messages along with MPR forwarding to disseminate neighbor information throughout the network. Host and network association (HNA) messages are used by OLSR to disseminate network route advertisements in the same way TC messages advertise host routes. Hello
Olsr-hello-packet.png Topology control (TC)
Olsr-tc-packet.png 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.[3][4]
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.
For more information see the list of ad-hoc routing protocols. OLSR version 2
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
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. 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/ SOURCEFORGE.NET-OLSR – Created by MOVIQUITY and based on studies within the project Workpad, it offers a code in C# to deploy a MANET (Ad-Hoc, Meshnet) with protocol OLSR. Developed for WM 6, Win XP and can be adapted to other platforms using NET Framework and Compact http://sourceforge.net/projects/wmolsr/
Referensi
- http://www.olsr.org/
- http://agungsep.wordpress.com/2008/05/20/automatic-start-up-aplikasi-olsr-di-ubuntu-804/
- http://wmunguiam.blogspot.com/2009/01/olsr-over-ubuntu-804.html
- http://wiki.ninux.org/NanostationM5AirOSModOLSR
- http://wiki.openwrt.org/inbox/mesh.olsr
- http://en.wikipedia.org/wiki/OLSR
Pranala Menarik
- WiFi: HotSpot - Linksys WRT54GL
- WiFi: HotSpot - Linksys WRT54GL Konfigurasi Orginal
- WiFi: HotSpot - Linksys WRT54GL Upgrade dd-wrt
- WiFi: HotSpot - Linksys WRT54GL Upgrade dd-wrt OLSR
- WiFi: HotSpot - DD-WRT WRT54GL Mengaktifkan OLSR
- WiFi: HotSpot - Linksys WRT54GL Upgrade FreiFunk Firmware
- WiFi: HotSpot - Linksys WRT54GL Konfigurasi FreiFunk
- WiFi: HotSpot - Linksys WRT54GL FreiFunk Setelah Upgrade Software
- WiFi: HotSpot - Linksys WRT54GL FreiFunk Peta Mesh Network
- De-Bricking WRT54GL v.1.1
- OLSR
- OLSR - di OpenWRT
- OLSR - di UBNT
- UBNT
- OLSR - di Ubuntu
- WNDW: Jaringan Mesh dengan OLSR
- WiFi: HotSpot
- WiFi: Mesh Network
- WiFi: Mesh Potato HOWTOs
- WiFi: Topik Lanjut
- Wireless Internet Berbasis WiFi