wirelessmeshnetwork

Just another WordPress.com site

Archive for February 2011

NS2 Basics studied on 25 and 26 feb

leave a comment »

System Modeling
System modeling refers to an act of representing an actual system in a simply way. System modeling is extremely important in system design and development, since it gives an idea of how the system would perform if actually implemented. With modeling, the parameters of the system can be changed, tested,and analyzed.Traditionally, there are two modeling approaches: analytical approach and simulation approach.

Analytical Approach
The general concept of analytical modeling approach is to first come up with a way to describe a system mathematically with the help of applied mathematical tools such as queuing and probability theories, and then apply numerical methods to gain insight from the developed mathematical model. When the system is simple and relatively small, analytical modeling would be preferable (over simulation).

Simulation Approach
Compared to analytical modeling, simulation usually requires less abstraction in the model (i.e., fewer simplifying assumptions) since almost every possible detail of the specifications of the system can be put into the simulation model to best describe the actual system. When the system is rather large and complex, a straightforward
mathematical formulation may not be feasible. In this case, the simulation approach is usually preferred to the analytical approach.

Simulation
Simulation is the process of designing a model of a real system and conducting experiments with this model for the purpose of
understanding the behavior of the system and/or evaluating various strategies for the operation of the system.

Time-Dependent Simulation
A main type of simulation is time dependent simulation which proceeds
chronologically. This type of simulation maintains a simulation clock which keeps track of the current simulation time. In most cases, the simulation is run until the clock reaches a predefined threshold.Time-dependent simulation can be further divided into time-driven simulation and event-driven simulation.

Time-Driven Simulation
In time-driven simulations, the simulation clock have exactly a fixed interval of Δ time units. After that interval of the clock, the simulation looks for events that may have occurred during this fixed interval. If so, such events are treated as if they occurred at the end of this interval. One disadvantage of time-driven simulation is that interval contains event which will not be handled until the end of the interval.

Event-Driven Simulation
An event-driven simulation is initiated and run by a set of events. A list of all scheduled events are usually maintained and updated
throughout the simulation process. In an event-driven simulation, all the events in an entire simulation may not be created at the initialization. As the simulation advances, one event may induce one or more events. The new event is usually inserted into the chain (i.e., list) of events arranged chronologically. An event-driven simulation
ignores the intervals of inactivity by advancing the simulation clock from one event time to another. This process goes on and on until all the events are executed, or until the system reaches a specific state.

Network Simulator 2
Network Simulator (Version 2), widely known as NS2, is simply an event-driven simulation tool that has proved useful in studying the dynamic nature of communication networks. Simulation of wired as well as wireless network functions and protocols (e.g., routing algorithms, TCP, UDP) can be done using NS2. In general, NS2 provides users with a way of specifying such network protocols and simulating their corresponding behaviors.

NS2 consists of two key languages: C++ and Object-oriented Tool Com
mand Language (OTcl). While the C++ defines the internal mechanism (i.e.,a backend) of the simulation objects, the OTcl sets up simulation by assembling and configuring the objects as well as scheduling discrete events (i.e., a frontend).

Written by umairabid

February 27, 2011 at 2:28 PM

Posted in project activities

rfc 1058

leave a comment »

RIP rfc 1058 completed.

Written by nomanahmed

February 25, 2011 at 8:13 PM

Posted in project activities

routing metric calculation for Ad hoc network

leave a comment »

Written by umairahmedshah

February 25, 2011 at 12:49 AM

Posted in Useful Links

RIP Protocol Studied

leave a comment »

Introduction
Routing is the task of finding a path from a sender to a desired destination.In the IP “Internet model” this reduces primarily to a matter of finding a series of routers between the source and destination networks.As long as a message or datagram remains on a single network or subnet, any forwarding problems are the responsibility of technology that is specific to the network. For example, Ethernet and the ARPANET

Distance Vector/RIP
Distance vector algorithms are based on the exchange of only a small amount of information. Each entity (router or host) that participates in the routing protocol is assumed to keep information about all of the destinations within the system. Generally, information about all entities connected to one network is summarized by a single entry, which describes the route to all destinations on that network.

Each entity keeps a routing database with one entry for every possible destination in the system. An actual implementation is likely to need to keep the following information about each destination:

– address: in IP implementations of these algorithms, this will be
the IP address of the host or network.

– router: the first router along the route to the destination.

– interface: the physical network which must be used to reach the
first router.

– metric: a number, indicating the distance to the destination.

– timer: the amount of time since the entry was last updated.

In addition, various flags and other internal information will probably be included. This database is initialized with a description of the entities that are directly connected to the system. It is updated according to information received in messages from neighboring routers.

Metric Calculation
let d(i,j) represent the cost of going directly from entity i to entity j. It is infinite if i and j are not immediate neighbors. (Note that d(i,i)
is infinite. That is, we don’t consider there to be a direct
connection from a node to itself.) Since costs are additive, it is
easy to show that the best metric must be described by

D(i,i) = 0, all i
D(i,j) = min [d(i,k) + D(k,j)], otherwise
k
and that the best routes start by going from i to those neighbors k
for which d(i,k) + D(k,j) has the minimum value. (These things can
be shown by induction on the number of steps in the routes.) Note
that we can limit the second equation to k’s that are immediate
neighbors of i. For the others, d(i,k) is infinite, so the term
involving them can never be the minimum.

(Only router will participate in routing and none of the host will participate in it .Consider there are 2 router A and F and A have host B,C,D,and E as we know that internal structure of IP is not visible so IP’s of A,B,C,D,E is summarized as single IP having same distance that will save the space in routing table and reduce unnecessary updates)

Limitations of the Protocol

This protocol does not solve every possible routing problem. As
mentioned above, it is primary intended for use as an IGP in networks
of moderate size. In addition, the following specific limitations
are be mentioned:

– The protocol is limited to networks whose longest path is 15 hops. The designers believe that the basic protocol design is inappropriate for larger networks.

– The protocol depends upon “counting to infinity” to resolve certain
unusual situations.If the system of networks has several hundred networks, and a
routing loop was formed involving all of them, the resolution of
the loop would require either much time or bandwidth . Such a loop would consume a large amount of network bandwidth before the loop was corrected. We believe that in realistic cases, this will not be a problem except on slow lines. Even then, the problem will be fairly unusual, since various precautions are taken that should prevent these
problems in most cases.

– This protocol uses fixed “metrics” to compare alternative routes.
It is not appropriate for situations where routes need to be chosen
based on real-time parameters such a measured delay, reliability,
or load. The obvious extensions to allow metrics of this type are
likely to introduce instabilities of a sort that the protocol is
not designed to handle.

Change in Topology
In RIP every router that participates in routing sends an update message to all its neighbors once every 30 seconds. Suppose the current route for network N uses router G. If we don’t hear from G for 180 seconds, we can assume that either the router has crashed or the network connecting us to it has become unusable. Thus, we mark the route as invalid.

Written by umairabid

February 25, 2011 at 12:37 AM

Posted in Project Background

RIP rfc 1058

leave a comment »

Studying rfc 1058 by C. hedrick (Rutgers university)

studied how distance vector or bellman ford is used in RIP

started studying message formats of RIP, split horizon,split horizon with reverse poisoning, triggered updates(different techniques to avoid routing loops).

timers and processing; still to be studied.

rfc1058

Written by nomanahmed

February 24, 2011 at 9:56 PM

Posted in project activities

NS2 tutorial slide

leave a comment »

Written by umairabid

February 24, 2011 at 1:29 AM

Posted in Useful Links

RIP RFC

leave a comment »

Written by umairabid

February 24, 2011 at 1:25 AM

Posted in project activities

NS2 Guide 2

leave a comment »

Written by umairabid

February 24, 2011 at 1:21 AM

Posted in Useful Links

NS2 Guide 1

leave a comment »

Written by umairabid

February 24, 2011 at 1:17 AM

Posted in Useful Links

DSR RFC

leave a comment »

Written by umairabid

February 24, 2011 at 1:15 AM

Posted in project activities