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

["Pascal Thubert (pthubert)" <[e-mail]>]

Hi Michael:

My take is that address ownership and uniqueness is a fundamental
assumption of the IPv6 architecture and it must be ensured.
The current ND does that at low cost. Basically similar to the cost of
DHCP, with similar flows.

Pascal

>-----Original Message-----
>From: Stuber, Michael [mailto:[e-mail]]
>Sent: mardi 10 novembre 2009 05:41
>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