Internet Engineering Task Force Simon Tsang Internet Draft Stan Moyer draft-tsang-appliances-discuss-00.txt Dave Marples February, 2001 Telcordia Technologies, Inc Expires: August, 2001 Henning Schulzrinne Columbia University Arjun Roychowdhury Hughes Software Systems Internet Personal Appliances Control (IPAC) Discussion STATUS OF THIS MEMO This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Comments should be submitted to the appliances@research.telcordia.com mailing list. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as work in progress. The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document introduces the concept of the Internet Personal Appliance (IPA) and the relationships between it and control entities in the Internet for command and control, and communication purposes. Within this document a number of issues to be addressed in the area of IPAs are outlined. This document is not intended to be an exhaustive treatment of all of these issues, but merely to introduce them for discussion in the widest possible context of using Internet protocols to communicate with small computation and I/O devices. Comments on this document should be directed to the appliances mailing list: appliances@research.telcordia.com. S. Tsang et al [Page 1] Internet Draft IPAC Discussion February 2001 1. IPAC Overview 1.1. What Are Internet Personal Appliances (IPAs)? The definition of an IPA is difficult in that the exact limitations of applicability of the term are poorly defined. The authors consider simple, dedicated purpose, limited configuration, devices such as washing machines, refrigerators, lamps, and televisions as IPAs. Other devices such as personal computers (PCs), workstations, and personal digital assistants (PDAs) have much more general applicability and higher levels of configurability and are normally considered as computational devices. These would not meet the definition of an IPA. Devices such as Digital Cameras and MP3 players are in the ægrey spaceÆ between an IPA and general purpose device. Of course, there is no reason why general computation devices cannot use the capabilities that are defined for IPAs, but it is important to design for the IPA target. We consider that Internet Personal Appliances (IPAs) are networked devices which have the following characteristics: 1) Dedicated functionality with limited configurability and optimized user interface - an Internet connected Calculator might be considered an IPA, a Palm Pilot running a calculator application would not. 2) The ability to interact with the physical environment through sensors and actuators; thus, a Network Attached Storage (NAS) device would not be considered an IPA. 3) Limited (or restricted) general purpose computational power, though the devices may possess high-computation power for specific tasks such as image processing, or audio processing as in the case of an MP3 player. In general, IPAs will be devices with sensors and/or actuators with limited computational power, but they will always have some form of permanent or temporary network connectivity. IPAs may be portable and may provide service in multiple locations. Some may be mobile and may provide service while stationary or in transit. Note that these portability and mobility issues may introduce new constraints or novel operational modes for specific IPAs - a typical example might be a MP3 player capable of relaying an Internet Radio Station while stationary and network connected, but only being able to play cached content when mobile without any network connection. Note that IPAs are also known as networked appliances, Internet appliances, IP appliances, and networked devices. In the following, we will only discuss the computational and network capabilities of IPAs and ignore their interaction with the physical environment. S. Tsang et al [Page 2] Internet Draft IPAC Discussion February 2001 1.2. Where Is the Intelligence? The capabilities of IPAs span a wide range, from æfatÆ IPAs, which contain sufficient processing power and memory to operate stand-alone (and perhaps only require network connectivity to collect new content or to enhance their own functionality), to æthinÆ IPAs which can only operate with the aid of another network-attached host. We will consider the extremes of this range in order to illustrate the kinds of IPA support that may be required. A fat IPA comprises a network interface, computational capabilities, embedded software, and I/O. The network interface is required for communication with the Internet. The software allows the IPA to operate autonomously, providing a degree of independence from other devices, the network, and the æintelligenceÆ for the device. It may provide its own local or networked user interface, such as a web server. Furthermore, the embedded software allows the IPA to interact with other IPAs or applications through the network interface. I/O enables the IPA to interact with its environment through actuators and sensors. This is illustrated in Figure 1. IPA = [network interface][application control][I/O control] Figure 1: Anatomy of a fat IPA Figure 2 shows the modes of operation for this autonomous IPA. It can communicate as a peer with applications and with other IPAs. This may be likened to application/application interaction and collaboration. (peer-to-peer) Application <-----> IPA (peer-to-peer) IPA <-----> IPA Figure 2: Modes of operation for a fat IPA A thin IPA (see Figure 3) comprises the same elements as its fat counterpart but the application is reduced to the absolute minimum necessary to marshal its I/O capabilities and to allow it to connect to real application functionality provided outside of it. Thin IPA = [network interface][I/O control] Figure 3: Anatomy of a thin IPA S. Tsang et al [Page 3] Internet Draft IPAC Discussion February 2001 Figure 4 shows the modes of operation for the thin IPA. Since it does not offer application level functionality, all intelligence is provided outside of the IPA, normally by a proxy function. The IPA executes the commands requested by the proxy. (client-server) Proxy Application -----> Thin IPA (peer-to-peer) (client-server) Application -----> Proxy Application ----> Dumb IPA Figure 4: Modes of operation for thin IPA. 1.3. How Do We Want to Interact with IPAs? We (people, applications, and other IPAs) will need to interact with IPAs in many ways. The main reason for interacting with an IPA is to request a service that the IPA provides. This service could be: - the type of function for which the IPA was primarily designed, e.g., ætoast the breadÆ, æmake the coffeeÆ, æturn on the lightÆ, æset the temperatureÆ, ætalk with the desired userÆ etc. - reporting the status or state of the IPA, e.g., æwhat's the temperature?Æ, æis the light on?Æ, æare there any intruders?Æ, etc. - a function for which the device was not primarily designed, but capable of anyway, e.g., using a stereo system for a network-based alarm clock, displaying a text message/page on a microwave display. These types of interactions are at the application layer. To request an IPA service, we don't need to know the IP address (or DNS name) of the IPA, but rather the service name. Note that the service name may include a DNS name as part of the name. This is analogous to a web page URL. As discussed in the previous sections, people may interact directly with an IPA, for example, through an application on a PC. Interactions with IPAs may be automated by host-based applications that reside either in the network or at the edge of the network. These host-based applications could be services offered to IPA owners. In addition, IPAs may interact with each other. For example, the alarm clock could turn on the coffee maker or a rain sensor turn off the lawn sprinkler system. Since not all interactions will be with human operators, the ability to interact with IPAs in a æmachine-friendlyÆ manner is necessary. Thus, simply providing a web page interface to IPAs is not likely to be sufficient. The type of communication used when interacting with IPAs will differ depending on the type of service/application. Some examples are: S. Tsang et al [Page 4] Internet Draft IPAC Discussion February 2001 - Control of an IPA, e.g., æturn off the light(s)Æ. This type of interaction implies a simple control message sequence - send a command and get a response back. - Queries to an IPA, e.g., æis there milk in the refrigeratorÆ or æwhat's the temperature?Æ This type of interaction also implies a simple message sequence - send a query receive a reply. - Notification of an event occurring at an IPA, e.g., ænotify me when the security alarm goes offÆ or ænotify me when someone rings the doorbellÆ. This type of interaction will probably require an event- based communication mechanism. - Media streaming (or sessions), e.g, æview the front door cameraÆ or ætalk with Bob (on the phone)Æ. Supporting media streaming will most likely require some sort of mechanism for establishing sessions (e.g., negotiating participants, transport parameters, media types, etc.). Protocols that support these different types of communication paradigms will need to be implemented in IPAs and/or IPA controllers and interworking units. 1.4. Where Will IPAs Be Found? At a minimum, IPAs require access to the Internet in order to operate and can be located wherever network connectivity is available. In particular, home networking [2-4,6] and the increasing interest in providing internet access in automobiles makes it likely that homes and automobiles are likely locations for IPAs. In addition, IPAs may visit networks other than their own. We describe each environment in turn. 1.4.1 The Home Environment (HE) Many IPAs will be household items (such as refrigerators, televisions, AC units, or lamps) and will thus reside within a home environment (HE). The HE is essentially a private LAN with network layer access to the Internet through a device such as a Residential Gateway (RGW). The RGW may include firewall and/or network address translator (NAT) functionality, effectively partitioning the HE from the rest of the Internet. NAT and firewalls aim to achieve security, privacy and IP address conservation. IPAs will use IP at the network layer for packet communication within the HE. There will be many appliances that are based on existing home networking technologies [2-4,6]. These devices will frequently not be IP capable [6] and will require an Interworking Unit (IWU) to provide network layer interworking (IP). This is illustrated in Figure 5. S. Tsang et al [Page 5] Internet Draft IPAC Discussion February 2001 The IWU may also be an appropriate point to provide transport and application layer interworking and proxying. (Home Environment) || (non-IP home network) IPA <--------------> IWU <--> non-IP home network Figure 5: Home Environment with non-IP appliances 1.4.2 Automobile Environment (AE) Many IPAs will be used within an automobile environment (AE). Although the AE may be very different from the HE, it is assumed that at the network layer and above there will be no fundamental differences. The authors therefore consider that in the automobile environment, the communication between IPAs and applications will be the same as in the HE, but with additional limitations introduced by connectivity issues; for example, the car might go through a tunnel and thus suddenly or temporarily lose network connectivity. 1.4.3 Visited Domains Given that IPAs are personal devices and many will be portable, it is likely that users will wish to take them wherever they go. For example, consider an Internet alarm clock which checks a userÆs Internet-based calendar and preferences. It would be convenient for the Internet alarm clock user to keep their IPA with them so that they will continue to be reminded of meetings, social events, and woken up at appropriate times. The visited domain may be another HE or automobile environment, for example. This opens the possibility that an IPA may be deployed into a domain which is owned or administered by another party. The problems of access to a device installed into such a network needs to be investigated, especially with respect to the requirements that such a device may impose upon the network in which it is installed (for example, it may require more expensive QoS capabilities than the network would by default provide). 2. General Issues 2.1. Who Owns the IPA? The ownership relationship between IPAs in the home domain is unclear. The simplest solution is for the responsible authority for the domain to have administrative control for it and to control all of the devices within it, but this will potentially require a significant level of administration. S. Tsang et al [Page 6] Internet Draft IPAC Discussion February 2001 Several questions in this area remain open: 1) Subcontract and rental arrangements û how can transitory ownership relationships be modeled and accommodated? 2) Access to owned devices in a non-owned domain. 3) Impact of non-owned devices on the operation of the owned environment in which it operates. 4) Responsibility for maintenance of non-owned IPAs in an owned network. 2.2. Information Privacy Issues All communication between IPAs should be secure so that no unauthorized parties can eavesdrop on the messages to glean any information about the (type of) IPAs and what is being done with them. The implication of this requirement is that not only does the payload (i.e., requested actions/queries) of the communications need to be protected, but also the name(s) of the IPAs may need to somehow be obfuscated. Further, the release of information contained on an IPA is subject to preferences that the owner of the IPA selects. Techniques need to be developed to describe the privacy and security restrictions that the user wishes to place upon this data. 3. IPA Issues 3.1. Connectivity Issues 3.1.1 Network Connectivity Appliances could be connected to the Internet through network level services (IPv4 or IPv6) or through some application controller (or interworking unit) that resides in the same premises. Each of these solutions brings its own problems: - IPv4: Typically with IPv4, there will not be enough addresses for every IPA. IPAs will thus need to go through a network address translator (NAT) and the NAT will have to configured for incoming requests. - IPv6: With IPv6, there will be enough addresses, but not enough networks (yet). As this situation changes, IPAs will need to go through an IPv6 IWU if not IPv6 native. - Application relay: This approach is typically not transparent, and encourages stove-piping. Network connectivity problems can be solved by finding a way to resolve limitations, such as techniques for providing a large number S. Tsang et al [Page 7] Internet Draft IPAC Discussion February 2001 of IPv4 addresses, or applying techniques for actually deploying IPv6. Alternatively, it may be more suitable to simply cope with the limitations through techniques such as designing applications that only use the outgoing TCP connections that NAT and firewalls support. 3.1.2 Issues With Thin and Fat IPAs IPAs differ significantly in their requirements for network availability and QoS. It is often asserted that, because they are less programmable, it is easier for external parties (other than the owner) to trust thin clients. Yet, the AT&T DOSA architecture makes the argument that, since the client is in the user premises (e.g. a residential gateway for DOSA), then that client cannot be trusted, no matter how limited its programmability is. 3.1.3 Intermittent Access Some devices may only be able to communicate intermittently, e.g., because their batteries are dead. In the automobile environment (AE), devices that may be continuously reachable at home, may suddenly show intermittent reachability due to power being turned off or network connectivity being interrupted. 3.2. Security Issues 3.2.1 Trust Zones and Domains of Control What trust will the user place on the appliance and appliance provider when the provider/seller retains some access to the appliance while it is in the userÆs domain? For instance, the washing machine seller might be able to access the washing machine to detect when it breaks, or the insurance company might want to access the smoke detectors. Does the person trust that these devices don't also contain microphones to record what happens in the house? Or, more likely, that the washing machine doesn't report back incoming hot water temperature so that the seller can offer a larger water heater based on having seen not-so-hot water in the past? Will all personal appliances within one domain (e.g., behind one RGW) trust each other? How does that relate to different entities having different levels of access and control of different devices? (Do I really want the company I lease the washing machine from be able to tell what movies I'm watching or what is in my refrigerator?) All of these examples motivate the need to authenticate and authorize each message to an IPA. IPAs may have different levels of trust and belong to different domains of control. Therefore, the originator of each communication with an IPA must be determined and the requested S. Tsang et al [Page 8] Internet Draft IPAC Discussion February 2001 action checked to verify that the requestor has permission to perform that action. 3.2.2 Authentication of IPAs In some cases, devices may need to be authenticated, particularly for sensors. For example, spoofing the output of alarm sensors may allow intruders to foil a home alarm monitoring system. 3.2.3 Privacy Messages sent to and from IPAs may reveal intimate details about a personÆs actions and behaviors. Thus, they need to be protected from interception by third parties. In some cases, even the act of communicating with a particular home or device may reveal information that a user considers private. 3.3. Operational Issues 3.3.1 Configuration and Provisioning The issues of provisioning appliances in a multiple-appliance environment may be considerable. A device needs to be associated with its owner or user. In addition, the limited human interface capabilities of the device may mean that an additional entity needs to be used to configure or control it. For example, an alarm clock may be configured through a web interface rather than scrolling through time settings. 3.3.2 Billing In some deployment scenarios, systems may need to be developed to allow users to be billed for services. However, this is not likely to be a subject for IETF standardization or concern, beyond providing suitable AAA mechanism. 3.3.3 Faults and Remote Diagnosis Fault diagnosis, fault control and resolution need to be investigated. Since IPAs interact with each other, an IPA may appear to behave incorrectly, even though the fault lies with another IPA. Thus, it must be possible to diagnose individual IPAs as well as observe their interaction. 3.3.4 Distributed Agreements Servers will provide reliable repositories for data. This data includes user profile, service data, bank balances, etc. Fat IPAs may cache data. Consider (for example) a PC phone (IP phone) user whose cache resides on the phone, and (s)he migrates the call to a cell phone, perhaps wanting to walk out of the office while continuing the S. Tsang et al [Page 9] Internet Draft IPAC Discussion February 2001 call. In this case either the cache has to migrate (based on the capability of the new device) or user queries have to go to another server/cache. A management system for synchronization and migration of data will be needed in this circumstance. Synchronization is needed for cache validation/invalidation. Devices disconnected from the network will contain newer versions of the data. For instance, updating data while on an airplane or updating data locally due to intermittent or slow connection. User data could be updated in the server when the user is disconnected. Upon re-connect the network/server, all data should be made consistent. Distributed database techniques such as two-phase commits are not suitable for distributed agreement in a disconnected network. Two- phase commit is extremely slow and conservative especially in cases on disconnected systems. What is needed is application and service specific agreement for a network of intermittently connected 'databases'. 3.3.5 Restricted I/O A management system has to handle unreliable, slow messaging as well as limited capabilities to provide an acceptable service environment. For example, the presentation layer may present a different view based on device capability and connectivity. 3.3.6 Multiplicity The number of IPAs may well exceed the current number of ætraditionalÆ networked devices such as hosts and routers. It remains to be investigated how well traditional network management approaches scale to such environments, in particular where these devices are not externally reachable and may change network addresses. 3.3.7 Initial Deployment Can we deploy appliances? In order to connect appliances to the network, we need to invest in a connection device, such as a residential gateway or a set-top box whose price may well exceed the price of the appliance itself. There are a few options for reducing the initial investment for the end user: 1) Provide an inexpensive direct connection to an existing network. This is the approach in the e-book (modem) and in the Palm VII (wireless). 2) Reuse an existing computing device as a hub, such as the home PC. This is the approach chosen by RIO, and by Palm IIIs and Vs. 4) Get someone, such as a network provider, to fund the platform deployment. This approach is common in the CATV industry. S. Tsang et al [Page 10] Internet Draft IPAC Discussion February 2001 3.3.8 Decomposition of IPAs An IPA is generally composed of an I/O component, of a logic component and of a storage component. There are three broad ways to deploy services between an appliance and network-based servers: - Everything in same place: autonomy, high security. - Storage in the network: data sharing. In some circumstance, performance, reliability. - Application in the network: reduced network bandwidth if lots of data transactions. New services can be deployed from within the network. Less power in I/O device, improves portability, reduces price. 4. IPAC Problem Statement Given the issues highlighted in the previous sections, it is clear that there is a need within the IETF to understand the issues surrounding IPA application control, and to define a framework for IPA service-layer communication which takes these issues into consideration. This work should also identify or define protocols which will enable control of service layer communication with IPAs from the Internet. In particular, the following issues need to be resolved: - Service layer naming and addressing for IPAs. - IPA service and application discovery and registration mechanisms. - Application security for IPAs. - Service/Application layer protocols for IPA communications. 5. Relation to IETF Working Groups and Other Organizations IETF ZeroConf Working Group As stated in section 1.3, we are concerned with interactions with IPAs at the services layer. To enable services layer communication, network layer communication must first be established. Therefore, for the purpose of this document, we assume that all IP-layer networking (e.g., address assignment, DNS configuration, etc.) has been configured. This could be done either manually or automatically, using existing tools such as DHCP or server-less mechanisms as are being discussed in the ZeroConf WG). OSGi The Open Services Gateway initiative seeks to define the Application Programming Interfaces (APIs) of a service execution platform that interfaces the many wide area networking protocol standards with the different in-home networking protocols. As such, an OSGi gateway S. Tsang et al [Page 11] Internet Draft IPAC Discussion February 2001 becomes an integral component in IPA communication but does not provide any functionality to enable this communication. Functionality could be deployed on an OSGi gateway that facilitates this communication and in fact that is the charter of a new Interest Group with OSGi on ædevice excitation.Æ This is a newly formed group and nothing has been agreed upon yet. However, even if a mechanism is created to enable communication with IPAs behind an OSGi gateway, the solution will be OSGi gateway-based and require the existence of a gateway. This is a restriction for the general case deployment of IPAs. UPnP The Universal Plug and Play (UPnP) forum provides a framework and a set of open interfaces for controlling appliances within the home. UPnP proposes a set of application and session layer protocols built over TCP/IP. These protocols provide device discovery and control. UPnP uses HTTP for transporting its control messages. Salutation Salutation enables the broadcast and discovery of services provided by IPAs, but it does not provide for command and control type communication with IPAs. The service information provided by Salutation protocols is necessary and useful for IPA services and applications, but is only solving part of the puzzle. 6. Some Service Examples Finally, this section provides some brief (high-level) service examples which illustrate how the capability for controlling IPAs over the internet may be used. 6.1. Power Management With the increasing demand for power consumption (particularly in North America), and dwindling natural resources, there is a clear need for intelligent power management. This may take two forms (or a combination of the two): (1) centralized power management, by the utility company for example, and (2) in-home power management by the appliances themselves. 1) Centralized power management The utility company is aware of two key facets of information: the available power for a particular area or region, and the power demands placed by consumersÆ homes and appliances. Based on this information, the utility company could turn on or off appliances within consumerÆs homes to reduce the demand. Of course, this capability must be exercised as part of a service level contract with the consumer. The consumer may register high and low priority appliances to control what stays on during peak demand periods. Fundamentally, this service example requires that the utility company S. Tsang et al [Page 12] Internet Draft IPAC Discussion February 2001 can query and control the status of appliances within the home securely from the internet. 2) In-home power management Another approach is to have the appliances intelligently control their power consumption. For example, numerous sensors within the home could be used to detect the presence of people and pets. If there is no presence detected, the sensors will send commands to the appliances within their vicinity to switch to stand-by mode. Once a presence is detected, the sensors will command the same appliances to revert to æonÆ mode. Users may choose to have such a service provided and managed remotely by a third party provider. In this case, the ability to query and control appliances within the home securely from the internet is required. 6.2. Security Management Home security is another important issue in people's lives today, particularly as we spend so much time either traveling or working at other locations. Therefore, it may be useful to maintain a ævirtualÆ presence within the home, and be able to monitor who approaches or enters the home. This could be achieved by placing sensors (e.g. motion or heat) around the home to detect approaching visitors, and strategically mounting cameras with streaming media capabilities. Whenever someone approaches or enters the home, the sensors will alert the user wherever they may be. The alert will be sent securely over the internet and will be rendered according to the userÆs preferences and devices at hand. The alert may take the form of a message on a PC, a PDA pop-up, a telephone ring, lights flashing on and off, etc. Once alerted, the user may choose to set up a streaming video session to one or all of the cameras in their home to assess the threat, and choose an appropriate course of action. Again, this service may be provided and managed by a third party provider. In all cases, the ability to query and control appliances within the home, and set up media sessions is required. Furthermore it must be possible to do this securely from the internet. 7. Acknowledgements The authors wish to gratefully acknowledge the ideas, comments and suggestions provided by Erik Nordmark and Thomas Narten during the writing of this document. 8. References S. Tsang et al [Page 13] Internet Draft IPAC Discussion February 2001 [1] OSGi, http://www.osgi.org [2] HAVi, http://www.havi.org [3] æVHN Home Network,Æ EIA 851, Version 1, to be released 4Q00, See http://www.vesa.org for further information. [4] UPnP, http://www.upnp.org [5] Jini, http://www.jini.org [6] X.10, http://www.x10.org [7] Bluetooth, http://www.bluetooth.com [8] Salutation, http://www.salutation.org 9. Acronyms 802.11 Wireless LAN networking technology. Bluetooth Wireless technology for networked devices. Domain An administrative IP domain. HAVi Home Audio Video Interoperability: A consortium of audio-visual electronics manufacturers who have developed a common, openly-licensable specification for networking digital home entertainment products. HE Home Environment IPA Internet Personal Appliance (see NA) Jini Java based device connectivity and discovery framework. NA Networked Appliance: A dedicated function consumer devices containing at least one networked processor. NAS Network Attached Storage. NAT Network Address Translator. OSGi Open Services Gateway initiative: An industry group working to define and promote an open standard for connecting smart consumer and small business appliances with commercial internet services. PDA Personal Digital Assistant RGW Residential Gateway: Point of networking and control access to/from a home environment. The RGW may contain additional functions, such as firewalls and NATs. Salutation An open service discovery and session management protocol developed by the Salutation Consortium. UPnP Universal Plug and Play: An open architecture for connectivity of PCs of all form factors, intelligent appliances, and wireless devices. VHN Video Electronics Standards Association (VESA) Home Networking: Networking and control for video appliances developed by the VESA consortium. X.10 Early power line based home networking technology. 10. Author's Contacts Simon Tsang S. Tsang et al [Page 14] Internet Draft IPAC Discussion February 2001 Telcordia Technologies 445 South Street MCC 1A 264R Morristown, NJ 07960, USA. e-mail: stsang@research.telcordia.com Stan Moyer Telcordia Technologies 445 South Street MCC 1A-238R Morristown, NJ 07960, USA. e-mail: stanm@research.telcordia.com Dave Marples Telcordia Technologies 445 South Street MCC 1J-226B Morristown, NJ 07960, USA. e-mail: dmarples@research.telcordia.com Henning Schulzrinne Department of Computer Science Columbia University M/S 0401 1214 Amsterdam Avenue New York, NY 10027-7003, USA. e-mail: hgs@cs.columbia.edu Arjun Roychowdhury Hughes Software Systems Prestige Opal 146 Infantry Road Bangalore 560001, India. e-mail: archow@hss.hns.com S. Tsang et al [Page 15]