Subject: [manet] question on RREP

From: "Ehsan Hamadani" <[email-masked]>
Date: Mon, 24 Nov 2003 14:42:11 -0000

Sorry , in the third line I made a mistake by using RREP, it should be
RREQ. So this is my question :
 
Hi all
I am a PhD student and it is just about 2 months that I have started my
research on Ad-Hoc networks.
My question is that in all reactive routing protocols, we assume that
RREP follows the reverse path in which RREQ has arrived, so what will
happen if in the return path one of the links are broken?? Does the
destination start a routing discovery to destination?
 
I would be thankful if someone can answer me.
 
Regards
 
Ehsan

---

From: "John Mullen" <[email-masked]>
Date: Mon, 24 Nov 2003 11:36:43 -0700

Hi Ehsan,
 
In wireless communications, link reliability is an issue.  Requiring the
RREP to follow the reverse path is a means of protecting against an
unreliable link.  For example, if the link reliability is 0.2, that
means that, on the average, once every five attempts, one will get
through.  One of those times could be a RREQ.  We wouldn't want to use
such a link to transmit a message.  However, if the path must be
traversed twice, once for the RREQ and once for the RREP, the chances of
both transmissions being received is only 0.04.  
 
Also, when a RREQ is sent out, there may be multiple replies via several
routes.  The requesting node will wait for a time interval for later
replies to arrive, then choose the best one.  If a RREP fails to arrive
because of an unreliable link, chances are that some other RREP will be
chosen from those that did arrive.  If no other RREP does arrive, then,
after a timeout, the RREQ will be sent out again, possibly with some
parameters changed.
 
Notice that I said "on the average" above.  There is a chance that even
a reliable link will fail in one direction or the other.  There is also
a chance that an unreliable path will be chosen.  The idea of the
protocol is to improve the odds, but nothing is certain.
 
John Mullen
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Ehsan Hamadani
Sent: Monday, November 24, 2003 7:42 AM
To: [email-masked]
Subject: [manet] question on RREP

Hi all

Regards
 
Ehsan

---

From: Dave Maltz <[email-masked]>
Date: Mon, 24 Nov 2003 15:16:20 -0500

Generalizing slightly on John's comments, I think there is often value
in testing the candidate routes discovered by a reactive or on-demand
protocol.

Over the years, we have looked at many variations on this theme in the
design of DSR.  For example, when S does a route request for D, DSR is
capable of independently discovering a route from D->S, rather than
simply using the reverse route on the Route Request packet.
Basically, the discovered S->D route is turned into a Route Reply that
is piggybacked on a RouteRequest lauched from D targeting S. (The
results in our '96 paper use this mechanism. see below for more
details)

When we believed that 802.11b, with its */DATA/ACK exchanges, was
likely to become the dominant MAC for ad hoc network testbeds, we
changed the default behavior in DSR to be sending Route Replies along the
reverse route because it was critical to verify the reverse route
worked before reporting it as a candidate route.  (802.11b with its
per-hop ACK cannot successfully deliver data over a unidirectional
link).

I always intended to run an experiment where nodes able to reply from
their cache would unicast the Route Request along the cached route,
rather than simply return a Route Reply themselves.  This would test
that the cached route was still valid before returning it to the
requesting node.  I'm pretty sure we never published the results, and
I don't recall if we eventually ran the experiment or not.

Cheers, 
 -dam

Prior to '98, it was the case that our ns-2 implementation of DSR
could be changed to work with asymetric routes simply by changing the
value of the flag below, which caused DSR to use Route Discovery to
determine how to return Route Replies to an originating node.

bool dsragent_require_bi_routes = true;
// do we need to have bidirectional source routes? 

As comments in the source file show, after '98 I stopped supporting
that option.  You could reimplement it easily if you were interested
in experimenting with it.

David B. Johnson and David A. Maltz. Protocols for Adaptive Wireless
and Mobile Networking. IEEE Personal Communications, 3(1):34-42,
February 1996.
http://www.monarch.cs.rice.edu/monarch-papers/pcs-monarch.ps

In message <[email-masked]>, "John Mullen" wr
ites:
>------=_NextPart_000_0001_01C3B27F.3C33BC00
>Content-Type: text/html;
>	charset="us-ascii"
>Content-Transfer-Encoding: quoted-printable
>
><!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
><HTML xmlns=3D"http://www.w3.org/TR/REC-html40" xmlns:o =3D=20
>"urn:schemas-microsoft-com:office:office" xmlns:w =3D=20
>"urn:schemas-microsoft-com:office:word"><HEAD>
><META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
>charset=3Dus-ascii">
><TITLE>Message</TITLE>
>
><META content=3DWord.Document name=3DProgId>
><META content=3D"MSHTML 6.00.2800.1276" name=3DGENERATOR>
><META content=3D"Microsoft Word 10" name=3DOriginator><LINK=20
>href=3D"cid:[email-masked]" rel=3DFile-List><!--[if gte =
>mso 9]><xml>
> <o:OfficeDocumentSettings>
>  <o:DoNotRelyOnCSS/>
> </o:OfficeDocumentSettings>
></xml><![endif]--><!--[if gte mso 9]><xml>
> <w:WordDocument>
>  <w:SpellingState>Clean</w:SpellingState>
>  <w:GrammarState>Clean</w:GrammarState>
>  <w:DocumentKind>DocumentEmail</w:DocumentKind>
>  <w:EnvelopeVis/>
>  <w:Compatibility>
>   <w:BreakWrappedTables/>
>   <w:SnapToGridInCell/>
>   <w:ApplyBreakingRules/>
>   <w:WrapTextWithPunct/>
>   <w:UseAsianBreakRules/>
>   <w:UseFELayout/>
>  </w:Compatibility>
>  <w:BrowserLevel>MicrosoftInternetExplorer4</w:BrowserLevel>
> </w:WordDocument>
></xml><![endif]-->
><STYLE>@font-face {
>	font-family: SimSun;
>}
>@font-face {
>	font-family: @SimSun;
>}
>@page Section1 {size: 595.3pt 841.9pt; margin: 72.0pt 90.0pt 72.0pt =
>90.0pt; mso-header-margin: 35.4pt; mso-footer-margin: 35.4pt; =
>mso-paper-source: 0; }
>P.MsoNormal {
>	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman"; =
>mso-style-parent: ""; mso-pagination: widow-orphan; =
>mso-fareast-font-family: SimSun
>}
>LI.MsoNormal {
>	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman"; =
>mso-style-parent: ""; mso-pagination: widow-orphan; =
>mso-fareast-font-family: SimSun
>}
>DIV.MsoNormal {
>	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman"; =
>mso-style-parent: ""; mso-pagination: widow-orphan; =
>mso-fareast-font-family: SimSun
>}
>A:link {
>	COLOR: blue; TEXT-DECORATION: underline; text-underline: single
>}
>SPAN.MsoHyperlink {
>	COLOR: blue; TEXT-DECORATION: underline; text-underline: single
>}
>A:visited {
>	COLOR: purple; TEXT-DECORATION: underline; text-underline: single
>}
>SPAN.MsoHyperlinkFollowed {
>	COLOR: purple; TEXT-DECORATION: underline; text-underline: single
>}
>SPAN.EmailStyle17 {
>	COLOR: windowtext; FONT-FAMILY: Arial; mso-style-type: =
>personal-compose; mso-style-noshow: yes; mso-ansi-font-size: 10.0pt; =
>mso-bidi-font-size: 10.0pt; mso-ascii-font-family: Arial; =
>mso-hansi-font-family: Arial; mso-bidi-font-family: Arial
>}
>SPAN.GramE {
>	mso-style-name: ""; mso-gram-e: yes
>}
>DIV.Section1 {
>	page: Section1
>}
></STYLE>
><!--[if gte mso 10]>
><style>
> /* Style Definitions */=20
> table.MsoNormalTable
>	{mso-style-name:"Table Normal";
>	mso-tstyle-rowband-size:0;
>	mso-tstyle-colband-size:0;
>	mso-style-noshow:yes;
>	mso-style-parent:"";
>	mso-padding-alt:0cm 5.4pt 0cm 5.4pt;
>	mso-para-margin:0cm;
>	mso-para-margin-bottom:.0001pt;
>	mso-pagination:widow-orphan;
>	font-size:10.0pt;
>	font-family:"Times New Roman";}
></style>
><![endif]--></HEAD>
><BODY lang=3DEN-GB style=3D"tab-interval: 36.0pt" vLink=3Dpurple =
>link=3Dblue>
><DIV><SPAN class=3D412522518-24112003><FONT face=3DArial color=3D#0000ff =
>size=3D2>Hi=20
>Ehsan,</FONT></SPAN></DIV>
><DIV><SPAN class=3D412522518-24112003><FONT face=3DArial color=3D#0000ff =
>
>size=3D2></FONT></SPAN>&nbsp;</DIV>
><DIV><SPAN class=3D412522518-24112003><FONT face=3DArial color=3D#0000ff =
>size=3D2>In=20
>wireless communications, link reliability is an issue.&nbsp; Requiring =
>the RREP=20
>to follow the reverse path is a means of protecting against an =
>unreliable=20
>link.&nbsp; For example, if the link reliability is 0.2, that means =
>that, on the=20
>average, once every five attempts, one will get through.&nbsp; One of =
>those=20
>times could be a RREQ.&nbsp; We wouldn't want to use such a link to =
>transmit a=20
>message.&nbsp; However, if the path must be traversed twice, once for =
>the RREQ=20
>and once for the RREP, the chances of both transmissions being received =
>is only=20
>0.04.&nbsp; </FONT></SPAN></DIV>
><DIV><SPAN class=3D412522518-24112003><FONT face=3DArial color=3D#0000ff =
>
>size=3D2></FONT></SPAN>&nbsp;</DIV>
><DIV><SPAN class=3D412522518-24112003><FONT face=3DArial color=3D#0000ff =
>size=3D2>Also,=20
>when a RREQ is sent out, there may be multiple replies via several =
>routes.&nbsp;=20
>The requesting node will wait for a time interval for later replies to =
>arrive,=20
>then choose the best one.&nbsp; If a RREP fails to arrive because of an=20
>unreliable link, chances are that some other RREP&nbsp;will be chosen =
>from those=20
>that did arrive.&nbsp; If no other RREP does arrive, then, after a =
>timeout, the=20
>RREQ will be sent out again, possibly with some parameters=20
>changed.</FONT></SPAN></DIV>
><DIV><SPAN class=3D412522518-24112003><FONT face=3DArial color=3D#0000ff =
>
>size=3D2></FONT></SPAN>&nbsp;</DIV>
><DIV><SPAN class=3D412522518-24112003><FONT face=3DArial color=3D#0000ff =
>size=3D2>Notice=20
>that I said "on the average" above.&nbsp; There is a chance that even a =
>reliable=20
>link will fail in one direction or the other.&nbsp; There is also a =
>chance that=20
>an unreliable path will be chosen.&nbsp; The idea of the protocol is to =
>improve=20
>the odds, but nothing is certain.</FONT></SPAN></DIV>
><DIV><SPAN class=3D412522518-24112003><FONT face=3DArial color=3D#0000ff =
>
>size=3D2></FONT></SPAN>&nbsp;</DIV>
><DIV><SPAN class=3D412522518-24112003><FONT face=3DArial color=3D#0000ff =
>size=3D2>John=20
>Mullen</FONT></SPAN></DIV>
><BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
>  <DIV></DIV>
>  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
>align=3Dleft><FONT=20
>  face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B>=20
>  [email-masked] [mailto:[email-masked]] <B>On Behalf Of =
></B>Ehsan=20
>  Hamadani<BR><B>Sent:</B> Monday, November 24, 2003 7:42 =
>AM<BR><B>To:</B>=20
>  [email-masked]<BR><B>Subject:</B> [manet] question on=20
>RREP<BR><BR></FONT></DIV>
>  <DIV class=3DSection1>
>  <P class=3DMsoNormal><SPAN class=3DGramE><FONT face=3DArial =
>size=3D2><SPAN=20
>  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Sorry =
>,</SPAN></FONT></SPAN><FONT=20
>  face=3DArial size=3D2><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
>Arial"> in the=20
>  third line I made a mistake by using RREP, it should be RREQ. So this =
>is my=20
>  question :<o:p></o:p></SPAN></FONT></P>
>  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
>  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
>Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
>  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
>  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Hi=20
>all<o:p></o:p></SPAN></FONT></P>
>  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
>  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">I am a PhD student and =
>it is just=20
>  about 2 months that I have started my research on Ad-Hoc=20
>  networks.<o:p></o:p></SPAN></FONT></P>
>  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
>  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">My question is that in =
>all=20
>  reactive routing protocols, we assume that RREP follows the reverse =
>path in=20
>  which RREQ has arrived, so what will happen if in the return path one =
>of the=20
>  links are broken?? Does the destination start a routing discovery to=20
>  destination?<o:p></o:p></SPAN></FONT></P>
>  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
>  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
>Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
>  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
>  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">I would be thankful if =
>someone can=20
>  answer me.<o:p></o:p></SPAN></FONT></P>
>  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
>  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
>Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
>  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
>  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
>Arial">Regards<o:p></o:p></SPAN></FONT></P>
>  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
>  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
>Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
>  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
>  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Ehsan<SPAN=20
>  style=3D"mso-spacerun: yes">&nbsp; =
></SPAN><o:p></o:p></SPAN></FONT></P>
>  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
>  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
>Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P></DIV></BLOCKQUOTE></BODY></HTM=
>L>
>
>------=_NextPart_000_0001_01C3B27F.3C33BC00--
>
>
>_______________________________________________
>manet mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/manet

_______________________________________________
manet mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/manet