Stanford Seminar - Software-Defined Networking at the Crossroads
Vložit
- čas přidán 8. 07. 2024
- "Software-Defined Networking at the Crossroads" -Scott Shenker, University of California, Berkeley
Colloquium on Computer Systems Seminar Series (EE380) presents the current research in design, implementation, analysis, and use of computer systems. Topics range from integrated circuits to operating systems and programming languages. It is free and open to the public, with new lectures each week.
Learn more: bit.ly/WinYX5
Explore all Stanford Online courses: online.stanford.edu/explore
0:00 Introduction
0:28 Co-Conspirators
2:32 Caveats and Clarifications
4:04 Architecture and Academia Don't Mix
4:33 Outline
7:49 What is the Root Cause?
8:48 The Two Networking "Planes"
9:54 Data Plane Abstractions: Layers
10:27 Layers Key to Internet's Success
11:26 Today's Control Plane: No Abstractions
12:39 Abstractions For Control Plane?
14:28 SDN: Two Control Plane Abstractions
15:05 SDN is "Layers" for Control Plane
15:52 Clean Separation of Concerns
17:05 Major Change in Paradigm
18:54 Looking Back After Five Years
20:44 The Role of Control Programs
22:06 Simple Example: Access Control
22:57 Network Virtualization
23:44 Virtualization Simplifies Control Program
24:27 Software Defined Network
24:58 Virtualization is Killer App for SDN
25:59 Long-Term Implications
27:52 Homogeneous Network
28:16 Three Important Logical Interfaces
29:48 How Are These Interfaces Implemented?
31:02 Incorporate MPLS Approach into SDN
32:00 Claim #1: Core Can Focus on Delivery
36:01 Software Switches Quite Common
37:04 Software Switches Getting Faster
38:09 Claim #2: Edge Can Use Software
38:26 Examples
39:15 Software vs Hardware
40:01 Long-Term Opportunity
42:53 The Myth of the Internet's Dataplane
43:03 The Reality of the Internet's Dataplane
43:35 Middleboxes As Common As Switches
44:02 Four Important Facts
45:25 One Inescapable Conclusion
48:58 How Did We Get Here?
50:25 Why Is Software Forwarding Better?
54:04 SDN and Networking at the Crossroads
I absolutely love this professor! Insightful and engaging talk even after 8 years! I am sure it would have been awesome to be in Scott Shenker's classes.
Great talk. It is nice to hear about SDN from a clean non-vendor-specific perspective.
Also, good job on clarifying and demystifying some of the more abstract concepts.
Thanks for sharing!
Very valuable pictures like this are allowing to make and create the knowledge more flexible
Amazing talk! In a first 15 min it explains what SND is all about. It's interesting to watch it even after learning SDN technology during several months.
Let's Stanford ... My appreciation ... I am at the very end of quite basic task of counting from B-address of broadcast and maximum of host of the address started 172.16 plus mask of 22 bits ... Both broadcast and multicast are one of the most crucial during passing every kind of the computer science studies even on the worse higher schools focused on computing, during my high school I had learnt crontab after exam and later I had no problems to pass exams of UNIX administration at all, one mistake can learn the rest of another experiences and can score as the very good goal to prompt into the level of Bachelor of Art within the topic, which is applied of ... Very valuable pictures like this are allowing to make and create the knowledge more flexible, sustainable, optimal and higher within the level of being advanced in case of computer science ...
The concept of SDN is very-very well explained, If you are the one who want to dive in SDN, then this video will add great value to your learning,concepts and provide you a clear thought process about SDN.
Very clear and simple explanation! good lecture
Very well explained and the best seminar on SDN :)
great explanation on edge networks!
Gr8 preso if u want to understand the history of sdn, the network problems that needed to be solved, how they are broken up and each piece solved separately.
I agree completely. Software should be used to the edge which should be the end host. Core routers are implemented using hardware ASICs. Simple and makes sense.
Great talk. However, the audio seems to be slightly distorted (feedback from the mic, perhaps?). If the audio could be smoothed out, it would make the video that much more pleasant to watch. :)
Anyone know a mailing list (or something similar) to exchange ideas about computer networks?
Hi Stanfordonline, where can I get the information about the SDN History? For example: Who created SDN? Where it created? When it created? The invention until 2016? I hope you can help me. Thank you.
www.cs.princeton.edu/courses/archive/fall13/cos597E/papers/sdnhistory.pdf
Very nice lecture. Little bit dated though. It would be nice to have another one
best on SDN..
Awesome lecture!! can i get the IEEE paper for this topic?
+shanthosh paramasivam arxiv.org/pdf/1406.0440.pdf
So how is the question posed with regards to middle-boxes and per packet processing really answered? I didn't quite get to hear a solid, definitive answer on that end with regards to how SDN would help solve the problem. The only thing mentioned was that better hardware implementation at the middle-boxes would help decrease the latency that the processing might cause. Can anyone please shed some light on this?
+Moeez R. I heard that we should split the MB processing in the edge.
+Moeez R. hi, i found a new paper of shenker, called Open Network Interfaces for Carrier Networks, hope it helps you
@35:03 "When a packet comes in wrong direction, I ll just remove a destination " What is that suppose to mean?
It will just drop the packets that goes from A to B.
He was talking about how a core router responds to link failure. So with SDN, and if the cord router senses a link failure and that core router is only forwarding packets, then to recover from that link failure the core router has only to remove the destination address at the end of that failed link from its forwarding table and that is all to it to recover from failure. So a packet coming in a wrong direction ( means going to a failed link) all that we need to do is to remove the wrong destination from the forwarding table. A task that could be done in nano seconds instead of hundreds of milliseconds.
Good info, thank you very much! I'm actually looking for an SDN architect to join our team in Omaha. We handled 58 BILLION minutes last year and want to deploy an SDN strategy in the very short term. Any questions? Please ask!
Not bad, but he should do one now 2 years later as an update for we are still in a crossroad.
well, we are still there
Martin cansado is not the inventor SDN absolutely wrong
Lets see, the ideal network has intelligence in the end nodes, and passes a simple label with the packets, and all the internal switches do is forward the packets without regard for what protocol is running, etc.
Yea, its called ATM (Asyncronous transfer mode) and its been around for decades. MPLS was ripped off from ATM.
+Scott Franco Truth be told, and even martin admits its SDN was coined by academia, he is not the inventor and given him to much credit is not acceptable. Also there is no way they invented SDN.... I knew about SDN since 2007 in college my self at devry university
P/161130/01/2024/041332