“Design Review” Randy H. Katz, Anthony Joseph, Ion Stoica Computer Science Division Electrical Engineering and Computer Science Department University of

“Design Review”

Randy H. Katz, Anthony Joseph, Ion StoicaComputer Science Division

Electrical Engineering and Computer Science DepartmentUniversity of California, Berkeley

Berkeley, CA 94720-1776

The “Sahara” Project

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

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

Global Packet Network Internetworking

(Connectivity)

ISPCLEC

Horizontal Service Model

Application-specificOverlay Networks

(Multicast Tunnels, Mgmt Svrcs)

Applications(Portals, E-Commerce,

E-Tainment, Media)

Application-specific Servers(Streaming Media, Transformation)ASP

InternetData Centers

Appl Infrastructure Services(Distribution, Caching,

Searching, Hosting)

AIPISV

Applications-enablingServices

Processing/StorageLocation & Placement

Reachability &Topology

AccessNetwork

s

Core Networks

Connectivity and Processing

Transit Net

Transit Net

Transit Net

PrivatePeering

NAP

PublicPeering

InternetDatacenter

PSTNRegional

WirelineRegionalVoiceVoice

CellCell

Cell

CableModem

LAN

LAN

LAN

Premises-based

WLAN

WLAN

WLAN

Premises-based

Operator-based

H.323Data

Data

RAS

Analog

DSLAM

H.323

Goals of the Design Review

• Originally– Present technical architecture for

comment/review

• But,– Not ready to do so!– Too early in our thinking for comprehensive

architecture

• So,– Snapshot of our current thoughts– Scenarios of service provision– Dialog with industry colleagues on essential

components of architecture and their interactions

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?

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?

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

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.

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

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

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?

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

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

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

TINA Reference Model

• Separate– apps from exec environ– service-specific from control

• Generic (Common) Objects + Service-Specific Objects

• Session: duration-based context for processes provisioning a service– Access session (authen-

tication, service selection)– Service session

• User service session (user state, resources)

• Provider service session (service logic)

– Comm session: abstract view of net connections

Distributed ProcessingEnvironment

Objects Sessions Trans-port

Applications

ServiceGeneric Mgmt

& Control

Network Environment

TINA Reference Model

• Business Model– Roles/entities & their

relationships while participating in service provisioning

– E.g., consumer, retailer, broker, 3rd party provider, content provider, connectivity provider

• Information Model– Information-bearing

entities– E.g., user and service

profiles• Computational Model

– Computational objects & their relationships

Business

Model

Information

Model

Computational

Model



Applications

ServiceGeneric Mgmt

& Control

Network Environment

Composed Services Under Investigation

• Overlay routing “service”: connectivity and reachability (BGP++: Sharad, Lakshmi, Morley)

• Multicast service: distribution tree formation across administrative domains (Mukund)

• Soft QoS Service: performance constrained connectivity/latency and bandwidth guarantees (Clearinghouse: Chen-nee, Lakshmi)

• Performance monitoring service: distance/latency mapping, load collection/balancing across service instances (Yan)

• Content distribution services: cache/storage resources, distribution/transport resources (Yan, Morley)

Composed Services Under Investigation

Infrastructure Services– Highly available/fast fall-over

services in wide-area (Bhaskar);Fall-back path bandwidth provisioning (Weidong);

– Service instance selection, load-balanced resource sharing;

– Resource allocation/auctions and class-of-service pricing for bandwidth, processing, storage (Weidong & Matt);

– Mobility and cooperation across access networks/device ensembles (Machi)

– Interdomain Authentication & Access Control (Suzuki)

Applications– Content

transformation/format translators; Universal In-Box (Bhaskar)

– H.323 Gateway selection under load & performance constraints (Matt)

– VoIP and bandwidth congestion pricing (Jimmy)

– Smart Spaces/PAN?

SAHARA ArchitectureNetwork 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



Applications

ServiceGeneric Mgmt

& Control

Network Environment

SLAsPerformanceVerification

SAHARA Architecture

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



Applications

ServiceGeneric Mgmt

& Control

Network Environment

SAHARA ArchitectureDistributed Processing:Service 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



Applications

ServiceGeneric Mgmt

& Control

Network Environment

SAHARA ArchitectureApplications– 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



Applications

ServiceGeneric Mgmt

& Control

Network Environment

SAHARA and TINA

• Key Differences– Extreme heterogeneity of spanned networks and resources– Greater awareness and management of underlying network

topology/administrative scopes and affect on services

• Focus on – Cooperative vs. competitive service composition– Resource management via placement, allocation, redirection

to services and resources

• Borrow good parts of TINA– Applications/Distributed Processing/Network Environment– Business models/Information Model/Computation Model

• Understand why TINA failed– Avoid full-blown complexity of TINA

Example: Content Distribution

• Application: Content Delivery– Clients: Subscribers, Publishers

• Services– Distribution network– Content caches (service instances)

• Place caches at selected DCs (service placement)

• Redirect client to “best” cache instance (service redirection)– Based on proximity, load, content

• Service Composition– Broker multi-point distribution paths

between publishers and caches– Add/delete cache instances as client

community grows/shrinks• Brokering at content level among

competing CDNs



Applications

ServiceGeneric Mgmt

& Control

Network Environment

SAHARA Architectural Model

Hardware platform

Service ClustersGateways

Peering RelationsOverlay Network

Logical platform

Application plane

Composed Services


Hardware platform



Logical platform

Application plane

Composed Services

Service SelectionService Placement

Service LocationPerf Measurement

Service Path Creation


Hardware platform



Logical platform

Application plane

Composed Services

Service SelectionService Placement

Service RedirectionPerf Measurement

Load Balancing


Hardware platform



Logical platform

Application plane

Composed Services

Path Determination

Perf MeasurementVerification

Service Brokering


Hardware platform



Logical platform

Application plane

Composed Services

Service DiscoverySLA Negotiation

Perf MeasurementSLA Verification

Service Confederation

Authentication & Authorization Interworking

Mobility Interworking


Hardware platform



Logical platform

Application plane

Composed Services

Service FailureDetection

Service RecoveryPath re-composition

High Availability Services


Hardware platform



Logical platform

Application plane

Composed Services

Service Location

Path OrthogonalityDetermination

High Availability Services


Hardware platform



Logical platform

Application plane

Composed ServicesTranslator

Provisioning andPlacement

Path Determination

Universal In-Box


Hardware platform



Logical platform

Application plane

Composed ServicesCache


Distribution TreeFormation

Content Distribution


Hardware platform



Logical platform

Application plane

Composed ServicesGateway


Packet-to-CircuitTermination

Selection

Voice over IP

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

Discussion

Documents

“Design Review” Randy H. Katz, Anthony Joseph, Ion Stoica Computer Science Division Electrical Engineering and Computer Science Department University of