How SDN will Shape Networking - Nick McKeown

thank you Dan so I don't know who I have to blame but it's my idea of a nightmare to be giving a talk right after Scott Schenker and before gender expert who you're also going to find out is spellbinding talks so you can think of me as the interlude between there between those two so how s the end will shape that networking or how will last in shape networking maybe that's what it should have said so as you heard from Martine and and from Scott a lot of these ideas jeld-wen Martine was a PhD student here at Stanford but working with me and Scott when Scott was at Berkeley and building on lots of work that had been going on in the field for those of you the familiar with the 4d work that Jen who's speaking next was a part of and and and lots of sort of ideas that we're heading in this in this direction what I want to start with though is rather than a research perspective a little bit of view of how this is likely to affect the industry as a whole or what is he is the sort of the industry trend and in some ways this industry trend I think is bigger than what we're talking about today it's a much more general trend that's been in motion for a number of number of years and then what I want to do is to talk about four main points that I think will though that will really come out of this that will shape networking the empowering of network owners and operators the increasing the pace of innovation diversifying the supply chain and building a robust foundation to to networking but I want to start with this industry change part I don't do it by an analogy and that analogy is to the computer industry of the 1980s so computer industry in the 1980s meant IBM and if you were buying a computer it was based on specialized hardware specialized operating system and specialized applications all from one from one vendor it was an industry that was vertically integrated it was closed proprietary relatively slow innovation but what happened shortly thereafter and we all know this story very well along came the microprocessor an open interface because it had to be published in order to be able to use it that led to over time many many operating systems way beyond the list that I have here open interfaces on top of that over time led to a very large number of applications so an industry that was vertically integrated closed and proprietary became an industry that was horizontal eyes very rapid innovation and became huge so clearly there's something similar going on in networking is an industry which has in the past being based primarily on specialized Hardware specialized operating systems and specialized features and control programs added on top this was a natural way for that industry to start out but it's sort of an intra in transition and actually the thing that is driving this much more than Sdn as a concept or open flow or anything like that is the availability of merchant merchant switching silicon and this is really transforming the industry at a quite an alarming rate we're not quite at the point of open interfaces that's what we're trying to work on here and having open interfaces to those much and switching chips but we believe what will happen on top of that is the emergence of multiple control planes they may look like things that you see today and the demos they make look look completely different only time will tell any experience will allow us to tell which one's work and which ones don't work some of them will have open interfaces some of them will have closed and eventually there will be applications and features and control programs that will emerge on top and so we're seeing an industry which has again been vertically integrated closed proprietary relatively slow innovation we've talked a lot about that today already accelerating through horizontal ization open interfaces and what we hope will be more rapid innovation and I really believe that Software Defined Networking or Sdn is just one manifestation of that or is one aspect one aspect of that clearly what we need is an open interface to the packet for you that's what open flow is but there could be alternatives of course and that we need at least one hopefully many network operating systems or control planes somewhere we open some will be closed some will be proprietary some will have similar interfaces to others some will be completely different depending on the context in which they operate we've seen many examples of what this this how this might affect us as the owner or operator of a network or as an end-user I just want to offer you a simple example it's kind of a trivial example and this is just to take OSPF as an example so if you take OSPF and you know it's not particularly beautiful beautiful method but is very very widely used it's described in an RFC and 245 pages and what that 245 pages is describing is the building of a distributed system through the exchange of state to group to gain a consistent global view of the network what's the current state of the network what's the topology what's the current best view of the topology that it can get and that's described over about 100 pages Dijkstra's algorithm which when we teach about networking and we teach about OSPF this is what we describe that's described in four pages and it could easily have been fit into half a page I teach it in 20 minutes I'm sure that's how we all learned it in a very very short it's true it's a very very simple method so what's the point here the point here is really one of the most important things that has somehow got lost along the way is that every time that we build a routing protocol every time we build anything that is a control program or a feature on top of the network we start by building a distributed system and we're not very good at it it takes many many attempts to do it and then on top of that we put what over the control program is so if you look inside a router what do you see see an operating system on top of which is a distributed system on top of which is the protocol that we have on top and the strange thing is that alongside each of these distributed systems is another one looks very similar it's running a different algorithm on top in this case in order to pick the shortest path through the network but this replication comes at a cost comes at a cost in terms of just the sheer complexity the lack of reliability but it's just in elegant to be repeating this repeating this this function all the time so as a simple word illustrative example it's not a particularly beautiful example but I think it captures something that's going on with Software Defined Networking it's not that there's anything particularly new that's happening it's essentially being refactored it's being refracted through different abstractions through different interfaces and so one distributed system to create that global view upon which these control programs connect and so it makes it easier to introduce new functionality over over time because merely all you need to do is to have an understanding of what that distributed system is presenting to you as that global view of the network and then write that control program to it underneath is the interface between the network operating system and the and the packet forwarding and the example that that's that's that we're obviously all talking a lot about here is Oakland flow I just want to speak for for two or three minutes about this Scott described it as a forwarding abstraction and I think it's a very good way of describing it there could be many possible forwarding abstractions and I expect over time that others will others will emerge but the thing to think about with or the thing to to observe with open flow is primarily its exploiting flow tables or tables that are already there so it's timely in that it exploits things that are there it does not mean that 10 or 15 years down the road this is the correct way to do it and I think this is an important thing for us to bear in mind standardization has the benefit of giving Hardware independence to give a common abstraction but the thing that we should be focusing on is the standardization in a pragmatic perfection is not the goal here a good enough abstraction is what we is what we need so what is it doing its exploiting this flow table and then populating that Floyd flow table with rules of the following sort if you see it if you see a header that looks like this as a header of P sender port 4 if you see a header of Q over write some fields and send it the sender a collection of ports for multicast or for multipath if you see an unknown header perhaps send it to me or drop the packet under the control of the network operating system what is really doing is providing a match plus action and I think this is actually the key the precise details of the mechanism matter less than this general abstraction of forwarding into if you see something that matches and looks like this then you perform an action but actually this is just an abstraction of how every forwarding element works in the network today whether it's layer 2 layer 3 it's an AC a CL 4 firewall etc all of these boxes are doing a match plus an action action an open flow is just one example of how you could do that so basically you match on a selection of on a set of rules that define a header you would like this to be as general as possible to match on any header that you can define or a new header that you create that's specific to your network and then you pick the granularity depending on where you are in the network if you're towards the edge perhaps you want to find growling erratic granularity and then aggregate as you go towards the middle as we do today that perhaps in a way that fits your context maybe VLANs it may be mpos or something that's created locally and then the actions in the case of open flow that set of actions is designed to be very small things like if you match then forward to a port or a set of ports drop the packet send to the control control plane overwrite the header with a mask otherwise modify or overwrite the fields in the header push a new one on in order to be able to create encapsulation or pop 2d capsulate and forward at a specific bit rate really the particular challenge that OpenFlow faces is not really on this whole match mechanism it's on this action and that is how do you use the minimal set the minimal set of actions to be a meaningful set of primitives from which you can do most things that you want to do while leaving room for chip vendors to be able to implement in hardware and box vendors to differentiate by adding additional features and additional capabilities and so it's been a it's it's been a crafting of of trying to figure these out as we go and I encourage and implore all of you to help in that process you will look at this and say there are things that are missing well then think about well maybe I can have that in my box and differentiate from everybody else maybe that there are things that you think should be there down the road we'll get involved in the onf and working groups and help steer it in that direction because as martine said very eloquently in the end this is what we make of it and we as everybody in this room represents a large fraction of the networking industry and in order to make this better and to improve this we all need to take part in moving this along so in the end what the abstraction that it provides us is protocol independence because you can potentially not right now today but potentially in future construct a variety of existing protocols construct new forwarding methods yet in a manner that is backward compatible and that you can stick it into an existing network and have a box that looks like a BGP router or a or an existing firewall and then and then have that as a point of innovation so that you can improve that over time and that is largely technology independent in that there are flavors of this that have been added to switches routers Wi-Fi access points cellular base stations even WDM and TDM circuit switches because that flow abstraction works works equally well in that context and so as a consequence many people have have chosen to develop products around this in domains that I've listed here I'm sure there are others that I'm not aware of data centers and public clouds enterprising campus networks cellular backhaul enterprise Wi-Fi wins home networks and the number of switches and routers and software vendors and startups this is a great area to be looking for a job right now the most common email that I get at the moment is how can I find somebody who can work in this area because I'm expanding I'm expanding and networking for the first time in five or six years but how will this shape networking how will this shape how we use the network well for this I want to go through these four points in term and may use this as an opportunity to illustrate some of them with two or three examples and these are research examples just to give a sense of the things that we might be able to do as a consequence of SDM so the first one is the ability to empower network owners and operators we can already see when when network administrator's here on campus and in other university campuses that have been deploying open flow and Sdn that works but once they have the ability to customize that network for their local needs that's what they do they start to come up with features and capabilities that they'd like to put into their network which is something that they've not been able to do in the past and in fact there's a wonderful opportunity here for a growing sort of peer group amongst people who already know each other and work with each other across universities between universities across the country and across the world to be able to develop ideas exchange them and to gain status within that paper just as people do within the software industry as a whole but more broadly people will customize their networks not necessarily by programming it for themselves but by paying others to develop features and capabilities for for their network through a new set of suppliers through a whole new holding part of the industry others will use this as an opportunity to eliminate unneeded features if you have a router in your network today it has somehow had to address about 6,000 rfcs and so that router is extremely complex and we know how reliable they are given the opportunity to be able to eliminate the 99% of those features that you don't actually use in your network gives you were potential to make it more reliable and so people some people would choose to do that not all so that will be something that others choose to do some of the networks that are being built right now are being built for very specialized applications using this technology because they only need three or four features because they don't have to carry the legacy of a thousand different types of user others will use it as a tool for building virtual networks which isolate sets of users perhaps perhaps in multi-tenancy and/or in just as a means of dividing up sets of users as we use VLANs today many many ways to to use this in order to be able to to isolate networks which have particular performance guarantees it will also have the effect of increasing the pace of innovation once you can define the operation in software then we move into a completely different culture as Scott was alluding to earlier innovation will start to happen at software speed standards if there are any who remains to be seen what standards mean in this in this environment will follow the software deployment in other words rather than today where a number of people sit in a room define a new feature or a new capability of a network and then we all wait for five or ten years for that to become available we will see deployments that people use that they share with others that they gain experience and then somewhere afterwards it gets solidified again standardized maybe if that's helpful for the further deployment through the industry others will just choose for example to peer with their neighbors using things that they've cooked up between them so you can imagine one provider peering with another and saying well across our boundary we'll actually use something that we've found works better for us and then at our combined boundary will peer using BGP or whatever that whatever happens to be used and so now over time you might imagine Islands growing up of of techniques whether it's routing protocols or whatever it happens to be that support the particular needs of that part of the industry so the consequence of this will be some amount of chaos a need for a lot of diligence in testing and of communication but on the other hand we can expect to see a much much more rapid piece of innovation and we like it in the university and there are a number of researchers here we like it because of the ability to try out ideas and for the first time perhaps ever in networking to be able to influence industry by transferring good ideas if we have them right by taking ideas and being able to using either networks of our own creation or of programmable test beds like the Genie testbed being funded by the National Science Foundation in order to be able to try out those ideas experiment with the Mexica at scale show our peers show industry and then if those ideas are good for those to be transferred and then more widely adopted so when we pick out two or three examples here so how might I customize my network and I would just want to use an example of someone here a student who's sitting at the back of the room Nikhil who was interested in customizing a network that we had here on campus and then extend that that that idea and to be able to demonstrate it over a much larger scale so his idea was to add distributed load balancing to the network that was here and then more broadly across the the network into connecting a number of campuses so we all know what load balancing is load balancing is when a set of requests in this case number of HTTP requests are delivered across a network to a randomly selected server or to one that's lightly loaded ideally that request would be sent over a path which is lightly loaded to a server which is lightly loaded in other words we were jointly optimize the combination of the path and the server in order to be able to minimize the request today in order to do that we have to go and buy several hundred thousand dollar boxes in the place of them in the middle of the network and yet all they can do is pick the server they can't pick the path so even though they sit in the infrastructure they're part of the network they were unable to choose the path they have to give be used the path that's handed to them by the network so we are he was interested in the in the question what if you could jointly optimize that that path and and server and see whether you actually got a better response and you wanted to do it in networks that look like this campus networks interconnected over over a backbone where the requests could come in from any directions so there was not an obvious place to put the load balancers so in this particular case the load balancing was to be distributed through the entire network so that every switch was capable of load balancing just because of a omniscient control plane that would see the requests that were coming in and be able to route to the servers as needed so the experimental setup looked like this a network operating system in this case Knox it's an open source open source control plane originally created by my team and then read this as a control program on top and then deployed it into the geni network which at the time looked like this national lambda rail and Internet to networks into connecting a number of campuses and BBN across the across the country so I'm going to show you a demo that we showed about a year ago at a genie conference of exactly this this is of a number of clients at the edge sending requests to a number of servers which are shown around the the top right hand side the numbers just show the response time for the reserve so these are HTTP requests being randomly sent to the servers without any consideration for the network as you might expect the network becomes very congested in some places and so the average response time is all over the place so this is the average response time seen by the client of that HTTP request so highly variable not something that you would like to do to see now we're going to more smartly load balanced by every time there's a request pick the path and the server jointly in order to minimize the expected response time choose the path using that control plane pushing that down into the switches and it's not going to use a particularly clever with them it is going to greedily pick the one that it's been the most likely congested in the near past and as you can see and this was done from a live demonstration so these numbers were were being measured at the time it moves from the red line to the green line there's a dramatic reduction not only in the response time but also in the variability my point here is not to say that this is the best way to do it that this is going to be widely deployed in your network anytime soon or that you couldn't improve upon it with with spending a little bit of time on it the point here is that for the first time that I have ever seen a graduate student was able to take an idea and within a few weeks put that into a national network run real traffic over it was able to demonstrate it to others and then hand it to them and said here's the code you can actually go and run this in your network - and you can use that as a basis for improvement and so that's what this Software Defined Networking and a test bed like Jeannie made possible so in this particular case this entire code in order be able to do this as a feature added on top was actually less than 500 lines of code so we've seen this time and time again that by placing this kind of facility into the hands of students and I think that in future we'll see this putting into the hands of engineers both engineers developing the infrastructure and people owning and operating the network but they too will have ideas that they will want want to put into the network and we've started to see this happen already there are a lot more videos that we've created and others have created of demos at this particular location and so if I'd encourage you to go take a look so on the second point of increasing the pace of innovation and innovating at software speed I want to offer you another example that some of you saw yesterday as a another way in order to be able to innovate that's provided by Sdn and it comes as a rather subtle consequence of that of this that once you have a well standardized well-defined interface to the hardware if that is a narrow interface then you can start to emulate that and create entire testing environments instead of needing a big test lab and spending millions of dollars on it you can start to do much of that testing and software we've seen some large companies already beginning to do this because it's impractical to take commercial switches and routers and to be able to emulate a whole network made from them but if the interface that they they provide is fairly narrow and fairly simple you only need to emulate bad an example of this is the mini net system that many of you will have used in the prep in the tutorial yesterday as a means for rapid prototyping so we just want to tell you briefly how this works basic idea is this so we're going to take the example that I just showed you of that network with the operating system and the load balancer sitting on top and then we're going to map this into a emulation and we're going to include some end hosts are going to be generating some traffic as well I'm going to put this onto a server this is the server at the top here with the user space and the kernel space I'm going to take the packet forwarding pieces put those into the the kernel of this machine take the various processes and put them into processes on this machine including the end hosts the thing that makes this possible with for those of you familiar with these things is the network namespace addition to Linux it's been a number of operating systems that allows you to do lightweight emulation by taking it's a little bit like lightweight virtualization where you can take a process with its own network namespaces you would expect to see for a virtual machine and then be able to run that at much much lower overhead than it would be for a full virtual machine and then you stitch these together with virtual Ethernet interfaces one of the cool things that you can do is then take any of these pieces and then move them over cause or even move them over machines and start to then emulate a really quite surprising speeds so why does this matter well it matters because it's fast you find that you can emulate quite nicely networks with tens of switches just on a single laptop as many of you saw yesterday by mapping these onto cores and servers you can emulate networks with thousands of switches just on a server rack so instead of needing millions of dollars of equipment in the lab you can potentially try out new versions of software new versions of control programs new ideas in this environment first and then you rapidly transfer it into the network so in a number of demonstrations where you can deploy that unmodified code without change from that mininet environment directly into the live network and in some cases even into a slice of that network without ever taking the network down so you get much much more rapid pace of innovation as a consequence of this and for those of you want the code it's available so getting back to this how will Sdn shape networking it will also diversify the supply chain we've already started to see a variety of software suppliers step forward I think we've only seen the beginning of this there will be many more existing vendors the best police companies to innovate in this area are going to be the existing vendors who have the most experience but there will be startups of course that come along and compete with them we'll see vendors a variety of a much greater variety of vendors people will do homegrown they will outsource to others they will ask consulting companies to develop new features for the network will see open-source will see all of the above and last I think it will build us a robust foundation in the spirit of what Scott was describing the turning something which is the mastering of complexity a a something which is something of an ad hoc discipline into something with much greater precision and what built on a much stronger foundation so the standardizing the forwarding abstraction is just one part of that but as those abstractions become nailed down on top and we begin to think in terms of this abstraction of networking control we will start to have provable properties at each layer of the network I just want to offer you one example here again some some work that we've been doing here improvable networking properties at the lowest level and I think that this will be we will see similar examples like this operating at other layers of the control plane as well this is something that payment who's sitting at the back has has been working on in something called head of space analysis so I view this because it's not about an application it's not about software it's about what this basic model allows you to do and I think it will give you a sense of some of the other things that will become possible down the road so in this particular case it's we're going to use the fact that the lowest portion of the network is this match plus action primitive in order to prove properties of the network and do some static checks of questions that have been very difficult to answer in the past so in today's networks some very simple questions are really quite hard things like can a talk to be is there any type of packet that a can send that can reach B but what are all the packet headers that a could send the would reach B can you describe those to me even if the network is transforming those packets as they go through they're very hard to to answer but if you're trying to debug in network and understand its operation then these kinds of questions are very important for it in order to be able to work correctly are there any loops in my network is one VLAN actually isolated from another other ways in which information can leak from one to another or if it's a slice and informations leak from one to another this is important obviously in an engineering environment but in a hospital and for things like HIPAA compliance and PCI this is extremely important so the approach that the payment has taken is first of all the map the entire set of headers this match plus action primitive model the entire packet headers are just a single point in a space which is L dimensional where L is the length of the header you will see in the minute that you've all seen this before what I'm describing is digital design but bear with me and you'll see that in a moment so we're going to map it as this as the single point and then we're going to model all switches is transforming this space all switches routers firewalls everything is going to transform this space and then we're going to analyze reach ability based on those transforms the transfer functions and is all building on this match plus action and we'll see that because of this it's protocol independent it's very general and quite surprisingly fast so let me explain a little bit more take a packet header l bits of the header that whether that's l2 l3 l4 or a thousand bits that's that's irrelevant here this space down here is the L dimensions I can only really draw too I've attempted to draw a three I certainly couldn't get beyond that dimensions here for which that header represents a single point it's a specified point within that space now a rule a rule that sits in a flow table whether that's an l2 table and l3 table or an open flow table we represented something like this if you see something that matches these bits with these wild cards then I want you to perform some action well that represents a region within that space what is a packet forwarding element do whether it's a switch or router or firewall doesn't really matter it's going to transform that space by performing actions when it sees matches so if it was to send to port 1 it might perform transform that space to something that looks like this it might be modifying the header because it's there to that it may be unone modified as in layer 2 doesn't matter it's going to move or transform that in some form or another and so we can map the transfer and the operations that are performed on this space if this is reminding you of karnaugh maps and boolean algebra and logic minimization it's a lot of similarity and in fact there's a whole algebra that you can build up from this that allows you to perform these analyses that are exploiting the fact that underneath you've just got this match + action primitive and so from this we can build an entire network transfer function what is the transfer function of the entire network so if I put in package to the lip that look like this at one end what will pop out at the other and then you can ask of that things like reachability analysis ask it to detect loops that are finite or infinite where is this coming from this is coming from because of this network transfer function that sits at the bottom and it's just a bunch of boolean expressions so then you can throw all of the machinery that was developed for CAD and formal verification at this and even use model checking in order to be able to answer some of these questions only relies on this match plus action so it's assumes the things that we already use without being dependent on them and then you can use it to find faults in real networks so payment oook this he took the older configuration of Stanford's backbone Network posited to create the transfer functions and then was able to say who can talk to him where are the loops and found a number of sort of surprising things was able to do that in about 10 minutes so again please contact us if you're interested in exploiting some of this so the point that I want to make here is not that any of these three particular examples of things that you should run off and use they may or may not be of interesting interest to you but what Software Defined Networking does and what it will do to the industry as a whole is introduce new ways to make the foundation stronger to allow us to innovate faster to allow us to innovate on our own and as a consequence the entire industry I think is going to change thank you [Applause]

Channel: Open Networking Summit

Views: 91,533

Rating: 4.9447732 out of 5

Keywords: Nick, McKeown

Id: c9-K5O_qYgA

Length: 34min 30sec (2070 seconds)

Published: Tue Oct 25 2011

Reddit Comments

[u/IWillNotBeBroken]

It's from ONS2011, but it's a very cogent presentation. It doesn't rely on my largest SDN pet peeve: re-solving solved problems.