idnits 2.17.1 draft-vanderstok-core-bc-00.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 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 4, 2010) is 5016 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'BACnet' is defined on line 480, but no explicit reference was found in the text == Unused Reference: 'ZigBee' is defined on line 482, but no explicit reference was found in the text == Unused Reference: 'LON' is defined on line 484, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5785 (Obsoleted by RFC 8615) -- No information found for draft-ietf-core-coap-01pre5 - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'IDcoap' -- Possible downref: Non-RFC (?) normative reference: ref. 'BACnet' -- Possible downref: Non-RFC (?) normative reference: ref. 'ZigBee' -- Possible downref: Non-RFC (?) normative reference: ref. 'LON' Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 6 comments (--). 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 Expires: January 5, 2011 July 4, 2010 6 CoAP utilisation for building control 7 draft-vanderstok-core-bc-00 9 Abstract 11 This draft describes an example use of the RESTful CoAP protocol to 12 control equipment in buildings such as HVAC and lighting. A few 13 basic design assumptions are stated first. The uri structure is 14 exploited to define multicast scopes. RFC 3986 divides the uri in 15 (1) a scheme, (2) an authority part, used here to locate the building 16 under control, (3) a path, used here to locate the resource under 17 control, and (4) a query and fragment part, only the query part is 18 discussed in the context of service discovery. This I-D supports the 19 view that (1) building control will move in steps towards all-IP 20 control networks building on the legacy efforts provided by DALI, 21 LON, BACnet, ZigBee and other standards, and (2) the provision of a 22 reliable group communication protocol is essential. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on January 5, 2011. 41 Copyright Notice 43 Copyright (c) 2010 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. 53 Table of Contents 55 1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. URI structure . . . . . . . . . . . . . . . . . . . . . . . . 5 57 2.1. Authority part . . . . . . . . . . . . . . . . . . . . . . 5 58 2.2. Path part . . . . . . . . . . . . . . . . . . . . . . . . 5 59 3. Group Addressing . . . . . . . . . . . . . . . . . . . . . . . 7 60 4. Payload examples . . . . . . . . . . . . . . . . . . . . . . . 9 61 5. Service discovery . . . . . . . . . . . . . . . . . . . . . . 12 62 6. Security considerations . . . . . . . . . . . . . . . . . . . 14 63 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 15 64 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 65 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 66 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18 68 1. Motivation 70 The CoAP protocol [IDcoap] aims at providing a user application 71 protocol architecture which is targeted to a network of nodes with a 72 low resource provision such as memory, CPU capacity and energy. 73 Although in general, IT application manufacturers strive to provide 74 the highest possible functionality and quality for a given price, in 75 building control, manufacturers tend to compete by delivering a given 76 functionality and quality for the lowest price. A low resource 77 budget reduces the price of the nodes and a large effort is spent on 78 reducing the message length. This approach is reinforced by the 79 required low energy consumption by battery-less nodes. Reduction of 80 the packet size is obtained by using the header reduction of 6lowpan 81 and encouraging small payloads. Constraints on the message contents 82 are imposed by the long history of control in the building which has 83 led to the development of much legacy knowledge and applications. 84 Reuse of this knowledge will stimulate the introduction of all-IP 85 control within the buildings. This draft aims at an approach in 86 which the payload can be built on existing control standards, and 87 future new standards to emerge. The syntax of the control messages 88 is specified in the standard (e.g. BACNet, LON, DALI, KNX, etc.). 89 The description of the services is based on the same standard. 90 Consequently, the syntax of the service discovery messages, partially 91 expressed in the uri, is related to the chosen legacy control 92 standard. From the above the basic syntax assumptions can be 93 summarized as: 95 - Generate small payloads 97 - Compatible with legacy standards (e.g. LON, BACnet, DALI, ZigBee 98 Device Objects) 100 - Service discovery in agreement with legacy standards and uri 101 conventions. 103 Of prime importance in building control (at least lighting and HVAC) 104 is the concept of a group. Many control messages are multicast from 105 one device to a group of devices (e.g. from light switch to all 106 lights in a room). The scope of a multicast or a service discovery 107 message depends upon the group of nodes that is targeted. 108 Determining multicast scopes on the basis of hop count or the 109 existence of edge routers is not always sufficient in buildings where 110 the network architecture may be independent of the controlled areas 111 (e.g. rooms) in the building. Consequently, additional protocol 112 oriented assumptions are: 114 - A syntactic definition of the multicast scope applicable to all 115 multicasts in the building 117 - Pervasive existence of groups of resources 119 For clarity, this I-D limits itself to two types of applications: (1) 120 M2M control applications running within a building area without any 121 human intervention after start-up of a given network segment and (2) 122 maintenance oriented applications where data are collected from node 123 in several building areas to nodes inside or outside the building, 124 and humans may intervene to change control settings. 126 2. URI structure 128 This I-D looks at three aspects of the uri: scheme, authority, and 129 path. The scheme is assumed to be set to coap. The authority is 130 defined within the context of the standard internet naming, while the 131 path is valid in relation to a given DNS addressing unit. An example 132 from RFC 3986 [RFC3986] is: 133 foo://example.com:8042/over/there?name=ferret#nose, where "foo" is 134 the scheme, "example.com:8042" is the authority, "/over/there" is the 135 path, "name=ferret" is the query, and "nose" is the fragment. 136 Fragments are not supported in CoAP. 138 2.1. Authority part 140 A building can be unambiguously be addressed by it GPS coordinates or 141 more functionally its zip/post code. For example the Dutch Internet 142 provider, KPN, assigns to each subscriber a name based on its 143 postcode. Analogously, an example authority for a building can be 144 given by: //bldg.zipcode_localnr.Country/ or more concretely an 145 imaginary address in the Netherlands as: //bldg.5533BA_125a.nl/. The 146 bldg prefix can identify building control oriented IP network 147 traffic. Arriving at the node identified with 5533BA_125a.nl, the 148 receiving service can parse the rest of the uri and send the message 149 on to the specified resource (node). Other naming schemes are 150 possible and can be freely used. The authority structure looks more 151 than adequate to address the specified building and its control 152 nodes. No additional work is required to standardize its syntax. 154 2.2. Path part 156 Buildings have a structure dependent on their size and function. 157 This ranges from a single hall without any structure to a complex 158 building with floors, wings, offices and possibly a structure within 159 individual rooms. The naming of the building control equipment and 160 the actual control strategy are intimately linked to the building 161 structure. It is therefore convenient to name the equipment with 162 their location within the building. Consequently, the path part of 163 the uri identifying a piece of equipment is expressed in the building 164 structure. An example is: wing/floor/office/left_hand_corner. 166 Within the building, devices communicate with each other. Often a 167 device needs to communicate to all devices of a given type within a 168 given area of the building. For example a light switch addresses all 169 lights within a given corridor, or a heating unit accesses all 170 radiator actuators on a floor. Although intuitively easy to 171 understand the relative location is verbose and needs much contextual 172 knowledge within a device. For example a switch located at room 173 25b006 of floor one, expressed as: //bldg.5533BA_125a.nl/floor1/ 174 25b006/, can specify a command to light_1 within the same room with 175 //bldg.5533BA_125a.nl/floor1/25b006/light_1. This approach seems to 176 lead to rather verbose uri strings in the packet contrary to the 177 small packet assumption. Working out a control application later in 178 the text, shows that the uri disappears largely from the packet. 179 Question exists whether the syntax of a path needs to be standardized 180 for building control. Given the examples later in the text, this 181 does not seem to be necessary. 183 3. Group Addressing 185 As already suggested by the examples above the uri is intimately 186 associated with the scope of the messages. This provides a better 187 handle to define the multicast scope than the traditional TTL counter 188 preventing the multicast message to pass one or more routers. This 189 more sophisticated scoping mechanism is needed to separate the 190 network layout from the multicast scopes. This is also witnessed by 191 all the work done by the BACnet over IP standardization to define the 192 scope of the service discovery messages. 194 Given a network configuration and associated prefixes, the network 195 operator needs to define an appropriate set of multicast groups which 196 can be mapped to the building areas. Knowledge about the 197 hierarchical structure of the building areas may assist in defining a 198 network architecture which encourages an efficient multicast 199 implementation. Example multicast groups become: 201 /path targeted group 203 / "the whole building" 205 /floor1 "all nodes on floor1" 207 /wing3 "all nodes in wing 3" 209 /floor1/wing2 "all nodes belonging to wing 2 at floor 1" 211 /floor2/bu036 "all nodes belonging to office bu036 at floor 2" 213 Preferably these multicast groups are created automatically. Their 214 automatic creation is out of the scope of this I-D. This concept can 215 be refined by defining, like done for DALI, scenes within the context 216 of a floor or a single office. For example the setting of all blue 217 lights in office bu036 of floor 2 can be realized by sending a 218 message to the multicast group "/floor2/bu036/blue-lights". All 219 multicast groups are associated with one IP address, similar to the 220 individual nodes in a building area. Consequently, when the 221 application specifies the sending of an "on" message to all blue 222 lights in the office, the message is multicast to the associated IP 223 address and a large part of the uri can be removed from the message. 225 The large number of multicast addresses looks difficult to handle. 226 The suggestion is made that the nodes and not the services are part 227 of a multicast group. That means that all services on a given node 228 belong to the same multicast addresses to which the node belongs. 229 The number of multicast groups to which a given node belongs is then 230 possibly limited to 10. For example the node belonging to the "blue 231 lights" group in a given corridor will also belong to the groups: 232 "whole building", "given floor", "given wing", "given corridor", 233 "lights in given corridor", and "blue lights in given corridor". 235 The path can be used to define the groups and associated multicast 236 scopes. Naming is building dependent and does not need extra 237 standardization efforts. In the context of an administrated 238 professional building, groups can be defined off-line and stored in 239 configuration files referred to by the DHCP server. In the 240 information file participation to all groups is stored. In the 241 context of the home, groups are named on-line by the tenant, possibly 242 storing the group names and members in files for later personnel 243 reference. A reliable group communication (multicast) is essential 244 for an efficient building control application. 246 4. Payload examples 248 Every node with a network address is completely identified with uri 249 structure //authority/path. The next part of the uri is composed of 250 resource identification and function specification. The names of 251 device types and their associated attributes are typically a subject 252 for standardization. For example there is no standard for naming 253 building control devices unambigously in a uri. When a GET with an 254 uri like: /floor1/25b006/t-sensor1/temperature is sent, the 255 underlying assumption is that the resource with name t-sensor1 of a 256 given standard type (e.g. temperture sensor) exists and that this 257 standard type has the readable attribute: temperature. It is 258 unlikely that such a building control wide standard will appear 259 within a short time from now. Consequently, the first use of CoAP in 260 building control must rely on naming standards which exist today. It 261 is assumed that devices exchange messages with a content defined by 262 one of the already existing building control standards e.g. BACnet, 263 LON, DALI, ZigBee Device Objects (ZDO), KNX, and others. All these 264 standards know the concepts of type (class) and type (class) 265 instances. Within a given type a number of attributes exists which 266 can be modified or read with a more or less complex invocation 267 syntax. This draft proposes that the functional part of the uri 268 first describes the standard and then continues with a standard 269 dependent syntax, to be defined by the standardization committee 270 interested to conform to CoAP. For example a command to a heating 271 unit with a BACnet interface can be expressed with //authority/path/ 272 resource/BACnet/BACnet_defined_command or a command to a DALI light 273 can be expressed with //authority/path/resource/DALI/ 274 DALI_defined_command. For example the request: PUT /floor1/bu036/ 275 light1/DALI/30lumen , assuming that light1 is a DALI device, 276 translates to CoAP header [IDcoap]: 278 - dest IP address defined by: /floor1/bu036/light1 280 - T bits to 0: Confirmable message 282 - Code = 2: PUT method 284 - OC bits set to 1 (for one Mime option) 286 - Transaction ID set 288 - Option type= 5, content type: /application/DALI 290 - DALI command: set intensity to 30 lumen 292 The new option sub type shows that new application mime types need to 293 be defined to cover the building control standards: e.g. 295 /application/DALI, /application/BACnet, etc. 297 Examples of wireless, battery-less nodes are sensors used for 298 measuring presence, temperature, light intensity, or humidity. 299 Battery-less means that the nodes are switched off most of the time 300 and sporadically power up and send out their current measured value. 301 This value is either sent to a controller node or to a group of 302 actuator nodes. Examples are presence detection sent to lamps, or 303 humidity level to a fan. The destination nodes of the measurements 304 are probably powered by the mains or a derivative of the mains. It 305 seems unrealistic to have the controller or the actuator nodes send 306 request messages to the batteryless nodes, after which the sender has 307 to wait an interval determined by the operation of the sender. More 308 natural is that the batteryless node wakes up and sends its message 309 to controller or actuator nodes which are always ready to receive a 310 message. For example, without controller node, the presence detector 311 can send presence regularly to a group of lights. The group can be 312 defined on-line, by having the lights subscribe to the presence 313 service, or the group can be defined off-line by the manager of the 314 control network. On-line definition is more natural in a dynamic 315 home environment, while off-line is more natural in the office 316 environment. Off-line has the added advantage of checking on missing 317 nodes. For subscription the subscribing nodes have to learn the IP 318 address(es) of the service(s) to which they want to subscribe. In 319 case of off-line the servers have to learn the IP address of the 320 multicast group. The latter can be learnt from DHCP options, by 321 inserting the destination IP address inside the configuration file of 322 the battery-less node. 324 The CoAP protocol foresees the use of a non confirmable message 325 packet to send these unsolicited responses to the multicast group or 326 the single controller. Again the syntax of the commands are most 327 likely defined by legacy standards. Assuming the DALI standard, the 328 command PUT /floor2/bu036/blue-lights/DALI/on leads to the following 329 packet lay-out: 331 - dest multicast IP address defined by: /floor1/bu036/blue lights 333 - T bits to 1: Non Confirmable message 335 - Code = 2, PUT method 337 - OC bits set to 1 (for one Mime option) 339 - Transaction ID set, for prevention of double messages 340 - Option type= 5, content type: /application/DALI 342 - DALI command: switch ON 344 5. Service discovery 346 Service discovery is intimately linked to the building structure. 347 When for example a lamp wants to discover the controller, it is only 348 interested in the controllers sitting in the same office (area) as 349 itself. Consequently, the service discovery is related to the groups 350 defined according to the building structure. It is advisable to send 351 a discovery message to a given group. Also the packet does not need 352 the complete uri in the uri option. In conformace with RFC 5785 353 [RFC5785], a packet from a controller with the request to return the 354 device types of all DALI devices within the office bu036 can look 355 like: 357 - dest multicast IP address defined by: /floor1/bu036/ 359 - T bits to 0: Confirmable messages 361 - Code 0: GET method 363 - OC bits set to 2 (for Mime and URI option) 365 - Transaction ID set 367 - Option type= 1, LEN=21, "/well-known/resources" 369 - Option type= 5, content type: /application/DALI 371 - DALI command: "return device type" 373 The responses from the DALI nodes may look like: 375 - dest IP address of controller 377 - T bits to 2: Acknowledgement messages 379 - CODE = 0, OK 381 - OC bits set to 1 (for Mime option) 383 - Transaction ID identical 385 - Option type= 5, content type: /application/DALI 387 - DALI command: "type = Lamp" 389 The rest of the protocol is dictated by the legacy standard in use 390 but encapsulated within the CoAP discovery messages as shown above. 392 To promote a step-wise introduction of CoAP, the suggestion is to 393 separate the service discovery protocol messages from the service 394 description syntax. The same CoAP protocol messages can be exchanged 395 between nodes, but the description syntax (e.g. xmi, ZDO, or BACnet) 396 is left free. Assuming a building control standard BS. The goal is 397 to exchange the BS messages sent by the service discovery BS client 398 with CoAP messages as described above. At the CoAP server, the BS 399 message is passed on to the BS server. The result from the BS server 400 is packed in a CoAP packet as described above and returned to the BS 401 client. 403 The second step of CoAP introduction uniformizes the sevice discovery 404 clients for interested BS's. Additional standardization effort is 405 needed to provide all functionality supported by all existing 406 standards. For example not all service discovery protocols support 407 the option to return answers from a given type of resource only. 408 Such a general extension can be expressed with the transported uri 409 /well-known/resources/?resource=X. A benefit of such standardisation 410 of discovery queries over all legacy standards is that the legacy 411 standards may enjoy additional facilities like resource directories, 412 which enhance the scalability of the service discovery protocol. The 413 I-D explains how buidling control is based on a hierachical structure 414 of the building areas, and that control message scope and discovery 415 message scope are defined by this building structure. It is shown 416 that the uri can express this structure but does not need 417 standardization. Also larger parts of the complete uri does not need 418 to be transported in the message but is expressed as a Multicast or 419 Unicast IP address in the IP header. It is shown that it is possible 420 to transport legacy commands (.e.g. expressed in BACnet, LON, DALI, 421 ZigBee, etc.) inside CoAP message structure. This necessitates the 422 definition of additional IANA mime codes, and the mapping of legacy 423 specific service discovery semantics to CoAP service discovery 424 messages. 426 It is expected that many control messages are sent by battery-less 427 sensors with their own specific sending intervals to a group of 428 actuator nodes or controllers. Given the importance of groups and 429 associated multicast messages, the specification of a reliable 430 multicast protocol with related multicast scope is needed. 432 6. Security considerations 434 Based on the programming model presented in this I-D, security 435 scenarios for building control need to be stated. Appropriate 436 methods to counteract the proposed threats can be based on the work 437 done elsewhere, for example in the ZigBee over IP context. 439 7. IANA considerations 441 This I-D proposes the following additions to the Media type 442 identifiers in conformance with the proposals done in [IDcoap]. 444 Internet media type code 446 /application/BACnet xx 448 /application/DALI xx+1 450 /application/ZDO xx+2 452 /application/LON xx+3 454 /application/KNX xx+4 456 /application/exi/building xx+5 458 /application/exi/metering xx+6 460 8. Acknowledgements 462 This I-D has benefited from conversations with and comments from 463 Kerry Lynn, Andrew Tokmakoff, Emmanuel Frimout, Jamie Mc Cormack, 464 Oscar Garcia, Dee Denteneer, Joop Talstra, Gerald Martocci, and . 466 9. References 468 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 469 Resource Identifiers (URI): Generic Syntax", RFC 3986, 470 January 2005. 472 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known 473 Uniform Resource Identifiers (URIs)", RFC 5785, 474 April 2010. 476 [IDcoap] Shelby, Z., Frank, B., and D. Sturek, "Constrained 477 Application Protocol (CoAP)", draft-ietf-core-coap-01pre5 478 (work in progress), June 2010. 480 [BACnet] xx, Z., "BACnet over IP", June 1998. 482 [ZigBee] xx, Z., "ZigBee device objects over IP", June 2009. 484 [LON] xx, Z., "LON objects", June 1990. 486 Author's Address 488 Peter van der Stok 489 Philips Research 490 High Tech Campus 491 Eindhoven, 5656 AA 492 Netherlands 494 Email: peter.van.der.stok@philips.com 495 URI: http://www.research.philips.com/