idnits 2.17.1 draft-bormann-core-simple-server-discovery-00.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 (March 7, 2011) is 4770 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-21) exists of draft-ietf-6lowpan-nd-15 == Outdated reference: A later version (-18) exists of draft-ietf-core-coap-04 == Outdated reference: A later version (-14) exists of draft-ietf-core-link-format-02 ** Obsolete normative reference: RFC 5988 (Obsoleted by RFC 8288) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CoRE Working Group C. Bormann 3 Internet-Draft Universitaet Bremen TZI 4 Intended status: Informational March 7, 2011 5 Expires: September 8, 2011 7 CoRE Simple Server Discovery 8 draft-bormann-core-simple-server-discovery-00 10 Abstract 12 CoRE defines a mechanism for resource discovery based on Web linking. 13 Many applications also need a simple form of discovery for the 14 servers carrying these resources. This specification shows a simple 15 way to extend the link-based resource discovery into a basic form of 16 server discovery. 18 The current version -00 of this document is just an initial draft 19 that is intended to spark discussion. 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 September 8, 2011. 38 Copyright Notice 40 Copyright (c) 2011 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 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Discovery Servers . . . . . . . . . . . . . . . . . . . . . . 4 58 3. CoAP Server Discovery . . . . . . . . . . . . . . . . . . . . 5 59 4. Finding a Candidate CoAP Server Discovery Server . . . . . . . 6 60 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 61 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 62 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 63 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 64 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 65 8.2. Informative References . . . . . . . . . . . . . . . . . . 10 66 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 68 1. Introduction 70 CoRE defines a mechanism for resource discovery based on Web linking 71 [RFC5988] [I-D.ietf-core-link-format]. Many applications also need a 72 simple form of discovery for the servers carrying these resources. 74 More sophisticated CoRE server discovery mechanisms have been 75 proposed [I-D.brandt-coap-subnet-discovery]. The present 76 specification is not intended as a competing protocol but shows a 77 very simple way to extend the link-based resource discovery into a 78 basic form of server discovery. It is an open question whether 79 different applications need different discovery solutions or whether 80 there can be a "scalable" solution that covers both simple and 81 complex scenarios. 83 The protocol as designed here has been prototyped in the SAHARA 84 project at TZI in just a few lines of code. The current version -00 85 of this document serves as an initial draft that is intended to spark 86 discussion. Not all aspects of the protocol as specified are part of 87 the current prototype. We expect to update the specification both 88 based on WG feedback and as we gain experience with the prototype. 90 1.1. Terminology 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 94 document are to be interpreted as described in RFC 2119. (See 95 [RFC2119].) 97 The term "byte" is used in its now customary sense as a synonym for 98 "octet". 100 The terminology from [I-D.ietf-core-coap] applies. 102 In addition: 104 CoAP Server Discovery: This protocol. 106 CoAP Server Discovery Server (CSDS): A server for this protocol, 107 which interacts with other CoAP servers, collects resource 108 discovery information from them and integrates it into larger 109 resource discovery information sets. 111 Candidate CSDS: An IP address that might or might not be useful for 112 conversion to a CSDS URI. 114 2. Discovery Servers 116 This specification defines a simple form of server discovery that 117 makes use of CoAP Server Discovery Servers (CSDS), which are 118 addressed simply using the CoAP protocol [I-D.ietf-core-coap]. 120 The assumption is that there is a way to find one or more CSDSs (see 121 Section 4 for a number of such ways). New CoAP servers that want to 122 provide discoverable services can make themselves known at the CSDSs. 123 CoAP clients can ask the CSDSs for a resource directory in the usual 124 way, which will include both information about the discovery server's 125 own resources and information about other servers that made 126 themselves known to the discovery servers. 128 3. CoAP Server Discovery 130 Simple CoAP Server Discovery makes use of a simple mapping from a 131 server's IP address to a default discovery URI: The default discovery 132 URI is created from the server IP address, the CoAP default port 133 [I-D.ietf-core-coap], and the absolute path "/.well-known/core" 134 [I-D.ietf-core-link-format]. 136 A CoAP server that wants to make itself discoverable occasionally 137 sends a POST request to the default discovery URI of any Candidate 138 CSDS that it finds. 140 The body of the POST request is either 142 o empty, in which case the CoAP Server Discovery Server is 143 encouraged by this POST request to perform GET requests at the 144 requesting server's default discovery URI. 146 or 148 o a link-format document, which indicates the specific services that 149 the requesting server wants to make known to the CSDS. 151 The CSDS integrates the information it received this way into its 152 resource directory. It MAY make the information available to further 153 CSDSs, if it can ensure that a loop does not form. The protocol used 154 between CSDSs to ensure loop-free operation is outside the scope of 155 this document. 157 4. Finding a Candidate CoAP Server Discovery Server 159 CoAP servers that want to contact a CSDS can obtain candidate IP 160 addresses for such servers (Candidate CSDS) in a number of ways. 162 In a 6LoWPAN, good candidates can be taken from: 164 o specific static configuration (e.g., anycast addresses), if any, 166 o the ABRO option of 6LoWPAN-ND [I-D.ietf-6lowpan-nd], 168 o other ND options that happen to point to servers (such as RDNSS), 170 o DHCPv6 options that might be defined later. 172 In networks with more inexpensive use of multicast, the Candidate 173 CSDS may be a well-known multicast address, i.e. CSDS are found by 174 simply sending POST requests to that well-known multicast address 175 (details TBD). 177 As some of these sources are just (more or less educated) guesses, 178 CoAP servers MUST make use of any error messages to very strictly 179 rate-limit requests to Candidate CSDSs that don't work out. E.g., an 180 ICMP Destination Unreachable message (and, in particular, the port 181 unreachable code for this message) may indicate the lack of a CoAP 182 server on the candidate host, or a CoAP error response code such as 183 4.05 "Method Not Allowed" may indicate unwillingness of a CoAP server 184 to act as a CSDS. 186 5. IANA Considerations 188 This document has no actions for IANA. 190 6. Security Considerations 192 (None so far; this section will certainly grow as additional security 193 considerations beyond those listed in the base specifications become 194 known.) 196 7. Acknowledgements 198 The concept for this document was inspired by Zach Shelby et al.'s 199 CoAP discovery node that was available in various CoAP interop 200 events. The current implementation was performed by the students of 201 the SAHARA project, including Bengt Kohrt, Julian Kornberger, Henning 202 Mueller, and Christian Thedieck. Philip Nguyen read an early draft 203 of this document (but all errors are mine). Anders Brandt's draft 204 [I-D.brandt-coap-subnet-discovery] is a fine piece of work and 205 certainly motivated me to finally write this up. 207 8. References 209 8.1. Normative References 211 [I-D.ietf-6lowpan-nd] 212 Shelby, Z., Chakrabarti, S., and E. Nordmark, "Neighbor 213 Discovery Optimization for Low-power and Lossy Networks", 214 draft-ietf-6lowpan-nd-15 (work in progress), 215 December 2010. 217 [I-D.ietf-core-coap] 218 Shelby, Z., Hartke, K., Bormann, C., and B. Frank, 219 "Constrained Application Protocol (CoAP)", 220 draft-ietf-core-coap-04 (work in progress), January 2011. 222 [I-D.ietf-core-link-format] 223 Shelby, Z., "CoRE Link Format", 224 draft-ietf-core-link-format-02 (work in progress), 225 December 2010. 227 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 228 Requirement Levels", BCP 14, RFC 2119, March 1997. 230 [RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010. 232 8.2. Informative References 234 [I-D.brandt-coap-subnet-discovery] 235 Brandt, A., "Discovery of CoAP servers across subnets", 236 draft-brandt-coap-subnet-discovery-00 (work in progress), 237 March 2011. 239 Author's Address 241 Carsten Bormann 242 Universitaet Bremen TZI 243 Postfach 330440 244 Bremen D-28359 245 Germany 247 Phone: +49-421-218-63921 248 Fax: +49-421-218-7000 249 Email: cabo@tzi.org