idnits 2.17.1 draft-vanderstok-core-bc-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 25, 2010) is 4932 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC5785' is defined on line 656, but no explicit reference was found in the text == Unused Reference: 'I-D.cheshire-dnsext-multicastdns' is defined on line 672, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 5785 (Obsoleted by RFC 8615) == Outdated reference: A later version (-11) exists of draft-cheshire-dnsext-dns-sd-06 == Outdated reference: A later version (-15) exists of draft-cheshire-dnsext-multicastdns-11 == Outdated reference: A later version (-18) exists of draft-ietf-core-coap-02 == Outdated reference: A later version (-14) exists of draft-ietf-core-link-format-00 == Outdated reference: A later version (-07) exists of draft-rahman-core-groupcomm-00 Summary: 2 errors (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CoRE P. van der Stok 3 Internet-Draft Philips Research 4 Intended status: Informational K. Lynn 5 Expires: April 28, 2011 Consultant 6 October 25, 2010 8 CoAP Utilization for Building Control 9 draft-vanderstok-core-bc-02 11 Abstract 13 This draft describes an example use of the RESTful CoAP protocol for 14 building automation and control (BAC) applications such as HVAC and 15 lighting. A few basic design assumptions are stated first, then URI 16 structure is utilized to define group as well as unicast scope for 17 RESTful operations. RFC 3986 defines the URI components as (1) a 18 scheme, (2) an authority, used here to locate the building, area, or 19 node under control, (3) a path, used here to locate the resource 20 under control, and (4) a query part (fragments are not supported in 21 CoAP.) Next, it is shown that DNS can be used to locate URIs on the 22 scale necessary in large commercial BAC deployments. Finally, a 23 method is proposed for mapping URIs onto legacy BAC resources, e.g., 24 to facilitate application-layer gateways. 26 This proposal supports the view that (1) building control is likely 27 to move in steps toward all-IP control networks based on the legacy 28 efforts provided by DALI, LON, BACnet, ZigBee, and other standards, 29 and (2) service discovery is complimentary to resource discovery and 30 facilitates control network scaling. 32 Status of this Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on April 28, 2011. 49 Copyright Notice 51 Copyright (c) 2010 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 68 1.2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 3 69 2. URI structure . . . . . . . . . . . . . . . . . . . . . . . . 5 70 2.1. Scheme part . . . . . . . . . . . . . . . . . . . . . . . 6 71 2.2. Authority part . . . . . . . . . . . . . . . . . . . . . . 6 72 2.3. Path part . . . . . . . . . . . . . . . . . . . . . . . . 7 73 3. Group Naming and Addressing . . . . . . . . . . . . . . . . . 8 74 4. Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . 10 75 4.1. DNS-Based Service Discovery . . . . . . . . . . . . . . . 10 76 4.2. Service vs Resource Discovery . . . . . . . . . . . . . . 11 77 4.3. Browsing for Services . . . . . . . . . . . . . . . . . . 11 78 5. Legacy Structure in CoAP . . . . . . . . . . . . . . . . . . . 11 79 6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 12 80 7. Security considerations . . . . . . . . . . . . . . . . . . . 13 81 8. IANA considerations . . . . . . . . . . . . . . . . . . . . . 13 82 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 83 10. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 14 84 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 85 11.1. Normative References . . . . . . . . . . . . . . . . . . . 14 86 11.2. Informative References . . . . . . . . . . . . . . . . . . 15 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 89 1. Introduction 91 1.1. Terminology 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 95 document are to be interpreted as described in "Key words for use in 96 RFCs to Indicate Requirement Levels" [RFC2119]. 98 In addition, the following conventions are used in this document. 100 The term "service" often means different things to different 101 communities and even different things to the same community. In 102 building control protocol standards, service is often used to refer 103 to a function in the RPC sense. In this context, we generally 104 substitute the term "function". In the IETF community, service may 105 often refer to an abstract capability such as "datagram delivery". 106 In this submission we use the term service, in the sense defined by 107 "DNS-based Service Discovery" [I-D.cheshire-dnsext-dns-sd], as 108 equivalent to a CoAP end-point. 110 A CoAP end-point is identified by the authority part of a URI. We 111 refer to this end-point (which is resolved to an {IP address, port} 112 tuple) as a "node". By "device" we generally mean the physical 113 object handled by the installer. While a device may host more than 114 one service, for simplicity we assume here that a given device may 115 only host a single CoAP node. 117 In examples below involving URIs, the authority is preceded by double 118 slashes "//" and path is preceded by a single slash "/". The 119 examples may make use of fully qualified or partial domain names and 120 the difference should be clear from the context. 122 1.2. Motivation 124 The CoAP protocol [I-D.ietf-core-coap] aims at providing a user 125 application protocol architecture that is targeted to a network of 126 nodes with a low resource provision such as memory, CPU capacity, and 127 energy. In general, IT application manufacturers strive to provide 128 the highest possible functionality and quality for a given price. In 129 contrast, the building controls market is highly price sensitive and 130 manufacturers tend to compete by delivering a given functionality and 131 quality for the lowest price. In the first market a decreasing 132 memory price leads to more software functionality, while in the 133 second market it leads to a lower Bill of Material (BOM). 135 The vast majority of nodes in a typical building control application 136 are resource constrained, making the standardization of a lightweight 137 application protocol like CoAP a necessary requirement for IP to 138 penetrate the device market. This approach is further indicated by 139 the low energy consumption requirement of battery-less nodes. Low 140 resource budget implies low throughput and small packet size as for 141 [IEEE.802.15.4]. Reduction of the packet size is obtained by using 142 the header reduction of 6LoWPAN [RFC4944] and encouraging small 143 payloads. 145 Several legacy building control standards (e.g [BACnet], [DALI], 146 [KNX], [LON], [ZigBee], etc.) have been developed based on years of 147 accumulated knowledge and industry cooperation. These standards 148 generally specify a data model, functional interfaces, packet 149 formats, and sometimes the physical medium for data objects and 150 function invocation. Many of these industry standards also specify 151 lower-level functionality such as proprietary transport protocols, 152 necessitating expensive stateful gateways for these standards to 153 interoperate. Many more recent building control network include IP- 154 based standards for transport (at least to interconnect islands of 155 functionality) and other functions such as naming and discovery. 156 CoAP will be successful in the building control market to the extent 157 that it can represent a given standard's data objects and provide 158 functions, e.g. resource discovery, that these standards depend on. 160 From the above the basic syntax assumptions can be summarized as: 162 - Generate small payloads. 164 - Compatible with legacy standards (e.g LON, BACnet, DALI, ZigBee 165 Device Objects). 167 - Service/resource discovery in agreement with legacy standards and 168 naming conventions. 170 This submission aims at an approach in which the payload contains 171 messages with a syntax defined by legacy control standards. 172 Accordingly, the syntax of the service/resource discovery messages is 173 related to the chosen legacy control standard. The intention is a 174 progressive approach to all-IP in building control. In a first stage 175 standard IETF based protocols (e.g CoAP, DNS-SD) are used for 176 transport of control messages and discovery messages expressed in a 177 legacy syntax. This approach enables the reuse of controllers based 178 on the semantics of the chosen control standard. In a later stage a 179 complete redesign of the controllers can be envisaged guided by the 180 accumulated experience with all-IP control. 182 Two concepts, hierarchy and group, are of prime importance in 183 building control, particularly in lighting and HVAC. Many control 184 messages or events are multicast from one device to a group of 185 devices (e.g. from a light switch to all lights in a room). The 186 scope of a multicast command or discovery message determines the 187 group of nodes that is targeted. A group scope may be defined as 188 link-local, or as a tree maintained by IP-multicast or an overlay 189 that corresponds to the logical structure of a building or campus, 190 and is independent of the underlying network structure. Techniques 191 for group communication are discussed in [I-D.rahman-core-groupcomm]. 193 As described in "Commercial Building Applications Requirements" 194 [I-D.martocci-6lowapp-building-applications] it is typical practice 195 to aggregate building control at the room, area, and supervisory 196 levels. Furthermore, networks for different subsystems (lights, 197 HVAC, etc.) or based on different legacy standards have historically 198 been isolated from each other in so-called "silos". RESTful web 199 services [Fielding] represent one possible way to expose 200 functionality and normalize data representations between silos in 201 order to facilitate higher order applications such as campus-wide 202 energy management. 204 Consequently, additional protocol oriented assumptions are: 206 - Nodes may be addressed by more than one group. 208 - Resources addressed by a group must be uniformly named across all 209 targeted nodes. 211 For clarity, this I-D limits itself to two types of applications: (1) 212 M2M control applications running within a building area without any 213 human intervention after commissioning of a given network segment and 214 (2) maintenance oriented applications where data are collected from 215 node in several building areas by nodes inside or outside the 216 building, and humans may intervene to change control settings. 218 2. URI structure 220 This I-D considers three elements of the URI: scheme, authority, and 221 path, as defined in "Uniform Resource Identifier (URI): Generic 222 Syntax" [RFC3986]. The authority is defined within the context of 223 standard DNS host naming, while the path is valid in relation to a 224 fully qualified domain name (FQDN) plus optional port (and protocol 225 is implicit, based on scheme). An example based on RFC 3986 is: 226 foo://host.example.com:8042/over/there?name=ferret#nose, where "foo" 227 is the scheme, "host.example.com:8042" is the authority, "/over/ 228 there" is the path, "name=ferret" is the query, and "nose" is the 229 fragment. Fragments are not supported in CoAP. 231 2.1. Scheme part 233 The default scheme specified in this submission is "coap". We assume 234 syntactic compatibility with the "http" scheme specification 235 [RFC2616], namely that the host part of the authority may be 236 represented either as a literal IP address or as a fully qualified 237 domain name. While scheme is irrelevant from the perspective of the 238 service, it is used in service discovery to identify the protocol 239 used to access the service. 241 TBD: we have yet to fully explore the utility of a separate scheme 242 (e.g., "coapm") to support group communication models as described in 243 [I-D.rahman-core-groupcomm]. 245 2.2. Authority part 247 The authority part is either a literal IP address or a DNS name 248 comprised of a local part, specifying an individual node or group of 249 nodes, and a global part specifying the (sub)domain that may reflect 250 the logical hierarchical structure of the building control network. 251 The result is said to be a fully qualified domain name (FQDN) which 252 is globally unique down to the group or node level. An optional port 253 number may be included in the authority following a single colon ":" 254 if the service port is other than the default CoAP value. 256 The CoAP spec [I-D.ietf-core-coap] states "When a CoAP server is 257 hosted by a 6LoWPAN node, it SHOULD support a port in the 61616-61631 258 compressed UDP port space defined in [RFC4944]. The specific port 259 number in use will be communicated in a URI and/or by some other 260 discovery mechanism." As shown below, DNS-SD 261 [I-D.cheshire-dnsext-dns-sd] is a viable technique for discovering 262 dynamic host and port assignments for a given service. However, the 263 use of dynamic ports in URIs is likely to lead to brittle (non- 264 persistent) identifiers as it is conventional to treat different 265 ports as representing different authorities and there is no assurance 266 that a coap server will consistently acquire the same dynamic port. 268 A building can be unambiguously addressed by it GPS coordinates or 269 more functionally by its zip or postal code. For example the Dutch 270 Internet provider, KPN, assigns to each subscriber a host name based 271 on its postcode. Analogously, an example authority for a building 272 may be given by: //bldg.zipcode-localnr.Country/ or more concretely 273 an imaginary address in the Netherlands as: //bldg.5533BA-125a.nl/. 274 The "bldg" prefix can specify the target node within the building. 275 Arriving at the node identified by //bldg.5533BA-125a.nl, the 276 receiving service can parse the path portion of the URI and perform 277 the requested method on the specified resource. 279 Buildings have a logical internal structure dependent on their size 280 and function. This ranges from a single hall without any structure 281 to a complex building with wings, floors, offices and possibly a 282 structure within individual rooms. The naming of the building 283 control equipment and the actual control strategy are intimately 284 linked to the building structure. It is therefore natural to name 285 the equipment based on their location within the building. 286 Consequently, the local part of the URI identifying a piece of 287 equipment is expressed in the building structure. An example is: 288 //light-27.floor-1.west-wing... 290 This proposal assumes a basic level of cooperation between the IT and 291 building management infrastructure, namely the ability of the former 292 to delegate DNS subdomains to the latter. This allows the building 293 controls installer to implement an appropriate naming scheme with the 294 required granularity. For institutional real estate such as a 295 college or corporate campus, the authority might be based on the 296 organization's domain, e.g. //node-or- 297 group.floor.wing.bldg.campus.example.com/. In cases where subdomain 298 delegation is not an option, structure can still be represented in a 299 "flat" namespace, subject to the 63 octet limit for a DNS sub- 300 string: //group1-floor2-west-bldg3-campus.example.com. 302 Most communication is device to device (M2M) within the building. 303 Often a device needs to communicate to all devices of a given type 304 within a given area of the building. For example a thermostat may 305 access all radiator actuators in a zone. A light switch located at 306 room 25b006 of floor one, expressed as: 307 //switch0.25b006.floor1.5533BA-125a.nl/, might specify a command to 308 light1 within the same room with //light1.25b006.floor1.5533BA- 309 125a.nl/. This approach seems to lead to rather verbose URI strings 310 in the packet, contrary to the small packet assumption. However, the 311 design of CoAP is such that the authority portion of the URI need not 312 be transmitted in requests sent to origin servers. The question 313 arises as to whether the syntax of the authority part needs to be 314 standardized for building control. Given the examples later in the 315 text, this appears more to be the concern of the building owner or 316 the installer. 318 2.3. Path part 320 Every network addressable resource is completely identified by a URI 321 scheme://authority/path. The path part of the URI specifies the 322 resource within a given node. The representation of object types and 323 their associated attributes are typically subjects for 324 standardization. There is no widely accepted standard for uniformly 325 naming building control device structure in a URI. A vigorous effort 326 is undertaken by the oBIX working group of OASIS [oBIX], but its 327 current impact is limited. 329 When a GET method with an URI like 330 "//t-sensor1.25b006.floor1.example.com/temperature" is sent, it 331 represents an a priori understanding that the node with name 332 t-sensor1 exists, is of a given standard type (e.g BACnet temperature 333 sensor), and that this standard type has the readable attribute: 334 temperature. When commands are sent to a group of nodes it MUST be 335 the case that the targeted resource has the same path on all targeted 336 nodes. Therefore, it is necessary to establish at least a local 337 uniform path naming convention to achieve this. One approach is to 338 include the name of the standard, e.g BACnet, as the first element in 339 the path and then employ the standard's chosen data scheme (in the 340 case of BACnet, /bacnet/device/object/property). Perhaps a better 341 alternative is to build on the concepts presented in 342 [I-D.ietf-core-link-format] and identify resources of a given type in 343 terms of the "/.well-known/core" prefix. 345 3. Group Naming and Addressing 347 Given a network configuration and associated prefixes, the network 348 operator needs to define an appropriate set of groups which can be 349 mapped to the building areas. Knowledge about the hierarchical 350 structure of the building areas may assist in defining a network 351 architecture which encourages an efficient group communication 352 implementation. IP-multicasting over the group is a possible 353 approach for building control, although proxy-based methods may prove 354 to be more appropriate in some deployments 355 [I-D.rahman-core-groupcomm]. 357 Example groups become: 359 URI authority Targeted group 360 //all.bldg6... "all nodes in building 6" 361 //all.west.bldg6... "all nodes in west wing, building 6" 362 //all.floor1.west.bldg6... "all nodes on floor 1, west wing, 363 ..." 364 //all.bu036.floor1.west.bldg6... "all nodes in office bu036, ..." 366 The granularity of this example is for illustration rather than a 367 recommendation. Experience will dictate the appropriate hierarchy 368 for a given structure as well as the appropriate number of groups per 369 subdomain. Note that in this example, the group name "all" is used 370 to identify the group of all nodes in each subdomain. In practice, 371 "all" could name an address record in each of the DNS zones shown 372 above and would bind to a different multicast address [RFC3596] in 373 each zone. Highly granular multicast scopes are only possible using 374 IPv6. The multicast address allocation strategy is beyond the scope 375 of this I-D, but various alternatives have been proposed 376 [RFC3306][RFC3307][RFC3956]. Some techniques in this proposal, e.g. 377 service discovery as described below, can be accomplished with a 378 single coap-specific multicast address as long as the desired scope 379 is building-wide. 381 To illustrate the concept of multiple group names within a building, 382 consider the definition, as done with [DALI], of scenes within the 383 context of a floor or a single office. For example, the setting of 384 all blue lights in office bu036 of floor 1 can be realized by 385 multicasting a message to the group "//blue-lights.bu036.floor1". 386 Each group is associated with an IP address. Consequently, when the 387 application specifies the sending of an "on" message to all blue 388 lights in the office, the message is multicast to the associated IP 389 address. The uri-authority option [I-D.ietf-core-coap] need not be 390 sent as part of the message. However to identify the resource that 391 is addressed, a short version of the resource path can be inserted as 392 an option as explained in [I-D.ietf-core-link-format]. 394 The binding of a group FQDN to multicast address (i.e., creation of 395 the AAAA record in the DNS zone server) happens during the 396 commissioning process. (TBD: How do we associate this name with 397 MLD's notion of a group?) Resolution of the group name to a 398 multicast address happens at restart of a source or receiver node. A 399 multicast address and associated group name in this context are 400 assumed to be long-lived. It can happen that during operation the 401 membership of the group changes (less or more lights) but its address 402 is not altered and neither its name. In the limit, the group can 403 degrade to a single controller that represents a non-networked 404 subsystem replacing the original networked group of nodes. Group 405 membership may be managed by a protocol such as Multicast Listener 406 Discovery [RFC5790]. 408 A group defines a set of nodes. All resources on a given node are 409 referenced by the multicast address(es) to which the node belongs. A 410 given node might belong to a number of groups. For example the node 411 belonging to the "blue-lights" group in a given corridor might also 412 belong to the groups: "whole building", "given wing", "given floor", 413 "given corridor", and "lights in given corridor". Assuming that 414 belonging to a group has as only consequence for the group member 415 that it should accept packets for an additional IP address, the 416 granularity of the domain names may have an impact on the complexity 417 of the DNS server but not necessarily on the low-resource 418 destinations or sources. Assuming that resolution of addresses only 419 happens at node start-up, the complexity of the DNS server need not 420 affect the responsiveness of the nodes. 422 In summary, the authority portion of the URI is used to identify a 423 node (group) and the resulting DNS name is bound to a unicast 424 (multicast) address. Naming is building or organization dependent, 425 must be flexible, and does not require standardization efforts but 426 SHOULD conform to some uniform convention. 428 4. Discovery 430 4.1. DNS-Based Service Discovery 432 DNS-Based Service Discovery (DNS-SD) defines a conventional way to 433 configure DNS PTR, SRV, and TXT records to facilitate discovery of 434 services such as CoAP nodes within a subdomain, using the existing 435 DNS infrastrucure. This section gives a cursory overview of DNS-SD; 436 see [I-D.cheshire-dnsext-dns-sd] for a detailed description. 438 A DNS-SD service is specified by a name of the form 439 Instance.ServiceType.Domain, where the service type for CoAP nodes is 440 "_coap._udp". The identifier "_udp" is required by the SRV record 441 definition [RFC2782] and "_coap" identifies the protocol on top of 442 udp. For each CoAP end-point in the zone, a PTR record with the name 443 _coap._udp is defined and each of these refers to SRV and TXT records 444 having the Instance.ServiceType.Domain name. 446 DNS-SD also supports one level of subtype, which could be used to 447 locate coap services based on object model, for example: 448 _bacnet._sub._coap._udp, _dali._sub._coap._udp, or 449 _zigbee._sub._coap._udp. The maximum length of the type and subtype 450 fields is 14 octets, therefore this could be extended to type- 451 function as _dali-light, _dali-switch, etc. 453 The Domain part of the service name is identical to the DNS 454 (sub)domain part of the authority in URIs that identify the resources 455 on this node or group and may identify a building zone as in the 456 examples above. 458 The Instance part of the service name is defined as part of the 459 commissioning process. It must be unique within the (sub)domain. 460 The complete service name uniquely identifies both a SRV and TXT 461 record in the DNS zone. The granularity of a service name MAY be 462 that of a host or group, or it could represent a particular resource 463 within a coap node. The SRV record contains the host (AAAA record) 464 name and port of the service. In the case where a service name 465 identifies a particular resource, the path part of the URI must be 466 placed in the TXT record. 468 4.2. Service vs Resource Discovery 470 While service discovery is concerned with finding the IP address, 471 port, and protocol of a named service, resource discovery is a fine- 472 grained discovery of resource URIs within a web service. 473 [I-D.ietf-core-link-format] specifies a resource discovery pattern, 474 such that sending a confirmable GET message for the /.well-known/core 475 resource returns a set of links that identify all resources present 476 on this node that are exposed as functions. 478 Assuming the ability to multicast the GET over the local link, the 479 coap resource discovery can be used to populate the DNS-SD database 480 in a semi-automated fashion. CoAP resource descriptions can be 481 imported into DNS-SD for exposure to service discovery by using the 482 n= attribute as the basis for a unique "Instance" name, defaulting to 483 "_coap._udp" for the ServiceType, and using some means to establish 484 which domain the service should be registered in (TBD). The DNS TXT 485 record can be populated by importing the other resource description 486 attributes as they share the same key=value format specified in 487 Section 6 of [I-D.cheshire-dnsext-dns-sd]. 489 4.3. Browsing for Services 491 CoAP nodes in a given subdomain may be enumerated by sending a DNS 492 query to the authoritative server for that zone for PTR records named 493 _coap._udp. A list of names for SRV records matching that 494 ServiceType.Domain is returned. Each SRV record contains the port 495 and host name of a CoAP node. The IP address of the node is obtained 496 by resolving the host name. DNS-SD also specifies an optional TXT 497 record, having the same name as the SRV record, which can contain 498 "key=value" attributes. This can be used to store information about 499 the device, e.g., schema=DALI, type=switch. The format of the TXT 500 record can be standardized by the various control standards bodies as 501 they adopt CoAP. 503 TO DO: How to handle changes in building control network 504 configuration. 506 5. Legacy Structure in CoAP 508 In the text above it is shown how information to locate services and 509 devices can be stored in a DNS zone registry. An installation tool 510 can populate the registry with the resource information gleaned by 511 the coap GET query to /.well-known/core. Applications can then query 512 the registry to find the address, port, and path for targeted 513 services/resources. Given the returned information, an application 514 that acts on devices of a given legacy standard can invoke the legacy 515 service using coap methods. Assume a short URI-reference /dl and the 516 setting of a value of 200 in the DALI device, dt is the number of the 517 dali type stored in the TXT record, and ct=52 is the proposed 518 Internet media type. 520 Client DALI server 521 | 522 | REQUEST | 523 |------- CON + PUT /dl [TID = 1234, ct=52] --------->| 524 | binary 16 bit payload dt*256 + 200 | 525 | | 526 | RESPONSE | 527 |<---------- ACK + 200 OK [TID = 1234] ------------- | 528 | | 530 Figure 1: Sending a DALI setting with coap to DALI device 532 In the example the format of the payload is determined by the legacy 533 standard. The short URI /dl on this IP address is obtained from the 534 TXT record for this service, e.g., sh="/dl". The value dt is entered 535 (e.g. dt="200") as the number identifying the dali type of the dali 536 compatible resource. 538 6. Conclusions 540 This I-D explains how naming in building control is based on a 541 hierarchical structure of the building areas. It is shown that DNS 542 subdomain delegation and naming can be used to express this hierarchy 543 in the authority portion of the URI, down to the group or node level. 544 The hierarchical naming scheme need not be standardized, but rather 545 can be designed to suit the application. However, it is recommended 546 that the scheme be employed consistently throughout the delegated 547 subdomain(s). 549 The authority portion of the URI is resolved by the client, using 550 conventional DNS, into the unicast or multicast IP address of the 551 targeted node(s). Taking advantage of the CoAP design 552 [I-D.ietf-core-coap], the uri-authority option need not be 553 transmitted in requests to origin servers and thus there is no 554 performance penalty for using descriptive naming schemes. The coap 555 design allows sending a short url to distinguish between resources on 556 a given node, resulting in very compact identifiers. 558 DNS-SD [I-D.cheshire-dnsext-dns-sd] can be used to scale up service 559 discovery beyond the local link. DNS-SD can be used to enumerate 560 instances of a given service type within a given sub-domain. This 561 affords additional flexibility, such as the ability to discover 562 dynamic port assignments for coap node, locate coap nodes by subtype, 563 or bind service names for particular coap URIs. 565 A targeted resource is specified by the path portion of the URI. 566 Again, this I-D does not mandate a universal naming standard for 567 resources but uses examples to show how resources could be named for 568 various legacy standards. An obvious requirement for resources that 569 are accessed by multicast is that they MUST all share the same path, 570 including short uri if used. It is shown that it is possible to 571 transport legacy commands (e.g. expressed in BACnet, LON, DALI, 572 ZigBee, etc.) inside a CoAP message body. This necessitates the 573 definition of an additional IANA mime code, and the mapping of legacy 574 specific discovery semantics to CoAP resource discovery messages or 575 DNS-SD lookups. 577 7. Security considerations 579 TBD: The detailed CoAP security analysis needs to encompass scenarios 580 for building control applications. 582 Based on the programming model presented in this I-D, security 583 scenarios for building control need to be stated. Appropriate 584 methods to counteract the proposed threats may be based on the work 585 done elsewhere, for example in the ZigBee over IP context. 587 Multicast messages are, by their nature, transmitted via UDP. Any 588 privacy applied to such messages must be block oriented and based on 589 group keys shared by all targeted nodes. The CoRE security analysis 590 must be broadened to include multicast scenarios. 592 8. IANA considerations 594 This I-D proposes the following additions to the Media type 595 identifiers in conformance with the proposals done in 596 [I-D.ietf-core-coap]. 598 Internet media type Code 599 /application/legacy 52 601 9. Acknowledgements 603 This I-D has benefited from conversations with and comments from 604 Andrew Tokmakoff, Emmanuel Frimout, Jamie Mc Cormack, Oscar Garcia, 605 Dee Denteneer, Joop Talstra, Zach Shelby, Jerald Martocci, Matthieu 606 Vial, Jerome Hamel, and Nicolas Riou. 608 10. Changelog 610 - Removed all references to multicast and multicast scope, given 611 draft of rahman group communication. 613 - Adapted examples to coap-2 and core-link drafts. 615 - transport short URL for destination recognition. 617 - Elaborated legacy discovery under DNS-SD. 619 11. References 621 11.1. Normative References 623 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 624 Requirement Levels", BCP 14, RFC 2119, March 1997. 626 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 627 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 628 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 630 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 631 specifying the location of services (DNS SRV)", RFC 2782, 632 February 2000. 634 [RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6 635 Multicast Addresses", RFC 3306, August 2002. 637 [RFC3307] Haberman, B., "Allocation Guidelines for IPv6 Multicast 638 Addresses", RFC 3307, August 2002. 640 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 641 "DNS Extensions to Support IP Version 6", RFC 3596, 642 October 2003. 644 [RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous 645 Point (RP) Address in an IPv6 Multicast Address", 646 RFC 3956, November 2004. 648 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 649 Resource Identifier (URI): Generic Syntax", STD 66, 650 RFC 3986, January 2005. 652 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 653 "Transmission of IPv6 Packets over IEEE 802.15.4 654 Networks", RFC 4944, September 2007. 656 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known 657 Uniform Resource Identifiers (URIs)", RFC 5785, 658 April 2010. 660 [RFC5790] Liu, H., Cao, W., and H. Asaeda, "Lightweight Internet 661 Group Management Protocol Version 3 (IGMPv3) and Multicast 662 Listener Discovery Version 2 (MLDv2) Protocols", RFC 5790, 663 February 2010. 665 11.2. Informative References 667 [I-D.cheshire-dnsext-dns-sd] 668 Cheshire, S. and M. Krochmal, "DNS-Based Service 669 Discovery", draft-cheshire-dnsext-dns-sd-06 (work in 670 progress), March 2010. 672 [I-D.cheshire-dnsext-multicastdns] 673 Cheshire, S. and M. Krochmal, "Multicast DNS", 674 draft-cheshire-dnsext-multicastdns-11 (work in progress), 675 March 2010. 677 [I-D.ietf-core-coap] 678 Shelby, Z., Frank, B., and D. Sturek, "Constrained 679 Application Protocol (CoAP)", draft-ietf-core-coap-02 680 (work in progress), September 2010. 682 [I-D.ietf-core-link-format] 683 Shelby, Z., "CoRE Link Format", 684 draft-ietf-core-link-format-00 (work in progress), 685 October 2010. 687 [I-D.martocci-6lowapp-building-applications] 688 Martocci, J., Schoofs, A., and P. Stok, "Commercial 689 Building Applications Requirements", 690 draft-martocci-6lowapp-building-applications-01 (work in 691 progress), July 2010. 693 [I-D.rahman-core-groupcomm] 694 Rahman, A., "Group Communication for CoAP", 695 draft-rahman-core-groupcomm-00 (work in progress), 696 October 2010. 698 [BACnet] Bender, J. and M. Newman, "BACnet/IP", 699 Web http://www.bacnet.org/Tutorial/BACnetIP/index.html. 701 [ZigBee] Tolle, G., "A UDP/IP Adaptation of the ZigBee Application 702 Protocol", draft-tolle-cap-00 (work in progress), 703 October 2008. 705 [LON] "LONTalk protocol specification, version 3", 1994. 707 [DALI] "DALI Manual", Web http://www.dali-ag.org/c/manual_gb.pdf, 708 2001. 710 [KNX] Kastner, W., Neugschwandtner, G., and M. Koegler, "AN OPEN 711 APPROACH TO EIB/KNX SOFTWARE DEVELOPMENT", Web http:// 712 www.auto.tuwien.ac.at/~gneugsch/ 713 fet05-openapproach-preprint.pdf, 2005. 715 [IEEE.802.15.4] 716 "Information technology - Telecommunications and 717 information exchange between systems - Local and 718 metropolitan area networks - Specific requirements - Part 719 15.4: Wireless Medium Access Control (MAC) and Physical 720 Layer (PHY) Specifications for Low Rate Wireless Personal 721 Area Networks (LR-WPANs)", IEEE Std 802.15.4-2006, 722 June 2006, 723 . 725 [oBIX] "oBIX working group", Web http://www.obix.org, 2003. 727 [Fielding] 728 Fielding, R., "Architectural Styles and the Design of 729 Network-based Software Architectures, Second Edition", 730 Doctoral dissertation , University of California, Irvine , 731 Web http://www.ics.uci.edu/~fielding/pubs/dissertation/ 732 top.html, 2000. 734 Authors' Addresses 736 Peter van der Stok 737 Philips Research 738 High Tech Campus 739 Eindhoven, 5656 AA 740 The Netherlands 742 Email: peter.van.der.stok@philips.com 744 Kerry Lynn 745 Consultant 747 Phone: +1 978 460 4253 748 Email: kerlyn@ieee.org