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

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

CoRE Working Group                                               K. Lynn
Internet-Draft                                                Consultant
Intended status: Standards Track                               Z. Shelby
Expires: January 12, 2012                                      Sensinode
                                                           July 11, 2011


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

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 scalable 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 may be used interchangeably to locate services.

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 12, 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 12, 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  . . . . . . . . 6
   3.  Examples  . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
   5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 8
   6.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 8
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 8
     7.1.  Normative References  . . . . . . . . . . . . . . . . . . . 8
     7.2.  Informative References  . . . . . . . . . . . . . . . . . . 8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 9



































Lynn & Shelby           Expires January 12, 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 devices (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.  The main deliverable of CoRE is the Constrained
   Application Protocol (CoAP) specification [I-D.ietf-core-coap].

   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 possibly other resource relations
   [I-D.ietf-core-link-format].

   In contrast, service discovery generally refers to a coarse-grained
   resolution of an end-point's IP address, port number, and protocol.
   This definition may be extended to include multi-function devices,
   where the result of the discovery process may include a path to a
   resource representing a RESTful service interface as well as a
   reference to a description of the interface such as a Web Application
   Description Language (WADL) document
   [I-D.vial-core-link-format-wadl].

   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 Link Format attributes and DNS-Based
   Service Discovery [I-D.cheshire-dnsext-dns-sd] fields that permits
   discovery of CoAP services by either means.  It also satisfies 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].



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


Internet-Draft           CoRE Discovery Mapping                July 2011


1.2.  Resource Discovery

   The main function of Resource Discovery is to provide Universal
   Resource Identifiers (URIs, called links) for the resources hosted by
   the server, complemented by attributes about those resources and
   perhaps additional link relations.  In CoRE this collection of links
   is carried as a resource of its own (as opposed to HTTP headers
   delivered with a specific resource).

   [I-D.ietf-core-link-format] specifies a link format for use in CoRE
   Resource Discovery by extending the HTTP Link Header Format [RFC5988]
   to describe these link descriptions.  The CoRE Link Format is carried
   as a payload and is assigned an Internet media type.  A well-known
   URI "/.well-known/core" is defined as a default entry-point for
   requesting the list of links about resources hosted by a server, and
   thus performing CoRE Resource Discovery.

   Resource Discovery can be performed either via unicast or multicast.
   When a server's IP address is already known, either a priori or
   resolved via the Domain Name System (DNS) [RFC1034][RFC1035], unicast
   discovery is performed in order to locate the entry point to the
   resource of interest.  This is performed using a GET to /.well-known/
   core on the server, which returns a payload in the CoRE Link Format.
   A client would then match the appropriate Resource Type, Interface
   Description, and possible Content-Type [RFC2045] for its application.
   These attributes may also be included in the query string in order to
   filter the number of links returned in a response.

1.3.  Resource Directories

   In many M2M scenarios, direct discovery of resources is not practical
   due to sleeping nodes, limited bandwidth, or networks where multicast
   traffic is inefficient.  These problems can be solved by employing an
   entity called a Resource Directory (RD), which hosts descriptions of
   resources held on other servers, called end-points (EP), and allows
   lookups to be performed for those resources.  An end-point is a web
   server associated with specific IP address and port; thus a physical
   device may host one or more end-points.  End-points may also act as
   clients.

   The Resource Directory implements a set of REST interfaces for end-
   points to register and maintain sets of Web Links, called resource
   directory entries.  [I-D.shelby-core-resource-directory] specifies
   the web interfaces that an RD supports in order for web servers to
   discover the RD and to register, maintain, lookup and remove resource
   descriptions; for the RD to validate entries; and for clients to
   lookup resources from the RD.  Furthermore, new link attributes
   useful in conjunction with an RD are defined.



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


Internet-Draft           CoRE Discovery Mapping                July 2011


1.4.  DNS-Based Service Discovery

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

   DNS-SD Service Names are limited to 255 octets and are of the form:

          Service Name = {Instance}.{Service}.{Domain}

   The {Domain} part of the service name is identical to the global (DNS
   subdomain) part of the authority in URIs that identify the resources
   on an individual server or group of servers. {Domain} may identify a
   building zone as shown in the examples of [I-D.vanderstok-core-bc].

   The {Service} part is composed of at least two labels.  The first
   label of the pair is an underscore character generally followed by
   the application protocol name [I-D.ietf-tsvwg-iana-ports].  The
   second label 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 label (beginning with an underscore)
   followed by the "_sub" label.  An example of the {Service} part is
   "_lamp._sub._dali._udp".  Only the rightmost pair of labels is used
   to name SRV and TXT records.

   The default {Instance} part of the service name may be set at the
   factory or during the commissioning process.  It SHOULD uniquely
   identify a {Service} within a {Domain}.  Taken together, these
   elements comprise a unique name for an SRV record (and optionally a
   corresponding TXT record) 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 (and 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 present 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 [I-D.cheshire-dnsext-dns-sd].  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).  An example string is:

                  | 0x08 | t | x | t | v | e | r | = | 1 |



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


Internet-Draft           CoRE Discovery Mapping                July 2011


2.  Mapping CoRE Link Attributes to DNS-SD Records

   [I-D.shelby-core-resource-directory] defines two new CoRE Link Format
   attributes that are particularly useful in conjunction with RDs:

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

   The Resource Instance "ins" attribute is an identifier for a resource
   that makes it possible to distinguish from other similar resources.
   This attribute SHOULD be unique across resources with the same
   Resource Type attribute in the domain in which it is used.

   If the "exp" attribute is defined for a link, then the following CoRE
   specific target attributes (defined in [I-D.ietf-core-link-format])
   are intended to be exported directly into DNS-SD.  The values are
   subject to format and length constraints as specified in
   [I-D.cheshire-dnsext-dns-sd].

2.1.  Resource Instance "ins" attribute mapped onto {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 the device's MAC address, serial number,
   or any similar hexadecimal string in an attempt to make the name
   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 mapped onto {Service}

   The resource type "rt" attribute is mapped onto the {Service} part of
   a DNS-SD instance name (as defined in Section 1.4) and must conform
   to the following format.  It must be comprised of Net-Unicode text



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


Internet-Draft           CoRE Discovery Mapping                July 2011


   stings, each preceded by an underscore '_' and limited to 16 octets
   in length.  The strings must be separated by periods '.' and end with
   the defined CoAP transport label "_udp".  The resulting string is
   used to form labels for DNS-SD records which are stored directly in
   the DNS.

2.3.  {Domain} mapping

   [TBD: A method must be specified to determine in which DNS zone the
   CoAP service should be registered.  See, for example, Section 11 in
   [I-D.cheshire-dnsext-dns-sd].]

2.4.  TXT Record strings

   The resource <URI> is exported to the TXT record string "PATH={URI}".

   The Interface Description "if" attribute is exported to the TXT
   record string "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 [I-D.cheshire-dnsext-dns-sd].


3.  Examples

   Assuming the ability to query a Resource Directory , or multicast a
   GET (?exp) over the local link, CoAP resource discovery can 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 {Service}, and registered in the correct {Domain} [selection
   method TBD].  The agent responsible for exporting records to the DNS
   zone file SHOULD be authenticated with the DNS server.

   [TBD: Examples]


4.  IANA Considerations

   This document makes no request of IANA.

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






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


Internet-Draft           CoRE Discovery Mapping                July 2011


5.  Security Considerations

   [TBD]


6.  Acknowledgments

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


7.  References

7.1.  Normative References

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

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

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

   [RFC2045]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
              Extensions (MIME) Part One: Format of Internet Message
              Bodies", RFC 2045, November 1996.

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

   [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-coap]
              Shelby, Z., Hartke, K., Bormann, C., and B. Frank,



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


Internet-Draft           CoRE Discovery Mapping                July 2011


              "Constrained Application Protocol (CoAP)",
              draft-ietf-core-coap-07 (work in progress), July 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.ietf-tsvwg-iana-ports]
              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",
              draft-ietf-tsvwg-iana-ports-10 (work in progress),
              February 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",
              draft-shelby-core-resource-directory-00 (work in
              progress), June 2011.

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

   [I-D.vial-core-link-format-wadl]
              Vial, M. and Z. Shelby, "Interface description with WADL
              in CoRE", draft-vial-core-link-format-wadl-00 (work in
              progress), March 2011.

   [dns-sd]   "dns-sd service type registration",
              Web http://www.dns-sd.org/ServiceTypes.html, 2011.












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


Internet-Draft           CoRE Discovery Mapping                July 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 12, 2012               [Page 10]


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