http://cleanslate.stanford.edu the stanford clean slate program nick mckeown professor of computer...

http://cleanslate.stanford.edu

The Stanford Clean Slate Program

Nick McKeownProfessor of Computer Science & Electrical Engineering

The Stanford Clean Slate Program http://cleanslate.stanford.edu

“It doesn't need fixing. It just needs a few upgrades. IPV6 would be a nice place to start”

“It doesn't need fixing. It just needs a few upgrades. IPV6 would be a nice place to start”

“These guys are completely on crack …You do not want to have

intelligence inside the network, ever… The [network] should be application-unaware, stupid, unreliable, and as

simple as possible. Which is the Internet we have today, and it works

great, thank you very much.”

“These guys are completely on crack …You do not want to have

intelligence inside the network, ever… The [network] should be application-unaware, stupid, unreliable, and as

simple as possible. Which is the Internet we have today, and it works

great, thank you very much.”It’s just a bunch of tubes, right? It’s just a bunch of tubes, right? 3

/11/2007

3/12/2007

3/13/2007

3/14/2007

3/15/2007

3/16/2007

3/17/2007

3/18/2007

Hits

193 159 99 655

46038

68616

33416 34433

0

10000

20000

30000

40000

50000

60000

70000H

its


Clean Slate Research is…

A way of thinking… that is common elsewhere

… but difficult when there is legacy


Car

Engine PolicyCar Body

MaterialsFuel

Control Safety Emissions FuelingStations

Manufacture

Rethinking the carInstalled base1900 8,0001968 170M2007 700M

1 gallon of gas 22lbs of CO2


Anything to rethink?

“How come it takes an hour to set up a session?”

“Why can I join someone else’s call?”

“Will the quality always be this poor?”

“Can I put a camera on my car and drive around?”


Economically sustainable

Trustworthy: Secure, robust, manageable

Mobility by default. Users and data

Unthought of links

Unthought of applications

Performance to blow our socks off


Early stakes in the ground

Organic growth lead to structure: Let’s exploit it

Optics is here to stay: Let’s exploit it too

Flows: They are our friends


In parallel2005: A sea-change in the networking research

community– Prompted by NSF– ITRs (including 100x100 Clean Slate Program)– NSF FIND: Funding for architectural ideas– NSF GENI: Creating a platform for experimenting with

new architectures, services and technologies

2006-2007: A large community-wide effort– GENI planning process– Programs starting in Europe and Asia

2007 - : GENI Project Office


ArchitecturalBlueprint?

Bottom-up first, Top-down later

Now…“Innovation in the small” Coverage of areas Four funded so far, adding more



Flagship projects

Larger collaborative projects Start to tie research together



ProgrammableNationwideBackbone

Backbone(Lightflow)

Local WirelessPlatform

FlowTheory

Security(Ethane)

Wireless(Spectrum)

Backbone(VLB)

CongestionControl(RCP)

Top-down blueprint?

Too early to decide


The Stanford Clean Slate Program

Create a breeding ground for new collaborative projects across boundaries

Projects that will have significant impact in 10-15 years

Exploit Stanford’s breadth and depth Work closely with a focused group of

committed industrial partners


Stanford Clean Slate Program

Faculty DirectorsNick McKeown

Bernd Girod

Executive DirectorGuru Parulkar

Affiliate MembersCisco Deutsche TelekomNEC NTT DoCoMoXilinx + 3 in the works


Stanford’s Breadth and Depth

World-class expertise in: Networking, optical communications, wireless,

access networks, theory, economics, security, applications, multimedia, operating systems, hardware and VLSI, system architecture, …

Participants from across EE, CS, MS&E, GSB Dan Boneh, David Cheriton, Bill Dally, Abbas El Gamal,

Bernd Girod, Ashish Goel, Andrea Goldsmith, Mark Horowitz, Ramesh Johari, Joseph Kahn, Sunil Kumar, David Mazières, Nick McKeown, David Miller, Phil Levis, Balaji Prabhakar, Mendel Rosenblum, Tim Roughgarden.



Backbone(Lightflow)


FlowTheory

Security(Ethane)

Wireless(Spectrum)

Backbone(VLB)


Projects

Optical technology promises enormous capacity & low-power

Professors Leonid Kazovsky & Nick McKeown

Goal is to propose new networks to exploit optical switching



Backbone(Lightflow)


FlowTheory

Security(Ethane)

Wireless(Spectrum)

Backbone(VLB)


Projects

Existing theory lacks details of flow-dynamics and end-to-end semantics

Professors Balaji Prabhakar & Amin Saberi

Goal is to develop flow-level theoretical models



Backbone(Lightflow)


FlowTheory

Security(Ethane)

Wireless(Spectrum)

Backbone(VLB)


Projects

Spectrum scarcity is a result of tight, inefficient government control

Professors Andrea Goldsmith & Ramesh Johari

Goal is to propose new approach to spectrum allocation & protocols



Backbone(Lightflow)


FlowTheory

Security(Ethane)

Wireless(Spectrum)

Backbone(VLB)


Projects

Professors Boneh, Mazieres, Rosenblum, McKeown

Goal is to propose clean slate architectures for secure networks


What we’d likePrinciple 1: Manage network using policy over real names

“Nancy can access Payroll”“Laptops can’t accept incoming connections”

“VoIP phones mustn’t move”

Principle 1: Manage network using policy over real names“Nancy can access Payroll”

“Laptops can’t accept incoming connections”“VoIP phones mustn’t move”

Nancy

PayrollPrinciple 2: Policy should dictate the path packets follow

“CEO traffic should not pass through engineering”“Guest flows must pass through http proxy”

“Laptop flows must pass through IDS”

Principle 2: Policy should dictate the path packets follow“CEO traffic should not pass through engineering”

“Guest flows must pass through http proxy”“Laptop flows must pass through IDS”

Principle 3: The origin of packets should be knownPrinciple 3: The origin of packets should be known

Principle 4: Network should log all connectivityFor diagnostics and auditing

Principle 4: Network should log all connectivityFor diagnostics and auditing


dhcp

TodayPrinciple 1: Manage network using policy over real names

“Nancy can access Payroll”“Laptops can’t accept incoming connections”

“VoIP phones mustn’t move”

Principle 1: Manage network using policy over real names“Nancy can access Payroll”

“Laptops can’t accept incoming connections”“VoIP phones mustn’t move”

Nancy

Payroll

Host: bIP: jMAC: n

Host: aIP: iMAC: m

dns

learningspanning tree

ospf

“Everyone who is not Nancy cannot access payroll”

Q: How to identify them?Q: Where do their packets flow?

Today

ACL: Jim’s IP, payroll

ACL: Jen’s IP, payroll

ACL: Jen’s IP, payroll

Jen


Problems

Bindings between users, hosts and addresses keep changing, are not authenticated and are chosen elsewhere.

Route is picked elsewhere and is unknown to the manager. And changes.

New entities require many more filters. Change of entity locations requires updating of filters.

Easy to circumvent, hard to diagnose.

NancyHost: b

IP: j

MAC: n

dns

dhcp

Dynamic bindings Allocated elsewhere Not authenticated Easily spoofed


Ethane: Design choices

Centralized management Policy language governs network All communication requires permission Secure and track all bindings


dhcp

Ethane: Taking Control

Nancy

Payroll

Host: bIP: jMAC: n

Host: aIP: iMAC: m

dns

“Nancy can access Payroll”“Laptops can’t accept

incoming connections”“VoIP phones mustn’t move”“CEO traffic should not pass

through engineering”“Guest flows must pass

through http proxy”“Laptop flows must pass

through IDS”




through http proxy”“Laptop flows must pass

through IDS”

learningspanning tree

ospf

controller


Waypoints

Payroll




through http proxy”“Flows to Payroll must pass

through IDS”




through http proxy”“Flows to Payroll must pass

through IDS”

controller

Nancy


Ethane: Manageability

Fine-grain control of each flow Can isolate users, groups, hosts Can specify waypoints Can require different forms of

authentication for different access points (e.g. stronger for wireless than wired)


Ethane: Many questions

Central controller– Performance & Scalability– Robustness

How to make it easy to use for manager… …and transparent to user.


Our deployment

300+ hosts at Stanford: Servers, laptops, desktops, phones.

19 switches– Hardware, software, wireless

Policy: 132 rules to replicate policy


Lessons so far…

Controller handles >10,000 flows/second Maybe enough for whole of campus Multiple ways to handle redundancy

– Cold-standby, hot-standby, stateless, stateful

Transparent to users (even remotely at home!) Diagnostics

– Control who can perform diagnostics and see traffic– Journal all bindings: Can tell who sent a packet when.

Flagship Projects

#1: Build our own small private programmable backbone


RoutingControl & Mgmt

RoutingControl & Mgmt

HardwareDatapath

HardwareDatapath

Open Source “Router Kit”

Software: Linux/XORP (ICSI)

Hardware: NetFPGA (Stanford)

Program in Verilog Industry-standard design flow Contains embedded CPUs

NetFPGA is a PCI cardNetFPGA is a Programmable

4 x 1GE “switch” or anypacket processor

~$500 for kit Available June 2007 For classroom & research

Used in CS344/EE384D “Build an Internet Router” and EE109




Backbone(Lightflow)


FlowTheory

Security(Ethane)

Wireless(Spectrum)

Backbone(VLB)


How would you like to take part?


Agenda 09:00 - 09:45

Nick McKeownIntroduction

09:45 - 10:30Jonathan Turner, WUSTLAn Architecture for a Diversified Internet

10:30 - 11:00Break

11:00 - 11:30Bernd GirodClean Slate Design for Internet Video Delivery

11:30 - 12:00Balaji Prabhakar21st Century Queuing Theory, and Internet Address Allocation

12:00 – 13:30Lunch with Poster Session

13:30 - 14:00William B. Norton, EquinixVideo Internet: The Next Wave of Massive Disruption to the U.S. Peering Ecosystem

14:00 - 14:30Dan BonehA Clean Slate Approach to Web Technology

14:30 - 15:00John MitchellSecurity Analysis of Network Protocols

15:00 - 16:00PANEL (Moderated by Balaji Prabhakar)It's Not Just About the Plumbing

http://cleanslate.stanford.edu the stanford clean slate program nick mckeown professor of computer...

Documents

clean slate research

legacy slide

optical switching slide

geni project office

boundaries projects

new collaborative projects

architectural blueprint

details of flow