5 The Future is Distributed Clouds integrated with Software-Defined-Networks!
6 SDN is a set of abstractions over the networking control plane Proxies are an essential element of the Internet ArchitectureShouldn’t there be an abstraction architecture for proxies?
7 Network ChallengesOriginal Concept of the Network: dumb pipe between smart endpointsContent-agnostic routingRates controlled by endpointsContent- and user-agnostic forwardingClean separation of concernsRouting and forwarding by network elementsRate 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 endpointsFor high-QoS applicationsFor lousy linksNeed in-network security and admission controlEndpoint security easily overwhelmed…
9 Some Examples Load-balanced end-system multicast Adaptive/DPI-based Intrusion DetectionIn-network transcoding to multiple devicesWeb and file content distribution networksLink-sensitive store-and-forward connection-splitting TCP proxiesproxies (e.g., MailShadow)In-network compression engines (Riverbed)Adaptive firewallIn-situ computation for data reduction from high-bandwidth sensors (e.g., high-resolution cameras)
10 Common FeatureAll of these examples require some combination of in-network and endpoint servicesInformation from the networkDiversion to a proxyLine-rate packet filteringAll require endpoint processingStateful processingConnection-splittingFilesystem accessThree central use casesOptimization of network resources, especially bandwidthProximity to user for real-time responseIn-situ sensor processing
11 Historic Solution: Middleboxes Dedicated network appliances to perform specific functionGets the job done, but…Appliances proliferate (one or more per task)OpaqueInteract unpredictably…Don’t do everythingE.g., generalized in-situ processing engine for data reductionAPST, 2005: “The ability to support…multiple coexisting overlays [of proxies]…becomes the crucial universal piece of the [network] architecture.”
12 OpenFlow and SDNL2/L3 Technology to permit software-defined control of network forwarding and routingWhat it’s not:On-the-fly software decisions about routing and forwardingIn-network connection-splitting store-and-forwardIn-network on-the-fly admission controlIn-network content distributionMagic….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 Openflow rationalizes routing.It does nothing aboutendpoint services
14 abstract in-network endpoint (a.k.a. “middlebox”) Question:Wouldn’t it be nice toabstract in-network endpoint (a.k.a. “middlebox”)services as well?
15 Question II:Wouldn’t It be nice toPut “Endpoints” whereWe need them, not justWhere we are?
16 In-Network Processing L4/L7 Services provided by nodes in the networkTCP/Application layer proxiesStateful/DPI based intrusion detectionApplication-layer admission controlApplication-layer load-balancing….Key featuresStateful processingTransport/Application layer information required
17 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.”Generalized Modern View (this talk): Proxies and Middleboxes are special cases of a general need: endpoint processing in the network. We need to merge the Cloud and the Network.
18 Going From Today to Tomorrow Today: MiddleboxesTomorrow: In-network general-purpose processors fronted by OpenFlow switchesAdvantages of MiddleboxesSpecialized processing at line rateDisadvantages of middleboxesNonexistent programming environmentOpaque configurationVendor-specific updatesOnly common functions get doneInteract unpredictably…
22 Advantages of the Generalizing and Factoring the Middlebox TransparentOpen programming environment: Linux + OpenFlowMuch broader range of features and functionsInteractions between middleboxes mediated by OpenFlow rulesVerifiablePredictableUpdates are software uploads
23 OpenFlow + In Network Processing Line-rate processingLargely implementable on COTS switchesPacket handling on a per-flow basisRapid rule updateUnified view of the networkL2-L7 services
24 But I Need Proxies Everywhere… Proxies are needed where I need endpoint processingIn-situ data reductionNext to usersWhere I need filteringCan’t always predict these in advance for every service!So I need a small cloud everywhere, so I can instantiate a middlebox anywhereSolution = Distributed “EC2” + OpenFlow network“Slice”: Virtual Network of Virtual MachinesOpenFlow creates Virtual Network“EC2” lets me instantiate VM’s everywhere
25 program routing protocols OpenFlow lets usprogram routing protocolsQuestion: how can weprogram a network ofmiddleboxes?
26 Shenker’s SDN Architecture Specification of a virtual network, with explicit forwarding instructionsTranslation onto OpenFlow rules on physical networkEffectuation on physical network
28 Key Function we want: Add Processing Anywhere in the Virtual Network
29 Going from Virtual Network to Virtual Distributed System Specification of a virtual distributed cloud, with explicit forwarding instructions BETWEEN specified VMsTranslation onto OpenFlow rules on physical network AND instantiation on physical machines at appropriate sitesEffectuation on physical network AND physical clouds
30 Key Points Federated Clouds can be somewhat heterogeneous Must support common APICan have some variants (switch variants still present a common interface through OpenFlow)DSOS is simply a mixture of three known components:Network Operating SystemCloud Managers (e.g., ProtoGENI, Eucalytpus, OpenStack)Tools to interface with Network OS and Cloud Managers (nascent tools under development)
31 Implications for OpenFlow/SDN Southbound API (i.e., OpenFlow): minimal and anticipated in 1.5“Support for L4/L7 services”, aka, seamless redirectionNorthbound APIJoint allocation of virtual machines and networksLocation-aware allocation of virtual machinesWAN-aware allocation of networksQoS controls between sitesBuild on/extend successful architectures“Neutron for the WAN”
32 Implications for Cloud Architectures Key problem we’ve rarely considered: how do we easily instantiate and stitch together services at multiple sites/multiple providers?Multiple sites is easy, multiple providers is notNeed easy way to instantiate from multiple providersCommon AUP/Conventions? ProbablyCommon form of identity/multiple IDs? Multiple or bottom-up (e.g. Facebook)Common API? AbsolutelyNeed to understand what’s important and what isn’tE.g. very few web services charge for bandwidth
35 GENI Mesoscale Nationwide network of small local clouds Each cloud worker coresSeveral TB of diskOpenFlow-native local switchingInterconnected over OpenFlow-based L2 NetworkLocal “Aggregate Manager” (aka controller)Two main designs with common APIInstaGENI (ProtoGENI-based)ExoGENI (ORCA/OpenStack-based)Global Allocation through federate aggregate managersUser allocation of networks and slices through tools (GENI portal, Flack)
36 GENI And The Distributed Cloud Stack Physical ResourcesGENI Racks, Emulab, GENI backboneCloud OSProtoGENI, ExoGENI…Orchestration LayerGENI Portal, Flack…
40 Distributed Clouds and NSFNet: Back to the Future GENI today is NSFNet circa 1985GENI and the SFA: Set of standards (e.g., TCP/IP)Mesoscale: Equivalent to NSF BackboneGENIRacks: Hardware/software instantiation of standards that sites can deploy instantlyEquivalent to VAX 11 running Berkeley UnixInstaGENI cluster running ProtoGENI and OpenFlowOther instantiations which are interoperableVNode (Aki Nakao, University of Tokyo and NICT)Tomato (Dennis Schwerdel, TU-Kaiserslautern)
44 “Testbeds” vs “Clouds” JGN-X, GENI, SAVI, Ofelia, GLab, OneLab are all described as “Testbeds”But they are really CloudsTests require realistic servicesHistory of testbeds:Academic ResearchAcademic/Research servicesCommercial servicesExpect similar evolution here (but commercial will come faster)
45 Programming Environment for Distributed Clouds Problem: Allocating and configuring distributed clouds is a painAllocate network of VM’sBuild VM’s and deploy imagesDeploy and run softwareBut most slices are mostly the sameAutomate commonly-used actions and pre-allocate typical slices5-minute rule: Build, deploy, and execute “Hello, World” in five minutesDecide what to build: start with sample application
46 TransGeo: A Model TransCloud Application Scalable, Ubiquitous Geographic Information SystemOpen and PublicAnyone can contribute layersAnyone can host computationWhy GIS?Large and active communityCharacterized by large data sets (mostly satellite images)Much open-source easily deployable software, standard data formatsComputation naturally partitions and is loosely-coupledCollaborations across geographic regions and continentsVery pretty…
51 Opening up TransGEO: The GENI Experiment Engine Key Idea: Genericize and make available the infrastructure behind the TransGEO demoOpen to every GENI, FIRE, JGN-X, Ofelia, SAVI…experimenter who wants to use itTransGEO is a trivial application on a generic infrastructurePerhaps 1000 lines of Python code on top ofKey-Value StoreLayer 2 networkSandboxed Python programming environmentMessaging ServiceDeployment ServiceGIS Libraries
52 GENI Experiment Engine Permanent, Long-Running, Distributed File SystemPermanent, Long-Running, GENI-wide Message ServicePermanent, Long-Running, Distributed Python EnvironmentPermanent, world-wide Layer-2 VLANs on high-performance networksAll offered in slicesAll shared by many experimentersModel: Google App EngineAdvantage for GENI: Efficient use of resourcesAdvantage for Experimenters: Up and running in no time
54 Staged Rollout Permanent Layer-2 Network Spring 2014 Shared File System based on (Swift) Spring 2014Python environment Summer 2014
55 Thanks and Credits Joe Mambretti, Fei Yeh, Jim Chen Northwestern/ iCAIRAndy Bavier, Marco Yuen, Larry Peterson, Jude Nelson, Tony MackPlanetWorks/PrincetonChris Benninger, Chris Matthews, Chris Pearson, Andi Bergen, Paul Demchuk, Yanyan Zhuang, Ron Desmarais, Stephen Tredger, Yvonne Coady, Hausi MullerUniversity of VictoriaHeidi Dempsey, Marshall Brinn, Vic Thomas, Niky Riga, Mark Berman, Chip ElliottBBN/GPORob Ricci, Leigh Stoller, Gary WongUniversity of UtahGlenn Ricart, William Wallace, Joe KonstanUS IgnitePaul Muller, Dennis SchwerdelTU-KaiserslauternAmin Vahdat, Alvin AuYoung, Alex Snoeren, Tom DeFantiUCSD
56 Thanks and Credits Nick Bastin Barnstormer Softworks Shannon Champion Matrix IntegrationJessica Blaine, Jack Brassil, Kevin Lai, Narayan Krishnan, Dejan Milojicic, Norm Jouppi, Patrick Scaglia, Nicki Watts, Michaela Mezo, Bill Burns, Larry Singer, Rob Courtney, Randy Anderson, Sujata Banerjee, Charles ClarkHPAki NakaoUniversity of Tokyo
57 Conclusions Distributed Clouds are nothing new… But this is OK… Akamai was basically the first Distributed CloudSingle Application, now generalizingBut this is OK…Web simply wrapped existing servicesNow in vogue with telcos (“Network Function Virtualization”)What’s new/different in GENI/JGN-X/SAVI/Ofelia….Support from programmable networks“Last frontier” for software in systemsOpen ProblemsSiting VMs!Complex network/compute/storage optimization problemsNeeds“http”-like standardization of APIs at IaaS, PaaS layers