Project Report Lsi
Project Report Lsi
Project Report Lsi
Submitted
Goa University
(2012-13)
Approval Sheet
This is to certify that Satyam Premanand Nagvenkar , bearing Roll no: 11ME10, has been
admitted to the candidacy of ME (Information Technology) in July 2011 and he has
undertaken the dissertation entitled “OPTIMIZING ROUTING IN ADHOC ON-
DEMAND DISTANCE VECTOR PROTOCOL ” is submitted as a partial fulfillment of
the requirements for the Masters Degree of Information Technology under Goa University
as it is examined and found satisfactory.
_________________
Project Examiners
Date: ___________
Place: ___________
INDEX
2. Introduction …………………………………….
3. Overview ………………………………………
4. AODV terminology
5. Applicability statement
6. Message formats
7. AODV Operation
8. Simulation model
9. Observation/Performance evaluation
Opinions are central to almost all human activities and are key influencers of
our behaviors. Our beliefs and perceptions of reality, and the choices we
make, are, to a considerable degree, conditioned upon how others see and
evaluate the world. For this reason, when we need to make a decision we
often seek out the opinions of others. This is not only true for individuals but
also true for organizations.
The deployment of Web 2.0 technologies has led to rapid growth of various
opinions and reviews on the web, such as reviews on products and opinions
about people. Such content can be very useful to help people find interesting
entities like products, businesses and people based on their individual
preferences or tradeoffs. In this paper, we propose a different way of
leveraging opinionated content, by directly ranking entities based on a user's
preferences. Our idea is to represent each entity with the text of all the
reviews of that entity. Given a user's keyword query that expresses the desired
features of an entity, we can then rank all the candidate entities based on how
well opinions on these entities match the user's preferences. We study several
methods for solving this problem, including both standard text retrieval
models. Experiment results on ranking entities based on opinions in car
domain show that the proposed extensions are effective and lead to
improvement of ranking accuracy over the standard text retrieval models for
this task.
The vast amount of opinions expressed by experts and ordinary users can be
very useful to help people make all kinds of decisions, ranging from what to
buy to what treatment to choose for a disease. For example, shoppers at
Amazon typically would read the reviews about a product before buying it,
and travelers may rely on opinions about hotels on Trip advisor to help them
choose an appropriate hotel at the destination. It has been shown that 77% of
online shoppers use reviews and ratings when making a purchase decision.
Summarization
To reduce the length and detail of a document while retaining its main
points and overall meaning.
Some sentences that are not essential in the summary may be included
in the summary because of their more weight than the important
sentences.
Classification
Same test documents may be assigned to more than one text category.
- Word Tagging(P.O.S)
- Case Folding
- Tokenization
- Stemming
Based on the weight of the keywords, sentences with more weight are
used to generate the summary.
The classifier then assign one category to one document of the testing
dataset
3. Overview
Nodes monitor the link status of next hops in active routes. When a link
break in an active route is detected, a RERR message is used to notify other
nodes that the loss of that link has occurred. The RERR message indicates
those destinations are no longer reachable by way of the broken link. In order
to enable this reporting mechanism, each node keeps a "precursor list",
containing the IP address for each its neighbors that are likely to use it as a
next hop towards each destination. The information in the precursor lists is
most easily acquired during the processing for generation of a RREP
message, which by definition has to be sent to a node in a precursor list. If
the RREP has a nonzero prefix length, then the originator of the RREQ which
solicited the RREP information is included among the precursors for the
subnet route (not specifically for the particular destination).
- Destination IP Address
- Other state and routing flags (e.g., valid, invalid, repairable, being
repaired)
- Network Interface
- Next Hop
- List of Precursors
Active route
A route towards a destination that has a routing table entry that is
marked as valid. Only active routes can be used to forward data packets.
Broadcast
Broadcasting means transmitting to the IP Limited Broadcast
address, 255.255.255.255. A broadcast packet may not be blindly forwarded,
but broadcasting is useful to enable dissemination of AODV messages
throughout the ad hoc network.
Destination
An IP address to which data packets are to be transmitted. Same as
"destination node". A node knows it is the destination node for a typical data
packet when its address appears in the appropriate field of the IP header.
Routes for destination nodes are supplied by action of the AODV protocol,
which carries the IP address of the desired destination node in route
discovery messages.
Forwarding node
A node that agrees to forward packets destined for another node, by
retransmitting them to a next hop that is closer to the unicast destination
along a path that has been set up using routing control messages.
Forward route
A route set up to send data packets from a node originating a
Route Discovery operation towards its desired destination.
Invalid route
A route that has expired, denoted by a state of invalid in the routing
table entry. An invalid route is used to store previously valid route
information for an extended period of time. An invalid route cannot be used
to forward data packets, but it can provide information useful for route
repairs, and also for future RREQ messages.
Originating node
A node that initiates an AODV route discovery message to be
processed and possibly retransmitted by other nodes in the ad hoc network.
For instance, the node initiating a Route Discovery process and broadcasting
the RREQ message is called the originating node of the RREQ message.
Reverse route
A route set up to forward a reply (RREP) packet back to the
originator from the destination or from an intermediate node having a route to
the destination.
Sequence number
A monotonically increasing number maintained by each originating
node. In AODV routing protocol messages, it is used by other nodes to
determine the freshness of the information contained from the originating
node.
5. Applicability Statement
The AODV routing protocol is designed for mobile ad hoc networks with
populations of tens to thousands of mobile nodes. AODV can handle low,
moderate, and relatively high mobility rates, as well as a variety of data
traffic levels. AODV is designed for use in networks where the nodes can all
trust each other, either by use of preconfigured keys, or because it is known
that there are no malicious intruder nodes. AODV has been designed to
reduce the dissemination of control traffic and eliminate overhead on data
traffic, in order to improve scalability and performance.
6. Message Formats
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
The format of the Route Request message is illustrated above, and contains
the following fields:
Type 1
Hop Count
RREQ ID
Destination IP Address
The latest sequence number received in the past by the originator for
any route towards the destination.
Originator IP Address
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
Type | R |A| Reserved | Prefix Size | Hop Count
Destination IP address
Destination Sequence Number
Originator IP address
Lifetime
The format of the Route Reply message is illustrated above, and contains
the following fields:
Type 2
A Acknowledgment required.
If nonzero, the 5-bit Prefix Size specifies that the indicated next hop
may be used for any nodes with the same routing prefix (as defined by the
Prefix Size) as the requested destination.
Hop Count
Destination IP Address
Originator IP Address
The IP address of the node which originated the RREQ for which the
route is supplied.
Lifetime
The time in milliseconds for which nodes receiving the RREP consider
the route to be valid.
6.3 Route Error (RERR) Message Format
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
Type |N| Reserved | DestCount
The format of the Route Error message is illustrated above, and contains the
following fields :
Type 3
DestCount
The sequence number in the route table entry for the destination listed
in the previous Unreachable Destination IP Address field.
The RERR message is sent whenever a link break causes one or more
destinations to become unreachable from some of the node's neighbors.
6.4. Route Reply Acknowledgment (RREP-ACK) Message Format
Type Reserved
Type 4
This section describes the scenarios under which nodes generate Route
Request (RREQ), Route Reply (RREP) and Route Error (RERR) messages
for unicast communication towards a destination, and how the message data
are handled. In order to process the messages correctly, certain state
information has to be maintained in the route table entries for the destinations
of interest.
In order to ascertain that information about a destination is not stale, the node
compares its current numerical value for the sequence number with that
obtained from the incoming AODV message. This comparison is done using
signed 32-bit arithmetic, this is necessary to accomplish sequence number
rollover. If the result of subtracting the currently stored sequence number
from the value of the incoming sequence number is less than zero, then the
information related to that destination in the AODV message is discarded,
since that information is stale compared to the node's currently stored
information.
The only other circumstance in which a node may change the destination
sequence number in one of its route table entries is in response to a lost or
expired link to the next hop towards that destination. The node determines
which destinations use a particular next hop by consulting its routing table.
In this case, for each destination that uses the next hop, the node increments
the sequence number and marks the route as invalid. Whenever any fresh
enough (i.e., containing a sequence number at least equal to the recorded
sequence number) routing information for an affected destination is received
by a node that has marked that route table entry as invalid, the node updates
its route table information according to the information contained in the
update.
A node may change the sequence number in the routing table entry of a
destination only if :
(ii) The sequence numbers are equal, but the hop count (of the new
information) plus one, is smaller than the existing hop count in the
routing table, or
The Lifetime field of the routing table entry is either determined from the
control packet, or it is initialized to ACTIVE_ROUTE_TIMEOUT. This
route may now be used to send any queued data packets and fulfills any
outstanding route requests. Each time a route is used to forward a data packet,
its Active Route Lifetime field of the source, destination and the next hop on
the path to the destination is updated to be no less than the current time plus
ACTIVE_ROUTE_TIMEOUT. Since the route between each originator and
destination pair is expected to be symmetric, the Active Route Lifetime for
the previous hop, along the reverse path back to the IP source, is also updated
to be no less than the current time plus ACTIVE_ROUTE_TIMEOUT. The
lifetime for an Active Route is updated each time the route is used regardless
of whether the destination is a single node or a subnet.
For each valid route maintained by a node as a routing table entry, the node
also maintains a list of precursors that may be forwarding packets on this
route. These precursors will receive notifications from the node in the event
of detection of the loss of the next hop link. The list of precursors in a
routing table entry contains those neighboring nodes to which a route reply
was generated or forwarded.
Before broadcasting the RREQ, the originating node buffers the RREQ ID
and the Originator IP address (its own address) of the RREQ for
PATH_DISCOVERY_TIME. In this way, when the node receives the packet
again from its neighbors, it will not reprocess and re-forward the packet.
Data packets waiting for a route (i.e., waiting for a RREP after a RREQ has
been sent) SHOULD be buffered. The buffering is done in "first-in, first-
out" (FIFO) manner. If a route discovery has been attempted
RREQ_RETRIES times at the maximum TTL without receiving any RREP,
all data packets destined for the corresponding destination is dropped from
the buffer and a Destination Unreachable message is delivered to the
application.
The Hop Count stored in an invalid routing table entry indicates the last
known hop count to that destination in the routing table. When a new route
to the same destination is required at a later time (e.g., upon route loss), the
TTL in the RREQ IP header is initially set to the Hop Count plus
TTL_INCREMENT. Thereafter, following each timeout the TTL is
incremented by TTL_INCREMENT until TTL = TTL_THRESHOLD.
Beyond this TTL = NET_DIAMETER is used. Once TTL =
NET_DIAMETER, the timeout for waiting for the RREP is set to
NET_TRAVERSAL_TIME.
7.5 Processing and Forwarding Route Requests
When a node receives a RREQ, it first creates or updates a route to the
previous hop without a valid sequence number then checks to determine
whether it has received a RREQ with the same Originator IP Address and
RREQ ID within at least the last PATH_DISCOVERY_TIME. If such a
RREQ has been received, the node silently discards the newly received
RREQ, else it first increments the hop count value in the RREQ by one, to
account for the new hop through the intermediate node.
Then the node searches for a reverse route to the Originator IP Address,
using longest-prefix matching. If need be, the route is created, or updated
using the Originator Sequence Number from the RREQ in its routing table.
This reverse route will be needed if the node receives a RREP back to the
node that originated the RREQ. When the reverse route is created or updated,
the following actions on the route are also carried out:
3. Tthe next hop in the routing table becomes the node from which the
RREQ was received.
4. The hop count is copied from the Hop Count in the RREQ message.
The current node can use the reverse route to forward data packets in the
same way as for any other route in the routing table.
If a node does not generate a RREP, and if the incoming IP header has TTL
larger than 1, the node updates and broadcasts the RREQ to address
255.255.255.255 on each of its configured interfaces. To update the RREQ,
the TTL or hop limit field in the outgoing IP header is decreased by one, and
the Hop Count field in the RREQ message is incremented by one, to account
for the new hop through the intermediate node. Lastly, the Destination
Sequence number for the requested destination is set to the maximum of the
corresponding value received in the RREQ message, and the destination
sequence value currently maintained by the node for the requested
destination.
However, the forwarding node mustn’t modify its maintained value for the
destination sequence number, even if the value received in the incoming
RREQ is larger than the value currently maintained by the forwarding node.
Otherwise, if a node does generate a RREP, then the node discards the
RREQ.
Once created, the RREP is unicast to the next hop toward the originator of the
RREQ, as indicated by the route table entry for that originator. As the RREP
is forwarded back towards the node which originated the RREQ message, the
Hop Count field is incremented by one at each hop. Thus, when the RREP
reaches the originator, the Hop Count represents the distance, in hops, of the
destination from the originator.
After a node receives a RREQ and responds with a RREP, it discards the
RREQ. If the RREQ has the 'G' flag set, and the intermediate node returns a
RREP to the originating node, it must also unicast a gratuitous RREP to the
destination node. The gratuitous RREP that is to be sent to the desired
destination contains the following values in the RREP message fields :
Hop Count : The Hop Count as indicated in the node's route table entry for
the originator.
Lifetime : The remaining lifetime of the route towards the originator of the
RREQ, as known by the intermediate node.
The gratuitous RREP is then sent to the next hop along the path to the
destination node, just as if the destination node had already issued a RREQ
for the originating node and this RREP was produced in response to that
(fictitious) RREQ. The RREP that is sent to the originator of the RREQ is
the same whether or not the 'G' bit is set.
(iii) the sequence numbers are the same, but the route is marked as
inactive.
(iv) the sequence numbers are the same, and the New Hop Count is
smaller than the hop count in route table entry.
If the route table entry to the destination is created or updated, then the
following actions occur:
- the next hop in the route entry is assigned to be the node from which the
RREP is received, which is indicated by the source IP address field in the IP
header,
- the hop count is set to the value of the New Hop Count,
- the expiry time is set to the current time plus the value of the Lifetime in
the RREP message,
The current node can subsequently use this route to forward data packets to
the destination. If the current node is not the node indicated by the Originator
IP Address in the RREP message and a forward route has been created or
updated as described above, the node consults its route table entry for the
originating node to determine the next hop for the RREP packet, and then
forwards the RREP towards the originator using the information in that route
table entry. If a node forwards a RREP over a link that is likely to have errors
or be unidirectional, the node sets the 'A' flag to require that the recipient of
the RREP acknowledge receipt of the RREP by sending a RREP-ACK
message back.
When any node transmits a RREP, the precursor list for the corresponding
destination node is updated by adding to it the next hop node to which the
RREP is forwarded. Also, at each node the (reverse) route used to forward a
RREP has its lifetime changed to the maximum of (existing-lifetime, (current
time + ACTIVE_ROUTE_TIMEOUT)).
Finally, the precursor list for the next hop towards the destination is updated
to contain the next hop towards the source.
Any suitable link layer notification, such as those provided by IEEE 802.11,
can be used to determine connectivity, each time a packet is transmitted to an
active next hop. For example, absence of a link layer ACK or failure to get a
CTS after sending RTS, even after the maximum number of retransmission
attempts, indicates loss of the link to this active next hop.
* Receiving any packet (including a Hello message) from the next hop.
* A RREQ unicast to the next hop, asking for a route to the next hop.
* An ICMP Echo Request message unicast to the next hop.
If a link to the next hop cannot be detected by any of these methods, the
forwarding node should assume that the link is lost, and take corrective action
by following the methods
A Route Error (RERR) message MAY be either broadcast (if there are many
precursors), unicast (if there is only 1 precursor), or iteratively unicast to all
precursors (if broadcast is inappropriate). Even when the RERR message is
iteratively unicast to several precursors, it is considered to be a single control
message for the purposes of the description in the text that follows. With
that understanding, a node shouldn’t generate more than
RERR_RATELIMIT RERR messages per second.
(i) if it detects a link break for the next hop of an active route in its
routing table while transmitting data.
(ii) if it gets a data packet destined to a node for which it does not have
an active route and is not repairing (if using local repair), or
(iii) if it receives a RERR from a neighbor for one or more active routes.
For case (i), the node first makes a list of unreachable destinations consisting
of the unreachable neighbor and purges all these routes.
The neighboring node(s) that should receive the RERR are all those that
belong to a precursor list of at least one of the unreachable destination(s) in
the newly created RERR. In case there is only one unique neighbor that
needs to receive the RERR, the RERR should be unicast toward that
neighbor. Otherwise the RERR is typically sent to the local broadcast
address (Destination IP = 255.255.255.255, TTL= 1) with the unreachable
destinations, and their corresponding destination sequence numbers, included
in the packet. The DestCount field of the RERR packet indicates the number
of unreachable destinations included in the packet.
Just before transmitting the RERR, certain updates are made on the routing
table that may affect the destination sequence numbers for the unreachable
destinations. For each one of these destinations, the corresponding routing
table entry is updated as follows:
Note that the Lifetime field in the routing table plays dual role for an active
route it is the expiry time, and for an invalid route it is the deletion time. If a
data packet is received for an invalid route, the Lifetime field is updated to
current time plus DELETE_PERIOD
7.10 Local Repair
When a link break in an active route occurs, the node upstream of that break
may choose to repair the link locally if the destination was no farther than
MAX_REPAIR_TTL hops away. To repair the link break, the node
increments the sequence number for the destination and then broadcasts a
RREQ for that destination. The TTL of the RREQ should initially be set to
max(MIN_REPAIR_TTL, 0.5 * #hops) + LOCAL_ADD_TTL.
On the other hand, if the node receives one or more RREPs (or other
control message creating or updating the route to the desired destination)
during the discovery period, If the hop count of the newly determined route
to the destination is greater than the hop count of the previously known route
the node will issue a RERR message for the destination, and the originating
node may choose to reinitiate route discovery.
Local repair of link breaks in routes may sometime result in increased path
lengths to those destinations. Repairing the link locally is likely to increase
the number of data packets that are able to be delivered to the destinations,
since data packets will not be dropped as the RERR travels to the originating
node.
Sending a RERR to the originating node after locally repairing the link break
may allow the originator to find a fresh route to the destination that is better,
based on current node positions. However, it does not require the
originating node to rebuild the route, as the originator may be done, or nearly
done, with the data session.
When a link breaks along an active route, there are often multiple
destinations that become unreachable, if same node is participating in more
then one connection. The node that is upstream of the lost link will try an
immediate local repair for only the one destination towards which the data
packet was traveling. Other routes using the same link will be marked as
invalid, but as the timeout occurs, these other routes will be repaired as
needed when packets arrive for the other destinations. Hence, these routes
are repaired as needed. If a data packet does not arrive for the route, then that
route will not be repaired.
8 Simulation model
In this paper we focus on Constant Bit Rate (CBR) sources (i.e voice sources)
and ftp sources (i.e file transfer). The packet size is limited to 512 bytes. The
source-destination pairs are chosen randomly over the network. The source-
destination numbers are fixed (called connection number). We make the
offered load vary by using scenarios with 10,20,30,40 and 50 connections.
Each source-destination pair begins packet sending at a chosen time and
keeps sending between 40 and 80s for CBR sources and between 5 and 20 for
ftp sources.
Packet delivery ratio :The ratio of the data packets delivered to the
destination to those generated by CBR or ftp sources.