5The Future is Distributed Clouds integrated with Software-Defined-Networks!
6SDN 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?
7Network 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
8Clean 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…
9Some 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)
10Common 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
11Historic 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.”
12OpenFlow 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
13Openflow rationalizes routing.It does nothing aboutendpoint services
14abstract in-network endpoint (a.k.a. “middlebox”) Question:Wouldn’t it be nice toabstract in-network endpoint (a.k.a. “middlebox”)services as well?
15Question II:Wouldn’t It be nice toPut “Endpoints” whereWe need them, not justWhere we are?
16In-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
17Middleboxes 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.
18Going 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…
22Advantages 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
23OpenFlow + In Network Processing Line-rate processingLargely implementable on COTS switchesPacket handling on a per-flow basisRapid rule updateUnified view of the networkL2-L7 services
24But 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
25program routing protocols OpenFlow lets usprogram routing protocolsQuestion: how can weprogram a network ofmiddleboxes?
26Shenker’s SDN Architecture Specification of a virtual network, with explicit forwarding instructionsTranslation onto OpenFlow rules on physical networkEffectuation on physical network
28Key Function we want: Add Processing Anywhere in the Virtual Network
29Going 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
30Key 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)
31Implications 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”
32Implications 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
35GENI 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)
36GENI And The Distributed Cloud Stack Physical ResourcesGENI Racks, Emulab, GENI backboneCloud OSProtoGENI, ExoGENI…Orchestration LayerGENI Portal, Flack…
40Distributed 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)
45Programming 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
46TransGeo: 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…
51Opening 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
52GENI 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
54Staged Rollout Permanent Layer-2 Network Spring 2014 Shared File System based on (Swift) Spring 2014Python environment Summer 2014
55Thanks 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
56Thanks 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
57Conclusions 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