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]