The SAHARA Project A Revolutionary Service Architecture for

The SAHARA Project: A Revolutionary Service Architecture for Future Telecommunications Systems http: //sahara. cs. Berkeley. edu Randy H. Katz, Anthony Joseph, Ion Stoica Computer Science Division Electrical Engineering and Computer Science Department University of California, Berkeley, CA 94720 -1776 1

Presentation Outline • • • History and Motivation Sahara Project Goals Sahara Architectural Elements Early Research Results Relevance to CITRIS Summary and Conclusions 2

Presentation Outline • • • History and Motivation Sahara Project Goals Sahara Architectural Elements Early Research Results Relevance to CITRIS Summary and Conclusions 3

Experimental Systems Research Methodology Analyze & Design Evaluate Prototype • Evaluate existing system to discover bottlenecks • Analyze alternatives to select among approaches • Prototype selected alternatives to understand implementation complexities • Repeat 4

BARWAN: 1995 -1998 Bay Area Research Wireless Access Network Low-tier Satellite Regional Area High-tier Local Area Wide Area High Mobility Low Mobility • Universal multimedia information access with mobility spanning residences, businesses, public/pedestrian, mobile/vehicular, national, and global regions – Session/Transport/Routing Mobility+Performance (Hari, Venkat, Seshan, Katz) – Client-Proxy-Server Architecture (Fox, Gribble, Brewer) – Soft-state Streaming Media Gateways (Amir, Mc. Canne) 5

ICEBERG: 1998 -2001 Internet-based Cor. E Beyond thi. Rd Generation Access Network Plane PSTN GSM IAP IAP ICEBERG Network Plane IAP A SF i. POP IAP NY i. POP IAP SF i. POP B NY i. POP Clearing House ISP Plane CA PR PAC APC NMS Pager ISP 1 ISP 2 • i. POP: Clustered computing environ. • Call Agent: handles signaling, one per device per call party ISP 3 • Name Mapping Service: Maps ICEBERG unique ID service end point • Preference Registry/Personal Activity Coordinator: user profile/user tracking • APC service: creates transcoding datapath between endpoints 6

ICEBERG Lessons • Soft state enabled session establishment and maintenance (Helen Wang’s Ph. D. ) – Distributed not centralized session maintenance protocol to provide correctness and robustness – Soft-state works well for tolerating transient component failures, network partitions, and exceptional conditions • Clearinghouse architecture (Chen-nee Chuah’s Ph. D. ) – Cooperatively negotiated “soft Qo. S” across admin domains – Traffic-matrix admission control – Group policing for malicious flow detection • Dynamic data transcoding (Several M. S. projects) – – Operator + plus concept, extended to wide-area Enables source/target data format independence/isolation Rapid support for new devices (new device in 2 hrs!) Universal In-box 7

ICEBERG Prelude to SAHARA • ICEBERG lives on top of multiple access networks (e. g. , cellular, pager, PSTN) • ICEBERG service provider places i. POP in each service region, executes on highly available clusters, links regions via multiple core network ISPs • Interactions among alternative service providers not explicitly addressed • Assumes a homogeneous ICEBERG-capable universe What about cooperation and competition among service providers? 8

Horizontal Service Model Applications (Portals, E-Commerce, E-Tainment, Media) Appl Infrastructure Services (Distribution, Caching, Searching, Hosting) AIP ISV Application-specific Servers (Streaming Media, Transformation) ASP Internet Data Centers ISP CLEC Application-specific Overlay Networks (Multicast Tunnels, Mgmt Svrcs) Global Packet Network Internetworking (Connectivity) 9

Horizontal Service Model Applications (Portals, E-Commerce, E-Tainment, Media) Appl Infrastructure Services Applications-enabling (Distribution, Caching, Services Searching, Hosting) AIP ISV Application-specific Servers Processing/Storage (Streaming Media, Placement Location & Transformation) ASP Internet Data Centers ISP CLEC Application-specific Reachability & Overlay Networks (Multicast Topology Tunnels, Mgmt Svrcs) Global Packet Network Internetworking (Connectivity) 10

SAHARA: 2001 -2003 • • • Service Architecture for Heterogeneous Access, Resources, and Applications 11

Presentation Outline • • • History and Motivation Sahara Project Goals Sahara Architectural Elements Early Research Results Relevance to CITRIS Summary and Conclusions 12

Sahara Research Themes • New mechanisms, techniques for end-to-end services w/ desirable, predictable, enforceable properties spanning potentially distrusting service providers – Tech architecture for service composition & inter-operation across separate admin domains, supporting peering & brokering, and diverse business, value-exchange, access-control models – Functional elements » Service discovery » Service-level agreements » Service composition under constraints » Redirection to a service instance » Performance measurement infrastructure » Constraints based on performance, access control, accounting/billing/settlements » Service modeling and verification 13

Competition vs. Cooperation • Internet Service Providers: Competition – Peering for packet transport: BGP protocol – Charging based on traffic volumes ISP A Peering Point Hot Potato Routing Peering Point ISP B 14

Competition vs. Cooperation • Wireless Operators: Cooperation – Telephone sessions span multiple providers – Well-defined roaming agreements among mobile operators – Established methods for sharing revenue between local access and transport providers – Context for Virtual Home Environment • Expense of 3 G Infrastructures – – European spectrum auctions: 150 billion+ ECU Capital outlays likely to match spectrum expenses Complex web of biz relationships among operators Result: Collaborative deployment of physical network • Need for a Service infrastructure – Mobile Virtual Network Operator (MVNO) – Content Dissemination Alliances 15

Cooperative Business Models • Any way to build a network? – Partitioning of frequencies independent of actual subscriber density – Duplicate antenna sites – Redundant backhaul networks • Cooperation – “Operators without networks”: MVNOs – “Operators without subscribers”: locally owned access infrastructure – Device ensembles: virtual devices spanning/integrating multiple access networks 16

Cable Modem Connectivity and Processing Premisesbased Access Networks LAN Transit Net Premisesbased Core Networks WLAN Private Peering Transit Net WLAN Operatorbased Cell Regional Internet Datacenter NAP Public Peering Data Voice Analog Transit Net H. 323 RAS H. 323 PSTN DSLAM Data Voice Wireline Regional 17

Presentation Outline • • • History and Motivation Sahara Project Goals Sahara Architectural Elements Early Research Results Relevance to CITRIS Summary and Conclusions 18

Research Questions: Service Design • For a given community of users and a given set of performance, availability, and administrative constraints, – Service Provisioning Problem: How many instances of a service are needed? – Service Placement Problem: Where should these services be placed? – Adaptive Services: How do these deployments change with evolution of the user community and variations in usage demand? 19

Research Questions: Composition Over Providers • Cooperative service placement – Consider placement from perspective of entire community of service providers – How to achieve best possible placement across whole community? – How do service providers make known their services for possible peering/composition with other providers (mechanisms of service advertisement/service level agreement)? – How are these offered services verified (service agreement verification)? Which service provider is responsible? 20

Research Questions: Spanning Service Providers • Brokered service placement – Form own service composition by picking & choosing among service instances discovered from underlying service providers – How is service quality determined by 3 rd-party broker (performance verification)? – How is service composition correctness determined by the 3 rd-party broker (protocol verification)? 21

Research Questions • Service Identification/Choice Problem – Given an application (e. g. , content distribution), which is the best service (e. g. , cache/storage resources, transport/interconnection connectivity and bandwidth for performance-constrained delivery) for supporting it? • Service Selection Problem – Given provisioning & placement of services within admin domain, which is “best” service instance? – Considering load, distance/latency between clients of the service and where the service is placed, subscription/billing relationships, loyalty/affinity relationships, preferences, etc. 22

Service Examples • Connectivity/Reachability – Basic Internet routing between ASs – More sophisticated multicast distribution formation – Performance constrained connectivity/latency and bandwidth guarantees (e. g. , Clearinghouse/Soft Qo. S) • Performance monitoring services (distance/latency mapping, load collection/balancing across service instances) • Content distribution services: cache/storage resources, distribution/transport resources 23

What is a Service? • Content transformation services (format translators) • Gateway selection under load and performance constraints • Resource allocation services (e. g. , auctions for bandwidth, processing, storage) • Mobility services (e. g. , device ensembles) • Who is allowed to invoke a service: Authentication, Accounting, Access Control • Payment for services: billing, financial clearinghouses • Interworking services across administrative domains/different technologies 24

Some Starting SAHARA Assumptions • Dynamic confederations to better share resources & deploy access/achieve regional coverage more rapidly • Scarce resources efficiently allocated using dynamic “market-driven” mechanisms • Trusted third partners manage resource marketplace in a fair, unbiased, audited and verifiable basis • Vertical stovepipe replaced by horizontally organized “multi-providers, ” open to increased competition and more efficient allocation of resources • Sanity Check? 25

Implications for Architectural Elements • “Open” service/resource allocation model – Independent service creation, establishment, placement, in overlapping domains – Resources, capabilities, status described/exchanged amongst confederates, via enhanced capability negotiation – Allocation based on economic methods, such as congestion pricing, dynamic marketplaces/auctions – Trust management among participants, based on trusted third party monitors 26

Implications for Architectural Elements • Forming dynamic confederations – Discovering potential confederates – Establishing trust relationships – Managing transitive trust relationships & levels of transparency – Not all confederates need be competitors--heterogeneous, collocated access networks to better support applications 27

Architectural Elements • Alternative View: Service Brokering – Dynamically construct overlays on component services provided by underlying service providers » E. g. , overlay network segments with desirable performance attributes » E. g. , construct end-to-end multicast trees from subtrees in different service provider clouds – Redirect to alternative service instances » E. g. , choose instance based on distance, network load, server load, trust relationships, resilience to network failure, … 28

Some Observations • Support for multiple service providers had to be retrofitted to original Internet architecture • Telephony architecture better developed model of multiple service providers & peering, but with longerlived agreements, fewer providers • Need for support in a more dynamic environment, with larger numbers of service providers and/or service instances • Key Approaches: – – Service Composition Topology-awareness Brokering vs. Confederation Market-based Mechanisms for Resource Allocation 29

SAHARA Architecture Network Environment – Service Generic Mgmt & Control – – Applications Objects Sessions Transport Distributed Processing Environment Performance Verification SLAs Network Environment – Explicitly distinguish between multiple Access Networks and Core Networks “Gateway Provider” (GP) » Points of Presence between different kinds of networks “Path” Provider (PP) » Autonomous systems (AS) determine service domains for purposes of reachability » Peering between administrative domains managed via BGP » Point-to-point (and multipoint) latency, availability SLAs within a single administrative domain “Datacenter” Provider (DCP) » Distributed computing resources (processing, storage) embedded within network topology » Load/latency/availability SLAs within single datacenter location 30

SAHARA Architecture Service Generic Mgmt & Control Applications Objects Sessions Transport Distributed Processing Environment Network Environment Distributed Processing: Service Placement – Place objects (operators + data) at DCs, connected by paths » Multiple object and path instances for load balancing, availability, scale – Brokers » Given performance & other constraints: • • Path brokering: create “overlay network” among processing sites, link by link DC brokering: given distribution of clients, select processing sites for operators – Confederations » Visibility of (alternative) paths, DCs among associated providers » Peer-to-peer reassignment of objects to DCs and paths 31

SAHARA Architecture Service Generic Mgmt & Control Distributed Processing: Service Building Services – – Applications – Objects Sessions Transport Distributed Processing Environment Network Environment – – Authorization, Authentication, Accounting » Interworking services spanning administrative domains Service Selection and Naming Service » Choosing a “best” service » Finding “nearest” service instance Service Redirection Service » Load balancing among service instances » Selecting the best among services with common affinity » Mobility support Resource Allocation Service » Auction-based allocation Performance Measurement Service » Network distance measurements » Latency measurements for operator invocation over network 32

SAHARA Architecture Applications Service Generic Mgmt & Control Applications Objects Sessions Transport Distributed Processing Environment Network Environment – Unified messaging services (Universal Inbox) » Content xform proxies » Latency, availability, scalability – Content-distribution services » Cache placement & replenishment algorithms » Adaptive to client community evolution – IP Telephony » H. 323 gateway selection/load balancing » Balance between packet (IP) and circuit-switched (PSTN) path – Device Ensembles/Virtual Devices » Inter-network stream synchronization » Virtual device proxy placement – Virtual Home Environment 33

SAHARA Architecture – Composed applications – Dynamic composition of services with desirable properties – Efficient wide-area deployment and use of services – Network of paths with more desirable end 2 end properties than the link network Paths (sets of links) with additional guarantees Applications Composition Services End 2 End Network – Enhanced Paths IP Network Links with desired properties – Enhanced Links – Basic underlying IP network composed of links and nodes 34

Presentation Outline • • • History and Motivation Sahara Project Goals Sahara Architectural Elements Early Research Results Relevance to CITRIS Summary and Conclusions 35

Recent Research Publications • Topology Discovery – L. Subramanian, V. Padmanabhan, R. H. Katz, “Geographic Properties of Internet Routing, ” USENIX Conference, Monterey, California, (June 2002). – L. Subramanian, S. Agarwal, J. Rexford, R. H. Katz, “Characterizing the Internet Hiearchy from Multiple Vantage Points, ” IEEE Infocom 2002, New York, (June 2002). • Service Discovery – S. Czerwinsky, B. Zhao, T. Hodes, A. Joseph, R. H. Katz, “An Architecture for a Secure Service Discovery Service, ” ACM/Balzer Mobile Networking and Applications (MONET), to appear. • Service Composition – Z. M. Mao, R. H. Katz, “Achieving Service Portability Using Self. Adaptive Data Paths, ” IEEE Communications Magazine, (January 2002), pp. 108 -114. 36

Recent Research Publications • Content Distribution – T. Wong, T. Henderson, R. H. Katz, “Tunable Reliable Multicast for Periodic Information Dissemination, ” ACM/Balzer Mobile Networking and Applications (MONET), Special Issue on Satellite-Based Information Systems, V. 7, N. 1, (January 2002), pp. 21 -36. – S. Zhuang, B. Zhao, A. Joseph, R. H. Katz, J. Kubiatowicz, “Bayeux: An Architecture for Wide-area Fault-Tolerant Data Dissemination Protocol, ” ACM NOSSDAV 2001, New York, (June 2001). – Z. Mao, W. So, R. H. Katz, “Network Support for Mobile Multimedia Using a Self-Adaptive Distributed Proxy, ” ACM NOSSDAV 2001, New York, (June 2001). 37

Recent Research Publications • Authorization, Authentication, Accounting – Y. Chen, A. Bargteil, D. Bindel, R. H. Katz, J. Kubiatowicz, “Quantifying Network Denial of Service: A Location Service Case Study, ” Third International Conference on Information and Communications Security (ICICS'2001), Xi'an, China, (November 2001). – T. Suzuki, R. H. Katz, “An Authorization Control Framework to Enable Service Composition Across Domains, ” Proceedings Eleventh World Wide Web Conference (WWW 2002), Honolulu, HI, (May 2002). • Economics-based Resource Allocation – J. Shih, R. H. Katz, A. D. Joseph, “Pricing Experiments for a Computer -Telephony Service Usage Allocation, ” IEEE Globecom 2001, San Antonio, TX, (November 2001). – C. Chuah, L. Subramanian, A. D. Joseph, R. H. Katz, “Qo. S Provisioning Using a Clearing House Architecture, ” 8 th International Workshop on Quality of Service (IWQOS 2000), Pittsburgh, PA, (June 2000). 38

Presentation Outline • • • History and Motivation Sahara Project Goals Sahara Architectural Elements Early Research Results Relevance to CITRIS Summary and Conclusions 39

Relevance to CITRIS • How to deploy a wide-area infrastructure without constructing (all of) your own network and datacenters? – Note: network resources follow people, roads, railroads, etc. • Cooperative model may be an especially good match for civilian infrastructures – E. g. , build service overlay over municipal, state, federal agencies’ sensors, networks, processing, storage centers • Sensor and control network services – Latency constraints for control messages – Placement of processing for aggregation, inference – Placement of storage for archive, logging 40

Presentation Outline • • • History and Motivation Sahara Project Goals Sahara Architectural Elements Early Research Results Relevance to CITRIS Summary and Conclusions 41

Summary and Status • Evolve (mobile) Internet architecture to better support multiple service provider model – Dynamic environment, location-based implies larger numbers of service providers & service instances • Refine and build SAHARA Architecture – Specification driven by selected applications and underlying widearea services – Composition across confederated vs. independent service providers: peer-to-peer vs. brokering 42

The SAHARA Project: A Revolutionary Service Architecture for Future Telecommunications Systems 43