idnits 2.17.1 draft-gundogan-icnrg-pub-iot-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack 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 107 has weird spacing: '...uplinks for h...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 13, 2017) is 2601 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 3 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: September 14, 2017 M. Waehlisch 6 link-lab & FU Berlin 7 March 13, 2017 9 Publish-Subscribe Deployment Option for NDN in the Constrained Internet 10 of Things 11 draft-gundogan-icnrg-pub-iot-00 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 September 14, 2017. 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 . . . . . . . . . . 3 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3. Publish-Subscribe in IoT Edge Networks . . . . . . . . . . . 4 60 3.1. Topology Maintenance and Routing . . . . . . . . . . . . 5 61 3.2. Mapping Publish to NDN . . . . . . . . . . . . . . . . . 6 62 3.3. Mapping Subscribe to NDN . . . . . . . . . . . . . . . . 7 63 3.4. Content Replication between Proxy Instances . . . . . . . 8 64 4. Control Plane Messaging . . . . . . . . . . . . . . . . . . . 8 65 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 66 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 67 6.1. Normative References . . . . . . . . . . . . . . . . . . 8 68 6.2. Informative References . . . . . . . . . . . . . . . . . 9 69 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 10 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 72 1. Introduction 74 In the emerging Internet of Things (IoT), it is expected that large 75 quantities of very constrained sensors and actuators collect, 76 communicate, and process massive amounts of machine data. Early 77 experiments with constrained nodes show promising results for 78 different deployments of ICN communication [NDN-EXP]. 80 Characteristics of constrained nodes: 82 o Battery-powered with sleep cycles 84 o Failing nodes 86 o Low power lossy networks 88 Challenges of NDN deployment [RFC7927] 90 o Complexity of name-based routing 92 o State management at nodes 94 o Clear separation between control and data plane 96 o Adaptation to constrained wireless transmission 97 o Mobility management 99 1.1. Baseline Scenarios 101 Multiple scenarios have been discussed in [RFC7476] and [IWMT] that 102 evaluate the applicability of ICN in IoT. 104 We consider two characteristic constrained IoT scenarios with the 105 enumerated challenges: 107 Stationary IoT nodes within reach of fixed uplinks for home, 108 building, and factory automation, stationary monitoring, ... 110 * Reliability, resilience of operation 112 * Radio coordination, coverage 114 * Energy constraints, device lifetime 116 * Interference with rivaling appliances 118 Mobile IoT nodes with sparse coverage or intermittent connectivity 119 for urban or rural mobility and sensing, industrial Internet in 120 widespread environments, disaster recovery and rescue ... 122 * Exploit connectivity when available 124 * Large off-duty cycles of nodes 126 * Partitioned networks 128 * Limited dependability 130 * Environmental impact and disturbance 132 IoT scenarios usually impose routing requirements to support mobile 133 nodes, handle failing links and to be resilient against attacks. A 134 secure and autonomous bootstrapping is essential, especially for 135 large-scale IoT deployments. 137 1.2. Benefits of Loose Coupling in the IoT 139 ICN decouples content consumers from data producers (decoupling in 140 space). A more sophisticated decoupling can be provided with the 141 publish-subscribe messaging pattern that further adds a decoupling in 142 time and synchronization. Constrained devices in LLNs can leverage 143 this loose coupling to increase sleep cycles and delegate the 144 authority over as much information as possible to more powerful 145 devices that act as content proxies. In Figure 1, once content is 146 published to the content proxy (CP) by a producer (P), consumers (C) 147 can retrieve this content from (CP) without interacting with the 148 producer. This indirection when retrieving information allows (P) to 149 align sleep cycles accordingly to the period of generating new sensor 150 readings, instead of handling content requests from any consumers 151 (C). 153 (CP) 154 / | \ 155 / | `-----. 156 / | | | \ 157 (P) (C) ...... (C) 159 Figure 1: Content Proxy (CP) - Producer (P) - Consumer (C) 161 TODO: The problem of PUSH 163 2. Terminology 165 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 166 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 167 document are to be interpreted as described in RFC 2119 [RFC2119]. 168 The use of the term, "silently ignore" is not defined in RFC 2119. 169 However, the term is used in this document and can be similarly 170 construed. 172 This document uses the terminology of [RFC7476], [RFC7927], and 173 [RFC7945] for ICN entities. 175 The following terms are used in the document and defined as follows: 177 Content Proxy Stable node for replicating content. 179 Cloud Gateway A Gateway that enables content transfer to and from a 180 remote cloud storage, possibly by performing some kind of protocol 181 translation. 183 PAM Prefix Advertisement Message. 185 NAM Name Advertisement Message. 187 3. Publish-Subscribe in IoT Edge Networks 189 The publish-subscribe system is centered around prefix-specific 190 content proxies (CPs) that are deployed in IoT edge networks. Such 191 proxy function can be hosted on the Cloud- or Internet Gateway, or 192 may reside on a stable, less constrained node within the IoT 193 infrastructure. It is assumed that a CP is present for each prefix 194 covering publishable content. 196 Implementing a pub-sub NDN involves several steps that are bound to 197 the tight requirements of resource-constrained devices. These steps 198 include: 200 1. Building the prefix-specific routing topology tailored to 201 constrained networks 203 2. Mapping _Publish_ to NDN semantics 205 3. Mapping _Subscribe_ to NDN semantics 207 3.1. Topology Maintenance and Routing 209 A (sensor) node that wants to publish a data item needs to rely on 210 path information towards the Content Proxy. Following the approach 211 of PANINI [PANINI], default routes will be established as follows. 213 Each CP in the local IoT sub-network advertises the prefix(es) it 214 represents to the routing system. It does so by broadcasting Prefix 215 Advertisement Messages (PAMs) on the link layer (see Section 4 for 216 the corresponding protocol details). Nodes that newly receive PAM 217 advertisements will add or refresh a prefix-specific default route in 218 their FIB. Intermediate nodes in a multi-hop environment also re- 219 broadcast PAMs, so that the entire sub-network is flooded and default 220 route entries build a shortest path tree (SPT) towards the CP as 221 shown in Table 1 (alternatively, a DODAG w.r.t. a gateway for 222 redundant CPs). 224 (CP) 225 PAM / \ 226 / \ PAM 227 (A) (B) 228 /|\ /|\ 229 : : : : : : PAM 231 Figure 2: SPT building by Prefix Advertisement Messages (PAMs) 233 Information flowing from constrained sensor nodes towards a gateway 234 is the prevalent communication pattern in the IoT (converge cast). 235 The publish-subscribe system hence establishes a default routing (see 236 sample FIB in Table 1) and uses the tree (DODAG) topology with 237 default routes towards the CP as a first step of content aggregation. 238 Content replication towards other CPs, an Internet gateway, or into a 239 cloud can follow subsequently. 241 +--------+------+----------+ 242 | Prefix | Face | Lifetime | 243 +--------+------+----------+ 244 | / | Fx | Ft | 245 | ... | ... | ... | 246 +--------+------+----------+ 248 Table 1: FIB with a default route 250 It is noteworthy that the role of the new PAM message remains 251 orthogonal to the existing Interest or Data semantics. A PAM never 252 carries data nor requests, but persists on the control plane of name- 253 based routing. User applications stay unaffected, and continue to 254 rely on the NDN-specific request-response paradigm. 256 3.2. Mapping Publish to NDN 258 In classical publish-subscribe systems, a _Publish_ is typically 259 implemented as a push mechanism on the data plane. However, this 260 contradicts the request-response paradigm employed by NDN. To adapt 261 the _Publish_ operation to NDN semantics, it is split into two phases 262 and the required push mechanism is moved into the control plane. The 263 two phases consist of: 265 1. Announcing names of Named Data Objects (NDO) on the control plane 267 2. Requesting NDOs on the data plane 269 The first phase is the actual announcement of names in the upwards 270 direction towards the CP. Because of NDN's name-based routing 271 approach, the announcement of names is subject of the routing 272 protocol and therefore belongs to the control plane. For this 273 purpose, the control message type Name Advertisement Message (NAM) is 274 adapted from PANINI [PANINI]. Similarly to the PAM, a NAM message 275 utilizes a push mechanism in the control plane without interfering 276 with the request-response mechanism on the data plane. NAMs are 277 directed towards the (prefix-specific) parent of a node and traverse 278 hop-by-hop along the gradient towards the CP. Each intermediate hop 279 on the gradient installs forwarding states in the downward direction 280 by using the announced names in the NAM and the incoming face. 281 Typically, states are short-lived for content replication, only. 282 NAMs contain one or multiple names encoded as TLV elements in the 283 payload. 285 Figure 3 (a) depicts the propagation of the NAM towards the (CP). In 286 this example, the name _/HAW/temp123_ is announced by (C) via (A) to 287 (CP). 289 +-----------------------------------------------------------------+ 290 | | 291 | +----------------------+ +-------------------------------+ | 292 | | | | | | 293 | | Mt: /HAW/temp123 | | Mt: /HAW/temp123 = 23C | | 294 | | ,->(CP) | | ,---(CP)<--, | | 295 | | NAM | / | | | / | | | 296 | | | / | | | / ,-' | | 297 | | (A)<-, | | Interest | (A) | Data(23C) | | 298 | | \ | NAM | | | \ `-, | | 299 | | \ | | | | \ | | | 300 | | (C) | | `--->(C)---' | | 301 | | /HAW/temp123 | | /HAW/temp123 = 23C | | 302 | | | | | | 303 | +----------------------+ +-------------------------------+ | 304 | (a) Phase 1 (b) Phase 2 | 305 +-----------------------------------------------------------------+ 307 Figure 3: Publish 309 In addition to a FIB, the (CP) maintains another data structure _Mt_ 310 (Meta-Table) to store all announced names annotated with additional 311 context information and a lifetime. Upon receipt of a NAM, the _Mt_ 312 is updated accordingly. Context information consists of generic 313 properties attached to a name (e.g. topic names and content freshness 314 indicators) and are out of scope of this document. The _Mt_ has its 315 own name and can be requested by other devices. 317 In the second phase, the (CP) requests the content of newly learned 318 names from the first phase. For content requests, the regular NDN 319 Interest-Data exchange on the data plane is used and is depicted in 320 Figure 3 (b). Upon receipt, the content is cached on the (CP). 322 3.3. Mapping Subscribe to NDN 324 In the proposed publish-subscribe system, the _Subscribe_ operation 325 is equivalent to an Interest-based request of previously learned 326 content names. A device can learn about new content by (a) Name 327 Advertisements of the CP via dedicated prefix path (TODO) or 328 broadcast. It may as well poll the _Mt_ in order to learn about 329 general updates at the CP. Context information in the _Mt_ may give 330 indications about periodic sensor readings, so that a periodic 331 polling of the _Mt_ can be aligned with the sensor reading period. 333 +--------------------------------------------------------+ 334 | | 335 | +----------------------+ +----------------------+ | 336 | | | | | | 337 | | Data (Mt) | | Data (Nx) | | 338 | | ,-------->(S) | | ,-------->(S) | | 339 | | (CP)<--------' | | (CP)<--------' | | 340 | | / \ Int. (Mt) | | / \ Int. (Nx) | | 341 | | / \ | | / \ | | 342 | | (A) (B) | | (A) (B) | | 343 | | /|\ /|\ | | /|\ /|\ | | 344 | | : : : : : : | | : : : : : : | | 345 | | | | | | 346 | +----------------------+ +----------------------+ | 347 | (a) Request Mt (b) Request Content | 348 +--------------------------------------------------------+ 350 Figure 4: Subscribe 352 In Figure 4 (a), a subscriber (S) requests the _Mt_ to learn about 353 new names. A new name (Nx) is then requested via the regular 354 Interest/Data request-response paradigm in Figure 4 (b). 356 The majority of constrained devices at the IoT edge are mostly 357 content producers, but not consumers. Subscribers do not necessarily 358 need to be part of the distribution tree, but may reach the gateway 359 (CP) by other means. 361 3.4. Content Replication between Proxy Instances 363 TODO 365 4. Control Plane Messaging 367 TODO 369 5. Security Considerations 371 TODO 373 6. References 375 6.1. Normative References 377 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 378 Requirement Levels", BCP 14, RFC 2119, 379 DOI 10.17487/RFC2119, March 1997, 380 . 382 6.2. Informative References 384 [IWMT] Kutscher, D. and S. Farrell, "Towards an Information- 385 Centric Internet with more Things", Position Paper, 386 Interconnecting Smart Objects with the Internet 387 Workshop IAB, 2011. 389 [NDN-EXP] Baccelli, E., Mehlis, C., Hahm, O., Schmidt, TC., and M. 390 Waehlisch, "Information Centric Networking in the IoT: 391 Experiments with NDN in the Wild", Proc. of 1st ACM Conf. 392 on Information-Centric Networking (ICN-2014) ACM DL, pp. 393 77-86, September 2014. 395 [PANINI] Schmidt, TC., Woelke, S., Berg, N., and M. Waehlisch, 396 "Let's Collect Names: How PANINI Limits FIB Tables in Name 397 Based Routing", Proc. of 15th IFIP Networking 398 Conference IEEE Press, pp. 458-466, Mai 2016. 400 [RFC7476] Pentikousis, K., Ed., Ohlman, B., Corujo, D., Boggia, G., 401 Tyson, G., Davies, E., Molinaro, A., and S. Eum, 402 "Information-Centric Networking: Baseline Scenarios", 403 RFC 7476, DOI 10.17487/RFC7476, March 2015, 404 . 406 [RFC7927] Kutscher, D., Ed., Eum, S., Pentikousis, K., Psaras, I., 407 Corujo, D., Saucez, D., Schmidt, T., and M. Waehlisch, 408 "Information-Centric Networking (ICN) Research 409 Challenges", RFC 7927, DOI 10.17487/RFC7927, July 2016, 410 . 412 [RFC7945] Pentikousis, K., Ed., Ohlman, B., Davies, E., Spirou, S., 413 and G. Boggia, "Information-Centric Networking: Evaluation 414 and Security Considerations", RFC 7945, 415 DOI 10.17487/RFC7945, September 2016, 416 . 418 Acknowledgments 420 This work was stimulated by fruitful discussions ... We would like to 421 thank all active members for constructive thoughts and feedback. In 422 particular, the authors would like to thank (in alphabetical order) 423 Emmanuel Baccelli, Michael Frey, Oliver Hahm, Peter Kietzmann, Dirk 424 Kutscher, Martine Lenders, Joerg Ott, Hauke Petersen, and Felix Shzu- 425 Juraschek. This work was partly funded by the German Federal 426 Ministry of Education and Research, project I3. 428 Authors' Addresses 430 Cenk Gundogan 431 HAW Hamburg 432 Berliner Tor 7 433 Hamburg D-20099 434 Germany 436 Phone: +4940428758067 437 EMail: Cenk.Guendogan@haw-hamburg.de 439 Thomas C. Schmidt 440 HAW Hamburg 441 Berliner Tor 7 442 Hamburg D-20099 443 Germany 445 EMail: t.schmidt@haw-hamburg.de 446 URI: http://inet.haw-hamburg.de/members/schmidt 448 Matthias Waehlisch 449 link-lab & FU Berlin 450 Hoenower Str. 35 451 Berlin D-10318 452 Germany 454 EMail: mw@link-lab.net 455 URI: http://www.inf.fu-berlin.de/~waehl