Diversified Internet Architecture

1. Diversified Internet Architecture Jon Turner, Patrick Crowley, Sergey Gorinsky, John Lockwood www.arl.wustl.edu/~jst/

2. Project Overview • Enable diversemetanetworks on shared substrate • Substrate architecture • data plane – flexible metalink support • control plane • configuring metanets – metarouters and metalinks • control communication and support services • architectural neutrality and security • Experimental metanetworks • publish-subscribe metanet for distributed simulation • omnidirectional multicast distribution trees with interest filters • high performance location-based filtering • large-scale science metanet • advance scheduling of bulk transfers • reconsidering fairness for on-demand schedules

3. many substratedomains metanetsspan multipledomains Substrate Domains in Div. Internet

4. Architectural Neutrality • Allow maximum diversity among metanets • enable wide variety of protocols, service models • Minimize substrate role, maximize metanet role • substrate will be difficult to change • metanets should handle all things that may change • Security and mobility • enable secure metanets • enable metanets that support mobility • minimize substrate role in providing security, mobility to enable on-going improvements • Limit substrate to resource provisioning role • no end-to-end packet delivery at substrate level • provides “raw” resources to metanets • diversity of resource types, open to new types

5. Substrate DomainController (SDC) Metanet Controller (MC) Substrate Control Metanet (SCM) Substrate Control Communication • SCM for control communication outside metanets • user-metanet connection requests, metanet-to-substrate • may have more than one for reliability, upgradability • SDCs provide control interface to substrates • MCs provide control interface to metanets

6. SCM Network Services • Unicast datagrams with spoof prevention andreceiver control with source-based queuing/filtering • hierarchical addresses with top half encoding location • OSPF-like protocol for routing • Publish/query service • used by substrates and metanets to advertise services • substrate domains advertise substrate platform locations, peering relationships, etc. • metanets advertise SCM addresses of metanet controllers providing connection services for different geographic regions • authenticated data with secure update protocols • may restrict distribution of information • published information can be queried by SCM clients • Authentication service • trusted repository for (identifier, public key) pairs

7. Security Issues • Enable secure metanets; minimize substrate role • enable continuing evolution of security mechanisms • Diversity of trust • most substrate domains cannot be trusted and should not be burdened with onerous security requirements • domains that host metarouters must be trustworthy • some metanets (e.g. SCM) must be trustworthy • Accreditation of selected substrates and metanets • accreditation is optional • carries with it certain responsibilities (maybe legal) • requires authentication, secure interaction • What level of isolation do metanets require?

8. Securing Metanets access metalinksingle endpoint for spoof-prevention accredited substrate domain unaccredited substrate domain • Use only accredited substrate domains for metarouters • substrate provides isolation to protect against DoS • Protect backbone metalinks using encryption • prevents eavesdropping, traffic insertion • can detect lost packets and hold substrate accountable • Protect access metalinks from misuse • prevent address spoofing by allowing only one endpoint

9. substrate topology with capacities metanet access points Least Cost Metanet Design • traffic constraints • NY-to-world – ≤100 • LA-to-Chicago – ≤30% • Atlanta-to-west – ≤50% Given topology, routing policy and node/link capacities that ensure all allowed traffic patterns can be handled Find

10. far≤25% 50% cost/lower bound 75% 100% looser pairwise constraints  Quick Summary • How traffic constraints affect optimal topology • Approximate topology selection algorithms • link/node pruning • good solutions relative to computed lower bounds • Next steps • substrate capacities • search over routes,not topologies • multi-commodity flow computations key tool

11. GPE CP ... Switch NPE LineCard ... Supercharged Planetlab Platform (SPP) • Objectives • enable substantial performance gains for many PlanetLab apps • prototype platform for high performance overlay hosting services • System components • Line Card (LC) with 10x1GbE physical interfaces – (or 1x10GbE) • Control Processor (CP) for system management • Processing Engines for hosting slices • conventional server blade (GPE) and network processor blade (NPE) • Switch blade – 10 GbE fabric plus 1 GbE control

12. PLC control net CP GPE VS GNM slicedesc. SC LNM VS VS LRM GRM ... Switch MP NPE MP LC ... Overview of Control • Illusion of single Plab node • Global Node Manager (GNM) • pools PLC for slice info • stores copy of local slices • selects GPE for new slice • Local Node Managers (LNM) • check for new slices on CP • setup vServers (VS) • Slices request NPE resources from Local Resource Mgr (LRM) • assigned a fast path slice • logical external interfaces defined by UDP port numbers • Line Card (LC) manages mux/ demux using port numbers • RMs coordinate “server ports” • NAT for “client ports”

13. Remote Login Interface SliceManager out-of-bandcontrol sharedserver exception packets& in-band control exception packets& in-band control Control Interface Filters Parse Lookup HdrFormat outputinterfaces ... ... inputinterfaces ... QueueManager Fast Path Fast Path/Slow Path App. Structure GPE hosts multiple slice managers NPE hosts fast path processing

14. IPv4 Performance Comparisons • NPE hosting IPv4 forwarding application • GPE hosting Click software router in user-space • 80x improvement in packet processing rate • Over 100x latency improvement at high loads • measuring ping delays in presence of background traffic

15. FreeList Mgr (1 ME) Stats (1 ME) Tx, QM Parse Plugin XScale Bandwidth Usage QM Copy Plugins SRAM Routing Table Queue Lengths Network Configuration xScale xScale TCAM Assoc. Data ZBT-SRAM SRAM HdrFmt (1 ME) Parse, Lookup, Copy (3 MEs) Rx (2 ME) Mux (1 ME) QM (1 ME) Tx (1 ME) 64KW ssh window to host showing ping delays NN PacketLosses SRAM 64KW 64KW Each Queue Parameters SRAM Ring NN NN NN NN Plugin4 Plugin3 Plugin0 Plugin1 Plugin2 SRAM xScale Scratch Ring NN Ring NN RouterPluginCommands Open Network Lab and GENI • ONL is Internet-accessible networking lab (onl.wustl.edu) • Major expansion underway • 14 new NP-based routers • plugin environment for toenable extensions • staging area for SPP/GENI