Internet Engineering Task Force Sumit Khurana Internet Draft Provin Gurung draft-khurana-dmp-appliances-00.txt Ashutosh Dutta Telcordia Technologies, Inc Expires: May, 2001 November, 2000 Device Message Protocol (DMP): An XML based format for Wide Area Communication with Networked Appliances 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 A variety of technologies are available to network appliances and provide home automation and control. However, these do not support wide-area access control and interworking of these Networked Appliances (NA). This document describes an XML based data format for conveying information pertaining to control, query and event notification functionality to Networked Appliances. 1 Introduction There are numerous technologies for networking and controlling appliances within a home. Some examples are X.10 [6], HAVi [1], VHN [2], and UPnP [3]. However, there is currently no support for wide- Khurana et al [Page 1] Internet Draft Device Message Protocol(DMP) November 2000 area access communication or control of these Networked Appliances (NAs) from the Internet, or for interworking the various home networking technologies. The ability to provide such support will radically enhance the ability to provide exciting new services [8,9]. This document defines an XML based format, the Device Message Protocol (DMP),for conveying information pertaining to control, query and event subscription and notification functionality to networked appliances. The data format defined, captures all the requirements for communicating with networked appliances described in [9]. DMP is intended to be carried as the body of the SIP, DO method, defined in [11] or the SUBSCRIBE, NOTIFY methods defined in [12]. However, no assumptions are made on the encapsulating protocol, therefore, any protocol, which supports MIME types, such as HTTP, may also be valid for carrying DMP messages. When a message carries a DMP payload, the MIME type should be set to "application/dmp". 2 Overview Mechanisms are required for communicating with NAs to 1. Invoke control actions, e.g. to switch on the heater in the bedroom; 2. For querying devices, e.g. to determine the temperature in the house; 3. For event notification, e.g. to receive notification if the temperature in the house falls below freezing point. 4. There is also a need for returning status information associated with the success or failure of each of these actions. Other communication needs identified in [9] include support for mobility and for initiation of multimedia sessions. This document defines an XML based format for conveying information pertaining to control, query and event subscription and notification functionality to networked appliances. The major design goals for DMP are flexibility and extensibility. Different devices will have varying functionality. In fact, Networked Appliances are defined as special purpose devices with a networked processor. For example, a cassette recorder has a play and record function, whereas a refrigerator has a thermostat setting. Moreover, similar devices manufactured by different companies will have varying features and capabilities. DMP is independent of functionality associated with a specific device or a class of devices. Instead, it defines a minimal set of functions specifically for communicating with networked appliances and a corresponding framework within which actions associated with specific devices must be cast. 2.1 Relationship with Wide Area Device Discovery and Device Description Khurana et al [Page 2] Internet Draft Device Message Protocol(DMP) November 2000 The capabilities and services offered by a device may not be known a-priori to a client. Moreover, the list of devices that are accessible for use (with proper authorization), within a domain, for example the user's home, may also not be known. The lack of a-priori knowledge of accessible services offered by a device makes the problem different from the approach used in the Service Location Protocol[13], where the client poses a query to determine a server that offers a specific service. In the case of networked appliances, a user may want to take a set of actions based on what devices are present and the set of capabilities that they offer. For example, a) switch on the music and dim the lights if they can be dimmed, or, b) Find devices in a hotel room and render the alarm clock service on one of the devices, according to say, the capabilities of the telephone, stereo or television. Mechanisms must thus be provided to enable clients to discover accessible devices and their associated services. 1. Configuration or provisioning of trusted clients with a list of devices and their capabilities, 2. Extending Subscribe/ Notify to have a proxy for the devices, for example a residential gateway, inform the subscribed clients of the capabilities and existence of devices when they come up, register or start offering additional services, or 3. An explicit discovery mechanism, wherein a client explicitly queries a proxy in order to determine the list of devices and/ or the devices' capabilities are possible mechanisms. One or more of the above may be used based on the application and the problem domain. SIP methods for, SUBSCRIBE and NOTIFY, and OPTIONS are applicable for mechanisms 2 and 3 above respectively. The OPTIONS method, which is used to query server capabilities, used with a new MIME type for device description and discovery, is appropriate for wide area control. Discovery mechanisms and device descriptions will be addressed in a companion document describing the Device Description Protocol (DDP), which will also be an XML based format. DMP makes no assumptions on the precise discovery mechanism used to find devices and their capabilities. The only assumption is that a set of devices and their associated capabilities are known to the wide area client. The question of discovery is not addressed further in this document. 2.2 Scope The scope of DMP is limited to actions specific to communicating with NAs. Other actions such as initiating a multi-media session, which may also be applicable for communicating with NAs, but have much wider scale applicability, are not addressed by DMP. Existing mechanisms should be used for such needs. The data format defined uses XML (eXtensible Markup Language)[10]. XML provides flexibility and extensibility that DMP requires, for supporting existing and future devices and services. The data format is similar and complimentary to the XML formats defined by the UP&P forum in the UP&P Device Architecture[4]. Device specific functionality and services can be captured using the XML schema Khurana et al [Page 3] Internet Draft Device Message Protocol(DMP) November 2000 defined by the UP&P forum Device Descriptions and cast in the framework defined by DMP for wide area communication with NAs. DDP and DMP, follow a minimalist approach, as exposing detailed descriptions for devices will neither scale well nor will be appropriate for security reasons when used for the wide area. Only a subset of devices within a home and a subset of the complete device capabilities are likely to be made available for wide area access. Moreover, the scope of the actions taken is not necessarily limited to a single device. Devices that use X.10, UP&P and other technologies within the home may not be SIP enabled. Protocol translators are required to enable communication between the SIP User Agent that understands DMP and acts on the device's behalf and the physical device to execute the DMP control actions. The initial application of DMP is intended as constituting the message body of the SIP, DO methods for control actions, and of the SUBSCRIBE/NOTIFY methods when used for event notification for NAs. 3. Core Components of Wide Area Device Communication The core components of wide area device communication are Control, Query and Event notification. The requirements and scenarios associated with these actions are as follows Control 1. Control one function on a device. For example, switch on the lamp. 2. Control in parallel more than one function on a device. For example, set the temperature on the AC to cooler and open itÆs vent. 3. Control in sequence more than one function on a device. For example, tilt the camera and then focus it. 4. Control a class of devices. For example, switch on all ACs in the home. 5. Control more than one device to execute one user action. For example, close the windows and switch on the AC. Query 1. Query a single state variable on a device. For example, get the temperature setting in the bedroom. 2. Query a set of state variables associated with a single device. For example, get the volume, balance and fade settings on the stereo audio player. 3. Query a class of devices. For example, get the status of all lamps in the house. Events 1. Subscribe to an event on a device where an event is defined as change in state of a variable. For example, inform me, if the temperature goes below 32F. 2. Notification should convey enough information about what has changed. For example, the temperature changed and now is 31F. Khurana et al [Page 4] Internet Draft Device Message Protocol(DMP) November 2000 3. Associate a validity period for the subscription. Should be able to specify this in various forms for example, till next Tuesday, for the next 5 days, till 5pm, etc. 4. Subscribe to a set of events constituting one user subscription. For example, inform me in the office, if the temperature changes or the door bell rings. 5. Possibly associate a different expiry time with each event, if a set of events is defined as in 4 above. These scenarios can be realized by using an appropriate combination of addresses, headers and message bodies. For example, the SIP URI may refer to a class of devices rather than a single device, such as, acs@examplehome.net which refers to all air conditioners in the home. The message body may contain an action, which is to be applied to all air conditioners. In the extreme case there could be but one UA associated with all devices in the home, possibly at a Residential Gateway, or, a separate UA for every single device. One could also enable group communication through the use of a forking proxy. The validity or appropriateness of the granularity of device addressing and the different approaches is not addressed here and is application dependent. DMP, however, is flexible enough to make it possible for all of these requirements and scenarios to be realized. 4 XML Definitions This section defines an XML schema for DMP, which captures the requirements stated in section 3. 4.1 Actions A DMP Action consists of one or more of, a device identifier, followed by one more of either a control, query or subscribe actions. Khurana et al [Page 5] Internet Draft Device Message Protocol(DMP) November 2000 4.1.1 Control Action A control action is an available control action that can be accessed on the device followed by 0 or more arguments associated with the action. 4.1.2 Query A Query consists of a list of one or more state Variables on the device that are being queried. 4.1.3 Event Subscription Khurana et al [Page 6] Internet Draft Device Message Protocol(DMP) November 2000 A Subscribe action consists of one or more variables, such as temperature, zero or more events associated with the variable, such as temperature < 32F, temperature >90F and a duration for which the subscription is valid. When no events are present, the device SHOULD notify of all changes to the variable. 4.2 Response The possible responses to the above actions are defined in the following schema: A DMP response is one or more device identifiers and one or more control, query or event notification responses associated with the device. Khurana et al [Page 7] Internet Draft Device Message Protocol(DMP) November 2000 4.2.1 Control Action Response A control response consists of one or more action identifiers each of which may have one or more associated result codes. Zero or more arguments may also be returned. 4.2.2 Query Response A query response returns identifiers for one or more variables and one or more values associated with the variables and zero or more result codes. 4.2.3 Event Notification Khurana et al [Page 8] Internet Draft Device Message Protocol(DMP) November 2000 An event notification response consists of a list of Variables that changed, the current value of the variable and 0 or more events that occurred which caused the value of the variable to change and possibly some result codes. Subscribe and Notify with the duration set to 0 and event set to NULL MAY be used to implement the query function. 5 Examples An example of DMP used in the body of the DO method to switch on a lamp. DO sip:[slp://d=lamp,r=bedroom,u=stanm]@home.net From: sip:stan@co.com To: sip:[slp://d=lamp,r=bedroom,u=stanm]@home.net Via: SIP/ 2.0/UDP anypc.com Content-function: render Content-type: application/dmp lamp_device_id Power On An example of DMP used in the body of the DO method to query a temperature setting. DO sip:[slp://d=thermostat,r=downstairs,u=stanm]@home.net From: sip:stan@co.com To: sip:[slp://d=thermostat,r=downstairs,u=stanm]@home.net Via: SIP/.0/UDP anypc.co.com Content-type: application/dmp thermostat_device_id Temperature An example of a query response for the above action. 200 stan@co.com From: sip:[slp://d=thermostat,r=downstairs,u=stanm]@home.net Khurana et al [Page 9] Internet Draft Device Message Protocol(DMP) November 2000 To:sip:stan@co.com Via: SIP/2.0/UDP stan.home.net Via: SIP/2.0/UDP home.net Via: SIP/2.0/UDP co.com Via: SIP/2.0/UDP anypc.co.com Content-type: application/dmp device-id Temperature 65F 6 Security Considerations Implementations SHOULD use authentication and encryption to ensure that only authorized entities control network appliances and that the message body cannot be altered without detection. The protocol carrying DMP should provide the needed support. For example SIP mechanisms specified in Section 13 of RFC 2543 should be used. 7 References [1] HAVi, http://www.havi.org [2] æVHN Home Network,Æ EIA 851, Version 1, to be released 4Q00, See http://www.vesa.org for further information. [3] UPnP, Universal Plug and Play Device Architecture v1.0, http://www.upnp.org/download/UPnPDA10_20000613.htm [4] Jini, http://www.jini.org [5] X.10, http://www.x10.org [6] Bluetooth, http://www.bluetooth.com [7] Salutation, http:// www.salutation.org [8] S. Moyer et al, "Framework Draft or Networked Appliances using the Session Initiation Protocol", Internet Draft, Internet Engineering Task Force, July 2000. Work in progress. http://www.argreenhouse.com/iapp/draft-moyer-sip- appliances-framework-00.txt [9] S. Tsang et al, "Requirements for Networked Appliances: Wide-Area Access, Control, and Interworking", Internet Draft, Internet Engineering Task Force, September 2000. Work in progress. http://www.argreenhouse.com/iapp/draft-tsang- appliances-reqs-01.txt [10] http://www.w3.org/XML [11] S. Tsang et al, "SIP Extensions for Communicating with Networked Appliances", Internet Draft, Internet Engineering Task Force, November 2000. Work in progress http://www.argreenhouse.com/iapp/draft-tsang-sip-appliances- do-00.txt Khurana et al [Page 10] Internet Draft Device Message Protocol(DMP) November 2000 [12] J. Rosenberg et al., " SIP Extensions for Presence", Internet Draft, Internet Engineering Task Force, June 2000, Work in progress, draft-rosenberg-impp-presence-00.txt [13] E. Guttman et al., "Service Location Protocol, Version 2", RFC 2608, Internet Engineering Task Force, June 1999 [14] M. Handley, H. Schulzrinne, E. Schooler and J. Rosenberg, "SIP: Session Initiation Protocol," RFC 2543, Internet Engineering Task Force, March 1999. 8 Acknowledgements: The authors would like to thank Stanley Moyer, David Marples, Simon Tsang, Thanh Cheng, Henning Schulzrinne and Arjun Roychowdhury for their contribution towards the evolution of DMP during several discussions on this topic. 9 Author's Addresses Sumit Khurana email: sumit@research.telcordia.com Provin Gurung email: pgurung@research.telcordia.com Ashutosh Dutta email: adutta@research.telcordia.com All of the above are at: Telcordia Technologies 445 South Street Morristown, NJ 07960 USA. Khurana et al [Page 11]