Archive for February 2011
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.
The general concept of analytical modeling approach is to ﬁrst 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).
Compared to analytical modeling, simulation usually requires less abstraction in the model (i.e., fewer simplifying assumptions) since almost every possible detail of the speciﬁcations 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 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.
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 predeﬁned threshold.Time-dependent simulation can be further divided into time-driven simulation and event-driven simulation.
In time-driven simulations, the simulation clock have exactly a ﬁxed interval of Δ time units. After that interval of the clock, the simulation looks for events that may have occurred during this ﬁxed 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.
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 speciﬁc 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++ deﬁnes the internal mechanism (i.e.,a backend) of the simulation objects, the OTcl sets up simulation by assembling and conﬁguring the objects as well as scheduling discrete events (i.e., a frontend).
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 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
– 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.
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
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.
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.