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

1. Rick McGeer
Chief Scientist, US IGNITE
October 7, 2013

2. Federated Local Clouds
and Software Defined
Networking
Complementary Technologies for
the Next-Generation Internet

3. Or, A Post-Hoc
Justification for the Last
10 Years of My Life
3

4. 4
The Future is Distributed
Clouds integrated with
Software-Defined-
Networks!

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. 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. 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. 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. 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. 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. 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. 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

14. 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

15. 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.”

17. 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

18. Perfect for L1-L3
18
Application
IP
MAC
Transport
PHY
OpenFlow
Network "Operating
System"
Physical
Network
Virtual
Network

19. 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

20. 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

21. 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

22. 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

23. Two Initial Attempts
• IGNITE Technical Architecture
• GENI Mesoscale
23

24. 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

25. 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

26. 26