Prof Kim,
This is great: results!
Q1: Are these experimental or simulation results?
Q2: Did you use the handling rules as per the draft, or did you modify the
link-layer
source address at every hop, as implied by your post a while back?
-gabriel
--- Ki-Hyung Kim <[EMAIL PROTECTED]> wrote:
> Sorry for this late reply on this issue about the source address compression
> in multi-hop environment.
> After raising this issue in August, our research group has studied on the
> reporting of RERRs to the originators without a source address and a
> precursor list.
> The purpose of the research is to search a light weight RERR reporting
> scheme without putting a source address in the format and maintaining
> precursor lists on routing tables of every nodes.
>
> If I say the conclusion first, the source address is at least not required
> in the 6lowpan format for reporting RERRs to the originators.
>
> In AODV, every intermediate node on a routing path keeps a precursor list on
> each routing entry for a destination. The setting up of the precursor list
> is done when processing RREQ and RREP.
> Thus, data packets do not need to have the originator address in AODV.
>
> What about 6lowpan?
> If a routing scheme of 6lowpan maintains precursor lists for routing as AODV
> does, data packets at least do not need to have the originator address.
> This issue could be handled in the routing documents.
>
> Currently, we have submitted a paper to a conference about the RERR
> reporting schemes.
> In the paper, we have proposed and evaluated several RERR reporting schemes
> including 1) unicasting a RERR back in one-hop only, 2) broadcasting
> backward a RERR in one-hop only, 3) broadcasting backward based on the
> routing table information, 4) using precursor lists, and 5) using the
> originator address if it is assumed to be added to the 6lowpan format
> document.
>
> In the preliminary performance evaluation result, (1) has shown the best
> result, and then (4) comes next in terms of the communication throughput.
> Also (1) showed the minimal implementation complexity.
>
> The detailed description of the schemes and performance results shall be
> shown shortly.
>
> --
> Ki-Hyung Kim
> Associate Professor
> Division of Information and Computer Eng., Ajou University
> Wonchun-Dong, Yeongtong-Gu, Suwon, Korea 442-749
> Tel: +82-31-219-2433, Cel: +82-17-760-2551, Fax: +82-31-219-1811
> http://ilab.ajou.ac.kr/kkim86/index.htm
>
> > -----Original Message-----
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
> > Of gabriel montenegro
> > Sent: Thursday, October 13, 2005 10:02 AM
> > To: Samita Chakrabarti; [EMAIL PROTECTED]; itijibox-
> > [EMAIL PROTECTED]
> > Cc: [email protected]
> > Subject: Re: [6lowpan] format document issues
> >
> > Samita,
> >
> > --- Samita Chakrabarti <[EMAIL PROTECTED]> wrote:
> > > Thus, the format document can save one address field (for originator
> > source
> > > link-layer addr) by requiring the routing protocol to provide
> > information
> > > on originator address so that the intermediate node can setup reverse
> > route.
> > > Alternately, the intermediate node will have to do route-discovery for
> > the
> > > originator - that is certainly not effecient.
> > > Hope this clarifies the point.
> >
> > I *think* we're repeating each other. From my post:
> >
> > > But of course, routing protocols like AODV or LOAD don't use the M bit,
> > > they have
> > > originator and destination address fields within the RREQ.
> >
> > So we don't even have to require "the routing protocol to provide
> > information
> > on originator address so that the intermediate node can setup reverse
> > route."
> > The required info is already in the RREQ, right?
> >
> > -gabriel
> >
> >
> > _______________________________________________
> > 6lowpan mailing list
> > [email protected]
> > https://www1.ietf.org/mailman/listinfo/6lowpan
>
>
_______________________________________________
6lowpan mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/6lowpan
