CoRE P. van der Stok Internet-Draft Philips Research Expires: January 5, 2011 July 4, 2010 CoAP utilisation for building control draft-vanderstok-core-bc-00 Abstract This draft describes an example use of the RESTful CoAP protocol to control equipment in buildings such as HVAC and lighting. A few basic design assumptions are stated first. The uri structure is exploited to define multicast scopes. RFC 3986 divides the uri in (1) a scheme, (2) an authority part, used here to locate the building under control, (3) a path, used here to locate the resource under control, and (4) a query and fragment part, only the query part is discussed in the context of service discovery. This I-D supports the view that (1) building control will move in steps towards all-IP control networks building on the legacy efforts provided by DALI, LON, BACnet, ZigBee and other standards, and (2) the provision of a reliable group communication protocol is essential. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on January 5, 2011. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of van der Stok Expires January 5, 2011 [Page 1] Internet-Draft CoAP utilisation for building control July 2010 publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Table of Contents 1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. URI structure . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Authority part . . . . . . . . . . . . . . . . . . . . . . 5 2.2. Path part . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Group Addressing . . . . . . . . . . . . . . . . . . . . . . . 7 4. Payload examples . . . . . . . . . . . . . . . . . . . . . . . 9 5. Service discovery . . . . . . . . . . . . . . . . . . . . . . 12 6. Security considerations . . . . . . . . . . . . . . . . . . . 14 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 15 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18 van der Stok Expires January 5, 2011 [Page 2] Internet-Draft CoAP utilisation for building control July 2010 1. Motivation The CoAP protocol [IDcoap] aims at providing a user application protocol architecture which is targeted to a network of nodes with a low resource provision such as memory, CPU capacity and energy. Although in general, IT application manufacturers strive to provide the highest possible functionality and quality for a given price, in building control, manufacturers tend to compete by delivering a given functionality and quality for the lowest price. A low resource budget reduces the price of the nodes and a large effort is spent on reducing the message length. This approach is reinforced by the required low energy consumption by battery-less nodes. Reduction of the packet size is obtained by using the header reduction of 6lowpan and encouraging small payloads. Constraints on the message contents are imposed by the long history of control in the building which has led to the development of much legacy knowledge and applications. Reuse of this knowledge will stimulate the introduction of all-IP control within the buildings. This draft aims at an approach in which the payload can be built on existing control standards, and future new standards to emerge. The syntax of the control messages is specified in the standard (e.g. BACNet, LON, DALI, KNX, etc.). The description of the services is based on the same standard. Consequently, the syntax of the service discovery messages, partially expressed in the uri, is related to the chosen legacy control standard. From the above the basic syntax assumptions can be summarized as: - Generate small payloads - Compatible with legacy standards (e.g. LON, BACnet, DALI, ZigBee Device Objects) - Service discovery in agreement with legacy standards and uri conventions. Of prime importance in building control (at least lighting and HVAC) is the concept of a group. Many control messages are multicast from one device to a group of devices (e.g. from light switch to all lights in a room). The scope of a multicast or a service discovery message depends upon the group of nodes that is targeted. Determining multicast scopes on the basis of hop count or the existence of edge routers is not always sufficient in buildings where the network architecture may be independent of the controlled areas (e.g. rooms) in the building. Consequently, additional protocol oriented assumptions are: van der Stok Expires January 5, 2011 [Page 3] Internet-Draft CoAP utilisation for building control July 2010 - A syntactic definition of the multicast scope applicable to all multicasts in the building - Pervasive existence of groups of resources For clarity, this I-D limits itself to two types of applications: (1) M2M control applications running within a building area without any human intervention after start-up of a given network segment and (2) maintenance oriented applications where data are collected from node in several building areas to nodes inside or outside the building, and humans may intervene to change control settings. van der Stok Expires January 5, 2011 [Page 4] Internet-Draft CoAP utilisation for building control July 2010 2. URI structure This I-D looks at three aspects of the uri: scheme, authority, and path. The scheme is assumed to be set to coap. The authority is defined within the context of the standard internet naming, while the path is valid in relation to a given DNS addressing unit. An example from RFC 3986 [RFC3986] is: foo://example.com:8042/over/there?name=ferret#nose, where "foo" is the scheme, "example.com:8042" is the authority, "/over/there" is the path, "name=ferret" is the query, and "nose" is the fragment. Fragments are not supported in CoAP. 2.1. Authority part A building can be unambiguously be addressed by it GPS coordinates or more functionally its zip/post code. For example the Dutch Internet provider, KPN, assigns to each subscriber a name based on its postcode. Analogously, an example authority for a building can be given by: //bldg.zipcode_localnr.Country/ or more concretely an imaginary address in the Netherlands as: //bldg.5533BA_125a.nl/. The bldg prefix can identify building control oriented IP network traffic. Arriving at the node identified with 5533BA_125a.nl, the receiving service can parse the rest of the uri and send the message on to the specified resource (node). Other naming schemes are possible and can be freely used. The authority structure looks more than adequate to address the specified building and its control nodes. No additional work is required to standardize its syntax. 2.2. Path part Buildings have a structure dependent on their size and function. This ranges from a single hall without any structure to a complex building with floors, wings, offices and possibly a structure within individual rooms. The naming of the building control equipment and the actual control strategy are intimately linked to the building structure. It is therefore convenient to name the equipment with their location within the building. Consequently, the path part of the uri identifying a piece of equipment is expressed in the building structure. An example is: wing/floor/office/left_hand_corner. Within the building, devices communicate with each other. Often a device needs to communicate to all devices of a given type within a given area of the building. For example a light switch addresses all lights within a given corridor, or a heating unit accesses all radiator actuators on a floor. Although intuitively easy to understand the relative location is verbose and needs much contextual knowledge within a device. For example a switch located at room 25b006 of floor one, expressed as: //bldg.5533BA_125a.nl/floor1/ van der Stok Expires January 5, 2011 [Page 5] Internet-Draft CoAP utilisation for building control July 2010 25b006/, can specify a command to light_1 within the same room with //bldg.5533BA_125a.nl/floor1/25b006/light_1. This approach seems to lead to rather verbose uri strings in the packet contrary to the small packet assumption. Working out a control application later in the text, shows that the uri disappears largely from the packet. Question exists whether the syntax of a path needs to be standardized for building control. Given the examples later in the text, this does not seem to be necessary. van der Stok Expires January 5, 2011 [Page 6] Internet-Draft CoAP utilisation for building control July 2010 3. Group Addressing As already suggested by the examples above the uri is intimately associated with the scope of the messages. This provides a better handle to define the multicast scope than the traditional TTL counter preventing the multicast message to pass one or more routers. This more sophisticated scoping mechanism is needed to separate the network layout from the multicast scopes. This is also witnessed by all the work done by the BACnet over IP standardization to define the scope of the service discovery messages. Given a network configuration and associated prefixes, the network operator needs to define an appropriate set of multicast groups which can be mapped to the building areas. Knowledge about the hierarchical structure of the building areas may assist in defining a network architecture which encourages an efficient multicast implementation. Example multicast groups become: /path targeted group / "the whole building" /floor1 "all nodes on floor1" /wing3 "all nodes in wing 3" /floor1/wing2 "all nodes belonging to wing 2 at floor 1" /floor2/bu036 "all nodes belonging to office bu036 at floor 2" Preferably these multicast groups are created automatically. Their automatic creation is out of the scope of this I-D. This concept can be refined by defining, like done for DALI, scenes within the context of a floor or a single office. For example the setting of all blue lights in office bu036 of floor 2 can be realized by sending a message to the multicast group "/floor2/bu036/blue-lights". All multicast groups are associated with one IP address, similar to the individual nodes in a building area. Consequently, when the application specifies the sending of an "on" message to all blue lights in the office, the message is multicast to the associated IP address and a large part of the uri can be removed from the message. The large number of multicast addresses looks difficult to handle. The suggestion is made that the nodes and not the services are part of a multicast group. That means that all services on a given node belong to the same multicast addresses to which the node belongs. The number of multicast groups to which a given node belongs is then possibly limited to 10. For example the node belonging to the "blue van der Stok Expires January 5, 2011 [Page 7] Internet-Draft CoAP utilisation for building control July 2010 lights" group in a given corridor will also belong to the groups: "whole building", "given floor", "given wing", "given corridor", "lights in given corridor", and "blue lights in given corridor". The path can be used to define the groups and associated multicast scopes. Naming is building dependent and does not need extra standardization efforts. In the context of an administrated professional building, groups can be defined off-line and stored in configuration files referred to by the DHCP server. In the information file participation to all groups is stored. In the context of the home, groups are named on-line by the tenant, possibly storing the group names and members in files for later personnel reference. A reliable group communication (multicast) is essential for an efficient building control application. van der Stok Expires January 5, 2011 [Page 8] Internet-Draft CoAP utilisation for building control July 2010 4. Payload examples Every node with a network address is completely identified with uri structure //authority/path. The next part of the uri is composed of resource identification and function specification. The names of device types and their associated attributes are typically a subject for standardization. For example there is no standard for naming building control devices unambigously in a uri. When a GET with an uri like: /floor1/25b006/t-sensor1/temperature is sent, the underlying assumption is that the resource with name t-sensor1 of a given standard type (e.g. temperture sensor) exists and that this standard type has the readable attribute: temperature. It is unlikely that such a building control wide standard will appear within a short time from now. Consequently, the first use of CoAP in building control must rely on naming standards which exist today. It is assumed that devices exchange messages with a content defined by one of the already existing building control standards e.g. BACnet, LON, DALI, ZigBee Device Objects (ZDO), KNX, and others. All these standards know the concepts of type (class) and type (class) instances. Within a given type a number of attributes exists which can be modified or read with a more or less complex invocation syntax. This draft proposes that the functional part of the uri first describes the standard and then continues with a standard dependent syntax, to be defined by the standardization committee interested to conform to CoAP. For example a command to a heating unit with a BACnet interface can be expressed with //authority/path/ resource/BACnet/BACnet_defined_command or a command to a DALI light can be expressed with //authority/path/resource/DALI/ DALI_defined_command. For example the request: PUT /floor1/bu036/ light1/DALI/30lumen , assuming that light1 is a DALI device, translates to CoAP header [IDcoap]: - dest IP address defined by: /floor1/bu036/light1 - T bits to 0: Confirmable message - Code = 2: PUT method - OC bits set to 1 (for one Mime option) - Transaction ID set - Option type= 5, content type: /application/DALI - DALI command: set intensity to 30 lumen The new option sub type shows that new application mime types need to be defined to cover the building control standards: e.g. van der Stok Expires January 5, 2011 [Page 9] Internet-Draft CoAP utilisation for building control July 2010 /application/DALI, /application/BACnet, etc. Examples of wireless, battery-less nodes are sensors used for measuring presence, temperature, light intensity, or humidity. Battery-less means that the nodes are switched off most of the time and sporadically power up and send out their current measured value. This value is either sent to a controller node or to a group of actuator nodes. Examples are presence detection sent to lamps, or humidity level to a fan. The destination nodes of the measurements are probably powered by the mains or a derivative of the mains. It seems unrealistic to have the controller or the actuator nodes send request messages to the batteryless nodes, after which the sender has to wait an interval determined by the operation of the sender. More natural is that the batteryless node wakes up and sends its message to controller or actuator nodes which are always ready to receive a message. For example, without controller node, the presence detector can send presence regularly to a group of lights. The group can be defined on-line, by having the lights subscribe to the presence service, or the group can be defined off-line by the manager of the control network. On-line definition is more natural in a dynamic home environment, while off-line is more natural in the office environment. Off-line has the added advantage of checking on missing nodes. For subscription the subscribing nodes have to learn the IP address(es) of the service(s) to which they want to subscribe. In case of off-line the servers have to learn the IP address of the multicast group. The latter can be learnt from DHCP options, by inserting the destination IP address inside the configuration file of the battery-less node. The CoAP protocol foresees the use of a non confirmable message packet to send these unsolicited responses to the multicast group or the single controller. Again the syntax of the commands are most likely defined by legacy standards. Assuming the DALI standard, the command PUT /floor2/bu036/blue-lights/DALI/on leads to the following packet lay-out: - dest multicast IP address defined by: /floor1/bu036/blue lights - T bits to 1: Non Confirmable message - Code = 2, PUT method - OC bits set to 1 (for one Mime option) - Transaction ID set, for prevention of double messages van der Stok Expires January 5, 2011 [Page 10] Internet-Draft CoAP utilisation for building control July 2010 - Option type= 5, content type: /application/DALI - DALI command: switch ON van der Stok Expires January 5, 2011 [Page 11] Internet-Draft CoAP utilisation for building control July 2010 5. Service discovery Service discovery is intimately linked to the building structure. When for example a lamp wants to discover the controller, it is only interested in the controllers sitting in the same office (area) as itself. Consequently, the service discovery is related to the groups defined according to the building structure. It is advisable to send a discovery message to a given group. Also the packet does not need the complete uri in the uri option. In conformace with RFC 5785 [RFC5785], a packet from a controller with the request to return the device types of all DALI devices within the office bu036 can look like: - dest multicast IP address defined by: /floor1/bu036/ - T bits to 0: Confirmable messages - Code 0: GET method - OC bits set to 2 (for Mime and URI option) - Transaction ID set - Option type= 1, LEN=21, "/well-known/resources" - Option type= 5, content type: /application/DALI - DALI command: "return device type" The responses from the DALI nodes may look like: - dest IP address of controller - T bits to 2: Acknowledgement messages - CODE = 0, OK - OC bits set to 1 (for Mime option) - Transaction ID identical - Option type= 5, content type: /application/DALI - DALI command: "type = Lamp" The rest of the protocol is dictated by the legacy standard in use but encapsulated within the CoAP discovery messages as shown above. van der Stok Expires January 5, 2011 [Page 12] Internet-Draft CoAP utilisation for building control July 2010 To promote a step-wise introduction of CoAP, the suggestion is to separate the service discovery protocol messages from the service description syntax. The same CoAP protocol messages can be exchanged between nodes, but the description syntax (e.g. xmi, ZDO, or BACnet) is left free. Assuming a building control standard BS. The goal is to exchange the BS messages sent by the service discovery BS client with CoAP messages as described above. At the CoAP server, the BS message is passed on to the BS server. The result from the BS server is packed in a CoAP packet as described above and returned to the BS client. The second step of CoAP introduction uniformizes the sevice discovery clients for interested BS's. Additional standardization effort is needed to provide all functionality supported by all existing standards. For example not all service discovery protocols support the option to return answers from a given type of resource only. Such a general extension can be expressed with the transported uri /well-known/resources/?resource=X. A benefit of such standardisation of discovery queries over all legacy standards is that the legacy standards may enjoy additional facilities like resource directories, which enhance the scalability of the service discovery protocol. The I-D explains how buidling control is based on a hierachical structure of the building areas, and that control message scope and discovery message scope are defined by this building structure. It is shown that the uri can express this structure but does not need standardization. Also larger parts of the complete uri does not need to be transported in the message but is expressed as a Multicast or Unicast IP address in the IP header. It is shown that it is possible to transport legacy commands (.e.g. expressed in BACnet, LON, DALI, ZigBee, etc.) inside CoAP message structure. This necessitates the definition of additional IANA mime codes, and the mapping of legacy specific service discovery semantics to CoAP service discovery messages. It is expected that many control messages are sent by battery-less sensors with their own specific sending intervals to a group of actuator nodes or controllers. Given the importance of groups and associated multicast messages, the specification of a reliable multicast protocol with related multicast scope is needed. van der Stok Expires January 5, 2011 [Page 13] Internet-Draft CoAP utilisation for building control July 2010 6. Security considerations Based on the programming model presented in this I-D, security scenarios for building control need to be stated. Appropriate methods to counteract the proposed threats can be based on the work done elsewhere, for example in the ZigBee over IP context. van der Stok Expires January 5, 2011 [Page 14] Internet-Draft CoAP utilisation for building control July 2010 7. IANA considerations This I-D proposes the following additions to the Media type identifiers in conformance with the proposals done in [IDcoap]. Internet media type code /application/BACnet xx /application/DALI xx+1 /application/ZDO xx+2 /application/LON xx+3 /application/KNX xx+4 /application/exi/building xx+5 /application/exi/metering xx+6 van der Stok Expires January 5, 2011 [Page 15] Internet-Draft CoAP utilisation for building control July 2010 8. Acknowledgements This I-D has benefited from conversations with and comments from Kerry Lynn, Andrew Tokmakoff, Emmanuel Frimout, Jamie Mc Cormack, Oscar Garcia, Dee Denteneer, Joop Talstra, Gerald Martocci, and . van der Stok Expires January 5, 2011 [Page 16] Internet-Draft CoAP utilisation for building control July 2010 9. References [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 3986, January 2005. [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known Uniform Resource Identifiers (URIs)", RFC 5785, April 2010. [IDcoap] Shelby, Z., Frank, B., and D. Sturek, "Constrained Application Protocol (CoAP)", draft-ietf-core-coap-01pre5 (work in progress), June 2010. [BACnet] xx, Z., "BACnet over IP", June 1998. [ZigBee] xx, Z., "ZigBee device objects over IP", June 2009. [LON] xx, Z., "LON objects", June 1990. van der Stok Expires January 5, 2011 [Page 17] Internet-Draft CoAP utilisation for building control July 2010 Author's Address Peter van der Stok Philips Research High Tech Campus Eindhoven, 5656 AA Netherlands Email: peter.van.der.stok@philips.com URI: http://www.research.philips.com/ van der Stok Expires January 5, 2011 [Page 18]