idnits 2.17.1 draft-vanderstok-core-bc-01.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 : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 701 has weird spacing: '.../BACnet xx...' -- The document date (July 9, 2010) is 5033 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.cheshire-dnsext-multicastdns' is defined on line 763, but no explicit reference was found in the text == Unused Reference: 'ZigBee' is defined on line 777, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5785 (Obsoleted by RFC 8615) == Outdated reference: A later version (-18) exists of draft-ietf-core-coap-01 == 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 Summary: 1 error (**), 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: January 10, 2011 Consultant 6 July 9, 2010 8 CoAP Utilization for Building Control 9 draft-vanderstok-core-bc-01 11 Abstract 13 This I-D describes an example use of the RESTful CoAP protocol for 14 building control applications such as HVAC and lighting. A few basic 15 design assumptions are stated first. The URI structure is exploited 16 to define multicast as well as unicast scopes. RFC 3986 defines the 17 URI components as (1) a scheme, (2) an authority, used here to locate 18 the building, area, or node under control, (3) a path, used here to 19 locate the resource under control, and (4) a query and fragment part, 20 where fragments are not supported in CoAP. 22 This proposal supports the view that (1) building control is likely 23 to move in steps toward all-IP control networks based on the legacy 24 efforts provided by DALI, LON, BACnet, ZigBee, and other standards, 25 (2) service discovery is complimentary to resource discovery and 26 facilitates control network scaling, and (3) the provision of a 27 reliable group communication protocol is essential to support 28 building control applications. 30 Status of this Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on January 10, 2011. 47 Copyright Notice 48 Copyright (c) 2010 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Conventions and Terminology Used in this Document . . . . . . 3 64 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 3. URI structure . . . . . . . . . . . . . . . . . . . . . . . . 5 66 3.1. Scheme part . . . . . . . . . . . . . . . . . . . . . . . 5 67 3.2. Authority part . . . . . . . . . . . . . . . . . . . . . . 6 68 3.3. Path part . . . . . . . . . . . . . . . . . . . . . . . . 7 69 4. Group Addressing . . . . . . . . . . . . . . . . . . . . . . . 7 70 5. Reliable multicast . . . . . . . . . . . . . . . . . . . . . . 9 71 6. Application examples . . . . . . . . . . . . . . . . . . . . . 10 72 7. Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . 12 73 8. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 15 74 9. Security considerations . . . . . . . . . . . . . . . . . . . 15 75 10. IANA considerations . . . . . . . . . . . . . . . . . . . . . 16 76 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 77 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 78 12.1. Normative References . . . . . . . . . . . . . . . . . . . 16 79 12.2. Informative References . . . . . . . . . . . . . . . . . . 17 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 82 1. Conventions and Terminology Used in this Document 84 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 85 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 86 document are to be interpreted as described in "Key words for use in 87 RFCs to Indicate Requirement Levels" [RFC2119]. 89 The term "service" may mean different things to different communities 90 and sometimes different things to the same community. In building 91 control protocol standards, service is often used to refer to a 92 function in the RPC sense. In this context, we generally substitute 93 the term "function". In the IETF community, service may often refer 94 to an abstract capability such as "datagram delivery". In this 95 submission we use the term service, in the sense defined by "DNS- 96 based Service Discovery" [I-D.cheshire-dnsext-dns-sd], as equivalent 97 to a CoAP end-point. 99 A CoAP end-point is identified by the authority part of a URI. We 100 refer to this end-point (which is resolved to an {IP address, port} 101 tuple) as a "node". By "device" we generally mean the physical 102 object handled by the installer. While a device may host more than 103 one service, for simplicity we assume here that a given device may 104 only host a single CoAP node. 106 In examples below involving URIs, the authority is preceded by double 107 slashes "//" and path is preceded by a single slash "/". The 108 examples may make use of fully qualified or partial domain names and 109 the difference should be clear from the context. 111 2. Motivation 113 The CoAP protocol [I-D.ietf-core-coap] aims at providing a user 114 application protocol architecture that is targeted to a network of 115 nodes with a low resource provision such as memory, CPU capacity, and 116 energy. In general, IT application manufacturers strive to provide 117 the highest possible functionality and quality for a given price. In 118 contrast, the building controls market is highly price sensitive and 119 manufacturers tend to compete by delivering a given functionality and 120 quality for the lowest price. 122 The vast majority of nodes in a typical building control application 123 are resource constrained, making the standardization of a lightweight 124 application protocol like CoAP a necessary requirement for IP to 125 penetrate the device market. This approach is further indicated by 126 the low energy consumption requirement of battery-less nodes. Low 127 resource budget implies low throughput and small packet size as for 128 [IEEE.802.15.4]. Reduction of the packet size is obtained by using 129 the header reduction of 6LoWPAN [RFC4944] and encouraging small 130 payloads. 132 Several legacy building control standards (e.g [BACnet], [LON], 133 [DALI], [KNX], etc.) have been developed based on years of 134 accumulated knowledge and industry cooperation. These standards 135 generally specify a data model, functions, packet formats, and 136 sometimes the physical medium for data objects and function 137 invocation. Many of these industry standards also specify lower- 138 level functionality such as proprietary transport protocols, 139 necessitating expensive stateful gateways for these standards to 140 interoperate. Many are in the process of transitioning to IP-based 141 standards for transport and other functions such as naming and 142 discovery. CoAP will be succesful in the building control market to 143 the extent that it can represent a given standard's data objects and 144 provide functions, e.g. resource discovery, that these standards 145 depend on. 147 From the above the basic syntax assumptions can be summarized as: 149 - Generate small payloads. 151 - Compatible with legacy standards (e.g LON, BACnet, DALI, ZigBee 152 Device Objects). 154 - Service/resource discovery in agreement with legacy standards and 155 naming conventions. 157 This submission aims at an approach in which the payload contains 158 messages with a syntax defined by legacy control standards. 159 Accordingly, the syntax of the service/resource discovery messages is 160 related to the chosen legacy control standard. The intention is a 161 progressive approach to all-IP in building control. In a first stage 162 standard IETF based protocols (e.g CoAP, DNS-SD) are used for 163 transport of control messages and discovery messages expressed in a 164 legacy syntax. This approach enables the reuse of controllers based 165 on the semantics of the chosen control standard. In a later stage a 166 complete redesign of the controllers can be envisaged guided by the 167 accumulated experience with all-IP control. 169 Two concepts, hierarchy and group, are of prime importance in 170 building control, particularly in lighting and HVAC. Many control 171 messages or events are multicast from one device to a group of 172 devices (e.g. from a light switch to all lights in a room). The 173 scope of a multicast command or discovery message covers the group of 174 nodes that is targeted. Defining multicast scopes on the basis of 175 hop count or the existence of edge routers is not always sufficient 176 in buildings where the network architecture may be independent of the 177 controlled areas (e.g. rooms) in the building. 179 As described in "Commercial Building Applications Requirements" 180 [I-D.martocci-6lowapp-building-applications] it is typical practice 181 to aggregate building control at the room, area, and supervisory 182 levels. Furthermore, networks for different subsystems (lights, 183 HVAC, etc.) or based on different legacy standards have historically 184 been isolated from each other in so-called "silos". RESTful web 185 services represent one possible way to expose functionality and 186 normalize data representations between silos in order to facilitate 187 higher order applications such as campus-wide energy management. 189 Consequently, additional protocol oriented assumptions are: 191 - A syntactic definition of the multicast scope applicable to all 192 control application multicasts in the building. 194 - Nodes may be addressed by more than one group. 196 - Resources addressed by a group must be uniformly named across all 197 targeted nodes. 199 For clarity, this I-D limits itself to two types of applications: (1) 200 M2M control applications running within a building area without any 201 human intervention after commissioning of a given network segment and 202 (2) maintenance oriented applications where data are collected from 203 node in several building areas by nodes inside or outside the 204 building, and humans may intervene to change control settings. 206 3. URI structure 208 This I-D considers three elements of the URI: scheme, authority, and 209 path, as defined in "Uniform Resource Identifier (URI): Generic 210 Syntax" [RFC3986]. The authority is defined within the context of 211 standard DNS host naming, while the path is valid in relation to a 212 fully qualified domain name (FQDN) plus optional port (and protocol 213 is implicit). An example based on RFC 3986 is: 214 foo://host.example.com:8042/over/there?name=ferret#nose, where "foo" 215 is the scheme, "host.example.com:8042" is the authority, "/over/ 216 there" is the path, "name=ferret" is the query, and "nose" is the 217 fragment. Fragments are not supported in CoAP. 219 3.1. Scheme part 221 The default scheme in this submission is "coap" although the 222 intention is that everything stated below about URIs SHOULD apply 223 equally to "http" and might be exposed, say, through an http-to-coap 224 gateway. That topic is beyond the scope of this document. 226 3.2. Authority part 228 The authority part is either a literal IP address or a DNS name 229 comprised of a global part specifying the domain and a local part 230 specifying the logical hierarchical structure of the building control 231 network, down to the group or node level. An optional port number 232 may be included in the authority following a single colon ":" if the 233 service port is other than the default CoAP value. 235 A building can be unambiguously addressed by it GPS coordinates or 236 more functionally by its zip or postal code. For example the Dutch 237 Internet provider, KPN, assigns to each subscriber a host name based 238 on its postcode. Analogously, an example authority for a building 239 may be given by: //bldg.zipcode-localnr.Country/ or more concretely 240 an imaginary address in the Netherlands as: //bldg.5533BA-125a.nl/. 241 The "bldg" prefix can specify the target node within the building. 242 Arriving at the node identified by //bldg.5533BA-125a.nl, the 243 receiving service can parse the path portion of the URI and perform 244 the requested method on the specified resource. 246 Buildings have a logical internal structure dependent on their size 247 and function. This ranges from a single hall without any structure 248 to a complex building with wings, floors, offices and possibly a 249 structure within individual rooms. The naming of the building 250 control equipment and the actual control strategy are intimately 251 linked to the building structure. It is therefore natural to name 252 the equipment based on their location within the building. 253 Consequently, the local part of the URI identifying a piece of 254 equipment is expressed in the building structure. An example is: 255 //light-27.floor-1.west-wing... 257 This proposal assumes a basic level of cooperation between the IT and 258 building management infrastructure, namely the ability of the former 259 to delegate DNS subdomains to the latter. This allows the building 260 controls installer to implement an appropriate naming scheme with the 261 required granularity. For institutional real estate such as a 262 college or corporate campus, the authority might be based on the 263 organization's domain, e.g. //node-or- 264 group.floor.wing.bldg.campus.example.com/. In cases where subdomain 265 delegation is not an option, structure can still be represented in a 266 "flat" namespace, subject to the 63 octet limit for a DNS sub- 267 string: //group1-floor2-west-bldg3-campus.example.com. 269 Most communication is device to device (M2M) within the building. 270 Often a device needs to communicate to all devices of a given type 271 within a given area of the building. For example a thermostat may 272 access all radiator actuators in a zone. A light switch located at 273 room 25b006 of floor one, expressed as: 274 //switch0.25b006.floor1.5533BA-125a.nl/, might specify a command to 275 light1 within the same room with //light1.25b006.floor1.5533BA- 276 125a.nl/. This approach seems to lead to rather verbose URI strings 277 in the packet, contrary to the small packet assumption. However, the 278 design of CoAP is such that the authority portion of the URI need not 279 be transmitted in requests sent to origin servers. The question 280 arises as to whether the syntax of the authority part needs to be 281 standardized for building control. Given the examples later in the 282 text, this appears more to be the concern of the building owner or 283 the installer. 285 3.3. Path part 287 Every network addressable resource is completely identified by a URI 288 scheme://authority/path. The path part of the URI specifies the 289 resource within a given node. The representation of object types and 290 their associated attributes are typically subjects for 291 standardization. There is no widely accepted standard for uniformly 292 naming building control device structure in a URI. A vigorous effort 293 is undertaken by the oBIX working group of OASIS [oBIX]. 295 When a GET method with an URI like: //t-sensor1.25b006.floor1/ 296 temperature is sent, it represents an a priori understanding that the 297 node with name t-sensor1 exists, is of a given standard type (e.g 298 BACnet temperature sensor), and that this standard type has the 299 readable attribute: temperature. However, in the case of multicast 300 commands to a group of nodes it is necessary that the targeted 301 resource have the same path on all targeted nodes. Therefore, it is 302 necessary to establish at least a local uniform path naming 303 convention to achieve this. One approach is to include the name of 304 the standard, e.g BACnet, as the first element in the path and then 305 employ the standard's natural data scheme (in the case of BACnet, 306 device/object/property). 308 4. Group Addressing 310 As suggested by the examples above, the scope of the messages can be 311 logically associated with the URI authority. This provides a better 312 handle to define the multicast scope than the traditional TTL counter 313 preventing the multicast message to pass one or more routers. This 314 more sophisticated scoping mechanism is needed to decouple multicast 315 scopes from the network layout. This is reflected by the capability 316 provided in [BACnet] to define the scope of its service/resource 317 discovery messages. 319 Given a network configuration and associated prefixes, the network 320 operator needs to define an appropriate set of multicast groups which 321 can be mapped to the building areas. Knowledge about the 322 hierarchical structure of the building areas may assist in defining a 323 network architecture which encourages an efficient multicast 324 implementation. Example multicast groups become: 326 URI authority Targeted group 327 //all.bldg6 "all nodes in building 6" 328 //all.west.bldg6 "all nodes in west wing, building 6" 329 //all.floor1.west.bldg6 "all nodes on floor 1, west wing, ..." 330 //all.bu036.floor1.west.bldg6 "all nodes in office bu036, ..." 332 The granularity of this example is for illustration rather than a 333 recommendation. Experience will dictate the appropriate hierarchy 334 for a given structure as well as the appropriate number of groups per 335 subdomain. Note that in this example, the group name "all" is used 336 to identify the group of all nodes in each subdomain. In practice, 337 "all" would name an address record in each of the DNS zones shown 338 above and would bind to a different multicast address [RFC3596] in 339 each zone. Highly granular multicast scopes are only possible using 340 IPv6. The multicast address allocation strategy is beyond the scope 341 of this I-D, but various alternatives have been proposed 342 [RFC3306][RFC3307][RFC3956]. Some techniques in this proposal, e.g. 343 service discovery as described below, can be accomplished with a 344 single coap-specific multicast address as long as the desired scope 345 is building-wide. 347 To illustrate the concept of multiple group names within a given 348 multicast scope, consider the definition, as done with [DALI], of 349 scenes within the context of a floor or a single office. For 350 example, the setting of all blue lights in office bu036 of floor 1 351 can be realized by multicasting a message to the group "//blue- 352 lights.bu036.floor1". Each group is associated with an IP address. 353 Consequently, when the application specifies the sending of an "on" 354 message to all blue lights in the office, the message is multicast to 355 the associated IP address. The uri-authority option 356 [I-D.ietf-core-coap] need not be sent as part of the message. 358 A group defines a set of nodes. All resources on a given node are 359 referenced by the multicast address(es) to which the node belongs. A 360 given node might belong to a number of groups. For example the node 361 belonging to the "blue-lights" group in a given corridor might also 362 belong to the groups: "whole building", "given wing", "given floor", 363 "given corridor", and "lights in given corridor". 365 In summary, the authority portion of the URI is used to identify a 366 node (group) and the resulting DNS name is bound to a unicast 367 (multicast) address, resulting in an associated unicast (multicast) 368 scope. Naming is building or organization dependent, must be 369 flexible, and does not require standardization efforts but SHOULD 370 conform to some uniform convention. In the context of an 371 administrated professional building, groups can be defined off-line 372 and stored in DNS server configuration. Automated enumeration, based 373 on service discovery methods described below, may be used to locate 374 nodes and add them to groups during the building commissioning phase. 376 5. Reliable multicast 378 A reliable group communication (multicast) is essential for an 379 efficient building control application. Reliable multicast supports 380 guaranteed delivery of messages to a group of nodes. The 381 representative example is a group of lights that need to be switched 382 on simultaneously. Although the delay between sending the command 383 message (e.g. from a switch) to the effective switching on of the 384 lights may be up to one second, all lights in the group should appear 385 to switch on simultaneously (within an interval of 100-200 msec). 386 Examples of reliable multicast specifications are cited in 387 [Mullender]. In the case of real-time control of devices, the 388 following specification applies: 390 Validity - If sender sends message, m, to a group, g, of 391 destinations, a path exists between sender and destinations, and 392 sender and destinations are correct, all destinations in g 393 eventually receive m. 395 Integrity - destination receives m at most once from sender and 396 only if sender sent m to a group including destination. 398 Agreement - If a correct destination of g receives m, then all 399 correct destinations of g receive m. 401 Timeliness - There is a known constant D such that if m is sent at 402 time t, no correct destination receives m after t+D. 404 Assuming that every new multicast message contains a unique 405 transaction identifier, the integrity requirement can be met by 406 checking this identifier. The agreement and timeliness requirements 407 can be met by multicast algorithms developed for real time computing. 408 It is assumed that the clocks of the nodes are synchronized and 409 multiple redundant paths can be used to reach all destinations either 410 directly or via other nodes. Especially for battery-less nodes it is 411 interesting to note that when the message arrives reliably at one 412 correct destination, it will be passed on to all other correct 413 destinations and in the contrary case is received by none 415 [Mullender]. The consequence of such a specification is also that 416 when a light in a group does not switch on, the lamp is faulty 417 (either the lamp or the associated node). Satisfaction of the 418 validity requirement does not rely on returning acknowledgement 419 messages, but on sufficient redundancy in nodes and network links. 421 The scope of the multicast helps to send the message only to a subset 422 of interested nodes. However, a minimum set of nodes is needed to 423 deliver the message reliably. Dividing the building network in 424 multicast areas helps to confine the multicast while at the same time 425 assuring the minimum number of participants. The choice of areas is 426 a design parameter not discussed here. Such areas can be supported 427 with route-over or mesh-under routing. 429 Another approach, favored by some implementations, is to send a 430 packet n times over a wireless link with given intervals dependent on 431 deployed physical medium. It can be expected that several techniques 432 will be advocated in the future. Interoperability between wireless 433 nodes from different manufacturers participating in a muticast 434 requires that reliable multicast is standardized. The challenges 435 posed by the wireless, real-time, and battery-less aspects of these 436 control networks motivate the specification of an appropriate 437 (possibly new) multicast protocol. 439 6. Application examples 441 It is assumed that devices may exchange messages with a content 442 defined by one of the existing building control standards e.g BACnet, 443 LON, DALI, ZigBee Device Objects (ZDO), KNX, and others. All of 444 these standards have defined concepts like type (class) and type 445 (class) instances. 447 Within a given type a number of attributes exists that can be 448 modified or read with a more or less complex invocation syntax. This 449 draft proposes that the path portion of the URI first identify the 450 standard and then continue with a standard dependent syntax, to be 451 defined by the standardization body interested in utilizing CoAP. 452 For example, a command to a heating unit with a BACnet interface can 453 be expressed as //authority/BACnet/BACnet-defined-command or a 454 command to a DALI light can be expressed as //authority/DALI/ 455 DALI-defined-command. The example request: PUT 456 //light1.bu036.floor1/DALI/Intensity = 30 would translate to CoAP 457 header [I-D.ietf-core-coap]: 459 - dest IP address determined by resolving: //light1.bu036.floor1 461 - T bits to 0: Confirmable message 463 - Code = 2: PUT method 465 - OC bits set to 1 (for one Mime option) 467 - Transaction ID set 469 - Option type= 1, content type: /application/DALI 471 - DALI command: set Intensity attribute to 30 473 The new option content type shows that new application mime types 474 need to be defined to cover the building control standards: e.g. 475 /application/DALI, /application/BACnet, etc. 477 Examples of wireless, battery-less nodes are sensors used for 478 measuring presence, temperature, light intensity, or humidity. 479 Battery-less means that the nodes are switched off most of the time 480 and sporadically power up and send out their current measured value. 481 This value is either sent to a controller node or to a group of 482 actuator nodes. Examples are presence detection sent to lamps, or 483 humidity level to a fan. 485 The destination nodes of the measurements are probably powered by the 486 mains or a derivative of the mains. It seems unrealistic to have the 487 controller or the actuator nodes send request messages to the 488 battery-less nodes, after which the sender has to wait an interval 489 determined by the duty cycle of the actuator or controller. More 490 natural is that the battery-less node wakes up and sends its message 491 to its controller or actuator nodes which are always ready to receive 492 a message. For example, without a controller node, the presence 493 detector can send presence regularly to a group of lights. 495 The group can be defined on-line, by having the lights subscribe to 496 the presence service, or the group can be defined off-line by the 497 manager of the control network. On-line definition is more natural 498 in a dynamic home environment, while off-line is more natural in the 499 office environment. Off-line has the added advantage of checking on 500 missing nodes. For subscription the subscribing nodes have to learn 501 the IP address(es) of the service(s) to which they want to subscribe. 502 In case of off-line the servers have to learn the IP address of the 503 multicast group. The latter can be learned from DHCP options, by 504 inserting the destination IP address inside the configuration file of 505 the battery-less node. 507 The CoAP protocol foresees the use of a non confirmable message 508 packet to send these unsolicited responses to the multicast group or 509 the single controller. Again the syntax of the commands are most 510 likely defined by legacy standards. Assuming the DALI standard, the 511 command PUT //blue-lights.bu036.floor1/DALI/OnOff=on leads to the 512 following packet lay-out: 514 - dest multicast IP address determined by: //blue- 515 lights.bu036.floor1 517 - T bits to 1: Non Confirmable message 519 - Code = 2, PUT method 521 - OC bits set to 1 (for one Mime option) 523 - Transaction ID set, for prevention of double messages 525 - Option type= 1, content type: /application/DALI 527 - DALI command: set OnOff attribute to on 529 7. Discovery 531 At a high level the the discovery strategy can be introduced with an 532 example to create a group "DALI/lights" in a given building domain. 534 - The building domains can be resolved according to a domain 535 specification which is consistent over a set of buildings 536 maintained by a building control provider 538 - A query over a specified domain returns the IP addresses of all 539 nodes in this domain with the reource DALI/lights 541 - The IP address of multicast group "DALI/lights" is defined 543 - The multicast group can be realized in two alternative ways: 545 - A list of IP addresses invoked by unicast. 547 - Each member allocates the IP multicast address, and receives 548 all messages sent to this IP address. 550 - Messages can be multicast to the group DALI/lights. 552 This implies a consistent naming scheme within each node. The above 553 group definition can be done on-line and off-line. 555 Service or resource discovery is often scoped according to the 556 building structure. For example, BACnet defines "Who-Is" and "Who- 557 Has" functions to locate nodes and resources, respectively, that 558 match specified criteria (filters) in a defined network scope. CoAP 559 defines a resource discovery capability, but it is limited to link- 560 local scope; examples may be found in [I-D.ietf-core-coap]. A 561 service discovery capability is required to extend discovery to other 562 subnets. 564 DNS-based Service Discovery [I-D.cheshire-dnsext-dns-sd] defines a 565 conventional way to configure DNS PTR, SRV, and TXT records to enable 566 enumeration of services such as CoAP nodes within subdomains. A 567 service is specified by a name of the form Instance.Type.Domain, 568 where the type for CoAP nodes is _coap._udp and the domain is a DNS 569 domain name that identifies a building zone as in the examples above. 570 For each CoAP end-point in the zone, a PTR record with the name 571 _coap._udp is defined and it points to an SRV record having the 572 Instance.Type.Domain name. 574 All CoAP nodes in a given subdomain may be enumerated by sending a 575 DNS query to the authoritative server for that zone for PTR records 576 named _coap._udp. A list of SRV records is returned. Each SRV 577 record contains the port and host name of a CoAP node. The IP 578 address of the node is obtained by resolving the host name. DNS-SD 579 also specifies an optional TXT record, having the same name as the 580 SRV record, which can contain "key=value" attributes. This can be 581 used to store information about the device, e.g. schema=DALI, 582 type=switch. 584 Another feature of DNS-SD is the ability to specify service subtypes 585 using PTR records. For example, a CoAP node that supports BACnet 586 commands might be represented with a PTR record having the name 587 _bacnet._sub._coap._udp. In this way, all BACnet nodes in a 588 subdomain might be enumerated more efficiently. This technique for 589 node enumeration can be used to emulate BACnet's "Who-Is" function. 591 With an enumerated list of nodes, a management workstation may then 592 perform unicast resource discovery as described in 593 [I-D.ietf-core-coap]. Alternately, the group multicast addressing 594 described earlier can be used to scope queries for specific resources 595 to different subdomains. This technique effectively emulates 596 BACnet's "Who-Has" function. 598 When for example a lamp wants to discover the controller, it is only 599 interested in the controllers located in the same office (area) as 600 itself. Consequently, the service discovery is related to the groups 601 defined according to the building structure. It is advisable to send 602 a discovery message to a given group. Also the packet does not need 603 the complete URI in the URI option. In conformance with RFC 5785 604 [RFC5785], a packet from a controller with the request to return the 605 device types of all DALI devices within the office bu036 can look 606 like: 608 - dest multicast IP address defined by: //bu036.floor1 610 - T bits to 0: Confirmable messages 612 - Code 0: GET method 614 - OC bits set to 2 (for Mime and URI option) 616 - Transaction ID set 618 - Option type= 9, uri-path: LEN=13, ".well-known/r" 620 - Option type= 1, content type: /application/DALI 622 - DALI command: "return device type" 624 The responses from the DALI nodes may look like: 626 - dest IP address of controller 628 - T bits to 2: Acknowledgement messages 630 - CODE = 0, OK 632 - OC bits set to 1 (for Mime option) 634 - Transaction ID identical 636 - Option type= 1, content type: /application/DALI 638 - DALI command: "type = Lamp" 640 The rest of the protocol is dictated by the legacy standard in use 641 but encapsulated within the CoAP discovery messages as shown above. 643 8. Conclusions 645 This I-D explains how building control is based on a hierarchical 646 structure of the building areas, and that the logical scope of 647 control and discovery messages is determined by the building 648 structure. It is shown that DNS subdomain delegation and naming can 649 be used to express this hierarchy in the authority portion of the 650 URI, down to the group or node level. The hierarchical naming scheme 651 need not be standardized, but rather can be designed to suit the 652 application. However, it is recommended that the scheme be employed 653 consistently throughout the delegated subdomain(s). The authority 654 portion of the URI is resolved by the client into the unicast or 655 multicast IP address of the targeted node(s). Taking advantage of 656 the CoAP design [I-D.ietf-core-coap], the uri-authority option need 657 not be transmitted in requests to origin servers and thus there is no 658 performance penalty for using descriptive naming schemes. 660 The targeted resource is specified by the path portion of the URI. 661 Again, this I-D does not mandate a universal naming standard for 662 resources but uses examples to show how resources could be named for 663 various legacy standards. An obvious requirement for resources that 664 are accessed by multicast is that they MUST all share the same path, 665 including short uri if used. It is shown that it is possible to 666 transport legacy commands (e.g. expressed in BACnet, LON, DALI, 667 ZigBee, etc.) inside a CoAP message body. This necessitates the 668 definition of additional IANA mime codes, and the mapping of legacy 669 specific discovery semantics to CoAP resource discovery messages or 670 DNS-SD lookups. 672 It is expected that many control messages are sent by battery-less 673 sensors with their own specific sending intervals to a group of 674 actuator nodes or controllers. Given the importance of groups and 675 associated multicast messages to support legacy standard functions, 676 the specification of a reliable multicast protocol with related 677 multicast scope is needed in CoAP. 679 9. Security considerations 681 TODO: The detailed CoAP security analysis needs to encompass 682 scenarios for building control applications. 684 Based on the programming model presented in this I-D, security 685 scenarios for building control need to be stated. Appropriate 686 methods to counteract the proposed threats may be based on the work 687 done elsewhere, for example in the ZigBee over IP context. 689 Multicast messages are, by their nature, transmitted via UDP. Any 690 privacy applied to such messages must be block oriented and based on 691 group keys shared by all targeted nodes. The CoRE security analysis 692 must be broadened to include multicast scenarios. 694 10. IANA considerations 696 This I-D proposes the following additions to the Media type 697 identifiers in conformance with the proposals done in 698 [I-D.ietf-core-coap]. 700 Internet media type Code 701 /application/BACnet xx 702 /application/DALI xx+1 703 /application/ZDO xx+2 704 /application/LON xx+3 705 /application/KNX xx+4 706 /application/oBIX+exi xx+5 708 TODO: Investigate CoAP specific well-known multicast address 709 assignment? 711 11. Acknowledgements 713 This I-D has benefited from conversations with and comments from 714 Andrew Tokmakoff, Emmanuel Frimout, Jamie Mc Cormack, Oscar Garcia, 715 Dee Denteneer, Joop Talstra, Zach Shelby, Jerald Martocci, and 716 Nicolas Riou. 718 12. References 720 12.1. Normative References 722 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 723 Requirement Levels", BCP 14, RFC 2119, March 1997. 725 [RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6 726 Multicast Addresses", RFC 3306, August 2002. 728 [RFC3307] Haberman, B., "Allocation Guidelines for IPv6 Multicast 729 Addresses", RFC 3307, August 2002. 731 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 732 "DNS Extensions to Support IP Version 6", RFC 3596, 733 October 2003. 735 [RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous 736 Point (RP) Address in an IPv6 Multicast Address", 737 RFC 3956, November 2004. 739 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 740 Resource Identifier (URI): Generic Syntax", STD 66, 741 RFC 3986, January 2005. 743 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 744 "Transmission of IPv6 Packets over IEEE 802.15.4 745 Networks", RFC 4944, September 2007. 747 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known 748 Uniform Resource Identifiers (URIs)", RFC 5785, 749 April 2010. 751 12.2. Informative References 753 [I-D.ietf-core-coap] 754 Shelby, Z., Frank, B., and D. Sturek, "Constrained 755 Application Protocol (CoAP)", draft-ietf-core-coap-01 756 (work in progress), July 2010. 758 [I-D.cheshire-dnsext-dns-sd] 759 Cheshire, S. and M. Krochmal, "DNS-Based Service 760 Discovery", draft-cheshire-dnsext-dns-sd-06 (work in 761 progress), March 2010. 763 [I-D.cheshire-dnsext-multicastdns] 764 Cheshire, S. and M. Krochmal, "Multicast DNS", 765 draft-cheshire-dnsext-multicastdns-11 (work in progress), 766 March 2010. 768 [I-D.martocci-6lowapp-building-applications] 769 Martocci, J., Schoofs, A., and P. Stok, "Commercial 770 Building Applications Requirements", 771 draft-martocci-6lowapp-building-applications-01 (work in 772 progress), July 2010. 774 [BACnet] Bender, J. and M. Newman, "BACnet/IP", 775 Web http://www.bacnet.org/Tutorial/BACnetIP/index.html. 777 [ZigBee] Tolle, G., "A UDP/IP Adaptation of the ZigBee Application 778 Protocol", draft-tolle-cap-00 (work in progress), 779 October 2008. 781 [LON] "LONTalk protocol specification, version 3", 1994. 783 [DALI] "DALI Manual", Web http://www.dali-ag.org/c/manual_gb.pdf, 784 2001. 786 [KNX] Kastner, W., Neugschwandtner, G., and M. Koegler, "AN OPEN 787 APPROACH TO EIB/KNX SOFTWARE DEVELOPMENT", Web http:// 788 www.auto.tuwien.ac.at/~gneugsch/ 789 fet05-openapproach-preprint.pdf, 2005. 791 [IEEE.802.15.4] 792 "Information technology - Telecommunications and 793 information exchange between systems - Local and 794 metropolitan area networks - Specific requirements - Part 795 15.4: Wireless Medium Access Control (MAC) and Physical 796 Layer (PHY) Specifications for Low Rate Wireless Personal 797 Area Networks (LR-WPANs)", IEEE Std 802.15.4-2006, 798 June 2006, 799 . 801 [oBIX] "oBIX working group", Web http://www.obix.org, 2003. 803 [Mullender] 804 Mullender, S., "Distributed Systems, Second Edition", 805 Section 5 , Addison-Wesley Publishing Company, Inc. , 806 ISBN 0-201-62427-3, 1995. 808 Authors' Addresses 810 Peter van der Stok 811 Philips Research 812 High Tech Campus 813 Eindhoven, 5656 AA 814 The Netherlands 816 Email: peter.van.der.stok@philips.com 817 URI: http://www.research.philips.com/ 819 Kerry Lynn 820 Consultant 822 Phone: +1 978 460 4253 823 Email: kerlyn@ieee.org