Network Functions Virtualization (text)

by Sasha Shkrebets — last modified Mar 06, 2023 01:19 PM

n this lecture, we'll talk about network functions virtualization, which is a way for network operators to place arbitrary functions in virtual machines and distribute them across the network.

Welcome back.

In this lecture, we'll talk about network functions virtualization, which is a way

for network operators to place arbitrary functions in virtual machines and

distribute them across the network.

NFV is increasingly taking hold with the rise of light weight containerization.

I'll talk a little bit about what NFV is, including various problems and

challenges that arise with NFV.

I'll then devote some time to talking about Slick, a system for

orchestrating the placement of network functions throughout the network, and

steering traffic flows through those network functions

based on high-level network control.

To understand NFV, it helps to start by understanding the status quo.

When middlebox functions are placed in separate monolithic middleboxes.

In contrast, NFV places these functions in virtual machines or

even virtual containers, and distributes these functions across the network.

By decoupling these functions from hardware that hosts them,

operators gain increased flexibility over how packet processing is performed.

Some of the benefits of NFV include reduced capital expenditures and

time to market, ability to scale middlebox functions up and

down as network demand changes, developing services that are specialized or

targeted for a particular application, and doing so

in ways that are independent of individual hardware vendors.

New use cases include virtualized services for enterprise, content distribution,

virtualized core networks, and the integration of production and testing.

One way I like to think about NFV is that it makes it possible to create

functional elements, sometimes on significantly finer granularity,

as opposed to monolithic middleboxes.

When we think about various middlebox functions, for

example, we can see that each of them is a combination of smaller modular functions.

One view of NFV is thus that we should be taking these individual functional

elements and placing them in virtual containers,

rather than deploying monolithic middle box functions.

Now the concept of NFV is simple enough, but

one of the main challenges that operators face is a problem called orchestration,

whereby operators implement modular network functions, and

a controller figures out how to place these functions throughout the network.

Another challenge is customizability, whereby a network operator might

want some very specific middlebox-like functions for specific traffic flows.

Slick's approach is to allow a programmer to define functional units called

elements that can be reused and composed to create more complex functions.

It provides a programming abstraction in a runtime system that

supports that extraction.

I'll now talk briefly about both the abstraction and the runtime.

The Slick programming abstraction

allows an operator to define applications and elements.

Network operator writes the application using an existing repository of elements,

and defines how different flows should be forwarded through chains of these

elements.

The runtime then handles when and where to install the elements,

as well as how to send the traffic through specific instances of these elements.

For example, ordinary network traffic might be forwarded along one path,

but an operator might specify that each flow to port 80 should be

sent through some logger element.

The controller is then responsible for

both placing that element on a particular node in the network, and

installing forwarding entries in the switches, so that traffic destined for

port 80 is forwarded through the appropriate elements.

Here's some example code for corresponding Slick application.

The code defines an element that logs HTTP traffic.

A network operator defines this function and

which flows the function should be applied on, and

the runtime then subsequently determines where to place the element in the network.

Slick elements are the basic functional unit in the Slick environment and

are inspired by the Click programming model.

They expose a uniform interface for writing functions.

A specification file allows an element to describe its

properties to the Slick controller.

The Slick runtime determines how to place these functional elements in a network,

given a specified mapping between flow space and sequences of elements.

The goal of this placement is to do so in a way that satisfies specifications

about the sequences of elements and functions, and yet achieves the desired

operational objectives, such as minimizing network congestion.

One way to perform this placement is to place elements that increase traffic

volume, such as decompression, closer to the traffic destination, and

place those that decrease traffic volume, such as firewalling, closer to the source.

The other aspect of the runtime for

orchestrating network functions virtualization is steering.

This is the process of routing traffic flows that belong to certain

portions of flow space through sequences of functional elements that have been

placed in the network.

One way to do this is to represent each element instance as a note

in an overlay graph.

Elements in each tier of the graph represent a particular functional element,

and multiple nodes in the same tier represent instances of the same element.

The steering problem considers this overlay graph for

each source destination pair, and computes a path for each flow that must

traverse this sequence of elements, that achieves the desired network objective.

Significant future work remains in NFV, including better algorithms for

placement and steering, faster data plane forwarding for

elements, better ways to resolve policy conflicts, and

ways to verify network policies that a network operator might specify.

In conclusion, NFV is an approach for

deploying middlebox-like functions on virtual appliances in the network,

often on a finer granularity that monolithic middleboxes.

Two important aspects of orchestrating these network functions

involve developing a high level programming abstraction for

defining these functions, and how they should be applied to network flows, and

developing a runtime that adequately implements the specified abstractions.

Slick is one way of addressing these challenges, but

significant work still remains.