Re: [6lowapp] [6lowpan] hardware trends, new vs. existing protocols [Re: 4861 usage in LLNs]

["Don Sturek" <[e-mail]>]

My read on 4861 and 6LowPAN-ND (and prior knowledge of DHCP) would indicate
that 6LowPAN-ND is still needed as Pascal points out.  Does everyone agree
with this? 

Don


-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf
Of Stuber, Michael
Sent: Monday, November 09, 2009 8:41 PM
To: Pascal Thubert (pthubert); Kris Pister; Jonathan Hui
Cc: Carsten Bormann; 6lowpan; [e-mail]
Subject: Re: [6lowpan] hardware trends, new vs. existing protocols [Re: 4861
usage in LLNs]

I realize that I'm new here, and I may be asking questions that have
already been hashed to death, but I confess I don't feel think that DAD
is appropriate on 802.15.4 mesh networks, unless the scope is limited to
the immediate neighbors.  Imagine a PAN with hundreds of nodes trying to
form.  

I understand that this may run afoul of the v6 RFCs, but I believe the
idea with 6LowPAN was to have an adaption for 802.15.4 networks, and I
believe this would be a reasonable adaption.  I for one am willing to
give up mesh-wide DAD in this context.  

-----Original Message-----
From: Pascal Thubert (pthubert) [mailto:[e-mail]] 
Sent: Monday, November 09, 2009 8:21 PM
To: Stuber, Michael; Kris Pister; Jonathan Hui
Cc: Carsten Bormann; 6lowpan; [e-mail]
Subject: RE: [6lowpan] hardware trends,new vs. existing protocols [Re:
4861 usage in LLNs]

Hi Michael;

To be very clear, I have nothing against using / optimizing DHCP in
LoWPAN. All the contrary.
A great item for rechartering I suspect. Just don't call it ND. 

Note that even if an address is obtained via DHCP, it has to be DADed
through ND. 
And if a backbone is used, the address has to be proxied. Etc...

IOW, DHCP is an alternate to SLAAC to get an address (and other stuff),
but the ND draft is still needed. 
DHCP does not remove the need for ND, never did still does not.

Pascal

>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]] On
Behalf Of Stuber, Michael
>Sent: mardi 10 novembre 2009 04:57
>To: Kris Pister; Jonathan Hui
>Cc: Carsten Bormann; 6lowpan; [e-mail]
>Subject: Re: [6lowpan] hardware trends,new vs. existing protocols [Re:
4861 usage in LLNs]
>
>Life may be getting better, but that doesn't mean we have the wrong 
>target.  Abandoning the installed base just goes to reinforce the idea 
>that IP isn't an appropriate technology for things.  Qualifications for

>parts in appliances, meters, and cars may take much longer than in
other
>consumer electronics.  There are lots of products shipping today with
>802.15.4 chips that do not match the (nicer) specs you outline below.
>If we want to enable IP everywhere, we must acknowledge that small 
>footprint parts are an important part of "everywhere."
>
>That said, I too am in favor of exploring optimized DHCP.  It would 
>provide the flexibility of living in an edge router, or being 
>centralized.  It is a well defined, characterized protocol.
>
>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]] On 
>Behalf Of Kris Pister
>Sent: Monday, November 09, 2009 6:53 PM
>To: Jonathan Hui
>Cc: Carsten Bormann; 6lowpan; [e-mail]
>Subject: [6lowpan] hardware trends, new vs. existing protocols [Re:
4861
>usage in LLNs]
>
>+1 in favor of using optimized DHCP if possible (no opinion on 'if
>possible'), rather than inventing something new.
>
>As I've shared with several people in private emails recently, it's 
>pretty clear that lowpan nodes are going to get more capable moving 
>forward, not less.  Why?  Radios don't scale down in area when you
scale
>
>CMOS processes.  Today's 15.4 single-chip nodes are made in
technologies
>
>that are several (maybe five?) generations behind the cutting edge.
>This makes economic sense because the sales volumes don't support the 
>need for expensive mask sets yet.
>When there's a volume application, and someone puts a 5mm2 radio into 
>modern CMOS, it just doesn't make sense to put 48kB of rom/flash and 
>10kB of RAM next to it.  You'll put hundreds of kB of rom/flash, and 
>many tens of kB of RAM, and the radio will still be by far the biggest 
>thing on the chip.
>
>Even the 48k/10k node from the (very nice) 6lowapp bof presentation is 
>not up to commercial standards - it's a five year old, expensive, 
>academic platform - great for it's time, but old.  Single-chip nodes 
>from Jennic, Freescale, etc. have ~200kB ROM/flash + 128kB RAM, a 32bit

>processor, and they aren't made in cutting-edge processes yet either.
>Life is just going to get better.  Let's try to find the smallest 
>optimized set of *existing* protocols that serve our needs, that run on

>the existing new low-cost hardware (not the old workhorses). Let's 
>invent the absolute minimum of new "optimized" protocols, because it's 
>not at all clear to me that we are optimizing the right things at this 
>point.  The less we invent, the broader the set of applications and 
>applications programmers we address.
>
>ksjp
>
>Jonathan Hui wrote:
>>
>> On Nov 9, 2009, at 5:50 PM, Carsten Bormann wrote:
>>
>>> Again, entirely getting rid of a function is always the best 
>>> optimization.
>>> Can we do that for DAD?
>>
>> The *need* for DAD is the core question for me.  As specified within 
>> 6lowpan-nd now, IPv6 addresses are maintained using a centralized 
>> protocol.  That protocol looks and smells like DHCP - there's 
>> request/response, lease times, relays.  The whiteboard may also 
>> administratively assign addresses.  So in the end, it's not clear to 
>> me why we would need to *detect* duplicates when we essentially
>> *avoid* them from the beginning.
>>
>> I've voiced my comment several times over the past 1+ years and 
>> presented a draft that argues for the use of optimized DHCP in
Dublin,
>
>> so this is not new from my end.  The fact that the current 6lowpan-nd

>> document has evolved towards using DHCP-like mechanisms is not an 
>> accident.  But if what we do is DHCP-like, it would seem to make
sense
>
>> to utilize existing DHCP infrastructure rather than defining
something
>
>> new.
>>
>> --
>> Jonathan Hui
>>
>_______________________________________________
>6lowpan mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/6lowpan
>_______________________________________________
>6lowpan mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/6lowpan
_______________________________________________
6lowpan mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/6lowpan