of the texts and illustrations are taken from the talks/lectures given by the referenced networking professors/gurus/ninjas (Credits at the end of the Slide).
Why Is Layering So Important? • Built an Artifact, Not a Discipline • Why Does Networking Lag Behind? • Infrastructure Still Works! • What Is the Problem? • The Need for (Essential) Network Abstractions • Abstractions for Network Control
To accomplish its task, the control plane must: • Figure-out what network looks like (topology) • Figure out how to accomplish goal on given topology • Tell the switches what to do (configure forwarding state) We view this as a natural set of requirements.... And we require each new protocol to solve all three
information about current network • Implementation: “Network Operating System” • Runs on servers in network (replicated for reliability) Abstraction: forwarding model • Provides standard way of defining forwarding state • OpenFlow is an example • Specification of <match,action> flow entries
Whether it be: isolation, access control, or QoS • CP should not be responsible for implementing that behavior on physical network infrastructure • CP should not be responsible for configuring the forwarding tables in each switch Proposed abstraction: Virtual Topology of network • Virtual Topology models only enough detail to specify goals • Will depend on task semantics
for general forwarding model • #2 – Need an abstraction for distributed state • #3 – Need an abstraction that simplifies configuration Once these abstractions are in place, control mechanism (CP) has a much easier job!
(smart but slow) – Forwarding ASIC (fast but dumb) • Need a forwarding abstraction for both – CPU abstraction can be almost anything • ASIC abstraction is much more subtle: OpenFlow • OpenFlow: – Control switch by inserting <header;action> entries – Essentially gives NOS remote access to forwarding table – Instantiated in OpenvSwitch
specified by control plane – Built from basic set of forwarding primitives Minimal – Streamlined for speed and low-power – Control program not vendor-specific OpenFlow is an example of such an abstraction
– While allowing access to this state • Natural abstraction: global network view – Annotated network graph provided through an API • Implemented with “Network Operating System” • Control mechanism is now program using API – No longer a distributed protocol, now just a graph algorithm – E.g. Use Dijkstra rather than Bellman-Ford
protocols – Design one distributed system (NOS) – Use for all control functions • Now just defining a centralized control function • configuration = Function(view)
up-to-date network view – Runs on servers (controllers) in the network – NOX, ONIX, Trema, Beacon, Maestro, … + more Uses forwarding abstraction to: – Get state information from forwarding elements – Give control directives to forwarding elements
Input: global network view (graph/database) – Output: configuration of each network device Control program is not a distributed system – Abstraction hides details of distributed state
It should not be responsible for implementing that behavior on physical network infrastructure • Natural abstraction: simplified model of network – Simple model with only enough detail to specify goals • Requires a new shared control layer: – Map abstract configuration to physical configuration • This is “network virtualization”
from reaching B • Control program does so with access control entries: – Control program must respond to topology/routing changes – It makes hard to write correct control program A B AB drop AB drop
• Abstraction: Virtual Topology – Allows operator to express requirements and policies – Via a set of logical switches and their configurations • Layer: Network Hypervisor – Translates those requirements into switch configurations – “Compiler” for virtual topologies
a simple model – Configuration merely a way to specify what you want • Virtualization layer “compiles” these requirements – Produces suitable configuration of actual network devices • NOS then transmits these settings to physical boxes • Examples – ACLs: who can talk to who – Isolation: who can hear my broadcasts – Routing: only specify routing to the degree you care • Some flows over satellite, others over landline – TE: specify in terms of quality of service, not routes
router – Physical network is collection of interconnected switches – Allows routers to “scale out, not up” – Use standard routing protocols on top • Multi-tenant networks: – Each tenant has control over their “private” network – Network virtualization layer compiles all of these individual control requests into a single physical configuration • Hard to do without SDN, easy (in principle) with SDN
tractable – NOS, Virtualization are still complicated pieces of code • SDN main achievements: – Simplifies interface for control program (user- specific) – Pushes complexity into reusable code (SDN platform) Just like compilers…. SDN: Layers for the Control Plane
Virtual Topology – Operator Requirements – Configuration = Function(view) – Not a distributed protocol, now just a graph algorithm • Network Hypervisor: Virtual Topology Global Network View • Network OS: Global Network View physical switches – Gathers information for global network view – Conveys configurations from control program to switches • Router/switches: merely follow orders from NOS
planes: • Not packaged together in proprietary boxes • Enables use of commodity hardware, 3rd party software • Easier to write, maintain, verify, reason about, …
Getting systems to work vs. making systems easy to use and understand • Extracting Simplicity builds intellectual foundations necessary for creating a discipline • Abstractions key to extracting simplicity
events DP cfg/cmd global view cfg/cmd NV a.k.a NH abstract view cfg/cmd Specification Abstraction State Dist. A. Forwarding A. Control Program: specify behavior on abstract model (driven by Operator Requirements)
events DP cfg/cmd global view cfg/cmd NV a.k.a NH abstract view cfg/cmd Specification Abstraction State Dist. A. Forwarding A. NV: map abstract model to global view (driven by Specification Abstraction)
events DP cfg/cmd global view cfg/cmd NV a.k.a NH abstract view cfg/cmd Specification Abstraction State Dist. A. Forwarding A. NOS: map global view to physical switches API: driven by Distributed State Abstraction Switch/fabric interface: driven by Forwarding Abstraction
Gives rise to a thriving ecosystem • Innovation is the true value proposition of SDN – SDN doesn’t allow you to do the impossible – It just allows you to do the possible much more easily • This is why SDN is the future of networking…
Small industry Specialized Operating System Specialized Hardware Ap p Ap p Ap p Ap p Ap p Ap p Ap p Ap p Ap p Ap p App Specialized Applications Horizontal Open interfaces Rapid innovation Huge industry Microprocessor Open Interface Linux Mac OS Windows (OS) or or Open Interface
Ap p Ap p Ap p Ap p Ap p Ap p Ap p Ap p Ap p Ap p App Horizontal Open interfaces Rapid innovation Control Plane Control Plane Control Plane or or Open Interface Specialized Control Plane Specialized Hardware Specialized Features Merchant Switching Chips Open Interface
and operators, not vendors • Faster changing, to meet operator needs • Lower opex, capex and power Abstractions • Will shield programmers from complexity • Make behavior more provable • Will take us places we can’t yet imagine
Past of Protocols • Nick McKeown, Stanford University, Many Talks/Articles • Jennifer Rexford, COS 597E, Princeton University • Mike Freedman, COS 461, Princeton University • Nick Feamster, https://www.coursera.org/course/sdn • Li Erran Li, COMS 6998-10, Univ. of Columbia • Marco Cello, SDN Talk @ CNR, Univ. Genova • Guido Appenzeller, Network Virtualization in Multi- tenant Datacenters, VMware
eueung
sat
champ
hakubishin3
.jpg){kind=avatar}
oshanqq
chanyou0311
mochizuki875
knih
kkamegawa
lycorptech_jp
kongmingstrap
spatial_ai_network
shimacos
eileencodes
caitiem20
cromwellryan
erikaheidi
keavy
mza
aleyda
samlambert
bkeepers
pedronauck
sstephenson
smashingmag
