One document matched: draft-vanderstok-core-dna-02.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC1035 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1035.xml">
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2782 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2782.xml">
<!ENTITY RFC2845 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2845.xml">
<!ENTITY RFC2931 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2931.xml">
<!ENTITY RFC3986 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3986.xml">
<!ENTITY RFC4033 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4033.xml">
<!ENTITY RFC4034 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4034.xml">
<!ENTITY RFC4035 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4035.xml">
<!ENTITY RFC4193 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4193.xml">
<!ENTITY RFC4291 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4291.xml">
<!ENTITY RFC4605 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4605.xml">
<!ENTITY RFC4944 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4944.xml">
<!ENTITY RFC5234 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5234.xml">
<!ENTITY RFC5785 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5785.xml">
<!ENTITY RFC5988 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5988.xml">
<!ENTITY RFC6282 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6282.xml">
<!ENTITY RFC6206 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6206.xml">
<!ENTITY I-D.cheshire-dnsext-dns-sd SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.cheshire-dnsext-dns-sd.xml">
<!ENTITY I-D.eggert-core-congestion-control SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.eggert-core-congestion-control.xml">
<!ENTITY I-D.ietf-6man-uri-zoneid SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-6man-uri-zoneid.xml">
<!ENTITY I-D.ietf-core-coap SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-core-coap.xml">
<!ENTITY I-D.shelby-core-coap-req SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.shelby-core-coap-req.xml">
<!ENTITY I-D.ietf-core-link-format SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-core-link-format.xml">
<!ENTITY I-D.shelby-core-resource-directory SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.shelby-core-resource-directory.xml">
<!ENTITY I-D.vanderstok-core-bc SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.vanderstok-core-bc.xml">
<!ENTITY I-D.lynn-core-discovery-mapping SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.lynn-core-discovery-mapping.xml">
<!ENTITY I-D.lynn-homenet-site-mdns SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.lynn-homenet-site-mdns.xml">
<!ENTITY I-D.ietf-core-groupcomm SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-core-groupcomm.xml">
<!ENTITY I-D.shelby-core-interfaces SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.shelby-core-interfaces.xml">
<!ENTITY I-D.jennings-http-srv SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.jennings-http-srv.xml">
<!ENTITY I-D.vial-core-mirror-proxy SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.vial-core-mirror-proxy.xml">
<!ENTITY I-D.giacomin-core-sleepy-option SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.giacomin-core-sleepy-option.xml">
]>
<!-- Use with the following tips & tools:
http://xml.resource.org/authoring/draft-mrose-writing-rfcs.html
http://xml.resource.org/
http://fenron.net/~fenner/ietf/xml2rfc-valid/
http://tools.ietf.org/rfcdiff
-->
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.35) -->
<!-- give errors regarding ID-nits and DTD validation -->
<?rfc strict="yes"?>
<!-- control the table of contents (ToC) -->
<!-- generate a ToC -->
<?rfc toc="yes"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<?rfc tocdepth="2"?>
<!-- control references -->
<!-- use anchors instead of numbers for refs, i.e, [RFC2119] instead of [1] -->
<?rfc symrefs="yes"?>
<!-- sort the reference entries alphabetically -->
<?rfc sortrefs="no" ?>
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<!-- do not start each main section on a new page -->
<?rfc compact="yes" ?>
<!-- "no" to keep one blank line between list items (rfced) -->
<?rfc subcompact="yes" ?>
<!-- encourage use of "xml2rfc" tool -->
<?rfc rfcprocack="yes" ?>
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" ipr="trust200902" docName="draft-vanderstok-core-dna-02">
<front>
<title abbrev="CoRE Discovery, Naming, and Addressing"> CoRE Discovery, Naming, and Addressing </title>
<author initials="P.D.V." surname="van der Stok" fullname="Peter van der Stok" role="editor">
<organization abbrev="vanderstok consultancy">vanderstok consultancy</organization>
<address>
<postal>
<street>Kamperfoelie 8</street>
<city>Helmond</city><region></region><code>5708 DM</code>
<country>The Netherlands</country>
</postal>
<email>consultancy@vanderstok.org</email>
</address>
</author>
<author fullname="Kerry Lynn" initials="K.E." surname="Lynn">
<organization> Consultant </organization>
<address>
<phone> +1-978-460-4253 </phone>
<email> kerlyn@ieee.org </email>
</address>
</author>
<author initials="A." surname="Brandt" fullname="Anders Brandt">
<organization abbrev="Sigma Designs">Sigma Designs</organization>
<address>
<postal>
<street>Emdrupvej 26A, 1.</street>
<city>Copenhagen O</city><region></region><code>2100</code>
<country>Denmark</country>
</postal>
<email>Anders_Brandt@sigmadesigns.com</email>
</address>
</author>
<date day="10" month="July" year="2012"/>
<area> Applications </area>
<workgroup> CoRE </workgroup>
<abstract>
<t>
This is a working document intended to focus discussion and refine
draft language for the CoAP protocol specification (or other proposed
standards) in the areas of discovery, naming, and addressing.
Requirements on discovery are motivated. Special emphasis
is placed on group definition and discovery. Examples show how
groups can be represented in CoAP Resource Directories or DNS-SD.
</t>
</abstract>
<!--
<note title="Requirements Language">
<t>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 <xref target="RFC2119">RFC 2119</xref>.
</t>
</note>
-->
</front>
<middle>
<!-- section anchor="sec-1" title="Introduction" -->
<section title="Introduction">
<t>
The CoRE working group is chartered to design and standardize a
Constrained Application Protocol (CoAP) for resource constrained
devices and networks <xref target="I-D.ietf-core-coap"/>. The requirements
for CoRE are documented in <xref target="I-D.shelby-core-coap-req"/>. This draft
discusses the requirements on service discovery for M2M and interactive applications using
resource constrained devices. We propose the use of DNS-SD <xref target="I-D.cheshire-dnsext-dns-sd"/>
and Resource Directory (RD) <xref target="I-D.shelby-core-resource-directory"/> to satisfy the requirements.
The proposal relies heavily on naming and addressing conventions. Special emphasis is placed on the
definition, naming, and discovery of groups.
</t>
<!-- section anchor="sec-1.1" title="Terminology" -->
<section title="Terminology">
<t>
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 <xref target="RFC2119">RFC 2119</xref>.
Addtional privileged words are described below.
</t><t>
A "device" is a physical processor connected to at least one
link through a network interface. Each interface has at least one IP unicast address.
The IP address is optionally bound to a host name, which may be a Fully Qualified Domain Name (FQDN).
</t><t>
An "end-point" corresponds to a "service" and is indentified by a unique {protocol, host, port} tuple.
The identity of an endpoint may be specified by the 'scheme' and 'authority' parts of a URI <xref target="RFC3986"/>.
'Protocol' is a label that indicates application and transport protocol bindings as well as default port (if port
is not specified) and possibly default semantics such as <xref target="RFC5988">web-linking</xref>. 'Host'
corresponds to the <xref target="RFC3986"/> ABNF production as updated by <xref target="I-D.ietf-6man-uri-zoneid"/>.
</t><t>
A "service type", e.g. _bldg-ctrl._tcp, is equivalent to the 'protocol' label described above. It identifies
an application protocol, typically defined by a Standards Development Organization (SDO), and is ultimately
registered with IANA
<xref target="I-D.cheshire-dnsext-dns-sd"/>.
The SDO may additionally specify service subtypes (e.g. _light, _onoff-control, _air-flow ...) to designate
units of functionality, the attributes of the subtypes, and the primitives acting on the attributes.
</t><t>
A "resource" is any attribute of an end-point that can be acted upon by REST methods.
A resource is identified by a URI, that is, an end-point plus a 'path' component <xref target="RFC3986"/>.
</t><t>
A "Function Set" is a service subtype with a set of resources and behaviors
that may be accessed through a REST interface. A Function Set will typically be decribed by a base URI
plus an interface definition as described in <xref target="I-D.shelby-core-interfaces"/>. The interface
definition may specify the naming patterns of subordinate resources and the methods that act on them.
</t><t>
A "Profile" is a group of Function Sets defined by a specification.
</t><t>
A "Collection" is a set of two or more homogeneous subordinate resources that may be acted upon in the aggregate
by sending messages to their parent resource, or individually by sending messages to the collection member.
</t><t>
A "Device type" describes a standardized set of Function Sets that satisfy a use case for a hosting device.
</t><t>
A "group" is a set of end-points.
</t><t>
A "multicast group" is a group of end-points that share a multicast address. The multicast address
is optionally bound to a FQDN that identifies the multicast group. For the purposes of this
document, a (multicast) group generally hosts one Function Set.
</t>
</section>
<!-- section anchor="sec-1.2" title="Motivation" -->
<section title="Motivation">
<t>
In this draft, we focus and expand discussions on requirements
pertaining to discovery, naming, and addressing, including REQ8
of the CoRE charter:
</t>
<figure>
<artwork><![CDATA[
REQ8: A definition of how to use CoAP to advertise about or query
for a Device's description. This description may include the
device name and a list of its Resources, each with a URL, an
interface description URI (pointing e.g. to a Web Application
Description Language (WADL) document) and an optional name or
identifier. The name taxonomy used for this description will
be consistent with other IETF work, e.g.
draft-cheshire-dnsext-dns-sd. [charter]
]]></artwork>
</figure>
<t>
The basis of this draft originated in <xref target="I-D.vanderstok-core-bc"/>.
</t>
</section>
<!-- section anchor="sec-1.3" title="Applicability" -->
<section title="Applicability">
<t>
This note applies to discovery of services for commissioning and auto-configuration in building networks (for example: residential and office).
The examples are inspired by the building environment. The proposed solutions and recommendations can be applied more generally.
</t>
</section>
</section>
<!-- section anchor="sec-2" title="Architecture" -->
<section title="Architecture">
<t>
This section illustrates the aspects of naming
schemes and their support by DNS-based Service Discovery (DNS-SD) <xref target="I-D.cheshire-dnsext-dns-sd"/>
, Extended Multicast DNS (xmDNS) <xref target="I-D.lynn-homenet-site-mdns"/>, and the
Resource Directory (RD) <xref target="I-D.shelby-core-resource-directory"/>
on a set of network architectures.
</t><t>
The basic network for low-power nodes can be
composed of low-resource nodes sharing the same IPv6 prefix and connected to low-power links like IEEE 802.15.4, ITU-T G.9959, or Powerline.
The "lowpan" is a good example of such a network <xref target="RFC4944"/>, <xref target="RFC6282"/>. The network can be either isolated or connected.
This draft assumes that application profiles are defined above coap or http, for example,
applications as specified by the ZigBee Smart Energy Profile 2.0 (SEP2), Obix, or BACnet IT working groups.
The naming and discovery solutions presented here are applicable to multiple interconnected
subnets. Example network architectures are:
</t>
<texttable style="none">
<ttcol> - </ttcol> <ttcol>
An isolated lowpan consists of at least two lowpan devices, one of which is an edge router
that is not connected to a backbone. A Resource Directory may be
situated on the edge router. Alternatively, xmDNS responders may execute on
each device.</ttcol>
<c> - </c> <c>
A connected lowpan consists of at least two lowpan devices, one of which is an
edge router that is connected to a backbone. A Resource Directory may be
situated on an edge router. Alternatively, xmDNS responders may execute on
each device or the DNS-SD service may be available over the
backbone.</c>
<c> - </c> <c>
Interconnected lowpans consist of at least two lowpans
connected via edge routers to the same backbone. A Resource Directory may be
situated on each edge router. Alternatively, xmDNS responders may execute on
each device or the DNS-SD service may be available over the
backbone.</c>
<c> - </c> <c>
A site is a set of interconnected subnets that is locally administered.
A site may include zero or more lowpans.
Border routers may prevent some messages from passing into or out of the site.
</c>
</texttable>
<t>
In certain scenarios, the domain may correspond to the network topology.
In the general case, the domain and network subnet structure may differ.
</t>
</section>
<!-- section anchor="sec-3" title="Use Cases" -->
<section title="Use Cases">
<t>
The use of service discovery is presented in two environments:
(1) interactive service discovery, and (2) M2M service discovery.
From the use cases we derive
the types of queries that service discovery should support.
In particular, a primary motivation is the discovery of groups
that support a given Function Set.
</t>
<!-- section anchor="sec-3.1" title="Discovery scope" -->
<section title="Discovery scope">
<t>
In the simplest case the discovery scope is limited to the services and resources provided on the LowPAN.
In more complex cases, discovery has a scope that can be defined with domain names.
The authority part of a URI <xref target="RFC3986"/> can express the location of the device hosting the service.
A common example is the naming associated with the structure of a building. A device may
acquire a FQDN that relates directly to its location in the building. For example,
power-strip.office4.floor1.example.com (or shorter ps.o4.f1.example.com) refers to a power-strip
with device name "power-strip" (or short "ps") in office4 at floor1 in the building of the company example.com.
Another naming scheme can be functional like TV1.media.IT.example.com, possibly refering to TV number 1
maintained by the media group of the IT department of the example organisation.
Domain naming can be used to express that devices are situated in the same building area or belong to the same organisational units.
Multiple FQDNs can identify a given device.
</t><t>
The DNS provides the mapping from Fully Qualified Domain Name (FQDN) to network address and vice-versa.
The RD realtes domain names to end-points.
The binding of domain names to a physical device (for example, assigning a given FQDN to the TV
in the corner) depends on the operational conditions as described below.
</t>
</section>
<!-- section anchor="sec-3.2" title="Interactive mapping" -->
<section title="Interactive mapping">
<t>
In the residential context, naming of the device is done by the occupant of the home. After connecting
the device to the network, an IP-address is assigned, possibly based on the EUI-64 value of the network interface.
The occupant can use a remote control with a graphical user interface to display all devices that provide
a given service (e.g. a "lighting" service). The remote control prompts the occupant to identify the
(default named) devices, possibly accompanied by on/off switching, barcode scanning, or other manual intervention.
The occupant can provide a meaningful name that will be bound to that device.
The installation steps can be as follows: Service discovery returns all
interfaces on which the specified service is available. The occupant, with or without additional physical support,
establishes the binding between an IP address (based on MAC address or other unique identifier) and the name of the
device providing the service, plus its relationship with other devices or function sets in the system.
In some cases a device has multiple names, and an additional mapping between user specified
name and an automatically generated DNS name is supported.
</t>
</section>
<!-- section anchor="sec-3.3" title="M2M mapping" -->
<section title="M2M mapping">
<t>
In the commercial context (e.g. office buildings) it is usual to employ a Comissioning Tool (CT) to
provide the mapping from physical device to IP network address or FQDN. The professional context is
more rigid than the home because the absence of devices and also the unwanted presence of devices needs to be detected.
Devices are named by an architect or installation contractor. Names can be generated automatically and need
not be human-friendly. The CT contains the names and the physical locations of the devices. At
commissioning time the interfaces have acquired a network address, possibly based on the EUI-64. The physical
device is identified by reading in a unique identifier (e.g. EUI-64 of interface, UUID of device)
with a reader (e.g. barcode reader). Consequently,
the device name to network address binding
is stored into DNS (or elsewhere). Alternatives for identifying devices
are pushing buttons on the device or remotely switching on/off the device.
</t>
</section>
<!-- section anchor="sec-3.4" title="Device and Function Set grouping" -->
<section title="End-point grouping">
<t>
Groups can be used to express that end-points are related by supporting a specific Function Set
(e.g. HVAC equipment controlled by the closest temperature sensor).
Grouping is also necessary when a set of end-points has to react together, more or less synchronously,
to a sequence of commands sent by one or more devices. A common example is provided
by lighting applications where a subset of lights in the building
are dimmed to the same level, set to the same colour, or switched off simultaneously. Another
example is provided by a power-strip supporting a set of power-outlets.
Power-outlets are switched on/off individually or all together. Other examples concern the home, such as
a "sleep mode" setting of all media devices in the home when the user activates the night scene.
</t><t>
Group naming is done the same way as for device naming. Related end-points
are grouped and named. The group name is constructed like a FQDN with the group name
as prefix. Adressing the group can be done in two ways: (1)
by addressing each end-point of the group individually (which requires serial access), or (2) by defining a multicast address for
a multicast group. In the latter case, each hosting device must enable reception by a given end-point of the messages
sent to the multicast address. The members of the multicast group must have identical
port number and path, because the requests are specified in a single multicast message.
</t><t>
The Function Set specified in a message can
contain a collection of resources of the same subtype. The Function Set path postfixed with an identifier
refers to the individual resources of the collection.
For example: the /path/light points to the resource collection of the service subtype light.
Each member of the collection can be identified with /path/light/x, with x in {1,2,3,..}. Consequently,
the /path/light/1/onoff specifies
the onoff resource of collection member 1 of Function Set with /path/light, and
/path/light/onoff specifies the resource onoff of all collection members
contained by the Function Set with /path/light.
When /path/light/onoff is used in a multicast message, it is interpreted as a message to a single light resource
by devices having only one, and to all members of the collection for devices having several light resources.
</t><t>
In <xref target="I-D.shelby-core-interfaces"/> the Batch interface is used to manipulate a collection of subresources
with one message. Both the batch and the collection are static. The collection contains homogeneous resources
where the batch can contain heterogeneous resources.
</t><t>
It is expected that SDOs will standardize resource types, profiles (path names) and group naming conventions.
Manufacturers design the functions supported by a device and select the Profiles, resources and collections.
Each manufacturer can precede the profile path names with a manufacturer defined path prefix; for example when a device
supports multiple standards. Domain name, device name, group name and group members are installation dependent.
</t><t>
Figure 1 illustrates some of the concepts described above. A device
is identified with the name "Power-strip".
In the example, no domain names are associated with the
device, and the name "power-strip" resolves to a Unique Local Address (ULA)<xref target="RFC4193"/>. The device provides
two end-points: one delivers a http service and the second a CoAP service.
The http server and
CoAP server share the same IP-address and use different ports 80
and 61616 respectively.
Two different service subtypes, one identified by Function Set, ps,
and one identified by Function Set, pm, are supported by one end-point.
The Function Set "Power strip" contains a collection of four resources, "Outlet 1" to "Outlet 4",
each one accessible via the accompanying paths /ps/1 to
ps/4. The path /ps interfaces to the entire resource collection.
The attribute "output" is defined
in the service subtype specification.
<vspace blankLines='100' /> <!-- page break -->
</t>
<figure title="Figure 1: device with end-points, Function Sets and resources" align="center">
<artwork><![CDATA[
+-------------------------------------------------------------------+
| "Power-strip" |
| [device] has at least one NIC/IP address, may have a name |
| |
| +---------------------------------------------------------------+ |
| | "HTTP server" | |
| | [End-point] http://power-strip (at default TCP port 80) | |
| +---------------------------------------------------------------+ |
| |
| +---------------------------------------------------------------+ |
| | "CoAP server" | |
| | [End-point] coap://power-strip (at default UDP port 61616) | |
| | | |
| | +-----------------------------------------------------------+ | |
| | | "Power Meter" | | |
| | | [Function Set] coap://power-strip/pm | | |
| | +-----------------------------------------------------------+ | |
| | | |
| | +-----------------------------------------------------------+ | |
| | | "Power strip" | | |
| | | [Function Set] coap://power-strip/ps | | |
| | | | | |
| | | +-------------------------------------------------------+ | | |
| | | | "Outlet 1" | | | |
| | | | [Collection member] coap://power-strip/ps/1 | | | |
| | | | [resource] coap://power-strip/ps/1/output | | | |
| | | | ... | | | |
| | | +-------------------------------------------------------+ | | |
| | | | | |
| | | +-------------------------------------------------------+ | | |
| | | | "Outlet 2" | | | |
| | | | [Collection member] coap://power-strip/ps/2 | | | |
| | | +-------------------------------------------------------+ | | |
| | | | | |
| | | +-------------------------------------------------------+ | | |
| | | | "Outlet 3" | | | |
| | | | [Collection member] coap://power-strip/ps/3 | | | |
| | | +-------------------------------------------------------+ | | |
| | | | | |
| | | +-------------------------------------------------------+ | | |
| | | | "Outlet 4" | | | |
| | | | [Collection member] coap://power-strip/ps/4 | | | |
| | | +-------------------------------------------------------+ | | |
| | +-----------------------------------------------------------+ | |
| +---------------------------------------------------------------+ |
+-------------------------------------------------------------------+
]]></artwork>
</figure>
</section>
<!-- section anchor="sec-3.5" title="Discovery queries" -->
<section title="Discovery queries">
<t>
The following conditions are assumed to be valid. A device has acquired an IP address and a name, possibly stored in DNS.
The resource naming (path) in the device obeys a standardized profile. The resource types of the Function Sets are also standardardized.
A device may belong to a domain.
</t><t>
Service discovery should support that a device can learn its domain(s) and
all the end-points within a domain providing a given service (e.g. temperature measurement).
The device learns of these end-points the path name that prefixes the path names defined by the profile.
Devices need to learn the groups to which they belong and learn all the members of those groups.
This section motivates that a discovery service supports the following queries:
</t>
<texttable style="none">
<ttcol> Goal </ttcol> <ttcol> Description </ttcol>
<c> Name_resolution </c> <c> Resolve the group or device name to IP address and optional port number </c>
<c> Return_server </c> <c> Return all end-points (Function-Sets) supporting a given service (sub-)type within a given domain</c>
<c> Create_group </c> <c> Create a group of end-points providing a given service (sub-)type within a given domain </c>
<c> Enroll_member </c> <c> Enroll an end-point as member of a given group </c>
<c> Remove_member </c> <c> Remove an end-point as member of a given group </c>
<c> Return_group </c> <c> Return all groups of which a given end-point (device) is a member </c>
<c> Return_member </c> <c> Return end-points belonging to a given group </c>
</texttable>
<t>
Name_resolution is supported by DNS and CoAP resource discovery. Names are required in the context of home control
and manual setup of installations. Names are persistent and meaningful as compared to IP addresses and are preferably
used in applications when IP addresses can change.
</t><t>
Return_server is the most common use of service discovery and was originally designed for interactive use.
The canonical IT example is finding all printers within a zone, which allows a user to select the
desired printer from the returned list. Another example is in the context of UPnP <xref target="UPNP"/>, where all media players
are returned on a screen and the user can select the desired media player on the screen and play the selected
content. In M2M applications, the returned names are not displayed on a screen but
an application uses the returned list to select a (set of) Function Set(s) to control.
Consequently, names in M2M applications need not be human interpretable (for example, they can be unique numbers).
</t><t>
Create_group is useful in commissioning scenarios, where end-points need to be grouped to receive the same command
in a possibly synchronous fashion. Groups can also be created to express relations between devices
such as ownership. The command creates a group name and creates a list of the members of the group. When
the group is a multicast group, the command defines a unique multicast address and port, and specifies the path.
</t><t>
Enroll_member supports network and device reconfiguration. When the physical lay-out
of an installation changes because devices are added, changed or removed, the associated groups also need to be modified.
</t><t>
Remove_member, see motivation under Enroll_member
</t><t>
Return_group is needed to learn the groups of which an end-point is member.
The command is necessary for commissioning purposes where a Commissioning Tool (CT) is used. The CT,
on the basis of designs provided by architects, decorators, sound/light engineers, defines groups and group
members and stores that information in the service discovery database. In the next phase, the members of a group may need to learn
their membership from the service discovery to enable reception of multicast messages.
</t><t>
Return_member can be used to learn which end-points are member of a given group. This command is useful in connection with Return_group.
The end-point knowing to which groups it belongs can establish communication with the group members. For example,
membership of a group instructs
new devices, replacing faulty ones, which other devices share access rights or need to be consulted regularly.
</t>
</section>
<!-- section anchor="sec-3.6" title="Sleeping devices" -->
<section title="Sleeping devices">
<t>
This section suggests that service discovery of sleeping devices is mostly a matter of discovering the proxy.
It is expected that a proxy will handle communications for the sleeping device, as expressed in <xref target="I-D.giacomin-core-sleepy-option"/>
and in <xref target="I-D.vial-core-mirror-proxy"/>.
The message sent to the sleeping device is directed to the proxy. The proxy will send the message on with a delay,
or send the result of a function on the history of messages, when the sleeping device is ready. Different communication protocols
between proxy and sleeping device are described in <xref target="I-D.giacomin-core-sleepy-option"/>
and in <xref target="I-D.vial-core-mirror-proxy"/>.
The setting up of the proxy is preferably standardized for a large set of proxy types.
During the setting-up process, (offline or online) the proxy will take over all the entry-points of the sleeping device.
The entry-points of the proxy can be entered into the discovery respository and consequently discovered like any other device.
</t><t>
For groups, two cases need to be considered (1) sleeping device is member of a group and receives group messages,
and (2) the sleeping device sends messages to a group.
Ad (1), when the sleeping device needs to receive messages sent to a group, the proxy will receive those messages
and the end-point of the proxy is entered as group member to receive the group messages. Ad (2) When the sleeping device sends messages to a group,
it is preferable that the sleeping device sends just one multicast message to the group to minimize energy costs. It is required
that when one member of the group receives the message, all other
group members receive it as well (unanimity), covered by the "reliability" REQ1 in <xref target="I-D.ietf-core-groupcomm"/>).
A simple broadcast over a lowpan will not always succceed and additional
multicast algorithms like Trickle <xref target="RFC6206"/> need to be introduced.
</t>
</section>
</section>
<!-- section anchor="sec-4" title="DNS and RD examples" -->
<section title="DNS and RD examples">
<t>
The following device configuration and environment are assumed for the examples. The devices are placed on floor-x (fx)
in two rooms room-y (ry) and room-z (rz). Both rooms contain a powerstrip with a powermeter and four power outlets.
In each room there are two luminaires and one presence sensor (PIR). Each luminaire contains a dimmable light and a
light sensor. Per floor there is a clock to set day and night time modes of the
devices. The domains are: ry.fx.bldg.org, rz.fx.bldg.org and fx.bldg.org. The device names of the 4 luminaires are lm00203,
lm00204, lm00205, and lm00206. The device names of the two powerstrips are ps0057, and ps0078. The paths of the Function Sets of
the luminaire are: /lamp with resource /lamp/dim for the dimmable light,
and /light with resource /light/lumen for the light sensor. The
Function Set path for four outlets is /ps with resource /ps/output.
The path of each individual outlet is /ps/x with x in {1,2,3,4}, and with resource ps/x/output.
The names of the two PIRs are pir0 and pir1. The Function Set path of the PIR is /occup, also being the resource.
</t><t>
Relating location to the domain name is a relevant example of domain naming. Multiple domain names,
related to other application aspects, can be specified and applied simultaneously.
</t><t>
As described in section 3,
devices do not announce themselves to the discovery repository, as is usual for IT applications, but they are entered
(partially) with the aid of a central tool, for example a Remote Control, dedicated device, IPAD or other means.
</t><t>
The examples are constructed such that DNS can be used as repository for the RD.
</t>
<!-- section anchor="sec-4.1" title="DNS-SD examples" -->
<section title="DNS-SD examples">
<!-- section anchor="sec-4.1.1" title="Basic Concepts" -->
<section title="Basic Concepts">
<t>
In conformance with <xref target="I-D.cheshire-dnsext-dns-sd"/>, DNS-based discovery uses
A or AAAA, PTR, SRV, and TXT Resource Records (RR). The SRV RR <xref target="RFC2782"/>
specifies an end-point. An associated (identically named) TXT RR can contain a URI path.
The SRV/TXT pair can specify a Function Set. An A or AAAA RR
<xref target="RFC1035"/> binds a device name or multicast group name to an IP address.
The PTR RR binds a service type to an end-point or Function Sets.
</t><t>
In cases where the end-point port may be dynamic, e.g. in the IPHC <xref target="RFC6282"/>
compressible range, a new 'coap+srv' scheme is proposed (after <xref target="I-D.jennings-http-srv"/>).
The authority part of a coap+srv URI specifies the name and location of an SRV record,
which in turn contains values for device (IP address) and port.
</t>
</section>
<!-- section anchor="sec-4.1.2" title="Commissioning devices" -->
<section title="Commissioning devices">
<t>
Commissioning is the process to store the relation between a FQDN and a device.
It is assumed that either a Remote Control (RC) in the home or a Commissioning Tool (CT) in the
professional domain store the relation in DNS.
</t><t>
In the professional domain, the CT is assumed to
contain information about the devices as prescibed by architect or installation company. The
information in the CT contains device name, device domain name, and location in the building,
but the relation with the installed device, identified with an unique identifier (e.g. EUI-64) is
not established. By reading a bar code (or pushing buttons, switching on/off equipment, etc.),
the CT learns the unique identifier of the device to be commissioned.
All kinds of techniques can be used to establish the relation between IP address and unique identifier.
When the identifier is the EUI-64 value, the IP address of the device can be constructed.
When the identifier is not the EUI-64, a proprietary procol can be used to ask a given device its identifier. Etc. etc.
The CT can learn the end-points (services) available on the device by querying /.well-known/core.
In some cases the CT already obtained the end-points from a configuration file.
Given these data, the CT can enter the devices and its services into DNS.
Either automatically, or on instructions of an operator, the CT defines the groups in the DNS.
</t><t>
The home domain is different from the professional domain in the sense that no configuration information exists.
The RC can for example use xmDNS to learn the addresses of all the devices present in its site. The RC
can query devices for the presence of a given service. The RC can query DNS for its own domain name and use that for the
other devices in the site. Once (new) devices are named, this information can be stored in DNS for use in the network.
</t>
</section>
<!-- section anchor="sec-4.1.3" title="device examples" -->
<section title="device examples">
<t>
The relation between device name and IP address is expressed for the example devices in the following table.
</t>
<texttable style="none">
<ttcol>lm00203.ry.fx.bldg.org. </ttcol> <ttcol> IN AAAA </ttcol> <ttcol> fdfd::1234 </ttcol>
<c> lm00204.ry.fx.bldg.org. </c> <c> IN AAAA </c> <c> fdfd::1235 </c>
<c> ps0057.ry.fx.bldg.org. </c> <c> IN AAAA </c> <c> fdfd::1236 </c>
<c> pir1.ry.fx.bldg.org. </c> <c> IN AAAA </c> <c> fdfd::1237 </c>
<c> lm00205.rz.fx.bldg.org. </c> <c> IN AAAA </c> <c> fdfd::1238 </c>
<c> lm00206.rz.fx.bldg.org. </c> <c> IN AAAA </c> <c> fdfd::1239 </c>
<c> ps0058.rz.fx.bldg.org. </c> <c> IN AAAA </c> <c> fdfd::1240 </c>
<c> pir2.rz.fx.bldg.org. </c> <c> IN AAAA </c> <c> fdfd::1241 </c>
<c> clock.fx.bldg.org. </c> <c> IN AAAA </c> <c> fdfd::1242 </c>
</texttable>
<t>
The next part defines the Resource Records to specify the end-points and their Function Sets.
The names of the SRV RRs need to be unique to the DNS server, and follow the naming suggested in <xref target="I-D.cheshire-dnsext-dns-sd"/>.
An end-point is represented with one SRV RR with a name "_service.domain".
A Function-Set is represented with a SRV/TXT pair with name "subtype._sub._service.domain".
</t><t>
The service type "_bc._udp" is assumed to exist with the service subtypes "lamp", "sensor", "power", "presence", and "timer".
Unique names of the SRV RRs can
be created from the service subtype prefixed by the EUI-64 value.
With EUI-64 value "1234" the SRV name 1234_bc._udp.domain can be created for the corresponding end-point.
Given that the service _bc._udp supports subtype lamp the name 1234lamp._sub._bc._udp.domain is created for for each SRV/TXT pair
describing a Function-Set serving the lamp subtype.
They are valid within the authority zone, bldg.org, of the name server.
For presentation purposes, 1234_bc is short for 1234_bc._udp.bldg.org, 1234lamp is short for 1234lamp._sub._bc._udp.bldg.org, etc.
The luminaires with name "lm00xxx" provide each one end-point hosting two Function Sets with the paths /lamp and /light.
</t>
<texttable style="none">
<ttcol> end-point </ttcol> <ttcol> </ttcol> <ttcol> </ttcol> <ttcol> host name </ttcol>
<c> 1234_bc </c> <c> IN SRV </c> <c> 0 0 Port </c> <c> lm00203.ry.fx.bldg.org </c>
<c> </c> <c> IN TXT </c> <c> txtvers=1 </c> <c> </c>
<c> 2345_bc </c> <c> IN SRV </c> <c>0 0 Port </c> <c> lm00204.ry.fx.bldg.org </c>
<c> </c> <c> IN TXT </c> <c> txtvers=1 </c> <c> </c>
<c> 3456_bc </c> <c> IN SRV </c> <c>0 0 Port </c> <c> lm00205.rz.fx.bldg.org </c>
<c> </c> <c> IN TXT </c> <c> txtvers=1 </c> <c> </c>
<c> 4567_bc </c> <c> IN SRV </c> <c>0 0 Port </c> <c> lm00206.rz.fx.bldg.org </c>
<c> </c> <c> IN TXT </c> <c> txtvers=1 </c> <c> </c>
<c> 5678_bc </c> <c> IN SRV </c> <c>0 0 Port </c> <c> ps0057.ry.fx.bldg.org </c>
<c> </c> <c> IN TXT </c> <c> txtvers=1 </c> <c> </c>
<c> 6789_bc </c> <c> IN SRV </c> <c>0 0 Port </c> <c> ps0058.rz.fx.bldg.org </c>
<c> </c> <c> IN TXT </c> <c> txtvers=1 </c> <c> </c>
<c> 7890_bc </c> <c> IN SRV </c> <c>0 0 Port </c> <c> pir1.ry.fx.bldg.org </c>
<c> </c> <c> IN TXT </c> <c> txtvers=1 </c> <c> </c>
<c> 8901_bc </c> <c> IN SRV </c> <c>0 0 Port </c> <c> pir2.rz.fx.bldg.org </c>
<c> </c> <c> IN TXT </c> <c> txtvers=1 </c> <c> </c>
<c> 9012_bc </c> <c> IN SRV </c> <c>0 0 Port </c> <c> clock.fx.bldg.org </c>
<c> </c> <c> IN TXT </c> <c> txtvers=1 </c> <c> </c>
</texttable>
<t>
The above list of SRV RRs specifies the attributes of the end-points: devices, port numbers,
and IP addresses with related AAAA RR.
The Function Sets are specified with a another set of SRV/TXT pairs. The accompanying TXT RR specify the paths of the associated Function Set(s).
The accompanying example table is:
</t>
<texttable style="none">
<ttcol> Function Set </ttcol> <ttcol> </ttcol> <ttcol> </ttcol> <ttcol> host name </ttcol>
<c> 1234lamp </c> <c> IN SRV </c> <c>0 0 Port </c> <c> lm00203.ry.fx.bldg.org </c>
<c> </c> <c> IN TXT </c> <c> txtvers=1 path=/lamp </c> <c> </c>
<c> 1234sensor </c> <c> IN SRV </c> <c>0 0 Port </c> <c> lm00203.ry.fx.bldg.org </c>
<c> </c> <c> IN TXT </c> <c> txtvers=1 path=/light </c> <c> </c>
<c> 2345lamp </c> <c> IN SRV </c> <c>0 0 Port </c> <c> lm00204.ry.fx.bldg.org </c>
<c> </c> <c> IN TXT </c> <c> txtvers=1 path=/lamp </c> <c> </c>
<c> 2345sensor </c> <c> IN SRV </c> <c>0 0 Port </c> <c> lm00204.ry.fx.bldg.org </c>
<c> </c> <c> IN TXT </c> <c> txtvers=1 path=/light </c> <c> </c>
<c> 5678power </c> <c> IN SRV </c> <c>0 0 Port </c> <c> ps0057.ry.fx.bldg.org </c>
<c> </c> <c> IN TXT </c> <c> txtvers=1 path=/ps </c> <c> </c>
<c> 7890presence </c> <c> IN SRV </c> <c>0 0 Port </c> <c> pir1.ry.fx.bldg.org </c>
<c> </c> <c> IN TXT </c> <c> txtvers=1 path=/occup </c> <c> </c>
<c> 3456lamp </c> <c> IN SRV </c> <c>0 0 Port </c> <c> lm00205.rz.fx.bldg.org </c>
<c> </c> <c> IN TXT </c> <c> txtvers=1 path=/lamp </c> <c> </c>
<c> 3456sensor </c> <c> IN SRV </c> <c>0 0 Port </c> <c> lm00205.rz.fx.bldg.org </c>
<c> </c> <c> IN TXT </c> <c> txtvers=1 path=/light </c> <c> </c>
<c> 4567lamp </c> <c> IN SRV </c> <c>0 0 Port </c> <c> lm00206.rz.fx.bldg.org </c>
<c> </c> <c> IN TXT </c> <c> txtvers=1 path=/lamp </c> <c> </c>
<c> 4567sensor </c> <c> IN SRV </c> <c>0 0 Port </c> <c> lm00206.rz.fx.bldg.org </c>
<c> </c> <c> IN TXT </c> <c> txtvers=1 path=/light </c> <c> </c>
<c> 6789power </c> <c> IN SRV </c> <c>0 0 Port </c> <c> ps0058.rz.fx.bldg.org </c>
<c> </c> <c> IN TXT </c> <c> txtvers=1 path=/ps </c> <c> </c>
<c> 8901presence </c> <c> IN SRV </c> <c>0 0 Port </c> <c> pir2.rz.fx.bldg.org </c>
<c> </c> <c> IN TXT </c> <c> txtvers=1 path=/occup </c> <c> </c>
<c> 9012timer </c> <c> IN SRV </c> <c>0 0 Port </c> <c> clock.fx.bldg.org </c>
<c> </c> <c> IN TXT </c> <c> txtvers=1 path=/time </c> <c> </c>
</texttable>
<t>
The names of the SRV records
can be created automatically, as long as they identify the SRV records uniquely
within the set of RR entries in the DNS zone.
The SRV record with name xxxxpower stands for a power collection, accessed via the
path /ps which refers to a Function Set that contains a collection of two or more resources.
</t><t>
PTR records specify the possible service discovery queries. The names of the PTR records are the names of the service
(sub)types, defined by IANA, and their values refer to the names of the associated end-points (SRV records) or Function-Sets (SRV/TXT records).
To support the query "all lamps within fx.bldg.org", the following
PTR records need to be added for service subtype:lamp._sub._bc._udp.
</t>
<texttable style="none">
<ttcol> lamp._sub._bc._udp.bldg.org </ttcol> <ttcol> IN PTR </ttcol> <ttcol> 1234lamp </ttcol>
<c> lamp._sub._bc._udp.bldg.org </c> <c> IN PTR </c> <c> 2345lamp </c>
<c> lamp._sub._bc._udp.bldg.org </c> <c> IN PTR </c> <c> 3456lamp </c>
<c> lamp._sub._bc._udp.bldg.org </c> <c> IN PTR </c> <c> 4567lamp </c>
</texttable>
<t>
Where xxxxlamp is still short for xxxxlamp._sub._bc._udp.bldg.org.
</t><t>
Equally to query all services within a domain, PTR records
with as name the building control service, "_bc.udp", refer to all SRV records describing all discoverable end-points.
</t>
<texttable style="none">
<ttcol> _bc._udp.bldg.org </ttcol> <ttcol> IN PTR </ttcol> <ttcol> 1234_bc._udp.bldg.org </ttcol>
<c> _bc._udp.bldg.org </c> <c> IN PTR </c> <c> 2345_bc._udp.bldg.org </c>
<c> _bc._udp.bldg.org </c> <c> IN PTR </c> <c> 3456_bc._udp.bldg.org </c>
<c> _bc._udp.bldg.org </c> <c> IN PTR </c> <c> 4567_bc._udp.bldg.org </c>
<c> _bc._udp.bldg.org </c> <c> IN PTR </c> <c> 5678_bc._udp.bldg.org </c>
<c> _bc._udp.bldg.org </c> <c> IN PTR </c> <c> etc, etc. </c>
</texttable>
<t>
It is shown above how PTR records support the queries filtered on service type. Filtering on domain
can be done adding additional PTR records which select the Function Sets of a given type within a given domain.
The set of PTR records below filters on all lamps within domain ry.fx.bldg.org.
</t>
<texttable style="none">
<ttcol> lamp._sub._bc._udp.ry.fx.bldg.org. </ttcol> <ttcol> IN PTR </ttcol> <ttcol> 1234lamp </ttcol>
<c> lamp._sub._bc._udp.ry.fx.bldg.org. </c> <c> IN PTR </c> <c> 2345lamp </c>
</texttable>
</section>
<!-- section anchor="sec-4.1.4" title="Group examples" -->
<section title="Group examples">
<t>
As an example, five multicast-groups are defined to group all lamps on floor "fx", all lamps in office "ry",
all lamps in office "rz",
all power-strips on floor "fx", and all devices in the building controlled by a central timer.
The multicast-group names are entered into DNS like the device names to enable resolution
from multicast-group name to multicast address.
</t>
<texttable style="none">
<ttcol> lamp-fx.fx.bldg.org. </ttcol> <ttcol> IN AAAA </ttcol> <ttcol> ff15::11 </ttcol>
<c> lamp-ry.ry.fx.bldg.org. </c> <c> IN AAAA </c> <c> ff15::12 </c>
<c> lamp-rz.rz.fx.bldg.org. </c> <c> IN AAAA </c> <c> ff15::13 </c>
<c> power-fx.fx.bldg.org. </c> <c> IN AAAA </c> <c> ff15::14 </c>
<c> timer-bldg.bldg.org. </c> <c> IN AAAA </c> <c> ff15::15 </c>
</texttable>
<t>
It is expected that SDOs will specify naming conventions for group names, extending the service (sub)type names
for end-points and Function Sets.
</t><t>
The path and port of the multicast-groups is defined with SRV and TXT RRs. Accordingly the group is bound to
end-points (SRV RR) and Function Sets (SRV+TXT RR). For convenience we assume that a multicast group is bound to a service subtype.
In the example below the groups concern the service subtypes "lamp", "power", and "timer".
(Remark gp1-lamp is short for gp1-lamp._sub._bc._udp.bldg.org, etc.)
</t>
<texttable style="none">
<ttcol> gp1-lamp </ttcol> <ttcol> IN SRV </ttcol> <ttcol>0 0 Port </ttcol> <ttcol> lamp-fx.fx.bldg.org. </ttcol>
<c> </c> <c> IN TXT </c> <c> path=/lamp </c> <c> </c>
<c> gp2-lamp </c> <c> IN SRV </c> <c> 0 0 Port </c> <c> lamp-ry.ry.fx.bldg.org. </c>
<c> </c> <c> IN TXT </c> <c> path=/lamp </c> <c> </c>
<c> gp3-lamp </c> <c> IN SRV </c> <c> 0 0 Port </c> <c> lamp-rz.rz.fx.bldg.org. </c>
<c> </c> <c> IN TXT </c> <c> path=/lamp </c> <c> </c>
<c> gp-power </c> <c> IN SRV </c> <c> 0 0 Port </c> <c> power-fx.fx.bldg.org. </c>
<c> </c> <c> IN TXT </c> <c> path=/ps </c> <c> </c>
<c> gp-timer </c> <c> IN SRV </c> <c> 0 0 Port </c> <c> timer-bldg.bldg.org. </c>
<c> </c> <c> IN TXT </c> <c> path=/time </c> <c> </c>
</texttable>
<t>
The groups for the power strips need extra attention because the power strips include a collection of resources.
The path to the group can be defined as /ps or as /ps/x with x in {1,2,3,4}. When using /ps/x the group contains the outlet x
of the power strips. Using the path /ps as done in the table above refers to all outlets of a powerstrip.
When sending a message to the power-fx group with as path /ps/x then the message will be received by Function Sets
with path ps/x only.
</t><t>
The members of the groups can be stored in DNS by using the reverse DNS resolution technique.
It is not unusual that a given IP address refers to multiple FQDNs. Extrapolating to
group names extends the reverse DNS resolution in a natural manner. Below the members of group lamp-fx.fx.bldg.org
with IP address ff15::11 containing all four lamps is shown.
</t>
<texttable style="none">
<ttcol> 1.1.0.....0.5.1.f.f.IP6.arpa. </ttcol> <ttcol> IN PTR </ttcol> <ttcol> lm00206.rz.fx.bldg.org. </ttcol>
<c> 1.1.0.....0.5.1.f.f.IP6.arpa. </c> <c> IN PTR </c> <c> lm00205.rz.fx.bldg.org. </c>
<c> 1.1.0.....0.5.1.f.f.IP6.arpa. </c> <c> IN PTR </c> <c> lm00204.ry.fx.bldg.org. </c>
<c> 1.1.0.....0.5.1.f.f.IP6.arpa. </c> <c> IN PTR </c> <c> lm00203.ry.fx.bldg.org. </c>
<c> 1.1.0.....0.5.1.f.f.IP6.arpa. </c> <c> IN PTR </c> <c> lamp-fx.fx.bldg.org. </c>
</texttable>
<t>
With the above table queries like "return all members of lamp-fx" can be answered.
</t><t>
Additional tables are needed to specify the multicast groups to which the end-point of
a device belongs. A PTR RR with the name of the Function Set can refer to the name of the group. In the table below
the Function Set "1234lamp" is member of the groups "lamp-fx" and "lamp-ry":
</t>
<texttable style="none">
<ttcol> 1234lamp </ttcol> <ttcol> IN PTR </ttcol> <ttcol> lamp-fx.fx.bldg.org </ttcol>
<c> 1234lamp </c> <c> IN PTR </c> <c> lamp-ry.ry.fx.bldg.org </c>
</texttable>
<t>
Consequently, a device can query DNS for the groups to which its Function Set belongs, and consecutively enable the reception of the
associated multicast messages.
</t>
</section>
<!-- section anchor="sec-4.1.5" title="Discovery validation" -->
<section title="Discovery validation">
<t>
This section describes how the disovery requirements are met with DNS-SD. It is assumed that the DNS server tables are correctly filled in.
</t><t>
Name_resolution: Group- or device-name is resolved to IP address by sending a query to DNS to return all AAAA records with the given name.
</t><t>
Return_server: Suppose the given service is defined by instance._sub._service.domain. All Function Sets supporting this service in the domain are found
by sending a query to DNS to return all PTR records with the name instance._sub._service.domain. The returned PTR records refer to the names
of the SRV/TXT pairs describing the port, FQDN and path of the associated Function Sets. Additional queries return all SRV and TXT records with the
names returned by the first query. To query the end-points a query is sent to return all PTR records with name service.domain.
</t><t>
Create-Group: Groups are created by creating resource records in DNS as described in section 4.1.4. The filing of the DNS server tables is done by a trusted
Remote Control or commissioning Device (see section 4.1.2). Section 6.1 discusses the security aspects.
</t><t>
Enroll-member, Remove-member: See Create-Group.
</t><t>
Return-Group: Suppose the given Function Set is given by the name instance._sub._bc._service.domain. All groups to which this Function Set belongs
are found by sending a query to DNS to return
all PTR records with the name instance._sub._bc._service.domain. The returned PTR records refer to the names of the associated groups.
Name resolution provides the IP address.
</t><t>
Return-member: The members of a group with name group group.domain are found by resolving the group name to an IP address. The members of the group are
obtained by sending a query to DNS to return all PTR records with as the name the inverted IP-address. The PRT records refer to the names of the associated
devices.
</t>
</section>
</section>
<!-- section anchor="sec-4.2" title="RD examples" -->
<section title="RD examples">
<t>
Resource discovery in CoAP handles resource paths (called links) for the resources hosted on the server,
augmented with attributes of these resources. A well-known path "/.well-known/core" <xref target="RFC5785"/> is a default Function Set for requesting
the list of links on a given server <xref target="I-D.shelby-core-resource-directory"/>.
The Resource Directory (RD) stores links to resources hosted by other servers.
The link-format <xref target="I-D.ietf-core-link-format"/> defines link extensions to specify
the service type and end-point as used by DNS-SD. When querying the Resource Directory for links, filters can be applied
to return only links with specified attribute values. A node learns the IP-address of the RD by for example sending a multicast request to a
predefined multicast address registered with IANA, or by assuming that the RD is located in the edge router.
</t><t>
Contrary to DNS-SD, the RD has not defined a process which permits SDOs to specify service (sub)types.
Consequently, the same service type examples are used for DNS-SD as for RD, where service type postfixed with subtype (DNS)
equals "resource type" (RD).
The "host" name of DNS is used as "end-point" name for RD.
</t><t>
This draft adheres to the mapping between DNS and link-format, described in <xref target="I-D.lynn-core-discovery-mapping"/>.
</t>
<!-- section anchor="sec-4.2.1" title="Commissioning devices" -->
<section title="Commissioning devices">
<t>
It is assumed that either a Remote Control (RC) in the home or a Commissioning Tool (CT) in the
professional domain is used to fill in the RD.
Devices cannot enter links into the RD contrary to the suggestion in <xref target="I-D.shelby-core-resource-directory"/>.
Both the RC or the CT have to fill in the RD, because at link creation
the RD generates a location
of the link-entry (e.g. /ed/453), that is returned to the
creator of the link. Consequently, the CT or the RD need to create the link, because they need the location
to update the link with additional information.
</t><t>
In the professional domain, the CT learns the identity
of the device as described earlier, reads the services of the devices with a GET to /.well-known/core on the device,
and stores them into the RD.
</t><t>
In the home domain, the RC
can read in the EUI-64 of the device to be entered. The user types in domain names and device names on the RC.
Consecutively, the RC follows the same procedure as the CT.
</t>
</section>
<!-- section anchor="sec-4.2.2" title="Device examples" -->
<section title="Device examples">
<t>
For convenience, it is assumed that DNS contains the mapping from FQDN to IP address with AAAA RRs
and vice-versa with PTR RRs.
In all examples the FQDN is used and not the IP-address. It is assumed that the service type "_bc" has the subtypes:
"lamp", "sensor", "power", "presence", and "timer".
Registration is done with the following statements by CT or RC to the RD with authority: //rd.example.com/ and path /rd.
Each POST command to the RD defines an end-point in the URI and defines the corresponding Function Sets in the payload.
</t>
<figure>
<artwork><![CDATA[
POST coap://rd.example.com/rd?ep=lm00203;d=ry.fx.bldg.org
Etag: 0x21
Payload:
</lamp>;rt="lamp._sub._bc",
</light>;rt="sensor._sub._bc"
Res: 2.01 created
Location: /rd/1234
]]></artwork>
</figure>
<t>
The other end-points are defined with (leaving out the response):
</t>
<figure>
<artwork><![CDATA[
POST coap://rd.example.com/rd?ep=lm00204;d=ry.fx.bldg.org
Payload:
</lamp>;rt="lamp._sub._bc",
</light>;rt="sensor._sub._bc"
POST coap://rd.example.com/rd?ep=lm00205;d=rz.fx.bldg.org
Payload:
</lamp>;rt="lamp._sub._bc",
</light>;rt="sensor._sub._bc"
POST coap://rd.example.com/rd?ep=lm00206;d=rz.fx.bldg.org
Payload:
</lamp>;rt="lamp._sub._bc",
</light>;rt="sensor._sub._bc" ]]></artwork>
</figure>
<t></t>
<figure>
<artwork><![CDATA[
POST coap://rd.example.com/rd?ep=ps0057;d=ry.fx.bldg.org
Payload:
</ps>;rt="power._sub._bc",
</ps/1>;rt="power._sub._bc",
</ps/2>;rt="power._sub._bc",
</ps/3>;rt="power._sub._bc",
</ps/4>;rt="power._sub._bc"
POST coap://rd.example.com/rd?ep=ps0058;d=rz.fx.bldg.org
Payload:
</ps>;rt="power._sub._bc",
</ps/1>;rt="power._sub._bc",
</ps/2>;rt="power._sub._bc",
</ps/3>;rt="power._sub._bc",
</ps/4>;rt="power._sub._bc"
POST coap://rd.example.com/rd?ep=pir1;d=ry.fx.bldg.org
Payload:
</occup>;rt="presence._sub._bc"
POST coap://rd.example.com/rd?ep=pir2;d=rz.fx.bldg.org
Payload:
</occup>;rt="presence._sub._bc"
POST coap://rd.example.com/rd?ep=clock;d=fx.bldg.org
Payload:
</time>;rt="timer._sub._bc"
]]></artwork>
</figure>
<t>
Update or removal of the groups is done by using the returned location (not shown above) as described in <xref target="I-D.shelby-core-resource-directory"/>
for the end-points.
</t>
</section>
<!-- section anchor="sec-4.2.3" title="Group examples" -->
<section title="Group examples">
<t>
The same five multicast groups of the DNS example are used. The group name to address mapping is specified
in DNS with AAAA RRs. The group name is not easily identified with an end-point. Therefore the mnemonic gp is added as link-format attribute.
The group members are included by citing the end-point names, which allows a unique identification of the members.
In all examples the group name is used and not the IP-address.
Registration is done with the following statements by CT or RC to the RD with authority: /rd.example.com/ and path /rd,
leaving out Etag:, Res:, and Location: lines.
The group name is defined in the URI, while all the members (end-points) are specified in the payload. The path in the payload
defines together with the end-point the Function Set.
</t>
<figure>
<artwork><![CDATA[
POST coap://rd.example.com/rd?gp=lamp-fx;d=fx.bldg.org
Payload:
</lamp>;rt="lamp._sub._bc";ep=lm00206,
</lamp>;rt="lamp._sub._bc";ep=lm00205,
</lamp>;rt="lamp._sub._bc";ep=lm00204,
</lamp>;rt="lamp._sub._bc";ep=lm00203
POST coap://rd.example.com/rd?gp=lamp-ry;d=ry.fx.bldg.org
Payload:
</lamp>;rt="lamp._sub._bc";ep=lm00204,
</lamp>;rt="lamp._sub._bc";ep=lm00203
POST coap://rd.example.com/rd?gp=lamp-rz;d=rz.fx.bldg.org
Payload:
</lamp>;rt="lamp._sub._bc";ep=lm00206,
</lamp>;rt="lamp._sub._bc";ep=lm00205
POST coap://rd.example.com/rd?gp=power-fx;d=fx.bldg.org
Payload:
</ps>;rt="power._sub._bc";ep=ps0057,
</ps>;rt="power._sub._bc";ep=ps0058
POST coap://rd.example.com/rd?gp=timer-bldg;d=bldg.org
Payload:
</time>;rt="timer._sub._bc";ep=clock
]]></artwork>
</figure>
<t>
With the above statements the groups are defined in the RD.
</t>
</section>
<!-- section anchor="sec-4.2.4" title="Discovery validation" -->
<section title="Discovery validation">
<t>
This section describes how the disovery requirements are met with the RD. It is assumed that the RD tables are correctly filled in.
</t><t>
Name_resolution: When LoWPAN is connected to backbone, it is assumed that DNS is used for name resolution. When LoWPAN is stand-alone without DNS server,
IP addresses are used to connect to an interface.
</t><t>
Return_server: Suppose the given service is defined by instance._sub._service. The query
</t>
<figure>
<artwork><![CDATA[
GET coap://rd.example.com/rd-lookup/res?rt=instance.
_sub._service
Res: 2.05 content
<coap://name.domain/path>;rt="instance._sub._service"
]]></artwork>
</figure>
<t>
returns all Function Sets providing the specified service. By changing the "res?" part in the query by "ep?" all end-points are returned.
</t><t>
Create-Group: Groups are created by sending POST commands to RD as described in section 4.2.2. The filling of the RD server tables is done by a trusted
Remote Control or commissioning Device (see section 4.2.1). Section 6.1 discusses the security aspects.
</t><t>
Enroll-member, Remove-member: See Create-Group.
</t><t>
Return-Group: Suppose the given end-point is given by the name ep.domain. All groups to which this end-point belongs are found by sending a query
</t>
<figure>
<artwork><![CDATA[
GET coap://rd.example.com/rd-lookup/gp?ep=ep.domain
Res: 2.05 content
<coap://name.domain/path>;gp="group.domain"
]]></artwork>
</figure>
<t>
returns all groups of which the specified end-point, ep.domain, is a member.
</t><t>
Return-member: The members of a group with name group group.domain are found by the query
</t>
<figure>
<artwork><![CDATA[
GET coap://rd.example.com/rd-lookup/ep?gp=group.domain
Res: 2.05 content
<coap://name.domain/path>;ep="ep.domain"
]]></artwork>
</figure>
<t>
which returns all end-points which are member of the group gp.domain.
</t>
</section>
</section>
</section>
<!-- section anchor="IANA" title="IANA Considerations" -->
<section title="IANA Considerations">
<t>This document makes no request of IANA.</t>
<t>Note to RFC Editor: this section may be removed on publication as an RFC.</t>
</section>
<!-- section anchor="Security" title="Security Considerations" -->
<section title="Security Considerations">
<t>
Security considerations apply to use of DNS and RD separately, because they use different security mechanisms.
</t>
<!-- section anchor="DNS Security title="DNS Security considerations" -->
<section title="DNS Security considerations">
<t>
Security extensions for DNS are provided by Domain Name System Security Extensions (DNSSEC) as described in <xref target="RFC4033"/>, <xref target="RFC4034"/>, and <xref target="RFC4035"/>.
In particular <xref target="RFC4033"/> describes all documents relevant to DNSSEC. The central design decision of DNSSEC is to provide origin authentication
and integrity protection for DNS data. All transported DNS data are freely accessible. Consequently, all correctly functioning nodes will receive the domain
and group names to which they belong, and will receive the addresses of the multicast and unicast destinations, and the multicast address of the groups to which they
belong. Accordingly, commands will be sent to the intended destinations and accepted by the intended destinations. All resolvers MUST be configured with a security anchor.
The anchor can be stored non-volatile memory or be provided by other out-of-band means.
</t><t>
Updating of DNS data, e.g,. zone data MUST be done using the secure dynamic updates mechanism. For example, a commissioning device is used to fill in the DNS server.
Both the device sending the update requests (i.e., the commissioning device) and the DNS Server MUST share a Transaction Signature (TSIG) key <xref target="RFC2845"/>.
The TSIG key is a symmetric-key and it can be generated using the dnssec-keygen primitive. The TSIG key is then used to sign the DNS update message, thus ensuring the authenticity of the request.
An access control list can be defined in the DNS to authorize updates to the DNS data. The Berkeley Internet Name Daemon (BIND) implementation of the Internet System Consortium (ISC) provides
a mechanism to specify access control lists, ensuring that updates of DNS zone data can only be performed by authorized parties. The allow-update option in a zone statement is used to control access to a zone.
This option grants clients with a particular TSIG key the permission to update any record of any name in the zone. To allow for finer-granular access control, the update-policy option can be used within a zone
statement, it specifies a set of rules where each rule either grants or denies permissions to one or more names to be updated by one or more identities.
The identity can be determined based on the TSIG key in the TSIG record.
</t><t>
In the home and also during construction in the professional case, islands of security exist when the authorative DNS server has no connection to parent
or children zones. In a later stage, access can be provided via DNS root servers involving a second security anchor. Alternatively, stub resolvers access
contact recursive name servers via an secure channel as SIG(0) <xref target="RFC2931"/> or TSIG <xref target="RFC2845"/>.
</t><t>
In spite of using DNSSEC, rogue devices can obtain valid addresses and accept commands for these destinations. This is not worse than rogue devices accepting
any packet via a NIC in promiscuous mode.
Rogue devices can send unwanted commands to the thus observed IP address. The same addresses can also be obtained by listening to the network traffic.
</t>
</section>
<!-- section anchor="RD Security title="RD Security considerations" -->
<section title="RD Security considerations">
<t>
Security for Resource Direcory is provided by recommended CoAP security techniques: DTLS.
</t>
</section>
</section>
<!-- section anchor="Acknowledgements" title="Acknowledgements" -->
<section title="Acknowledgments">
<t>
Zach Shelby wrote the original Discovery section in <xref target="I-D.ietf-core-coap"/>
which forms the basis for this draft. This I-D has benefited from conversations with and comments from
Emmanuel Frimout, Michael Verschoor, Jamie Mc Cormack, Esko Dijk,
Dee Denteneer, Joop Talstra, Jerald Martocci,
Matthieu Vial, Jerome Hamel, George Yianni, and Nicolas Riou.
</t><t>
Sye Loong Keoh, Sandeep Kumar, and Oscar Garcia Morchon contributed actively to security considerations.
</t>
</section>
<!-- section anchor="Changelog" title="Changelog" -->
<section title="Changelog">
<t>
Changes from -02 to -03:
<list style="symbols">
<t>adapted to resource direcory version -03</t>
<t>DNS-SD examples follow better DNS-SD naming conventions</t>
<t>added gp= link-format attribute</t>
<t>added security considerations</t>
<t>groups of end-points and groups of Function Sets instead of groups of devices</t>
<t>less centered around DNS, more RD aspects</t>
</list>
</t>
</section>
</middle>
<back>
<references title="Normative References">
&RFC1035;
&RFC2119;
&RFC2782;
&RFC2845;
&RFC2931;
&RFC3986;
&RFC4033;
&RFC4034;
&RFC4035;
&RFC4193;
&RFC4291;
&RFC4605;
&RFC4944;
&RFC5234;
&RFC5785;
&RFC5988;
&RFC6282;
&RFC6206;
</references>
<references title="Informative References">
&I-D.cheshire-dnsext-dns-sd;
&I-D.eggert-core-congestion-control;
&I-D.ietf-6man-uri-zoneid;
&I-D.ietf-core-coap;
&I-D.ietf-core-groupcomm;
&I-D.ietf-core-link-format;
&I-D.lynn-core-discovery-mapping;
&I-D.lynn-homenet-site-mdns;
&I-D.shelby-core-coap-req;
&I-D.shelby-core-interfaces;
&I-D.shelby-core-resource-directory;
&I-D.vanderstok-core-bc;
&I-D.jennings-http-srv;
&I-D.giacomin-core-sleepy-option;
&I-D.vial-core-mirror-proxy;
<reference anchor="ZeroConf">
<front>
<title>Zero Configuration Networking: The Definitive Guide</title>
<author initials="S." surname="Cheshire" fullname="Stuart Cheshire"/>
<author initials="D.H." surname="Steinberg" fullname="Daniel H. Steinberg"/>
<date year="2006"/>
</front>
<seriesInfo name="O'Reilly Media, Inc." value=""/>
<seriesInfo name="ISBN" value="0-596-10100-7"/>
</reference>
<reference anchor="UPNP">
<front>
<title>Universal Plug and Play</title>
<author fullname="UPnP working group"/>
<date year="2012"/>
</front>
<seriesInfo name="Web" value="http://www.upnp.org"/>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 14:27:47 |