Appliance Aggregation Research Group Terminology, Survey and Scenarios Ian Taylor, Cardiff University Dimitris Lioupis, University of Patras Milan Milenkovic,

Appliance Aggregation Research Group

Terminology, Survey and Scenarios

Ian Taylor, Cardiff UniversityDimitris Lioupis, University of

Patras Milan Milenkovic, Intel

Dejan Milojicic, HP Labs

GGF 7, Tokyo, Japan, March 5, 2003

Original Agenda

• Brief intro, Milan Milenkovic & Dejan Milojicic (10m) • Update on the past activities (5m) • Review of the documents

– Terminology (Chairs) (10 m) – Survey (Ian Taylor) (20 m) – Use cases (Dimitris Lioupis) (20 m)

• Open for discussion (20 m) • Planning for the next period (5 m)

Overview

• Setting the Scene– Terminology – Intro to Related Technologies– Appagg Stack

• Existing Technologies– BlueTooth, HAVi, UPnP, and Rendezvous

• Relation to Other Fields– P2P, JXTA, Grid Computing, and Jini

• User Scenarios• Next Steps• Summary

Terminology

Definition Examples Non Examples

Appliance: a device capable to aggregate with other devices - smallest unit of aggregation

camera, PDA, laptop, watch, hotspot

no communication, shared & queued devices

Ensemble: group of appliances aggregated to perform a function greater than their parts

a camera, PDA, and a watch used in concert to capture, annotate, and communicate pictures

a client-server relationship such as a users home PC used to access Yahoo!

Appliance aggregation: illusion of multiple appliances that operate together as a single entity for a period of time

use the screen of another device for display; exe-cute a single application across multiple appliances

execute a distributed algorithm on a work-station cluster; send a document to a printer

•Trust: each ensemble should maintain trust boundaries for its owner

•Data sharing: an ensemble should support sharing of data and content across the ensemble in a sufficiently transparent way

•Application sharing: should be possible to share applications across an ensemble

•Service sharing: it should be possible to share services and functionality across an ensemble, similarly to applications

Terminology, Continued

•Grids: Appagg aggregates resources of personal devices and devices in locale

•P2P: Appagg relies on P2P techniques and the whole aggregation is essentially P2P-centric

•Middleware: Appagg is middleware – provides the layer between operating system and applications

Related Technologies

Appliance Aggregation: Setting the SceneLinux

•Connect devices in a simple & coherent fashion into ensembles

•A common model of ownership, shared state, apps, & functionality

•Easier control over appliances, transparent synchronization of data & continuous access to apps and functionality from any appliance

Appliance Aggregation Stack

Network

Device A Device B

Applications

Middleware Services

OS, e.g.Mac OS 10

OS, e.g.Windows

TransportProtocols

JXTAJXME

Jini

OGSA

Bluetooth TCP UDP

APPAGG

Existing Technologies

• BlueTooth• HAVi• UPnP• Rendezvous

• Short-range radio technology aimed at simplifying • communications between devices and Internet• data synchronization

• Bluetooth products must pass interoperability test by Bluetooth Special Interest Group

• Bluetooth 1.0 specification consists of two documents: • Foundation Core - provides design specifications• Foundation Profile - provides interoperability guidelines

• Bluetooth contains link and application layer definitions supporting data, voice, and content-centric apps

• Up to seven simultaneous connections can be established

Bluetooth

• Sony HAVi - short for Home Audio Video interoperability

• Vendor-neutral audio-video standard• Aimed specifically at home entertainment

environment: VCR, TV, stereo, security system, video monitors

• Home entertainment & communication devices can benetworked and controlled from a device (eg PC or TV)

• IEEE 1394 (Firewire) for connectivity – up to 800Mbps

HAVi

• Standard based on Internet and Web protocols to •enable devices to be plugged into a network and •automatically know about each other

• Target: PC, peripherals, intelligent appliances, & wireless

• When a user plugs a device into the network, • the device will configure itself•acquire a TCP/IP address•announce its presence on network to other devices

• E.g.: send a picture from digital camera directly to printer

•camera issues a "discover" request for any printer•printer identifies itself and send its location (URL)•camera & printer negotiate protocol & capabilities

(XML)•camera controls printer & print photograph you

selected

UPnP

•Networking technology by Apple for •automatic creation of ad-hoc network of computers and devices

•discovering the services available on them•Enable sharing of files, content, printers, and other devices

•E.g: enables discovery, network integration, setup and administration of router, webcam, printer, and laptop

•Works in the following way•When a device is added to a network (with no DHCP) Rendezvous configures it using link-local addressing

•Link-local addressing randomly selects an IP address from a predefined range and assigns it o the new device

•It verifies if address is used by any other device• Process is repeated until an unused address is found

Rendezvous

Relation to other Technologies

• P2P File Sharing• JXTA• Grid Computing• Jini

• Lessons learned from file sharing• Stanley Milgram social networking –

make Appagg networks utilize the “small world” effect ?

• KaZaA, Morpheus, Limewire utilize this• based on a centralized-decentralized structure

Relation to P2P

• Role of JXTA JXME?• A lightweight JXTA implementation for mobile

devices that could be used to run on appliances• JXME Goals

1. Be interoperable with JXTA on desktops and workstations2. Provide a p2p infrastructure for small devices3. Be simple and easy to use by developers4. Be small enough to be used with Cell phones and PDAs5. Provide a good user experience6. Be CLDC-1.0 and MIDP-1.0 compliant

JXTA

What is JXTA ?• A short for juxtapose, as in “side by side”,

juxtaposed to client-server or Web-based computing

• A set of open, generalized P2P protocols allowing any connected device to communicate and collaborate:

• discovery, resolver, information, pipe binding, endpoint routing & rendezvous

• Designed as a set of building blocks to allow developers to rapidly develop P2P applications

• Designed to have a peer-to-peer, decentralized model (also supports traditional client/centralized server)

• As in Gnutella, every JXTA peer can be both a client and a server

JXTA Design ConstraintsInteroperability•SW vendors tend to create specific code for their services e.g. file sharing, instant messaging, resulting in • incompatible systems i.e. not able to interoperate •vendor-specific P2P user communities•duplicate effort in software and system primitives

• JXTA attempts to fit in by giving peers a common language to talk to each other

Platform independence, designed to be independent of:•programming languages e.g. C or Java•system platforms e.g. Microsoft Windows and UNIX•networking platforms (such as TCP/IP or Bluetooth)

Ubiquity•implementable on every device with a digital heartbeat

•most current are limited certain platforms (Wintel…) •extendable to new platforms e.g. mobile phones using J2ME

JXTA Community ApplicationsJXTAApplications

JXTA Community Services

JXTAServices

SUNJXTAServices

• Indexing• Searching• File Sharing

Peer GroupsJXTACore

Any Peer on the extended Web

Peer Pipes Peer Monitoring

Security (authentication, authorization and on the wire)

JXTAShell

PeerCommands

SUNJXTA

Applications

JXTA Architecture

• Grids have infrastructure- v. Appagg’s client-focus• Grids focus on aggregation of geographically

distributed computation, storage and services • Appagg focus on personal and environment appliances

in local• Potential leverage of security/trust & resource

aggregation• OGSA-P2P natural link to Grids

Grid Computing

What is Jini?

Historically, operating systems rely on disk drives …

•Written in Java•Builds on Java, object serialization, and RMI to enable Java objects to move around the network

•Offers network plug and play of services (java objects)

•Allows devices to dynamically establish communication to share and exchange services across a network

• Provides mechanisms to enable devices to plug together to form an impromptu community

Jini’s goal is to shift this reliance back to the network

Key Features:

• Jini defines a runtime infrastructure that enable you to add, remove, locate, and access services

•There are three main players

… and the network connecting all three - generally be running TCP/IP

a service, e.g printer, scanner, storage device, software service etc.

a client which would like to make use of this service.

a lookup service (LUS) - a service locator

Jini Players

the network (TCP/IP)

Jini ServiceJini Client (Consumer)

LUS – Lookup Service

1. Jini service discovers LUS and registers its service

2. Jini client discovers LUS to locate the desired Jini service

4. Jini client uses proxy to contact Jini service directly

Jini In Action: Broad Overview

3. Jini client receives Java proxy for Jini Service

Scenarios

• A Day in the Office• On the way to Work• A Day in Hospital

• Visitors arrival alerts Bill in the office• As they enter room, lights turns on• Bill’s watch identity brings in his virtual desktop • Projectors turns on from the desktop, lights turn off• Voice command to connect other colleagues by

phone

Scenario 1, A Day in the Office

Scenario 2, On the way to Work

• Using his PDA Mr. Smith decides whether to go by car or by train (local inquiry, sensors on roads report on traffic)

• Loads daily news from the nearby kiosks• Alerts about the stocks, based on his identity• Download advertisements from the displays in metro• Act upon stocks while walking to the office

• Doctor access patient’s history using personal appliance• Brings up the pictures from a display device to another• Medicine on stock get checked before prescription is

issued• Emergency triggers nearby doctor, using his appliance• His appliance initiates new machinery and …• … results get displayed back on a set of room displays

Scenario 3, A Day in Hospital

Summary

• Presented– Terminology– Survey– Scenarios

• Missing– Introduce security considerations (required in any GGF

doc)– Review by the group and improve the document– Architectural description of Appagg components & layers

Original Agenda

• Brief intro, Milan Milenkovic & Dejan Milojicic (10m) • Update on the past activities (5m) • Review of the documents

– Terminology (Chairs) (10 m) – Survey (Ian Taylor) (20 m) – Use cases (Dimitris Lioupis) (20 m)

• Open for discussion (20 m) • Planning for the next period (5 m)

Next steps

• 1 month reviewing the document• 3rd week of June Seattle, -2 weeks for document

submitted as a draft– Case studies by Intel (Milan messenger)– Demo something, Chicago (?)– Apple (rendezvous)– Interoperability (long time), power of aggregation– Visionaries of ubiquitous computing– Awareness of general area of pervasive/ubiquitous computing

• Security• Demos at GGF9? October