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

• 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)

DSR (Rough Sketch)

S D

Initially, nodes do not have any topology information and hence no routesSuppose that the application gives S’s OS a packet to send to D.S must find a route to D

DSR (Rough Sketch)RREQ

S D

RREQ: S is looking for a path to D, seqno=1

RREQ

DSR (Rough Sketch) RREQ

S A D

A:0. Receive RREQ1. Record that A can reach S in one hop2. Process RREQ

1. Is S looking for A? No2. Does A have a path to D? No3. Forward RREQ

RREQ

RREQ: S is looking for a path to D, seqno=1

DSR (Rough Sketch) RREQ

S A DRREQ

RREQ: S is looking for a path to D, seqno=1; link: A,S

The RREQ has been extended, so that the path from S to A is appended to the RREQ

DSR (Rough Sketch) RREQ

S A B D

B:0. Receive RREQ1. Record that B and A are neighbors, and that S and A are neighbors2. Process RREQ

1. Is S looking for B? No2. Does B have a path to D? No3. Forward RREQ

RREQ

RREQ: S is looking for a path to D, seqno=1; link: A,S

The RREQ has been extended, so that the path from S to A is appended to the RREQ

DSR (Rough Sketch) RREQ

S A B DRREQ

RREQ: S is looking for a path to D, seqno=1; links: A,S; B,A

The RREQ has been extended, so that the path from S to C is appended to the RREQ

DSR (Rough Sketch) RREQ

S A B C DRREQ

RREQ: S is looking for a path to D, seqno=1; links: A,S; B,A; C,B

D:0. Receive RREQ1. Record that S and A, A and B, B and C, and C and D are neighbors2. Process RREQ

1. Is S looking for Y? Yes. Send RREP back to S

DSR (Rough Sketch)RREP

S A B C DRREP

RREP: Send pkt along path D, C, B, A, S.

S:0. Receive RREP1. Record path S,A,B,C,D2. 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 existsReverse path forwarding is not so good because the reverse path might not be “low quality.”

DSR (Rough Sketch)Packet Forwarding

S A B C DData

Data: Send pkt along path S, A, B, C, D

DSR – Path Break

S A B C DData

Data: Send pkt along path S, A, B, C, D

DSR (Rough Sketch)Path Break

S A B C DRERR

1. B detects that the link with C has broken2. B sends a RERR message to S. RERR: from B to S. The link from B to C has broken

DSR (Rough Sketch)Path Break

B C D

1. S repeats the route search processes 2. RREQ: S is looking for a path to D. By the way, the link between B and C has broken

S ARREQ

DSR (Rough Sketch)Topology Cache

S A B C D

1. Since wireless communications are broadcasted, nodes can receive packets even if they are not the destination of the packet

2. RREQ, RREP, RERR, and Data packet all include topology information. This information can be used to determine routes

DSR (Rough Sketch)Topology Cache

S A DRREQ

S A DRREQ

S A B DRREQ

S A B C DRREQ

Learns: It is a neighbor of A, B, and C, and path {S,A,B,C,D}

DSR (Rough Sketch)Topology Cache

B C DS ARREQ

Knows: It is a neighbor of A, B, and C, and path {S,A,B,C,D}

DSR (Rough Sketch)Topology Cache

B

E

C DS ARREQ

Knows: It is a neighbor of A, B, and C, and path {S,A,B,C,D}

E:0. Receive RREQ1. E knows a route to D without link B<->C2. Generate RREP

DSR (Rough Sketch)Topology Cache

B

E

C DS ARREP

Knows: It is a neighbor of A, B, and C, and path {S,A,B,C,D}

E:0. Receive RREQ1. E knows a route to D without link B<->C2. Generate RREP

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)

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.

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

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

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

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

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 routeAlternatively, • 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.

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

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

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?)

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

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

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

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.

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

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?

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.

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.

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