So given that network management can become a nightmare with a proliferation middleboxes, what we want to think about is how can you make this less onerous on network management. And this is where thinking about network services software entities comes in and that's the next segment. So the idea behind this network functional software entities is to replace these middleboxes by software entities that runs on COTS servers. COTS stands of course another acronym that you may have heard, which is commercial off the shelf systems. So COTS servers give you the ability to not think about specialized boxes, but generic servers on which you can run these networks functional software entities. And so basically what we're doing is we're taking this network function and running it as an application on general purpose service. And what are the benefits that you get out of doing that, first of all low cost of deployment. And better resource utilization because you have a set number of servers and you can use it to running different functions without having to dedicate a particular server for a particular function and scaling is possible and leave leads to lower capital expenditure. And you can switch easily between vendors, if it is software entities that you want to run on COTS servers. And in terms of failures are also easier to deal with because it is not bringing down a network outage. But it is really something as software failure that you can handle by running the software on different server and so on. So these are the reasons why thinking about network functions as software entities is a good idea. So what are examples of software middleboxes? This is a very light field has been ongoing for a long time. And in fact software middleboxes have been deployed quite widely. Examples include, Linux iptables which is providing NAT and Firewall services and VPN gateways using SoftEther and HTTP proxy as Squid as and example and load balances Agnix as an example of that. And then Intrusion Detection Systems like Bro, these are all things that are available software middleboxes. They don't require specialized middleboxes but you can run them as software entities on commodity servers. What are the fundamental components of software middlebox? Most of them are using Linux platform and they use Unix sockets. Opening a socket creates a file descriptor. And then once you create a Unix socket, then you can use system calls like read and write to the sockets, and that way you can read the network packets right to the right the network packet. And so raw Linux sockets enable the developer of a network function to read and write raw bytes from the MAC layer from the NIC into the software buffers from which you can do the analysis of the packet. So that's the basic idea of how a software middleboxe will work, and what I'm going to do is I'm going to give you a concrete example of a load balancer network function and how you might architect it as a software entity. So the idea in a load balance is that you want to distribute the client's connections to a pool of backend service. For example, if you have an HTTP server you have an incoming connection through which clients are accessing the HTTP server. So in order to scale horizontally depending on the number of users a load balancer may be architected using a packets five tuple rule to choose a particular backend instance. Now what is this five tuple? Well, there's a source address from which a packet is coming in, a destination address from which it is coming in, and there is a source port number destination port number and a protocol that is being used by the particular connection. And these this is a five tuple and based on this five tuple we can choose a backend instance, to serve that particular connection. And that gives you affinity to a particular connection and the same connection will be sent to the same backend instance. So that's the idea behind that. So the load balancer that's in between the internal servers and the external users, what it is doing is when an incoming request comes in, it is either going to look up, or you're going to update the table based on this five tuple rule that I mentioned. And the idea is that, when a packet comes in, you read the packet and in order to receive the packet the load balancer does the receive from call in the Unix and it reads a packet. Once you read the packet, you extract the connection information from the header. The connection information in the header gives you access to this five tuple, that uniquely identifies a particular packet, and once you have that, then you can use this five tuple to look up this table and see if an instance is already serving this five tuple. If a match is found, you're going to use that particular instance, in order to do the packet processing and send it to that particular instance. And so you can send it to that particular instance using the sent to call. So the load balancer sitting in the middle of a packet coming in and being sent to a particular instance of a service, what it is doing is it is doing the analysis. Read the packet, and once you read the packet, you see, extract the necessary information file tuple. Once you extract that, look it up, and if you find the match, then send the packet to the particular instance. And so you're simply using UNIX calls for this received from, read the packet from the NIC, and send to the sender packet owed to the particular instance through the NIC that is sitting in this load balancer. And on the other hand, it might be that the match is not found and if a match is not found, then you have to select a new back end instance and add it to the to this table and say that for this particular, five tuple, I'm going to use a new instance. And this is the instance I'm going to use, and that's the one that will be matched in the future when packets come with the same five tuple signature. So you can think of this five tuple as a signature that helps the load balancer to choose a particular instance and keep the affinity for that connection with that instance. So what happens when a packet arrives? Well, the NIC uses DMA to write the incoming packet to the memory and then the NIC generates an interrupt indicating that the packet has arrived. So that is what is going on here. And once the interrupt comes in, the CPU is going to handle the interrupt and allocate the kernel buffer and copies the DMA packet into the buffer for either IP pop processing to happen or TCP processing to happen. So all of these are things that depending on the particular protocol that is being used, the appropriate high level entities are going to be contacted by the kernel, once this interrupt is haggle by the kernel. And after the protocol processing, the packet payload is copied into the application buffer. So this is what is separating the application from the protocol stack. And so in the application buffer we're going to copy the packet that is coming in into this application buffer. So this is in the user space, and you can see that this is the path that is being traversed when a packet arrives into a system from the network.
