idnits 2.17.1 draft-lindgren-icnrg-efficientiot-03.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 an Introduction 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 6, 2015) is 3217 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- No issues found here. Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ICN Research Group A. Lindgren 3 Internet-Draft F. Ben Abdesslem 4 Intended status: Experimental B. Ahlgren 5 Expires: January 7, 2016 SICS 6 O. Schelen 7 Lulea University of Technology 8 A. Malik 9 Ericsson 10 July 6, 2015 12 Applicability and Tradeoffs of Information-Centric Networking for 13 Efficient IoT 14 draft-lindgren-icnrg-efficientiot-03 16 Abstract 18 This document outlines the tradeoffs involved in utilizing 19 Information Centric Networking (ICN) for the Internet of Things (IoT) 20 scenarios. It describes the contexts and applications where the IoT 21 would benefit from ICN, and where a host-centric approach would be 22 better. The requirements imposed by the heterogeneous nature of IoT 23 networks are discussed (e.g., in terms of connectivity, power 24 availability, computational and storage capacity). Design choices 25 are then proposed for an IoT architecture to handle these 26 requirements, while providing efficiency and scalability. An 27 objective is to not require any IoT specific changes of the ICN 28 architecture per se, but we do indicate some potential modifications 29 of ICN that would improve efficiency and scalability for IoT and 30 other applications. 32 This document mainly serves as a problem statement and will not 33 present a conclusive architecture design. It can be used as a basis 34 for further discussion and to design architectures for the IoT. 36 Status of this Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at http://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on January 7, 2016. 53 Copyright Notice 55 Copyright (c) 2015 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (http://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 2. Advantages of using ICN for IoT . . . . . . . . . . . . . . . 5 72 2.1. Naming of Devices, Data and Services . . . . . . . . . . . 5 73 2.2. Distributed Caching . . . . . . . . . . . . . . . . . . . 5 74 2.3. Decoupling between Sender and Receiver . . . . . . . . . . 5 75 3. Design Challenges of IoT over ICN . . . . . . . . . . . . . . 6 76 3.1. Naming of Devices, Data and Services . . . . . . . . . . . 6 77 3.2. Efficiency of Distributed Caching . . . . . . . . . . . . 7 78 3.3. Decoupling between Sender and Receiver . . . . . . . . . . 8 79 4. Proposed Design Choices for IoT over ICN . . . . . . . . . . . 9 80 4.1. Relationship to existing Internet protocols . . . . . . . 9 81 4.2. Data naming, format and composition . . . . . . . . . . . 9 82 4.3. Immutable atomic data objects . . . . . . . . . . . . . . 10 83 4.4. Data naming in streams of immutable data objects . . . . . 11 84 4.5. The importance of time . . . . . . . . . . . . . . . . . . 12 85 4.6. Decoupling and roles of senders and receivers . . . . . . 13 86 4.7. Combination of PULL/PUSH model . . . . . . . . . . . . . . 14 87 4.8. Capability advertisements . . . . . . . . . . . . . . . . 15 88 4.9. Name-based routing vs name resolution + 1-step vs 89 2-step . . . . . . . . . . . . . . . . . . . . . . . . . . 16 90 4.10. What's naming and what's searching . . . . . . . . . . . . 16 91 4.11. Meta data, tagging/tracing of data . . . . . . . . . . . . 16 92 4.12. Handling actuators in the ICN model . . . . . . . . . . . 17 93 4.13. Role of constrained IoT devices as ICN nodes . . . . . . . 18 94 5. Security Considerations . . . . . . . . . . . . . . . . . . . 19 95 5.1. Retrieving trusted content from untrusted caches . . . . . 20 96 5.2. Enabling application-layer processing in untrusted 97 intermediaries . . . . . . . . . . . . . . . . . . . . . . 20 98 5.3. Energy efficiency of cryptographic mechanisms . . . . . . 20 99 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 102 1. Motivation 104 Information Centric Networking (ICN) has been shown to efficiently 105 meet current usage demands of computer networks, where users consume 106 content from the network instead of communicating with specific 107 hosts. The applications and usage of the Internet of Things (IoT) 108 often imply information centric usage patterns, where users or 109 devices consume IoT generated content from the network instead of 110 communicating with specific hosts or devices. 112 However, while the IoT shares many characteristics with typical 113 information centric applications, it differs because of the high 114 heterogeneity of connected devices (including sensors and actuators), 115 the very high rate of new information being generated, and the 116 heterogeneity in requirements from applications regarding information 117 retrieval and dynamic actuation. Because of these differences, using 118 an Information Centric Network to design an architecture of the IoT 119 is often, but not always, beneficial. Depending on the context, the 120 IoT architecture may benefit from using an ICN or a host-centric 121 network (HCN). In practice, the right approach is a complex tradeoff 122 that depends on the applications and usage of the IoT network. 124 This document describes some advantages and inconveniences of using 125 an ICN for the IoT architecture, and helps finding the right tradeoff 126 between using an ICN or an HCN, depending on the context. In this, 127 we explore how to represent and model IoT on top of existing ICN 128 solutions, without requiring IoT specific functionality in the ICN. 129 We discuss this in terms of effectiveness, efficiency and 130 scalability. However, in some cases we do invite for discussion on 131 tentative additions of functionality to ICN in order to make the 132 overall IoT solution more efficient and scalable. 134 2. Advantages of using ICN for IoT 136 A key concept of ICN is the ability to name data independently from 137 the current location at which it is stored, which simplifies caching 138 and enables decoupling of sender and receiver. Using ICN to design 139 an architecture for IoT data potentially provides such advantages 140 compared to using traditional host-centric networks. This section 141 highlights general benefits that ICN could provide to IoT networks. 143 2.1. Naming of Devices, Data and Services 145 The heterogeneity of both network equipment deployed and services 146 offered by IoT networks leads to a large variety of data, services 147 and devices. While using a traditional host-centric architecture, 148 only devices or their network interfaces are named at the network 149 level, leaving to the application layer the task to name data and 150 services. In many common applications of IoT networks, data and 151 services are the main goal, and specific communication between two 152 devices is secondary. The network distributes content and provides a 153 service, instead of establishing a communication link between two 154 devices. In this context, data content and services can be provided 155 by several devices, or group of devices, hence naming data and 156 services is often more important than naming the devices. 158 2.2. Distributed Caching 160 While caching mechanisms are already used by other types of overlay 161 networks, IoT networks can potentially benefit even more from caching 162 systems, because of their resource constraints. Wireless bandwidth 163 and power supply can be limited for multiple devices sharing a 164 communication channel, and for small mobile devices powered by 165 batteries. In this case, avoiding unnecessary transmissions with IoT 166 devices to retrieve and distribute IoT data to multiple places is 167 important, and storing such content in the network can save wireless 168 bandwidth and battery power. Moreover, as for other types of 169 networks, applications for IoT networks requiring shorter delays can 170 benefit from local caches to reduce delays between content request 171 and delivery. 173 2.3. Decoupling between Sender and Receiver 175 IoT devices may be mobile and face intermittent network connectivity. 176 When specific data is requested, such data can often be delivered by 177 ICN without any consistent direct connectivity between devices. 178 Apart from using structured caching systems as described previously, 179 information can also be spread by forwarding data opportunistically. 181 3. Design Challenges of IoT over ICN 183 As outlined in Section 2, there are potential benefits from using ICN 184 to implement IoT communication architectures. However, in order to 185 obtain a scalable and efficient architecture there are some aspects 186 of ICN that must be specifically considered in making the right 187 design choices for IoT. In fact, using an ICN may not be beneficial 188 in all desired sub-functions and scenarios. This section outlines 189 some of the ICN specific challenges that must be considered and 190 describes some of the trade offs that will be involved. We will 191 address these challenges in our proposed design choices later in 192 Section 4. 194 3.1. Naming of Devices, Data and Services 196 The ICN approach of named data and services (i.e., device independent 197 naming) is typically desirable when retrieving IoT data. However, 198 data centric naming may also pose challenges. 200 o Naming of devices: Naming devices is often important in an IoT 201 network. The presence of actuators requires clients to act 202 specifically on a device, e.g. to switch it on or off. Also, 203 managing and monitoring the devices for administration purposes 204 requires devices to have a specific name allowing to identify them 205 uniquely. There are multiple ways to achieve device naming, even 206 in systems that are data centric by nature. For example, in 207 systems that are addressable or searchable based on metadata or 208 sensor content, the device identifier can be included as a special 209 kind of metadata or sensor reading. 211 o Size of data/service name: In information centric applications, 212 the size of the data is typically larger than its name. For the 213 IoT, sensors and actuators are very common, and they can generate 214 or use data as small as a short integer containing a temperature 215 value, or a one-byte instruction to switch off an actuator. The 216 name of the content for each of these pieces of data has to 217 uniquely identify the content. For this reason, many existing 218 naming schemes have long names that are likely to be longer than 219 the actual data content for many types of IoT applications. 220 Furthermore, naming schemes that have self certifying properties 221 (e.g., by creating the name based on a hash of the content), 222 suffer from the problem that the object can only be requested when 223 the object has been created and the content is already known, thus 224 requiring some form of indexing service. While this is an 225 acceptable overhead for larger data objects, it is infeasible for 226 use when the object size is on the order of a few bytes. 228 o Hash-based content name: Hash algorithms are commonly used to name 229 content in order to verify that the content is the one requested. 230 This is only possible in contexts where the requested object is 231 already existing, and where there is a directory service to look 232 up names. This approach is suitable for systems with large data 233 objects where it is important to verify the content. 235 o Metadata-based content name: Relying on metadata allows to 236 generate a name for an object before it is created. However this 237 mechanism requires metadata matching semantics. 239 o Naming of services: Similarly to naming of devices or data, 240 services can be referred to with a unique identifier, provided by 241 a specific device or by someone assigned by a central authority as 242 the service provider. It can however also be a service provided 243 by anyone meeting some certain metadata conditions. Example of 244 services include content retrieval, that takes a content name/ 245 description as input and returns the value of that content, and 246 actuation, that takes an actuation command as input and possibly 247 returns a status code afterwards. 249 3.2. Efficiency of Distributed Caching 251 Distributed caching is a key opportunity with ICN. However, an IoT 252 framework must be carefully designed to reap the maximum benefits of 253 ICN caching. When content popularity is heterogeneous, some content 254 is often requested repeatedly. In that case, the network can benefit 255 from caching. Another case where caching would be beneficial is when 256 devices with low duty cycle are present in the network and when 257 access to the cloud infrastructure is limited. 259 However, using distributed caching mechanisms in the network is not 260 useful when each object is only requested at most once, as a cache 261 hit can only occur for the second request and later. It may also be 262 less useful to have caches distributed throughout ICN nodes in cases 263 when there are overlays of distributed repositories, e.g., a cloud or 264 a Content Distribution Network (CDN), from which all clients can 265 retrieve the data. Using ICN to retrieve data from such services is 266 beneficial, but in case of dense occurrence of overlay CDN servers 267 the additional benefit of caching in ICN nodes would be lower. 268 Another example is when the name of the data has a different meaning 269 depending on the context, or if the name refers to an object with 270 variable content/state. For example, when the last value for a 271 sensor reading is requested, the returned data should change every 272 time the sensor reading is updated. In that case, ICN caching may 273 increase the risk that cache inconsistencies result in old data being 274 returned. 276 3.3. Decoupling between Sender and Receiver 278 Decoupling the sender and receiver is useful mechanism offered by the 279 ICN approach, especially for content retrieval with duty cycling 280 devices or devices with intermittent connectivity. However, in order 281 to efficiently retrieve data it must be possible for requestors 282 (receivers) to easily deduce the name of the data to request, without 283 any direct contact with the responder (sender). 285 Nevertheless, de-coupling is a challenge when authentication is 286 needed for management and actuation, or when real-time interaction 287 between devices is necessary. Solutions for object security 288 supporting decoupled authentication (e.g., similar to signing by 289 proxy), and solutions for pushing data to decoupled entities must be 290 explored. 292 4. Proposed Design Choices for IoT over ICN 294 This section describes some fundamental design choices and trade-offs 295 to allow for effective, efficient and scalable handling of IoT data 296 in an ICN network. An objective with these choices is to facilitate 297 that an ICN network can be used without requiring additions of IoT 298 application specific functionality in the ICN network. However, in 299 some cases we do invite for discussion on tentative additions of 300 functionality to ICN in order to make the overall IoT solution more 301 efficient and scalable. 303 4.1. Relationship to existing Internet protocols 305 IoT devices can have a role as content generators (e.g., sensors) in 306 where an ICN paradigm should be effective for data retrieval and 307 dissemination. However, IoT devices may also have roles as actuators 308 in which such devices shall be accessed for control purposes. The 309 use of an ICN network may be less natural when actuation and control 310 of specific devices is the key objective. As ICN networks are likely 311 to coexist with existing Internet protocols in most situation, often 312 being deployed as overlay networks, we will consider that there may 313 be situations where a host centric addressing is more suitable for 314 IoT. Thus, to facilitate support of IoT for both data generation and 315 control/actuation, we assume that ICN routing should therefore work 316 in concert with existing Internet protocols. However, we will also 317 investigate the possibility of utilizing ICN network primitives for 318 actuation as well to see what the tradeoffs are, as can be seen in 319 Section 4.12. 321 4.2. Data naming, format and composition 323 The data served by ICN may be aggregated from smaller components. 324 Although IoT data components in many cases are small and simple, a 325 general challenge in defining ICN applications is to decide how to 326 compose (i.e. group) the data so that it can be effectively named and 327 requested. Requesting partial data inside a composition may become a 328 challenge. Indeed, if data is composed and sub components are 329 requested, which are not directly namable by the requestor, finding 330 such a subset will resemble a database query which may require 331 processing to resolve. The ICN network should not have to support 332 such complexity. 334 A design choice regarding IoT data is therefore to keep the ICN 335 network free from supporting any advanced queries and instead only 336 support directly addressable (i.e., named) data objects. Any 337 advanced composition (hierarchical, graph-based, hyperlink, etc.) of 338 IoT data, and related searching for sub-components, would be handled 339 in servers/endpoints instead of inside the ICN network. The issue of 340 IoT data structure and searching at that higher level is for further 341 study. For effective ICN interoperability, only the structure of the 342 atomically addressable data objects must be agreed and mapped to the 343 underlying ICN naming scheme. This is to avoid making new 344 requirements on the ICN and to make sure that the need for 345 computation is kept low in the ICN network, essentially limiting it 346 to deciding whether there is a cache hit or not. There are some 347 considerations following from this design choice. First, the size of 348 the directly addressable objects could be kept fairly small to avoid 349 that unwanted data is pulled over resource constrained networks and 350 cached in the ICN network (resulting in better resource utilization, 351 better localization of desired data, and ultimately better 352 scalability). There is however a tradeoff in that smaller data 353 objects results in a larger naming overhead. Second, this approach 354 means that a flat ICN address space would be sufficient, but for 355 practical reasons a hierarchical address space may add some benefits. 356 In any case, there is flexibility in using different addressing 357 schemes depending on what is supported by the existing ICN framework. 359 4.3. Immutable atomic data objects 361 The number of IoT devices as well as the amount of data produced by 362 these devices may potentially be very large, and the data may be 363 spread over very large ICN networks. The potential problem of cache 364 inconsistencies in an ICN network may therefore be large if we allow 365 for data to be mutable objects. To support scalability and 366 horizontal distribution it is essential to define data properties 367 that facilitate independency and consistency, while minimizing the 368 need for dynamic global synchronization. 370 A key design choice is therefore to mandate that IoT only uses 371 immutable atomic data objects. This supports large scale 372 distribution by ensuring that there is no stale data in the ICN 373 domain. A cache hit is always a clean hit. A trade-off from this is 374 that dynamic data must be modeled as a stream of immutable data 375 objects, potentially consuming more resources. However, this 376 challenge can be resolved by smart caching strategies where old data 377 is dropped. 379 There is however some practicalities to consider. Devices, including 380 IoT devices, are restarted now and then. They might in this process 381 loose their state, including what name they used for a particular 382 data value. So in practise it will be hard to implement a strong 383 assumption on immutable data. We therefore likely must be prepared 384 to handle the occasional exception to this rule. 386 4.4. Data naming in streams of immutable data objects 388 Many IoT devices produce new sensor readings or other data values at 389 regular intervals or on demand. With the design choice on immutable 390 atomic data objects, there is a need to model the resulting stream of 391 sensor readings with a stream of immutable data objects in the ICN 392 domain. The need in this situation is very similar, if not 393 identical, to video streaming, where video frames or chunks are 394 immutable data objects in a video stream. 396 A key advantage of modelling IoT data as a stream of immutable data 397 objects is that ICN caches will not contain any stale data w r t a 398 given name. However, since new data objects (with new names) 399 representing different versions of a sensor reading may be emitted 400 frequently, there must be a way to tell the different versions apart. 402 To support immutable streamed data efficiently, while adhering to the 403 expected naming schemes of ICN, we recommend that names of data 404 objects include a sequence number. When data can be named with 405 sequence number, any request may or may not include such a sequence 406 number. If no number is included in the request, the nearest cache 407 hit will result in a response. If a sequence number is included in 408 the request, only an exact cache match will result in a response. A 409 client that wants the "latest" reading can according to our 410 previously mentioned design choice, in Section 4.2, not ask the ICN 411 network such a high level query, instead it must ask for the specific 412 (version of) information. To avoid complicated searching in the ICN 413 nodes, there is thus no way to explicitly ask the network for the 414 "latest" reading, or any other "range" of sequence numbers. 416 Should a client want the latest reading from a sensor, one method for 417 this is to make a subscription for the pushed stream of data, as 418 described in Section 4.7, provided that the particular ICN 419 architecture supports this interaction model. The confirmation of 420 that subscription can contain the latest reading, and then obviously 421 the normal stream will be received. The reason for including the 422 latest reading in the response is to immediately provide the "state" 423 of sensors that generate new data infrequently. 425 Another method to obtain the latest reading, or a particular reading 426 in the past, from a sensor is to perform adaptive probing, for 427 example by binary interval reduction. If a requested sequence number 428 does not (yet) exist, there will be a negative answer from the ICN. 429 This method is preferably combined with application knowledge, for 430 example, in the form of capability advertisements as described in 431 Section 4.8 that enable the client to better predict the sequence 432 number to request. The client that always wants the latest value 433 could also dynamically tune its requests for the next data value to 434 the frequency of the publisher in order to minimise the latency. The 435 fact that non-existing data is asked for would however potentially 436 pose an overload threat to the ICN since each request of non-existing 437 data could result in cache misses that ripple through all the way to 438 the source, which has to respond that the data doesn't exist. It may 439 therefore be beneficial with negative caching. Serving requests for 440 non-existing data is however a generic challenge to ICN (not 441 specifically to IoT) to be resolved. 443 There is a third method "in between" the above two. If requests for 444 a not yet existing data object can be held for a short time until the 445 data object is actually available, instead of immediately returning 446 "not found", these requests act as one-time subscriptions. Provided 447 that request aggregation is being used, this mechanism would be 448 efficient and latency-minimising, and at the same time would not 449 require persistent subscription state. 451 The support for sequence numbers depends on the particular flavor of 452 ICN. The naming scheme of CCN/NDN may here provide an advantage. It 453 is for further study whether it is possible to use ICNs that do not 454 support sequence numbers as part of naming (e.g., by clever use of 455 metadata, namespace, and search functionality) and what the trade- 456 offs would be. 458 Two issues for further study are the size of the sequence number 459 space and gaps in the sequence numbers. Must sequence number 460 wraparound be handled, or is it possible to require a large enough 461 sequence number space? Wraparound means an exception to the 462 assumption on immutable objects. Gaps in the sequence number space 463 might result in inefficiencies in some of the above methods, or, if 464 the gaps are large, making them unfeasible. Yet, it might not always 465 be possible to guarantee that there are no gaps. 467 4.5. The importance of time 469 Time is almost always a very important property of IoT data, and 470 especially so for data that change over time. When modeling dynamic 471 IoT data with a stream of immutable data values, it is often the case 472 that a certain IoT data value is a sensor reading at a particular 473 point in time, and the next value in the stream is the next reading 474 in time. Thus, dynamic data is in this case dynamic over time, with 475 well defined (immutable) values for particular points in time. 477 We therefore argue that it is important to find a way to represent 478 these time-related streams of immutable data values in ICN. It 479 should be possible to request a data value from a certain time, and 480 to infer/find the name (sequence number) of the latest, most current, 481 data value. The question is whether or not the stream sequence 482 numbers are sufficient to support time. If not, the ICN system needs 483 to be extended with explicit support for time, something we want to 484 avoid. In general, the methods outlined in the previous section are 485 applicable for finding an IoT data value from a particular point in 486 time, including the latest. What is missing is the mapping between 487 sequence number and time. 489 One possibility could be to use sequence numbers that directly 490 correspond to time, for instance, the Unix (POSIX) time in form of 491 seconds since January 1st, 1970. This would however both limit the 492 time resolution to seconds, and also result in large gaps in the 493 sequence numbers, something that can be problematic, as discussed in 494 the previous section. 496 There are several other methods for finding readings from a certain 497 time, or the latest reading, for example through a high level request 498 from a server/endpoint, or by using a naming scheme where the name 499 can be directly inferred, e.g., if an IoT device has advertised under 500 which conditions it produces data and how it is named. 502 To represent absolute time so that it can be directly inferred, one 503 method is that the producer of data in its capability advertisements 504 (Section 4.8) provide a mapping function between sequence number and 505 time. Thereby also readings on the time axis are immutable while it 506 is still possible to efficiently find the latest reading, as 507 described in Section 4.4. It should be noted that sequence numbers 508 then may have gaps in order to cater for triggered non periodic data, 509 etc. Another method is to include meta data with information on 510 absolute time. Using this mapping scheme data from the current 511 second can be efficiently requested (provided that clock 512 synchronisation is accurate enough, which is out of scope of this 513 document). 515 We also note that time is also important for other applications, in 516 particular for live streaming video. Live video also produces a 517 time-related stream of immutable objects, and would in the same way 518 benefit from such support in the ICN service. 520 4.6. Decoupling and roles of senders and receivers 522 Since ICN networks essentially support a request/response model of 523 interaction, we denote the receivers of information as requestors, 524 and the senders of information as responders. The ICN network in 525 itself provides decoupling of requestors and responders. It is an 526 important feature of the ICN that it will allow responders (e.g., IoT 527 devices) to be occasionally unreachable (e.g., due to intermittent 528 connectivity, low battery level, duty cycling). Another advantage is 529 that caching in the ICN will ensure that data objects are normally 530 delivered only once from the IoT devices, independently of the number 531 of immediate requestors. 533 Note however, that the ICN does not (and should not) provide any 534 transformation or aggregation of data. The IoT dissemination 535 architecture should therefore allow for any number of intermediate 536 processing nodes. An intermediate node will be an endpoint in the 537 ICN network that can act as both requestor and responder. Such a 538 node may perform aggregation, filtering, selection, etc. The 539 instantiation of such nodes may for example form a directed (acyclic) 540 graph between ultimate responders (IoT devices) and ultimate 541 requestors (the final applications). It is for further study how to 542 define such an architecture. 544 It is a design choice to keep the IoT dissemination and aggregation 545 functionality outside of the ICN domain. That architecture would be 546 an overlay that may have intricate structure, and put the ICN usage 547 in a new context, where content from ultimate requestors to ultimate 548 responders may go through many IoT processing nodes that collect, 549 process and re-publish data through an ICN for various purposes. 551 4.7. Combination of PULL/PUSH model 553 A critical decision regarding IoT data is whether to use a PULL 554 model, a PUSH model, or both. In this document, we define a PULL 555 model as a system where data is only sent when explicitly requested, 556 while a PUSH model indicate that data transmission is initiated by 557 the source based on some trigger (either periodic, for each new 558 object, or based on some condition on the generated data). There are 559 some intrinsic trade offs between these models. The PULL model is 560 for example resource efficient when there is an abundant amount of 561 IoT information, potentially redundant from many devices, and the 562 clients only occasionally or partially are interested in the 563 information. The PUSH model is for example efficient when there is 564 real-time information and the clients are interested in all 565 information from specific devices all the time. 567 A design decision in the IoT domain is to support both PULL and PUSH. 568 The base model should be PULL, since this is the native mode of ICN, 569 meaning that requestors must always start by sending a request. If 570 the request is for some specific data, it can be resolved by 571 returning the data (if it exists). The pull model can be supported 572 efficiently and scalably by an ICN network. 574 A challenge with the pull model is that it may be inefficient for 575 retrieving new data that occur sporadically or based on specific 576 conditions. Our proposal for an IoT framework is therefore that 577 there must be support for efficiently retrieving such triggered 578 information, without having to poll for it through the ICN. Our 579 proposal is that a request can also include triggers, which means 580 that data will be returned (pushed) when triggers are fulfilled, 581 which may be immediately, or in the future at one or several 582 occasions. This can be used to select alarm conditions, to request 583 continuous or periodic push, etc. The trigger conditions could be 584 set by the requestor, or be pre-defined by the responder. The former 585 would be more flexible but also have performance/scalability issues 586 since the number of trigger conditions and consequent data generation 587 would depend on a potential large number of requestors. The latter 588 is more scalable since there will be a predefined and finite number 589 of trigger conditions (as defined in capability advertisements). Our 590 recommended choice, at least for the initial phase, is to go for a 591 simple and scalable solution and therefore adopt the model where 592 available trigger conditions are defined and advertised by the 593 responder. The ICN would be apt for supporting such capability 594 advertisements, given that they are fairly static. 596 With this, there is no requirement raised on ICNs supporting data 597 push, but we recommend to have a discussion on whether an ICN network 598 can or should provide an option to effectively support a push model 599 of data. Such support could make real-time IoT data dissemination 600 more efficient and scalable as previously mentioned in Section 4.3. 601 However, since we assume that the ICN works with existing IP 602 protocols, such functionality can be provided without ICN, by using 603 traditional unicast or multicast communication. We finally note that 604 an ICN supported push service model would make the ICN network more 605 like a publish/subscribe system. 607 4.8. Capability advertisements 609 Capability advertisements and discovery can be used by requestors to 610 discover which data is available and/or to which responders to 611 connect to. In a deployment with large numbers of responders, the 612 functionality of automatic advertisement and discovery becomes a 613 critical factor to support scaling. Responders should advertise 614 their methods (inputs, outputs, parameters, triggers, etc) and 615 provide relevant metadata in the responses as advertised. Such 616 capability advertisements should be conservative with resources, 617 which suggests that new advertisements should be posted with 618 reasonably low frequency. This implies that an ICN network can be 619 used for providing capability advertisements. The advertisements 620 should be provided as a stream of immutable objects, or alternatively 621 the IoT system should be tolerant to stale caches. Should there be a 622 need real-time awareness of dynamic changes, a subscription/push 623 model of capability advertisements could be used as earlier described 624 in Section 4.7. 626 4.9. Name-based routing vs name resolution + 1-step vs 2-step 628 As described in Section 4.2, the IoT framework should be defined so 629 that new functionality in the ICN is not needed. For data that is 630 frequently generated and regenerated, it makes sense to keep simple 631 structures and provide directly inferable naming/addressing of data 632 objects, so that requestors can directly address the data. For more 633 complex data, such as pre-processed, aggregated and structured data a 634 two-step resolution model is recommended. The IoT devices can 635 provide a higher level resolution based on for example queries and 636 searching, resulting in a number of concrete directly addressable ICN 637 objects. This is similar to what web servers do when they return 638 URLs that requestors can use, but in this case it is named content 639 that is returned. 641 Consequently, the IoT framework should have no requirement that the 642 ICN network itself should support 2-step addressing (although such 643 2-step methods may exist in some ICNs) 645 4.10. What's naming and what's searching 647 As described in Section 4.2, the IoT framework should be defined so 648 that no new functionality is required in the ICN for searching data 649 or subcomponents of data. The ICN network supports just naming of 650 atomic data objects, while any searching is provided by the IoT 651 framework, which in itself may be constituted by a highly distributed 652 set of nodes that provide processing, analysis and aggregation of IoT 653 data. 655 4.11. Meta data, tagging/tracing of data 657 IoT data may be tagged with metadata to tell where it originates 658 from. Tagging is made at the level above the ICN network and may for 659 example be a list of strings. It can be added/changed by the 660 originating node (or a node that assigns the originating ID), and 661 added/changed/deleted by any node that processes the data. The tag 662 can in some cases be used to trace data back to origins. In some 663 cases it makes no sense to request or transmit metadata. For 664 efficiency reasons the ICN network should have support for optional 665 delivery of metadata. This is to be conservative with scarce 666 resources, for example when a wireless node requests data which is 667 cached in the ICN network, it would be beneficial if the requestor 668 could tell that it is desirable to not receive any metadata. There 669 should be a discussion whether there should be just one, or more than 670 one, piece of optional information in ICN content to be future proof. 672 4.12. Handling actuators in the ICN model 674 If actuators should be controlled using the ICN communication model, 675 we need to map the functionality of the actuator to named data and/or 676 the requesting of named data. We see two main models with some 677 variants as described in the following paragraphs. 679 In the first model, the state of the actuator is represented by a 680 stream of immutable named data objects. The actuator periodically 681 requests its new state using the name of its designated state object. 682 There then has to be a producer of that state data that responds with 683 the current state. When the actuator receives the response, it sets 684 that new state, invoking its actuation function. Authentication of 685 the producer of the state is important, but as this corresponds 686 directly to publisher and data object authenticity that are 687 fundamental in the ICN model, there are no additional requirements 688 for the IoT domain. 690 A variant of this first model is that a requester first requests the 691 state of the actuator. The requester supplies additional information 692 with the request including the name of the new state data it will 693 produce. The actuator responds with its state, and then requests its 694 new state using the name that was supplied with the additional 695 information in the first request. This variant enables low latency 696 without high frequency polling. 698 In the second model, the actuator invokes its actuation function as a 699 side-effect of receiving a particular request. There are several 700 plausible variants. The new state could be encoded in the name of 701 the requested data in the request, or could be supplied as additional 702 information with the request. Regardless, the actuator acts on the 703 new state information as a side effect, and responds with data, 704 possibly its state, to the requester. The security issues are 705 potentially more difficult with this model, since in the ICN model, 706 anyone could make the request. Access control and/or requester 707 authentication are therefore required. 709 To reap the advantages of caching, it should be possible to cache the 710 state of the actuator in both the aforementioned models. However, we 711 think that caching is not as relevant for actuation as it is for 712 other IoT use cases, and can furthermore even be quite problematic. 713 The first model less so, since the actuator can make sure that its 714 state is arbitrarily fresh with the polling method described in 715 Section 4.4. In other words, the latency until actuation happens can 716 be bounded. The variant of the first model and the second model have 717 larger issues. With caching, it is hard for a requester to make sure 718 that its request actually reaches the actuator, and thus, it is hard 719 to bound the actuation latency. Some caching directive might be 720 needed in this case for reliable functionality. 722 4.13. Role of constrained IoT devices as ICN nodes 724 Typical ICN nodes such as routers and gateways are deemed to be rich 725 in resources like energy, processing, bandwidth and storage. IoT 726 devices, on the other hand, are quite constrained in such resources. 727 It is also worth noticing that some resources are more crucial than 728 others. In most cases energy, processing and bandwidth are quite 729 expensive for constrained IoT devices. In contrast, storage has 730 shown a considerably rapid decreasing trend in prices over the past 731 few years. There is reason to believe that the memory needed for IoT 732 devices to act as servers of their data will not be prohibitive and 733 that the data centric role of the devices may be elevated by 734 information-centric networks. 736 However, it is questionable whether IoT devices also should provide 737 caching for data produced by other IoT devices. In ad-hoc networks 738 this may be desirable, but often there is a desire for wireless nodes 739 to minimize communication by handling only data of their own concern. 740 Our design decision in this regard is that we logically separate IoT 741 server functionality (such as sensing and transmitting IoT data) and 742 ICN functionality (such as routing and caching data generated by 743 other devices). A resource constrained device may choose to only 744 implement IoT functionality and act as a server to the ICN, i.e., not 745 act as intermediate ICN node. However, since storage is getting 746 cheaper, IoT devices should be able to cache their own content and, 747 in essence, act as sources to ICN. 749 5. Security Considerations 751 The ICN paradigm is information-centric as opposed to state-of-the- 752 art host-centric internet. Besides aspects like naming, content 753 retrieval and caching this also has security implications. ICN 754 advocates the model of trust in content rather than trust in network 755 hosts. This brings in the concept of Object Security which is 756 contrary to session-based security mechanisms such as TLS/DTLS 757 prevalent in the current host-centric internet. 759 Object Security is based on the idea of securing information objects 760 unlike session-based security mechanisms which secure the 761 communication channel between a pair of nodes. This reinforces an 762 inherent characteristic of ICN networks i.e. to decouple senders and 763 receivers. In the context of IoT, the Object Security model has 764 several concrete advantages. As discussed earlier in Section 2.1, in 765 many IoT applications data and services are the main goal and 766 specific communication between two devices is secondary. Therefore 767 it makes more sense to secure IoT objects instead of securing the 768 session between communicating endpoints. 770 It is important that while security mechanisms complement the ICN 771 architecture in a coherent fashion, they do so without laying down 772 any strict requirements or constraints. Therefore, the decision of 773 what security mechanisms are employed should be handled at a layer 774 above ICN, in this case within the IoT framework. However, the ICN 775 layer should not be completely oblivious of Object Security. At this 776 point it is important to distinguish between the different aspects of 777 Object Security i.e. integrity, authenticity and confidentiality. 778 ICN provides data integrity through Name-Data Integrity i.e. the 779 guarantee that the given data corresponds to the name with which it 780 was addressed. Typical ICN protocols provide Name-Data integrity 781 using various schemes such as hash-based names and signatures. 782 Signature-based schemes additionally provide data authenticity. 783 Otherwise data authenticity should be provided in layers above the 784 ICN layer. Data confidentiality should also be handled above the ICN 785 layer. This facilitates flexibility and allows IoT applications more 786 freedom to decide which encryption scheme suits them best (session- 787 based encryption, object-based encryption or a hybrid). 789 Though the idea of Object Security is very much in line with the ICN 790 concept, there can still be some use cases where Object Security does 791 not add much e.g. a Pub/Sub interaction where a client is expected to 792 interact more or less with the same server node (a session-based 793 security protocol should suffice here) or use cases where application 794 layer headers should also be secured (which can be achieved by TLS/ 795 DTLS). We, therefore, effectively imply that there is no need to 796 modify typical ICN standards to accommodate Object Security in its 797 entirety. 799 The following sub-sections discuss some security advantages of using 800 ICN and Object Security in IoT applications. 802 5.1. Retrieving trusted content from untrusted caches 804 When functioning in an ICN network, an IoT client is expected to rely 805 on the network to deliver the requested content in an optimal fashion 806 without concerning itself with where the content actually lies. This 807 could potentially mean that each individual object within a stream of 808 immutable objects is retrieved from a different source. Having a 809 trust relationship with each of these different sources is not 810 realistic. This gives rise to the need of retrieving trusted content 811 from untrusted nodes/caches in an ICN network. Through Name-Data 812 Integrity, ICN automatically guarantees data integrity to the 813 requester regardless of the source from where it is delivered. 814 Additionally, Object-based signatures and encryption are ideal in 815 such use cases because it relieves an IoT client application from the 816 hassle of having to establish trust with each node that can 817 potentially cache an IoT object. This also means that a requesting 818 client can make use of more caches in the network, hence resulting in 819 better throughput and latency. 821 5.2. Enabling application-layer processing in untrusted intermediaries 823 Securing content at the object level provides greater granularity and 824 hence more control. An ICN data object may comprise of several 825 distinct application-layer objects e.g. XML, JSON objects. An 826 example of this is an ICN object that corresponds to all the sensor 827 readings in a certain time interval where each sensor reading is a 828 JSON object. Using Object-based encryption to provide data 829 confidentiality allows for the possibility to encrypt a subset of 830 these application-layer objects while leaving others unencrypted and 831 available for processing in untrusted intermediary nodes (e.g. 832 proxies and caches). With this approach, the IoT application has 833 more control of the parts of data it wants to make public and the 834 parts of data it wants to keep confidential and visible only to peers 835 with the right cryptographic keys. 837 5.3. Energy efficiency of cryptographic mechanisms 839 Session-based security protocols rely on the exchange of several 840 messages before a secure session is established between a pair of 841 nodes. Use of such protocols in constrained IoT devices can have 842 serious consequences in terms of power efficiency because in most 843 cases transmission and reception of messages is more costly than the 844 cryptographic operations. This is especially true for wireless 845 devices. 847 The problem is amplified proportionally with the number of nodes the 848 constrained device has to interact with because a secure session 849 would have to be established with every node. If the constrained 850 device is acting as a consumer of data this would mean setting up 851 secure sessions with every caching node that the device retrieves 852 data from. When acting as a producer of data the constrained device 853 would have to setup secure sessions with all the consumers. The 854 Object Security model eliminates this problem because the content is 855 readily available in a secure state in the network. IoT devices 856 producing data can secure it w.r.t. all the intended consumers and 857 start transmitting it right away. 859 6. Acknowledgements 861 The work behind and the writing of this document are in part 862 supported by the activity `14010 Efficient IoT Content' within EIT 863 Digital (formerly EIT ICT labs). 865 Authors' Addresses 867 Anders F. Lindgren 868 SICS Swedish ICT 869 Box 1263 870 Kista SE-164 29 871 SE 873 Phone: +46707177269 874 Email: andersl@sics.se 875 URI: http://www.sics.se/~andersl 877 Fehmi Ben Abdesslem 878 SICS Swedish ICT 879 Box 1263 880 Kista SE-164 29 881 SE 883 Phone: +46705470642 884 Email: fehmi@sics.se 885 URI: http://www.sics.se/~fehmi 887 Bengt Ahlgren 888 SICS Swedish ICT 889 Box 1263 890 Kista SE-164 29 891 SE 893 Phone: +46703141562 894 Email: bengta@sics.se 895 URI: http://www.sics.se/people/bengt-ahlgren 897 Olov Schelen 898 Lulea University of Technology 899 Lulea SE-971 87 900 SE 902 Phone: 903 Email: olov.schelen@ltu.se 904 URI: 906 Adeel Mohammad Malik 907 Ericsson 908 Kista SE-164 80 909 SE 911 Phone: +46725074492 912 Email: adeel.mohammad.malik@ericsson.com 913 URI: