Appliance Aggregation Research Group Terminology, Survey and Scenarios Ian Taylor, Cardiff University Dimitris 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 DefinitionExamplesNon 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 Scene Linux 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 ADevice B Applications Middleware Services OS, e.g. Mac OS 10 OS, e.g. Windows Transport Protocols JXTA JXME Jini OGSA Blue tooth TCPUDP APP AGG

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 be networked 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 workstations 2. Provide a p2p infrastructure for small devices 3. Be simple and easy to use by developers 4. Be small enough to be used with Cell phones and PDAs 5. Provide a good user experience 6. 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 Constraints Interoperability 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 Applications JXTA Applications JXTA Community Services JXTA Services SUN JXTA Services Indexing Searching File Sharing Peer Groups JXTA Core Any Peer on the extended Web Peer PipesPeer Monitoring Security (authentication, authorization and on the wire) JXTA Shell Peer Commands SUN JXTA 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 Service Jini 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 3 rd 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