idnits 2.17.1 draft-dinh-icn-sensor-scenarios-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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 9) being 59 lines 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 (June 30, 2014) is 3578 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 ICNRG N.T. Dinh 2 Internet Draft Y. Kim 3 Intended status: Standards Track Truong-xuan Do 4 Expires: Dec 30, 2014 Hyunsik Yang 5 Soongsil University 6 June 30, 2014 8 ICN Wireless Sensor and Actor Network BaseLine Scenarios 9 draft-dinh-icn-sensor-scenarios-03 11 Abstract 13 This document presents scenarios for information centric wireless 14 sensor and actor networks. The scenarios selected for inclusion in 15 this first draft aim to exercise a variety of aspects in wireless 16 sensor and actor network that an ICN solution could address. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six 29 months and may be updated, replaced, or obsoleted by other documents 30 at any time. It is inappropriate to use Internet-Drafts as 31 reference material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html 39 This Internet-Draft will expire on Dec 30, 2014. 41 Copyright Notice 43 Copyright (c) 2013 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with 51 respect to this document. Code Components extracted from this 52 document must include Simplified BSD License text as described in 53 Section 4.e of the Trust Legal Provisions and are provided without 54 warranty as described in the Simplified BSD License. 56 Redistribution and use in source and binary forms, with or without 57 modification, is permitted pursuant to, and subject to the license 58 terms contained in, the Simplified BSD License set forth in Section 59 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents 60 (http://trustee.ietf.org/license-info). 62 Table of Contents 64 1. Introduction...................................................2 65 2. Problem Statement..............................................3 66 3. Naming Scheme..................................................3 67 4. In-network Auto-configuration..................................6 68 5. Distributed Information Sharing Model..........................7 69 6. Distributed Network-level Information Filter...................7 70 7. Information centric routing and Aggregation....................7 71 8. Semantic Coordination and Collaboration........................8 72 9. In-network Caching.............................................9 73 10. Security Considerations......................................10 74 11. IANA Considerations..........................................10 75 12. Acknowledgements.............................................10 76 13. References...................................................10 77 13.1. Normative References.......................................10 78 13.2.Informative References......................................10 80 1. Introduction 82 Wireless sensor and actor networks (WSANs) consist of resource- 83 constrained nodes which operate in low power and lossy network 84 environment. Therefore, resource optimization is a very important 85 factor in design of WSANs' operations. Current TCP/IP model does not 86 fit well in this environment, so a need of 6LoWPAN is highlighted in 87 [RFC4919]. This draft exploits ICN approach in WSANs (ICWSANs) and 88 illustrates the obtained benefits. 90 For example, Dinh and Kim [ICWSAN] consider a functional oriented 91 naming scheme for information objects (IO)/entities and illustrate 92 the ICN benefits through scenarios in this category, including an 93 in-network auto-configuration, a distributed virtual information 94 sharing model, a content-based distributed information filter, a 95 content-based routing and data aggregation, and a semantic 96 cooperative distributed approach for WSANs. 98 2. Problem Statement 100 The usage models in WSANs are mostly information-based. The 101 information consumers exploited the network in information centric 102 way. Particularly, they are only interested in the fact that they 103 can get what they want. In contrast, the current IP approach is 104 address-centric, indicating where information has to be taken. 105 Moreover, the IP model requires an end-to-end connection between 106 source and destination, which may be not available all the time in 107 WSAN. Therefore, there are inconsistency between the information 108 usage model and the IP addressing style. 110 In IP paradigm, the network forwards bits equally and 111 indistinguishably. In the other hand, the bits should be exactly 112 flow from a source to a destination which is normally occurs in real 113 time. However, in WSAN, the network connectivity may be not always 114 available for end-to-end communication. Moreover, sensors may sleep 115 to reduce the energy consumption. The energy consumption is a 116 critical issue in WSAN where data aggregation is a good method to 117 reduce number of transmission, thus saving energy. Data aggregation 118 may require a deeper packet inspection, directly contradicting the 119 current model where the bits are indistinguishable. It remains a 120 challenge to recognize the information in the network layer in order 121 to achieve a better network performance. Therefore, information 122 centric network approach is potentially fit into the WSANs. 124 3. Naming Scheme 126 The naming scheme is a very important part. In comparison to the 127 Internet, a WSAN node produces and needs a few types of information. 128 For example, a temperature sensor may produce only temperature 129 sensing data or notifications about an over-threshold temperature 130 event. Types of information have a closely relationship with their 131 producers' functions (e.g. temperature data or temperature event in 132 a relationship with the temperature sensor). In this way, naming 133 schemes applied for each piece of information in Internet-ICN 134 approach [CCN] and other ICN proposals are not efficient in WSANs. 136 The basic idea of ICN is to change focus from network hosts to the 137 information objects (IOs) themselves while ICWSANs move focus from 138 separately device IDs to the composed denotation between the 139 information objects (IOs) and smart objects (e.g. sensors). The 140 reason is that there is a closed relationship between the produced 141 information objects and the functionality of the producers. For 142 example, the temperature sensor should produce the temperature 143 sensing data. Smart objects are categorized based on its 144 functionality (e.g. temperature sensor, humidity sensor, light 145 sensor). These category names are used to represent the type of 146 sensors and the type of sensing data produced by the corresponding 147 types of sensor. The category prefix is created by selecting brief 148 representative symbols for each category name (e.g. temperature may 149 be presented in a reduced form as "temp"). The brief form of the 150 category prefix helps reduce the packet overhead. The category 151 prefix is used to name smart objects and information objects 152 produced by them. Each smart object's name or information objects' 153 name will start with a corresponding category prefix name. The 154 sensor data are transformed into IOs with the name corresponding to 155 their producers' name. By this way, the smart object type and the 156 information object type could be recognized by the network, thus 157 easier for discovery and interaction. Based on the information based 158 name, IOs could be recognized and reused for multiple requests from 159 multiple consumers without a must to reach to the producers. The IOs 160 could be retrieved from any content holder or cache. This thus 161 reflects a separation in time between source and destination which 162 promises an efficient approach to improve the network serving 163 performance of the sleep/wake-up model for energy saving in WSAN 164 (i.e. while a sensor sleeps, its sensing data could be retrieved 165 elsewhere closer the consumer). 167 Particularly, a functional-oriented naming scheme is proposed in 168 ICWSANs. A name in ICWSANs includes an information category prefix 169 and information ID. The first part expresses a real-world functional 170 category name of a type of sensor or actor. The naming scheme is 171 proposed for both information naming and node's naming, which are 172 associated in the relationship with node's function. For example, a 173 temperature sensor could be named as tempSen:xxx and its temperature 174 information could be named as temp:xxx, or a temperature sink node 175 could also be named as tempSink:xxx ("temp" is a category prefix for 176 multiple types of sensor, actor, and sink nodes which are related to 177 the temperature category). By this way, the scalability issue of the 178 naming scheme in ICWSANs may not be as critical as other Internet's 179 ICN proposals. In the other hand, by exploiting the functional 180 category-certifying, ICWSANs could improve the network performance 181 and reduce communication overhead in WSANs, especially in group 182 communication. The sensing data is transformed into an IO with the 183 name corresponding to its producer and stored in the producer or 184 published to other information holders. 186 In the sensing data query model, consumers are normally not 187 interested an individual sensing data, but the sensing data in a 188 location. Thus, the smart objects could not separate from their 189 location. In other words, the value of IOs depends on their location. 190 Therefore, spatial information is also a key element of the IOs/SOs. 191 An example of ID generation related to the spatial information is 192 given below. The location mentioned here does not mean the IP 193 address, but the area of interest (AoI). Consumers may not be 194 interested in all IOs or SOs in an AoI, but Entities of Interest 195 (EoI) or Information Object of Interest (IoI) in an AoI. The design 196 of ICWSAN is to support consumers to express their interests on 197 EoI/IoI on an AoI and an efficient approach for serving such 198 interests. 200 In ICWSAN, the latter part of the name expresses the detail 201 information (e.g. ID, security code) which makes the name persistent 202 and unique. An example of ID generation based on the object's 203 ranking is given. The rank of a node in ICWSANs expresses the 204 position relative to other nodes. Nodes form a ranked tree topology 205 which is similar to the multibit-trie [MULTIBIT-TRIE] using in the 206 router table indexing. The purpose of the ranking-based ID is to 207 make routing become easier and more efficient by minimizing the 208 communication for route discovery. The object function (OF) is used 209 to generate the ranking of a node follow a rule as presented below. 211 Ranking of ith child node = ranking parent + i/15*'0' + HEX [I (mod) 212 15]. 214 Maximum number of children max_child for a node means that each node 215 could receive maximum max_child nodes. Each node allocates and 216 manages the ordered slots for children nodes. A node allocates an 217 ordered slot for only one child node at a time. The child node keeps 218 its ordered slot if there is no change in the network. Because the 219 parent ID is assumed to be unique and each child node receives a 220 unique ordered slot, thus the generated ID is also unique. The ID 221 generation is executed from the sink downward to children nodes. The 222 sink node initiates a unique ID automatically or is assigned by some 223 mechanism to guarantee that its ID is unique among sink nodes in the 224 network. It configures the rank as its ID to set up the full name 225 for the sink node. The sink node becomes a ranked node. When a node 226 turns on, it sends a ranking request (RRQ) message to its one hop 227 neighbors. As far as the network startups, each node, when turns on 228 the first time without sensing any ranked neighbor, puts itself in 229 listening mode for a random backoff periods and then request again. 230 On the contrary, ranked neighbor nodes check if they have any 231 available slot for a child node (its children number is smaller than 232 max_child), it then returns a ranking reply (RRP) message contain 233 its full name and allocate a valid ordered slot number (no child 234 node takes this number) to the requester. The requester may receive 235 multiple RRP from different ranked nodes. It then selects a node 236 with the shortest ID-length to be its parent. If several nodes have 237 the same shortest ID-length value, it selects the nearest node to be 238 its parent. The requester then runs OF with two parameters (parent 239 ID, ordered slot) to generate the rank. The requester then sets its 240 ID with the calculated rank and becomes a ranked node. After a 241 waiting time, it then sends a neighbour advertisement(NA) message to 242 its one hop neighbors containing its information and parent ID. When 243 the parent node receives the NA message, it stores the child full 244 name with the corresponding ordered slot for management. Other 245 neighbours update its neighbour table with the new ranked neighbour 246 node with upstream or downstream category. The process is executed 247 continuously until all nodes are ranked and participate to the 248 ranked tree network. 250 The value of IOs also has the temporal constraint which limits the 251 value of IOs in a period of time. This is a specific characteristic 252 of IOs, not SOs. In ICN, metadata is included to denote such 253 information. The ICN metadata may denote the ownership, various 254 timestamps, and usage or access policy constraints. These types of 255 information should be tied to IOs instead of nodes as in the 256 traditional host centric network. Therefore, the IOs could be 257 replicated reuse for multiple applications, thus saving a number of 258 requests to sensor nodes. An efficient storing method for metadata 259 is still an opened research topic. In WSANs, a wide range of 260 alternative security levels (fully public, confidentiality by 261 private name resolution system, or cryptographic) could be accepted 262 depending on specific applications. A simple method is required for 263 constrained nodes. 265 Multiple potentialities of ICWSAN are discussed below. 267 4. In-network Auto-configuration 269 In low power and lossy environment as WSANs, the WSAN system 270 dynamically adapts to change in network topology due to node 271 failures, environmental condition change, and new deployed nodes. 272 Therefore, auto-configuration design is important for such a large 273 scale network with limited resource nodes. Furthermore, the 274 connectivity from a node to the sink node could not guarantee all 275 the time because of sleep/wakeup intermediate node and low link 276 quality. In ICWSAN, an in-network auto-configuration is proposed to 277 reduce the configuration overhead. In particularly, when a new node 278 is deployed, configuration information could be retrieved from the 279 previously deployed nodes (with cached configuration information) 280 without a need to send a configuration information request to sink 281 node, or manually by user (e.g. a new temperature deployed node may 282 retrieve configuration information from the nearest temperature node 283 which is deployed previously). The new node then processes the 284 configuration information for all the information needed to fully 285 join to the existing network and start its operation. The in-network 286 auto-configuration requires only one alive neighbour node is enough 287 to execute auto-configuration for the newly deployed node while 288 optimizing number of forwarding requests to minimize the 289 configuration overhead by sharing information. 291 5. Distributed Information Sharing Model 293 The information sharing model also could execute in a distributed 294 virtual way; particularly, in a heterogeneous WSANs with multiple 295 types of sensors and actors, multiple separately virtual groups 296 could be created semantically to support inter-operate among nodes 297 without a requirement of a complex group's member addresses 298 management or centralized control(e.g. temperature sensors with the 299 same name prefix "temp" in an area could form a virtual group while 300 fired actors with the name prefix "fire-xxx" also form as another 301 group). The sharing rules could be determined based on the category 302 prefix of the information. The distributed virtual model is very 303 useful in case of configuration, data collection, and inter- 304 operation; for example, an interest request could be sent to collect 305 only temperature sensing information (only ) or a configuration 306 message is sent to only humidity sensors (only humidity sensors 307 should process this message). 309 6. Distributed Network-level Information Filter 311 An information-based distributed information filter approach is 312 proposed to support the distributed sharing model where a node 313 receives and processes an IO only if it is interested in this 314 information; if not, it could forward or simply discard messages, 315 even broadcast messages. ICWSAN could enable this technique because 316 the network layer could understand what information is carried, what 317 that means and distributes the information to nodes that need this 318 information. The network level could support fault-tolerance. 319 Uninterested information objects are discarded from the network 320 layer where disallows the communication/processing, hence the error 321 is never propagated to application level. In contrast, TCP/IP 322 network layer delivers all the indistinguishable packets equally. 323 Therefore, the information-based distributed filer is desired to 324 reduce failure in resource-constrained nodes like sensors. 326 7. Information-centric routing and Aggregation 328 Routing in WSANs is tightly coupled to the requirement of sensing 329 task as well as application. ICWSAN designs a content-based routing 330 which is closer to the application semantics to optimize the data 331 transport and information aggregation. The content becomes 332 transparently from the view point of clients, service discovery and 333 routing, thus reduce overhead in HTTP-CoAP translation process at 334 proxy node. In ICWSAN, the information can be recognized in the 335 network layer which is valuable to implement a content-based 336 prioritized routing policy to meet different requirements of 337 information dissemination (e.g. an emergency event type or a 338 periodic sensing report). Same type (ST) nodes could be organized in 339 a ST tree to serve the requests. ICWSAN strongly supports anycast 340 and multicast requests/commands to a specific EoI in an AoI. 342 The data aggregation could be executed along the ST trees. Sensing 343 data from children nodes are aggregated together to reduce redundant 344 or summary. A large number of transmission could be reduced, thus 345 save energy. For upstream direction, the content based aggregation 346 helps improve the quality of information while minimizing the 347 communication (e.g. temperature data could be recognized and 348 aggregated together before sending to a temperature sink node or an 349 actor node). In general, data aggregation in WSANs is to reduce 350 redundancy (e.g. summarize data), which has been widely studied. 351 However, data aggregation in heterogeneous WSANs is a challenge in 352 traditional approaches, which has not or little studied in the 353 literature. There are many types of information are generated and 354 transmitted from different types of sensors and actors. Different 355 types of information may not allow aggregating together and they 356 could be forwarded to different receivers. Mixed aggregation may 357 results in errors (e.g. temperature data is summarized with a 358 humidity data) because the node could not know the content inside 359 the packets until it is forwarded to the application layer. By 360 enabling information at the network layer through the naming scheme, 361 IOs in heterogeneous ICWSANs could be classified and aggregated in 362 data flows or at any nodes. By reducing a large number of IOs 363 forwarded to the sink node, it thus reduces congested links around 364 the sink node. 366 8. Semantic Coordination and Collaboration 368 One of the main ideas of ICWSAN is to base sensors/actors 369 collaboration decision on content which is to build cooperative 370 distributed WSAN environments where autonomous objects (including 371 information objects and network entities) can be discovered, 372 queried, coordinated automatically without a need of a central 373 control. ICWSAN implements a high-level abstraction for integration 374 of sensor networks with actors (e.g. mobile robots, vehicles). 375 Sensors could execute cooperative sensing, processing, and 376 organizing themselves to produce and retrieve the information 377 required by sink/actor node while minimizing the number of 378 transmitted messages. For example, in a heterogeneous wireless 379 sensor and actor network environment with multiple types of sensor, 380 actor and sink nodes existing in the same space, a temperature 381 sensor could self-coordinates to report its sensing data to a 382 temperature sink node (not another type of sink node) without a need 383 of sink node discovery; or a fire fighter (e.g. actors or robots) 384 could express its interest with a key word "temp-xxx" to collect 385 temperature data from any or all temperature in a fired area without 386 caring specific address of each node; the actors could also self- 387 coordinate and collaborate together to extinguish fires. In 388 addition, cooperative caching ensures sharing sensing information 389 among nodes to not only reduce number of communications but also 390 support indirect query in case of sleeping node; for instant, when a 391 node wakes up, it could retrieve configuration/notification message 392 cached in neighbour nodes; in other hand, a node also could 393 disseminate its sensing information to be cached in its neighbours 394 and fall to a sleep mode; a request for the sensing data from this 395 node could be retrieved indirectly from a cache holder or 396 asynchronously by interest message caching. 398 9. In-network caching 400 One of the main benefits from the ICN concept is the support of 401 in-network caching. The in-network caching feature can improve the 402 performance of the dissemination of information generated by sensor 403 nodes. The sensing data from a source node can be cached along 404 the intermediate sensor nodes that will improve bandwidth of whole 405 network. For example, according to industrial routing requirements 406 in low-power and lossy networks [RFC 5673], one characteristic in 407 the industrial environment is periodic data. The data is sent 408 periodically and causes bandwidth problem. The in-network caching 409 allows the intermediate nodes to cache these periodically generated 410 data. In this situation, the bandwidth of whole sensor network will 411 be improved for the future requests to the same kind of data. 412 In-network caching can be useful in the case of incorrect data 413 detection or over-threshold detection. In the information-centric 414 sensor network, by putting caching functions at the border sensor 415 node, the border node can cache most of the sensing data from a 416 specific area. Some tasks, such as incorrect data detection or 417 calculation can be done at the border nodes instead of the control 418 center. For examples, the border node can calculate the average 419 temperature of a specific area by using temperature data from its 420 cache as well as requesting temperature data from sensors which the 421 border node doesn't have. This can reduce bandwidth cost of the 422 sensor network. 424 10. Security Considerations 426 11. IANA Considerations 428 12. Acknowledgments 430 13. References 432 13.1. Normative References 434 13.2. Informative References 436 [RFC4919] N., Kushalnagar., Montenegro, G., and C. Schumacher," IPv6 437 over Low-Power Wireless Personal Area Networks 438 (6LoWPANs):Overview, Assumptions, Problem Statement, and 439 Goals", RFC4919, February 2007. 440 [RFC 5673] K. Pister et al., "Industrial Routing requirements in 441 Low-power and Lossy networks", RFC 5673, Oct 2009 443 [ICWSAN] Ngoc-Thanh Dinh and Younghan Kim, "Potential of 444 Information-Centric Wireless Sensor and Actor Networking," 445 Proc. Of COMMANTEL, January 2013 447 [CCN] Jacobson, V. et al., "Networking Named Content," Proc. Of ACM 448 CoNEXT, 2009. 450 [MULTIBIT-TRIE] Kun Suk Kim and Sartaj Sahni, "Efficient 451 Construction of Piplined Multibit-Trie Router Tables," IEEE 452 Trans. On Computers, Vol. 6, No. 1,pp. 32-43, 2007. 454 Authors' Addresses 456 Ngoc-Thanh Dinh 457 Soongsil University 458 Sangdo-do,Dongjak-Gu,Seoul, Korea 156-743 460 Email: ngocthanhdinh@dcn.ssu.ac.kr 462 Younghan Kim 463 Soongsil University 464 Sangdo-do,Dongjak-Gu,Seoul, Korea 156-743 466 Email: younghak@ssu.ac.kr 468 Truong-xuan Do 469 Soongsil University 470 Sangdo-do,Dongjak-Gu,Seoul, Korea 156-743 472 Email: xuan@dcn.ssu.ac.kr 474 Hyunsik Yang 475 Soongsil University 476 Sangdo-do,Dongjak-Gu,Seoul, Korea 156-743 478 Email: yangun@dcn.ssu.ac.kr