ors today already support both VMWare and KVM hypervi- sors for the network functions they offer. The discussion on virtualization, however, cannot be concluded without exploring another form of virtualization that is getting a lot of traction, especially in a cloud environment called Linux Containers [3]. While Linux Container as a technology is not new, its application as a form of vir- tualization is relatively new. A hypervisor focuses on virtualizing the hardware, whereas containers work on the principal of virtualizing the host operating system. Since there is only one OS/kernel on the machine, containers do not have the overhead that exists with the hypervisor model. For example, in a typical hypervisor environment, each virtual machine (VM) has its own guest OS. So if you have four virtualized network functions (VNFs) implemented as VMs, you get five OSs running on the platform-each one consuming resources on the platform and trying to schedule the job on the same CPU cores. With Linux Containers, we have a single OS function on the plat- form with a single scheduler used by all functions. As a result, this form of virtualization provides significant boost to improve the packet-performance capability necessary for applications such as network functions (Figure 10.5). However, today the Container-based approach does not allow all the needed flexibility required by different VNF vendors. Different VNF functions may need to customize the kernel, or depend Container 1 Container 2 Host os COTS HW FIGURE 10.5 Linux containers. Enterprise Networks on certain kernel versions, and this does not work well since all functions will need to share the same kernel. In particular, for an environment where the same machine is required to host software applications sourced from different vendors let alone different functions, these issues become much more relevant. Multiple VNFs sharing a single kernel can also create security and stability issues that are yet to be solved. As an example, since every application uses the s