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 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
