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]