| CoRE | P.D.V. van der Stok |
| Internet-Draft | Philips Research |
| Intended status: Informational | K.E. Lynn |
| Expires: September 15, 2011 | Consultant |
| March 14, 2011 |
CoAP Utilization for Building Control
draft-vanderstok-core-bc-03
This draft describes an example use of the RESTful CoAP protocol for building automation and control (BAC) applications such as HVAC and lighting. A few basic design assumptions are stated first, then URI structure is utilized to define group as well as unicast scope for RESTful operations. RFC 3986 defines the URI components as (1) a scheme, (2) an authority, used here to locate the building, area, or node under control, (3) a path, used here to locate the resource under control, and (4) a query part (fragments are not supported in CoAP.) Next, it is shown that DNS can be used to locate URIs on the scale necessary in large commercial BAC deployments. Finally, a method is proposed for mapping URIs onto legacy BAC resources, e.g., to facilitate application-layer gateways.
This proposal supports the view that (1) building control is likely to move in steps toward all-IP control networks based on the legacy efforts provided by DALI, LON, BACnet, ZigBee, and other standards, and (2) service discovery is complimentary to resource discovery and facilitates control network scaling.
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 September 15, 2011.
Copyright (c) 2011 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 publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in "Key words for use in RFCs to Indicate Requirement Levels" [RFC2119].
In addition, the following conventions are used in this document.
The term "service" often means different things to different communities and even different things to the same community. In building control protocol standards, service is often used to refer to a function in the RPC sense. In this context, we generally substitute the term "function". In the IETF community, service may often refer to an abstract capability such as "datagram delivery". In this submission we use the term service, in the sense defined by "DNS-based Service Discovery" [I-D.cheshire-dnsext-dns-sd], as equivalent to a CoAP end-point (or server).
A CoAP end-point is identified by the authority part of a URI. We refer to this end-point (which is resolved to an {IP address, port} tuple) as a "node". By "device" we generally mean the physical object handled by the installer. While a device may host more than one service, for simplicity we assume here that a given device may only host a single CoAP node.
In examples below involving URIs, the authority is preceded by double slashes "//" and path is preceded by a single slash "/". The examples may make use of full or partial host names and the difference should be clear from the context.
The CoAP protocol [I-D.ietf-core-coap] aims at providing a user application protocol architecture that is targeted to a network of nodes with a low resource provision such as memory, CPU capacity, and energy. In general, IT application manufacturers strive to provide the highest possible functionality and quality for a given price. In contrast, the building controls market is highly price sensitive and manufacturers tend to compete by delivering a given functionality and quality for the lowest price. In the first market a decreasing memory price leads to more software functionality, while in the second market it leads to a lower Bill of Material (BOM).
The vast majority of nodes in a typical building control application are resource constrained, making the standardization of a lightweight application protocol like CoAP a necessary requirement for IP to penetrate the device market. This approach is further indicated by the low energy consumption requirement of battery-less nodes. Low resource budget implies low throughput and small packet size as for [IEEE.802.15.4]. Reduction of the packet size is obtained by using the header reduction of 6LoWPAN [RFC4944] and encouraging small payloads.
Several legacy building control standards (e.g. [BACnet], [DALI], [KNX], [LON], [ZigBee], etc.) have been developed based on years of accumulated knowledge and industry cooperation. These standards generally specify a data model, functional interfaces, packet formats, and sometimes the physical medium for data objects and function invocation. Many of these industry standards also specify lower-level functionality such as proprietary transport protocols, necessitating expensive stateful gateways for these standards to interoperate. Many more recent building control network include IP-based standards for transport (at least to interconnect islands of functionality) and other functions such as naming and discovery. CoAP will be successful in the building control market to the extent that it can represent a given standard's data objects and provide functions, e.g. resource discovery, that these standards depend on.
This submission aims at an approach in which the payload contains messages with a syntax defined by legacy control standards. Accordingly, the syntax of the service/resource discovery messages is related to the chosen legacy control standard. The intention is a progressive approach to all-IP in building control. In a first stage standard IETF based protocols (e.g.CoAP, DNS-SD) are used for transport of control messages and discovery messages expressed in a legacy syntax. This approach enables the reuse of controllers based on the semantics of the chosen control standard. In a later stage a complete redesign of the controllers can be envisaged guided by the accumulated experience with all-IP control.
Two concepts, hierarchy and group, are of prime importance in building control, particularly in lighting and HVAC. Many control messages or events are multicast from one device to a group of devices (e.g. from a light switch to all lights in an area). The scope of a multicast command or discovery message determines the group of nodes that is targeted. A group scope may be defined as link-local, or as a tree maintained by IP-multicast or an overlay that corresponds to the logical structure of a building or campus, and is independent of the underlying network structure. Techniques for group communication are discussed in [I-D.rahman-core-groupcomm].
As described in "Commercial Building Applications Requirements" [I-D.martocci-6lowapp-building-applications] it is typical practice to aggregate building control at the room, area, and supervisory levels. Furthermore, networks for different subsystems (lights, HVAC, etc.) or based on different legacy standards have historically been isolated from each other in so-called "silos". RESTful web services [Fielding] represent one possible way to expose functionality and normalize data representations between silos in order to facilitate higher order applications such as campus-wide energy management.
Consequently, additional protocol oriented assumptions are:
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 commissioning of a given network segment and (2) maintenance oriented applications where data are collected from node in several building areas by nodes inside or outside the building, and humans may intervene to change control settings.
This I-D considers three elements of the URI: scheme, authority, and path, as defined in "Uniform Resource Identifier (URI): Generic Syntax" [RFC3986]. The authority is defined within the context of standard DNS host naming, while the path is valid in relation to a fully qualified domain name (FQDN) plus optional port (and protocol is implicit, based on scheme). An example based on [RFC3986] is: foo://host.example.com:8042/over/there?name=ferret#nose, where "foo" is the scheme, "host.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.
The coap URI scheme syntax is specified in section 6.1 of [I-D.ietf-core-coap] and is compatible with the "http" scheme specification [RFC2616]. The host part of the authority may be represented either as a literal IP address or as a fully qualified domain name. While scheme is irrelevant from the perspective of the service, it is used in service discovery to identify the protocol used to access the service.
TBD: we have yet to fully explore the utility of a separate scheme (e.g., "coapm") to support group communication models as described in [I-D.rahman-core-groupcomm].
The authority part is either a literal IP address or a DNS name comprised of a local part, specifying an individual node or group of nodes, and a global part specifying a (sub)domain that may reflect the logical hierarchical structure of the building control network. The result is said to be a fully qualified domain name (FQDN) which is globally unique down to the group or node level. An optional port number may be included in the authority following a single colon ":" if the service port is other than the default CoAP value.
The CoAP spec [I-D.ietf-core-coap] states "When a CoAP server is hosted by a 6LoWPAN node, it SHOULD also support a port in the 61616-61631 compressed UDP port space defined in [RFC4944]." As shown below, DNS-SD [I-D.cheshire-dnsext-dns-sd] is a viable technique for discovering dynamic host and port assignments for a given service. However, the use of dynamic ports in URIs is likely to lead to brittle (non-durable) identifiers as it is conventional to treat different ports as representing different authorities and there is no assurance that a coap server will consistently acquire the same dynamic port.
A building can be unambiguously addressed by it GPS coordinates or more functionally by its zip or postal code. For example the Dutch Internet provider, KPN, assigns to each subscriber a host name based on its postcode. Analogously, an example authority for a building may 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 specify the target node within the building. Arriving at the node identified by //bldg.5533BA-125a.nl, the receiving service can parse the path portion of the URI and perform the requested method on the specified resource.
Buildings have a logical internal structure dependent on their size and function. This ranges from a single hall without any structure to a complex building with wings, floors, 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 natural to name the equipment based on their location within the building. Consequently, the local part of the URI identifying a piece of equipment is expressed in the building structure. An example is: //light-27.floor-1.west-wing...
This proposal assumes a minimal level of cooperation between the IT and building management infrastructure, namely the ability of the former to delegate DNS subdomains to the latter. This allows the building controls installer to implement an appropriate naming scheme with the required granularity. For institutional real estate such as a college or corporate campus, the authority might be based on the organization's domain, e.g. //node-or-group.floor.wing.bldg.campus.example.com/. In cases where subdomain delegation is not an option, structure can still be represented in a "flat" namespace, subject to the 63 octet limit for a DNS label: //group1-floor2-west-bldg3-campus.example.com.
Most communication is device to device (M2M) within the building. Often a device needs to communicate to all devices of a given type within a given area of the building. For example a thermostat may access all radiator actuators in a zone. A light switch located at room 25b006 of floor one, expressed as: //switch0.25b006.floor1.5533BA-125a.nl/, might specify a command to light1 within the same room with //light1.25b006.floor1.5533BA-125a.nl/. This approach seems to lead to rather verbose URI strings in the packet, contrary to the small packet assumption. However, the design of CoAP is such that the authority portion of the URI need not be transmitted in requests sent to servers. The question arises as to whether the syntax of the authority part needs to be standardized for building control. Given the examples later in the text, this appears more to be the concern of the building owner or the installer than a standardization concern.
Every network addressable resource is completely identified by a URI scheme://authority/path. The path part of the URI specifies the resource within a given node. The representation of object types and their associated attributes are typically subjects for standardization. There is no widely accepted standard for uniformly naming building control device structure in a URI. A vigorous effort is undertaken by the oBIX working group of OASIS [oBIX], but its current impact is limited.
When a GET method with an URI like "//t-sensor1.25b006.floor1.example.com/temperature" is sent, it represents an a priori understanding that the node with name t-sensor1 exists, is of a given standard type (e.g. ZigBee temperature sensor), and that this standard type has the readable attribute: temperature. When commands are sent to a group of nodes it MUST be the case that the targeted resource has the same path on all targeted nodes. Therefore, it is necessary to establish at least a local uniform path naming convention to achieve this. One approach is to include the name of the standard, e.g. BACnet, as the first element in the path and then employ the standard's chosen data scheme (in the case of BACnet, /bacnet/device/object/property).
A better long-term solution is to build on the concepts presented in [I-D.ietf-core-link-format] and identify resources of a given object model in terms of a registered "/.well-known" prefix. The organization responsible for defining a given industry standard XXX (e.g. BACnet, ZigBee, etc.) can register the /.well-known/XXX prefix and specify the allowable pathnames that may occur under this prefix. This allows the XXX standard development organization to assume responsibility for defining the name space and resources associated with the prefix. The registered /.well-known/XXX URI effectively defines a standard object model, or schema. Manufacturers may optionally define proprietary resources that can be discovered dynamically using methods described below.
Given a network configuration and associated prefixes, the network operator needs to define an appropriate set of 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 group communication implementation. IP-multicasting over the group is a possible approach for building control, although proxy-based methods may prove to be more appropriate in some deployments [I-D.rahman-core-groupcomm].
| URI authority | Targeted group |
|---|---|
| //all.bldg6... | "all nodes in building 6" |
| //all.west.bldg6... | "all nodes in west wing, building 6" |
| //all.floor1.west.bldg6... | "all nodes on floor 1, west wing, ..." |
| //all.bu036.floor1.west.bldg6... | "all nodes in office bu036, ..." |
Example groups become: [RFC3596] in each zone. Highly granular multicast scopes are only practical using IPv6. The multicast address allocation strategy is beyond the scope of this I-D, but various alternatives have been proposed [RFC3306][RFC3307][RFC3956]. Some techniques in this proposal, e.g. service discovery as described below, can be accomplished with a single coap-specific multicast address as long as the desired scope is building-wide.
To illustrate the concept of multiple group names within a building, consider the definition, as done with [DALI], of scenes within the context of a floor or a single office. For example, the setting of all blue lights in office bu036 of floor 1 can be realized by multicasting a message to the group "//blue-lights.bu036.floor1". Each group is associated with an IP address. 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. The Uri-Host option [I-D.ietf-core-coap] need not be sent as part of the message. However to identify the resource that is addressed, a short version of the resource path can be inserted as an option as explained in [I-D.ietf-core-link-format].
The binding of a group FQDN to multicast address (i.e., creation of the AAAA record in the DNS zone server) happens during the commissioning process. Resolution of the group name to a multicast address happens at restart of a source or receiver node. A multicast address and associated group name in this context are assumed to be long-lived. It can happen that during operation the membership of the group changes (less or more lights) but its address is not altered and neither its name. In the limit, the group can degrade to a single controller that represents a non-networked subsystem replacing the original networked group of nodes. Group membership may be managed by a protocol such as Multicast Listener Discovery [RFC5790].
A group defines a set of nodes. All resources on a given node are referenced by the multicast address(es) to which the node belongs. A given node might belong to a number of groups. For example the node belonging to the "blue-lights" group in a given corridor might also belong to the groups: "whole building", "given wing", "given floor", "given corridor", and "lights in given corridor". Assuming that belonging to a group has as only consequence for the group member that it should accept packets for an additional IP address, the granularity of the domain names may have an impact on the complexity of the DNS server but not necessarily on the low-resource destinations or sources. Assuming that resolution of addresses only happens at node start-up, the complexity of the DNS server need not affect the responsiveness of the nodes.
In summary, the authority portion of the URI is used to identify a node (group) and the resulting DNS name is bound to a unicast (multicast) address. Naming is building or organization dependent, must be flexible, and does not require standardization efforts but SHOULD conform to some uniform convention.
DNS-Based Service Discovery (DNS-SD) defines a conventional way to configure DNS PTR, SRV, and TXT records to facilitate discovery of services such as CoAP nodes within a subdomain, re-using the existing DNS infrastructure. This section gives a cursory overview of DNS-SD; see [I-D.cheshire-dnsext-dns-sd] for a complete description.
A DNS-SD service instance name is of the form <Instance>.<ServiceType>.<Location>, where the service type for CoAP nodes is "_coap._udp". The identifier "_udp" provides a transport protocol hint as required by the SRV record definition [RFC2782] and "_coap" identifies the application protocol. A PTR record with the label "_coap._udp" is defined for each CoAP end-point in the zone, and this record's value is set to the service instance name (which in turn identifies to SRV and TXT records for the CoAP end-point).
DNS-SD also supports one level of subtype, which can be used to locate coap services based on object model (schema), for example: _bacnet._sub._coap._udp, _dali._sub._coap._udp, or _zigbee._sub._coap._udp. The maximum length of the type and subtype fields is 14 octets, which could allow for "schema-function" descriptors such as _dali-light, _dali-switch, etc.
The Location part of the service name is identical to the global (DNS subdomain) part of the authority in URIs that identify the resources on this node or group and may identify a building zone as in the examples above.
The Instance part of the service name may be changed during the commissioning process. It must be unique within the subdomain. The complete service name uniquely identifies an SRV and a TXT record in the DNS zone. The granularity of a service name MAY be at the group or node level, or it could represent a particular resource within a coap node. The SRV record contains the host (AAAA record) name and port of the service. In the case where a service name identifies a particular functional entry point, the path part of the URI may be placed in the TXT record.
In general, the authority "www.example.com" does not refer to a canonical host name (the label of a AAAA record). Logically, it refers to the "world wide web service" for the example.com domain. Literally, the "www" is probably the label of a CNAME record that names a AAAA record that may in turn specify more than one address (in the case of round-robin load leveling between identical origin server instances).
The SRV record functions something like the CNAME in this case, except that it is capable of resolving to an IP address plus a listening socket (though, as we said, the use of dynamic sockets is not recommended in URIs). An optional TXT record may be configured wih same name as the SRV record and be used to store context- dependent key=value pairs. For example, a multi-function device might define a service name for each "base URI" that locates the start of an object resource (e.g. abs-path=/.well-known/zigbee/sensor/). Thus, the URI coap://host.example.com/temp might resolve through DNS-SD lookups to coap://[fdfd::1234]/.well-known/zigbee/sensor/temp.
CoAP nodes in a given subdomain may be enumerated by sending a DNS query for PTR records named _coap._udp to the authoritative server for that zone. A list of names for SRV records matching that ServiceType.Location is returned. Each SRV record contains the port and host name of a CoAP node. The IP address of the node is obtained by resolving the host name. DNS-SD also specifies an optional TXT record, having the same name as the SRV record, which can contain "key=value" attributes. Apart from defining the standard resources identified by schema=XXX, the XXX organization may also define the standard "key=value" pairs present in the TXT record, e.g. type=switch. By convention, the first pair is txtver=<number> so that different versions of the XXX schema may interoperate.
While service discovery is concerned with finding the IP address, port, protocol, and possibly path of a named service, resource discovery is a fine-grained enumeration of resource URIs within a web service. [I-D.ietf-core-link-format] specifies a resource discovery pattern, such that sending a confirmable GET message for the /.well-known/core resource returns a set of links that identify all resources present on the node that are exposed as functions.
Assuming the ability to multicast the GET over the local link, coap resource discovery can be used to enumerate attributes and populate the DNS-SD database in a semi-automated fashion. CoAP resource descriptions can be imported into DNS-SD for exposure to service discovery by using /.well-known/core attributes as the basis for a unique "Instance" name, defaulting to "_coap._udp" for the ServiceType, and using some means to establish in which subdomain the service should be registered (TBD). The DNS TXT record can be populated by importing the other resource description attributes as they share the same key=value format specified in Section 6 of [I-D.cheshire-dnsext-dns-sd].
link-extension = ( "sn" "=" quoted-string )
link-extension = ( "st" "=" quoted-string )
link-extension = ( "ss" "=" quoted-string )
The following CoRE specific target attributes are proposed as extensions to [I-D.ietf-core-link-format] to support DNS-SD. The values are intended to be imported directly into a DNS- SD zone file are are subject to format and length constraints as specified in [I-D.cheshire-dnsext-dns-sd].
The service name "sn" attribute is the <Instance> portion of a DNS-SD service instance name. It is stored directly in the DNS as a single DNS label of canonical precomposed UTF-8 [RFC3629] "Net-Unicode" (Unicode Normalization Form C) [RFC5198] text. However, to the extent that the "sn" attribute may be chosen to match the DNS host name of a proxy or gateway, it SHOULD use the syntax defined in Section 3.5 of [RFC1034] and Section 2.1 of [RFC1123].
The <Instance> portion of the name of a service being offered on the network SHOULD be configurable by the user setting up the service, so that he or she may give it an informative name. However, the device or service SHOULD NOT require the user to configure a name before it can be used. A sensible choice of default name can allow the device or service to be accessed in many cases without any manual configuration at all. The default name should be short and descriptive, and MAY include the device's MAC address, serial number, or any similar hexadecimal string in an attempt to make the name globally unique.
DNS labels are currently limited to 63 octets in length and the entire service instance name may not exceed 255 octets.
The service type "st" attribute is composed into the <ServiceType> portion of a DNS-SD instance name as follows. It is limited to 14 octets of Net-Unicode text. If ommitted, it defaults to "coap". An underscore '_' is prepended to the value of the "st" attribute, which is then concatenated with a period '.', and finally the "_udp" identifier. The resulting string is used to form labels for DNS-SD records and as such is stored directly in the DNS.
The service subtype "st" attribute, if present, follows the format and composition rules defined in the previous section. It is then concatenated with a period '.' and the <ServiceType> string defined above to form additonal labels for DNS-SD records as defined in Section 4.1.
Before CoAP devices can come to market, manufacturers must agree that the type and attributes of the device can be interpreted according to some generally recognized syntax. At this moment no such generally recognized syntax exists for CoAP devices. We do not expect an IETF working group to standardize such a syntax, and we are convinced that syntax standardization is the responsibility of industry standards organizations. Given the long history of building control, many groups have defined a data representation for building control devices for example BACnet, ZigBee oBIX, LON, KNX, and many others. It is our believe that new representations will be defined and must coexist with the named legacy ones.
The CoAP protocol should transport any data representation, and certainly the legacy ones. As pointed out earlier, this has consequences for the naming of resources. In some cases a CoAP device can handle more than one legacy representation. Given that a CoAP device can handle representation of standard XXX, this I-D proposes that such a CoAP device can communicate with legacy devices via a CoAP/legacy gateway (router).
Figure 1 represents the network architecture which is expected for the purpose of this I-D. The coap gateway connects one link with two legacy nodes -containing legacy data representation "yyy"- with the wireless coap network composed of three coap hosts. Two coap hosts contain the coap stack with a zzz representation and one host contains the coap stack with a zzz and an yyy representation. The yyy hosts can freely communicate according to the yyy link protocol over the yyy link. The zzz coap hosts, including the zzz;yyy host can freely exchange zzz data representations according to the coap protocol over the wireless IP/6LoWPAN network. The zzz;yyy host can send yyy data representations to the coap gateway which passes them on to the specified yyy legacy host. The yyy legacy node returns data to the requesting zzz;yyy coap host via the same gateway.
+------+ +------+ +------+
| yyy | | zzz | | zzz |
| link | | coap | | coap |
+------+ +------+ +------+
| +---------+
|---------| coap |-->
| | gateway |
+------+ +---------+ +-----------+
| yyy | | zzz ; yyy |
| link | | coap |
+------+ +-----------+
There are at least four ways that the CoAP hosts can address the legacy nodes behind the gateway.
The major advantage of all four approaches is that the gateway only handles the URI or IP address and port number to select the destination legacy node independent of the type of legacy device and the contents of the legacy payload of the message. In Figure 1 the gateway connects to a single link. For example, this would be the case for DALI standard. Other legacy standards, like BACnet, LON, allow networks composed of multiple links.
An example of an invocation of a zzz device from a controller that can producee zzz commands is given. Assume the resource path /.well-known/zzz identifies the parser of the ZZZ syntax. A 12 octet message completely describes the zzz command. The host is completely identified by the authority in the URI. The zzz parser on the host is identified by the port number.
Client CoAP/ZZZ
| node
| REQUEST |
|-------- CON [0x5577] PUT /.well-known/ZZZ -------->|
| binary 12 octet string |
| |
| RESPONSE |
|<---------- ACK [0x5577] 2.00 OK ----------------- |
| |
An example of an invocation of a DALI legacy node behind a gateway is given. Assume the resource path /.well-known/DALI where the port number identifies the DALI node. The application sets a value of 200 in the DALI node in the attribute 256 defined by the DALI spec.
Client DALI/CoAP
| gateway
| REQUEST |
|------- CON [0x5577] PUT /.well-known/DALI -------->|
| binary 16 bit payload dt*256 + 200 |
| |
| RESPONSE |
|<---------- ACK [0x5577] 2.00 OK ----------------- |
| |
Two types of gateways are considered; (1) coap gateway to a single legacy link, called yyy/coap gateway, and (2) coap gateway to legacy network, called xxx/coap gateway. The source encapsulates the data with the corresponding representation inside a CoAP message and sends these messages to the gateway. In the gateway the XXX/YYY data is removed from the CoAP message and transported to the desired node. Returning an answer to the invoking host needs to be done in two different ways dependent on the addressing type of the XXX/YYY standard. The IP-node-identifier (INI) can be (1) the IP-address, (2) the IP-address, port number, (3) the URI, or (4) the path .
It is assumed that the gateway conforms to the core standard at the internet interfaces. Consequently, all resources are visible at /.well-known/core by invoking a GET. These entries can be entered into DNS-SD with a commissioning tools as proposed in section 5.3; according to the rules specified in section 4. Filling in the address mapping tables is done in a similar way as done for other application level gateways (ALG).
Commissioning means mapping a physical device identified by its location to an URI. Given that mapping of URI to IP address is done elsewhere (e.g. DNS), the mapping of location to IP address is done during commissioning with a commissioning tool. The commissiong is done for a set of coap nodes interconnected by a wireless network. The netwok can contain zero or more 6LR routers and zero or more 6LBR. The IP infrastructure (DNS, DHCP servers) is connected to the coap network via the 6LBR. Two cases are considerd for commissioning: (1) no 6LBR and no DNS server connected, and (2) a 6LBR connects to a DNS server.
When an architect has designed the building and described all light points, ventilators, heating- and cooling units, and sensors, it is necessary to provide identifiers for all these devices. The triple Instance.ServiceType.Location, as proposed in DNS-SD, is used to describe the commssioning process. The identifiers of the devices often reflect their action domain which is linked to their physical location. The authority can be equated to the Location identifier. The Location uniquely identifies the device. The Instance is the unique identifier given to the device in the factory but which has no relation to its later function. The ServiceType together with the Location fully determine the semantics of the data returned by the device. Commissioning is the process of mapping the Location to Instance for all installed hosts. The mapping is stored in a discovery repository such that applications can communicate with the required devices.
Design decision: A commissioning tool with access to the network is used for the commissioning phase.
For example, dependent on used technology and production process, the following situation (state) exists in a host after physical installation of the devices:
Consider the commissioning process (1) with a central DNS-SD server and (2) without a central server using mDNS.
The names with the corresponding authority prefixes can be grouped by the tool and appropriate group names can be assigned. The names stored in the tool are inserted into the DNS-SD server, respecting all DNS rules with respect to domain naming, and authority structure. Assuming that the authority syntax corresponds with the structure of the building, the installer can select on a screen the subset of names belonging to the building part he wants to commission. The installer reads with a bar code reader, attached to the tool, the identifier of the device to commission. The installer selects, on the screen of the tool, the physical location of the chosen device. The tool knows the authority of the selected device. The tool informs the DNS-SD server that the read barcode belongs to the selected authority. This is done for all devices within a given part of the building. Once this manual commissioning part is done the nodes conclude the commissioning process:
After the commissioning process, all resources of each node have an URI and IP address which are stored in the central DNS-SD server. When nodes are restarted, the DHCP server allocates IP addresses to the node and updates the DNS server
It is assumed that the building network is composed of independent network segments (possibly a single link) such that each node on a given segment can communicate directly with any other node on this segment. The segments are not connected to a 6LBR and have no access to DNS or other servers. The installer knows these segments and has a list of devices for a given segment. In the tool the installer selects the names which belong to the given building segment. The selected names are converted to link-local authorities and stored in the tool. All nodes are assumed to have selected a link-local IP address. Assume that every device has a unique barcode within the building and that the corresponding node knows the bar code number. The installer reads with a bar code reader, attached to the tool, the identifier of the device to commission. The installer selects, on the screen of the tool, the physical location of the chosen device. The tool knows the authority of the selected device. The tool broadcasts the bar code number and authority to all connected nodes. The node with the given barcode number, extends the authority with the path name of the resources. For each resource, the node multicasts the link-local IP-address and the link-local URI to the mDNS servers in the connected nodes. This concludes the commissioning of a network segment. All resources of each node have a link-local URI and a link-local IP address which are stored in the mDNS servers.
This I-D explains how naming in building control is based on a hierarchical structure of the building areas. It is shown that DNS subdomain delegation and naming can be used to express this hierarchy in the authority portion of the URI, down to the group or node level. The hierarchical naming scheme need not be standardized, but rather can be designed to suit the application. However, it is recommended that the scheme be employed consistently throughout the delegated subdomain(s).
The authority portion of the URI is resolved by the client, using conventional DNS, into the unicast or multicast IP address of the targeted node(s). Taking advantage of the CoAP design [I-D.ietf-core-coap], the Uri-Host option need not be transmitted in requests to origin servers and thus there is no performance penalty for using descriptive naming schemes. The coap design allows sending a short url to distinguish between resources on a given node, resulting in very compact identifiers.
DNS-SD [I-D.cheshire-dnsext-dns-sd] can be used to scale up service discovery beyond the local link. DNS-SD can be used to enumerate instances of a given service type within a given sub-domain. This affords additional flexibility, such as the ability to discover dynamic port assignments for coap node, locate coap nodes by subtype, or bind service names for particular coap URIs.
A targeted resource is specified by the path portion of the URI. Again, this I-D does not mandate a universal naming standard for resources but uses examples to show how resources could be named for various legacy standards. An obvious requirement for resources that are accessed by multicast is that they MUST all share the same path. It is shown that it is possible to transport legacy commands (e.g. expressed in BACnet, LON, DALI, ZigBee, etc.) inside a CoAP message body. This necessitates the definition of an additional IANA mime code, and the mapping of legacy specific discovery semantics to CoAP resource discovery messages or DNS-SD lookups.
TBD: The detailed CoAP security analysis needs to encompass scenarios for building control applications.
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 may be based on the work done elsewhere, for example in the ZigBee over IP context.
Multicast messages are, by their nature, transmitted via UDP. Any privacy applied to such messages must be block oriented and based on group keys shared by all targeted nodes. The CoRE security analysis must be broadened to include multicast scenarios.
This I-D proposes that associations which standardize device representations (like BACnet, ZigBee, DALI,...) contact IANA to reserve the prefix /.well-known/XXX for the standard XXX.
This I-D has benefited from conversations with and comments from Andrew Tokmakoff, Emmanuel Frimout, Jamie Mc Cormack, Oscar Garcia, Dee Denteneer, Joop Talstra, Zach Shelby, Jerald Martocci, Anders Brandt, Matthieu Vial, Jerome Hamel, George Yianni, and Nicolas Riou.
From bc-01 to bc-02
- Removed all references to multicast and multicast scope, given draft of rahman group communication.
- Adapted examples to coap-2 and core-link drafts.
- transport short URL for destination recognition.
- Elaborated legacy discovery under DNS-SD.
From bc-02 to bc-03
- Elaboration on gateways, commissioning and legacy networks. - Recommendation to extend DNS-SD naming with sn, st, and ss attributes.
| [I-D.cheshire-dnsext-dns-sd] | Cheshire, S and M Krochmal, "DNS-Based Service Discovery", Internet-Draft draft-cheshire-dnsext-dns-sd-10, February 2011. |
| [I-D.cheshire-dnsext-multicastdns] | Cheshire, S and M Krochmal, "Multicast DNS", Internet-Draft draft-cheshire-dnsext-multicastdns-14, February 2011. |
| [I-D.ietf-core-coap] | Shelby, Z, Hartke, K, Bormann, C and B Frank, "Constrained Application Protocol (CoAP)", Internet-Draft draft-ietf-core-coap-08, October 2011. |
| [I-D.ietf-core-link-format] | Shelby, Z, "CoRE Link Format", Internet-Draft draft-ietf-core-link-format-09, November 2011. |
| [I-D.martocci-6lowapp-building-applications] | Martocci, J, Schoofs, A and P Stok, "Commercial Building Applications Requirements", Internet-Draft draft-martocci-6lowapp-building-applications-01, July 2010. |
| [I-D.rahman-core-groupcomm] | Rahman, A and E Dijk, "Group Communication for CoAP", Internet-Draft draft-rahman-core-groupcomm-07, October 2011. |
| [BACnet] | Bender, J. and M. Newman, "BACnet/IP", Web http://www.bacnet.org/Tutorial/BACnetIP/index.html, . |
| [ZigBee] | Tolle, G., "A UDP/IP Adaptation of the ZigBee Application Protocol", Internet-Draft draft-tolle-cap-00, October 2008. |
| [LON] | LONTalk protocol specification, version 3", 1994. | , "
| [DALI] | DALI Manual", Web http://www.dali-ag.org/c/manual_gb.pdf, 2001. | , "
| [KNX] | Kastner, W., Neugschwandtner, G. and M. Koegler, "AN OPEN APPROACH TO EIB/KNX SOFTWARE DEVELOPMENT", Web http://www.auto.tuwien.ac.at/~gneugsch/fet05-openapproach-preprint.pdf, 2005. |
| [IEEE.802.15.4] | Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific requirements - Part 15.4: Wireless Medium Access Control (MAC) and Physical Layer (PHY) Specifications for Low Rate Wireless Personal Area Networks (LR-WPANs) ", IEEE Std 802.15.4-2006, June 2006. | , "
| [oBIX] | oBIX working group", Web http://www.obix.org, 2003. | , "
| [Fielding] | Fielding, R., "Architectural Styles and the Design of Network-based Software Architectures, Second Edition", Doctoral dissertation , University of California, Irvine , Web http://www.ics.uci.edu/~fielding/pubs/dissertation/top.html, 2000. |