idnits 2.17.1 draft-he-core-energy-aware-pd-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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** There is 1 instance of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 16, 2012) is 4273 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC2119' is mentioned on line 99, but not defined == Outdated reference: A later version (-04) exists of draft-shelby-core-coap-req-01 == Outdated reference: A later version (-18) exists of draft-ietf-core-coap-06 == Outdated reference: A later version (-14) exists of draft-ietf-core-link-format-07 == Outdated reference: A later version (-01) exists of draft-bormann-core-simple-server-discovery-00 == Outdated reference: A later version (-05) exists of draft-shelby-core-resource-directory-01 Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group X. He 3 Internet-Draft YC.Ma 4 Intended status: Informational Hitachi (China) Research and 5 Expires: January 12, 2013 Development Corporation 6 Z.Cao 7 China Mobile 8 July 16, 2012 10 Energy Aware Proxy Discovery for CoAP 11 draft-he-core-energy-aware-pd-01.txt 13 Abstract 15 CoRE defines a mechanism for resource discovery based on Web linking 16 with discovery, registration,modification, and other procedures. But 17 energy efficiency is very important for resource constrained devices. 18 This specification shows an efficient method for CoAP proxy finding 19 the resource from end-points by reducing multicast messages. 21 The current version -01 of this document is just an initial draft 22 that is modified according to related comments. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on January 12, 2013. 41 Copyright Notice 43 Copyright (c) 2012 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Resource discovery analysis. . . . . . . . . . . . . . . . . . 4 60 3. Energy aware proxy discovery . . . . . . . . . . . . . . . . . 5 61 3.1. Reduced Protocol Operations . . . . . . . . . . . . . . . 5 62 3.2. Example . . . . . . . . . . . . . . . . . . 6 63 4. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 7 64 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 65 6. Normative References . . . . . . . . . . . . . . . . . . . . . .7 67 1. Introduction 69 The Constrained RESTful Environments (CoRE) working group aims at 70 realizing the REST architecture in a suitable form for the most 71 constrained nodes and networks. CoRE is aimed at machine-to-machine 72 (M2M) applications such as smart energy and building automation 73 [I-D.shelby-core-coap-req]. As being the main work of CORE,CoAP 74 defined a proxy mechanism for CoAP end-point, that proxy can be 75 tasked by CoAP clients to perform requests on their behalf 76 [I-D.ietf-core-coap]. 78 Since in many M2M scenarios, direct discovery of resources is not 79 practical due to sleeping nodes, disperse networks, or networks where 80 multicast traffic is inefficient. These problems can be solved by 81 employing an entity called a Resource Directory (RD), which hosts 82 descriptions of resources held on other servers, allowing lookups to 83 be performed for those resources[I-D.shelby-core-resource-directory]. 85 The proxy mechanism should support this RD function in resource 86 constrained environments. There are several methods to discovery 87 proxy by a CoAP end-point, including assuming a default location 88 (e.g. on an Edge Router in a LoWPAN), by assigning an anycast address 89 to the proxy, using DHCP, or using the CoRE Link Format. While 90 reducing energy consumption is essential for battery operated nodes 91 in some devices, which is one of the most important work in M2M 92 communication. Node's energy usage depends on network messages it has 93 to receive and or respond. Thus the discovery procedure should be 94 optimized with energy aware consideration. 96 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 97 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 98 document are to be interpreted as described in RFC 2119 [RFC2119]. 100 Internet-Draft Proxy Discovery for CoAP Jul 20121 102 2. Resource discovery analysis 104 As mentioned in other drafts, resource discovery is performed by 105 sending either a multicast or unicast GET request to 106 /.well-known/core and including a Resource Type (rt) parameter 107 [I-D.ietf-core-link-format] with the value "core-rd" in the query 108 string. Upon success, the response will contain a payload with a 109 link format entry for each RD discovered, with the URL indicating 110 the root resource of the RD. 112 After discovering the location of an RD, an end-point MAY register 113 its resources to the RD's registration interface. This interface 114 accepts a POST from an end-point containing the list of resources to 115 be added to the directory as the message payload in the CoRE Link 116 Format along with query string parameters indicating the name of the 117 end-point, an optional node identifier and the lifetime of the 118 registration. Upon success, the response will be 2.01 "Created" 119 [I-D.shelby-core-resource-directory]. 121 That means once resource discovery needs twice communication process 122 between end-point and proxy. For energy saving point of view, this 123 procedure should be optimized. Another draft indicates more efficient 124 method.A CoAP server that wants to make itself discoverable sends a 125 POST request to the default discovery URI of any Candidate CoAP 126 Server Discovery Server [I-D.bormann-core-simple-server-discovery]. 128 This draft shows more details about energy aware proxy discovery 129 mechanism for CoAP. 131 3. Energy aware proxy discovery 133 3.1. Reduced Protocol Operations 135 The Energy aware proxy reduces discovery and registration processes 136 into one. 138 The end-point acting as a server will use server IP address, the CoAP 139 default port[I-D.ietf-core-coap], and the absolute path 140 "/.well-known/core"[I-D.ietf-core-link-format] to build its POST 141 request. And this request will be send to its Neighbor by unicast 142 (as using 6LOWPAN or IPv6) or to a multicast address. 144 The POST request is a link-format message, which indicates the 145 service list that requesting server wants to make known to the proxy. 147 End-point resources in the proxy are kept active for the period 148 also indicated by the lifetime parameter. But unless the end-point 149 needs to refreshing the data with update message, the data will be 150 kept in this lifetime. Then the data will be delete automatically as 151 expired. 153 The discovery interface is specified as follows: 155 Interaction: EP -> Proxy 157 Path: /.well-known/core 159 Method: POST 161 Content-Type: application/link-format 163 Parameters: 165 Lifetime (lt): Lifetime of the registration in seconds. Range of 166 60-4294967295. If no lifetime is included, the value will be a 167 default lifetime, (e.g.3600seconds) 169 Host (h): The host identifier or name of the registering node. 170 The maximum length of this parameter is 63 octets. This 171 parameter is combined with the Instance parameter (if any) to 172 form the end-point name. If not included, the proxy MUST 173 generate a unique Host name on behalf of the node. 175 Instance (ins): The instance of the end-point on this host, if 176 there are multiple. The maximum length of this parameter is 63 177 octets. 179 Type (rt): The semantic type of end-point. The maximum length of 180 this parameter is 63 octets. 182 Success: 2.01 "Created". The Location header of the new resource 183 entry for the end-point could be e.g. in the form /{rd-base}/ 184 {end-point name} 186 Failure: 4.00 "Bad Request". Malformed request. 188 Failure: 5.03 "Service Unavailable". Service could not perform the 189 operation. 191 3.2 Example 193 The following example shows an end-point with the name "node1" POST 194 temperature resource to a proxy using this interface. 196 End-point Neighbor 197 | (as a proxy) 198 | --- POST /.well-known/core?rt=core-rd-------> | 199 | | 200 | | 201 | <-- 2.01 Created Location: /rd/node1 --------- | 202 | | 204 Req: POST coap://[ff02::1]/.well-known/core?rt=core-rd 205 Payload: 206 ;ct=41;rt="TemperatureC";if="sensor", 208 Res: 2.01 Created 209 Location: /rd/node1 211 The second example shows an end-point with the name "node2" POST 212 video resource to a proxy using this interface, but proxy cannot 213 support this application data. 215 End-point Neighbor 216 | (as a proxy) 217 | --- POST /.well-known/core?rt=core-rd-------> | 218 | | 219 | | 220 | <-- 4.00 Bad Request---------------- --------- | 221 | | 223 Req: POST coap://[ff02::1]/.well-known/core?rt=core-rd 224 Payload: 225 ;ct=41;rt="video";if="sensor", 227 Res: 4.00 Bad Request 229 4. Security Considerations 231 TBD. 233 5. IANA Considerations 235 This document does not require any IANA actions. 237 6. Normative References 239 [I-D.shelby-core-coap-req] 240 Shelby, Z., Stuber, M., Sturek, D., Frank, B., and R. 241 Kelsey, "CoAP Requirements and Features", 242 draft-shelby-core-coap-req-01 (work in progress), 243 April 2010. 245 [I-D.ietf-core-coap] 246 Shelby, Z., Hartke, K., Bormann, C., and B. Frank, 247 "Constrained Application Protocol (CoAP)", 248 draft-ietf-core-coap-06 , May 2011. 250 [I-D.ietf-core-link-format] 251 Shelby, Z., "CoRE Link Format", 252 draft-ietf-core-link-format-07,July 2011. 254 [I-D.bormann-core-simple-server-discovery] 255 Bormann, C.,"CoRE Simple Server Discovery" 256 draft-bormann-core-simple-server-discovery-00, June, 2011 258 [I-D.shelby-core-resource-directory] 259 Shelby, Z.,Krco, S., "CoRE Resource Directory" 260 draft-shelby-core-resource-directory-01, September, 2011 262 Authors' Addresses 264 Xuan He 265 Yuanchen Ma 266 Hitachi R&D China 267 301 of North Tower C, Raycom 268 @ Kexuyuan Nanlu, Haidian District 269 Beijing 100190 270 China 272 Email: 273 xhe@hitachi.cn 274 ycma@hitachi.cn 276 Zhen Cao 277 China Mobile 278 Unit2, 28 Xuanwumenxi Ave,Xuanwu District 279 Beijing 100053 280 China 282 Email: zehn.cao@gmail.com