Network Virtualization (English)

by Sasha Shkrebets — last modified Feb 04, 2025 10:15 AM

We are continuing our discussion of the history of software defined networks. Today, we'll talk about, network virtualization. We'll first talk about what network virtualization is, and what it's useful for, and we'll trace its history back to the 1990s, as well as exploring some of the developments in network virtualization.

Welcome back.

We are continuing our discussion of the history of software defined networks.

Today, we'll talk about, network virtualization.

We'll first talk about what network virtualization is,

and what it's useful for, and we'll trace

its history back to the 1990s, as well

as exploring some of the developments in network virtualization.

Over the past ten years, in the form of

both support for network experimentation, as well as various

concepts such as the separation of service providers from

infrastructure providers that we saw in some earlier network architectures.

We'll also look forward and talk about

how network virtualization relates to software defined networks.

So, to remind you where we are, we are in the third

of three lessons where we are discussing the evolution of supporting technologies.

We just finished our discussion of the history of network programmability

and we also talked about the history of central network control.

In this lesson we will talk about the history of network virtualization.

So, first of all, what is network virtualization?

Simply put, network virtualization is the representation of one or more

logical network topologies on top of the same underlying physical infrastructure.

And there are many different instantiations of network virtualization.

Some of them that predate even the 1990s such as virtual LANs.

What we are going to talk about in this lesson, however, are

various technologies and network testbeds that

use and develop network virtualization since then

that have essentially led to some of the more mature virtual network

technologies that we see in the form of companies and commercial products today.

So, first of all, what are the benefits of network virtualization.

One of them is sharing.

So, using network virtualization, one can instantiate multiple logical

routers on top of a single physical node or a

single platform and more generally one can instantiate multiple

virtual networks on top of the same physical network infrastructure.

This sharing of course requires the ability to provide resource isolation

in terms of CPU, memory, bandwidth, forwarding tables and so forth.

So, in addition to sharing, network

virtualization offers the prospect of customizability.

Users of a virtual network could essentially get

a view of their own logical network and logical

network topology that's separate from other logical networks that

may be running on the same underlying physical infrastructure.

And the ability to see an independent

logical network also allows the ability to run

custom routing and forwarding software on that own,

on that particular slice of the virtual network.

So, let's just look at what this might look like in terms of a few pictures.

So, let's assume we have a fixed physical infrastructure and on

top of that fixed physical infrastructure, the routers, links and so forth.

We might have multiple parties who want to use that fixed physical infrastructure.

So, we might have the red party and we might have the blue party.

Each of which might want access

to different underlying physical network resources.

Each of those parties might also want to instantiate different

arbitrary virtual topologies on top of that underlying physical infrastructure.

So, the idea here is that each of these parties

who wants to use the infrastructure has the ability to

create their own view, or their own virtual topology, their

own logical topology sitting on top of that physical infrastructure.

And the idea is that each of these would

be able to run independently without interfering with one another.

So, in the rest of this lesson we

will explore three different examples of virtual networks.

One is the Tempest architecture, Switchlets,

which dates back to the late 1990s.

And some of the ideas that came out of Switchlets are

the separation of the control framework from the underlying switches themselves.

As well as the ability or capability to virtualize the underlying

switch hardware to provide the appearance of multiple virtual switches.

The second virtual network technology that we'll look at is something called the

virtual network infrastructure or VINI which

dates back to 2006 and the motivation

here was to provide a virtual

network infrastructure so that experimenters could run

experiments with their own logical networks

shared on the same underlying physical topology.

Then we'll look at a network architecture called Cabo, which used

some of the vision of the emerging virtual network technologies to

realize that virtual networks could allow service providers to operate independently

of the providers that, that make

the underlying physical network infrastructure available.

So let's first look at switchlets, which

came out of something called the Tempest architecture.

In this particular architecture, we have

a single underlying switch, with its resources.

And then we have an open switch control interface

then exposes those resources to software that is sitting above.

Indeed, that control interface does look a little bit like open flow.

So, the idea or the motivation behind switchlets was to

allow multiple control architectures to operate over a single ATM network.

The open control interface separated the switch controller

and the fabric via an open signaling protocol.

And the divider partitioned the switch resources to allow multiple

controllers each to have their own view of a logical switch.

Indeed, that looks a little bit like flow visor, something that we will explore

a little bit more when we talk

about modern SDN architectures, particular open flow.

The switch divider, partition port space, bandwidth and

buffers, and allow different controller to control each switchlet.

In addition to the similarity of this architecture

to some more modern SDN architectures, it's also

interesting to note this paragraph in the conclusion

of the paper that introduces the switchlet architecture.

It says, as anyone who can obtain a virtual

network will effectively be a network operator, we hope

to see an increase in the creativity that can

be brought to bear upon the problem of network control.

So that's interesting because it essentially predicts what

happens next, which is the realization that virtual network

infrastructures can allow network researchers to bridge the

gap between small scale experiments and simulation and real

live deployments and that was the motivation behind VINI or

the virtual network infrastructure.

The idea here was that on one hand, we had

controlled, repeatable lab experiments that were potentially not so realistic.

And on the other hand we had live deployments, which were very

realistic, could scale up, run real

traffic, but not necessarily be repeatable.

And the idea here, was that we could use

network virtualization to bridge the gap between, repeatability and realism.

So, VINI runs real routing software, and exposes real,

realistic network conditions to the applications running on it.

It gives control to the experimenter

over different network events, such as failures.

It can carry traffic on behalf of real users.

It can also be shared among many different experimenters.

VINI also used a separation of the data and control

planes to achieve some of its goals of network virtualization.

Its control plane is a software router called

XORP, which runs a variety of different routing protocols,

with the goal of allowing the experimenters to run

real routing protocols on top of virtual network topologies.

VINI's data plane provides the appearance of these

virtual network topologies to experimenters.

VINI's data plane is implemented using a software router called Click,

and the interfaces, the virtual interfaces were implemented using

a technology called Tunneling which is also used in many other virtual

network technologies, to create the appearance of virtual links.

In VINI, experimenters could also put filters in front of these

tunnels, to create the illusion, or appearance of failing a link.

These filters would essentially just block packets on individual tunnels.

Given the technologies to build virtual networks,

researchers then began exploring how this technology could

be used to facilitate the introduction of

new services and speed the pace of innovation.

One of those architectures was called Cabo,

or Concurrent architectures are better than one.

This architecture offered the insight that the infrastructure providers, or

those parties that maintained routers, links, data centers and other physical

infrastructure, could operate independently or

separately from the service providers

that offered end to end services on top of that infrastructure.

Examples of this separation between infrastructure and

service providers, in some sense, already existed.

Two such examples were packet fabric, which allowed multiple

ISPs to share the same physical routers at exchange points.

And FON, a commercial internet service provider that

resells users' wireless Internet connectivity to its customers.

FON has an interesting economic refactoring, where the users in their

homes, who buy upstream connectivity from different Internet service providers,

are effectively the infrastructure providers and FON is simply a broker of

that Internet service and effectively acts as the service provider.

So let's just summarize what we've learned in this lesson.

We have learned about network virtualization, particular what it is.

Network virtualization separates the logical network that users

or service providers see from the underlining physical

infrastructure and potentially allows multiple parties to share

that same underlining physical infrastructure for different purposes.

Network virtualization has a rich history dating back

to virtual switches or switclets in the 1990s.

Network test beds such as VINI and these architectures that

envision using network virtualization to offer different types of services.

The legacy of network virtualization for SDN is actually quite rich.

The idea of separating service providers from infrastructure providers is something

that we see a lot in commercial software defined networks today.

The idea of using multiple controllers to control a single switch

and exposing multiple logical switches on top of a single switch is

actually something that has roots in the switchlets architecture.

And the notion that a single physical

infrastructure could, in fact, expose multiple logical

network topologies also has its roots in

a lot of this network virtualization research.

So, to summarize, we have just completed three

lessens that explore supporting

technologies for software defined networks.

Next, we'll talk about different types of standardization of the control plane

that were going on in parallel

with the evolution of these supporting technologies.