[Docs] [txt|pdf|xml|html] [Tracker] [WG] [Email] [Nits]

Versions: 00

CoRE                                                             K. Lynn
Internet-Draft                                              Verizon Labs
Intended status: Standards Track                         P. van der Stok
Expires: January 4, 2018                                      consultant
                                                               M. Koster
                                                         C. Amsuess, Ed.
                                             Energy Harvesting Solutions
                                                           July 03, 2017

                CoRE Resource Directory: DNS-SD mapping



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 4, 2018.

Copyright Notice

   Copyright (c) 2017 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
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of

Lynn, et al.             Expires January 4, 2018                [Page 1]

Internet-Draft   CoRE Resource Directory: DNS-SD mapping       July 2017

   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  New Link-Format Attributes  . . . . . . . . . . . . . . . . .   3
     2.1.  Resource Instance attribute 'ins' . . . . . . . . . . . .   3
     2.2.  Export attribute 'exp'  . . . . . . . . . . . . . . . . .   3
   3.  DNS-SD Mapping  . . . . . . . . . . . . . . . . . . . . . . .   4
     3.1.  DNS-based Service discovery . . . . . . . . . . . . . . .   4
     3.2.  mapping ins to <Instance> . . . . . . . . . . . . . . . .   5
     3.3.  Mapping rt to <ServiceType> . . . . . . . . . . . . . . .   5
     3.4.  Domain mapping  . . . . . . . . . . . . . . . . . . . . .   6
     3.5.  TXT Record key=value strings  . . . . . . . . . . . . . .   6
     3.6.  Importing resource links into DNS-SD  . . . . . . . . . .   6
   4.  Examples  . . . . . . . . . . . . . . . . . . . . . . . . . .   7
     4.1.  DNS entries . . . . . . . . . . . . . . . . . . . . . . .   7
   5.  IANA considerations . . . . . . . . . . . . . . . . . . . . .   8
   6.  Security considerations . . . . . . . . . . . . . . . . . . .   8
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   9
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  10
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Introduction

   TBD ... [RFC7252] ... [I-D.ietf-core-resource-directory] ... DNS-SD

1.1.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "OPTIONAL" in this document are to be interpreted as described in
   [RFC2119].  The term "byte" is used in its now customary sense as a
   synonym for "octet".

   This specification requires readers to be familiar with all the terms
   and concepts that are discussed in [RFC5988] and [RFC6690].  Readers
   should also be familiar with the terms and concepts discussed in
   [RFC7252].  To describe the REST interfaces defined in this
   specification, the URI Template format is used [RFC6570].

   This specification makes use of the terminology of

Lynn, et al.             Expires January 4, 2018                [Page 2]

Internet-Draft   CoRE Resource Directory: DNS-SD mapping       July 2017

   This specification makes use of the following additional terminology:

   TBD:  TBD

   TBD:  TBD

2.  New Link-Format Attributes

   When using the CoRE Link Format to describe resources being
   discovered by or posted to a resource directory service, additional
   information about those resources is useful.  This specification
   defines the following new attributes for use in the CoRE Link Format

      link-extension    = ( "ins" "=" (ptoken | quoted-string) )
                          ; The token or string is max 63 bytes
      link-extension    = ( "exp" )

2.1.  Resource Instance attribute 'ins'

   The Resource Instance "ins" attribute is an identifier for this
   resource, which makes it possible to distinguish it from other
   similar resources.  This attribute is similar in use to the
   <Instance> portion of a DNS-SD record (see Section 3.1, and SHOULD be
   unique across resources with the same Resource Type attribute in the
   domain it is used.  A Resource Instance might be a descriptive string
   like "Ceiling Light, Room 3", a short ID like "AF39" or a unique UUID
   or iNumber.  This attribute is used by a Resource Directory to
   distinguish between multiple instances of the same resource type
   within the directory.

   This attribute MUST be no more than 63 bytes in length.  The resource
   identifier attribute MUST NOT appear more than once in a link
   description.  This attribute MAY be used as a query parameter in the
   RD Lookup Function Set defined in Section 7.

2.2.  Export attribute 'exp'

   The Export "exp" attribute is used as a flag to indicate that a link
   description MAY be exported by a resource directory to external

   The CoRE Link Format is used for many purposes between CoAP
   endpoints.  Some are useful mainly locally, for example checking the
   observability of a resource before accessing it, determining the size
   of a resource, or traversing dynamic resource structures.  However,
   other links are very useful to be exported to other directories, for
   example the entry point resource to a functional service.  This

Lynn, et al.             Expires January 4, 2018                [Page 3]

Internet-Draft   CoRE Resource Directory: DNS-SD mapping       July 2017

   attribute MAY be used as a query parameter in the RD Lookup Function
   Set defined in Section 7.

3.  DNS-SD Mapping

   CoRE Resource Discovery is intended to support fine-grained discovery
   of hosted resources, their attributes, and possibly other resource
   relations [RFC6690].  In contrast, service discovery generally refers
   to a coarse-grained resolution of an endpoint's IP address, port
   number, and protocol.

   Resource and service discovery are complementary in the case of large
   networks, where the latter can facilitate scaling.  This document
   defines a mapping between CoRE Link Format attributes and DNS-Based
   Service Discovery [RFC6763] fields that permits discovery of CoAP
   services by either method.

3.1.  DNS-based Service discovery

   DNS-Based Service Discovery (DNS-SD) defines a conventional method of
   configuring DNS PTR, SRV, and TXT resource records to facilitate
   discovery of services (such as CoAP servers in a subdomain) using the
   existing DNS infrastructure.  This section gives a brief overview of
   DNS-SD; see [RFC6763] for a detailed specification.

   DNS-SD service names are limited to 255 octets and are of the form:

   Service Name = <Instance>.<ServiceType>.<Domain>.

   The service name is the label of SRV/TXT resource records.  The SRV
   RR specifies the host and the port of the endpoint.  The TXT RR
   provides additional information in the form of key/value pairs.

   The <Domain> part of the service name is identical to the global (DNS
   subdomain) part of the authority in URIs that identify servers or
   groups of servers.

   The <ServiceType> part is composed of at least two labels.  The first
   label of the pair is the application protocol name [RFC6335] preceded
   by an underscore character.  The second label indicates the transport
   and is always "_udp" for UDP-based CoAP services.  In cases where
   narrowing the scope of the search may be useful, these labels may be
   optionally preceded by a subtype name followed by the "_sub" label.
   An example of this more specific <ServiceType> is

   A default <Instance> part of the service name may be set at the
   factory or during the commissioning process.  It SHOULD uniquely

Lynn, et al.             Expires January 4, 2018                [Page 4]

Internet-Draft   CoRE Resource Directory: DNS-SD mapping       July 2017

   identify an instance of <ServiceType> within a <Domain>.  Taken
   together, these three elements comprise a unique name for an SRV/ TXT
   record pair within the DNS subdomain.

   The granularity of a service name MAY be that of a host or group, or
   it could represent a particular resource within a CoAP server.  The
   SRV record contains the host name (AAAA record name) and port of the
   service while protocol is part of the service name.  In the case
   where a service name identifies a particular resource, the path part
   of the URI must be carried in a corresponding TXT record.

   A DNS TXT record is in practice limited to a few hundred octets in
   length, which is indicated in the resource record header in the DNS
   response message.  The data consists of one or more strings
   comprising a key=value pair.  By convention, the first pair is
   txtver=<number> (to support different versions of a service

3.2.  mapping ins to <Instance>

   The Resource Instance "ins" attribute maps to the <Instance> part of
   a DNS-SD service name.  It is stored directly in the DNS as a single
   DNS label of canonical precomposed UTF-8 [RFC3629] "Net-Unicode"
   (Unicode Normalization Form C) [RFC5198] text.  However, to the
   extent that the "ins" attribute may be chosen to match the DNS host
   name of a service, it SHOULD use the syntax defined in Section 3.5 of
   [RFC1034] and Section 2.1 of [RFC1123].

   The <Instance> part of the name of a service being offered on the
   network SHOULD be configurable by the user setting up the service, so
   that he or she may give it an informative name.  However, the device
   or service SHOULD NOT require the user to configure a name before it
   can be used.  A sensible choice of default name can allow the device
   or service to be accessed in many cases without any manual
   configuration at all.  The default name should be short and
   descriptive, and MAY include a collision-resistant substring such as
   the lower bits of the device's MAC address, serial number,
   fingerprint, or other identifier in an attempt to make the name
   relatively unique.

   DNS labels are currently limited to 63 octets in length and the
   entire service name may not exceed 255 octets.

3.3.  Mapping rt to <ServiceType>

   The resource type "rt" attribute is mapped into the <ServiceType>
   part of a DNS-SD service name and SHOULD conform to the reg-rel-type
   production of the Link Format defined in Section 2 of [RFC6690].  The

Lynn, et al.             Expires January 4, 2018                [Page 5]

Internet-Draft   CoRE Resource Directory: DNS-SD mapping       July 2017

   "rt" attribute MUST be composed of at least a single Net-Unicode text
   string, without underscore '_' or period '.' and limited to 15 octets
   in length, which represents the application protocol name.  This
   string is mapped to the DNS-SD <ServiceType> by prepending an
   underscore and appending a period followed by the "_udp" label.  For
   example, rt="dali" is mapped into "_dali._udp".

   The application protocol name may be optionally followed by a period
   and a service subtype name consisting of a Net-Unicode text string,
   without underscore or period and limited to 63 octets.  This string
   is mapped to the DNS-SD <ServiceType> by appending a period followed
   by the "_sub" label and then appending a period followed by the
   service type label pair derived as in the previous paragraph.  For
   example, rt="dali.light" is mapped into "light._sub._dali._udp".

   The resulting string is used to form labels for DNS-SD records which
   are stored directly in the DNS.

3.4.  Domain mapping

   DNS domains may be derived from the "d" attribute.  The domain
   attribute may be suffixed with the zone name of the authoritative DNS
   server to generate the domain name.  The "ep" attribute is prefixed
   to the domain name to generate the FQDN to be stored into DNS with an

3.5.  TXT Record key=value strings

   A number of [RFC6763] key/value pairs are derived from link-format
   information, to be exported in the DNS-SD as key=value strings in a
   TXT record ([RFC6763], Section 6.3).

   The resource <URI> is exported as key/value pair "path=<URI>".

   The Interface Description "if" attribute is exported as key/value
   pair "if=<Interface Description>".

   The DNS TXT record can be further populated by importing any other
   resource description attributes as they share the same key=value
   format specified in Section 6 of [RFC6763].

3.6.  Importing resource links into DNS-SD

   Assuming the ability to query a Resource Directory or multicast a GET
   (?exp) over the local link, CoAP resource discovery may be used to
   populate the DNS-SD database in an automated fashion.  CoAP resource
   descriptions (links) can be exported to DNS-SD for exposure to
   service discovery by using the Resource Instance attribute as the

Lynn, et al.             Expires January 4, 2018                [Page 6]

Internet-Draft   CoRE Resource Directory: DNS-SD mapping       July 2017

   basis for a unique service name, composed with the Resource Type as
   the <ServiceType>, and registered in the correct <Domain>.  The agent
   responsible for exporting records to the DNS zone file SHOULD be
   authenticated to the DNS server.  The following example, using the
   example lookup location /rd-lookup, shows an agent discovering a
   resource to be exported:

      Req: GET /rd-lookup/res?exp

      Res: 2.05 Content

   The agent subsequently registers the following DNS-SD RRs, assuming a
   zone name "example.com" prefixed with "office":

   node1.office.example.com.          IN AAAA        FDFD::1234
   _dali._udp.office.example.com      IN PTR
   light._sub._dali._udp.example.com  IN PTR
   Spot._dali._udp.office.example.com IN SRV  0 0 5683
   Spot._dali._udp.office.example.com IN TXT

   In the above figure the Service Name is chosen as
   Spot._dali._udp.office.example.com without the light._sub service
   prefix.  An alternative Service Name would be:

4.  Examples

4.1.  DNS entries

   It may be profitable to discover the light groups for applications,
   which are unaware ot the existence of the RD.  An agent needs to
   query the RD to return all groups which are exported to be inserted
   into DNS.

Lynn, et al.             Expires January 4, 2018                [Page 7]

Internet-Draft   CoRE Resource Directory: DNS-SD mapping       July 2017

      Req: GET /rd-lookup/gp?exp

      Res: 2.05 Content

   The group with FQDN grp_R2-4-015.bc.example.com can be entered into
   the DNS by the agent.  The accompanying instance name is grp1234.
   The <ServiceType> is chosen to be _group._udp.  The agent enters the
   following RRs into the DNS.

   grp_R2-4-015.bc.example.com.        IN AAAA            FF05::1
   _group._udp.bc.example.com          IN PTR
   grp1234._group._udp.bc.example.com  IN SRV  0 0 5683
   grp1234._group._udp.bc.example.com  IN TXT

   From then on applications, not familiar with the existence of the RD,
   can use DNS to access the lighting group.

5.  IANA considerations


6.  Security considerations


7.  References

7.1.  Normative References

              Shelby, Z., Koster, M., Bormann, C., and P. Stok, "CoRE
              Resource Directory", draft-ietf-core-resource-directory-10
              (work in progress), March 2017.

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

Lynn, et al.             Expires January 4, 2018                [Page 8]

Internet-Draft   CoRE Resource Directory: DNS-SD mapping       July 2017

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

   [RFC6335]  Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S.
              Cheshire, "Internet Assigned Numbers Authority (IANA)
              Procedures for the Management of the Service Name and
              Transport Protocol Port Number Registry", BCP 165,
              RFC 6335, DOI 10.17487/RFC6335, August 2011,

   [RFC6570]  Gregorio, J., Fielding, R., Hadley, M., Nottingham, M.,
              and D. Orchard, "URI Template", RFC 6570,
              DOI 10.17487/RFC6570, March 2012,

   [RFC6690]  Shelby, Z., "Constrained RESTful Environments (CoRE) Link
              Format", RFC 6690, DOI 10.17487/RFC6690, August 2012,

   [RFC6763]  Cheshire, S. and M. Krochmal, "DNS-Based Service
              Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,

7.2.  Informative References

   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
              STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,

   [RFC1123]  Braden, R., Ed., "Requirements for Internet Hosts -
              Application and Support", STD 3, RFC 1123,
              DOI 10.17487/RFC1123, October 1989,

   [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
              10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
              2003, <http://www.rfc-editor.org/info/rfc3629>.

   [RFC5198]  Klensin, J. and M. Padlipsky, "Unicode Format for Network
              Interchange", RFC 5198, DOI 10.17487/RFC5198, March 2008,

   [RFC7252]  Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
              Application Protocol (CoAP)", RFC 7252,
              DOI 10.17487/RFC7252, June 2014,

Lynn, et al.             Expires January 4, 2018                [Page 9]

Internet-Draft   CoRE Resource Directory: DNS-SD mapping       July 2017


   This document was split off from [I-D.ietf-core-resource-directory].
   TODO: Copy over relevant acknowledgements.

Authors' Addresses

   Kerry Lynn
   Verizon Labs
   50 Sylvan Rd
   Waltham, MA  02451

   Phone: +1 781 296 9722
   Email: kerlyn@ieee.org

   Peter van der Stok

   Phone: +31-492474673 (Netherlands), +33-966015248 (France)
   Email: consultancy@vanderstok.org
   URI:   www.vanderstok.org

   Michael Koster
   665 Clyde Avenue
   Mountain View  94043

   Phone: +1-707-502-5136
   Email: Michael.Koster@smartthings.com

   Christian Amsuess (editor)
   Energy Harvesting Solutions
   Hollandstr. 12/4

   Phone: +43-664-9790639
   Email: c.amsuess@energyharvesting.at

Lynn, et al.             Expires January 4, 2018               [Page 10]

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