dnssd P. van der Stok Internet-Draft consultant Intended status: Informational K. Lynn Expires: April 20, 2014 Consultant October 17, 2013 Building control requirements draft-vanderstok-dnssd-building-requirements-00 Abstract The draft describes an interface to the discovery of services on a bounded network segment from a building control perspective. Building control has special boundary conditions related to: (1) management of devices and services, (2) an installation involving stand-alone networks (3) (dis)connecting network (from) to Internet without renaming services and devices. Roaming devices are not considered in this version. Note Discussion and suggestions for improvement are requested, and should be sent to dnssd@ietf.org. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 20, 2014. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. van der Stok & Lynn Expires April 20, 2014 [Page 1] Internet-Draft BC-req October 2013 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. Identification of services . . . . . . . . . . . . . . . . . 3 3. Network . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Naming conventions . . . . . . . . . . . . . . . . . . . . . 6 4.1. Host name . . . . . . . . . . . . . . . . . . . . . . . . 6 4.2. Service name . . . . . . . . . . . . . . . . . . . . . . 8 4.3. Discovery scope . . . . . . . . . . . . . . . . . . . . . 8 5. Installation procedures . . . . . . . . . . . . . . . . . . . 9 5.1. Managed Installation . . . . . . . . . . . . . . . . . . 10 5.2. Plug-and-play Installation . . . . . . . . . . . . . . . 11 5.3. Group declaration . . . . . . . . . . . . . . . . . . . . 11 5.4. Binding . . . . . . . . . . . . . . . . . . . . . . . . . 12 5.5. Device naming . . . . . . . . . . . . . . . . . . . . . . 12 6. Service discovery requirements . . . . . . . . . . . . . . . 13 6.1. Mapping to requirements I-D . . . . . . . . . . . . . . . 14 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 10.1. Normative References . . . . . . . . . . . . . . . . . . 15 10.2. Informative References . . . . . . . . . . . . . . . . . 15 Appendix A. RR for service discovery . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 1. Introduction The DNS-SD working group aims at service discovery without operator intervention on multi-link networks. The discovery of the services is restricted to a multi-link network segment of which the limits may be determined automatically. In building control stable relations between application and server need to be created such that applications can communicate with servers during the lifetime of the installation without changes to the application code. Applications discover named service instances van der Stok & Lynn Expires April 20, 2014 [Page 2] Internet-Draft BC-req October 2013 on named devices connected to a network segment. At the start of its lifetime the network segment is not connected to Internet and its services. Before connection, after connection to Internet and during consecutive dis-/re-connections, the applications should be able to use the same names for devices and service instances. At installation time the applications bind to the services that they want to use; e.g. a lighting application binds to the light sensor server. The location of the service is leading in selecting the required service instance from an offer of identical services. The supporting installation process leads to a number of requirements on the multi-link discovery. These requirements are expressed at the application level to a discovery interface which may hide the names which are actually transported over the network. The service discovery is assumed to make use of DNS-Based service discovery [RFC6763]. This document complements the DNSSD requirements document [I-D.lynn-mdnsext-requirements]. 1.1. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. This specification requires readers to be familiar with all the terms and concepts that are discussed in [RFC6763]. In addition, this specification makes use of the following terminology: Network segment: A network of interconnected devices. The network may be composed of one link or multiple heterogeneous wired and wireless links interconnected by routers. Stand-alone segment: a network segment that has no access or connection to Internet and its services, e.g. DNS service, DHCP service. Connected segment: a network segment that is connected with one or more border routers to Internet. TODO: other terms to be specified. 2. Identification of services van der Stok & Lynn Expires April 20, 2014 [Page 3] Internet-Draft BC-req October 2013 Devices providing a given service need to be identified and addressed, such that an application in another device can use the service instance hosted by the selected device. The physical location or other visual aspects of the device are often important for the service instance selection. Two layers of communication can be distinguished: (1) the application communicating with the service instance, and (2) the messages exchanged between (ports, IP-addresses) over the network. Identifiers of the first layer need to be stable, while identifiers of the second layer can evolve. Devices are connected to the network via one or more interfaces. On the network, the interfaces can be addressed by an IP address. The IP address comes with a scope. Often, the link-local IP address is constructed from the MAC address (full or short)[RFC4862], [RFC6775]. A global IP address can be constructed from the long MAC address and a prefix provided by a border router. On the other hand a global IP address can be allocated by the IP provider via DHCP. This latter IP address bears no relation at all to the MAC address. The IP address can change at any moment during the operational life of the device. The applications make use of services. For inter-operability reasons services and their service type are standardized. The service type has the same life-time as the standard that defines it. In this way an application can find the service instance hosted by candidate devices. Applications refer to a service instance on a given device identified with a host name. The host name, used by the client application, should remain stable during the life-time of the device and beyond. When a device fails, the application continues to use the same host name to minimize interventions on the network at device failure. The new replacing device keeps the same host name but has a new MAC address and IP address. From the stable service type the client application selects a service instance with a host name and path. From the stable service instance name and host name the client application can find the currently valid IP address and port number. For control purposes devices are grouped. For example a set of lights need to be turned off/on or dimmed simultaneously. A group is identified with a group name with has the same purpose and format as the host name. An IP multicast address or a set of IP unicast addresses can be associated with a group name. van der Stok & Lynn Expires April 20, 2014 [Page 4] Internet-Draft BC-req October 2013 The identifiers of Table 1 need to be considered when looking at the binding of a client application to a service instance: +-------------------------+---------------------------------+ | Identifier | Lifetime determined by | +-------------------------+---------------------------------+ | Global IP address | IP provider decision | | | | | Link-local IP address | MAC address lifetime | | | | | Host name | Installation lifetime | | | | | Service instance name | Installation lifetime | | | | | Service type | service defining SDO existence | | | | | Group name | Installation lifetime | +-------------------------+---------------------------------+ Table 1 During installation and commissioning of the devices, the host name and hosted service instance need to be related to each other and to the IP addresses and port number. 3. Network For this specification we distinguish the logical network and the network segment. A "logical network" is composed of "named" devices hosting "named" service-instances which provide "named" services to applications. A network segment, defined in Section 1.1, provides IP addresses and ports. The "logical network" is implemented with a network segment, which can be: o A wireless mesh network with wireless IP routers o single link without IP routers o network segment containing several IP routers interconnecting meshes and single links but without IP border router. o Any of the three networks above with one or more border routers connecting the network segment to Internet. van der Stok & Lynn Expires April 20, 2014 [Page 5] Internet-Draft BC-req October 2013 The installation process knows several phases: Physical connections: Devices are unpacked, and installed at their location and connected to the mains (if appropriate) and connected to the network segment. Logical connections: Devices are connected to the "logical network" and receive a host name such that the mapping: host name to IP address is established. Grouping: Groups are defined. Binding: Client applications bind to service instances (group of service instances) and the application is operational. During installation, applications start operational life on a evolving "logical network". During and after installation, the network segment goes through any sequence of the stages "Stand-alone", and "Connected". The limits of the "logical network" are defined as a function of the two network segment states: 1. All the devices connected to the stand-alone segment. 2. Border routers on the connected segment which delimit the boundaries of the "logical network". Once the network segment is connected, the logical network represents a zone in DNS terms. 4. Naming conventions In this and following sections design decisions are formulated to define the context in which the requirements can be made concrete. 4.1. Host name Choosing an existing naming format limits the possibilities but also helps to profit from existing and proven techniques. Design decision 1: host names use the naming scheme established for DNS. This decision implies that the host name is composed of sequences of characters delimited by dots. Accordingly, the host name can reflect the hierarchical structure that is used for its identification within the installation (topological or organizational). The structure's van der Stok & Lynn Expires April 20, 2014 [Page 6] Internet-Draft BC-req October 2013 use is explained in Section 4.3. The prefix of the host name is the name of the single unconnected device given during installation. The device name can be post-fixed with the installation structure. The latter can be post-fixed with its DNS domain name. For example, the host name can look like: host name scope Device1 within the stand-alone network with a flat name structure. Device1.floor1.bldg3 within the stand-alone network with a hierarchical name structure. Device1.floor1.bldg3.example.com. Fully Qualified Domain Name (FQDN) within the Internet connected network. The prefix device1 can have human interpretable names like TV_in_kitchen which has meaning to the occupants of a home. Within the context of automated building control, the names are most likely machine interpretable and can represent any sequence of characters, like 213_abk_0004545588, which takes its meaning from the device's technical or organizational details, at the same time making the name unique within the installation. This specification uses the naming convention name.ld.gd., where ld represents a "local domain" possibly with a structure like floor1.bldg3, and gd represents the "global domain" name supported by DNS like: example.com. The dots separating domain names in "global domain" are recognized by DNS for the definition of zones. The dots separating names in the "local domain" name are not seen by DNS but provide a consistent hierarchical naming convention. Its example use for service discovery is shown in Appendix A. Design decision 2: Host and service instance names with a local scope are suffixed with global domain names to global scope. The handling of roaming devices is out of scope of this requrement specification. This is analogous to the scoping of telephone numbers. For example, within a small village all occupants can be reached by dialling a 6 digit number. Dialling nationally outside the village area necessitates a larger number, and the local 6-digit number is prefixed with the national area code. International access necessitates an international prefix code. This numbering policy has van der Stok & Lynn Expires April 20, 2014 [Page 7] Internet-Draft BC-req October 2013 a proven track record and conforms to a mental picture shared by a large majority of people. Accordingly, applications use the names with the gd extension when access to services outside the local scope is needed. This approach has one large advantage: Applications on devices connected to a "logical network" use names without global domain suffix for binding to servers on that network segment independent of the segment state (connected or stand-alone). 4.2. Service name A device can host servers. The server provides a service instance. Design decision 3: The name of the service instance follows the Instance.Service.Domain format defined in [RFC6763]. Where the "Service" part is composed of a name reserved by IANA for a given SDO. For example, the name _bc._udp (following [RFC2782]) can be used for the example building control service, where bc is (hypothetically) reserved by IANA. A service can be composed of subtypes (e.g. light) prefixed to the service type, resulting in: light._sub._bc._udp. The "Instance" part can be the host name prefix, or the UID of the device. It is possible that there are multiple servers for a given device (e.g. multiple lights controlled by a device). In that case the service instance identifier must be extended to distinguish the service instances providing identical services on the same device. The "Domain" part is composed of "ld.gd" as specified in Section 4.1. Similar to the host name, the service instance identifiers are known within the "logical network" without the "gd" suffix. 4.3. Discovery scope Names of hosts and service instances are locally unique when they are unique within the "logical network". Names used as input to queries can include the suffixes "ld" and "gd". When a name includes the "gd" suffix the "ld" suffix MUST be included as well. It should be noted that there is no 1-1 mapping from domain hierarchy to network segment topology. Given the hierarchy of Section 4.1, all devices of floor 1 to floor n can be connected to one switched ethernet segment. The lights in one floor (even one office) can be connected to different powerline segments. van der Stok & Lynn Expires April 20, 2014 [Page 8] Internet-Draft BC-req October 2013 The following rules SHOULD apply and be enforced by the service discovery service: 1. Names with the "gd" suffix are globally unique and are consequently locally unique. 2. Names with a "ld" suffix but without "gd" suffix are locally unique. 3. Names without "ld" suffix can be locally unique 4. Non-unique names without "ld" suffix should be locally unique with an appropriate "ld" suffix. It is required that the underlying service discovery service guarantees the uniqueness of the names when they are declared to the network. The local domain suffix is useful to group devices which are related. For example the location of the device can be communicated in the local domain name as proposed in Section 4.1. An application that wants to discover all light services in a given office, off3, queries all devices which provide service, light._sub._bc._udp, within domain off3.floor1.bldg3. Querying all devices within domain floor1.bldg3 or bldg3 returns all light services at floor 1 or within the whole building 3 respectively. The Resource Records for local service discovery are shown in Appendix A. When the global domain is example.com, the queries to floor1.bldg3 and floor1.blg3.example.com should return the same results. When in an early phase of the installation the local and the global domain names are not known, the query for light._sub._bc._udp should return all service instances present on the devices connected to the stand-alone segment. 5. Installation procedures Two types of installations can be identified: "managed" and "plug- and-play". In building control, often a tight control on device presence (and absence) and physical location is necessary to guarantee a smooth operation and maintenance. Mostly, the installation of devices for building control is "managed" accompanied by installation dependent naming guidelines. van der Stok & Lynn Expires April 20, 2014 [Page 9] Internet-Draft BC-req October 2013 In the home environment it is assumed that humans will notice absence and presence of devices visually, and names can be automatically chosen by devices, and may be changed to more personal names when experience invites users to do so. Mostly the installation for homes is "plug-and-play" without external installation dependent guidelines. The terms "managed" and "plug-and play" are used when referring to any of these two installation approaches. 5.1. Managed Installation Commissioning is the process of pairing the factory provided device identifier and the host name, and the consecutive binding of the application to service instances and groups. The factory provided device identifier can be the MAC address, used in the remainder of the text. Design decision 4: A Commissioning Tool (CT) supports the storing of the relations in DNS-SD based structures. The storage technique for DNS-SD relations should be transparent to the applications. Example storage techniques are: o Distributed memory as implemented by mDNS [RFC6762] o Hierarchic storage as implemented by DNS [RFC1035] The CT contains information about the devices as prescribed by architect or Installation Company. The information in the CT describes host name -possibly suffixed with local domain-, location in the building, and the group names with its members. Before commissioning, the relation between the host name and the MAC address is unknown. The commissioning is based on two actions: 1. The CT learns the MAC address of a given device installed at a given location by reading a bar code (or pushing buttons, switching on/off equipment, etc.). 2. The CT learns the host name by pointing at a map of the building (or selection from a list, typing in the name or any other appropriate technique). Uniqueness of the host name is assumed to be guaranteed by the installation process. In this way the CT pairs the host name with the MAC address. Assuming the CT to be connected to the "logical network", all kinds van der Stok & Lynn Expires April 20, 2014 [Page 10] Internet-Draft BC-req October 2013 of techniques can be used to establish the relation between IP address and MAC address. For example, the link-local IP address of the device can be constructed from the MAC address. Having learnt the IP address, the CT can communicate the host name to the device. The CT can learn the attributes of the services instances available on the device by querying /.well-known/core on the device. Alternatively, the CT already obtained the service instance attributes from a configuration file. Given these data, the CT can enter the host names and associated services into DNS-SD based storage structures. Either automatically, or on instructions of an operator, or much later in the commissioning process, the CT can define the groups in DNS-SD. Before commissioning, the CT has a list of group names. For each group a service type and the host names of the members are specified. With additional information about the path of the services in the device and the port number of service, the groups can be fully specified in DNS-SD. 5.2. Plug-and-play Installation The constraints on the host name and service instance name specified in Section 4.3 are assumed to be valid. The relation between the factory provided device identifier ( e.g. MAC address) and host name has to be established without any intervention by the installing person. The device is connected to the network and acquires its IP addresses (link-local, or global) according its installation characteristics (DHCP, or stateless). The device acquires a host name, either proposed by the manufacturer (for example, stored in the device at manufacturing location) or specified by the installing person. Uniqueness of the host name within the "logical network" must be ascertained by the underlying "discovery service". At the location of the device, the host name is now related to the MAC address and consequently to the IP-addresses of the device. The relation host name to IP address is published to the service discovery service. After successful publication, host name, IP address, and service instances are accessible to all other devices on the "logical network". From this moment, applications on a device can discover service instances of a specified service offered by the devices connected to the "logical network". 5.3. Group declaration van der Stok & Lynn Expires April 20, 2014 [Page 11] Internet-Draft BC-req October 2013 Group declaration is managed both in managed and plug-and play environments. The CT defines the group in the DNS-SD repository. A group has a name associated with a set of service instances. When the group is accessed with a multicast invocation, a multicast address, the port number, and a path to the service instance MUST be specified in the DNS repository. Multicast address, path, and port number are equal for all members of the group because transported in the same message to all destinations. 5.4. Binding Applications need to bind to the service instances which provide a requested service. The service is identified with a service type, and with the service type the application knows how to access the service. The application learns the service instances present at the logical network, identified by: o Path to the service instance. o Host name of the device hosting the service instance, or group name of the set of service instances. Binding can be done in mainly two ways: Managed: a third device (CT) specifies the service instance to which the given application needs to bind. Plug-and-play: the service requesting device learns the service instances of service providing devices via service discovery. The device (group) name should remain valid during the lifetime of the installation independent of the state of the "logical network". 5.5. Device naming Devices obtain their host name as function of the "managed" or the "plug-and play" mode. Managed: The CT allocates the host name from a list. The host name can be flat or hierarchical expressed in the local domain suffix, but its global domain suffix is not necessarily known at allocation time. Given that networks can disconnect from and reconnect to the Internet the device is known within its "logical network" by its host name without the global domain suffix. Plug-and-play: the device assumes a default host name given by the manufacturer. Uniqueness can be guaranteed by adding random van der Stok & Lynn Expires April 20, 2014 [Page 12] Internet-Draft BC-req October 2013 numbers when necessary. In a later stage users have the opportunity to change the host name to their liking. For the same reasons as the managed case, the device is known within its "logical network" by its host name without global domain suffix. TODO: mobility of devices is not considered. 6. Service discovery requirements Service discovery supports that an application can learn the names of service instances or group name of service instances and the names of the hosting devices. The discovery service supports the following: Name_resolution: Resolve the group name, host name to IP address; resolve service instance name to host name, port number, and path. Create_group: Create a group of end-points providing a given service Enrol_member: Enrol an end-point as member of a given group. Remove_member: Remove an end-point as member of a given group. A summary of the requirements specified in the text is presented in Table 2. The first 4 requirements are the four design decisions. +----------+-------------------------------------------+------------+ | Number | Requirement | Text | +----------+-------------------------------------------+------------+ | BC1 | Host names follow DNS format | Section | | | | 4.1 | | | | | | BC2 | Local names are suffixed for global | Section | | | uniqueness | 4.1 | | | | | | BC3 | Service instance names follow DNS-SD | Section | | | conventions | 4.2 | | | | | | BC4 | A Commissioning Tool assists managed | Section 5 | | | installation | | | | | | | BC5 | SD queries with local names return same | Section 3 | | | results for stand-alone and connected | | | | segments | | | | | | | BC6 | Limits of connected "logical network" are | Section 3 | | | defined by border routers | | | | | | | BC7 | A network segment is composed of one or | Section 3 | van der Stok & Lynn Expires April 20, 2014 [Page 13] Internet-Draft BC-req October 2013 | | several connected wired and wireless | | | | links | | | | | | | BC8 | SD service guarantees local uniqueness of | Section | | | names | 4.3 | | | | | | BC9 | The storage technology of DNS-SD | Section | | | relations is transparent to application | 5.1 | | | | | | BC10 | The SD service stores group names and | Section | | | group members | 5.3 | +----------+-------------------------------------------+------------+ Table 2 6.1. Mapping to requirements I-D The requirements of [I-D.lynn-mdnsext-requirements] are mapped to the requirements of Section 6 in Table 3. +----------------------------+-----------------+ | lynn-mdnsext-requirements | This document | +----------------------------+-----------------+ | REQ 1 | BC5, BC6, BC8 | | | | | REQ 2 | BC7, BC9 | | | | | REQ 3 | BC6, BC2 | | | | | REQ 4 | BC5 | | | | | REQ 5 | BC1, BC3 | +----------------------------+-----------------+ Table 3 The mapping of Table 3 is not one to one. BC10 is not covered by [I-D.lynn-mdnsext-requirements]. BC4 is not applicable to [I-D.lynn-mdnsext-requirements]. The requirements of [I-D.lynn-mdnsext-requirements] are requirements on the service discovery service solution, while the requirements in this specification are specified at the application level. The [I-D.lynn-mdnsext-requirements] does not address the changing states of the logical network, but mentions incremental deployment in REQ5. van der Stok & Lynn Expires April 20, 2014 [Page 14] Internet-Draft BC-req October 2013 7. Security Considerations TODO: follows DNS-SD security provisioning. 8. IANA Considerations TODO 9. Acknowledgements The draft has benefited from comments by Dee Denteneer, Esko Dijk, MIchael Verschoor, Gerhard Mekekamp, and Michael van Hartskamp. 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 10.2. Informative References [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000. [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007. [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", RFC 4944, September 2007. [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link Format", RFC 6690, August 2012. [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, February 2013. [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", RFC 6763, February 2013. van der Stok & Lynn Expires April 20, 2014 [Page 15] Internet-Draft BC-req October 2013 [RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann, "Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)", RFC 6775, November 2012. [I-D.ietf-core-coap] Shelby, Z., Hartke, K., and C. Bormann, "Constrained Application Protocol (CoAP)", draft-ietf-core-coap-18 (work in progress), June 2013. [I-D.lynn-mdnsext-requirements] Lynn, K. and S. Cheshire, "Requirements for DNS-SD/mDNS Extensions", draft-lynn-mdnsext-requirements-02 (work in progress), July 2013. Appendix A. RR for service discovery This Appendix presents a simplified example to make the use of the local domain name more concrete. The naming used here is chosen to clarify the use of the local domain names for service discovery. Suppose there are two areas area1 and area2 both containing two sensors providng a service with service type sensor._sub._bc._udp accessible via path /sns. Area1 and area2 are subdomains of floor4. The sensors are connected to different hosts with names device1 to device4. Suppose there are two devices app1 and app2 running client applications where app1 belongs to area1.floor4 and app2 belongs to floor2. App1 can discover all sensor service instances in its own domian area1.floor4 by doing a query for all PTR RR with name _sensor._sub._bc._udp.area1.floor4. App2 can discover all sensor service instances in floor4 doing a query for all PTR RR with name _sensor._sub._bc._udp.floor4. In the latter case App2 must be configured to target floor4. ; comment-- device names to IP addressses device1.area1.floor4 IN AAAA fdfd::01 device2.area1.floor4 IN AAAA fdfd::02 device3.area2.floor4 IN AAAA fdfd::03 device4.area2.floor4 IN AAAA fdfd::04 app1.area1.floor4 IN AAAA fdfd::05 app2.floor2 IN AAAA fdfd::06 ; comment-- service instances to end points ii_sensor IN SRV 0 0 61614 device1.area1.floor4 IN TXT txtver=1 path=/sns jj_sensor IN SRV 0 0 61614 device2.area1.floor4 IN TXT txtver=1 path=/sns kk_sensor IN SRV 0 0 61614 device3.area2.floor4 van der Stok & Lynn Expires April 20, 2014 [Page 16] Internet-Draft BC-req October 2013 IN TXT txtver=1 path=/sns ll_sensor IN SRV 0 0 61614 device4.area2.floor4 IN TXT txtver=1 path=/sns ; comment-- service in domain to service instances _sensor._sub._bc._udp.area1.floor4 IN PTR ii_sensor _sensor._sub._bc._udp.area1.floor4 IN PTR jj_sensor _sensor._sub._bc._udp.area2.floor4 IN PTR kk_sensor _sensor._sub._bc._udp.area2.floor4 IN PTR ll_sensor _sensor._sub._bc._udp.floor4 IN PTR ii_sensor _sensor._sub._bc._udp.floor4 IN PTR jj_sensor _sensor._sub._bc._udp.floor4 IN PTR kk_sensor _sensor._sub._bc._udp.floor4 IN PTR ll_sensor According to [RFC6763], the service instance name yy_sensor (with y in {i,j,k,l}) should be yy_sensor._sub._bc._udp.areax.floor4. In the example the shorter (and also unique) name is used for clarity reasons. The AAAA RR specify the IP addresses of the devices. The SRV RR combined with the TXT RR specify the hosting device of the service instances together with port number and path. The PTR RR specify the service instances associated with a service in a given domain. Authors' Addresses Peter van der Stok consultant Phone: +31-492474673 (Netherlands), +33-966015248 (France) Email: consultancy@vanderstok.org URI: www.vanderstok.org Kerry Lynn Consultant Phone: +1-978-460-4253 Email: kerlyn@ieee.org van der Stok & Lynn Expires April 20, 2014 [Page 17]