[Search] [pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05                                             
CoRE                                                     P. van der Stok
Internet-Draft                                          Philips Research
Intended status: Informational                                   K. Lynn
Expires: September 15, 2011                                   Consultant
                                                          March 14, 2011

                 CoAP Utilization for Building Control


   This draft describes an example use of the RESTful CoAP protocol for
   building automation and control (BAC) applications such as HVAC and
   lighting.  A few basic design assumptions are stated first, then URI
   structure is utilized to define group as well as unicast scope for
   RESTful operations.  RFC 3986 defines the URI components as (1) a
   scheme, (2) an authority, used here to locate the building, area, or
   node under control, (3) a path, used here to locate the resource
   under control, and (4) a query part (fragments are not supported in
   CoAP.)  Next, it is shown that DNS can be used to locate URIs on the
   scale necessary in large commercial BAC deployments.  Finally, a
   method is proposed for mapping URIs onto legacy BAC resources, e.g.,
   to facilitate application-layer gateways.

   This proposal supports the view that (1) building control is likely
   to move in steps toward all-IP control networks based on the legacy
   efforts provided by DALI, LON, BACnet, ZigBee, and other standards,
   and (2) service discovery is complimentary to resource discovery and
   facilitates control network scaling.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on September 15, 2011.

van der Stok & Lynn    Expires September 15, 2011               [Page 1]

Internet-Draft    CoAP Utilization for Building Control       March 2011

Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

van der Stok & Lynn    Expires September 15, 2011               [Page 2]

Internet-Draft    CoAP Utilization for Building Control       March 2011

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  4
     1.2.  Motivation . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  URI structure  . . . . . . . . . . . . . . . . . . . . . . . .  6
     2.1.  Scheme part  . . . . . . . . . . . . . . . . . . . . . . .  7
     2.2.  Authority part . . . . . . . . . . . . . . . . . . . . . .  7
     2.3.  Path part  . . . . . . . . . . . . . . . . . . . . . . . .  8
   3.  Group Naming and Addressing  . . . . . . . . . . . . . . . . .  9
   4.  Discovery  . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     4.1.  DNS-Based Service Discovery  . . . . . . . . . . . . . . . 11
     4.2.  Service vs Host Names  . . . . . . . . . . . . . . . . . . 12
     4.3.  Browsing for Services  . . . . . . . . . . . . . . . . . . 12
     4.4.  Resource vs Service Discovery  . . . . . . . . . . . . . . 12
     4.5.  CoRE Link Extensions for DNS-SD  . . . . . . . . . . . . . 13
       4.5.1.  Service Name "sn" attribute  . . . . . . . . . . . . . 13
       4.5.2.  Service Type "st" attribute  . . . . . . . . . . . . . 14
       4.5.3.  Service Subtype "ss" attribute . . . . . . . . . . . . 14
   5.  Data Representations in CoAP . . . . . . . . . . . . . . . . . 14
     5.1.  Network architectures  . . . . . . . . . . . . . . . . . . 15
     5.2.  Gateways to legacy networks  . . . . . . . . . . . . . . . 17
     5.3.  Commissioning CoAP devices . . . . . . . . . . . . . . . . 18
       5.3.1.  DNS-SD server present  . . . . . . . . . . . . . . . . 19
       5.3.2.  DNS-SD server not present  . . . . . . . . . . . . . . 20
   6.  Conclusions  . . . . . . . . . . . . . . . . . . . . . . . . . 20
   7.  Security considerations  . . . . . . . . . . . . . . . . . . . 21
   8.  IANA considerations  . . . . . . . . . . . . . . . . . . . . . 22
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22
   10. Changelog  . . . . . . . . . . . . . . . . . . . . . . . . . . 22
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 22
     11.2. Informative References . . . . . . . . . . . . . . . . . . 24
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25

van der Stok & Lynn    Expires September 15, 2011               [Page 3]

Internet-Draft    CoAP Utilization for Building Control       March 2011

1.  Introduction

1.1.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in "Key words for use in
   RFCs to Indicate Requirement Levels" [RFC2119].

   In addition, the following conventions are used in this document.

   The term "service" often means different things to different
   communities and even different things to the same community.  In
   building control protocol standards, service is often used to refer
   to a function in the RPC sense.  In this context, we generally
   substitute the term "function".  In the IETF community, service may
   often refer to an abstract capability such as "datagram delivery".
   In this submission we use the term service, in the sense defined by
   "DNS-based Service Discovery" [I-D.cheshire-dnsext-dns-sd], as
   equivalent to a CoAP end-point (or server).

   A CoAP end-point is identified by the authority part of a URI.  We
   refer to this end-point (which is resolved to an {IP address, port}
   tuple) as a "node".  By "device" we generally mean the physical
   object handled by the installer.  While a device may host more than
   one service, for simplicity we assume here that a given device may
   only host a single CoAP node.

   In examples below involving URIs, the authority is preceded by double
   slashes "//" and path is preceded by a single slash "/".  The
   examples may make use of full or partial host names and the
   difference should be clear from the context.

1.2.  Motivation

   The CoAP protocol [I-D.ietf-core-coap] aims at providing a user
   application protocol architecture that is targeted to a network of
   nodes with a low resource provision such as memory, CPU capacity, and
   energy.  In general, IT application manufacturers strive to provide
   the highest possible functionality and quality for a given price.  In
   contrast, the building controls market is highly price sensitive and
   manufacturers tend to compete by delivering a given functionality and
   quality for the lowest price.  In the first market a decreasing
   memory price leads to more software functionality, while in the
   second market it leads to a lower Bill of Material (BOM).

   The vast majority of nodes in a typical building control application
   are resource constrained, making the standardization of a lightweight

van der Stok & Lynn    Expires September 15, 2011               [Page 4]

Internet-Draft    CoAP Utilization for Building Control       March 2011

   application protocol like CoAP a necessary requirement for IP to
   penetrate the device market.  This approach is further indicated by
   the low energy consumption requirement of battery-less nodes.  Low
   resource budget implies low throughput and small packet size as for
   [IEEE.802.15.4].  Reduction of the packet size is obtained by using
   the header reduction of 6LoWPAN [RFC4944] and encouraging small

   Several legacy building control standards (e.g.  [BACnet], [DALI],
   [KNX], [LON], [ZigBee], etc.) have been developed based on years of
   accumulated knowledge and industry cooperation.  These standards
   generally specify a data model, functional interfaces, packet
   formats, and sometimes the physical medium for data objects and
   function invocation.  Many of these industry standards also specify
   lower-level functionality such as proprietary transport protocols,
   necessitating expensive stateful gateways for these standards to
   interoperate.  Many more recent building control network include IP-
   based standards for transport (at least to interconnect islands of
   functionality) and other functions such as naming and discovery.
   CoAP will be successful in the building control market to the extent
   that it can represent a given standard's data objects and provide
   functions, e.g. resource discovery, that these standards depend on.

   From the above the basic syntax assumptions can be summarized as:

   -  Generate small payloads.

   -  Compatible with legacy standards (e.g.  LON, BACnet, DALI, ZigBee
      Device Objects).

   -  Service/resource discovery in agreement with legacy standards and
      naming conventions.

   This submission aims at an approach in which the payload contains
   messages with a syntax defined by legacy control standards.
   Accordingly, the syntax of the service/resource discovery messages is
   related to the chosen legacy control standard.  The intention is a
   progressive approach to all-IP in building control.  In a first stage
   standard IETF based protocols (e.g.CoAP, DNS-SD) are used for
   transport of control messages and discovery messages expressed in a
   legacy syntax.  This approach enables the reuse of controllers based
   on the semantics of the chosen control standard.  In a later stage a
   complete redesign of the controllers can be envisaged guided by the
   accumulated experience with all-IP control.

   Two concepts, hierarchy and group, are of prime importance in
   building control, particularly in lighting and HVAC.  Many control
   messages or events are multicast from one device to a group of

van der Stok & Lynn    Expires September 15, 2011               [Page 5]

Internet-Draft    CoAP Utilization for Building Control       March 2011

   devices (e.g. from a light switch to all lights in an area).  The
   scope of a multicast command or discovery message determines the
   group of nodes that is targeted.  A group scope may be defined as
   link-local, or as a tree maintained by IP-multicast or an overlay
   that corresponds to the logical structure of a building or campus,
   and is independent of the underlying network structure.  Techniques
   for group communication are discussed in [I-D.rahman-core-groupcomm].

   As described in "Commercial Building Applications Requirements"
   [I-D.martocci-6lowapp-building-applications] it is typical practice
   to aggregate building control at the room, area, and supervisory
   levels.  Furthermore, networks for different subsystems (lights,
   HVAC, etc.) or based on different legacy standards have historically
   been isolated from each other in so-called "silos".  RESTful web
   services [Fielding] represent one possible way to expose
   functionality and normalize data representations between silos in
   order to facilitate higher order applications such as campus-wide
   energy management.

   Consequently, additional protocol oriented assumptions are:

   -  Nodes may be addressed by one or more groups.

   -  Resources addressed by a group must be uniformly named across all
      targeted nodes.

   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.

2.  URI structure

   This I-D considers three elements of the URI: scheme, authority, and
   path, as defined in "Uniform Resource Identifier (URI): Generic
   Syntax" [RFC3986].  The authority is defined within the context of
   standard DNS host naming, while the path is valid in relation to a
   fully qualified domain name (FQDN) plus optional port (and protocol
   is implicit, based on scheme).  An example based on [RFC3986] is:
   foo://host.example.com:8042/over/there?name=ferret#nose, where "foo"
   is the scheme, "host.example.com:8042" is the authority, "/over/
   there" is the path, "name=ferret" is the query, and "nose" is the
   fragment.  Fragments are not supported in CoAP.

van der Stok & Lynn    Expires September 15, 2011               [Page 6]

Internet-Draft    CoAP Utilization for Building Control       March 2011

2.1.  Scheme part

   The coap URI scheme syntax is specified in section 6.1 of
   [I-D.ietf-core-coap] and is compatible with the "http" scheme
   specification [RFC2616].  The host part of the authority may be
   represented either as a literal IP address or as a fully qualified
   domain name.  While scheme is irrelevant from the perspective of the
   service, it is used in service discovery to identify the protocol
   used to access the service.

   TBD: we have yet to fully explore the utility of a separate scheme
   (e.g., "coapm") to support group communication models as described in

2.2.  Authority part

   The authority part is either a literal IP address or a DNS name
   comprised of a local part, specifying an individual node or group of
   nodes, and a global part specifying a (sub)domain that may reflect
   the logical hierarchical structure of the building control network.
   The result is said to be a fully qualified domain name (FQDN) which
   is globally unique down to the group or node level.  An optional port
   number may be included in the authority following a single colon ":"
   if the service port is other than the default CoAP value.

   The CoAP spec [I-D.ietf-core-coap] states "When a CoAP server is
   hosted by a 6LoWPAN node, it SHOULD also support a port in the 61616-
   61631 compressed UDP port space defined in [RFC4944]."  As shown
   below, DNS-SD [I-D.cheshire-dnsext-dns-sd] is a viable technique for
   discovering dynamic host and port assignments for a given service.
   However, the use of dynamic ports in URIs is likely to lead to
   brittle (non-durable) identifiers as it is conventional to treat
   different ports as representing different authorities and there is no
   assurance that a coap server will consistently acquire the same
   dynamic port.

   A building can be unambiguously addressed by it GPS coordinates or
   more functionally by its zip or postal code.  For example the Dutch
   Internet provider, KPN, assigns to each subscriber a host name based
   on its postcode.  Analogously, an example authority for a building
   may be given by: //bldg.zipcode-localnr.Country/ or more concretely
   an imaginary address in the Netherlands as: //bldg.5533BA-125a.nl/.
   The "bldg" prefix can specify the target node within the building.
   Arriving at the node identified by //bldg.5533BA-125a.nl, the
   receiving service can parse the path portion of the URI and perform
   the requested method on the specified resource.

   Buildings have a logical internal structure dependent on their size

van der Stok & Lynn    Expires September 15, 2011               [Page 7]

Internet-Draft    CoAP Utilization for Building Control       March 2011

   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:

   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:

   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.

2.3.  Path part

   Every network addressable resource is completely identified by a URI
   scheme://authority/path.  The path part of the URI specifies the
   resource within a given node.  The representation of object types and
   their associated attributes are typically subjects for
   standardization.  There is no widely accepted standard for uniformly
   naming building control device structure in a URI.  A vigorous effort
   is undertaken by the oBIX working group of OASIS [oBIX], but its
   current impact is limited.

van der Stok & Lynn    Expires September 15, 2011               [Page 8]

Internet-Draft    CoAP Utilization for Building Control       March 2011

   When a GET method with an URI like
   "//t-sensor1.25b006.floor1.example.com/temperature" is sent, it
   represents an a priori understanding that the node with name
   t-sensor1 exists, is of a given standard type (e.g.  ZigBee
   temperature sensor), and that this standard type has the readable
   attribute: temperature.  When commands are sent to a group of nodes
   it MUST be the case that the targeted resource has the same path on
   all targeted nodes.  Therefore, it is necessary to establish at least
   a local uniform path naming convention to achieve this.  One approach
   is to include the name of the standard, e.g.  BACnet, as the first
   element in the path and then employ the standard's chosen data scheme
   (in the case of BACnet, /bacnet/device/object/property).

   A better long-term solution is to build on the concepts presented in
   [I-D.ietf-core-link-format] and identify resources of a given object
   model in terms of a registered "/.well-known" prefix.  The
   organization responsible for defining a given industry standard XXX
   (e.g.  BACnet, ZigBee, etc.) can register the /.well-known/XXX prefix
   and specify the allowable pathnames that may occur under this prefix.
   This allows the XXX standard development organization to assume
   responsibility for defining the name space and resources associated
   with the prefix.  The registered /.well-known/XXX URI effectively
   defines a standard object model, or schema.  Manufacturers may
   optionally define proprietary resources that can be discovered
   dynamically using methods described below.

3.  Group Naming and Addressing

   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

   Example groups become:

   URI authority                    Targeted group
   //all.bldg6...                   "all nodes in building 6"
   //all.west.bldg6...              "all nodes in west wing, building 6"
   //all.floor1.west.bldg6...       "all nodes on floor 1, west wing,
   //all.bu036.floor1.west.bldg6... "all nodes in office bu036, ..."

van der Stok & Lynn    Expires September 15, 2011               [Page 9]

Internet-Draft    CoAP Utilization for Building Control       March 2011

   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 [RFC3596] in
   each zone.  Highly granular multicast scopes are only practical using
   IPv6.  The multicast address allocation strategy is beyond the scope
   of this I-D, but various alternatives have been proposed
   [RFC3306][RFC3307][RFC3956].  Some techniques in this proposal, e.g.
   service discovery as described below, can be accomplished with a
   single coap-specific multicast address as long as the desired scope
   is building-wide.

   To illustrate the concept of multiple group names within a building,
   consider the definition, as done with [DALI], of scenes within the
   context of a floor or a single office.  For example, the setting of
   all blue lights in office bu036 of floor 1 can be realized by
   multicasting a message to the group "//blue-lights.bu036.floor1".
   Each group is associated with an IP address.  Consequently, when the
   application specifies the sending of an "on" message to all blue
   lights in the office, the message is multicast to the associated IP
   address.  The Uri-Host option [I-D.ietf-core-coap] need not be sent
   as part of the message.  However to identify the resource that is
   addressed, a short version of the resource path can be inserted as an
   option as explained in [I-D.ietf-core-link-format].

   The binding of a group FQDN to multicast address (i.e., creation of
   the AAAA record in the DNS zone server) happens during the
   commissioning process.  Resolution of the group name to a multicast
   address happens at restart of a source or receiver node.  A multicast
   address and associated group name in this context are assumed to be
   long-lived.  It can happen that during operation the membership of
   the group changes (less or more lights) but its address is not
   altered and neither its name.  In the limit, the group can degrade to
   a single controller that represents a non-networked subsystem
   replacing the original networked group of nodes.  Group membership
   may be managed by a protocol such as Multicast Listener Discovery

   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

van der Stok & Lynn    Expires September 15, 2011              [Page 10]

Internet-Draft    CoAP Utilization for Building Control       March 2011

   that it should accept packets for an additional IP address, the
   granularity of the domain names may have an impact on the complexity
   of the DNS server but not necessarily on the low-resource
   destinations or sources.  Assuming that resolution of addresses only
   happens at node start-up, the complexity of the DNS server need not
   affect the responsiveness of the nodes.

   In summary, the authority portion of the URI is used to identify a
   node (group) and the resulting DNS name is bound to a unicast
   (multicast) address.  Naming is building or organization dependent,
   must be flexible, and does not require standardization efforts but
   SHOULD conform to some uniform convention.

4.  Discovery

4.1.  DNS-Based Service Discovery

   DNS-Based Service Discovery (DNS-SD) defines a conventional way to
   configure DNS PTR, SRV, and TXT records to facilitate discovery of
   services such as CoAP nodes within a subdomain, re-using the existing
   DNS infrastructure.  This section gives a cursory overview of DNS-SD;
   see [I-D.cheshire-dnsext-dns-sd] for a complete description.

   A DNS-SD service instance name is of the form
   <Instance>.<ServiceType>.<Location>, where the service type for CoAP
   nodes is "_coap._udp".  The identifier "_udp" provides a transport
   protocol hint as required by the SRV record definition [RFC2782] and
   "_coap" identifies the application protocol.  A PTR record with the
   label "_coap._udp" is defined for each CoAP end-point in the zone,
   and this record's value is set to the service instance name (which in
   turn identifies to SRV and TXT records for the CoAP end-point).

   DNS-SD also supports one level of subtype, which can be used to
   locate coap services based on object model (schema), for example:
   _bacnet._sub._coap._udp, _dali._sub._coap._udp, or
   _zigbee._sub._coap._udp.  The maximum length of the type and subtype
   fields is 14 octets, which could allow for "schema-function"
   descriptors such as _dali-light, _dali-switch, etc.

   The Location part of the service name is identical to the global (DNS
   subdomain) part of the authority in URIs that identify the resources
   on this node or group and may identify a building zone as in the
   examples above.

   The Instance part of the service name may be changed during the
   commissioning process.  It must be unique within the subdomain.  The
   complete service name uniquely identifies an SRV and a TXT record in

van der Stok & Lynn    Expires September 15, 2011              [Page 11]

Internet-Draft    CoAP Utilization for Building Control       March 2011

   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.

4.2.  Service vs Host Names

   In general, the authority "www.example.com" does not refer to a
   canonical host name (the label of a AAAA record).  Logically, it
   refers to the "world wide web service" for the example.com domain.
   Literally, the "www" is probably the label of a CNAME record that
   names a AAAA record that may in turn specify more than one address
   (in the case of round-robin load leveling between identical origin
   server instances).

   The SRV record functions something like the CNAME in this case,
   except that it is capable of resolving to an IP address plus a
   listening socket (though, as we said, the use of dynamic sockets is
   not recommended in URIs).  An optional TXT record may be configured
   wih same name as the SRV record and be used to store context-
   dependent key=value pairs.  For example, a multi-function device
   might define a service name for each "base URI" that locates the
   start of an object resource (e.g. abs-path=/.well-known/zigbee/
   sensor/).  Thus, the URI coap://host.example.com/temp might resolve
   through DNS-SD lookups to

4.3.  Browsing for Services

   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.

4.4.  Resource vs Service Discovery

   While service discovery is concerned with finding the IP address,
   port, protocol, and possibly path of a named service, resource

van der Stok & Lynn    Expires September 15, 2011              [Page 12]

Internet-Draft    CoAP Utilization for Building Control       March 2011

   discovery is a fine-grained enumeration of resource URIs within a web
   service.  [I-D.ietf-core-link-format] specifies a resource discovery
   pattern, such that sending a confirmable GET message for the /.well-
   known/core resource returns a set of links that identify all
   resources present on the node that are exposed as functions.

   Assuming the ability to multicast the GET over the local link, coap
   resource discovery can be used to enumerate attributes and populate
   the DNS-SD database in a semi-automated fashion.  CoAP resource
   descriptions can be imported into DNS-SD for exposure to service
   discovery by using /.well-known/core attributes as the basis for a
   unique "Instance" name, defaulting to "_coap._udp" for the
   ServiceType, and using some means to establish in which subdomain the
   service should be registered (TBD).  The DNS TXT record can be
   populated by importing the other resource description attributes as
   they share the same key=value format specified in Section 6 of

4.5.  CoRE Link Extensions for DNS-SD

   The following CoRE specific target attributes are proposed as
   extensions to [I-D.ietf-core-link-format] to support DNS-SD.  The
   values are intended to be imported directly into a DNS- SD zone file
   are are subject to format and length constraints as specified in

      link-extension    = ( "sn" "=" quoted-string )
      link-extension    = ( "st" "=" quoted-string )
      link-extension    = ( "ss" "=" quoted-string )

4.5.1.  Service Name "sn" attribute

   The service name "sn" attribute is the <Instance> portion of a DNS-SD
   service instance name.  It is stored directly in the DNS as a single
   DNS label of canonical precomposed UTF-8 [RFC3629] "Net-Unicode"
   (Unicode Normalization Form C) [RFC5198] text.  However, to the
   extent that the "sn" attribute may be chosen to match the DNS host
   name of a proxy or gateway, it SHOULD use the syntax defined in
   Section 3.5 of [RFC1034] and Section 2.1 of [RFC1123].

   The <Instance> portion of the name of a service being offered on the
   network SHOULD be configurable by the user setting up the service, so
   that he or she may give it an informative name.  However, the device
   or service SHOULD NOT require the user to configure a name before it
   can be used.  A sensible choice of default name can allow the device
   or service to be accessed in many cases without any manual

van der Stok & Lynn    Expires September 15, 2011              [Page 13]

Internet-Draft    CoAP Utilization for Building Control       March 2011

   configuration at all.  The default name should be short and
   descriptive, and MAY include the device's MAC address, serial number,
   or any similar hexadecimal string in an attempt to make the name
   globally unique.

   DNS labels are currently limited to 63 octets in length and the
   entire service instance name may not exceed 255 octets.

4.5.2.  Service Type "st" attribute

   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.

4.5.3.  Service Subtype "ss" attribute

   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.

5.  Data Representations in CoAP

   Before CoAP devices can come to market, manufacturers must agree that
   the type and attributes of the device can be interpreted according to
   some generally recognized syntax.  At this moment no such generally
   recognized syntax exists for CoAP devices.  We do not expect an IETF
   working group to standardize such a syntax, and we are convinced that
   syntax standardization is the responsibility of industry standards
   organizations.  Given the long history of building control, many
   groups have defined a data representation for building control
   devices for example BACnet, ZigBee oBIX, LON, KNX, and many others.
   It is our believe that new representations will be defined and must
   coexist with the named legacy ones.

   The CoAP protocol should transport any data representation, and
   certainly the legacy ones.  As pointed out earlier, this has
   consequences for the naming of resources.  In some cases a CoAP
   device can handle more than one legacy representation.  Given that a
   CoAP device can handle representation of standard XXX, this I-D
   proposes that such a CoAP device can communicate with legacy devices
   via a CoAP/legacy gateway (router).

van der Stok & Lynn    Expires September 15, 2011              [Page 14]

Internet-Draft    CoAP Utilization for Building Control       March 2011

5.1.  Network architectures

   Figure 1 represents the network architecture which is expected for
   the purpose of this I-D.  The coap gateway connects one link with two
   legacy nodes -containing legacy data representation "yyy"- with the
   wireless coap network composed of three coap hosts.  Two coap hosts
   contain the coap stack with a zzz representation and one host
   contains the coap stack with a zzz and an yyy representation.  The
   yyy hosts can freely communicate according to the yyy link protocol
   over the yyy link.  The zzz coap hosts, including the zzz;yyy host
   can freely exchange zzz data representations according to the coap
   protocol over the wireless IP/6LoWPAN network.  The zzz;yyy host can
   send yyy data representations to the coap gateway which passes them
   on to the specified yyy legacy host.  The yyy legacy node returns
   data to the requesting zzz;yyy coap host via the same gateway.

     +------+                 +------+     +------+
     | yyy  |                 | zzz  |     | zzz  |
     | link |                 | coap |     | coap |
     +------+                 +------+     +------+
       |         +---------+
       |---------| coap    |-->
       |         | gateway |
     +------+    +---------+        +-----------+
     | yyy  |                       | zzz ; yyy |
     | link |                       |   coap    |
     +------+                       +-----------+

         Figure 1: network with multiple representation standards

   There are at least four ways that the CoAP hosts can address the
   legacy nodes behind the gateway.

   -  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.

   -  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.

van der Stok & Lynn    Expires September 15, 2011              [Page 15]

Internet-Draft    CoAP Utilization for Building Control       March 2011

   -  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.

   -  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.

   The major advantage of all four approaches is that the gateway only
   handles the URI or IP address and port number to select the
   destination legacy node independent of the type of legacy device and
   the contents of the legacy payload of the message.  In Figure 1 the
   gateway connects to a single link.  For example, this would be the
   case for DALI standard.  Other legacy standards, like BACnet, LON,
   allow networks composed of multiple links.

   An example of an invocation of a zzz device from a controller that
   can producee zzz commands is given.  Assume the resource path /.well-
   known/zzz identifies the parser of the ZZZ syntax.  A 12 octet
   message completely describes the zzz command.  The host is completely
   identified by the authority in the URI.  The zzz parser on the host
   is identified by the port number.

       Client                                             CoAP/ZZZ
         |                                                  node
         |  REQUEST                                           |
         |-------- CON [0x5577] PUT /.well-known/ZZZ -------->|
         |             binary 12 octet string                 |
         |                                                    |
         |  RESPONSE                                          |
         |<---------- ACK [0x5577] 2.00 OK  ----------------- |
         |                                                    |

        Figure 2: Sending a ZZZ command with coap to coap/ZZZ node

   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.

   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

van der Stok & Lynn    Expires September 15, 2011              [Page 16]

Internet-Draft    CoAP Utilization for Building Control       March 2011

   number identifies the DALI node.  The application sets a value of 200
   in the DALI node in the attribute 256 defined by the DALI spec.

       Client                                             DALI/CoAP
         |                                                 gateway
         |  REQUEST                                           |
         |------- CON [0x5577] PUT /.well-known/DALI -------->|
         | binary 16 bit payload dt*256 + 200                 |
         |                                                    |
         |  RESPONSE                                          |
         |<---------- ACK [0x5577] 2.00 OK  ----------------- |
         |                                                    |

      Figure 3: Sending a DALI setting with coap to coap/DALI gateway

   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

5.2.  Gateways to legacy networks

   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 .

   -  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

van der Stok & Lynn    Expires September 15, 2011              [Page 17]

Internet-Draft    CoAP Utilization for Building Control       March 2011

      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,

   -  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.

   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).

5.3.  Commissioning CoAP devices

   Commissioning means mapping a physical device identified by its
   location to an URI.  Given that mapping of URI to IP address is done
   elsewhere (e.g.  DNS), the mapping of location to IP address is done
   during commissioning with a commissioning tool.  The commissiong is
   done for a set of coap nodes interconnected by a wireless network.
   The netwok can contain zero or more 6LR routers and zero or more
   6LBR.  The IP infrastructure (DNS, DHCP servers) is connected to the
   coap network via the 6LBR.  Two cases are considerd for
   commissioning: (1) no 6LBR and no DNS server connected, and (2) a
   6LBR connects to a DNS server.

   When an architect has designed the building and described all light
   points, ventilators, heating- and cooling units, and sensors, it is
   necessary to provide identifiers for all these devices.  The triple
   Instance.ServiceType.Location, as proposed in DNS-SD, is used to
   describe the commssioning process.  The identifiers of the devices
   often reflect their action domain which is linked to their physical

van der Stok & Lynn    Expires September 15, 2011              [Page 18]

Internet-Draft    CoAP Utilization for Building Control       March 2011

   location.  The authority can be equated to the Location identifier.
   The Location uniquely identifies the device.  The Instance is the
   unique identifier given to the device in the factory but which has no
   relation to its later function.  The ServiceType together with the
   Location fully determine the semantics of the data returned by the
   device.  Commissioning is the process of mapping the Location to
   Instance for all installed hosts.  The mapping is stored in a
   discovery repository such that applications can communicate with the
   required devices.

   Design decision: A commissioning tool with access to the network is
   used for the commissioning phase.

   For example, dependent on used technology and production process, the
   following situation (state) exists in a host after physical
   installation of the devices:

   -  A given host is unaware of its Location.

   -  A given host knows its ServiceType and Instance.  The Instance is
      also readable by bar code reader.

   -  The commissioning tool knows all Location's to which hosts need to
      be assigned.

   -  A DHCP server (neigbor discovery) provided each host with a (link-
      local) IP address.

   Consider the commissioning process (1) with a central DNS-SD server
   and (2) without a central server using mDNS.

5.3.1.  DNS-SD server present

   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:

van der Stok & Lynn    Expires September 15, 2011              [Page 19]

Internet-Draft    CoAP Utilization for Building Control       March 2011

   -  Each node asks the DNS-SD server the authority belonging to its

   -  Each node updates the authority in the DNS-SD server with its IP

   -  Each node appends for each resource the path name to the authority
      and inserts it into the DNS-SD server with its IP address.

   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

5.3.2.  DNS-SD server not present

   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.

6.  Conclusions

   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

van der Stok & Lynn    Expires September 15, 2011              [Page 20]

Internet-Draft    CoAP Utilization for Building Control       March 2011

   can be designed to suit the application.  However, it is recommended
   that the scheme be employed consistently throughout the delegated

   The authority portion of the URI is resolved by the client, using
   conventional DNS, into the unicast or multicast IP address of the
   targeted node(s).  Taking advantage of the CoAP design
   [I-D.ietf-core-coap], the Uri-Host option need not be transmitted in
   requests to origin servers and thus there is no performance penalty
   for using descriptive naming schemes.  The coap design allows sending
   a short url to distinguish between resources on a given node,
   resulting in very compact identifiers.

   DNS-SD [I-D.cheshire-dnsext-dns-sd] can be used to scale up service
   discovery beyond the local link.  DNS-SD can be used to enumerate
   instances of a given service type within a given sub-domain.  This
   affords additional flexibility, such as the ability to discover
   dynamic port assignments for coap node, locate coap nodes by subtype,
   or bind service names for particular coap URIs.

   A targeted resource is specified by the path portion of the URI.
   Again, this I-D does not mandate a universal naming standard for
   resources but uses examples to show how resources could be named for
   various legacy standards.  An obvious requirement for resources that
   are accessed by multicast is that they MUST all share the same path.
   It is shown that it is possible to transport legacy commands (e.g.
   expressed in BACnet, LON, DALI, ZigBee, etc.) inside a CoAP message
   body.  This necessitates the definition of an additional IANA mime
   code, and the mapping of legacy specific discovery semantics to CoAP
   resource discovery messages or DNS-SD lookups.

7.  Security considerations

   TBD: The detailed CoAP security analysis needs to encompass scenarios
   for building control applications.

   Based on the programming model presented in this I-D, security
   scenarios for building control need to be stated.  Appropriate
   methods to counteract the proposed threats may be based on the work
   done elsewhere, for example in the ZigBee over IP context.

   Multicast messages are, by their nature, transmitted via UDP.  Any
   privacy applied to such messages must be block oriented and based on
   group keys shared by all targeted nodes.  The CoRE security analysis
   must be broadened to include multicast scenarios.

van der Stok & Lynn    Expires September 15, 2011              [Page 21]

Internet-Draft    CoAP Utilization for Building Control       March 2011

8.  IANA considerations

   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.

9.  Acknowledgements

   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.

10.  Changelog

   From bc-01 to bc-02

   - Removed all references to multicast and multicast scope, given
   draft of rahman group communication.

   - Adapted examples to coap-2 and core-link drafts.

   - transport short URL for destination recognition.

   - Elaborated legacy discovery under DNS-SD.

   From bc-02 to bc-03

   - Elaboration on gateways, commissioning and legacy networks. -
   Recommendation to extend DNS-SD naming with sn, st, and ss

11.  References

11.1.  Normative References

   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
              STD 13, RFC 1034, November 1987.

   [RFC1123]  Braden, R., "Requirements for Internet Hosts - Application
              and Support", STD 3, RFC 1123, October 1989.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

van der Stok & Lynn    Expires September 15, 2011              [Page 22]

Internet-Draft    CoAP Utilization for Building Control       March 2011

   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

   [RFC2782]  Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
              specifying the location of services (DNS SRV)", RFC 2782,
              February 2000.

   [RFC3306]  Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6
              Multicast Addresses", RFC 3306, August 2002.

   [RFC3307]  Haberman, B., "Allocation Guidelines for IPv6 Multicast
              Addresses", RFC 3307, August 2002.

   [RFC3596]  Thomson, S., Huitema, C., Ksinant, V., and M. Souissi,
              "DNS Extensions to Support IP Version 6", RFC 3596,
              October 2003.

   [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
              10646", STD 63, RFC 3629, November 2003.

   [RFC3956]  Savola, P. and B. Haberman, "Embedding the Rendezvous
              Point (RP) Address in an IPv6 Multicast Address",
              RFC 3956, November 2004.

   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66,
              RFC 3986, January 2005.

   [RFC4944]  Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
              "Transmission of IPv6 Packets over IEEE 802.15.4
              Networks", RFC 4944, September 2007.

   [RFC5198]  Klensin, J. and M. Padlipsky, "Unicode Format for Network
              Interchange", RFC 5198, March 2008.

   [RFC5785]  Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known
              Uniform Resource Identifiers (URIs)", RFC 5785,
              April 2010.

   [RFC5790]  Liu, H., Cao, W., and H. Asaeda, "Lightweight Internet
              Group Management Protocol Version 3 (IGMPv3) and Multicast
              Listener Discovery Version 2 (MLDv2) Protocols", RFC 5790,
              February 2010.

van der Stok & Lynn    Expires September 15, 2011              [Page 23]

Internet-Draft    CoAP Utilization for Building Control       March 2011

11.2.  Informative References

              Cheshire, S. and M. Krochmal, "DNS-Based Service
              Discovery", draft-cheshire-dnsext-dns-sd-10 (work in
              progress), February 2011.

              Cheshire, S. and M. Krochmal, "Multicast DNS",
              draft-cheshire-dnsext-multicastdns-14 (work in progress),
              February 2011.

              Shelby, Z., Hartke, K., Bormann, C., and B. Frank,
              "Constrained Application Protocol (CoAP)",
              draft-ietf-core-coap-04 (work in progress), January 2011.

              Shelby, Z., "CoRE Link Format",
              draft-ietf-core-link-format-02 (work in progress),
              December 2010.

              Martocci, J., Schoofs, A., and P. Stok, "Commercial
              Building Applications Requirements",
              draft-martocci-6lowapp-building-applications-01 (work in
              progress), July 2010.

              Rahman, A., "Group Communication for CoAP",
              draft-rahman-core-groupcomm-04 (work in progress),
              March 2011.

   [BACnet]   Bender, J. and M. Newman, "BACnet/IP",
              Web http://www.bacnet.org/Tutorial/BACnetIP/index.html.

   [ZigBee]   Tolle, G., "A UDP/IP Adaptation of the ZigBee Application
              Protocol", draft-tolle-cap-00 (work in progress),
              October 2008.

   [LON]      "LONTalk protocol specification, version 3", 1994.

   [DALI]     "DALI Manual", Web http://www.dali-ag.org/c/manual_gb.pdf,

   [KNX]      Kastner, W., Neugschwandtner, G., and M. Koegler, "AN OPEN

van der Stok & Lynn    Expires September 15, 2011              [Page 24]

Internet-Draft    CoAP Utilization for Building Control       March 2011

              fet05-openapproach-preprint.pdf, 2005.

              "Information technology - Telecommunications and
              information exchange between systems - Local and
              metropolitan area networks - Specific requirements - Part
              15.4: Wireless Medium Access Control (MAC) and Physical
              Layer (PHY) Specifications for Low Rate Wireless Personal
              Area Networks (LR-WPANs)", IEEE Std 802.15.4-2006,
              June 2006,

   [oBIX]     "oBIX working group", Web http://www.obix.org, 2003.

              Fielding, R., "Architectural Styles and the Design of
              Network-based Software Architectures, Second Edition",
              Doctoral dissertation , University of California, Irvine ,
              Web http://www.ics.uci.edu/~fielding/pubs/dissertation/
              top.html, 2000.

Authors' Addresses

   Peter van der Stok
   Philips Research
   High Tech Campus
   Eindhoven,   5656 AA
   The Netherlands

   Email: peter.van.der.stok@philips.com

   Kerry Lynn

   Phone: +1 978 460 4253
   Email: kerlyn@ieee.org

van der Stok & Lynn    Expires September 15, 2011              [Page 25]