1 / 13

aodv

aodv. Distance vector routing. Belman principle. AODV - overview. Similar to DSR On demand Route request when needed and route reply when a node knows how to get to the desired destination

ismet
Download Presentation

aodv

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. aodv

  2. Distance vector routing • Belman principle

  3. AODV - overview • Similar to DSR • On demand • Route request when needed and route reply when a node knows how to get to the desired destination • However, paths are not included in the packet header. Rather, nodes maintain a table with each destination is knows about and the next hop and the number of hops to go

  4. basics • Basics • When a route search is propagated, the receiver of each packet records the transmitter and the source -> this is put into a table • If there is a table entry to the desire destination, then a route reply is generated. • The route reply is sent back to the source. Each node along the way learns about the route to the destination and the next hop • There is a problem with keeping the tables up-to-date • If a route fails, then many tables may be incorrect. • When a new route search is performed, node might believe that they have a route, but they do not. • In path based, this problem can easily be solved since the link failure is known and can in fact be included in the route search. (piggy-backed route error) • As will be seen, in aodv, and distance vector in general, the only solution is to invalidate all routes found up to now, since it is not known if these routes use the ill-fated link • A route search will have a destination sequence number • The destination determines the seq number and the sources try to keep it correct. • When a dest replies with a route reply, it include the dest seq num. • Intermediate nodes record this value • When a route fails, then the new route is found, but with a larger dest seq num • Nodes only with large enough dest seq num can provide route replies

  5. AODV sequence number • The sequence number is used as a way to deal with failed routes/links. It does not shared the benefits of the approach used by DSR (I.e., including the known broken links in RREQ) • Each nodes keeps a destination seq, num. T • The seq num is only incremented. • The larger the seq num, the newer the route info to the dest. • Any routing info that has a higher seq num both over rides the old routing info and invalidates the old route info • E.g., if a node has a route to a node and then a RREQ arrives with a higher seq num, then the old route is no longer valid • Here we see the inability of AODV to precisely specified which link has broken and hence its inability to make use of topology that has been previously explored (ie., explored with a smaller seq num) • Adjusting the seq num • When a dest offers a new route it either increments it current seq num or uses the seq found in the RREQ, which ever is greater • When a node receives a message with routing info that has a higher seq num, then the node will take this new/higher value • If a node learns that the path to the dest breaks, then a node will increments the seq num (to invalidate all old top info) • If no seq num for the dest is known, then it is set to unknown

  6. Routing table • When a node receives a route message (e.g., RREQ or Rreply), if no route currently exists a new entry is made • If an entry already exists, it is updated only if • the message has a higher seq num than this one is used in the entry • The seq num is the same, but the path (hops) is smaller • The current seq num is unknown (e.g., the entry was just made) • Entry timeout • An entry will time out • Every time a packet traverse the route, the lifetime is extended • At the saem time, the reverse path lifetime is also updated • Each entry also includes a list of precursors • A node is a precursor if there is an active path that goes to from the node to the dest. • When a link fails, then the list of precursors can be notified and so on…

  7. Generating Route request • If a route is needed, e.g., if the current one timed out or the path has been found to have broken • The last known seq num is put into the RREQ. • If none is known, then the dest seq num is marked as invalid • Note, the dest seq num is incremented when a link failure has been detected or timeouts • The sender/orginating node includes is own seq num • The num is incremented just before being put inot the RREQ • This seq num is then used by all neighbor nodes to update their cost… • This also acts to update the current path lifetime • However, if the routing follows a funny path, this may result in increasing the hop count to the dest and perhaps could break some paths???

  8. Processing route request • The route to the previous hop is updated/created. • Next, it is checked if this RREQ has been previously observed, if so, the RREQ is dropped • This means that not even the return path is updated, so if a return path includes this node, it too has been updated. • However, downstream nodes (toward the dest) are not aware of this better path. Hence, not all paths are explored. • On the other hand, shorter/better routes should be traversed sooner. But if a better route means one that will last longer, or has good power properties, then this approach will not work. It only makes sense if the metric is delay. • Compare this to real distance vector and belman • When a RREQ is received the return/reverse path entry is saved and perhaps updated . specifically • The seq number is updated (if it is larger) • The seq num is set to valid • The next hop is set to the sender of the RREQ (previous hop) • The hop count is set • The lifetime is set to be the max of the existing lifetime and currenttime+2*net_traversal_time – 2 * hopCount*Link_traversal_time) • If the TTL is zero or if a RREP is generated, the RREQ is dropped. • Note that if a RREP is generated, the dest may never receive a RREQ and hence never build a return route to the source (!!). In this case the dest will have to perform route discovery. • But the dest could observe the source of the packet and form a route accordingly. But this is not done. It is rather odd that no such route forming is done. For example, a table entry could also be formed by overhearing packets, but.. • To solve the problme with the dest, the Gratuitous flag is set. In this case, if a RREP is generated, then a gratuitous RREP packet is sent over the known path to the dest,

  9. Generating route reply (RREP) • If the node is the dest. Or if the node has a active route with seq num that is greater or equal to the seq num in the RREQ • If the node is the dest. • If the seq num is the same as the seq num in the RREQ, then the node increments its seq num and puts that into the RREP, otherwise, it puts the current seq num in the RREP • If the node is an intermediate node • It leaves the seq num unchanged • The pervious hop is placed in the precursor list for the dest • The route to the source is updated by placing the next hop toward the dest as a precursor for the route to the source. • On both cases, the hop count is set…

  10. Processing a RREP • Upon receiving a RREP, a table entry is made/updated to the previous hop (the sender of the RREP), but the seq num marked as invalid if the entry is created. • The hop count in the RREP is incremented • The table entry to the dest is updated only if • The seq num in the table is marked as invalid • The seq num in the RREP is valid and is greater that the entry’s • The seq num are the same but the route is marked as inactive • The seq num are the same but the hop count is smaller • If the entry is updated/created • The rotue is makered as active • The seq num is marked as valid • The next hop is set to the sender of the RREP • The hop count is set • The expiry time is set from the RREP • The dest seq num is the same as in the RREP • The RREP is forwarded upstream • The precursor lists are updated

  11. Route error, route expiry, and route deletion • Basic idea: When a link breaks • The routes that use the link are invalidated • The destination that are impacted are determined • The affected upstream neighbors are determined • The upstream neighbors are informed of the breakage via a RERR (either via unicast or b-cast) • This continues until the sources are reached • Hence, a RERR is generated when • A transmission fails and hence a link break is detected and further that the route repair fails • If a data packet arrives for a dest for which the node does not have a route and a route repair is not ongoing (I.e., the route had already broken or had already timeout) (note: there is a limit to the rate at which RERR packets can be generated – if a burst of packets arrive, then the a burst of route error messages might not be generated. • If a RERR message arrives from a downstream node for an active route. • Before a RERR is transmitted • The seq num for the dest in the table entry is incremented, unless the RERR comes from a downstream node, in which case the seq num in the RERR packet is used • The entry is marked as invalid • The lifetime of the entry is set to the DELETE_PERIOD. The entry is not deleted before this time. • The idea of delete period is that you don’t want a data packet to arrive with a dest that is not in the routing table. • So the delete period is at least as large as the active_route_timeout. Thus, when the route is finally deleted, the upstream nodes will have marked the route as invalid. • Note that if a data packet arrives for an invalid route, then the lifetime is reset to the DELETE_PERIOD.

  12. Local repair • When a link break is detected, the upstream node may try to repair the link if the destination is less than MAX_REPAIR_TTL hops away. • The TTL of the route search is • max(hops to dest, 0.5*Num hops to the source) + Local_ADD_TTL • The idea is that the route search will try not to reach the source • During route search, packets are buffered • If no route is found, then a RERR is generated and any buffered packets are dropped • If a new route is found, then the buffered packets are sent over this new route • If the new route has a hop count that is longer than the old, now broken route • A RERR is generated with the N bit set. • A node receiving a RERR with the N bit set does not delete the entry but merely forwards the RERR packet upstream • When a source receives a RERR with the N bit set, it MAY begin a new route search

  13. Link break cont. • When a link breaks, routes are marked as invalid. • These route may be repaired when a packet arrives for these routes. To support this, these routes are marked as repairable • If a route is marked as repairable, it remains so until it times out

More Related