Hi, my name is Larry Horner. I'm a Solution Architect with Intel's Networking Communication Services. Today we're going to talk about the introduction to cloud networking. In particular then we're going to get down into network function virtualization. Hopefully you've heard that term before and we're going to spend a little bit of time talking about those elements. In this course, the agenda, we're going to look at some of the dedicated networking of the appliances and the software, elements of that and you're going to hear some more alphabet soup of NFV or network function virtualization, the VNFs, the virtualized network function and then also container network functions and what we mean by that. Then the benefits and challenges that are associated with that. We're going to touch a little bit on the data center edge functionalities and how they're deployed. Then third-party applications for those VNFs and DIY, do it yourself, VNFs. Then we're going to talk a little bit about the network workloads on the compute. In particular, well, what this means to the bandwidth. You heard in one of our other sections, probably discussions about the speed of those ports, of those interfaces, and we're going to have some comments about that. We're going to look at some of the compute resources,and as we allocate those resources, what that means to that interconnected bandwidth, and the cautions that come into play that are there. We're also then going to look at the implementation as we transition from what we'd call the legacy VNFs to a more modern or cloud native architecture. Then we're going to mention very briefly some of the things that would have to happen in order to do what we call acceleration, and what we mean by that in this scope. Let's take a look at some of those details then on what we call network function virtualization. We've laid the foundation onto the cloud environment. Now what is this thing that I talked about, NFVs and VNFs? Why are we interested in it, and why does this have implications to what we think about as we start looking at networking and into the type of the cloud environment level. Before we do that, let's really give us some idea of the definition of what this thing is in network function virtualization. We talk about it as being able to create a desegregation of the application from the underlying compute network and resources and the storages of the physical server, what we mean by network function. Again, if you think back to how we're saying we use the word network in a variety of ways and sometimes we think about it analogous to addition or multiplication. Well, in this sense, the network function itself is the keywords that we're talking about that are in place there. What do we mean when we say network function? It's not the network and it's not the function. It's a network function that we're talking about, and then why are we describing that as virtualization? The thing that happened is that back in 2012, a group of very bright folks got together and they wrote a white paper, and you can go out there and you can Google this Don Clarke fellow who was Executive author of that work for a company called British Telecom at the time. A lot of the communication service providers were reaching a business problem. The business problem that they were reaching was the volume of traffic that was flowing through their network was ever increasing, and an ever increasing at an exponential level. Yet their ARPU, their average revenue per user, was not increasing at that same level. This implied that they were going to reach some point in the future where their ability to purchase equipment, for inside their network, was no longer sustained by the amount of revenue that they brought into it, and the two lines would cross in a bad way as the expense of growing your network would exceed your ability to pay for that growth of the network. They looked at what the cloud folks were doing, back in this timeframe, and they had this realization. What the cloud folks were doing with this desegregation, this separation of the application from the hardware itself so that we can force that utilization to go up. Now we brought with us some additional challenges when we did that, but that was one of the things that came out from this is to increase that utilization from that. They coined the term network function virtualization, or NFV. In this paper they, wrote a bunch of use cases, they give you some use cases. Two of the interesting ones, not difficult but interesting ones were actually firewalls and load balancers. Another one was deep packet inspection, and why are those interesting? Those are interesting because, again, if we look at what happens into those functions, let's talk very quickly about the firewall. That term comes from a physical use in the construction industry. It means a barrier. A barrier between two elements that protects one from the other. What firewalls do, in a network function, is they will actually have two ports, an eastbound port and a westbound port if you want to think of it that way in my earlier analogy, or a public address and an internal address. That firewall is designed to prevent bad things from happening. What are the bad things that it's trying to do? Well, we can go into that all day long, but fundamentally, it's designed to protect the network first of all, the inside network, the big network. Then it's designed to protect the servers, those elements that we showed before that were interconnected, and it's intended to protect the application. Then finally, it's intended to protect the service itself at the application or above the application layer. It goes back to remember I said we never turn this network off. That's what we've done, we've done some things that allow us to protect that element so it continues to operate even if it's under some type of excessive load, whether that's an intentional excessive load, Mother's Day, someone's out doing a golden day purchasing or whatever happens to be the excessive loads. We've got to peak the capacity of that network and protect the network so it doesn't get pinned down. Or we've got applications that would also run there that would prevent us from some type of hostile activity. The most common one that we talked about would be some type of DDoS attack. There are elements that do that. Here, in this picture we see stylistically a collection of classical servers. Let's call that a couple of different racks. Not a large deployment and each one of these servers would have a associated with a unique IP address. When I talk about what is a machine, the server becomes a machine when it has an instantiation of an operating system running on it, it's doing more than just making heat and it has associated with it then an IP address. Somebody can get to it and it has a personality associated with that then so we can get to it from other environments. That machine than itself and again, whether it's IPV4 is a minimum, maybe IPV4 plus IPV6 or some type of an element and its associated then with those interconnectivity that's in there. In addition though, when we look at this, we see some other devices in that picture that don't look like this. The large number of servers and we can think about those as possibly realizing those firewalls and load balancers that I spoke of a little bit earlier in that type of an example and those are there obviously, to protect the network, to protect the service, protect the application, and protect the instances we spoke of before. When we transition that type of a model into network function virtualization, so when those network functions of load balancing and firewall and this trivial example then become virtualized, that environment looks a little bit different. Now that we still have that server that's there, that becomes a machine, there's that physical machine and it has an operating system that's on there so that's that Infrastructure or platform as a service that we've talked about. But now we've got the possibility of having a collection of virtual machines and again, I'm using that keyword machine that's in there as virtual machines so what do we think of it then? It's going to have an instantiation of an operating system and it's going to have an associated IP address. The IP address and that operating system may in fact be different from that of that physical machine that it resides on. Because of that socialization or that distribution that takes place there, I can actually have multiple of those virtual machines that exist in that environment so there's become a multiple virtual servers. But because of that, just like I had a top-of-the-rack switch or a tour that allowed my machines in the physical world to interconnect to each other, if I've got traffic that needs to go East to West, and now I mean this is the micro level not the macro level of St. Louis and Chicago, [inaudible] before. Then those machines need to be able to talk to each other and there's going to be a realization in some layer that allows those machines to talk to each other, possibly without the requirement, the necessity of bouncing that traffic off of a physical top-of-the-rack switch. If you think about that for a moment, you think about, if I had a single machine that is sitting there and I have two VMs and all that traffic has to go into the physical machine and into one of these VMs and out of that VM, and then back into another VM and I start bouncing it off the top of the switches, those VMs scale. I start to consume more and more resources off of that platform, off of that infrastructure as a service. That's not necessarily a good thing from an architectural standpoint. We've realized virtual switch capability and that keeps us packets into that physical machine as long as those VMs are co-resident inside that machine. There are other certain workloads that are interesting in that type of environment. Obviously, that would not be a multi-tenancy type of an application, but that would be a collaborative type of an application where maybe we've got a firewall and a load balancer, and then some applications that are collaborating together to realize that implementation. That allows us then to push that resource utilization pyre and potentially address that what I described as that CFO question much earlier on. What really is network function virtualization? It's a way to address that business problem that I spoke of before and it's architectural concept. It's really not a product or a service. It allows us then to utilize the resources more effectively that are on those platforms. In some sense, when we start adding more and more cores, beginning of my career, we had a single core on a CPU. Now, it's not unusual to find 40 cores on a CPU, 80 cores or more on server and we want to be able to use those cores because that's what allows me to travel that utilization up. NFV is a way that allows me to do that up and it brings out virtualization concept into that network load, and it copies and replicates that model that we would have seen into that type of cloud environment. Whether that's a multi-tenancy type of an application, or whether it's a single tenant application. But we want to take the advantages of scalability and redundancy and increased utilization and be able to throttle those utilizations up and down as that workload changes, whether that's throughout the day and their examples of that, or whether it's through out some type of planning cycle or some period of year. When we go back to the rows example , when we think about that. One of the driving points here is that while we're applying technology and NFV into this environment, it's really not about that technology, it's about disaggregating that hardware and that software. One of the tests that we'd like to talk to is when will you know you're successful when you've done virtualization? Some folks will tell you it's when I virtualized certain percentage of functions in my OT or my IT type of an environment. We challenge that representation. Representation, it's actually when you've got common hardware that allows me to deploy the next generation of applications on that hardware and I could do that at scale, or I deploy the next generation of hardware into that environment and I can take that previously existing application and deploy it in that environment and it's just going to work. It may not utilize all the features that are there and that later example because of this thing we call enablement, but it's going to allow you to continue to build on to that environment and change the software later in time. As opposed to in the purpose-built environment level, you had to go and you had to get new hardware and new software and you had to test and qualify all those elements as a unit level before they could get deployed into these network environment. It simplifies that process and it gives you that better utilization that we spoke of before. We haven't talked a whole lot about the on-prem and off-prem type of an environment yet, but we're going to get into that a little bit. That comes into a choice as to how we're going to deploy these types of operations and how we're going to separate that cost of the hardware, the connectivity, and the operational aspects of it into that type of an environment. Again, it's about driving a better business results in the utilization of our resources, which ultimately is a financial argument that is being made as to why we're going to do this. We want to do this to improve our ability of agility, our ability to scale, or our ability to meet the needs of our business as it changes in its dynamic. Let's take a look at where we've come from and where we are and where we're heading in the scope of this virtualization. Back in that 2012 time frame, while we created the verbage, the text, and everybody agreed that that's how we're going to talk about things, that wasn't actually when we started things. Some of us had been doing things that we now call Network Function Virtualization prior to that, but we weren't common in our language. Again, I'll go back to the math model. This is the way math evolves is that sometimes it takes a little while for everybody to realize, "Oh, we're doing the same thing. Let's make sure that we're using the same language in order to describe it." We can extend it from there. But that's what happen. But in that environment that existed a decade ago as we were doing that hypervisors were the way to go, is that we would have an application and it would be running an operating system, whether it was a Linux instantiation or maybe a Windows type of an operating system or some other, and the hypervisors allowed for a virtual machine to exist, and then you can bring your own operating system, and the operating system wouldn't know that it didn't have a physical machine or anything. But along with that came a certain amount of performance burden. Most significantly was compute performance burden, but also a performance burden to the networking itself. While it may have looked to the outside that we're reaching utilization thresholds, we really weren't utilizing the network or the resources optimally in that environment. In 2012 to '15, containers started to come into scope and containers are certainly a much more light way of looking at virtualization. We still have the ability of having multi-tenancy into that type of an environment. But now the container itself, this concept of the container brings more of the application and more of the functions that allowed interface to that host operating system into that environment, and it allows us to drive the utilization up higher on to those platforms and still have multi-tenancy inside of an environment. One might point out though, is that we made that migration, we lost a little bit of the security that can exist and operating systems are really good about protecting themselves and their memory instance from others and other memory instances inside of their environment. One of the things that's happened in this environment level with containers is you've got to look at that multi-tenancy and whether or not there's a potential for leakage across that operating system. That's a real concern for multi-tenancy type of environment, but certainly not in a unified application where we can actually drive that utilization. Now, going forward, we're now starting to see process containers where those applications, so processes, typically we think of that as a PID. It's an instantiation of a very specific workload, you want to think of Excel or Word if those are trivial, so those would represent two different applications. Each of them may have a separate process ID and it's not as interesting when I translate it into this environment, but most of us associate with that. In a containerized environment, those applications would have a unique process and they would come with everything that they need in order to maximize utilization of those services into the environment level, and that's where we're heading in this Cloud 2.0. That's the work that's going on right now in transforming these applications. We're no longer just taking an existing application and driving a hypervisor underneath it, but rather we've gone through the machine containerization level and now we're starting to look at process containerization level as we improve that desegregation. A snapshot of the future is that today we call it unikernel. That's probably an engineering word that once the marketing folks get hold of it, they'll change it into something else. But you can find some research out there on unikernel and that allow those applications to get closer to the physical device itself and still have that concept of virtualization, desegregation from the hardware itself to the host operating system, those still exist. But now under the unikernel model, those applications, collection of processes, not a single, but the collection of processes that exist into that type environment have a greater content of the kernel aspect associated with them. That in fact may give us better security for those that are concerned about that security model than we had either on the machine or the process container type of an environment. That's just a snapshot of where we're going and where we've been into that environmental level. If we look at, again, that evolution from the physical appliance model, and here we do see our examples of firewalls, and load balancers, and the applications there into that virtualized environment level, you can see very simply then we take those two VNFs, so fire one at load balancer and we bring them over onto our server and instantiate those. Then we've got headroom for the application itself, the interesting application that's indicated in this slide, and what we see in that environment. The caution that we've got there, is we can spin those up today. We can go to those cloud service providers today and we could spin those up today. If I spin up a VM, as part of spinning that VM up, one of the things I get to choose is, how much bandwidth do you want from the interface? That physical machine itself, it's got plumbed interface, it's physical connected up to the top of the rack switch. There's 10 gig interface is 25 gigahertz, affects this multiple 10 gig interfaces, or whatever happens to be. We can go to that environment and we can say, hey, I'm going to spin up a particular VM. I'm going to spin this VM up and I know I need four cores. I need four cores of the latest Intel processor because that's the performance benchmark that I've reached. By the way, I want 10 gigs of capacity that's in there. That machine may have 80 cores available on it, let's say. Someone else comes along and says, "I want four cores." Now we're using a 10th of the machine and this fellow comes along and allocates 10 gig of that interface as well in their environment level. Now we've only used a 10th of the cores that are available on that machine, but we ask for 20 gig of interface capacity that's in that environment. Now, in this example, if that machine itself only has 10 gig of interface, the obvious question is, how do you both get it? Well, the answer is there, you don't. They're simple Linux tools that are out there, and I'm sure there are tools in other operating system environments, but the world I live in. There are simple tools that are out there like iPerf3, that allow you to look at the performance once you've spun that up. You get your favorite VM that's out there. You've got an instantiation of an operating system. You get to pick your flavor Linux that's running and it's assigned an IP address, so it's a machine. Now, we can get to that machine. I don't care where they are. If it's spin two of them up, I can actually cause traffic to go between them and I can look at the utilization of the traffic that's between those two. Ideally, I spin them up on different physical machines so that they actually have to go off of that top of rack switch, at least, in order to reach each other instead of existing between that VM. If we look at the maximum utilization of those devices, we're going to see that even if we spec'd it out to be a 10 gig interface, chances are you're not going to be able to get that. You're not going to be able to get that because of the multi-tenancy and the constraints that are built into that environment. If you really need a 10 gig interface, for example, into your VM, then that's something that you're going to have to look at your cloud service provider with and you may in fact actually have to contact them a little more aggressively than just by spinning up and clicking buttons that are on there, even though it tells you can get that. That gives you the Layer 1, right? You're still going to get Layer 1 at 10 gig, but the packet interchange, that frame interchanges takes place at Layer 2. That's really the important thing when you start looking at the communication that may exist into that device. Keep that in mind as you start looking at some of the things that happen there. In this environment level, we've got a complex solution, we've got firewalls, and we've got load balancers. Let's say we've got a couple of databases that are providing our rose purchasing service that are in there and their Mac should be load balancers outside that one from enterprise level so that we can continue to scale east and west as this service reaches its demand on the 2nd day into the 2nd week of February, into that type of environment. I've talked around a little bit about infrastructure as a service, and then platform as a service, and applications as a service. As you start thinking about stitching these things together, you're going to look at the marketplace that's available out there. Some of the common marketplaces are Amazon, Google, or Microsoft Azure. In those marketplaces, you can get a tremendous amount of resources that you don't have to build. You can actually just go out and license them. You can buy them from them. If you start looking at stitching those VMs together, it's not like you need to bring your own load balancer, your own firewall, your own application, your own database, your own web server, you can actually stitch those together. Maybe all you need to do is actually bring your own schema of the application or built on top of an API user interface that you want as you spin those types of environments up so that in those type of environments, you can bring your own instantiation as much as you want from that level or you can go out and you can stitch those together and put them on separate VMs. If you stitch them together, then that's where this inner VM, first of all, those applications need to know about each other. When we go back to that application, I said you can spin up the 10 gig interface, you can do that. It gets an IP address, I didn't tell you what that IP address was. At some point, if those two applications need to talk to each other, they need to know how to find each other. Just because they're applications and you've built them, you're going to have to do from a provisioning standpoint, some ability to interconnect to allow that stitching to take place. That's one of the things that we're going to talk about a little bit later in that environment. We go back to our classical rack layout. Again, we saw this picture earlier in a stylized form, we went from left to right. We've got a collection of servers and top-of-the-rack switches. Then we've got our firewalls, and load balancers, and maybe intrusion detection or deep packet inspection. I talk about that at the functionality takes place into those types of environments. But that rack then, those purpose-built plot appliances that we've talked before can be realized in servers if those are the right servers. Again, you can look back at the marketplace, and you can allocate those functionality and that traffic distribution for your interesting workload, and then idealized even more so is that those functionalities could actually be co-resident on your server itself. Some said the traffic flowing through a top-of-the-rack switch or a tour it provides. You can stitch those IP addresses together on that server. You can use capabilities, for example, inside that vSwitch operation in order to stitch those together. The network traffic between virtual machines can exist in a couple of different ways, is that there's inner machine traffic that is host to host. Typically, we want that traffic to not leave the host. As I mentioned in the earlier section, we don't want to bounce all the traffic off of the switch, off the top of the rack switch. Couple of reasons. One is that oftentimes switches don't like to do that. There's a configuration that's necessary in order to tell the switch to send traffic back out on the same port that it regressed on. That creates some problems operationally, but also it just consumes extra resources on a switch when it's not necessary. So inter VM traffic can exist through a virtual switch. That's a very common environment where the two VMs now need to know each other's IP address, so at least the one on the left side of the traffic flow needs to know the one on the right. The one on the right can learn the IP address from the first packet, it receives an order, send it back. But that packet, we'd like to keep it as close to those machines as possible and maybe right on the CPU interfaces from that level as opposed to even using a NIC card. There are some models that actually allow the traffic to move from the CPU to the NIC card and that card can perform the switching and move it back. But now again, we're moving traffic further than we need to in that type of an environment, and maybe consuming resources unnecessarily. Because remember, we want the realization to go up and we want that utilization to go purposefully, not just to drive the utilization up. Then the other model is when we've got traffic that goes inter machine, that goes across the machines. In that case, those virtual functions actually do need to go through the switching fabric. It would be a top of the rack type of switch that exists there. But again, those virtual machines need to know about each other from a VM standpoint and an IP address as a minimum. There are ways to do that we can look at using DNS servers. If those things get registered with an address that can be dereferenced. Or the most common way actually is, they get stitched together programmatically, it's been uptime since our collaborative, we tell them about each other. Of course, you only need again in that model, the left to right, the first one makes connection because the IP address of the source comes in on the packet oftentimes with the destination that exists there, so we can respond back and say that traffic in the backward direction when it's in that environment. There's another way that you can see. If you can go back to that model when we're talking about containers and the advancement and possibly into the unikernel type of an environment. That is if these applications themselves, these processes themselves are very collaborative and that is maybe coming from a single source or single vendor. There are ways in the software application to not use the networking stack itself, but rather use some type of inter-process communication. But security folks oftentimes have concern with that for a variety of reasons. But that is a way that the process can communicate it into those type of environments provided that they exist collaboratively on a single server. You do see some of that in some environments. But the most common way is to use the IP addressing mechanism and to use the resources of the physical device itself and keeps the traffic is close to the VM, just possible such or not. The other way we oftentimes use yours, so we're not trombone in traffic, unnecessary off the server and out in that direction. Those are the things. When we looked at virtualization back in 2012 timeframe and the decade that has passed, we've gone from interface speeds that were in the one gig range, and top-of-the-rack switches maybe the only 24 ports, in some cases at that one gig level. Today it's not uncommon to find things where we've grown two orders of magnitude. Two orders of magnitude in a decade is quite significant. It's not unusual today to find 100-gig interfaces into these devices, a 100 gig interfaces into some of the modern switches that are going out to the play. There's an awful lot of 10-gig, 25-gig, and even in some environments, 40-gig that are out to play there. The thing that happens is that we move further to the right in this diagram is that, things like network acceleration, certainly, become an issue. Is that back in the one gig era, we could do things like context switch, possibly from a network card itself. For those you may not be familiar with that word. A packet arrives physically under a network card itself and that packet, so a frame, layer 2, let's say, will get buffered up. We've got a beginning flag and an ending flag, and we do some calculation and go, "Yeah, I like that." Then that frame itself will get stored into a memory location on the card itself. The card has an array on it. But then it's got to get in the memory and the CPU in order for it to be used. In the old days, the card itself could issue a hardware vector interrupt; it would raise a flag, a physical flag if you would. It's not a real flag, but a line would change state from one to zero, zero to one. It would cause an interrupt and operating system would perform a contact switch on that server, take resources. So I push things onto the stack, pop things off the stack, and ago, "Oh, you've got information for me." It would pull the stuff from the buffer that exists and maybe there are multiple frames, but it would pull everything from those buffers that are in there into some memory location and the operating system would look through that and go, "This was meant for that process, this was meant for that process based on some knowledge that it's got in there." Then it would schedule that information to be transferred into those process. Terribly inefficient if you just think about everything that I've described. But if all you've got is a one gig interface, you can do it at that speed. But as soon as you start looking at 10 gig interfaces, now you can't afford all that overhead. There are accelerator technology that came along, DPDK is a very popular one or SRLV. What that does is that allows that traffic to move more efficiently from the network interface card itself into the memory of the CPU. Sometimes we'll talk about pulling, I'm not going to go a lot into that detail, but that allows certain cores on that CPU to be constantly looking down to that network card and moving that information in real time without having this process contact switch to an operating system and back taking place, it's in there. Now what happens is you give up some resources, you give up a core or two in order to do that. But we're able to then operate, let's say four core, if we give up four cores we can easily handle 10 gig of interface traffic that's going from one device to the other. Where we are today is that we're in a situation where we can handle about three, three-and-a-half easily of throughput on a per-core basis. You look at 10 gig interface, maybe you're going to consume four cores in order to do that. But as we start looking at 25 gig and 100 gigs, we find that we need to do additional things in packet acceleration or network acceleration that comes into play. In order to reach that, and there's work going on in these environments to get to the point where we can now see servers that can handle 200 gig of throughput. So you think about, again, left to right type of traffic that I spoke of St. Louis to Chicago or St. Louis to New York or Los Angeles type of an operation. There are servers that are capable of handling that East to West traffic at 100 gig in both directions, so 200 gig type of operation without consuming all those resources and still in that bump of the wire tap application, realize how high-capacity, and high-performance, and high-throughput. We're going to 400 gig. Before we know, we're going to wake up tomorrow and we're going to be talking about 400 gig interfaces on these devices. There's work going on to get that high volume of hyperscale offload into that type of environment as we see that coming out. Today's implementations, I said we can easily reached 100 gig com and the 200 gig range in the capabilities of using those Xeon processors and features like SRLV and DPDK. There are packet acceleration capabilities that are coming about that may allow us to handle some traffic, lowering the stack, and there are additional design capabilities that are coming about in the software layers that allow us to more efficiently handle those at the upper layers, so we talked a little bit about that unikernel type of possibility. When we start looking at that, it's also about utilization of those resources and how to optimize that and putting features into the systems that allow us to reach that very high level of scalability into the environment. I think that's about the end of the things that I wanted to comment on. I hope you've learned a little bit of something in this course. We've got follow-on material that you're going to get into that East or West traffic. One of my colleagues is going to talk more about the capabilities necessary for network acceleration very specifically. The thing has to happen in that multi-port type of an environment, which is quite interesting to these network functions. Not just interesting, but in many cases it's quite necessary. Thanks for joining us.
