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