Tuesday, May 3, 2011

Ad-hoc Routing Protocols




       Traditional adhoc routings can be divided into two categories as on-demand (or reactive) and table-driven (or proactive) protocols. Some of the best known on-demand protocols are Ad-hoc On-demand Distance Vector routing (AODV), Dynamic Source Routing (DSR) and Temporary Ordered Routing Algorithm (TORA). Some popular proactive routings include Optimized Link State Routing Protocol (OLSR), Destination Sequence Distance Vector routing protocol (DSDV).
 
 



OLSR


           Optimized Link State Protocol (OLSR) is a proactive routing protocol, so the routes are always immediately available when needed. OLSR is an optimization version of a pure link state protocol. So the topological changes cause the flooding of the topological information to all available hosts in the network. To reduce the possible overhead in the network protocol uses Multi-point Relays (MPR). The idea of MPR is to reduce flooding of broadcasts by reducing the same broadcast in some regions in the network. Another reduce is to provide the shortest path. The reducing the time interval for the control messages transmission can bring more reactivity to the topological changes . OLSR uses three control messages for routing as,

a. TC Message
b. Hello Message
c. MID Message

There is also Multiple Interface Declaration (MID) messages which are used for informing other host that the announcing host can have multiple OLSR interface addresses. The MID message is broadcasted throughout the entire network only by MPRs. There is also a “Host and Network Association” (HNA) message which provides the external routing information by giving the possibility for routing to the external addresses. The HNA message provides information about the network- and the netmask addresses, so that OLSR host can consider that the announcing host can act as a gateway to the announcing set of addresses. The HNA is considered as a generalized version of the TC message with only difference that the TC message can inform about route cancelling while HNA message information is removed only after expiration time.



Hello Message:
                    The link in the ad hoc network can be either unidirectional or bidirectional so the host must know this information about the neighbors. The Hello messages are broadcasted periodically for the neighbor sensing. The Hello messages are only broadcasted one hop away so that they are not forwarded further. When the first host receives the Hello message from the second host, it sets the second host status to asymmetric in the routing table. When the first host sends a Hello message and includes that, it has the link to the second host as asymmetric, the second host set first host status to symmetric in own routing table. Finally, when second host send again Hello message, where the status of the link for the first host is indicated as symmetric, then first host changes the status from asymmetric to symmetric. In the end both hosts knows that their neighbor is alive and the corresponding link is bidirectional.

Hello messages are used for finding the information about the link status and the host’s neighbors. With the Hello message the Multi-point Relay (MPR) Selector set is constructed which describes which neighbors has chosen this host to act as MPR and from this information the host can calculate its own set of the MPRs. The Hello messages are sent only one hop away but the TC messages are broadcasted throughout the entire network. TC messages are used for broadcasting information about own advertised neighbors which includes at least the MPR Selector list. The TC messages are broadcasted periodically and only the MPR hosts can forward the TC messages.

MPR:
             The Multipoint Relays (MPR) is the key idea behind the OLSR protocol to reduce the information exchange overhead. Instead of pure flooding the OLSR uses MPR to reduce the number of the host which broadcasts the information throughout the network. The MPR is a host’s one hop neighbor which may forward its messages. The MPR set of host is kept small in order for the protocol to be efficient. In OLSR only the MPRs can forward the data throughout the network. Each host must have the information about the symmetric one hop and two hop neighbors in order to calculate the optimal MPR set. Information about the neighbors is taken from the Hello messages. The two hop neighbors are found from the Hello message because each Hello message contains all the hosts’ neighbors. Selecting the minimum number of the one hop neighbors which covers all the two hop neighbors is the goal of the MPR selection algorithm. Also each host has the Multipoint Relay Selector set, which indicates which hosts has selected the current host to act as a MPR.

Proposed algorithm for selecting Multi-point Relay set:
1. Take all the symmetric one hop neighbors which are willing to act as an MPR.
2. Calculate for every neighbor host a degree, which is a number of the symmetric
neighbors that are two hops away from the calculating source and does not
include the source or its one hop neighbors.
  1. Add the neighbor symmetric host to the MPR set. If it is the only neighbor form which is possible to get to the specific two hop neighbor, then remove the chosen host neighbors from the two hop neighbor set.
  2. If there are still some hosts in the two hop neighbor set, then calculate the reachability of the each one hop neighbor, meaning the number of the two hop neighbors, that are yet uncovered by MPR set. Choose the node with highest willing value, if the values are the same then takes the node with greater number of reachability. If the reachability is the same, then take the one with greater degree counted in the second step. After choosing the neighbor for MPR set remove the reachable two hop neighbor from the two hop neighbor set.
  3. Repeat previous step until the two hop neighbors set is empty.
  4. For the optimization, set the hosts in the MPR set in the increasing order basing on the willingness. If one host is taken away and all the two hop neighbors, covered by at least one host and the willingness of the host are smaller than WILL_ALWAYS, then the host may be removed.

TC Message:
                 In order to exchange the topological information and build the topology information base the host that were selected as MPR need to sent the topology control (TC) message. The TC messages are broadcasted throughout the network and only MPR are allowed to forward TC messages. The TC messages are generated and broadcasted periodically in the network. The TC message is sent by a host in order to advertise own links in the network. The host must send at least the links of its MPR selector set. The TC message includes the own set of advertised links and the sequence number of each message. The sequence number is used to avoid loops of the messages and for indicating the freshness of the message, so if the host gets a message with the smaller sequence number it must discard the message without any updates.
The host must increment the sequence number when the links are removed from the TC message and also it should increment the sequence number when the links are added to the message. The sequence numbers are wrapped around. When the hosts advertised links set becomes empty, it should still send empty TC messages for specified amount of time, in order to invalidate previous TC messages. This should stop sending the TC messages until it has again some information to send. The size of the TC message can be quite big, so the TC message can be sent in parts, but then the receiver must combine all parts during some specified amount of time. Host can increase its transmission rate to become more sensible to the possible link failures. When the change in the MPR Selector set is noticed, it indicates that the link failure has happened and the host must transmit the new TC message as soon as possible.



AODV

           The information in this section concerning the Ad Hoc Ondemand Distance Vector Protocol (AODV). AODV is a reactive protocol that means; the routes are created and maintained only when they are needed. The routing table stores the information about the next hop to the destination and a sequence number which is received from the destination and indicating the freshness of the received information. Also the information about the active neighbors is received throughout the discovery of the destination host. When the corresponding route breaks, then the neighbors can be notified. Mainly 4 types of messages are used in this routing protocol that are

a. Hello
b. RREQ
c. RREP
d. RERR
           
                      The main messages in AODV are received via UDP on port 654. The route discovery is used by broadcasting the RREQ message to the neighbors with the requested destination sequence number, which prevents the old information to be replied to the request and also prevents looping problem, which is essential to the traditional distance vector protocols. The route reply use RREP message that can be only generated by the destination host or the hosts who have the information that the destination host is alive and the connection is fresh. This feature enables that the unidirectional links can be detected. When the breakage of the route is noticed the host sends RERR message to the neighbors. The Hello message is periodically sent for maintaining the route information. All the information about the routes in the network is stored in this table. The routing table has the following entries i.e. DSN, flag, next hop, IP address, State, hop count, the list of precursors, Life time and network interface.
                      The AODV protocol is a flat routing protocol it does not need any central administrative system to handle the routing process. Reactive protocols like AODV tend to reduce the control traffic messages overhead at the cost of increased latency in finding new routes. When the link breakage occurs then the host can try to locally repair the link if the destination is no further than specified amount of hops. In order to repair the link the host increase the destination sequence number and broadcasts the RREQ message to the host. The TTL for the IP header must be calculated, so that locally repair process would not spread throughout the network.

Sequence Numbers:

                 The sequence numbers are the key idea for removing the old and invaluable information from the network. The sequence number act as timestamps and prevent this distance vector protocol from the loop problem The destination sequence number for each possible destination host is stored in the routing table. The destination sequence numbers are updated in the routing table when the host receives the message with the greater sequence number. The host can change the destination sequence number in the routing table if it is offering a new route to itself or if some route expires or simply breaks The host also keeps its own sequence number, which must be incremented only in two different cases: before it sends RREQ message and when the host sends a RREP message responding to the RREQ message. In the second case the sequence number must be incremented to the maximum of the current sequence number and the sequence number in the received RREQ message. The sequence numbers must be treated as unsigned integers so that the possible rollovers can occur, AODV protocol supports the sequence number to be rolled over without any problems.


HELLO MESSAGES:

              Although AODV is a reactive protocol it uses the Hello messages periodically to inform its neighbors that the link to the host is alive. The Hello messages are broadcasted with TTL equals to 1, so that the message will not be forwarded further. When host receives the Hello message it will update the lifetime of the host information in the routing table. If the host does not get information from the host’s neighbor for specified amount of time, then the routing information in the routing table is marked as lost. This action generates needed RRER message to inform other hosts of the link breakage. The routes that were created by the Hello message and were not used for any routing actions should not generate the RERR message when the link breakage occurs.

RREQ, RREP and RREP-ACK:

           The route request message (RREQ) is sent when the host does not know the route to the needed destination host or the existed route is expired. The RREQ message includes the destination sequence number which is the last known sequence number of the destination host entry found in the routing table. If there contains no entry for the destination host, then the unknown sequence number flag must be set. The RREQ message also contains the requesting hosts sequence number, which must be incremented beforehand. The RREQ ID field is incremented by one which is found from the last used RREQ message, which was sent by this host. Also the hop count metric must be set to zero and before sending the RREQ message the RREQ ID and its own address must be saved to the buffer for the specified amount of time, so that it recognize the replies Every intermediate host will generate the RREP message and unicast it to the requesting host. Also the intermediate host must generate the gratuitous RREP to the destination host.
The host can generate the route reply message (RREP) if the destination is the host itself or if the route to the destination is valid and has the same or greater destination sequence number, but only if the D field is not set. D field in the RREQ message indicates that only the destination host can reply to the RREQ message. When generating the RREP message host copies the destination address and the requested host’s sequence number to the corresponding RREP message’s fields. If the receiver is the destination host then its own sequence number is incremented and copied to the destination sequence number field. In addition, the hop count is set to zero and the lifetime field of the RREP message is set to the initial timeout value of the host. If the receiver is the intermediate host, then it just copies destination sequence number from the routing table and adds the host address from where it has received RREQ message to the destination address field. Also the host must add the hop count with the lifetime from the routing table to the RREP. The lifetime is calculated by subtracting the current time and the expiration time from the routing table. When the RREP message is created it is sent using unicast to the next hop in order to be delivered to the requested host[1]. The hop count metric is incremented along the path, so at the end, it corresponds to the actual distance between the hosts.

REPAIR:
           When the link breakage occurs then the host can try to locally repair the link if the destination is no further than specified amount of hops. In order to repair the link the host increase the destination sequence number and broadcasts the RREQ message to the host. The host waits for the RREP messages to its RREQ message for specified amount of time. If the RREP message is not received, then it changes the routing table status for the entry to invalid. If host receives the RREP message then the hop count metric is compared. If the hop metric from the message is greater than the previous one then the RERR with the N field set up is broadcasted. The N field in the RERR message indicates that the host has locally repaired the link and the entry in the table should not be deleted. The received RREP message is handled as original RREP message. The repairing of the link before the data is sent to unavailable host is a proactive repairing. Proactive repairing can be inefficient because the risk of repairing the routes that are not used anymore. So the proactive repairing can be used basing on the local traffic and the workload of the network.


What is Tshark?


           TShark is a network protocol analyzer. It lets you capture packet data from a live network, or read packets from a previously saved capture file, either printing a decoded form of those packets to the standard output or writing the packets to a file. Packet capturing is performed with the pcap library. The capture filter syntax follows the rules of the pcap library. This syntax is different from the read filter syntax. A read filter can also be specified when capturing, and only packets that pass the read filter will be displayed or saved to the output file; note, however, that capture filters are much more efficient than read filters, and it may be more difficult for TShark to keep up with a busy network if a read filter is specified for a live capture.

The following are some of its features:
• Work on UNIX and Windows
• It can capture live packet from a network interface
• It describes very detailed information, which is very important to measure the performance metrics.
• It shows various statistics.

What is wx-python??


WxPython API is a set of functions and widgets. Widgets are essential building blocks of a GUI application. Under Windows widgets are called controls. We can roughly divide programmers into two groups. They code applications or libraries. In our case, wxPython is a library that is used by application programmers to code applications. Technically, wxPython is a wrapper over a C++ GUI API called wxWidgets. So it is not a native API. e.g. not written directly in Python. The only native GUI library for an interpreted language that I know is Java's Swing library.
In wxPython we have lots of widgets. These can be divided into some logical groups.
a. Base Widgets
b. Top level Widgets
c. Containers
d. Dynamic Widgets
e. Static Widgets

what is python??


Python is an interpreted, general-purpose high-level programming language whose design philosophy emphasizes code readability. Python aims to combine "remarkable power with very clear syntax", and its standard library is large and comprehensive. Its use of indentation for block delimiters is unique among popular programming languages. Python supports multiple programming paradigms, primarily but not limited to object-oriented, imperative and, to a lesser extent, functional programming styles. It features a fully dynamic type system and automatic memory management, similar to that of Scheme, Ruby, Perl, and Tcl. Like other dynamic languages, Python is often used as a scripting language, but is also used in a wide range of non-scripting contexts.
Python was intended to be a highly readable language. It is designed to have an uncluttered visual layout, frequently using English keywords where other languages use punctuation. Python requires less boilerplate than traditional manifestly typed structured languages such as C or Pascal, and has a smaller number of syntactic exceptions and special cases than either of these. Python uses whitespace indentation, rather than curly braces or keywords, to delimit blocks (a feature also known as the off-side rule). An increase in indentation comes after certain statements; a decrease in indentation signifies the end of the current block.

Features of Python:

a. Simple:
Python is a simple and minimalistic language. Reading a good Python program feels almost like reading English, although very strict English! This pseudo-code nature of Python is one of its greatest strengths. It allows you to concentrate on the solution to the problem rather than the language itself.
b. Easy to Learn:
As you will see, Python is extremely easy to get started with. Python has an extraordinarily simple syntax, as already mentioned.
c. Free and Open Source:
Python is an example of a FLOSS (Free/Libré and Open Source Software). In simple terms, you can freely distribute copies of this software, read its source code, make changes to it, use pieces of it in new free programs, and that you know you can do these things. FLOSS is based on the concept of a community which shares knowledge. This is one of the reasons why Python is so good - it has been created and is constantly improved by a community who just want to see a better Python.
d. High-level Language:
When you write programs in Python, you never need to bother about the low-level details such as managing the memory used by your program, etc.
e. Portable:
Due to its open-source nature, Python has been ported (i.e. changed to make it work on) to many platforms. All your Python programs can work on any of the platforms without requiring any changes at all if you are careful enough to avoid any system-dependent features. 

Features of Python:

a. Simple:
Python is a simple and minimalistic language. Reading a good Python program feels almost like reading English, although very strict English! This pseudo-code nature of Python is one of its greatest strengths. It allows you to concentrate on the solution to the problem rather than the language itself.
b. Easy to Learn:
As you will see, Python is extremely easy to get started with. Python has an extraordinarily simple syntax, as already mentioned.
c. Free and Open Source:
Python is an example of a FLOSS (Free/Libré and Open Source Software). In simple terms, you can freely distribute copies of this software, read its source code, make changes to it, use pieces of it in new free programs, and that you know you can do these things. FLOSS is based on the concept of a community which shares knowledge. This is one of the reasons why Python is so good - it has been created and is constantly improved by a community who just want to see a better Python.
d. High-level Language:
When you write programs in Python, you never need to bother about the low-level details such as managing the memory used by your program, etc.
e. Portable:
Due to its open-source nature, Python has been ported (i.e. changed to make it work on) to many platforms. All your Python programs can work on any of the platforms without requiring any changes at all if you are careful enough to avoid any system-dependent features.
f. Interpreted:
Python does not need compilation to binary. You just run the program directly from the source code. Internally, Python converts the source code into an intermediate form called byte codes and then translates this into the native language of your computer and then runs it. All this, actually, makes using Python much easier since you don't have to worry about compiling the program, making sure that the proper libraries are linked and loaded, etc, etc. This also makes your Python programs much more portable, since you can just copy your Python program onto another computer and it just works!
g. Object Oriented:
Python supports procedure-oriented programming as well as object-oriented programming. In procedure-oriented languages, the program is built around procedures or functions which are nothing but reusable pieces of programs. In object-oriented languages, the program is built around objects which combine data and functionality. Python has a very powerful but simplistic way of doing OOP, especially when compared to big languages like C++ or Java.
h. Extensible:
If you need a critical piece of code to run very fast or want to have some piece of algorithm not to be open, you can code that part of your program in C or C++ and then use them from your Python program.
i. Embeddable:
You can embed Python within your C/C++ programs to give 'scripting' capabilities for your program's users. 
j. Extensive Libraries:
The Python Standard Library is huge indeed. It can help you do various things involving regular expressions, documentation generation, unit testing, threading, databases, web browsers, CGI, ftp, email, XML, XML-RPC, HTML, WAV files, cryptography, GUI (graphical user interfaces), Tk, and other system-dependent stuff. Remember, all this is always available wherever Python is installed. This is called the 'Batteries Included' philosophy of Python
 
 



 




OLSR Installation


For implementation of olsr we downloaded olsrd-0.6.1 and installed in the system. The source-tree includes the following directories, files, gui, lib, make, redhat and src. The implementation procedure is given below.

First, we build with the command:
>make
We install as root with the command:
>make install
To delete object files we run:
>make clean
Optionally, to clean all generated files, we use the command:
>make uberclean