[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: January 10, 2011                                     Consultant
                                                            July 9, 2010


                 CoAP Utilization for Building Control
                      draft-vanderstok-core-bc-01

Abstract

   This I-D describes an example use of the RESTful CoAP protocol for
   building control applications such as HVAC and lighting.  A few basic
   design assumptions are stated first.  The URI structure is exploited
   to define multicast as well as unicast scopes.  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 and fragment part,
   where fragments are not supported in CoAP.

   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,
   (2) service discovery is complimentary to resource discovery and
   facilitates control network scaling, and (3) the provision of a
   reliable group communication protocol is essential to support
   building control applications.

Status of this Memo

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

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

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

   This Internet-Draft will expire on January 10, 2011.

Copyright Notice




van der Stok & Lynn     Expires January 10, 2011                [Page 1]


Internet-Draft    CoAP Utilization for Building Control        July 2010


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

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   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.


Table of Contents

   1.  Conventions and Terminology Used in this Document  . . . . . .  3
   2.  Motivation . . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  URI structure  . . . . . . . . . . . . . . . . . . . . . . . .  5
     3.1.  Scheme part  . . . . . . . . . . . . . . . . . . . . . . .  5
     3.2.  Authority part . . . . . . . . . . . . . . . . . . . . . .  6
     3.3.  Path part  . . . . . . . . . . . . . . . . . . . . . . . .  7
   4.  Group Addressing . . . . . . . . . . . . . . . . . . . . . . .  7
   5.  Reliable multicast . . . . . . . . . . . . . . . . . . . . . .  9
   6.  Application examples . . . . . . . . . . . . . . . . . . . . . 10
   7.  Discovery  . . . . . . . . . . . . . . . . . . . . . . . . . . 12
   8.  Conclusions  . . . . . . . . . . . . . . . . . . . . . . . . . 15
   9.  Security considerations  . . . . . . . . . . . . . . . . . . . 15
   10. IANA considerations  . . . . . . . . . . . . . . . . . . . . . 16
   11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
   12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
     12.1. Normative References . . . . . . . . . . . . . . . . . . . 16
     12.2. Informative References . . . . . . . . . . . . . . . . . . 17
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18

















van der Stok & Lynn     Expires January 10, 2011                [Page 2]


Internet-Draft    CoAP Utilization for Building Control        July 2010


1.  Conventions and Terminology Used in this Document

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

   The term "service" may mean different things to different communities
   and sometimes 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.

   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 fully qualified or partial domain names and
   the difference should be clear from the context.


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.

   The vast majority of nodes in a typical building control application
   are resource constrained, making the standardization of a lightweight
   application protocol like CoAP a necessary requirement for IP to
   penetrate the device market.  This approach is further indicated by
   the low energy consumption requirement of battery-less nodes.  Low
   resource budget implies low throughput and small packet size as for
   [IEEE.802.15.4].  Reduction of the packet size is obtained by using



van der Stok & Lynn     Expires January 10, 2011                [Page 3]


Internet-Draft    CoAP Utilization for Building Control        July 2010


   the header reduction of 6LoWPAN [RFC4944] and encouraging small
   payloads.

   Several legacy building control standards (e.g [BACnet], [LON],
   [DALI], [KNX], etc.) have been developed based on years of
   accumulated knowledge and industry cooperation.  These standards
   generally specify a data model, functions, 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 are in the process of transitioning to IP-based
   standards for transport and other functions such as naming and
   discovery.  CoAP will be succesful 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
   devices (e.g. from a light switch to all lights in a room).  The
   scope of a multicast command or discovery message covers the group of
   nodes that is targeted.  Defining multicast scopes on the basis of
   hop count or the existence of edge routers is not always sufficient
   in buildings where the network architecture may be independent of the



van der Stok & Lynn     Expires January 10, 2011                [Page 4]


Internet-Draft    CoAP Utilization for Building Control        July 2010


   controlled areas (e.g. rooms) in the building.

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

   -  A syntactic definition of the multicast scope applicable to all
      control application multicasts in the building.

   -  Nodes may be addressed by more than one group.

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


3.  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).  An example based on RFC 3986 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.

3.1.  Scheme part

   The default scheme in this submission is "coap" although the
   intention is that everything stated below about URIs SHOULD apply
   equally to "http" and might be exposed, say, through an http-to-coap



van der Stok & Lynn     Expires January 10, 2011                [Page 5]


Internet-Draft    CoAP Utilization for Building Control        July 2010


   gateway.  That topic is beyond the scope of this document.

3.2.  Authority part

   The authority part is either a literal IP address or a DNS name
   comprised of a global part specifying the domain and a local part
   specifying the logical hierarchical structure of the building control
   network, 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.

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

   Buildings have a logical internal structure dependent on their size
   and function.  This ranges from a single hall without any structure
   to a complex building with wings, floors, offices and possibly a
   structure within individual rooms.  The naming of the building
   control equipment and the actual control strategy are intimately
   linked to the building structure.  It is therefore natural to name
   the equipment based on their location within the building.
   Consequently, the local part of the URI identifying a piece of
   equipment is expressed in the building structure.  An example is:
   //light-27.floor-1.west-wing...

   This proposal assumes a basic 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 sub-
   string: //group1-floor2-west-bldg3-campus.example.com.

   Most communication is device to device (M2M) within the building.
   Often a device needs to communicate to all devices of a given type
   within a given area of the building.  For example a thermostat may



van der Stok & Lynn     Expires January 10, 2011                [Page 6]


Internet-Draft    CoAP Utilization for Building Control        July 2010


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

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

   When a GET method with an URI like: //t-sensor1.25b006.floor1/
   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
   BACnet temperature sensor), and that this standard type has the
   readable attribute: temperature.  However, in the case of multicast
   commands to a group of nodes it is necessary that the targeted
   resource have 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 natural data scheme (in the case of BACnet,
   device/object/property).


4.  Group Addressing

   As suggested by the examples above, the scope of the messages can be
   logically associated with the URI authority.  This provides a better
   handle to define the multicast scope than the traditional TTL counter
   preventing the multicast message to pass one or more routers.  This
   more sophisticated scoping mechanism is needed to decouple multicast
   scopes from the network layout.  This is reflected by the capability
   provided in [BACnet] to define the scope of its service/resource
   discovery messages.




van der Stok & Lynn     Expires January 10, 2011                [Page 7]


Internet-Draft    CoAP Utilization for Building Control        July 2010


   Given a network configuration and associated prefixes, the network
   operator needs to define an appropriate set of multicast groups which
   can be mapped to the building areas.  Knowledge about the
   hierarchical structure of the building areas may assist in defining a
   network architecture which encourages an efficient multicast
   implementation.  Example multicast groups become:

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

   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" would 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 possible 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 given
   multicast scope, 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-authority option
   [I-D.ietf-core-coap] need not be sent as part of the message.

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

   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



van der Stok & Lynn     Expires January 10, 2011                [Page 8]


Internet-Draft    CoAP Utilization for Building Control        July 2010


   (multicast) address, resulting in an associated unicast (multicast)
   scope.  Naming is building or organization dependent, must be
   flexible, and does not require standardization efforts but SHOULD
   conform to some uniform convention.  In the context of an
   administrated professional building, groups can be defined off-line
   and stored in DNS server configuration.  Automated enumeration, based
   on service discovery methods described below, may be used to locate
   nodes and add them to groups during the building commissioning phase.


5.  Reliable multicast

   A reliable group communication (multicast) is essential for an
   efficient building control application.  Reliable multicast supports
   guaranteed delivery of messages to a group of nodes.  The
   representative example is a group of lights that need to be switched
   on simultaneously.  Although the delay between sending the command
   message (e.g. from a switch) to the effective switching on of the
   lights may be up to one second, all lights in the group should appear
   to switch on simultaneously (within an interval of 100-200 msec).
   Examples of reliable multicast specifications are cited in
   [Mullender].  In the case of real-time control of devices, the
   following specification applies:

    Validity -   If sender sends message, m, to a group, g, of
      destinations, a path exists between sender and destinations, and
      sender and destinations are correct, all destinations in g
      eventually receive m.

    Integrity -   destination receives m at most once from sender and
      only if sender sent m to a group including destination.

    Agreement -   If a correct destination of g receives m, then all
      correct destinations of g receive m.

    Timeliness -   There is a known constant D such that if m is sent at
      time t, no correct destination receives m after t+D.

   Assuming that every new multicast message contains a unique
   transaction identifier, the integrity requirement can be met by
   checking this identifier.  The agreement and timeliness requirements
   can be met by multicast algorithms developed for real time computing.
   It is assumed that the clocks of the nodes are synchronized and
   multiple redundant paths can be used to reach all destinations either
   directly or via other nodes.  Especially for battery-less nodes it is
   interesting to note that when the message arrives reliably at one
   correct destination, it will be passed on to all other correct
   destinations and in the contrary case is received by none



van der Stok & Lynn     Expires January 10, 2011                [Page 9]


Internet-Draft    CoAP Utilization for Building Control        July 2010


   [Mullender].  The consequence of such a specification is also that
   when a light in a group does not switch on, the lamp is faulty
   (either the lamp or the associated node).  Satisfaction of the
   validity requirement does not rely on returning acknowledgement
   messages, but on sufficient redundancy in nodes and network links.

   The scope of the multicast helps to send the message only to a subset
   of interested nodes.  However, a minimum set of nodes is needed to
   deliver the message reliably.  Dividing the building network in
   multicast areas helps to confine the multicast while at the same time
   assuring the minimum number of participants.  The choice of areas is
   a design parameter not discussed here.  Such areas can be supported
   with route-over or mesh-under routing.

   Another approach, favored by some implementations, is to send a
   packet n times over a wireless link with given intervals dependent on
   deployed physical medium.  It can be expected that several techniques
   will be advocated in the future.  Interoperability between wireless
   nodes from different manufacturers participating in a muticast
   requires that reliable multicast is standardized.  The challenges
   posed by the wireless, real-time, and battery-less aspects of these
   control networks motivate the specification of an appropriate
   (possibly new) multicast protocol.


6.  Application examples

   It is assumed that devices may exchange messages with a content
   defined by one of the existing building control standards e.g BACnet,
   LON, DALI, ZigBee Device Objects (ZDO), KNX, and others.  All of
   these standards have defined concepts like type (class) and type
   (class) instances.

   Within a given type a number of attributes exists that can be
   modified or read with a more or less complex invocation syntax.  This
   draft proposes that the path portion of the URI first identify the
   standard and then continue with a standard dependent syntax, to be
   defined by the standardization body interested in utilizing CoAP.
   For example, a command to a heating unit with a BACnet interface can
   be expressed as //authority/BACnet/BACnet-defined-command or a
   command to a DALI light can be expressed as //authority/DALI/
   DALI-defined-command.  The example request: PUT
   //light1.bu036.floor1/DALI/Intensity = 30 would translate to CoAP
   header [I-D.ietf-core-coap]:







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


Internet-Draft    CoAP Utilization for Building Control        July 2010


   -  dest IP address determined by resolving: //light1.bu036.floor1

   -  T bits to 0: Confirmable message

   -  Code = 2: PUT method

   -  OC bits set to 1 (for one Mime option)

   -  Transaction ID set

   -  Option type= 1, content type: /application/DALI

   -  DALI command: set Intensity attribute to 30

   The new option content type shows that new application mime types
   need to be defined to cover the building control standards: e.g.
   /application/DALI, /application/BACnet, etc.

   Examples of wireless, battery-less nodes are sensors used for
   measuring presence, temperature, light intensity, or humidity.
   Battery-less means that the nodes are switched off most of the time
   and sporadically power up and send out their current measured value.
   This value is either sent to a controller node or to a group of
   actuator nodes.  Examples are presence detection sent to lamps, or
   humidity level to a fan.

   The destination nodes of the measurements are probably powered by the
   mains or a derivative of the mains.  It seems unrealistic to have the
   controller or the actuator nodes send request messages to the
   battery-less nodes, after which the sender has to wait an interval
   determined by the duty cycle of the actuator or controller.  More
   natural is that the battery-less node wakes up and sends its message
   to its controller or actuator nodes which are always ready to receive
   a message.  For example, without a controller node, the presence
   detector can send presence regularly to a group of lights.

   The group can be defined on-line, by having the lights subscribe to
   the presence service, or the group can be defined off-line by the
   manager of the control network.  On-line definition is more natural
   in a dynamic home environment, while off-line is more natural in the
   office environment.  Off-line has the added advantage of checking on
   missing nodes.  For subscription the subscribing nodes have to learn
   the IP address(es) of the service(s) to which they want to subscribe.
   In case of off-line the servers have to learn the IP address of the
   multicast group.  The latter can be learned from DHCP options, by
   inserting the destination IP address inside the configuration file of
   the battery-less node.




van der Stok & Lynn     Expires January 10, 2011               [Page 11]


Internet-Draft    CoAP Utilization for Building Control        July 2010


   The CoAP protocol foresees the use of a non confirmable message
   packet to send these unsolicited responses to the multicast group or
   the single controller.  Again the syntax of the commands are most
   likely defined by legacy standards.  Assuming the DALI standard, the
   command PUT //blue-lights.bu036.floor1/DALI/OnOff=on leads to the
   following packet lay-out:

   -  dest multicast IP address determined by: //blue-
      lights.bu036.floor1

   -  T bits to 1: Non Confirmable message

   -  Code = 2, PUT method

   -  OC bits set to 1 (for one Mime option)

   -  Transaction ID set, for prevention of double messages

   -  Option type= 1, content type: /application/DALI

   -  DALI command: set OnOff attribute to on


7.  Discovery

   At a high level the the discovery strategy can be introduced with an
   example to create a group "DALI/lights" in a given building domain.

   -  The building domains can be resolved according to a domain
      specification which is consistent over a set of buildings
      maintained by a building control provider

   -  A query over a specified domain returns the IP addresses of all
      nodes in this domain with the reource DALI/lights

   -  The IP address of multicast group "DALI/lights" is defined

   -  The multicast group can be realized in two alternative ways:

      -  A list of IP addresses invoked by unicast.

      -  Each member allocates the IP multicast address, and receives
         all messages sent to this IP address.








van der Stok & Lynn     Expires January 10, 2011               [Page 12]


Internet-Draft    CoAP Utilization for Building Control        July 2010


   -  Messages can be multicast to the group DALI/lights.

   This implies a consistent naming scheme within each node.  The above
   group definition can be done on-line and off-line.

   Service or resource discovery is often scoped according to the
   building structure.  For example, BACnet defines "Who-Is" and "Who-
   Has" functions to locate nodes and resources, respectively, that
   match specified criteria (filters) in a defined network scope.  CoAP
   defines a resource discovery capability, but it is limited to link-
   local scope; examples may be found in [I-D.ietf-core-coap].  A
   service discovery capability is required to extend discovery to other
   subnets.

   DNS-based Service Discovery [I-D.cheshire-dnsext-dns-sd] defines a
   conventional way to configure DNS PTR, SRV, and TXT records to enable
   enumeration of services such as CoAP nodes within subdomains.  A
   service is specified by a name of the form Instance.Type.Domain,
   where the type for CoAP nodes is _coap._udp and the domain is a DNS
   domain name that identifies a building zone as in the examples above.
   For each CoAP end-point in the zone, a PTR record with the name
   _coap._udp is defined and it points to an SRV record having the
   Instance.Type.Domain name.

   All CoAP nodes in a given subdomain may be enumerated by sending a
   DNS query to the authoritative server for that zone for PTR records
   named _coap._udp.  A list of SRV records 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.  This can be
   used to store information about the device, e.g. schema=DALI,
   type=switch.

   Another feature of DNS-SD is the ability to specify service subtypes
   using PTR records.  For example, a CoAP node that supports BACnet
   commands might be represented with a PTR record having the name
   _bacnet._sub._coap._udp.  In this way, all BACnet nodes in a
   subdomain might be enumerated more efficiently.  This technique for
   node enumeration can be used to emulate BACnet's "Who-Is" function.

   With an enumerated list of nodes, a management workstation may then
   perform unicast resource discovery as described in
   [I-D.ietf-core-coap].  Alternately, the group multicast addressing
   described earlier can be used to scope queries for specific resources
   to different subdomains.  This technique effectively emulates
   BACnet's "Who-Has" function.




van der Stok & Lynn     Expires January 10, 2011               [Page 13]


Internet-Draft    CoAP Utilization for Building Control        July 2010


   When for example a lamp wants to discover the controller, it is only
   interested in the controllers located in the same office (area) as
   itself.  Consequently, the service discovery is related to the groups
   defined according to the building structure.  It is advisable to send
   a discovery message to a given group.  Also the packet does not need
   the complete URI in the URI option.  In conformance with RFC 5785
   [RFC5785], a packet from a controller with the request to return the
   device types of all DALI devices within the office bu036 can look
   like:

   -  dest multicast IP address defined by: //bu036.floor1

   -  T bits to 0: Confirmable messages

   -  Code 0: GET method

   -  OC bits set to 2 (for Mime and URI option)

   -  Transaction ID set

   -  Option type= 9, uri-path: LEN=13, ".well-known/r"

   -  Option type= 1, content type: /application/DALI

   -  DALI command: "return device type"

   The responses from the DALI nodes may look like:

   -  dest IP address of controller

   -  T bits to 2: Acknowledgement messages

   -  CODE = 0, OK

   -  OC bits set to 1 (for Mime option)

   -  Transaction ID identical

   -  Option type= 1, content type: /application/DALI

   -  DALI command: "type = Lamp"

   The rest of the protocol is dictated by the legacy standard in use
   but encapsulated within the CoAP discovery messages as shown above.







van der Stok & Lynn     Expires January 10, 2011               [Page 14]


Internet-Draft    CoAP Utilization for Building Control        July 2010


8.  Conclusions

   This I-D explains how building control is based on a hierarchical
   structure of the building areas, and that the logical scope of
   control and discovery messages is determined by the building
   structure.  It is shown that DNS subdomain delegation and naming can
   be used to express this hierarchy in the authority portion of the
   URI, down to the group or node level.  The hierarchical naming scheme
   need not be standardized, but rather can be designed to suit the
   application.  However, it is recommended that the scheme be employed
   consistently throughout the delegated subdomain(s).  The authority
   portion of the URI is resolved by the client 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-authority option need
   not be transmitted in requests to origin servers and thus there is no
   performance penalty for using descriptive naming schemes.

   The 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,
   including short uri if used.  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 additional IANA mime codes, and the mapping of legacy
   specific discovery semantics to CoAP resource discovery messages or
   DNS-SD lookups.

   It is expected that many control messages are sent by battery-less
   sensors with their own specific sending intervals to a group of
   actuator nodes or controllers.  Given the importance of groups and
   associated multicast messages to support legacy standard functions,
   the specification of a reliable multicast protocol with related
   multicast scope is needed in CoAP.


9.  Security considerations

   TODO: 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



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


Internet-Draft    CoAP Utilization for Building Control        July 2010


   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.


10.  IANA considerations

   This I-D proposes the following additions to the Media type
   identifiers in conformance with the proposals done in
   [I-D.ietf-core-coap].

                        Internet media type   Code
                        /application/BACnet   xx
                        /application/DALI     xx+1
                        /application/ZDO      xx+2
                        /application/LON      xx+3
                        /application/KNX      xx+4
                        /application/oBIX+exi xx+5

   TODO: Investigate CoAP specific well-known multicast address
   assignment?


11.  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, and
   Nicolas Riou.


12.  References

12.1.  Normative References

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

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




van der Stok & Lynn     Expires January 10, 2011               [Page 16]


Internet-Draft    CoAP Utilization for Building Control        July 2010


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

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

12.2.  Informative References

   [I-D.ietf-core-coap]
              Shelby, Z., Frank, B., and D. Sturek, "Constrained
              Application Protocol (CoAP)", draft-ietf-core-coap-01
              (work in progress), July 2010.

   [I-D.cheshire-dnsext-dns-sd]
              Cheshire, S. and M. Krochmal, "DNS-Based Service
              Discovery", draft-cheshire-dnsext-dns-sd-06 (work in
              progress), March 2010.

   [I-D.cheshire-dnsext-multicastdns]
              Cheshire, S. and M. Krochmal, "Multicast DNS",
              draft-cheshire-dnsext-multicastdns-11 (work in progress),
              March 2010.

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

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




van der Stok & Lynn     Expires January 10, 2011               [Page 17]


Internet-Draft    CoAP Utilization for Building Control        July 2010


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

   [KNX]      Kastner, W., Neugschwandtner, G., and M. Koegler, "AN OPEN
              APPROACH TO EIB/KNX SOFTWARE DEVELOPMENT", Web http://
              www.auto.tuwien.ac.at/~gneugsch/
              fet05-openapproach-preprint.pdf, 2005.

   [IEEE.802.15.4]
              "Information technology - Telecommunications and
              information exchange between systems - Local and
              metropolitan area networks - Specific requirements - Part
              15.4: Wireless Medium Access Control (MAC) and Physical
              Layer (PHY) Specifications for Low Rate Wireless Personal
              Area Networks (LR-WPANs)", IEEE Std 802.15.4-2006,
              June 2006,
              <http://standards.ieee.org/getieee802/802.15.html>.

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

   [Mullender]
              Mullender, S., "Distributed Systems, Second Edition",
              Section 5 , Addison-Wesley Publishing Company, Inc. ,
              ISBN 0-201-62427-3, 1995.


Authors' Addresses

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

   Email: peter.van.der.stok@philips.com
   URI:   http://www.research.philips.com/


   Kerry Lynn
   Consultant

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








van der Stok & Lynn     Expires January 10, 2011               [Page 18]