Subject: RE: [6lowpan] format document issues

From: Samita Chakrabarti <[email-masked]>
Date: Thu, 13 Oct 2005 17:04:05 -0700 (PDT)

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-masked]
https://www1.ietf.org/mailman/listinfo/6lowpan

---

From: gabriel montenegro <[email-masked]>
Date: Fri, 14 Oct 2005 01:24:20 -0700 (PDT)

> address format for the 64bit MAC address. Do we know if it could be a

Sure. By default the MAC address is an EUI-64, as mentioned here:

http://www.geocities.com/gabriel_montenegro_2000/draft-ietf-6lowpan-format-00a.htm#mesh

As with many 802 devices (ethernet, token ring, fddi...) you're not forced to set it
to the manufacturer-set MAC address. So people quite commonly set it to other things
like random, or layer 2 CGAs or structured, etc. ZigBee has a structured addressing
scheme, and Geoff can tell you about issues with that. We've seen a similar proposal
in this group as well.

802.15.4 also allows the 16-bit addresses, assigned by the controller during
network entry of the device.

> source and destination MAC address when M bit is set.

Just using 16-bit addresses would go a long way. Not sure we should
look any further. We could include both src and dst then.

> or not. If the bit is 0, the RERR is not generated for the datapackets.

AODVjr, for example, does not use RERRs (or precursor lists, for that matter).

-gabriel