idnits 2.17.1 draft-zotti-core-sleepy-nodes-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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 9, 2015) is 3335 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5988 (Obsoleted by RFC 8288) == Outdated reference: A later version (-14) exists of draft-ietf-core-interfaces-02 == Outdated reference: A later version (-28) exists of draft-ietf-core-resource-directory-02 == Outdated reference: A later version (-05) exists of draft-koster-core-coap-pubsub-00 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 T. Zotti 3 Internet-Draft Philips Research 4 Intended status: Informational P. van der Stok 5 Expires: September 10, 2015 Consultant 6 E. Dijk 7 Philips Research 8 March 9, 2015 10 Sleepy CoAP Nodes 11 draft-zotti-core-sleepy-nodes-00 13 Abstract 15 6LoWPAN networks rely on application protocols like CoAP to enable 16 RESTful communications in constrained environments. Many of these 17 networks make use of "Sleepy Nodes": battery powered devices that 18 switch off their (radio) interface during most of the time to 19 conserve battery energy. As a result of this, Sleepy Nodes cannot be 20 reached most of the time. This fact prevents using normal 21 communication patterns as specified in the CoRE group, since the 22 server-model is not applicable to these devices. This document 23 discusses and specifies an architecture to support Sleepy Nodes such 24 as battery-powered sensors in 6LoWPAN networks with the goal of 25 guiding and stimulating the discussion on Sleepy Nodes support for 26 CoAP in the CoRE WG. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on September 10, 2015. 45 Copyright Notice 47 Copyright (c) 2015 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.1. Problem statement . . . . . . . . . . . . . . . . . . . . 3 64 1.2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 4 65 1.3. Requirements Language . . . . . . . . . . . . . . . . . . 4 66 2. Solution Architecture . . . . . . . . . . . . . . . . . . . . 6 67 3. Use case scenarios . . . . . . . . . . . . . . . . . . . . . 7 68 4. Initial operations . . . . . . . . . . . . . . . . . . . . . 9 69 4.1. Proxy Discovery . . . . . . . . . . . . . . . . . . . . . 10 70 4.2. Registration at a Proxy . . . . . . . . . . . . . . . . . 10 71 4.3. Initialization of Delegated Resource . . . . . . . . . . 10 72 4.4. Proxy registers at a Discovery Server on behalf of Sleepy 73 Node . . . . . . . . . . . . . . . . . . . . . . . . . . 11 74 5. Interfaces during operation . . . . . . . . . . . . . . . . . 11 75 5.1. Discovering Node DISCOVERs Sleepy Node via Discovery 76 Server . . . . . . . . . . . . . . . . . . . . . . . . . 11 77 5.2. Discovering Node DISCOVERs Sleepy Node via Proxy . . . . 11 78 5.3. Sleepy Node REPORTs events directly to Destination Node . 11 79 5.4. Sleepy Node REPORTs event to Destination Node(s) via 80 Proxy . . . . . . . . . . . . . . . . . . . . . . . . . . 12 81 5.5. Sleepy Node WRITEs changed resource to Proxy . . . . . . 12 82 5.6. A Node WRITEs to Sleepy Node via Proxy . . . . . . . . . 12 83 5.7. Sleepy Node READs resource updates from Proxy . . . . . . 13 84 5.8. A Node READs information from Sleepy Node via Proxy . . . 13 85 5.9. A Sleepy Node READs information from a Server Node . . . 14 86 6. Realization with PubSub server . . . . . . . . . . . . . . . 14 87 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 88 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 89 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 90 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 91 10.1. Normative References . . . . . . . . . . . . . . . . . . 15 92 10.2. Informative References . . . . . . . . . . . . . . . . . 15 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 96 1. Introduction 98 6LoWPAN networks rely on application protocols such as CoAP to enable 99 RESTful communications in constrained environments. Many of these 100 networks feature "Sleepy Nodes": battery-powered nodes which switch 101 on/off their communication interface to conserve battery energy. As 102 a result of this, Sleepy Nodes cannot be reached most of the time. 103 This fact prevents using normal communication patterns as specified 104 by the CoRE group, since the server model is clearly not applicable 105 to the most energy constrained devices. 107 This document discusses and specifies an architecture to support 108 Sleepy Nodes such as battery-powered sensors in 6LoWPAN networks. 109 The proposed solution makes use of a Proxy Node to which a Sleepy 110 Node delegates part of its communication tasks while it is not 111 accessible in the 6LoWPAN network. Direct interactions between 112 Sleepy Nodes and non-Sleepy Nodes are only possible, when the Sleepy 113 Node initiates the communication. 115 Earlier related documents treating the sleepy node subject are the 116 CoRE mirror server [I-D.vial-core-mirror-server] and the Publish- 117 Subscribe in the Constrained Application Protocol (CoAP) 118 [I-D.koster-core-coap-pubsub]. Both documents describe the 119 interfaces to the proxy accompanying the sleepy node. Both make use 120 of the observe option discussed in [I-D.ietf-core-observe]. This 121 document describes the roles of the nodes communicating with the 122 sleepy node and/or its proxy. As such it contributes to 123 understanding how well the other proposals support the operation of 124 the sleepy nodes in a building control context. 126 The issues that need to be addressed to provide support for Sleepy 127 Nodes in 6LoWPAN networks are summarized in Section 1.1. Section 2 128 shows the communications patterns involving Sleepy Nodes in 6LoWPAN 129 networks. Section 3 provides a set of use case descriptions that 130 illustrate how these communication patterns can be used in home and 131 building control scenarios. For each of these scenarios, the 132 behaviour of the Sleepy Node is explained in Section 5, 134 1.1. Problem statement 136 During typical operation, a Sleepy Node has its radio disabled and 137 the CPU may be in a sleeping state. If an external event occurs 138 (e.g. person walks into the room activating a presence sensor), the 139 CPU and radio are powered back on and they send out an event message 140 to another node, or to a group of nodes. After sending this message, 141 the radio and CPU are powered off again, and the Sleepy Node sleeps 142 until the next external event or until a predefined time period has 143 passed. The main problems when introducing Sleepy Nodes into a 144 6LoWPAN network are as follows: 146 Problem 1: How to contact a Sleepy Node that has its radio turned off 147 most of the time for: 149 - Writing configuration settings; 151 - Reading out sensor data, settings or log data 153 - Configuring additional event destination nodes or node groups 155 Problem 2: How to discover a Sleepy Node and its services, while the 156 node is asleep: 158 - Direct node discovery (CoAP GET /.well-known/core as defined in 159 [RFC7252]) does not find the node with high probability. 161 - Mechanisms may be needed to provide, as the result of node 162 discovery, the IP address of a Proxy instead of the IP address of 163 the node directly. 165 Problem 3: How a Sleepy Node can convey data to a node or groups of 166 nodes, with good reliability and minimal energy consumption. 168 1.2. Assumptions 170 The solution architecture specified here assumes that a Sleepy Node 171 has enough energy to perform bidirectional communication during its 172 normal operational state. This solution may be applicable also to 173 extreme low-power devices such as solar powered sensors as long as 174 they have enough energy to perform commissioning and the initial 175 registration steps. These installation operations may require, in 176 some cases, an additional source of power. Since a Sleepy Node is 177 unreachable for relatively long periods of times, the data exchanges 178 in the interaction model are always initiated by a Sleepy Node when 179 its sleep period ends. 181 1.3. Requirements Language 183 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 184 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 185 document are to be interpreted as described in [RFC2119]. 187 This document assumes readers are familiar with the terms and 188 concepts discussed in [RFC7252],[RFC5988], 189 [I-D.ietf-core-resource-directory], 191 [I-D.ietf-core-interfaces],[I-D.ietf-core-observe] and 192 [I-D.vial-core-mirror-server]. 194 In addition, this document makes use of the following additional 195 terminology: 197 Sleepy Node: a battery-powered node which does the on/off switching 198 of its communication interface with the purpose of conserving battery 199 energy 201 Sleeping/Asleep: A Sleepy Node being in a "sleeping state" i.e. its 202 network interface is switched off and a Sleepy Node is not able to 203 send or receive messages. 205 Awake/Not Sleeping: A Sleepy Node being in an "awake state" i.e. its 206 network interface is switched on and the Sleepy Node is able to send 207 or receive messages. 209 Wake up reporting duration: the duration between a wake up from a 210 Sleepy Node and the next wake up and report of the same Node. 212 Proxy: any node that is configured to, or selected to, perform 213 communication tasks on behalf of one or more Sleepy Nodes. 215 Regular Node: any node in the network which is not a Proxy or a 216 Sleepy Node. 218 Reading Node: any regular node that reads information from the Sleepy 219 Node. 221 Configuring Node: any regular node that writes information/ 222 configuration into Sleepy Node(s). Examples of configuration are new 223 thresholds for a sensor or a new value for the wake-up cycle time. 225 Discovering Node: any regular node that performs discovery of the 226 nodes in a network, including Sleepy Nodes. 228 Destination Node: any regular node or node in a group that receives a 229 message that is generated by the Sleepy Node. 231 Server Node: an optional server that the Sleepy Node knows about, or 232 is told about, which is used to fetch information/configuration/ 233 firmware updates/etc. 235 Discovery Server: an optional server that enables nodes to discover 236 all the devices in the network, including Sleepy Nodes, and query 237 their capabilities. For example, a Resource Directory server as 238 defined in [I-D.ietf-core-resource-directory] or a DNS-SD server as 239 defined in [RFC6763]. 241 2. Solution Architecture 243 The solution architecture described in this document makes use of a 244 Proxy Node to which a Sleepy Node delegates part of its communication 245 tasks during its sleeping periods. In particular, the solution is 246 based on the set of functionalities described in 247 [I-D.vial-core-mirror-server] according to which a Proxy Node hosts a 248 'delegated' version of the original CoAP resources of the Sleepy 249 Node. [I-D.vial-core-mirror-server] provides the interface to 250 register, update and remove proxied resources, along with the 251 interface to read and update the proxied resources by both the Sleepy 252 Node and Regular Nodes. 254 Figure 1 provides an overview of the communication interfaces 255 required to support a Sleepy Node in a 6LoWPAN Network, highlighting 256 the different types and roles of the Nodes (shown as blocks) along 257 with the interactions between them. The interfaces are depicted as 258 arrows. The arrows point from the Node taking the communication 259 initiative to the target Node. 261 In some implementations, the roles of Proxy and Discovery Server 262 could be implemented by a single node. Furthermore, a single Node 263 could act in a combination of roles (e.g. it may play both the role 264 of discovering node and Configuring Node). 266 +------------+ +-------------+ 267 | Discovery | <-DISCOVERY-| Discovering | 268 | server | | Node | 269 | (Optional) | +-------------+ 270 +------------+ | 271 | 272 .--DISCOVERY--' +---------+ 273 | | Reading | 274 | .---| Node | 275 v | +---------+ 276 +---------+ +-----------+ | 277 | Sleepy |---REPORT(A)-->| |<--READ--' +-------------+ 278 | Node |---READ------->| Proxy |<--WRITE----| Configuring | 279 | |---WRITE------>| | | Node | 280 +---------+ +-----------+ +-------------+ 281 | | | +-------------+ 282 | | '---REPORT(B)->| Destination | 283 | '-----DIRECT REPORT---------------------->| Node | 284 | +-------------+ 285 | +-----------+ 286 '------------READ--------------------------->| Server | 287 | Node | 288 +-----------+ 290 Figure 1: Interaction model for Sleepy Nodes in 6LowPAN networks 292 3. Use case scenarios 294 To describe the application viewpoint of the solution, we introduce 295 some example scenarios for the various interface functions in 296 Figure 1, assuming the Sleepy Node to be a sensor device in a home or 297 a building control context. 299 Function 1: a Node DISCOVERs Sleepy Node(s) (via Proxy or Discovery 300 Server); for example: 302 - A Node wants to discover given services related to a group of 303 deployed sensors via multicast. It gets responses for the 304 sleeping sensors from the Proxy nodes. 306 - During commissioning phase, a configuring node queries a 307 Discovery Server to find all the proxies providing a given 308 service. 310 Function 2: Sleepy Node REPORTs event to other Node(s) (directly or 311 via Proxy); for example: 313 - A battery-powered sensor sends an event "battery low" directly 314 to a designated reporting location Node. 316 - A battery-powered occupancy sensor detects an event "people 317 present", switches on the radio and sends a request to one or a 318 group of lights to turn on. 320 - A battery-powered temperature sensor reports periodically the 321 room temperature to a designated Node that controls HVAC devices. 322 The sensor reports also extra events when the temperature change 323 deviates from a predefined range. 325 Function 3: Sleepy Node WRITEs information to the Proxy; for example: 327 - A battery-powered sensor wants to extend the registration 328 lifetime of its delegated resource at the Proxy. 330 Function 4: Sleepy Node READs from other Node(s) (directly or via 331 Proxy); for example: 333 - A sensor (periodically) updates internal data tables by fetching 334 it from a predetermined remote node. 336 - A sensor (periodically) checks for new firmware with a remote 337 node. If new firmware is found, the sensor switches to a non- 338 sleepy operation mode, and fetches the data. 340 - A sensor (periodically) checks with his Proxy availability of 341 configuration updates or changes of its delegated resources (e.g. 342 a sensor may detect in this way that a configuring Node has 343 changed its name or modified its reporting frequency). 345 Function 5: Node READs information from Sleepy Node(s) (via Proxy 346 only); for example: 348 - A Node (e.g. in the backend) requests the status of a deployed 349 sensor, e.g. asking the sensor state and/or firmware version and/ 350 or battery status and/or its error log. The Proxy returns this 351 information. 353 - A Node requests a Proxy when a Sleepy sensor was 'last active' 354 (i.e. identified as being awake) in the network. 356 - An authorized Node adds a new subscription to an operational 357 sensor via the Proxy. From that moment on, the new Node receives 358 also the sensor events and status updates from the sensor. 360 Function 6: A Node WRITEs information to a Sleepy Node (via Proxy 361 only); for example: 363 - An authorized Node changes the reporting frequency of a deployed 364 sensor by contacting the Proxy node to which the sensor is 365 registered. 367 - Sensor firmware is upgraded. An authorized Node pushes firmware 368 data blocks to the Proxy, which pushes the blocks to the Sleepy 369 Node. 371 4. Initial operations 373 In order to become fully operational in a network and to communicate 374 over the interfaces shown in Figure 1, a Sleepy Node needs first to 375 perform some initial operations: 377 - Discovery of Proxy (directly or via Discovery Server) 379 - Registration of resources to delegate at a Proxy 381 - Initialization of its delegated resources at the Proxy 383 - Registration to a Discovery Server via Proxy (optional) 385 +------------+ 386 | Discovery | 387 .-Proxy Discovery-->| server |<--Register Sleepy-. 388 | | (Optional) | Node | 389 | +------------+ | 390 | | 391 +---------+ +-----------+ | 392 | |----Direct Proxy Discovery--->| | | 393 | Sleepy |----Register Resources------->| Proxy |-----' 394 | Node |----Initialize Resources----->| | 395 +---------+ +-----------+ 397 Figure 2: Overview of initial operations 399 4.1. Proxy Discovery 401 A Sleepy Node can find a Proxy implementing resource cache 402 functionalities to which it can delegate its own resources by means 403 of: 405 1. Discovery via Discovery Server: this interface is the default one 406 supplied by the Discovery Server, e.g. CoRE Resource Directory 407 [I-D.ietf-core-resource-directory] or DNS-SD [RFC6763]. 409 2. Direct Discovery: a CoAP multicast GET request can be performed 410 on the /.well-known/core resource as specified for CoAP in 411 [RFC7390]. 413 In both cases, a query can be done for the core.ms resource type, 414 defined in [I-D.vial-core-mirror-server]. 416 In a system, The Proxy discovery can be performed even in both ways 417 (e.g. if Discovery via Discovery Server fails, the Sleepy Node can 418 try Direct Discovery). 420 4.2. Registration at a Proxy 422 Once a Sleepy Node has discovered a Proxy by means of one of the 423 procedures described above, the registration step can be performed. 424 To perform registration, a Sleepy Node sends to the Proxy Node a CoAP 425 POST request containing a description of the resources to be 426 delegated to the Proxy as the message payload in the CoRE Link 427 Format. The description of the resource includes the Sleepy Node 428 identifier, its domain and the lifetime of the registration. The 429 Link Format description is identical to the /.well-known/core 430 resource. At the moment of the registration at the Proxy, the Sleepy 431 Node may specify the 'obs' attribute to indicate to the Proxy that a 432 CoAP observation relationship between the delegated resource and a 433 client is allowed and can be performed as described in IETF Draft 434 CoRE Observe [I-D.ietf-core-observe]. Upon successful registration, 435 the Proxy creates a new resource and returns its location. 437 4.3. Initialization of Delegated Resource 439 Once registration has been successfully performed, the Sleepy Node 440 must initialize the delegated resource before it can be visible in 441 Resource Discovery via the Proxy Node. To send the initial contents 442 (e.g. values, device name, manufacturer name) of the delegated 443 resources to the Proxy, the Sleepy Node uses CoAP PUT repeatedly. 444 The use of repeated CoAP PUT can be avoided by writing all relevant 445 resources into the Proxy in one operation by means of the Batch 446 interface described in [I-D.ietf-core-interfaces] After successful 447 initialization, a Proxy should enable resource discovery for the new 448 delegated resources by updating its /.well-known/core resource. 450 4.4. Proxy registers at a Discovery Server on behalf of Sleepy Node 452 Once a Sleepy Node has registered itself to a Proxy, the Proxy has 453 the responsibility to register the Sleepy Node to a Discovery Server 454 and to keep this registration up-to-date. This interface, not to be 455 confused with the interface in which the Sleepy Node registers its 456 resources to a Proxy, is required whenever a Discovery Server is 457 present in the network. There may be in fact deployments that do not 458 have a Discovery Server. At run-time, the Proxy will try to find a 459 Discovery Server and if such server is found it will register the 460 Sleepy Node. The details of the interface are exactly according to 461 the respective Discovery Server specification. A special case might 462 be when Proxy and Discovery Server are embodied by the same node. In 463 this case the registration occurs as an internal process within the 464 Proxy Node itself, upon registration of the Sleepy Node at the Proxy. 466 5. Interfaces during operation 468 This section details the scope and behaviour of each interface 469 function specified in the architecture in Figure 1. 471 5.1. Discovering Node DISCOVERs Sleepy Node via Discovery Server 473 Through this interface, a Discovering Node can discover one or more 474 Sleepy Node(s) through a Discovery Server. The interface is the 475 default one supplied by the Discovery Server, e.g. CoRE Resource 476 Directory or DNS-SD. 478 5.2. Discovering Node DISCOVERs Sleepy Node via Proxy 480 Through this interface, a Discovering Node can discover one or more 481 Sleepy Node(s) through a Proxy. In case a Discovery Server is not 482 active in a system, this is the only way to discover Sleepy Nodes. A 483 CoAP client discovers resources owned by the Sleepy Node but hosted 484 on the Proxy using typical mechanisms such as one or more GETs on the 485 resource /.well-known/core [RFC6690]. 487 5.3. Sleepy Node REPORTs events directly to Destination Node 489 When the Sleepy Node needs to report an event to Destination nodes or 490 groups of Destination nodes present in the subscribers list, it 491 becomes Awake and then it can use standard CoAP POST unicast or 492 multicast requests to report the event. 494 5.4. Sleepy Node REPORTs event to Destination Node(s) via Proxy 496 This interface can be used by the Sleepy Node to communicate a sensor 497 event report message to Proxy (REPORT A) which will further notify it 498 to interested Destination Node(s) (REPORT B) that are not directly 499 present in the subscribers list of the Sleepy Node itself. This 500 indirect reporting is useful for a scalable solution, e.g. there may 501 be many interested subscribers but the Sleepy Node itself can only 502 support a limited number of subscribers given its limits on battery 503 energy. The standard CoAP unicast POST can be used to report events 504 to the Proxy (REPORT A), while the mechanism according to which the 505 Proxy forwards the event to Destination Nodes (REPORT B) may be 506 linked to a specific protocol (for example: CoAP, HTTP, or publish/ 507 subscribe as in MQTT). A client interested in the events related 508 with a specific resource may send a CoAP GET to the Proxy, to obtain 509 the last published state. If a Reading node is interested in 510 receiving updates whenever the Sleepy Node reports event to its 511 Proxy, it can perform a subscription at the Proxy to that specific 512 resource. In this case, a standard CoAP GET with the CoAP Observe 513 option on the delegated resource at the Proxy can be used, as 514 described in [I-D.ietf-core-observe]. 516 5.5. Sleepy Node WRITEs changed resource to Proxy 518 A Sleepy Node can update a proxy resource at the Proxy using a 519 standard CoAP PUT requests on the proxied resource. This interface 520 is only needed when a resource can be changed on the Sleepy Node 521 outside the knowledge of the Proxy, i.e. by an entity which is not 522 the Proxy. For example, a resource can be changed by the Sleepy Node 523 itself. It is good practice, to avoid write/write conflicts at the 524 proxy side, to ensure that such frequently-updated resources are 525 read-only, e.g. the sensed temperature value of a sensor can be read 526 by external nodes but not written. 528 5.6. A Node WRITEs to Sleepy Node via Proxy 530 A Configuring Node uses CoAP PUT to write information (such as 531 configuration data) to the Proxy, where the information is destined 532 for a Sleepy Node. Upon change of a delegated resource, an internal 533 flag is set in the Proxy that the specific resource has changed. 534 Next time the Sleepy Node wakes up, the PS Node checks the Proxy for 535 any modification of its delegated resources and reads those changed 536 resources using CoAP GET requests, as shown in Figure 3. The allowed 537 resources that a Configuring Node can write to, and the CoAP Content- 538 Format of those CoAP resources, is determined in the initial 539 registration phase. 541 5.7. Sleepy Node READs resource updates from Proxy 543 This interface allows a Sleepy Node to retrieve a list of delegated 544 resources that have been modified at the Proxy by other nodes. As in 545 [I-D.vial-core-mirror-server], the path /ms is used to store the 546 sleepy node resources in the proxy. 548 The Sleepy Node can send GET requests to its Proxy on each delegated 549 resource in order to receive their updated representation. The 550 example in Figure 3 shows a configuration node which changes the name 551 of a Sleepy Node at the Proxy. The Sleepy Node can then check and 552 read the modification in its resource. 554 +--------+ +-------+ +---------+ 555 | Sleepy | | Proxy | | Regular | 556 | Node | | | | Node | 557 +--------+ +-------+ +---------+ 558 | | <---PUT /ms/0/dev/n----| 559 | | Payload: Sensor1 | 560 Wake-up |---2.04 Changed-------->| 561 event | | 562 | | | 563 |--POST /ms/0?chk------>| | 564 |<----2.04 Changed------| | 565 | Payload: | | 566 | | | 567 |---GET /ms/0/dev/n---->| | 568 |<-----2.05 Content-----| | 569 | Payload: Sensor1 | | 570 | | | 572 Figure 3: Example: A Sleepy Node READs resource updates from his 573 Proxy 575 5.8. A Node READs information from Sleepy Node via Proxy 577 A Reading Node uses standard CoAP GET to read information of a Sleepy 578 Node via a Proxy. However, not all information/resources from the 579 Sleepy Node may be copied on the Proxy. In that case, the Reading 580 Node cannot get direct access to resources that are not delegated to 581 the Proxy. The strategy to follow in that case is to first WRITE to 582 the Sleepy Node (via the Proxy, Section 5.6) a request for reporting 583 this missing information; where the request can be fulfilled by the 584 Sleepy Node the next time the Sleepy Node wakes up. 586 5.9. A Sleepy Node READs information from a Server Node 588 A Sleepy Node while Awake uses standard CoAP GET to read any 589 information from a Server Node. While the Sleepy Node awaits a CoAP 590 response containing the requested information, it remains awake. To 591 increase battery life of Sleepy Nodes, such an operation should not 592 be performed frequently. 594 6. Realization with PubSub server 596 The registration and discovery of the PubSub broker 597 [I-D.koster-core-coap-pubsub] is covered to the same extent as 598 discussed in this document. Not covered is the direct interaction 599 between sleepy node and destination nodes. The support from a server 600 node to initialize resources or other information also represents an 601 addition to PubSub broker. 603 In addition to the continuous updates provided by the PubSub broker, 604 the ad-hoc query of values, the maintenance of operational 605 parameters, the provision of direct update from sleepy node to a 606 node, the reliability aspects of the update, and the concept of 607 groups are equally important topics that need consideration. 609 7. Acknowledgements 611 TBD 613 8. IANA Considerations 615 The new Resource Type (rt=) Link Target Attribute, 'core.ms' needs to 616 be registered in the "Resource Type (rt=) Link Target Attribute 617 Values" subregistry under the "Constrained RESTful Environments 618 (CoRE) Parameters" registry. This is not yet done by 619 [I-D.vial-core-mirror-server]. 621 9. Security Considerations 623 Layer 2 (MAC) security is used in all communication in the 6LoWPAN 624 network. A Sleepy Node may obtain the Layer 2 network key using the 625 bootstrapping mechanism described in 626 [I-D.kumar-6lo-selective-bootstrap]. On top of this, DTLS and DTLS- 627 multicast can be used for further transport-layer protection of 628 messages between a Sleepy Node and other nodes; and also between a 629 Proxy and other nodes. There are no special adaptations needed of 630 the DTLS handshake to support Sleepy Nodes. During the whole 631 handshake, Sleepy Nodes are required to remain awake to avoid that, 632 in case of small retransmission timers, the other node may think the 633 handshake message was lost and starts retransmitting. In view of 634 this, the only key point, therefore, is that DTLS handshakes are not 635 performed frequently to save on battery power. Based on the DTLS 636 authentication, also an authorization method could be implemented so 637 that only authorized nodes can e.g. 639 - Act as a Proxy for a Sleepy Node. (The Proxy shall be a trusted 640 device given its important role of storing values of parameters 641 for the delegated resources); 643 - READ data from Sleepy Nodes; 645 - WRITE data to Sleepy Nodes (via the Proxy); 647 - Receive REPORTs from Sleepy Nodes (direct or via Proxy). 649 10. References 651 10.1. Normative References 653 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 654 Requirement Levels", BCP 14, RFC 2119, March 1997. 656 [RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010. 658 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 659 Format", RFC 6690, August 2012. 661 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 662 Application Protocol (CoAP)", RFC 7252, June 2014. 664 [RFC7390] Rahman, A. and E. Dijk, "Group Communication for the 665 Constrained Application Protocol (CoAP)", RFC 7390, 666 October 2014. 668 10.2. Informative References 670 [I-D.ietf-core-interfaces] 671 Shelby, Z. and M. Vial, "CoRE Interfaces", draft-ietf- 672 core-interfaces-02 (work in progress), November 2014. 674 [I-D.ietf-core-observe] 675 Hartke, K., "Observing Resources in CoAP", draft-ietf- 676 core-observe-16 (work in progress), December 2014. 678 [I-D.ietf-core-resource-directory] 679 Shelby, Z. and C. Bormann, "CoRE Resource Directory", 680 draft-ietf-core-resource-directory-02 (work in progress), 681 November 2014. 683 [I-D.koster-core-coap-pubsub] 684 Koster, M., Keranen, A., and J. Jimenez, "Publish- 685 Subscribe in the Constrained Application Protocol (CoAP)", 686 draft-koster-core-coap-pubsub-00 (work in progress), 687 October 2014. 689 [I-D.kumar-6lo-selective-bootstrap] 690 Kumar, S. and P. Stok, "Security Bootstrapping over IEEE 691 802.15.4 in selective order", draft-kumar-6lo-selective- 692 bootstrap-00 (work in progress), March 2015. 694 [I-D.vial-core-mirror-server] 695 Vial, M., "CoRE Mirror Server", draft-vial-core-mirror- 696 server-01 (work in progress), April 2013. 698 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 699 Discovery", RFC 6763, February 2013. 701 Authors' Addresses 703 Teresa Zotti 704 Philips Research 705 High Tech Campus 34 706 Eindhoven 5656 AE 707 The Netherlands 709 Phone: +31 6 21175346 710 Email: teresa.zotti@philips.com 712 Peter van der Stok 713 Consultant 714 Kamperfoelie 8 715 Helmond 5708 DM 716 The Netherlands 718 Phone: +31 492474673 719 Email: consultancy@vanderstok.com 721 Esko Dijk 722 Philips Research 723 High Tech Campus 34 724 Eindhoven 5656 AE 725 The Netherlands 727 Phone: +31 6 55408986 728 Email: esko.dijk@philips.com