idnits 2.17.1 draft-gundogan-icnrg-pub-iot-01.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 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 == Line 112 has weird spacing: '...uplinks for h...' -- The document date (July 3, 2017) is 2489 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ICN Research Group C. Gundogan 3 Internet-Draft T. Schmidt 4 Intended status: Experimental HAW Hamburg 5 Expires: January 4, 2018 M. Waehlisch 6 link-lab & FU Berlin 7 July 3, 2017 9 Publish-Subscribe Deployment Option for NDN in the Constrained Internet 10 of Things 11 draft-gundogan-icnrg-pub-iot-01 13 Abstract 15 Constrained IoT devices often operate more efficiently in a loosely 16 coupled environment without maintaining end-to-end connectivity 17 between nodes. Information Centric Networking naturally supports 18 this demand by replicated data distribution and hop wise forwarding. 19 This document outlines a deployment option for NDN in low-power and 20 lossy networks (LLNs) that follows a publish-subscribe pattern. The 21 proposed protocol scheme simplifies name-based routing significantly 22 and facilitates even large off-duty cycles for constrained nodes. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on January 4, 2018. 41 Copyright Notice 43 Copyright (c) 2017 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 respect 51 to this document. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 1.1. Baseline Scenarios . . . . . . . . . . . . . . . . . . . 3 57 1.2. Benefits of Loose Coupling in the IoT . . . . . . . . . . 4 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3. Publish-Subscribe in IoT Edge Networks . . . . . . . . . . . 5 60 3.1. Topology Maintenance and Routing . . . . . . . . . . . . 5 61 3.2. Mapping Publish to NDN . . . . . . . . . . . . . . . . . 7 62 3.3. Mapping Subscribe to NDN . . . . . . . . . . . . . . . . 8 63 3.4. Content Replication in partitioned networks . . . . . . . 9 64 3.5. Content Replication between Proxy Instances . . . . . . . 9 65 3.6. Alerting and group communication . . . . . . . . . . . . 9 66 4. Control Plane Messaging . . . . . . . . . . . . . . . . . . . 10 67 4.1. Prefix Advertisement Message (PAM) . . . . . . . . . . . 10 68 4.2. Name Advertisement Message (NAM) . . . . . . . . . . . . 10 69 4.2.1. Name Option . . . . . . . . . . . . . . . . . . . . . 11 70 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 71 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 72 6.1. Normative References . . . . . . . . . . . . . . . . . . 12 73 6.2. Informative References . . . . . . . . . . . . . . . . . 12 74 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 13 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 77 1. Introduction 79 In the emerging Internet of Things (IoT), it is expected that large 80 quantities of very constrained sensors and actuators collect, 81 communicate, and process massive amounts of machine data. Early 82 experiments with constrained nodes show promising results for 83 different deployments of ICN communication [NDN-EXP]. 85 Characteristics of constrained nodes: 87 o Battery-powered with sleep cycles 89 o Failing nodes 91 o Low power lossy networks 93 Challenges of NDN deployment [RFC7927] 95 o Complexity of name-based routing 96 o State management at nodes 98 o Clear separation between control and data plane 100 o Adaptation to constrained wireless transmission 102 o Mobility management 104 1.1. Baseline Scenarios 106 Multiple scenarios have been discussed in [RFC7476] and [IWMT] that 107 evaluate the applicability of ICN in IoT. 109 We consider two characteristic constrained IoT scenarios with the 110 enumerated challenges: 112 Stationary IoT nodes within reach of fixed uplinks for home, 113 building, and factory automation, stationary monitoring, ... 115 * Reliability, resilience of operation 117 * Radio coordination, coverage 119 * Energy constraints, device lifetime 121 * Interference with rivaling appliances 123 Mobile IoT nodes with sparse coverage or intermittent connectivity 124 for urban or rural mobility and sensing, industrial Internet in 125 widespread environments, disaster recovery and rescue ... 127 * Exploit connectivity when available 129 * Large off-duty cycles of nodes 131 * Partitioned networks 133 * Limited dependability 135 * Environmental impact and disturbance 137 IoT scenarios usually impose routing requirements to support mobile 138 nodes, handle failing links and to be resilient against attacks. A 139 secure and autonomous bootstrapping is essential, especially for 140 large-scale IoT deployments. 142 1.2. Benefits of Loose Coupling in the IoT 144 ICN decouples content consumers from data producers (decoupling in 145 space). A more sophisticated decoupling can be provided with the 146 publish-subscribe messaging pattern that further adds a decoupling in 147 time and synchronization. Constrained devices in LLNs can leverage 148 this loose coupling to increase sleep cycles and delegate the 149 authority over as much information as possible to more powerful 150 devices that act as content proxies. In Figure 1, once content is 151 published to the content proxy (CP) by a producer (P), consumers (C) 152 can retrieve this content from (CP) without interacting with the 153 producer. This indirection when retrieving information allows (P) to 154 align sleep cycles accordingly to the period of generating new sensor 155 readings, instead of handling content requests from any consumers 156 (C). 158 (CP) 159 / | \ 160 / | `-----. 161 / | | | \ 162 (P) (C) ...... (C) 164 Figure 1: Content Proxy (CP) - Producer (P) - Consumer (C) 166 TODO: The problem of PUSH 168 2. Terminology 170 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 171 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 172 document are to be interpreted as described in RFC 2119 [RFC2119]. 173 The use of the term, "silently ignore" is not defined in RFC 2119. 174 However, the term is used in this document and can be similarly 175 construed. 177 This document uses the terminology of [RFC7476], [RFC7927], and 178 [RFC7945] for ICN entities. 180 The following terms are used in the document and defined as follows: 182 Converge Cast Many-to-One communication pattern, where multiple 183 devices send sensor readings to one gateway. 185 Content Proxy Stable node for replicating content. 187 Cloud Gateway A Gateway that enables content transfer to and from a 188 remote cloud storage, possibly by performing some kind of protocol 189 translation. 191 PAM Prefix Advertisement Message. 193 NAM Name Advertisement Message. 195 3. Publish-Subscribe in IoT Edge Networks 197 The publish-subscribe system is centered around prefix-specific 198 content proxies (CPs) that are deployed in IoT edge networks. Such 199 proxy function can be hosted on the Cloud- or Internet Gateway, or 200 may reside on a stable, less constrained node within the IoT 201 infrastructure. It is assumed that a CP is present for each prefix 202 covering publishable content. 204 Implementing a pub-sub NDN involves several steps that are bound to 205 the tight requirements of resource-constrained devices. These steps 206 include: 208 1. Building the prefix-specific routing topology tailored to 209 constrained networks 211 2. Mapping _Publish_ to NDN semantics 213 3. Mapping _Subscribe_ to NDN semantics 215 3.1. Topology Maintenance and Routing 217 A (sensor) node that wants to publish a data item needs to rely on 218 path information towards the Content Proxy. Following the approach 219 of PANINI [PANINI], default routes will be established as follows. 221 Each CP in the local IoT sub-network advertises the prefix(es) it 222 represents to the routing system. It does so by broadcasting Prefix 223 Advertisement Messages (PAMs) on the link layer (see Section 4 for 224 the corresponding protocol details). Nodes that newly receive PAM 225 advertisements will add or refresh a prefix-specific default route in 226 their FIB. Intermediate nodes in a multi-hop environment also re- 227 broadcast PAMs, so that the entire sub-network is flooded and default 228 route entries build a shortest path tree (SPT) towards the CP as 229 shown in Table 1 (alternatively, a DODAG w.r.t. a gateway for 230 redundant CPs). 232 (CP) 233 PAM / \ 234 / \ PAM 235 (A) (B) 236 /|\ /|\ 237 : : : : : : PAM 239 Figure 2: SPT building by Prefix Advertisement Messages (PAMs) 241 Information flowing from constrained sensor nodes towards a gateway 242 is the prevalent communication pattern in the IoT (converge cast). 243 The publish-subscribe system hence establishes a default routing (see 244 sample FIB in Table 1) and uses the tree topology with default routes 245 towards the CP as a first step of content aggregation. Content 246 replication towards other CPs, an Internet gateway, or into a cloud 247 can follow subsequently. 249 +--------+------+----------+ 250 | Prefix | Face | Lifetime | 251 +--------+------+----------+ 252 | /P/ | Fx | Ft | 253 | ... | ... | ... | 254 +--------+------+----------+ 256 Table 1: FIB with a prefix-specific default route 258 It is noteworthy that the role of the new PAM message remains 259 orthogonal to the existing Interest or Data semantics. A PAM never 260 carries data nor requests, but persists on the control plane of name- 261 based routing. User applications stay unaffected, and continue to 262 rely on the NDN-specific request-response paradigm. 264 Each node in the tree calculates a rank based on the rank of its 265 parent and a routing metric. Hence, the rank is an indication for 266 the position within the tree and is strictly monotonically increasing 267 in the downwards direction from root to leaf. For simplicity, this 268 document uses the hop-count routing metric to calculate the rank. 269 Future work can focus on more elaborate routing metrics, e.g., to 270 reduce packet retransmissions or improve load balancing for publish 271 operations. 273 The Routing Information Base (RIB) contains the following 274 information: 276 SPT 278 Prefix: 280 Variable length prefix to configure a prefix-specific default 281 route 283 Rank: 284 16-bit unsigned integer indicating a node's rank 286 Flags: 287 8-bit unsigned integer to store SPT related flags 289 Parent 290 The appropriate face towards the parent node is stored. 292 NAM Cache (NC) 293 Entries in the NAM Cache are __ tuples. The 294 NC is consolidated when propagating name advertisements. 296 3.2. Mapping Publish to NDN 298 In classical publish-subscribe systems, a _Publish_ is typically 299 implemented as a push mechanism on the data plane. However, this 300 contradicts the request-response paradigm employed by NDN. To adapt 301 the _Publish_ operation to NDN semantics, it is split into two phases 302 and the required push mechanism is performed on the control plane 303 with a link-local scope. The two phases consist of: 305 1. Announcing names of Named Data Objects (NDO) on the control plane 307 2. Requesting NDOs on the data plane 309 In the first phase, the name of the NDO to publish is advertised to 310 the prefix-specific upstream neighbor by encoding it with TLV format 311 in a unicast link-local Name Advertisement Message (NAM) adopted from 312 PANINI [PANINI]. Once an upstream neighbor receives an unsolicited 313 NAM, the name is extracted and along with the incoming face stored in 314 the NAM Cache (NC) as a __ tuple. This link- 315 local content signaling does not establish any data paths in the PIT, 316 nor does it modify the FIB or the Content Store (CS). 318 In the second phase and as a result of an unsolicited NAM, the 319 content is requested from the downstream neighbor accordingly to the 320 standard NDN scheme with an Interest message for the name recorded in 321 the NC on the recorded face. When a downstream neighbor replies with 322 the content (Data message), this neighbor removes the corresponding 323 NC entry and the NDO to publish is successfully replicated one hop 324 closer towards the content proxy. NC entries are thus short-lived 325 for hop-wise replication only. 327 Both phases are iteratively repeated hop-wise until the content proxy 328 is reached. Being the root of this prefix-specific spanning tree, 329 the content proxy has no further prefix-specific upstream neighbor 330 and the replication terminates. It is noteworthy, that both phases 331 can be interleaved, so that NAMs are signaled to the upstream 332 neighbor, while the content is requested from the downstream 333 neighbor. 335 Figure 3 (a) depicts the hop-wise replication of a published content 336 on the gradient towards the (CP). In this example, the name _/HAW/ 337 temp_t_ is advertised by the producer (P) to its parent node (A). 338 (A) extracts the name from the NAM and stores it along with the 339 incoming face in its NC. (A) then propagates the NAM further to its 340 parent (CP) and simultaneously requests the content from (P) as 341 depicted in Figure 3 (b). Likewise in Figure 3 (c), (CP) reacts to 342 the incoming NAM by requesting the content from (A). NC states from 343 (A) and (P) are removed as soon as they respond to the request. 345 +-------------+ +------------------------+ +-------------------+ 346 | | | | | Interest | 347 | (CP) | | ,->(CP) | | ,----(CP)<-, | 348 | / | | NAM | / | | | / / | 349 | / | | | / | | | / / | 350 | (A)<-, | | ,-(A)<-, | | `>(A)---' Data | 351 | \ | NAM | | | \ | Data | | \ | 352 | \ | | | | \ | | | \ | 353 | (P) | | Interest `--->(P) | | (P) | 354 | /HAW/temp_t | | /HAW/temp_t | | /HAW/temp_t | 355 +-------------+ +------------------------+ +-------------------+ 356 (a) Adv. Name (b) Replicate Content (c) Finish publish 358 Figure 3: Publish 360 3.3. Mapping Subscribe to NDN 362 In the proposed publish-subscribe system, the _Subscribe_ operation 363 is equivalent to an Interest-based request of previously learned 364 content names. A device can learn about new content in various ways: 366 a. Name Advertisements of the CP via dedicated prefix path (TODO) or 367 broadcast. 369 b. By polling a dedicated data structure at the CP that records 370 publishings and updates. Such a data structure may contain 371 indicators about the periodicity of sensor readings to align 372 periodic polling schemes to sensor reading intervals. 374 c. By encoding topics into a hierarchical naming scheme of the form 375 _routing prefix / topic / unique_part_. Inerest timeouts for 376 these names serve as subscription periods and must be refreshed 377 or retriggered for every publishing to adhere to the flow control 378 approach of NDN / CCNx. 380 TODO 382 3.4. Content Replication in partitioned networks 384 The hop-wise replication described in Section 3.2 transparently 385 supports publish operations in partitioned networks. When a publish 386 operation fails to replicate content and no backup parent is in the 387 vicinity (Figure 4 (b)), the node marks its sub-DAG as _floating_ by 388 propagating PAMs with the floating bit set and the NC entry is 389 preserved. Once a sub-DAG becomes connected to another parent, the 390 publishing is resumed (Figure 4 (c)). 392 +-------------+ +-------------+ +-------------+ 393 | | | | | | 394 | (CP) | | (CP) | | (CP)<-, | 395 | | | | | / / | 396 | | | X | | / / | 397 | (A)<-, | | (A)---' | | (A)---' | 398 | \ | PUB | | \ PUB | | \ PUB | 399 | \ | | | \ | | \ | 400 | (P) | | (P) | | (P) | 401 | /HAW/temp_t | | /HAW/temp_t | | /HAW/temp_t | 402 +-------------+ +-------------+ +-------------+ 403 (a) Publish content (b) Publish fails (c) Finish Publish 405 Figure 4: Publish in partitioned network 407 A node receiving a PAM from its parent with the floating bit set may 408 rejoin the tree using another parent in the neighborhood that is 409 connected to the content proxy. Rejoining the tree may result in a 410 worse rank. 412 3.5. Content Replication between Proxy Instances 414 TODO 416 3.6. Alerting and group communication 418 TODO 420 4. Control Plane Messaging 422 TODO: add ABNF 424 TODO: add mappings of PAM and NAM to the NDN and CCNx dialects 426 4.1. Prefix Advertisement Message (PAM) 428 0 1 2 3 429 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 | Type = PAM |F| Reserved | Rank | 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 | Prefix Length | Prefix ... 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 Figure 5: Prefix Advertisement Message (PAM) 438 Message type: 439 8-bit unsigned integer. Indicates a PAM. 441 Floating (F): 442 1-bit floating flag. Indicates that a sub-tree is not 443 connected to the content proxy, when set. 445 Reserved: 446 7-bit unused field. It MUST be initialized to zero by 447 the sender and MUST be ignored by the receiver. 449 Rank: 450 16-bit unsigned integer. Indicates a node's position in 451 the SPT. 453 Prefix Length: 454 16-bit unsigned integer. Indicates the length of the 455 following prefix in bytes. 457 Prefix: 458 Variable length prefix used to configure a default route 459 within the SPT. 461 4.2. Name Advertisement Message (NAM) 462 0 1 2 3 463 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 | Type = NAM | Reserved | Options Length | 466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 467 : Options : 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 Figure 6: Name Advertisement Message (NAM) 472 Type: 473 8-bit unsigned integer. Indicates a NAM. 475 Reserved: 476 8-bit unused field. It MUST be initialized to zero by 477 the sender and MUST be ignored by the receiver. 479 Length: 480 16-bit unsigned integer. Indicates the accumulated 481 length of all options. 483 4.2.1. Name Option 485 0 1 2 3 486 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 | Type = 0x00 | Name Length | Name ... 489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 Figure 7: Name option format 493 Type: 494 8-bit unsigned integer. Indicates the name option 495 (0x00). 497 Name Length: 498 16-bit unsigned integer. Indicates the length of the 499 name, excluding the type and length field. 501 Name: 502 Variable length name. 504 5. Security Considerations 506 TODO 508 6. References 510 6.1. Normative References 512 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 513 Requirement Levels", BCP 14, RFC 2119, 514 DOI 10.17487/RFC2119, March 1997, 515 . 517 6.2. Informative References 519 [IWMT] Kutscher, D. and S. Farrell, "Towards an Information- 520 Centric Internet with more Things", Position Paper, 521 Interconnecting Smart Objects with the Internet 522 Workshop IAB, 2011. 524 [NDN-EXP] Baccelli, E., Mehlis, C., Hahm, O., Schmidt, TC., and M. 525 Waehlisch, "Information Centric Networking in the IoT: 526 Experiments with NDN in the Wild", Proc. of 1st ACM Conf. 527 on Information-Centric Networking (ICN-2014) ACM DL, pp. 528 77-86, September 2014. 530 [PANINI] Schmidt, TC., Woelke, S., Berg, N., and M. Waehlisch, 531 "Let's Collect Names: How PANINI Limits FIB Tables in Name 532 Based Routing", Proc. of 15th IFIP Networking 533 Conference IEEE Press, pp. 458-466, Mai 2016. 535 [RFC7476] Pentikousis, K., Ed., Ohlman, B., Corujo, D., Boggia, G., 536 Tyson, G., Davies, E., Molinaro, A., and S. Eum, 537 "Information-Centric Networking: Baseline Scenarios", 538 RFC 7476, DOI 10.17487/RFC7476, March 2015, 539 . 541 [RFC7927] Kutscher, D., Ed., Eum, S., Pentikousis, K., Psaras, I., 542 Corujo, D., Saucez, D., Schmidt, T., and M. Waehlisch, 543 "Information-Centric Networking (ICN) Research 544 Challenges", RFC 7927, DOI 10.17487/RFC7927, July 2016, 545 . 547 [RFC7945] Pentikousis, K., Ed., Ohlman, B., Davies, E., Spirou, S., 548 and G. Boggia, "Information-Centric Networking: Evaluation 549 and Security Considerations", RFC 7945, 550 DOI 10.17487/RFC7945, September 2016, 551 . 553 Acknowledgments 555 This work was stimulated by fruitful discussions ... We would like to 556 thank all active members for constructive thoughts and feedback. In 557 particular, the authors would like to thank (in alphabetical order) 558 Emmanuel Baccelli, Michael Frey, Oliver Hahm, Peter Kietzmann, Dirk 559 Kutscher, Martine Lenders, Joerg Ott, Hauke Petersen, and Felix Shzu- 560 Juraschek. This work was partly funded by the German Federal 561 Ministry of Education and Research, project I3. 563 Authors' Addresses 565 Cenk Gundogan 566 HAW Hamburg 567 Berliner Tor 7 568 Hamburg D-20099 569 Germany 571 Phone: +4940428758067 572 EMail: Cenk.Guendogan@haw-hamburg.de 574 Thomas C. Schmidt 575 HAW Hamburg 576 Berliner Tor 7 577 Hamburg D-20099 578 Germany 580 EMail: t.schmidt@haw-hamburg.de 581 URI: http://inet.haw-hamburg.de/members/schmidt 583 Matthias Waehlisch 584 link-lab & FU Berlin 585 Hoenower Str. 35 586 Berlin D-10318 587 Germany 589 EMail: mw@link-lab.net 590 URI: http://www.inf.fu-berlin.de/~waehl