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

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 10 Nov 2009 09:14:26 +0100

Hi Kris:

I would adhere to your idea but not that it applies to 6LoWPAN ND.

We are not rewriting IP from scratch. We are not even reinventing ND. 

We are adding another mechanism to the NDP suite, which already counts a
number of them (3122, 4861, 4862...).

It is a surprise for nobody that we have more than one classical IGP or
MANET protocol. In fact, MANET is working on one reactive and one
proactive protocol. Why would there only be one ND flavor? Should that
be at all cost? Hopefully, ND is not so cast in stone that we can't
improve it for new purposes. That would be the real bad news.

This additional mechanism goes along the sense of history:

1) it is proactive. 
In general, global flooding and centralized registries are extremes and
apply to very different scales and goals. 
You'll find protocols that occupy different places on a scale between
with those 2 extremes, with different optimization goals.

2) it is compatible with the other mechanisms
You can run it together with 4861 on ethernet or together with 3122 on
FR/ATM. In a same way that you can do NS/NA and RS/RA on a same link. It
is just an additional mechanism that provides additional benefits but
not a replacement though there's intersection for DAD and for address
resolution between host and router. 

3) It provides new benefits
Specifically, it is a way to grant the right to use an address over a
link, this grant including the validation that the address is unique.
There's a WG (SAVI) at the IETF dealing with one of the limitations of
the reactive ND. 
They end up snooping ND flows to reconstruct what may be the owners of
IPv6 addresses; A proactive registration resolves this.

4) It is lightweight
The model for that new operation is that the node only needs connect to
its router(s). IOW the protocol addition operates with an implicit not
on link model. This yields a low footprint both on the node and in the
air. 

5) It scales
Using a backbone that interconnects the white boards, the new mechanism
enables a subnet to grow pretty large. The spec uses proxy (4861) ND
there but other mechanisms like TRILL could be put in place.

6) It DADs, it ROLLs, and it moves
The new registration messages are designed to be extendable to enable an
end-node to join a RPL network. DAD using a distributed registry enables
a solid Address Duplication avoidance without the hassle of multicast.
Transparent mobility within the subnet is ensured by the protocol
operation between the registries. The mechanism also detects duplicate
MACs, an 'attack' that might be uncommon today but might appear more and
more as forgery speads in this domain. The alternate on the table is not
to do DAD and call it compliant to 4861.

I see people raising larger-than-life red flags to preserve their
precious pre-standard implementation, inflating the effort to make it
look either huge, incompatible, or a dead end that will not benefit from
further work on ND. I think none of this is true. If we do our job well,
with the help and support from 6MAN, then we can make this mechanism a
lot more generic than meets the eyes, with application on all sorts of
network, and thus an integral piece of ND from then on.

It seems clear to me that the resolution for the 6LoWPAN ND problem
cannot come from 6LoWPAN alone. 

Most of the objections that we see can be alleviated if 6MAN:
* adheres to the new model and completes it into a generic support
* confirms whether DAD is still required these days or whether has
become an obsolete commodity that we can live without with no hassle

The other way around, if 6MAN thinks that we are really on a dead end,
it would save a lot of time and friendly fire to let us know ASAP.

Either way, I think that 6LoWPAN needs external help.

Pascal

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On
Behalf Of Kris Pister
>Sent: mardi 10 novembre 2009 07:12
>To: Stuber, Michael
>Cc: 6lowpan; [email-masked]
>Subject: Re: [6lowapp] [6lowpan] hardware trends, new vs. existing
protocols [Re: 4861 usage in LLNs]
>
>
> > Abandoning the installed base just goes to reinforce the idea
> > that IP isn't an appropriate technology for things.
>
>Michael - I think that we have the same goal, but I disagree with that
>statement.  I think that re-writing every protocol from discovery
>through transport to applications, from scratch, is what reinforces the
>idea that IP isn't an appropriate technology for things.
>
>I realize that there are pressures from an installed base, but at this
>point it's a tiny fraction of the overall potential.  If we let the 1%
>installed base dictate the path for the next 99%, we should do our best
>to ensure that it's the right path.
>
>ksjp
>
>Stuber, Michael wrote:
>> 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: [email-masked] [mailto:[email-masked]] On
>> Behalf Of Kris Pister
>> Sent: Monday, November 09, 2009 6:53 PM
>> To: Jonathan Hui
>> Cc: Carsten Bormann; 6lowpan; [email-masked]
>> 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
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/6lowpan
>>
>_______________________________________________
>6lowapp mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/6lowapp