CoRE Resource Directory: DNS-SD mappingVerizon Labs50 Sylvan RdWalthamMA02451USA+1 781 296 9722kerlyn@ieee.orgconsultant+31-492474673 (Netherlands), +33-966015248 (France)consultancy@vanderstok.orgwww.vanderstok.orgSmartThings665 Clyde AvenueMountain View94043USA+1-707-502-5136Michael.Koster@smartthings.comEnergy Harvesting SolutionsHollandstr. 12/41020Austria+43-664-9790639c.amsuess@energyharvesting.at
Internet
CoRECoRE, Web Linking, Resource Discovery, Resource DirectoryTBDTBD … … … DNS-SDThe key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”,
“SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL”
in this
document are to be interpreted as described in . The
term “byte” is used in its now customary sense as a synonym for “octet”.This specification requires readers to be familiar with all the terms and
concepts that are discussed in and . Readers should
also be familiar with the terms and concepts discussed in . To
describe the REST interfaces defined in this specification, the URI Template
format is used .This specification makes use of the terminology of .This specification makes use of the following additional terminology:
TBD
TBDWhen using the CoRE Link Format to describe resources being discovered by
or posted to a resource directory service, additional information about those
resources is useful. This specification defines the following new attributes
for use in the CoRE Link Format :The Resource Instance “ins” attribute is an
identifier for this resource, which makes it possible
to distinguish it from other similar resources. This attribute is similar
in use to the <Instance> portion of a DNS-SD record (see , and SHOULD be unique across resources with the same Resource Type attribute
in the domain it is used. A Resource Instance might be a descriptive string
like “Ceiling Light, Room 3”, a short ID like “AF39” or a unique UUID or
iNumber. This attribute is used by a Resource Directory to distinguish between
multiple instances of the same resource type within the directory.This attribute MUST be no more than 63 bytes in length. The resource identifier
attribute MUST NOT appear more than once in a link description. This attribute MAY be used as a query parameter in the RD Lookup Function Set defined in Section 7.The Export “exp” attribute is used as a flag to indicate that a link description
MAY be exported by a resource directory to external directories.The CoRE Link Format is used for many purposes between CoAP endpoints. Some
are useful mainly locally, for example checking the observability of a resource
before accessing it, determining the size of a resource, or traversing dynamic
resource structures. However, other links are very useful to be exported
to other directories, for example the entry point resource to a functional
service. This attribute MAY be used as a query parameter in the RD Lookup Function Set defined in Section 7.CoRE Resource
Discovery is intended to support fine-grained discovery of hosted
resources, their attributes, and possibly other resource relations . In contrast, service discovery generally refers to a coarse-grained
resolution of an endpoint’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 fields that permits
discovery of CoAP services by either method.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 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 provides additional information
in the form of key/value pairs.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 preceded by an
underscore character. The second label indicates the transport and is always
“_udp” for UDP-based 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 “light._sub._dali._udp”.A 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).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 “Net-Unicode” (Unicode
Normalization Form C) 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 and Section 2.1
of .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 a collision-resistant 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.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 . 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.DNS domains may be derived from the “d” attribute. The domain attribute may
be suffixed with the zone name of the authoritative DNS server to generate
the domain name. The “ep” attribute is prefixed to the domain name to generate
the FQDN to be stored into DNS with an AAAA RR.A number of key/value pairs are derived from link-format
information, to be exported in the DNS-SD as key=value strings in a
TXT record (, Section 6.3).The resource <URI> is exported as key/value pair “path=<URI>”.The Interface Description “if” attribute is exported as key/value
pair “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 .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, using the example lookup location /rd-lookup, shows an agent discovering a resource to be
exported:The agent subsequently registers the following DNS-SD RRs, assuming a zone
name “example.com” prefixed with “office”:In the above figure the Service Name is chosen as Spot._dali._udp.office.example.com
without the light._sub service prefix. An alternative Service Name would
be: Spot.light._sub._dali._udp.office.example.com.It may be profitable to discover the light groups for applications, which are unaware ot the existence of the RD. An agent needs to query the
RD to return all groups which are exported to be inserted into DNS.The group with FQDN grp_R2-4-015.bc.example.com can be entered into the DNS
by the agent. The accompanying instance name is grp1234. The <ServiceType>
is chosen to be _group._udp. The agent enters the following RRs into the
DNS.From then on applications, not familiar with the existence of the RD, can use DNS to access the lighting group.TBDTBDConstrained RESTful Environments (CoRE) Link FormatThis specification defines Web Linking using a link format for use by constrained web servers to describe hosted resources, their attributes, and other relationships between links. Based on the HTTP Link Header field defined in RFC 5988, the Constrained RESTful Environments (CoRE) Link Format is carried as a payload and is assigned an Internet media type. "RESTful" refers to the Representational State Transfer (REST) architecture. A well-known URI is defined as a default entry point for requesting the links hosted by a server. [STANDARDS-TRACK]Key words for use in RFCs to Indicate Requirement LevelsIn many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.Web LinkingThis document specifies relation types for Web links, and defines a registry for them. It also defines the use of such links in HTTP headers with the Link header field. [STANDARDS-TRACK]Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number RegistryThis document defines the procedures that the Internet Assigned Numbers Authority (IANA) uses when handling assignment and other requests related to the Service Name and Transport Protocol Port Number registry. It also discusses the rationale and principles behind these procedures and how they facilitate the long-term sustainability of the registry.This document updates IANA's procedures by obsoleting the previous UDP and TCP port assignment procedures defined in Sections 8 and 9.1 of the IANA Allocation Guidelines, and it updates the IANA service name and port assignment procedures for UDP-Lite, the Datagram Congestion Control Protocol (DCCP), and the Stream Control Transmission Protocol (SCTP). It also updates the DNS SRV specification to clarify what a service name is and how it is registered. This memo documents an Internet Best Current Practice.URI TemplateA URI Template is a compact sequence of characters for describing a range of Uniform Resource Identifiers through variable expansion. This specification defines the URI Template syntax and the process for expanding a URI Template into a URI reference, along with guidelines for the use of URI Templates on the Internet. [STANDARDS-TRACK]DNS-Based Service DiscoveryThis document specifies how DNS resource records are named and structured to facilitate service discovery. Given a type of service that a client is looking for, and a domain in which the client is looking for that service, this mechanism allows clients to discover a list of named instances of that desired service, using standard DNS queries. This mechanism is referred to as DNS-based Service Discovery, or DNS-SD.CoRE Resource DirectoryIn many M2M applications, direct discovery of resources is not practical due to sleeping nodes, disperse networks, 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, allowing lookups to be performed for those resources. This document specifies the web interfaces that a Resource Directory supports in order for web servers to discover the RD and to register, maintain, lookup and remove resource descriptions. Furthermore, new link attributes useful in conjunction with an RD are defined.The Constrained Application Protocol (CoAP)The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks. The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) often have high packet error rates and a typical throughput of 10s of kbit/s. The protocol is designed for machine- to-machine (M2M) applications such as smart energy and building automation.CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types. CoAP is designed to easily interface with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead, and simplicity for constrained environments.UTF-8, a transformation format of ISO 10646ISO/IEC 10646-1 defines a large character set called the Universal Character Set (UCS) which encompasses most of the world's writing systems. The originally proposed encodings of the UCS, however, were not compatible with many current applications and protocols, and this has led to the development of UTF-8, the object of this memo. UTF-8 has the characteristic of preserving the full US-ASCII range, providing compatibility with file systems, parsers and other software that rely on US-ASCII values but are transparent to other values. This memo obsoletes and replaces RFC 2279.Unicode Format for Network InterchangeThe Internet today is in need of a standardized form for the transmission of internationalized "text" information, paralleling the specifications for the use of ASCII that date from the early days of the ARPANET. This document specifies that format, using UTF-8 with normalization and specific line-ending sequences. [STANDARDS-TRACK]Requirements for Internet Hosts - Application and SupportThis RFC is an official specification for the Internet community. It incorporates by reference, amends, corrects, and supplements the primary protocol standards documents relating to hosts. [STANDARDS-TRACK]Domain names - concepts and facilitiesThis RFC is the revised basic definition of The Domain Name System. It obsoletes RFC-882. This memo describes the domain style names and their used for host address look up and electronic mail forwarding. It discusses the clients and servers in the domain name system and the protocol used between them.This document was split off from . TODO: Copy over relevant acknowledgements.