1 / 38

Dsr – dynamics source routing

Dsr – dynamics source routing. basics. Two types of routing On-demand / reactive Information is only collected when required, I.e., when a packet needs to be sent and there is no current/valid route Proactive Routing information is stored and collected even if a route is not needed

trula
Download Presentation

Dsr – dynamics source routing

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. Dsr – dynamics source routing

  2. basics Two types of routing On-demand / reactive Information is only collected when required, I.e., when a packet needs to be sent and there is no current/valid route Proactive Routing information is stored and collected even if a route is not needed On-demand has less overhead (sometimes) but is often slower to begin data delivery Proactive may require extensive overhead DSR uses two mechanisms Route discovery Route request Route reply Route maintenance Route Cache – locally stored routes Packets carry the entire path (Source Routing)

  3. DSR (Rough Sketch) D S Initially, nodes do not have any topology information and hence no routes Suppose that the application gives S’s OS a packet to send to D. S must find a route to D

  4. DSR (Rough Sketch)RREQ D S RREQ RREQ: S is looking for a path to D, seqno=1

  5. DSR (Rough Sketch) RREQ RREQ A D S RREQ: S is looking for a path to D, seqno=1 • A: • 0. Receive RREQ • Record that A can reach S in one hop • Process RREQ • Is S looking for A? No • Does A have a path to D? No • Forward RREQ

  6. DSR (Rough Sketch) RREQ RREQ A D S The RREQ has been extended, so that the path from S to A is appended to the RREQ RREQ: S is looking for a path to D, seqno=1; link: A,S

  7. DSR (Rough Sketch) RREQ RREQ A B D S The RREQ has been extended, so that the path from S to A is appended to the RREQ RREQ: S is looking for a path to D, seqno=1; link: A,S • B: • 0. Receive RREQ • Record that B and A are neighbors, and that S and A are neighbors • Process RREQ • Is S looking for B? No • Does B have a path to D? No • Forward RREQ

  8. DSR (Rough Sketch) RREQ RREQ A B D S The RREQ has been extended, so that the path from S to C is appended to the RREQ RREQ: S is looking for a path to D, seqno=1; links: A,S; B,A

  9. DSR (Rough Sketch) RREQ RREQ A B C D S RREQ: S is looking for a path to D, seqno=1; links: A,S; B,A; C,B • D: • 0. Receive RREQ • Record that S and A, A and B, B and C, and C and D are neighbors • Process RREQ • Is S looking for Y? Yes. Send RREP back to S

  10. DSR (Rough Sketch)RREP RREP A B C D S RREP: Send pkt along path D, C, B, A, S. • S: • 0. Receive RREP • Record path S,A,B,C,D • Send data packets with destination D along path {S,A,B,C,D} This is called reverse path forwarding. Reverse path forwarding is good in that if links are bidirectional, then the path always exists Reverse path forwarding is not so good because the reverse path might not be “low quality.”

  11. DSR (Rough Sketch)Packet Forwarding Data A B C D S Data: Send pkt along path S, A, B, C, D

  12. DSR – Path Break Data A B C D S Data: Send pkt along path S, A, B, C, D

  13. DSR (Rough Sketch)Path Break RERR A B C D S • B detects that the link with C has broken • B sends a RERR message to S. RERR: from B to S. The link from B to C has broken

  14. DSR (Rough Sketch)Path Break RREQ A B C D S • S repeats the route search processes • RREQ: S is looking for a path to D. By the way, the link between B and C has broken

  15. DSR (Rough Sketch)Topology Cache A B C D S • Since wireless communications are broadcasted, nodes can receive packets even if they are not the destination of the packet • RREQ, RREP, RERR, and Data packet all include topology information. This information can be used to determine routes

  16. RREQ RREQ RREQ A A A B D D D S S S Learns: It is a neighbor of A, B, and C, and path {S,A,B,C,D} RREQ A B C D S DSR (Rough Sketch)Topology Cache

  17. Knows: It is a neighbor of A, B, and C, and path {S,A,B,C,D} DSR (Rough Sketch)Topology Cache RREQ A B C D S

  18. Knows: It is a neighbor of A, B, and C, and path {S,A,B,C,D} DSR (Rough Sketch)Topology Cache A B C D S RREQ E • E: • 0. Receive RREQ • E knows a route to D without link B<->C • Generate RREP

  19. Knows: It is a neighbor of A, B, and C, and path {S,A,B,C,D} DSR (Rough Sketch)Topology Cache A B C D S RREP E • E: • 0. Receive RREQ • E knows a route to D without link B<->C • Generate RREP

  20. DSR Details and Design Issues • Flooding RREQ - Flooding Storms • Each RREQ has a sequence number, so nodes do not forward the same RREQ twice • In dense networks, broadcasts can collide • Broadcast delay: Each node selects a random delay before broadcasting a RREQ (how long should this delay be when there are N neighbors?) • In dense networks, not all nodes need to broadcast the message. Which ones should? Efficient flooding • Counter-based • During the random delay, a node records how many copies of the message it has received. • If, at the end of the delay, the number of copies received is below a threshold, then the message is broadcasted • maxC=5.*(degrees<=5)+4.*(degrees>=6 & degrees<=8)+3.*(degrees>=9 & degrees<=11)+2.*(degrees>=12); • Local topology methods • Use neighbor discovery methods to learn the local topology. Based on the local topology, nodes select which nodes should forward the message. • The MANET routing protocol OLSR uses this technique. (We’ll see it later)

  21. DSR Details and Design Issues • Topology Cache • Should the cache timeout? That is, if some link information has been in the cache for a long time without any evidence that the link is still up, should it be removed? • More basic question: what to do if a RREQ yields a route that does not work? Answer: Repeat the RREQ, but perhaps without cache (so the RREQ must reach the destination • Trade-off: if the cache is stale, then RREQ floods are wasted. If cache is time-out too early, then RREQ are performed unnecessarily.

  22. DSR Details and Design Issues • How to detect link breaks? • Perhaps all nodes periodically sends hello messages, and B stops getting hello messages from C • Perhaps whenever C gets a pkt from B, it sends an ACK • Note, that 802.11 also sends ACKs. Why not use 802.11 ACKs? • The network layer should be independent of the MAC/PHY, so it cannot count on ACKs • While 802.11 does receive ACKs, the drivers do not provide information as to which packets were ACKed • What is a link? • Occasional pkt losses are expected. • It is very difficult to determine whether a packet loss is because communication over the link is no longer possible or that communication will soon be possible

  23. DSR Details and Design Issues • Reverse path forwarding • Reverse paths usually exist, but their quality might be bad. • In fact, the quality is typically bad. S D If there are enough nodes in this clump, then it is very likely that one will be able to decode the RREQ

  24. DSR Details and Design Issues • Reverse path forwarding • Reverse paths usually exist, but their quality might be bad. • In fact, the quality is typically bad. S D If there are enough nodes in this clump, then it is very likely that one will be able to decode the RREQ If there are enough nodes in this clump, then it is very likely that one will be able to decode the RREQ

  25. DSR Details and Design Issues • Reverse path forwarding • Reverse paths usually exist, but their quality might be bad. • In fact, the quality is typically bad. S D If there are enough nodes in this clump, then it is very likely that one will be able to decode the RREQ If there are enough nodes in this clump, then it is very likely that one will be able to decode the RREQ

  26. DSR Details and Design Issues • Reverse path forwarding • Reverse paths usually exist, but their quality might be bad. • In fact, the quality is typically bad. S D But this is a very bad route • Alternatively, • Each RREQ contains some link quality information • But then, RREQ need to be forwarded multiple times (each time a better route is found) • The random delay before forwarding the RREQ depends on the route quality, with bad routes only being forwarded after a long delay and good routes after a short delay.

  27. DSR Details and Design Issues • Packet salvaging • If a link is broken, then a RERR is sent to source, but if an alternative route is available, then the current pkt is sent over that route • Path shortening • If a node learns that it can reach some other node along the path in fewer hops, then that node sends a RREP to the source. • Source Path Routing • Generally, source path routing is difficult because if any link alogn the way breaks, the path is broken. • There is no good way to use information that intermediate nodes might have. • Other methods, such as AODV, can make use of information available to intermediate nodes

  28. Route request • When a packet has a destination that is not within the route cache, a route discovery is initiated. • To this end: a route request (REEQ) packet is transmitted • The RREQ contains: • The source, the desire destination and request ID • It also contains a list of the nodes visited so far • The RREQ is broadcasted • When a node receives a RREQ, if it is the desired destination, then it replies with a route reply • When a route request is received • Record that this request was received and check if it was already received, if so, then drop the request. The request id is the request id and the source address • Copy the path within the packet into the cache • Append this nodes address onto the path • Search local route cache for a route to the destination • If a route is not found in the route cache, then update path in the packet and broadcast the packet

  29. Route request continued • The RREQ include a TTL – the number of hops for the search • Every time the RREQ is forwarded, the TTL is decremented • If TTL =0, then the packet is dropped • If a route reply does not arrive after a specified time, then a new search is initiated • The source seq number is incremented (changed) • The TO is at least doubled if the initial TTL is unchanged • Why would TTL be unchanged / why would it be smaller/larger? • The rate at which a route search is initiated is limited - an application cannot ask for too many routes to a particular host (but what about a DoS route request to different addresses?)

  30. Route Reply • If the desire destination receives a route request and the dest has never seen this request before, it returns a route reply. • Thus, no route selection occurs, the first packet to reach is used. • In the typical case that the links are bidirectional, then the reply is sent along the reverse path. • If links are not bidirectional (when can this happen), a new route search must be performed. • Of course, the found route is carried in the new route request. This way, the source has a way to inform the dest that route has been found • The dest must ensure that there are no loops in the route • The Salvage field is set to Max_Salvage, so the route back to the source will not be salvaged, if the route fails, the packet is dropped and a route error is generated

  31. Filling Route Cache • When ANY packet is overheard, the route within the packet is broken into links, and the links are stored in the route cache (topology cache) • The details of the cache are not in the experimental RFC 4728 • Each link in the packet is added to the cache (thus, the cache is a cache of links) • Note, a RREQ results in a large amount of topology information being put into different caches • Each entry in the cache has a time-out. • A common approach is to set the time-out • Alternatively, link lifetimes could be estimated

  32. Link lifetime estimation • Each node has a stability attribute (SA) • When a packet appears that has used over node I or will pass through node I, • SA_i = SA_i + timeSinceLastUpdated * StabilityIncFactor • StabilityIncFactor (>1 default=4). • When a link is found to have broken, then the stability of each end point is multiplied by StabilityDecFractor (<1 default =1/2) • SA_i = SA_i* StabilityDecFractor • AIMD – whyyyy • Link lifetime • When a link is put into the link cache, its lifetime is the min SA its end points, but never less than 1sec. • When a link is used for a route, its lifetime is set to max(120, current lifetime). • A route is selected from the graph in the cache. • The route is the shortest, but among the shortest, the one with the longest lifetime is selected

  33. Generating route reply from cache • When a RREQ arrives, if the packet has not been seen before, then the route cache is examined for a route to the destination • If the route cache includes a path to the destination, then a cache route reply is generated • It is checked that the route does not have any loops (easy) • The cached route is included in the options part of the packet. So there are two path segments, one from source to this node and one from this node to the dest. • Route replies are sent either over the reverse path or over some different path, which might require finding a path • The salvage field is set to non-zero and ideally be set to Max_salvage • This will indicate that the packet is being salvaged (which is not exactly correct) and so other nodes will not take the path as valid • If salvage = max_salvage, the delivery to the source will be salvaged if a link is found to have broken.

  34. Preventing packet reply storms • Note that after the dest broadcasts a route reply, all its neighbors have a route to the source • Any late arriving RREQ will cause a RREP to be generated. Causing a RREP storm • Instead: when a route reply can be generated (by dest or intermediate node), a timer is set. • The timer = d = H * (h - 1 + r) where H is a constant that is at least twice the link propagation delay, h is the number of hops from source to the destination, and r is random between 0 and 1 • During this time, the node listens for DATA packets with better routes. If no such data packet appears before the time expires, then the route reply is sent when the time expires

  35. Detecting link failure • Link layer ACKs • Using passive ACKs • Does not work at the last hop • Does not work with power control • Radios must be the same and limited spatial reuse • There might be queuing delay that delays the forwarding • The sender may record the typical forwarding time • Network layer ACKs • Neighbor detection (via hellos) for active routes. • How many times to try before giving up?

  36. Responding to link failure • If a packet is not able to be sent over a link, a route error is generated. • If the salvage field is zero (i.e., not a salvaged packet), then the route error is sent to the source. • If the salvage field is not zero, then the route error is sent to the source address in the options • E.g., if the packet is a route reply from cache, the node with the cache hit is the source in the options part • A route error may generate another route error. • When receiving a route error message • Remove any links from the cache that include the failed link. • If only routes are cached, the remove all routes that contain this link (one could break the routes into route segments..) • If the dest of the route error is not this node, then forward the packet to the next node • A source may begin a new route search when a route error arrives. But, of course, the limit on route searches must be maintained. • Also, the new route search should contain a piggy-backed with the route error. This way nodes can keep their cache up to date and also so they do not respond with a route that is already known to be broken.

  37. Packet salvaging (not route salvaging) • If a link failure is detected a route error is generated (always) • If the node generating the route error has a different path to the dest, then it may salvage the packet • The new route is placed in the options part • The salvage field is incremented • If the packet is a route reply and the links are unidirectional (e.g., 802.11), then packet salvaging is not allowed • The RREP should travel back to the originator of the RREQ to indicate that the path found is a good one. • However, since the path just broke, it is not a good one. Hence, such a message should not be sent • If links are unidirectional, then the RREP indicates that there is a path from the originator to the destination. This information is still valid.

  38. Route shortening • If a node overhears a packet with this node listed in the route that is still to come and this node is not the next hop, then • This node should generate a gratuitous route reply to the source of the packet. • The reply includes the shorter route • The source can then use this shorter route • The node that generates the gratuitous route reply should consider the SNR of the link. • This is crazy

More Related