idnits 2.17.1 draft-lynn-core-discovery-mapping-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 11, 2011) is 4670 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'TBD' is mentioned on line 306, but not defined ** Obsolete normative reference: RFC 5988 (Obsoleted by RFC 8288) == Outdated reference: A later version (-11) exists of draft-cheshire-dnsext-dns-sd-10 == Outdated reference: A later version (-18) exists of draft-ietf-core-coap-07 == Outdated reference: A later version (-14) exists of draft-ietf-core-link-format-06 == Outdated reference: A later version (-04) exists of draft-shelby-core-coap-req-02 == Outdated reference: A later version (-05) exists of draft-shelby-core-resource-directory-00 == Outdated reference: A later version (-05) exists of draft-vanderstok-core-bc-04 == Outdated reference: A later version (-01) exists of draft-vial-core-link-format-wadl-00 Summary: 1 error (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CoRE Working Group K. Lynn 3 Internet-Draft Consultant 4 Intended status: Standards Track Z. Shelby 5 Expires: January 12, 2012 Sensinode 6 July 11, 2011 8 CoRE Link-Format to DNS-Based Service Discovery Mapping 9 draft-lynn-core-discovery-mapping-01 11 Abstract 13 Resource and service discovery are complimentary. Resource discovery 14 provides fine-grained detail about the content of a server, while 15 service discovery can provide a scalable method to locate servers in 16 large networks. This document defines a method for mapping between 17 CoRE Link Format attributes and DNS-Based Service Discovery fields so 18 the two methods may be used interchangeably to locate services. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on January 12, 2012. 37 Copyright Notice 39 Copyright (c) 2011 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Mapping CoRE Link Attributes to DNS-SD Records . . . . . . . . 6 56 3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 57 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 58 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 59 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 8 60 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 61 7.1. Normative References . . . . . . . . . . . . . . . . . . . 8 62 7.2. Informative References . . . . . . . . . . . . . . . . . . 8 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 65 1. Introduction 67 The Constrained RESTful Environments (CoRE) working group aims at 68 realizing the REST architecture in a suitable form for the most 69 constrained devices (e.g. 8-bit microcontrollers with limited RAM and 70 ROM) and networks (e.g. 6LoWPAN). CoRE is aimed at machine-to- 71 machine (M2M) applications such as smart energy and building 72 automation. The main deliverable of CoRE is the Constrained 73 Application Protocol (CoAP) specification [I-D.ietf-core-coap]. 75 Automated discovery of resources hosted by a constrained server is 76 critical in machine-to-machine applications where human intervention 77 is minimal and static interfaces result in fragility. CoRE Resource 78 Discovery is intended to support fine-grained discovery of hosted 79 resources, their attributes, and possibly other resource relations 80 [I-D.ietf-core-link-format]. 82 In contrast, service discovery generally refers to a coarse-grained 83 resolution of an end-point's IP address, port number, and protocol. 84 This definition may be extended to include multi-function devices, 85 where the result of the discovery process may include a path to a 86 resource representing a RESTful service interface as well as a 87 reference to a description of the interface such as a Web Application 88 Description Language (WADL) document 89 [I-D.vial-core-link-format-wadl]. 91 Resource and service discovery are complimentary in the case of large 92 networks, where the latter can facilitate scaling. This document 93 defines a mapping between CoRE Link Format attributes and DNS-Based 94 Service Discovery [I-D.cheshire-dnsext-dns-sd] fields that permits 95 discovery of CoAP services by either means. It also satisfies the 96 following CoRE charter requirement [I-D.shelby-core-coap-req]: 98 REQ8: A definition of how to use CoAP to advertise about or query 99 for a Device's description. This description may include the 100 device name and a list of its Resources, each with a URL, an 101 interface description URI (pointing e.g. to a Web Application 102 Description Language (WADL) document) and an optional name or 103 identifier. The name taxonomy used for this description will 104 be consistent with other IETF work, e.g. 105 draft-cheshire-dnsext-dns-sd. [charter] 107 1.1. Terminology 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in "Key words for use in 112 RFCs to Indicate Requirement Levels" [RFC2119]. 114 1.2. Resource Discovery 116 The main function of Resource Discovery is to provide Universal 117 Resource Identifiers (URIs, called links) for the resources hosted by 118 the server, complemented by attributes about those resources and 119 perhaps additional link relations. In CoRE this collection of links 120 is carried as a resource of its own (as opposed to HTTP headers 121 delivered with a specific resource). 123 [I-D.ietf-core-link-format] specifies a link format for use in CoRE 124 Resource Discovery by extending the HTTP Link Header Format [RFC5988] 125 to describe these link descriptions. The CoRE Link Format is carried 126 as a payload and is assigned an Internet media type. A well-known 127 URI "/.well-known/core" is defined as a default entry-point for 128 requesting the list of links about resources hosted by a server, and 129 thus performing CoRE Resource Discovery. 131 Resource Discovery can be performed either via unicast or multicast. 132 When a server's IP address is already known, either a priori or 133 resolved via the Domain Name System (DNS) [RFC1034][RFC1035], unicast 134 discovery is performed in order to locate the entry point to the 135 resource of interest. This is performed using a GET to /.well-known/ 136 core on the server, which returns a payload in the CoRE Link Format. 137 A client would then match the appropriate Resource Type, Interface 138 Description, and possible Content-Type [RFC2045] for its application. 139 These attributes may also be included in the query string in order to 140 filter the number of links returned in a response. 142 1.3. Resource Directories 144 In many M2M scenarios, direct discovery of resources is not practical 145 due to sleeping nodes, limited bandwidth, or networks where multicast 146 traffic is inefficient. These problems can be solved by employing an 147 entity called a Resource Directory (RD), which hosts descriptions of 148 resources held on other servers, called end-points (EP), and allows 149 lookups to be performed for those resources. An end-point is a web 150 server associated with specific IP address and port; thus a physical 151 device may host one or more end-points. End-points may also act as 152 clients. 154 The Resource Directory implements a set of REST interfaces for end- 155 points to register and maintain sets of Web Links, called resource 156 directory entries. [I-D.shelby-core-resource-directory] specifies 157 the web interfaces that an RD supports in order for web servers to 158 discover the RD and to register, maintain, lookup and remove resource 159 descriptions; for the RD to validate entries; and for clients to 160 lookup resources from the RD. Furthermore, new link attributes 161 useful in conjunction with an RD are defined. 163 1.4. DNS-Based Service Discovery 165 DNS-Based Service Discovery (DNS-SD) defines a conventional method of 166 configuring DNS PTR, SRV, and TXT records to facilitate discovery of 167 services (such as CoAP servers in a subdomain) using the existing DNS 168 infrastructure. This section gives a cursory overview of DNS-SD; see 169 [I-D.cheshire-dnsext-dns-sd] for a detailed specification. 171 DNS-SD Service Names are limited to 255 octets and are of the form: 173 Service Name = {Instance}.{Service}.{Domain} 175 The {Domain} part of the service name is identical to the global (DNS 176 subdomain) part of the authority in URIs that identify the resources 177 on an individual server or group of servers. {Domain} may identify a 178 building zone as shown in the examples of [I-D.vanderstok-core-bc]. 180 The {Service} part is composed of at least two labels. The first 181 label of the pair is an underscore character generally followed by 182 the application protocol name [I-D.ietf-tsvwg-iana-ports]. The 183 second label is always "_udp" for CoAP services. In cases where 184 narrowing the scope of the search may be useful, these labels may be 185 optionally preceded by a subtype label (beginning with an underscore) 186 followed by the "_sub" label. An example of the {Service} part is 187 "_lamp._sub._dali._udp". Only the rightmost pair of labels is used 188 to name SRV and TXT records. 190 The default {Instance} part of the service name may be set at the 191 factory or during the commissioning process. It SHOULD uniquely 192 identify a {Service} within a {Domain}. Taken together, these 193 elements comprise a unique name for an SRV record (and optionally a 194 corresponding TXT record) within the DNS subdomain. 196 The granularity of a service name MAY be that of a host or group, or 197 it could represent a particular resource within a CoAP server. The 198 SRV record contains the host name (AAAA record name) and port of the 199 service (and protocol is part of the service name). In the case 200 where a service name identifies a particular resource, the path part 201 of the URI must be present in a corresponding TXT record. 203 A DNS TXT record is in practice limited to a few hundred octets in 204 length, which is indicated in the resource record header in the DNS 205 response message [I-D.cheshire-dnsext-dns-sd]. The data consists of 206 one or more strings comprising a key=value pair. By convention, the 207 first pair is txtver= (to support different versions of a 208 service description). An example string is: 210 | 0x08 | t | x | t | v | e | r | = | 1 | 212 2. Mapping CoRE Link Attributes to DNS-SD Records 214 [I-D.shelby-core-resource-directory] defines two new CoRE Link Format 215 attributes that are particularly useful in conjunction with RDs: 217 link-extension = ( "ins" "=" quoted-string ) ; Max 63 octets 218 link-extension = ( "exp" ) 220 The Resource Instance "ins" attribute is an identifier for a resource 221 that makes it possible to distinguish from other similar resources. 222 This attribute SHOULD be unique across resources with the same 223 Resource Type attribute in the domain in which it is used. 225 If the "exp" attribute is defined for a link, then the following CoRE 226 specific target attributes (defined in [I-D.ietf-core-link-format]) 227 are intended to be exported directly into DNS-SD. The values are 228 subject to format and length constraints as specified in 229 [I-D.cheshire-dnsext-dns-sd]. 231 2.1. Resource Instance "ins" attribute mapped onto {Instance} 233 The Resource Instance "ins" attribute maps to the {Instance} part of 234 a DNS-SD service name. It is stored directly in the DNS as a single 235 DNS label of canonical precomposed UTF-8 [RFC3629] "Net-Unicode" 236 (Unicode Normalization Form C) [RFC5198] text. However, to the 237 extent that the "ins" attribute may be chosen to match the DNS host 238 name of a service, it SHOULD use the syntax defined in Section 3.5 of 239 [RFC1034] and Section 2.1 of [RFC1123]. 241 The {Instance} part of the name of a service being offered on the 242 network SHOULD be configurable by the user setting up the service, so 243 that he or she may give it an informative name. However, the device 244 or service SHOULD NOT require the user to configure a name before it 245 can be used. A sensible choice of default name can allow the device 246 or service to be accessed in many cases without any manual 247 configuration at all. The default name should be short and 248 descriptive, and MAY include the device's MAC address, serial number, 249 or any similar hexadecimal string in an attempt to make the name 250 globally unique. 252 DNS labels are currently limited to 63 octets in length and the 253 entire service name may not exceed 255 octets. 255 2.2. Resource Type "rt" attribute mapped onto {Service} 257 The resource type "rt" attribute is mapped onto the {Service} part of 258 a DNS-SD instance name (as defined in Section 1.4) and must conform 259 to the following format. It must be comprised of Net-Unicode text 260 stings, each preceded by an underscore '_' and limited to 16 octets 261 in length. The strings must be separated by periods '.' and end with 262 the defined CoAP transport label "_udp". The resulting string is 263 used to form labels for DNS-SD records which are stored directly in 264 the DNS. 266 2.3. {Domain} mapping 268 [TBD: A method must be specified to determine in which DNS zone the 269 CoAP service should be registered. See, for example, Section 11 in 270 [I-D.cheshire-dnsext-dns-sd].] 272 2.4. TXT Record strings 274 The resource is exported to the TXT record string "PATH={URI}". 276 The Interface Description "if" attribute is exported to the TXT 277 record string "IF={Interface Description}". 279 The DNS TXT record can be further populated by importing any other 280 resource description attributes as they share the same key=value 281 format specified in Section 6 of [I-D.cheshire-dnsext-dns-sd]. 283 3. Examples 285 Assuming the ability to query a Resource Directory , or multicast a 286 GET (?exp) over the local link, CoAP resource discovery can be used 287 to populate the DNS-SD database in an automated fashion. CoAP 288 resource descriptions (links) can be exported to DNS-SD for exposure 289 to service discovery by using the Resource Instance attribute as the 290 basis for a unique service name, composed with the Resource Type as 291 the {Service}, and registered in the correct {Domain} [selection 292 method TBD]. The agent responsible for exporting records to the DNS 293 zone file SHOULD be authenticated with the DNS server. 295 [TBD: Examples] 297 4. IANA Considerations 299 This document makes no request of IANA. 301 Note to RFC Editor: this section may be removed on publication as an 302 RFC. 304 5. Security Considerations 306 [TBD] 308 6. Acknowledgments 310 Contributions and review comments were made by Anders Brandt, Angelo 311 Castellani, and Peter van der Stok. 313 7. References 315 7.1. Normative References 317 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 318 STD 13, RFC 1034, November 1987. 320 [RFC1035] Mockapetris, P., "Domain names - implementation and 321 specification", STD 13, RFC 1035, November 1987. 323 [RFC1123] Braden, R., "Requirements for Internet Hosts - Application 324 and Support", STD 3, RFC 1123, October 1989. 326 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 327 Extensions (MIME) Part One: Format of Internet Message 328 Bodies", RFC 2045, November 1996. 330 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 331 Requirement Levels", BCP 14, RFC 2119, March 1997. 333 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 334 10646", STD 63, RFC 3629, November 2003. 336 [RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network 337 Interchange", RFC 5198, March 2008. 339 [RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010. 341 7.2. Informative References 343 [I-D.cheshire-dnsext-dns-sd] 344 Cheshire, S. and M. Krochmal, "DNS-Based Service 345 Discovery", draft-cheshire-dnsext-dns-sd-10 (work in 346 progress), February 2011. 348 [I-D.ietf-core-coap] 349 Shelby, Z., Hartke, K., Bormann, C., and B. Frank, 350 "Constrained Application Protocol (CoAP)", 351 draft-ietf-core-coap-07 (work in progress), July 2011. 353 [I-D.ietf-core-link-format] 354 Shelby, Z., "CoRE Link Format", 355 draft-ietf-core-link-format-06 (work in progress), 356 June 2011. 358 [I-D.ietf-tsvwg-iana-ports] 359 Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 360 Cheshire, "Internet Assigned Numbers Authority (IANA) 361 Procedures for the Management of the Service Name and 362 Transport Protocol Port Number Registry", 363 draft-ietf-tsvwg-iana-ports-10 (work in progress), 364 February 2011. 366 [I-D.shelby-core-coap-req] 367 Shelby, Z., Stuber, M., Sturek, D., Frank, B., and R. 368 Kelsey, "CoAP Requirements and Features", 369 draft-shelby-core-coap-req-02 (work in progress), 370 October 2010. 372 [I-D.shelby-core-resource-directory] 373 Shelby, Z. and S. Krco, "CoRE Resource Directory", 374 draft-shelby-core-resource-directory-00 (work in 375 progress), June 2011. 377 [I-D.vanderstok-core-bc] 378 Stok, P. and K. Lynn, "CoAP Utilization for Building 379 Control", draft-vanderstok-core-bc-04 (work in progress), 380 July 2011. 382 [I-D.vial-core-link-format-wadl] 383 Vial, M. and Z. Shelby, "Interface description with WADL 384 in CoRE", draft-vial-core-link-format-wadl-00 (work in 385 progress), March 2011. 387 [dns-sd] "dns-sd service type registration", 388 Web http://www.dns-sd.org/ServiceTypes.html, 2011. 390 Authors' Addresses 392 Kerry Lynn 393 Consultant 395 Phone: +1 978 460 4253 396 Email: kerlyn@ieee.org 398 Zach Shelby 399 Sensinode 400 Kidekuja 2 401 Vuokatti 88600 402 FINLAND 404 Phone: +358407796297 405 Email: zach@sensinode.com