Welcome back. In this module we'll look at network virtualization. The module will have three lessons. The first will look at what Network Virtualization is and how it's implemented. The second lesson we will look at some examples of network virtualization, and various applications for it. And finally we'll look at virtual networking in Mininet. We'll see how Mininet implements network virtualization, and we will get a chance to play around with it a little bit in the Mininet environment. There will also be a quiz and a hands on assignment in Mininet as part of this module. So let's jump in and start exploring this first question. What is network virtualization and how is it implemented? So simply put, network virtualization is a particular abstraction of a physical network that allows the support of multiple logical networks running on a common shared physical substrate. In other words, you can have a common set of physical routers, links, and so forth. That support multiple logical network topologies on top of that physical infrastructure. Another way of viewing it is as, as, as a container of network services from layer two all the way up to layer seven, that can be instantiated on some underlying physical platform. There are various aspects of the network that can be virtualized, and together these technologies support network virtualization. So, on one hand, the nodes need to be virtualized. One technology for virtualizing those nodes is with virtual machines, and we'll look at various examples of virtual machine technology in this lesson. The links themselves also have to be virtualized, and a common way of doing that is with tunnels. And we'll look at various ways of doing that as well. Finally, there are other parts of the network that also can be virtualized such as storage and so forth. And we won't really look at those in this lesson, but they are certainly relevant to network virtualization in general. So here's a pretty good picture describing the analogy of network virtualization. On the left hand side, we have sort of a more conventional virtualization environment which you may be familiar with, which is the virtual machine environment. In this environment, the machine's physical CPU, memory, and IO are essentially abstracted by a hypervisor on top of which multiple virtual machines can run. Each of these virtual machines essentially gives the appearance of running on a dedicated platform, when in fact the hypervisor sitting below the virtual machines is responsible for ensuring isolation and resource control. Now, in the same way that a machine can be virtualized, a physical network can also be virtualized. So, similarly to the hypervisor which virtualizes a single machine, a virtualization layer can provide support so that multiple virtual networks can coexist on top of a single, shared, physical network. And similarly, that virtualization layer is responsible for insuring isolation, and proper resource sharing between these distinct virtual networks. So what's the motivation for network virtualization? Well, one of the original motivations was, The ossification of the internet architecture. And there's lots of work on overlay networks in the 2000s in networking that essentially was trying to make changes to network functions by yielding overlay networks on top of the underlying IP infrastructure. Acknowledging the fact that it was rather difficult to change the underlying IP infrastructure. In the course of doing this work, many people began to realize that a one size fits all architecture is, is actually rather difficult. It's very difficult to design a new network that would be everything to everyone. So the motivation then was to provide some kind of infrastructure that allowed network technologies to evolve so that once that platform was deployed. The technologies could evolve on top of that platform independently of the underlying infrastructure. And in particular the motivation for network virtualization was to create some kind of substrate where 1,000 flowers can bloom. So you could have one particular experimental virtual network running aside the production network, and these virtual networks need not interfere with one another. So these days the promise of network virtualization is significant. One particular promise is rapid innovation, services could be delivered at software speeds. Another is that it makes possible new forms of network control. Since network virtualization makes it possible to instantiate multiple logical networks on top of a single physical network, the ability to deploy and instantiate multiple different kinds of networks makes it possible to explore different kinds of control as well. A third promises vendor choice. So because the logical network is decoupled from the underlying physical infrastructure, in some sense it matters less what the underlying physical infrastructure is in terms of vendors and so forth. Because all the magic is happening at higher layers of extraction. Network Virtualization also provides the promise of simplified programming and operations by allowing the network operator to see the network through a logical abstraction, rather than having to tinker with the details of the underlying physical network. So, in looking at the promise of network virtualization, it's important to recognize a distinction because many of these promises are sometimes touted as the promises of SDN. But, it's important to recognize that SDN itself does not inherently abstract the details of the physical network. Essentially what it does is separate the data plane from the control plane. But network virtualization is the technology that provides the abstraction, so that multiple logical networks can be instantiated on top of that single physical network. So related topic is Virtual Private Networks, which you may have heard of, but it's a, it's a quite a different thing from network virtualization or virtual networks. Virtual private networks are essentially virtual networks that connect distributed sites. So, for example, if you're in an enterprise or company, you may use a virtual private network, or a VPN, to securely tunnel back to different parts of that enterprise network. But, in contrast to the types of network virtualization that we're talking about in this course, VPNs are not designed to let multiple custom architectures run on the same underlying physical infrastructure. So, for example, it would be very tough to run an IPv4 network in parallel with some kind of next generation non-IP network, for example, on conventional VPNs. Virtual networks, on the other hand, are explicitly designed to enable and support that kind of heterogeneity. Let's now have a quick look at some of the design goals of virtual networks. One of the design goals is flexibility. That is, virtual networks should be able to support many different kinds of topologies, routing and forwarding architectures and paradigms, and they should be able to allow each virtual network to be configured independently from the others. Virtual networks should separate policy and mechanism as well, thereby enabling better manageability. And a good virtual network's platform should maximize the number of virtual networks that can co-exist on the same underlying physical substrate. Network virtualization technology should also isolate both the logical networks that are running on top of the shared physical substrate, as well as the resources to ensure that no single virtual network can take more than it's fair share of the underlying physical resources. Or otherwise interfere with resource allocations of other virtual networks. Virtual networks should be programmable. That supports the goal of customizability. And they also should support many different underlying technologies. The idea being that a logical network in some sense should be unaware, or not need to be aware of the underlying physical infrastructure that supports that logical network. So building a virtual network requires, of course, the technology to build virtual nodes or machines. One particular approach for doing that is the Xen Virtual Machine Monitor. Another is User-Mode Linux, with something called network namespaces. Network namespaces were originally an add on to the Linux kernel and they're now part of the main line Linux kernel. The idea with network namespace is, is essentially that each container gets it's own view of the network. It's own network stack. IP addresses, MAC addresses, interfaces, and so forth. KVM is another virtualization technology. And there's certainly others as well. VMWare of course makes their own commercial virtual machine technology. And Virtual Box is one that we'll use in this course. Let's take a closer look at one example virtual machine environment, Xen. So, in this picture, which describes the Xen architecture, you can see that Xen essentially allows multiple what are called guest operating systems to run on the same underlying shared physical hardware. So the hardware here, of course, which is processor memory, the physical network interfaces, and so forth. Is then abstracted away by the Xen hypervisor. And Domain0, which is shown over here on the left, essentially runs the control software that arbitrates how these other guest OSs gain access to the underlying resources. We also need a way of constructing virtual links. And there are many possible ways to do that, all essentially based on different types of tunneling technology. One approach is to take Ethernet frames that are generated by virtual nodes and encapsulate those Ethernet frames in IP packets that may travel multiple hops over an IP network. So, two virtual machines or virtual nodes, have the appearance of being connected by a point to point, layer two Ethernet link. But are in fact sending the frames over a multi-hop IP network. There are other approaches to generating or constructing virtual links, such as VXLAN. Now, each one of these containers or virtual nodes also has virtual interfaces, here denoted as ZTON. Which have to be connected to the physical interfaces on each of these physical network nodes. And that requires some kind of virtual switching technology. The trellis architecture shown here, devised something called a short bridge which was essentially a fast, mechanism for taking Ethernet frames inside a virtual machine, and passing them to the physical interface on the node that was hosting that virtual machine. But, since this architecture was proposed, there have been other technologies to do this. One is Open vSwitch. Now as I mentioned, the problem here is to network these virtual machines together over a Layer 2 topology. VINI or Trellis use shortbridge, which is an extension of Linux bridging. The Open vSwitch basically performs a similar set of glue functions, but also the Open vSwitch can be configured remotely with control protocols like OpenFlow or JSON. So in summary, the motivation for virtual networks is flexible and agile deployment. Thereby enabling rapid innovation, independence from vendors, and scale. There are various technologies that are requirements to support for virtual networks including virtual nodes, links and switch. And we've discussed some of the technologies that have been developed to support each one of those components of a virtual network. We also talked about the distinction between software-defined networks, and virtual networks. So let's review that briefly. SDN effectively separates the data plane and the control plane. Whereas, virtual networks separate logical and physical networks. So, SDN's are in some sense a useful tool for implementing virtual networks, but the two concepts are certainly distinct from one another.
