idnits 2.17.1 draft-dijk-core-sleepy-reqs-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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The exact meaning of the all-uppercase expression 'NOT REQUIRED' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. -- The document date (June 10, 2013) is 3972 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-18) exists of draft-ietf-core-coap-17 == Outdated reference: A later version (-21) exists of draft-ietf-core-block-11 == Outdated reference: A later version (-16) exists of draft-ietf-core-observe-08 == Outdated reference: A later version (-07) exists of draft-ietf-lwig-terminology-04 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CoRE Working Group E. Dijk, Ed. 3 Internet-Draft Philips Research 4 Intended status: Informational June 10, 2013 5 Expires: December 12, 2013 7 Sleepy Devices using CoAP - Requirements 8 draft-dijk-core-sleepy-reqs-00 10 Abstract 12 This document provides requirements for operation of sleepy CoAP 13 devices, based on home control and building control use cases. These 14 requirements can be used to help design, or select, a solution for 15 sleepy CoAP devices in the CoRE WG. In addition, for the existing 16 CoAP, core-block and core-observe functions some notes are made on 17 how these functions could be used in an overall CoRE sleepy devices 18 solution that meets the requirements. 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 December 12, 2013. 37 Copyright Notice 39 Copyright (c) 2013 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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 2 56 1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 2 57 1.3. Requirements Language . . . . . . . . . . . . . . . . . . 3 58 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3. Requirements Categories and Use Cases . . . . . . . . . . . . 4 60 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 7 61 4.1. R1 - SEP Reports To NSEP . . . . . . . . . . . . . . . . 7 62 4.2. R2 - SEP Reads From NSEP . . . . . . . . . . . . . . . . 8 63 4.3. R3 - NSEP Reads From SEP . . . . . . . . . . . . . . . . 9 64 4.4. R4 - NSEP Writes To SEP . . . . . . . . . . . . . . . . . 9 65 4.5. R5 - Large transfer From NSEP To SEP . . . . . . . . . . 10 66 4.6. R6 - Security . . . . . . . . . . . . . . . . . . . . . . 10 67 4.7. R7 - Configuration, commissioning, diagnostics, 68 maintenance . . . . . . . . . . . . . . . . . . . . . . . 11 69 4.8. R8 - General . . . . . . . . . . . . . . . . . . . . . . 11 70 4.9. R9 - Non-functional requirements . . . . . . . . . . . . 12 71 5. CoRE Building Blocks in a Sleepy Devices Solution . . . . . . 12 72 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 73 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 74 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 75 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 76 9.1. Normative References . . . . . . . . . . . . . . . . . . 13 77 9.2. Informative References . . . . . . . . . . . . . . . . . 13 78 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 80 1. Terminology 82 For terminology regarding constrained nodes we use 83 [I-D.ietf-lwig-terminology]. This document focuses on S0 class 84 devices ("always-off"). 86 1.1. Abbreviations 88 CoRE: Constrained RESTful Environments 90 SEP: Sleepy Endpoint 92 NSEP: Non-Sleepy Endpoint 94 1.2. Definitions 95 Sleepy Endpoint (SEP) : A CoAP endpoint hosted on a networked 96 computing device, which sets its network link to a disconnected 97 state during long periods of time to save energy. "Long" means 98 here that the period is of such duration that most messages sent 99 to a SEP are lost despite use of standard "reliable transmission" 100 techniques. The device is S0 class and any of E0/E1/E2 class 101 according to [I-D.ietf-lwig-terminology]. See also the similar 102 definition of SEP in [I-D.rahman-core-sleepy-problem-statement]. 104 Non-Sleepy Endpoint (NSEP) : A CoAP endpoint hosted on a networked 105 computing device, which has its network interface in an always- 106 connected state or operates its network interface such that the 107 endpoint(s) on it appear always-connected. The device is S1 or S2 108 class and any of E1/E2/E3 class as in [I-D.ietf-lwig-terminology]. 110 Sleeping/Asleep : A SEP being in a "sleeping state" i.e. its network 111 interface is disconnected and a SEP is not able to send or receive 112 messages. 114 Awake/Not Sleeping : A SEP being in an "awake state" i.e. its 115 network interface is connected and the SEP is able to send or 116 receive messages. 118 Destination : a NSEP to which event messages are sent by a SEP, or 119 by a Proxy on behalf of a SEP. 121 Heartbeat : a type of message (event), which is sent periodically to 122 indicate to a Destination that the sender is still operational and 123 able to communicate to the Destination. A heartbeat message may 124 contain data about the current status of the sender. Typically 125 sent by a SEP. 127 Proxy : a NSEP which is communicating directly with a SEP; able to 128 cache information/CoAP resources on behalf of SEP for the purpose 129 of further distribution or making it accessible to interested 130 endpoints. It acts as an intermediary between a SEP and a NSEP. 131 The Proxy provides immediate/reliable connectivity, to enable 132 NSEPs to operate on SEP resources even while the SEP is sleeping. 134 In addition to these definitions, readers should also be familiar 135 with the terms and concepts discussed in [I-D.ietf-core-coap]. 137 1.3. Requirements Language 138 Capitalized equirements language is used in this document to indicate 139 the importance of requirements. "MUST" level requirements are those 140 required to be addressed by a solution. "SHOULD" level requirements 141 are about functionality that is preferably provided by a solution. 142 "MAY" level requirements describe optional functionality. 144 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 145 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 146 "OPTIONAL" in this document are to be interpreted as described above 147 and in RFC 2119 [RFC2119]. 149 2. Introduction 151 The CoRE WG charter includes the topic of caching resources on behalf 152 of sleepy devices. Already, various proposals have been made in the 153 CoRE WG with solutions to enable operation of sleepy CoAP endpoints. 155 During and shortly after IETF 83 (March 2012) it was proposed to 156 first clarify the scope and the requirements that a solution should 157 fulfil, before choosing for or developing a solution to support 158 sleepy device operation in CoRE using CoAP. 160 This document aims to provide input to the mentioned requirement 161 gathering and selection process. The application area that we focus 162 on is Home Control and Building Control. The reader is assumed to be 163 familiar with the Sleepy Devices in CoAP Problem Statement 164 [I-D.rahman-core-sleepy-problem-statement]. Possibly, the content of 165 this document can be input to the Problem Statement I-D. 167 First, the requirements categories and related use cases are listed 168 in Section 3. From the use cases a set of requirements was 169 extracted, which is detailed in Section 4. Finally, Section 5 170 provides some ideas how current protocols being defined in the CoRE 171 WG ([I-D.ietf-core-coap], [I-D.ietf-core-block], 172 [I-D.ietf-core-observe]) can be applied to a sleepy CoAP devices 173 solution that meets the requirements. 175 3. Requirements Categories and Use Cases 177 From use cases, a number of requirements can be extracted for SEPs 178 and for constrained RESTful systems that contain SEP devices. 179 Section 4 will list the main requirements that we extracted. 181 This section lists a number of use cases in Home Control and Building 182 Control, in which SEP functionality would be desired. The main 183 driver for SEP functionality in CoAP is to achieve fully wireless, 184 battery-operated or energy-harvesting CoAP devices that require 185 minimal manual maintenance, e.g. having a long battery lifetime. 187 Note that CoRE application domains like Industrial Sensing, Smart 188 Energy or Smart City are not covered by these use cases. However, it 189 is likely that requirements from these domains overlap to a large 190 extent with those presented here. 192 The requirements are organized in the categories (Rx) shown below. 193 Per category, some use case examples are provided. 195 R1. Report SEP->NSEP: SEP reports new information (e.g. events) 196 to a non-SEP, or to a multicast group of non-SEPs. 198 * A solar-powered daylight sensor periodically measures daylight 199 intensity in a room and reports this information to a 200 designated NSEP or group of endpoints. For example, a local 201 luminaire that adapts its dim level according to daylight 202 level. 204 * An energy-harvesting light switch is pressed, switches on the 205 radio and sends a request to a light or group of lights (NSEPs) 206 to turn on. 208 * A battery-powered occupancy sensor detects an event of people 209 present, switches on the radio and sends a request to one or a 210 group of CoAP-enabled lights to turn on. 212 * Alternative to above: instead of sending directly to the 213 light(s) the sensor sends to an intermediate CoAP node (e.g. 214 Proxy or controller) which then carries out the request to 215 endpoint/group(s) of endpoints. 217 * A battery-powered temperature sensor reports room temperature 218 to a designated NSEP that controls HVAC devices. The sensor 219 reports periodically and reports extra when the temperature 220 deviates from a predefined range. 222 * A battery-powered sensor sends an event "battery low" to a 223 designated reporting location (NSEP). 225 R2. Read SEP->NSEP: SEP reads (or queries) information from a 226 non-SEP 228 * A sleepy sensor (periodically) updates internal data tables by 229 fetching it from a predetermined remote NSEP, e.g. a backend 230 server. 232 * A sleepy sensor (periodically) checks for new firmware with a 233 remote (CoAP) endpoint. If new firmware is found, the sensor 234 switches to a non-sleepy operation mode, starts an update 235 procedure and new firmware is downloaded in the device. 237 R3. Read NSEP->SEP: Non-SEP reads (or queries) information from a 238 SEP, or from a multicast group of SEPs. 240 * A NSEP (e.g. in the backend) requests the status of a deployed 241 sleepy sensor, e.g. current sensor state and/or firmware 242 version and/or battery status and/or its error log. It expects 243 a response within one, or at most a few, second(s). 245 * A NSEP (e.g. in the backend) requests the status of a group of 246 deployed sleepy sensors. It expects responses even for the 247 sensors that are sleeping at the time of doing the request. 249 * A NSEP requests information on when a sleepy sensor was 'last 250 active' (i.e. identified as being awake) in the network. 252 * A NSEP subscribes itself to sensor events and status reports of 253 multiple sleepy sensors for diagnostic purposes. The 254 subscription relation is only temporary, until the diagnostic 255 operation concludes. 257 R4. Write NSEP->SEP: Non-SEP writes (or configures, updates, 258 deletes, etc.) information to a SEP 260 * An authorized NSEP changes the reporting frequency of a 261 deployed sleepy sensor. 263 * An authorized NSEP adds a new reporting endpoint to an 264 operational sleepy sensor. From that moment on, the new 265 endpoint (NSEP) receives also the sensor events and status 266 updates from the sleepy sensor. 268 * A remote NSEP instructs a sleepy sensor to upgrade its 269 firmware. The sensor firmware is then upgraded. (In whatever 270 way - the SEP may pull data from a server, or the remote NSEP 271 may push data to the SEP.) 273 R5. Transfer NSEP->SEP: Large data volume e.g. firmware is 274 transferred into a SEP. The data originates from a non-SEP. 275 Either NSEP or SEP takes initiative to start the transfer. 277 * A remote NSEP instructs a sleepy sensor to upgrade its 278 firmware. The sensor firmware is then upgraded. (In whatever 279 way - the SEP may pull data from a server, or the remote NSEP 280 may push data to the SEP.) 282 * A sleepy sensor (SEP) on own initiative switches to a non- 283 sleepy operation mode, starts an update procedure and new 284 firmware is downloaded in the device. 286 R6. Security 288 R7. Configuration, commissioning, diagnostics & maintenance 290 * An installer deploys a new sleepy sensor in a room. The sensor 291 is then configured to control all lights in the room in a 292 commissioning phase. Finally, the sleepy operation is enabled 293 in the sensor right after the commissioning phase (i.e. start 294 of the operational phase). 296 R8. General 298 4. Requirements 300 4.1. R1 - SEP Reports To NSEP 302 1. Reporting destination type(s). A SEP MUST be able to report 303 directly to an endpoint or group; and to an intermediate node/ 304 Proxy that takes care of communicating to the final endpoint/ 305 group. Multiple reporting destinations MUST be supported. 306 Rationale: direct unicast/multicast reporting is needed for high 307 reliability, low latency, and avoiding single-point-of-failure 308 situations. 310 2. Reporting destination location. A reporting destination 311 endpoint MUST be able to handle any addressing like: link-local, 312 subnet-local (e.g. 6LoWPAN), site-local (typ. corporate LAN/ 313 Intranet), or global (WAN/Intranet/Internet). 315 3. Reporting latency. Any report SHOULD be delivered with low 316 latency to the final local destination. Rationale: use cases 317 include e.g. person detection applications, actuators react 318 within 200 ms. 320 4. Reporting reliability unicast. SEP MUST be able to reliably 321 report events in unicast. For example, a 99.9% reliability may 322 be required in a specific use case. 324 5. Reporting reliability multicast. SEP MUST be able to report 325 events in multicast to a group of NSEPs, with similar 326 reliability as is achievable by a NSEP doing a multicast. 328 6. Multicast report via Proxy. It SHOULD be possible to configure 329 a Proxy, to which a SEP reports in unicast, such that it resends 330 the report in multicast. Rationale: to allow simplified SEPs 331 that do not have multicast ability; or devices that do not know 332 a priori how multicast operation needs to be done in target 333 networks. 335 7. Reporting group topology. For a multicast group it MUST be 336 possible to place group members across multiple subnets, with 337 routers in between. Rationale: allow for flexibility and 338 organic IP network growth. 340 8. SEP reporting configuration. A CoRE solution MUST leave the 341 freedom to configure a SEP with reporting destination 342 address(es) in the following ways: standard-defined, pre- 343 commissioned, runtime configured, runtime discovered. 344 Rationale: leave it to vendors or other SDOs how device 345 relations are (pre)configured. 347 9. Configuration of receiver of SEP events. A CoRE solution SHOULD 348 allow a receiver of SEP events to discover group IP address(es) 349 it has to listen to, to receive events from a specific SEP. 351 10. Direct SEP subscription. A mechanism MUST be provided for NSEPs 352 to receive events (i.e. resource updates) sent by a SEP directly 353 to NSEP, during a given period. Event delivery MUST still work 354 even if a Proxy is not available at the time of the event. 355 Subscribing to events MUST work also if the SEP is sleeping at 356 the time of subscribing. 358 11. Proxy subscription. A solution SHOULD be provided for clients 359 to receive events sent by a Proxy on behalf of a SEP, during a 360 given period. Rationale: to avoid high load on the SEP due to 361 high number of subscribers. 363 4.2. R2 - SEP Reads From NSEP 365 1. Read direct. It SHOULD be possible for a SEP to read from/query 366 a selected CoAP and/or HTTP server. 368 2. Sleep mode change. It is allowed that the SEP temporarily 369 switches to an always-on mode to perform a Read task. 371 4.3. R3 - NSEP Reads From SEP 373 1. Read via Proxy. It MUST be possible for a NSEP to read/query 374 designated SEP information via a Proxy. Rationale: the SEP is 375 unavailable most of the time, making direct contact practically 376 impossible. 378 2. Multicast read via proxies. It SHOULD be possible for a NSEP to 379 perform a CoAP multicast request to read/query a group of SEPs, 380 or a group of proxies. 382 3. Reading reported information. A client MUST be able to read the 383 information (CoAP resources) that a SEP is currently reporting 384 (e.g. periodically or event-based). 386 4. Reading non-reported information. A client MUST be able to read 387 information (CoAP resources) that a SEP is currently not 388 reporting. 390 * Note: this may require that the Proxy has a specific relation 391 to the SEP that enables it to detect when the SEP is awake, 392 and at that moment forward the information request to the SEP 393 for processing. 395 * Note: some information (manufacturer name) may be sent a 396 priori by the SEP to a Proxy, while other information (error 397 log) may be sent on demand only. 399 5. Read latency. The response time for a read operation SHOULD NOT 400 differ significantly from a typical NSEP->NSEP request in the 401 same IP network, if the information is available in the Proxy. 402 If the Proxy needs to wait for the next SEP's wakeup, the 403 response time SHOULD NOT significantly exceed the device's 404 current sleep duration. 406 6. Client location. A requesting client MUST be allowed to be link- 407 local to the SEP, or subnet-local (e.g. 6LoWPAN), or site-local 408 (typ. corporate LAN/Intranet), or global (WAN/Intranet/Internet). 410 4.4. R4 - NSEP Writes To SEP 412 1. Write via Proxy. It MUST be possible for an authorized NSEP to 413 write information to or delete information on a SEP via a Proxy. 415 2. Client location: see R3 client location. 417 3. Write latency. The writing latency SHOULD be approximately equal 418 to the current sleep interval duration of the SEP, or less. 420 Rationale: while SEP is sleeping, no writing can possibly take 421 place. Best performance is when write operation occurs at the 422 next SEP wake-up. 424 4. Write reliability. The write operation MUST be performed 425 reliably. (For example, a 99% success rate may be required in a 426 use case, with notification to the application layer about 427 outcome of the write operation.) 429 4.5. R5 - Large transfer From NSEP To SEP 431 1. Sleeping mode. A SEP MAY switch its mode of operation 432 temporarily to always-on to execute a data transfer. 434 2. Buffering requirement. A Proxy MUST NOT be required to buffer an 435 entire data object in its memory. Rationale: a firmware image 436 will never fit entirely in a Proxy's available memory. 438 3. Location of data object. See R3 client location. 440 4. Transfer external trigger. There MUST be a reliable way for a 441 NSEP to trigger a SEP into starting a large data transfer. 442 Rationale: to cover situations where the SEP itself is in best 443 position to initiate the transfer, e.g. acting as a CoAP/HTTP 444 client to fetch data blocks at its own pace. 446 5. Transfer latency. If a transfer is initiated by a NSEP, It 447 SHOULD be possible for the transfer to start at the next time 448 instant the SEP wakes up. 450 4.6. R6 - Security 452 1. Security level. It MUST be possible to secure communication with 453 a SEP at a level similar to NSEP communication. (E.g., DTLS.) 455 2. Bootstrap security. It SHOULD be possible to secure any 456 communication with a SEP that is needed to bootstrap a (new) SEP 457 into a network. 459 3. Proxy security. The Proxy MAY be a trusted device. That is, 460 end-to-end CoAP security from SEP to Destination is NOT REQUIRED 461 if a Proxy is used in the communication process. 463 4. Write Authentication and Authorization. When information/ 464 resources on a SEP are being written or deleted, it MUST be 465 possible for a SEP (or its Proxy) to authenticate the writer and 466 to check that it is authorized to do so. 468 5. Read/subscribe Authentication and Authorization. When 469 information/resources on a SEP are being requested, it SHOULD be 470 possible for a SEP (or its Proxy) to authenticate the reader/ 471 subscriber and to check that it is authorized to read. 473 4.7. R7 - Configuration, commissioning, diagnostics, maintenance 475 1. Configurable sleep interval(s). The sleep interval (i.e. 476 heartbeat interval) MUST be fully configurable per sleepy node. 477 A wide range of values (seconds, minutes, hours, days) SHOULD be 478 supported. Variable sleep intervals SHOULD be supported. 479 Multiple sleep intervals (such as a different interval for each 480 sensor resource attached to an endpoint) MUST be supported. 482 2. Discoverability. There MUST be one or more ways defined for a 483 NSEP to establish the existince of a SEP and to find the IP 484 address to contact the device (either directly or its Proxy). 485 Note: possible ways may be DNS discovery, Resource Directory, IP 486 address(es) derived from hardware identifier, pre-commissioned, 487 standard-defined, etc. 489 3. Discoverability 2. There SHOULD be a way to discover all proxies 490 in a given network scope (e.g. link-local, subnet-local, site- 491 local) and to find out which SEP they are representing. 493 4. Portability. A SEP SHOULD be able to be relocated to a new 494 physical position, while keeping its existing association to an 495 IP subnet or PAN, without requiring any reconfiguration of the 496 SEP and/or NSEPs/proxies it communicates with. 498 5. A Proxy caching information from a SEP MAY be configured to store 499 additional computed information based on past resource values, 500 e.g. an average, standard deviation, history graph, etc. 502 4.8. R8 - General 504 1. Optional reliability. It MUST be possible for a SEP to 505 optionally use Confirmable (CON) CoAP messaging. 507 2. Cached resources freshness. Having a different Max-Age 508 (freshness duration) per resource MUST be supported. 510 3. Wake-up triggers. Wake-up based on a timer trigger, wake-up 511 based on an (unpredictable) event trigger (e.g. sensor based), 512 and a combination of both all MUST be possible. 514 4. Local Proxy. A SEP MAY rely on the presence of at least one 515 "parent/Proxy" device in radio range. 517 5. Reception windows. A SEP SHOULD enable a radio reception 518 interval at least once every interval it is awake. 520 4.9. R9 - Non-functional requirements 522 1. Implementation complexity. A solution SHOULD have minimal 523 implementation complexity on the SEPs. Even if this implies 524 shifting additional complexity to the clients/proxies. 525 Rationale: sleepy sensor devices are expected to be more 526 constrained along multiple resource axes (RAM, ROM, MCU, energy). 528 2. Configuration effort sleepy. A solution SHOULD operate with 529 minimal configuration effort of SEPs. 531 3. Configuration effort proxies/clients. A solution SHOULD operate 532 with minimal configuration effort of non-SEPs, keeping in mind 533 that both configuration effort and implementation complexity for 534 SEPs should be minimized with higher priority. Rationale: SEPs 535 are typically harder to configure once deployed, due to frequent/ 536 unpredictable sleep periods. 538 4. Network load. A solution SHOULD introduce minimal extra network 539 load (number of messages, message sizes, etc.) 541 5. Battery life. A CoRE SEP solution SHOULD aim to provide as long 542 as possible battery life for SEPs. Battery life of non-SEPs is 543 assumed to be of minor importance. 545 6. Scalability. Number of devices that can subscribe to events from 546 a single SEP SHOULD be as high as possible. 548 7. Adaptability. SEPs SHOULD be aware, or made aware, of any 549 relevant network configuration changes. 551 8. NSEP communication effort. The "effort" a NSEP has to spend on 552 communicating with SEPs SHOULD be minimal. Note: "effort" here 553 includes complexity, need for protocols in addition to core-coap, 554 number of transactions/messages needed, waiting time, etc. 556 5. CoRE Building Blocks in a Sleepy Devices Solution 558 In the CoRE WG there are various functions, or "building blocks", 559 being developed that could be applied in a CoRE sleepy devices 560 solution. 562 o [I-D.ietf-core-coap] CoAP proxy: can possibly be re-used to 563 implement the role of Proxy as defined in this document. However, 564 this could require adding some special functions/measures to deal 565 with SEPs. Currently a CoAP proxy will have the problem that it 566 may not reach the SEP for prolonged periods of time, e.g. to 567 forward a CoAP request or a CoAP+observe request to the SEP. 569 o [I-D.ietf-core-observe]: the core-observe paradigm and 570 subscription + notification syntax can possibly be re-used to meet 571 the subscription/notification requirements. A problem to solve is 572 that a CoAP client is unable to perform an observe request to a 573 SEP, since it is likely to be sleeping at the time the request is 574 made. In worst case, the SEP can never be reached by the client. 576 o [I-D.ietf-core-block]: can be used for implementing the 577 requirements R5 (Large transfers, Section 4.5). However, a 578 blockwise POST or PUT initiated by a NSEP can not be immediately 579 used, again due to the reason that the SEP is likely to be asleep 580 at the time(s) the NSEP sends its request. 582 6. Acknowledgements 584 Thanks to Peter van der Stok and Sye Loong Keoh for reviewing the 585 text. 587 7. IANA Considerations 589 This document includes no request to IANA. 591 8. Security Considerations 593 This document contains requirements for solutions, including security 594 requirements (Section 4.6). Refer to [I-D.ietf-core-coap] 595 Section 11.2 for security considerations on (caching) proxies. This 596 is very relevant as the requirements indicate that use of a caching 597 proxy may be necessary. 599 9. References 601 9.1. Normative References 603 [I-D.ietf-core-coap] 604 Shelby, Z., Hartke, K., and C. Bormann, "Constrained 605 Application Protocol (CoAP)", draft-ietf-core-coap-17 606 (work in progress), May 2013. 608 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 609 Requirement Levels", BCP 14, RFC 2119, March 1997. 611 9.2. Informative References 613 [I-D.ietf-core-block] 614 Bormann, C. and Z. Shelby, "Blockwise transfers in CoAP", 615 draft-ietf-core-block-11 (work in progress), March 2013. 617 [I-D.ietf-core-observe] 618 Hartke, K., "Observing Resources in CoAP", draft-ietf- 619 core-observe-08 (work in progress), February 2013. 621 [I-D.ietf-lwig-terminology] 622 Bormann, C., Ersue, M., and A. Keranen, "Terminology for 623 Constrained Node Networks", draft-ietf-lwig-terminology-04 624 (work in progress), April 2013. 626 [I-D.rahman-core-sleepy-problem-statement] 627 Rahman, A., Fossati, T., Loreto, S., and M. Vial, "Sleepy 628 Devices in CoAP - Problem Statement", draft-rahman-core- 629 sleepy-problem-statement-01 (work in progress), October 630 2012. 632 Author's Address 634 Esko Dijk (editor) 635 Philips Research 636 High Tech Campus 34 637 Eindhoven 5656 AE 638 NL 640 Phone: +31 40 2747947 641 Email: esko.dijk@philips.com