Please look at the replies below. > -----Original Message----- > From: gabriel montenegro [mailto:[EMAIL PROTECTED] > Sent: Friday, October 14, 2005 1:52 AM > To: Ki-Hyung Kim; 'Samita Chakrabarti'; [EMAIL PROTECTED] > Cc: [email protected] > Subject: RE: [6lowpan] format document issues > > Prof Kim, > > This is great: results! > > Q1: Are these experimental or simulation results? That is simulation results. About the Q1: Currently, we are implementing the formatting document and LOAD on a sensor platform. After finishing the implementation, the experimental results will be available.
> 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? I didn't change anything of the format document on the simulation. Also the link-layer source address is changed at every hop as everybody expected. > > -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
