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

1
The SAHARA Project A Revolutionary Service
Architecture for Future Telecommunications
Systemshttp//sahara.cs.Berkeley.edu

• Randy H. Katz, Anthony Joseph, Ion Stoica
• Computer Science Division
• Electrical Engineering and Computer Science
  Department
• University of California, Berkeley
• Berkeley, CA 94720-1776

2
Presentation Outline

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

3
Presentation Outline

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

4
Experimental SystemsResearch Methodology
5
BARWAN 1995-1998Bay Area Research Wireless
Access Network

• Universal multimedia information access with
  mobility spanning residences, businesses,
  public/pedestrian, mobile/vehicular, national,
  and global regions
• Session/Transport/Routing MobilityPerformance
  (Hari, Venkat, Seshan, Katz)
• Client-Proxy-Server Architecture (Fox, Gribble,
  Brewer)
• Soft-state Streaming Media Gateways (Amir,
  McCanne)

6
ICEBERG 1998-2001Internet-based CorE Beyond
thiRd Generation
Access Network Plane
ICEBERG Network Plane
Clearing House
ISP Plane
ISP1
ISP2
ISP3
7
ICEBERG Lessons

• Soft state enabled session establishment and
  maintenance (Helen Wangs 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 Chuahs
  Ph.D.)
• Cooperatively negotiated soft QoS 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

8
ICEBERG Prelude to SAHARA

• ICEBERG lives on top of multiple access networks
  (e.g., cellular, pager, PSTN)
• ICEBERG service provider places iPOP 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?

9
Horizontal Service Model
10
Horizontal Service Model
Applications-enabling Services
Processing/Storage Location Placement
Reachability Topology
11
SAHARA 2001-2003

• Service
• Architecture for
• Heterogeneous
• Access,
• Resources, and
• Applications

12
Presentation Outline

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

13
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

14
Competition vs. Cooperation

• Internet Service Providers Competition
• Peering for packet transport BGP protocol
• Charging based on traffic volumes

ISP A
Hot Potato Routing
ISP B
15
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 3G 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

16
CooperativeBusinessModels

• 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

17
Connectivity and Processing
18
Presentation Outline

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

19
Research QuestionsService 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?

20
Research QuestionsComposition 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?

21
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 3rd-party
  broker (performance verification)?
• How is service composition correctness determined
  by the 3rd-party broker (protocol verification)?

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

23
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
  QoS)
• Performance monitoring services (distance/latency
  mapping, load collection/balancing across service
  instances)
• Content distribution services cache/storage
  resources, distribution/transport resources

24
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

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

26
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

27
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--heteroge
  neous, collocated access networks to better
  support applications

28
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,

29
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
  longer-lived 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

30
SAHARA Architecture

• 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

Service
Generic Mgmt Control
Applications
Objects
Sessions
Trans- port
Distributed ProcessingEnvironment
Performance Verification
SLAs
Network Environment
31
SAHARA Architecture

• Distributed ProcessingService 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

Service
Generic Mgmt Control
Applications
Objects
Sessions
Trans- port
Distributed ProcessingEnvironment
Network Environment
32
SAHARA Architecture

• Distributed ProcessingService Building
  Services
• 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

Service
Generic Mgmt Control
Applications
Objects
Sessions
Trans- port
Distributed ProcessingEnvironment
Network Environment
33
SAHARA Architecture

• Applications
• Unified messaging services (Universal In-box)
• 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

Service
Generic Mgmt Control
Applications
Objects
Sessions
Trans- port
Distributed ProcessingEnvironment
Network Environment
34
SAHARA Architecture
Applications
End2End Network
IP Network
35
Presentation Outline

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

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

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

38
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 (WWW2002), 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, QoS Provisioning Using a Clearing House
  Architecture, 8th International Workshop on
  Quality of Service (IWQOS 2000), Pittsburgh, PA,
  (June 2000).

39
Presentation Outline

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

40
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

41
Presentation Outline

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

42
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 wide-area services
• Composition across confederated vs. independent
  service providers peer-to-peer vs. brokering

43
The SAHARA ProjectA Revolutionary Service
Architecture for Future Telecommunications Systems