 Hello everyone, my name is Illa, very excited to be here. My talk is going to be about 6-Low Pan and Pica TCP and how to support new link layer types. But first of all, I'm going to give it a short introduction because afterwards I'll give a small, really small demonstration. Bit louder? Okay, so what is Pica TCP? First of all, Pica TCP is a better TCP IP stack for the Internet of Things. It's mostly backed by Alpine Intelligent Systems, those guys. And it's developed from scratch with an I only Internet of Things revolution. The first commit was in January 2012 where the three key goals were to make a modular and a qualitative and portable TCP IP stack. So for example, portable, it works with various operating systems on various devices, like for example, which talk in some hours, supports Pica TCP as well. Modularity, every module is so like, yeah, you can switch it down and switch it off, compile it in, compile it out, et cetera. And also, quality is a very high priority on Pica TCP. It's published under the GPLv2 license, but soon it will also be published under GPLv3, but more on that later. Then about 6Lopan, what is 6Lopan for those who don't know 6Lopan? 6Lopan stands for IPv6 over low-rate and lossy personal area networks. What's the name? I didn't invented it. It's an adaption layer, an optimization layer that doesn't really fit in the regular TCP IP protocol suite. It's squeezed between the network layer and the link layer between IPv6 and 802.15.4 link layer. This is how a regular standard 6Lopan stack looks like. UDP has a transport layer IPv6 with IPv6 neighbor discovery as well. 6Lopan, which provides a compression and fragmentation because those links, most of the time, have like an empty U of 135 bytes, for example, small anti-use. And so the frames have to be compressed and fragmented because IPv6 have 1,500 bytes in a single frame. So that's what 6Lopan provides. But most of the stacks are available. They only support like 802.15.4, which is really cool. And they also support Nomac that you just provide the 6Lopan buffer and do whatever you want with it. But I wanted to go a little bit further because there are a lot of new physical radios. Like radio standards like Bluetooth has a new standard coming out. Maybe you want it over any radio you want, IPv6 over those radio links. Then we should provide the capability to extend it further than only the 802.15.4 standard. So that was my goal really to do. Now I'll give you a small demo. Fuck code. So unfortunately I couldn't finish a real fancy demo with meshing and everything because I'm still working on the meshing part, which is a mesh under topology. So it meshes under at link layer level. But now I have a virtual demo. So we have a virtual radio network in Picot TCP that can simulate radios. And just to give you a sense of the flexibility of 6Lopan and Picot TCP, I just started some time events that changed the MTU of the device. For example to run at 27 to 80 bytes and later on it changes to 200 bytes. So it's really flexible. So the 6Lopan in Picot TCP and that to that. So I'll first start this. So this is the radio driver. Wait, I'm gonna compile again. Because a radio driver sometimes is a little bit... Yeah, it's not the best. But it works. Seriously, what the fuck? Seriously. This is embarrassing. So the radio... Wait, maybe I'll... No, no, no, no. I'm not gonna do this. Okay, but I've added a PCAP driver that captures the device's messages that it sends. And so we're now probably going to see this one. So now first of all we have an MTU of 125 bytes for IEEE 802.15.4. So the fragmentation and the compression layer adapts to that. But after a while the MTU has changed to 80 bytes. Where is it? Ah, here. And then the adaption layer, yeah. It just compresses it and then fragments it further to 80 bytes. And then at a later point the compression doesn't leave it anymore. So it just... It has an MTU of 200 bytes and it fits inside an entire packet. And it doesn't need to fragment it and compress it anymore. So that's just to give you an idea about the compression, the flexibility of a 6-lopen. And so how does 6-lopen and Picatissipi look like? We have the IPv6 module, the 6-lopen module, which provides the compression and fragmentation. And then we have another module, 6-lopen link layer. And this allows to easily interchange the MAC layer, the link layer itself, to provide support for other devices. By the way, the same application is running at the moment on these two devices. Just a blinky application that... That's it. How does it work? So when IPv6 wants to send a frame, so we have the IPv6 module on top, the 6-lopen module and then the 6-lopen link layer module. So every module in Picatissipi looks like this. Every protocol has its own two queues, like the in-going queue and the outgoing queue. They can hold multiple frames at once. And then next to that we have the Picatissipi stack itself, with the scheduler and everything, and functions. So if IPv6 wants to send a frame, it sends it to the stack, which endures it into the 6-lopen queue, outgoing queue, after which at the moment, at some point, the scheduler calls a process out of the 6-lopen and decays it, and then starts processing it. And what does it do? It first gets the link layer addresses from the neighbor discovery table, from the IPv6 addresses, and then it immediately pushes the frame to the 6-lopen link layer to check if it fits inside a single MTU. And if it doesn't, the link layer is going to give back the available bytes, and then the 6-lopen adaption layer starts compressing and fragmentation. And then eventually when it does fit, then it endures it in the outgoing queue of 6-lopen link layer module. And then afterwards, the scheduler calls again the 6-lopen link layer module to process the frame, and then it goes to the device driver eventually. So that's how it works. The 6-lopen link layer itself is based on extensions. So we have several extensions that we can add and remove from the link layer. And so two are currently installed like PicoMesh, which is on which I'm working now, and 6-lopen link layer Mac, and they have to provide three functionalities, so estimation to see if they prepare the header for processing if the available bytes is sufficient for the 6-lopen frame that has to fit in it. Process in is just when an incoming frame has to be handled and process out for an outgoing frame. And so we define a 6-lopen link layer protocol structure to make it easily interchangeable for different protocols. And they have to implement these functionalities. So process in, process out, and estimate are just explained. And estimate is double, sorry. And then address from network because it has to translate IPv6 address to a link layer address. It has to get it from the labor discovery tables or something. It has to know the length of the address, the link layer address. It has to be able to compare the address and also to derive an interface identifier, IPv6 interface identifier from the link layer address, which can be derived from the extended universal identifier 64-bit or from 16-bit short addresses. So we define Pico link layer address for that so that it's a generic version of link layer addresses. Then Pico device, a 6-lopen device, just has two functions. It has to implement sent and pull to transmit the frame on the wire and pull to see if something has to be done or an incoming frame is... Yeah, there is an incoming frame or something. So if you want to implement 6-lopen for your radio, you have to write the device driver first of all. Define how you're going to use addresses like EUI 64 extended addresses or short addresses. Then write some helper functions. Register them in Pico TCP with that device, on the initialization of that device. Then it just works with that implementation of the link layer protocol and then you're done. So I have spent a while implementing 6-lopen and I have some thoughts about... Well, it is actually a good 6-lopen because it's kind of weird if you think about it that it says IPv6 over low-rate and lossy wireless networks, but for low power it's kind of weird because so the entire TCP IP stack says... Yeah, okay, here's my framing, here's my formatting, IPv6, etc. Then 6-lopen says at once like, yeah, fuck it, I don't care. I'm just going to remove it all and compress it and it's kind of computationally expensive to do so I find it kind of weird that it's... So low power, I think it's more easy to... But the good thing about 6-lopen is that it's standardized TCP IP future sets you can use. You can use fancy things like DNS for example or co-op or... A cool thing, I also worked on DNS-based service discovery on Pic2CP which is kind of cool if every device registers their own service and then now it's on the network through 6-lopen and that would be really cool and you have these sensors with their own service they can provide, announced on the network. So quite low power applications. Mestopologies with IPv6 addressing and also another application would be to bridge different radio links like I just said. You can also... Like this device can, for example, support IEEE 802.15.4 but another device with the same stack can use Bluetooth low energy for example. So that's kind of cool to have and with these different protocols everywhere this is maybe not a bad idea. So this is my final slide. Pic2CP is going to have a release next week which includes 6-lopen support and GPLv2 3-licensing plus GPLv2 2-licensing and that's it. Are there any questions? Don't forget to repeat the question. About the licensing and about the software and about the phone application it's not a problem. GPLv2 3-licensing because you static link inside the firmware how does it work? For example, we want to use it. We have to open a show-off application. So the question is how does it work with GPLv2 and GPLv3 licensing with static linking on embedded devices? What if applications have to use GPLv2 and GPLv3 as well? I have to be honest, I don't know a lot about licensing. I know. So I'm maybe going to give the word to Ferdic. Will you repeat for the recording then? In very brief, if you use the GPL version then there is also a commercial option available for people in the city where they can pay their license and then you are allowed to repeat for the source. So if you make money with it you can pay your license. Can you repeat for the recording then? So there is also a license for commercial applications and then if you pay for it you can use it in your proprietary application. So that's any more questions? Yeah. I have a question about all the compression schemes you are supporting. So there is the old HCE1, HCE2, there is IPHC. Yeah, yeah, yeah. And you are also supporting next set of compression? Yeah. So the question is there are different compression schemes in 6-Low-Pal like HCE0 and HCEUDP in RFC44 but they are a little deprecated so we don't support those. We support IPHC compression and next other UDP compression we support. It's also in the same RFC but there is also the generic which is coming out in, it's a proposal, RFC proposal I think. It's already available? It's already available? Yeah, okay, yeah. So the generic header compression we don't implement yet. More questions? Yeah. And just the health functions and they are just in space they have to do in your advice program to, you know, talk. Yeah. Yeah, you can. Yeah, sorry. So the helper functions. Yeah, it's just in space. Yeah, it's the interface with a link layer. Like, yeah, sorry. And no, here. Yeah, it's the interface with the link layer protocol. So those, you can register them with the initialization of the device. So you can assign a different link layer protocol to any, I mean, to a different device. So that makes it, yeah. Yeah. Well, with a lot of people, I call TCP, do you actually do TCP? Yeah, we do TCP. Oh, yeah, sorry. So the question was, we're called Pico TCP. Do we actually do Pico TCP? Do we do TCP? Yeah, we do TCP as well. But that's not really advised with 6Lopan because they're lossy networks. They're connection. It would be better to use a connectionless protocol like UDP. So a standard 6Lopan stack most often uses UDP for that. Do you know about the footprint in memory and energy with some TCP instead of TCP? I wouldn't know. TCP requires somewhat more. But now with UDP we have, I don't know, around 100K flash. But that's with the buggy symbols in. So if we put TCP in, I wouldn't know exactly how much it would add to the stack. There have been talks about Pico TCP in this death room or in the embedded death room previous years, which focus on the TCP part and on the memory footprint and size. So you could check those and then you'll get a lot of figures and I guess also on your website. Yeah, yeah, yeah. But they're not related to the 6Lopan. Yeah, indeed, yeah. Because we support other protocols. This is just the 6Lopan part of Pico TCP. It's only a small part. We do much more than only 6Lopan. Any more questions? Okay, thanks a lot.