Opportunities in Various Domains (English text)

by Sasha Shkrebets — last modified Feb 21, 2023 12:53 PM

We're continuing our discussion of the benefits of control and data plane separation. And in this lesson we'll talk of the opportunities for control and data plain separation in terms of two examples. One is new routing services in the wide area. In terms of maintenance, egress selection, and security.

We're continuing our discussion of the

benefits of control and data plane separation.

And in this lesson we'll talk of the opportunities for

control and data plain separation in terms of two examples.

One is new routing services in the wide area.

In terms of maintenance, egress selection, and security.

And the second is benefits in data center networks in terms of cost and management.

So to remind you this module has three lessons.

We covered the overview last time and in this lesson we will talk about

opportunities in various domains that exist as

a result of controlling data plane separation.

We'll then talk about some of the challenges and approaches

to addressing those challenges for the control and data plane separation.

So lets jump into the first example, which is benefits

of control and data point separation in the wide area.

So if you know anything about interdomain routing,

perhaps you remember it from your undergraduate network

course, you may remember that policies, ways to

set policies, in interdomain routing protocols are very constrained.

Today's interdomain routing protocol, the Border Gateway Protocol, or BGP.

Artificially constrains routes that any particular

router in the network could select.

That's because route selection is based on a fixed set of steps.

And there are a limited number of knobs

to control in the inbound and outbound traffic.

It's also very difficult to incorporate

other information, such as auxiliary information

about the reputation of a route, time of day and so forth.

The separation of the control and data plane makes it a lot

easier to select routes based on a much richer set of policies.

Because the route controller can directly update the

state in the forwarding plane independently of whatever

software or other technology may be running on

the forwarding elements, the routers and switches themselves.

So let's look at a few examples.

One example is called maintenance dry out, the idea here is that

a network operator may want to do planned maintenance on an edge router.

So in this example, let's suppose that the operator wants

to do maintenance on egress, the router sitting at egress 1.

In this particular example, the operator could use

something like the RCP, routing control platform,

to directly tell a, router at egress to send its

traffic for a particular destination to egress 2.

This will be much more difficult in today's networks because the

network operator will have to use existing routing protocols to

adjust the configuration of individual routers in the network.

To effectively tell all of them to switch

their route from one egress point to another.

This could be done in a lot of ways.

Mostly likely in tuning the intra-domain route weights.

For example, the OSPF weights on each individual router.

But, that's a very indirect way of doing, doing this.

It's much more direct to have a controller

directly tell the router which egress point to use.

A second example would be to let

customers themselves control the selection of egress routers.

So, for example, if a particular customer wanted to use one

data center or another to reach its particular services.

Again the network could use the RCP to send traffic for one

customer to one data center, and another customer to a different data center.

This should, by contrast, this will be very difficult in today's networks

because PGP is routing traffic based on destination prefix.

So if a particular service was served from a particular destination prefix, all

of the traffic, regardless of customer, would go to the same data center.

In this particular case, the RCP could route

traffic to different data centers depending on the source.

In particular, in this case, depending on

which customer the traffic was originating from.

As another example, we could imagine how separating the data and

control planes could result in better security for inter domain routing.

So while there are secure routing protocols that exist,

many of them are very difficult to, to deploy.

There are also auxiliary monitoring systems that can tell an autonomous system

about the reputation or potential security or insecurities of a route advertisement.

But there's no way to directly incorporate that

information into the EGP or inter domain route selection.

So, one idea might be, to use an existing

anomaly detection system to detect suspicious or bogus routes.

And to prefer, familiar routes, over unfamiliar routes.

So if a particular autonomous system learned two

routes, or rou, two routes to a destination D.

One of which looks suspicious, and the other which did not.

The control plane, or an RCP for example, could tell the routers in that autonomous

system, to all prefer routing to that

preferred to that destination via the preferred route.

By contrast this would be very difficult to do in today's networks because

there is no easy way to incorporate

reputation information into the route selection process.

Another area where the separation of the control and data

planes can significantly benefit network operators is in data centers.

And in particular, this separation can drastically

reduce the cost of running a data center.

Looking at a typical data center with about 20,000 servers

and a fan out of 20 in the data server topology, we see that the

requirements to support this topology is about 10,000 switches.

If we take a particular switch from a standard vendor that cost $5000 we are

now talking about the cost of about $50 million just to deploy the switches.

If on the other hand, we could

deploy commodity switches, based on merchant silicon that

costs only about a $1,000, now we're talking

about a switch deployment costing about $10 million.

So if we're talking about a large service

provider that has ten data centers, and you're

a Google or a Yahoo or a Facebook,

now we're talking about saving of $400 million.

Which presumably you can use then to hire engineers to

develop controls systems for controlling that, those commodity switches.

The benefits of, of that separate control result in more flexibility; the ability to

tailor the network for specific services and

the ability to quickly improve and innovate.

Because as we've noted, once the control plane is separate from the

data plane, it is a lot easier to control the behavior of

the network because those switches are doing nothing more than just forwarding

traffic, and all the smarts of the network are in the software control.

Let's take a look in particular at how

separation of data and control plane can make

it easier to manage a data center through

more flexible control in the context of addressing.

So, let's suppose that you have a data center with tens of thousands of servers.

And you want to figure out, how you should address those servers.

On one hand you could use Layer 2 addressing like ethernet.

This results, obviously, in less configuration or administration.

Because if you've got one large layer to ethernet you

can essentially just plug everything in and it's a flat topology.

On the other hand, a flat topology with tens of thousands of servers

clearly results in poor scaling because

these layers and networks are typically broadcast.

On the other hand, we could do a layer three network.

And the benefits here are that we could

use existing routing protocols and scaling properties are much

better, but the administration overhead is a lot

higher because we have to configure these routing protocols.

For example, if we're using an intradomain routing protocol like OSPF, then

the network operator needs to configure the link weights in the topology.

And adjust those link weights accordingly to load

balance traffic, account for failures, and so forth.

So, on the one hand, there are

some conveniences to using layer three addressing.

Or it's topology specifying addressing, addressing like IP, but

there are also some drawbacks like higher administration overhead.

So, how do we get the best of both worlds?

Well, one idea is basically to use Layer 2

address it, and construct a large layer two network.

But to make those addresses to topology specific rather than topology

independent and how I, how I we do that because mac addresses are typically flat.

Well the idea basically is we can use mac

addresses but we can renumber or readdress these hosts

so that the addresses of these hosts have mac

addresses that depend on where they are in this topology.

Now hosts can still send traffic to the

other hosts IP addresses in this data center topology

but the problem is that since we've reassigned the

MAC address in the topology to be topology dependent.

The hosts don't actually know that they've had their MAC addresses reassigned.

They still think that they have their old flat MAC addresses.

So as we know, if a particular host wants to send traffic to another host

IP address, it will use the address resolution protocol, or ARP, to

send out a broadcast query that asks, who has a particular IP address?

In other words, what is the MAC address for this

particular IP address, that I would like to send to?

And the trick here is that we don't

want the host, the destination host, to respond.

Because it still thinks it has its old MAC address.

What we can do in this case, because we have separate network control, is to use

something they call a fabric manager, or a

separate controller to basically intercept all of these r-queries.

Or all these queries that are wanting

to discover MAC addresses for particular IP addresses.

So in this particular switch, receives a query that says,

tell me the MAC address for a particular IP address.

That switch can kick that query to a central controller or a fabric manager

which can then reply with the topology dependent pseudo MAC, or P MAC.

And then all of the traffic can be rewritten

with the appropriate source and

destination topology dependent MAC addresses.

So that's just one example of how a separate controller and a data center

can allow a network administrator to get the best of both worlds.

In terms of both topology dependencies and the benefits of a Layer 2 topology.

We'll look at data centers a lot more, in a particular module

where we look at case studies of SDN later in the course.

But this hopefully gives you a flavor of the types of benefits that separating

control and data plane in a network

can offer to network operators and administrators.

There are a number of other opportunities that the separation

of the control and data plane can offer to network administratives.

For example, here at Georgia Tech, we're looking at how the separation of

control and data plane can enable, dynamic

access control, for campus and enterprise networks.

And there are another, number of other

opportunities that you can see here listed out.

Many of which we will explore throughout the rest of this course.

You can also check out the URL below here on the openflow site.

To look at various videos that explore different case studies of how the

separation of data and control plane

can make network management and operations easier.