Current IP networks make use of a number of additional functionalities beyond the pure IP forwarding. The course lists them explicitly: firewall, NAT, proxy, intrusion detection systems, traffic profilers, and the inevitable "…". Each of these is historically implemented by a different physical device, so a real path from a user to a service crosses an access router, a firewall, a NAT, a DPI box, a switch, a media or web server and an edge router — a plethora of middleboxes, each one added cost and added complexity.
The slides draw this twice, under two headings, and the pair of pictures is the whole argument of NFV in one image.
A Virtual Network Function (VNF) is defined in the course as a virtualized networking function in which the functionality is de-coupled from the hardware used to implement it. Two immediate consequences are listed: it enhances scalability and it reduces the operational burden.
More interesting are the three new opportunities that only exist once the function is software:
The first example of NFV exploitation used in the slides comes from A. Manzalini et al., Clouds of Virtual Machines in Edge Networks, IEEE Communications Magazine, July 2013, and it is used to show the same migration twice: VNF migration without QoS support and VNF migration with QoS support. The comparison makes the point that moving a function is easy; moving it while preserving the service quality is the engineering problem.
A VNF is not "a firewall in a VM". It is the claim that the identity of a network function no longer depends on the box it runs in. Everything that follows — placement, chaining, migration, orchestration — is only meaningful once that de-coupling holds.
Network Function Virtualization (NFV) is the systematic version of the idea: virtualize the Physical Network Functions as Virtual Network Functions. Two practical statements accompany it in the slides. First, this requires data centers in the networks to host the virtualization. Second, the implementation depends on the computing platform running the data center — NFV does not prescribe a hypervisor, it prescribes a separation.
Consistently with that, VNFs can be deployed in many different fashions:
Each VNF is a full guest operating system plus the application, over a virtualization hypervisor. Strongest isolation, heaviest footprint. This is the deployment style assumed by most of the early ETSI work, and it is what an OpenStack compute node hosts.
The VNF is an application plus a runtime environment sharing the host operating system — Docker, Kubernetes are named explicitly. No guest OS means far less overhead and much faster start-up, at the price of a shared kernel. This is the model used by Kathará in chapter 11, where every emulated network device is a container.
MiniKernels: minimal kernels carrying just enough OS to run one function. The point of listing all three is that NFV is a principle about de-coupling, and the packaging technology is an implementation choice that keeps changing.
The slides make a careful distinction. The VNF concept may be used individually by any user or network operator, each with different architectures and implementation strategies — nothing stops you. But applying the concept to the whole network in an open fashion requires a standard. The answer is ETSI NFV-MANO (Network Function Virtualization Management and Orchestration), started by ETSI in 2012.
Two dates and one name worth having ready: ETSI started the NFV-MANO initiative in 2012; the first NFV exploitation example used in class is Manzalini et al., IEEE Communications Magazine, July 2013. And the reason a standard exists at all: individual use needs no standard, open use across a whole network does.
The slides put the two stacks side by side, and the difference is exactly one layer.
Docker is described as a client-server system that allows you to create containers, store and retrieve containers and execute containers. The registry is the repository of container images.
The part that matters for a networking course is the set of Docker network drivers, because they are the first virtual network infrastructure you will meet:
The default choice. It is the LAN of the containers that need to communicate with one another. Conceptually it is the software equivalent of plugging every container into the same Ethernet switch — which is literally what you will build by hand in chapter 4 with ip link add type bridge.
No networking isolation: the container is connected to the host network interface. Fast and simple, but the container now shares the port space of the host, so two containers cannot both bind port 80.
To be used by containers that do not need networking: the container has no network interface at all. The slides add that a custom user driver can be used for specific applications of the container.
The three drivers map cleanly onto the three isolation choices that Linux namespaces give you, and chapter 4 shows the mechanism underneath: bridge is a separate network namespace attached to a bridge by a veth pair, host is "do not create a network namespace at all", none is "create it and leave it empty".
A cloud computing infrastructure is presented as four physical components built on general purpose hardware configuration — which is the whole point, since commodity hardware is what makes the economics work:
| Node | Role |
|---|---|
| Controller | Management console: it hosts the cloud platform management system. |
| Compute node | Hosts virtual machines and related computing tasks — the computational resources actually running the VMs. |
| Network node | Hosts shared network components: gateway for external connectivity, multi-tenant isolation, network configuration and additional service providers. |
| Storage node | Hosts shared storage devices: VM images and virtual hard disks. |
The OpenStack example in the slides is built up one layer at a time, and the layering is instructive because three different networks appear, each with its own job:
Here is the sentence that defines the Virtual Network Infrastructure (VNI), and it is worth quoting almost literally: every tenant sees its own conventional LAN — LAN switch, DHCP and DNS servers, default gateway — but none of these exist as real devices; they exist as software components forming the Virtual Network Infrastructure.
That is the crux of the whole topic. From inside a tenant VM, the network looks entirely ordinary: there is a switch, there is a gateway, there is a DHCP server that hands out an address. Every one of those is a process or a kernel object somewhere on a controller, a network node or a compute node. The distributed switch spans the compute nodes; the DHCP server and the gateway/NAT live on the network node; the controller node orchestrates them.
The tenant's mental model is deliberately conservative — a normal LAN — while the implementation is entirely software. That gap is what makes the VNI usable, and also what makes it hard to debug: there is no cable to unplug and no switch LED to look at, which is exactly why chapter 4 builds one by hand.
The slides open a compute node hosting two VMs and label every object on the path. Four kinds of object appear:
| Object | What it is |
|---|---|
| Virtual tap | The network plug for the VM Ethernet interface eth. |
| Virtual Ethernet pair (veth) | Required to establish a virtual point-to-point Ethernet link between two objects. The logical equivalent of a cable with a plug at each end. |
| Linux bridge | An unmanaged Ethernet switch in software. |
| Open vSwitch (OVS) | The more advanced virtual switch; two of them appear in series in the reference diagram. |
A tunnel with the network node is used to reach the instances/tunnel data network. On the network node the picture is analogous but the contents differ: a gateway to the external network with a specific routing table, a DHCP server, and Open vSwitches.
The course does not present the VNI as free. A measurement campaign compares the traffic received against the traffic generated, in kilopackets per second, for chains of virtual switching elements, with a back-to-back (B2B) physical reference curve as the upper bound. Two comparisons are made:
The general lesson is the one the plate above sets up: every Linux bridge and every Open vSwitch on the path is a software forwarding stage, and each stage consumes CPU per packet. A VNI that looks clean in a topology drawing may contain four or five switching stages between a VM and a physical NIC.
Different users mean different virtual infrastructures, and OpenStack isolates tenants: tenant #1 and tenant #2 each see their own switch, their own gateway/NAT and their own address plan, while sharing the same compute nodes and the same controller node.
The multi-tenancy measurement in the slides is set up carefully, and the setup itself is worth reading as a template for how to evaluate a VNI: different numbers of tenants are simultaneously active on the same compute node; each sender generates UDP traffic ranging from 103 to 105 packets per second; all physical interfaces are Gigabit Ethernet network cards.
Be able to explain why tenant isolation costs performance, not just that it does. Isolation is implemented by additional virtual switching and tunnelling stages (per-tenant bridges, per-tenant tunnels), and every stage is software forwarding on the same CPU that also runs the tenants' VMs. Scaling the number of tenants on one compute node therefore scales the per-packet work, which is what the UDP measurement from 103 to 105 pps is designed to expose.
Do not read the performance slides as "virtual switching is bad". They are there to justify the rest of the course: if forwarding in software is expensive, then either you accelerate the software path (SR-IOV, DPDK — see chapter 13) or you push the behaviour back into the silicon while keeping it programmable (P4 — chapters 5 to 8).
A middlebox implements a functionality beyond pure IP forwarding: firewall, NAT, proxy, intrusion detection system, traffic profiler. The problem is that each functionality is a different physical device, so a real path crosses a plethora of them; the slides summarise the consequence as added cost and complexity, and each box must be configured and maintained separately.
A Virtual Network Function is a virtualized networking function in which the functionality is de-coupled from the hardware used to implement it, which enhances scalability and reduces the operational burden. The new opportunities listed are network function roaming, keeping functions in the proximity of the user to reduce latency, and modifying the service paradigm by changing the network function.
Virtualize the Physical Network Functions as Virtual Network Functions. The two constraints: it requires data centers in the networks to host the virtualization, and the implementation depends on the computing platform running the data center.
Because the VNF concept may be used individually by any user or operator, each with different architectures and implementation strategies — that works in isolation. Applying the concept to the whole network in an open fashion requires interoperability, and therefore a standard. ETSI started NFV-MANO in 2012.
The container stack has no guest OS and no hypervisor: application plus runtime environment sit directly on the host operating system. The VM stack inserts a guest operating system per VM over a virtualization hypervisor. Isolation is stronger with VMs; density and start-up time are far better with containers. Mini-kernels are the third option named in the course.
bridge — the default; it is the LAN of the containers that need to communicate with one another. host — no networking isolation, the container is connected to the host network interface. none — for containers that do not need networking, the container has no network interface; a custom user driver can be used for specific applications.
Controller (management console), compute node (hosts VMs and related computing tasks), network node (hosts shared network components: gateway for external connectivity, multi-tenant isolation, network configuration and additional services), storage node (shared storage: VM images and hard disks). All on general purpose hardware.
The External Net, which connects the platform to users and the Internet; the Instance/tunnel (data) network, a physical LAN for inter-machine VM communication; and the Management Net, a physical LAN for control and management traffic. Separating them separates three different security and failure profiles.
The set of software components that give every tenant its own conventional LAN — LAN switch, DHCP and DNS servers, default gateway — none of which exist as real devices. The distributed switch spans the compute nodes; DHCP and the gateway/NAT run on the network node.
The virtual tap (network plug for the VM Ethernet interface), the veth pair (a virtual point-to-point Ethernet link, needed to connect two objects), the Linux bridge, and Open vSwitch. A tunnel towards the network node carries the traffic onto the instances/tunnel data network.
Traffic received (Kpps) was plotted against traffic generated (Kpps), with a back-to-back physical path as reference. Two comparisons: two VMs in two compute nodes versus two VMs in one compute node; and, inside a single compute node, two VMs with Open vSwitch versus two VMs with Linux Bridge. Each additional software forwarding stage costs CPU per packet.
Different numbers of tenants are simultaneously active on the same compute node; each sender generates UDP traffic ranging from 103 to 105 packets per second; all physical interfaces are Gigabit Ethernet cards. The point is to see how per-tenant isolation, implemented as extra virtual switching, degrades as tenants are added.