Subject: Re: [core] #370 (resource-directory): Integrate the DNS-SD mapping

From: "core issue tracker" <[email-masked]>
Date: Sat, 25 Oct 2014 19:54:14 -0000

#370: Integrate the DNS-SD mapping

Changes (by [email-masked]):

 * status:  new => closed
 * resolution:   => fixed

Comment:

 Integrated contribution from Peter Van Der Stok in -02.

 9.  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 end-point'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 means.

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

 Shelby & Bormann         Expires April 28, 2015                [Page 25]

 Internet-Draft           CoRE Resource Directory            October 2014

    provides additional information.

    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 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 "lamp._sub._dali._udp".

    The default <Instance> part of the service name may be set at the
    factory or during the commissioning process.  It SHOULD uniquely
    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
    description).

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

 Shelby & Bormann         Expires April 28, 2015                [Page 26]

 Internet-Draft           CoRE Resource Directory            October 2014

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

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

 9.4.  Domain mapping

    DNS zones are defined from the "d" attribute.The domain attribute is
    suffixed to the host name and should be consistent with the domain
    name attributed to the hosting network segment.

 9.5.  TXT Record key=value strings

    The resource <URI> is exported to the TXT record key=value string
    "path=<URI>".

    The Interface Description "if" attribute is exported to the TXT
    record key=value string "if=<Interface Description>".

 Shelby & Bormann         Expires April 28, 2015                [Page 27]

 Internet-Draft           CoRE Resource Directory            October 2014

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

 9.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
    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 shows an
    agent discovering a resource to be exported:

        Agent                                                          RD
          |                                                             |
          | --- GET /rd-lookup/res?exp ------------------------------>  |
          |                                                             |
          |                                                             |
          | <-- 2.05 Content "<coap://node1/light/1>;exp; ------------  |
          |                   rt="dali.light";ins="FrontSpot"           |
          |                   d="example.com"                           |
          |                                                             |

       Req: GET /rd-lookup/res?exp

       Res: 2.05 Content
       <coap://[FDFD::1234]:61616/light/1>;
         exp;ct=41;rt="dali.light";ins="FrontSpot";
                   d="example.com"

    The agent subsequenly registers the following DNS-SD RRs:

 Shelby & Bormann         Expires April 28, 2015                [Page 28]

 Internet-Draft           CoRE Resource Directory            October 2014

    node1.example.com.                IN AAAA
                              FDFD::1234
    _dali._udp.example.com            IN PTR
                              FrontSpot._dali._udp.example.com
    light._sub._dali._udp.example.com IN PTR
                              FrontSpot._dali._udp.example.com
    FrontSpot._dali._udp.example.com  IN SRV  0 0 5678
                              node1.example.com.
    FrontSpot._dali._udp.example.com  IN TXT
                              txtver=1;path=/light/1

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

-- 
-------------------------+-------------------------------------------------
 Reporter:               |       Owner:  draft-ietf-core-resource-
  [email-masked]     |  [email-masked]
     Type:  task         |      Status:  closed
 Priority:  major        |   Milestone:
Component:  resource-    |     Version:
  directory              |  Resolution:  fixed
 Severity:  -            |
 Keywords:               |
-------------------------+-------------------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/core/trac/ticket/370#comment:1>
core <http://tools.ietf.org/core/>