idnits 2.17.1 draft-irtf-icnrg-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: ---------------------------------------------------------------------------- No issues found here. 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 (August 8, 2014) is 3542 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ICNRG K. Pentikousis, Ed. 3 Internet-Draft EICT 4 Intended Status: Informational B. Ohlman 5 Expires: February 9, 2015 Ericsson 6 D. Corujo 7 Universidade de Aveiro 8 G. Boggia 9 Politecnico di Bari 10 G. Tyson 11 Queen Mary, University of London 12 E. Davies 13 Trinity College Dublin 14 A. Molinaro 15 UNIRC 16 S. Eum 17 NICT 18 August 8, 2014 20 Information-centric Networking: Baseline Scenarios 21 draft-irtf-icnrg-scenarios-03 23 Abstract 25 This document aims at establishing a common understanding about a set 26 of scenarios that can be used as a base for the evaluation of 27 different information-centric networking (ICN) approaches so that 28 they can be tested and compared against each other while showcasing 29 their own advantages. Towards this end, we review the ICN literature 30 and document scenarios which have been considered in previous 31 performance evaluation studies. We discuss a variety of aspects that 32 an ICN solution can address. This includes general aspects, such as, 33 network efficiency, reduced complexity, increased scalability and 34 reliability, mobility support, multicast and caching performance, 35 real-time communication efficiency, energy consumption frugality, and 36 disruption and delay tolerance. We detail ICN-specific aspects as 37 well, such as information security and trust, persistence, 38 availability, provenance, and location independence. 40 This document is a product of the IRTF Information-Centric Networking 41 Research Group (ICNRG). 43 Status of this Memo 45 This Internet-Draft is submitted to IETF in full conformance with the 46 provisions of BCP 78 and BCP 79. 48 Internet-Drafts are working documents of the Internet Engineering 49 Task Force (IETF), its areas, and its working groups. Note that 50 other groups may also distribute working documents as 51 Internet-Drafts. 53 Internet-Drafts are draft documents valid for a maximum of six months 54 and may be updated, replaced, or obsoleted by other documents at any 55 time. It is inappropriate to use Internet-Drafts as reference 56 material or to cite them other than as "work in progress." 58 The list of current Internet-Drafts can be accessed at 59 http://www.ietf.org/1id-abstracts.html 61 The list of Internet-Draft Shadow Directories can be accessed at 62 http://www.ietf.org/shadow.html 64 Copyright and License Notice 66 Copyright (c) 2014 IETF Trust and the persons identified as the 67 document authors. All rights reserved. 69 This document is subject to BCP 78 and the IETF Trust's Legal 70 Provisions Relating to IETF Documents 71 (http://trustee.ietf.org/license-info) in effect on the date of 72 publication of this document. Please review these documents 73 carefully, as they describe your rights and restrictions with respect 74 to this document. 76 Table of Contents 78 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 79 1.1. Baseline Scenario Selection . . . . . . . . . . . . . . . 5 80 1.2. Document Goals and Outline . . . . . . . . . . . . . . . . 5 81 2. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 6 82 2.1. Social Networking . . . . . . . . . . . . . . . . . . . . 6 83 2.2. Real-time Communication . . . . . . . . . . . . . . . . . 7 84 2.3. Mobile Networking . . . . . . . . . . . . . . . . . . . . 9 85 2.4. Infrastructure Sharing . . . . . . . . . . . . . . . . . . 12 86 2.5. Content Dissemination . . . . . . . . . . . . . . . . . . 13 87 2.6. Vehicular Networking . . . . . . . . . . . . . . . . . . . 14 88 2.7. Delay- and Disruption-Tolerance . . . . . . . . . . . . . 17 89 2.7.1. Opportunistic Content Sharing . . . . . . . . . . . . 21 90 2.7.2. Emergency Support and Disaster Recovery . . . . . . . 21 91 2.8. Internet of Things . . . . . . . . . . . . . . . . . . . . 23 92 2.9. Smart City . . . . . . . . . . . . . . . . . . . . . . . . 26 93 3. Cross-scenario Considerations . . . . . . . . . . . . . . . . 27 94 3.1. Multiply-connected Nodes and Economics . . . . . . . . . . 27 95 3.2. Energy Efficiency . . . . . . . . . . . . . . . . . . . . 32 96 3.3. Operation across Multiple Network Paradigms . . . . . . . 33 97 4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 98 5. Security Considerations . . . . . . . . . . . . . . . . . . . 36 99 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 100 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 36 101 8. Informative References . . . . . . . . . . . . . . . . . . . . 36 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 44 104 1. Introduction 106 Information-centric networking (ICN) marks a fundamental shift in 107 communications and networking. In contrast with the omnipresent and 108 very successful host-centric paradigm, which is based on perpetual 109 connectivity and the end-to-end principle, ICN changes the focal 110 point of the network architecture from the end host to "named 111 information" (or content, or data). In this paradigm, connectivity 112 may well be intermittent. End-host and in-network storage can be 113 capitalized upon transparently, as bits in the network and on storage 114 devices have exactly the same value. Mobility and multiaccess are 115 the norm and anycast, multicast, and broadcast are natively 116 supported. 118 It is also worth noting that with the transition from a host-centric 119 to an information-centric communication model the security paradigm 120 changes as well. In a host-centric network, the basic idea is to 121 create secure (remote-access) tunnels to trusted providers of data. 122 In an information-centric network, on the other hand, any source 123 (cache) should be equally usable. This requires some mechanism for 124 making each information item trustworthy by itself, which can be 125 achieved, for example, by name-data-integrity or by signing data 126 objects. 128 Although interest in ICN is growing rapidly, ongoing work on 129 different architectures, such as, for example, NetInf [NetInf], CCN 130 [CCN] and NDN [NDNP], the publish-subscribe Internet (PSI) 131 architecture [PSI], and the data-oriented architecture [DONA] is far 132 from being completed. One could think of ICN today as being at an 133 equivalent stage of development similar to the one that packet- 134 switched networking was in the late 70's when different technologies, 135 e.g. DECnet, IPX, and IP, just to name a few, were actively developed 136 and put to the test. As such, the development phase that ICN is 137 going through, and the plethora of approaches to tackle the hardest 138 problems, make this a very active and growing research area but, on 139 the downside, it also makes it more difficult to compare different 140 proposals on an equal footing. This document aims to address this 141 partially by establishing a common understanding about potential 142 experimental setups where different ICN approaches can be tested and 143 compared against each other while showcasing their advantages. 145 The first version of this document appeared in November 2012. It was 146 adopted by ICNRG at IETF 87 (July 2013) as the document to address 147 the work item on the definition of "reference baseline scenarios to 148 enable performance comparisons between different approaches". Earlier 149 versions of this document have been presented during the ICNRG 150 meetings at IETF 85, IETF 86, IETF 87, IETF 88, IETF 89 and at the 151 ICNRG interim meeting in Stockholm in February 2013. This document 152 has been reviewed, commented, and discussed extensively for a period 153 of nearly two years by the vast majority of ICNRG members, which 154 certainly exceeds 100 individuals. It is the consensus of ICNRG that 155 the baseline scenarios described in this document should be published 156 in the IRTF Stream RFC Series. This document does not constitute a 157 standard. 159 1.1. Baseline Scenario Selection 161 Ahlgren et al. [SoA1][SoA2] note that describing ICN architectures is 162 akin to shooting a moving target. We find that comparing these 163 different approaches is often even more tricky. It is not uncommon 164 that researchers devise different performance evaluation scenarios, 165 typically with good reason, in order to highlight the advantages of 166 their approach. This should be expected to some degree at this early 167 stage of ICN development. Nevertheless, this document shows that 168 certain baseline scenarios seem to emerge in which ICN architectures 169 could showcase their comparative advantage over current systems, in 170 general, and against each other, in particular. 172 This document surveys the peer-reviewed ICN literature and presents 173 prominent evaluation study cases as a foundation for the baseline 174 scenarios to be considered by the IRTF Information-Centric Networking 175 Research Group (ICNRG) in its future work. There are two goals for 176 this document. First, to provide a set of use cases and applications 177 that highlight opportunities for testing different ICN proposals. 178 Second, to identify key attributes of a common set of techniques that 179 can be instrumental in evaluating ICN. Further, these scenarios are 180 intended to equip researchers with sufficient configuration data to 181 effectively evaluate their ICN proposals in a variety of settings, 182 particularly extending beyond scenarios focusing simply on 183 traditional content delivery. The overall aim is that each scenario 184 is described at a sufficient level of detail, and with adequate 185 references to already published work, so that it can serve as the 186 base for comparative evaluations of different approaches. Example 187 code which implements some of the scenarios and topologies included 188 in this document is available from http://telematics.poliba.it/icn- 189 baseline-scenarios. 191 1.2. Document Goals and Outline 193 This document incorporates input from ICNRG participants and their 194 corresponding text contributions, has been reviewed by several ICNRG 195 active participants (see section 7), and represents the consensus of 196 the research group. However, this document does not constitute an 197 IETF standard, but is indented as an informational document; see also 199 [RFC5743]. As mentioned above, these scenarios are intended to 200 provide a framework for evaluating different ICN approaches. The 201 methodology for how to do these evaluations as well as definitions of 202 metrics that should be used will be described in a separate document 203 [draft-irtf-icnrg-evaluation-methodology]. In addition, interested 204 readers should consider reviewing [draft-kutscher-icnrg-challenges]. 206 The remainder of this document presents a number of scenarios grouped 207 into several categories in section 2, followed by a number of cross- 208 scenario considerations in section 3. Overall, note that certain 209 evaluation scenarios span across these categories, so the boundaries 210 between them should not be considered rigid and inflexible. Section 211 4 summarizes in a concise manner the main evaluation aspects across 212 the range of scenarios discussed in this document. 214 2. Scenarios 216 This section presents nine scenario categories based on use cases and 217 evaluations which have appeared in the peer-reviewed literature. 219 2.1. Social Networking 221 Social networking applications have proliferated over the past decade 222 based on overlay content dissemination systems that require large 223 infrastructure investments to rollout and maintain. Content 224 dissemination is at the heart of the ICN paradigm. Therefore, we 225 would expect that social networking scenarios are a "natural fit" for 226 comparing ICN performance with traditional client-server TCP/IP-based 227 systems. Mathieu et al. [ICN-SN], for instance, illustrate how an 228 Internet Service Provider (ISP) can capitalize on CCN to deploy a 229 short-message service akin to Twitter at a fraction of the complexity 230 of today's systems. Their key observation is that such a service can 231 be seen as a combination of multicast delivery and caching. That is, 232 a single user addresses a large number of recipients, some of which 233 receive the new message immediately as they are online at that 234 instant, while others receive the message whenever they connect to 235 the network. 237 Along similar lines, Kim et al. [VPC] present an ICN-based social 238 networking platform in which a user shares content with her/his 239 family and friends without the need for centralized content servers; 240 see also section 2.4, below, and [CBIS]. Based on the CCN naming 241 scheme, [VPC] takes a user name to represent a set of devices that 242 belong to the person. Other users in this in-network, serverless 243 social sharing scenario can access the user's content not via a 244 device name/address but with the user's name. In [VPC], signature 245 verification does not require any centralized authentication server. 246 Kim and Lee [VPC2] present a proof-of-concept evaluation in which 247 users with ordinary smartphones can browse a list of members or 248 content using a name, and download the content selected from the 249 list. 251 In other words, the above-mentioned evaluation studies indicate that 252 with ICN there may be no need for an end-to-end system design which 253 intermediates between content providers and consumers in a hub-and- 254 spoke fashion at all times. 256 Earlier work by Arianfar et al. [CCR] considers a similar pull-based 257 content retrieval scenario using a different architecture, pointing 258 to significant performance advantages. Although the authors consider 259 a network topology (redrawn in Fig. 1 for convenience) that has 260 certain interesting characteristics, they do not explicitly address 261 social networking in their evaluation scenario. Nonetheless, 262 similarities are easy to spot: "followers" (such as C0, C1, ..., and 263 Cz in Fig. 1) obtain content put "on the network" (I1, ..., Im, and 264 B1, B2) by a single user (e.g. Px) relying solely on network 265 primitives. 267 \--/ 268 |C0| 269 /--\ +--+ +--+ +--+ +--+ 270 *=== |I0| === |I1| ... |In| |P0| 271 \--/ +--+ +--+ +--+ +--+ 272 |C1| \ / o 273 /--\ +--+ +--+ o 274 o |B1| === |B2| o 275 o o o o o +--+ +--+ o 276 o / \ o 277 o +--+ +--+ +--+ +--+ 278 o *=== |Ik| === |Il| ... |Im| |Px| 279 \--/ +--+ +--+ +--+ +--+ 280 |Cz| 281 /--\ 283 Figure 1. Dumbbell with linear daisy chains. 285 In summary, the social networking scenario aims to exercise each ICN 286 architecture in terms of network efficiency, multicast support, 287 caching performance and its reliance on centralized mechanisms (or 288 lack thereof). 290 2.2. Real-time Communication 291 Real-time audio and video (A/V) communications include an array of 292 services ranging from one-to-one voice calls to multi-party multi- 293 media conferences with support ranging from whiteboards to augmented 294 reality. Real-time communications have been studied and deployed in 295 the context of packet- and circuit-switched networks for decades. 296 The stringent quality of service requirements that this type of 297 communication imposes on network infrastructure are well known. 298 Since one could argue that network primitives which are excellent for 299 information dissemination are not well-suited for conversational 300 services, ICN evaluation studies should consider real-time 301 communication scenarios in detail. 303 Notably, Jacobson et al. [VoCCN] presented an early evaluation where 304 the performance of a VoIP (voice over IP) call using an information- 305 centric approach was compared with that of an off-the-shelf VoIP 306 implementation using RTP/UDP. The results indicated that despite the 307 extra cost of adding security support in the ICN approach, 308 performance was virtually identical in the two cases evaluated in 309 their testbed. However, the experimental setup presented is quite 310 rudimentary, while the evaluation considered a single voice call 311 only. Xuan and Yan [NDNpb] revisit the same scenario but are 312 primarily interested in reducing the overhead that may arise in one- 313 to-one communication employing an ICN architecture. Both studies 314 illustrate that quality telephony services are feasible with at least 315 one ICN approach. That said, future ICN evaluations should employ 316 standardized call arrival patterns, for example, following well- 317 established methodologies from the quality of service/experience 318 (QoS/QoE) evaluation toolbox and would need to consider more 319 comprehensive metrics. 321 Given the wide-spread deployment of real-time A/V communications, an 322 evaluation of an ICN system should demonstrate capabilities beyond 323 feasibility. For example, with respect to multimedia conferencing, 324 Zhu et al. [ACT] describe the design of a distributed audio 325 conference tool based on NDN. Their system includes ICN-based 326 conference discovery, discovery of speakers and voice data 327 distribution. The reported evaluation results point to gains in 328 scalability and security. Moreover, Chen et al. [G-COPSS] explore 329 the feasibility of implementing a Massively Multiplayer Online Role 330 Playing Game (MMORPG) based on CCNx and show that stringent temporal 331 requirements can be met, while scalability is significantly improved 332 when compared to a host-centric (IP-based) client-server system. 333 This type of work points to benefits for both the data and control 334 path of a modern network infrastructure. 336 Real-time communication also brings up the issue of named data 337 granularity for dynamically generated content. For instance, in many 338 cases A/V data is generated in real-time and is distributed 339 immediately. One possibility is to apply a single name to the entire 340 content, but this could result in significant distribution delays. 341 Alternatively, distributing A/V content in smaller "chunks" which are 342 named individually may be a better option with respect to real-time 343 distribution but raises naming scalability concerns. 345 We observe that, all in all, the ICN research community has hitherto 346 only scratched the surface of this area with respect to illustrating 347 the benefits of adopting an information-centric approach as opposed 348 to a host-centric one, and thus more work is recommended in this 349 direction. Scenarios in this category should illustrate not only 350 feasibility but reduced complexity, increased scalability, 351 reliability, and capacity to meet stringent QoS/QoE requirements when 352 compared to established host-centric solutions. Accordingly, the 353 primary aim of this scenario is to exercise each ICN architecture in 354 terms of its ability to satisfy real-time QoS requirements and 355 improved user experience. 357 2.3. Mobile Networking 359 IP mobility management relies on anchors to provide ubiquitous 360 connectivity to end-hosts as well as moving networks [MMIN]. This is 361 a natural choice for a host-centric paradigm that requires end-to-end 362 connectivity and a continuous network presence for hosts [SCES]. An 363 implicit assumption in host-centric mobility management is therefore 364 that the mobile node aims to connect to a particular peer, as well as 365 to maintain global reachability and service continuity [EEMN]. 366 However, with ICN new ideas about mobility management should come to 367 the fore capitalizing on the different nature of the paradigm, such 368 as native support for multihoming, abstraction of network addresses 369 from applications, less dependence on connection-oriented sessions, 370 and so on [MOBSURV]. 372 Dannewitz et al. [N-Scen] illustrate a scenario where a multiaccess 373 end-host can retrieve email securely using a combination of cellular 374 and wireless local area network (WLAN) connectivity. This scenario 375 borrows elements from previous work, e.g., [DTI], and develops them 376 further with respect to multiaccess. Unfortunately, Dannewitz et al. 377 [N-Scen] do not present any results demonstrating that an ICN 378 approach is, indeed, better. That said, the scenario is interesting 379 as it considers content specific to a single user (i.e., her mailbox) 380 and does point to reduced complexity. It is also compatible with 381 recent work in the Distributed Mobility Management (DMM) Working 382 Group within the IETF. Finally, Xylomenos et al. [PSIMob] as well as 383 [EEMN] argue that an information-centric architecture can avoid the 384 complexity of having to manage tunnels to maintain end-to-end 385 connectivity as is the case with mobile anchor-based protocols such 386 as Mobile IP (and its variants). Similar considerations hold for a 387 vehicular (networking) environment, as we discuss in section 2.6. 389 Overall, mobile networking scenarios have not been developed in 390 detail, let alone evaluated at a large scale. Further, the majority 391 of scenarios discussed so far have related to information consumer, 392 rather than source, mobility. We expect that in the coming period 393 more papers will address this topic. Earlier work [mNetInf] argues 394 that for mobile and multiaccess networking scenarios we need to go 395 beyond the current mobility management mechanisms in order to 396 capitalize on the core ICN features. They present a testbed setup 397 (redrawn in Fig. 2) which can serve as the basis for other ICN 398 evaluations. In this scenario, node "C0" has multiple network 399 interfaces that can access local domains N0 and N1 simultaneously 400 allowing C0 to retrieve objects from whichever server (I2 or I3) can 401 supply them without necessarily needing to access the servers in the 402 core network "C" (P1 and P2). Lindgren [HybICN] explores this 403 scenario further for an urban setting. He uses simulation and 404 reports sizable gains in terms of reduction of object retrieval times 405 and core network capacity use. 407 +------------+ +-----------+ 408 | Network N0 | | Network C | 409 | | | | 410 | +--+ | ==== | +--+ | 411 | |I2| | | |P1| | 412 | +--+ | | +--+ | 413 | \--/ | | | 414 +-----|C0|---+ | | 415 | /--\ | | | 416 | +--+ | | | 417 | |I3| | | +--+ | 418 | +--+ | ==== | |P2| | 419 | | | +--+ | 420 | Network N1 | | | 421 +------------+ +-----------+ 423 Figure 2. Overlapping wireless multiaccess. 425 The benefits from capitalizing on the broadcast nature of wireless 426 access technologies has yet to be explored to its full potential in 427 the ICN literature, including quantifying possible gains in terms of 428 energy efficiency [E-CHANET]. Obviously, ICN architectures must 429 avoid broadcast storms. Early work in this area considers 430 distributed packet suppression techniques which exploit delayed 431 transmissions and overhearing; examples can be found in [MobiA] and 432 [CCNMANET] for ICN-based mobile ad-hoc networks (MANETs), and in 433 [RTIND] and [CCNVANET] for vehicular scenarios. 435 One would expect that mobile networking scenarios will be naturally 436 coupled with those discussed in the previous sections, as more users 437 access social networking and multimedia applications through mobile 438 devices. Further, the constraints of real-time A/V applications 439 create interesting challenges in handling mobility, particularly in 440 terms of maintaining service continuity. This scenario therefore 441 spans across most of the others considered in this document with the 442 likely need for some level of integration, particularly considering 443 the well-documented increases in mobile traffic. Mobility is further 444 considered in section 2.7 and the economic consequences of nodes 445 having multiple network interfaces is explored in section 3.1. 447 Host-centric mobility management has traditionally used a range of 448 metrics for evaluating performance on a per-node and network-wide 449 level. The first metric that comes to mind is handover latency, 450 defined in [RFC5568] as the "period during which the mobile node is 451 unable to send or receive packets". This metric should be considered 452 in ICN performance evaluation studies dealing with mobility. Note 453 that in IP-based networks handover latency has been addressed by the 454 introduction of mobility management protocols, which aim to hide node 455 mobility from the correspondent node, and often follow a make-before- 456 break approach in order to ensure seamless connectivity, and minimize 457 or eliminate altogether handover latency. The "always-on" and "always 458 best connected" [ABC] paradigms have guided mobility management 459 research and standardization for a good decade or so. One can argue 460 that such mechanisms are not particularly suited for ICN. That said, 461 there has been a lot of interest recently in distributed mobility 462 management schemes (see [MMIN] for a summary), where mobility 463 management support is not "always on" by default. Such schemes may be 464 more suitable for ICN. As a general recommendation ICN designs should 465 aim to minimize handover latency so that the end-user and service 466 Quality of Experience (QoE) is not affected adversely. 468 Network overhead, such as, for instance, the amount of signaling 469 necessary to minimize handover latency, is also a metric that should 470 be considered when studying ICN mobility management. In the past, 471 network overhead has been seen as one of the main factors hindering 472 the deployment of various mobility solutions. In IP-based networks, 473 network overhead includes, but is not limited to, tunneling overhead, 474 in-band control protocol overhead, mobile terminal and network 475 equipment state maintenance and update. ICN designs and evaluation 476 studies should clearly identify the network overhead associated with 477 handling mobility. Alongside network overhead, deployment complexity 478 should also be studied. 480 To summarize, mobile networking scenarios should aim to provide 481 service continuity for those applications that require it, decrease 482 complexity and control signaling for the network infrastructure, as 483 well as increase wireless capacity utilization by taking advantage of 484 the broadcast nature of the medium. Beyond this, mobile networking 485 scenarios should form a cross-scenario platform that can highlight 486 how other scenarios can still maintain their respective performance 487 metrics during periods of high mobility. 489 2.4. Infrastructure Sharing 491 A key idea in ICN is that the network should secure information 492 objects per se, not the communications channel that they are 493 delivered over. This means that hosts attached to an information- 494 centric network can share resources on an unprecedented scale, 495 especially when compared to what is possible in an IP network. All 496 devices with network access and storage capacity can contribute their 497 resources increasing the value of an information-centric network, 498 although compensation schemes motivating users to contribute 499 resources remain a research challenge primarily from a business 500 perspective. 502 For example, Jacobson et al. [CBIS] argue that in ICN the "where and 503 how" of obtaining information are new degrees of freedom. They 504 illustrate this with a scenario involving a photo sharing application 505 which takes advantage of whichever access network connectivity is 506 available at the moment (WLAN, Bluetooth, and even SMS) without 507 requiring a centralized infrastructure to synchronize between 508 numerous devices. It is important to highlight that since the focus 509 of communication changes, keep-alives in this scenario are simply 510 unnecessary, as devices participating in the testbed network 511 contribute resources in order to maintain user content consistency, 512 not link state information as is the case in the host-centric 513 paradigm. This means that the notion of "infrastructure" may be 514 completely different in the future. 516 Muscariello et al. [SHARE], for instance, presented early work on an 517 analytical framework that attempts to capture the storage/bandwidth 518 tradeoffs that ICN enables and can be used as foundation for a 519 network planning tool. In addition, Chai et al. [CL4M] explore the 520 benefits of ubiquitous caching throughout an information-centric 521 network and argue that "caching less can actually achieve more." 522 These papers also sit alongside a variety of other studies that look 523 at various scenarios such as caching HTTP-like traffic [CCNCT] and 524 BitTorrent-like traffic [BTCACHE]. We observe that much more work is 525 needed in order to understand how to make optimal use of all 526 resources available in an information-centric network. In real-world 527 deployments, policy and commercial considerations are also likely to 528 affect the use of particular resources and more work is expected in 529 this direction as well. 531 In conclusion, scenarios in this category, would cover the 532 communication-computation-storage tradeoffs that an ICN deployment 533 must consider. This would exercise features relating to network 534 planning, perhaps capitalizing on user-provided resources, as well as 535 operational and economical aspects of ICN and contrast them with 536 other approaches. An obvious baseline to compare against in this 537 regard is existing federations of IP-based Content Distribution 538 Networks (CDNs), such as the ones discussed in the IETF CDNI WG. 540 2.5. Content Dissemination 542 Content dissemination has attracted more attention than other aspects 543 of ICN. Scenarios in this category abound in the literature, 544 including stored and streaming A/V distribution, file distribution, 545 mirroring and bulk transfers, versioned content services (cf. 546 Subversion-type revision control), as well as traffic aggregation. 548 Decentralized content dissemination with on-the-fly aggregation of 549 information sources was envisaged in [N-Scen], where information 550 objects can be dynamically assembled based on hierarchically 551 structured subcomponents. For example, a video stream could be 552 associated with different audio streams and subtitle sets, which can 553 all be obtained from different sources. Using the topology depicted 554 in Fig. 1 as an example, an application at C1 may end up obtaining, 555 say, the video content from I1, but the user-selected subtitles from 556 Px. Semantics and content negotiation, on behalf of the user, were 557 also considered, e.g., for the case of popular tunes which may be 558 available in different encoding formats. Effectively this scenario 559 has the information consumer issuing independent requests for content 560 based on information identifiers, and stitching the pieces together 561 irrespective of "where" or "how" they were obtained. 563 A case in point for content dissemination are vehicular ad-hoc 564 networks (VANETs), as an ICN approach may address their needs for 565 information dissemination between vehicles better than today's 566 solutions, as discussed in the following section. The critical part 567 of information dissemination in a VANET scenario revolves around 568 "where" and "when". For instance, one may be interested in traffic 569 conditions 2 km ahead while having no interest in similar information 570 about the area around the path origin. VANET scenarios may provide 571 fertile ground for showcasing the ICN advantage with respect to 572 content dissemination especially when compared with current host- 573 centric approaches. That said, information integrity and filtering 574 are challenges that must be addressed. As mentioned above, content 575 dissemination scenarios in VANETs have a particular affinity to the 576 mobility scenarios discussed in section 2.3. 578 Content dissemination scenarios, in general, have a large overlap 579 with those described in the previous sections and are explored in 580 several papers, such as [DONA] [PSI] [PSIMob] [NetInf] [CCN] [CBIS] 581 [CCR], just to name a few. In addition, Chai et al. [CURLING] 582 present a hop-by-hop hierarchical content resolution approach, which 583 employs receiver-driven multicast over multiple domains, advocating 584 another content dissemination approach. Yet, largely, work in this 585 area did not address the issue of access authorization in detail. 586 Often, the distributed content is mostly assumed to be freely 587 accessible by any consumer. Distribution of paid-for or otherwise 588 restricted content on a public ICN network requires more attention in 589 the future. Fotiou et al. [ACDICN] consider a scheme to this effect 590 but it still requires access to an authorization server to verify the 591 user's status after the (encrypted) content has been obtained. This 592 may effectively negate the advantage of obtaining the content from 593 any node, especially in a disruption-prone or mobile network. 595 In summary, scenarios in this category aim to exercise primarily 596 scalability, cost and performance attributes of content 597 dissemination. Particularly, they should highlight the ability of an 598 ICN to scale to billions of objects, while not exceeding the cost of 599 existing content dissemination solutions (i.e., CDNs) and, ideally, 600 increasing performance. These should be shown in a holistic manner, 601 improving content dissemination for both information consumers and 602 publishers of all sizes. We expect that in particular for content 603 dissemination both extreme as well as typical scenarios can be 604 specified drawing data from current CDN deployments. 606 2.6. Vehicular Networking 608 Users "on wheels" are interested in road safety, traffic efficiency, 609 and infotainment applications that can be supported through vehicle- 610 to-vehicle (V2V) and vehicle-to-infrastructure (V2I) wireless 611 communications. These applications exhibit unique features in terms 612 of traffic generation patterns, delivery requirements, spatial and 613 temporal scope, which pose great challenges to traditional networking 614 solutions. VANETs, by their nature, are characterized by challenges 615 such as fast-changing topology, intermittent connectivity, high node 616 mobility, but also by the opportunity to combine information from 617 different sources as each vehicle does not care about "who" delivers 618 the named data objects. 620 ICN is an attractive candidate solution for vehicular networking, as 621 it has several advantages. First, ICN fits well to the nature of 622 typical vehicular applications that are geography- and time-dependent 623 (e.g., road traveler information, accident warning, point-of-interest 624 advertisements) and usually target vehicles in a given area, 625 regardless of their identity or IP address. These applications are 626 likely to benefit from in-network and decentralized data caching and 627 replication mechanisms. Second, content caching is particularly 628 beneficial for intermittent on-the-road connectivity and can speed up 629 data retrieval through content replication in several nodes. Caching 630 can usually be implemented at relatively low cost in vehicles as the 631 energy demands of the ICN device are likely to be a negligible 632 fraction of the total vehicle energy consumption, thus allowing for 633 sophisticated processing, continuous communication and adequate 634 storage in the vehicle. Finally, ICN natively supports asynchronous 635 data exchange between end-nodes. By using (and redistributing) 636 cached named information objects, a mobile node can serve as a link 637 between disconnected areas. In short, ICN can enable communication 638 even under intermittent network connectivity, which is typical of 639 vehicular environments with sparse roadside infrastructure and fast 640 moving nodes. 642 The advantages of ICN in vehicular networks were preliminarily 643 discussed in [EWC] and [DMND], and additionally investigated in 644 [DNV2V] [RTIND] [CCNHV] [CCDIVN] [CCNVANET] [CRoWN]. For example, 645 Bai and Krishnamachari [EWC] take advantage of the localized and 646 dynamic nature of a VANET to explore how a road congestion 647 notification application can be implemented. Wang et al. [DMND] 648 consider data collection where Road-Side Units (RSUs) collect 649 information from vehicles by broadcasting NDN-like INTEREST packets. 650 The proposed architecture is evaluated using simulation in a grid 651 topology and is compared against a host-centric alternative based on 652 Mobile IP. See Fig. 3 for an indicative example of an urban VANET 653 topology. Their results indicate high efficiency for ICN even at high 654 speeds. That said, the authors point out that as this work is a 655 preliminary exploration of ICN in vehicular environments, many issues 656 remain to be evaluated, such as system scalability to large numbers 657 of vehicles and the impact of vehicles forwarding Interests and 658 relaying data for other vehicles. 660 + - - _- - -_- - - -_- - _- - - + 661 | /_\ /_\ /_\ /_\ | 662 | o o o o o o o o | 663 | +-------+ +-------+ _ | 664 | | | | |/_\ | 665 | _ | | | |o o | 666 | /_\| | | | | 667 | o o+--_----+\===/+--_----+ | 668 | /_\ |RSU| /_\ | 669 | o o /===\ o o | 670 | +-------+ +-------+ _ | 671 | | | | |/_\ | 672 | _ | | | |o o | 673 |/_\ | | | | | 674 |o o +_-----_+ +_-----_+ | 675 | /_\ /_\ /_\ /_\ | 676 +_ _ o_o_ _o_o_ _ _o_o_ _o_o_ _ + 678 Figure 3. Urban grid VANET topology. 680 As mentioned in the previous section, due to the short communication 681 duration between a vehicle and the RSU, and the typically short time 682 of sustained connectivity between vehicles, VANETs may be a good 683 showcase for the ICN advantages with respect to content 684 dissemination. Wang et al. [DNV2V], for instance, analyze the 685 advantages of hierarchical naming for vehicular traffic information 686 dissemination. Arnould et al. [CCNHV] apply ICN principles to safety 687 information dissemination between vehicles with multiple radio 688 interfaces. In [CCDIVN], TalebiFard and Leung use network coding 689 techniques to improve content dissemination over multiple ICN paths. 690 Amadeo et al. [CCNVANET][[CRoWN] propose an application-independent 691 ICN framework for content retrieval and distribution where the role 692 of provider can be played equivalently by both vehicles and RSUs. 693 ICN forwarding is extended through path-state information carried in 694 Interest and Data packets, stored in a new data structure kept by 695 vehicular nodes, and exploited also to cope with node mobility. 697 Typical scenarios for testing content distribution in VANETs may be 698 highways with vehicles moving in straight lines, with or without RSUs 699 along the road, as shown in Fig. 4. With a NDN approach in mind, for 700 example, RSUs may send Interests to collect data from vehicles 701 [DMND], or vehicles may send Interests to collect data from other 702 peers [RTIND] or from RSUs [CCNVANET]. Fig. 2 applies to content 703 dissemination in VANET scenarios as well, where C0 represents a 704 vehicle which can obtain named information objects via multiple 705 wireless peers and/or RSUs (I2 and I3 in the figure). Grid 706 topologies such as the one illustrated in Fig. 3 should be considered 707 in urban scenarios with RSUs at the crossroads or co-located with 708 traffic lights as in [CRoWN]. 710 \___/ \___/ 711 |RSU| |RSU| 712 ================================ 713 _ _ _ _ 714 /_\ /_\ /_\ /_\ 715 _ _ o_o_ _o_o_ _o_o_ _o_o_ _ _ _ 716 _ _ _ _ 717 /_\ /_\ /_\ /_\ 718 o o o o o o o o 719 ================================ 721 Figure 4. Highway VANET topology. 723 To summarize, VANET scenarios aim to exercise ICN deployment from 724 various perspectives, including scalability, caching, transport, and 725 mobility issues. There is a need for further investigation in (i) 726 challenging scenarios (e.g., disconnected segments); (ii) scenarios 727 involving both consumer and provider mobility; (iii) smart caching 728 techniques which take into consideration node mobility patterns, 729 spatial and temporal relevance, content popularity, and social 730 relationships between users/vehicles; (iv) identification of new 731 applications (beyond data dissemination and traffic monitoring) that 732 could benefit from the adoption of an ICN paradigm in vehicular 733 networks (e.g., mobile cloud, social networking). 735 2.7. Delay- and Disruption-Tolerance 737 Delay- and Disruption-Tolerant Networking (DTN) originated as a means 738 to extend the Internet to interplanetary communications [DTN]. 739 However, it was subsequently found to be an appropriate architecture 740 for many terrestrial situations as well. Typically, this was where 741 delays were greater than protocols such as TCP could handle, and 742 where disruptions to communications were the norm rather than 743 occasional annoyances, e.g. where an end-to-end path does not 744 necessarily exist when communication is initiated. DTN has now been 745 applied to many situations, including opportunistic content sharing, 746 handling infrastructural issues during emergency situations (e.g., 747 earthquakes) and providing connectivity to remote rural areas without 748 existing Internet provision and little or no communications or power 749 infrastructure. 751 The DTN architecture [RFC4838] is based on a "store, carry and 752 forward" paradigm that has been applied extensively to situations 753 where data is carried between network nodes by a "data mule", which 754 carries bundles of data stored in some convenient storage medium 755 (e.g., a USB memory stick). With the advent of sensor and peer-to- 756 peer (P2P) networks between mobile nodes, DTN is becoming a more 757 commonplace type of networking than originally envisioned. Since ICN 758 also does not rely on the familiar end-to-end communications 759 paradigm, there are, thus, clear synergies [DTNICN]. It could 760 therefore be argued that many of the key principles embodied within 761 DTN also exist in ICN, as we explain next. 763 First, both approaches rely on in-network storage. In the case of 764 DTN, bundles are stored temporarily on devices on a hop-by-hop basis. 765 In the case of ICN, information objects are also cached on devices 766 in a similar fashion. As such, both paradigms must provision storage 767 within the network. 769 Second, both approaches espouse late binding of names to locations 770 due to the potentially large interval between request and response 771 generation. In the case of DTN, it is often impossible to predict the 772 exact location (in a disconnected topology) where a node will be 773 found. Similarly, in the case of ICN, it is also often impossible to 774 predict where an information object might be found. As such, the 775 binding of a request/bundle to a destination (or routing locator) 776 must be performed as late as possible. 778 Finally, both approaches treat data as a long-lived component that 779 can exist in the network for extended periods of time. In the case of 780 DTN, bundles are carried by nodes until appropriate next hops are 781 discovered. In the case of ICN, information objects are typically 782 cached until storage is exhausted. As such, both paradigms require a 783 direct shift in the way applications interact with the network. 785 Through these similarities, it becomes possible to identify many DTN 786 principles that are already in existence within ICN architectures. 787 For example, ICN nodes will often retain information objects locally, 788 making them accessible later on, much as DTN bundles are handled. 789 Consequently, these synergies suggest strong potential for marrying 790 the two technologies. This, for instance, could include building new 791 integrated Information-Centric Delay Tolerant Network (ICDTN) 792 protocols or, alternatively, building ICN schemes over existing DTN 793 protocols (and vice versa). 795 The above similarities suggest that integration of the two principles 796 would be certainly feasible. Beyond this, there are also a number of 797 direct benefits identifiable. Through caching and replication, ICN 798 offers strong information resilience, whilst, through store-and- 799 forward, DTN offers strong connectivity resilience. As such, both 800 architectures could benefit greatly from each other. Initial steps 801 have already been taken in the DTN community to integrate ICN 802 principles, e.g., the Bundle Protocol Query Block [BPQ] has been 803 proposed for the DTN Bundle Protocol [RFC5050]. Whilst, similarly, 804 initial steps have also been taken in the ICN community, such as 805 [SLINKY]. In fact, the SAIL project has developed a prototype 806 implementation of NetInf running over the DTN Bundle Protocol. 808 Of course, in many circumstances, information-centricity is not 809 appropriate for use in delay- and disruption-tolerant environments. 810 This is particularly the case when information is not the key 811 communications atom transmitted. Further, situations where a single 812 sink is always used for receiving information may not warrant the 813 identification and routing of independent information objects. 814 However, there are a number of key scenarios where clear benefits 815 could be gained by introducing information-centric principles into 816 DTNs, two of which we describe later in this section. 818 For the purpose of evaluating the use of ICNs in a DTN setting, two 819 key scenarios are identified in this document (note the rest of this 820 section uses the term ICDTN). These are both prominent use cases 821 that are currently active in both the ICN and DTN communities. The 822 first is opportunistic content sharing, whilst the second is the use 823 of ad hoc networks during disaster recovery (e.g., earthquakes). We 824 discuss both types of scenarios in the context of a simulation-based 825 evaluation: due to the scale and mobility of DTN-like setups, this is 826 the primary method of evaluation used. Within the DTN community, the 827 majority of simulations are performed using the Opportunistic Network 828 Environment (ONE) simulator [ONE], which is referred to in this 829 document. Before exploring the two scenarios, the key shared 830 components of their simulation are discussed. This is separated into 831 the two primary inputs that are required: the environment and the 832 workload. 834 In both types of scenarios the environment can be abstractly modeled 835 by a time series of active connections between device pairs. Unlike 836 other scenarios in this document, an ICDTN scenario therefore does 837 not depend on (relatively) static topologies but, rather, a set of 838 time-varying disconnected topologies. In opportunistic networks, 839 these topologies are actually products of the mobility of users. For 840 example, if two users walk past each other, an opportunistic link can 841 be created. There are two methods used to generate these mobility 842 patterns and, in turn, the time series of topologies. The first is 843 synthetic, whereby a (mathematical) model of user behavior is created 844 in an agent-based fashion, e.g., random waypoint, Gauss-Markov. The 845 second is trace-driven, whereby the mobility of real users is 846 recorded and used. In both cases, the output is a sequence of time- 847 stamped "contacts", i.e. periods of time in which two devices can 848 communicate. An important factor missing from typical mobility 849 traces, however, is the capacity of these contacts: how much data can 850 be transferred? In both approaches to modeling mobility, links are 851 usually configured as Bluetooth or WiFi (ONE easily allows this, 852 although lower layer considerations are ignored, e.g., interference). 853 This is motivated by the predominance of these technologies on 854 mobile phones. 856 The workload in an ICDTN is modeled much like the workload within the 857 other scenarios. It involves object creation/placement and object 858 retrieval. Object creation/placement can either be done statically 859 at the beginning of the simulations or, alternatively, dynamically 860 based on a model of user behavior. In both cases, the latter is 861 focused on as it models far better the characteristics of the 862 scenarios. 864 Once the environment and workload has been configured, the next step 865 is to decide the key metrics for the study. Unlike traditional 866 networking, the quality of service expectation is typically far lower 867 in an ICDTN, thereby moving away from metrics such as throughput. At 868 a high-level, it is of clear interest to evaluate different ICN 869 approaches with respect to both their delay- and disruption- 870 tolerance, i.e., how effective is the approach when used in an 871 environment subject to significant delay and/or disruption; and to 872 their active support for operations in a DTN environment. 874 The two most prominent metrics considered in a host-centric DTN are 875 delivery probability and delivery delay. The former relates to the 876 probability by which a sent message will be received within a certain 877 delay bound, whilst the latter captures the average length of time it 878 takes for nodes to receive the message. These metrics are similarly 879 important in an ICDTN, although they are slightly different due to 880 the request-response nature of ICN. Therefore, the two most prominent 881 evaluative metrics are satisfaction probability and satisfaction 882 delay. The former refers to the probability by which an information 883 request (e.g., Interest) will be satisfied (i.e., how often a Data 884 response will be received). Satisfaction delay refers to the length 885 of time it takes an information request to be satisfied. 887 Note that the key difference between the host-centric and 888 information-centric metrics is the need for a round-trip rather than 889 a one-way communication. Beyond this, depending on the focus of the 890 work, other elements that may be investigated include name 891 resolution, routing and forwarding in disconnected parts of the 892 network; support for unidirectional links; number of round trips 893 needed to complete a data transfer; long-term content availability 894 (or resilience); efficiency in the face of disruption, and so on. It 895 is also important to weigh these performance metrics against the 896 necessary overheads. In the case of an ICDTN, this is generally 897 measured by the number of message replicas required to access 898 content. Note that routing in a DTN is often replication-based, 899 which leads to many copies of the same message. 901 2.7.1. Opportunistic Content Sharing 903 The first key baseline scenario in this context is opportunistic 904 content sharing. This occurs when mobile nodes create opportunistic 905 links between each other to share content of interest. For example, 906 people riding on an underground train can pass news items between 907 their mobile phones. Equally, content generated on the phones (e.g., 908 tweets [TWIMIGHT]) could be stored for later forwarding (or even 909 forwarded amongst interested passengers on the train). Such 910 scenarios, clearly, must be based around either the altruistic or 911 incentivized interaction amongst users. The latter is a particularly 912 active area of research. These networks are often termed pocket- 913 switched networks, as they are independently formed between the user 914 devices. Here, the evaluative scenario of ICDTN microblogging is 915 proposed. As previously discussed, the construction of such an 916 evaluative scenario requires a formalization of its environment and 917 workload. Fortunately, there exist a number of datasets that offer 918 exactly this information required for microblogging. 920 In terms of the environment (i.e., mobility patterns), the Haggle 921 project produced contact traces based on conference attendees using 922 Bluetooth. These traces are best targeted at application scenarios 923 in which a small group of (50-100) people are in a relatively 924 confined space. In contrast, larger scale traces are also available, 925 most notably MIT's Reality Mining project. These are better suited 926 for cases where longer-term movement patterns are of interest. 928 The second input, workload, relates to the creation and consumption 929 of microblogs (e.g. tweets). This can be effectively captured 930 because subscriptions conveniently formalize who consumes what. For 931 bespoke purposes, specific data can be directly collected from 932 Twitter for trace-driven simulations. Several Twitter datasets are 933 already available to the community containing a variety of data, 934 ranging from Tweets to follower graphs. See 935 http://www.tweetarchivist.com, http://twapperkeeper.com, 936 http://www.infochimps.com/collections/twitter-census, and 937 http://socialcomputing.asu.edu/datasets/Twitter. These datasets can 938 therefore be used to extract information production, placement and 939 consumption. 941 2.7.2. Emergency Support and Disaster Recovery 943 The second key baseline scenario in this context relates to the use 944 of ICDTNs in emergency scenarios. In these situations it is typical 945 for infrastructure to be damaged or destroyed, leading to the 946 collapse of traditional forms of communications (e.g., cellular 947 telephone networks). This has been seen in the recent North Indian 948 flooding, as well as the 2011 Tohoku earthquake and tsunami. Power 949 problems often exacerbate the issue, with communication failures 950 lasting for days. Therefore, in order to address this, DTNs have 951 been used due to their high levels of resilience and independence 952 from fixed infrastructure. The most prominent use of DTNs in 953 disaster areas would be the dissemination of information, e.g., 954 warnings and evacuation maps. Unlike the previous scenario, it can 955 be assumed that certain users (e.g., emergency responders) are highly 956 altruistic. However, it is likely many other users (e.g., endangered 957 civilians) might become far more conservative in how they use their 958 devices for battery conserving purposes. Here, we focus on the 959 dissemination of standard broadcast information that should be 960 received by all parties; this is something generally led by emergency 961 responders. 963 For the environmental setup, there are no commonly used mobility 964 traces for disaster zones, unlike in the previous scenario. This is 965 clearly due to the difficultly (near impossibility) of acquiring them 966 in a real setting. That said, various synthetic models are 967 available. The Post Disaster Mobility Model [MODEL1] models 968 civilians and emergency responders after a disaster has occurred, 969 with people attempting to reach evacuation points (this has also been 970 implemented in ONE). Aschenbruck et al. [MODEL2] focus on emergency 971 responders, featuring the removal of nodes from the disaster zone, as 972 well as things like obstacles (e.g., collapsed buildings). Cabrero 973 et al. [MODEL3] also look at emergency responders, but focus on 974 patterns associated with common procedures. For example, command and 975 control centers are typically set up with emergency responders 976 periodically returning. Clearly, the mobility of emergency 977 responders is particularly important in this setting because they 978 usually are the ones who will "carry" information into the disaster 979 zone. It is recommended that one of these emergency-specific models 980 are used during any evaluations, due to the inaccuracy of alternate 981 models used for "normal" behavior. 983 The workload input in this evaluative scenario is far simpler than 984 for the previous scenario. In emergency cases, the dissemination of 985 individual pieces of information to all parties is the norm. This is 986 often embodied using things like the Common Alert Protocol (CAP), 987 which is an XML standard for describing warning message. It is 988 currently used by various systems, including the Integrated Public 989 Alert & Warning System and Google Crisis Response. As such, small 990 objects (e.g., 512KB to 2MB) are usually generated containing text 991 and images; note that the ONE simulator offers utilities to easily 992 generate these. These messages are also always generated by central 993 authorities, therefore making the placement problem easier (they 994 would be centrally generated and given to emergency responders to 995 disseminate as they pass through the disaster zone). The key 996 variable is therefore the generation rate, which is synonymous with 997 the rate that microblogs are written in the previous scenario. This 998 will largely be based on the type of disaster occurring, however, 999 hourly updates would be an appropriate configuration. Higher rates 1000 can also be tested, based on the rate at which situations change 1001 (lands slides, for example, can exhibit highly dynamic properties). 1003 To summarize, this section has highlighted the applicability of ICN 1004 principles to existing DTN scenarios. Two evaluative setups have been 1005 described in detail, namely, mobile opportunistic content sharing 1006 (microblogging) and emergency information dissemination. 1008 2.8. Internet of Things 1010 Advances in electronics miniaturization combined with low-power 1011 wireless access technologies (e.g., ZigBee, NFC, Bluetooth and 1012 others) have enabled the coupling of interconnected digital services 1013 with everyday objects. As devices with sensors and actuators connect 1014 into the network, they become "smart objects" and form the foundation 1015 for the so-called Internet of Things (IoT). IoT is expected to 1016 increase significantly the amount of content carried by the network 1017 due to machine-to-machine (M2M) communication as well as novel user 1018 interaction possibilities. 1020 Yet, the full potential of IoT does not lie in simple remote access 1021 to smart object data. Instead, it is the intersection of Internet 1022 services with the physical world that will bring about the most 1023 dramatic changes. Burke [IoTEx], for instance, makes a very good 1024 case for creating everyday experiences using interconnected things 1025 through participatory sensing applications. In this case, inherent 1026 ICN capabilities for data discovery, caching, and trusted 1027 communication are leveraged to obtain sensor information and enable 1028 content exchange between mobile users, repositories, and 1029 applications. 1031 Kutscher and Farrell [IWMT] discuss the benefits that ICN can provide 1032 in these environments in terms of naming, caching, and optimized 1033 transport. The Named Information URI scheme (ni) [RFC6920], for 1034 instance, could be used for globally unique smart object 1035 identification, although an actual implementation report is not 1036 currently available. Access to information generated by smart 1037 objects can be of varied nature and often vital for the correct 1038 operation of large systems. As such, supporting timestamping, 1039 security, scalability, and flexibility need to be taken into account. 1041 Ghodsi et al. [NCOA] examine hierarchical and self-certifying naming 1042 schemes and point out that ensuring reliable and secure content 1043 naming and retrieval may pose stringent requirements (e.g., the 1044 necessity for employing PKI), which can be too demanding for low- 1045 powered nodes, such as sensors. That said, earlier work by Heidemann 1046 et al. [nWSN] shows that, for dense sensor network deployments, 1047 disassociating sensor naming from network topology and using named 1048 content at the lowest level of communication in combination with in- 1049 network processing of sensor data is feasible in practice and can be 1050 more efficient than employing a host-centric binding between node 1051 locator and the content existing therein. 1053 Burke et al. [NDNl] describe the implementation of a lighting control 1054 building automation system where the security, naming and device 1055 discovery NDN mechanisms are leveraged to provide configuration, 1056 installation and management of residential and industrial lighting 1057 control systems. The goal is an inherently resilient system, where 1058 even smartphones can be used for control. Naming reflects fixtures 1059 with evolved identification and node reaching capabilities thus 1060 simplifying bootstrapping, discovery, and user interaction with 1061 nodes. The authors report that this ICN-based system requires less 1062 maintenance and troubleshooting than typical IP-based alternatives. 1064 Biswas et al. [CIBUS] visualize ICN as a contextualized information- 1065 centric bus (CIBUS) over which diverse sets of service producers and 1066 consumers co-exist with different requirements. ICN is leveraged to 1067 unify different platforms to serve consumer-producer interaction in 1068 both infrastructure and ad hoc settings. Ravindran et al. [Homenet], 1069 show the application of this idea in the context of a home network, 1070 where consumers (residents) require policy-driven interactions with 1071 diverse services such as climate control, surveillance systems, and 1072 entertainment systems. Name-based protocols are developed to enable 1073 zero-configuration node and service discovery, contextual service 1074 publishing and subscription, policy-based routing and forwarding with 1075 name-based firewall, and hoc device-to-device communication. 1077 IoT exposes ICN concepts to a stringent set of requirements which are 1078 exacerbated by the amount of nodes, as well as by the type and volume 1079 of information that must be handled. A way to address this is 1080 proposed in [IoTScope], which tackles the problem of mapping named 1081 information to an object, diverting from the currently typical 1082 centralized discovery of services and leveraging the intrinsic ICN 1083 scalability capabilities for naming. It extends the base [PURSUIT] 1084 design with hierarchically-based scopes, facilitating lookup, access, 1085 and modifications of only the part of the object information that the 1086 user is interested in. Another important aspect is how to 1087 efficiently address resolution and location of the information 1088 objects, particularly when large numbers of nodes are connected, as 1089 in IoT deployments. In [ICN-DHT], Katsaros et al. propose a 1090 Distributed Hash Table (DHT) which is compared with DONA [DONA]. 1091 Their results show how topological routing information has a positive 1092 impact on resolution, at the expense of memory and processing 1093 overhead. 1095 The use of ICN mechanisms is IoT scenarios faces the most dynamic and 1096 heterogeneous type of challenges, when taking into consideration the 1097 requirements and objectives of such integration. The disparity in 1098 technologies (not only in access technologies, but also in terms of 1099 end-node diversity such as sensors, actuators and their 1100 characteristics) as well as in the information that is generated and 1101 consumed in such scenarios, will undoubtedly bring about many of the 1102 considerations presented in the previous sections. For instance, IoT 1103 shares similarities with the constraints and requirements applicable 1104 to vehicular networking. Here, a central problem is the deployment 1105 of mechanisms that can use opportunistic connectivity in unreliable 1106 networking environments (similarly to the vehicular networking and 1107 DTN scenarios). 1109 However, one important concern in IoT scenarios, also motivated by 1110 this strongly heterogeneous environment, is how content dissemination 1111 will be affected by the different semantics of the disparate 1112 information and content being shared. In fact, this is already a 1113 difficult problem that goes beyond the scope of ICN [SEMANT]. With 1114 the ability of the network nodes to cache forwarded information to 1115 improve future requests, a challenge arises regarding whether the ICN 1116 fabric should be involved in any kind of procedure (e.g., tagging) 1117 that facilitates the relationship or the interpretation of the 1118 different sources of information. 1120 Another issue lies with the need for having energy-efficiency 1121 mechanisms related to the networking capabilities of IoT 1122 infrastructures. Often, the devices in IoT deployments have limited 1123 battery capabilities, and thus need low power consumption schemes 1124 working at multiple levels. In principle, energy efficiency gains 1125 should be observed from the inherent in-network caching capability. 1126 However, this might not be the most usual case in IoT scenarios, 1127 where the information (particularly from sensors, or controlling 1128 actuators) is more akin to real-time traffic, thus reducing the scale 1129 of potential savings due to ubiquitous in-network caching. 1131 ICN approaches, therefore, should be evaluated with respect to their 1132 capacity to handle the content produced and consumed by extremely 1133 large numbers of diverse devices. IoT scenarios aim to exercise ICN 1134 deployment from different aspects, including ICN node design 1135 requirements, efficient naming, transport, and caching of time- 1136 restricted data. Scalability is particularly important in this 1137 regard as the successful deployment of IoT principles could expand 1138 both device and content numbers dramatically beyond all current 1139 expectations. 1141 2.9. Smart City 1143 The rapid increase in urbanization sets the stage for the most 1144 compelling and challenging environments for networking. By 2050 the 1145 global population will reach nine billion people, 75% of which will 1146 dwell in urban areas. In order to cope with this influx, many cities 1147 around the world have started their transformation toward the Smart 1148 City vision. Smart cities will be based on the following innovation 1149 axes: smart mobility, smart environment, smart people, smart living, 1150 and smart governance. In development terms, the core goal of a smart 1151 city is to become a business-competitive and attractive environment, 1152 while serving citizen well being [CPG]. 1154 In a smart city, ICT plays a leading role and acts as the glue 1155 bringing together all actors, services, resources (and their 1156 interrelationships), that the urban environment is willing to host 1157 and provide [MVM]. ICN appears particularly suitable for these 1158 scenarios. Domains of interest include intelligent transportation 1159 systems, energy networks, health care, A/V communications, peer-to- 1160 peer and collaborative platforms for citizens, social inclusion, 1161 active participation in public life, e-government, safety and 1162 security, sensor networks. Clearly, this scenario has close ties to 1163 the vision of IoT, discussed in the previous section, as well as to 1164 vehicular networking. 1166 Nevertheless, the road to build a real information-centric digital 1167 ecosystem will be long and more coordinated effort is required to 1168 drive innovation in this domain. We argue that smart city needs and 1169 ICN technologies can trigger a virtuous innovation cycle toward 1170 future ICT platforms. Recent concrete ICN-based contributions have 1171 been formulated for home energy management [iHEMS], geo-localized 1172 services [ACC], smart city services [IB], and traffic information 1173 dissemination in vehicular scenarios [RTIND]. Some of the proposed 1174 ICN-based solutions are implemented in real testbeds while others are 1175 evaluated through simulation. 1177 Zhang et al. [iHEMS] propose a secure publish-subscribe architecture 1178 for handling the communication requirements of Home Energy Management 1179 Systems (HEMS). The objective is to safely and effectively collect 1180 measurement and status information from household elements, aggregate 1181 and analyze the data, and ultimately enable intelligent control 1182 decisions for actuation. They consider a simple experimental testbed 1183 for their proof-of-concept evaluation, exploiting open source code 1184 for the ICN implementation, and emulating some node functionality in 1185 order to facilitate system operation. 1187 A different scenario is considered in [ACC], where DHTs are employed 1188 for distributed, scalable, and geographically-aware service lookup in 1189 a smart city. Also in this case, the ICN application is validated by 1190 considering a small-scale testbed: a small number of nodes are 1191 realized with simple embedded PCs or specific hardware boards (e.g., 1192 for some sensor nodes); other nodes realizing the network connecting 1193 the principal actors of the tests are emulated with workstations. 1194 The proposal in [IB] draws from a smart city scenario (mainly 1195 oriented towards waste collection management) comprising sensors and 1196 moving vehicles, as well as a cloud computing system that supports 1197 data retrieval and storage operations. The main aspects of this 1198 proposal are analyzed via simulation using open source code which is 1199 publicly available. Some software applications are designed on real 1200 systems (e.g., PCs and smartphones). 1202 With respect to evaluating ICN approaches in smart city scenarios, it 1203 is necessary to consider generic metrics useful to track and monitor 1204 progress on services results and also for comparing localities 1205 between themselves and learn from the best [ISODIS]. In particular, 1206 it is possible to select a specific set of Key Performance Indicators 1207 (KPIs) for a given project in order to evaluate its success. These 1208 KPIs may reflect the city's environmental and social goals, as well 1209 as its economic objectives, and they can be calculated at the global, 1210 regional, national, and local levels. Therefore, it is not possible 1211 to define a unique set of interesting metrics, but in the context of 1212 smart cities the KPIs should be characterized with respect to the 1213 developed set of services offered by using the ICN paradigm. 1215 To sum up, smart city scenarios aim to exercise several ICN aspects 1216 in an urban environment. In particular, they can be useful to (i) 1217 analyze the capacity of using ICN for managing extremely large data 1218 sets; (ii) study ICN performance in terms of scalability in 1219 distributed services; (iii) verify the feasibility of ICN in a very 1220 complex application like vehicular communication systems; and (iv) 1221 examine the possible drawbacks related to privacy and security issues 1222 in complex networked environments. 1224 3. Cross-scenario Considerations 1226 This section discusses considerations that span multiple scenarios. 1228 3.1. Multiply-connected Nodes and Economics 1230 The evolution of, in particular, wireless networking technologies has 1231 resulted in a convergence of the bandwidth and capabilities of 1232 various different types of network. Today a leading edge mobile 1233 telephone or tablet computer will typically be able to access a Wi-Fi 1234 access point, a 4G cellular network and the latest generation of 1235 Bluetooth local networking. Until recently a node would usually have 1236 a clear favorite network technology appropriate to any given 1237 environment. The choice would, for example, be primarily determined 1238 by the available bandwidth with cost as a secondary determinant. 1239 Furthermore, it is normally the case that a device only uses one of 1240 the technologies at a time for any particular application. 1242 It seems likely that this situation will change so that nodes are 1243 able to use all of the available technologies in parallel. This will 1244 be further encouraged by the development of new capabilities in 1245 cellular networks including Small Cell Networks (SCN) and 1246 Heterogeneous Networks (HetNet) [SCN] [HetNet]. Consequently, mobile 1247 devices will have similar choices to wired nodes attached to multiple 1248 service providers allowing "multi-homing" via the various different 1249 infrastructure networks as well as potential direct access to other 1250 mobile nodes via Bluetooth or a more capable form of ad hoc Wi-Fi. 1252 Infrastructure networks are generally under the control of separate 1253 economic entities that may have different policies about the 1254 information of an ICN deployed within their network caches. As ICN 1255 shifts the focus from nodes to information objects, the interaction 1256 between networks will likely evolve to capitalize on data location 1257 independence, efficient and scalable in-network named object 1258 availability and access via multiple paths. These interactions 1259 become critical in evaluating the technical and economic impact of 1260 ICN architectural choices, as noted in [ArgICN]. Beyond simply 1261 adding diversity in deployment options, these networks have the 1262 potential to alter the incentives among existing, and future, we may 1263 add, network players, as noted in [EconICN]. 1265 Moreover, such networks enable more numerous inter-network 1266 relationships where exchange of information may be conditioned on a 1267 set of multilateral policies. For example, shared SCNs are emerging 1268 as a cost-effective way to address coverage of complex environments 1269 such as sports stadiums, large office buildings, malls, etc. Such 1270 networks are likely to be a complex mix of different cellular and 1271 WLAN access technologies (such as HSPA, LTE, and Wi-Fi) as well as 1272 ownership models. It is reasonable to assume that access to content 1273 generated in such networks may depend on contextual information such 1274 as the subscription type, timing, and location of both the owner and 1275 requester of the content. The availability of such contextual 1276 information across diverse networks can lead to network 1277 inefficiencies unless data management can benefit from an 1278 information-centric approach. The "Event with Large Crowds" 1279 demonstrator created by the SAIL project investigated this kind of 1280 scenario; more details are available in [SAIL-B3]. 1282 Jacobson et al. [CCN] include interactions between networks in their 1283 overall system design, and mention both "an edge-driven, bottom-up 1284 incentive structure" and techniques based on evolutions of existing 1285 mechanisms both for ICN router discovery by the end-user and for 1286 interconnecting between autonomous systems (AS). For example, a BGP 1287 extension for domain-level content prefix advertisement can be used 1288 to enable efficient interconnection between AS's. Liu et al. [MLDHT] 1289 proposed to address the "suffix-hole" issue found in prefix-based 1290 name aggregation through the use of a combination of Bloom-filter 1291 based aggregation and multi-level DHT. 1293 Name aggregation has been discussed for a flat naming design, for 1294 example, in [NCOA], in which the authors note that based on 1295 estimations in [DONA] flat naming may not require aggregation. This 1296 is a point that calls for further study. Scenarios evaluating name 1297 aggregation, or lack thereof, should take into account the amount of 1298 state (e.g. size of routing tables) maintained in edge routers as 1299 well as network efficiency (e.g. amount of traffic generated). 1301 +---------------+ 1302 +---------->| Popular Video | 1303 | +---------------+ 1304 | ^ ^ 1305 | | | 1306 | +-+-+ $0/MB +-+-+ 1307 | | A +-------+ B | 1308 | ++--+ +-+-+ 1309 | | ^ ^ | 1310 | $8/MB | | | | $10/MB 1311 | v | | v 1312 +-+-+ $0/MB +--+---------+--+ 1313 | D +---------+ C | 1314 +---+ +---------------+ 1316 Figure 5. Relationships and transit costs between networks A to D. 1318 DiBenedetto et al. [RP-NDN] study policy knobs made available by NDN 1319 to network operators. New policies, which are not feasible in the 1320 current Internet are described, including a "cache sharing peers" 1321 policy, where two peers have an incentive to share content cached in, 1322 but not originating from, their respective network. The simple 1323 example used in the investigation considers several networks and 1324 associated transit costs, as shown in Fig. 5. (based on Fig. 1 of 1325 [RP-NDN]). Agyapong and Sirbu [EconICN] further establish that ICN 1326 approaches should incorporate features that foster (new) business 1327 relationships. For example, publishers should be able to indicate 1328 their willingness to partake in the caching market, proper reporting 1329 should be enabled to avoid fraud, and content should be made 1330 cacheable as much as possible to increase cache hit ratios. 1332 Kutscher et al. [SAIL-B3] enable network interactions in the NetInf 1333 architecture using a name resolution service at domain edge routers, 1334 and a BGP-like routing system in the NetInf Default Free Zone. 1335 Business models and incentives are studied in [SAIL-A7] and [SAIL- 1336 A8], including scenarios where the access network provider (or a 1337 virtual CDN) guarantees QoS to end users using ICN. Fig. 6 1338 illustrates a typical scenario topology from this work which involves 1339 an interconnectivity provider. 1341 +----------+ +-----------------+ +------+ 1342 | Content | | Access Network/ | | End | 1343 | Provider +---->| ICN Provider +---->| User | 1344 +----------+ +-+-------------+-+ +------+ 1345 | | 1346 | | 1347 v v 1348 +-------------------+ +----------------+ +------+ 1349 | Interconnectivity | | Access Network | | End | 1350 | Provider +---->| Provider +------>| User | 1351 +-------------------+ +----------------+ +------+ 1353 Figure 6. Setup and operating costs of network entities. 1355 Jokela et al. [LIPSIN] propose a two-layer approach where additional 1356 rendezvous systems and topology formation functions are placed 1357 logically above multiple networks and enable advertising and routing 1358 content between them. Visala et al. [LANES] further describe an ICN 1359 architecture based on similar principles, which, notably, relies on a 1360 hierarchical DHT-based rendezvous interconnect. Rajahalme et al. 1361 [PSIRP1] describe a rendezvous system using both a BGP-like routing 1362 protocol at the edge and a DHT-based overlay at the core. Their 1363 evaluation model is centered around policy-compliant path stretch, 1364 latency introduced by overlay routing, caching efficacy, and overlay 1365 routing node load distribution. 1367 Rajahalme et al. [ICCP] point out that ICN architectural changes may 1368 conflict with the current tier-based peering model. For example, 1369 changes leading to shorter paths between ISPs are likely to meet 1370 resistance from Tier-1 ISPs. Rajahalme [IDMcast] shows how 1371 incentives can help shape the design of specific ICN aspects, and in 1372 [IDArch] he presents a modeling approach to exploit these incentives. 1373 This includes a network model which describes the relationship 1374 between Autonomous Systems based on data inferred from the current 1375 Internet, a traffic model taking into account business factors for 1376 each AS, and a routing model integrating the valley-free model and 1377 policy-compliance. A typical scenario topology is illustrated in 1378 Fig. 7, which is redrawn here based on Fig. 1 of [ICCP]. Note that 1379 it relates well with the topology illustrated in Fig. 1 of this 1380 document. 1382 o-----o 1383 +-----+ J +-----+ 1384 | o--*--o | 1385 | * | 1386 o--+--o * o--+--o 1387 | H +-----------+ I | 1388 o-*-*-o * o-*-*-o 1389 * * * * * 1390 ****** ******* * ******* ******* 1391 * * * * * 1392 o--*--o o*-*-*o o--*--o 1393 | E +--------+ F +---------+ G + 1394 o-*-*-o o-----o o-*-*-o 1395 * * * * 1396 ****** ******* ****** ****** 1397 * * * * 1398 o--*--o o--*--o o--*--o o--*--o 1399 | A | | B +-----------+ C | | D | 1400 o-----o o--+--o o--+--o o----+o 1401 | | ^^ | route 1402 data | data | data || | to 1403 | | || | data 1404 o---v--o o---v--o o++--v-o 1405 | User | | User | | Data | 1406 o------o o------o o------o 1408 Legend: 1409 ***** Transit link 1410 +---+ Peering link 1411 +---> Data delivery or route to data 1413 Figure 7. Tier-based set of interconnections between AS A to J. 1415 To sum up, the evaluation of ICN architectures across multiple 1416 network types should include a combination of technical and economic 1417 aspects, capturing their various interactions. These scenarios aim 1418 to illustrate scalability, efficiency and manageability, as well as 1419 traditional and novel network policies. Moreover, scenarios in this 1420 category should specifically address how different actors have proper 1421 incentives, not only in a pure ICN realm, but also during the 1422 migration phase towards this final state. 1424 3.2. Energy Efficiency 1426 ICN has prominent features which can be taken advantage of in order 1427 to significantly reduce the energy footprint of future communication 1428 networks. Of course, one can argue that specific ICN network elements 1429 may consume more energy than today's conventional network equipment 1430 due to the potentially higher energy demands for named-data 1431 processing en route. On balance, however, ICN introduces an 1432 architectural approach which may compensate on the whole and can even 1433 achieve higher energy efficiency rates when compared to the host- 1434 centric paradigm. 1436 We elaborate on the energy efficiency potential of ICN based on three 1437 categories of ICN characteristics. Namely, we point out that a) ICN 1438 does not rely solely on end-to-end communication, b) ICN enables 1439 ubiquitous caching, and c) ICN brings awareness of user requests (as 1440 well as their corresponding responses) at the network layer thus 1441 permitting network elements to better schedule their transmission 1442 patterns. 1444 First, ICN does not mandate perpetual end-to-end communication, which 1445 introduces a whole range of energy consumption inefficiencies due to 1446 the extensive signaling, especially in the case of mobile and 1447 wirelessly connected devices. This opens up new opportunities for 1448 accommodating sporadically connected nodes and could be one of the 1449 keys to an order of magnitude decrease in energy consumption over and 1450 above what other technological advances can contribute. For example, 1451 web applications often need to maintain state at both ends of a 1452 connection in order to verify that the authenticated peer is up and 1453 running. This introduces keep-alive timers and polling behavior with 1454 a high toll on energy consumption. Pentikousis [EEMN] discusses 1455 several related scenarios and explains why the current host-centric 1456 paradigm, which employs perpetual end-to-end connections, introduces 1457 built-in energy inefficiencies arguing that patches to make currently 1458 deployed protocols energy-aware cannot provide for an order of 1459 magnitude increase in energy efficiency. 1461 Second, ICN network elements come with built-in caching capabilities, 1462 which is often referred to as ubiquitous caching. Pushing data 1463 objects to caches closer to end user devices, for example, could 1464 significantly reduce the amount of transit traffic in the core 1465 network, thereby reducing the energy used for data transport. Guan 1466 et al. [EECCN] study the energy efficiency of CCNx (based on their 1467 proposed energy model) and compare it with conventional content 1468 dissemination systems such as CDNs and P2P. Their model is based on 1469 the analysis of the topological structure and the average hop-length 1470 from all consumers to the nearest cache location. Their results show 1471 that an information-centric approach can be more energy efficient in 1472 delivering popular and small size content. In particular, they also 1473 note that different network element design choices (e.g. the optical 1474 bypass approach) can be more energy-efficient in delivering 1475 infrequently accessed content. 1477 Lee et al. [EECD] investigate the energy efficiency of various 1478 network devices deployed in access, metro, and core networks for both 1479 CDNs and ICN. They use trace-based simulations to show that an ICN 1480 approach can substantially improve the network energy efficiency for 1481 content dissemination mainly due to the reduction in the number of 1482 hops required to obtain a data object, which can be served by 1483 intermediate nodes in ICN. They also emphasize that the impact of 1484 cache placement (in incremental deployment scenarios) and 1485 local/cooperative content replacement strategies need to be carefully 1486 investigated in order to better quantify the energy efficiencies 1487 arising from adopting an ICN paradigm. 1489 Third, ICN elements are aware of the user request and its 1490 corresponding data response, due to the nature of name-based routing, 1491 they can employ power consumption optimization processes for 1492 determining their transmission schedule or powering down inactive 1493 network interfaces. For example, network coding [NCICN] or adaptive 1494 video streaming [COAST] can be used in individual ICN elements so 1495 that redundant transmissions, possibly passing through intermediary 1496 networks, could be significantly reduced, thereby saving energy by 1497 avoiding to carry redundant traffic. 1499 Alternatively, approaches that aim to simplify routers, such as 1500 [PURSUIT], could also reduce energy consumption by pushing routing 1501 decisions to a more energy-efficient entity. Along these lines, Ko 1502 et al. [ICNDC] design a data center network architecture based on ICN 1503 principles and decouple the router control-plane and data-plane 1504 functionalities. Thus, data forwarding is performed by simplified 1505 network entities while the complicated routing computation is carried 1506 out in more energy-efficient data centers. 1508 To summarize, energy efficiency has been discussed in ICN evaluation 1509 studies but most published work is preliminary in nature. Thus, we 1510 suggest that more work is needed in this front. Evaluating energy 1511 efficiency does not require the definition of new scenarios or 1512 baseline topologies, but does require the establishment of clear 1513 guidelines so that different ICN approaches can be compared not only 1514 in terms of scalability, for example, but also in terms to power 1515 consumption. 1517 3.3. Operation across Multiple Network Paradigms 1518 Today the overwhelming majority of networks are integrated with the 1519 well-connected Internet with IP at the "waist" of the technology 1520 hourglass. However there is a large amount of ongoing research into 1521 alternative paradigms that can cope with conditions other than the 1522 standard set assumed by the Internet. Perhaps the most advanced of 1523 these is Delay- and Disruption-Tolerant Networking (DTN). DTN is 1524 considered as one of the scenarios for the deployment in section 2.7 1525 but here we consider how ICN can operate in an integrated network 1526 that has essentially disjoint "domains" (a highly-overloaded term!) 1527 or regions that use different network paradigms and technologies, but 1528 with gateways that allow interoperation. 1530 ICN operates in terms of named data objects so that requests and 1531 deliveries of information objects can be independent of the 1532 networking paradigm. Some researchers have contemplated some form of 1533 ICN becoming the new waist of the hourglass as the basis of a future 1534 reincarnation of the Internet, e.g., [ArgICN], but there are a large 1535 number of problems to resolve, including authorization and access 1536 control and transactional operation for applications such as banking, 1537 before some form of ICN can be considered as ready to take over from 1538 IP as the dominant networking technology. In the meantime, ICN 1539 architectures will operate in conjunction with existing network 1540 technologies as an overlay or in cooperation with the lower layers of 1541 the "native" technology. 1543 It seems likely that as the reach of the "Internet" is extended, 1544 other technologies such as DTN will be needed to handle scenarios 1545 such as space communications where inherent delays are too large for 1546 TCP/IP to cope with effectively. Thus, demonstrating that ICN 1547 architectures can work effectively in and across the boundaries of 1548 different networking technologies will be important. 1550 The NetInf architecture in particular targets the inter-domain 1551 scenario by the use of a convergence layer architecture [SAIL-B3] and 1552 PSIRP/PURSUIT is envisaged as a candidate for an IP replacement. 1554 The key items for evaluation over and above the satisfactory 1555 operation of the architecture in each constituent domain will be to 1556 ensure that requests and responses can be carried across the network 1557 boundaries with adequate performance and do not cause malfunctions in 1558 applications or infrastructure because of the differing 1559 characteristics of the gatewayed domains. 1561 4. Summary 1563 This document presents a wide range of different application areas in 1564 which the use of information-centric network designs have been 1565 evaluated in the peer-reviewed literature. Evidently, this broad 1566 range of scenarios illustrates the capability of ICN to potentially 1567 address today's problems in an alternative and better way than host- 1568 centric approaches as well as to point to future scenarios where ICN 1569 may be applicable. We believe that by putting different ICN systems 1570 to the test in diverse application areas, the community will be 1571 better equipped to judge the potential of a given ICN proposal and 1572 therefore subsequently invest more effort in developing it further. 1573 It is worth noting that this document collected different kinds of 1574 considerations, as a result of our ongoing survey of the literature 1575 and the discussion within ICNRG, which we believe would have 1576 otherwise remained unnoticed in the wider community. As a result, we 1577 expect that this document can assist in fostering the applicability 1578 and future deployment of ICN over a broader set of operations, as 1579 well as possibly influencing and enhancing the currently-available 1580 base ICN proposals and possibly assist in defining new scenarios 1581 where ICN would be applicable. 1583 We conclude this document with a brief summary of the evaluation 1584 aspects we have seen across a range of scenarios. 1586 The scalability of different mechanisms in an ICN architecture stands 1587 out as an important concern (cf. sections 2.1, 2.2, 2.5, 2.6, 2.8, 1588 2.9, 3.1) as does network, resource and energy efficiency (cf. 1589 sections 2.1, 2.3, 2.4, 3.1, 3.2). Operational aspects such as 1590 network planing, manageability, reduced complexity and overhead (cf. 1591 sections 2.2, 2.3, 2.4, 2.8, 3.1) should not be neglected especially 1592 as ICN architectures are evaluated with respect to their potential 1593 for deployment in the real world. Accordingly, further research in 1594 economic aspects as well as in the communication, computation, and 1595 storage tradeoffs entailed in each ICN architecture is needed. 1597 With respect to purely technical requirements, support for multicast, 1598 mobility, and caching lie at the core of many scenarios (cf. sections 1599 2.1, 2.3, 2.5, 2.6). ICN must also be able to cope when the Internet 1600 expands to incorporate additional network paradigms (cf. section 1601 3.3). We have also seen that being able to address stringent QoS 1602 requirements and increase reliability and resilience should also be 1603 evaluated following well-established methods (cf. sections 2.2, 2.8, 1604 2.9). 1606 Finally, we note that new applications that significantly improve the 1607 end user experience and forge a migration path from today's host- 1608 centric paradigm could be the key to a sustained and increasing 1609 deployment of the ICN paradigm in the real world (cf. sections 2.2, 1610 2.3, 2.6, 2.8, 2.9). 1612 5. Security Considerations 1614 This document does not impact the security of the Internet. 1616 6. IANA Considerations 1618 This document presents no IANA considerations. 1620 7. Acknowledgments 1622 Dorothy Gellert contributed to an earlier version of this document. 1624 This document has benefited from reviews, pointers to the growing ICN 1625 literature, suggestions, comments and proposed text provided by the 1626 following members of the IRTF Information-Centric Networking Research 1627 Group (ICNRG), listed in alphabetical order: Marica Amadeo, Hitoshi 1628 Asaeda, Claudia Campolo, Luigi Alfredo Grieco, Myeong-Wuk Jang, Ren 1629 Jing, Hongbin Luo, Priya Mahadevan, Will Liu, Ioannis Psaras, Spiros 1630 Spirou, Dirk Trossen, Jianping Wang, Yuanzhe Xuan, and Xinwen Zhang. 1632 The authors would like to thank Mark Stapp, Juan Carlos Zuniga, and 1633 G.Q. Wang for their comments and suggestions as part of their open 1634 and independent review of this document within ICNRG. 1636 8. Informative References 1638 [RFC5743] Falk, A., "Definition of an Internet Research Task Force 1639 (IRTF) Document Stream", RFC 5743, December 2009. 1641 [RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol 1642 Specification", RFC 5050, November 2007. 1644 [RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, 1645 R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant 1646 Networking Architecture", RFC 4838, April 2007. 1648 [RFC5568] Koodli, R., Ed., "Mobile IPv6 Fast Handovers", RFC 5568, 1649 July 2009. 1651 [RFC6920] Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B., 1652 Keranen, A., and P. Hallam-Baker, "Naming Things with 1653 Hashes", RFC 6920, April 2013. 1655 [NetInf] Ahlgren, B. et al., "Design considerations for a network 1656 of information", Proc. CoNEXT Re-Arch Workshop. ACM, 1657 2008. 1659 [CCN] Jacobson, V. et al., "Networking Named Content", Proc. 1660 CoNEXT. ACM, 2009. 1662 [NDNP] Zhang, L. et al., "Named Data Networking (NDN) Project", 1663 NDN Technical Report NDN-0001, Oct. 2010. Available: 1664 http://named-data.net/publications/techreports/ 1666 [PSI] Trossen, D. and G. Parisis, "Designing and realizing an 1667 information-centric internet", IEEE Commun. Mag., vol. 50, 1668 no. 7, July 2012. 1670 [DONA] Koponen, T. et al., "A Data-Oriented (and Beyond) Network 1671 Architecture", Proc. SIGCOMM. ACM, 2007. 1673 [SoA1] Ahlgren, B. et al., "A survey of information-centric 1674 networking", IEEE Commun. Mag., vol. 50, no. 7, July 2012. 1676 [SoA2] Xylomenos, G., et al. "A survey of information-centric 1677 networking research", IEEE Communications Surveys and 1678 Tutorials (2013): 1-26. 1680 [ICN-SN] Mathieu, B. et al., "Information-centric networking: a 1681 natural design for social network applications", IEEE 1682 Commun. Mag., vol. 50, no. 7, July 2012. 1684 [VPC] Kim, J. et al., "Content Centric Network-based Virtual 1685 Private Community", Proc. ICCE. IEEE, 2011. 1687 [CBIS] Jacobson, V. et al., "Custodian-Based Information 1688 Sharing", IEEE Commun. Mag., vol. 50, no. 7, July 2012. 1690 [VPC2] Kim, D. and J. Lee, "CCN-based virtual private community 1691 for extended home media service", IEEE Trans. Consumer 1692 Electronics, vol. 57, no. 2, May 2011. 1694 [CCR] Arianfar, S. et al., "On content-centric router design and 1695 implications", Proc. CoNEXT Re-Arch Workshop. ACM, 2010. 1697 [VoCCN] Jacobson, V. et al., "VoCCN: Voice-over Content-Centric 1698 Networks", Proc. CoNEXT Re-Arch Workshop. ACM, 2009. 1700 [NDNpb] Xuan, Y. and Z. Yan, "Enhancing Routing Efficiency in 1701 Named Data Network with Piggybacked Interest", Proc. CFI. 1702 ACM, 2013. 1704 [ACT] Zhu, Z. et al., "ACT: Audio Conference Tool Over Named 1705 Data Networking", Proc. SIGCOMM ICN Workshop. ACM, 2011. 1707 [G-COPSS] Chen, J. et al., "G-COPSS: A Content Centric Communication 1708 Infrastructure for Gaming Applications", Proc. ICDCS. 1709 IEEE, 2012. 1711 [MMIN] Pentikousis, K., and P. Bertin., "Mobility Management in 1712 Infrastructure Networks." IEEE Internet Computing 17, no. 1713 5 (2013): 74-79. 1715 [SCES] Allman, M. et al., "Enabling an Energy-Efficient Future 1716 Internet through Selectively Connected End Systems", Proc. 1717 HotNets-VI. ACM, 2007. 1719 [EEMN] Pentikousis, K., "In Search of Energy-Efficient Mobile 1720 Networking", IEEE Commun. Mag., vol. 48, no. 1, Jan. 2010. 1722 [MOBSURV] Tyson, G. et al., "A Survey of Mobility in Information- 1723 Centric Networks: Challenges and Research Directions", 1724 Proc. MobiHoc Workshop on Emerging Name-Oriented Mobile 1725 Networking Design. ACM, 2012. 1727 [N-Scen] Dannewitz, C. et al., "Scenarios and research issues for a 1728 Network of Information", Proc. MobiMedia. ICST, 2012. 1730 [DTI] Ott, J. and D. Kutscher, "Drive-thru Internet: IEEE 1731 802.11b for 'automobile' users", Proc. INFOCOM. IEEE, 1732 2004. 1734 [PSIMob] Xylomenos, G. et al., "Caching and Mobility Support in a 1735 Publish-Subscribe Internet Architecture", IEEE Commun. 1736 Mag., vol. 50, no. 7, July 2012. 1738 [mNetInf] Pentikousis, K. and T. Rautio, "A Multiaccess Network of 1739 Information", Proc. WoWMoM. IEEE, 2010. 1741 [HybICN] Lindgren, A., "Efficient content distribution in an 1742 information-centric hybrid mobile networks", Proc. CCNC. 1743 IEEE, 2011. 1745 [E-CHANET] M. Amadeo, et al., "E-CHANET: Routing, Forwarding and 1746 Transport in Information-Centric Multihop Wireless 1747 Networks", Computer Communications. Elsevier, Jan. 2013 1748 online. 1750 [MobiA] Meisel, M. et al., "Ad Hoc Networking via Named Data", 1751 Proc. MobiArch. ACM 2010. 1753 [CCNMANET] Oh, S. Y. et al., "Content Centric Networking in Tactical 1754 and Emergency MANETs", Proc. Wireless Days. IFIP, 2010. 1756 [RTIND] Wang, L. et al., "Rapid Traffic Information Dissemination 1757 Using Named Data", Proc. MobiHoc NoM workshop. ACM, 2012. 1759 [CCNVANET] Amadeo, M. et al., "Content-Centric Networking: is that a 1760 Solution for Upcoming Vehicular Networks?", Proc. VANET. 1761 ACM, 2012. 1763 [ABC] Gustafsson, E., and A. Jonsson. "Always best connected." 1764 Wireless Communications, IEEE 10.1 (2003): 49-55. 1766 [SHARE] Muscariello, L. et al., "Bandwidth and storage sharing 1767 performance in information centric networking", Proc. 1768 SIGCOMM ICN Workshop. ACM, 2011. 1770 [CL4M] Chai, W. K. et al., "Cache 'Less for More' in Information- 1771 centric Networks", Proc. Networking. IFIP, 2012. 1773 [CCNCT] Psaras, I. et al., "Modelling and Evaluation of CCN- 1774 Caching Trees", In Proc. of the 10th international IFIP 1775 conference on Networking, Valencia, Spain, May 2011. 1777 [BTCACHE] Tyson, G. et al., "A Trace-Driven Analysis of Caching in 1778 Content-Centric Networks", Proc. ICCCN. IEEE, 2012. 1780 [CURLING] Chai, W. K. et al., "CURLING: Content-Ubiquitous 1781 Resolution and Delivery Infrastructure for Next-Generation 1782 Services", IEEE Commun. Mag., vol. 49, no. 3, Mar. 2011. 1784 [ACDICN] Fotiou, N. et al., "Access control enforcement delegation 1785 for information-centric networking architectures", Proc. 1786 SIGCOMM ICN Workshop. ACM, 2012. 1788 [EWC] Bai, F. and B. Krishnamachari, "Exploiting the wisdom of 1789 the crowd: localized, distributed information-centric 1790 VANETs", IEEE Commun. Mag., vol. 48, no. 5, May 2010. 1792 [DMND] Wang, J., R. Wakikawa, and L. Zhang, "DMND: Collecting 1793 data from mobiles using Named Data", Proc. Vehicular 1794 Networking Conference (VNC). IEEE, 2010. 1796 [DNV2V] Wang, L. et al., "Data Naming in Vehicle-to-Vehicle 1797 Communications", Proc. INFOCOM NOMEN workshop. IEEE, 1798 2012. 1800 [CCNHV] Arnould, G. et al., "A Self-Organizing Content Centric 1801 Network Model for Hybrid Vehicular Ad-Hoc Networks". Proc. 1802 DIVANet. ACM, 2011. 1804 [CCDIVN] TalebiFard, P. and V.C.M. Leung, "A Content Centric 1805 Approach to Dissemination of Information in Vehicular 1806 Networks". Proc. DIVANet. ACM, 2012. 1808 [CRoWN] Amadeo, M. et al., "CRoWN: Content-Centric Networking in 1809 Vehicular Ad Hoc Networks", IEEE Communications Letters, 1810 vol. 16, no. 9, Sept. 2012. 1812 [SCN] Hoydis, J., et al., "Green small-cell networks", IEEE 1813 Vehicular Technology Magazine, vol. 6, no.1, pp. 37-43, 1814 March 2011. 1816 [HetNet] Li, H., et al. "Efficient HetNet implementation using 1817 broadband wireless access with fiber-connected massively 1818 distributed antennas architecture." IEEE Wireless 1819 Communications, vol. 18, no.3, pp. 72-78, June 2011. 1821 [ArgICN] Trossen, D. et al., "Arguments for an information centric 1822 internetworking architecture", ACM SIGCOMM CCR, 40:26-33, 1823 Apr. 2010. 1825 [EconICN] Agyapong, P. and M. Sirbu, "Economic Incentives in 1826 Information Centric Networking: Implications for Protocol 1827 Design and Public Policy", IEEE Commun. Mag., vol. 50, no. 1828 12, Dec. 2012. 1830 [SAIL-B3] Kutscher, D. (ed.) et al., "Final NetInf Architecture", 1831 SAIL Project Deliverable D-B.3 , Jan. 2013. Available: 1832 http://www.sail-project.eu/deliverables/ 1834 [MLDHT] Liu, H. et al., "A multi-level DHT routing framework with 1835 aggregation", Proc. SIGCOMM ICN Workshop. ACM, 2012. 1837 [NCOA] Ghodsi, A. et al., "Naming in Content-oriented 1838 Architectures", Proc. SIGCOMM ICN Workshop. ACM, 2011. 1840 [RP-NDN] DiBenedetto, S. et al., "Routing policies in named data 1841 networking", Proc. SIGCOMM ICN Workshop. ACM, 2011. 1843 [SAIL-A7] Salo, J. (ed.) et al., "New business models and business 1844 dynamics of the future networks", SAIL Project Deliverable 1845 D-A.7, Aug. 2011. Available: http://www.sail- 1846 project.eu/deliverables/ 1848 [SAIL-A8] Zhang, N. (ed.) et al., "Evaluation of business models", 1849 SAIL Project Deliverable D-A.8, Jan. 2013. Available: 1850 http://www.sail-project.eu/deliverables/ 1852 [LIPSIN] Jokela, P. et al., "LIPSIN: line speed publish/subscribe 1853 inter-networking", Proc. of ACM SIG-COMM 2009. 1855 [LANES] Visala, K. et al., "LANES: An Inter-Domain Data-Oriented 1856 Routing Architecture", Proc. CoNEXT Re-Arch Workshop. 1857 ACM, 2009. 1859 [PSIRP1] Rajahalme, J. et al., "Inter-Domain Rendezvous Service 1860 Architecture", PSIRP Technical Report TR09-003, Dec. 2009. 1862 [ICCP] Rajahalme J. et al., "Incentive-Compatible Caching and 1863 Peering in DataOriented Networks", Proc. CoNEXT Re-Arch 1864 Workshop. ACM, 2008. 1866 [IDMcast] Rajahalme, J., "Incentive-informed Inter-domain 1867 Multicast", Proc. Global Internet Symposium 2010. 1869 [IDArch] Rajahalme, J., "Inter-domain incentives and Internet 1870 architecture", PhD. Dissertation, Aalto University, Aug. 1871 2012. 1873 [PURSUIT] Fotiou, N. et al., "Developing Information Networking 1874 Further: From PSIRP to PURSUIT", Proc. BROADNETS. ICST, 1875 2010. 1877 [EECCN] Guan, K. et al., "On the Energy Efficiency of Content 1878 Delivery Architectures", Proc. ICC Workshops. IEEE, 2011. 1880 [EECD] Lee, U., Rimac, I., Kilper, D., and V. Hilt, "Toward 1881 energy-efficient content dissemination", IEEE Network, 1882 vol. 25, no. 2, March-April 2011. 1884 [NCICN] Montpetit, M. J., Westphal, C., and D. Trossen, "Network 1885 coding meets information-centric networking: an 1886 architectural case for information dispersion through 1887 native network coding", Proc. MOBIHOC NoM Workshop. ACM, 1888 2012. 1890 [COAST] Gruneberg, K. et al., "File format specification and 3D 1891 video codec", COAST Project Deliverable D5.1, July 2011. 1892 Available: http://www.coast-fp7.eu/deliverables.html 1894 [ICNDC] Ko, B. J., Pappas, V., Raghavendra, R., Song, Y., 1895 Dilmaghani, R. B., Lee, K.-w., and D. Verma, "An 1896 information-centric architecture for data center 1897 networks", Proc. SIGCOMM ICN Workshop. ACM, 2012. 1899 [DTN] Fall, K., "A delay-tolerant network architecture for 1900 challenged internets", Proc. SIGCOMM. ACM, 2003. 1902 [DTNICN] Tyson, G., Bigham, J. and E. Bodanese, "Towards an 1903 Information-Centric Delay-Tolerant Network", Proc. IEEE 1904 INFOCOM NOMEN 2013, Turin, Italy. 1906 [BPQ] Farrell, S., Lynch, A., Kutscher, D., and A. Lindgren, 1907 "Bundle protocol query extension block", draft-irtf-dtnrg- 1908 bpq-00 (work in progress), May 2012. 1910 [SLINKY] Kawadia, V., Riga, N.,Opper, J., and D. Sampath, "Slinky: 1911 An adaptive protocol for content access in disruption- 1912 tolerant ad hoc networks", in Proc. MobiHoc Workshop on 1913 Tactical Mobile Ad Hoc Networking, 2011. 1915 [ONE] The Opportunistic Network Environment simulator. 1916 Available: http://www.netlab.tkk.fi/tutkimus/dtn/theone 1918 [TWIMIGHT] Hossmann, T., et al. "Twitter in disaster mode: smart 1919 probing for opportunistic peers", Proc. 3rd ACM 1920 International Workshop on Mobile Opportunistic Networks. 1921 ACM, 2012. 1923 [MODEL1] Uddin, M.Y.S., Nicol, D.M., Abdelzaher, T.F., and R.H. 1924 Kravets, "A post-disaster mobility model for Delay 1925 Tolerant Networking", Simulation Conference (WSC), 1926 Proceedings of the 2009 Winter , vol., no., pp.2785,2796, 1927 13-16 Dec. 2009 1929 [MODEL2] Aschenbruck, N., Gerhards-Padilla, E., and P. Martini, 1930 "Modeling mobility in disaster area scenarios.", 1931 Performance Evaluation 66, no. 12 (2009): 773-790. 1933 [MODEL3] Cabrero, S., Paneda, X.G., Plagemann, T., Melendi, D., and 1934 R. Garcia, "An Overlay Routing Protocol for Video over 1935 sparse MANETs in Emergencies", Cadernos de Informatica 6, 1936 no. 1 (2011): 195-202. 1938 [IoTEx] Burke, J., "Authoring Place-based Experiences with an 1939 Internet of Things: Tussles of Expressive, Operational, 1940 and Participatory Goals", Proc. Interconnecting Smart 1941 Objects with the Internet Workshop. IAB, 2011. 1943 [IWMT] Kutscher, D. and S. Farrell, "Towards an Information- 1944 Centric Internet with more Things", Proc. Interconnecting 1945 Smart Objects with the Internet Workshop. IAB, 2011. 1947 [nWSN] Heidemann, J. et al., "Building efficient wireless sensor 1948 networks with low-level naming", Proc. SOSP. ACM, 2001. 1950 [NDNl] Burke, J. et al., "Authenticated Lighting Control Using 1951 Named Data Networking", NDN Technical Report NDN-0011, 1952 Oct. 2012. 1954 [CIBUS] Biswas, T. et al., "Contextualized Information-Centric 1955 Home Network", Proc. ACM SIGCOMM. ACM, 2013. 1957 [Homenet] Ravindran, R. et al., "Information-centric Networking 1958 based Homenet", Proc. International Workshop on Management 1959 of the Future Internet (ManFI). IFIP/IEEE, 2013. 1961 [IoTScope] Marias, G.F. et al., "Efficient information lookup for the 1962 Internet of Things", Proc. WoWMoM. IEEE, 2012. 1964 [ICN-DHT] Katsaros, K. et al., "On inter-domain name resolution for 1965 information-centric networks", Proc. Networking. 1966 Springer, 2012. 1968 [SEMANT] Sheth, A. et al., "Semantic Sensor Web," Internet 1969 Computing, IEEE , vol.12, no.4, pp.78,83, July-Aug. 2008 1971 [CPG] Cianci, I. et al., "Content Centric Services in Smart 1972 Cities", Proc. NGMAST. IEEE, 2012. 1974 [MVM] Hernndez-Munoz, J.M. et al., "Smart cities at the 1975 forefront of the future Internet", The Future Internet. 1976 Springer, 2011. 1978 [iHEMS] Zhang, J. et al., "iHEMS: An Information-Centric Approach 1979 to Secure Home Energy Management", Proc. SmartGridComm. 1980 IEEE, 2012. 1982 [ACC] Andreini, F. et al., "A scalable architecture for geo- 1983 localized service access in smart cities", Proc. Future 1984 Network and Mobile Summit. IEEE, 2011. 1986 [IB] Idowu, S. and N. Bari, "A Development Framework for Smart 1987 City Services, Integrating Smart City Service Components", 1988 Master Thesis. Lulea University of Technology, 2012. 1990 [ISODIS] ISO/DIS 37120, Sustainable development and resilience of 1991 communities --Indicators for city services and quality of 1992 life, 2013. 1994 Authors' Addresses 1996 Kostas Pentikousis (editor) 1997 EICT GmbH 1998 Torgauer Strasse 12-15 1999 10829 Berlin 2000 Germany 2002 Email: k.pentikousis@eict.de 2004 Borje Ohlman 2005 Ericsson Research 2006 S-16480 Stockholm 2007 Sweden 2009 Email: Borje.Ohlman@ericsson.com 2011 Daniel Corujo 2012 Instituto de Telecomunicacoes 2013 Campus Universitario de Santiago 2014 P-3810-193 Aveiro 2015 Portugal 2017 Email: dcorujo@av.it.pt 2019 Gennaro Boggia 2020 Dep. of Electrical and Information Engineering 2021 Politecnico di Bari 2022 Via Orabona 4 2023 70125 Bari 2024 Italy 2026 Email: g.boggia@poliba.it 2028 Gareth Tyson 2029 School and Electronic Engineering and Computer Science 2030 Queen Mary, University of London 2031 United Kingdom 2033 Email: gareth.tyson@eecs.qmul.ac.uk 2035 Elwyn Davies 2036 Trinity College Dublin/Folly Consulting Ltd 2037 Dublin, 2 2038 Ireland 2040 Email: davieseb@scss.tcd.ie 2042 Antonella Molinaro 2043 Dep. of Information, Infrastructures, and Sustainable 2044 Energy Engineering 2045 Universita' Mediterranea di Reggio Calabria 2046 Via Graziella 1 2047 89100 Reggio Calabria 2048 Italy 2050 Email: antonella.molinaro@unirc.it 2052 Suyong Eum 2053 National Institute of Information and Communications Technology 2054 4-2-1, Nukui Kitamachi, Koganei 2055 Tokyo 184-8795 2056 Japan 2058 Phone: +81-42-327-6582 2059 Email: suyong@nict.go.jp