Device Control Protocol Specification (DCP)
 an Internet Protocol for Controlling Devices

CONTENTS

Up
Introduction
Conventions
Parameters
Fundamentals
Message Format
Requests
Responses
Entities
Request Methods
Reserved Objects
Status Codes
Headers
Session Management
Authentication
Security
XML DTD

 

[ Next ]

 

 

 

 

Click Here to visit the home page belonging to the creator of DCP and get access to other downloads, including a white paper on forward compatible design for the Internet.

DcpIntroBan.jpg

Getting Started

 

Welcome to the Device Control Protocol Reference.  This reference makes it easy to learn about and develop applications for integrating common everyday devices over the Internet.

Abstract

The Device Control Protocol (DCP) is an application level protocol optimized for the integration, monitoring and control of devices on a network. It provides a framework for integrating unconventional network devices attached to networks either directly or as computer periphery.  DCP is a generic, object-oriented protocol which supports connection and connectionless communication between resources. It employs an open ended set of methods for indicating the purpose of a request and builds on the discipline of reference provided by the Uniform Resource Identifier (URI), for indicating the object to which these methods are to be applied. By the typing and negotiation of device data representation, DCP allows applications and devices to be built independently of data representation while maintaining interoperability. It defines an extensible object model that enables the developer to expose objects, properties, methods, and events of a device. Plug-and-play characteristics may be implemented for devices through the reserved user interface and device driver objects. The Device Control Protocol has been designed to provide a natural and comfortable extension of the Internet to devices.

This reference assumes knowledge of the Transmission Control Protocol (TCP), the Universal Datagram Protocol (UDP), TCP/IP communications, and Object Oriented Programming (OOP).

Quick Tour of Features

The Device Control Protocol Reference includes the following features.

DCP Protocol Standard

The DCP Specification is a protocol standard, similar to an Internet RFC, which makes developing devices and applications that leverage this Internet-based device control technology simple.  It is a complete hyperlinked reference to the protocol.

XML Document Type Definition for DCP

The DCP XML DTD is an Extensible Markup Language Document Type Definition for DCP.  It is a hierarchical markup language that can be used to represent device states, properties and events.  Device object models may also be described with the DCP XML DTD.  For your reference, a hyperlinked reference to this XML DTD is available here.

Overview

DCP is a protocol designed for communication with and between network devices. While the File Transfer Protocol (FTP) was designed for transferring files and the Hypertext Transfer Protocol (HTTP) emphasizes the transfer of media, DCP focuses on controlling and monitoring devices connected to the Internet.  In the context of DCP, a device is any resource attached to a network and is not necessarily a terminal or network infrastructure equipment.  DCP is a protocol for controlling network devices and should not be compared with DCOM and CORBA, which are binary standards for network components.

DCP addresses the increasing demand for integrating non-traditional network devices by specifying a common language for devices to interoperate with each other, as well as Internet applications. It provides a protocol standard for devices that embed Internet technology and connect to networks directly in addition to devices that connect to networks as computer periphery (see illustration below).



Network Devices

 

Applications for DCP are endless, but here are a few examples:

    • Distributed security systems and security monitoring
    • Integration and control of factory production machinery
    • Remote data collection
    • Load shedding and remote metering for utility providers
    • Environmental control systems
    • Consumer electronics and home appliance integration
    • Device browsers that work with any DCP device
    • Applications that provide logic for a network of devices

 

The Device Control Protocol is a generic, object-oriented protocol which employs a session / transaction paradigm that may be implemented on both connection and connectionless communication between resources. The object-oriented features of DCP allow the protocol to be easily applied to real world objects, or devices. Since the protocol supports both connection and connectionless communication, it offers facilities for reliable and secure communication, as well as broadcast and light-weight messaging.

DCP is extensible and leverages existing Internet technology and standards. It employs an open-ended set of methods for indicating the purpose of a transaction request, allowing expansion methods to be added. The Device Control Protocol builds on the discipline of reference provided by the Uniform Resource Identifier (URI), for indicating the object to which methods are to be applied. DCP extends URI’s to include objects, properties, methods and events in a style that object oriented programmers are used to.

Although an XML document type definition for device data has been defined, use of the representation with DCP is not required. All that is required is that the recipient of the representation be able to understand and process it. The architecture of DCP exhibits the abstraction of device data from the protocol itself. By the typing and negotiation of device data representation, DCP allows applications and devices to be built independently of data representation while maintaining interoperability. This allows for the expansion of data representation types without changing the protocol, allowing developers to separate the transfer of data from the data itself. Since DCP negotiates device data representation, multiple representation types may be supported with ease.

The Device Control Protocol allows the developer to communicate with devices as if they were objects by specifying a core set of facilities which include:

    1. getting a device property
    2. setting a device property
    3. tethering to a device property
    4. calling a device method
    5. subscribing to a device event
    6. transmitting a device event
    7. administrating sessions with devices
    8. discovering the devices attached to a network

DCP further extends it capabilities through a collection of reserved objects.   Developers may expose properties, methods, and events of device through a reserved object model object. This allows applications and other devices to query and browse the capabilities of a device.  Plug and play characteristics may be implemented for DCP aware devices through the reserved user interface and device driver objects.  This allows user interfaces and device drivers to be embedded inside devices.   These reserved objects only specify exposition, negotiation and transfer of the objects.  Although the devices may be implemented with DCP, the technology chosen is at the discretion of the developer.

DCP provides a natural and comfortable extension of the Internet to devices. It has been designed to leverage the massive infrastructure, huge physical network, and large embedded base of software standards and knowledge associated with the Internet. It is also designed to offer an object-oriented approach to embedding the Internet in devices.   The result is a powerful, extensible protocol that allows developers to seamlessly connect devices to the Internet in a comfortable and simple fashion.

PURPOSE

The purpose of DCP is

    1. to enable remote control and monitoring of devices and applications on the Internet
    2. to promote the integration of non-traditional devices on networks
    3. to give network devices "plug-and-play" characteristics
    4. to encourage the development of distributed Internet applications and devices
    5. to shield a user from variations in specific protocols and interfaces for applications and devices

TERMINOLOGY

This resource uses a number of terms to refer to roles played by participants in and objects of DCP communication.  Several new terms and new contexts for existing terms are introduced.  It is recommended that even the seasoned Internet developer review the terms before proceeding to other areas of this reference.

Application -  a program or process attached to a network that is capable of DCP communication.  Throughout this reference, the terms "application", "device" and "resource" are used interchangeably.
Client -  a network resource that issues requests to a server.  In typical client/server environments, resources usually play one role or the other.  This is not the case for DCP.  In DCP, devices typically play roles as both clients and servers by issuing requests to other devices and servicing requests from other devices.   To avoid confusion in this resource, the term client will not be used when making reference to a DCP transaction.  Instead, the device initiating a transaction will be referred to as the initiator.  The term initiator is intended to only be used in the context of the DCP transaction that it is associated with.
Connection -  a transport layer virtual circuit established between two network resources for the purpose of communication.  In DCP, when the mode of service is connection-oriented, the initiator establishes a connection with the target before making a request.
Device -  a piece of physical equipment attached to a network that is capable of DCP communication.  A device is not limited to traditional network hardware (like terminals, switches and routers), but it includes unconventional network devices (like security systems, environmental control systems and factory machinery).  Throughout this reference, the terms "device", "application" and "resource" are used interchangeably.
Entity -  a particular representation or rendition of device data that may be enclosed within a request or response message. An entity consists of meta-information in the form of entity headers and content in the form of an entity body.
Host -  any resource on a network that provides services of any kind to other resources on the network and is qualified by a valid Internet host name or IP address.
Initiator -  refers to the device or application that initiates or starts a transaction with another DCP resource (the target).  In both open-loop and closed-loop transactions, the initiator is the resource that initiates the transaction by making a DCP request and the target is the resource that processes it.  In a client/server model, resources usually play a single messaging or processing role.   This is not the case for DCP, so the term client will not be used in this reference to avoid confusion.  Instead, the term initiator will be used and carry the meaning described above.  Since most DCP devices play multiple roles,  the term initiator only has meaning in the context of the transaction that it refers to.
Message -  the basic unit of DCP communication and consists of a structured sequence of octets matching the syntax defined in this resource and transmitted via a connection or datagram.  DCP transactions are made up of messages.  In DCP there are two types of messages, requests and responses.  DCP Messages have request or response lines, headers and bodies.
Mode of Service (MOS) -  the method used by a network to provide communication services between two processes.  In short, a mode of service specifies how a communication layer performs an operation.  DCP makes reference to two modes of service, connection-oriented and connectionless.  Connection-oriented services create a virtual circuit, which gives the illusion of a physical communication path or point-to-point connection.  To an application using a connection oriented mode of service, the communication channel appears to be a solid, unbroken path for communication.   A connection-oriented mode of service is similar to telephone communication.   A connectionless mode of service provides communication in the form of a delivery service.  In other words, a connectionless mode of service does not establish a point-to-point connection.  There is no illusion of a solid, unbroken communication path.  Communication takes place as a series of datagrams that are delivered by the network through potentially different paths and at varying rates.
Object Model -  a hierarchical object oriented structure that describes a resource's properties, methods and events.  It contains all the information necessary for having a DCP conversation with a resource.  An object model may be used to expose the accessible characteristics of a resource.
Request -a DCP request message.  DCP transactions are initiated by a request message being sent from the initiator to the target.
Resource -  a device, application program or process attached to a network that is capable of DCP communication.  Throughout this reference, the terms "resource", "device" and "application" are used interchangeably.
Response -  a DCP response message.  DCP closed-loop transactions are completed by a response message being sent from the target to the initiator.
Server -  a network resource that services requests from a client.  In typical client/server environments, resources usually play one role or the other.  This is not the case for DCP.  In DCP, devices typically play roles as both clients and servers by initiating transactions with other devices and processing transactions started by other devices.   To avoid confusion in this resource, the term server will not be used.  Instead, the device servicing a transaction will be referred to as the target.  This term is intended to only be used in the context of the DCP transaction that it is associated with.
Session -  a DCP conversation between two devices.  Once a session is opened, any combination of DCP transactions may take place.  Sessions apply to both connection-oriented and connectionless modes of service and should not be considered the same as a connection.  Sessions are identified by a session ID, not a TCP connection.
Target -  a resource that processes a DCP transaction initiated by another resource, known as the initiator.  In both open-loop and closed-loop transactions, the target processes transactions.  The target completes closed-loop transactions by sending a response message to the initiator.  In a client/server model, resources usually play a single messaging or processing role.  Since this is not the case for DCP, the term server will not be used in this reference to avoid confusion.  Instead, the term target will be used and carry the meaning described above.  Since most DCP devices play multiple roles,  the term target only has meaning in the context of the transaction that it refers to.
Tether -  a feature of DCP communication that allows a resource to bind itself to a property of another resource.  The DCP tether facilitates a continuous (as opposed to event driven) stream of property data from the target to the initiator.
Transaction -  a piece of DCP communication that occurs within a session.  Many transactions can occur within a single session.  Transactions may be of an open-loop or closed-loop nature.  Open-loop transactions consist of a DCP request message that is sent from an initiator to a target and the processing performed by the target to satisfy the request.  Closed-loop transactions are identical to open-loop transactions except that they also include a DCP response message sent from the target to the initiator to acknowledge the request and return device data when appropriate.

OVERALL OPERATION

The DCP protocol follows a session / transaction paradigm that may be implemented on both connection-oriented and connectionless modes of service.  A DCP conversation behaves as follows:

  1. An initiator resource opens a DCP session with a target resource.

  2. Any number of DCP transactions are performed within the session by either party.

  3. The DCP session is closed.

DCP sessions and transactions can be compared to a conversation between people.  A session is like an entire conversation and transactions are like statements (or questions and answers).  Just as many statements are made by both parties in a conversation, many transactions can be made by both participants in a single DCP session. 

Within a session, any combination of transactions can take place.   There are two general types of DCP transactions and each of these may occur in either direction:

  1. open-loop

  2. closed-loop

Open-loop transactions are one-way communication scenarios that are initiated by one resource and processed by another. They do not include a response.  A closed-loop transaction is a two-way communication scenario that, in addition to the message that initiates the transaction, includes a response.  DCP devices are likely to initiate and process both open-loop and closed-loop transactions.

In both open-loop and closed-loop transactions, a request is sent from an initiator resource to a target resource in the form of a request method, URI and protocol version followed by headers and a MIME-like message with possible body content.  For closed-loop transactions, a response follows in the form of a status line, including a protocol version and status code followed by headers and a MIME-like message with possible body content.  Message headers are used to communicate and negotiate content representation of the body, permitting DCP applications and devices to be built independently of data representation while maintaining interoperability. 

© 2000 Chris Armbruster