idnits 2.17.1
draft-jimenez-t2trg-coap-functionality-lwm2m-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 :
----------------------------------------------------------------------------
** The document seems to lack a Security Considerations section.
** The document seems to lack an IANA Considerations section. (See Section
2.2 of https://www.ietf.org/id-info/checklist for how to handle the case
when there are no actions for IANA.)
** The abstract seems to contain references ([LWM2M], [IPSO]), which it
shouldn't. Please replace those with straight textual mentions of the
documents in question.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (October 31, 2016) is 2731 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
== Outdated reference: A later version (-46) exists of
draft-ietf-ace-oauth-authz-04
== Outdated reference: A later version (-11) exists of
draft-ietf-core-coap-tcp-tls-05
== Outdated reference: A later version (-04) exists of
draft-ietf-core-etch-03
== Outdated reference: A later version (-17) exists of
draft-ietf-core-http-mapping-16
== Outdated reference: A later version (-10) exists of
draft-ietf-core-links-json-06
== Outdated reference: A later version (-16) exists of
draft-ietf-core-object-security-00
== Outdated reference: A later version (-28) exists of
draft-ietf-core-resource-directory-08
== Outdated reference: A later version (-20) exists of
draft-ietf-core-yang-cbor-02
-- Obsolete informational reference (is this intentional?): RFC 7049
(Obsoleted by RFC 8949)
Summary: 3 errors (**), 0 flaws (~~), 9 warnings (==), 2 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Network Working Group J. Jimenez
3 Internet-Draft Ericsson
4 Intended status: Informational October 31, 2016
5 Expires: May 4, 2017
7 CoAP functionality expected in a LWM2M system
8 draft-jimenez-t2trg-coap-functionality-lwm2m-00
10 Abstract
12 This document provides a strawman summary of information that should
13 be used for the LWM2M specification [LWM2M]. LWM2M is based on CoAP,
14 on top of which it describes certain management interfaces and data
15 models that go beyond the CoAP specifications itself. However LWM2M
16 does not describe all behavior that should be expected from
17 implementations of the CoAP specifications. This document attempts
18 to clarify what should be present in a LWM2M system beyond what is
19 specified in the LWM2M documents. Additionally, this document also
20 adds information about IPSO Objects [IPSO] and their usage with LWM2M
21 as application protocol.
23 Status of This Memo
25 This Internet-Draft is submitted in full conformance with the
26 provisions of BCP 78 and BCP 79.
28 Internet-Drafts are working documents of the Internet Engineering
29 Task Force (IETF). Note that other groups may also distribute
30 working documents as Internet-Drafts. The list of current Internet-
31 Drafts is at http://datatracker.ietf.org/drafts/current/.
33 Internet-Drafts are draft documents valid for a maximum of six months
34 and may be updated, replaced, or obsoleted by other documents at any
35 time. It is inappropriate to use Internet-Drafts as reference
36 material or to cite them other than as "work in progress."
38 This Internet-Draft will expire on May 4, 2017.
40 Copyright Notice
42 Copyright (c) 2016 IETF Trust and the persons identified as the
43 document authors. All rights reserved.
45 This document is subject to BCP 78 and the IETF Trust's Legal
46 Provisions Relating to IETF Documents
47 (http://trustee.ietf.org/license-info) in effect on the date of
48 publication of this document. Please review these documents
49 carefully, as they describe your rights and restrictions with respect
50 to this document. Code Components extracted from this document must
51 include Simplified BSD License text as described in Section 4.e of
52 the Trust Legal Provisions and are provided without warranty as
53 described in the Simplified BSD License.
55 Table of Contents
57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
59 3. Interaction Model . . . . . . . . . . . . . . . . . . . . . . 3
60 3.1. Device and Manager configuration. . . . . . . . . . . . . 3
61 3.2. Device to Device configuration. . . . . . . . . . . . . . 4
62 3.3. Device to Application configuration. . . . . . . . . . . 4
63 4. Data Model . . . . . . . . . . . . . . . . . . . . . . . . . 5
64 5. Web Linking . . . . . . . . . . . . . . . . . . . . . . . . . 6
65 6. Collaboration . . . . . . . . . . . . . . . . . . . . . . . . 6
66 7. Informative References . . . . . . . . . . . . . . . . . . . 6
67 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8
69 1. Introduction
71 The current LWM2M protocol is probably the main Device Management
72 protocol based on CoAP today. It defines the application layer
73 communication protocol between a LWM2M Server and a LWM2M Client,
74 which is located in a LWM2M Device.
76 2. Terminology
78 The LWM2M Specification tends to use its own terminology for client,
79 server, etc. In this document, we use the existing terminology from
80 [RFC7252].
82 For example the use of LWM2M "Client" and "Server" and the roles they
83 play has confused developers that are initiating on the protocol,
84 mainly because a CoAP server runs on the device, just like a LWM2M
85 client does. Moreover, most LWM2M devices will often work both as
86 client and server depending on the interfaces used, it would be good
87 to explore the use of terms like "servients" for devices that
88 regularly support both.
90 Similarly, the reference to existing drafts of RFCs often can mislead
91 the reader to believe that the full RFC has been implemented. It
92 would be better to state the support to an IETF CoRE WG document when
93 applicable.
95 For example, the Registration interface in LWM2M is based on the CoAP
96 Resource Directory. However, it is not sufficient to implement just
97 the interface described to obtain the benefits provided by the CoAP
98 Resource Directory.
100 3. Interaction Model
102 LWM2M has been created with a strong focus on centralizing control
103 and management. Devices set associations with their manager and all
104 traffic is directed to the cloud. All this is fine but in the
105 process some functionalities that could be used locally device to
106 device and device to application have not been explicitly described.
108 Below we have common configurations that make use of LWM2M.
110 o (1) Device and Manager configuration.
112 o (2) Device to Device configuration.
114 o (3) Device to Application configuration.
116 Device +
117 +--------+--------+ | (1) +----------+--------------+
118 | | | | LWM2M | | LWM2M Server |
119 | LWM2M | IPSO | | <-------------> | Manager +--------------+
120 +--------+--------+ | | | BS Server |
121 | | | +----------+--------------+
122 | CoAP | | (2)
123 +--------+--------+ | CoAP+IPSO +----------+
124 | | | | <-------------> | Device |
125 | UDP | TCP | | +----------+
126 +-----------------+ | (3)
127 | IPv6 | | CoAP+IPSO +-------------------------+
128 | | | <-------------> | User / Application |
129 +-----------------+ | +-------------------------+
130 +
132 3.1. Device and Manager configuration.
134 This is covered by common LWM2M compliant implementations we have
135 today. However there are upcoming RFCs and drafts that greatly
136 enhance LWM2M with more CoAP features.
138 For example TCP support is soon going to be added to CoAP. The draft
139 [I-D.ietf-core-coap-tcp-tls] outlines the changes required to use
140 CoAP over TCP, TLS, and WebSockets transports.
142 Support for features like PATCH/FETCH [I-D.ietf-core-etch] could be
143 greatly beneficial for things like firmware upgrade or observing
144 relatively large sets of resources.
146 For systems in which endpoints work behind a gateway or use LWM2M for
147 managing the gateways, it might be good to implement other types of
148 cryptographic protection than DTLS. For example some of the setups
149 using OSCoAP [I-D.ietf-core-object-security] allow for "smarter"
150 gateways.
152 3.2. Device to Device configuration.
154 Beyond what is described in the LWM2M documentation, devices will
155 often talk to each other. Specially in cases when all devices are
156 under the same subnet, this could be pretty common. For example
157 devices could be more resilient if they did not have to contact their
158 manager constantly; in case of lack of internet connectivity the
159 local IoT network would still function. Managers could just set
160 policies on the devices and they would operate more autonomously.
162 For this setup to take place, LWM2M would use more of the device-to-
163 device functionality of CoAP. A more complete Resource Directory
164 implementation [I-D.ietf-core-resource-directory] would be needed,
165 either on the LWM2M server in addition to the registration interface
166 or standalone. Devices should be able to perform lookup on that RD
167 and get the series of links to resources elsewhere. They should be
168 able to find new functionality through /.well-known/core. If not,
169 they should be able to use IP multicast as expressed on [RFC7390].
171 Needless to say, it is assumed that devices would be running a CoAP
172 Server on them and would support CoAP Observe [RFC7641], so that
173 devices can subscribe to updates from one another, thus becoming more
174 autonomous.
176 There are also updates on ACE security framework, that allow for
177 securing the communication between two devices via an Authorization
178 Server [I-D.ietf-ace-oauth-authz].
180 The current LWM2M Data Model needs more expressiveness when it comes
181 to data types; More on that in Section 4. Also Web Linking will be
182 dealt at Section 5.
184 3.3. Device to Application configuration.
186 In some other cases applications would be running on the phone
187 connecting locally to sensors and/or control actuators. A smartphone
188 can access directly a CoAP home sensor using a mutually authenticated
189 'https' request, provided its home router runs a HTTP to CoAP (HC)
190 proxy and is configured with the appropriate certificate. For this
191 scenario to happen, the GW should implement a HC proxy. It is highly
192 recommended then that they make use of [I-D.ietf-core-http-mapping]
193 to properly do the URI mapping and specific ABNF queries.
195 Just like other devices, smartphone applications should be able to
196 discover devices using standard methods, thus they would need access
197 to the RD as well.
199 4. Data Model
201 The LWM2M Object Model is specified in [LWM2M]. Other models that
202 build on it like IPSOs or OneM2M have spawned out of it. They
203 normally introduce incremental features. They usually allow for
204 performing any set of operations on a device through a CoAP
205 interface. Resources are exposed as Objects using the same data
206 model used for management.
208 For example, in the case of a temperature sensor we can access and
209 subscribe to the readings of the device (using [IPSO]).
211 Req: GET /3303/0/5700 Observe_Option=1
212 Res: 2.05 Content (25 C)
213 Res (Notify): 2.05 Content (26 C)
215 There has also been much work on different serialization and
216 compression mechanisms that LWM2M could consider adopting. A
217 serialized JSON file like the one below could be greatly compressed
218 (about 46% max, depending on the case) using CBOR representation
219 format [RFC7049] instead.
221 { "e": [{
222 "bn": "/3303/0",
223 "e": [{
224 "n": "5700",
225 "v": 20.0 }, {
226 "n": "5701",
227 "v": "c" }, {
228 "n": "5603",
229 "v": 10 }, {
230 "n": "5604",
231 "v": 40
232 }], }, {
233 "bn": "/3302/0",
234 "e": [{
235 "n": "5500",
236 "v": true }, {
237 "n": "5501",
238 "v": 23
239 } ]}]}
241 LWM2M ResourceIDs at the moment have no specific semantic meaning
242 like ObjectIDs do. Adding a similar registry for ResourceIDs could
243 be useful. Specially to those using LWM2M for their applications.
244 For example IPSO uses such ResourceIDs to register resources
245 univocally, so that the string _5701_ consistently represents units.
247 5. Web Linking
249 One thing that that could be very useful in the future is some form
250 of Web Link resource type. ObjectLinks are not sufficient to
251 represent links between devices or applications. There has been much
252 work on web linking on [RFC6690] that could be used in the LWM2M
253 spec. For example a new Data Type named "Web Link" could be a
254 simple, yet useful addition. Instead of the current
255 _ObjectID:InstanceID_ expressed now, a full WebLink would be used.
256 That would take advantage of other features like
257 [I-D.ietf-core-links-json] or even newer Object Models.
259 Other use cases contemplate some form of Object Redirection to help
260 decouple management and applications. LWM2M expects that the
261 management servers will observe resources and collect telemetry on
262 the management server itself. If LWM2M is to be used as application
263 protocol as well as management, it should provide a way for
264 applications or CoAP Clients to observe resources on the devices,
265 together with their required credentials. Such credentials should be
266 stored on the device in some way, maybe a new Object.
268 6. Collaboration
270 To further develop the relationship between the LWM2M specification
271 and other specifications based on CoAP, it would also be advisable to
272 foster collaboration between organizations developing CoAP-based
273 standard implementations. At the moment there is no forum for inter
274 group communication nor discussion. That should change.
276 The IETF CoRE WG has quite some people also interested in device
277 management. Communication would be mutually beneficial. Example of
278 that work is on COMI [I-D.ietf-core-yang-cbor] or data model
279 translation.
281 OMA LWM2M already has benefited from workshops that gather most of
282 the industry, such as [IOTSI] and [IOTSU]. Similarly, specifications
283 can be developed in the IETF with a view to be directly usable in
284 LWM2M.
286 7. Informative References
288 [I-D.ietf-ace-oauth-authz]
289 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and
290 H. Tschofenig, "Authentication and Authorization for
291 Constrained Environments (ACE)", draft-ietf-ace-oauth-
292 authz-04 (work in progress), October 2016.
294 [I-D.ietf-core-coap-tcp-tls]
295 Bormann, C., Lemay, S., Tschofenig, H., Hartke, K.,
296 Silverajan, B., and B. Raymor, "CoAP (Constrained
297 Application Protocol) over TCP, TLS, and WebSockets",
298 draft-ietf-core-coap-tcp-tls-05 (work in progress),
299 October 2016.
301 [I-D.ietf-core-etch]
302 Stok, P., Bormann, C., and A. Sehgal, "Patch and Fetch
303 Methods for Constrained Application Protocol (CoAP)",
304 draft-ietf-core-etch-03 (work in progress), October 2016.
306 [I-D.ietf-core-http-mapping]
307 Castellani, A., Loreto, S., Rahman, A., Fossati, T., and
308 E. Dijk, "Guidelines for HTTP-to-CoAP Mapping
309 Implementations", draft-ietf-core-http-mapping-16 (work in
310 progress), October 2016.
312 [I-D.ietf-core-links-json]
313 Li, K., Rahman, A., and C. Bormann, "Representing CoRE
314 Formats in JSON and CBOR", draft-ietf-core-links-json-06
315 (work in progress), July 2016.
317 [I-D.ietf-core-object-security]
318 Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
319 "Object Security of CoAP (OSCOAP)", draft-ietf-core-
320 object-security-00 (work in progress), October 2016.
322 [I-D.ietf-core-resource-directory]
323 Shelby, Z., Koster, M., Bormann, C., and P. Stok, "CoRE
324 Resource Directory", draft-ietf-core-resource-directory-08
325 (work in progress), July 2016.
327 [I-D.ietf-core-yang-cbor]
328 Veillette, M., Pelov, A., Somaraju, A., Turner, R., and A.
329 Minaburo, "CBOR Encoding of Data Modeled with YANG",
330 draft-ietf-core-yang-cbor-02 (work in progress), July
331 2016.
333 [IOTSI] IAB, "IoT Workshop for Semantic Interoperability (IOTSI)",
334 2016, .
336 [IOTSU] IAB, "Internet of Things Software Update Workshop
337 (IoTSU)", 2016, .
340 [IPSO] IPSO, "IPSO Object Model", n.d.,
341 .
343 [LWM2M] OMA, "LWM2M specification", n.d.,
344 .
348 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link
349 Format", RFC 6690, DOI 10.17487/RFC6690, August 2012,
350 .
352 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object
353 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049,
354 October 2013, .
356 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
357 Application Protocol (CoAP)", RFC 7252, DOI 10.17487/
358 RFC7252, June 2014,
359 .
361 [RFC7390] Rahman, A., Ed. and E. Dijk, Ed., "Group Communication for
362 the Constrained Application Protocol (CoAP)", RFC 7390,
363 DOI 10.17487/RFC7390, October 2014,
364 .
366 [RFC7641] Hartke, K., "Observing Resources in the Constrained
367 Application Protocol (CoAP)", RFC 7641, DOI 10.17487/
368 RFC7641, September 2015,
369 .
371 Author's Address
373 Jaime Jimenez
374 Ericsson
376 Phone: +358-442-992-827
377 Email: jaime.jimenez@ericsson.com