3.1.2 Software-Defined Networking Architecture - Part 2 - Week 3

[MUSIC]

So what we just saw are some of the key ideas of SDN.

A programmatic low level interface with the data plane,

centralized control, and higher level abstractions that make that control easy.

Now all of these ideas have long roots if we go back into the history of networking.

No one of these ideas in isolation is something that's new.

So we're not going to be able to cover all of that history but

I want to talk about a few of the threads of evolution of SDN.

So one of the important needs that SDN is driving towards is making

the network flexible.

And there are a few important ideas that I'd like to mention in past systems that

allowed us to make the network more flexible in somewhat related ways.

One of those is label switching or MPLS.

Okay.

Now, in terms of, the mechanism what MPLS does is actually

simpler than IP Longest Prefix Match Forwarding,

it does matching labels and executing actions based on those labels.

The effect that we get from that is that we can essentially

lay down any path that we want in the network for certain classes of traffic.

That allows us to go beyond simple shortest path forwarding, and

do more interesting and complicated things.

Like good optimization of traffic flow to get high throughput for

traffic engineering, or

setting up private connections between enterprises and distributed sites.

Okay, and that flexibility of programming a network and, in particular,

oriented towards traffic engineering is something that made MPLS very successful,

and as we'll see is also an important application for SDN.

Now active networks made networks more flexible in a very explicitly

programmatic way, by embedding a program within a packet header or a pointer

to the program in the packet header, that the router switch should execute.

Okay, now this is a somewhat radical idea of packets carrying code with them.

But it illustrates that even at that time there was a recognition

that we could do a lot more with networks if we could make them more programmable.

Another important thread of ideas is around logically centralized control of

networks, and this is something that goes back decades.

But I'm going to mention a few projects that are more recent in

the sphere of Internet working.

One of these that was influential is the Routing Control Platform.

So if you look at how routing is done with BGP routing,

this is the Global Internet Routing Protocol.

Even within an enterprise it's still a distributed system.

You still have many exit and entry points where you connect to the outside world,

and your global routing flow, even within your enterprise,

is controlled in a distributed system.

The idea of RCP was to centralize the decisions about routing flow, and

then push out those decisions to the border routers within the network.

The 4D architecture introduced an idea of a logically

centralized decision plane that, like SDN,

separates those decisions from the data plane actions.

And that's very closely related, of course,

to the idea of having that explicit API where you're programming the hardware.

Now an immediate predecessor to SDN was a project called Ethane which

allowed us to program policy for an enterprise.

For example, access control in a centralized way and

have it then pushed out to the entire network.

Okay, so you would write a policy such as the one illustrated

here about how certain groups of users and

types of devices can access the network and then have that single centralized

expression of the policy be implemented automatically in a distributed way.

Now the OpenFlow protocol was introduced in 2008.

And this is one possibility for

how we have that interface to the data plane.

So it introduced that explicit idea of the standardized interface to the data plane

and with general purpose programmability at the controller.

NOX was the first controller for

OpenFlow that provided a centralized view of the network

and exposed that to multiple applications with database style access.

So the important idea here is that NOX can provide this

service of the appearance of centralized control to the applications,

where behind the scenes it's doing that work of state collection and

state distribution in the distributive system.

Sine then there's been an explosion of interest both in academia and

in industry in Software Define Networking with

essentially every major networking company having some sort of an SDN product.

But if we go beyond the marketing,

what is it that is the real fundamental, technical, opportunity here?

Well there are, in fact, real opportunities that are pretty exciting.

If we look at having an open interface to the data plane.

From the hardware perspective, if we have a standardized API,

it can be easier for operators to change hardware in their networks,

to use different vendors, and for new vendors to enter the market.

From the software perspective,

we can finally directly access the device behavior,

which exposes a lot more capabilities then we would have in traditional networks.

The centralized controller gives us that direct programmatic control.

So we can make architecting and network more like good software design.

Okay, and then building abstractions in the controller allows

up to solve these distributed system problems only once.

And then, it's just a matter of writing algorithms.

So, whereas, in a traditional network,

if we want to devise a new way of controlling traffic flow in the network,

that involves writing distributed protocols and standardizing.

Now we can just write an algorithm like Dijkstra's algorithm.

The kind of thing you learn in freshman or sophomore level computer science and

plug it directly into your STN controller.

So we can control networks in a way that's much more like traditional

software engineering with libraries, with languages to help write programs.

And if you don't want to write programs,

perhaps we can build systems that allow you to express higher level goals.

Like I want my network to have optimal traffic flow or

this certain kind of access control.

So those are real exciting opportunities.

But at the same time, there are certainly challenges.

So one, of course, is performance and scalability.

Where we're controlling the network through devices that are going to have

to respond quickly with latency concerns, for example, and capacity concerns.

And although I've talked about a logically centralized controller,

I'm careful to use when I am careful I use the word logically centralized,

because, in fact, we can't have a single centralized controller.

All of those distributed system challenges

are still precedent that are present in a traditional network.

The network is still fundamentally a distributed system.

Which means there are hard problems surrounding resilience,

the lack of perfect knowledge of everything that's going on.

We never know exactly when an event happens.

And consistency issues between the multiple controllers that we will need.

Moving beyond purely technical challenges, there are architectural

questions that academia and industry are exploring.

One is what should be the protocol to program the data plane?

Should it be OpenFlow which itself is a standard that's evolving.

Something that allows more network function virtualization.

That is, there's more general purpose compute embedded in the network devices.

Whitebox switching or programmable data planes.

We're not going to talk about all of these and certainly it's likely that there will

be multiple solutions for different use cases.

But this is a space that is actively evolving.

As is the space of what are the right higher level control

abstractions that run at the centralized controller?

Looking at the OpenFlow protocol, or even the early NOX example that we saw,

that's far too low level for most of what we want.

We generally have a goal, something you're trying to get done in the network.

I want this part of my network to be properly segmented or

I want traffic to flow through load balancers properly.

I want to express that high level goal without worrying about

the low level details of matching certain fields and packets, right?

But what are the right abstractions

that can cover a good set of use cases and

whether we need special controllers for special uses?

These are questions that are, again, evolving.

In the context of those significant challenges we have, however,

seen deployment of software defined networking.

And with those challenges it really takes a killer app.

So what were the early killer apps for SDN?

That's an interesting question.

And another interesting question is, I haven't said anything

about cloud computing so far in this lecture, where does the cloud come in?

Well, it turns out that a couple of the early killer apps for

SDN were very relevant to the cloud.

One of them is virtualization of multi tenant data centers.

Where we have tens of thousands of tenants for which we're spinning up

VM's and virtual networks in real time, very well suited to a programmatic model.

And second inter-datacenter traffic engineering; where we're

trying to drive our expensive network that connects our cloud sites

to the maximum utilization possible.

All right, because in the wide area

we want to get every bit of bandwidth that we can in that expansive network.

And again this is something that if we want to get

the best possible utilization we actually need more interesting algorithms that is,

again, very well suited to an SDN programmable model of the network.

So, something that both of these use cases have in common is that they

were special purpose deployments, targeted towards a specific use case with less

diverse hardware and controlled by one entity, which made the deployment easier.

And second, they were applications, where the existing solutions weren't just

a little bit inconvenient, they wouldn't work.

They wouldn't have achieved the goal.

So, what we're going to see in the upcoming lectures is focusing

on these particular use cases, in the context of cloud computing, and

looking at case studies for systems that were built to address them.

[MUSIC]

3.1.2 Software-Defined Networking Architecture - Part 2

Cloud Networking

Conoce a los instructores

Explora nuestro catálogo

Inscríbete de manera gratuita y obtén recomendaciones personalizadas, actualizaciones y ofertas.