Active Networks (English)

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

We're continuing our study of the history of software defined networks. In this lesson we'll talk about the history of active networks. We will talk about what active networks are, the motivation for active networks, and the technology that supports active networks. We'll also talk about how active networks relate to software defined networks. As well as the legacy of active networks for SDN.

Welcome back.

We're continuing our study of the history of software defined networks.

In this lesson we'll talk about the history of active networks.

We will talk about what active networks are, the motivation

for active networks, and the technology that supports active networks.

We'll also talk about how active networks relate to software defined networks.

As well as the legacy of active networks for SDN.

To remind you where we are in this module, we just completed a lesson on the history

of central network control, which dates back at

least to the 1980s, in AT&Ts network control point.

We're now going to study the origins of network program ability.

In particular, its roots in the active networks projects of the 1990s.

So first of all, what are active networks?

Simply put, active networks are networks where the switches perform

custom computations on packets, as the packets travel through those switches.

Some examples, you might imagine a router

or every router in the network performing some

kind of tracing, or a program, on

the packets as they travel through the routers.

Middleboxes are also an example of active networks.

Boxes in the network that perform firewalling

function, proxying, application services and so forth.

Are all custom computations on traffic, that are performed in the network.

And we can think of middleboxes as a modern day form of active networks.

Where did active networks come from?

Well, in the mid 1990s, the DARPA research community

was discussing, various problems that existed in today's networks.

In particular they identified, that it was difficult

lt to integrate new technology into the network.

At that, sometimes the network would exhibit poor performance.

Because, the same operations were being reimplemented,

at multiple layers of the protocol stack.

Finally it was noted that it was difficult to

accommodate new services as they were introduced into the network.

So in a nutshell the motivation for active networks, was to accelerate innovation.

It was observed innovation relies on consensus, and that from the time

at which a working prototype was demonstrated, to the time, at, at which

that technology would ultimate de, be

deployed in operational network, could take as

long as ten years, because of

standardization, the process of procuring new hardware.

And ultimately testing and deploying it in

a production network, could just take forever.

If that motivation sounds familiar, it's

because SDN actually has the same motivation.

That is accelerating innovation in existing networks, so that technology

could be introduced a lot more rapidly, without consensusm, standardization, etc.

Well, active networks had the same motivation and observed

that if you could put active nodes in the network,

where routers could download new services, in, in the int,

into the infrastructure, that could allow for some user-driven innovation.

So, the main idea here, is that messages or packets would carry

both the data and procedures that, that might operate on that data, so.

These active routers, that perform these custom operations, might coexist

with legacy routers that do nothing more than forward the traffic.

Each of these programmable switches, might then perform

additional processing, in addition, to forwarding the traffic.

So, there are both de, user demands, and technology

enablers, that made active networks compelling at the time.

On one side of the coin, the

demand side, the proliferation of firewalls, proxies, transcoders,

etc, resulted in a lot of ad hoc

point solutions to solving various custom packet processing.

problems, and the goal or the vision on active networks, was to

replace a lot of these ad hoc approaches, with a more unified approach.

On the flip side we had technology push or enablers.

There was a lot of research and technology being developed

at the time, in support of safe execution of mobile code.

In particular, Java applets were emerging, and, and those provide the ability to.

Develop portable code that could run, in one place or another.

And, and it allowed shipping code around, which was a

very natural supporting technology, for certain types of active networks.

Also, various operating systems support was being developed.

The Scout Operating System focused on support for real time communications.

The Exokernel developed new technologies to allow

safe access to low-level resources, and SPIN, focused

on providing trustworthy code or, or providing

technologies that could enable generation of trustworthy code.

So, there are two different approaches to active networks.

The first was a rather extreme approach, and that was

essentially that every message, or every packet actually carried a program.

And active nodes, along the network path, would evaluate,

that code that was being carried in the packet.

So the code, as it was carried in the packet.

Would be dispatched into an execution en, environment

that was running on a programmable switch or router.

We'll take a look at capsules a little, in

a little bit more detail on the next slide.

But, the other approach, was something that looks a lot more familiar to us now.

And almost looks like SDN, and the idea here is that.

You can have programmable switches, that would, where code would be installed.

These programmable switches then, would perform custom operations of processing

functions, on packets, depending on values in the packet header field.

So, essentially, packets would be dispatched to the appropriate

code block, depending on the values of packet headers.

So, that sounds a lot like SDN, you wouldn't be mistaken.

Let's just take a quick look at capsules.

So, capsules essentially expand the existing packet header.

So, in addition to having the regular IP header with your payload, you have.

An active networking header, and this particular one was the ANTS header.

This was developed at MIT, and, this

header actually, had a few additional fields.

One was the type, which specified the forwarding routine

to be executed in a particular code by reference.

The previous address, basically told the node where to obtain

the forwarding routine if it wasn't available on the present node.

The dependent fields allow the packet pass parameters into this

code, and then of course, there was the payload itself.

So, some previous notable projects in active networks.

So, one was the ANTS project, which we just refered to.

And that actually took the packet capsule

approach, where, Java programs would actually be carried.

With these packets.

Naturally this introduced some limitations for guaranteeing quality

of service, and, in response to that, the university

of Arizona had implemented something called the Joust JVM,

which provided better real-time performance for active network scenarios.

There was also the SwitchWare program

at Penn, which developed a programmable switch

and a, and a scripting language that could support the invocation of switchlets.

The smart packets project at BBN, focused

on applying active networks to network management problems.

Open Signaling at Columbia developed a language called NetScript, which allowed a

programmer to specify custom packet processing

routines, and pipelines on streams of packets.

We will look at some more modern programmable data plans

later on this course, that look a lot like Open Signaling.

Finally there was the Tempest project at Cambridge, which

invented something called Switchlets which was a programmable, virtualizable switch.

And we'll look a little bit more about at that in the next lesson.

So what happened to active networks?

This was, this technology was introduced almost 20 years ago, why are we.

Why didn't we see some of these ideas come to fruition sooner?

Well, for one, the timing was off.

At the time, there was no

clear application for this type of programmability.

As we've seen now, and as we'll see throughout this course one of the

killer apps, or killer environments for SDN, was the data center and the cloud.

And at the time.

The data center and cloud just didn't exist.

So there was no, particularly clear application for for active networks.

At least no immediate application.

Additionally hardware support wasn't cheap, everyone was

using ASICs to support this type of technology.

Now we have a lot more options to support programmable data plans, such as, TCAMs.

FPGAs and network processors, there were also some missteps.

In particular, there was a lot of focus on security providing

special languages for safe code talking about packets that carry code, etc.

And may be too much focus on this, as opposed to the general

concept, or the overall goal of, how do we provide programmability in the network?

So, whether or not its done by a capsule, or whether or not its done by

a programmable switch, was less important, than, than

simply providing that programmability or flexibility in the infrastructure.

There was also potentially too much focus on.

The end user people like you and me sitting on our laptops

or end, end user devices in our, in our homes, as the programmer.

In contrast SDN has now focused on the network

operator, as the programmer, and the application service operator.

People who actually want to introduce, new technology, into the network.

Finally, there was a lot of focus on

interoperability between existing active network implementations and deployments.

And in contrast to that, OpenFlow essentially punted that.

They, they did a very good job with

grappling with backwards compatibility in existing switch hardware.

It was a a, it's a, it's a, it's effectively

a simple firmware upgrade, to provide OpenFlow support, into existing switches.

And many switch hardware platforms, already

support these basic operations that OpenFlow specifies.

So, let's just think about the legacy of

active networks for SDN, for just a minute.

What lessons can we take away from active networks?

Well the first, was the idea of providing

programmable functions, in a network, to enable innovation.

That problem statement, or that motivation.

Is almost identical to the SDN motivation in

it and it, it has roots in active networks.

The second was that idea, the, the the programmable switch approach, where

switches would actually carry code, or, code could be installed on switches.

And then the packets or values in the packet headers, would

determine how those packets would be demultiplexed into the correct code block.

That idea actually came from active networks, and we've seen it

over and over and over again, in projects like Planetlab, Flowvisor, GENI.

Even now all the work talking about how to integrate SDN, with middleboxes.

It all has roots back into this idea that came from active networks.

Finally just one more point on middleboxes.

It's worth noting active networks paid a lot, of attention to middle boxes.

One of the motivations for active networks, was the proliferation

of different kinds of middleboxes, and the vision for unifying architecture.

So, we're now seeing the same type

of vision, being espoused in various SDN projects.

And it's probably worth going back to, going back to look

at some of the work on active networks, to see whether

or not that some of the same lessons that we learned

there, could be applied to to integration of middleboxes with SDN.