Dear Mister Jara, Thank you for your reply.
> 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. 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 -- Guillaume FORTAINE [email protected] DevOpSpace http://www.devopspace.com +33(0)631.092.519 On Fri, Jan 27, 2012 at 1:38 AM, Antonio Jara <[email protected]> wrote: > Dear Guillaume, > > On Fri, Jan 27, 2012 at 12:41 AM, Guillaume Fortaine > <[email protected]> wrote: >> >> Hello, >> >> >> > 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. >> >> 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 ? >> > 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. > >> >> >> >> I would prefer to discuss these things from a technical angle, not by >> >> 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 protected] >> DevOpSpace >> http://www.devopspace.com >> +33(0)631.092.519 >> >> >> On Thu, Jan 26, 2012 at 11:56 PM, Antonio Jara <[email protected]> wrote: >> > 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 protected]> 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 >> >> >> >> >> > > > _______________________________________________ Lwip mailing list [email protected] https://www.ietf.org/mailman/listinfo/lwip
