One document matched: draft-vanderstok-core-bc-03.xml
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC1034 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1034.xml">
<!ENTITY RFC1123 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1123.xml">
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2616 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2616.xml">
<!ENTITY RFC2782 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2782.xml">
<!ENTITY RFC3306 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3306.xml">
<!ENTITY RFC3307 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3307.xml">
<!ENTITY RFC3596 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3596.xml">
<!ENTITY RFC3629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3629.xml">
<!ENTITY RFC3956 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3956.xml">
<!ENTITY RFC3986 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3986.xml">
<!ENTITY RFC4944 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4944.xml">
<!ENTITY RFC5198 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5198.xml">
<!ENTITY RFC5785 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5785.xml">
<!ENTITY RFC5790 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5790.xml">
<!ENTITY I-D.ietf-core-coap SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-core-coap.xml">
<!ENTITY I-D.ietf-core-link-format SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-core-link-format.xml">
<!ENTITY I-D.cheshire-dnsext-dns-sd SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.cheshire-dnsext-dns-sd.xml">
<!ENTITY I-D.cheshire-dnsext-multicastdns SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.cheshire-dnsext-multicastdns.xml">
<!ENTITY I-D.martocci-6lowapp-building-applications SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.martocci-6lowapp-building-applications.xml">
<!ENTITY I-D.rahman-core-groupcomm SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.rahman-core-groupcomm.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="no" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc category="info" ipr="trust200902" docName="draft-vanderstok-core-bc-03">
<front>
<title>CoAP Utilization for Building Control </title>
<author initials="P.D.V." surname="van der Stok" fullname="Peter van der Stok">
<organization abbrev="Philips Research">Philips Research</organization>
<address>
<postal>
<street>High Tech Campus</street>
<city>Eindhoven</city><region></region><code>5656 AA</code>
<country>The Netherlands</country>
</postal>
<email>peter.van.der.stok@philips.com</email>
</address>
</author>
<author fullname="Kerry Lynn" initials="K.E." surname="Lynn">
<organization> Consultant </organization>
<address>
<phone> +1 978 460 4253 </phone>
<email> kerlyn@ieee.org </email>
</address>
</author>
<date day="14" month="March" year="2011"/>
<workgroup> CoRE </workgroup>
<abstract>
<t>
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.
</t><t>
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.
</t>
</abstract>
</front>
<middle>
<section title="Introduction" anchor="sect-1">
<section title="Terminology" anchor="sect-1.1">
<t>
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" <xref target="RFC2119"/>.
</t><t>
In addition, the following conventions are used in this document.
</t><t>
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" <xref target="I-D.cheshire-dnsext-dns-sd"/>,
as equivalent to a CoAP end-point (or server).
</t><t>
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.
</t><t>
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.
</t>
</section>
<section title="Motivation" anchor="sect-1.2">
<t>
The CoAP protocol <xref target="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).
</t><t>
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
<xref target="IEEE.802.15.4" />. Reduction of the packet size is obtained by using the header
reduction of 6LoWPAN <xref target="RFC4944" /> and encouraging small payloads.
</t><t>
Several legacy building control standards (e.g. <xref target="BACnet" />, <xref target="DALI" />,
<xref target="KNX" />, <xref target="LON" />, <xref target="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.
<t></t>
From the above the basic syntax assumptions can be summarized as:
<list style="hanging">
<t hangText="- ">Generate small payloads.</t>
<t hangText="- ">Compatible with legacy standards (e.g. LON, BACnet, DALI, ZigBee Device Objects).</t>
<t hangText="- ">Service/resource discovery in agreement with legacy standards and naming conventions.
</t>
</list>
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.
</t><t>
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 <xref target="I-D.rahman-core-groupcomm" />.
</t><t>
As described in "Commercial Building Applications Requirements" <xref target="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 <xref target="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.
</t><t>
Consequently, additional protocol oriented assumptions are:
<list style="hanging">
<t hangText="- ">Nodes may be addressed by one or more groups.</t>
<t hangText="- ">Resources addressed by a group must be uniformly named across all targeted nodes.</t>
</list>
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.
</t>
</section>
</section>
<section title="URI structure" anchor="sect-2">
<t>
This I-D considers three elements of the URI: scheme, authority, and path,
as defined in "Uniform Resource Identifier (URI): Generic Syntax" <xref target="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 <xref target="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.
</t>
<section title="Scheme part" anchor="sect-2.1">
<t>
The coap URI scheme syntax is specified in section 6.1 of <xref target="I-D.ietf-core-coap" />
and is compatible with the "http" scheme specification
<xref target="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.
</t><t>
TBD: we have yet to fully explore the utility of a separate scheme
(e.g., "coapm") to support group communication models as described
in <xref target="I-D.rahman-core-groupcomm" />.
</t>
</section>
<section title="Authority part" anchor="sect-2.2">
<t>
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.
</t><t>
The CoAP spec <xref target="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 <xref target="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.
</t><t>
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.
</t><t>
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...
</t><t>
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.
</t><t>
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.
</t>
</section>
<section title="Path part" anchor="sect-2.3">
<t>
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
<xref target="oBIX" />, but its current impact is limited.
</t><t>
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).
</t><t>A better long-term solution is
to build on the concepts presented in <xref target="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.
</t>
</section>
</section>
<section title="Group Naming and Addressing" anchor="sect-3">
<t>
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 <xref target="I-D.rahman-core-groupcomm" />.
</t><t>
Example groups become:
<texttable style="none">
<ttcol> URI authority </ttcol> <ttcol> Targeted group </ttcol>
<c> //all.bldg6... </c> <c> "all nodes in building 6"</c>
<c> //all.west.bldg6... </c> <c> "all nodes in west wing, building 6" </c>
<c> //all.floor1.west.bldg6... </c> <c> "all nodes on floor 1, west wing, ..." </c>
<c> //all.bu036.floor1.west.bldg6... </c> <c> "all nodes in office bu036, ..." </c>
</texttable>
The granularity of this example is for illustration rather than a recommendation.
Experience will dictate the appropriate hierarchy for a given structure as well
as the appropriate number of groups per subdomain. Note that in this example,
the group name "all" is used to identify the group of all nodes in each subdomain.
In practice, "all" could name an address record in each of the DNS zones shown above
and would bind to a different multicast address <xref target="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 <xref target="RFC3306" /><xref target="RFC3307" /><xref target="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.
</t><t>
To illustrate the concept of multiple group names within a building,
consider the definition, as done with <xref target="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 <xref target="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 <xref target="I-D.ietf-core-link-format" />.
</t><t>
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 <xref target="RFC5790" />.
</t><t>
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.
</t><t>
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.
</t>
</section>
<section title="Discovery" anchor="sect-4">
<section title="DNS-Based Service Discovery" anchor="sect-4.1">
<t>
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 <xref target="I-D.cheshire-dnsext-dns-sd" /> for a complete description.
</t><t>
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 <xref target="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).
</t><t>
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.
</t><t>
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.
</t><t>
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.
</t>
</section>
<section title="Service vs Host Names" anchor="sect-4.2">
<t>
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).
</t><t>
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.
</t>
</section>
<section title="Browsing for Services" anchor="sect-4.3">
<t>
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.
</t>
</section>
<section title="Resource vs Service Discovery" anchor="sect-4.4">
<t>
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.
<xref target="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.
</t><t>
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 <xref target="I-D.cheshire-dnsext-dns-sd" />.
</t>
</section>
<section anchor="sec-4.5" title="CoRE Link Extensions for DNS-SD">
<t>
The following CoRE specific target attributes are proposed as
extensions to <xref target="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 <xref target="I-D.cheshire-dnsext-dns-sd" />.
<figure>
<artwork>
<![CDATA[
link-extension = ( "sn" "=" quoted-string )
link-extension = ( "st" "=" quoted-string )
link-extension = ( "ss" "=" quoted-string )
]]>
</artwork>
</figure>
</t>
<section anchor="sec-4.5.1" title='Service Name "sn" attribute'>
<t>
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 <xref target="RFC3629" /> "Net-Unicode"
(Unicode Normalization Form C) <xref target="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 <xref target="RFC1034" /> and Section 2.1 of <xref target="RFC1123" />.
</t><t>
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.
</t><t>
DNS labels are currently limited to 63 octets in length and the entire
service instance name may not exceed 255 octets.
</t>
</section>
<section anchor="sec-4.5.2" title='Service Type "st" attribute'>
<t>
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.
</t>
</section>
<section anchor="sec-4.5.3" title='Service Subtype "ss" attribute'>
<t>
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.
</t>
</section>
</section>
</section>
<section title="Data Representations in CoAP" anchor="sect-5">
<t>
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.
</t>
<t>
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).
</t>
<section title="Network architectures" anchor="sect-5.1">
<t>
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.
</t>
<figure title="Figure 1: network with multiple representation standards">
<artwork>
+------+ +------+ +------+
| yyy | | zzz | | zzz |
| link | | coap | | coap |
+------+ +------+ +------+
| +---------+
|---------| coap |-->
| | gateway |
+------+ +---------+ +-----------+
| yyy | | zzz ; yyy |
| link | | coap |
+------+ +-----------+
</artwork>
</figure>
<t>
There are at least four ways that the CoAP hosts can address the legacy nodes
behind the gateway.
</t>
<list style="hanging">
<t hangText="- ">All nodes of legacy network YYY share the same Uri-Host also used for
the coap gateway on the coap network.
Every legacy node is a resource for the gateway as seen from the CoAP host. Consequently, the CoAP host sends the message
to the IP address of the gateway and the gateway parses the Uri-Path to determine the specified legacy node.</t>
<t hangText="- ">All nodes of legacy network YYY have IP addresses different from the IP address of the gateway.
Consequently, a CoAP host sends the message to the IP address of the specified node. The routing protocol
on the coap network makes the message
arrive at the coap gateway. The gateway determines the specified legacy node from the destination IP address.</t>
<t hangText="- ">All nodes of legacy network YYY have different authorities. This means that the possibly
lenghy authority names need to be transmitted. The gateway recognizes the authorities and maps authority to legacy node.</t>
<t hangText="- ">All nodes of legacy network YYY have different ports. This can be expresed in two ways (1) as :port in the URI,
or (2) can be defined in the DNS-SD records. In the latter case the port is defined in the UDP header and is efficient
in packet header size.</t>
</list>
<t>
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.
</t>
<t>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.
</t><t>
<figure title="Figure 2: Sending a ZZZ command with coap to coap/ZZZ node">
<artwork>
<![CDATA[
Client CoAP/ZZZ
| node
| REQUEST |
|-------- CON [0x5577] PUT /.well-known/ZZZ -------->|
| binary 12 octet string |
| |
| RESPONSE |
|<---------- ACK [0x5577] 2.00 OK ----------------- |
| |
]]>
</artwork>
</figure>
In the example the format of the payload is determined
by the zzz standard. The path /.well-known/ZZZ is
obtained from the TXT record for this service, e.g., schema=ZZZ.
The 12 octet binary payload specifies the zzz command. The port number
in the UDP header identifies the zzz parser.
</t>
<t>
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.
</t><t>
<figure title="Figure 3: Sending a DALI setting with coap to coap/DALI gateway">
<artwork>
<![CDATA[
Client DALI/CoAP
| gateway
| REQUEST |
|------- CON [0x5577] PUT /.well-known/DALI -------->|
| binary 16 bit payload dt*256 + 200 |
| |
| RESPONSE |
|<---------- ACK [0x5577] 2.00 OK ----------------- |
| |
]]>
</artwork>
</figure>
In the example the format of the payload is determined
by the legacy standard. The path /.well-known/DALI is
obtained from the TXT record for this service, e.g., schema=DALI.
The 16-bit binary payload specifies that the attribute dt
of the dali compatible resource is set to 200. The port number
in the UDP header identifies the DALI node.
</t>
</section>
<section title="Gateways to legacy networks" anchor="sect-5.2">
<t>
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 .
</t>
<list style="hanging">
<t hangText="- "> The packet contains a YYY link address. In the gateway two tables are maintained.
Table 1 contains a link from INI to YYY address. Table 2 contains a link of the source IP address to the destination YYY address for the active request.
A yyy/coap host with IP address, IPs, sends a request to the INI, IPd, of the specified YYY device with link address Yd.
The packet is routed to the coap gateway.
The gateway strips the link, network and coap information from the packet and sends the message to the Yd specified in table 1 with the (Yd, IPd) pair.
The gateway stores the source IP address with the destination YYY address in table 2 as pair (IPs, Yd). When an answer is returned from Yd, the gateway
creates a new coap packet with the destination address, IPs, as found in table 2 and sends it on to the yyy/coap host, IPs. </t>
<t hangText="- "> The packet contains a XXX network address.
In the gateway two tables are maintained. Table 1 contains a mapping from XXX network addresses to INI for all XXX devices.
Table 2 contains a mapping from IP addresses to XXX network addresses for IP devices. The xxx/coap host with IP address, IPs, sends a request to the INI, IPd,
of the specified XXX device with network address Xd. The packet is routed to the coap gateway. The gateway strips the link, network and coap information from the packet and sends
the message to the Xd specified in table 1 with the (Xd, IPd) pair with as source Xs as specified in table 2 with the (Xs, IPs) pair. When an answer is returned
from Xd to Xs, the gateway creates a new coap packet with the destination address, IPs, as found in table 2 with the (IPs, Xs) pair and with source address IPd
as found in table 1 with (Dd, IPd) pair. The gateway sends the answer on to the xxx/coap host, IPs. </t>
</list>
<t>
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).
</t>
</section>
<section title="Commissioning CoAP devices" anchor="sect-5.3">
<t>
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.
</t><t>
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.
</t><t>
Design decision: A commissioning tool with access to the network is used for the commissioning phase.
</t><t>
For example, dependent on used technology and production process, the following situation
(state) exists in a host after physical installation of the devices:
</t>
<list style="hanging">
<t hangText="- ">A given host is unaware of its Location.</t>
<t hangText="- ">A given host knows its ServiceType and Instance. The Instance is also readable by bar code reader.</t>
<t hangText="- ">The commissioning tool knows all Location's to which hosts need to be assigned.</t>
<t hangText="- ">A DHCP server (neigbor discovery) provided each host with a (link-local) IP address.</t>
</list>
<t>
Consider the commissioning process (1) with a central DNS-SD server and (2) without a central server using mDNS.
</t>
<section title="DNS-SD server present" anchor="sect-5.3.1">
<t>
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:
</t>
<list style="hanging">
<t hangText="- ">Each node asks the DNS-SD server the authority belonging to its barcode.</t>
<t hangText="- ">Each node updates the authority in the DNS-SD server with its IP address.</t>
<t hangText="- ">Each node appends for each resource the path name to the authority and inserts
it into the DNS-SD server with its IP address.</t>
</list>
<t>
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
</t>
</section>
<section title="DNS-SD server not present" anchor="sect-5.3.2">
<t>
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.
</t>
</section>
</section>
</section>
<section title="Conclusions" anchor="conclusions">
<t>
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).
</t><t>
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 <xref target="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.
</t><t>
DNS-SD <xref target="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.
</t><t>
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.
</t>
</section>
<section title="Security considerations" anchor="sec">
<t>
TBD: The detailed CoAP security analysis needs to encompass scenarios for building
control applications.
</t><t>
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.
</t><t>
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.
</t>
</section>
<section title="IANA considerations" anchor="iana">
<t>
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.
</t>
</section>
<section title="Acknowledgements" anchor="ack">
<t>
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.
</t>
</section>
<section title="Changelog" anchor="change">
<t>
From bc-01 to bc-02
</t><t>
- Removed all references to multicast and multicast scope, given draft of rahman group communication.
</t><t>
- Adapted examples to coap-2 and core-link drafts.
</t><t>
- transport short URL for destination recognition.
</t><t>
- Elaborated legacy discovery under DNS-SD.
</t><t>
</t><t>
From bc-02 to bc-03
</t><t>
- Elaboration on gateways, commissioning and legacy networks.
- Recommendation to extend DNS-SD naming with sn, st, and ss attributes.
</t>
</section>
</middle>
<back>
<references title="Normative References">
<!-- Define IETF entities at the beginning. -->
&RFC1034;
&RFC1123;
&RFC2119;
&RFC2616;
&RFC2782;
&RFC3306;
&RFC3307;
&RFC3596;
&RFC3629;
&RFC3956;
&RFC3986;
&RFC4944;
&RFC5198;
&RFC5785;
&RFC5790;
</references>
<references title="Informative References">
<!-- Define IETF entities at the beginning. -->
&I-D.cheshire-dnsext-dns-sd;
&I-D.cheshire-dnsext-multicastdns;
&I-D.ietf-core-coap;
&I-D.ietf-core-link-format;
&I-D.martocci-6lowapp-building-applications;
&I-D.rahman-core-groupcomm;
<reference anchor="BACnet">
<front>
<title abbrev="BACnet">BACnet/IP</title>
<author initials="J." surname="Bender" fullname="Joel Bender">
</author>
<author initials="M." surname="Newman" fullname="Mike Newman">
</author>
</front>
<seriesInfo name="Web" value="http://www.bacnet.org/Tutorial/BACnetIP/index.html"/>
</reference>
<reference anchor="ZigBee">
<front>
<title abbrev="ZigBee">A UDP/IP Adaptation of the ZigBee Application Protocol</title>
<author initials="G." surname="Tolle" fullname="Gilman Tolle">
</author>
<date month="October" year="2008"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-tolle-cap-00"/>
</reference>
<reference anchor="LON">
<front>
<title abbrev="LON">LONTalk protocol specification, version 3</title>
<date year="1994"/>
</front>
</reference>
<reference anchor="DALI">
<front>
<title abbrev="DALI">DALI Manual</title>
<date year="2001"/>
</front>
<seriesInfo name="Web" value="http://www.dali-ag.org/c/manual_gb.pdf"/>
</reference>
<reference anchor="KNX">
<front>
<title abbrev="DALI">AN OPEN APPROACH TO EIB/KNX SOFTWARE DEVELOPMENT</title>
<author initials="W." surname="Kastner" fullname="Wolfgang Kastner">
</author>
<author initials="G." surname="Neugschwandtner" fullname="Georg Neugschwandtner">
</author>
<author initials="M." surname="Koegler" fullname="Martin Koegler">
</author>
<date year="2005"/>
</front>
<seriesInfo name="Web" value="http://www.auto.tuwien.ac.at/~gneugsch/fet05-openapproach-preprint.pdf"/>
</reference>
<!-- Patterned after http://xml.resource.org/public/rfc/bibxml2/_reference.IEEE.802-3.1998.xml -->
<reference anchor="IEEE.802.15.4" target="http://standards.ieee.org/getieee802/802.15.html">
<front>
<title>
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)
</title>
<author/>
<date year="2006" month="June"/>
</front>
<seriesInfo name="IEEE" value="Std 802.15.4-2006"/>
</reference>
<reference anchor="oBIX">
<front>
<title abbrev="oBIX">oBIX working group</title>
<date year="2003"/>
</front>
<seriesInfo name="Web" value="http://www.obix.org"/>
</reference>
<reference anchor="Fielding">
<front>
<title abbrev="Fielding">Architectural Styles and the Design of Network-based Software Architectures, Second Edition</title>
<author initials="R." surname="Fielding" fullname="Roy Thomas Fielding">
</author>
<date year="2000"/>
</front>
<seriesInfo name="Doctoral dissertation" value=""/>
<seriesInfo name="University of California, Irvine" value=""/>
<seriesInfo name="Web" value="http://www.ics.uci.edu/~fielding/pubs/dissertation/top.html"/>
</reference>
</references>
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-23 08:48:32 |