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