 So the next talk is about high-performance open-source and high-performance networks by Jeremias. Please give him, welcome him with a big round of applause. Hello everyone. So, yeah, welcome from my side as well. I'm glad that a few people showed up. It's going to be about open-source and high-performance networks. With high-performance networks, what I want to say is, I mean these kind of boxes down here, which I would say are, as a comparison to other devices, low-performance, I would say software switching or software-based networking. And there are even bigger boxes, which are basically much, much bigger, with many, many more ports. And, well, there are different scales. So I'm going to specifically talk about this kind of size of a networking device. Okay, before we go into the details, I have a bit of history, which is probably not 100% accurate, but I want to motivate why I think that open-source is quite important in networking. If you look at the year 2000, I remember back then I was an administrator for a firewall, and it was a Sun Ultra Spark. I don't actually remember the exact model, and it went Sun Solaris, and Solaris is a commercial operating system, and there weren't any VMs back then, and everything you did was manually more or less, and maybe some shell scripts. Now, if you move 15 years forward, what did change? Now, as you probably know, a lot. So first of all, most of the alternative hardware is dead today. You rarely see any Sun hardware or IBM hardware anymore. There are new systems like ARM, but to my knowledge, they're not really widely deployed as of today, and as of 2015 even less. So what kind of operating systems do we have? Well, it's more or less just Linux. Everything else is not really used in computing, and of course there are loads of management systems. So there are really cool stuff. There is virtualization in every kind of flavors. You can have virtual machines, you can have containers, and you can even have something like Unicernals, which are like very, very small virtual machines, and you get all this kind of software stuff that comes with it. You can run small scripts that set up your whole network. You can use Kubernetes to configure an application and automatically start like hundreds of VMs around the globe, but that's pretty cool stuff. So I really like that, and I think this is really what progress looks like and should look like. Now, if you look at networking, what did we have in the year 2000? Again, back then, I remember we had Cisco stuff. Actually, I never saw Juniper, but apparently it existed back then as well. Then Loosen Technologies, I'm pretty sure that it existed back then. About Alcatel, I'm actually not completely sure. Well, let's just assume they had switches as well. The average interface speed or the good one was one gigabit, and the protocols, just a few examples here, are basically Spending Tree, MPLS, and the usual interior gateway protocols like ISIS or OSPF. And I remember back then, if you use Spending Tree, it was really a pleasure because if something went wrong, you have to wait for a minute until everything was back to normal again. So it was not really ideal. And for management, we had CLI and, well, the dreaded expect scripts basically automated CLI. And now, of course, we are all very excited because we hope the same thing that happened in compute will happen in networking as well. Unfortunately, that's not the case. So if you look at the hardware and software, Alcatel, Loosen, and, well, basically they merged together Alcatel and Loosen, and now we're about by Nokia, everything else is the same. There's still Cisco, there's still Juniper. If you look at the interface, that's pretty cool. We now have 100 gigabit interfaces. That's pretty nice. That's 100-fold increase. And when it comes to the protocols, it's kind of disappointing. We now have the rabbit Spending Tree protocol. It actually works, which is nice. Then we have MPLS and I have never used it, but people tell me now it works and in 2000 it didn't work, which is also, it's okay, but it's not really the thing that you would expect or hope for. And I don't know if there were any big changes in the SIS or OSPF. I'm not into that too much, but they are still there, maybe some extensions. And, well, the management where there was so much growth in the compute area, there's basically nothing. So still have CLIs, we still have expect scripts. In 2015, there was already NetConf, but I remember when we tried to buy a switch at university, most of those that you could buy back then, they didn't even support NetConf. So this is really, really disappointing and really sad. And this is kind of, I don't know, the compute guys have so much cool stuff to do and networking we don't. Of course, still the speed is very, very nice, but everything else is kind of disappointing. And one question, of course, is why? And of course, I don't have the answer to that, but I think if you compare the two right sides of the previous slides, you will see that one distinct feature is that in compute, we have basically Linux for everything. And Linux is open source, everybody can propose their own changes. It comes with an organization that manages the progress basically and well, in networking, we don't have that. So my guess would be one reason is a lack of openness in terms of hardware specification and, of course, in open source. And of course, I mean, the companies in this area, they want money. I mean, that's their job. And if they can make money without having any progress, I guess, why not? That's my guess here. And apparently, customers don't care. Customers don't care. I'm not really sure why. But there have been some change recently. There has been some openness. You will see that later. And I think we are now at a point maybe where the computing industry was maybe in the 90s or even in the 80s. And hopefully we will see the same progress. And of course, I mean, this progress thing is not the only thing I would hope to get from open source but also the usual security stuff. It's much harder to plan any back doors in open source software than it is in closed source software. So that's my reason why I think open source would be pretty cool in networking as well. And the thing is, there are already some opportunities on how to use open source today. My impression was at the last Karl's Communication Congresses I attended that there's not much, too much awareness of this. And there are very few talks on the matter. One exception was this demystifying network cards from Paul Emmerich, which is really, really a good talk, which again shows the specification of the network cards. He discusses they are open for some years now, but nobody bothered to write his own driver and he did. So that's pretty cool. And well, the goal of the talk is basically to show you what kind of stuff you could do today with open source and open things. And my approach here is I will first give a short introduction on how I see networks work today. And I give an overview on the APIs and specifications and then I will go a little bit into more detail onto the different data plane API models. But that exactly is, we will see later. Okay, so, yeah, how does this switch work? So we have this box, we've seen that before. Hopefully everybody of you has seen such a device before. It's not, here's a picture, which in this case has 65 ports, which is quite a lot for such a small switch. If you open it, and this box has like 20 screws, so that's really a lot of work. You see, well, again, those ports. These are the physical encasements of these ports. And then we have this huge cooling device. And well, I guess these are fans, but you can't really see much. So we'll have another photo. And this is from the top. Again, here in front are the ports. Here's the huge cooling device. And these are fans, and these are the power supplies. And then we have all these small things that we really can't see. So I highlighted them. And first of all, there's the forwarding chip. So all the ports are directly connected to the forwarding chip. In this case, a barefoot toffinu chip. Then we have a management port. We saw in front, which is a copper port, like a 1 gigabyte usually. And then it turns out it's just a normal PC inside. In this case, it's rather a beefy computer, but still it's a normal computer. So the forwarding chip is attached to the CPU with the PCI bus. The same goes for the NIC. And so in the end, although it looks very different, in the end, it's more or less just a PC with a huge networking card. Yeah, so that's a single device. Now, how does this stuff work in a real network? I have three very small network here as an example. I have three of these devices. Now, I'll extract it a little bit to make it more visible. And we have packets going from the bottom left here to the top right. And let's see what kind of different architectural aspects we can find here. So we have basically this packet processing path, which we call the data plane. It's basically this ASIC thing we saw before. And this does all the packet handling. Then we have the control plane, which is the server, the x86 CPU we saw before, which is there to basically to configure the data plane. It's not involved in the packet processing. And all these small CPUs here, they run different routing protocols. And the network works in a way that all these control plane computers, they talk different routing protocols, they exchange information. And using these information about the topology of the network, for example, they configure their local ASIC and make sure the packets are forwarded in the right way. And then we have a third plane, which is the management plane. Here it's a manual thing. So if you log into your switch and configure it and change some parameters, that's what you could call the management plane. And because it's not abstract enough, we will go one step further and make it a little more abstract even. So we have a data plane with all the special chip stuff. Then we have the control plane CPU, which is like a normal PC. And we have a new thing here, which is centralized control. So there are some cases where you want either parts of the complete and control plane functionality. So the functionality that decides what the chip actually does, you might want to have this on a different computer. And this is called software defined networking, or in BGP you often use a router reflector, which is somewhat similar to that kind of thing. So the control plane actually is not only the CPU that's directly attached to the switching device, but might also be a remote server or something. And then you have the management plane, which is monitoring and usually involves human work today. So this is the overview about the network architecture, as I see it. And I mentioned SDN, and I think I should quickly introduce what I mean with SDN. I think software defined networking has been a buzzword for some years now. Usually if I talk with people who work in this area, they don't like the word. But it has actually meaning that it goes beyond marketing. And that's why I will introduce it in the next slide. Before we go further, I will now focus on the control plane, data plane part, and skip the management plane. I know all the progress we saw in the compute area came from the management plane, but I think we are not there yet. We still have to figure out how to do this stuff automatically. Once this is done, you can do also a lot more in the management plane part. Okay, so what's SDN, or what's my view of what the most important feature of SDN is? We again have our small network here, now a little bit simplified. Again, data plane and control plane in one device, and they all speak these protocols to make the network work. And the idea behind that is that you have different devices from different vendors, and the standardization is through the protocol that communicate between the boxes. So you could think of a vertical, at least in this figure, a vertical standardization. Now the idea of SDN is specifically to change the orientation of the standardization. And you do that by removing the control plane part from the boxes and put it into a central location, which in this case is just a single server, but usually you wouldn't have a single server, you would have some kind of a cluster or something. So it's in general the separation of the control and data plane. And often even remotely, I mean theoretically you could run this on here, but then you have the same setup as in classical networks. And now the original idea of SDN was, or the hope was, which I think didn't really work out, that you now have a vertical standardization. So we have a standardized protocol in this case, in this example it's open flow. And the idea was that you can have a single control plane and you can have a standardization in that the interface that the switch speaks to the control plane is always the same, and thereby you get the same level of standardization just from a different perspective. So that's my view on SDN. Basically you can run the actual control plane somewhere else. It's actually quite simple I think. Okay, now back to the devices. There are different approaches on how you can run software on these devices today, or basically just how you can buy these devices. You've seen this before. You have the switch here, and the switch has a CPU, which is basically this part. You have a forwarding ASIC or a chip, and we have our port. Now, if I buy a box today, it looks like this. The box I get from Cisco or Juniper or whatever other vendor is closed. I get a complete stack of software. I can't open it like Windows PC or something. And from an open source perspective, that's not very nice because I can't do anything myself. So the routing software stack is usually closed source. The operation system is closed. It might be based on open source operating system. Often it's based on something like FreeBSD or NetBSD, but you can actually change it on the actual device. And of course the chip. The specifications are closed. And the interface that the operating system uses, or the software uses to talk with the chip, of course is also closed source. So there's actually nothing you can do with these devices. You can use them, right? But if you have a great new idea, it kind of sucks. And they tend to be quite expensive. Now, there's this software defined networking idea, which I mentioned before, where you have a shift basically where you move this part, these OSP FPGP and so on software demons, where you move them on the centralized place on a different server. And then you can still buy these closed boxes, but it's not that bad anymore because you can still run your software as open source, which is already quite nice. Of course it has a dead advantage that everything is remote, so you have to check if that works for your use case, depending on what you want to do. But the cool thing is now you can run most of your things as open source software. And if you check, there are a lot of projects. I didn't include it in the talk, but if you Google it, there are hundreds of open source projects that deal with exactly this part, where you can get an open flow or general networking OS and run open source software with actually hardware switches, which is nice. But still not the thing that we actually want. Okay, then there's this thing called the metal switches that came up a few years ago. And the idea of a metal switch is that it's the same model as if you buy a switch from a Juniper or Cisco. It's just that you get the switch without software, basically like if you buy a PC without operating system. The problem now is these, this forwarding chip, the specifications are, to my knowledge, none of the cases is available online. So you still have the problem of how to access the chip. I mean, you can now run here. You can run Linux on this thing. There are a lot of projects who have mostly Debian-based Linux that actually come with some kind of driver here and you can run your own router software there. So that's, again, like in software defined networking, you can have your routing stack in open source, which is pretty cool and it's done today. And it has also the slight advantage that these things are usually cheaper than if you buy the Metisco or Juniper. But from an open source perspective, there's still the problem that in many cases this device is not open sourced. And there is one exception, however, and this is Metanox and we will later see in detail, but they released the driver, which is integrated into the Linux kernel and it's completely open source. Although I actually don't know how much of the chip specification is actually open. So I guess you can read the code in the Linux kernel, but I'm not entirely sure if they made the entire specification open. So there's one way to use this, like with Linux kernel, the Switch Dev, and another way is that something from Broadcom, it's called SDK LT. It's a C library which you can use as a basis for your own applications, but actually I haven't looked into there into detail and I don't really know how well it works and how open it actually is. Okay, that's option three. It's cool because now we can have our own software. And I think everybody should. First option, and it is just quite a new one, is called Programmable Hardware. What does this mean? This means that I have a forwarding chip, like today I have an x86 chip from Intel or AMD and I can write my own program for it. And the cool thing is here, you can do the same thing. You can write your own forwarding program. It is really cool. It has, of course, a slight advantage that this part from all vendors I saw today is still closed. So it's still part of the pipeline is closed source, but you can write your own forwarding programs, which means that you can, I don't know, if you have a nice idea on a new protocol, you can write it yourself. That's pretty cool. Usually or today, I think the only credible language that you can use is called P4. And if you do header processing, you can basically do everything you can think of with that language. And you can actually, by hardware, do it. Which is cool. But again, if it gets more interesting like something else in hardware than header processing, you usually end up having proprietary APIs. So in terms of features, that's pretty cool. In terms of openness, still not there, but that's where we are today. And I hope at least this step opens up a few new possibilities, because I mean, you can write these programs and you can publish them as open source. But I think it's really cool. Now to the open source part. So we've seen a lot of different elements which play together. And if you write something, it's right software. It's usually all about the interfaces you can use. And this is what I try to sum up here. I'm not sure if this is the perfect abstraction layers, but it is one. And it hopefully is enough to explain what I'm talking about. So it's again the same thing that we saw before, but a little bit abstracted. Again, for a specific use case that you write software. So you have your chip, which is, I don't think it will ever be really open. Then you have a data plane pipeline. If you have a programmable chip, you can write your own. You can write your own pipeline. If you have most chips that you buy today, they are fixed function pipelines, which means the pipeline is given. You cannot change it. But hopefully, or in some cases, you still can see how the pipeline works and can program it. Then you have the actual driver to the pipeline, which can be open or not. We've seen before that today, in many cases, we have open source drivers, or in some cases. And that's the actual thing that you usually think about. You want to write an application and do something in the network. That's by usually care for the control application. And each layer here is something that you usually could have a specification on. And each arrow is an API, more or less. And now, of course, you can think about every step here, but we will focus on this part. So basically, how would I call or how would I talk with my control pen application with my chip driver? How does it look like? And I think that's the most interesting part here. Okay. Now, the question is, what's an API? And how does it help us to understand which point is the right point if I want to do something with open source? Where should I start? And, yeah, as I said before, if you write a program, you usually write it against an API. An API is usually just a list of functions, but implicit, if it's not explicit, you have a data model of things that you can actually talk about. You have functions that you can call, and you have protocols, usually something like a list of or an order in which you have to call specific functions. And, well, it's kind of a simple language, an API, and it tells me what I can talk about and what I can express in this API. And if I write a program for a specific API, I'm usually, well, attached to this API and have to go with it. And, of course, there it helps if I have some kind of standard, at least some kind of standard way of thinking, right? So if somebody comes up with a great new idea, it takes time to learn that. So it usually helps if you have some kind of standardization. When it's not in the exact API, then at least in the kind of thinking that you have. And that's what I would call data plane models. I'm not sure if this is the best name, but at least that's my take on it. And in the classical networking case, if you do networking today, mostly, at least that's my impression. What you think about is you have routers, you have switches, and usually everything uses a middle box. What does that mean? Well, a router takes an IP address, checks for the destination, IP address what takes a packet, checks the destination IP address, has some kind of routing table, or if it's in the data plane, it's actually a forwarding information base. Checks which interface it should go to and what's the next top, rewrites the destination, make address, and sends out the packet. So that's the general idea. Of course, today you have some advanced functionality like tunneling protocols and queuing. But in terms of header processing, for example, that's usually what you think about. A router forwards packets, that's it. Then you have switches, which is similar, but just based on the MAC address, and you usually don't even modify the packet at all. That's a nice thing. If you have a very simple network, that's usually a cool thing to have, and it really helps you to think about networks because you have some kind of, you have to have some kind of mental model for it. The problem is everything that's not a router or a switch is the middle box. And a lot of things you have today in networks are middle boxes. And that's kind of, well, it's not ideal, I would say. On the other hand, of course, it's really good. Everybody knows this kind of stuff. It's well understood. Linux kernel, for example, is based on this kind of model. Most of the routing stuff that you find today expect this kind of interface. And most hardware, even that you can buy today is the same. They are based on this model. The disadvantage, of course, is if you want to do something else, something different in routing or switching, you're kind of lost because usually these interfaces do not allow this. So if you have a great new idea on what to do in networks, you probably aren't going to be able to do it with this kind of API. Nevertheless, of course, these are very useful if you just want a router or a switch. And there are different implementations of these interface. One of those is a switch abstraction interface that's from the OpenComput project. And if you buy, for example, a switch from Broadcom, you can get a software that actually offers you a switch abstraction interface. I think most vendors today do this. So it might be closed source, which in this case, these cases I listed here are. You don't need a closed source binary driver. But at least you have an open interface. So if you just want to do routing and switching, you can more or less buy every bare metal switch on the market and you will get this for free. Which is also nice, already nice because, well, you can write your own software and you don't really need to buy a Cisco switch anymore. Another approach is Linux Switch Dev. I mentioned that before. This is completely open source. It's really cool and really nice. And it's completely integrated in the Linux kernel, as I understand it. The only drawback is that the only supported device to manage is this SN2000 series from Anamox. And these devices are really, really expensive. So this is kind of a drawback. So if you want to do something yourself, I'll have prizes in the end. But they are like something like starting at 15,000 euros. Even at our university, we were not able to convince anybody to buy us such a device. So, yeah, this tradition is the classical fewer networks. It's nice. It can work today. If you just want to do routing and switching, if you want to do anything else, that's not really the thing. Then we talked about software-defined networking before. The software-defined networking idea comes with the OpenFlow standard. And that, as you hopefully remember, was this protocol. You can speak with your centralized controller and your data plane box somewhere in the field. And the OpenNetworking foundation came up with this. And the idea is to abstract this model or to generalize the model of the router and the switch that we discussed before. So the idea is to find some more basic things you can do on packets or you can structure your pipeline to make sure that you can express more things that are not just limited to routing and switching. And the ideas they had was well, in some way, or if you buy a switch today, they are mostly a pipeline of tables. And in these tables, it's usually like this. You get a packet in. You have, they call it a flow table in OpenFlow, but could be a routing table in a classical router. You have some kind of measure in a routing table. This would be you match the destination IPv4 address. You have an order of rules and the first tool that matches has attached some instructions on what to do with the packet. If it's an IPv4 router, you would say decrement the time to live and send out on this port and at this MAC address. So this is the basic idea. And if you think about it, you can do most of the things you can do in networking so the OpenFlow ideas, you have a lot of these tables and you can change the packet on the fly with these instructions or basically collect instructions that are executed in the end. So it's much more abstract. I hope it's not too abstract to understand, actually, if you haven't seen this before. But the general idea is you take a packet, you pass the headers, you have a series of tables you can match for specific tables in the tables and if the packet matches for the same rule, you would call it a flow and that's why it's called OpenFlow and by doing that, you are quite flexible and it's kind of a neat idea. One thing that you should remember, of course, when we talk about pipelines is that you have this series of tables but you can never get backwards. Basically, you cannot have a loop because if you want low latency you cannot have loops that doesn't work. So the idea is that in the pipeline you always go forward, never backward. That's the basic idea. Now, in the implementation it turned out it wasn't while the idea is cool, it was progress but it didn't really work out in the end. This is an example for an actual broadcom switch and it's actual OpenFlow tables. As you can see, there are a lot of tables and the point is this is again a model, it's not the actual hardware so it's still an abstraction layer and what's interesting about this, and this is something the OpenFlow people found out very late is that I think it's hard to read. So this is basically the incoming port and then you have a series of tables ingress port, relan, MAC termination unicast routing, policy ACL and I can't even read it myself. Bit of contrast next time. So the point is this is the classical pipeline thing that we saw on the last slide. The problem is not all of these tables are the same so they are very different. So there are tables like the policy ACL where you can have more complex matches where on the other hand you have this ingress port table which has a very very restricted set of operations you can do in this case here's the match that you can match the import and the ethernet type and everything you can do is you can go to the wheel-end table okay and if you thought about the pipeline model in the last slide when you read it the first time you envision much more complex things and in any case it turned out that OpenFlow didn't think about this early enough so they had to come up with some kind of additional concept where you could restrict the actions or the things you can do in a table because in the end if you write your program you don't want to change your program from every switch the idea was originally that you have one interface you write your program and you're done now if you have to change it for every switch because every switch is different and have different features here the attributes that's not really working out and it's actually still not really solved today so but this wasn't the real drawback of OpenFlow I think the reason why it nowadays it's pronounced that so stuff still exists and I think it's very interesting to use as an example for centralized controller network the protocol itself is probably not going to see big deployments anymore the cool thing about OpenFlow is we had this idea of this match action tables which is a really really good idea and you could have remote controllers which is also very nice in some use cases I think now the main problem was that the matches and action fields they were defined in the standard and you can see here an image it's taken from a paper it's from 2012 this one and you can see in OpenFlow version 1.0 the number of different match fields in total we're 20 and with OpenFlow 1.4 we had much much more we had we think 41 different match fields so basically every time somebody comes up with a new protocol you have to come up with a new match field and you have to change the standard that's not the ideal approach and the same thing goes for action so basically if you can remove a specific header field or write to it it's always a different action and every time you have something new it has to go on the standard so I would say it was a nice statement in the right direction but it didn't really work out because if you have a new protocol you still can't do it and it's much more complex than the traditional networking model like I said that in the traditional abstraction layer you can just tell the router, install the router and you're done and here you have to do it yourself so it's more complicated but you don't really have a reward for it so it's nice but probably mostly academic now these people thought before we go on there are two examples of stuff that you can actually use if you want to try it out in university there are mainly two different open-flow implementations one is from Broadcom it's called OFDPA and it's important because if you buy a switch today Broadcom switches are simply the cheapest while still being reasonably good and I'm actually working quite nice if you want to have a switch I'll show that again in the end if you want to do something yourself of course there's a drawback that the driver has closed but still you can download it on GitHub so it's nice if you want a little more convenient approach because the OFDPA model is not always adhering in all the details to the open-flow standard you can use PicoS which is an open-re-switch based open-flow agent however you have to pay for it, it's closed source but it has some neat options for example you can combine the traditional routing and switching model with the open-flow pipeline embedded in it so you can do very interesting things again if you want to use it in production I don't know but for experimenting I think it's quite nice okay now to the next step in the development which is called P4 so we've seen the switch abstraction layer the traditional approach where you have routers and others in switches and now the same guys who did open-flow thought well why not do the next step and they came up with a thing called P4 I can't actually even really say what P4 is it's a language, it's a specification it's an architecture they're putting a lot of stuff in there I used it first and foremost as a language but it comes also with an architecture so what's the idea it's basically just the next step of the open-flow you saw with the open-flow we have these protocols that are fixed on the standard and now the idea is why not make it programmable and the idea is that you have these match action tables still but they are now reconfigurable which means all the parsers or all the protocols you have to write them yourself and they provide a very simple switch model which shows how this kind of pipeline works so you have a parser which is programmable so you have to write it yourself then you have match action tables then you have queues and buffers and again match action tables and then the packet is sent out so very similar to open-flow a little more complex with a major difference that you have a programmable parser now and the coolest since everything is software of course you cannot only if you have an idea for a protocol you can write it, it's cool but also everything you do is available in software so it's hopefully going to be easier to write automated management platforms because all the way down like it is with x86 it's all software and you can all change it yourself here's a small example my impression was that not many people know before yet so I just wanted to show how it looks like we have here, here's the code it's very simple of course because otherwise it wouldn't have fit in here there are two language standard p4, 14 and 16 16 is much more elaborate but I think for understanding this is sufficient so if you want to have a specific header field of a packet to match against you have to parse it first and you do this in the sea light structure say header type and then you give just a list of fields you have in your header so it's very simple you can see it's also destination, it has either type that's it then you have instantiate this it's basically a sea struct and then you have a parser program and then the actual table program didn't fit but it's actually kind of obvious so you have a parser which means it always starts at the parser start you get the packet and then you tell the parser where to go next it goes to ethernet then you have the parser ethernet it does extract ethernet this is this one so basically it just takes the next 112 bits I think and puts them in these fields that's about it you can write your own custom tables that actually do stuff with it for example this table reads the destination MAC address with an exact match and then you can have different actions like drop and do nothing so this is basically the end of the development because now you can write your own parser that's cool actually I use this stuff and it's really fun I'm not sure if you're networking I recommend it of course it has some drawbacks because I mean openflow was nice it was a very defined protocol everything was in this standard now we have the problem all this stuff is not in the standard I did this so if you now want to have an API for p4 how would you do it the first approach was if you buy a commercial switch this is more or less what you would do today because that's what actually works what you do is you basically get an auto-generated API that you can use in your program and it will just use the names that you use here so you write a program and you have a table called filter and then you will have some API calls in your API where you can actually put rules in this table called filter and of course it works like this but of course if you change the names in your program you have to rewrite all your control plan as well and all your tests and that's getting cumbersome over time and that's why they came up with some kind of successor to openflow I think is their idea it's called p4 runtime and it has an advantage over openflow in that it actually enables you to write or to run local control local control programs and remote control programs so you're not fixed to one one part of the spectrum that you can be at and basically the idea is that you have some kind of basic protocol like gRPC for remote access or protobufs for the data types and they try to build an ecosystem when you write a program you can more or less automatically map to these data structure that you get from the data plan how well this works, I haven't tried it yet but I think right now it's the most interesting approach if you want to actually write your own data plan protocols okay so what's the advantage I just said that it's the most generic model yet and again if you want to do more than just having a router or switch I think this is the way to go the packet pipeline if you come with a new protocol you can write it yourself and it can be open source most of it at least and in my opinion pretty much solves the problem of packet header processing what it does not solve yet is everything else so if you for example want to do queuing or encryption or something like that everything that's little more than packet header processing it changes the whole payload for example of a packet there's usually not something that you can do today because in p4 you only can change those things that you can parse in your parser and if you wanted to encrypt the packet you would have to parse the complete packet and that doesn't really work I think yeah so that's not there are still some things that need to be done the problem is the API I just said it's pretty new you would have to check if the thing you want to do is actually in there the basic API I explained in the last slide where you can just have the name of the tables and the names of your objects in your program that actually works I actually worked with that last year and it was really cool the problem the next problem is that while p4 itself is not a standard if you wanted to use it with an actual hardware device you have to rely on a closed source driver and compiler which is that maybe this changes in the future or hopefully it does but right now that's where we are at and if you want to have something like encryption or so on it can be integrated but it's usually then proprietary and you can't open source it okay so no examples here because I will now directly go to the part if you're interested and want to do something yourself or if you look at the prices maybe I don't know at your university or your local CCC group or whatever if you want to have the classical data plane model I think the best approach is to use this switch testing it's in the Linux kernel they have regular updates they have a nice documentation and for a half size switch which means it's just half a rack with 16 ports you pay like 9000 euros that's unfortunately a little expensive and the thing at least I just googled I don't want to do advertisements here so I didn't put the link there but if you google it yourself it's pretty easy to find it comes with communist Linux and my understanding is it's based on Linux but it's not really free so I'm not sure if you want to hack yourself you can actually do that so theory is great practice I'm not entirely sure because I haven't tried so if anybody knows I would be interested the other thing is if you want to use openflow I think that's the easiest way today because you can get very cheap switches this is the 10 gigabit switch but if you want just the 1 gigabit switch you can get one for one and a half thousand euros and then you would have to get commercial software but I would say about 2000 euros the good thing about OFDPA that works on this switch is it's not perfect but it's free and you don't have to pay any subscription or whatever and you can use the review as the end framework which is if you want to experiment yourself really nice and by the way if it doesn't have to be high performance you can just get OpenVswitch which comes with every Linux distribution and you can basically build your own router but of course it's not high performance so it doesn't fit the title then we have the P4 data plane model if you want something affordable you can buy these Agilio CX networking cards the P4 support is actually a little bit like put on top of the software stack later on but it still works and again we have those at university actually working quite fine except just they don't have they only have two ports they are more like a networking card and not really a switch but it's I think quite nice to get started and of course if you want the real thing you can buy this 65 ports 100 gigabit device you got one at university really cheap I think if you normally buy it's quite expensive but again you can get like the fastest switch ever and you can program it yourself which I think is a really cool thing great time problem again if you want to do something with it you will have to sign NDA to get their proprietary tools which is again a drawback from the open source perspective but of course you get included as I showed before you get included this 8-core CPU I guess you can do quite interesting stuff with it if you have the money for that maybe you should ask your local university or Hacker Club or whatever if they might want to invest this kind of money for some progress of the world or whatever okay that's about it on my talk I hope I gave you some insight on what you can do today and some ideas maybe of what you might want to do and if you have any questions so questions no questions okay thank you very much and yeah