idnits 2.17.1 draft-vanderstok-core-dna-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 74 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 644 has weird spacing: '... 0 Port lm002...' == Line 646 has weird spacing: '... 0 Port lm002...' == Line 648 has weird spacing: '... 0 Port lm002...' == Line 650 has weird spacing: '... 0 Port lm002...' == Line 652 has weird spacing: '... 0 Port ps005...' == (9 more instances...) -- The document date (July 10, 2012) is 4279 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'End-point' is mentioned on line 373, but not defined == Unused Reference: 'RFC4291' is defined on line 1189, but no explicit reference was found in the text == Unused Reference: 'RFC4605' is defined on line 1192, but no explicit reference was found in the text == Unused Reference: 'RFC5234' is defined on line 1201, but no explicit reference was found in the text == Unused Reference: 'I-D.eggert-core-congestion-control' is defined on line 1224, but no explicit reference was found in the text == Unused Reference: 'ZeroConf' is defined on line 1298, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2845 (Obsoleted by RFC 8945) ** Obsolete normative reference: RFC 5785 (Obsoleted by RFC 8615) ** Obsolete normative reference: RFC 5988 (Obsoleted by RFC 8288) == Outdated reference: A later version (-06) exists of draft-ietf-6man-uri-zoneid-01 == Outdated reference: A later version (-18) exists of draft-ietf-core-coap-10 == Outdated reference: A later version (-25) exists of draft-ietf-core-groupcomm-01 == Outdated reference: A later version (-02) exists of draft-lynn-core-discovery-mapping-01 == Outdated reference: A later version (-01) exists of draft-lynn-homenet-site-mdns-00 == Outdated reference: A later version (-04) exists of draft-shelby-core-coap-req-02 == Outdated reference: A later version (-05) exists of draft-shelby-core-interfaces-02 == Outdated reference: A later version (-05) exists of draft-shelby-core-resource-directory-03 == Outdated reference: A later version (-01) exists of draft-vial-core-mirror-proxy-00 Summary: 3 errors (**), 0 flaws (~~), 23 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CoRE P. van der Stok, Ed. 3 Internet-Draft vanderstok consultancy 4 Intended status: Informational K. Lynn 5 Expires: January 11, 2013 Consultant 6 A. Brandt 7 Sigma Designs 8 July 10, 2012 10 CoRE Discovery, Naming, and Addressing 11 draft-vanderstok-core-dna-02 13 Abstract 15 This is a working document intended to focus discussion and refine 16 draft language for the CoAP protocol specification (or other proposed 17 standards) in the areas of discovery, naming, and addressing. 18 Requirements on discovery are motivated. Special emphasis is placed 19 on group definition and discovery. Examples show how groups can be 20 represented in CoAP Resource Directories or DNS-SD. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on January 11, 2013. 39 Copyright Notice 41 Copyright (c) 2012 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 4 59 1.3. Applicability . . . . . . . . . . . . . . . . . . . . . . 4 60 2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 3.1. Discovery scope . . . . . . . . . . . . . . . . . . . . . 6 63 3.2. Interactive mapping . . . . . . . . . . . . . . . . . . . 6 64 3.3. M2M mapping . . . . . . . . . . . . . . . . . . . . . . . 7 65 3.4. End-point grouping . . . . . . . . . . . . . . . . . . . . 7 66 3.5. Discovery queries . . . . . . . . . . . . . . . . . . . . 10 67 3.6. Sleeping devices . . . . . . . . . . . . . . . . . . . . . 11 68 4. DNS and RD examples . . . . . . . . . . . . . . . . . . . . . 12 69 4.1. DNS-SD examples . . . . . . . . . . . . . . . . . . . . . 13 70 4.2. RD examples . . . . . . . . . . . . . . . . . . . . . . . 19 71 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 72 6. Security Considerations . . . . . . . . . . . . . . . . . . . 24 73 6.1. DNS Security considerations . . . . . . . . . . . . . . . 24 74 6.2. RD Security considerations . . . . . . . . . . . . . . . . 26 75 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26 76 8. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 26 77 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 78 9.1. Normative References . . . . . . . . . . . . . . . . . . . 26 79 9.2. Informative References . . . . . . . . . . . . . . . . . . 28 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 82 1. Introduction 84 The CoRE working group is chartered to design and standardize a 85 Constrained Application Protocol (CoAP) for resource constrained 86 devices and networks [I-D.ietf-core-coap]. The requirements for CoRE 87 are documented in [I-D.shelby-core-coap-req]. This draft discusses 88 the requirements on service discovery for M2M and interactive 89 applications using resource constrained devices. We propose the use 90 of DNS-SD [I-D.cheshire-dnsext-dns-sd] and Resource Directory (RD) 91 [I-D.shelby-core-resource-directory] to satisfy the requirements. 92 The proposal relies heavily on naming and addressing conventions. 93 Special emphasis is placed on the definition, naming, and discovery 94 of groups. 96 1.1. Terminology 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 100 document are to be interpreted as described in RFC 2119 [RFC2119]. 101 Addtional privileged words are described below. 103 A "device" is a physical processor connected to at least one link 104 through a network interface. Each interface has at least one IP 105 unicast address. The IP address is optionally bound to a host name, 106 which may be a Fully Qualified Domain Name (FQDN). 108 An "end-point" corresponds to a "service" and is indentified by a 109 unique {protocol, host, port} tuple. The identity of an endpoint may 110 be specified by the 'scheme' and 'authority' parts of a URI 111 [RFC3986]. 'Protocol' is a label that indicates application and 112 transport protocol bindings as well as default port (if port is not 113 specified) and possibly default semantics such as web-linking 114 [RFC5988]. 'Host' corresponds to the [RFC3986] ABNF production as 115 updated by [I-D.ietf-6man-uri-zoneid]. 117 A "service type", e.g. _bldg-ctrl._tcp, is equivalent to the 118 'protocol' label described above. It identifies an application 119 protocol, typically defined by a Standards Development Organization 120 (SDO), and is ultimately registered with IANA 121 [I-D.cheshire-dnsext-dns-sd]. The SDO may additionally specify 122 service subtypes (e.g. _light, _onoff-control, _air-flow ...) to 123 designate units of functionality, the attributes of the subtypes, and 124 the primitives acting on the attributes. 126 A "resource" is any attribute of an end-point that can be acted upon 127 by REST methods. A resource is identified by a URI, that is, an end- 128 point plus a 'path' component [RFC3986]. 130 A "Function Set" is a service subtype with a set of resources and 131 behaviors that may be accessed through a REST interface. A Function 132 Set will typically be decribed by a base URI plus an interface 133 definition as described in [I-D.shelby-core-interfaces]. The 134 interface definition may specify the naming patterns of subordinate 135 resources and the methods that act on them. 137 A "Profile" is a group of Function Sets defined by a specification. 139 A "Collection" is a set of two or more homogeneous subordinate 140 resources that may be acted upon in the aggregate by sending messages 141 to their parent resource, or individually by sending messages to the 142 collection member. 144 A "Device type" describes a standardized set of Function Sets that 145 satisfy a use case for a hosting device. 147 A "group" is a set of end-points. 149 A "multicast group" is a group of end-points that share a multicast 150 address. The multicast address is optionally bound to a FQDN that 151 identifies the multicast group. For the purposes of this document, a 152 (multicast) group generally hosts one Function Set. 154 1.2. Motivation 156 In this draft, we focus and expand discussions on requirements 157 pertaining to discovery, naming, and addressing, including REQ8 of 158 the CoRE charter: 160 REQ8: A definition of how to use CoAP to advertise about or query 161 for a Device's description. This description may include the 162 device name and a list of its Resources, each with a URL, an 163 interface description URI (pointing e.g. to a Web Application 164 Description Language (WADL) document) and an optional name or 165 identifier. The name taxonomy used for this description will 166 be consistent with other IETF work, e.g. 167 draft-cheshire-dnsext-dns-sd. [charter] 169 The basis of this draft originated in [I-D.vanderstok-core-bc]. 171 1.3. Applicability 173 This note applies to discovery of services for commissioning and 174 auto-configuration in building networks (for example: residential and 175 office). The examples are inspired by the building environment. The 176 proposed solutions and recommendations can be applied more generally. 178 2. Architecture 180 This section illustrates the aspects of naming schemes and their 181 support by DNS-based Service Discovery (DNS-SD) 182 [I-D.cheshire-dnsext-dns-sd] , Extended Multicast DNS (xmDNS) 183 [I-D.lynn-homenet-site-mdns], and the Resource Directory (RD) 184 [I-D.shelby-core-resource-directory] on a set of network 185 architectures. 187 The basic network for low-power nodes can be composed of low-resource 188 nodes sharing the same IPv6 prefix and connected to low-power links 189 like IEEE 802.15.4, ITU-T G.9959, or Powerline. The "lowpan" is a 190 good example of such a network [RFC4944], [RFC6282]. The network can 191 be either isolated or connected. This draft assumes that application 192 profiles are defined above coap or http, for example, applications as 193 specified by the ZigBee Smart Energy Profile 2.0 (SEP2), Obix, or 194 BACnet IT working groups. The naming and discovery solutions 195 presented here are applicable to multiple interconnected subnets. 196 Example network architectures are: 198 - An isolated lowpan consists of at least two lowpan devices, one of 199 which is an edge router that is not connected to a backbone. A 200 Resource Directory may be situated on the edge router. 201 Alternatively, xmDNS responders may execute on each device. 202 - A connected lowpan consists of at least two lowpan devices, one of 203 which is an edge router that is connected to a backbone. A 204 Resource Directory may be situated on an edge router. 205 Alternatively, xmDNS responders may execute on each device or the 206 DNS-SD service may be available over the backbone. 207 - Interconnected lowpans consist of at least two lowpans connected 208 via edge routers to the same backbone. A Resource Directory may be 209 situated on each edge router. Alternatively, xmDNS responders may 210 execute on each device or the DNS-SD service may be available over 211 the backbone. 212 - A site is a set of interconnected subnets that is locally 213 administered. A site may include zero or more lowpans. Border 214 routers may prevent some messages from passing into or out of the 215 site. 217 In certain scenarios, the domain may correspond to the network 218 topology. In the general case, the domain and network subnet 219 structure may differ. 221 3. Use Cases 223 The use of service discovery is presented in two environments: (1) 224 interactive service discovery, and (2) M2M service discovery. From 225 the use cases we derive the types of queries that service discovery 226 should support. In particular, a primary motivation is the discovery 227 of groups that support a given Function Set. 229 3.1. Discovery scope 231 In the simplest case the discovery scope is limited to the services 232 and resources provided on the LowPAN. In more complex cases, 233 discovery has a scope that can be defined with domain names. The 234 authority part of a URI [RFC3986] can express the location of the 235 device hosting the service. A common example is the naming 236 associated with the structure of a building. A device may acquire a 237 FQDN that relates directly to its location in the building. For 238 example, power-strip.office4.floor1.example.com (or shorter 239 ps.o4.f1.example.com) refers to a power-strip with device name 240 "power-strip" (or short "ps") in office4 at floor1 in the building of 241 the company example.com. Another naming scheme can be functional 242 like TV1.media.IT.example.com, possibly refering to TV number 1 243 maintained by the media group of the IT department of the example 244 organisation. Domain naming can be used to express that devices are 245 situated in the same building area or belong to the same 246 organisational units. Multiple FQDNs can identify a given device. 248 The DNS provides the mapping from Fully Qualified Domain Name (FQDN) 249 to network address and vice-versa. The RD realtes domain names to 250 end-points. The binding of domain names to a physical device (for 251 example, assigning a given FQDN to the TV in the corner) depends on 252 the operational conditions as described below. 254 3.2. Interactive mapping 256 In the residential context, naming of the device is done by the 257 occupant of the home. After connecting the device to the network, an 258 IP-address is assigned, possibly based on the EUI-64 value of the 259 network interface. The occupant can use a remote control with a 260 graphical user interface to display all devices that provide a given 261 service (e.g. a "lighting" service). The remote control prompts the 262 occupant to identify the (default named) devices, possibly 263 accompanied by on/off switching, barcode scanning, or other manual 264 intervention. The occupant can provide a meaningful name that will 265 be bound to that device. The installation steps can be as follows: 266 Service discovery returns all interfaces on which the specified 267 service is available. The occupant, with or without additional 268 physical support, establishes the binding between an IP address 269 (based on MAC address or other unique identifier) and the name of the 270 device providing the service, plus its relationship with other 271 devices or function sets in the system. In some cases a device has 272 multiple names, and an additional mapping between user specified name 273 and an automatically generated DNS name is supported. 275 3.3. M2M mapping 277 In the commercial context (e.g. office buildings) it is usual to 278 employ a Comissioning Tool (CT) to provide the mapping from physical 279 device to IP network address or FQDN. The professional context is 280 more rigid than the home because the absence of devices and also the 281 unwanted presence of devices needs to be detected. Devices are named 282 by an architect or installation contractor. Names can be generated 283 automatically and need not be human-friendly. The CT contains the 284 names and the physical locations of the devices. At commissioning 285 time the interfaces have acquired a network address, possibly based 286 on the EUI-64. The physical device is identified by reading in a 287 unique identifier (e.g. EUI-64 of interface, UUID of device) with a 288 reader (e.g. barcode reader). Consequently, the device name to 289 network address binding is stored into DNS (or elsewhere). 290 Alternatives for identifying devices are pushing buttons on the 291 device or remotely switching on/off the device. 293 3.4. End-point grouping 295 Groups can be used to express that end-points are related by 296 supporting a specific Function Set (e.g. HVAC equipment controlled 297 by the closest temperature sensor). Grouping is also necessary when 298 a set of end-points has to react together, more or less 299 synchronously, to a sequence of commands sent by one or more devices. 300 A common example is provided by lighting applications where a subset 301 of lights in the building are dimmed to the same level, set to the 302 same colour, or switched off simultaneously. Another example is 303 provided by a power-strip supporting a set of power-outlets. Power- 304 outlets are switched on/off individually or all together. Other 305 examples concern the home, such as a "sleep mode" setting of all 306 media devices in the home when the user activates the night scene. 308 Group naming is done the same way as for device naming. Related end- 309 points are grouped and named. The group name is constructed like a 310 FQDN with the group name as prefix. Adressing the group can be done 311 in two ways: (1) by addressing each end-point of the group 312 individually (which requires serial access), or (2) by defining a 313 multicast address for a multicast group. In the latter case, each 314 hosting device must enable reception by a given end-point of the 315 messages sent to the multicast address. The members of the multicast 316 group must have identical port number and path, because the requests 317 are specified in a single multicast message. 319 The Function Set specified in a message can contain a collection of 320 resources of the same subtype. The Function Set path postfixed with 321 an identifier refers to the individual resources of the collection. 322 For example: the /path/light points to the resource collection of the 323 service subtype light. Each member of the collection can be 324 identified with /path/light/x, with x in {1,2,3,..}. Consequently, 325 the /path/light/1/onoff specifies the onoff resource of collection 326 member 1 of Function Set with /path/light, and /path/light/onoff 327 specifies the resource onoff of all collection members contained by 328 the Function Set with /path/light. When /path/light/onoff is used in 329 a multicast message, it is interpreted as a message to a single light 330 resource by devices having only one, and to all members of the 331 collection for devices having several light resources. 333 In [I-D.shelby-core-interfaces] the Batch interface is used to 334 manipulate a collection of subresources with one message. Both the 335 batch and the collection are static. The collection contains 336 homogeneous resources where the batch can contain heterogeneous 337 resources. 339 It is expected that SDOs will standardize resource types, profiles 340 (path names) and group naming conventions. Manufacturers design the 341 functions supported by a device and select the Profiles, resources 342 and collections. Each manufacturer can precede the profile path 343 names with a manufacturer defined path prefix; for example when a 344 device supports multiple standards. Domain name, device name, group 345 name and group members are installation dependent. 347 Figure 1 illustrates some of the concepts described above. A device 348 is identified with the name "Power-strip". In the example, no domain 349 names are associated with the device, and the name "power-strip" 350 resolves to a Unique Local Address (ULA)[RFC4193]. The device 351 provides two end-points: one delivers a http service and the second a 352 CoAP service. The http server and CoAP server share the same IP- 353 address and use different ports 80 and 61616 respectively. Two 354 different service subtypes, one identified by Function Set, ps, and 355 one identified by Function Set, pm, are supported by one end-point. 356 The Function Set "Power strip" contains a collection of four 357 resources, "Outlet 1" to "Outlet 4", each one accessible via the 358 accompanying paths /ps/1 to ps/4. The path /ps interfaces to the 359 entire resource collection. The attribute "output" is defined in the 360 service subtype specification. 362 +-------------------------------------------------------------------+ 363 | "Power-strip" | 364 | [device] has at least one NIC/IP address, may have a name | 365 | | 366 | +---------------------------------------------------------------+ | 367 | | "HTTP server" | | 368 | | [End-point] http://power-strip (at default TCP port 80) | | 369 | +---------------------------------------------------------------+ | 370 | | 371 | +---------------------------------------------------------------+ | 372 | | "CoAP server" | | 373 | | [End-point] coap://power-strip (at default UDP port 61616) | | 374 | | | | 375 | | +-----------------------------------------------------------+ | | 376 | | | "Power Meter" | | | 377 | | | [Function Set] coap://power-strip/pm | | | 378 | | +-----------------------------------------------------------+ | | 379 | | | | 380 | | +-----------------------------------------------------------+ | | 381 | | | "Power strip" | | | 382 | | | [Function Set] coap://power-strip/ps | | | 383 | | | | | | 384 | | | +-------------------------------------------------------+ | | | 385 | | | | "Outlet 1" | | | | 386 | | | | [Collection member] coap://power-strip/ps/1 | | | | 387 | | | | [resource] coap://power-strip/ps/1/output | | | | 388 | | | | ... | | | | 389 | | | +-------------------------------------------------------+ | | | 390 | | | | | | 391 | | | +-------------------------------------------------------+ | | | 392 | | | | "Outlet 2" | | | | 393 | | | | [Collection member] coap://power-strip/ps/2 | | | | 394 | | | +-------------------------------------------------------+ | | | 395 | | | | | | 396 | | | +-------------------------------------------------------+ | | | 397 | | | | "Outlet 3" | | | | 398 | | | | [Collection member] coap://power-strip/ps/3 | | | | 399 | | | +-------------------------------------------------------+ | | | 400 | | | | | | 401 | | | +-------------------------------------------------------+ | | | 402 | | | | "Outlet 4" | | | | 403 | | | | [Collection member] coap://power-strip/ps/4 | | | | 404 | | | +-------------------------------------------------------+ | | | 405 | | +-----------------------------------------------------------+ | | 406 | +---------------------------------------------------------------+ | 407 +-------------------------------------------------------------------+ 409 Figure 1: device with end-points, Function Sets and resources 411 3.5. Discovery queries 413 The following conditions are assumed to be valid. A device has 414 acquired an IP address and a name, possibly stored in DNS. The 415 resource naming (path) in the device obeys a standardized profile. 416 The resource types of the Function Sets are also standardardized. A 417 device may belong to a domain. 419 Service discovery should support that a device can learn its 420 domain(s) and all the end-points within a domain providing a given 421 service (e.g. temperature measurement). The device learns of these 422 end-points the path name that prefixes the path names defined by the 423 profile. Devices need to learn the groups to which they belong and 424 learn all the members of those groups. This section motivates that a 425 discovery service supports the following queries: 427 Goal Description 428 Name_resolution Resolve the group or device name to IP address and 429 optional port number 430 Return_server Return all end-points (Function-Sets) supporting a 431 given service (sub-)type within a given domain 432 Create_group Create a group of end-points providing a given 433 service (sub-)type within a given domain 434 Enroll_member Enroll an end-point as member of a given group 435 Remove_member Remove an end-point as member of a given group 436 Return_group Return all groups of which a given end-point (device) 437 is a member 438 Return_member Return end-points belonging to a given group 440 Name_resolution is supported by DNS and CoAP resource discovery. 441 Names are required in the context of home control and manual setup of 442 installations. Names are persistent and meaningful as compared to IP 443 addresses and are preferably used in applications when IP addresses 444 can change. 446 Return_server is the most common use of service discovery and was 447 originally designed for interactive use. The canonical IT example is 448 finding all printers within a zone, which allows a user to select the 449 desired printer from the returned list. Another example is in the 450 context of UPnP [UPNP], where all media players are returned on a 451 screen and the user can select the desired media player on the screen 452 and play the selected content. In M2M applications, the returned 453 names are not displayed on a screen but an application uses the 454 returned list to select a (set of) Function Set(s) to control. 455 Consequently, names in M2M applications need not be human 456 interpretable (for example, they can be unique numbers). 458 Create_group is useful in commissioning scenarios, where end-points 459 need to be grouped to receive the same command in a possibly 460 synchronous fashion. Groups can also be created to express relations 461 between devices such as ownership. The command creates a group name 462 and creates a list of the members of the group. When the group is a 463 multicast group, the command defines a unique multicast address and 464 port, and specifies the path. 466 Enroll_member supports network and device reconfiguration. When the 467 physical lay-out of an installation changes because devices are 468 added, changed or removed, the associated groups also need to be 469 modified. 471 Remove_member, see motivation under Enroll_member 473 Return_group is needed to learn the groups of which an end-point is 474 member. The command is necessary for commissioning purposes where a 475 Commissioning Tool (CT) is used. The CT, on the basis of designs 476 provided by architects, decorators, sound/light engineers, defines 477 groups and group members and stores that information in the service 478 discovery database. In the next phase, the members of a group may 479 need to learn their membership from the service discovery to enable 480 reception of multicast messages. 482 Return_member can be used to learn which end-points are member of a 483 given group. This command is useful in connection with Return_group. 484 The end-point knowing to which groups it belongs can establish 485 communication with the group members. For example, membership of a 486 group instructs new devices, replacing faulty ones, which other 487 devices share access rights or need to be consulted regularly. 489 3.6. Sleeping devices 491 This section suggests that service discovery of sleeping devices is 492 mostly a matter of discovering the proxy. It is expected that a 493 proxy will handle communications for the sleeping device, as 494 expressed in [I-D.giacomin-core-sleepy-option] and in 495 [I-D.vial-core-mirror-proxy]. The message sent to the sleeping 496 device is directed to the proxy. The proxy will send the message on 497 with a delay, or send the result of a function on the history of 498 messages, when the sleeping device is ready. Different communication 499 protocols between proxy and sleeping device are described in 500 [I-D.giacomin-core-sleepy-option] and in 501 [I-D.vial-core-mirror-proxy]. The setting up of the proxy is 502 preferably standardized for a large set of proxy types. During the 503 setting-up process, (offline or online) the proxy will take over all 504 the entry-points of the sleeping device. The entry-points of the 505 proxy can be entered into the discovery respository and consequently 506 discovered like any other device. 508 For groups, two cases need to be considered (1) sleeping device is 509 member of a group and receives group messages, and (2) the sleeping 510 device sends messages to a group. Ad (1), when the sleeping device 511 needs to receive messages sent to a group, the proxy will receive 512 those messages and the end-point of the proxy is entered as group 513 member to receive the group messages. Ad (2) When the sleeping 514 device sends messages to a group, it is preferable that the sleeping 515 device sends just one multicast message to the group to minimize 516 energy costs. It is required that when one member of the group 517 receives the message, all other group members receive it as well 518 (unanimity), covered by the "reliability" REQ1 in 519 [I-D.ietf-core-groupcomm]). A simple broadcast over a lowpan will 520 not always succceed and additional multicast algorithms like Trickle 521 [RFC6206] need to be introduced. 523 4. DNS and RD examples 525 The following device configuration and environment are assumed for 526 the examples. The devices are placed on floor-x (fx) in two rooms 527 room-y (ry) and room-z (rz). Both rooms contain a powerstrip with a 528 powermeter and four power outlets. In each room there are two 529 luminaires and one presence sensor (PIR). Each luminaire contains a 530 dimmable light and a light sensor. Per floor there is a clock to set 531 day and night time modes of the devices. The domains are: 532 ry.fx.bldg.org, rz.fx.bldg.org and fx.bldg.org. The device names of 533 the 4 luminaires are lm00203, lm00204, lm00205, and lm00206. The 534 device names of the two powerstrips are ps0057, and ps0078. The 535 paths of the Function Sets of the luminaire are: /lamp with resource 536 /lamp/dim for the dimmable light, and /light with resource /light/ 537 lumen for the light sensor. The Function Set path for four outlets 538 is /ps with resource /ps/output. The path of each individual outlet 539 is /ps/x with x in {1,2,3,4}, and with resource ps/x/output. The 540 names of the two PIRs are pir0 and pir1. The Function Set path of 541 the PIR is /occup, also being the resource. 543 Relating location to the domain name is a relevant example of domain 544 naming. Multiple domain names, related to other application aspects, 545 can be specified and applied simultaneously. 547 As described in section 3, devices do not announce themselves to the 548 discovery repository, as is usual for IT applications, but they are 549 entered (partially) with the aid of a central tool, for example a 550 Remote Control, dedicated device, IPAD or other means. 552 The examples are constructed such that DNS can be used as repository 553 for the RD. 555 4.1. DNS-SD examples 557 4.1.1. Basic Concepts 559 In conformance with [I-D.cheshire-dnsext-dns-sd], DNS-based discovery 560 uses A or AAAA, PTR, SRV, and TXT Resource Records (RR). The SRV RR 561 [RFC2782] specifies an end-point. An associated (identically named) 562 TXT RR can contain a URI path. The SRV/TXT pair can specify a 563 Function Set. An A or AAAA RR [RFC1035] binds a device name or 564 multicast group name to an IP address. The PTR RR binds a service 565 type to an end-point or Function Sets. 567 In cases where the end-point port may be dynamic, e.g. in the IPHC 568 [RFC6282] compressible range, a new 'coap+srv' scheme is proposed 569 (after [I-D.jennings-http-srv]). The authority part of a coap+srv 570 URI specifies the name and location of an SRV record, which in turn 571 contains values for device (IP address) and port. 573 4.1.2. Commissioning devices 575 Commissioning is the process to store the relation between a FQDN and 576 a device. It is assumed that either a Remote Control (RC) in the 577 home or a Commissioning Tool (CT) in the professional domain store 578 the relation in DNS. 580 In the professional domain, the CT is assumed to contain information 581 about the devices as prescibed by architect or installation company. 582 The information in the CT contains device name, device domain name, 583 and location in the building, but the relation with the installed 584 device, identified with an unique identifier (e.g. EUI-64) is not 585 established. By reading a bar code (or pushing buttons, switching 586 on/off equipment, etc.), the CT learns the unique identifier of the 587 device to be commissioned. All kinds of techniques can be used to 588 establish the relation between IP address and unique identifier. 589 When the identifier is the EUI-64 value, the IP address of the device 590 can be constructed. When the identifier is not the EUI-64, a 591 proprietary procol can be used to ask a given device its identifier. 592 Etc. etc. The CT can learn the end-points (services) available on 593 the device by querying /.well-known/core. In some cases the CT 594 already obtained the end-points from a configuration file. Given 595 these data, the CT can enter the devices and its services into DNS. 596 Either automatically, or on instructions of an operator, the CT 597 defines the groups in the DNS. 599 The home domain is different from the professional domain in the 600 sense that no configuration information exists. The RC can for 601 example use xmDNS to learn the addresses of all the devices present 602 in its site. The RC can query devices for the presence of a given 603 service. The RC can query DNS for its own domain name and use that 604 for the other devices in the site. Once (new) devices are named, 605 this information can be stored in DNS for use in the network. 607 4.1.3. device examples 609 The relation between device name and IP address is expressed for the 610 example devices in the following table. 612 lm00203.ry.fx.bldg.org. IN AAAA fdfd::1234 613 lm00204.ry.fx.bldg.org. IN AAAA fdfd::1235 614 ps0057.ry.fx.bldg.org. IN AAAA fdfd::1236 615 pir1.ry.fx.bldg.org. IN AAAA fdfd::1237 616 lm00205.rz.fx.bldg.org. IN AAAA fdfd::1238 617 lm00206.rz.fx.bldg.org. IN AAAA fdfd::1239 618 ps0058.rz.fx.bldg.org. IN AAAA fdfd::1240 619 pir2.rz.fx.bldg.org. IN AAAA fdfd::1241 620 clock.fx.bldg.org. IN AAAA fdfd::1242 622 The next part defines the Resource Records to specify the end-points 623 and their Function Sets. The names of the SRV RRs need to be unique 624 to the DNS server, and follow the naming suggested in 625 [I-D.cheshire-dnsext-dns-sd]. An end-point is represented with one 626 SRV RR with a name "_service.domain". A Function-Set is represented 627 with a SRV/TXT pair with name "subtype._sub._service.domain". 629 The service type "_bc._udp" is assumed to exist with the service 630 subtypes "lamp", "sensor", "power", "presence", and "timer". Unique 631 names of the SRV RRs can be created from the service subtype prefixed 632 by the EUI-64 value. With EUI-64 value "1234" the SRV name 633 1234_bc._udp.domain can be created for the corresponding end-point. 634 Given that the service _bc._udp supports subtype lamp the name 635 1234lamp._sub._bc._udp.domain is created for for each SRV/TXT pair 636 describing a Function-Set serving the lamp subtype. They are valid 637 within the authority zone, bldg.org, of the name server. For 638 presentation purposes, 1234_bc is short for 1234_bc._udp.bldg.org, 639 1234lamp is short for 1234lamp._sub._bc._udp.bldg.org, etc. The 640 luminaires with name "lm00xxx" provide each one end-point hosting two 641 Function Sets with the paths /lamp and /light. 643 end-point host name 644 1234_bc IN SRV 0 0 Port lm00203.ry.fx.bldg.org 645 IN TXT txtvers=1 646 2345_bc IN SRV 0 0 Port lm00204.ry.fx.bldg.org 647 IN TXT txtvers=1 648 3456_bc IN SRV 0 0 Port lm00205.rz.fx.bldg.org 649 IN TXT txtvers=1 650 4567_bc IN SRV 0 0 Port lm00206.rz.fx.bldg.org 651 IN TXT txtvers=1 652 5678_bc IN SRV 0 0 Port ps0057.ry.fx.bldg.org 653 IN TXT txtvers=1 654 6789_bc IN SRV 0 0 Port ps0058.rz.fx.bldg.org 655 IN TXT txtvers=1 656 7890_bc IN SRV 0 0 Port pir1.ry.fx.bldg.org 657 IN TXT txtvers=1 658 8901_bc IN SRV 0 0 Port pir2.rz.fx.bldg.org 659 IN TXT txtvers=1 660 9012_bc IN SRV 0 0 Port clock.fx.bldg.org 661 IN TXT txtvers=1 663 The above list of SRV RRs specifies the attributes of the end-points: 664 devices, port numbers, and IP addresses with related AAAA RR. The 665 Function Sets are specified with a another set of SRV/TXT pairs. The 666 accompanying TXT RR specify the paths of the associated Function 667 Set(s). The accompanying example table is: 669 Function Set host name 670 1234lamp IN SRV 0 0 Port lm00203.ry.fx.bldg.org 671 IN TXT txtvers=1 path=/lamp 672 1234sensor IN SRV 0 0 Port lm00203.ry.fx.bldg.org 673 IN TXT txtvers=1 path=/light 674 2345lamp IN SRV 0 0 Port lm00204.ry.fx.bldg.org 675 IN TXT txtvers=1 path=/lamp 676 2345sensor IN SRV 0 0 Port lm00204.ry.fx.bldg.org 677 IN TXT txtvers=1 path=/light 678 5678power IN SRV 0 0 Port ps0057.ry.fx.bldg.org 679 IN TXT txtvers=1 path=/ps 680 7890presence IN SRV 0 0 Port pir1.ry.fx.bldg.org 681 IN TXT txtvers=1 path=/occup 682 3456lamp IN SRV 0 0 Port lm00205.rz.fx.bldg.org 683 IN TXT txtvers=1 path=/lamp 684 3456sensor IN SRV 0 0 Port lm00205.rz.fx.bldg.org 685 IN TXT txtvers=1 path=/light 686 4567lamp IN SRV 0 0 Port lm00206.rz.fx.bldg.org 687 IN TXT txtvers=1 path=/lamp 688 4567sensor IN SRV 0 0 Port lm00206.rz.fx.bldg.org 689 IN TXT txtvers=1 path=/light 690 6789power IN SRV 0 0 Port ps0058.rz.fx.bldg.org 691 IN TXT txtvers=1 path=/ps 692 8901presence IN SRV 0 0 Port pir2.rz.fx.bldg.org 693 IN TXT txtvers=1 path=/occup 694 9012timer IN SRV 0 0 Port clock.fx.bldg.org 695 IN TXT txtvers=1 path=/time 697 The names of the SRV records can be created automatically, as long as 698 they identify the SRV records uniquely within the set of RR entries 699 in the DNS zone. The SRV record with name xxxxpower stands for a 700 power collection, accessed via the path /ps which refers to a 701 Function Set that contains a collection of two or more resources. 703 PTR records specify the possible service discovery queries. The 704 names of the PTR records are the names of the service (sub)types, 705 defined by IANA, and their values refer to the names of the 706 associated end-points (SRV records) or Function-Sets (SRV/TXT 707 records). To support the query "all lamps within fx.bldg.org", the 708 following PTR records need to be added for service subtype: 709 lamp._sub._bc._udp. 711 lamp._sub._bc._udp.bldg.org IN PTR 1234lamp 712 lamp._sub._bc._udp.bldg.org IN PTR 2345lamp 713 lamp._sub._bc._udp.bldg.org IN PTR 3456lamp 714 lamp._sub._bc._udp.bldg.org IN PTR 4567lamp 716 Where xxxxlamp is still short for xxxxlamp._sub._bc._udp.bldg.org. 718 Equally to query all services within a domain, PTR records with as 719 name the building control service, "_bc.udp", refer to all SRV 720 records describing all discoverable end-points. 722 _bc._udp.bldg.org IN PTR 1234_bc._udp.bldg.org 723 _bc._udp.bldg.org IN PTR 2345_bc._udp.bldg.org 724 _bc._udp.bldg.org IN PTR 3456_bc._udp.bldg.org 725 _bc._udp.bldg.org IN PTR 4567_bc._udp.bldg.org 726 _bc._udp.bldg.org IN PTR 5678_bc._udp.bldg.org 727 _bc._udp.bldg.org IN PTR etc, etc. 729 It is shown above how PTR records support the queries filtered on 730 service type. Filtering on domain can be done adding additional PTR 731 records which select the Function Sets of a given type within a given 732 domain. The set of PTR records below filters on all lamps within 733 domain ry.fx.bldg.org. 735 lamp._sub._bc._udp.ry.fx.bldg.org. IN PTR 1234lamp 736 lamp._sub._bc._udp.ry.fx.bldg.org. IN PTR 2345lamp 738 4.1.4. Group examples 740 As an example, five multicast-groups are defined to group all lamps 741 on floor "fx", all lamps in office "ry", all lamps in office "rz", 742 all power-strips on floor "fx", and all devices in the building 743 controlled by a central timer. The multicast-group names are entered 744 into DNS like the device names to enable resolution from multicast- 745 group name to multicast address. 747 lamp-fx.fx.bldg.org. IN AAAA ff15::11 748 lamp-ry.ry.fx.bldg.org. IN AAAA ff15::12 749 lamp-rz.rz.fx.bldg.org. IN AAAA ff15::13 750 power-fx.fx.bldg.org. IN AAAA ff15::14 751 timer-bldg.bldg.org. IN AAAA ff15::15 753 It is expected that SDOs will specify naming conventions for group 754 names, extending the service (sub)type names for end-points and 755 Function Sets. 757 The path and port of the multicast-groups is defined with SRV and TXT 758 RRs. Accordingly the group is bound to end-points (SRV RR) and 759 Function Sets (SRV+TXT RR). For convenience we assume that a 760 multicast group is bound to a service subtype. In the example below 761 the groups concern the service subtypes "lamp", "power", and "timer". 762 (Remark gp1-lamp is short for gp1-lamp._sub._bc._udp.bldg.org, etc.) 763 gp1-lamp IN SRV 0 0 Port lamp-fx.fx.bldg.org. 764 IN TXT path=/lamp 765 gp2-lamp IN SRV 0 0 Port lamp-ry.ry.fx.bldg.org. 766 IN TXT path=/lamp 767 gp3-lamp IN SRV 0 0 Port lamp-rz.rz.fx.bldg.org. 768 IN TXT path=/lamp 769 gp-power IN SRV 0 0 Port power-fx.fx.bldg.org. 770 IN TXT path=/ps 771 gp-timer IN SRV 0 0 Port timer-bldg.bldg.org. 772 IN TXT path=/time 774 The groups for the power strips need extra attention because the 775 power strips include a collection of resources. The path to the 776 group can be defined as /ps or as /ps/x with x in {1,2,3,4}. When 777 using /ps/x the group contains the outlet x of the power strips. 778 Using the path /ps as done in the table above refers to all outlets 779 of a powerstrip. When sending a message to the power-fx group with 780 as path /ps/x then the message will be received by Function Sets with 781 path ps/x only. 783 The members of the groups can be stored in DNS by using the reverse 784 DNS resolution technique. It is not unusual that a given IP address 785 refers to multiple FQDNs. Extrapolating to group names extends the 786 reverse DNS resolution in a natural manner. Below the members of 787 group lamp-fx.fx.bldg.org with IP address ff15::11 containing all 788 four lamps is shown. 790 1.1.0.....0.5.1.f.f.IP6.arpa. IN PTR lm00206.rz.fx.bldg.org. 791 1.1.0.....0.5.1.f.f.IP6.arpa. IN PTR lm00205.rz.fx.bldg.org. 792 1.1.0.....0.5.1.f.f.IP6.arpa. IN PTR lm00204.ry.fx.bldg.org. 793 1.1.0.....0.5.1.f.f.IP6.arpa. IN PTR lm00203.ry.fx.bldg.org. 794 1.1.0.....0.5.1.f.f.IP6.arpa. IN PTR lamp-fx.fx.bldg.org. 796 With the above table queries like "return all members of lamp-fx" can 797 be answered. 799 Additional tables are needed to specify the multicast groups to which 800 the end-point of a device belongs. A PTR RR with the name of the 801 Function Set can refer to the name of the group. In the table below 802 the Function Set "1234lamp" is member of the groups "lamp-fx" and 803 "lamp-ry": 805 1234lamp IN PTR lamp-fx.fx.bldg.org 806 1234lamp IN PTR lamp-ry.ry.fx.bldg.org 808 Consequently, a device can query DNS for the groups to which its 809 Function Set belongs, and consecutively enable the reception of the 810 associated multicast messages. 812 4.1.5. Discovery validation 814 This section describes how the disovery requirements are met with 815 DNS-SD. It is assumed that the DNS server tables are correctly 816 filled in. 818 Name_resolution: Group- or device-name is resolved to IP address by 819 sending a query to DNS to return all AAAA records with the given 820 name. 822 Return_server: Suppose the given service is defined by 823 instance._sub._service.domain. All Function Sets supporting this 824 service in the domain are found by sending a query to DNS to return 825 all PTR records with the name instance._sub._service.domain. The 826 returned PTR records refer to the names of the SRV/TXT pairs 827 describing the port, FQDN and path of the associated Function Sets. 828 Additional queries return all SRV and TXT records with the names 829 returned by the first query. To query the end-points a query is sent 830 to return all PTR records with name service.domain. 832 Create-Group: Groups are created by creating resource records in DNS 833 as described in section 4.1.4. The filing of the DNS server tables 834 is done by a trusted Remote Control or commissioning Device (see 835 section 4.1.2). Section 6.1 discusses the security aspects. 837 Enroll-member, Remove-member: See Create-Group. 839 Return-Group: Suppose the given Function Set is given by the name 840 instance._sub._bc._service.domain. All groups to which this Function 841 Set belongs are found by sending a query to DNS to return all PTR 842 records with the name instance._sub._bc._service.domain. The 843 returned PTR records refer to the names of the associated groups. 844 Name resolution provides the IP address. 846 Return-member: The members of a group with name group group.domain 847 are found by resolving the group name to an IP address. The members 848 of the group are obtained by sending a query to DNS to return all PTR 849 records with as the name the inverted IP-address. The PRT records 850 refer to the names of the associated devices. 852 4.2. RD examples 854 Resource discovery in CoAP handles resource paths (called links) for 855 the resources hosted on the server, augmented with attributes of 856 these resources. A well-known path "/.well-known/core" [RFC5785] is 857 a default Function Set for requesting the list of links on a given 858 server [I-D.shelby-core-resource-directory]. The Resource Directory 859 (RD) stores links to resources hosted by other servers. The link- 860 format [I-D.ietf-core-link-format] defines link extensions to specify 861 the service type and end-point as used by DNS-SD. When querying the 862 Resource Directory for links, filters can be applied to return only 863 links with specified attribute values. A node learns the IP-address 864 of the RD by for example sending a multicast request to a predefined 865 multicast address registered with IANA, or by assuming that the RD is 866 located in the edge router. 868 Contrary to DNS-SD, the RD has not defined a process which permits 869 SDOs to specify service (sub)types. Consequently, the same service 870 type examples are used for DNS-SD as for RD, where service type 871 postfixed with subtype (DNS) equals "resource type" (RD). The "host" 872 name of DNS is used as "end-point" name for RD. 874 This draft adheres to the mapping between DNS and link-format, 875 described in [I-D.lynn-core-discovery-mapping]. 877 4.2.1. Commissioning devices 879 It is assumed that either a Remote Control (RC) in the home or a 880 Commissioning Tool (CT) in the professional domain is used to fill in 881 the RD. Devices cannot enter links into the RD contrary to the 882 suggestion in [I-D.shelby-core-resource-directory]. Both the RC or 883 the CT have to fill in the RD, because at link creation the RD 884 generates a location of the link-entry (e.g. /ed/453), that is 885 returned to the creator of the link. Consequently, the CT or the RD 886 need to create the link, because they need the location to update the 887 link with additional information. 889 In the professional domain, the CT learns the identity of the device 890 as described earlier, reads the services of the devices with a GET to 891 /.well-known/core on the device, and stores them into the RD. 893 In the home domain, the RC can read in the EUI-64 of the device to be 894 entered. The user types in domain names and device names on the RC. 895 Consecutively, the RC follows the same procedure as the CT. 897 4.2.2. Device examples 899 For convenience, it is assumed that DNS contains the mapping from 900 FQDN to IP address with AAAA RRs and vice-versa with PTR RRs. In all 901 examples the FQDN is used and not the IP-address. It is assumed that 902 the service type "_bc" has the subtypes: "lamp", "sensor", "power", 903 "presence", and "timer". Registration is done with the following 904 statements by CT or RC to the RD with authority: //rd.example.com/ 905 and path /rd. Each POST command to the RD defines an end-point in 906 the URI and defines the corresponding Function Sets in the payload. 908 POST coap://rd.example.com/rd?ep=lm00203;d=ry.fx.bldg.org 909 Etag: 0x21 910 Payload: 911 ;rt="lamp._sub._bc", 912 ;rt="sensor._sub._bc" 913 Res: 2.01 created 914 Location: /rd/1234 916 The other end-points are defined with (leaving out the response): 918 POST coap://rd.example.com/rd?ep=lm00204;d=ry.fx.bldg.org 919 Payload: 920 ;rt="lamp._sub._bc", 921 ;rt="sensor._sub._bc" 923 POST coap://rd.example.com/rd?ep=lm00205;d=rz.fx.bldg.org 924 Payload: 925 ;rt="lamp._sub._bc", 926 ;rt="sensor._sub._bc" 928 POST coap://rd.example.com/rd?ep=lm00206;d=rz.fx.bldg.org 929 Payload: 930 ;rt="lamp._sub._bc", 931 ;rt="sensor._sub._bc" 932 POST coap://rd.example.com/rd?ep=ps0057;d=ry.fx.bldg.org 933 Payload: 934 ;rt="power._sub._bc", 935 ;rt="power._sub._bc", 936 ;rt="power._sub._bc", 937 ;rt="power._sub._bc", 938 ;rt="power._sub._bc" 940 POST coap://rd.example.com/rd?ep=ps0058;d=rz.fx.bldg.org 941 Payload: 942 ;rt="power._sub._bc", 943 ;rt="power._sub._bc", 944 ;rt="power._sub._bc", 945 ;rt="power._sub._bc", 946 ;rt="power._sub._bc" 948 POST coap://rd.example.com/rd?ep=pir1;d=ry.fx.bldg.org 949 Payload: 950 ;rt="presence._sub._bc" 952 POST coap://rd.example.com/rd?ep=pir2;d=rz.fx.bldg.org 953 Payload: 954 ;rt="presence._sub._bc" 956 POST coap://rd.example.com/rd?ep=clock;d=fx.bldg.org 957 Payload: 958 ;rt="timer._sub._bc" 960 Update or removal of the groups is done by using the returned 961 location (not shown above) as described in 962 [I-D.shelby-core-resource-directory] for the end-points. 964 4.2.3. Group examples 966 The same five multicast groups of the DNS example are used. The 967 group name to address mapping is specified in DNS with AAAA RRs. The 968 group name is not easily identified with an end-point. Therefore the 969 mnemonic gp is added as link-format attribute. The group members are 970 included by citing the end-point names, which allows a unique 971 identification of the members. In all examples the group name is 972 used and not the IP-address. Registration is done with the following 973 statements by CT or RC to the RD with authority: /rd.example.com/ and 974 path /rd, leaving out Etag:, Res:, and Location: lines. The group 975 name is defined in the URI, while all the members (end-points) are 976 specified in the payload. The path in the payload defines together 977 with the end-point the Function Set. 979 POST coap://rd.example.com/rd?gp=lamp-fx;d=fx.bldg.org 980 Payload: 981 ;rt="lamp._sub._bc";ep=lm00206, 982 ;rt="lamp._sub._bc";ep=lm00205, 983 ;rt="lamp._sub._bc";ep=lm00204, 984 ;rt="lamp._sub._bc";ep=lm00203 986 POST coap://rd.example.com/rd?gp=lamp-ry;d=ry.fx.bldg.org 987 Payload: 988 ;rt="lamp._sub._bc";ep=lm00204, 989 ;rt="lamp._sub._bc";ep=lm00203 991 POST coap://rd.example.com/rd?gp=lamp-rz;d=rz.fx.bldg.org 992 Payload: 993 ;rt="lamp._sub._bc";ep=lm00206, 994 ;rt="lamp._sub._bc";ep=lm00205 996 POST coap://rd.example.com/rd?gp=power-fx;d=fx.bldg.org 997 Payload: 998 ;rt="power._sub._bc";ep=ps0057, 999 ;rt="power._sub._bc";ep=ps0058 1001 POST coap://rd.example.com/rd?gp=timer-bldg;d=bldg.org 1002 Payload: 1003 ;rt="timer._sub._bc";ep=clock 1005 With the above statements the groups are defined in the RD. 1007 4.2.4. Discovery validation 1009 This section describes how the disovery requirements are met with the 1010 RD. It is assumed that the RD tables are correctly filled in. 1012 Name_resolution: When LoWPAN is connected to backbone, it is assumed 1013 that DNS is used for name resolution. When LoWPAN is stand-alone 1014 without DNS server, IP addresses are used to connect to an interface. 1016 Return_server: Suppose the given service is defined by 1017 instance._sub._service. The query 1019 GET coap://rd.example.com/rd-lookup/res?rt=instance. 1020 _sub._service 1021 Res: 2.05 content 1022 ;rt="instance._sub._service" 1024 returns all Function Sets providing the specified service. By 1025 changing the "res?" part in the query by "ep?" all end-points are 1026 returned. 1028 Create-Group: Groups are created by sending POST commands to RD as 1029 described in section 4.2.2. The filling of the RD server tables is 1030 done by a trusted Remote Control or commissioning Device (see section 1031 4.2.1). Section 6.1 discusses the security aspects. 1033 Enroll-member, Remove-member: See Create-Group. 1035 Return-Group: Suppose the given end-point is given by the name 1036 ep.domain. All groups to which this end-point belongs are found by 1037 sending a query 1039 GET coap://rd.example.com/rd-lookup/gp?ep=ep.domain 1040 Res: 2.05 content 1041 ;gp="group.domain" 1043 returns all groups of which the specified end-point, ep.domain, is a 1044 member. 1046 Return-member: The members of a group with name group group.domain 1047 are found by the query 1049 GET coap://rd.example.com/rd-lookup/ep?gp=group.domain 1050 Res: 2.05 content 1051 ;ep="ep.domain" 1053 which returns all end-points which are member of the group gp.domain. 1055 5. IANA Considerations 1057 This document makes no request of IANA. 1059 Note to RFC Editor: this section may be removed on publication as an 1060 RFC. 1062 6. Security Considerations 1064 Security considerations apply to use of DNS and RD separately, 1065 because they use different security mechanisms. 1067 6.1. DNS Security considerations 1069 Security extensions for DNS are provided by Domain Name System 1070 Security Extensions (DNSSEC) as described in [RFC4033], [RFC4034], 1071 and [RFC4035]. In particular [RFC4033] describes all documents 1072 relevant to DNSSEC. The central design decision of DNSSEC is to 1073 provide origin authentication and integrity protection for DNS data. 1075 All transported DNS data are freely accessible. Consequently, all 1076 correctly functioning nodes will receive the domain and group names 1077 to which they belong, and will receive the addresses of the multicast 1078 and unicast destinations, and the multicast address of the groups to 1079 which they belong. Accordingly, commands will be sent to the 1080 intended destinations and accepted by the intended destinations. All 1081 resolvers MUST be configured with a security anchor. The anchor can 1082 be stored non-volatile memory or be provided by other out-of-band 1083 means. 1085 Updating of DNS data, e.g,. zone data MUST be done using the secure 1086 dynamic updates mechanism. For example, a commissioning device is 1087 used to fill in the DNS server. Both the device sending the update 1088 requests (i.e., the commissioning device) and the DNS Server MUST 1089 share a Transaction Signature (TSIG) key [RFC2845]. The TSIG key is 1090 a symmetric-key and it can be generated using the dnssec-keygen 1091 primitive. The TSIG key is then used to sign the DNS update message, 1092 thus ensuring the authenticity of the request. An access control 1093 list can be defined in the DNS to authorize updates to the DNS data. 1094 The Berkeley Internet Name Daemon (BIND) implementation of the 1095 Internet System Consortium (ISC) provides a mechanism to specify 1096 access control lists, ensuring that updates of DNS zone data can only 1097 be performed by authorized parties. The allow-update option in a 1098 zone statement is used to control access to a zone. This option 1099 grants clients with a particular TSIG key the permission to update 1100 any record of any name in the zone. To allow for finer-granular 1101 access control, the update-policy option can be used within a zone 1102 statement, it specifies a set of rules where each rule either grants 1103 or denies permissions to one or more names to be updated by one or 1104 more identities. The identity can be determined based on the TSIG 1105 key in the TSIG record. 1107 In the home and also during construction in the professional case, 1108 islands of security exist when the authorative DNS server has no 1109 connection to parent or children zones. In a later stage, access can 1110 be provided via DNS root servers involving a second security anchor. 1111 Alternatively, stub resolvers access contact recursive name servers 1112 via an secure channel as SIG(0) [RFC2931] or TSIG [RFC2845]. 1114 In spite of using DNSSEC, rogue devices can obtain valid addresses 1115 and accept commands for these destinations. This is not worse than 1116 rogue devices accepting any packet via a NIC in promiscuous mode. 1117 Rogue devices can send unwanted commands to the thus observed IP 1118 address. The same addresses can also be obtained by listening to the 1119 network traffic. 1121 6.2. RD Security considerations 1123 Security for Resource Direcory is provided by recommended CoAP 1124 security techniques: DTLS. 1126 7. Acknowledgments 1128 Zach Shelby wrote the original Discovery section in 1129 [I-D.ietf-core-coap] which forms the basis for this draft. This I-D 1130 has benefited from conversations with and comments from Emmanuel 1131 Frimout, Michael Verschoor, Jamie Mc Cormack, Esko Dijk, Dee 1132 Denteneer, Joop Talstra, Jerald Martocci, Matthieu Vial, Jerome 1133 Hamel, George Yianni, and Nicolas Riou. 1135 Sye Loong Keoh, Sandeep Kumar, and Oscar Garcia Morchon contributed 1136 actively to security considerations. 1138 8. Changelog 1140 Changes from -02 to -03: 1141 o adapted to resource direcory version -03 1142 o DNS-SD examples follow better DNS-SD naming conventions 1143 o added gp= link-format attribute 1144 o added security considerations 1145 o groups of end-points and groups of Function Sets instead of groups 1146 of devices 1147 o less centered around DNS, more RD aspects 1149 9. References 1151 9.1. Normative References 1153 [RFC1035] Mockapetris, P., "Domain names - implementation and 1154 specification", STD 13, RFC 1035, November 1987. 1156 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1157 Requirement Levels", BCP 14, RFC 2119, March 1997. 1159 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 1160 specifying the location of services (DNS SRV)", RFC 2782, 1161 February 2000. 1163 [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D., and B. 1164 Wellington, "Secret Key Transaction Authentication for DNS 1165 (TSIG)", RFC 2845, May 2000. 1167 [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures ( 1168 SIG(0)s)", RFC 2931, September 2000. 1170 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1171 Resource Identifier (URI): Generic Syntax", STD 66, 1172 RFC 3986, January 2005. 1174 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1175 Rose, "DNS Security Introduction and Requirements", 1176 RFC 4033, March 2005. 1178 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1179 Rose, "Resource Records for the DNS Security Extensions", 1180 RFC 4034, March 2005. 1182 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1183 Rose, "Protocol Modifications for the DNS Security 1184 Extensions", RFC 4035, March 2005. 1186 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 1187 Addresses", RFC 4193, October 2005. 1189 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1190 Architecture", RFC 4291, February 2006. 1192 [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, 1193 "Internet Group Management Protocol (IGMP) / Multicast 1194 Listener Discovery (MLD)-Based Multicast Forwarding 1195 ("IGMP/MLD Proxying")", RFC 4605, August 2006. 1197 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 1198 "Transmission of IPv6 Packets over IEEE 802.15.4 1199 Networks", RFC 4944, September 2007. 1201 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1202 Specifications: ABNF", STD 68, RFC 5234, January 2008. 1204 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known 1205 Uniform Resource Identifiers (URIs)", RFC 5785, 1206 April 2010. 1208 [RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010. 1210 [RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6 1211 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 1212 September 2011. 1214 [RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko, 1215 "The Trickle Algorithm", RFC 6206, March 2011. 1217 9.2. Informative References 1219 [I-D.cheshire-dnsext-dns-sd] 1220 Cheshire, S. and M. Krochmal, "DNS-Based Service 1221 Discovery", draft-cheshire-dnsext-dns-sd-11 (work in 1222 progress), December 2011. 1224 [I-D.eggert-core-congestion-control] 1225 Eggert, L., "Congestion Control for the Constrained 1226 Application Protocol (CoAP)", 1227 draft-eggert-core-congestion-control-01 (work in 1228 progress), January 2011. 1230 [I-D.ietf-6man-uri-zoneid] 1231 Carpenter, B. and R. Hinden, "Representing IPv6 Zone 1232 Identifiers in Uniform Resource Identifiers", 1233 draft-ietf-6man-uri-zoneid-01 (work in progress), 1234 May 2012. 1236 [I-D.ietf-core-coap] 1237 Shelby, Z., Hartke, K., Bormann, C., and B. Frank, 1238 "Constrained Application Protocol (CoAP)", 1239 draft-ietf-core-coap-10 (work in progress), June 2012. 1241 [I-D.ietf-core-groupcomm] 1242 Rahman, A. and E. Dijk, "Group Communication for CoAP", 1243 draft-ietf-core-groupcomm-01 (work in progress), 1244 March 2012. 1246 [I-D.ietf-core-link-format] 1247 Shelby, Z., "CoRE Link Format", 1248 draft-ietf-core-link-format-14 (work in progress), 1249 June 2012. 1251 [I-D.lynn-core-discovery-mapping] 1252 Lynn, K. and Z. Shelby, "CoRE Link-Format to DNS-Based 1253 Service Discovery Mapping", 1254 draft-lynn-core-discovery-mapping-01 (work in progress), 1255 July 2011. 1257 [I-D.lynn-homenet-site-mdns] 1258 Lynn, K. and D. Sturek, "Extended Multicast DNS", 1259 draft-lynn-homenet-site-mdns-00 (work in progress), 1260 March 2012. 1262 [I-D.shelby-core-coap-req] 1263 Shelby, Z., Stuber, M., Sturek, D., Frank, B., and R. 1264 Kelsey, "CoAP Requirements and Features", 1265 draft-shelby-core-coap-req-02 (work in progress), 1266 October 2010. 1268 [I-D.shelby-core-interfaces] 1269 Shelby, Z. and M. Vial, "CoRE Interfaces", 1270 draft-shelby-core-interfaces-02 (work in progress), 1271 March 2012. 1273 [I-D.shelby-core-resource-directory] 1274 Shelby, Z. and S. Krco, "CoRE Resource Directory", 1275 draft-shelby-core-resource-directory-03 (work in 1276 progress), May 2012. 1278 [I-D.vanderstok-core-bc] 1279 Stok, P. and K. Lynn, "CoAP Utilization for Building 1280 Control", draft-vanderstok-core-bc-05 (work in progress), 1281 October 2011. 1283 [I-D.jennings-http-srv] 1284 Jennings, C., "DNS SRV Records for HTTP", 1285 draft-jennings-http-srv-05 (work in progress), March 2009. 1287 [I-D.giacomin-core-sleepy-option] 1288 Fossati, T., Giacomin, P., Loreto, S., and M. Rossini, 1289 "Sleepy Option for CoAP", 1290 draft-giacomin-core-sleepy-option-00 (work in progress), 1291 February 2012. 1293 [I-D.vial-core-mirror-proxy] 1294 Vial, M., "CoRE Mirror Proxy", 1295 draft-vial-core-mirror-proxy-00 (work in progress), 1296 March 2012. 1298 [ZeroConf] 1299 Cheshire, S. and D. Steinberg, "Zero Configuration 1300 Networking: The Definitive Guide", O'Reilly Media, Inc. , 1301 ISBN 0-596-10100-7, 2006. 1303 [UPNP] "Universal Plug and Play", Web http://www.upnp.org, 2012. 1305 Authors' Addresses 1307 Peter van der Stok (editor) 1308 vanderstok consultancy 1309 Kamperfoelie 8 1310 Helmond, 5708 DM 1311 The Netherlands 1313 Email: consultancy@vanderstok.org 1315 Kerry Lynn 1316 Consultant 1318 Phone: +1-978-460-4253 1319 Email: kerlyn@ieee.org 1321 Anders Brandt 1322 Sigma Designs 1323 Emdrupvej 26A, 1. 1324 Copenhagen O, 2100 1325 Denmark 1327 Email: Anders_Brandt@sigmadesigns.com