Control/Data Separation (English text)
by
Sasha Shkrebets
—
last modified
Feb 21, 2023 12:53 PM
We're now starting the second module where we
will talk about the control and data plane separation.
By the end of the module you should be able
to explain the difference between the control and data planes as
well as the functions of each of them including the infrastructure
that's required to support each of the control and data plane.
Welcome back.
We're now starting the second module where we
will talk about the control and data plane separation.
By the end of the module you should be able
to explain the difference between the control and data planes as
well as the functions of each of them including the infrastructure
that's required to support each of the control and data plane.
We'll also talk about the challenges of separating the control and data
plane and various approaches that have been taken to tackling these challenges.
The module comprises three lessons.
The first lesson is the Overview, where we will
discuss what control data plane separation is, why it's a
good idea, and will provide a brief overview of the
opportunities and challenges of separating the control and data plane.
The second lesson we'll discuss opportunities in more detail, and the
third we'll talk about challenges and approaches to tackling those challenges.
So first, what are the control and data plans?
The control plan is logic that controls the forwarding behavior in the network.
Examples of the control plane are routing protocols, network box configuration
such as firewall configuration or load balancer configuration, and so forth.
One can think of it in some ways as the brain of the network.
The Data Plane on the other hand
forwards traffic according to the control plane logic.
Examples of data planes are IP forwarding layered to switching and so forth.
Data plane is sometimes implemented in hardware, but
also is increasingly implemented in things like software routers.
So why separate the data plane and the control plane?
One reason is that by separating the data plane and the control plane.
Each can evolve, and be developed independently.
In particular the software control of the
network can evolve independently of the hardware.
That means one can buy a router, switches,
middle boxes, and so forth deploy them in the
network and not be bound by capabilities of software
that ship with the hardware at that particular time.
Second reason to separate the control and data planes is that it
allows the network to be controlled from a single high level software program.
So higher order programs could control the behavior of
the entire network and in doing so not only is
it easier to reason about the behavior of the network
but it's also easier to debug and check this behavior.
So there's various opportunities that we look at where separation actually helps.
In this particular lecture I will provide a brief overview of where separating
the data and control plane can help in data centers and in routing.
And in a subsequent lecture we will talk about also where this control and
data plane separation can help make certain
applications in enterprise networks easier to manage.
We'll also talk about how the separation of control and data plane can help in
research networks by allowing research networks to coexist
with production networks on the same physical infrastructure.
One particular domain where operating the control and data
planes has proved particularly useful is the data center.
Where it's relatively common place to move a virtual machine from one
physical location in the data center to another as traffic demands shift.
As one example, Yahoo sites says it has about 20,000 servers.
In a cluster in a data center resulting in about 400,000 virtual
machines each of which might need
to communicate with any other virtual machine.
Thus resulting in about 1,024 distinct inter
host links between any pair of virtual machines.
For the topology that they've deployed.
Now if on top of that, you
want to guarantee sub-second virtual machine migration,
and guaranteed consistency in the network as
that migration occurs, this problem becomes particularly hairy.
The solution to this problem.
That Yahoo has taken is to program each
of the network switches from a central database.
So as virtual machines migrate, that central
controller knows about the migration and can update
the switch state accordingly so that network paths
update in accordance with the virtual machine migration.
As another example, suppose that an attacker is
sending denial of service attack traffic to a victim.
In this case it can sometimes be difficult to squelch that traffic near the source.
One approach that AT&T has taken is to separate
the data plane to the routers that forward that traffic.
From the control plane that makes decisions
about what to do with particular traffic flows.
In particular they deployed something called a IRSCP.
Which is a commercial version of the RCP, which we've talked about.
Which will insert a null route into a router
for particular flows or destinations that are receiving attack traffic.
So those are just two examples of how the
control and data plane separation have helped in specific cases.
But there are also challenges to making
the control and data plane separation a reality.
The first is scalability, once you separate
the control elements from the forwarding elements.
Its likely that a control element maybe responsible for
many many forwarding elements and
sometimes thousands of forwarding elements.
The other challenge is reliability or security what
happens if a controller fails or is compromised?
Well we should hope that the forwarding
elements continue forwarding traffic, business as usual.
But once we've separated the brains of the network
from the devices that are actually forwarding the traffic.
Correct behavior is no longer guaranteed if
a controller should be failed or compromised.
So in the coming two lessons, we'll talk about both the
opportunities and challenges associated with
separating the data and control planes.