Subject: RE: [6lowpan] 6lowpan hallway pre-meeting

From: "Kushalnagar, Nandakishore" <[email-masked]>
Date: Wed, 3 Aug 2005 15:13:01 -0700

Hi Carsten,

Same here. 
My comments preceded by NK.

-----Original Message-----
From: Carsten Bormann [mailto:[email-masked]] 
Sent: Wednesday, August 03, 2005 7:29 AM
To: Kushalnagar, Nandakishore
Cc: Carsten Bormann; [email-masked]
Subject: Re: [6lowpan] 6lowpan hallway pre-meeting

Hi Nandu,

good to hear from you.
I'm afraid my notes (and musings) may have been a bit ambiguous in  
places.

> Address assignment:
> Before I comment on this I agree scalability is a concern in routing,
> but I am a bit concerned of assuming the amount of "MAC technologies"
> embedded into addresses such as the topology information. In this  
> path,
> I am afraid that solutions would not be generic enough. From my
> perspective, I think how addresses are assigned is implementation
> dependent.

It seems to me I wasn't careful enough to separate L2 addresses  
(which have fixed 64-bit and freely assignable 16-bit values in  
802.15.4) from L3 addresses.
The latter directly follow from the MAC address (which one?) if we  
use stateless autoconfiguration.

NK: Here, I meant L2 address assignment.

> Dictating the addressing methodology to have implicit routing
> information is an interesting idea but not sure all implementations  
> may
> need it.

IP routing scalability is based on the fact that an IP address is a  
locator, containing some topology-dependent information (the prefix)  
and some information that generally is opaque (the network part).   
Since 6lowpan is at L2, one could consider extending this to the  
assignable L2 addresses as well.

NK: hmmm.. I am confused. Although one could think of 6lowpan being in
L2, is it not the purpose of 6lowpan to specify how to run IP packets on
802.15.4? If so, how does assigning of L2 addressing fall into the shim
adaptation layer? what do other folks think?

> Decoupling the addressing and routing because of the following
> reasons:
>
> 1. Making a node to route a particular fashion may not be suitable for
> lowpans as nodes are constrained in different manners. (bandwidth,
> energy, etc) and may want to choose routing via different nodes
> depending on these constraints.

This would be part of the topology.
NK: Topology changes quite often at runtime and changing addresses
becomes kind of messy, don't you think?

> 2. Heterogeneity can exist at different layers. Various kinds of
> heterogeneity may exist. Addressing is just one kind of service.

Yes, but routing scalability requires some way to abstract out  
information from an address.

> 3. Specifying how MAC addresses are assigned may not be an IETF  
> concern.

Certainly not for EUI-64.  If we use 16-bit addresses for routing  
scalability, the MAC address assignment would definitely be a concern  
for 6lowpan if any interoperability is desired.

NK: I see.

> Optimization:
> I agree that device constraints restrain the packet size. My 2c for  
> the
> "It is not quite clear what we are optimizing for", is in my mind, I
> think we one of the many things that we may are optimizing for is the
> control messages to be within one 802.15.4 packet. (Control packets
> could be packets needed to maintain the network such as routing  
> packets,
> etc.) The others are of course the amount of packets needed,  
> methods for
> disseminating packets, etc.

Agree.

> I also want to capture one more important application that I found
> missing here is the industrial automation space: This includes  
> proactive
> maintenance, machine monitoring, etc. This is an important space as  
> this
> has some unique requirements is characterized by frequent bursty data
> but less frequent in terms of collection cycles.

(Is that the same as or different from ICMC?)

> Interface to routing:
> I really like the "plug and play" concept for routing layers as the
> routing protocol is application dependent. One strategy we may  
> choose to
> do is to specify frame work for reactive and proactive routing  
> protocols
> at LoWPAN and specify guidelines for adapting routing layer to  
> lowpans.

Agree.

Gruesse, Carsten

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