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
