One document matched: draft-vanderstok-core-bc-04.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">
<!ENTITY I-D.shelby-core-resource-directory SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.shelby-core-resource-directory.xml">
<!ENTITY I-D.lynn-core-discovery-mapping SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.lynn-core-discovery-mapping.xml">
<!ENTITY I-D.lynn-dnsext-site-mdns SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.lynn-dnsext-site-mdns.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-04">
<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 34-1</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="11" month="July" 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.
</t><t>
The authority portion of the URI is used to identify a device (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><t>
It is shown that DNS-based service discovery 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) service discovery is complementary to resource discovery and
facilitates control network scaling, and 2) 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,
</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>
A CoAP end-point, or server, is identified by a unique {IP address, port}
tuple. A server is completely specified by the authority part of
a URI.
</t><t>
A device is the physical object that is connected to the network. A
device may host one or more CoAP servers.
</t><t>
A service (in the service discovery sense) is a related set of
resources on a CoAP server. A URI completely specifies the syntax of a service interface.
Metadata describe the semantics of the service
interface. The semantics may include the relation between service and the hardware connected to the device.
A CoAP server may expose one or more services.
</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 for a network of devices 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 automation 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 devices in a typical building control application is resource
constrained, making the standardization of a lightweight application protocol like
CoAP a necessary requirement for IP to penetrate the device market.
The low energy consumption requirement of battery-less
devices reinforces this approach.
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 a physical medium
for data objects and function invocation. Many of these industry
standards also specify 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 properties can be summarized as:
</t>
<texttable style="none">
<ttcol> - </ttcol> <ttcol> Generate small payloads. </ttcol>
<c> - </c> <c> Compatible with legacy standards (e.g. LON, BACnet, DALI, ZigBee Device Objects).</c>
<c> - </c> <c> Service/resource discovery in agreement with legacy standards and naming conventions. </c>
</texttable>
<t>
This submission defines 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
encapsulates 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 devices that is targeted. A group scope may be defined as
link-local, as a tree maintained by an IP-multicast protocol, 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 group properties are:
</t>
<texttable style="none">
<ttcol> - </ttcol> <ttcol> Devices may be part of one or more groups. </ttcol>
<c> - </c> <c> Resources addressed by a group must be uniformly and consistently named across all targeted devices.</c>
</texttable>
<t>
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
devices in several building areas by devices inside or outside the building,
and humans may intervene to change control settings. This I-D compares
commercial building solutions with solutions for the home.
</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 scheme is implicit from
the perspective of the service, but it indicates the protocol
used to access the service to potential clients.
</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 device or group of devices, 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
device 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 authority resolves to a {IP-address, port} tuple. The IP-address may be
either unicast or multicast. The authority therefore identifies an individual
server or a named group of servers.
</t><t>
The CoAP spec <xref target="I-D.ietf-core-coap" /> states "When a CoAP server is
hosted by a 6LoWPAN device, 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 there is no assurance that a CoAP server will consistently
acquire the same dynamic port and different {IP-address, port} tuples
conventionally represent different servers.
</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 device within the building. Arriving at the
device 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. //device-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 can lead to rather verbose URI strings in the packet, contrary
to the small packet assumption. 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,
naming authorities for building control 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>
The path identifies the addressable attributes of the service at the highest possible granularity.
A set of paths defines the syntax of the service invocation and constitutes the interface description
of the service.
Every network service attribute is completely identified by a URI
scheme://authority/path. In analogy, the path part of the URI specifies
the resource of a given server. The naming of the services and
their associated attributes are typically subjects for standardization.
There is no widely accepted standard for uniformly naming building control
services in a URI. A vigorous effort is undertaken by the oBIX working group of OASIS
<xref target="oBIX" />, but its current impact is limited. There is also
an open source point naming effort underway called Project Haystack <xref target="HAYSTACK" />.
</t><t>
The path is constructed like a file system path name. It consists of a sequence of one or more name fields,
with each field preceded with a slash, like /func1/subf2/final.
The set of paths is structured as a tree. The last name in a name field sequence
is called a leave of the tree, and the authority is the root of the path tree of a given host.
The semantics of a given sub-tree in the path tree is specified by the Interface Description (if=)
attribute described in <xref target="I-D.ietf-core-link-format" />. As for file systems some tree naming
with associated semantics can be standardized
such as the de facto PC standard directory "documents and settings" with the sub-directories "My documents",
"usradmin", etc. When a given body, e.g. XXX, has defined a name structure and semantics for the path tree,
we say that "if = XXX" for the path tree conforms to the name structure defined by XXX.
</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 server with name t-sensor1 exists, provides a service of
a given standard type (with associated semantics) (e.g. ZigBee temperature sensor), and that this
standard type has the readable attribute: temperature. When commands are sent
to a group of servers it MUST be the case that
the targeted resource has the same path on all targeted servers. 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>
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 path-names that may occur under this prefix. The same
body also defines the "if=XXX" attribute. This
allows the standards development organization responsibile for XXX to
define the name space and resources associated with the prefix together with the associated semantics. The
registered /.well-known/XXX URI effectively defines a standard object model,
or schema, for services of the XXX application protocol. Manufacturers may optionally define proprietary resources
that can be discovered dynamically using methods described below.
</t><t>
Although the authority part names need not always be transported, the path names MUST be transported
in the CoAP packets. Therefore, it is advisable to make the resource names as short as
possible, even at the detriment of the clarity of the meaning of the path name.
</t>
</section>
</section>
<section title="Group Naming and Addressing" anchor="sect-3">
<t>
Within building control it is necessary to send the same command
to a set of servers or devices. Grouping allows to invoke the set of services with one
application command to be executable within a specified time interval.
Given a network configuration, 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 device groups become:
</t>
<texttable style="none">
<ttcol> URI authority </ttcol> <ttcol> Targeted group </ttcol>
<c> //all.bldg6... </c> <c> "all devices in building 6"</c>
<c> //all.west.bldg6... </c> <c> "all devices in west wing, building 6" </c>
<c> //all.floor1.west.bldg6... </c> <c> "all devices on floor 1, west wing, ..." </c>
<c> //all.bu036.floor1.west.bldg6... </c> <c> "all devices in office bu036, ..." </c>
</texttable>
<t>
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 devices 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 a multicast 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 a 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
device. 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 is 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 devices. Group membership may be managed by a protocol
such as Multicast Listener Discovery <xref target="RFC5790" />.
</t><t>
Similarly, a group can identify a set of services on one device. For examples a device contains
four I/O channels. The device hosts one server which provides four services to access each of the
four individual channels separately. Commonly, it is also required to access a subset of all four channels
simultaneously. An additional path identifies the group of services. An example set of services and service-group becomes:
</t>
<texttable style="none">
<ttcol> URI path </ttcol> <ttcol> Targeted group </ttcol>
<c> /IOchannel/channel1... </c> <c> "channel 1 of the IO channel device " </c>
<c> /IOchannel/channel2... </c> <c> "channel 2 of the IO channel device " </c>
<c> /IOchannel/channel3... </c> <c> "channel 3 of the IO channel device " </c>
<c> /IOchannel/channel4... </c> <c> "channel 4 of the IO channel device " </c>
<c> /IOchannel/group1-3... </c> <c> "channel 1 to 3 of the IO channel device " </c>
</texttable>
<t>
A group defines a set of servers or a set of service attributes.
Grouping of the service attributes is provided by the device manufacturer.
Grouping of the services is supported by DNS and multicast protocols.
The multicast address(es) identify the servers belonging to the group.
A given server might belong to a number of groups.
For example the server 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". From the perspective of a server, the main
consequence of joining a group is 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 infrastructure but not necessarily on the low-resource
destinations or sources. Assuming that resolution of addresses only happens at device start-up, the
complexity of the DNS server need not affect the responsiveness of the devices.
</t><t>
In summary, the authority portion of the URI resolves to an IP-address and port number, and identifies a server
or group of servers.
Authority naming is building or organization dependent, must be flexible, and does not require
standardization efforts but SHOULD conform to some uniform convention. Path naming SHOULD conform
to the naming convention of a standardization body.
</t>
</section>
<section title="Discovery" anchor="sect-4">
<section title="Service discovery goals" anchor="sect-4.1">
<t>
Service discovery in building control should rely on a minimal need for intervention by humans
(or complete absence of humans)
during system setup, bootstrapping, restart, configuration and daily operation.
The goals for service discovery area:
</t>
<texttable style="none">
<ttcol> Goal </ttcol> <ttcol> Goal description </ttcol>
<c> Return_instance </c> <c> Return all instances of a given service type within a given domain</c>
<c> Group_instance </c> <c> Group a set of instances within a group associated with a domain </c>
<c> Instance_resolution </c> <c> Resolve the instance name to usable invocation information (e.g. IP address and port) </c>
<c> Group_resolution </c> <c> resolve the group name to usable invocation information (e.g. IP address and port) </c>
</texttable>
<t>
These goals are necessary to support the operation of commercial building control. Returning the instances
results in a list of names. For building control these names can be any sequence of characters as long as
for each service instance these names are unique within the domain. In <xref target="I-D.cheshire-dnsext-dns-sd" />
the office equipment in the IT domain is recommended to use understandable and human-readable names.
The Home domain may have a need for human understandable names. This is not the case for the commercial
building automation domain. However,
uniqueness of the name is necessary for the application
that needs to address the service interface on the devices in a consistent manner.
Given the large number of devices in a building (several hundreds to thousands) scaling is an important aspect of the
service discovery. A set of central DNS servers will provide the scalability. The expectation is that names need to be
managed consistently by a central authority which can be supported by the DNS server. Tools will assist the installer
and operator of the network to do the installation, configuration and maintenance of the network structure. Small
devices will use the DNS server to learn the communication partners providing a given service within their domain
and to resolve the IP addresses of the communication partners.
</t><t>
Within the home it is more important that
the names convey the purpose of the service to the user reading the names and selecting his favored service instance.
Non-unique names, although confusing, can probably be handled by the user of these names. Scalability is less of an issue
because a smaller number of devices is implicated. The network in the home is probably more dynamic
than its commercial counter-part, with
many movements of devices and arrival or removal of devices.
</t><t>
Section 5 presents some examples of DNS structures to show how the choice of names influences the
granularity of the discovery. In sections 5.1 and 5.3 a grouping example and a commissioning example, filling the DNS,
are presented.
</t>
</section>
<section title="DNS-Based Service Discovery" anchor="sect-4.2">
<t>
DNS-Based Service Discovery (DNS-SD) defines a conventional way to
configure DNS PTR, SRV, and TXT records to facilitate discovery of
services 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>.
</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 device or
group and may identify a building zone as in the examples above.
</t><t>
The ServiceType is composed of multiple parts: 1) the IP protocol part, 2) the application or
service type of the defining organization (e.g. ZigBee HomeAutomation),
and optionally 3) the subtype of the service (e.g. temperature sensor). The ServiceType
SHOULD have the form [_subtype._sub.]_type._proto. The _proto identifier provides
a transport protocol hint as required by the SRV record definition <xref target="RFC2782" />
and, in the case of CoAP, it is always "_udp".
The _type identifier is determined by standards development organization (SDO) and
MUST be registered with dns-sd.org <xref target="dns-sd" />. The SDO is then free
to specifiy one or more _subtype identifiers, which must be unique for a given _type.
The _subtype and _type labels are separated by the literal "._sub" label.
</t><t>
A PTR record with
the label "_type._proto" is defined for each end-point in a selected domain,
and this record's value is set to the service instance name (which
in turn identifies the SRV and TXT records for the CoAP end-point).
Assuming that the DALI organization defines _type as "dali" and _proto as "udp" for its CoAP binding,
PTR records with the label "_dali._udp" are stored in DNS-SD. Assuming ZigBee HomeAutomation defines
_type as "HomeAutomation", PTR records with label "_HomeAutomation._udp" are stored.
This approach permits DNS-SD to return all services pertaining to HomeAutomation or DALI.
</t><t>
DNS-SD also supports one level of subtype, which can be used to locate
services based on the object model (schema) of a given standard. <xref target="I-D.cheshire-dnsext-dns-sd" />
suggests to separate the subtype from the service by _sub.
For example: _AI._sub._bacnet._udp
for an Analog Input object of BACnet or
_lamp._sub._dali._udp for a lamp type of DALI.
The maximum length
of the type and subtype fields is 14 octets, but shorter names are encouraged to reduce packet sizes.
</t><t>
The Instance part of the service name may be changed during the
commissioning process. It must be unique for a given ServiceType 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 server level, or it could represent a particular resource (service interface)
within a CoAP device. 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 MUST be placed in the TXT record (PATH=).
</t>
</section>
<section title="Service vs Host Names" anchor="sect-4.3">
<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 a canonical host name plus a
listening socket. An optional TXT record may be configured
with the 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 a
service interface (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><t>
TODO: Kerry: this last line needs quite some explanations !!!!
</t>
</section>
<section title="Browsing for Services" anchor="sect-4.4">
<t>
Devices in a given Location with given ServiceType, _type._proto, may be enumerated by sending a DNS query for
PTR records named _type._proto to the authoritative server for that zone associated with the Location. A list of
names for SRV records matching that ServiceType.Location is returned. Each SRV
record contains the host name and port of a CoAP server. The IP address of the
device 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 standardized resources identified by IF=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.
For example: A query is sent to DNS-SD to return all DALI lamps within the domain office5/mybuilding
and with ServiceType: _lamp._sub._dali._udp. DNS-SD returns
the list of all SRV records and AAAA records of the devices within the domain
providing the wanted service.
</t>
</section>
<section title="Resource vs Service Discovery" anchor="sect-4.5">
<t>
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 resources (path-names) within a 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 available from the server.
These links may describe resources hosted on that server or on other servers.
</t><t>
Assuming the ability to multicast the GET over the site 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, and the ServiceType,
while using some means to establish in which subdomain the service
should be registered
</t><t>(TBD).
</t><t> 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" />.
The values stored in the DNS-SD directory are extracted from the information stored in the
resource directory associated with a set of CoAP hosts <xref target="I-D.shelby-core-resource-directory" />.
The resources describe how the services can be manipulated in detail and in concreto.
</t><t>
It is assumed that a resource directory exists per 6LoWPAN <xref target="RFC4944" />, possibly running on the edge router.
The DNS-SD provides a larger scope by storing the info of all services over a set of interconnected 6LoWPANs.
Where the resource directory is possibly completely adequate for home networks, handling of multiple
resource directories can be quite cumbersome for the many 6LoWPANs envisaged for offices.
However, during network configuration, the resource directory can be used as long as
the DNS is not yet accessible.
</t><t>
The DNS-SD approach is complementary to the more fine-grained resource discovery,
fits better the concept of discovering devices with given properties (services).
DNS-SD supports a hierarchical approach to the naming of the services as discussed in section 3.
DNS-SD provides a directory structure that scales well with the network size as shown
by its present-day operation.
</t>
</section>
</section>
<section title="DNS record structure" anchor="sect-5">
<t>
An example is presented which explains the Resource Record (RR) structure on the DNS server.
This section follows the mapping specified in <xref target="I-D.lynn-core-discovery-mapping" />,
which defines how to fill the DNS-SD records from the link extension values.
Suppose the services
are delivered by ZigBee home automation devices. The example subtype- and context- names are assumed
to be standardized by the ZigBee alliance.
All devices are situated in one office with location office4.bldg8.example.com.
The names in the examples are more verbose than recommended to make the examples more readable.
The table presents the services provided in the office control network:
</t>
<texttable style="none">
<ttcol> service </ttcol> <ttcol> ServiceType </ttcol> <ttcol> Number </ttcol>
<c> illumination </c> <c> _OnOff_light._sub._HomeAutomation._udp </c> <c> 4 </c>
<c> presence </c> <c> _occup_sensor._sub._HomeAutomation._udp </c> <c> 1 </c>
<c> temperature </c> <c> _temp_sensor._sub._HomeAutomation._udp </c> <c> 1 </c>
<c> shading </c> <c> _shade_control._sub._HomeAutomation._udp </c> <c> 1 </c>
</texttable>
<t>
For every service there is a PTR record stored, with as label the ServiceType, that points to the service instances.
The unique Instance names identify the service instances. The unique names are represented
as id-x, with x in natural numbers. They are usually created at the factory floor
and somehow attached to the product. The ServiceTypes have been suffixed with .04.8 to represent office4 in building8.
</t>
<texttable style="none">
<ttcol> _OnOff_light._sub._HomeAutomation._udp.04.8 </ttcol> <ttcol> PTR </ttcol> <ttcol> id-1._OnOff_light </ttcol>
<c> _OnOff_light._sub._HomeAutomation._udp.04.b8 </c> <c> PTR </c> <c> id-2._OnOff_light </c>
<c> _OnOff_light._sub._HomeAutomation._udp.04.b8 </c> <c> PTR </c> <c> id-3._OnOff_light </c>
<c> _OnOff_light._sub._HomeAutomation._udp.04.b8 </c> <c> PTR </c> <c> id-4._OnOff_light </c>
<c> _occup_sensor._sub._HomeAutomation._udp.04.b8 </c> <c> PTR </c> <c> id-5._occup_sensor </c>
<c> _temp_sensor._sub._HomeAutomation._udp.04.b8 </c> <c> PTR </c> <c> id-6._temp_sensor </c>
<c> _shade_control._sub._HomeAutomation._udp.04.b8 </c> <c> PTR </c> <c> id-7._temp_sensor </c>
</texttable>
<t>
In the above example the id-x identifiers without the subtype suffix would be
discriminating enough.
</t><t>
Discovery can be done with the following results. A query with the following argument returns
</t>
<texttable style="none">
<ttcol> query argument </ttcol> <ttcol> result list </ttcol>
<c> .04.8 </c> <c> id-1._OnOff_light </c>
<c> </c> <c> ....... </c>
<c> </c> <c> id-7._temp_sensor </c>
<c> _HomeAutomation._udp.04.b8 </c> <c> id-1._OnOff_light </c>
<c> </c> <c> ....... </c>
<c> </c> <c> id-7._temp_sensor </c>
<c> _OnOff_light._sub._HomeAutomation._udp.04.b8 </c> <c> id-1._OnOff_light </c>
<c> </c> <c> ....... </c>
<c> </c> <c> id-4._OnOff_light </c>
<c> _occup_sensor._sub._HomeAutomation._udp.04.b8 </c> <c> id-5._occup_sensor </c>
</texttable>
<t>
When other offices are included in the database, the query argument 04.b8 selects those entries
which are associated with office4 in building8 and rejects any others. The example shows clearly
the query granularity that can be obtained
and the care that must be exercised when defining the names of the ServiceTypes.
</t><t>
The unique identifiers suffixed with their subtype are the labels of the SRV, AAAA and TXT
records describing the service instance. The SRV record specifies the location (authority) and the port number.
In the authority o4.b8 refers to office4 in building8.
The AAAA record specifies the IP-address, while the TXT record specifies the subtype and the data representation
of the legacy parser (IF = ZigBee).
</t>
<texttable style="none">
<ttcol> id-1._OnOff_light </ttcol> <ttcol> SRV </ttcol> <ttcol> light1.o4.b8.example.com </ttcol> <ttcol> Port-x </ttcol>
<c> </c> <c> AAAA </c> <c> FDFD::1234 </c> <c> </c>
<c> </c> <c> TXT </c> <c> IF=ZigBee </c> <c> </c>
<c> id-2._OnOff_light </c> <c> SRV </c> <c> light2.o4.b8.example.com </c> <c> Port-x </c>
<c> </c> <c> AAAA </c> <c> FDFD::1235 </c> <c> </c>
<c> </c> <c> TXT </c> <c> IF=ZigBee </c> <c> </c>
<c> id-3._OnOff_light </c> <c> SRV </c> <c> light3.o4.b8.example.com </c> <c> Port-x </c>
<c> </c> <c> AAAA </c> <c> FDFD::1236 </c> <c> </c>
<c> </c> <c> TXT </c> <c> IF=ZigBee </c> <c> </c>
<c> id-4._OnOff_light </c> <c> SRV </c> <c> light4.o4.b8.example.com </c> <c> Port-x </c>
<c> </c> <c> AAAA </c> <c> FDFD::1237 </c> <c> </c>
<c> </c> <c> TXT </c> <c> IF=ZigBee </c> <c> </c>
<c> id-5._occup_sensor </c> <c> SRV </c> <c> occup.o4.b8.example.com </c> <c> Port-x </c>
<c> </c> <c> AAAA </c> <c> FDFD::1238 </c> <c> </c>
<c> </c> <c> TXT </c> <c> IF=ZigBee </c> <c> </c>
<c> id-6._temp_sensor </c> <c> SRV </c> <c> temp.o4.b8.example.com </c> <c> Port-x </c>
<c> </c> <c> AAAA </c> <c> FDFD::1239 </c> <c> </c>
<c> </c> <c> TXT </c> <c> IF=ZigBee </c> <c> </c>
<c> id-7._shade_control </c> <c> SRV </c> <c> shade.o4.b8.example.com </c> <c> Port-x </c>
<c> </c> <c> AAAA </c> <c> FDFD::1240 </c> <c> </c>
<c> </c> <c> TXT </c> <c> IF=ZigBee </c> <c> </c>
</texttable>
<t>
It is possible that the temperature sensor and occupancy sensor are delivered on one device.
The consequence is that one device hosts two services. In the DNS table the four lights and the
shade controller are unaffected. However, the PTR records with the occupancy and temperature sensor
point to the same unique identifier id-8 that is suffixed with the name of the subtype. This example
shows that the subtype suffix
is needed to discriminate between the two services.
</t>
<texttable style="none">
<ttcol> _occup_sensor._sub._HomeAutomation._udp </ttcol> <ttcol> PTR </ttcol> <ttcol> id-8._occup_sensor </ttcol>
<c> _temp_sensor._sub._HomeAutomation._udp </c> <c> PTR </c> <c> id-8._temp_sensor </c>
</texttable>
<t>
Two SRV records with accompanying AAAA and TXT records describe the two servers, each providing one service, in more detail.
The servers share the same IP address but are connected to different ports, and do have a different paths names.
The TXT record is used to specify the path part with "PATH=".
</t>
<texttable style="none">
<ttcol> id-8._occup_sensor </ttcol> <ttcol> SRV </ttcol> <ttcol> occup.o4.b8.example.com </ttcol> <ttcol> Port-x </ttcol>
<c> </c> <c> AAAA </c> <c> FDFD::1241 </c> <c> </c>
<c> </c> <c> TXT </c> <c> PATH=/os IF=ZigBee </c> <c> </c>
<c> id-8._temp_sensor </c> <c> SRV </c> <c> temp.o4.b8.example.com </c> <c> Port-y </c>
<c> </c> <c> AAAA </c> <c> FDFD::1241 </c> <c> </c>
<c> </c> <c> TXT </c> <c> PATH=/ts IF=ZigBee </c> <c> </c>
</texttable>
<t>
The path names /ts and /os are short names for temperature_sensor and occupancy_sensor respectively.
Not all multi-function devices will use different ports for the individual functions. It is also
quite common to use different IP interfaces with different IP addresses, reflected by the
value of the AAAA records.
</t>
<section title="DNS group example" anchor="sect-5.1">
<t>
Another aspect is the grouping of servers. Where in the former section the names of the services are standardized names,
this is less probable for the group names. Usually the group names are application specific or are standardized
at the manufacturer.
For example, assume that a group all-light.o4.b8.example.com is created which contains all four lights
inside office4. The accompanying ServiceType can be defined as _all_light._sub._HomeAutomation._udp. The use
of HomeAutomation is taken although _all_light is not a supported service within HomeAutomation profile.
The ServiceType suffixed with 04.b8 points to a unique identifier defined as _all_light.04.b8, assuming that this
is the only _all_light group within office 4 of building 8. The PTR record looks like:
</t>
<texttable style="none">
<ttcol> _all_light._sub._HomeAutomation._udp.04.b8 </ttcol> <ttcol> PTR </ttcol> <ttcol> _all_light.04.b8 </ttcol>
</texttable>
<t>
It is assumed that the group all_light.o4.b8.example.com has received a multicast address: FF1E::148.
The accompanying SRV, AAAA, and TXT RR become:
</t>
<texttable style="none">
<ttcol> _all_light.04.b8 </ttcol> <ttcol> SRV </ttcol> <ttcol> all_light.o4.b8.example.com </ttcol> <ttcol> Port-z </ttcol>
<c> </c> <c> AAAA </c> <c> FF1E::148 </c> <c> </c>
<c> </c> <c> TXT </c> <c> IF=ZigBee </c> <c> </c>
</texttable>
<t>
In some cases it may be desirable to show all hosts which are part of the multicast group.
This can be done using the PTR records which point to the authorities of the associated hosts.
The AAAA records provide the IP addresses of the hosts.
</t>
<texttable style="none">
<ttcol> all_light.o4.b8.example.com </ttcol> <ttcol> PTR </ttcol> <ttcol> light1.o4.b8.example.com </ttcol>
<c> all_light.o4.b8.example.com </c> <c> PTR </c> <c> light2.o4.b8.example.com </c>
<c> all_light.o4.b8.example.com </c> <c> PTR </c> <c> light3.o4.b8.example.com </c>
<c> all_light.o4.b8.example.com </c> <c> PTR </c> <c> light4.o4.b8.example.com </c>
<c> light1.o4.b8.example.com </c> <c> AAAA </c> <c> FDFD::1234 </c>
<c> light2.o4.b8.example.com </c> <c> AAAA </c> <c> FDFD::1235 </c>
<c> light3.o4.b8.example.com </c> <c> AAAA </c> <c> FDFD::1236 </c>
<c> light4.o4.b8.example.com </c> <c> AAAA </c> <c> FDFD::1237 </c>
</texttable>
<t>
The entries in DNS can be used to form groups with the light weight group management protocol and multicast listener discovery
<xref target="RFC5790" />. In contrast to the earlier examples the name of the PTR record is a domain name
and not a ServiceType.
</t>
</section>
<section title="Operational use of DNS-SD" anchor="sect-5.2">
<t>
The populated DNS-SD server provides the necessary support for the applications to execute their
control loops with minimum operator support. The operation of the office network can be split up in phases.
In a first phase the network is commissioned, such that a relation is established between the IP address,
the servicetype and the domain. The servicetype can be extracted from the link-format as described in
<xref target="I-D.shelby-core-resource-directory" />.
After commissioning this information is stored in the DNS-SD files. In a second
phase groups are formed and group names with their IP address are stored in the DNS-SD files. The IP multicast
addresses are communicated to the members of the groups. In the third and final phase, applications query DNS-SD
to find the IP addresses of the services within a given domain, and of the groups within a given domain.
</t><t>
In the home, a commissioning phase requiring the intervention of an installer (a "truck roll") is to be avoided if possible. Here the first phase
consists of the booting up devices which insert their services resources to a link-format directory.
The information from the resource directory can be inserted into DNS-SD or into xmDNS <xref target="I-D.lynn-dnsext-site-mdns" /> when appropriate.
In the second phase remote controllers or other hand-held devices can be used to discover the services of a given type,
to group the services, and to store the group names into DNS-SD or xmDNS as appropriate. Pointing out the members of a group
can be in any kind of manner from typing members in, selecting them from a browser list, etc.
</t>
</section>
<section title="Commissioning CoAP devices" anchor="sect-5.3">
<t>
For clarity it is assumed in this section that a device hosts one server.
The URI of the device together with its service completely determines
the function of the device within the building. The authority part of the URI represents the location
of the host within the domain name space. Given the authority naming presented in section 2.2
the authority name represents the location of the host within the building.
</t><t>
Commissioning means the following three actions:
</t>
<texttable style="none">
<ttcol> - </ttcol> <ttcol> Defining the URI (location) </ttcol>
<c> - </c> <c> Assigning an IP address to the URI </c>
<c> - </c> <c> mapping the unique device identifier to the URI </c>
</texttable>
<t>
Two cases of the office network are considered
for commissioning: (1) no 6LBR and no DNS server connected, and (2) a 6LBR connects the office network 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 identify all these devices spatially and functionally.
Storing the triple Instance.ServiceType.Location into DNS-SD represents the commissioning process.
The Instance is the unique identifier given to the device in the factory but which has no relation
to its later location. The ServiceType together with the Location fully determine the semantics of the data
returned by the device.
</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:
<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 Locations to which hosts need to be assigned.</t>
<t hangText="- ">A DHCP server (neighbor discovery) provided each host with a (site-local) IP address.</t>
</list>
Consider the commissioning process (1) with a central DNS-SD server and (2) without a central server using xmDNS.
The commissioning processes described below are just examples and should not be taken as working
procedures for commissioning devices in a building.
</t>
<section title="DNS-SD server present" anchor="sect-5.3.1">
<t>
The installer reads with a bar code reader, attached
to the commissioning tool, the identifier of the device to commission.
It is assumed that the tool can learn the IP address of the device with the given identifier.
The tool displays on a screen the physical lay-out of the devices within the building.
The installer selects, on the screen of the
tool, the physical location of the chosen device. From the designated physical location the tool
creates the URI of the selected device.
The tool inserts the URI and the IP address into the DNS server.
For example the light with URI light1.o4.b8.example.com is represented with an AAAA record:
</t>
<texttable style="none">
<ttcol> light1.o4.b8.example.com </ttcol> <ttcol> AAAA </ttcol> <ttcol> FDFD::1234 </ttcol>
</texttable>
<t>
The tool reads the service name and type from the device using resource information stored
according to the link-format <xref target="I-D.ietf-core-link-format" />. With this information the
tool constructs the PTR, SRV and TXT records according to the example presented in section 5.
</t><t>
This is done for all devices
within a given part of the building.
After the commissioning process, all resources of each device have an URI and IP address which are stored in the
central DNS-SD server.
When devices are restarted, the DHCP server allocates IP addresses to the device 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 site) such that each device on a given segment can communicate directly with any
other device 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 site-local authorities and stored in the tool.
All devices are assumed to have selected a site-local IP address. Assume that every device has a
unique barcode within the building and that the corresponding device knows the bar code number.
The installer reads with a bar code reader, attached
to the tool, the Instance name 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 devices.
The device with the given barcode number, extends the authority with the path name of the resources.
For each resource, the device multicasts the site-local IP-address and the site-local URI to the
xmDNS servers in the connected devices. This concludes the commissioning of a network segment.
All resources of each device have a site-local URI and a site-local IP address which are stored in the xmDNS servers.
</t>
</section>
</section>
<section title="Proxy discovery" anchor="sect-5.4">
<t>
Proxies will be used in CoAP networks for at least two major reasons: (1) http/coap proxy, and (2)
proxy of service on battery-less device. The first proxy is probably implemented as forward
proxy, while the latter is probably implemented as backward proxy.
The battery-less device will at rare occasions (when it is not sleeping) and during installation answer the GET /.well-known/core
request. The return data are used by the installation tool to make the proxy device
return the same resource names on /.well-known/core as is returned by the sleeping device.
An installation tool installs on the proxy all the resources of the sleeping
device for which the proxy is assumed to answer.
Each resource on the proxy is informed of the service name of the sleeping device by the installation tool.
Consequently, the proxy is discovered as a multi-service host with as many path names as it proxies sleeping services.
The services of the sleeping devices should not be discoverable via DNS-SD.
However, AAAA records are generated for the sleeping device host name. This host name is used by the proxy
to subscribe to the services of the sleeping device.
For example assume two sleeping devices, an occupancy sensor and a temperature sensor, and one proxy.
Two service types are defined with PTR records in DNS-SD. The identifier id-1 of the proxy is used by the installation
tool to define the Instances.
</t>
<texttable style="none">
<ttcol> _occup_sensor._sub._HomeAutomation._udp.04.b8 </ttcol> <ttcol> PTR </ttcol> <ttcol> id-1._occup_sensor </ttcol>
<c> _temp_sensor._sub._HomeAutomation._udp.04.b8 </c> <c> PTR </c> <c> id-1._temp_sensor </c>
</texttable>
<t>
Two SRV records with accompanying AAAA and TXT records describe the two services in more detail.
The services share the same IP address, are connected to the same port, but do have different paths names.
The TXT record is used to specify the path part with "PATH=".
</t>
<texttable style="none">
<ttcol> id-1._occup_sensor </ttcol> <ttcol> SRV </ttcol> <ttcol> proxy.o4.b8.example.com </ttcol> <ttcol> Port-x </ttcol>
<c> </c> <c> AAAA </c> <c> FDFD:: 1241 </c> <c> </c>
<c> </c> <c> TXT </c> <c> PATH=/os IF=ZigBee </c> <c> </c>
<c> id-1._temp_sensor </c> <c> SRV </c> <c> proxy.o4.b8.example.com </c> <c> Port-x </c>
<c> </c> <c> AAAA </c> <c> FDFD:: 1241 </c> <c> </c>
<c> </c> <c> TXT </c> <c> PATH=/ts IF=ZigBee </c> <c> </c>
<c> sl-ts.o4.b8.example.com </c> <c> AAAA </c> <c> FDFD::1242 </c> <c> </c>
<c> sl-os.o4.b8.example.com </c> <c> AAAA </c> <c> FDFD::1243 </c> <c> </c>
</texttable>
<t>
The path names /ts and /os are short names for temperature_sensor and occupancy_sensor respectively and were taken over from
link-format information contained in the sleeping devices. Two AAAA records are provided for the two sleeping devices.
The proxy has used the domain names of the sleeping devices to subscribe to the publications of the two sleeping devices.
</t>
<t>
It is important to remark that there are now two services with the same resources present on two different devices:
the sleeping device and its proxy. When a host invokes the /.well-known/core resource, it should be possible to distinguish
between the proxy (to be invoked) and the sleeping device (not to be invoked). The distinction is necessary once the sleeping
device is discoverable and the sleeping device is awake from time to time. It is suggested that the link-format syntax
allows to make this distinction.
</t>
</section>
</section>
<section title="Legacy data Representations in CoAP" anchor="sect-6">
<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-6.1">
<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>
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 devices -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
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 device returns data to the requesting zzz;yyy CoAP
host via the same gateway.
</t><t>
The CoAP hosts can address the legacy devices
behind the gateway in at least 4 ways.
<list style="hanging">
<t hangText="- ">All devices of legacy network YYY share the URI-host with the CoAP gateway.
Every legacy device 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 device.</t>
<t hangText="- ">All devices 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 device. The routing protocol
on the CoAP network makes the message
arrive at the CoAP gateway. The gateway determines the specified legacy device from the destination IP address.</t>
<t hangText="- ">All devices of legacy network YYY have different authorities. This means that the possibly
lengthy authority names need to be transmitted. The gateway recognizes the authorities and maps authority to legacy device.</t>
<t hangText="- ">All devices of legacy network YYY have different ports. This can be expressed in two ways (1) as :port in the URI,
or (2) 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>
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 device 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 service (See figure 2).
The resource path /.well-known/ZZZ identifies the
parser of the ZZZ syntax. A 12 octet string 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 in the UDP header (not shown).
</t>
<figure title="Figure 2: Sending a ZZZ command with CoAP to CoAP/ZZZ device">
<artwork>
<![CDATA[
Client CoAP/ZZZ
| device
| REQUEST |
|-------- CON [0x5577] PUT /.well-known/ZZZ -------->|
| binary 12 octet string |
| |
| RESPONSE |
|<---------- ACK [0x5577] 2.00 OK ----------------- |
| |
]]>
</artwork>
</figure>
<t>
An example of an invocation of a DALI legacy device behind a gateway is given in figure 3.
The resource path /.well-known/DALI identifies the DALI device.
The application sets a value of 200 in the DALI
device in the attribute 256 defined by the DALI spec.
</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>
</section>
<section title="Gateways to legacy networks" anchor="sect-6.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 device.
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-device-identifier (INI) can be (1) the IP-address, (2) the IP-address, port number, (3) the URI, or (4) the path .
<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>
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="Discovery of legacy gateways" anchor="sect-6.3">
<t>
Discovery of legacy gateways is not very different from discovery of proxies in section 5.4. the consequences
for discovery are listed for the four modes of addressing legacy devices via a gateway of section 6.1.
<list style="hanging">
<t hangText="- ">The gateway presents a list of resources representing the legacy devices. Discovery
is done as for other CoAP devices.</t>
<t hangText="- "> Each legacy device has a different IP address. The gateway must create entries in the DNS for as many legacy devices.
The authority of the legacy device
is the authority of the gateway with a ServiceType to be specified by the gateway.</t>
<t hangText="- ">All devices of legacy network YYY have different authorities.
In this case each legacy device has the same IP address as the gateway. The gateway must create entries in the DNS for as many legacy devices.</t>
<t hangText="- ">All devices of legacy network YYY have different ports. The gateway must create entries in the DNS for as many legacy devices.
Each entry has the authority of the gateway with a different ServiceType and a different port number.</t>
</list>
</t>
</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
naming can be used to express this hierarchy
in the authority portion of the URI, down to the group or device 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 device(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 URI to distinguish
between resources on a given device, 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 6LoWPAN. 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 device, locate CoAP devices by subtype, or bind
service names for particular CoAP URIs.
</t><t>
This I-D discusses the addressing, discovery and naming of legacy devices behind gateways.
The discovery of backward proxies of sleeping devices is handled in a similar fashion.
</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
devices. 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.
</t><t>
- Recommendation to extend DNS-SD naming with sn, st, and ss attributes.
</t><t>
</t><t>
From bc-03 to bc-04
</t><t>
- moved core link extension sub-section to resource directory draft
</t><t>
- extended use of service type
</t><t>
- gave DNS record examples and worked out multifunction device
</t><t>
- added proxy discovery and legacy gateway discovery
</t><t>
- defined path tree and corresponding schema
</t><t>
- reviewed definition of server, service, device, service attribute, and resource
</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;
&I-D.shelby-core-resource-directory;
&I-D.lynn-core-discovery-mapping;
&I-D.lynn-dnsext-site-mdns;
<reference anchor="BACnet">
<front>
<title abbrev="BACnet">BACnet/IP</title>
<author initials="J." surname="Bender" fullname="Joel Bender" />
<author initials="M." surname="Newman" fullname="Mike Newman" />
<date year="2000"/>
</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" />
<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>
<author />
<date year="1994"/>
</front>
</reference>
<reference anchor="DALI">
<front>
<title abbrev="DALI">DALI Manual</title>
<author />
<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 initials="G." surname="Neugschwandtner" fullname="Georg Neugschwandtner" />
<author initials="M." surname="Koegler" fullname="Martin Koegler" />
<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="HAYSTACK">
<front>
<title>
Project Haystack
</title>
<author />
<date year="2011"/>
</front>
<seriesInfo name="Web" value="http://project-haystack.org/"/>
</reference>
<reference anchor="oBIX">
<front>
<title abbrev="oBIX">oBIX working group</title>
<author initials="B." surname="Frank" fullname="Brian Frank" role="editor" />
<date year="2006"/>
</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" />
<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>
<reference anchor="ZigBee-IP">
<front>
<title abbrev="SE-PAPS">ZigBee Smart Energy Profile 2.0 Application Protocol Specification
</title>
<author />
<date year="2011" month="March"/>
</front>
<seriesInfo name="Draft" value="ZigBee-11167"/>
</reference>
<reference anchor="dns-sd">
<front>
<title abbrev="dns-sd">dns-sd servicetype registration
</title>
<author />
<date year="2011"/>
</front>
<seriesInfo name="Web" value="http://www.dns-sd.org/ServiceTypes.html"/>
</reference>
</references>
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-23 14:25:37 |