LEFT | RIGHT |
(no file at all) | |
| 1 .. include:: replace.txt |
| 2 |
| 3 DSDV Routing |
| 4 ------------ |
| 5 |
| 6 Dynamic Source Routing (DSR) protocol is a reactive routing protocol designed sp
ecifically for use in multi-hop· |
| 7 wireless ad hoc networks of mobile nodes. |
| 8 |
| 9 This model was developed by· |
| 10 `the ResiliNets research group <http://www.ittc.ku.edu/resilinets>`_ |
| 11 at the University of Kansas.·· |
| 12 |
| 13 DSR Routing Overview |
| 14 ********************* |
| 15 · |
| 16 This model implements the base specification of the Dynamic Source Routing (DSR
) |
| 17 protocol. Implementation is based on RFC4728. |
| 18 |
| 19 Class dsr::DsrRouting implements all functionality of service packet exchange a
nd inherits Ipv4L4Protocol. |
| 20 |
| 21 Class dsr::DsrOptions implements functionality of packet processing and talk to
DsrRouting to send/receive packets |
| 22 |
| 23 Class dsr::DsrFsHeader defines the fixed-size header and identify the up-layer
protocol |
| 24 |
| 25 Class dsr::DsrOptionHeader takes care of different dsr options and process diff
erent header according to specification from rfc |
| 26 |
| 27 Class dsr::DsrSendBuffer is a buffer to save data packet as well as route error
packet when there is no route to forward the packet |
| 28 |
| 29 Class dsr::DsrMaintainBuffer is a buffer to save data packet for next-hop notif
ication when the data packet has already sent out of send buffer |
| 30 |
| 31 Class dsr::RouteCache is the essential part to save routes found for data packe
t, dsr responds to several routes for a single destination |
| 32 |
| 33 Class dsr::RreqTable implements the functionalities to avoid duplicate route re
quests and control route request rate for a single destination |
| 34 |
| 35 Protocol operation depends on the many adjustable parameters. We support parame
ters, with their default values, from |
| 36 RFC and parameters that enable/disable protocol features or tune for specific s
imulation scenarios, such as the max size |
| 37 of send buffer and its timeout value. The full parameter list is in DsrRouting.
cc file. |
| 38 |
| 39 DSR discovers routes totally on demand. Therefore, our DSR model buffers all pa
ckets, while a route request packet (RREQ) |
| 40 is disseminated. We implement a packet buffer in dsr-rsendbuff.cc. The packet q
ueue implements garbage collection of old |
| 41 packets and a queue size limit. When the packet is sent out from the send buffe
r, it will be queued in maintenance buffer for |
| 42 next hop acknowledgment |
| 43 |
| 44 Route Cache implementation support garbage collection of old entries and state
machine, defined in standard. |
| 45 It implements as a STL map container. The key is the destination IP address. |
| 46 |
| 47 Protocol operation strongly depends on broken link detection mechanism. We impl
ement all the three heuristics. |
| 48 First, we use layer 2 feedback when possible. Link considered to be broken,
if frame transmission results in a transmission |
| 49 failure for all retries. This mechanism meant for active links and work much
more faster, than first method. |
| 50 Layer 2 feedback implementation relies on TxErrHeader trace source, currentl
y it is supported in AdhocWifiMac only. |
| 51 |
| 52 Second, passive acknowledgment should be used whenever possible. The node tu
rns on "promiscuous" receive mode, in which it can receive |
| 53 packet not destined for itself, and when the node assures the delivery of th
at data packet to its destination, it cancels the passive |
| 54 acknowledgment timer. |
| 55 |
| 56 Last, we use network layer acknowledge scheme to notify the receipt of a pac
ket. Route request packet will not |
| 57 be acknowledge or retransmitted. |
| 58 |
| 59 Following optional protocol optimizations aren't implemented: |
| 60 - Flow state |
| 61 - First Hop External (F), Last Hop External (L) flags |
| 62 - Handling unknown DSR options |
| 63 - Two types of error headers: |
| 64 1. flow state not supported option |
| 65 2. unsupported option (not going to happen in simulation) |
| 66 |
| 67 DSR operates with direct access to IP header, and operates between network and
transport layer. |
| 68 |
| 69 Implementation changes |
| 70 - The DsrFsHeader has added 3 fields: message type, source id, destination id,
and these changes only for post-processing |
| 71 - message type is used to identify the data packet from control packet |
| 72 - source id is used to identify the real source of the data packet since w
e have to deliver the packet hop-by-hop and the ipv4header |
| 73 is not carrying the real source and destination ip address as needed |
| 74 - destination id is for same reason of above |
| 75 |
| 76 Changes: |
| 77 - Route Reply header is not word-aligned in DSR rfc, change it to word-aligne
d in implementation |
| 78 - DSR works as a shim header between transport and network protocol, it needs
its own forwarding mechanism, |
| 79 we are changing the packet transmission to hop-by-hop delivery, so we added
two fields in dsr fixed header |
| 80 to notify packet delivery |
| 81 1. message type to notify the type of this packet: data packet or control o
ne |
| 82 2. source id to identify the real source address of this packet |
| 83 3. destination id to identify the real destination |
| 84 |
| 85 Current Route Cache implementation: |
| 86 - This implementation used "path cache", which is simple to implement and ens
ures loop-free |
| 87 - the path cache has automatic expire policy |
| 88 - the cache saves multiple route entries for a certain destination and sor
t the entries based on hop counts |
| 89 - the MaxEntriesEachDst can be tuned to change the maximum entries saved f
or a single destination |
| 90 - when adding mulitiple routes for one destination, the route is compared
based on hop-count and expire time, the one with less hop count |
| 91 or relatively new route is favored |
| 92 - Future implementation may include "link cache" as another possibility |
| 93 |
| 94 References |
| 95 ********** |
| 96 |
| 97 Link for the original paper: www.monarch.cs.rice.edu/monarch-papers/dsr-chapter0
0.pdf |
| 98 Link for RFC 4728: http://www6.ietf.org/rfc/rfc4728.txt |
LEFT | RIGHT |