Hello Ki-Hyung, Thanks for the clarification. Please see my comments in-line. > > I want to clarify about reporting RERR to the originator in AODV. > > AODV does not rely on the reverse route path for reporting RERR to the > originator even though it could.
It is true. RFC3561 talks about the 'precursor or neighbor list for previous hops'. I was looking at the following section: 6.11. Route Error (RERR) Messages, Route Expiry and Route Deletion A Route Error (RERR) message MAY be either broadcast (if there are many precursors), unicast (if there is only 1 precursor), or iteratively unicast to all precursors (if broadcast is inappropriate). The idea expressed in the previous mail for reverse route RERR is an idea that I am pursuing in my mind - that can be appropriate for Lowpan-aodv; I was thinking wrt to RREQ packets. > Moreover, the reverse route path in the routing table could not be used for > unicasting back a RERR in 6lowpan because a data packet does not contain the > originator address. > That is, even though a routing table contains a reverse route to the > originator, the route could not be found by just looking at a data packet. > You are right! It's definitely confusing our thoughts on this kind of cross-layer design. > Instead of the reverse route, AODV uses a precursor list attached on the > routing entry for the unreachable destination. The list contains neighbor > nodes in previous hop. Also, AODV could even utilize a reverse route path to > the originator instead. > > The precursor list was set up when a node processing a RREQ and a RREP. > If the list contains a neighbor, the upstream node just unicasts a RERR to > the neighbor (that is, previous hop node). Otherwise, if the list has > multiple neighbors, the node may broadcast a RERR or unicast a RERR > one-by-one to each neighbor. agree. > The precursor list might be utilized in 6lowpan also for the RERR reporting, > but have to pay some expense for maintaining it. > That is one of the reasons why we are trying to find alternate lightweight > solutions in 6lowpan. Still, the problem lies with the datapacket not carrying information on the source link-layer address. The question is whether we want to sacrifice 64bit for the link-layer source address for occasional error messages back? One question, I have in mind, whether we need to define a format for IEEE 64bit address for lowpan - AFAIK, IEEE802.15.4 does not specify an address format for the 64bit MAC address. Do we know if it could be a random number? If we have a specific format for the address, perhaps we can comeup with some clever header-compression and include both source and destination MAC address when M bit is set. Or just doing a multiple-unicast to the precusor list and so on. If the routing table maintains a precusor list, it will not be that costly for the lowpan layer-code to lookup that list. The third option is to include a bit in the lowpan layer along with 'M' bit to ask for RERR or not. If the bit is 0, the RERR is not generated for the datapackets. Anyway, I can see the problem you're trying to address. It is an interesting problem when one wants to send data directly over lowpan. Thanks. -Samita _______________________________________________ 6lowpan mailing list [email protected] https://www1.ietf.org/mailman/listinfo/6lowpan
