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

From: "Kushalnagar, Nandakishore" <[email-masked]>
Date: Wed, 3 Aug 2005 07:06:31 -0700

All,

Thanks for the meeting minutes. I am sorry I could not attend.

My initial comments:

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. 

Dictating the addressing methodology to have implicit routing
information is an interesting idea but not sure all implementations may
need it. 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.
2. Heterogeneity can exist at different layers. Various kinds of
heterogeneity may exist. Addressing is just one kind of service.
3. Specifying how MAC addresses are assigned may not be an IETF concern.

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.

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.

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.

Nandu

 am a little concerned about specifying addresses where routing is
embedded. 
-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Carsten Bormann
Sent: Sunday, July 31, 2005 10:29 AM
To: [email-masked]
Cc: Carsten Bormann
Subject: [6lowpan] 6lowpan hallway pre-meeting

Lowpanners,

there are 9 drafts that are relevant to this week's meeting at the IETF.

Two working group drafts:

draft-ietf-6lowpan-format-00.txt
draft-ietf-6lowpan-problem-00.txt

Seven independent submissions:

draft-chakrabarti-lowpan-ipv6-nd-00.txt
draft-chakrabarti-mobopts-lowpan-req-00.txt
draft-daniel-6lowpan-hilow-hierarchical-routing-00.txt
draft-daniel-6lowpan-interoperability-01.txt
draft-daniel-6lowpan-load-adhoc-routing-01.txt
draft-daniel-6lowpan-sslp-00.txt
draft-montenegro-lowpan-aodv-00.txt

It is pretty clear that we can't cover this ground in the one-hour  
meeting we have on the official agenda.
Since most of the authors and other interested people are here in  
Paris, I'm proposing that we have an off-line meeting

     Monday, 18:30, at the corner of the terminal room to the right  
of the entrance (where the L-shaped table arrangement is).

We need to discuss:

What is the impact of each of the seven independent submissions on  
the probable course of action?
Is the charter's assumption that we'll finish the encapsulation/ 
format first and then tackle security/routing the right way forward?
Are the additional proposals going to require changes in our current  
standards track document (draft-ietf-6lowpan-format-00.txt)?
What do the authors want to have happen to the additional submissions?

Of course, no decisions are made in smoke-filled rooms; this is just  
about maximizing use of the face time.
We will summarize the discussion to the list.

Gruesse, Carsten

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

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

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 3 Aug 2005 16:28:33 +0200

Hi Nandu,

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

> perspective, I think how addresses are assigned is implementation

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.

> 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.

> Decoupling the addressing and routing because of the following
> reasons:
>

This would be part of the topology.

> 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  

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.

> disseminating packets, etc.

Agree.

> but less frequent in terms of collection cycles.

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

> at LoWPAN and specify guidelines for adapting routing layer to  

Agree.

Gruesse, Carsten