[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 02 draft-ietf-core-rd-dns-sd

CoRE                                                             K. Lynn
Internet-Draft                                                Consultant
Intended status: Standards Track                               Z. Shelby
Expires: January 5, 2012                                       Sensinode
                                                           July 04, 2011


        CoRE Link-Format to DNS-Based Service Discovery Mapping
                  draft-lynn-core-discovery-mapping-00

Abstract

   Resource and service discovery are complimentary.  Resource discovery
   provides fine-grained detail about the content of a server, while
   service discovery can provide a scable method to locate servers in
   large networks.  This document defines a method for mapping between
   CoRE Link-Format attributes and DNS-Based Service Discovery fields so
   the two methods can be jointly employed in large scale networks.

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 5, 2012.

Copyright Notice

   Copyright (c) 2011 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 & Shelby            Expires January 5, 2012                [Page 1]


Internet-Draft           Core Discovery Mapping                July 2011


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


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Mapping CoRE Link Attributes to DNS-SD Records  . . . . . . . . 5
   3.  Examples  . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
   5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 7
   6.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 8
     7.1.  Normative References  . . . . . . . . . . . . . . . . . . . 8
     7.2.  Informative References  . . . . . . . . . . . . . . . . . . 8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 9



































Lynn & Shelby            Expires January 5, 2012                [Page 2]


Internet-Draft           Core Discovery Mapping                July 2011


1.  Introduction

   The Constrained RESTful Environments (CoRE) working group aims at
   realizing the REST architecture in a suitable form for the most
   constrained nodes (e.g. 8-bit microcontrollers with limited RAM and
   ROM) and networks (e.g. 6LoWPAN).  CoRE is aimed at machine-to-
   machine (M2M) applications such as smart energy and building
   automation.

   Automated discovery of resources hosted by a constrained server is
   critical in machine-to-machine applications where human intervention
   is minimal and static interfaces result in fragility.  CoRE Resource
   Discovery is intended to support fine-grained discovery of hosted
   resources, their attributes, and other resource relations
   [I-D.ietf-core-link-format].

   In contrast, service discovery generally refers to a coarse-grained
   resolution of a service access point's IP address, port number, and
   protocol.  Resource and service discovery are complimentary in the
   case of large networks, where the latter can facilitate scaling.
   This document defines a mapping between CoRE Resource Discovery and
   DNS-Based Service Discovery [I-D.cheshire-dnsext-dns-sd] fields that
   permits discovery of CoAP servers by either means.  It also satisfies
   a literal interpretation of the following CoRE charter requirement
   [I-D.shelby-core-coap-req]:

   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]

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 "Key words for use in
   RFCs to Indicate Requirement Levels" [RFC2119].

1.2.  DNS-Based Service Discovery

   DNS-Based Service Discovery (DNS-SD) defines a conventional way to
   configure DNS PTR, SRV, and TXT records to facilitate discovery of
   services (such as CoAP nodes within a subdomain) using the existing
   DNS infrastructure.  This section gives a cursory overview of DNS-SD;



Lynn & Shelby            Expires January 5, 2012                [Page 3]


Internet-Draft           Core Discovery Mapping                July 2011


   see [I-D.cheshire-dnsext-dns-sd] for a detailed specification.

   DNS-SD service names are of the form Instance.ServiceType.Location,
   where the default ServiceType for CoAP nodes is "_coap._udp".  (The
   identifier "_udp" is required for DNS-SD SRV record definitions and
   "_coap" identifies the application protocol.)  For each CoAP end-
   point in the domain, a PTR record with the name _coap._udp is defined
   and each PTR value references SRV and TXT records having the
   Instance.ServiceType.Location name.

   DNS-SD currently supports one level of subtype, which MAY be used to
   locate coap services based on object model, for example:
   _bacnet._sub._coap._udp, _dali._sub._coap._udp, or
   _zigbee._sub._coap._udp.  The maximum length of each type and subtype
   fields is 15 octets including the underscore.  It is proposed to
   eliminate the "_sub" string and allow any number of _subtype strings,
   subject to the overall 255 octet limit on service names.

   The Location part of the service name is identical to the DNS
   (sub)domain part of the authority in URIs that identify the resources
   on this node or group and may, for example, identify a building zone.

   The Instance part of the service name is defined as part of the
   commissioning process.  It must be unique within the (sub)domain.
   The complete service name uniquely identifies both a SRV and TXT
   record in the DNS zone.  The granularity of a service name MAY be
   that of a host or group, or it could represent a particular resource
   within a coap node.  The SRV record contains the host (AAAA record)
   name and port of the service.  In the case where a service name
   identifies a particular resource, the path part of the URI must be
   placed in the TXT record.

1.3.  Resource Discovery

   While service discovery is concerned with finding the IP address,
   port, and protocol of a named service, resource discovery is a fine-
   grained discovery of resource URIs within a web service.
   [I-D.ietf-core-link-format] specifies a resource discovery pattern,
   such that sending a confirmable GET message for the /.well-known/core
   resource returns a set of links that identify all resources present
   on this node that are exposed as functions.

1.4.  Resource Directory

   A Resource Directory (RD) is used as a repository for Web Links
   [RFC5988] about resources hosted on other web servers, which are
   called end-points (EP).  An end-point is a web server associated with
   a port, thus a physical node may host one or more end-points.  The RD



Lynn & Shelby            Expires January 5, 2012                [Page 4]


Internet-Draft           Core Discovery Mapping                July 2011


   implements a set of REST interfaces for end-points to register and
   maintain sets of Web Links (called resource directory entries), for
   the RD to validate entries, and for clients to lookup resources from
   the RD.  End-points themselves can also act as clients.


2.  Mapping CoRE Link Attributes to DNS-SD Records

   ---------+---------+---------+---------+---------+---------+---------
   [Discuss here the new RD attributes]


   link-extension    = ( "ins" "=" quoted-string ) ; Max 63 octets
   link-extension    = ( "exp" )

   Resource Instance (ins=) is mapped to DNS-SD Service Instance (as
   defined in core-resource-directory)
   Resource Type (rt=) is mapped to the DNS-SD service type and subtypes
   <URI> is mapped to the DNS-SD TXT record PATH=
   Interface Description (if=) is mapped to the DNS-SD TXT record IF=



   The following CoRE specific target attributes as defined in
   [I-D.ietf-core-link-format] are imported directly into DNS-SD if
   "exp" is present.  The values are intended to be imported directly
   into a DNS-SD zone file are are subject to format and length
   constraints as specified in [I-D.cheshire-dnsext-dns-sd].

2.1.  Resource Instance "ins" attribute

   The Resource Instance "ins" attribute is the Instance portion 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 proxy or gateway, it SHOULD use the syntax defined in
   Section 3.5 of [RFC1034] and Section 2.1 of [RFC1123].

   The Instance portion 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 the device's MAC address, serial number,
   or any similar hexadecimal string in an attempt to make the name



Lynn & Shelby            Expires January 5, 2012                [Page 5]


Internet-Draft           Core Discovery Mapping                July 2011


   globally unique.

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

2.2.  Resource Type "rt" attribute

   The resource type "rt" attribute is mapped into the ServiceType
   portion of a DNS-SD instance name and must conform to the following
   format.  It must be comprised of Net-Unicode text stings, each
   preceded by an underscore '_' and limited to 15 octets in length.
   The strings must be separated by periods '.' and prepended to the
   default CoAP ServiceType "_coap._udp".  The resulting string is used
   to form labels for DNS-SD records and as such is stored directly in
   the DNS.

   [TBD: If the default type is always "_coap._udp" do we need to
   specify it?  If not, do we need separate attributes for type and
   subtype strings?]

2.3.  Location

   [ A method must be specified to determine in which DNS zone the CoAP
   service should be registered in.  Perhaps some way to map subnet into
   DNS subdomain name.]


3.  Examples

   Assuming the ability to access a Resource Directory, or multicast a
   GET over the local link, CoAP resource discovery can be used to
   populate the DNS-SD database in an automated fashion.  CoAP resource
   descriptions can be imported into DNS-SD for exposure to service
   discovery by using the "ins" attribute as the basis for a unique
   "Instance" name, defaulting to "_coap._udp" for the ServiceType, and
   using some means to establish which domain the service should be
   registered in [TBD].  The DNS TXT record can be populated by
   importing the other resource description attributes as they share the
   same key=value format specified in Section 6 of
   [I-D.cheshire-dnsext-dns-sd].

   Examples [TBD]


4.  IANA Considerations

   This document makes no request of IANA.




Lynn & Shelby            Expires January 5, 2012                [Page 6]


Internet-Draft           Core Discovery Mapping                July 2011


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


5.  Security Considerations

   [TBD]


6.  Acknowledgments

   Contributions and review comments were made by Anders Brandt, Angelo
   Castellani, and Peter van der Stok.






































Lynn & Shelby            Expires January 5, 2012                [Page 7]


Internet-Draft           Core Discovery Mapping                July 2011


7.  References

7.1.  Normative References

   [RFC0020]  Cerf, V., "ASCII format for network interchange", RFC 20,
              October 1969.

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

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

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

   [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
              10646", STD 63, RFC 3629, November 2003.

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

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

7.2.  Informative References

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

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

   [I-D.shelby-core-coap-req]
              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-resource-directory]
              Shelby, Z. and S. Krco, "CoRE Resource Directory",



Lynn & Shelby            Expires January 5, 2012                [Page 8]


Internet-Draft           Core Discovery Mapping                July 2011


              draft-shelby-core-resource-directory-00 (work in
              progress), June 2011.


Authors' Addresses

   Kerry Lynn
   Consultant

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


   Zach Shelby
   Sensinode
   Kidekuja 2
   Vuokatti  88600
   FINLAND

   Phone: +358407796297
   Email: zach@sensinode.com






























Lynn & Shelby            Expires January 5, 2012                [Page 9]


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