Date post: | 18-Jan-2018 |
Category: |
Documents |
Upload: | christian-holmes |
View: | 226 times |
Download: | 0 times |
If you can't read please download the document
Ad Hoc On-Demand Distance Vector Routing (AODV) http://www. ietf
Use protocol to discover the path (routing)
Ad-hoc Solutions Use existing computers to act as routers Use
protocol to discover the path (routing) Traditional routing
algorithms no longer work well Proactive Reactive Protocol Classes
Ready to go Whole topology
On-demand Little maintenance Cell operations Ready to go Whole
topology Updates changes Overhead costs Bandwidth Battery power
Inflexible AODV Overview AODV is a packet routing protocol designed
for use in mobile ad hoc networks (MANET) Intended for networks
that may contain thousands of nodes One of a class of demand-driven
protocols The route discovery mechanism is invoked only if a route
to a destination is not known *As a routing protocol for mobile ad
hoc networks, AODV is intended to accommodate networks that are as
large as several thousand nodes. *It is one of several
demand-driven (or on-demand) protocols that are in existence today.
Hence, the protocol is invoked only when a node (host) has data to
transmit. It is a reactive protocol. *The AODV RFC indicates that
the transport layer protocol is UDP, which of course only offers
best effort delivery of packets, and does not support either error
recovery or flow control. *Addressing is handled using IP
addressing *Since each node acts as both a host and routing node,
each must maintain a routing table that contains information about
known destination nodes. Entries are keyed to destinations. Ad-hoc
On-demand Distance Vector (AODV)
Charles E. Perkins, 1999 Reactive protocol Fast discovery Loop free
On-demand Unicast Route Establishment
Unicast route is a route from a source node to a destination node.
this protocols uses two types of messages, route request (RREQ) and
route reply (RREP). we use sequence numbers to keep track of recent
routes. Every time a node sends a new message, it uses a new
sequence number which increases monotonically. AODV Routing There
are two phases Route Discovery. Route Maintenance.
Each node maintains a routing table with knowledge about the
network. AODV deals with route table management. Route information
maintained even for short lived routes reverse pointers. AODV Route
Discovery Destination Starting Point AODV Route Discovery AODV
Route Discovery AODV Route Discovery AODV Route Discovery AODV
Route Discovery AODV Route Discovery AODV Route Discovery AODV
Route Maintenance AODV Route Maintenance
Broken Link in Route AODV Route Maintenance Overview (continued)
The basic message set consists of:
RREQ Route request RREP Route reply RERR Route error HELLO For link
status monitoring The basic message set includes a route request
message, route reply message, route error message, and a hello
message. The mechanics of each of these messages will be covered in
detail later in the presentation. Briefly, however, a host (node)
multicasts a RREQ message when it needs to find a route to a
destination (either not already contained in its routing table, or
one whose status is invalid). AODV Operation Message Types
RREQ Messages While communication routes between nodes are valid,
AODV does not play any role. A RREQ message is broadcasted when a
node needs to discover a route to a destination. As a RREQ
propagates through the network, intermediate nodes use it to update
their routing tables (in the direction of the source node). The
RREQ also contains the most recent sequence number for the
destination. A valid destination route must have a sequence number
at least as great as that contained in the RREQ. Route Request
(RREQ) Message Format A B? B? B? B? B? B? B? B RREQ Message
Make sure you explain how an intermediate node distinguishes
between copies of the same RREQ. In your graph, the node in the
middle receives two copies of the RREQ. In this case, the hop count
from the source (A) is the same, so it doesnt matter how its own
routing back to A is updated. If you look at the example graph I
included in the overview, you see that node B and the destination
node F both receive multiple copies of the RREQ. In both cases,
each copy followed a different route to get to the respective node.
Therefore, B and F must choose the correct version of the message
to use for updating their own routing tables and also for
forwarding. The hop count field is the key that allows them to
decide which message to keep and which message to throw away. B? B?
B AODV Operation Message Types
RREP Messages When a RREQ reaches a destination node, the
destination route is made available by unicasting a RREP back to
the source route. A node generates a RREP if: It is itself the
destination. It has an active route to the destination. Ex: an
intermediate node may also respond with an RREP if it has a fresh
enough route to the destination. As the RREP propagates back to the
source node, intermediate nodes update their routing tables (in the
direction of the destination node). You should point out that the
RREQ/RREP mechanism depends on the assumption that links are
symmetrical, or bidirectional. Route Reply (RREP) Message Format
RREP Message A A A A A A A B Route Error (RERR) Message Types
RERR Messages This message is broadcast for broken links Generated
directly by a node or passed on when received from another node
Route Error (RERR) Message Format AODV Operation Message
Types
Hello Messages Hello Message = RREP with TTL = 1 This message is
used for broadcasting connectivity information. Ex: If a neighbor
node does not receive any packets (Hello messages or otherwise) for
more than ALLOWED_HELLO_LOSS * HELLO_INTERVAL mseconds, the node
will assume that the link to this neighbor is currently lost. A
node should use Hello messages only if it is part of an active
route. Unicasting Point-to-point transmission from one device to
another. Most transmissions (where one user connects with one
source or other user at a time) is unicast. A source node wants to
send a message to a destination node. Multicasting However, in many
situations a node wants to send a message to a group of nodes in
the network. This is called multicasting and the group is called a
multicast group. Broadcasting Broadcasting is a special case of
multicasting when all the nodes in the network is in the multicast
group. Route Request (RREQ) Message
When node S wants to send a message to node D, S searches its route
table for a route to D. If there is no route, S initiates a RREQ
message with the following components : The IP addresses of S and D
The current sequence number of S and the last known sequence number
of D A broadcast ID from S. This broadcast ID is incremented each
time S sends a RREQ message. Processing a RREQ Message (I)
The pair of the source S forms a unique identifier for the RREQ.
Suppose a node P receives the RREQ from S. P first checks whether
it has received this RREQ before. Each node stores the pairs for
all the recent RREQs it has received. Processing a RREQ Message
(II)
D P Q If P has seen this RREQ from S already, P discards the RREQ.
Otherwise, P processes the RREQ : P sets up a reverse route entry
in its route table for the source S. This entry contains the IP
address and current sequence number of S,number of hops to S and
the address of the neighbour from whom P got the RREQ. Lifetime of
a Route-Table Entry
A lifetime is associated with the entry in the route table. This is
an important feature of AODV. If a route entry is not used within
the specified lifetime, it is deleted. A route is maintained only
when it is used. A route that is unused for a long time is assumed
to be stale. Route Requests in AODV Y Z S E F B C M L J A G H D K I
N
Represents a node that has received RREQ for D from S Broadcast
transmission
Route Requests in AODV Y Broadcast transmission Z S E F B C M L J A
G H D K I N Represents transmission of RREQ Route Requests in AODV
Y Z S E F B C M L J A G H D K I N
Represents links on Reverse Path Reverse Path Setup in AODV
Y Z S E F B C M L J A G H D K I N Node C receives RREQ from G and
H, but does not forward it again, because node C has already
forwarded RREQ once Reverse Path Setup in AODV
Y Z S E F B C M L J A G H D K I N Reverse Path Setup in AODV
Y Z S E F B C M L J A G H D K I N Node D does not forward RREQ,
because node D is the intended target of the RREQ Forward Path
Setup in AODV
Y Z S E F B C M L J A G H D K I N Forward links are setup when RREP
travels along the reverse path Represents a link on the forward
path Handling More than one RREP
An intermediate node P may receive more than one RREP for the same
RREQ. P forwards the first RREP it receives and forwards a second
RREP later only if : The later RREP contains a greater sequence
number for the destination, or The hop-count to the destination is
smaller in the later RREP Otherwise, it does not forward the later
RREPs. This reduces the number of RREPs propagating towards the
source. Route Maintenance Once a unicast route has been established
between two nodes S and D, it is maintained as long as S (source
node) needs the route. If S moves during an active session, it can
reinitiate route discovery to establish a new route to D. When D or
an intermediate node moves, a route error (RERR) message is sent to
S. Route Maintenance 1 2 3 S D RERR 3
The link from node 3 to D is broken as 3 has moved away to a
position 3. Node 2 sends a RERR message to 1 and 1 sends the
message in turn to S. S initiates a route discovery if it still
needs the route to D. Updating Route Tables 1 2 3 S D RERR 3 4
5
Suppose neighbours 4 and 5 route through 2 to reach D. Node 2
broadcasts RERR to all such neighbours. Each neighbour marks its
route table entry to D as invalid by setting the distance to
infinity. Updating Route Tables 1 2 3 S D RERR 3 4 5
Each neighbour in turn propagates the RERR message. Route entries
with an infinity metric are not rejected immediately as they
contain useful routing information for the neighbourhood. Local
Connectivity Neighbourhood information is obtained through hello
messages. Each node broadcasts a hello message to its neighbours at
a regular hello-interval. When a node M receives a hello message
from a neighbour N, node M updates the lifetime associated with N
in its route table. Hello messages propagate only for one hop, in
the neighbourhood of a node. Performance of AODV AODV does not
retransmit data packets that are lost and hence does not guarantee
packet delivery. However, the packet delivery percentage is close
to 100 with relatively small number of nodes. The packet delivery
percentage drops with increased moility. Control Overheads The
overhead packets in AODV are due to RREQ, RREP and RERR messages.
AODVneeds much less number of overhead packets compared to DSDV.
The number of overhead packets increases with increased mobility,
since this gives rise to frequent link breaks and route discovery.
Latency in Route Discovery
The route discovery latency in AODV is low compared to DSR and
DSDV. The latency is almost constant even with increased mobility
if the concentration of the nodes remain similar. The average path
length for discovered routes is also quite low. AODV: Summary
Routes need not be included in packet headers
Nodes maintain routing tables containing entries only for routes
that are in active use At most one next-hop per destination
maintained at each node DSR may maintain several routes for a
single destination Sequence numbers are used to avoid old/broken
routes Sequence numbers prevent formation of routing loops Unused
routes expire even if topology does not change