idnits 2.17.1 draft-lynn-core-discovery-mapping-02.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 (October 22, 2012) is 4204 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 351, but not defined ** Obsolete normative reference: RFC 5988 (Obsoleted by RFC 8288) == Outdated reference: A later version (-18) exists of draft-ietf-core-coap-12 == 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-04 Summary: 1 error (**), 0 flaws (~~), 5 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: April 25, 2013 Sensinode 6 October 22, 2012 8 CoRE Link-Format to DNS-Based Service Discovery Mapping 9 draft-lynn-core-discovery-mapping-02 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 to 18 allow either method to be used to locate service interfaces down to 19 the granularity of function sets in mixed HTTP/CoAP environments. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on April 25, 2013. 38 Copyright Notice 40 Copyright (c) 2012 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Mapping CoRE Link Attributes to DNS-SD Records . . . . . . . . 6 57 3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 58 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 59 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 60 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 61 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 62 7.1. Normative References . . . . . . . . . . . . . . . . . . . 9 63 7.2. Informative References . . . . . . . . . . . . . . . . . . 10 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 66 1. Introduction 68 The Constrained RESTful Environments (CoRE) working group aims at 69 realizing the REST architecture in a suitable form for the most 70 constrained devices (e.g. 8-bit microcontrollers with limited RAM and 71 ROM) and networks (e.g. 6LoWPAN). CoRE is aimed at machine-to- 72 machine (M2M) applications such as smart energy and building 73 automation. The main deliverable of CoRE is the Constrained 74 Application Protocol (CoAP) specification [I-D.ietf-core-coap]. 76 Automated discovery of resources hosted by a constrained server is 77 critical in machine-to-machine applications where human intervention 78 is minimal and static interfaces result in fragility. CoRE Resource 79 Discovery is intended to support fine-grained discovery of hosted 80 resources, their attributes, and possibly other resource relations 81 [RFC6690]. 83 In contrast, service discovery generally refers to a coarse-grained 84 resolution of an end-point's IP address, port number, and protocol. 85 This definition may be extended to include multi-function devices, 86 where the result of the discovery process may include a path to a 87 resource representing a RESTful service interface and possibly a 88 reference to a description of the interface such as a Web Application 89 Description Language (WADL) document 90 [I-D.vial-core-link-format-wadl]. 92 Resource and service discovery are complimentary in the case of large 93 networks, where the latter can facilitate scaling. This document 94 defines a mapping between CoRE Link Format attributes and DNS-Based 95 Service Discovery [I-D.cheshire-dnsext-dns-sd] fields that permits 96 discovery of CoAP services by either means. It also addresses the 97 following CoRE charter requirement [I-D.shelby-core-coap-req]: 99 REQ8: A definition of how to use CoAP to advertise about or query 100 for a Device's description. This description may include the 101 device name and a list of its Resources, each with a URL, an 102 interface description URI (pointing e.g. to a Web Application 103 Description Language (WADL) document) and an optional name or 104 identifier. The name taxonomy used for this description will 105 be consistent with other IETF work, e.g. 106 draft-cheshire-dnsext-dns-sd. [charter] 108 1.1. Terminology 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 112 document are to be interpreted as described in "Key words for use in 113 RFCs to Indicate Requirement Levels" [RFC2119]. 115 1.2. Resource Discovery 117 The main function of Resource Discovery is to provide Universal 118 Resource Identifiers (URIs, also called "links") for the resources 119 hosted by the server, complemented by attributes about those 120 resources and perhaps additional link relations. In CoRE this 121 collection of links and attributes is itself a resource (as opposed 122 to HTTP headers delivered with a specific resource). 124 [RFC6690] specifies a link format for use in CoRE Resource Discovery 125 by extending the HTTP Link Header Format [RFC5988] to describe these 126 link descriptions. The CoRE Link Format is carried as a payload and 127 is assigned an Internet media type. A well-known URI "/.well-known/ 128 core" is defined as a default entry-point for requesting the list of 129 links about resources hosted by a server, and thus performing CoRE 130 Resource Discovery. 132 Resource Discovery can be performed either via unicast or multicast. 133 When a server's IP address is already known, either a priori or 134 resolved via the Domain Name System (DNS) [RFC1034][RFC1035], unicast 135 discovery is performed in order to locate a URI for the resource of 136 interest. This is performed using a GET to /.well-known/core on the 137 server, which returns a payload in the CoRE Link Format. A client 138 would then match the appropriate Resource Type, Interface 139 Description, and possible Content-Type [RFC2045] for its application. 140 These attributes may also be included in the query string in order to 141 filter the number of links returned in a response. 143 1.3. Resource Directories 145 In many M2M scenarios, direct discovery of resources is not practical 146 due to sleeping nodes, limited bandwidth, or networks where multicast 147 traffic is inefficient. These problems can be solved by deploying a 148 network element called a Resource Directory (RD), which hosts 149 descriptions of resources held on other servers (referred to as "end- 150 points") and allows lookups to be performed for those resources. An 151 end-point is a web server associated with specific IP address and 152 port; thus a physical device may host one or more end-points. End- 153 points may also act as clients. 155 The Resource Directory implements a set of REST interfaces for end- 156 points to register and maintain sets of Web Links, called resource 157 directory entries. [I-D.shelby-core-resource-directory] specifies 158 the web interfaces that an RD supports in order for web servers to 159 discover the RD and to register, maintain, lookup and remove resource 160 descriptions; for the RD to validate entries; and for clients to 161 lookup resources from the RD. Furthermore, new link attributes 162 useful in conjunction with an RD are defined. 164 1.4. DNS-Based Service Discovery 166 DNS-Based Service Discovery (DNS-SD) defines a conventional method of 167 configuring DNS PTR, SRV, and TXT resource records to facilitate 168 discovery of services (such as CoAP servers in a subdomain) using the 169 existing DNS infrastructure. This section gives a brief overview of 170 DNS-SD; see [I-D.cheshire-dnsext-dns-sd] for a detailed 171 specification. 173 DNS-SD service names are limited to 255 octets and are of the form: 175 Service Name = .. 177 The part of the service name is identical to the global (DNS 178 subdomain) part of the authority in URIs that identify the resources 179 on an individual server or group of servers. may identify a 180 building zone as shown in the examples of [I-D.vanderstok-core-bc]. 182 The part is composed of at least two labels. The first 183 label of the pair is the application protocol name [RFC6335] preceded 184 by an underscore character. The second label indicates the transport 185 and is always "_udp" for CoAP services. In cases where narrowing the 186 scope of the search may be useful, these labels may be optionally 187 preceded by a subtype name followed by the "_sub" label. An example 188 of this more specific is "lamp._sub._dali._udp". Only 189 the rightmost pair of labels is used in SRV and TXT record names. 191 The default part of the service name may be set at the 192 factory or during the commissioning process. It SHOULD uniquely 193 identify an instance of within a . Taken 194 together, these three elements comprise a unique name for an SRV/ TXT 195 record pair within the DNS subdomain. 197 The granularity of a service name MAY be that of a host or group, or 198 it could represent a particular resource within a CoAP server. The 199 SRV record contains the host name (AAAA record name) and port of the 200 service while protocol is part of the service name. In the case 201 where a service name identifies a particular resource, the path part 202 of the URI must be carried in a corresponding TXT record. 204 A DNS TXT record is in practice limited to a few hundred octets in 205 length, which is indicated in the resource record header in the DNS 206 response message [I-D.cheshire-dnsext-dns-sd]. The data consists of 207 one or more strings comprising a key=value pair. By convention, the 208 first pair is txtver= (to support different versions of a 209 service description). An example string is: 211 | 0x08 | t | x | t | v | e | r | = | 1 | 213 2. Mapping CoRE Link Attributes to DNS-SD Records 215 [I-D.shelby-core-resource-directory] defines two new CoRE Link Format 216 attributes that are particularly useful in conjunction with RDs: 218 link-extension = ( "ins" "=" quoted-string ) ; Max 63 octets 219 link-extension = ( "exp" ) 221 The Resource Instance "ins" attribute is an identifier for a resource 222 that distinguishes it from other similar resources. This attribute 223 SHOULD be unique across resources with the same Resource Type 224 attribute in the domain in which it is used. 226 The Export "exp" attribute is used as a flag to indicate that a link 227 description MAY be exported by a resource directory to external 228 directories. If the "exp" attribute is defined for a link, then the 229 following CoRE specific target attributes (defined in [RFC6690]) are 230 mapped directly into DNS-SD labels. The values are subject to format 231 and length constraints as specified in [I-D.cheshire-dnsext-dns-sd]. 233 2.1. Mapping Resource Instance "ins" attribute into 235 The Resource Instance "ins" attribute maps to the part of 236 a DNS-SD service name. It is stored directly in the DNS as a single 237 DNS label of canonical precomposed UTF-8 [RFC3629] "Net-Unicode" 238 (Unicode Normalization Form C) [RFC5198] text. However, to the 239 extent that the "ins" attribute may be chosen to match the DNS host 240 name of a service, it SHOULD use the syntax defined in Section 3.5 of 241 [RFC1034] and Section 2.1 of [RFC1123]. 243 The part of the name of a service being offered on the 244 network SHOULD be configurable by the user setting up the service, so 245 that he or she may give it an informative name. However, the device 246 or service SHOULD NOT require the user to configure a name before it 247 can be used. A sensible choice of default name can allow the device 248 or service to be accessed in many cases without any manual 249 configuration at all. The default name should be short and 250 descriptive, and MAY include a collision-resistent substring such as 251 the lower bits of the device's MAC address, serial number, 252 fingerprint, or other identifier in an attempt to make the name 253 relatively unique. 255 DNS labels are currently limited to 63 octets in length and the 256 entire service name may not exceed 255 octets. 258 2.2. Mapping Resource Type "rt" attribute into 260 The resource type "rt" attribute is mapped into the 261 part of a DNS-SD service name (as defined in Section 1.4) and SHOULD 262 conform to the reg-rel-type production of the Link Format defined in 263 Section 2 of [RFC6690]. 265 The "rt" attribute MUST be composed of at least a single Net-Unicode 266 text string, without underscore '_' or period '.' and limited to 15 267 octets in length, which represents the application protocol name. 268 This string is mapped to the DNS-SD by prepending an 269 underscore and appending a period followed by the "_udp" label. For 270 example, rt="dali" is mapped into "_dali._udp". 272 The application protocol name may be optionally followed by a period 273 and a service subtype name consisting of a Net-Unicode text string, 274 without underscore or period and limited to 63 octets. This string 275 is mapped to the DNS-SD by appending a period followed 276 by the "_sub" label and then appending a period followed by the 277 service type label pair derived as in the previous paragraph. For 278 example, rt="dali.light" is mapped into "light._sub._dali._udp". 280 The resulting string is used to form labels for DNS-SD records which 281 are stored directly in the DNS. 283 2.3. mapping 285 [TBD: A method must be specified to determine in which DNS zone the 286 CoAP service should be registered. See, for example, Section 11 in 287 [I-D.cheshire-dnsext-dns-sd].] 289 2.4. TXT Record key=value strings 291 The resource is exported to the TXT record key=value string 292 "path=". 294 The Interface Description "if" attribute is exported to the TXT 295 record key=value string "if=". 297 The DNS TXT record can be further populated by importing any other 298 resource description attributes as they share the same key=value 299 format specified in Section 6 of [I-D.cheshire-dnsext-dns-sd]. 301 3. Examples 303 3.1. Importing resource links into DNS-SD 305 Assuming the ability to query a Resource Directory or multicast a GET 306 (?exp) over the local link, CoAP resource discovery may be used to 307 populate the DNS-SD database in an automated fashion. CoAP resource 308 descriptions (links) can be exported to DNS-SD for exposure to 309 service discovery by using the Resource Instance attribute as the 310 basis for a unique service name, composed with the Resource Type as 311 the , and registered in the correct (see 312 section 2.3). The agent responsible for exporting records to the DNS 313 zone file SHOULD be authenticated to the DNS server. 315 The following example shows an agent discovering a resource to be 316 exported: 318 Agent RD 319 | | 320 | --- GET /rd-lookup/res?exp ------------------------------> | 321 | | 322 | | 323 | <-- 2.05 Content ";exp; ------------ | 324 | rt="dali.light";ins="FrontSpot" | 325 | | 327 Req: GET /rd-lookup/res?exp 329 Res: 2.05 Content 330 ; 331 exp;ct=41;rt="dali.light";ins="FrontSpot" 333 The agent subsequenly registers the following DNS-SD RRs: 335 node1.example.com. IN AAAA FDFD::1234 336 _dali._udp IN PTR FrontSpot._dali._udp 337 light._sub._dali._udp IN PTR FrontSpot._dali._udp 338 FrontSpot._dali._udp IN SRV 0 0 5678 node1.example.com. 339 IN TXT txtver=1 340 IN TXT path=/light/27 342 4. IANA Considerations 344 This document makes no request of IANA. 346 Note to RFC Editor: this section may be removed on publication as an 347 RFC. 349 5. Security Considerations 351 [TBD] 353 6. Acknowledgments 355 Valuable contributions and review comments were made by Anders 356 Brandt, Angelo Castellani, Esko Dijk, and Peter van der Stok. 358 7. References 360 7.1. Normative References 362 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 363 STD 13, RFC 1034, November 1987. 365 [RFC1035] Mockapetris, P., "Domain names - implementation and 366 specification", STD 13, RFC 1035, November 1987. 368 [RFC1123] Braden, R., "Requirements for Internet Hosts - Application 369 and Support", STD 3, RFC 1123, October 1989. 371 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 372 Extensions (MIME) Part One: Format of Internet Message 373 Bodies", RFC 2045, November 1996. 375 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 376 Requirement Levels", BCP 14, RFC 2119, March 1997. 378 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 379 10646", STD 63, RFC 3629, November 2003. 381 [RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network 382 Interchange", RFC 5198, March 2008. 384 [RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010. 386 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 388 Cheshire, "Internet Assigned Numbers Authority (IANA) 389 Procedures for the Management of the Service Name and 390 Transport Protocol Port Number Registry", BCP 165, 391 RFC 6335, August 2011. 393 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 394 Format", RFC 6690, August 2012. 396 7.2. Informative References 398 [I-D.cheshire-dnsext-dns-sd] 399 Cheshire, S. and M. Krochmal, "DNS-Based Service 400 Discovery", draft-cheshire-dnsext-dns-sd-11 (work in 401 progress), December 2011. 403 [I-D.ietf-core-coap] 404 Shelby, Z., Hartke, K., Bormann, C., and B. Frank, 405 "Constrained Application Protocol (CoAP)", 406 draft-ietf-core-coap-12 (work in progress), October 2012. 408 [I-D.shelby-core-coap-req] 409 Shelby, Z., Stuber, M., Sturek, D., Frank, B., and R. 410 Kelsey, "CoAP Requirements and Features", 411 draft-shelby-core-coap-req-02 (work in progress), 412 October 2010. 414 [I-D.shelby-core-resource-directory] 415 Shelby, Z., Krco, S., and C. Bormann, "CoRE Resource 416 Directory", draft-shelby-core-resource-directory-04 (work 417 in progress), July 2012. 419 [I-D.vanderstok-core-bc] 420 Stok, P. and K. Lynn, "CoAP Utilization for Building 421 Control", draft-vanderstok-core-bc-05 (work in progress), 422 October 2011. 424 [I-D.vial-core-link-format-wadl] 425 Vial, M. and Z. Shelby, "Interface description with WADL 426 in CoRE", draft-vial-core-link-format-wadl-01 (work in 427 progress), September 2011. 429 [dns-sd] "dns-sd service type registration", 430 Web http://www.dns-sd.org/ServiceTypes.html, 2012. 432 Authors' Addresses 434 Kerry Lynn 435 Consultant 437 Phone: +1 978 460 4253 438 Email: kerlyn@ieee.org 440 Zach Shelby 441 Sensinode 442 Kidekuja 2 443 Vuokatti 88600 444 FINLAND 446 Phone: +358407796297 447 Email: zach@sensinode.com