idnits 2.17.1
draft-zotti-core-sleepy-nodes-04.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:
----------------------------------------------------------------------------
== It seems as if not all pages are separated by form feeds - found 0 form
feeds but 26 pages
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 (September 28, 2015) is 3105 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-03
== Outdated reference: A later version (-28) exists of
draft-ietf-core-resource-directory-04
== Outdated reference: A later version (-05) exists of
draft-koster-core-coap-pubsub-02
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: March 31, 2016 Consultant
6 E. Dijk
7 Philips Research
8 September 28, 2015
10 Sleepy CoAP Nodes
11 draft-zotti-core-sleepy-nodes-04
13 Abstract
15 Control 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 mesh networks with the goal of
25 proposing a standardisation solution for Sleepy Node proxies.
27 Status of This Memo
29 This Internet-Draft is submitted in full conformance with the
30 provisions of BCP 78 and BCP 79.
32 Internet-Drafts are working documents of the Internet Engineering
33 Task Force (IETF). Note that other groups may also distribute
34 working documents as Internet-Drafts. The list of current Internet-
35 Drafts is at http://datatracker.ietf.org/drafts/current/.
37 Internet-Drafts are draft documents valid for a maximum of six months
38 and may be updated, replaced, or obsoleted by other documents at any
39 time. It is inappropriate to use Internet-Drafts as reference
40 material or to cite them other than as "work in progress."
42 This Internet-Draft will expire on March 31, 2016.
44 Copyright Notice
46 Copyright (c) 2015 IETF Trust and the persons identified as the
47 document authors. All rights reserved.
49 This document is subject to BCP 78 and the IETF Trust's Legal
50 Provisions Relating to IETF Documents
51 (http://trustee.ietf.org/license-info) in effect on the date of
52 publication of this document. Please review these documents
53 carefully, as they describe your rights and restrictions with respect
54 to this document. Code Components extracted from this document must
55 include Simplified BSD License text as described in Section 4.e of
56 the Trust Legal Provisions and are provided without warranty as
57 described in the Simplified BSD License.
59 Table of Contents
61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
62 1.1. Problem statement . . . . . . . . . . . . . . . . . . . . 3
63 1.2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 4
64 1.3. Requirements Language . . . . . . . . . . . . . . . . . . 4
65 1.4. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 5
66 2. Use cases and architecture . . . . . . . . . . . . . . . . . 5
67 2.1. Node interactions and use cases . . . . . . . . . . . . . 6
68 2.2. Architecture . . . . . . . . . . . . . . . . . . . . . . 9
69 2.3. Example contents . . . . . . . . . . . . . . . . . . . . 10
70 3. Design motivation . . . . . . . . . . . . . . . . . . . . . . 10
71 4. Interactions involving Resource Directory . . . . . . . . . . 10
72 5. Synchronize interface . . . . . . . . . . . . . . . . . . . . 12
73 5.1. Sleepy Node discovers proxy . . . . . . . . . . . . . . . 12
74 5.2. Registration at a Proxy . . . . . . . . . . . . . . . . . 12
75 5.3. De-registration at a Proxy . . . . . . . . . . . . . . . 15
76 5.4. Initialization of delegated resource . . . . . . . . . . 16
77 5.5. Sleepy Node updates delegated resource at Proxy . . . . . 17
78 5.6. Sleepy Node READs resource updates from Proxy . . . . . . 18
79 6. Delegate Interface . . . . . . . . . . . . . . . . . . . . . 18
80 6.1. Discovering Endpoint discovers Sleepy Node at Proxy . . . 19
81 6.2. Proxy REPORTs events to Endpoint . . . . . . . . . . . . 20
82 6.3. A Node WRITEs to Sleepy Node via Proxy . . . . . . . . . 21
83 6.4. A Node READs information from Sleepy Node via Proxy . . . 22
84 7. Direct Interface . . . . . . . . . . . . . . . . . . . . . . 22
85 7.1. Sleepy Node REPORTs events directly to Destination Node . 22
86 7.2. A Sleepy Node READs information from a Server Node . . . 23
87 8. Realization with PubSub broker . . . . . . . . . . . . . . . 23
88 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
89 10. Security Considerations . . . . . . . . . . . . . . . . . . . 24
90 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24
91 12. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 24
92 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
93 13.1. Normative References . . . . . . . . . . . . . . . . . . 25
94 13.2. Informative References . . . . . . . . . . . . . . . . . 25
95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
97 1. Introduction
99 Control networks rely on application protocols such as CoAP to enable
100 RESTful communications in constrained environments. Many of these
101 networks feature "Sleepy Nodes": battery-powered nodes which switch
102 on/off their communication interface to conserve battery energy. As
103 a result of this, Sleepy Nodes cannot be reached most of the time.
104 This fact prevents using normal communication patterns as specified
105 by the CoRE group, since the server model is clearly not applicable
106 to the most energy constrained devices.
108 This document discusses and specifies an architecture to support
109 Sleepy Nodes such as battery-powered sensors in wireless networks.
110 The proposed solution makes use of a Proxy Node to which a Sleepy
111 Node delegates part of its communication tasks while it is not
112 accessible in the wireless network. Direct interactions between
113 Sleepy Nodes and non-Sleepy Nodes are only possible, when the Sleepy
114 Node initiates the communication.
116 Earlier related documents treating the Sleepy Node subject are the
117 CoRE mirror server [I-D.vial-core-mirror-server] and the Publish-
118 Subscribe in the Constrained Application Protocol (CoAP)
119 [I-D.koster-core-coap-pubsub]. Both documents describe the
120 interfaces to the proxy accompanying the Sleepy Node. Both make use
121 of the observe option discussed in [I-D.ietf-core-observe]. This
122 document describes the roles of the nodes communicating with the
123 Sleepy Node and/or its proxy. The draft describes the differences
124 between the concepts supporting the Sleepy Node, and the concepts
125 underlying the PubSub paradigm.
127 The draft relies heavily on the concepts introduced by the Resource
128 Directory [I-D.ietf-core-resource-directory], and describes how the
129 Sleepy Node profits of the introduction of a Resource Directory into
130 the network.
132 The issues that need to be addressed to provide support for Sleepy
133 Nodes in Control networks are summarized in Section 1.1. Section 2
134 provides a set of use case descriptions that introduce communication
135 patterns to be used in home and building control scenarios.
136 Section 4, Section 5,Section 6, and Section 7 specify interfaces to
137 support each of these scenarios. Many interface specifications and
138 examples are taken over from [I-D.vial-core-mirror-server].
140 1.1. Problem statement
142 During typical operation, a Sleepy Node has its radio disabled and
143 the CPU may be in a sleeping state. If an external event occurs
144 (e.g. person walks into the room activating a presence sensor), the
145 CPU and radio are powered back on and they send out a message to
146 another node, or to a group of nodes. After sending this message,
147 the radio and CPU are powered off again, and the Sleepy Node sleeps
148 until the next external event or until a predefined time period has
149 passed. The main problems when introducing Sleepy Nodes into a
150 wireless network are as follows:
152 Problem 1: How to contact a Sleepy Node that has its radio turned off
153 most of the time for:
155 - Writing configuration settings.
157 - Reading out sensor data, settings or log data.
159 - Configuring additional event destination nodes or node groups.
161 Problem 2: How to discover a Sleepy Node and its services, while the
162 node is asleep:
164 - Direct node discovery (CoAP GET /.well-known/core as defined in
165 [RFC7252]) does not find the node with high probability.
167 - Mechanisms may be needed to provide, as the result of node
168 discovery, the IP address of a Proxy instead of the IP address of
169 the node directly.
171 Problem 3: How a Sleepy Node can convey data to a node or groups of
172 nodes, with good reliability and minimal energy consumption.
174 1.2. Assumptions
176 The solution architecture specified here assumes that a Sleepy Node
177 has enough energy to perform bidirectional communication during its
178 normal operational state. This solution may be applicable also to
179 extreme low-power devices such as solar powered sensors as long as
180 they have enough energy to perform commissioning and the initial
181 registration steps. These installation operations may require, in
182 some cases, an additional source of power. Since a Sleepy Node is
183 unreachable for relatively long periods of times, the data exchanges
184 in the interaction model are always initiated by a Sleepy Node when
185 its sleep period ends.
187 1.3. Requirements Language
189 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
190 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
191 document are to be interpreted as described in [RFC2119].
193 This document assumes readers are familiar with the terms and
194 concepts discussed in [RFC7252],[RFC5988],
195 [I-D.ietf-core-resource-directory],
196 [I-D.ietf-core-interfaces],[I-D.ietf-core-observe] and
197 [I-D.vial-core-mirror-server].
199 In addition, this document makes use of the following additional
200 terminology:
202 Sleepy Node: a battery-powered node which does the on/off switching
203 of its communication interface with the purpose of conserving battery
204 energy
206 Sleeping/Asleep: A Sleepy Node being in a "sleeping state" i.e. its
207 network interface is switched off and a Sleepy Node is not able to
208 send or receive messages.
210 Awake/Not Sleeping: A Sleepy Node being in an "awake state" i.e. its
211 network interface is switched on and the Sleepy Node is able to send
212 or receive messages.
214 Wake up reporting duration: the duration between a wake up from a
215 Sleepy Node and the next wake up and report of the same Node.
217 Proxy: any node that is configured to, or selected to, perform
218 communication tasks on behalf of one or more Sleepy Nodes.
220 Regular Node: any node in the network which is not a Proxy or a
221 Sleepy Node.
223 1.4. Acronyms
225 This Internet-Draft contains the following acronyms:
227 DTLS: Datagram Transport Layer Security
229 EP: Endpoint
231 MC: Multicast
233 RD: Resource Directory
235 2. Use cases and architecture
237 To describe the application viewpoint of the solution, we introduce
238 some example scenarios for the various interactions shown in
239 Figure 1. The figure assigns the following roles taken up by a
240 regular node:
242 o Reading Node: any regular node that reads information from the
243 Sleepy Node.
245 o Configuring Node: any regular node that writes information/
246 configuration into Sleepy Node(s). Examples of configuration are
247 new thresholds for a sensor or a new value for the wake-up cycle
248 time.
250 o Discovering Node: any regular node that performs discovery of the
251 nodes in a network, including Sleepy Nodes.
253 o Destination Node: any regular node or node in a group that
254 receives a message that is generated by the Sleepy Node.
256 o Server Node: an optional server that the Sleepy Node knows about,
257 or is told about, which is used to fetch
258 information/configuration/firmware updates/etc.
260 o Discovery Server: an optional server that enables nodes to
261 discover all the devices in the network, including Sleepy Nodes,
262 and query their capabilities. For example, a Resource Directory
263 server as defined in [I-D.ietf-core-resource-directory] or a DNS-
264 SD server as defined in [RFC6763]. For the rest of this document
265 the discovery server is a Resource Directory. Specifically, the
266 functionalities of the Resource Directory related to the
267 architecture presented in this Internet-Draft are described in
268 more details in Section 4.
270 o Delegated resource is the copy at the Proxy of a resource present
271 in the Sleepy Node.
273 2.1. Node interactions and use cases
274 +------------+ +-------------+
275 | Discovery | <-DISCOVERY-| Discovering |
276 | server | | Node |
277 | (Optional) | +-------------+
278 +------------+ |
279 |
280 .--DISCOVERY--' +---------+
281 | | Reading |
282 | .---| Node |
283 v | +---------+
284 +---------+ +-----------+ |
285 | Sleepy |---REPORT(A)-->| |<--READ--' +-------------+
286 | Node |---READ------->| Proxy |<--WRITE---| Configuring |
287 | |---WRITE------>| | | Node |
288 +---------+ +-----------+ +-------------+
289 | | | +-------------+
290 | | '---REPORT(B)->| Destination |
291 | '-----DIRECT REPORT---------------------->| Node |
292 | +-------------+
293 | +-----------+
294 '------------READ--------------------------->| Server |
295 | Node |
296 +-----------+
298 Figure 1: Interaction model for Sleepy Nodes in IP-based networks
300 The interactions visualized in Figure 1 are discussed and motivated
301 with their use cases. The arrows in the figure indicate that the
302 initiative for an interaction is taken by the source of the arrow.
304 DISCOVERY Interaction: a Discovering Node discovers Sleepy Node(s)via
305 Proxy or Discovery Server; for example:
307 - A Discovering Node wants to discover given services related to a
308 group of deployed sensors by sending a multicast to /.well-known/
309 core. It gets responses for the sleeping sensors from the Proxy
310 nodes.
312 - During commissioning phase, a discovering node queries a
313 Discovery Server to find all the proxies providing a given
314 service.
316 REPORT Interaction: On request of a Destination Node or because of
317 configuration settings which have instructed the Node to do so, a
318 Node sends a sequence of event notifications to destination Node(s),
319 (A) directly or (B) via Proxy; for example:
321 - A battery-powered sensor sends a notification with "battery low"
322 event directly to a designated Destination Node (REPORT(A)).
324 - A battery-powered occupancy sensor detects an event "people
325 present", switches on the radio and multicasts an "ON" command to
326 a group of lights (REPORT(A)).
328 - A battery-powered temperature sensor reports periodically the
329 room temperature to a proxy Node (REPORT(A)). The proxy node
330 reports to all associated HVAC destination nodes when the
331 temperature change deviates from a predefined range (REPORT(B)).
333 WRITE Interaction: A node sends a request to a proxy to set a value.
335 o A Sleepy Node WRITES to the proxy; for example:
337 - A battery-powered sensor wants to extend the registration
338 lifetime of its delegated resource at the Proxy.
340 o A configuring Node WRITEs information to a Proxy; for example:
342 - A configuring Node changes the reporting frequency of a
343 deployed sensor by contacting the Proxy node to which the
344 sensor is registered.
346 - Sensor firmware is upgraded. A configuring Node pushes
347 firmware data blocks to the Proxy, which pushes the blocks to
348 the Sleepy Node.
350 - A configuring Node adds a new subscription to an operational
351 sensor via the Proxy. From that moment on, the new Node
352 receives also the sensor events and status updates from the
353 sensor.
355 READ Interaction: A node sends a read request to a node that returns
356 a value.
358 o Sleepy Node sends a read request to a server Node; for example:
360 - A sensor (periodically) updates internal data tables by
361 fetching it from a predetermined remote node.
363 - A sensor (periodically) checks for new firmware with a remote
364 node. If new firmware is found, the sensor switches to a non-
365 sleepy operation mode, and fetches the data.
367 o A Sleepy Node sends a read request to its proxy; for example:
369 - A sensor (periodically) checks with his Proxy availability of
370 configuration updates or changes of its delegated resources
371 (e.g. a sensor may detect in this way that a configuring Node
372 has changed its name or modified its reporting frequency).
374 o A reading Node sends a read request to a proxy; for example:
376 - A Node (e.g. in the backend) requests the status of a
377 deployed sensor, e.g. asking the sensor state and/or firmware
378 version and/or battery status and/or its error log. The Proxy
379 returns this information.
381 - A Node requests a Proxy when a Sleepy sensor was 'last
382 active' (i.e. identified as being awake) in the network.
384 2.2. Architecture
386 The architecture associated with the support of Sleepy Nodes is
387 illustrated in Figure 2. Three High level interfaces are shown.
389 direct synchronize delegate
390 | | |
391 +----+ | +--------+ | +-------+ | +----+
392 | EP |---|---| sleepy |---|---| proxy |---|---| EP |
393 +----+ | +--------+ | +-------+ | +----+
394 | | |
396 Figure 2: Architecture of Sleepy Node support
398 o Direct interface: it allows the Sleepy Node to communicate
399 directly to endpoints (i.e. for sending or reading information).
400 The operations performed via this interface are always initiated
401 by the Sleepy Node when its sleep period ends.
403 o Delegate interface: via this interface the Proxy exposes the
404 values of delegated resources to interested endpoints on behalf of
405 the Sleepy Node. The same interface is used by endpoints which
406 want to communicate with the Sleepy Node (e.g. for reading or
407 writing information).
409 o Synchronize interface: used by Sleepy Node and Proxy to
410 synchronize values of delegated resources. Through this interface
411 operations as discovery of the Proxy, registration, initialization
412 and update of resources at the Proxy are performed, along with a
413 de-registration operation to explicitly remove resources already
414 registered to the Proxy.
416 The interfaces consist of a set of functions which together realize
417 the interactions described in Section 2.1.
419 Endpoints and the proxy communicate with a Resource Directory (RD) to
420 discover resources of the Sleepy Node and delegated resources on the
421 proxy (not shown in the Figure 2).
423 2.3. Example contents
425 The examples presented in this specification make use of a smart
426 temperature sensor the resources of which are defined below using
427 Link Format [RFC6690]. Three resources are dedicated to the Device
428 Description (manufacturer, model, name) and one contains the current
429 temperature in degree Celsius.
431 ;rt="ipso.dev.mfg";if="core.rp",
432 ;rt="ipso.dev.mdl";if="core.rp",
433 ;rt="ipso.dev.n";if="core.p",
434 ;rt="ucum.Cel";if="core.s"
436 3. Design motivation
438 The Sleepy Node stack features a CoAP interface, to make the Sleepy
439 Node part of the IP-based network. Adding CoAP with a transport
440 protocol increases the possibilities to configure the Sleepy Node
441 within the network. The increased energy consumption coming from the
442 overhead of the CoAP and IP headers can be acceptable in many cases.
444 The proxy and Sleepy Node make use of the /.well-known/core resource
445 to handle discovery during network initialization. Using the
446 Resource Directory during operation of the Sleepy Node reduces its
447 participation in the discovery traffic.
449 A Sleepy Node delegates its resources to a proxy. The proxy
450 functionality extends the functionality of the RD, because the proxy
451 handles the value of the resource, and the RD does not. A proxy may
452 support multiple Sleepy Nodes. A Sleepy Node may also delegate its
453 resources to multiple proxies. A node can select a proxy that
454 handles the resource of the Sleepy Node of choice.
456 The complexity of the discovery and delegation interfaces is
457 minimized by reusing the RD interface as much as possible.
459 4. Interactions involving Resource Directory
461 It is assumed that the Proxy has a resource type rt="core.sp", where
462 sp stands for sleepy proxy.
464 In order to become fully operational in a network and to communicate
465 over the functional interfaces shown in Figure 2, a Sleepy Node and
466 the Proxy need to perform operations via the Registration interface
467 of the RD:
469 - Discovery of Proxy via RD. The Sleepy Node MAY discover the
470 Proxy by sending a request to the RD to return all EP with
471 rt=core.sp.
473 - Register existence of Proxy. When a RD is present and a Sleepy
474 Node has registered itself to a Proxy (see Section 5.2), the Proxy
475 MUST register the Sleepy Node at the RD and MUST keep this
476 registration up-to-date.
478 - Register delegated resources. When a RD is present, the Proxy
479 MUST register the delegated resources at the RD and keep them up-
480 to date.
482 A Configuring Endpoint (often part of a so-called Commissioning Tool)
483 registers the services that are reported directly by the Sleepy Node
484 in the resource directory, by registering the resource type and the
485 multicast address. The multicast address can be associated with a
486 group as described in [I-D.ietf-core-resource-directory].
488 A discovering Endpoint can discover one or more Sleepy Node resources
489 via the Resource Directory.
491 +-------------+ +-----------------+
492 | Configuring | | Discovering |---.
493 | Endpoint | | Endpoint | |
494 +-------------+ +-----------------+ |
495 | |
496 | +------------+ |
497 .-Register MC------>| |<--Discover resources -.
498 | Resource |
499 | Directory |<--Register Proxy -----.
500 .-Proxy Discovery-->| |<--Register resources -.
501 | +------------+ |
502 | |
503 +---------+ +-----------+ |
504 | Sleepy | | Proxy |---------'
505 | Node | | |
506 +---------+ +-----------+
508 Figure 3: Interactions involving Resource Directory
510 5. Synchronize interface
512 The functions of the synchronize interface implemented by the Proxy
513 are described in this section.
515 5.1. Sleepy Node discovers proxy
517 A Sleepy Node can discover the proxy in two ways:
519 - via the CoAP interface [RFC7390] by sending a multicast message
520 to discover an endpoint with rt=core.sp.
522 - via RD as already described in Section 4.
524 The following example shows a sleeping endpoint discovering a proxy
525 using this interface, thus learning that the base Proxy resource,
526 where the Sleepy Node resources are registered, is at /sp.
528 Sleepy Proxy
529 | |
530 | ----- GET /.well-known/core?rt=core.sp ------> |
531 | |
532 | |
533 | <---- 2.05 Content "; rt="core.sp" ------ |
534 | |
536 Req: GET coap://[ff02::1]/.well-known/core?rt=core.sp
537 Res: 2.05 Content
538 ;rt="core.sp"
540 The use of /sp is recommended and not compulsory.
542 5.2. Registration at a Proxy
544 Once a Sleepy Node has discovered a Proxy by means of one of the
545 procedures described in Section 5.1, the registration step can be
546 performed. To perform registration, a Sleepy Node sends to the Proxy
547 Node a CoAP POST request containing a description of the resources to
548 be delegated to the Proxy as the message payload in the CoRE Link
549 Format [RFC6690]. The description of the resource includes the
550 Sleepy Node identifier, its domain and the lifetime of the
551 registration.
553 Upon successful registration a Proxy creates a new delegated resource
554 or updates an existing delegated resource and returns its location.
555 The resources specified by the Sleepy Node during registration are
556 created with path that has as prefix the base Proxy resource path
557 (e.g. /sp). The registration interface MUST be implemented to be
558 idempotent, so that registering twice with the same endpoint
559 parameter does not create multiple delegated resources. The
560 delegated resource SHOULD implement the Interface Type CoRE Link List
561 defined in [I-D.ietf-core-interfaces]. A GET request on this
562 resource MUST return the list of delegated resources for the
563 corresponding Sleepy Node.
565 After successful registration, a Proxy SHOULD enable resource
566 discovery for the new resources by updating its "/.well-known/core"
567 resource. A Proxy MUST wait for the initial representation of a
568 resource before it can be visible during resource discovery. The top
569 level delegated resource MUST be published in "/.well-known/core" to
570 enable the discovery of the resources via RD as described in
571 Section 4. Resources of a delegated container SHOULD be discoverable
572 either directly in "/.well-known/core" or indirectly through gradual
573 reveal from the delegated resource. The Web Link of a delegated
574 resource MUST contain an "ep" attribute with the value of the End-
575 Point parameter received during registration.
577 A Proxy MAY be configured to register the Sleepy Node's resources in
578 a RD. In this case, a Sleepy Node MUST NOT register the resources in
579 a RD by itself since it is the responsibility of the Proxy to perform
580 the registration in the RD on behalf of the Sleepy Node. Since each
581 Sleepy Node may register resources with different lifetimes, a Proxy
582 MUST register the resources of a given Sleepy Node in a dedicated
583 path of the RD.
585 In case a Sleepy Node delegates its own resources to more than one
586 Proxy and each Proxy registers the Sleepy Node's resource in a RD,
587 the RD entries from the different Proxies for the same Sleepy Node
588 risk to overlap.
590 To avoid this problem, a Proxy MUST create its own resource path to
591 register the resources of a Sleepy Node on the RD.
593 The new path name is typically formed by concatenating the Proxy's
594 endpoint identifier with the path in use. This precaution ensures
595 that the ep identifier of a Sleepy Node is unique for each resource
596 path in the RD.
598 Implementation note: It is not recommended to reuse the value of the
599 ep parameter in the URI of the delegated resource. This parameter
600 may be a relatively long identifier to guarantee global uniqueness
601 (e.g. EUI64) and would generate inefficient URIs on the Proxy where
602 only a local handler is necessary.
604 The following example shows a Sleepy Node registering with a Proxy.
606 Sleepy Proxy
607 | |
608 | --- POST /sp?ep=0224e8fffe925dcf;rt=sensor " |
609 | |
610 | |
611 | <-- 2.01 Created Location: /sp/0 ----------------------- |
612 | |
614 Req: POST coap://sp.example.org/sp?ep=0224e8fffe925dcf;rt=sensor
615 Etag: 0x3f
616 Payload:
617 ;rt="ipso.dev.mfg";if="core.rp",
618 ;rt="ipso.dev.mdl";if="core.rp",
619 ;rt="ipso.dev.n";if="core.p",
620 ;rt="ucum.Cel";if="core.s"
622 Res: 2.01 Created
623 Location: /sp/0
625 The delegated resource has been created with path /sp/0 on the Proxy
626 in the example above. The path to the ep can be discovered as shown
627 below:
629 Req: GET coap://sp.example.org/.well-known/core
630 Res: 2.05 Content
631 ;rt="core.sp",
632 ;ep="0224e8fffe925dcf";rt="sensor"
634 A node can discover the delegated resources of the ep as shown below:
636 Req: GET coap://sp.example.org/sp/0
637 Res: 2.05 Content
638 Payload:
639 ;rt="ipso.dev.mfg";if="core.rp",
640 ;rt="ipso.dev.mdl";if="core.rp",
641 ;rt="ipso.dev.n";if="core.p",
642 ;rt="ucum.Cel";if="core.s"
644 Once the resources are registered in the Proxy, the Proxy registers
645 the delegated resources in the RD.
647 Proxy RD
648 | |
649 | --- POST /rd?ep=0224e8fffe925dcf " |
650 | |
651 | |
652 | <-- 2.01 Created Location: /rd/6534 ------------------- |
653 | |
655 Req: POST coap://rd.example.org/rd?ep=0224e8fffe925dcf
656 Etag: 0x6a
657 Payload:
658 ;rt="ipso.dev.mfg";if="core.rp",
659 ;rt="ipso.dev.mdl";if="core.rp",
660 ;rt="ipso.dev.n";if="core.p",
661 ;rt="ucum.Cel";if="core.s"
663 Res: 2.01 Created
664 Location: /rd/6534
666 5.3. De-registration at a Proxy
668 Sleepy Node resources in the Proxy are kept active for the period
669 indicated by the lifetime parameter. The Sleepy Node is responsible
670 for refreshing the delegated resource within this period using either
671 the registration or update function (see Section 5.5 of the
672 Synchronize interface). Once a delegated resource has expired, the
673 Proxy deletes all resources associated to that resource and updates
674 its "/.well-known/core" resource. When the Proxy resources are also
675 registered in a RD, the RD and delegated resources are supposed to
676 have the same lifetime. Consequently, when the delegated resource
677 expires, a Proxy MAY let the RD resource expire too instead of
678 explicitly deleting it. When the delegated resource is deleted by
679 means of explicit de-registration operation then also the RD resource
680 MUST be explicitly removed.
682 A Proxy could lose or delete the delegated resource associated to a
683 Sleepy Node without sending an explicit notification (e.g. after
684 reboot). A Sleepy Node SHOULD be able to detect this situation by
685 processing the response code while using the Sleepy Node Operation or
686 Update interface. Especially an error code "4.04 Not Found" SHOULD
687 cause the Sleepy Node to register again. A Sleepy Node MAY also
688 register with multiple proxies to alleviate the risk of interruption
689 of service.
691 5.4. Initialization of delegated resource
693 Once registration has been successfully performed, the Sleepy Node
694 must initialize the delegated resource. To send the initial contents
695 (e.g. values, device name, manufacturer name) of the delegated
696 resources to the Proxy, the Sleepy Node uses CoAP PUT repeatedly.
698 The basic interface is specified as follows:
700 Interaction: Sleepy -> Proxy
702 Method: PUT
704 URI Template: /{+location}{+resource}{?lt}
706 URI Template Variables:
708 location := This is the Location path returned by the Proxy as a
709 result of a successful registration.
711 resource := This is the relative path to a delegated resource
712 managed by the registered Sleepy Node.
714 lt := Lifetime (optional). The number of seconds by which the
715 lifetime of the whole delegated resource is extended. Range of
716 1-4294967295. If no lifetime is included, the current
717 remaining lifetime stays unchanged.
719 Request Content-Type: Defined at registration
721 Response Content-Type: Defined at registration for GET method.
722 application/link-format for PUT method if at least one of the
723 mutable resources has been updated since the last PUT request.
725 Etag: The Etag option MAY be included to allow clients to validate a
726 resource on multiple Proxies.
728 Success: 2.01 "Created", the request MUST include the initial
729 representation of the delegated resource.
731 Success: 2.04 "Changed", the request MUST include the new
732 representation of the delegated resource.
734 Success: 2.05 "Content", the response MUST include the current
735 representation of the delegated resource.
737 Failure: 4.00 "Bad Request". Malformed request.
739 Failure: 5.03 "Service Unavailable". Service could not perform the
740 operation.
742 The following example describes how a Sleepy Node can initialize the
743 resource containing its manufacturer name just after registration.
745 Sleepy Proxy
746 | |
747 | --- PUT /sp/0/dev/mfg "acme" ---------------> |
748 | |
749 | |
750 | <-- 2.01 Created ----------------------------- |
751 | |
753 Req: PUT /sp/0/dev/mfg
754 Payload: acme
755 Res: 2.01 Created
757 The example below shows how a Sleepy Node can indicate that it is
758 supposed to send a temperature value at least every hour to keep its
759 delegated resource active.
761 Sleepy Proxy
762 | |
763 | --- PUT /sp/0/sen/temp?lt=3600 "22" --------> |
764 | |
765 | |
766 | <-- 2.04 Changed ----------------------------- |
767 | |
769 Req: PUT /sp/0/sen/temp?lt=3600
770 Payload: 22
771 Res: 2.04 Changed
773 The use of repeated CoAP PUT can be avoided by writing all relevant
774 resources into the Proxy in one operation by means of the Batch
775 interface described in [I-D.ietf-core-interfaces]. After successful
776 initialization, a Proxy SHOULD enable resource discovery for the new
777 delegated resources by updating its /.well-known/core resource.
779 5.5. Sleepy Node updates delegated resource at Proxy
781 A Sleepy Node can update a delegated resource at the Proxy (REPORT A)
782 using standard CoAP PUT requests on the delegated resource as shown
783 in Section 5.4.
785 When a Sleepy Node sends a PUT request to update its resources, the
786 response MAY contain a link-format payload. The payload does not
787 directly relate to the target resource of the PUT request. Instead,
788 it is a list of web links to resources that have been modified by
789 clients since either the last PUT request or the last call to the
790 modification check interface (see Section 5.6).
792 5.6. Sleepy Node READs resource updates from Proxy
794 This function allows a Sleepy Node to retrieve a list of delegated
795 resources that have been modified at the Proxy by other nodes. The
796 interface format for GET is the same as the one specified for PUT in
797 Section 5.4.
799 A configuring Node (EP) can update a resource in the Proxy. The
800 Sleepy Node receives an indication of the changed resources as
801 specified in Section 5.5.
803 The Sleepy Node can send GET requests to its Proxy on each delegated
804 resource in order to receive their updated representation. The
805 example in Figure 4 shows a configuration node which changes the name
806 of a Sleepy Node at the Proxy. The Sleepy Node can then check and
807 read the modification in its resource.
809 Sleepy Proxy EP
810 | | <---PUT /sp/0/dev/n----|
811 | | Payload: Sensor1 |
812 Wake-up |---2.04 Changed-------->|
813 event | |
814 | | |
815 |--POST /sp/0/dev/.. -->| |
816 |<----2.04 Changed------| |
817 | Payload: | |
818 | | |
819 |---GET /sp/0/dev/n---->| |
820 |<-----2.05 Content-----| |
821 | Payload: Sensor1 | |
822 | | |
824 Figure 4: Example: A Sleepy Node READs resource updates from his
825 Proxy
827 6. Delegate Interface
829 This section details the functions belonging to the delegate
830 interface.
832 6.1. Discovering Endpoint discovers Sleepy Node at Proxy
834 Through this function, a Discovering Endpoint can discover one or
835 more Sleepy Node(s) at a Proxy. In case a Resource Directory is not
836 present, this is the only way to discover Sleepy Nodes. A CoAP
837 client discovers resources owned by the Sleepy Node but hosted on the
838 Proxy using typical mechanisms such as one or more GETs on the
839 resource /.well-known/core [RFC6690].
841 Resource discovery between an Endpoint and a proxy or an Endpoint and
842 a RD needs special care to take into account the fact that resources
843 from a Sleepy Node might appear duplicated. EPs SHOULD employ 2-step
844 resource discovery by looking up Sleepy Nodes AND resource types to
845 detect duplicate resources. EPs MAY use single-step resource
846 discovery only if the Sleepy Node can register with no more than one
847 Proxy. An EP can use the "ep" link attribute as a filter on the
848 "/.well-known/core" resource to retrieve a list of endpoints and
849 detect duplicate Sleepy Nodes registered on multiple proxies. An EP
850 can use the "ep" type of lookup to do the same on a RD. The result
851 of endpoint discovery is then used to filter out duplicate resources
852 returned from simple resource discovery.
854 The following example shows a client discovering the Sleepy Nodes and
855 learning that the Sleepy Node 0224e8fffe925dcf is registered on two
856 Proxies.
858 EP proxy1 proxy2
859 | | |
860 | ----- GET /.well-known/core?ep=* ------->|------>|
861 | | |
862 | | |
863 | <---- 2.05 Content "..." --------| |
864 | | |
865 | <---- 2.05 Content "..." --------|-------|
867 Req: GET coap://[ff02::1]/.well-known/core?ep=*
868 Res: 2.05 Content
869 ;ep="0224e8fffe925dcf"
870 Res: 2.05 Content
871 ;ep="02004cfffe4f4f50"
872 ;ep="0224e8fffe925dcf"
874 From the previous exchange and the next resource discovery request,
875 the EP can infer that the resources coap://sp1/sp/0/sen/temp and
876 coap://sp2/sp/1/sen/temp actually come from the same Sleepy Node with
877 ep=0224e8fffe925dcf.
879 EP proxy1 proxy2
880 | | |
881 | - GET /.well-known/core?rt=ipso:ucum.Cel ->|------>|
882 | | |
883 | | |
884 | <---- 2.05 Content "..." ----------| |
885 | | |
886 | <---- 2.05 Content "..." ----------|-------|
888 Req: GET coap://[ff02::1]/.well-known/core?rt=ucum.Cel
889 &ep=0224e8fffe925dcf
890 Res: 2.05 Content
891 ;rt="ucum.Cel"
895 6.2. Proxy REPORTs events to Endpoint
897 This interface can be used by the Endpoint to receive event report
898 message to Proxy (REPORT A) which further notifies it to interested
899 Destination Endpoint(s)(REPORT B). This indirect reporting is useful
900 for a scalable solution, e.g. there may be many interested
901 subscribers but the Sleepy Node itself can only support a limited
902 number of subscribers given its limits on battery energy. A client
903 interested in the events related with a specific resource may send a
904 CoAP GET to the Proxy, to obtain the last published state. If a
905 Reading node is interested in receiving updates whenever the Sleepy
906 Node reports new event to its Proxy, it can use observe
907 [I-D.ietf-core-observe] at the Proxy for that specific resource.
909 A proxy using the CoAP protocol [RFC7252] SHOULD accept to establish
910 a CoAP observation relationship between the delegated resource and a
911 client as defined in [I-D.ietf-core-observe].
913 A Sleepy Node may stop updating its delegated resources without
914 explicitly removing its delegated resource (e.g. transition to
915 another proxy after network unreachability detection). An Endpoint
916 can detect this situation when the corresponding delegated resource
917 has expired. Upon receipt of a response with error code 4.04 "Not
918 Found", an Endpoint SHOULD restart resource discovery to determine if
919 the resources are now delegated to another proxy.
921 The interface function is specified as follows:
923 Interaction: EP -> Proxy
925 Method: Defined at registration
926 URI Template: /{+location}{+resource}
928 URI Template Variables:
930 location := This is the Location path returned by the Proxy as a
931 result of a successful registration.
933 resource := This is the relative path to a delegated resource
934 managed by a Sleepy Node.
936 Content-Type: Defined at registration
938 In the example below an EP observes the changes of temperature
939 through the Proxy.
941 Sleepy Proxy EP
942 | | |
943 | | <- GET /sp/0/sen/temp - |
944 | | (observe) |
945 | | |
946 | | -- 2.05 Content "22" -> |
947 | | |
948 | - PUT /sp/0/sen/temp "23" -> | |
949 | | |
950 | <- 2.04 Changed ------------ | |
951 | | |
952 | | -- 2.05 Content "23" -> |
954 6.3. A Node WRITEs to Sleepy Node via Proxy
956 A Configuring Node uses CoAP PUT to write information (such as
957 configuration data) to the Proxy, where the information is destined
958 for a Sleepy Node. Upon change of a delegated resource, an internal
959 flag is set in the Proxy that the specific resource has changed.
960 Next time the Sleepy Node wakes up, the Sleepy Node checks the Proxy
961 for any modification of its delegated resources and reads those
962 changed resources using CoAP GET requests, as shown in Figure 4. The
963 allowed resources that a Configuring Node can write to, and the CoAP
964 Content-Format of those CoAP resources, is determined in the initial
965 registration phase.
967 The following example shows a commissioning tool (EP) changing the
968 name of a Sleepy Node through a Proxy. The Sleepy Node detects this
969 change right after updating its current temperature.
971 Sleepy Proxy EP
972 | | |
973 | | <-- PUT /sp/0/dev/n --- |
974 | | |
975 | | -- 2.04 Changed ------> |
976 | | |
977 | - PUT /sp/0/sen/temp ---> | |
978 | <- 2.04 Changed --------- | |
979 | Payload: --- | |
980 | | |
981 | - GET /sp/0/dev/n ------> | |
982 | | |
983 | <- 2.05 Content --------- | |
984 | | |
986 Req: PUT /sp/0/dev/n
987 Payload: "sensor-1"
988 Res: 2.04 Changed
990 Req: PUT /sp/0/sen/temp
991 Payload: "24"
992 Res: 2.04 Changed, Content-Type: application/link-format
993 Payload: ""
995 Req: GET /sp/0/dev/n
996 Res: 2.05 Content
997 Payload: "sensor-1"
999 6.4. A Node READs information from Sleepy Node via Proxy
1001 A Reading Node uses standard CoAP GET to read information of a Sleepy
1002 Node via a Proxy. However, not all information/resources from the
1003 Sleepy Node may be copied to the Proxy. In that case, the Reading
1004 Node cannot get direct access to resources that are not delegated to
1005 the Proxy. The strategy to follow in that case is to first WRITE to
1006 the Sleepy Node (via the Proxy, Section 6.3) a request for reporting
1007 this missing information; where the request can be fulfilled by the
1008 Sleepy Node the next time the Sleepy Node wakes up.
1010 7. Direct Interface
1012 This section details the functions belonging to the direct interface.
1014 7.1. Sleepy Node REPORTs events directly to Destination Node
1016 When the Sleepy Node needs to report an event to Destination nodes or
1017 groups of Destination nodes present in the subscribers list, it
1018 becomes Awake and then it can use standard CoAP POST unicast or
1019 multicast requests to report the event.
1021 TODO: MC example
1023 7.2. A Sleepy Node READs information from a Server Node
1025 A Sleepy Node while Awake uses standard CoAP GET to read any
1026 information from a Server Node. While the Sleepy Node awaits a CoAP
1027 response containing the requested information, it remains awake. To
1028 increase battery life of Sleepy Nodes, such an operation should not
1029 be performed frequently.
1031 8. Realization with PubSub broker
1033 The PubSub broker [I-D.koster-core-coap-pubsub] can be used to
1034 implement the REPORT function of the Sleepy Node proxy specified in
1035 this document. However, there are some differences to be taken into
1036 account:
1038 - The PubSub broker handles topics. In the case of the proxy the
1039 topics must be equated to resources.
1041 - Clients publish anonymously updates to a topic. In the case of
1042 the proxy, a delegated resource is bound to one given node that is
1043 allowed to update it. For the same functionality, the PubSub
1044 broker must restrict topic updates to one client only. The client
1045 linked to the topic must be visible to the clients which subscribe
1046 to the topic.
1048 In addition, some other functionality needs to be added to the PubSub
1049 broker to satisfy the interaction model shown in Figure 1:
1051 - the READ function from Sleepy Node to proxy is not covered by
1052 the PubSub broker. The PubSub broker needs to piggy-back a "check
1053 topic" on the confirmation of a publication by the proxy. The
1054 proxy can then perform a Read on the signalled topic.
1056 - The interaction "register resources" from proxy to Resource
1057 Directory, shown in Figure 3, is not part of the PubSub broker.
1059 9. IANA Considerations
1061 The new Resource Type (rt=) Link Target Attribute, 'core.sp' needs to
1062 be registered in the "Resource Type (rt=) Link Target Attribute
1063 Values" sub registry under the "Constrained RESTful Environments
1064 (CoRE) Parameters" registry.
1066 10. Security Considerations
1068 For the communication between Sleepy Node and Proxy it MAY be
1069 sufficient to use Layer 2 (MAC) security without the recommended use
1070 of DTLS. However, it must be ascertained that the Sleepy Node can
1071 communicate only with a given secured Proxy. A Sleepy Node may
1072 obtain the Layer 2 network key using the bootstrapping mechanism
1073 described in [I-D.kumar-6lo-selective-bootstrap]. DTLS MUST be used
1074 over link-layer security for further transport-layer protection of
1075 messages between Regular Nodes and Proxies in the network. There are
1076 no special adaptations needed of the DTLS handshake to support Sleepy
1077 Nodes. During the whole handshake, Sleepy Nodes are required to
1078 remain awake to avoid that, in case of small retransmission timers,
1079 the other node may think the handshake message was lost and starts
1080 retransmitting. In view of this, the only key point, therefore, is
1081 that DTLS handshakes are not performed frequently to save on battery
1082 power. Based on the DTLS authentication, also an authorization
1083 method could be implemented so that only authorized nodes can e.g.
1085 - Act as a Proxy for a Sleepy Node. (The Proxy shall be a trusted
1086 device given its important role of storing values of parameters
1087 for the delegated resources);
1089 - READ data from Sleepy Nodes;
1091 - WRITE data to Sleepy Nodes (via the Proxy);
1093 - Receive REPORTs from Sleepy Nodes (direct or via Proxy).
1095 11. Acknowledgements
1097 Much of the text and examples in this document are copied from
1098 [I-D.vial-core-mirror-server]. Matthieu Vial has generously
1099 authorized us to use his text. Rahman Akbar has pointed out the CoAP
1100 dependency of earlier versions.
1102 12. Changelog
1104 RFC editor, please delete this section before publication.
1106 From version 2 to version 3:
1108 Introduced interfaces and copied examples and text from mirror
1109 server draft.
1111 From version 3 to version 4:
1113 Comparison with PubSub Broker completed.
1115 Mistakes in examples removed.
1117 Less dependence on 6LowPAN networks.
1119 Added Design motivation section.
1121 13. References
1123 13.1. Normative References
1125 [I-D.ietf-core-observe]
1126 Hartke, K., "Observing Resources in CoAP", draft-ietf-
1127 core-observe-16 (work in progress), December 2014.
1129 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1130 Requirement Levels", BCP 14, RFC 2119,
1131 DOI 10.17487/RFC2119, March 1997,
1132 .
1134 [RFC5988] Nottingham, M., "Web Linking", RFC 5988,
1135 DOI 10.17487/RFC5988, October 2010,
1136 .
1138 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link
1139 Format", RFC 6690, DOI 10.17487/RFC6690, August 2012,
1140 .
1142 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
1143 Application Protocol (CoAP)", RFC 7252,
1144 DOI 10.17487/RFC7252, June 2014,
1145 .
1147 [RFC7390] Rahman, A., Ed. and E. Dijk, Ed., "Group Communication for
1148 the Constrained Application Protocol (CoAP)", RFC 7390,
1149 DOI 10.17487/RFC7390, October 2014,
1150 .
1152 13.2. Informative References
1154 [I-D.ietf-core-interfaces]
1155 Shelby, Z., Vial, M., and M. Koster, "CoRE Interfaces",
1156 draft-ietf-core-interfaces-03 (work in progress), July
1157 2015.
1159 [I-D.ietf-core-resource-directory]
1160 Shelby, Z., Koster, M., Bormann, C., and P. Stok, "CoRE
1161 Resource Directory", draft-ietf-core-resource-directory-04
1162 (work in progress), July 2015.
1164 [I-D.koster-core-coap-pubsub]
1165 Koster, M., Keranen, A., and J. Jimenez, "Publish-
1166 Subscribe Broker for the Constrained Application Protocol
1167 (CoAP)", draft-koster-core-coap-pubsub-02 (work in
1168 progress), July 2015.
1170 [I-D.kumar-6lo-selective-bootstrap]
1171 Kumar, S. and P. Stok, "Security Bootstrapping over IEEE
1172 802.15.4 in selective order", draft-kumar-6lo-selective-
1173 bootstrap-00 (work in progress), March 2015.
1175 [I-D.vial-core-mirror-server]
1176 Vial, M., "CoRE Mirror Server", draft-vial-core-mirror-
1177 server-01 (work in progress), April 2013.
1179 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service
1180 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,
1181 .
1183 Authors' Addresses
1185 Teresa Zotti
1186 Philips Research
1187 High Tech Campus 34
1188 Eindhoven 5656 AE
1189 The Netherlands
1191 Phone: +31 6 21175346
1192 Email: teresa.zotti@philips.com
1194 Peter van der Stok
1195 Consultant
1197 Phone: +31 492474673
1198 Email: consultancy@vanderstok.org
1200 Esko Dijk
1201 Philips Research
1202 High Tech Campus 34
1203 Eindhoven 5656 AE
1204 The Netherlands
1206 Phone: +31 6 55408986
1207 Email: esko.dijk@philips.com