Subject: [Lwip] Device Classification

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 24 Jan 2012 18:25:12 +0200

Hey guys, 

after sending the workshop announcements to a few working groups I was asked what I mean by "constrained" device.

I responded with a pointer to the classification Carsten proposed in http://tools.ietf.org/html/draft-bormann-lwig-guidance-00: 

       +---------+-----------------------+-------------------------+
       | Name    | data size (e.g., RAM) | code size (e.g., Flash) |
       +---------+-----------------------+-------------------------+
       | Class 1 | ~ 10 KiB              | ~ 100 KiB               |
       |         |                       |                         |
       | Class 2 | ~ 50 KiB              | ~ 250 KiB               |
       +---------+-----------------------+-------------------------+

During the IAB technical plenary at the last IETF meeting Jari claimed that we need to have a Class 0 here as well to cover his sensor deployment. 

Any thoughts about this classification? 

Ciao
Hannes

---

From: Joe Touch <[email-masked]>
Date: Tue, 24 Jan 2012 08:34:52 -0800

I'm concerned that these ranges are too similar, and the distinction 
would be short-lived.

I expect devices to persistently operate differently when their 
parameters are at least 2 order of magnitudes different.

The numbers below are so close that they will change and thus likely 
overlap over timescales that are too short, IMO, for the IETF to be 
concerned.

(i.e., there was a time when the difference between 4KB and 8KB was 
important; now it's irrelevant)

Joe

On 1/24/2012 8:25 AM, Hannes Tschofenig wrote:
> Hey guys,
>
> after sending the workshop announcements to a few working groups I was
> asked what I mean by "constrained" device.
>
> I responded with a pointer to the classification Carsten proposed in
> http://tools.ietf.org/html/draft-bormann-lwig-guidance-00:
>
> During the IAB technical plenary at the last IETF meeting Jari claimed
> that we need to have a Class 0 here as well to cover his sensor deployment.
>
> _______________________________________________
> Lwip mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lwip

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 24 Jan 2012 18:55:20 +0200

I tend to agree with Joe here. 

The classification seems a bit arbitrary to me. Carsten, could you provide a bit of background about the chosen values? 

On Jan 24, 2012, at 6:34 PM, Joe Touch wrote:

> I'm concerned that these ranges are too similar, and the distinction would be short-lived.
> 
> I expect devices to persistently operate differently when their parameters are at least 2 order of magnitudes different.
> 
> The numbers below are so close that they will change and thus likely overlap over timescales that are too short, IMO, for the IETF to be concerned.
> 
> (i.e., there was a time when the difference between 4KB and 8KB was important; now it's irrelevant)
> 
> Joe
>

---

From: Guillaume Fortaine <[email-masked]>
Date: Tue, 24 Jan 2012 17:56:32 +0100

Hello,

> Any thoughts about this classification?

I have just asked the same question a few minutes ago :)

On Tue, Jan 24, 2012 at 5:34 PM, Joe Touch <[email-masked]> wrote:
> I expect devices to persistently operate differently when their parameters
> are at least 2 order of magnitudes different.

I totally agree and couldn't say better.

On my side, I would replace Class 1 by Class 2. According to my
analysis, a good chip with the lowest common denominator  features for
Internet of Things could be the STM32L Family (Ultra Low Power
Cortex-M3 32 bit, up to 48K SRAM/384K Flash, AES) :

http://www.emcu.it/STM8L-STM32L-UltraLowPowerPlatform.html

So, is there any need for 6LoWPAN or a "Lightweight IP Stack" ? Why
not to capitalize around the lwIP stack that, moreover, supports IPv6
? :

http://git.savannah.gnu.org/cgit/lwip.git/tree/CHANGELOG

"2011-05-17: Patch by Ivan Delamer (only checked in by Simon Goldschmidt)
  * nearly the whole stack: Finally, we got decent IPv6 support, big thanks to
    Ivan! (this is work in progress: we're just post release anyway :-)"

By the way, after that, there are the future chips around the
Cortex-A5 architecture :

https://docs.google.com/viewer?a=v&q=cache:9DxfCwAl1JAJ:realview.com.cn/shoppic/down/seminar/1011/Track%25201/Tech%2520Symposium%2520-%2520Cortex-A5.pdf+Tech%2520Symposium%2520-%2520Cortex-A5.pdf&hl=fr&gl=fr&pid=bl&srcid=ADGEESjTOGdalGDTg4lwwL-QM8rwVQi9ywlEvO_0aexJne-9lLDQooQzsi9LcFHNMFBm3bbbNT67qB8RURsATZ0TtqoeNsNWGVKk6fEeV_7SmMN_t-SAW4ZWRu30aZhjYkExu-DYJATS&sig=AHIEtbT8XrAlTv_cpDxvNbaECQLwVpCN0Q

Best Regards,

Guillaume FORTAINE

On Tue, Jan 24, 2012 at 5:34 PM, Joe Touch <[email-masked]> wrote:
> I expect devices to persistently operate differently when their parameters
> are at least 2 order of magnitudes different.
>
> The numbers below are so close that they will change and thus likely overlap
> over timescales that are too short, IMO, for the IETF to be concerned.
>

---

From: "Colin O'Flynn" <[email-masked]>
Date: Tue, 24 Jan 2012 14:13:59 -0400

Hello,

There is a difference between Class 1 and Class 2, and not that much
difference below Class 1.

Before I elaborate, let me explain where I'm getting my arguments from: I've
been involved in about four different main IPv6 stacks for low-power
devices, each stack on a different architecture.

Around Class 1, you can do "real" IPv6. But you need to be careful: you've
got enough SRAM to buffer a few IPv6 frames, such as when you are doing ND.
But you won't get that much more, and you'll have to keep your neighbor
table small. For example such are the constraints Contiki's uipv6 is
originally built for (it can go a lot smaller even too).

At Class 2, the extra 10K of breathing room means you can buffer several
frames along with having larger tables. This approach is taken in my own
IPv6 stack, (http://sourceforge.net/apps/trac/flexibleipfip/). The extra
code space gives you a lot more room for higher-level protocols, and
generally lets you do stuff that wastes a bit of code/SRAM but makes the
stack easier to work with.

Much below Class 1 you start having to do "hacks" to get things working...
perhaps collapsing the 6LoWPAN layer and IPv6 layer, such as in 
Atmel App-note AVR2070 (IIRC it has an option for a collapsed stack which
fits in 16K-FLASH 4K-SRAM parts, but I could be wrong).

So I think the definitions are OK. What will happen is nobody will buy Class
1 parts - already for example it's often cheaper buying a SoC than a
separate radio + micro. And most of the SoC have a lot of room in them...

Warm Regards,

  -Colin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Guillaume Fortaine
Sent: January 24, 2012 12:57 PM
To: Joe Touch
Cc: [email-masked]; [email-masked]; Antonio J. Jara
Subject: Re: [Lwip] Device Classification

Hello,

"2011-05-17: Patch by Ivan Delamer (only checked in by Simon Goldschmidt)
  * nearly the whole stack: Finally, we got decent IPv6 support, big thanks
to
    Ivan! (this is work in progress: we're just post release anyway :-)"

https://docs.google.com/viewer?a=v&q=cache:9DxfCwAl1JAJ:realview.com.cn/shop
pic/down/seminar/1011/Track%25201/Tech%2520Symposium%2520-%2520Cortex-A5.pdf
+Tech%2520Symposium%2520-%2520Cortex-A5.pdf&hl=fr&gl=fr&pid=bl&srcid=ADGEESj
TOGdalGDTg4lwwL-QM8rwVQi9ywlEvO_0aexJne-9lLDQooQzsi9LcFHNMFBm3bbbNT67qB8RURs
ATZ0TtqoeNsNWGVKk6fEeV_7SmMN_t-SAW4ZWRu30aZhjYkExu-DYJATS&sig=AHIEtbT8XrAlTv
_cpDxvNbaECQLwVpCN0Q

Best Regards,

Guillaume FORTAINE

> The numbers below are so close that they will change and thus likely
overlap

---

From: Joe Touch <[email-masked]>
Date: Tue, 24 Jan 2012 11:54:36 -0800

Hi, Colin,

> stack easier to work with.

I understand, but AFAICT an extra 10K isn't the issue. IMO, it would be 
more useful to describe this in terms of numbers of packets and/or headers.

i.e. under 10 packets things get difficult. Substantially above that and 
there's much more breathing room. That makes sense.

At that point, however, the class boundaries, IMO, would be (in terms of 
RAM at least):

	<<100 packets	difficult
	>>100 packets	easy

Right around 100 packets it's arguable how hard/easy things are, based 
on multiple connections, windowing, ND, etc.

Joe

---

From: Michael Richardson <[email-masked]>
Date: Tue, 24 Jan 2012 17:45:39 -0500

So, I think that these numbers are off.

In MSP430F54xx family of devices that I've spent most of the last year
working with, the smallest MSP430F5418 has 16KiB ram, 128K flash, while
the largest MSP430F5438 has 16KiB ram, and 256KiB flash.

I suggest that class 2 double the flash value, as I think the 430 should
be class 1 only.  A C64 is... class 2?

I agree with need a class 0 device.  

-- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition.

---

From: Joe Touch <[email-masked]>
Date: Tue, 24 Jan 2012 14:52:03 -0800

> the largest MSP430F5438 has 16KiB ram, and 256KiB flash.

Arduinos have 32KB flash and 2KB RAM, and support WIFI and IPv4 
(including DHCP, DNS, UDP, TCP, and a small web server).

FYI.

Joe

---

From: Michael Richardson <[email-masked]>
Date: Wed, 25 Jan 2012 11:42:33 -0500

>>>>> "Joe" == Joe Touch <[email-masked]> writes:
    Joe> On 1/24/2012 2:45 PM, Michael Richardson wrote:
    >> | Class 1 | ~ 10 KiB | ~ 100 KiB | | Class 2 | ~ 50 KiB | ~ 250
    >> KiB |
    >> 
    >> In MSP430F54xx family of devices that I've spent most of the last
    >> year working with, the smallest MSP430F5418 has 16KiB ram, 128K
    >> flash, while the largest MSP430F5438 has 16KiB ram, and 256KiB
    >> flash.

    Joe> Arduinos have 32KB flash and 2KB RAM, and support WIFI and IPv4
    Joe> (including DHCP, DNS, UDP, TCP, and a small web server).

Yes, for me, these are class 1, while all MSP is perhaps a class 2
device.  I agree that the critical point is not so much flash size, as
ram size, and 10K is the wrong threshold.

---

From: Guillaume Fortaine <[email-masked]>
Date: Thu, 26 Jan 2012 16:59:16 +0100

Hello,

> stack easier to work with.

Thank you for pointing out your Flexible IP project. However, we can
see a 6LoWPAN folder in it [0]. However, 6LoWPAN is not the way to go,
we need plain IPv6 [1] :

" 6LoWPAN is really useful, but this presents limitations for  global
communications (RFC6282)"

> Right around 100 packets it's arguable how hard/easy things are, based on
> multiple connections, windowing, ND, etc.

"Smews is now available on the Mbed platform using ethernet. It is
able to serve static content at about 80Mbp/s on this configuration."
[2]

(mbed = Cortex-M3 with 64K SRAM/512K Flash) [3]

On Wed, Jan 25, 2012 at 5:42 PM, Michael Richardson <[email-masked]> wrote:
>    >> So, I think that these numbers are off.
>    >>
>    >> | Class 1 | ~ 10 KiB | ~ 100 KiB | | Class 2 | ~ 50 KiB | ~ 250
>    >> KiB |
>    >>
>    >> In MSP430F54xx family of devices that I've spent most of the last
>    >> year working with, the smallest MSP430F5418 has 16KiB ram, 128K
>    >> flash, while the largest MSP430F5438 has 16KiB ram, and 256KiB
>    >> flash.
>

a) Arduino

Arduino (ATmega328) doesn't support Wifi.You can add Wifi capability,
that is completely different, through a Wifi shield and these ones are
mainly based around an ARM9 baseband (ARM946E-S core) [4]. Indeed, the
Wifi shield is an order of magnitude more powerful than the Arduino
itself [5] :

"You can use your wireless device as a powerful ARM developement
board, with a 946E core clocked at 30MHz"

By the way, the newer Arduinos will be based around Cortex-M3 cores [6] :

"Arduino Due, a major breakthrough for Arduino because we’re launching
an Arduino board with a 32bit Cortex-M3 ARM processor on it. We’re
using the SAM3U processor from ATMEL running at 96MHz with 256Kb of
Flash, 50Kb of Sram, 5 SPI buses, 2 I2C interfaces, 5 UARTS, 16 Analog
Inputs at 12Bit resolution and much more.."

b) MSP

What about the MSP430FR57xx Family (1K SRAM/16K Flash) [7] ? Anyway,
we should clearly forget the MSP430 Family [8] :

"MSP430 : Public key and IPv6 may strain limits."

Best Regards,

[0] http://flexibleipfip.git.sourceforge.net/git/gitweb.cgi?p=flexibleipfip/flexibleipfip;a=tree;f=source/sixlowpan
[1] http://www.iot-forum.eu/events/launch-event/presentations/wg-technology/slides%20IoT%20Forum%20upload%20Web_Jara.pdf
[2] http://smews.gforge.inria.fr/
[3] http://mbed.org
[4] http://wiki.laptop.org/go/Marvell_microkernel
[5] http://lekernel.net/prism54/freemac.html
[6] http://arduino.cc/blog/2011/09/17/arduino-launches-new-products-in-maker-faire/
[7] http://focus.ti.com/paramsearch/docs/parametricsearch.tsp?familyId=1751&sectionId=95&tabId=2475&family=mcu&DCMP=FRAM&HQ
[8] http://www.dash7.org/OpenTag%20Webinar.pdf

--
Guillaume FORTAINE

On Tue, Jan 24, 2012 at 8:54 PM, Joe Touch <[email-masked]> wrote:
> I understand, but AFAICT an extra 10K isn't the issue. IMO, it would be more
> useful to describe this in terms of numbers of packets and/or headers.
>
> At that point, however, the class boundaries, IMO, would be (in terms of RAM
> at least):
>
>        <<100 packets   difficult
>        >>100 packets   easy
>
> Right around 100 packets it's arguable how hard/easy things are, based on
> multiple connections, windowing, ND, etc.
>
> Joe

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 26 Jan 2012 18:15:49 +0100

> communications (RFC6282)"

6LoWPAN *is* plain IPv6.
I have no idea what the sentence that you are quoting is trying to say.

Grüße, Carsten

---

From: Guillaume Fortaine <[email-masked]>
Date: Thu, 26 Jan 2012 18:23:47 +0100

Dear Dr Bormann,

Thank you for your reply.

> I have no idea what the sentence that you are quoting is trying to say.

With all the due respect, it seems that some people don't agree with you :

http://dash7.org/blog/?p=1782

"(N.B. Ironically, 6LoWPAN, a wireless spec written specifically to
allow IPv6 over low power wireless, is kind of silly, because it is
802.15.4 based and hence it is largely incapable of achieving any of
the useful features of IPv6.)"

Best Regards,

Guillaume FORTAINE

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 26 Jan 2012 18:49:27 +0100

> With all the due respect, it seems that some people don't agree with you :

Sure, some people even think that SOPA is a good idea.

> the useful features of IPv6.)"

From a technical point of view, the whole point of running the 6LoWPAN WG for the last half-decade was to exactly make IPv6 available for constrained node/networks.  That may not take away those constraints, and if you want to sell something else, it may make sense to proclaim it silly.  Here, specifically, the guy is selling a radio that is different from 802.15.4, so he's trying to malign 802.15.4, striking 6LoWPAN in passing.

I would prefer to discuss these things from a technical angle, not by pointing to content-free marketing sites/slides.

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 26 Jan 2012 18:57:46 +0100

> I would prefer to discuss these things from a technical angle, not by pointing to content-free marketing sites/slides.

(*@$(*@&!$

I have been using RFC822 mail for three decades now, so I should *know* you don't start a new line with "From" in E-mail.

Anyway, for those who can't see this in their mail clients: the sentence with "From" is mine, not from the source cited by Guillaume.  Sorry for the confusion.

Grüße, Carsten

PS.: It is really amazing this bug is still hitting in 2012.  And that it is *amplified* by OSX…

---

From: Guillaume Fortaine <[email-masked]>
Date: Thu, 26 Jan 2012 19:03:51 +0100

Dear Mister Bormann,

Thank you for your comprehensive reply.

> I would prefer to discuss these things from a technical angle, not by pointing to content-free marketing sites/slides.

If you remember my first mail on this mailing-list, I was explicitly
asking what you called a "constrained node". Because, to quote :

http://tools.ietf.org/html/draft-bormann-lwig-guidance-01

"Generic hardware design advice and software implementation techniques
are outside the scope of this document."

This is totally no sense. In deeply embedded environments, we also
need a bottom-top approach, hence my request.

Especially, we can see that the people on this mailing-list (and on
the contiki's one as well) need a serious course in Electrical
Engineering before dreaming of designing the "Internet of the Future".

By the way, I have absolutely no affiliation with the DASH7 project.
But, I should admit that Mister Norair made something that too few
people are doing : his homeworks :)

> Anyway, for those who can't see this in their mail clients: the sentence with "From" is mine, not from the source cited by Guillaume.  Sorry for the confusion.

No problem on my side : I am using Gmail :)

Best Regards,

Guillaume FORTAINE

---

From: Antonio Jara <[email-masked]>
Date: Thu, 26 Jan 2012 23:56:37 +0100

Dear All,

Since, I have been involved in this discussion from my slides in the IoT
Forum regarding IPv6 and IoT.

I would like remark that I am agree with the mention from Joe Touch about
that we need to make a difference between overload of the headers and also
the lightweight of the stack, i.e. number of KB required in ROM and RAM
space.

It is the main issue, we need to mark the difference between lwIP, uIP,
Flexible IP which are approaches focused on reduce the number of KBs for
ROM and RAM, with other approaches such as 6LoWPAN which is mainly focused
on reduce the number of bytes in the overload i.e. in the headers through
their header compression.

Both are reducing and optimizing IP but in two different ways.

Few weeks ago, I already had an exchange of emails with Gullaime Fortaine,
where he was interested about our Glowbal IP approach. Which is following
the idea of 6LoWPAN about reduction of header size, at the same way that
RFC4944 was optimized with RFC6282 through the contexts for the global IP
addressing, we consider that it needs to be yet reduced for new
technologies such as Bluetooth Low Energy.

I would like also remark that the my sentence is that " 6LoWPAN is really
useful, but this presents limitations for  global
communications (RFC6282)" from [1].

I am not agree with the sentence of "However, 6LoWPAN is not the way to go,
we need plain IPv6", and this is not coming from the [1] reference such as
indicated in previous emails. And remark that I am agree with Prof. Bormann
that 6LoWPAN is in some way plain IPv6 sinde for the end nodes/clients this
looks as IPv6 and they don't need to make any differente, this
considerations are only required in a local level between the 6LoWPAN
device and the 6LoWPAN Border Router.

[1]
http://www.iot-forum.eu/events/launch-event/presentations/wg-technology/slides%20IoT%20Forum%20upload%20Web_Jara.pdf

And I explain that mention, since such as presented in the slide 7 from
[1], this continues presenting a high overload for global IP addressing,
e.g. 2001::1, instead of the usual link local FE80::1.

Then, not only for IEEE 802.15.4 where we have a frame size of 127 bytes,
also for technologies such as Bluetooth Low Energy, where we have 27bytes,
we define other approaches, the mentioned Glowbal IP, which you can find
more information in:

http://www.esiot.com/MIS_Glowbal_IP_Jara.pdf

Finally, regarding these comments, I enclose a brief reflexion about the
evolution of lwIP, 6LoWPAN, Glowbal IP and their reasons...

---------

First, we need to consider the dates from each approach.

LwIP is from 2001, it was a solution to support an implementation of the
TCP/IP protocol stack in embedded systems with highly constrained
capabilities (from 8 to 32 bits CPUs). The main goal of LwIP stack is to
reduce memory usage and code size.

LwIP stack was not defined for any specific physical technology. It can be
from Ethernet (usually) to WiFi. Remark, that in 2001 was also being
defined IEEE 802.15.4, and it was not extended until 2003 with the standard
version. For example, if you review the lwIP document (
http://www.sics.se/~adam/lwip/doc/lwip.pdf) it is not defined any reference
to IEEE 802.15.4.

After this... Then it was defined the LoWPANs, i.e. these constrained and
embedded systems with Wireless Networking with capabilities for
communications, and then it was extended to these networks the use of lwIP,
but not only lwIP, it was also defined by SICS and even lower size solution
with uIP.

But then... this is defined a new requirement with IEEE 802.15.4 and the
LoWPANs, it is not only the code/memory size, it is also the overhead of IP
for technologies with a frame size of 127bytes (IEEE 802.15.4 case), which
is even lower after of MAC layer headers. Leaving it to a few bytes. Then,
it is feasible to have more than 60bytes on headers?, it is feasible to
consider the current IP and UDP headers for this so frame size constrained
technologies.

The answer was obviously not, and in 2007 borns with this idea the first
RFC about these requirements with the RFC4919, and after its consolidation
with the RFC4944, it is defined 6LoWPAN!

Then SICS people, implements a lightweight version also following some
design issues and ideas from lwIP/uIP and define SICSLoWPAN, in order to
also continue keeping the purposed of low size/memory in conjunction with
this new goal of low overhead.

6LoWPAN was ok for reducing overload, but it was found several problems for
the cases with global addressing, since the addressing compression was too
focused on stateless-configuration address from the MAC EUI-64, in order to
elide it.

Then, it was starting to think how to solve more generic cases for
multicast, global addressing etc..., and it was defined the idea of
contexts instead of the prefix addresses, which idea was consolidated in
the last RFC for 6LoWPAN, RFC6282 in 2011. But, this continues without a
suitable compression, such as it is presented in the first section from the
document of Glowbal IP, but ok it is useful.

The problem in 2011, it is that we continue with our ideas to introduce
Internet everywhere, and other technology also very present in the WPANs
world is Bluetooth, and they lunch Bluetooth 4.0, with the capabilities for
a version of Bluetooth Low Energy in order to be competitive with
6LoWPAN/IEEE 802.15.4/ZigBee.

But the miracles are not so simple, and how they got it?, they define a too
constrained communication medium with a limitation of frame size to 27
bytes for the PDU!!!!!

So, from the highly constrain of 127 bytes in IEEE802.15.4, now we have
limitations to 27 bytes, and they are trying to move 6LoWPAN to Bluetooh
Low Energy.

Obviously, the current  6LoWPAN approach for Bluetooth Low Energy is
focused on remove everything, limit it to local communications, remove even
ports (defining a fixed port)... then when you analize this kind of
approaches, and remember the Internet of Things goals, it is obvious that
we are losing the link with the original motivation.

For that reason, in 2011/2012 is defined Glowbal IP, which is a new
approach to reduce the overloads to 5bytes, and define a solution suitable
for LoWPANs such as IEEE 802.15.4-based, and also to satisfy the
requirements from new technologies such as Bluetooth Low Energy

Best regards,
Antonio J. Jara

On Thu, Jan 26, 2012 at 11:12 PM, JP Norair <[email-masked]> wrote:

> Marketing is in some ways a dirty business, but it other ways it is
> completely necessary.  I do not intend to cheapen other peoples' work and
> research, but if I were not provocative this discussion would never have
> happened.  When we began thinking about DASH7 in 2007, the first thing we
> started doing was market research.  We did market research for three years.
>  As a result, we are not using 802.15.4 + 6LowPAN as a foundation for DASH7.
>
> The 6LowPAN stack is a fine set of technologies, but there is no focus.
>  For US$2 embedded devices, focus matters.  In our market research, it
> became very clear that only three elements of the IP-stack mattered [to our
> market].  They are: UDP, TCP, IPsec.  Also, the market did not care at all
> about gateway vs. router.  Practically -- and especially with 6LowPAN edge
> routers -- most "routers" today actually operate at layer 4.  So we found
> no reason to re-implement IP at layer 3.  Instead, we developed a
> completely different approach to layer 3 routing, we made sure IPsec could
> be integrated, and we made sure UDP and TCP-based applications could be
> used.  Surely, this is not how everyone thinks -- some users will want
> special functionality from IP, and for those users 6LoWPAN is the clear
> answer.  But for our market, all that matters are UDP, TCP, IPsec, so DASH7
> is the clear answer.
>
> Best regards,
> JP Norair
>
>
> On 26 Jan 2012, at 09:49, Carsten Bormann wrote:
>
> he whole point of running the 6LoWPAN WG for the last half-decade was to
> exactly make IPv6 available for constrained node/networks. That may not
> take away those constraints, and if you want to sell something else, it may
> make sense to proclaim it silly.  Here, specifically, the guy is selling a
> radio that is different from 802.15.4, so he's trying to malign 802.15.4,
> striking 6LoWPAN in passing.
>
> I would prefer to discuss these things from a technical angle, not by
> pointing to content-free marketing sites/slides.
>
> Grüße, Carsten
>
>
>

---

From: Antonio Jara <[email-masked]>
Date: Fri, 27 Jan 2012 00:00:35 +0100

Dear All,

Few weeks ago, I already had an exchange of emails with Gullaime Fortaine,
where he was interested about our Glowbal IP approach. Which is following
the idea of 6LoWPAN about reduction of header size, at the same way that
RFC4944 was optimized with RFC6282 through the contexts for the global IP
addressing, we consider that it needs to be reduced for new technologies
such as Bluetooth Low Energy.

I would like also remark that my sentence is " 6LoWPAN is really useful,
but this presents limitations for  global
communications (RFC6282)" from [1].

I am not agree with the sentence of "However, 6LoWPAN is not the way to go,
we need plain IPv6", and this is not coming from the [1] reference such as
indicated in previous emails. And remark that I am agree with Prof. Bormann
that 6LoWPAN is in some way plain IPv6 since for the end nodes/clients this
looks as IPv6 and they don't need to make any difference, this
considerations are only required in a local level between the 6LoWPAN
device and the 6LoWPAN Border Router.

[1]

---------

Best regards,
Antonio J. Jara

On Thu, Jan 26, 2012 at 11:56 PM, Antonio Jara <[email-masked]> wrote:

> I am not agree with the sentence of "However, 6LoWPAN is not the way to
> go, we need plain IPv6", and this is not coming from the [1] reference such
> as indicated in previous emails. And remark that I am agree with Prof.
> Bormann that 6LoWPAN is in some way plain IPv6 sinde for the end
> nodes/clients this looks as IPv6 and they don't need to make any
> differente, this considerations are only required in a local level between
> the 6LoWPAN device and the 6LoWPAN Border Router.
>
> [1]
> http://www.sics.se/~adam/lwip/doc/lwip.pdf) it is not defined any
> reference to IEEE 802.15.4.
>
> 6LoWPAN was ok for reducing overload, but it was found several problems
> for the cases with global addressing, since the addressing compression was
> too focused on stateless-configuration address from the MAC EUI-64, in
> order to elide it.
>
> But the miracles are not so simple, and how they got it?, they define a
> too constrained communication medium with a limitation of frame size to 27
> bytes for the PDU!!!!!
>

---

From: Guillaume Fortaine <[email-masked]>
Date: Fri, 27 Jan 2012 00:41:42 +0100

Hello,

> considerations are only required in a local level between the 6LoWPAN device
> and the 6LoWPAN Border Router.

I totally assume my sentence. Especially, I am asking again, where is
the business need for a new stack when you can embed a full IPv6 stack
? IPv6 was thought from the beginning for the Internet of Things, so
why should we reinvent a (squared) wheel ?

>> pointing to content-free marketing sites/slides.

Let's discuss from a technical angle. Especially, I would greatly
appreciate the profile of an embedded engineer working for a Telecoms
Service Provider, if you wouldn't mind.

By the way, I really appreciated DASH7 approach by making a market
study and focusing on very low cost devices (2 USD). According to my
knowledge, the highest density Cortex-M0 device is the Samsung S3FN41F
(32K SRAM/256K Flash) [0]. Why should we bother with the obsolete
MSP430 Family that is, moreover, higher priced ? There is absolutely
no economic reason to support this.

Moreover, you are all claiming the necessity  of 6LoWPAN. However, I
didn't you see your names in the Linux Kernel 6LoWPAN stack [1].
Especially, did you know that the only supported USB device on Linux
for 802.15.4 was the ATUSB [2] ? Again, I didn't see your names on the
mailing-list.

How could you claim that it is essential or even working if you don't
actively participate in its implementation with an end-to-end approach
? If it is not under Linux, under which OS do you plan to use a
"6LoWPAN Border Router" ? Why a network service provider should bother
with this kind of devices ? Did you think about the associated
increase of CAPEX/OPEX costs for networks at a global scale ? How
could we justify a such investment ?

6LoWPAN is dead :

http://daruino.blogspot.com/

"The blog of the Daruino open source hardware project - Breadboard to
production, evolve with Daruino!"

Best Regards,

[0] http://www.samsung.com/global/business/semiconductor/productInfo.do?fmly_id=804&partnum=S3FN41F&xFmly_id=802
[1] http://linux-zigbee.git.sourceforge.net/git/gitweb.cgi?p=linux-zigbee/kernel;a=shortlog;h=refs/heads/6lowpan
[2] http://en.qi-hardware.com/wiki/Ben_WPAN

--
Guillaume FORTAINE
[email-masked]
DevOpSpace
http://www.devopspace.com
+33(0)631.092.519

On Thu, Jan 26, 2012 at 11:56 PM, Antonio Jara <[email-masked]> wrote:
> Flexible IP which are approaches focused on reduce the number of KBs for ROM
> and RAM, with other approaches such as 6LoWPAN which is mainly focused on
> reduce the number of bytes in the overload i.e. in the headers through their
> header compression.
>
> addressing, we consider that it needs to be yet reduced for new technologies
> considerations are only required in a local level between the 6LoWPAN device
> and the 6LoWPAN Border Router.
>
> [1]
> And I explain that mention, since such as presented in the slide 7 from [1],
> this continues presenting a high overload for global IP addressing, e.g.
> 2001::1, instead of the usual link local FE80::1.
>
> from Ethernet (usually) to WiFi. Remark, that in 2001 was also being defined
> IEEE 802.15.4, and it was not extended until 2003 with the standard version.
> For example, if you review the lwIP document
> (http://www.sics.se/~adam/lwip/doc/lwip.pdf) it is not defined any reference
> to IEEE 802.15.4.
>
> The answer was obviously not, and in 2007 borns with this idea the first RFC
> about these requirements with the RFC4919, and after its consolidation with
> the RFC4944, it is defined 6LoWPAN!
>
> multicast, global addressing etc..., and it was defined the idea of contexts
> instead of the prefix addresses, which idea was consolidated in the last RFC
> for 6LoWPAN, RFC6282 in 2011. But, this continues without a suitable
> compression, such as it is presented in the first section from the document
> of Glowbal IP, but ok it is useful.
>
> constrained communication medium with a limitation of frame size to 27 bytes
> for the PDU!!!!!
>
> limitations to 27 bytes, and they are trying to move 6LoWPAN to Bluetooh Low
> Energy.
>
> Obviously, the current  6LoWPAN approach for Bluetooth Low Energy is focused
> on remove everything, limit it to local communications, remove even ports
> (defining a fixed port)... then when you analize this kind of approaches,
> and remember the Internet of Things goals, it is obvious that we are losing
> the link with the original motivation.
>
> For that reason, in 2011/2012 is defined Glowbal IP, which is a new approach
> to reduce the overloads to 5bytes, and define a solution suitable for
> LoWPANs such as IEEE 802.15.4-based, and also to satisfy the requirements
> from new technologies such as Bluetooth Low Energy
>
> Best regards,
> Antonio J. Jara
>
>
>> routers -- most "routers" today actually operate at layer 4.  So we found no
>> reason to re-implement IP at layer 3.  Instead, we developed a completely
>> different approach to layer 3 routing, we made sure IPsec could be
>> integrated, and we made sure UDP and TCP-based applications could be used.
>>  Surely, this is not how everyone thinks -- some users will want special
>> functionality from IP, and for those users 6LoWPAN is the clear answer.  But
>> for our market, all that matters are UDP, TCP, IPsec, so DASH7 is the clear
>> answer.
>>
>> Best regards,
>> JP Norair
>>
>>
>> exactly make IPv6 available for constrained node/networks. That may not take
>> away those constraints, and if you want to sell something else, it may make
>> sense to proclaim it silly.  Here, specifically, the guy is selling a radio
>> that is different from 802.15.4, so he's trying to malign 802.15.4, striking
>> 6LoWPAN in passing.
>>

---

From: Antonio Jara <[email-masked]>
Date: Fri, 27 Jan 2012 01:38:06 +0100

Dear Guillaume,

On Fri, Jan 27, 2012 at 12:41 AM, Guillaume Fortaine <
[email-masked]> wrote:

> go,
> I have already mentioned to you, one issue is to be able to embed a full
IPv6 stack, such as uIP, lwIP and Flexible IP are reaching.

Please, notice that lwIP is coming even before than IEEE 802.15.4 was
defined. lwIP was defined for embedded systems in general, for example over
Ethernet, where it has not so frame size constrains.

But now with the WPAN such as IEEE 802.15.4 and Bluetooth Low Energy, where
we have a constrained frame size, 127 and 27 bytes respectively, we are not
only interested in embed the IP stack and reduce the code and memory
requirements, we are also interested in reducing the header size, in order
to reach the higher payload capability.

That is the main reason because it is defined 6LoWPAN, and that is also the
main difference between lwIP and 6LoWPAN.

Glowbal IP is just a new generation of optimizations to continue reducing
header overload, assuming that each time new IoT technologies such as
Bluetooth Low Energy are focused on reduce frame size, in order to reach
high lifetime, reduce power consumption etc...

Remark, it is not only memory issues, it is also performance isues
regarding payload capability, overload from IP headers and lifetime from
the devices.

> [0]
> http://www.samsung.com/global/business/semiconductor/productInfo.do?fmly_id=804&partnum=S3FN41F&xFmly_id=802
> [1]
> http://linux-zigbee.git.sourceforge.net/git/gitweb.cgi?p=linux-zigbee/kernel;a=shortlog;h=refs/heads/6lowpan
> ROM
> go,
> [1],
> defined
> RFC
> for
> contexts
> too
> bytes
> Low
> focused
> approach
> take

---

From: Guillaume Fortaine <[email-masked]>
Date: Fri, 27 Jan 2012 01:48:31 +0100

Dear Mister Jara,

> to reach the higher payload capability.

I perfectly understand your goals. But you made one mistake in your
reasoning : you assume that there is a future for IEEE 802.15.4.

Not only, IEEE 802.15.4 doesn't provide the openness needed to be
supported by strong communities like the Free Software Foundation [0],
but also the industry is clearly moving towards Wifi that has the main
advantage to be available now :

http://www.slideshare.net/mkovatsc/connecting-things-to-the-web-using-programmable-lowpower-wifi-modules

So, on my side, I assume that IEEE 802.15.4 is dead. And I doesn't
seem to be the only one :)

Best Regards;

[0] http://en.qi-hardware.com/wiki/Ben_WPAN

On Fri, Jan 27, 2012 at 1:38 AM, Antonio Jara <[email-masked]> wrote:
> Dear Guillaume,
>
> On Fri, Jan 27, 2012 at 12:41 AM, Guillaume Fortaine
> <[email-masked]> wrote:
>>
>> Hello,
>>
>>
> Remark, it is not only memory issues, it is also performance isues regarding
> payload capability, overload from IP headers and lifetime from the devices.
>
>>
>>

---

From: Robert Cragie <[email-masked]>
Date: Sat, 28 Jan 2012 14:53:37 +0000

Hi Guillaume,

Some comments inline, bracketed by <RCC></RCC>.

Robert

> are outside the scope of this document."
<RCC>They are outside the scope of the document because it is outside 
the scope and charter of the lwig WG: 
http://datatracker.ietf.org/wg/lwig/charter/</RCC>
> need a bottom-top approach, hence my request.
<RCC>Of course, but the IETF is not about software engineering, it is 
about Internet protocols. The aim of the lwig WG is to provide guidance 
on the Internet protocol parts - that is all it can do within its 
remit</RCC>
> Engineering before dreaming of designing the "Internet of the Future".
<RCC>I think such statements are unnecessary and do not add anything 
constructive to the discussion. I can assure you that contributors like 
Carsten and others I work with have a superior knowledge of what is 
required to implement Internet protocol-based devices in low power 
devices with small footprints</RCC>
> people are doing : his homeworks :)
<RCC>I think it would behove the DASH7 Alliance to produce something 
akin to what the BT-LE folks did, i.e. produce a draft of 6LoWPAN over 
DASH7. To write off 6LoWPAN just because it was initially targeted at 
802.15.4 seems pointless; it is applicable to any low power wired or 
wireless technology which uses short packets and would benefit from some 
header/payload compression</RCC>
> On Thu, Jan 26, 2012 at 6:49 PM, Carsten Bormann<[email-masked]>  wrote:

---

From: Robert Cragie <[email-masked]>
Date: Sat, 28 Jan 2012 15:33:19 +0000

Hi Guillaume,

Robert

> advantage to be available now :
<RCC>In what way is 802.15.4 not open? I can download the standard from 
the IEEE free of charge: 
http://standards.ieee.org/getieee802/download/802.15.4-2006.pdf. Maybe 
I'm missing something, but the second line of [0] says "The primary 
protocols are IEEE 802.15.4 and 6LoWPAN" and further down the page it 
goes into some detail about using 802.15.4 over Wi-Fi (802.11)</RCC>
> http://www.slideshare.net/mkovatsc/connecting-things-to-the-web-using-programmable-lowpower-wifi-modules
<RCC>Whilst Wi-Fi undoubtedly has a place in the Internet of Things, the 
footprint is generally larger than that required for 802.15.4 devices, 
as is the power. In the above article, it points to the Roving Networks 
RN-131, which has 128K RAM and 2M ROM. This would not come into the 
class 2 as defined in 
http://tools.ietf.org/html/draft-bormann-lwig-guidance-01.</RCC>
> seem to be the only one :)
<RCC>There are plenty of people out there who would disagree with you. 
My personal view is that the future is about using IPv6 in 
easily-connectable subnets, thus extending the edge of the Internet to 
all devices in the home/office/etc. The IETF homenet WG is working along 
these lines too. We can already build home networks quite easily using 
Ethernet, Wi-Fi and HomePlug PLC but these tend to be based on MAC 
bridging; what is needed is an IP-based solution.</RCC>

> [0] http://en.qi-hardware.com/wiki/Ben_WPAN
<snip>

---

From: JP Norair <[email-masked]>
Date: Thu, 26 Jan 2012 14:12:09 -0800

Marketing is in some ways a dirty business, but it other ways it is completely necessary.  I do not intend to cheapen other peoples' work and research, but if I were not provocative this discussion would never have happened.  When we began thinking about DASH7 in 2007, the first thing we started doing was market research.  We did market research for three years.  As a result, we are not using 802.15.4 + 6LowPAN as a foundation for DASH7.

The 6LowPAN stack is a fine set of technologies, but there is no focus.  For US$2 embedded devices, focus matters.  In our market research, it became very clear that only three elements of the IP-stack mattered [to our market].  They are: UDP, TCP, IPsec.  Also, the market did not care at all about gateway vs. router.  Practically -- and especially with 6LowPAN edge routers -- most "routers" today actually operate at layer 4.  So we found no reason to re-implement IP at layer 3.  Instead, we developed a completely different approach to layer 3 routing, we made sure IPsec could be integrated, and we made sure UDP and TCP-based applications could be used.  Surely, this is not how everyone thinks -- some users will want special functionality from IP, and for those users 6LoWPAN is the clear answer.  But for our market, all that matters are UDP, TCP, IPsec, so DASH7 is the clear answer.

Best regards,
JP Norair

On 26 Jan 2012, at 09:49, Carsten Bormann wrote:

> he whole point of running the 6LoWPAN WG for the last half-decade was to exactly make IPv6 available for constrained node/networks. That may not take away those constraints, and if you want to sell something else, it may make sense to proclaim it silly.  Here, specifically, the guy is selling a radio that is different from 802.15.4, so he's trying to malign 802.15.4, striking 6LoWPAN in passing.
>

---

From: Joe Touch <[email-masked]>
Date: Thu, 26 Jan 2012 16:12:05 -0800

> Hello,
...
> Arduino (ATmega328) doesn't support Wifi.

There's a variant called the Diamondback that does, and we're currently 
using 60 of them in a building sensor project. FYI, the most widely used 
WiFi Arduninos are:

	BlackWidow (full-sized)		now DiamondBack
	YellowJacket (micro)		now RedBack

I.e., the left side are the originals; the right side are supposed to be 
pin and firmware equivalent variants that are still available.

They use a built-in shield based on a ZG2100:
http://www.microchip.com/wwwproducts/Devices.aspx?dDocName=en547511

It does have internal RAM.

Note, however, that there is a TCP/IP library for SLIP (serial-line IP) 
that works with just the Arduino's on-board memory and CPU, using 9KB of 
flash and most of the 2KB of on-board SRAM:

http://arduino.cc/playground/Code/SerialIP

 > You can add Wifi capability,

The ZG2100 is based on the PIC, not an ARM.

> Inputs at 12Bit resolution and much more.."

 From that site: "We plan a final and tested release by the end of 2011".

That as come and gone, and no public word about this has appeared 
anywhere except this blog.

The biggest current Arduino CPU currently available is the ATmega2560, 
with 8KB SRAM and 256KB flash.

FYI.

Joe

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 29 Jan 2012 11:25:13 +0200

Hi Joe, 

On Jan 25, 2012, at 12:52 AM, Joe Touch wrote:

> Arduinos have 32KB flash and 2KB RAM, and support WIFI and IPv4 (including DHCP, DNS, UDP, TCP, and a small web server).
> 

I am working with Arduino devices and there are obviously different types of types available. 

I use the http://arduino.cc/en/Main/arduinoBoardUno and it has the 32Kb flash and 2KB of RAM. There are versions that different hardware properties. 

It is interesting to note that I couldn't find an IPv6 implementation for Arduino and, depending on your application needs, the available ram and flash may not be sufficient.

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 29 Jan 2012 11:25:32 +0200

Hi Colin, 

the problem is that you do not only have IPv6 on your device but some application (+security) as well. 

Your example with buffering frames does not really mean a lot with respect to the hardware requirements if do not also state the assumptions you make about the applications. 

Ciao
Hannes

---

From: Joe Touch <[email-masked]>
Date: Sun, 29 Jan 2012 09:49:57 -0800

> I am working with Arduino devices and there are obviously different types of types available.

Yes, though currently available models don't vary widely on memory.

> I use the http://arduino.cc/en/Main/arduinoBoardUno and it has the
> 32Kb flash and 2KB of RAM. There are versions that different hardware
> properties.

Most of the variation is around I/O pins, processor speed, and physical 
layout - again, based on currently available models.

The Uno, e.g., uses the same processor on the Duemilenove (the basis of 
the Diamondback I use) and varies only in how USB is supported.

> It is interesting to note that I couldn't find an IPv6
> implementation for Arduino and, depending on your application needs,
> the available ram and flash may not be sufficient.

I typed in "ipv6 arduino" and found a stack fairly easily.

It does rely on an ethernet shield that itself implements ethernet, and 
has 8KB of packet memory. It includes a small web server as an example.

The WIFI shield on the device I use has hardware support for crypto, too.

Joe

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 29 Jan 2012 20:14:07 +0200

You are right about your observation regarding the differences between the Arduino variants. 

Regarding IPv6: I must have been blind when I tried to find it 6 months ago...
I will give the library at http://sites.google.com/site/ghoelzl/ipv6ethershield a try. 

On Jan 29, 2012, at 7:49 PM, Joe Touch wrote:

> It does rely on an ethernet shield that itself implements ethernet, and has 8KB of packet memory. It includes a small web server as an example.
>

---

From: Guillaume Fortaine <[email-masked]>
Date: Mon, 30 Jan 2012 03:30:25 +0100

Dear Mister Cragie,

> <RCC>They are outside the scope of the document because it is outside the
> scope and charter of the lwig WG:

True, but contradictory :

"Building a small implementation does not have to be hard. Many small
devices use stripped down versions of general purpose operating systems
and their TCP/IP stacks. However, there are implementations that go even
further in minimization and can exist in as few as a couple of kilobytes
of code, as on some devices this level of optimization is necessary.
Technical and cost considerations may limit the computing power, battery
capacity, available memory, or communications bandwidth that can be
provided. To overcome these limitations the implementors have to employ
the right hardware and software mechanisms. For instance, certain types
of memory management or even fixed memory allocation may be required. It
is also useful to understand what is necessary from the point of view of
the communications protocols and the application employing them. For
instance, a device that only acts as a client or only requires one
connection can simplify its TCP implementation."

> Carsten and others I work with have a superior knowledge of what is required
> to implement Internet protocol-based devices in low power devices with small
> footprints</RCC>

No. Especially, I have read with interest your presentation entitled
"The ZigBee IP Stack : IPv6-based stack for 802.15.4 network", slide
"IETF 6lowpan-hc adaptation layer",  p.10 [0] : This is totally no
sense. Where is the point of compressed IP packets on low power PANs ?

> <RCC>I think it would behove the DASH7 Alliance to produce something akin to
> what the BT-LE folks did, i.e. produce a draft of 6LoWPAN over DASH7. To
> write off 6LoWPAN just because it was initially targeted at 802.15.4 seems
> pointless; it is applicable to any low power wired or wireless technology
> which uses short packets and would benefit from some header/payload
> compression</RCC>

There are people working on this topic : "IPv6 on wireless DASH7 links" [1].

> <RCC>In what way is 802.15.4 not open? I can download the standard from the
> IEEE free of charge:
> http://standards.ieee.org/getieee802/download/802.15.4-2006.pdf

Yes, like DASH7. But, indeed, these two standards are flawed by design.

Best Regards,

[0] http://labs.chinamobile.com/attachments/wiise/MiracleW-3.pdf
[1] http://kurser.iha.dk/ee-ict-master/tienprau/ProjectProposals/Communication%20Technology/Engineering%20Research%20Projects%20-%206LOWPAN%20on%20DASH7.htm

Guillaume FORTAINE

On Sat, Jan 28, 2012 at 3:53 PM, Robert Cragie
<[email-masked]> wrote:
>>>  From a technical point of view, the whole point of running the 6LoWPAN
>>> WG for the last half-decade was to exactly make IPv6 available for
>>> constrained node/networks.  That may not take away those constraints, and if
>>> you want to sell something else, it may make sense to proclaim it silly.
>>>  Here, specifically, the guy is selling a radio that is different from
>>> 802.15.4, so he's trying to malign 802.15.4, striking 6LoWPAN in passing.
>>>
> <RCC>They are outside the scope of the document because it is outside the
> scope and charter of the lwig WG:
> <RCC>Of course, but the IETF is not about software engineering, it is about
> Internet protocols. The aim of the lwig WG is to provide guidance on the
> Internet protocol parts - that is all it can do within its remit</RCC>
>
>>
> Carsten and others I work with have a superior knowledge of what is required
> to implement Internet protocol-based devices in low power devices with small
> footprints</RCC>
>
>>
> <RCC>I think it would behove the DASH7 Alliance to produce something akin to
> what the BT-LE folks did, i.e. produce a draft of 6LoWPAN over DASH7. To
> write off 6LoWPAN just because it was initially targeted at 802.15.4 seems
> pointless; it is applicable to any low power wired or wireless technology
> which uses short packets and would benefit from some header/payload
> compression</RCC>
>>
>>
>>
>>> Anyway, for those who can't see this in their mail clients: the sentence
>>> with "From" is mine, not from the source cited by Guillaume.  Sorry for the
>>> confusion.
>>>
>>>  From a technical point of view, the whole point of running the 6LoWPAN
>>> WG for the last half-decade was to exactly make IPv6 available for
>>> constrained node/networks.  That may not take away those constraints, and if
>>> you want to sell something else, it may make sense to proclaim it silly.
>>>  Here, specifically, the guy is selling a radio that is different from
>>> 802.15.4, so he's trying to malign 802.15.4, striking 6LoWPAN in passing.
>>>

---

From: Guillaume Fortaine <[email-masked]>
Date: Mon, 30 Jan 2012 03:37:08 +0100

Hello,

> I use the http://arduino.cc/en/Main/arduinoBoardUno and it has the 32Kb flash and 2KB of RAM. There are versions that different hardware properties.

For your information :

http://mchck.org/

Best Regards,

Guillaume FORTAINE

---

From: Robert Cragie <[email-masked]>
Date: Mon, 30 Jan 2012 09:42:20 +0000

Hi Guillaume,

More comments inline, bracketed by <RCC2></RCC2>.

Robert

> connection can simplify its TCP implementation."
<RCC2>I think you are missing my point. When designing a system based on 
a constrained platform, many considerations have to be made for 
optimization. That is acknowledged in the statement above. However, the 
scope and remit of lwig (part of the INT area) concerns the Internet 
protocol stack part alone and even then, the implementation of the 
IETF-specified protocols. So, for example, there may be a novel way to 
represent buffers which provides a good optimization for a constrained 
system. However, this does not fall under the remit of the lwig WG. 
There are many good references outside of the IETF to obtain guidance 
for such areas of optimization.</RCC2>
> sense. Where is the point of compressed IP packets on low power PANs ?
<RCC2>Unfortunately, just stating it is "no sense" does not really give 
me a good position from which to discuss this further. Firstly, I think 
you mean slide 9. not 10. With regard to the statement "Where is the 
point of compressed IP packets on low power PANs ?": I presume you mean 
"where do I make the point?" as opposed to "what is the point?". The 
slide states "optimize limited bandwidth". I guess I could have 
elaborated further but this is a presentation and not meant to be a 
detailed discussion. For wireless especially, clearly shorter packets 
means less radio time, which means less power consumption as the 
dominant power consumption is usually the analog Rx/Tx. Also, these type 
of networks have more recently been described as "lossy/low power" (the 
"LL" in ROLL WG) where the two do not necessarily go hand-in-hand; it is 
possible to envisage a lossy network but not one which is low power.</RCC2>
> There are people working on this topic : "IPv6 on wireless DASH7 links" [1].
<RCC2>I look forward to it being submitted as an Internet Draft, like 
the BT-LE folks did. Antonio Jura and his colleagues' work looks 
interesting too and I shall read his paper.</RCC2>
> Yes, like DASH7. But, indeed, these two standards are flawed by design.
<RCC2>You are entitled to your opinion. There are many wireless 
standards out there and consequently many (IMHO often pointless) debates 
about which one is better than the other. As I said in my earlier post, 
I believe if the focus is more on enabling subnets on different MAC/PHYs 
to work together, then it provides a more level playing field and then 
the market can decide.</RCC2>

---

From: Guillaume Fortaine <[email-masked]>
Date: Mon, 30 Jan 2012 11:38:22 +0100

Dear Mister Cragie,

> <RCC2>I think you are missing my point. When designing a system based on a
> constrained platform, many considerations have to be made for optimization.
> That is acknowledged in the statement above. However, the scope and remit of
> lwig (part of the INT area) concerns the Internet protocol stack part alone
> and even then, the implementation of the IETF-specified protocols. So, for
> example, there may be a novel way to represent buffers which provides a good
> optimization for a constrained system. However, this does not fall under the
> remit of the lwig WG. There are many good references outside of the IETF to
> obtain guidance for such areas of optimization.</RCC2>

I don't think that I am missing the point. Please let explain me why.
The network layer IP is dependent of the MAC Layer, hence the need for
6LoWPAN on top of 802.15.4 which uses short packets. However, the MAC
is also tightly coupled to the underlying Hardware. Especially, I
would greatly appreciate to invite you to a further reading of the
paper entitled "The Lambda-MAC framework: redefining MAC protocols for
wireless sensor networks". To quote [0] :

"We feel that this is important because simulation is a poor guide to
how something as low-level and radio
hardware dependent as a MAC protocol will behave on real hardware."

Thus, my advice to have a bottom-top approach.

> <RCC2>Unfortunately, just stating it is "no sense" does not really give me a
> good position from which to discuss this further. Firstly, I think you mean
> slide 9. not 10. With regard to the statement "Where is the point of
> compressed IP packets on low power PANs ?": I presume you mean "where do I
> make the point?" as opposed to "what is the point?". The slide states
> "optimize limited bandwidth". I guess I could have elaborated further but
> this is a presentation and not meant to be a detailed discussion. For
> wireless especially, clearly shorter packets means less radio time, which
> means less power consumption as the dominant power consumption is usually
> the analog Rx/Tx. Also, these type of networks have more recently been
> described as "lossy/low power" (the "LL" in ROLL WG) where the two do not
> necessarily go hand-in-hand; it is possible to envisage a lossy network but
> not one which is low power.</RCC2>

a) "Firstly, I think you mean slide 9. not 10." : yes, sorry. for the mistake.

b) "shorter packets means less radio time  which means less power
consumption as the dominant power consumption is usually the analog
Rx/Tx." : you could also increase the throughput. Especially, Power
Consumption is becoming less and less critical due to recent advances
in Energy Harvesting. By the way, I would greatly appreciate to invite
you to a further reading of the publication entitled "Opal: A
Multi-radio Platform for High Throughput Wireless Sensor Network". To
quote [1] :

"Energy-efﬁciency has so far been a dominant design target in WSN
platforms, due to the limited battery capacity imposed by the device
form factor. However, recent advances in energy harvesting, such as
solar, have shown networks that can operate for years [1]. While
energy remains a key consideration, the focus on energy-efﬁciency has
so far sidelined other design considerations in WSNs, such as
communication throughput and range."

> <RCC2>You are entitled to your opinion. There are many wireless standards
> out there and consequently many (IMHO often pointless) debates about which
> one is better than the other. As I said in my earlier post, I believe if the
> focus is more on enabling subnets on different MAC/PHYs to work together,
> then it provides a more level playing field and then the market can
> decide.</RCC2>

802.15.4g is what I call a winner :-) :

https://mentor.ieee.org/802.15/dcn/09/15-09-0485-02-004g-fpp-sun-technical-overview.pdf

By the way, it removes the need for 6LoWPAN :

http://tools.ietf.org/wg/6lowpan/minutes?item=minutes79.html

"We do not need a 6lowpan over 802.15.4g document."

Best Regards,

[0] http://www.springerlink.com/content/17t7n74336v6qu57/fulltext.pdf
[1] http://www.es.ewi.tudelft.nl/papers/2011-Jurdak-opal.pdf

Guillaume FORTAINE

On Mon, Jan 30, 2012 at 10:42 AM, Robert Cragie
<[email-masked]> wrote:
> <RCC2>I think you are missing my point. When designing a system based on a
> constrained platform, many considerations have to be made for optimization.
> That is acknowledged in the statement above. However, the scope and remit of
> lwig (part of the INT area) concerns the Internet protocol stack part alone
> and even then, the implementation of the IETF-specified protocols. So, for
> example, there may be a novel way to represent buffers which provides a good
> optimization for a constrained system. However, this does not fall under the
> remit of the lwig WG. There are many good references outside of the IETF to
> obtain guidance for such areas of optimization.</RCC2>
>
>>
>>
>>> required
> <RCC2>Unfortunately, just stating it is "no sense" does not really give me a
> good position from which to discuss this further. Firstly, I think you mean
> slide 9. not 10. With regard to the statement "Where is the point of
> compressed IP packets on low power PANs ?": I presume you mean "where do I
> make the point?" as opposed to "what is the point?". The slide states
> "optimize limited bandwidth". I guess I could have elaborated further but
> this is a presentation and not meant to be a detailed discussion. For
> wireless especially, clearly shorter packets means less radio time, which
> means less power consumption as the dominant power consumption is usually
> the analog Rx/Tx. Also, these type of networks have more recently been
> described as "lossy/low power" (the "LL" in ROLL WG) where the two do not
> necessarily go hand-in-hand; it is possible to envisage a lossy network but
> not one which is low power.</RCC2>
>
>>
>>
> <RCC2>I look forward to it being submitted as an Internet Draft, like the
> BT-LE folks did. Antonio Jura and his colleagues' work looks interesting too
> and I shall read his paper.</RCC2>
>
>>
>>
>>> the
> <RCC2>You are entitled to your opinion. There are many wireless standards
> out there and consequently many (IMHO often pointless) debates about which
> one is better than the other. As I said in my earlier post, I believe if the
> focus is more on enabling subnets on different MAC/PHYs to work together,
> then it provides a more level playing field and then the market can
> decide.</RCC2>
>
>>
>>
>> Best Regards,
>>
>> http://kurser.iha.dk/ee-ict-master/tienprau/ProjectProposals/Communication%20Technology/Engineering%20Research%20Projects%20-%206LOWPAN%20on%20DASH7.htm
>>
>> Guillaume FORTAINE
>>
>>
>>
>

---

From: Robert Cragie <[email-masked]>
Date: Mon, 30 Jan 2012 11:48:47 +0000

Hi Guillaume,

More comments inline, bracketed by <RCC3></RCC3>.

In summary, I appreciate your contributions to the mailing list. I would 
rather not get into a debate over the merits of one wireless standard 
over another on this forum, simply because a) lwig is probably the wrong 
forum and b) it is subjective to a large extent and thus debate can 
ensue for a long time without making any real progress.

Robert

> Thus, my advice to have a bottom-top approach.
<RCC3>OK, let me try and put it a different way. I agree with a holistic 
approach to optimization which includes bottom up and top down; the 
application is equally important. So the aim would be for such an 
approach to reference guidance produced by lwig with regard to an 
implementation of an IP stack.</RCC3>
> Multi-radio Platform for High Throughput Wireless Sensor Network". To
<RCC3>Indeed, you could increase the throughput also resulting in 
shorter packets and thus less radio time; many 802.15.4 radios have 
'turbo' modes, which allow faster bit rates. There is usually a link 
budget cost though do to reduced chipping sequence sizes etc. but for 
devices in close proximity this may well be worth it. However, these 
modes are generally proprietary and non-interoperable. Power consumption 
and energy harvesting is an interesting area of discussion, probably one 
for off-list; similarly there have been good advances from some of the 
chip manufacturers in 802.15.4 radios</RCC3>
> "We do not need a 6lowpan over 802.15.4g document."
<RCC3>15.4g was generally created for carrier-grade longer range 
wireless mesh ("Smart Utility Network") as opposed to WPAN. I agree that 
the longer packets and generally higher power may make the need for 
6lowpan redundant. However, whilst fragmentation into smaller packets 
does have a header overhead, it can be a benefit in low power, lossy 
networks; if a long MAC/PHY packet gets corrupted, the whole packet has 
to be sent again, whereas shorter packets can be reassembled and only 
missed fragments need to be re-requested 
(http://tools.ietf.org/html/draft-thubert-6lowpan-simple-fragment-recovery-07).</RCC3>

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 30 Jan 2012 14:24:18 +0200

I think we drifted away from the initial discussion. 

We wanted to know whether 
a) additional classes are needed, and 
b) whether the currently proposed classes by Carsten need to be modified. 

I heard folks saying 
a) yes - we need a class 0 for very small devices, and 
b) the current classes need to be modified (although I haven't really seen a convincing proposal). 

I believe it also makes sense to briefly describe what we believe can be done with devices of the various classes. 
For example, a device from class 0 can already run IP, DNS, DHCP and a UDP/TCP based client side application with a pre-shared secret key based security mechanism. 

Ciao
Hannes

---

From: Guillaume Fortaine <[email-masked]>
Date: Mon, 30 Jan 2012 13:36:05 +0100

Hello,

> b) whether the currently proposed classes by Carsten need to be modified.

I would greatly appreciate to invite you to a further reading of the
document entitled "Java embarqué"

http://videos.rennes.inria.fr/irisatech/logiciel%20embarque/Fred-Rivard.pdf

This document gives a good overview of the MCU market and it should
help in providing guidance about the proposed classes.

Best Regards,

Guillaume FORTAINE

---

From: Joe Touch <[email-masked]>
Date: Mon, 30 Jan 2012 09:25:39 -0800

Hi, Hannes,

> b) the current classes need to be modified (although I haven't really seen a convincing proposal).

I gave a definition with two classes:

	Limited IP	<<100 packets
		supports ARP/ND, IP, and UDP
		can support DHCP,  TCP, and HTTP in limited forms
		typically does not support dynamic routing or complete
		versions of DHCP, TCP, HTTP, or other protocols

	Full IP		>>100 packets
		not limited in what it *can* support
		(might be limited by choice in what it *does* support)

IMO, the middle ground is fuzzy anyway.

Joe