Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Rick McGeer
Chief Scientist, US IGNITE
October 7, 2013
Federated Local Clouds
and Software Defined
Networking
Complementary Technologies for
the Next-Generation Internet
Or, A Post-Hoc
Justification for the Last
10 Years of My Life
3
4
The Future is Distributed
Clouds integrated with
Software-Defined-
Networks!
5
SDN is a set of
abstractions over the
networking control
plane
Proxies are an
essential element of
the Internet
Architec...
Links
6
http://www.youtube.com/watch?v=eXsCQdshMr4
http://pages.cs.wisc.edu/~akella/CS838/F09/838-
Papers/APST05.pdf
http:...
Network Challenges
• Original Concept of the Network: dumb pipe
between smart endpoints
– Content-agnostic routing
– Rates...
Clean separation of
concerns doesn’t work very
well
• Need application-aware stateful forwarding
(e.g., multicast)
• Need ...
Some Examples
• Load-balanced end-system multicast
• Adaptive/DPI-based Intrusion Detection
• In-network transcoding to mu...
Common Feature
• All of these examples require some combination of
in-network and endpoint services
– Information from the...
Historic Solution:
Middleboxes
• Dedicated network appliances to perform specific
function
• Gets the job done, but…
– App...
OpenFlow and SDN
• L2/L3 Technology to permit software-defined control of network
forwarding and routing
• What it’s not:
...
In-Network Processing
• L4/L7 Services provided by nodes in the network
– TCP/Application layer proxies
– Stateful/DPI bas...
Middleboxes and the
Network
• Classic View: Proxies and Middleboxes are a
necessary evil that breaks the “end-to-end
princ...
Shenker’s SDN Architecture
17
OpenFlow
Network "Operating
System"
Physical
Network
Virtual
Network
Specification of a virt...
Perfect for L1-L3
18
Application
IP
MAC
Transport
PHY
OpenFlow
Network "Operating
System"
Physical
Network
Virtual
Network
Key Function we want: Add
Processing Anywhere in the
Virtual Network
19
OpenFlow + Cloud
Managers
Distributed System
"Oper...
Going from Virtual Network
to Virtual Distributed
System
20
OpenFlow + Cloud
Managers
Distributed System
"Operating System...
Key Points
• Federated Clouds can be somewhat heterogeneous
– Must support common API
– Can have some variants (switch var...
Implications for
OpenFlow/SDN
• Southbound API (i.e., OpenFlow): minimal and
anticipated in 1.5
– “Support for L4/L7 servi...
Two Initial Attempts
• IGNITE Technical Architecture
• GENI Mesoscale
23
Existing
ISP
connects
Layer 2
Ignite
Connect
(1 GE or
10GE)
Layer 3 GENI
control plane
Layer 2 connect
to subscribers
Exis...
GENI Mesoscale
• Nationwide network of small local clouds
• Each cloud
– 80-150 worker cores
– Several TB of disk
– OpenFl...
26
Distributed Clouds and Software Defined Networking
Distributed Clouds and Software Defined Networking
Distributed Clouds and Software Defined Networking
Upcoming SlideShare
Loading in …5
×

Distributed Clouds and Software Defined Networking

944 views

Published on

Distributed Clouds and Software Defined Networking a presentation by Rick McGeer at the US Ignite ONF GENI Workshop on October 8, 2013

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Distributed Clouds and Software Defined Networking

  1. 1. Rick McGeer Chief Scientist, US IGNITE October 7, 2013
  2. 2. Federated Local Clouds and Software Defined Networking Complementary Technologies for the Next-Generation Internet
  3. 3. Or, A Post-Hoc Justification for the Last 10 Years of My Life 3
  4. 4. 4 The Future is Distributed Clouds integrated with Software-Defined- Networks!
  5. 5. 5 SDN is a set of abstractions over the networking control plane Proxies are an essential element of the Internet Architecture Shouldn’t there be an abstraction architecture for proxies?
  6. 6. Links 6 http://www.youtube.com/watch?v=eXsCQdshMr4 http://pages.cs.wisc.edu/~akella/CS838/F09/838- Papers/APST05.pdf http://citeseerx.ist.psu.edu/viewdoc/download?d oi=10.1.1.20.123&rep=rep1&type=pdf
  7. 7. Network Challenges • Original Concept of the Network: dumb pipe between smart endpoints – Content-agnostic routing – Rates controlled by endpoints – Content- and user-agnostic forwarding • Clean separation of concerns – Routing and forwarding by network elements – Rate control, admission control, security at endpoints
  8. 8. Clean separation of concerns doesn’t work very well • Need application-aware stateful forwarding (e.g., multicast) • Need QoS guarantees and network-aware endpoints – For high-QoS applications – For lousy links • Need in-network security and admission control – Endpoint security easily overwhelmed…
  9. 9. Some Examples • Load-balanced end-system multicast • Adaptive/DPI-based Intrusion Detection • In-network transcoding to multiple devices • Web and file content distribution networks • Link-sensitive store-and-forward connection-splitting TCP proxies • Email proxies (e.g., MailShadow) • In-network compression engines (Riverbed) • Adaptive firewall • In-situ computation for data reduction from high-bandwidth sensors (e.g., high-resolution cameras)
  10. 10. Common Feature • All of these examples require some combination of in-network and endpoint services – Information from the network – Diversion to a proxy – Line-rate packet filtering • All require endpoint processing – Stateful processing – Connection-splitting – Filesystem access
  11. 11. Historic Solution: Middleboxes • Dedicated network appliances to perform specific function • Gets the job done, but… – Appliances proliferate (one or more per task) – Opaque – Interact unpredictably… • Don’t do everything – E.g., generalized in-situ processing engine for data reduction • APST, 2005: “The ability to support…multiple coexisting overlays [of proxies]…becomes the crucial universal piece of the architecture.”
  12. 12. OpenFlow and SDN • L2/L3 Technology to permit software-defined control of network forwarding and routing • What it’s not: – On-the-fly software decisions about routing and forwarding – In-network connection-splitting store-and-forward – In-network on-the-fly admission control – In-network content distribution – Magic…. • What it is: – Table-driven routing and forwarding decisions (including drop and multicast) – Callback protocol from a switch to a controller when entry not in table (“what do I do now?”) – Protocol which permits the controller to update the switch
  13. 13. In-Network Processing • L4/L7 Services provided by nodes in the network – TCP/Application layer proxies – Stateful/DPI based intrusion detection – Application-layer admission control – Application-layer load-balancing – …. • Key features – Stateful processing – Transport/Application layer information required
  14. 14. Middleboxes and the Network • Classic View: Proxies and Middleboxes are a necessary evil that breaks the “end-to-end principle” (Network should be a dumb pipe between endpoints) • Modern View (Peterson): “Proxies play a fundamental role in the Internet architecture: They bridge discontinuities between different regions of the Internet. To be effective, however, proxies need to coordinate and communicate with each other.”
  15. 15. Shenker’s SDN Architecture 17 OpenFlow Network "Operating System" Physical Network Virtual Network Specification of a virtual network, with explicit forwarding instructions Translation onto OpenFlow rules on physical network Effectuation on physical network
  16. 16. Perfect for L1-L3 18 Application IP MAC Transport PHY OpenFlow Network "Operating System" Physical Network Virtual Network
  17. 17. Key Function we want: Add Processing Anywhere in the Virtual Network 19 OpenFlow + Cloud Managers Distributed System "Operating System" Physical Distributed Cloud Virtual Distributed SystemApplication IP MAC Transport PHY
  18. 18. Going from Virtual Network to Virtual Distributed System 20 OpenFlow + Cloud Managers Distributed System "Operating System" Physical Distributed Cloud Virtual Distributed System Specification of a virtual distributed, with explicit forwarding instructions BETWEEN specified VMs Translation onto OpenFlow rules on physical network AND instantiation on physical machines at appropiate sites Effectuation on physical network AND physical clouds
  19. 19. Key Points • Federated Clouds can be somewhat heterogeneous – Must support common API – Can have some variants (switch variants still present a common interface through OpenFlow) • DSOS is simply a mixture of three known components: – Network Operating System – Cloud Managers (e.g., ProtoGENI, Eucalytpus, OpenStack) – Tools to interface with Network OS and Cloud Managers (nascent tools under development) 21
  20. 20. Implications for OpenFlow/SDN • Southbound API (i.e., OpenFlow): minimal and anticipated in 1.5 – “Support for L4/L7 services”, aka, seamless redirection • Northbound API – Joint allocation of virtual machines and networks – Location-aware allocation of virtual machines – WAN-aware allocation of networks – QoS controls between sites • Build on/extend successful architectures – “Quantum for the WAN” 22
  21. 21. Two Initial Attempts • IGNITE Technical Architecture • GENI Mesoscale 23
  22. 22. Existing ISP connects Layer 2 Ignite Connect (1 GE or 10GE) Layer 3 GENI control plane Layer 2 connect to subscribers Existing head-end New GENI / Ignite rack pair OpenFlow switch(es) Flowvisor Remote management Instrumentation Aggregate manager Measurement Programmable servers Storage Video switch (opt) Home Most equipment not shown U.S. Ignite City Technical Architecture
  23. 23. GENI Mesoscale • Nationwide network of small local clouds • Each cloud – 80-150 worker cores – Several TB of disk – OpenFlow-native local switching • Interconnected over OpenFlow-based • Local “Aggregate Manager” (aka controller) • Two main designs with common API – InstaGENI (ProtoGENI-based) – ExoGENI (ORCA/OpenStack-based) • Global Allocation through federate aggregate managers • User allocation of networks and slices through tools (GENI portal, Flack) 25
  24. 24. 26

×