In the cloud networking course, we will see what the network needs to do to enable cloud computing. We will explore current practice by talking to leading industry experts, as well as looking into interesting new research that might shape the cloud network’s future. This course will allow us to explore in-depth the challenges for cloud networking—how do we build a network infrastructure that provides the agility to deploy virtual networks on a shared infrastructure, that enables both efficient transfer of big data and low latency communication, and that enables applications to be federated across countries and continents? Examining how these objectives are met will set the stage for the rest of the course. This course places an emphasis on both operations and design rationale—i.e., how things work and why they were designed this way. We're excited to start the course with you and take a look inside what has become the critical communications infrastructure for many applications today.
3.1.2 Software-Defined Networking Architecture - Part 2
Loading...
Del curso dictado por University of Illinois at Urbana-Champaign
Cloud Networking
143 calificaciones
University of Illinois at Urbana-Champaign
143 calificaciones
Curso 5 de 6 en SpecializationCloud Computing
De la lección
Week 3
This week focuses on management and sharing of network infrastructure in cloud data centers. Traditional networking technologies require complex, error-prone network configuration, and make sharing of the network across multiple tenants in a secure manner difficult. We’ll learn how software-defined networking and network virtualization are addressing these problems.
Conoce a los instructores
P. Brighten GodfreyAssociate Professor
Department of Computer Science
Ankit SinglaAssistant Professor
Department of Computer Science, ETH Zürich
[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]
Explora nuestro catálogo
Inscríbete de manera gratuita y obtén recomendaciones personalizadas, actualizaciones y ofertas.
Coursera brinda acceso universal a la mejor educación del mundo, al asociarse con las mejores universidades y organizaciones, para ofrecer cursos en línea.
© 2018 Coursera Inc. Todos los derechos reservados.
