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
