Computer Networks: A Systems Approach, Release Version 6.1
Figure 3.40.: Network Operating System (NOS) hosting a set of control applications and providing a logi- cally centralized point of control for an underlying network data plane.
Key Takeaway
It is important to understand that SDN is an implementation strategy. It does not magically make fundamen- tal problems like needing to compute a forwarding table go away. But instead of burdening the switches with having to exchange messages with each other as part of a distributed routing algorithm, the logically central- ized SDN controller is charged with collecting link and port status information from the individual switches, constructing a global view of the network graph, and making that graph available to the control apps. From the control application’s perspective, all the information it needs to compute the forwarding table is locally available. Keeping in mind that the SDN Controller is logically centralized but physically replicated on multple servers—for both scalable performance and high availability—it is still a hotly contested question whether the centralized or distributed approach is best.[Next]
As much of an advantage as the cloud providers have been able to get out of SDN, its adoption in enterprises and Telcos has been much slower. This is partly about the ability of different markets to manage their networks. The Googles, Microsofts, and Amazons of the world have the engineers and DevOps skills needed to take advantage of this technology, whereas others still prefer pre-packaged and integrated solutions that support the management and command line interfaces they are familiar with.
erably smaller that the apparent pool of virtual memory. This abstraction enables programmers to operate under the illusion that there is plenty of memory and that no-one else is using it, while under the covers the memory management system takes care of things like mapping the virtual memory to physical resources and avoiding conflict between users.
Similarly, server virtualization presents the abstraction of a virtual machine (VM), which has all the features of a physical machine. Again, there may be many VMs supported on a single physical server, and the operating system and users on the virtual machine are happily unaware that the VM is being mapped onto physical resources.
A key point is the virtualization of computing resources preserves the abstractions and interfaces that existed before they were virtualized. This is important because it means that users of those abstractions don’t need to change—they see a faithful reproduction of the resource being virtualized. Virtualization also means that the different users (sometimes calledtenants) cannot interfere with each other. So what happens when we try to virtualize a network?
VPNs, as described inSection 3.3, were one early success for virtual networking. They allowed carriers to present corporate customers with the illusion that they had their own private network, even though in reality they were sharing underlying links and switches with many other users. VPNs, however, only virtualize a few resources, notably addressing and routing tables. Network virtualization as commonly understood today goes further, virtualizing every aspect of networking. That means that a virtual network should support all the basic abstractions of a physical network. In this sense, they are analogous to the virtual machine, with its support of all the resources of a server: CPU, storage, I/O, and so on.
To this end, VLANS, as described inSection 3.2, are how we typically virtualize an L2 network. VLANs proved to be quite useful to enterprises that wanted to isolate different internal groups (e.g., departments, labs), giving each of them the appearance of having their own private LAN. VLANs were also seen as a promising way to virtualize L2 networks in cloud datacenters, making it possible to give each tenant their own L2 network so as to isolate their traffic from the traffic of all other tenants. But there was a problem:
the 4096 possible VLANs was not sufficient to account for all the tenants that a cloud might host, and to complicate matters, in a cloud the network needs to connectvirtual machines rather than the physical machines that those VMs run on.
To address this problem, another standard calledVirtual Extensible LAN (VXLAN) was introduced. Unlike the original approach, which effectively encapsulated a virtualized ethernet frame inside another ethernet frame, VXLAN encapsulates a virtual ethernet frame inside a UDP packet. This means a VXLAN-based virtual network (which is often referred to as anoverlay network) runs on top of an IP-based network, which in turn runs on an underlying ethernet (or perhaps in just one VLAN of the underlying ethernet). VXLAN also makes it possible for one cloud tenant to have multiple VLANs of their own, which allows them to segregate their own internal traffic. This means it is ultimately possible to have a VLAN encapsulated in a VXLAN overlay encapsulated in a VLAN.
The powerful thing about virtualization is that when done right, it should be possible to nest one virtualized resource inside another virtualized resource, since after all, a virtual resource should behave just like a physical resources and we know how to virtualize physical resources! Said another way, being able to virtualize a virtual resource is the best proof that you have done a good job of virtualizing the original physical resource. To re-purpose the mythology of the World Turtle: It’s virtual networks all the way down.
The actual VXLAN header is simple, as shown inFigure 3.41. It includes a 24-bitVirtual Network Id(VNI), plus some flag and reserved bits. It also implies a particular setting of the UDP source and destination port fields (seeSection 5.1), with the destination port 4789 officially reserved for VXLANs. Figuring out how to
176 Chapter 3. Internetworking
Computer Networks: A Systems Approach, Release Version 6.1
Figure 3.41.: VXLAN Header encapsulated in a UDP/IP packet. header.
uniquely identify virtual LANs (VLAN tags) and virtual networks (VXLAN VIDs) is the easy part. This is because encapsulation is the fundamental cornerstone of virtualization; all you need to add is an identifier that tells you which of many possible users this encapsulated packet belongs to.
The hard part is grappling with the idea of virtual networks being nested (encapsulated) inside virtual net- works, which is networking’s version of recursion. The other challenge is understanding how to automate the creation, management, migration, and deletion of virtual networks, and on this front there is still a lot of room for improvement. Mastering this challenge will be at the heart of networking in the next decade, and while some of this work will undoubtedly happen in proprietary settings, there are open source network virtualization platforms (e.g., the Linux Foundation’sTungsten Fabricproject) leading the way.
Broader Perspective
To continue reading about the cloudification of the Internet, seePerspective: The Cloud is Eating the Inter- net.
To learn more about the maturation of virtual networks, we recommend:
• Network Heresy, 2012.
• Tungsten Fabric, 2018.
3.5. Implementation 177
178 Chapter 3. Internetworking
CHAPTER