idnits 2.17.1 draft-vanderstok-core-bc-05.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 22 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 501 has weird spacing: '...olution res...' -- The document date (October 30, 2011) is 4534 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: '0x5577' is mentioned on line 1141, but not defined == Unused Reference: 'RFC1034' is defined on line 1290, but no explicit reference was found in the text == Unused Reference: 'RFC1123' is defined on line 1293, but no explicit reference was found in the text == Unused Reference: 'RFC3629' is defined on line 1317, but no explicit reference was found in the text == Unused Reference: 'RFC5198' is defined on line 1332, but no explicit reference was found in the text == Unused Reference: 'RFC5785' is defined on line 1335, but no explicit reference was found in the text == Unused Reference: 'I-D.cheshire-dnsext-multicastdns' is defined on line 1351, but no explicit reference was found in the text == Unused Reference: 'ZigBee-IP' is defined on line 1435, 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-10 == Outdated reference: A later version (-15) exists of draft-cheshire-dnsext-multicastdns-14 == Outdated reference: A later version (-18) exists of draft-ietf-core-coap-07 == Outdated reference: A later version (-14) exists of draft-ietf-core-link-format-07 == Outdated reference: A later version (-05) exists of draft-shelby-core-resource-directory-01 == Outdated reference: A later version (-02) exists of draft-lynn-core-discovery-mapping-01 Summary: 2 errors (**), 0 flaws (~~), 17 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: May 2, 2012 Consultant 6 October 30, 2011 8 CoAP Utilization for Building Control 9 draft-vanderstok-core-bc-05 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. 19 This proposal supports the view that 1) service discovery is 20 complementary to resource discovery and facilitates control network 21 scaling, and 2) building control is likely to move in steps toward 22 all-IP control networks based on the legacy efforts provided by DALI, 23 LON, BACnet, ZigBee, and other standards. 25 The authority portion of the URI is used to identify a device (group) 26 and the resulting DNS name is bound to a unicast (multicast) address. 27 Group addressing has consequence for the naming convention of the 28 resources of a device. Naming of URI is building or organization 29 dependent, must be flexible, and SHOULD conform to some local 30 convention. Naming of resources MUST be standardised preferrable by 31 a building control related organisation. 33 It is shown that DNS-based service discovery can be used to locate 34 URIs on the scale necessary in large commercial BAC deployments. The 35 relation of DNS-SD and a Resource Directory is discussed. Finally, a 36 method is proposed for mapping URIs onto legacy BAC resources, e.g., 37 to discover application-layer gateways, proxies, and their dependent 38 services. 40 Status of this Memo 42 This Internet-Draft is submitted in full conformance with the 43 provisions of BCP 78 and BCP 79. 45 Internet-Drafts are working documents of the Internet Engineering 46 Task Force (IETF). Note that other groups may also distribute 47 working documents as Internet-Drafts. The list of current Internet- 48 Drafts is at http://datatracker.ietf.org/drafts/current/. 50 Internet-Drafts are draft documents valid for a maximum of six months 51 and may be updated, replaced, or obsoleted by other documents at any 52 time. It is inappropriate to use Internet-Drafts as reference 53 material or to cite them other than as "work in progress." 55 This Internet-Draft will expire on May 2, 2012. 57 Copyright Notice 59 Copyright (c) 2011 IETF Trust and the persons identified as the 60 document authors. All rights reserved. 62 This document is subject to BCP 78 and the IETF Trust's Legal 63 Provisions Relating to IETF Documents 64 (http://trustee.ietf.org/license-info) in effect on the date of 65 publication of this document. Please review these documents 66 carefully, as they describe your rights and restrictions with respect 67 to this document. Code Components extracted from this document must 68 include Simplified BSD License text as described in Section 4.e of 69 the Trust Legal Provisions and are provided without warranty as 70 described in the Simplified BSD License. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 75 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 76 1.2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 4 77 2. URI structure . . . . . . . . . . . . . . . . . . . . . . . . 6 78 2.1. Scheme part . . . . . . . . . . . . . . . . . . . . . . . 7 79 2.2. Authority part . . . . . . . . . . . . . . . . . . . . . . 7 80 2.3. Path part . . . . . . . . . . . . . . . . . . . . . . . . 8 81 3. Group Naming and Addressing . . . . . . . . . . . . . . . . . 10 82 4. Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . 12 83 4.1. Service discovery goals . . . . . . . . . . . . . . . . . 12 84 4.2. DNS-Based Service Discovery . . . . . . . . . . . . . . . 13 85 4.3. Browsing for Services . . . . . . . . . . . . . . . . . . 14 86 4.4. Resource vs Service Discovery . . . . . . . . . . . . . . 14 87 5. DNS record structure . . . . . . . . . . . . . . . . . . . . . 15 88 5.1. DNS group example . . . . . . . . . . . . . . . . . . . . 18 89 5.2. Operational use of DNS-SD . . . . . . . . . . . . . . . . 19 90 5.3. Commissioning CoAP devices . . . . . . . . . . . . . . . . 20 91 5.3.1. DNS-SD server present . . . . . . . . . . . . . . . . 21 92 5.3.2. DNS-SD server not present . . . . . . . . . . . . . . 21 93 5.4. Proxy discovery . . . . . . . . . . . . . . . . . . . . . 22 94 6. Legacy data Representations in CoAP . . . . . . . . . . . . . 23 95 6.1. Network architectures . . . . . . . . . . . . . . . . . . 24 96 6.2. Discovery of legacy gateways . . . . . . . . . . . . . . . 26 97 7. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 26 98 8. Security considerations . . . . . . . . . . . . . . . . . . . 27 99 9. IANA considerations . . . . . . . . . . . . . . . . . . . . . 28 100 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28 101 11. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 28 102 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 103 12.1. Normative References . . . . . . . . . . . . . . . . . . . 29 104 12.2. Informative References . . . . . . . . . . . . . . . . . . 30 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32 107 1. Introduction 109 1.1. Terminology 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in "Key words for use in 114 RFCs to Indicate Requirement Levels" [RFC2119]. 116 In addition, the following conventions are used in this document: 118 A CoAP end-point, or server, is identified by a unique {IP address, 119 port} tuple and characterised by a protocol. A server is completely 120 specified by the authority part of a URI. 122 A device is the physical object that is connected to the network. A 123 device may host one or more CoAP servers. 125 A service (in the service discovery sense) is a related set of 126 resources on a CoAP server. A URI completely specifies the syntax of 127 a service interface. Metadata describe the semantics of the service 128 interface. The semantics may include the relation between service 129 and the hardware connected to the device. A CoAP server may expose 130 one or more services. 132 In examples below involving URIs, the authority is preceded by double 133 slashes "//" and path is preceded by a single slash "/". The 134 examples may make use of full or partial host names and the 135 difference should be clear from the context. 137 1.2. Motivation 139 The CoAP protocol [I-D.ietf-core-coap] aims at providing a user 140 application protocol architecture for a network of devices with a low 141 resource provision such as memory, CPU capacity, and energy. In 142 general, IT application manufacturers strive to provide the highest 143 possible functionality and quality for a given price. In contrast, 144 the building automation controls market is highly price sensitive and 145 manufacturers tend to compete by delivering a given functionality and 146 quality for the lowest price. In the first market a decreasing 147 memory price leads to more software functionality, while in the 148 second market it leads to a lower Bill of Material (BOM). 150 The vast majority of devices in a typical building control 151 application is resource constrained, making the standardization of a 152 lightweight application protocol like CoAP a necessary requirement 153 for IP to penetrate the device market. The low energy consumption 154 requirement of battery-less devices reinforces this approach. Low 155 resource budget implies low throughput and small packet size as for 156 [IEEE.802.15.4]. Reduction of the packet size is obtained by using 157 the header reduction of 6LoWPAN [RFC4944] and encouraging small 158 payloads. 160 Several legacy building control standards (e.g. [BACnet], [DALI], 161 [KNX], [LON], [ZigBee], etc.) have been developed based on years of 162 accumulated knowledge and industry cooperation. These standards 163 generally specify a data model, functional interfaces, packet 164 formats, and sometimes a physical medium for data objects and 165 function invocation. Many of these industry standards also specify 166 proprietary transport protocols, necessitating expensive stateful 167 gateways for these standards to interoperate. Many more recent 168 building control network include IP-based standards for transport (at 169 least to interconnect islands of functionality) and other functions 170 such as naming and discovery. CoAP will be successful in the 171 building control market to the extent that it can represent a given 172 standard's data objects and provide functions, e.g. resource 173 discovery, that these standards depend on. 175 From the above the wanted basic syntax properties can be summarized 176 as: 178 - Generate small payloads. 179 - Compatible with legacy standards (e.g. LON, BACnet, DALI, ZigBee 180 Device Objects). 181 - Service/resource discovery in agreement with legacy standards and 182 naming conventions. 184 This submission defines an approach in which the payload contains 185 messages with a syntax defined by legacy control standards. 186 Accordingly, the syntax of the service/resource discovery messages 187 encapsulates legacy control standard. The intention is a progressive 188 approach to all-IP in building control. In a first stage standard 189 IETF based protocols (e.g. CoAP, DNS-SD) are used for transport of 190 control messages and discovery messages expressed in a legacy syntax. 191 This approach enables the reuse of controllers based on the semantics 192 of the chosen control standard. In a later stage a complete redesign 193 of the controllers can be envisaged guided by the accumulated 194 experience with all-IP control. 196 Two concepts, hierarchy and group, are of prime importance in 197 building control, particularly in lighting and HVAC. Many control 198 messages or events are multicast from one device to a group of 199 devices (e.g. from a light switch to all lights in an area). The 200 scope of a multicast command or discovery message determines the 201 group of devices that is targeted. A group scope may be defined as 202 link-local, as a tree maintained by an IP-multicast protocol, or an 203 overlay that corresponds to the logical structure of a building or 204 campus and is independent of the underlying network structure. 205 Techniques for group communication are discussed in 206 [I-D.rahman-core-groupcomm]. 208 As described in "Commercial Building Applications Requirements" 209 [I-D.martocci-6lowapp-building-applications] it is typical practice 210 to aggregate building control at the room, area, and supervisory 211 levels. Furthermore, networks for different subsystems (lights, 212 HVAC, etc.) or based on different legacy standards have historically 213 been isolated from each other in so-called "silos". RESTful web 214 services [Fielding] represent one possible way to expose 215 functionality and normalize data representations between silos in 216 order to facilitate higher order applications such as campus-wide 217 energy management. 219 Consequently, additional group properties are: 221 - Devices may be part of one or more groups. 222 - Resources addressed by a group must be uniformly and consistently 223 named across all targeted devices. 225 For clarity, this I-D limits itself to two types of applications: (1) 226 M2M control applications running within a building area without any 227 human intervention after commissioning of a given network segment and 228 (2) maintenance oriented applications where data are collected from 229 devices in several building areas by devices inside or outside the 230 building, and humans may intervene to change control settings. This 231 I-D compares commercial building solutions with solutions for the 232 home. 234 2. URI structure 236 This I-D considers three elements of the URI: scheme, authority, and 237 path, as defined in "Uniform Resource Identifier (URI): Generic 238 Syntax" [RFC3986]. The authority is defined within the context of 239 standard DNS host naming, while the path is valid in relation to a 240 fully qualified domain name (FQDN) plus optional port (and protocol 241 is implicit, based on scheme). An example based on [RFC3986] is: 242 foo://host.example.com:8042/over/there?name=ferret#nose, where "foo" 243 is the scheme, "host.example.com:8042" is the authority, "/over/ 244 there" is the path, "name=ferret" is the query, and "nose" is the 245 fragment. Fragments are not supported in CoAP. 247 2.1. Scheme part 249 The CoAP URI scheme syntax is specified in section 6 of 250 [I-D.ietf-core-coap] and is compatible with the "http" scheme 251 specification [RFC2616]. The scheme is implicit from the perspective 252 of the service, but it indicates the protocol used to access the 253 service to potential clients. 255 2.2. Authority part 257 The authority part is either a literal IP address or a DNS name 258 comprised of a local part, specifying an individual device or group 259 of devices, and a global part specifying a (sub)domain that may 260 reflect the logical hierarchical structure of the building control 261 network. The result is said to be a fully qualified domain name 262 (FQDN) which is globally unique down to the group or device level. 263 An optional port number may be included in the authority following a 264 single colon ":" if the service port is other than the default CoAP 265 value. The authority resolves to a {IP-address, port} tuple. The 266 IP-address may be either unicast or multicast. The authority 267 therefore identifies an individual server or a named group of 268 servers. 270 The CoAP spec [I-D.ietf-core-coap] states "When a CoAP server is 271 hosted by a 6LoWPAN device, it SHOULD also support a port in the 272 61616-61631 compressed UDP port space defined in [RFC4944]." As 273 shown below, DNS-SD [I-D.cheshire-dnsext-dns-sd] is a viable 274 technique for discovering dynamic host and port assignments for a 275 given service. However, the use of dynamic ports in URIs is likely 276 to lead to brittle (non-durable) identifiers as there is no assurance 277 that a CoAP server will consistently acquire the same dynamic port 278 and different {IP-address, port} tuples conventionally represent 279 different servers. 281 A building can be unambiguously addressed by it GPS coordinates or 282 more functionally by its zip or postal code. For example the Dutch 283 Internet provider, KPN, assigns to each subscriber a host name based 284 on its postcode. Analogously, an example authority for a building 285 may be given by: //bldg.zipcode-localnr.Country/ or more concretely 286 an imaginary address in the Netherlands as: //bldg.5533BA-125a.nl/. 287 The "bldg" prefix can specify the target device within the building. 288 Arriving at the device identified by //bldg.5533BA-125a.nl, the 289 receiving service can parse the path portion of the URI and perform 290 the requested actions on the specified resource. 292 Buildings have a logical internal structure dependent on their size 293 and function. This ranges from a single hall without any structure 294 to a complex building with wings, floors, offices and possibly a 295 structure within individual rooms. The naming of the building 296 control equipment and the actual control strategy are intimately 297 linked to the building structure. It is therefore natural to name 298 the equipment based on their location within the building. 299 Consequently, the local part of the URI identifying a piece of 300 equipment is expressed in the building structure. An example is: 301 //light-27.floor-1.west-wing... 303 This proposal assumes a minimal level of cooperation between the IT 304 and building management infrastructure, namely the ability of the 305 former to delegate DNS subdomains to the latter. This allows the 306 building controls installer to implement an appropriate naming scheme 307 with the required granularity. For institutional real estate such as 308 a college or corporate campus, the authority might be based on the 309 organization's domain, e.g. //device-or- 310 group.floor.wing.bldg.campus.example.com/. In cases where subdomain 311 delegation is not an option, structure can still be represented in a 312 "flat" namespace, subject to the 63 octet limit for a DNS label: 313 //group1-floor2-west-bldg3-campus.example.com. 315 Most communication is device to device (M2M) within the building. 316 Often a device needs to communicate to all devices of a given type 317 within a given area of the building. For example a thermostat may 318 access all radiator actuators in a zone. A light switch located at 319 room 25b006 of floor one, expressed as: 320 //switch0.25b006.floor1.5533BA-125a.nl/, might specify a command to 321 light1 within the same room with //light1.25b006.floor1.5533BA- 322 125a.nl/. This approach can lead to rather verbose URI strings in 323 the packet, contrary to the small packet assumption. The question 324 arises as to whether the syntax of the authority part needs to be 325 standardized for building control. Given the naming flexibility 326 provided by DNS, authority names for building control are more the 327 concern of the building owner or the installer than a standardization 328 concern. 330 2.3. Path part 332 The path identifies the addressable attributes of the service at the 333 highest possible granularity. A set of paths defines the syntax of 334 the service invocation and constitutes the interface description of 335 the service. Every network service attribute is completely 336 identified by a URI scheme://authority/path. In analogy, the path 337 part of the URI specifies the resource of a given server. The naming 338 of the services and their associated attributes are typically 339 subjects for standardization. There is no widely accepted standard 340 for uniformly naming building control services in a URI. A vigorous 341 effort is undertaken by the oBIX working group of OASIS [oBIX], but 342 its current impact is limited. There is also an open source point 343 naming effort underway called Project Haystack [HAYSTACK]. 345 The path is constructed like a file system path name. It consists of 346 a sequence of one or more name fields, with each field preceded with 347 a slash, like /func1/subf2/final. The set of paths is structured as 348 a tree. The last name in a name field sequence is called a leave of 349 the tree, and the authority is the root of the path tree of a given 350 host. The semantics of a given sub-tree in the path tree is 351 specified by the Interface Description (if=) attribute described in 352 [I-D.ietf-core-link-format]. As for file systems some tree naming 353 with associated semantics can be standardized such as the de facto PC 354 standard directory "documents and settings" with the sub-directories 355 "My documents", "usradmin", etc. When a given body, e.g. XXX, has 356 defined a name structure and semantics for the path tree, we say that 357 "if = XXX" when the path tree conforms to the name structure defined 358 by XXX. 360 When a GET method with an URI like 361 "//t-sensor1.25b006.floor1.example.com/temperature" is sent, it 362 represents an a priori understanding that the server with name 363 t-sensor1 exists, provides a service of a given standard type (with 364 associated semantics) (e.g. ZigBee temperature sensor), and that 365 this standard type has the readable attribute: temperature. When 366 commands are sent to a group of servers it MUST be the case that the 367 targeted resource has the same path on all targeted servers. 368 Therefore, it is necessary to establish at least a local uniform path 369 naming convention to achieve this. One approach is to include the 370 name of the standard, e.g. BACnet, as the first element in the path 371 and then employ the standard's chosen data scheme (in the case of 372 BACnet, /bacnet/device/object/property). 374 The organization responsible for defining a given industry standard 375 XXX (e.g. BACnet, ZigBee, etc.) can register the /.well-known/XXX 376 prefix and specify the allowable path-names for a server of a given 377 type. The same body also defines the "if=XXX" attribute. This 378 allows the standards development organization responsibile for XXX to 379 define the name space and resources associated with the prefix 380 together with the associated semantics. The registered /.well-known/ 381 XXX URI effectively defines a standard object model, or schema, for 382 services of the XXX application protocol. Manufacturers may 383 optionally define proprietary resources that can be discovered 384 dynamically using methods described below. 386 Although the authority part names need not always be transported, the 387 path names MUST be transported in the CoAP packets. Therefore, path 388 names SHOULD be as short as possible, even at the detriment of the 389 clarity of the meaning of the path name. 391 3. Group Naming and Addressing 393 Within building control it is necessary to send the same command to a 394 set of servers. Grouping allows to invoke the set of services with 395 one application command to be executable within a specified time 396 interval. Given a network configuration, the network operator needs 397 to define an appropriate set of groups which can be mapped to the 398 building areas. Knowledge about the hierarchical structure of the 399 building areas may assist in defining a network architecture which 400 encourages an efficient group communication implementation. IP- 401 multicasting over the group is a possible approach for building 402 control, although proxy-based methods may prove to be more 403 appropriate in some deployments [I-D.rahman-core-groupcomm]. 405 Example device groups become: 407 URI authority Targeted group 408 //all.bldg6... "all devices in building 6" 409 //all.west.bldg6... "all devices in west wing, building 410 6" 411 //all.floor1.west.bldg6... "all devices on floor 1, west wing, 412 ..." 413 //all.bu036.floor1.west.bldg6... "all devices in office bu036, ..." 415 The granularity of this example is for illustration rather than a 416 recommendation. Experience will dictate the appropriate hierarchy 417 for a given structure as well as the appropriate number of groups per 418 subdomain. Note that in this example, the group name "all" is used 419 to identify the group of all devices in each subdomain. In practice, 420 "all" could name an address record in each of the DNS zones shown 421 above and would bind to a different multicast address [RFC3596] in 422 each zone. Highly granular multicast scopes are only practical using 423 IPv6. The multicast address allocation strategy is beyond the scope 424 of this I-D, but various alternatives have been proposed 425 [RFC3306][RFC3307][RFC3956]. 427 To illustrate the concept of multiple group names within a building, 428 consider the definition, as done with [DALI], of scenes within the 429 context of a floor or a single office. For example, the setting of 430 all blue lights in office bu036 of floor 1 can be realized by 431 multicasting a message to the group "//blue-lights.bu036.floor1". 432 Each group is associated with a multicast IP address. Consequently, 433 when the application specifies the sending of an "on" message to all 434 blue lights in the office, the message is multicast to the associated 435 IP address. 437 The binding of a group FQDN to a multicast address (i.e., creation of 438 the AAAA record in the DNS zone server) happens during the 439 commissioning process. Resolution of the group name to a multicast 440 address happens at restart of a device. A multicast address and 441 associated group name in this context are assumed to be long-lived. 442 It can happen that during operation the membership of the group 443 changes (less or more lights) but its address is not altered and 444 neither is its name. Group membership may be managed by a protocol 445 such as Multicast Listener Discovery [RFC5790]. 447 Similarly, a group can identify a set of resources of one server. 448 For examples a device contains four I/O channels. The device hosts 449 one server with four resources to access each of the four individual 450 channels separately. Commonly, it is also required to access all 451 four channels as one group. An additional path identifies the group 452 of services. An example set of services and service-group is: 454 URI path Targeted group 455 /IOchannel/1... "channel 1 of the IO channel device " 456 /IOchannel/2... "channel 2 of the IO channel device " 457 /IOchannel/3... "channel 3 of the IO channel device " 458 /IOchannel/4... "channel 4 of the IO channel device " 459 /IOchannel/... "channel 1 to 4 of the IO channel device " 461 A group defines a set of servers possibly containing a set of 462 resources. Grouping of the resources is provided by the device 463 manufacturer. Grouping of the servers is supported by DNS and 464 multicast protocols. The multicast address(es) identify the servers 465 belonging to the group. A given server might belong to a number of 466 groups. For example the server belonging to the "blue-lights" group 467 in a given corridor might also belong to the groups: "whole 468 building", "given wing", "given floor", "given corridor", and "lights 469 in given corridor". From the perspective of a server, the main 470 consequence of joining a group is it should accept packets for an 471 additional IP address. The granularity of the domain names may have 472 an impact on the complexity of the DNS infrastructure but not 473 necessarily on the low-resource destinations or sources. Assuming 474 that resolution of addresses only happens at device start-up, the 475 complexity of the DNS server need not affect the responsiveness of 476 the devices. 478 In summary, the authority portion of the URI resolves to an IP- 479 address and port number, and identifies a server or group of servers. 480 Authority naming is building or organization dependent, must be 481 flexible, and does not require standardization efforts but SHOULD 482 conform to some uniform convention. Path naming SHOULD conform to 483 the naming convention of a standardization body. 485 4. Discovery 487 4.1. Service discovery goals 489 Service discovery in building control should rely on a minimal need 490 for intervention by humans (or complete absence of humans) during 491 system setup, bootstrapping, restart, configuration and daily 492 operation. The goals for service discovery area: 494 Goal Goal description 495 Return_instance Return all instances of a given service type 496 within a given domain 497 Group_instance Group a set of instances within a group 498 associated with a domain 499 Instance_resolution Resolve the instance name to usable invocation 500 information (e.g. IP address and port) 501 Group_resolution resolve the group name to usable invocation 502 information (e.g. IP address and port) 504 These goals are necessary to support the operation of commercial 505 building control. Returning the instances results in a list of 506 names. For building control these names can be any sequence of 507 characters as long as for each service instance these names are 508 unique within the domain. In [I-D.cheshire-dnsext-dns-sd] the office 509 equipment in the IT domain is recommended to use understandable and 510 human-readable names. The Home domain may have a need for human 511 understandable names. This is not the case for the commercial 512 building automation domain. However, uniqueness of the name is 513 necessary for the application that needs to address the service in a 514 consistent manner. Given the large number of devices in a building 515 (several hundreds to thousands) scaling is an important aspect of the 516 service discovery. A set of central DNS servers will provide the 517 scalability. The expectation is that names need to be managed 518 consistently by a central authority which can be supported by the DNS 519 server. Tools will assist the installer and operator of the network 520 to do the installation, configuration and maintenance of the network 521 structure. Small devices will use the DNS server to learn the 522 communication partners providing a given service within their domain 523 and to resolve the IP addresses of the communication partners. 525 Within the home it is more important that the names convey the 526 purpose of the service to the user reading the names and selecting 527 his favored service instance. Non-unique names, although confusing, 528 can probably be handled by the user of these names. Scalability is 529 less of an issue because a smaller number of devices is implicated. 530 The network in the home is probably more dynamic than its commercial 531 counter-part, with many movements of devices and arrival or removal 532 of devices. 534 Section 5 presents some examples of DNS structures to show how the 535 choice of names influences the granularity of the discovery. In 536 sections 5.1 and 5.3 a grouping example and a commissioning example, 537 filling the DNS, are presented. 539 4.2. DNS-Based Service Discovery 541 DNS-Based Service Discovery (DNS-SD) defines a conventional way to 542 configure DNS PTR, SRV, and TXT records to facilitate discovery of 543 services within a subdomain, re-using the existing DNS 544 infrastructure. This section gives a cursory overview of DNS-SD; see 545 [I-D.cheshire-dnsext-dns-sd] for a complete description. 547 A DNS-SD service instance name is of the form 548 ... 550 The Location part of the service name is identical to the DNS 551 subdomain part of the authority in URIs that identify the resources 552 of this server or group and may identify a building zone as in the 553 examples above. 555 The ServiceType SHOULD have the form [_subtype._sub.]_type._proto 556 (e.g. _temp._sub._bc._udp). The _proto identifier provides a 557 transport protocol hint as required by the SRV record definition 558 [RFC2782] and, in the case of CoAP, it is always "_udp". The _type 559 identifier is determined by standards development organization (SDO) 560 and MUST be registered with dns-sd.org [dns-sd] (e.g. _bc for 561 building control). The SDO is then free to specifiy one or more 562 _subtype identifiers, which must be unique for a given _type (e.g. 563 _temp). The _subtype and _type labels are separated by the literal 564 "._sub" label.The maximum length of the type and subtype fields is 14 565 octets, but shorter names are encouraged to reduce packet sizes. 567 A PTR record with the label "_type._proto" is defined for each server 568 in a selected domain, and this record's value is set to the service 569 instance name (which in turn identifies the SRV and TXT records for 570 the CoAP server). 572 The Instance part of the service name may be changed during the 573 commissioning process. It must be unique for a given ServiceType 574 within the subdomain. The complete service name uniquely identifies 575 an SRV and a TXT record in the DNS zone. The granularity of a 576 service name MAY be at the group or server level, or it could 577 represent a particular resource within a CoAP server. The SRV record 578 contains the host (AAAA record) name and port of the service. The 579 path part of the URI MUST be placed in the TXT record (path=) when 580 multiple resources belong to the same service. 582 4.3. Browsing for Services 584 Devices in a given Location with given ServiceType, _type._proto, may 585 be enumerated by sending a DNS query for PTR records named 586 _type._proto to the authoritative server for that zone associated 587 with the Location. A list of instance names for SRV records matching 588 that . is returned. Each SRV record contains 589 the host name and port of a CoAP server. The IP address of the 590 device is obtained by resolving the host name. DNS-SD also specifies 591 an optional TXT record, having the same name as the SRV record, which 592 can contain "key=value" attributes. Apart from defining standardized 593 resources identified by if=XXX, the XXX organization may also define 594 the standard "key=value" pairs present in the TXT record, e.g. 595 type=switch. By convention, the first pair is txtver= so 596 that different versions of the XXX schema may interoperate. For 597 example: A query is sent to DNS-SD to return all DALI lamps within 598 the domain office5/mybuilding and with ServiceType: 599 _lamp._sub._dali._udp. DNS-SD returns the list of all SRV records 600 and AAAA records of the devices within the domain providing the 601 wanted service. 603 4.4. Resource vs Service Discovery 605 Service discovery is concerned with finding the IP address, port, 606 protocol, and possibly path of a named service. Resource discovery 607 is a fine-grained enumeration of resources (path-names) of a server. 608 [I-D.ietf-core-link-format] specifies a resource discovery pattern, 609 such that sending a confirmable GET message for the /.well-known/core 610 resource returns a set of links available from the server. These 611 links describe resources hosted on that server. 613 CoAP link format can be used to enumerate attributes and populate the 614 DNS-SD database in a semi-automated fashion. CoAP resource 615 descriptions can be imported into DNS-SD for exposure to service 616 discovery as described in [I-D.lynn-core-discovery-mapping]. The 617 values stored in the DNS-SD directory are extracted from the 618 information stored in the resource directory associated with a set of 619 CoAP hosts [I-D.shelby-core-resource-directory]. The resources 620 describe how the services can be manipulated in detail and in 621 concreto. 623 It is assumed that a resource directory exists per 6LoWPAN [RFC4944], 624 possibly running on the edge router. The DNS-SD provides a larger 625 scope by storing the info of all services over a set of 626 interconnected 6LoWPANs. Where the resource directory is possibly 627 completely adequate for home networks, handling of multiple resource 628 directories can be quite cumbersome for the many 6LoWPANs envisaged 629 for offices. However, during network configuration, the resource 630 directory can be used as long as the DNS is not yet accessible. 632 The DNS-SD approach is complementary to the more fine-grained 633 resource discovery, fits better the concept of service by discovering 634 servers with given properties. DNS-SD supports a hierarchical 635 approach to the naming of the services as discussed in section 3. 636 DNS-SD provides a directory structure that scales well with the 637 network size as shown by its present-day operation. 639 5. DNS record structure 641 An example is presented which explains the Resource Record (RR) 642 structure on the DNS server. This section follows the mapping 643 specified in [I-D.lynn-core-discovery-mapping], which defines how to 644 fill the DNS-SD records from the link extension values. Suppose the 645 services are delivered by XXX building control devices. The example 646 subtype- and context- names are assumed to be standardized by the XXX 647 alliance. All devices are situated in one office with location 648 office4.bldg8.example.com. The names in the examples are more 649 verbose than recommended to make the examples more readable. The 650 table presents the services provided in the office control network: 652 service ServiceType Number 653 illumination _OnOff_light._sub._bc._udp 4 654 presence _occup_sensor._sub._bc._udp 1 655 temperature _temp_sensor._sub._bc._udp 1 656 shading _shade_control._sub._bc._udp 1 658 In DNS PTR records with as label the ServiceType have as value 659 service instance names. The unique Instance names identify the 660 service instances. In the example, the names contain id-x, with x in 661 natural numbers. The names are usually created at the factory floor 662 and somehow attached to the product. The ServiceTypes have been 663 suffixed with .04.b8 to represent office4 in building8. The same 664 suffix is used as PTR label to enemerate all instance of a given 665 service, or within a given domain. 667 _OnOff_light._sub._bc._udp.04.b8 PTR id-1._OnOff_light 668 bc._udp.04.b8 PTR id-1._OnOff_light 669 04.b8 PTR id-1._OnOff_light 670 _OnOff_light._sub._bc._udp.04.b8 PTR id-2._OnOff_light 671 bc._udp.04.b8 PTR id-2._OnOff_light 672 04.b8 PTR id-2._OnOff_light 673 _OnOff_light._sub._bc._udp.04.b8 PTR id-3._OnOff_light 674 bc._udp.04.b8 PTR id-3._OnOff_light 675 04.b8 PTR id-3._OnOff_light 676 _OnOff_light._sub._bc._udp.04.b8 PTR id-4._OnOff_light 677 bc._udp.04.b8 PTR id-4._OnOff_light 678 04.b8 PTR id-4._OnOff_light 679 _occup_sensor._sub._bc._udp.04.b8 PTR id-5._occup_sensor 680 bc._udp.04.b8 PTR id-5._occup_sensor 681 04.b8 PTR id-5._occup_sensor 682 _temp_sensor._sub._bc._udp.04.b8 PTR id-6._temp_sensor 683 bc._udp.04.b8 PTR id-6._temp_sensor 684 04.b8 PTR id-6._temp_sensor 685 _shade_control._sub._bc._udp.04.b8 PTR id-7._temp_sensor 686 bc._udp.04.b8 PTR id-7._temp_sensor 687 04.b8 PTR id-7._temp_sensor 689 In the above example the id-x identifiers without the subtype suffix 690 would be discriminating enough. 692 Discovery can be done with the following results. A query with the 693 following argument returns 695 query argument result list 696 .04.8 id-1._OnOff_light 697 ....... 698 id-7._temp_sensor 699 _bc._udp.04.b8 id-1._OnOff_light 700 ....... 701 id-7._temp_sensor 702 _OnOff_light._sub._bc._udp.04.b8 id-1._OnOff_light 703 ....... 704 id-4._OnOff_light 705 _occup_sensor._sub._bc._udp.04.b8 id-5._occup_sensor 707 When other offices are included in the database, the query argument 708 04.b8 selects those entries which are associated with office4 in 709 building8 and rejects any others. The example shows clearly the 710 query granularity that can be obtained and the care that must be 711 exercised when defining the names of the ServiceTypes. 713 The service instances (value of PTR records) are the labels of the 714 SRV, AAAA and TXT records describing the service instance. The SRV 715 record specifies the location (authority) and the port number. In 716 the authority o4.b8 refers to office4 in building8. The AAAA record 717 specifies the IP-address, while the TXT record specifies the subtype 718 and the data representation of the legacy parser (if = ZigBee). 720 id-1._OnOff_light SRV light1.o4.b8.example.com Port-x 721 AAAA fdfd::1234 722 TXT if=ZigBee 723 id-2._OnOff_light SRV light2.o4.b8.example.com Port-x 724 AAAA fdfd::1235 725 TXT if=ZigBee 726 id-3._OnOff_light SRV light3.o4.b8.example.com Port-x 727 AAAA fdfd::1236 728 TXT if=ZigBee 729 id-4._OnOff_light SRV light4.o4.b8.example.com Port-x 730 AAAA fdfd::1237 731 TXT if=ZigBee 732 id-5._occup_sensor SRV occup.o4.b8.example.com Port-x 733 AAAA fdfd::1238 734 TXT if=ZigBee 735 id-6._temp_sensor SRV temp.o4.b8.example.com Port-x 736 AAAA fdfd::1239 737 TXT if=ZigBee 738 id-7._shade_control SRV shade.o4.b8.example.com Port-x 739 AAAA fdfd::1240 740 TXT if=ZigBee 742 It is possible that the temperature sensor and occupancy sensor are 743 delivered on one device. The consequence is that one device hosts 744 two services. In the DNS table the four lights and the shade 745 controller are unaffected. However, the PTR records with the 746 occupancy and temperature sensor point to the same unique identifier 747 id-8 that is suffixed with the name of the subtype. This example 748 shows that the subtype suffix is needed to discriminate between the 749 two service instances. 751 _occup_sensor._sub._bc._udp PTR id-8._occup_sensor 752 _temp_sensor._sub._bc._udp PTR id-8._temp_sensor 754 Two SRV records with accompanying AAAA and TXT records describe the 755 two servers, each providing one service, in more detail. The servers 756 share the same IP address but are connected to different ports, and 757 do have a different paths names. The TXT record is used to specify 758 the path part with "path=". 760 id-8._occup_sensor SRV occup.o4.b8.example.com Port-x 761 AAAA fdfd::1241 762 TXT path=/os if=ZigBee 763 id-8._temp_sensor SRV temp.o4.b8.example.com Port-y 764 AAAA fdfd::1241 765 TXT path=/ts if=ZigBee 767 The path names /ts and /os are short names for temperature_sensor and 768 occupancy_sensor respectively. Not all multi-function devices will 769 use different ports for the individual functions. It is also quite 770 common to use different IP interfaces with different IP addresses, 771 reflected by the value of the AAAA records. 773 5.1. DNS group example 775 Another aspect is the grouping of servers. Where in the former 776 section the names of the services are standardized names, this is 777 less probable for the group names. Usually the group names are 778 application specific or are standardized at the manufacturer. For 779 example, assume that a group all-light.o4.b8.example.com is created 780 which contains all four lights inside office4. The accompanying 781 ServiceType can be defined as _all_light._sub._bc._udp. The 782 ServiceType suffixed with 04.b8 points to a unique identifier defined 783 as _all_light.04.b8, assuming that this is the only _all_light group 784 within office 4 of building 8. The PTR record looks like: 786 _all_light._sub._bc._udp.04.b8 PTR _all_light.04.b8 788 It is assumed that the group all_light.o4.b8.example.com has received 789 a multicast address: ff1e::148. The accompanying SRV, AAAA, and TXT 790 RR become: 792 _all_light.04.b8 SRV all_light.o4.b8.example.com Port-z 793 AAAA ff1e::148 794 TXT if=ZigBee 796 When a multicast message is sent to a group, the path of the accessed 797 resource must be strictly the same for all servers. The naming of 798 the path is typically a responsibility for the standardisation 799 organisations describing the command set for a given application 800 area. However a constraint exits in the case of mult-function 801 devices which host multiple resource of the same type. For example a 802 device with three lamps with corresponding onoff attributes can be 803 accessed via the three different paths: 805 /light/1/onoff 806 /light/2/onoff 807 /light/3/onoff 809 A unique path to the onoff resource of all instances of light on this 810 device can be provided by /light/onoff. As this is logically the 811 path to a single instance on a mono-function device. The 812 corresponding unique paths for onoff to be used in the multicast 813 message becomes /light/onoff. The corresponding resource records for 814 a luminaire, named lm1, in DNS become: 816 _light._sub._bc._udp.04.b8 PTR _all_light.04.b8 817 _light._sub._bc._udp.04.b8 PTR _light_1.04.b8 818 _light._sub._bc._udp.04.b8 PTR _light_2.04.b8 819 _light._sub._bc._udp.04.b8 PTR _light_3.04.b8 820 _all_light.04.b8 SRV all_light.o4.b8.example.com Port-x 821 AAAA ff1e::148 822 TXT if=ZigBee path=/light 823 _light_1.04.b8 SRV lm1.o4.b8.example.com Port-z 824 AAAA fdfd::1234 825 TXT if=ZigBee path=/light/1 826 _light_2.04.b8 SRV lm1.o4.b8.example.com Port-z 827 AAAA fdfd::1234 828 TXT if=ZigBee path=/light/2 829 _light_3.04.b8 SRV lm1.o4.b8.example.com Port-z 830 AAAA fdfd::1234 831 TXT if=ZigBee path=/light/3 833 The entries in DNS can be used to form groups with the light weight 834 group management protocol and multicast listener discovery [RFC5790]. 836 5.2. Operational use of DNS-SD 838 The populated DNS-SD server provides the necessary support for the 839 applications to execute their control loops with minimum operator 840 support. The operation of the office network can be split up in 841 phases. In a first phase the network is commissioned, such that a 842 relation is established between the IP address, the servicetype and 843 the domain. The servicetype can be extracted from the link-format as 844 described in [I-D.shelby-core-resource-directory]. After 845 commissioning this information is stored in the DNS-SD files. In a 846 second phase groups are formed and group names with their IP address 847 are stored in the DNS-SD files. The IP multicast addresses are 848 communicated to the members of the groups. In the third and final 849 phase, applications query DNS-SD to find the IP addresses of the 850 services within a given domain, and of the groups within a given 851 domain. 853 In the home, a commissioning phase requiring the intervention of an 854 installer (a "truck roll") is to be avoided if possible. Here the 855 first phase consists of the booting up devices which insert their 856 services resources to a link-format directory. The information from 857 the resource directory can be inserted into DNS-SD or into xmDNS 858 [I-D.lynn-dnsext-site-mdns] when appropriate. In the second phase 859 remote controllers or other hand-held devices can be used to discover 860 the services of a given type, to group the services, and to store the 861 group names into DNS-SD or xmDNS as appropriate. Pointing out the 862 members of a group can be in any kind of manner from typing members 863 in, selecting them from a browser list, etc. 865 5.3. Commissioning CoAP devices 867 For clarity it is assumed in this section that a device hosts one 868 server. A device has received a unique device identifier at the 869 production plant. Given the authority naming presented in section 870 2.2 the authority name represents the location of the host within the 871 building. 873 Commissioning means the following three actions: 875 - Defining the URI (location) 876 - Assigning an IP address to the URI 877 - mapping the unique device identifier to the URI 879 Two cases of the office network are considered for commissioning: (1) 880 no 6LBR and no DNS server connected, and (2) a 6LBR connects the 881 office network to a DNS server. 883 When an architect has designed the building and described all light 884 points, ventilators, heating- and cooling units, and sensors, it is 885 necessary to identify all these devices spatially and functionally. 886 Storing the triple .. into DNS-SD 887 represents the commissioning process. The Instance is the unique 888 identifier given to the device in the factory but which has no 889 relation to its later location. The ServiceType together with the 890 Location represent the spatial and functional aspects of the device 891 as specified by the architect. 893 Design decision: A commissioning tool with access to the network is 894 used for the commissioning phase. 896 For example, dependent on used technology and production process, the 897 following situation (state) may exist in a host after physical 898 installation of the devices and before commissioning: 900 - A given host is unaware of its Location. 902 - A given host knows its ServiceType and Instance. The Instance is 903 also readable by bar code reader. 905 - The commissioning tool knows all Locations to which hosts need to 906 be assigned. 908 - Each host has a (site-local) IP address. 910 Consider the commissioning process (1) with a central DNS-SD server 911 and (2) without a central server using xmDNS. The commissioning 912 processes described below are just examples and should not be taken 913 as working procedures for commissioning devices in a building. 915 5.3.1. DNS-SD server present 917 The installer reads with a bar code reader, attached to the 918 commissioning tool, the identifier of the device to commission. It 919 is assumed that the tool can learn the IP address of the device with 920 the given identifier. The tool displays on a screen the physical 921 lay-out of the devices within the building. The installer selects, 922 on the screen of the tool, the physical location of the chosen 923 device. From the designated physical location the tool creates the 924 URI of the selected device. The tool inserts the URI and the IP 925 address into the DNS server. For example the light with URI 926 light1.o4.b8.example.com is represented with an AAAA record: 928 light1.o4.b8.example.com AAAA fdfd::1234 930 The tool reads the service name and type from the device using 931 resource information stored according to the link-format 932 [I-D.ietf-core-link-format]. With this information the tool 933 constructs the PTR, SRV and TXT records according to the example 934 presented in section 5. 936 This is done for all devices within a given part of the building. 937 After the commissioning process, all resources of each device have an 938 URI and IP address which are stored in the central DNS-SD server. 939 When devices are restarted, the DHCP server may allocate new IP 940 addresses to the device and update the DNS server. 942 5.3.2. DNS-SD server not present 944 It is assumed that the building network is composed of independent 945 network segments (possibly a single site) such that each device on a 946 given segment can communicate directly with any other device on this 947 segment. The segments are not connected to a 6LBR and have no access 948 to DNS or other servers. The installer knows these segments and has 949 a list of devices for a given segment. In the tool the installer 950 selects the names which belong to the given building segment. The 951 selected names are converted to site-local authorities and stored in 952 the tool. All devices are assumed to have selected a site-local IP 953 address. Assume that every device has a unique barcode within the 954 building and that the corresponding device knows the bar code number. 955 The installer reads with a bar code reader, attached to the tool, the 956 Instance name of the device to commission. The installer selects, on 957 the screen of the tool, the physical location of the chosen device. 958 The tool knows the authority of the selected device. The tool 959 broadcasts the bar code number and authority to all connected 960 devices. The device with the given barcode number, extends the 961 authority with the path name of the resources. For each resource, 962 the device multicasts the site-local IP-address and the site-local 963 URI to the xmDNS servers in the connected devices. This concludes 964 the commissioning of a network segment. All resources of each device 965 have a site-local URI and a site-local IP address which are stored in 966 the xmDNS servers. 968 5.4. Proxy discovery 970 Proxies will be used in CoAP networks for at least two major reasons: 971 (1) http/coap proxy, and (2) proxy of service on battery-less device. 972 The first proxy is probably implemented as forward proxy, while the 973 latter is probably implemented as backward proxy. The battery-less 974 device will at rare occasions (when it is not sleeping) and during 975 installation answer the GET /.well-known/core request. The return 976 data are used by the installation tool to make the proxy device 977 return the same resource names on /.well-known/core as is returned by 978 the sleeping device. An installation tool installs on the proxy all 979 the resources of the sleeping device for which the proxy is assumed 980 to answer. Consequently, the proxy is discovered as a multi-server 981 host with as many path names as it proxies sleeping servers. The 982 servers on sleeping devices should not be discoverable via DNS-SD. 983 However, AAAA records are generated for the sleeping device host 984 name. This host name is used by the proxy to subscribe to the 985 "sporadic" services of the sleeping device. For example assume two 986 sleeping devices, an occupancy sensor and a temperature sensor, and 987 one proxy. Two service types are defined with PTR records in DNS-SD. 988 The identifier id-1 of the proxy is used by the installation tool to 989 define the Instances. 991 _occup_sensor._sub._bc._udp.04.b8 PTR id-1._occup_sensor 992 _temp_sensor._sub._bc._udp.04.b8 PTR id-1._temp_sensor 994 Two SRV records with accompanying AAAA and TXT records describe the 995 two services in more detail. The services share the same IP address, 996 are connected to the same port, but do have different paths names. 997 The TXT record is used to specify the path part with "path=". 999 id-1._occup_sensor SRV proxy.o4.b8.example.com Port-x 1000 AAAA fdfd:: 1241 1001 TXT path=/os if=ZigBee 1002 id-1._temp_sensor SRV proxy.o4.b8.example.com Port-x 1003 AAAA fdfd:: 1241 1004 TXT path=/ts if=ZigBee 1005 sl-ts.o4.b8.example.com AAAA fdfd::1242 1006 sl-os.o4.b8.example.com AAAA fdfd::1243 1008 The path names /ts and /os are short names for temperature_sensor and 1009 occupancy_sensor respectively and were taken over from link-format 1010 information contained in the sleeping devices. Two AAAA records are 1011 provided for the two sleeping devices. The proxy has used the domain 1012 names of the sleeping devices to subscribe to the publications of the 1013 two sleeping devices. 1015 It is important to remark that there are now two services with the 1016 same resources present on two different devices: the sleeping device 1017 and its proxy. When a host invokes the /.well-known/core resource, 1018 it should be possible to distinguish between the proxy (to be 1019 invoked) and the sleeping device (not to be invoked). The 1020 distinction is necessary once the sleeping device is discoverable and 1021 the sleeping device is awake from time to time. It is suggested that 1022 the link-format syntax allows to make this distinction. 1024 6. Legacy data Representations in CoAP 1026 Before CoAP devices can come to market, manufacturers must agree that 1027 the type and resources of the device can be interpreted according to 1028 some generally recognized syntax. At this moment no such generally 1029 recognized syntax exists for CoAP devices. We do not expect an IETF 1030 working group to standardize such a syntax, and we are convinced that 1031 syntax standardization is the responsibility of industry standards 1032 organizations. Given the long history of building control, many 1033 groups have defined a data representation for building control 1034 devices for example BACnet, ZigBee, oBIX, LON, KNX, and many others. 1035 It is our belief that new representations will be defined and must 1036 coexist with the named legacy ones. 1038 The CoAP protocol should transport any data representation, and 1039 certainly the legacy ones.It is expected that a CoAP client can 1040 handle one or more legacy representation. Given that a CoAP client 1041 can handle representation of standard XXX, this I-D proposes that 1042 such a CoAP device can communicate with legacy devices via a CoAP/ 1043 legacy gateway (router). 1045 6.1. Network architectures 1047 +------+ +------+ +------+ 1048 | yyy | | zzz | | zzz | 1049 | link | | CoAP | | CoAP | 1050 +------+ +------+ +------+ 1051 | +---------+ 1052 |---------| CoAP |--> 1053 | | gateway | 1054 +------+ +---------+ +-----------+ 1055 | yyy | | zzz ; yyy | 1056 | link | | CoAP | 1057 +------+ +-----------+ 1059 Figure 1: network with multiple representation standards 1061 Figure 1 represents the network architecture which is expected for 1062 the purpose of this I-D. The CoAP gateway connects one link with two 1063 legacy devices -containing legacy data representation "yyy"- with the 1064 wireless CoAP network composed of three CoAP hosts. Two CoAP hosts 1065 contain the CoAP stack with a zzz representation and one host 1066 contains the CoAP stack with a zzz and an yyy representation. The 1067 yyy hosts can freely communicate according to the yyy link protocol 1068 over the yyy link. The zzz CoAP hosts, including the zzz;yyy host 1069 can freely exchange zzz data representations according to the CoAP 1070 protocol over the wireless 6LoWPAN network. The zzz;yyy host can 1071 send yyy data representations to the CoAP gateway which passes them 1072 on to the specified yyy legacy host. The yyy legacy device returns 1073 data to the requesting zzz;yyy CoAP host via the same gateway. 1075 The CoAP hosts can address the legacy devices behind the gateway in 1076 at least 4 ways. 1078 - All devices of legacy network YYY share the URI with the CoAP 1079 gateway. Every legacy device is a resource for the gateway as 1080 seen from the CoAP host. Consequently, the CoAP host sends the 1081 message to the IP address of the gateway and the gateway parses 1082 the URI-Path to determine the specified legacy device. 1084 - All devices of legacy network YYY have IP addresses different from 1085 the IP address of the gateway. Consequently, a CoAP host sends 1086 the message to the IP address of the specified device. The 1087 routing protocol on the CoAP network makes the message arrive at 1088 the CoAP gateway. The gateway determines the specified legacy 1089 device from the destination IP address. 1091 - All devices of legacy network YYY have different authorities. The 1092 authorities of the legacy device resolve to an IP address of the 1093 gateway. This means that the possibly lengthy authority names 1094 need to be transmitted. The gateway recognizes the authorities 1095 and maps authority to legacy device. 1097 - All devices of legacy network YYY have different ports. This can 1098 be expressed in two ways (1) as :port in the URI, or (2) in the 1099 DNS-SD records. In the latter case the port is defined in the UDP 1100 header and is efficient in packet header size. 1102 The major advantage of all four approaches is that the gateway only 1103 handles the URI or IP address and port number to select the 1104 destination legacy device independent of the type of legacy device 1105 and the contents of the legacy payload of the message. In Figure 1 1106 the gateway connects to a single link. For example, this would be 1107 the case for DALI standard. Other legacy standards, like BACnet, 1108 LON, allow networks composed of multiple links. 1110 An example of an invocation of a ZZZ service (See figure 2). The 1111 resource path /ZZZ identifies the parser of the ZZZ syntax. A 12 1112 octet string completely describes the ZZZ command. The host is 1113 completely identified by the authority in the URI. The ZZZ parser on 1114 the host is identified by the port number in the UDP header (not 1115 shown). 1117 Client CoAP/ZZZ 1118 | device 1119 | REQUEST | 1120 |-------- CON [0x5577] PUT /ZZZ -------->| 1121 | binary 12 octet string | 1122 | | 1123 | RESPONSE | 1124 |<---------- ACK [0x5577] 2.00 OK ----------------- | 1125 | | 1127 Figure 2: Sending a ZZZ command with CoAP to CoAP/ZZZ device 1129 An example of an invocation of a DALI legacy device behind a gateway 1130 is given in figure 3. The resource path /DALI identifies the DALI 1131 parser. The application sets a value of 200 in the DALI device in 1132 the resource 256 defined by the DALI spec. 1134 Client DALI/CoAP 1135 | gateway 1136 | REQUEST | 1137 |------- CON [0x5577] PUT /DALI -------->| 1138 | binary 16 bit payload dt*256 + 200 | 1139 | | 1140 | RESPONSE | 1141 |<---------- ACK [0x5577] 2.00 OK ----------------- | 1142 | | 1144 Figure 3: Sending a DALI setting with CoAP to CoAP/DALI gateway 1146 6.2. Discovery of legacy gateways 1148 Discovery of legacy gateways is not very different from discovery of 1149 proxies in section 5.4. the consequences for discovery are listed for 1150 the four modes of addressing legacy devices via a gateway of section 1151 6.1. 1153 - The gateway presents a list of resources representing the legacy 1154 devices. Discovery is done as for other CoAP devices. 1156 - Each legacy device has a different IP address. The gateway must 1157 create entries in the DNS for as many legacy devices. The 1158 authority of the legacy device is the authority of the gateway 1159 with a ServiceType to be specified by the gateway. 1161 - All devices of legacy network YYY have different authorities. In 1162 this case each legacy device has the same IP address as the 1163 gateway. The gateway must create entries in the DNS for as many 1164 legacy devices. 1166 - All devices of legacy network YYY have different ports. The 1167 gateway must create entries in the DNS for as many legacy devices. 1168 Each entry has the authority of the gateway with a different 1169 ServiceType and a different port number. 1171 7. Conclusions 1173 This I-D explains how naming in building control is based on a 1174 hierarchical structure of the building areas. It is shown that DNS 1175 naming can be used to express this hierarchy in the authority portion 1176 of the URI, down to the group or device level. The hierarchical 1177 naming scheme need not be standardized, but rather can be designed to 1178 suit the application. However, it is recommended that the scheme be 1179 employed consistently throughout the delegated subdomain(s). 1181 The authority portion of the URI is resolved by the client, using 1182 conventional DNS, into the unicast or multicast IP address of the 1183 targeted device(s). Taking advantage of the CoAP design 1184 [I-D.ietf-core-coap], the URI-Host option need not be transmitted in 1185 requests to origin servers and thus there is no performance penalty 1186 for using descriptive naming schemes. The CoAP design allows sending 1187 a short URI to distinguish between resources on a given device, 1188 resulting in very compact identifiers. 1190 DNS-SD [I-D.cheshire-dnsext-dns-sd] can be used to scale up service 1191 discovery beyond the 6LoWPAN. DNS-SD can be used to enumerate 1192 instances of a given service type within a given sub-domain. This 1193 affords additional flexibility, such as the ability to discover 1194 dynamic port assignments for CoAP device, locate CoAP devices by 1195 subtype, or bind service names for particular CoAP URIs. 1197 This I-D discusses the addressing, discovery and naming of legacy 1198 devices behind gateways. The discovery of backward proxies of 1199 sleeping devices is handled in a similar fashion. 1201 A targeted resource is specified by the path portion of the URI. 1202 Again, this I-D does not mandate a universal naming standard for 1203 resources but uses examples to show how resources could be named for 1204 various legacy standards. An obvious requirement for resources that 1205 are accessed by multicast is that they MUST all share the same path. 1206 It is shown that it is possible to transport legacy commands (e.g. 1207 expressed in BACnet, LON, DALI, ZigBee, etc.) inside a CoAP message 1208 body. Entering ServiceTypes particular to a given standard 1209 necessitates that the standardization body declares the ServiceType 1210 to dns.org. 1212 8. Security considerations 1214 TBD: The detailed CoAP security analysis needs to encompass scenarios 1215 for building control applications. 1217 Based on the programming model presented in this I-D, security 1218 scenarios for building control need to be stated. Appropriate 1219 methods to counteract the proposed threats may be based on the work 1220 done elsewhere, for example in the ZigBee over IP context. 1222 Multicast messages are, by their nature, transmitted via UDP. Any 1223 privacy applied to such messages must be block oriented and based on 1224 group keys shared by all targeted devices. The CoRE security 1225 analysis must be broadened to include multicast scenarios. 1227 9. IANA considerations 1229 This I-D proposes that associations which standardize device 1230 representations (like BACnet, ZigBee, DALI,...) contact IANA to 1231 reserve the prefix /.well-known/XXX for the standard XXX. 1233 10. Acknowledgements 1235 This I-D has benefited from conversations with and comments from 1236 Andrew Tokmakoff, Emmanuel Frimout, Jamie Mc Cormack, Oscar Garcia, 1237 Dee Denteneer, Joop Talstra, Zach Shelby, Jerald Martocci, Anders 1238 Brandt, Matthieu Vial, Jerome Hamel, George Yianni, and Nicolas Riou. 1240 11. Changelog 1242 From bc-01 to bc-02 1244 - Removed all references to multicast and multicast scope, given 1245 draft of rahman group communication. 1247 - Adapted examples to CoAP-2 and core-link drafts. 1249 - transport short URL for destination recognition. 1251 - Elaborated legacy discovery under DNS-SD. 1253 From bc-02 to bc-03 1255 - Elaboration on gateways, commissioning and legacy networks. 1257 - Recommendation to extend DNS-SD naming with sn, st, and ss 1258 attributes. 1260 From bc-03 to bc-04 1262 - moved core link extension sub-section to discovery mapping draft 1264 - extended use of service type 1266 - gave DNS record examples and worked out multifunction device 1268 - added proxy discovery and legacy gateway discovery 1270 - defined path tree and corresponding schema 1272 - reviewed definition of group, device, server, service (interface), 1273 resopurce, and attribute. 1275 From bc-04 to bc-05 1277 - extended and corrected examples for multi-function devicesw 1279 - syntax more compatible with other resource discovery I-Ds 1281 - abstract adapted 1283 - more stringent use of the words server, end point, service and 1284 devices 1286 12. References 1288 12.1. Normative References 1290 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 1291 STD 13, RFC 1034, November 1987. 1293 [RFC1123] Braden, R., "Requirements for Internet Hosts - Application 1294 and Support", STD 3, RFC 1123, October 1989. 1296 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1297 Requirement Levels", BCP 14, RFC 2119, March 1997. 1299 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1300 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1301 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1303 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 1304 specifying the location of services (DNS SRV)", RFC 2782, 1305 February 2000. 1307 [RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6 1308 Multicast Addresses", RFC 3306, August 2002. 1310 [RFC3307] Haberman, B., "Allocation Guidelines for IPv6 Multicast 1311 Addresses", RFC 3307, August 2002. 1313 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 1314 "DNS Extensions to Support IP Version 6", RFC 3596, 1315 October 2003. 1317 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 1318 10646", STD 63, RFC 3629, November 2003. 1320 [RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous 1321 Point (RP) Address in an IPv6 Multicast Address", 1322 RFC 3956, November 2004. 1324 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1325 Resource Identifier (URI): Generic Syntax", STD 66, 1326 RFC 3986, January 2005. 1328 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 1329 "Transmission of IPv6 Packets over IEEE 802.15.4 1330 Networks", RFC 4944, September 2007. 1332 [RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network 1333 Interchange", RFC 5198, March 2008. 1335 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known 1336 Uniform Resource Identifiers (URIs)", RFC 5785, 1337 April 2010. 1339 [RFC5790] Liu, H., Cao, W., and H. Asaeda, "Lightweight Internet 1340 Group Management Protocol Version 3 (IGMPv3) and Multicast 1341 Listener Discovery Version 2 (MLDv2) Protocols", RFC 5790, 1342 February 2010. 1344 12.2. Informative References 1346 [I-D.cheshire-dnsext-dns-sd] 1347 Cheshire, S. and M. Krochmal, "DNS-Based Service 1348 Discovery", draft-cheshire-dnsext-dns-sd-10 (work in 1349 progress), February 2011. 1351 [I-D.cheshire-dnsext-multicastdns] 1352 Cheshire, S. and M. Krochmal, "Multicast DNS", 1353 draft-cheshire-dnsext-multicastdns-14 (work in progress), 1354 February 2011. 1356 [I-D.ietf-core-coap] 1357 Shelby, Z., Hartke, K., Bormann, C., and B. Frank, 1358 "Constrained Application Protocol (CoAP)", 1359 draft-ietf-core-coap-07 (work in progress), July 2011. 1361 [I-D.ietf-core-link-format] 1362 Shelby, Z., "CoRE Link Format", 1363 draft-ietf-core-link-format-07 (work in progress), 1364 July 2011. 1366 [I-D.martocci-6lowapp-building-applications] 1367 Martocci, J., Schoofs, A., and P. Stok, "Commercial 1368 Building Applications Requirements", 1369 draft-martocci-6lowapp-building-applications-01 (work in 1370 progress), July 2010. 1372 [I-D.rahman-core-groupcomm] 1373 Rahman, A. and E. Dijk, "Group Communication for CoAP", 1374 draft-rahman-core-groupcomm-07 (work in progress), 1375 October 2011. 1377 [I-D.shelby-core-resource-directory] 1378 Shelby, Z. and S. Krco, "CoRE Resource Directory", 1379 draft-shelby-core-resource-directory-01 (work in 1380 progress), September 2011. 1382 [I-D.lynn-core-discovery-mapping] 1383 Lynn, K. and Z. Shelby, "CoRE Link-Format to DNS-Based 1384 Service Discovery Mapping", 1385 draft-lynn-core-discovery-mapping-01 (work in progress), 1386 July 2011. 1388 [I-D.lynn-dnsext-site-mdns] 1389 Lynn, K. and D. Sturek, "Extended Multicast DNS", 1390 draft-lynn-dnsext-site-mdns-01 (work in progress), 1391 March 2011. 1393 [BACnet] Bender, J. and M. Newman, "BACnet/IP", 1394 Web http://www.bacnet.org/Tutorial/BACnetIP/index.html, 1395 2000. 1397 [ZigBee] Tolle, G., "A UDP/IP Adaptation of the ZigBee Application 1398 Protocol", draft-tolle-cap-00 (work in progress), 1399 October 2008. 1401 [LON] "LONTalk protocol specification, version 3", 1994. 1403 [DALI] "DALI Manual", Web http://www.dali-ag.org/c/manual_gb.pdf, 1404 2001. 1406 [KNX] Kastner, W., Neugschwandtner, G., and M. Koegler, "AN OPEN 1407 APPROACH TO EIB/KNX SOFTWARE DEVELOPMENT", Web http:// 1408 www.auto.tuwien.ac.at/~gneugsch/ 1409 fet05-openapproach-preprint.pdf, 2005. 1411 [IEEE.802.15.4] 1412 "Information technology - Telecommunications and 1413 information exchange between systems - Local and 1414 metropolitan area networks - Specific requirements - Part 1415 15.4: Wireless Medium Access Control (MAC) and Physical 1416 Layer (PHY) Specifications for Low Rate Wireless Personal 1417 Area Networks (LR-WPANs)", IEEE Std 802.15.4-2006, 1418 June 2006, 1419 . 1421 [HAYSTACK] 1422 "Project Haystack", Web http://project-haystack.org/, 1423 2011. 1425 [oBIX] Frank, B., Ed., "oBIX working group", 1426 Web http://www.obix.org, 2006. 1428 [Fielding] 1429 Fielding, R., "Architectural Styles and the Design of 1430 Network-based Software Architectures, Second Edition", 1431 Doctoral dissertation , University of California, Irvine , 1432 Web http://www.ics.uci.edu/~fielding/pubs/dissertation/ 1433 top.html, 2000. 1435 [ZigBee-IP] 1436 "ZigBee Smart Energy Profile 2.0 Application Protocol 1437 Specification", Draft ZigBee-11167, March 2011. 1439 [dns-sd] "dns-sd servicetype registration", 1440 Web http://www.dns-sd.org/ServiceTypes.html, 2011. 1442 Authors' Addresses 1444 Peter van der Stok 1445 Philips Research 1446 High Tech Campus 34-1 1447 Eindhoven, 5656 AA 1448 The Netherlands 1450 Email: peter.van.der.stok@philips.com 1452 Kerry Lynn 1453 Consultant 1455 Phone: +1 978 460 4253 1456 Email: kerlyn@ieee.org