idnits 2.17.1 draft-vanderstok-dnssd-building-requirements-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 17, 2013) is 3837 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC4944' is defined on line 696, but no explicit reference was found in the text == Unused Reference: 'RFC6690' is defined on line 700, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-core-coap' is defined on line 714, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 dnssd P. van der Stok 3 Internet-Draft consultant 4 Intended status: Informational K. Lynn 5 Expires: April 20, 2014 Consultant 6 October 17, 2013 8 Building control requirements 9 draft-vanderstok-dnssd-building-requirements-00 11 Abstract 13 The draft describes an interface to the discovery of services on a 14 bounded network segment from a building control perspective. 15 Building control has special boundary conditions related to: (1) 16 management of devices and services, (2) an installation involving 17 stand-alone networks (3) (dis)connecting network (from) to Internet 18 without renaming services and devices. Roaming devices are not 19 considered in this version. 21 Note 23 Discussion and suggestions for improvement are requested, and should 24 be sent to dnssd@ietf.org. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on April 20, 2014. 43 Copyright Notice 45 Copyright (c) 2013 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Identification of services . . . . . . . . . . . . . . . . . 3 63 3. Network . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 4. Naming conventions . . . . . . . . . . . . . . . . . . . . . 6 65 4.1. Host name . . . . . . . . . . . . . . . . . . . . . . . . 6 66 4.2. Service name . . . . . . . . . . . . . . . . . . . . . . 8 67 4.3. Discovery scope . . . . . . . . . . . . . . . . . . . . . 8 68 5. Installation procedures . . . . . . . . . . . . . . . . . . . 9 69 5.1. Managed Installation . . . . . . . . . . . . . . . . . . 10 70 5.2. Plug-and-play Installation . . . . . . . . . . . . . . . 11 71 5.3. Group declaration . . . . . . . . . . . . . . . . . . . . 11 72 5.4. Binding . . . . . . . . . . . . . . . . . . . . . . . . . 12 73 5.5. Device naming . . . . . . . . . . . . . . . . . . . . . . 12 74 6. Service discovery requirements . . . . . . . . . . . . . . . 13 75 6.1. Mapping to requirements I-D . . . . . . . . . . . . . . . 14 76 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 77 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 78 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 79 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 80 10.1. Normative References . . . . . . . . . . . . . . . . . . 15 81 10.2. Informative References . . . . . . . . . . . . . . . . . 15 82 Appendix A. RR for service discovery . . . . . . . . . . . . . . 16 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 85 1. Introduction 87 The DNS-SD working group aims at service discovery without operator 88 intervention on multi-link networks. The discovery of the services 89 is restricted to a multi-link network segment of which the limits may 90 be determined automatically. 92 In building control stable relations between application and server 93 need to be created such that applications can communicate with 94 servers during the lifetime of the installation without changes to 95 the application code. Applications discover named service instances 96 on named devices connected to a network segment. At the start of its 97 lifetime the network segment is not connected to Internet and its 98 services. Before connection, after connection to Internet and during 99 consecutive dis-/re-connections, the applications should be able to 100 use the same names for devices and service instances. 102 At installation time the applications bind to the services that they 103 want to use; e.g. a lighting application binds to the light sensor 104 server. The location of the service is leading in selecting the 105 required service instance from an offer of identical services. The 106 supporting installation process leads to a number of requirements on 107 the multi-link discovery. These requirements are expressed at the 108 application level to a discovery interface which may hide the names 109 which are actually transported over the network. 111 The service discovery is assumed to make use of DNS-Based service 112 discovery [RFC6763]. This document complements the DNSSD 113 requirements document [I-D.lynn-mdnsext-requirements]. 115 1.1. Terminology 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 119 document are to be interpreted as described in [RFC2119]. 121 This specification requires readers to be familiar with all the terms 122 and concepts that are discussed in [RFC6763]. In addition, this 123 specification makes use of the following terminology: 125 Network segment: A network of interconnected devices. The network 126 may be composed of one link or multiple heterogeneous wired and 127 wireless links interconnected by routers. 129 Stand-alone segment: a network segment that has no access or 130 connection to Internet and its services, e.g. DNS service, DHCP 131 service. 133 Connected segment: a network segment that is connected with one or 134 more border routers to Internet. 136 TODO: other terms to be specified. 138 2. Identification of services 139 Devices providing a given service need to be identified and 140 addressed, such that an application in another device can use the 141 service instance hosted by the selected device. The physical 142 location or other visual aspects of the device are often important 143 for the service instance selection. 145 Two layers of communication can be distinguished: (1) the application 146 communicating with the service instance, and (2) the messages 147 exchanged between (ports, IP-addresses) over the network. 148 Identifiers of the first layer need to be stable, while identifiers 149 of the second layer can evolve. 151 Devices are connected to the network via one or more interfaces. On 152 the network, the interfaces can be addressed by an IP address. The 153 IP address comes with a scope. Often, the link-local IP address is 154 constructed from the MAC address (full or short)[RFC4862], [RFC6775]. 155 A global IP address can be constructed from the long MAC address and 156 a prefix provided by a border router. On the other hand a global IP 157 address can be allocated by the IP provider via DHCP. This latter IP 158 address bears no relation at all to the MAC address. The IP address 159 can change at any moment during the operational life of the device. 161 The applications make use of services. For inter-operability reasons 162 services and their service type are standardized. The service type 163 has the same life-time as the standard that defines it. In this way 164 an application can find the service instance hosted by candidate 165 devices. 167 Applications refer to a service instance on a given device identified 168 with a host name. The host name, used by the client application, 169 should remain stable during the life-time of the device and beyond. 170 When a device fails, the application continues to use the same host 171 name to minimize interventions on the network at device failure. The 172 new replacing device keeps the same host name but has a new MAC 173 address and IP address. 175 From the stable service type the client application selects a service 176 instance with a host name and path. From the stable service instance 177 name and host name the client application can find the currently 178 valid IP address and port number. 180 For control purposes devices are grouped. For example a set of 181 lights need to be turned off/on or dimmed simultaneously. A group is 182 identified with a group name with has the same purpose and format as 183 the host name. An IP multicast address or a set of IP unicast 184 addresses can be associated with a group name. 186 The identifiers of Table 1 need to be considered when looking at the 187 binding of a client application to a service instance: 189 +-------------------------+---------------------------------+ 190 | Identifier | Lifetime determined by | 191 +-------------------------+---------------------------------+ 192 | Global IP address | IP provider decision | 193 | | | 194 | Link-local IP address | MAC address lifetime | 195 | | | 196 | Host name | Installation lifetime | 197 | | | 198 | Service instance name | Installation lifetime | 199 | | | 200 | Service type | service defining SDO existence | 201 | | | 202 | Group name | Installation lifetime | 203 +-------------------------+---------------------------------+ 205 Table 1 207 During installation and commissioning of the devices, the host name 208 and hosted service instance need to be related to each other and to 209 the IP addresses and port number. 211 3. Network 213 For this specification we distinguish the logical network and the 214 network segment. 216 A "logical network" is composed of "named" devices hosting "named" 217 service-instances which provide "named" services to applications. 219 A network segment, defined in Section 1.1, provides IP addresses and 220 ports. 222 The "logical network" is implemented with a network segment, which 223 can be: 225 o A wireless mesh network with wireless IP routers 227 o single link without IP routers 229 o network segment containing several IP routers interconnecting 230 meshes and single links but without IP border router. 232 o Any of the three networks above with one or more border routers 233 connecting the network segment to Internet. 235 The installation process knows several phases: 237 Physical connections: Devices are unpacked, and installed at their 238 location and connected to the mains (if appropriate) and connected 239 to the network segment. 241 Logical connections: Devices are connected to the "logical network" 242 and receive a host name such that the mapping: host name to IP 243 address is established. 245 Grouping: Groups are defined. 247 Binding: Client applications bind to service instances (group of 248 service instances) and the application is operational. 250 During installation, applications start operational life on a 251 evolving "logical network". 253 During and after installation, the network segment goes through any 254 sequence of the stages "Stand-alone", and "Connected". The limits of 255 the "logical network" are defined as a function of the two network 256 segment states: 258 1. All the devices connected to the stand-alone segment. 260 2. Border routers on the connected segment which delimit the 261 boundaries of the "logical network". 263 Once the network segment is connected, the logical network represents 264 a zone in DNS terms. 266 4. Naming conventions 268 In this and following sections design decisions are formulated to 269 define the context in which the requirements can be made concrete. 271 4.1. Host name 273 Choosing an existing naming format limits the possibilities but also 274 helps to profit from existing and proven techniques. 276 Design decision 1: host names use the naming scheme established for 277 DNS. 279 This decision implies that the host name is composed of sequences of 280 characters delimited by dots. Accordingly, the host name can reflect 281 the hierarchical structure that is used for its identification within 282 the installation (topological or organizational). The structure's 283 use is explained in Section 4.3. The prefix of the host name is the 284 name of the single unconnected device given during installation. The 285 device name can be post-fixed with the installation structure. The 286 latter can be post-fixed with its DNS domain name. For example, the 287 host name can look like: 289 host name scope 291 Device1 within the stand-alone 292 network with a flat name 293 structure. 294 Device1.floor1.bldg3 within the stand-alone 295 network with a hierarchical 296 name structure. 297 Device1.floor1.bldg3.example.com. Fully Qualified Domain Name 298 (FQDN) within the Internet 299 connected network. 301 The prefix device1 can have human interpretable names like 302 TV_in_kitchen which has meaning to the occupants of a home. Within 303 the context of automated building control, the names are most likely 304 machine interpretable and can represent any sequence of characters, 305 like 213_abk_0004545588, which takes its meaning from the device's 306 technical or organizational details, at the same time making the name 307 unique within the installation. 309 This specification uses the naming convention name.ld.gd., where ld 310 represents a "local domain" possibly with a structure like 311 floor1.bldg3, and gd represents the "global domain" name supported by 312 DNS like: example.com. The dots separating domain names in "global 313 domain" are recognized by DNS for the definition of zones. The dots 314 separating names in the "local domain" name are not seen by DNS but 315 provide a consistent hierarchical naming convention. Its example use 316 for service discovery is shown in Appendix A. 318 Design decision 2: Host and service instance names with a local 319 scope are suffixed with global domain names to global scope. 321 The handling of roaming devices is out of scope of this requrement 322 specification. 324 This is analogous to the scoping of telephone numbers. For example, 325 within a small village all occupants can be reached by dialling a 6 326 digit number. Dialling nationally outside the village area 327 necessitates a larger number, and the local 6-digit number is 328 prefixed with the national area code. International access 329 necessitates an international prefix code. This numbering policy has 330 a proven track record and conforms to a mental picture shared by a 331 large majority of people. 333 Accordingly, applications use the names with the gd extension when 334 access to services outside the local scope is needed. This approach 335 has one large advantage: 337 Applications on devices connected to a "logical network" use names 338 without global domain suffix for binding to servers on that 339 network segment independent of the segment state (connected or 340 stand-alone). 342 4.2. Service name 344 A device can host servers. The server provides a service instance. 346 Design decision 3: The name of the service instance follows the 347 Instance.Service.Domain format defined in [RFC6763]. 349 Where the "Service" part is composed of a name reserved by IANA for a 350 given SDO. For example, the name _bc._udp (following [RFC2782]) can 351 be used for the example building control service, where bc is 352 (hypothetically) reserved by IANA. A service can be composed of 353 subtypes (e.g. light) prefixed to the service type, resulting in: 354 light._sub._bc._udp. 356 The "Instance" part can be the host name prefix, or the UID of the 357 device. It is possible that there are multiple servers for a given 358 device (e.g. multiple lights controlled by a device). In that case 359 the service instance identifier must be extended to distinguish the 360 service instances providing identical services on the same device. 362 The "Domain" part is composed of "ld.gd" as specified in Section 4.1. 363 Similar to the host name, the service instance identifiers are known 364 within the "logical network" without the "gd" suffix. 366 4.3. Discovery scope 368 Names of hosts and service instances are locally unique when they are 369 unique within the "logical network". Names used as input to queries 370 can include the suffixes "ld" and "gd". When a name includes the 371 "gd" suffix the "ld" suffix MUST be included as well. 373 It should be noted that there is no 1-1 mapping from domain hierarchy 374 to network segment topology. Given the hierarchy of Section 4.1, all 375 devices of floor 1 to floor n can be connected to one switched 376 ethernet segment. The lights in one floor (even one office) can be 377 connected to different powerline segments. 379 The following rules SHOULD apply and be enforced by the service 380 discovery service: 382 1. Names with the "gd" suffix are globally unique and are 383 consequently locally unique. 385 2. Names with a "ld" suffix but without "gd" suffix are locally 386 unique. 388 3. Names without "ld" suffix can be locally unique 390 4. Non-unique names without "ld" suffix should be locally unique 391 with an appropriate "ld" suffix. 393 It is required that the underlying service discovery service 394 guarantees the uniqueness of the names when they are declared to the 395 network. 397 The local domain suffix is useful to group devices which are related. 398 For example the location of the device can be communicated in the 399 local domain name as proposed in Section 4.1. An application that 400 wants to discover all light services in a given office, off3, queries 401 all devices which provide service, light._sub._bc._udp, within domain 402 off3.floor1.bldg3. Querying all devices within domain floor1.bldg3 403 or bldg3 returns all light services at floor 1 or within the whole 404 building 3 respectively. The Resource Records for local service 405 discovery are shown in Appendix A. 407 When the global domain is example.com, the queries to floor1.bldg3 408 and floor1.blg3.example.com should return the same results. 410 When in an early phase of the installation the local and the global 411 domain names are not known, the query for light._sub._bc._udp should 412 return all service instances present on the devices connected to the 413 stand-alone segment. 415 5. Installation procedures 417 Two types of installations can be identified: "managed" and "plug- 418 and-play". 420 In building control, often a tight control on device presence (and 421 absence) and physical location is necessary to guarantee a smooth 422 operation and maintenance. Mostly, the installation of devices for 423 building control is "managed" accompanied by installation dependent 424 naming guidelines. 426 In the home environment it is assumed that humans will notice absence 427 and presence of devices visually, and names can be automatically 428 chosen by devices, and may be changed to more personal names when 429 experience invites users to do so. Mostly the installation for homes 430 is "plug-and-play" without external installation dependent 431 guidelines. 433 The terms "managed" and "plug-and play" are used when referring to 434 any of these two installation approaches. 436 5.1. Managed Installation 438 Commissioning is the process of pairing the factory provided device 439 identifier and the host name, and the consecutive binding of the 440 application to service instances and groups. The factory provided 441 device identifier can be the MAC address, used in the remainder of 442 the text. 444 Design decision 4: A Commissioning Tool (CT) supports the storing of 445 the relations in DNS-SD based structures. 447 The storage technique for DNS-SD relations should be transparent to 448 the applications. Example storage techniques are: 450 o Distributed memory as implemented by mDNS [RFC6762] 452 o Hierarchic storage as implemented by DNS [RFC1035] 454 The CT contains information about the devices as prescribed by 455 architect or Installation Company. The information in the CT 456 describes host name -possibly suffixed with local domain-, location 457 in the building, and the group names with its members. Before 458 commissioning, the relation between the host name and the MAC address 459 is unknown. The commissioning is based on two actions: 461 1. The CT learns the MAC address of a given device installed at a 462 given location by reading a bar code (or pushing buttons, 463 switching on/off equipment, etc.). 465 2. The CT learns the host name by pointing at a map of the building 466 (or selection from a list, typing in the name or any other 467 appropriate technique). 469 Uniqueness of the host name is assumed to be guaranteed by the 470 installation process. 472 In this way the CT pairs the host name with the MAC address. 473 Assuming the CT to be connected to the "logical network", all kinds 474 of techniques can be used to establish the relation between IP 475 address and MAC address. For example, the link-local IP address of 476 the device can be constructed from the MAC address. Having learnt 477 the IP address, the CT can communicate the host name to the device. 479 The CT can learn the attributes of the services instances available 480 on the device by querying /.well-known/core on the device. 481 Alternatively, the CT already obtained the service instance 482 attributes from a configuration file. Given these data, the CT can 483 enter the host names and associated services into DNS-SD based 484 storage structures. 486 Either automatically, or on instructions of an operator, or much 487 later in the commissioning process, the CT can define the groups in 488 DNS-SD. Before commissioning, the CT has a list of group names. For 489 each group a service type and the host names of the members are 490 specified. With additional information about the path of the 491 services in the device and the port number of service, the groups can 492 be fully specified in DNS-SD. 494 5.2. Plug-and-play Installation 496 The constraints on the host name and service instance name specified 497 in Section 4.3 are assumed to be valid. 499 The relation between the factory provided device identifier ( e.g. 500 MAC address) and host name has to be established without any 501 intervention by the installing person. The device is connected to 502 the network and acquires its IP addresses (link-local, or global) 503 according its installation characteristics (DHCP, or stateless). The 504 device acquires a host name, either proposed by the manufacturer (for 505 example, stored in the device at manufacturing location) or specified 506 by the installing person. Uniqueness of the host name within the 507 "logical network" must be ascertained by the underlying "discovery 508 service". At the location of the device, the host name is now 509 related to the MAC address and consequently to the IP-addresses of 510 the device. The relation host name to IP address is published to the 511 service discovery service. After successful publication, host name, 512 IP address, and service instances are accessible to all other devices 513 on the "logical network". 515 From this moment, applications on a device can discover service 516 instances of a specified service offered by the devices connected to 517 the "logical network". 519 5.3. Group declaration 520 Group declaration is managed both in managed and plug-and play 521 environments. The CT defines the group in the DNS-SD repository. 523 A group has a name associated with a set of service instances. When 524 the group is accessed with a multicast invocation, a multicast 525 address, the port number, and a path to the service instance MUST be 526 specified in the DNS repository. Multicast address, path, and port 527 number are equal for all members of the group because transported in 528 the same message to all destinations. 530 5.4. Binding 532 Applications need to bind to the service instances which provide a 533 requested service. The service is identified with a service type, 534 and with the service type the application knows how to access the 535 service. The application learns the service instances present at the 536 logical network, identified by: 538 o Path to the service instance. 540 o Host name of the device hosting the service instance, or group 541 name of the set of service instances. 543 Binding can be done in mainly two ways: 545 Managed: a third device (CT) specifies the service instance to which 546 the given application needs to bind. 548 Plug-and-play: the service requesting device learns the service 549 instances of service providing devices via service discovery. 551 The device (group) name should remain valid during the lifetime of 552 the installation independent of the state of the "logical network". 554 5.5. Device naming 556 Devices obtain their host name as function of the "managed" or the 557 "plug-and play" mode. 559 Managed: The CT allocates the host name from a list. The host name 560 can be flat or hierarchical expressed in the local domain suffix, 561 but its global domain suffix is not necessarily known at 562 allocation time. Given that networks can disconnect from and 563 reconnect to the Internet the device is known within its "logical 564 network" by its host name without the global domain suffix. 566 Plug-and-play: the device assumes a default host name given by the 567 manufacturer. Uniqueness can be guaranteed by adding random 568 numbers when necessary. In a later stage users have the 569 opportunity to change the host name to their liking. For the same 570 reasons as the managed case, the device is known within its 571 "logical network" by its host name without global domain suffix. 573 TODO: mobility of devices is not considered. 575 6. Service discovery requirements 577 Service discovery supports that an application can learn the names of 578 service instances or group name of service instances and the names of 579 the hosting devices. The discovery service supports the following: 581 Name_resolution: Resolve the group name, host name to IP address; 582 resolve service instance name to host name, port number, and path. 584 Create_group: Create a group of end-points providing a given service 586 Enrol_member: Enrol an end-point as member of a given group. 588 Remove_member: Remove an end-point as member of a given group. 590 A summary of the requirements specified in the text is presented in 591 Table 2. The first 4 requirements are the four design decisions. 593 +----------+-------------------------------------------+------------+ 594 | Number | Requirement | Text | 595 +----------+-------------------------------------------+------------+ 596 | BC1 | Host names follow DNS format | Section | 597 | | | 4.1 | 598 | | | | 599 | BC2 | Local names are suffixed for global | Section | 600 | | uniqueness | 4.1 | 601 | | | | 602 | BC3 | Service instance names follow DNS-SD | Section | 603 | | conventions | 4.2 | 604 | | | | 605 | BC4 | A Commissioning Tool assists managed | Section 5 | 606 | | installation | | 607 | | | | 608 | BC5 | SD queries with local names return same | Section 3 | 609 | | results for stand-alone and connected | | 610 | | segments | | 611 | | | | 612 | BC6 | Limits of connected "logical network" are | Section 3 | 613 | | defined by border routers | | 614 | | | | 615 | BC7 | A network segment is composed of one or | Section 3 | 616 | | several connected wired and wireless | | 617 | | links | | 618 | | | | 619 | BC8 | SD service guarantees local uniqueness of | Section | 620 | | names | 4.3 | 621 | | | | 622 | BC9 | The storage technology of DNS-SD | Section | 623 | | relations is transparent to application | 5.1 | 624 | | | | 625 | BC10 | The SD service stores group names and | Section | 626 | | group members | 5.3 | 627 +----------+-------------------------------------------+------------+ 629 Table 2 631 6.1. Mapping to requirements I-D 633 The requirements of [I-D.lynn-mdnsext-requirements] are mapped to the 634 requirements of Section 6 in Table 3. 636 +----------------------------+-----------------+ 637 | lynn-mdnsext-requirements | This document | 638 +----------------------------+-----------------+ 639 | REQ 1 | BC5, BC6, BC8 | 640 | | | 641 | REQ 2 | BC7, BC9 | 642 | | | 643 | REQ 3 | BC6, BC2 | 644 | | | 645 | REQ 4 | BC5 | 646 | | | 647 | REQ 5 | BC1, BC3 | 648 +----------------------------+-----------------+ 650 Table 3 652 The mapping of Table 3 is not one to one. BC10 is not covered by 653 [I-D.lynn-mdnsext-requirements]. BC4 is not applicable to 654 [I-D.lynn-mdnsext-requirements]. 656 The requirements of [I-D.lynn-mdnsext-requirements] are requirements 657 on the service discovery service solution, while the requirements in 658 this specification are specified at the application level. 660 The [I-D.lynn-mdnsext-requirements] does not address the changing 661 states of the logical network, but mentions incremental deployment in 662 REQ5. 664 7. Security Considerations 666 TODO: follows DNS-SD security provisioning. 668 8. IANA Considerations 670 TODO 672 9. Acknowledgements 674 The draft has benefited from comments by Dee Denteneer, Esko Dijk, 675 MIchael Verschoor, Gerhard Mekekamp, and Michael van Hartskamp. 677 10. References 679 10.1. Normative References 681 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 682 Requirement Levels", BCP 14, RFC 2119, March 1997. 684 10.2. Informative References 686 [RFC1035] Mockapetris, P., "Domain names - implementation and 687 specification", STD 13, RFC 1035, November 1987. 689 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 690 specifying the location of services (DNS SRV)", RFC 2782, 691 February 2000. 693 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 694 Address Autoconfiguration", RFC 4862, September 2007. 696 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 697 "Transmission of IPv6 Packets over IEEE 802.15.4 698 Networks", RFC 4944, September 2007. 700 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 701 Format", RFC 6690, August 2012. 703 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 704 February 2013. 706 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 707 Discovery", RFC 6763, February 2013. 709 [RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann, 710 "Neighbor Discovery Optimization for IPv6 over Low-Power 711 Wireless Personal Area Networks (6LoWPANs)", RFC 6775, 712 November 2012. 714 [I-D.ietf-core-coap] 715 Shelby, Z., Hartke, K., and C. Bormann, "Constrained 716 Application Protocol (CoAP)", draft-ietf-core-coap-18 717 (work in progress), June 2013. 719 [I-D.lynn-mdnsext-requirements] 720 Lynn, K. and S. Cheshire, "Requirements for DNS-SD/mDNS 721 Extensions", draft-lynn-mdnsext-requirements-02 (work in 722 progress), July 2013. 724 Appendix A. RR for service discovery 726 This Appendix presents a simplified example to make the use of the 727 local domain name more concrete. The naming used here is chosen to 728 clarify the use of the local domain names for service discovery. 730 Suppose there are two areas area1 and area2 both containing two 731 sensors providng a service with service type sensor._sub._bc._udp 732 accessible via path /sns. Area1 and area2 are subdomains of floor4. 733 The sensors are connected to different hosts with names device1 to 734 device4. Suppose there are two devices app1 and app2 running client 735 applications where app1 belongs to area1.floor4 and app2 belongs to 736 floor2. App1 can discover all sensor service instances in its own 737 domian area1.floor4 by doing a query for all PTR RR with name 738 _sensor._sub._bc._udp.area1.floor4. App2 can discover all sensor 739 service instances in floor4 doing a query for all PTR RR with name 740 _sensor._sub._bc._udp.floor4. In the latter case App2 must be 741 configured to target floor4. 743 ; comment-- device names to IP addressses 744 device1.area1.floor4 IN AAAA fdfd::01 745 device2.area1.floor4 IN AAAA fdfd::02 746 device3.area2.floor4 IN AAAA fdfd::03 747 device4.area2.floor4 IN AAAA fdfd::04 748 app1.area1.floor4 IN AAAA fdfd::05 749 app2.floor2 IN AAAA fdfd::06 751 ; comment-- service instances to end points 752 ii_sensor IN SRV 0 0 61614 device1.area1.floor4 753 IN TXT txtver=1 path=/sns 754 jj_sensor IN SRV 0 0 61614 device2.area1.floor4 755 IN TXT txtver=1 path=/sns 756 kk_sensor IN SRV 0 0 61614 device3.area2.floor4 757 IN TXT txtver=1 path=/sns 758 ll_sensor IN SRV 0 0 61614 device4.area2.floor4 759 IN TXT txtver=1 path=/sns 761 ; comment-- service in domain to service instances 762 _sensor._sub._bc._udp.area1.floor4 IN PTR ii_sensor 763 _sensor._sub._bc._udp.area1.floor4 IN PTR jj_sensor 764 _sensor._sub._bc._udp.area2.floor4 IN PTR kk_sensor 765 _sensor._sub._bc._udp.area2.floor4 IN PTR ll_sensor 767 _sensor._sub._bc._udp.floor4 IN PTR ii_sensor 768 _sensor._sub._bc._udp.floor4 IN PTR jj_sensor 769 _sensor._sub._bc._udp.floor4 IN PTR kk_sensor 770 _sensor._sub._bc._udp.floor4 IN PTR ll_sensor 772 According to [RFC6763], the service instance name yy_sensor (with y 773 in {i,j,k,l}) should be yy_sensor._sub._bc._udp.areax.floor4. In the 774 example the shorter (and also unique) name is used for clarity 775 reasons. 777 The AAAA RR specify the IP addresses of the devices. The SRV RR 778 combined with the TXT RR specify the hosting device of the service 779 instances together with port number and path. The PTR RR specify the 780 service instances associated with a service in a given domain. 782 Authors' Addresses 784 Peter van der Stok 785 consultant 787 Phone: +31-492474673 (Netherlands), +33-966015248 (France) 788 Email: consultancy@vanderstok.org 789 URI: www.vanderstok.org 791 Kerry Lynn 792 Consultant 794 Phone: +1-978-460-4253 795 Email: kerlyn@ieee.org