[Docs] [txt|pdf|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02

CoRE                                                P. van der Stok, Ed.
Internet-Draft                                    vanderstok consultancy
Intended status: Informational                                   K. Lynn
Expires: January 11, 2013                                     Consultant
                                                               A. Brandt
                                                           Sigma Designs
                                                           July 10, 2012


                 CoRE Discovery, Naming, and Addressing
                      draft-vanderstok-core-dna-02

Abstract

   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.

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 January 11, 2013.

Copyright Notice

   Copyright (c) 2012 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   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



van der Stok, et al.    Expires January 11, 2013                [Page 1]


Internet-Draft   CoRE Discovery, Naming, and Addressing        July 2012


   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 . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  3
     1.2.  Motivation . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.3.  Applicability  . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Architecture . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Use Cases  . . . . . . . . . . . . . . . . . . . . . . . . . .  5
     3.1.  Discovery scope  . . . . . . . . . . . . . . . . . . . . .  6
     3.2.  Interactive mapping  . . . . . . . . . . . . . . . . . . .  6
     3.3.  M2M mapping  . . . . . . . . . . . . . . . . . . . . . . .  7
     3.4.  End-point grouping . . . . . . . . . . . . . . . . . . . .  7
     3.5.  Discovery queries  . . . . . . . . . . . . . . . . . . . . 10
     3.6.  Sleeping devices . . . . . . . . . . . . . . . . . . . . . 11
   4.  DNS and RD examples  . . . . . . . . . . . . . . . . . . . . . 12
     4.1.  DNS-SD examples  . . . . . . . . . . . . . . . . . . . . . 13
     4.2.  RD examples  . . . . . . . . . . . . . . . . . . . . . . . 19
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 24
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 24
     6.1.  DNS Security considerations  . . . . . . . . . . . . . . . 24
     6.2.  RD Security considerations . . . . . . . . . . . . . . . . 26
   7.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 26
   8.  Changelog  . . . . . . . . . . . . . . . . . . . . . . . . . . 26
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 26
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 28
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29


















van der Stok, et al.    Expires January 11, 2013                [Page 2]


Internet-Draft   CoRE Discovery, Naming, and Addressing        July 2012


1.  Introduction

   The CoRE working group is chartered to design and standardize a
   Constrained Application Protocol (CoAP) for resource constrained
   devices and networks [I-D.ietf-core-coap].  The requirements for CoRE
   are documented in [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 [I-D.cheshire-dnsext-dns-sd] and Resource Directory (RD)
   [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.

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 RFC 2119 [RFC2119].
   Addtional privileged words are described below.

   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).

   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
   [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 web-linking
   [RFC5988].  'Host' corresponds to the [RFC3986] ABNF production as
   updated by [I-D.ietf-6man-uri-zoneid].

   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
   [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.

   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 [RFC3986].




van der Stok, et al.    Expires January 11, 2013                [Page 3]


Internet-Draft   CoRE Discovery, Naming, and Addressing        July 2012


   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 [I-D.shelby-core-interfaces].  The
   interface definition may specify the naming patterns of subordinate
   resources and the methods that act on them.

   A "Profile" is a group of Function Sets defined by a specification.

   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.

   A "Device type" describes a standardized set of Function Sets that
   satisfy a use case for a hosting device.

   A "group" is a set of end-points.

   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.

1.2.  Motivation

   In this draft, we focus and expand discussions on requirements
   pertaining to discovery, naming, and addressing, including REQ8 of
   the CoRE charter:

   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]

   The basis of this draft originated in [I-D.vanderstok-core-bc].

1.3.  Applicability

   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.




van der Stok, et al.    Expires January 11, 2013                [Page 4]


Internet-Draft   CoRE Discovery, Naming, and Addressing        July 2012


2.  Architecture

   This section illustrates the aspects of naming schemes and their
   support by DNS-based Service Discovery (DNS-SD)
   [I-D.cheshire-dnsext-dns-sd] , Extended Multicast DNS (xmDNS)
   [I-D.lynn-homenet-site-mdns], and the Resource Directory (RD)
   [I-D.shelby-core-resource-directory] on a set of network
   architectures.

   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 [RFC4944], [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:

   - 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.
   - 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.
   - 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.
   - 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.

   In certain scenarios, the domain may correspond to the network
   topology.  In the general case, the domain and network subnet
   structure may differ.


3.  Use Cases

   The use of service discovery is presented in two environments: (1)
   interactive service discovery, and (2) M2M service discovery.  From



van der Stok, et al.    Expires January 11, 2013                [Page 5]


Internet-Draft   CoRE Discovery, Naming, and Addressing        July 2012


   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.

3.1.  Discovery scope

   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 [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.

   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.

3.2.  Interactive mapping

   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



van der Stok, et al.    Expires January 11, 2013                [Page 6]


Internet-Draft   CoRE Discovery, Naming, and Addressing        July 2012


   and an automatically generated DNS name is supported.

3.3.  M2M mapping

   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.

3.4.  End-point grouping

   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.

   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.

   The Function Set specified in a message can contain a collection of
   resources of the same subtype.  The Function Set path postfixed with



van der Stok, et al.    Expires January 11, 2013                [Page 7]


Internet-Draft   CoRE Discovery, Naming, and Addressing        July 2012


   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.

   In [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.

   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.

   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)[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.











van der Stok, et al.    Expires January 11, 2013                [Page 8]


Internet-Draft   CoRE Discovery, Naming, and Addressing        July 2012


   +-------------------------------------------------------------------+
   | "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           | | | |
   | | | +-------------------------------------------------------+ | | |
   | | +-----------------------------------------------------------+ | |
   | +---------------------------------------------------------------+ |
   +-------------------------------------------------------------------+

       Figure 1: device with end-points, Function Sets and resources



van der Stok, et al.    Expires January 11, 2013                [Page 9]


Internet-Draft   CoRE Discovery, Naming, and Addressing        July 2012


3.5.  Discovery queries

   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.

   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:

   Goal            Description
   Name_resolution Resolve the group or device name to IP address and
                   optional port number
   Return_server   Return all end-points (Function-Sets) supporting a
                   given service (sub-)type within a given domain
   Create_group    Create a group of end-points providing a given
                   service (sub-)type within a given domain
   Enroll_member   Enroll an end-point as member of a given group
   Remove_member   Remove an end-point as member of a given group
   Return_group    Return all groups of which a given end-point (device)
                   is a member
   Return_member   Return end-points belonging to a given group

   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.

   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 [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).

   Create_group is useful in commissioning scenarios, where end-points



van der Stok, et al.    Expires January 11, 2013               [Page 10]


Internet-Draft   CoRE Discovery, Naming, and Addressing        July 2012


   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.

   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.

   Remove_member, see motivation under Enroll_member

   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.

   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.

3.6.  Sleeping devices

   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 [I-D.giacomin-core-sleepy-option] and in
   [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
   [I-D.giacomin-core-sleepy-option] and in
   [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.



van der Stok, et al.    Expires January 11, 2013               [Page 11]


Internet-Draft   CoRE Discovery, Naming, and Addressing        July 2012


   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
   [I-D.ietf-core-groupcomm]).  A simple broadcast over a lowpan will
   not always succceed and additional multicast algorithms like Trickle
   [RFC6206] need to be introduced.


4.  DNS and RD examples

   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.

   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.

   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.

   The examples are constructed such that DNS can be used as repository
   for the RD.




van der Stok, et al.    Expires January 11, 2013               [Page 12]


Internet-Draft   CoRE Discovery, Naming, and Addressing        July 2012


4.1.  DNS-SD examples

4.1.1.  Basic Concepts

   In conformance with [I-D.cheshire-dnsext-dns-sd], DNS-based discovery
   uses A or AAAA, PTR, SRV, and TXT Resource Records (RR).  The SRV RR
   [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 [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.

   In cases where the end-point port may be dynamic, e.g. in the IPHC
   [RFC6282] compressible range, a new 'coap+srv' scheme is proposed
   (after [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.

4.1.2.  Commissioning devices

   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.

   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.

   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



van der Stok, et al.    Expires January 11, 2013               [Page 13]


Internet-Draft   CoRE Discovery, Naming, and Addressing        July 2012


   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.

4.1.3.  device examples

   The relation between device name and IP address is expressed for the
   example devices in the following table.

                lm00203.ry.fx.bldg.org. IN AAAA fdfd::1234
                lm00204.ry.fx.bldg.org. IN AAAA fdfd::1235
                ps0057.ry.fx.bldg.org.  IN AAAA fdfd::1236
                pir1.ry.fx.bldg.org.    IN AAAA fdfd::1237
                lm00205.rz.fx.bldg.org. IN AAAA fdfd::1238
                lm00206.rz.fx.bldg.org. IN AAAA fdfd::1239
                ps0058.rz.fx.bldg.org.  IN AAAA fdfd::1240
                pir2.rz.fx.bldg.org.    IN AAAA fdfd::1241
                clock.fx.bldg.org.      IN AAAA fdfd::1242

   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
   [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".

   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.












van der Stok, et al.    Expires January 11, 2013               [Page 14]


Internet-Draft   CoRE Discovery, Naming, and Addressing        July 2012


             end-point                  host name
             1234_bc   IN SRV 0 0 Port  lm00203.ry.fx.bldg.org
                       IN TXT txtvers=1
             2345_bc   IN SRV 0 0 Port  lm00204.ry.fx.bldg.org
                       IN TXT txtvers=1
             3456_bc   IN SRV 0 0 Port  lm00205.rz.fx.bldg.org
                       IN TXT txtvers=1
             4567_bc   IN SRV 0 0 Port  lm00206.rz.fx.bldg.org
                       IN TXT txtvers=1
             5678_bc   IN SRV 0 0 Port  ps0057.ry.fx.bldg.org
                       IN TXT txtvers=1
             6789_bc   IN SRV 0 0 Port  ps0058.rz.fx.bldg.org
                       IN TXT txtvers=1
             7890_bc   IN SRV 0 0 Port  pir1.ry.fx.bldg.org
                       IN TXT txtvers=1
             8901_bc   IN SRV 0 0 Port  pir2.rz.fx.bldg.org
                       IN TXT txtvers=1
             9012_bc   IN SRV 0 0 Port  clock.fx.bldg.org
                       IN TXT txtvers=1

   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:


























van der Stok, et al.    Expires January 11, 2013               [Page 15]


Internet-Draft   CoRE Discovery, Naming, and Addressing        July 2012


     Function Set                              host name
     1234lamp     IN SRV 0 0 Port              lm00203.ry.fx.bldg.org
                  IN TXT txtvers=1 path=/lamp
     1234sensor   IN SRV 0 0 Port              lm00203.ry.fx.bldg.org
                  IN TXT txtvers=1 path=/light
     2345lamp     IN SRV 0 0 Port              lm00204.ry.fx.bldg.org
                  IN TXT txtvers=1 path=/lamp
     2345sensor   IN SRV 0 0 Port              lm00204.ry.fx.bldg.org
                  IN TXT txtvers=1 path=/light
     5678power    IN SRV 0 0 Port              ps0057.ry.fx.bldg.org
                  IN TXT txtvers=1 path=/ps
     7890presence IN SRV 0 0 Port              pir1.ry.fx.bldg.org
                  IN TXT txtvers=1 path=/occup
     3456lamp     IN SRV 0 0 Port              lm00205.rz.fx.bldg.org
                  IN TXT txtvers=1 path=/lamp
     3456sensor   IN SRV 0 0 Port              lm00205.rz.fx.bldg.org
                  IN TXT txtvers=1 path=/light
     4567lamp     IN SRV 0 0 Port              lm00206.rz.fx.bldg.org
                  IN TXT txtvers=1 path=/lamp
     4567sensor   IN SRV 0 0 Port              lm00206.rz.fx.bldg.org
                  IN TXT txtvers=1 path=/light
     6789power    IN SRV 0 0 Port              ps0058.rz.fx.bldg.org
                  IN TXT txtvers=1 path=/ps
     8901presence IN SRV 0 0 Port              pir2.rz.fx.bldg.org
                  IN TXT txtvers=1 path=/occup
     9012timer    IN SRV 0 0 Port              clock.fx.bldg.org
                  IN TXT txtvers=1 path=/time

   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.

   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.

                lamp._sub._bc._udp.bldg.org IN PTR 1234lamp
                lamp._sub._bc._udp.bldg.org IN PTR 2345lamp
                lamp._sub._bc._udp.bldg.org IN PTR 3456lamp
                lamp._sub._bc._udp.bldg.org IN PTR 4567lamp

   Where xxxxlamp is still short for xxxxlamp._sub._bc._udp.bldg.org.



van der Stok, et al.    Expires January 11, 2013               [Page 16]


Internet-Draft   CoRE Discovery, Naming, and Addressing        July 2012


   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.

              _bc._udp.bldg.org IN PTR 1234_bc._udp.bldg.org
              _bc._udp.bldg.org IN PTR 2345_bc._udp.bldg.org
              _bc._udp.bldg.org IN PTR 3456_bc._udp.bldg.org
              _bc._udp.bldg.org IN PTR 4567_bc._udp.bldg.org
              _bc._udp.bldg.org IN PTR 5678_bc._udp.bldg.org
              _bc._udp.bldg.org IN PTR etc, etc.

   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.

            lamp._sub._bc._udp.ry.fx.bldg.org. IN PTR 1234lamp
            lamp._sub._bc._udp.ry.fx.bldg.org. IN PTR 2345lamp

4.1.4.  Group examples

   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.

                 lamp-fx.fx.bldg.org.    IN AAAA ff15::11
                 lamp-ry.ry.fx.bldg.org. IN AAAA ff15::12
                 lamp-rz.rz.fx.bldg.org. IN AAAA ff15::13
                 power-fx.fx.bldg.org.   IN AAAA ff15::14
                 timer-bldg.bldg.org.    IN AAAA ff15::15

   It is expected that SDOs will specify naming conventions for group
   names, extending the service (sub)type names for end-points and
   Function Sets.

   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.)






van der Stok, et al.    Expires January 11, 2013               [Page 17]


Internet-Draft   CoRE Discovery, Naming, and Addressing        July 2012


            gp1-lamp IN SRV 0 0 Port   lamp-fx.fx.bldg.org.
                     IN TXT path=/lamp
            gp2-lamp IN SRV 0 0 Port   lamp-ry.ry.fx.bldg.org.
                     IN TXT path=/lamp
            gp3-lamp IN SRV 0 0 Port   lamp-rz.rz.fx.bldg.org.
                     IN TXT path=/lamp
            gp-power IN SRV 0 0 Port   power-fx.fx.bldg.org.
                     IN TXT path=/ps
            gp-timer IN SRV 0 0 Port   timer-bldg.bldg.org.
                     IN TXT path=/time

   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.

   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.

       1.1.0.....0.5.1.f.f.IP6.arpa. IN PTR lm00206.rz.fx.bldg.org.
       1.1.0.....0.5.1.f.f.IP6.arpa. IN PTR lm00205.rz.fx.bldg.org.
       1.1.0.....0.5.1.f.f.IP6.arpa. IN PTR lm00204.ry.fx.bldg.org.
       1.1.0.....0.5.1.f.f.IP6.arpa. IN PTR lm00203.ry.fx.bldg.org.
       1.1.0.....0.5.1.f.f.IP6.arpa. IN PTR lamp-fx.fx.bldg.org.

   With the above table queries like "return all members of lamp-fx" can
   be answered.

   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":

                  1234lamp IN PTR lamp-fx.fx.bldg.org
                  1234lamp IN PTR lamp-ry.ry.fx.bldg.org

   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.



van der Stok, et al.    Expires January 11, 2013               [Page 18]


Internet-Draft   CoRE Discovery, Naming, and Addressing        July 2012


4.1.5.  Discovery validation

   This section describes how the disovery requirements are met with
   DNS-SD.  It is assumed that the DNS server tables are correctly
   filled in.

   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.

   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.

   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.

   Enroll-member, Remove-member: See Create-Group.

   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.

   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.

4.2.  RD examples

   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" [RFC5785] is
   a default Function Set for requesting the list of links on a given
   server [I-D.shelby-core-resource-directory].  The Resource Directory
   (RD) stores links to resources hosted by other servers.  The link-



van der Stok, et al.    Expires January 11, 2013               [Page 19]


Internet-Draft   CoRE Discovery, Naming, and Addressing        July 2012


   format [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.

   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.

   This draft adheres to the mapping between DNS and link-format,
   described in [I-D.lynn-core-discovery-mapping].

4.2.1.  Commissioning devices

   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 [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.

   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.

   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.

4.2.2.  Device examples

   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.




van der Stok, et al.    Expires January 11, 2013               [Page 20]


Internet-Draft   CoRE Discovery, Naming, and Addressing        July 2012


           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

   The other end-points are defined with (leaving out the response):

           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"



























van der Stok, et al.    Expires January 11, 2013               [Page 21]


Internet-Draft   CoRE Discovery, Naming, and Addressing        July 2012


           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"

   Update or removal of the groups is done by using the returned
   location (not shown above) as described in
   [I-D.shelby-core-resource-directory] for the end-points.

4.2.3.  Group examples

   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.





van der Stok, et al.    Expires January 11, 2013               [Page 22]


Internet-Draft   CoRE Discovery, Naming, and Addressing        July 2012


           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

   With the above statements the groups are defined in the RD.

4.2.4.  Discovery validation

   This section describes how the disovery requirements are met with the
   RD.  It is assumed that the RD tables are correctly filled in.

   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.

   Return_server: Suppose the given service is defined by
   instance._sub._service.  The query

           GET coap://rd.example.com/rd-lookup/res?rt=instance.
                                                _sub._service
           Res: 2.05 content
           <coap://name.domain/path>;rt="instance._sub._service"

   returns all Function Sets providing the specified service.  By
   changing the "res?" part in the query by "ep?" all end-points are
   returned.



van der Stok, et al.    Expires January 11, 2013               [Page 23]


Internet-Draft   CoRE Discovery, Naming, and Addressing        July 2012


   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.

   Enroll-member, Remove-member: See Create-Group.

   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

           GET coap://rd.example.com/rd-lookup/gp?ep=ep.domain
           Res: 2.05 content
           <coap://name.domain/path>;gp="group.domain"

   returns all groups of which the specified end-point, ep.domain, is a
   member.

   Return-member: The members of a group with name group group.domain
   are found by the query

           GET coap://rd.example.com/rd-lookup/ep?gp=group.domain
           Res: 2.05 content
           <coap://name.domain/path>;ep="ep.domain"

   which returns all end-points which are member of the group gp.domain.


5.  IANA Considerations

   This document makes no request of IANA.

   Note to RFC Editor: this section may be removed on publication as an
   RFC.


6.  Security Considerations

   Security considerations apply to use of DNS and RD separately,
   because they use different security mechanisms.

6.1.  DNS Security considerations

   Security extensions for DNS are provided by Domain Name System
   Security Extensions (DNSSEC) as described in [RFC4033], [RFC4034],
   and [RFC4035].  In particular [RFC4033] describes all documents
   relevant to DNSSEC.  The central design decision of DNSSEC is to
   provide origin authentication and integrity protection for DNS data.



van der Stok, et al.    Expires January 11, 2013               [Page 24]


Internet-Draft   CoRE Discovery, Naming, and Addressing        July 2012


   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.

   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 [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.

   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) [RFC2931] or TSIG [RFC2845].

   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.






van der Stok, et al.    Expires January 11, 2013               [Page 25]


Internet-Draft   CoRE Discovery, Naming, and Addressing        July 2012


6.2.  RD Security considerations

   Security for Resource Direcory is provided by recommended CoAP
   security techniques: DTLS.


7.  Acknowledgments

   Zach Shelby wrote the original Discovery section in
   [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.

   Sye Loong Keoh, Sandeep Kumar, and Oscar Garcia Morchon contributed
   actively to security considerations.


8.  Changelog

   Changes from -02 to -03:
   o  adapted to resource direcory version -03
   o  DNS-SD examples follow better DNS-SD naming conventions
   o  added gp= link-format attribute
   o  added security considerations
   o  groups of end-points and groups of Function Sets instead of groups
      of devices
   o  less centered around DNS, more RD aspects


9.  References

9.1.  Normative References

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, November 1987.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2782]  Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
              specifying the location of services (DNS SRV)", RFC 2782,
              February 2000.

   [RFC2845]  Vixie, P., Gudmundsson, O., Eastlake, D., and B.
              Wellington, "Secret Key Transaction Authentication for DNS
              (TSIG)", RFC 2845, May 2000.



van der Stok, et al.    Expires January 11, 2013               [Page 26]


Internet-Draft   CoRE Discovery, Naming, and Addressing        July 2012


   [RFC2931]  Eastlake, D., "DNS Request and Transaction Signatures (
              SIG(0)s)", RFC 2931, September 2000.

   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66,
              RFC 3986, January 2005.

   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "DNS Security Introduction and Requirements",
              RFC 4033, March 2005.

   [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "Resource Records for the DNS Security Extensions",
              RFC 4034, March 2005.

   [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "Protocol Modifications for the DNS Security
              Extensions", RFC 4035, March 2005.

   [RFC4193]  Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
              Addresses", RFC 4193, October 2005.

   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 4291, February 2006.

   [RFC4605]  Fenner, B., He, H., Haberman, B., and H. Sandick,
              "Internet Group Management Protocol (IGMP) / Multicast
              Listener Discovery (MLD)-Based Multicast Forwarding
              ("IGMP/MLD Proxying")", RFC 4605, August 2006.

   [RFC4944]  Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
              "Transmission of IPv6 Packets over IEEE 802.15.4
              Networks", RFC 4944, September 2007.

   [RFC5234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234, January 2008.

   [RFC5785]  Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known
              Uniform Resource Identifiers (URIs)", RFC 5785,
              April 2010.

   [RFC5988]  Nottingham, M., "Web Linking", RFC 5988, October 2010.

   [RFC6282]  Hui, J. and P. Thubert, "Compression Format for IPv6
              Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,
              September 2011.

   [RFC6206]  Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko,



van der Stok, et al.    Expires January 11, 2013               [Page 27]


Internet-Draft   CoRE Discovery, Naming, and Addressing        July 2012


              "The Trickle Algorithm", RFC 6206, March 2011.

9.2.  Informative References

   [I-D.cheshire-dnsext-dns-sd]
              Cheshire, S. and M. Krochmal, "DNS-Based Service
              Discovery", draft-cheshire-dnsext-dns-sd-11 (work in
              progress), December 2011.

   [I-D.eggert-core-congestion-control]
              Eggert, L., "Congestion Control for the Constrained
              Application Protocol (CoAP)",
              draft-eggert-core-congestion-control-01 (work in
              progress), January 2011.

   [I-D.ietf-6man-uri-zoneid]
              Carpenter, B. and R. Hinden, "Representing IPv6 Zone
              Identifiers in Uniform Resource Identifiers",
              draft-ietf-6man-uri-zoneid-01 (work in progress),
              May 2012.

   [I-D.ietf-core-coap]
              Shelby, Z., Hartke, K., Bormann, C., and B. Frank,
              "Constrained Application Protocol (CoAP)",
              draft-ietf-core-coap-10 (work in progress), June 2012.

   [I-D.ietf-core-groupcomm]
              Rahman, A. and E. Dijk, "Group Communication for CoAP",
              draft-ietf-core-groupcomm-01 (work in progress),
              March 2012.

   [I-D.ietf-core-link-format]
              Shelby, Z., "CoRE Link Format",
              draft-ietf-core-link-format-14 (work in progress),
              June 2012.

   [I-D.lynn-core-discovery-mapping]
              Lynn, K. and Z. Shelby, "CoRE Link-Format to DNS-Based
              Service Discovery Mapping",
              draft-lynn-core-discovery-mapping-01 (work in progress),
              July 2011.

   [I-D.lynn-homenet-site-mdns]
              Lynn, K. and D. Sturek, "Extended Multicast DNS",
              draft-lynn-homenet-site-mdns-00 (work in progress),
              March 2012.

   [I-D.shelby-core-coap-req]



van der Stok, et al.    Expires January 11, 2013               [Page 28]


Internet-Draft   CoRE Discovery, Naming, and Addressing        July 2012


              Shelby, Z., Stuber, M., Sturek, D., Frank, B., and R.
              Kelsey, "CoAP Requirements and Features",
              draft-shelby-core-coap-req-02 (work in progress),
              October 2010.

   [I-D.shelby-core-interfaces]
              Shelby, Z. and M. Vial, "CoRE Interfaces",
              draft-shelby-core-interfaces-02 (work in progress),
              March 2012.

   [I-D.shelby-core-resource-directory]
              Shelby, Z. and S. Krco, "CoRE Resource Directory",
              draft-shelby-core-resource-directory-03 (work in
              progress), May 2012.

   [I-D.vanderstok-core-bc]
              Stok, P. and K. Lynn, "CoAP Utilization for Building
              Control", draft-vanderstok-core-bc-05 (work in progress),
              October 2011.

   [I-D.jennings-http-srv]
              Jennings, C., "DNS SRV Records for HTTP",
              draft-jennings-http-srv-05 (work in progress), March 2009.

   [I-D.giacomin-core-sleepy-option]
              Fossati, T., Giacomin, P., Loreto, S., and M. Rossini,
              "Sleepy Option for CoAP",
              draft-giacomin-core-sleepy-option-00 (work in progress),
              February 2012.

   [I-D.vial-core-mirror-proxy]
              Vial, M., "CoRE Mirror Proxy",
              draft-vial-core-mirror-proxy-00 (work in progress),
              March 2012.

   [ZeroConf]
              Cheshire, S. and D. Steinberg, "Zero Configuration
              Networking: The Definitive Guide", O'Reilly Media, Inc. ,
              ISBN 0-596-10100-7, 2006.

   [UPNP]     "Universal Plug and Play", Web http://www.upnp.org, 2012.










van der Stok, et al.    Expires January 11, 2013               [Page 29]


Internet-Draft   CoRE Discovery, Naming, and Addressing        July 2012


Authors' Addresses

   Peter van der Stok (editor)
   vanderstok consultancy
   Kamperfoelie 8
   Helmond,   5708 DM
   The Netherlands

   Email: consultancy@vanderstok.org


   Kerry Lynn
   Consultant

   Phone: +1-978-460-4253
   Email: kerlyn@ieee.org


   Anders Brandt
   Sigma Designs
   Emdrupvej 26A, 1.
   Copenhagen O,   2100
   Denmark

   Email: Anders_Brandt@sigmadesigns.com


























van der Stok, et al.    Expires January 11, 2013               [Page 30]


Html markup produced by rfcmarkup 1.126, available from https://tools.ietf.org/tools/rfcmarkup/