idnits 2.17.1 draft-irtf-icnrg-challenges-04.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 (February 8, 2016) is 2993 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-08) exists of draft-irtf-icnrg-videostreaming-05 -- Obsolete informational reference (is this intentional?): RFC 2002 (Obsoleted by RFC 3220) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ICNRG D. Kutscher, Ed. 3 Internet-Draft NEC 4 Intended status: Informational S. Eum 5 Expires: August 11, 2016 NICT 6 K. Pentikousis 7 EICT 8 I. Psaras 9 UCL 10 D. Corujo 11 Universidade de Aveiro 12 D. Saucez 13 INRIA 14 T. Schmidt 15 HAW HAmburg 16 M. Waehlisch 17 FU Berlin 18 February 8, 2016 20 ICN Research Challenges 21 draft-irtf-icnrg-challenges-04 23 Abstract 25 This memo describes research challenges for Information-Centric 26 Networking (ICN), an approach to evolve the Internet infrastructure 27 to directly support information distribution by introducing uniquely 28 named data as a core Internet principle. Data becomes independent 29 from location, application, storage, and means of transportation, 30 enabling or enhancing a number of desirable features, such as 31 security, user-mobility, multicast and in-network caching. 32 Mechanisms for realizing these benefits is subject of on-going 33 research in the IRTF and elsewhere. This document describes current 34 research challenges in ICN, including naming, security, routing, 35 system scalability, mobility management, wireless networking, 36 transport services, in-network caching, and network management. 38 This document is a product of the IRTF Information-Centric Networking 39 Research Group (ICNRG). 41 Status of This Memo 43 This Internet-Draft is submitted in full conformance with the 44 provisions of BCP 78 and BCP 79. 46 Internet-Drafts are working documents of the Internet Engineering 47 Task Force (IETF). Note that other groups may also distribute 48 working documents as Internet-Drafts. The list of current Internet- 49 Drafts is at http://datatracker.ietf.org/drafts/current/. 51 Internet-Drafts are draft documents valid for a maximum of six months 52 and may be updated, replaced, or obsoleted by other documents at any 53 time. It is inappropriate to use Internet-Drafts as reference 54 material or to cite them other than as "work in progress." 56 This Internet-Draft will expire on August 11, 2016. 58 Copyright Notice 60 Copyright (c) 2016 IETF Trust and the persons identified as the 61 document authors. All rights reserved. 63 This document is subject to BCP 78 and the IETF Trust's Legal 64 Provisions Relating to IETF Documents 65 (http://trustee.ietf.org/license-info) in effect on the date of 66 publication of this document. Please review these documents 67 carefully, as they describe your rights and restrictions with respect 68 to this document. Code Components extracted from this document must 69 include Simplified BSD License text as described in Section 4.e of 70 the Trust Legal Provisions and are provided without warranty as 71 described in the Simplified BSD License. 73 Table of Contents 75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 76 2. Problems with Host-Centric Communications . . . . . . . . . . 4 77 3. ICN Terminology and Concepts . . . . . . . . . . . . . . . . 5 78 3.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 79 3.2. Concepts . . . . . . . . . . . . . . . . . . . . . . . . 5 80 4. ICN Research Challenges . . . . . . . . . . . . . . . . . . . 7 81 4.1. Naming, Data Integrity, and Data Orign Authentication . . 7 82 4.2. Security . . . . . . . . . . . . . . . . . . . . . . . . 9 83 4.2.1. Data Integrity and Orign Authentication . . . . . . . 9 84 4.2.2. Binding NDOs to Real-World Identities . . . . . . . . 11 85 4.2.3. Access Control and Authorization . . . . . . . . . . 11 86 4.2.4. Encryption . . . . . . . . . . . . . . . . . . . . . 12 87 4.2.5. Traffic Aggregation and Filtering . . . . . . . . . . 12 88 4.2.6. State Overloading . . . . . . . . . . . . . . . . . . 12 89 4.2.7. Delivering Data Objects from Replicas . . . . . . . . 13 90 4.2.8. Cryptographic Robustness . . . . . . . . . . . . . . 13 91 4.2.9. Routing and Forwarding Information Bases . . . . . . 14 92 4.3. Routing and Resolution System Scalability . . . . . . . . 14 93 4.3.1. Route-By-Name Routing . . . . . . . . . . . . . . . . 14 94 4.3.2. Lookup-By-Name Routing . . . . . . . . . . . . . . . 15 95 4.3.3. Hybrid Routing . . . . . . . . . . . . . . . . . . . 16 97 4.4. Mobility Management . . . . . . . . . . . . . . . . . . . 16 98 4.5. Wireless Networking . . . . . . . . . . . . . . . . . . . 19 99 4.6. Rate and Congestion Control . . . . . . . . . . . . . . . 21 100 4.7. In-Network Caching . . . . . . . . . . . . . . . . . . . 23 101 4.7.1. Cache Placement . . . . . . . . . . . . . . . . . . . 23 102 4.7.2. Content Placement -- Content-to-Cache Distribution . 24 103 4.7.3. Request-to-Cache Routing . . . . . . . . . . . . . . 25 104 4.7.4. Staleness Detection of Cached NDOs . . . . . . . . . 25 105 4.7.5. Cache Sharing by Multiple Applications . . . . . . . 26 106 4.8. Network Management . . . . . . . . . . . . . . . . . . . 26 107 4.9. ICN Applications . . . . . . . . . . . . . . . . . . . . 28 108 4.9.1. Web Applications . . . . . . . . . . . . . . . . . . 29 109 4.9.2. Video Streaming and Download . . . . . . . . . . . . 29 110 4.9.3. Internet of Things . . . . . . . . . . . . . . . . . 30 111 5. Security Considerations . . . . . . . . . . . . . . . . . . . 31 112 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 113 7. Informative References . . . . . . . . . . . . . . . . . . . 31 114 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 35 115 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 117 1. Introduction 119 Information-centric networking (ICN) is an approach to evolve the 120 Internet infrastructure to directly support this use by introducing 121 named data as a network primitive. Data objects become independent 122 of location, application, storage, and means of transportation, 123 allowing for inexpensive and ubiquitous in-network caching and 124 replication. The expected benefits are improved efficiency and 125 security, better scalability with respect to information/bandwidth 126 demand and better robustness in challenging communication scenarios. 128 ICN concepts can be deployed by retooling the protocol stack: name- 129 based data access can be implemented on top of the existing IP 130 infrastructure, e.g., by allowing for named data structures, 131 ubiquitous caching and corresponding transport services, or it can be 132 seen as a packet-level internetworking technology that would cause 133 fundamental changes to Internet routing and forwarding. In summary, 134 ICN can evolve the Internet architecture towards a named-data-based 135 network model with different properties and different services. 137 This document presents the ICN research challenges that need to be 138 addressed in order to achieve these goals. These research challenges 139 are seen from a technical perspective, although business 140 relationships between Internet players will also influence 141 developments in this area. We leave business challenges for a 142 separate document, however. The objective of this memo is to 143 document the technical challenges and corresponding current 144 approaches and to expose requirements that should be addressed by 145 future research work. 147 This document has been reviewed, commented, and discussed extensively 148 for a period of nearly two years by the vast majority of ICNRG 149 members, which certainly exceeds 100 individuals. It is the 150 consensus of ICNRG that the research challenges described in this 151 document should be published in the IRTF Stream of the RFC series. 152 This document does not constitute a standard. 154 2. Problems with Host-Centric Communications 156 The best current practice to manage the above-mentioned growth in 157 terms of data volume and number of devices is to increase 158 infrastructure investment, employ application-layer overlays that 159 cache content such as Content Distribution Networks (CDNs) and Peer- 160 to-Peer (P2P) applications, provide location-independent access to 161 data, and optimize its delivery. In principle, such platforms 162 provide a service model of accessing named data objects (NDOs) (e.g., 163 replicated web resources in data centers) instead of a host-to-host 164 packet delivery service model. 166 However, since this functionality resides in overlays only, the full 167 potential of content distribution platforms cannot be leveraged as 168 the network is not aware of data requests and data transmissions. 169 This has the following impact: 171 o data traffic typically follows sub-optimal paths as it is 172 effectively routed depending on the overlay topology instead of 173 the Internet layer topology; 175 o network capabilities, such as multicast and broadcast, are largely 176 underutilized or not employed at all. As a result, request and 177 delivery for the same object have to be made multiple times; 179 o overlays typically require significant infrastructure support, 180 e.g., authentication portals, content storage, and applications 181 servers, making it often impossible to establish local, direct 182 communication; 184 o the forwarding layer cannot cooperate with transport layer 185 functions,so sometimes useful functionality such as local 186 retransmission, local rate control have to implemented with TCP 187 proxies or other intermediaries. 189 o provenance validation uses host authentication today. As such, 190 even if there are locally cached copies available, it is normally 191 not easily possible to validate their authenticity; and 193 o many applications follow their own approach to caching, 194 replication, transport, authenticity validation (if at all), 195 although they all share similar models for accessing named data 196 objects in the network. 198 Host-centric communication systems restrict applications to data 199 transfer between end-hosts only. Naming data directly provides a 200 powerful "hook" for applications to exploit and natively support 201 multi-party communication, e.g., multi-source/multi-destination 202 communication and a ubiquitous information ecosystem that is not 203 restricted to end-host addresses. 205 3. ICN Terminology and Concepts 207 3.1. Terminology 209 Information-Centric Networking (ICN): A concept for communicating in 210 a network that provides accessing named data objects as a first 211 order service. See Section 3.2 for details. 213 Named Data Object (NDO): Addressable data unit in an information- 214 centric network that can represent a collection of bytes or a 215 piece of information. In ICN, each data object has a name bound 216 to it, and there are typically mechanisms to secure (and validate) 217 this binding. Different ICN approaches have different concepts 218 for how to map NDOs to individual units of transport, e.g., 219 chunks, segments. Sometimes smaller units may be represented by 220 NDOs themselves. Within the context of this document, an NDO is 221 any named data object that can be requested from the network, and 222 we do not consider sub units below the NDO level. In this 223 document we often use the terms NDO and data object 224 interchangeably. 226 Requestor: Entity in an ICN network that is sending a request for a 227 Named Data Object to the network. 229 Publisher: Entity in an ICN network that publishes an NDO to the 230 network, so that corresponding requests can reach the publisher. 231 The publisher does not need to be identical to the actual creator, 232 for example a publisher could provide the service of hosting NDOs 233 on behalf of the actual creators/owners. 235 3.2. Concepts 237 Fundamentally, ICN provides access to named data as a first-order 238 network service, i.e., the network is able to serve requests to named 239 data natively. That means, network nodes can receive requests for 240 named data and act as necessary, for example, by forwarding the 241 request to a suitable next-hop. Consequently, the network processes 242 requests for named data objects (and corresponding responses) 243 natively. Every network node on a path is enabled to perform 244 forwarding decisions, cache objects etc. This enables the network to 245 forward such requests on optimal paths, employing the best 246 transmission technologies at every node, e.g., broadcast/multicast 247 transmission in wireless networks to avoid duplicate transmission of 248 both requests and responses. 250 In ICN there is a set of common concepts and node requirements beyond 251 this basic service model. Naming data objects is a key concept. In 252 general, ICN names represent neither network nodes nor interfaces -- 253 they represent NDOs independently of their location. Names do play a 254 key role in forwarding decisions and are used for matching requests 255 to responses: In order to provide better support for accessing copies 256 of NDOs regardless of their location, it is important to be able to 257 validate that a response actually delivers the bits that correspond 258 to an original request for named data. 260 Name-content binding validation is a fundamental security service in 261 ICN, and this is often achieved by establishing a verifiable binding 262 between the object name and the actual object or an identity that has 263 created the object. ICN can support other security services, such as 264 provenance validation and encryption depending on the details of 265 naming schemes, object models and assumptions on infrastructure 266 support. Security services such as name-content binding validation 267 are available to any node, i.e., not just the actual requestors. 268 This is an important feature, for enabling ingress gateways to check 269 object authenticity to prevent denial-of-service attacks. 271 Based on these fundamental properties it is possible to leverage 272 network storage ubiquitously: every ICN node can cache data objects 273 and respond to requests for such objects -- it is not required to 274 validate the authenticity of the node itself since name-content 275 bindings can be validated. Ubiquitous in-network storage can be used 276 for different purposes: it can enable sharing, i.e., the same object 277 copy can be delivered to multiple users/nodes as in today's proxy 278 caches and CDNs. It can also be used to make communication more 279 robust (and perform better) by enabling the network to answer 280 requests from local caches (instead of from origin servers). In case 281 of disruption (message not delivered), a node can resend the request, 282 and it could be answered by an on-path cache, i.e., on the other side 283 of the disrupted link. The network itself would thus support 284 retransmissions enabling shorter round-trip times and offloading 285 origin servers and other parts of the network. 287 ICN potentially retrieves segments of NDOs from multiple data 288 sources, and so only a requestor can determine the completion of a 289 retrieval process, i.e., the retrieval of NDOs or individual segments 290 is typically controlled by a requestor. For this reason, ICN 291 transport protocols are typically based on a receiver-driven 292 mechanism: requestors can control message sending rates by regulating 293 the request sending rate (assuming that every response message has to 294 be triggered by a request message). Retransmission would be achieved 295 by resending requests, e.g., after a timeout. Because objects can be 296 replicated, object transmission and transport sessions would not 297 necessarily have end-to-end semantics: requests can be answered by 298 caches, and a node can select one or multiple next-hop destinations 299 for a particular request depending on configuration, observed 300 performance or other criteria. 302 This receiver-driven communication model potentially enables new 303 interconnection and business models: a request for named data can be 304 linked to an interest of a requestor (or requesting network) in data 305 from another peer, which could suggest modeling peering agreements 306 and charging accordingly. 308 4. ICN Research Challenges 310 4.1. Naming, Data Integrity, and Data Orign Authentication 312 Naming data objects is as important for ICN as naming hosts is for 313 today's Internet. Fundamentally, ICN requires unique names for 314 individual NDOs, since names are used for identifying objects 315 independently of their location or container. In addition, since 316 NDOs can be cached anywhere, the origin cannot be trusted anymore 317 hence the importance to establish a verifiable binding between the 318 object and its name (name-data binding validation) so that a 319 requestor can be sure that the received bits do correspond to the NDO 320 originally requested (data integrity). Data orign authentication is 321 a different security service that can be related to naming, i.e., 322 verifying that an NDO has indeed been published by a publisher (that 323 could be identified by a name prefix). 325 The above functions are fundamentally required for the information- 326 centric network to work reliably, otherwise neither network elements 327 nor requestors can trust object authenticity. Lack of this trust 328 enables several attacks including DoS attacks by injecting spoofed 329 content into the network. There are different ways to use names and 330 cryptography to achieve the desired functions [ICNNAMING] 331 [ICNSURVEY], and there are different ways to manage namespaces 332 correspondingly. 334 Two types of naming schemes have been proposed in the ICN literature: 335 hierarchical and flat namespaces. For example, a hierarchical scheme 336 may have a structure similar to current URIs, where the hierarchy is 337 rooted in a publisher prefix. Such hierarchy enables aggregation of 338 routing information, improving scalability of the routing system. In 339 some cases, names are human-readable, which makes it possible for 340 users to manually type in names, reuse and, to some extent, map the 341 name to user intent. 343 The second general class of naming schemes enables verifying the 344 object's name-data integrity without requiring a public key 345 infrastructure (PKI) or other third party to first establish trust in 346 the key. This is achieved, e.g., by binding the hash of the NDO 347 content to the object's name. For instance, this can be done by 348 directly embedding the hash of the content in the name. Another 349 option is an indirect binding, which embeds the public key of the 350 publisher in the name and signs the hash of the content with the 351 corresponding secret key. The resulting names are typically non- 352 hierarchical, or flat, although the publisher field could be employed 353 to create a structure which could facilitate route aggregation. 355 There are several design trade-offs for ICN naming, which affect 356 routing and security. Hash-based names are not human readable nor 357 hierarchical. They can however provide some structure for 358 aggregation, for instance, a name part corresponding to a publisher. 359 In hash-based names with indirect binding, the key of the publisher 360 is bound to the name of NDO, and so when a user receives, e.g., the 361 triplet namely [data, key, signature], the receiving entity can 362 verify that the NDO has been generated by the possessor of the 363 private/public key pair and that the NDO has not been changed in 364 transit (data integrity). This can be done by cryptographically 365 hashing the received key and the name of NDO, and comparing it with 366 received hashed key. Then, the key can be used to verify the 367 signature. 369 Data origin authentication can be achieved by validating public-key- 370 cryptography-based signatures about an NDO's name and content. In 371 order to ascertain data integrity and origin authenticity with such 372 an approach, a PKI-like system is required that would allow linking 373 the corresponding public key to a trust chain. 375 Research challenges specific to naming include: 377 o Naming static data objects can be performed by using content 378 hashes as part of object names, so that publishers can calculate 379 the hash over existing data objects and requestors and any ICN 380 node can validate the name-content binding by re-calculating the 381 hash and comparing it to the name (component). [RFC6920] 382 specifies a concrete naming format for this. 384 o Naming dynamic objects refers to use cases where the name has to 385 be generated before the object is created. For example, this 386 could be the case for live streaming, when a publisher wants to 387 make the stream available by registering stream chunk names in the 388 network. One approach to this can be hash-based names with 389 indirect binding as described above. 391 o Requestor privacy protection can be a challenge in ICN as a direct 392 consequence of the accessing-named-data-objects paradigm: if the 393 network can "see" requests and responses, it can also log request 394 history for network segments or individual users, which can be 395 undesirable, especially since names are typically expected to be 396 long-lived. That is, even if the name itself does not reveal much 397 information, the assumption is that the name can be used to 398 retrieve the corresponding data objects in the future. 400 o Updating and versioning NDOs can be challenging because it can 401 contradict fundamental ICN assumptions: if an NDO can be 402 replicated and stored in in-network storage for later retrieval, 403 names have to be long-lived and the name-content binding must not 404 change: updating an object (i.e., changing the content without 405 generating a new name) is not possible. Versioning is one 406 possible solution, but requires a naming scheme that supports it 407 (and a way for requestors to learn about versions). 409 o Managing accessibility: whereas in ICN the general assumption is 410 to enable ubiquitous access to NDOs, there can be relevant use 411 cases where access to objects should be restricted, for example to 412 a specific user group. There are different approaches for this, 413 such as object encryption (requiring key distribution and related 414 mechanisms) or the concept of scopes, e.g., based on names that 415 can only be used/resolved under some constraints. 417 4.2. Security 419 Security is an active research field in ICN. This section provides 420 an overview of important important security features and 421 corresponding challenges that are related to shifting to information- 422 centric communications. Some challenges are well-understood, and 423 there are (sometimes multiple different) approaches to address them, 424 whereas other challenges are active research and engineering topics. 426 4.2.1. Data Integrity and Orign Authentication 428 As mentioned in section Section 4.1, data integrity verification is 429 an important ICN feature, since NDOs are retrieved not only from an 430 original copy holder but also from any caching point. Hence, the 431 communication channel endpoints to retrieve NDOs are not trustable 432 anymore and solutions widely used today such as TLS [RFC5246] cannot 433 be used as a general solution. Since data objects can be maliciously 434 modified, ICN should provide receivers with a security mechanism to 435 verify the integrity of the data object, and there are different ways 436 to achieve this. 438 An efficient approach for static NDOs is providing a name-content- 439 binding by hashing an NDO and using the hash as a part of the 440 object's name. [RFC6920] provides a mechanism and a format for 441 representing a digest algorithm and the actual digest in a name 442 (amongst other information). 444 For dynamic objects where it is desirable to refer to an NDO by name 445 before the object has been created, public-key cryptography is often 446 applied, i.e., every NDO would be authenticated by means of a 447 signature performed by the data object publisher so that any data 448 object consumer can verify the validity of the data object based on 449 the signature. However, in order to verify the signature of an 450 object, the consumer must know the public key of the entity that 451 signed the object. 453 Data Orign Authentication, i.e., verifying that an NDO has indeed 454 been published by a publisher, requires a secure binding of an NDO 455 name to a publisher identiy -- this is also typically implemented 456 using public key cryptography, i.e., by requiring a recevier to 457 verify digital signatures that as part of a received message. 459 One research challenge is then to support a mechanism to distribute 460 the publisher's public keys to the consumers of data objects. There 461 are two main approaches to achieve this; one is based on an external 462 third party authority such as hierarchical Public Key Infrastructure 463 (PKI) (see [RFC5280] for a description of hierarchical PKI) and the 464 other is to adapt a hash-based scheme with indirect binding. The 465 former, as the name implies, depends on an external third party 466 authority to distribute the public key of the publisher for the 467 consumers. In a hash-based scheme with indirect binding, the public 468 key (or a hash of it) would be used as part of the name -- which is 469 sufficient to validate the data integrity. 471 In cases where information about the origin of a data object is not 472 available by other means, the object itself would have to incorporate 473 the necessary information to determine the object publisher, for 474 example with a certificate, that can be validated through the PKI. 475 Once the certificate is authenticated, its public key can be used to 476 authenticate the signed data object itself. 478 4.2.2. Binding NDOs to Real-World Identities 480 In addition to validating NDO authenticity, it is still important to 481 bind real-world identities, e.g., a publisher identity, to objects, 482 so that a requestor can verify that a received object was actually 483 published by a certain source. 485 With hash-based names, real world identity bindings are not 486 intrinsically established: the name provides the hash of the NDO or 487 of the public key that has been used to sign the NDO. There needs to 488 be another binding to a real world identity if that feature is 489 requested. 491 If the object name directly provides the publisher name and if that 492 name is protected by a certificate that links to a PKI-like trust 493 chain, the object name itself can provide an intrinsic binding to a 494 real world identity. 496 Binding between NDOs and real world identities is essential but there 497 is no universal way to achieve it as it is all intrinsic to a 498 particular ICN approach. 500 4.2.3. Access Control and Authorization 502 Access control and authorization is a challenge in ICN, because of 503 the lack of user-to-server authentication in the fundamental named- 504 data-based communication model. 506 All ICN entities are capable of delivering NDOs on demand due to 507 their in-network caching function. In such an environment, 508 traditional access control schemes based on Access Control List (ACL) 509 are ill-suited since widely distributed ICN entities have to maintain 510 an identical control policy over NDOs for each consumer, which is 511 prohibited due to computational overhead and privacy issues. There 512 are two complementary approaches to address the issues: 514 1. Separated approach: access control service from a third party 515 that is independent from ICN entities. Due to the clear 516 separation, ICN entities free from computational overhead to 517 determine the accessibility of NDOs by consumers and also 518 consumers can secure their privacy through the independent 519 authorization entity [access-control-delegation]. One challenge 520 relevant to this approach is how to reduce the authorization 521 delay involved with the delay to the access control provider? 523 2. Integrated approach: access control service from ICN entities. 524 This mechanism is often based on content encryption and key 525 distribution [encryption-ac]. As mentioned previously, this 526 approach suffers from prohibitive overhead for ICN entities due 527 to the process of key verification. While key distribution is 528 per se challenging, this approach is beneficial in a way that 529 NDOs can be retrieved without the help of an external access 530 control provider. Challenges to this approach include: 532 1. How to apply an access control mechanism for dynamic NDOs in 533 in-network caches in a timely manner? 535 2. How to provide consumers with the different levels of 536 accessibility to individual NDOs in a scalable manner? 538 4.2.4. Encryption 540 In ICN, NDOs can be encrypted to implement access control (only 541 consumers in possession of corresponding decryption keys can access 542 the content) or privacy (same approach). Distributing and managing 543 the corresponding keys as well as providing usable interfaces to 544 applications and human users is a challenge and subject of on-going 545 work. 547 In principle, the challenges are similar to those of broadcast/media 548 distribution, and similar approaches (combing symmetric with public- 549 key cryptography) are being investigated. [ndn-controlled-sharing] 551 4.2.5. Traffic Aggregation and Filtering 553 One request message to retrieve a data object can actually aggregate 554 requests coming from several consumers. This aggregation of requests 555 reduces the overall traffic but makes per-requestor filtering harder. 556 The challenge in this case is to provide a mechanism that allows 557 request aggregation and per-requestor filtering. A possible solution 558 is to indicate the set of requestors in the aggregated request such 559 that the response can indicate the subset of requestors allowed to 560 access the data object. However, this solution requires 561 collaboration from other nodes in the network and is not suitable for 562 caching. Another possible solution is to encrypt data objects and 563 ensure that only authorised consumers can decrypt them. This 564 solution does not preclude caching and does not require collaboration 565 from the network. However, it implies a mechanism to generate group 566 keys (e.g., different private keys can be used to decrypt the same 567 encrypted data object) [Chaum]. 569 4.2.6. State Overloading 571 ICN solutions that implement state on intermediate routers for 572 request routing or forwarding (e.g., CCN [CCN]) are subject to denial 573 of service attacks from overloading or superseding the internal state 574 of a router (e.g., 'interest flooding' [BACKSCATTER]). Additionally, 575 stateful forwarding can enable attack vectors such as resource 576 exhaustion or complexity attacks to the routing infrastructure. The 577 challenge is then to provision routers and construct internal state 578 in a way that alleviates sensibility to such attacks. The problem 579 becomes even harder, if the protocol does not provide information 580 about the origin of messages. Without origin, it is a particular 581 challenge to distinguish between regular (intense) use and misuse of 582 the infrastructure. 584 4.2.7. Delivering Data Objects from Replicas 586 A common capability of ICN solutions is data replication and in- 587 network storage. Delivering replicated data objects from caches 588 decouples content consumption from data sources, which leads to a 589 loss of control on (1) content access, and (2) content dissemination. 590 In a widely distributed, decentralized environment like the Internet, 591 this raises several challenges. 593 One group of challenges is related to content management. Without 594 access control, a content provider loses the means to count and 595 survey content consumption, to limit access scopes, to control or 596 know about the number of copies of its data in the network, or to 597 withdraw earlier publications reliably. Any non-cooperative or 598 desynchronized data cache may hinder an effective content management 599 policy. 601 Another group of challenges arises from potential traffic 602 amplifications in the decoupled environment. ICN solutions that 603 attempt to retrieve content from several replicas in parallel, or 604 decorrelated network routing states, but also distributed attackers 605 may simultaneously initiate the transmission of content from multiple 606 replicas towards the same destination (e.g., 'initiated overloads' or 607 'blockades' [BACKSCATTER]). Methods for mitigating such threats need 608 rigorous forwarding checks that require alignment with caching 609 procedures (e.g., on-path or off-path). 611 4.2.8. Cryptographic Robustness 613 Content producers sign their content to ensure the integrity of data 614 and to allow for data object authentication. This is a fundamental 615 requirement in ICN due to distributed caching. Publishers, who (a) 616 massively sign content, which is (b) long-lived, offer time and data 617 to an attacker for comprising cryptographic credentials. Signing 618 large amount of data eases common attacks that try to breach the key 619 of the publisher. Based on this observation, the following research 620 challenges emerge: 622 o To which extent does the content publication model conflict with 623 cryptographic limitations? 625 o How can we achieve transparent re-signing without introducing 626 additional cryptographic weaknesses or key management overhead? 628 4.2.9. Routing and Forwarding Information Bases 630 In information-centric networks, one attack vector is to increase the 631 size of routing and forwarding information bases at ICN nodes, i.e., 632 attacking routing scalability in networks that rely on routing by 633 name. This is an intrinsic ICN security issue: possible mitigation 634 approaches include combining routing information authenticity 635 validation with filtering (e.g., maximum de-aggregation level 636 whenever applicable, black lists, etc.). 638 4.3. Routing and Resolution System Scalability 640 ICN routing is a process that finds a NDO based on its name initially 641 provided by a requestor. ICN routing may comprise three steps: (i) 642 name resolution, (ii) discovery, and (iii) delivery. The name 643 resolution step translates the name of the requested NDO into its 644 locator. The discovery step routes the request to data object based 645 on its name or locator. The last step (delivery) routes the data 646 object back to the requestor. Depending on how these steps are 647 combined, ICN routing schemes can be categorized as Route-By-Name 648 Routing (RBNR), Lookup-By-Name Routing (LBNR), and Hybrid Routing 649 (HR) as discussed in the following subsections. 651 4.3.1. Route-By-Name Routing 653 RBNR omits the first name resolution step as the name of the NDO is 654 directly used to route the request to the data object. Therefore, 655 routing information for each data object has to be maintained in the 656 routing table. Since the number of data objects is very large 657 (estimated as 10^11 back in 2007 [DONA] but this may be significantly 658 larger than that, e.g., 10^15 to 10^22), the size of routing tables 659 becomes a concern, as it can be proportional to the number of data 660 objects unless an aggregation mechanism is introduced. On the other 661 hand, RBNR reduces overall latency and simplifies the routing process 662 due to the omission of the resolution process. For the delivery 663 step, RBNR needs another identifier (ID) of either host or location 664 to forward the requested data object back to the requestor. 665 Otherwise, an additional routing mechanism has to be introduced, such 666 as bread-crumbs routing [BREADCRUMBS], in which each request leaves 667 behind a trail of breadcrumbs along its forwarding path, and then the 668 response is forwarded back to the requestor consuming the trail. 670 Challenges specific to RBNR include: 672 o How can we aggregate the names of data objects to reduce the 673 number of routing entries? 675 o How does a user learn the name which is designed for aggregation 676 by provider? For example, although we name our contribution as 677 "ICN research challenges", the IRTF (provider) may want to change 678 the name to "/IETF/IRTF/ICN/Research challenges" for aggregation. 679 In this case, how does a user learn the name "/IETF/IRTF/ICN/ 680 Research challenges" to retrieve the contribution initially named 681 "ICN research challenges" without any resolution process? 683 o Without introducing the name aggregation scheme, can we still 684 achieve scalable routing by taking advantage of topological 685 structure and distributed copies? For example, would employing 686 compact routing [COMPACT], random walk [RANDOM] or greedy routing 687 [GREEDY] work at Internet scale? 689 o How can we incorporate copies of a data object in in-network 690 caches in this routing scheme? 692 o Bread-crumbs routing implies a symmetric path for ICN request and 693 response delivery. Some network configurations and link types 694 prohibit symmetric path forwarding, so it would be challenging to 695 interconnect such networks to bread-crumbs routing-based 696 infrastructure. For example, certain forwarding strategies in 697 Delay-Tolerant Networking (DTN) [RFC4838] are employing 698 opportunistic forwarding where responses cannot be assumed to 699 travel the same path as requests. 701 4.3.2. Lookup-By-Name Routing 703 LBNR uses the first name resolution step to translate the name of the 704 requesting data object into its locator. Then, the second discovery 705 step is carried out based on the locator. Since IP addresses could 706 be used as locators, the discovery step can depend on the current IP 707 infrastructure. The delivery step can be implemented similarly to IP 708 routing. The locator of the requestor is included in the request 709 message, and then the requested data object is delivered to the 710 requestor based on the locator. An instantiation of LBNR is [MDHT]. 712 Challenges specific to LBNR include: 714 o How can we build a scalable resolution system which provides 716 * Fast lookup: mapping the name of data object to its locators 717 (copies as well). 719 * Fast update: the location of data object is expected to change 720 frequently. Also, multiple data objects may change their 721 locations at the same time, e.g., data objects in a laptop. 723 o How can we incorporate copies of a data object in in-network 724 caches in this routing scheme? 726 4.3.3. Hybrid Routing 728 HR combines RBNR and LBNR to benefit from their advantages. Within a 729 single administrative domain, e.g., an ISP, where scalability issues 730 can be addressed with network planning, RBNR can be adopted to reduce 731 overall latency by omitting the resolution process. On the other 732 hand, LBNR can be used to route between domains which have their own 733 prefix (locator). 735 For instance, a request message initially includes the name of NDO 736 for the operation of RBNR, and is forwarded to a cached copy of the 737 NDO or the original server. When the request message fails to find a 738 routing entry in the router, a name resolution step kicks in to 739 translate the name into its locator before forwarding the request 740 message based on the retrieved locator. 742 Challenge specific to HR are: 744 o How can we design a scalable mapping system which, given the name 745 of NDO, should return a destination domain locator so that a user 746 request can be encapsulated and forwarded to the domain? 748 o How to secure the mapping information to prevent a malicious 749 router from hijacking the request message by chaining its locator? 751 o How to maintain the bind between the name and the content of NDO 752 for the verification of its origin and integrity when the name 753 changes due to the retrieved locator? 755 4.4. Mobility Management 757 Mobility management has been an active field in host-centric 758 communications for more than two decades. In IETF in particular, 759 starting with [RFC2002], a multitude of enhancements to IP have been 760 standardized aiming to "allow transparent routing of IP datagrams to 761 mobile nodes in the Internet" [RFC5944]. In a nutshell [MMIN], 762 mobility management for IP networks is locator-oriented and relies on 763 the concept of a mobility anchor as a foundation for providing 764 always-on connectivity to mobile nodes. Other standards 765 organizations, such as 3GPP, have followed similar anchor-based 766 approaches. Traffic to and from the mobile node must flow through 767 the mobility anchor, typically using a set of tunnels, enabling the 768 mobile node to remain reachable while changing its point of 769 attachment to the network. 771 Needless to say, an IP network which supports node mobility is more 772 complex than one that does not, as specialized network entities must 773 be introduced in the network architecture. This is reflected in the 774 control plane as well, which carries mobility-related signaling 775 messages, establishes and tears down tunnels and so on. While mobile 776 connectivity was an afterthought in IP, in ICN this is considered a 777 primary deployment environment. Most, if not all, ICN proposals 778 consider mobility from the very beginning, although at varying levels 779 of architectural and protocol detail. That said, no solution has so 780 far come forward with a definite answer on how to handle mobility in 781 ICN using native primitives. In fact, we observe that mobility 782 appears to be addressed on an ICN proposal-specific basis. That is, 783 there is no single paradigm solution, akin to tunneling through a 784 mobility anchor in host-centric networking, that can be applied 785 across different ICN proposals. For instance, although widely- 786 deployed mobile network architectures typically come with their own 787 network entities and associated protocols, they follow the same line 788 of design with respect to managing mobility. This design thinking, 789 which calls for incorporating mobility anchors, permeates in the ICN 790 literature too. 792 However, employing mobility anchors and tunneling is probably not the 793 best way forward in ICN research for mobile networking. 794 Fundamentally this approach is anything but information-centric and 795 location-independent. In addition, as argued in [SEEN], current 796 mobility management schemes anchor information retrieval not only at 797 a specific network gateway (e.g., home agent in Mobile IP) but due to 798 the end-to-end nature of host-centric communication also at a 799 specific correspondent node. However, once a change in the point of 800 attachment occurs, information retrieval from the original 801 "correspondent node" may be no longer optimal. This was shown in 802 [MANI], for example, where a simple mechanism that triggers the 803 discovery of new retrieval providers for the same data object, 804 following a change in the point of attachment, clearly outperforms a 805 tunnel-based approach like Mobile IP in terms of object download 806 times. The challenge here is how to capitalize on location 807 information while facilitating the use of ICN primitives which 808 natively support multicast and anycast. 810 ICN naming and name resolution, as well as the security features that 811 come along should natively support mobility. For example, CCN [CCN] 812 does not have the restriction of spanning tree routing, so it is able 813 to take advantage of multiple interfaces or adapt to the changes 814 produced by rapid mobility (i.e., there is no need to bind a layer 3 815 address with a layer 2 address). In fact, client mobility can be 816 simplified by allowing requests for new content to normally flow from 817 different interfaces, or through newly connected points of attachment 818 to the network. However, when the node moving is the (only) content 819 source, it appears that more complex network support might be 820 necessary, including forwarding updates and cache rebuilding. A case 821 in point is a conversation network service, such as a voice or video 822 call between two parties. The requirements in this case are more 823 stringent when support for seamless mobility is required, especially 824 when compared to content dissemination that is amenable to buffering. 825 Another parameter that needs to be paid attention to is the impact of 826 using different wireless access interfaces based on different 827 technologies, where the performance and link conditions can vary 828 widely depending of numerous factors. 830 In host-centric networking, mobility management mechanisms ensure 831 optimal handovers and (ideally) seamless transition from one point of 832 attachment to another. In ICN, however, the traditional meaning of 833 "point of attachment" no longer applies as communication is not 834 restrained by location-based access to data objects. Therefore, a 835 "seamless transition" in ICN ensures that content reception continues 836 without any perceptible change from the point of view of the ICN 837 application receiving that content. Moreover, this transition needs 838 to be executed in parallel with ICN content identification and 839 delivery mechanisms enabling scenarios, such as, preparation of the 840 content delivery process at the target connectivity point, prior to 841 the handover (to reduce link switch disturbances). Finally, these 842 mobility aspects can also be tightly coupled with network management 843 aspects, in respect to policy enforcement, link control and other 844 parameters necessary for establishing the node's link to the network. 846 In summary, the following research challenges on ICN mobility 847 management can be derived: 849 o How can mobility management take full advantage of native ICN 850 primitives? 852 o How do we avoid the need for mobility anchors in a network that by 853 design supports multicast, anycast and location-indepedent 854 information retrieval? 856 o How can content retrieval mechanisms interface with specific link 857 operations, such as identifying which links are available for 858 certain content? 860 o How can mobility be offered as a service, which is only activated 861 when the specific user/content/conditions require it? 863 o How can mobility management be coordinated between the node and 864 the network for optimization and policing procedures? 866 o How do we ensure that managing mobility does not introduce 867 scalability issues in ICN? 869 o How will the name resolution process be affected by rapid 870 topological changes, when the content source itself is mobile? 872 4.5. Wireless Networking 874 Today, all layer 2 (L2) wireless network radio access technologies 875 are developed with a clear assumption in mind: the waist of the 876 protocol stack is IP and it will be so for the foreseeable future. 877 By fixing the protocol stack waist, engineers can answer a large set 878 of questions, including how to handle conversational traffic (e.g., 879 voice calls) vs. web traffic, how to support multicast, and so on, in 880 a rather straightforward manner. Broadcast, on the other hand, which 881 is inherent in wireless communication is not fully taken advantage 882 of. On the contrary, researchers are often more concerned about 883 introducing mechanisms that ensure that "broadcast storms" do not 884 take down a network. The question of how can broadcast better serve 885 ICN needs has yet to be thoroughly investigated. 887 Wireless networking is often intertwined with mobility but this is 888 not always the case. In fact, empirical measurements often indicate 889 that many users tend to connect (and remain connected) to a single 890 Wi-Fi access point for considerable amounts of time. A case in 891 point, which is frequently cited in different variations in the ICN 892 literature, is access to a document repository during a meeting. For 893 instance, in a typical IETF working group meeting, a scribe takes 894 notes which are uploaded to a centralized repository (see Figure 1). 895 Subsequently, each meeting participant obtains a copy of the document 896 on their own devices for local use, annotation, and sharing with 897 colleagues that are not present at the meeting. Note that in this 898 example there is no node mobility and that it is not important 899 whether the document with the notes is uploaded in one go at the end 900 of the session or in a streaming-like fashion as is typical today 901 with online (cloud-based) document processing. 903 +---------------------+ 904 | Document Repository | 905 +---------------------+ 906 || 907 (Internet) 908 || 909 +--------------+ 910 | Access Point | 911 +--------------+ 912 / | \ 913 / | \ 914 / | \ 915 Scribe Participant 1 ... Participant N 917 Figure 1: Document sharing during a meeting 919 In this scenario we observe that the same data object bits 920 (corresponding to the meeting notes) need to traverse the wireless 921 medium at least N+1 times, where N is the number of meeting 922 participants obtaining a copy of the notes. In effect, a broadcast 923 medium is shoehorned into N+1 virtual unicast channels. One could 924 argue that wireless local connectivity is inexpensive, but this is 925 not the critical factor in this example. The actual information 926 exchange wastes N times the available network capacity, no matter 927 what is the spectral efficiency (or the economics) underlying the 928 wireless technology. This waste is a direct result of extending the 929 remote access paradigm from wired to wireless communication, 930 irrespective of the special characteristics of the latter. 932 It goes without saying that an ICN approach that does not take into 933 consideration the wireless nature of an interface will waste the same 934 amount of resources as a host-centric paradigm. In-network caching 935 at the wireless access point could reduce the amount of data carried 936 over the backhaul link but, if there is no change in the use of the 937 wireless medium, the NDO will still be carried over the wireless 938 ether N+1 times. Intelligent caching strategies, replica placement 939 cooperation and so on simply cannot alleviate this. On the other 940 hand, promiscuous interface operation and opportunistic caching would 941 maximize wireless network capacity utilization in this example. 943 Arguably, if one designs a future wireless access technology with an 944 information-centric "layer 3" in mind, many of the design choices 945 that are obvious in an all-IP architecture may no longer be valid. 946 Although this is clearly outside the scope of this document, a few 947 research challenges that the wider community may be interested in 948 include: 950 o Can we use wireless resources more frugally with the information- 951 centric paradigm than what is possible today in all-IP wireless 952 networks? 954 o In the context of wireless access, how can we leverage the 955 broadcast nature of the medium in an information-centric network? 957 o Would a wireless-oriented ICN protocol stack deliver significant 958 performance gains? How different would it be from a wired- 959 oriented ICN protocol stack? 961 o Is it possible that by changing the network paradigm to ICN we can 962 in practice increase the spectral efficiency (bits/s/Hz) of a 963 wireless network beyond what would be possible with today's host- 964 centric approaches? What would be the impact of doing so with 965 respect to energy consumption? 967 o Can wireless interface promiscuous operation coupled with 968 opportunistic caching increase ICN performance, and if so, by how 969 much? 971 o How can a conversational service be supported at least as 972 efficiently as today's state-of-the-art wireless networks deliver? 974 o What are the benefits from combining ICN with network coding in 975 wireless networks? 977 o How can MIMO and Coordinated Multipoint Transmission (CoMP) be 978 natively combined with ICN primitives in future cellular networks? 980 4.6. Rate and Congestion Control 982 ICN's receiver-driven communication model as described above creates 983 new opportunities for transport protocol design, as it does not rely 984 solely on end-to-end communication from a sender to a requestor. A 985 requested data object can be accessible in multiple different network 986 locations. A node can thus decide how to utilize multiple sources, 987 e.g., by sending parallel requests for the same NDO or by switching 988 sources (or next hops) in a suitable schedule for a series of 989 requests. 991 In this model, the requestor would control the data rate by 992 regulating its request sending rate and next by performing source/ 993 next-hop selections. Specific challenges depend on the specific ICN 994 approach, but general challenges for receiver-driven transport 995 protocols (or mechanisms, since dedicated protocols might not be 996 required) include flow and congestion control, fairness, network 997 utilization, stability (of data rates under stable conditions) etc. 999 [HRICP] and [ConTug] describe request rate control protocols and 1000 corresponding design challenges. 1002 As mentioned above, the ICN communication paradigm does not depend 1003 strictly on end-to-end flows, as contents might be received from in- 1004 network caches. The traditional concept of a flow is then somewhat 1005 not valid as sub-flows, or flowlets, might be formed on the fly, when 1006 fractions of an NDO are transmitted from in-network caches. For a 1007 transport layer protocol this is challenging, as any measurement 1008 related to this flow as traditionally done by transport protocols 1009 such as TCP, can often prove misleading. For example, false Round- 1010 Trip Time (RTT) measurements will lead to largely variable average 1011 and smoothed RTT values, which in turn will trigger false timeout 1012 expirations. 1014 Furthermore, out-of-order delivery is expected to be common in a 1015 scenario where parts of a data object are retrieved from in-network 1016 caches, rather than from the origin server. Several techniques for 1017 dealing with out-of-order delivery have been proposed in the past for 1018 TCP, some of which could potentially be modified and re-used in the 1019 context of ICN. Further research is needed in this direction though 1020 to choose the right technique and adjust it according to the 1021 requirements of the ICN architecture and transport protocol in use. 1023 ICN offers routers the possibility to aggregate requests and can use 1024 several paths, meaning that there is no such thing as a (dedicated) 1025 end-to-end communication path, e.g., a router that receives two 1026 requests for the same content at the same time only sends one request 1027 to its neighbour. The aggregation of requests has a general impact 1028 on transport protocol design and offers new options for employing 1029 per-node forwarding strategies and for rethinking in-network resource 1030 sharing. [hotnets2014-psaras] 1032 Achieving fairness for requestors can be one challenge as it is not 1033 possible to identify the number of requestors behind one particular 1034 request. A second problem related to request aggregation is the 1035 management of request retransmissions. Generally, it is assumed that 1036 a router will not transmit a request if it transmitted an identical 1037 request recently and because there is no information about the 1038 requestor, the router cannot distinguish the initial request from a 1039 client from a retransmission from the same client. In such a 1040 situation, how routers can adapt their timers to use the best of the 1041 communication paths. 1043 4.7. In-Network Caching 1045 Explicitly named data objects allow for caching at virtually any 1046 network element, including routers, proxy caches and end-user 1047 devices. In-network caching can therefore improve network 1048 performance by fetching content from nodes geographically placed 1049 closer to the end-user. Several issues that need further 1050 investigation have been identified with respect to in-network 1051 caching. In this section we list important challenges that relate to 1052 the properties of the new ubiquitous caching system. 1054 4.7.1. Cache Placement 1056 The declining cost of fast memory gives the opportunity to deploy 1057 caches in network routers and take advantage of cached NDOs. We 1058 identify two approaches to in-network caching, namely, on-path and 1059 off-path caching. Both approaches have to consider the issue of 1060 cache location. Off-path caching is similar to traditional proxy- 1061 caching or CDN server placement. Retrieval of contents from off-path 1062 caches requires redirection of requests and, therefore, is closely 1063 related to the Request-to-Cache Routing problem discussed later. 1064 Off-path caches have to be placed in strategic points within a 1065 network in order to reduce the redirection delays and the number of 1066 detour hops to retrieve cached contents. Previous research on proxy- 1067 caching and CDN deployment is helpful in this case. 1069 On the other hand, on-path caching requires less network intervention 1070 and fits more neatly in ICN. However, on-path caching requires line- 1071 speed operation, which places more constraints on the design and 1072 operation of in-network caching elements. Furthermore, the gain of 1073 such a system of on-path in-network caches relies on opportunistic 1074 cache hits and has therefore been considered of limited benefit, 1075 given the huge amount of contents hosted in the Internet. For this 1076 reason, network operators might initially consider only a limited 1077 number of network elements to be upgraded to in-network caching 1078 elements. The decision on which nodes should be equipped with caches 1079 is an open issue and might be based, among others, on topological 1080 criteria, or traffic characteristics. These challenges relate to 1081 both the Content Placement Problem and the Request-to-Cache Routing 1082 Problem discussed below. 1084 In most cases, however, the driver for the implementation, deployment 1085 and operation of in-network caches will be its cost. Operating 1086 caches at line speed inevitably requires faster memory, which 1087 increases the implementation cost. Based on the capital to be 1088 invested, ISPs will need to make strategic decisions on the cache 1089 placement, which can be driven by several factors, such as: avoid 1090 inter-domain/expensive links, centrality of nodes, size of domain and 1091 the corresponding spatial locality of users, traffic patterns in a 1092 specific part of the network (e.g., university vs. business vs. 1093 fashion district of a city). 1095 4.7.2. Content Placement -- Content-to-Cache Distribution 1097 Given a number of on-path or off-path in-network caching elements, 1098 content-to-cache distribution will affect both the dynamics of the 1099 system, in terms of request redirections (mainly in case of off-path 1100 caches) and the gain of the system in terms of cache hits. A 1101 straightforward approach to content placement is on-path placement of 1102 contents as they travel from source to destination. This approach 1103 reduces the computation and communication overhead of placing content 1104 within the network but, on the other hand, might reduce the chances 1105 of hitting cached contents. This relates to the Request-to-Cache 1106 Routing problem discussed next. 1108 Furthermore, the number of replicas held in the system brings up 1109 resource management issues in terms of cache allocation. For 1110 example, continuously replicating data objects in all network 1111 elements results in redundant copies of the same objects. The issue 1112 of redundant replication has been investigated in the past for 1113 hierarchical web caches. However, in hierarchical web-caching, 1114 overlay systems coordination between the data and the control plane 1115 can guarantee increased performance in terms of cache hits. Line- 1116 speed, on-path in-network caching poses different requirements and 1117 therefore, new techniques need to be investigated. In this 1118 direction, reducing the redundancy of cached copies is a study item. 1119 However, the issue of coordinated content placement in on-path caches 1120 remains open. 1122 The Content-to-Cache Allocation problem relates also to the 1123 characteristics of the content to be cached. Popular content might 1124 need to be placed where it is going to be requested next. 1125 Furthermore, issues of "expected content popularity" or temporal 1126 locality need to be taken into account in designing in-network 1127 caching algorithms in order for some contents to be given priority 1128 (e.g., popular content vs. one-timers). The criteria as to which 1129 contents should be given priority in in-network content caches relate 1130 also to the business relationships between content providers and 1131 network operators. Business model issues will drive some of these 1132 decisions on content-to-cache distribution, but such issues are 1133 outside the scope of this note and are not discussed here further. 1135 4.7.3. Request-to-Cache Routing 1137 In order to take advantage of cached contents, requests have to be 1138 forwarded to the nodes that cache the corresponding contents. This 1139 challenge relates to name-based routing, discussed earlier. Requests 1140 should ideally follow the path to the cached NDO. However, 1141 instructions as to which content is cached where cannot be broadcast 1142 throughout the network. Therefore, the knowledge of a NDO location 1143 at the time of the request might either not exist, or it might not be 1144 accurate (i.e., contents might have been removed by the time a 1145 request is redirected to a specific node). 1147 Coordination between the data and the control planes to update 1148 information of cached contents has been considered, but in this case 1149 scalability issues arise. We therefore, have two options. We either 1150 have to rely on opportunistic caching, where requests are forwarded 1151 to a server and in case the NDOt is found on the path, then the 1152 content is fetched from this node instead of the origin server; or we 1153 employ cache-aware routing techniques. Cache-aware routing can 1154 either involve both the control and the data plane, or only one of 1155 them. Furthermore, cache-aware routing can be done in a domain-wide 1156 scale or can involve more than one individual Autonomous System (AS). 1157 In the latter case, business relationships between ASes might need to 1158 be exploited in order to build a scalable model. 1160 4.7.4. Staleness Detection of Cached NDOs 1162 Due to the largely distributed copies of NDOs in in-network caches, 1163 ICN should be able to provide a staleness verification algorithm 1164 which provides synchronization of NDOs located at their providers and 1165 in-network caching points. Two types of approaches can be considered 1166 for this problem, namely direct and indirect approaches. 1168 In the direct approach, each cache looks up certain information in 1169 the name of NDO, e.g., timestamp which directly indicates its 1170 staleness. This approach is applicable to some NDOs that come from 1171 machine-to-machine and Internet of Things scenarios, whose base 1172 operation relies on obtaining the latest version of that NDO (i.e., a 1173 soil sensor in a farm providing different continuous parameters that 1174 are sent to a display or green-house regulation system) [FRESHNESS]. 1176 In the indirect approach, each cache consults the publisher of the 1177 cached NDO about its staleness before serving it. This approach 1178 assumes that the NDO includes the publisher information which can be 1179 used to reach the publisher. It is suitable for the NDO whose 1180 expiration time is difficult to be set in advance, e.g., a web page 1181 which contains main text (that stays the same ever after) and the 1182 interactive sections such as comments or ads (that are updated 1183 irregularly). 1185 It is often argued that ignoring stale NDOs in caches and simply 1186 providing new names for updated NDOs might be sufficient rather than 1187 using a staleness verification algorithm to manage them. However, 1188 notifying the new names of updated NDOs to users is not a trivial 1189 task. Unless the update is informed to all users at the same time, 1190 some users would use the old name although intending to retrieve the 1191 updated NDO. 1193 One research challenge is how to design consistency and coherence 1194 models for caching NDOs along with their revision handling and 1195 updating protocols in a scalable manner. 1197 4.7.5. Cache Sharing by Multiple Applications 1199 When ICN is deployed as a general, application-independent network 1200 and cache infrastructure, multiple consumers and producers 1201 (representing different applications) would communicate over the same 1202 infrastructure. With universal naming schemes or sufficiently unique 1203 hash-based identifiers different application could also share 1204 identical NDOs in a transparent way. 1206 Depending on the naming, data integrity and data orign authentication 1207 approaches, there may be technical and business challenges to share 1208 caches across different applications, for example content protection, 1209 avoiding cache poisoning, ensuring performance isolation etc. As ICN 1210 research matures, these challenges should be addressed more 1211 specifically in a dedicated document. 1213 4.8. Network Management 1215 Managing networks has been a core craft in the IP-based host-centric 1216 paradigm ever since the technology was introduced in production 1217 networks. However, at the onset of IP, management was considered 1218 primarily as an add-on. Essential tools that are used daily by 1219 networkers, such as ping and traceroute, did not become widely 1220 available until more than a decade or so after IP was first 1221 introduced. Management protocols, such as SNMP, also became 1222 available much later than the original introduction of IP and many 1223 still consider them insufficient despite the years of experience we 1224 have running host-centric networks. Today, when new networks are 1225 deployed network management is considered a key aspect for any 1226 operator, a major challenge which is directly reflected in higher 1227 operational cost if not done well. If we want ICN to be deployed in 1228 infrastructure networks, development of management tools and 1229 mechanisms must go hand-in-hand with the rest of the architecture 1230 design. 1232 Although defining an FCAPS (fault, configuration, accounting, 1233 performance, security) [ISOIEC-7498-4] management model for ICN is 1234 clearly outside the scope of this document, there is a need for 1235 creating basic tools early on while ICN is still in the design and 1236 experimentation phases that can evolve over time and help network 1237 operations centers (NOCs) to define policies, validate that they are 1238 indeed used in practice, be notified early on about failures, 1239 determine and resolve configuration problems. Authentication, 1240 Authorization, Accounting (AAA) as well as performance management, 1241 from a NOC perspective, will also need to be considered. Given the 1242 expectations for a large number of nodes and unprecedented traffic 1243 volumes, automating tasks, or even better employing self-management 1244 mechanisms are preferred. The main challenge here is that all tools 1245 we have at our disposal today are node-centric, end-to-end oriented, 1246 or assuming a packet-stream communication environment. Rethinking 1247 reachability and operational availability, for example, can yield 1248 significant insights into how information-centric networks will be 1249 managed in the future. 1251 With respect to network management we see three different aspects. 1252 First, any operator needs to manage all resources available in the 1253 network, which can range from node connectivity to network bandwidth 1254 availability to in-network storage to multi-access support. In ICN, 1255 users will also bring into the network significant resources in terms 1256 of network coverage extension, storage, and processing capabilities. 1257 Delay Tolerant Networking (DTN) characteristics should also be 1258 considered to the degree that this is possible (e.g., content 1259 dissemination through data mules). Secondly, given that nodes and 1260 links are not at the center of an information-centric network, 1261 network management should capitalize on native ICN mechanisms. For 1262 example, in-network storage and name resolution can be used for 1263 monitoring, while native publish/subscribe functionality can be used 1264 for triggering notifications. Finally, management is also at the 1265 core of network controlling capabilities by allowing operating 1266 actions to be mediated and decided, triggering and activating 1267 networking procedures in an optimized way. For example, monitoring 1268 aspects can be conjugated with different management actions in a 1269 coordinated way, allowing network operations to flow in a concertated 1270 manner. 1272 However, the considerations on leveraging intrinsic ICN mechanisms 1273 and capabilities to support management operations go beyond a simple 1274 mapping exercise. In fact, not only it raises a series of challenges 1275 on its own, but also opens up new possibilities for both ICN and 1276 "network management" as a concept. For instance, naming mechanisms 1277 are central to ICN intrinsic operations, which are used to identify 1278 and reach content under different aspects (e.g., hierarchically 1279 structured vs. 'flattish' names). In this way, ICN is decoupled from 1280 host-centric aspects on which traditional networking management 1281 schemes rely upon. As such, questions are raised which can directly 1282 be translated into challenges for network management capability, such 1283 as, for example how to address a node or a network segment in a ICN 1284 naming paradigm, how to identify which node is connected "where", how 1285 to be aware of the node capabilities (i.e., high or low-powered M2M 1286 node) and if there is a host-centric protocol running where the 1287 management process can also leverage. 1289 But, on the other hand, these same inherent ICN characteristics also 1290 allow us to look into network management through a new perspective. 1291 By centering its operations around NDOs, one can conceive new 1292 management operations addressing, for example, per-content management 1293 or access control, as well as analyzing performance per NDO instead 1294 of per link or node. Moreover, such considerations can also be used 1295 to manage operational aspects of ICN mechanisms themselves. For 1296 example, [NDN-MGMT] re-utilizes inherent content-centric capabilities 1297 of CCN to manage optimal link connectivity for nodes, in concert with 1298 a network optimization process. Conversely, how these content- 1299 centric aspects can otherwise influence and impact management in 1300 other areas (e.g., security, resilience) is also important, as 1301 exemplified in [CCN-ACCESS], where access control mechanisms are 1302 integrated into a prototype of the [PURSUIT] architecture. 1304 The set of core research challenges on ICN management include: 1306 o Management and control of NDO reception at the requestor 1308 o Coordination of management information exchange and control 1309 between ICN nodes and ICN network control points 1311 o Identification of management and controlling actions and items 1312 through information naming 1314 o Relationship between NDOs and host entities identification, i.e., 1315 how to identify a particular link, interface, or flow that need to 1316 be managed. 1318 4.9. ICN Applications 1320 ICN can be applied to different application domains and is expected 1321 to provide benefits for application developers by providing a more 1322 suitable interface for application developers (in addition to the 1323 other ICN benefits described above). [RFC7476] provides an overview 1324 of relevant application domains at large. This section discusses 1325 opportunities and challenges for selected application types. 1327 4.9.1. Web Applications 1329 Intuitively, the ICN request/response communication style seems to be 1330 directly mappable to web communication over HTTP. NDO names could be 1331 the equivalent of URIs in today's web, proprietary and transparent 1332 caching could be obsoleted by ICN in-network caching, and developers 1333 could directly use an ICN request/response API to build applications. 1335 Research efforts such as [ICN2014-WEB-NDN] have analysed real-world 1336 web applications and ways to implement them in ICN. The most 1337 significant insight is that, REST-style web communication heavily 1338 relies on transmitting user/application context information in HTTP 1339 GET requests, which would have to be mapped to corresponding ICN 1340 messages. The challenge in ICN would be how to exactly achieve that 1341 mapping. This could be done to some degree by extending name formats 1342 or by extending message structure to include cookies and similar 1343 context information. The design decisions would need to consider 1344 overhead in routers (if larger GET/Interest messages would have to be 1345 stored in corresponding tables on routers, for example. 1347 Other challenges include the ability to return different results 1348 based on requestor-specific processing in the presence on immutable 1349 objects (and name-object bindings) in ICN and the ability for 1350 efficient bidirectional communication, which would require some 1351 mechanism to name and reach requestor applications. 1353 4.9.2. Video Streaming and Download 1355 One of ICN's prime application areas is video streaming and download 1356 where accessing named data, object-level security and in-network 1357 storage can fulfil requirements for both video streaming and 1358 download. The applicability and benefits of ICN to video has been 1359 demonstrated by several prototype developments 1360 [ICN2014-AHLGREN-VIDEO-DEMO]. 1362 [I-D.irtf-icnrg-videostreaming] discusses the opportunities and 1363 challenges for implementing today's' video services such as DASH- 1364 based streaming and download over ICN, considering performance 1365 requirements, relationship to peer-to-peer live streaming, IPTV and 1366 Digital Rights Management (DRM). 1368 In addition to just porting today's video application from a host- 1369 centric paradigm to ICN there are also promising opportunities to 1370 leverage the ICN network services for redesigning and thus 1371 significantly enhancing video access and distribution 1373 [ICNRG-2015-01-WESTPHAL]. For example, ICN store and forward could 1374 be leveraged for rate adaptation to achieve maximum throughput and 1375 optimal QoE in scenarios with varying link properties, if capacity 1376 information is fed back to rate selection algorithms at senders. 1377 Other optimizations such as more aggressive prefetching could be 1378 performed in the network by leveraging visibility of chunk NDO names 1379 and NDO metadata in the network. Moreover, multi-source rate 1380 adaptation in combination with network coding could enable better 1381 quality of experience, for example in multi-interface/access 1382 scenarios where multiple paths from client to upstream caches exist 1383 [RFC7476]. 1385 4.9.3. Internet of Things 1387 The essence of ICN lies in the name based routing that enables users 1388 to retrieve NDOs by the names regardless of their locations. By the 1389 definition, ICN is suitable well for IoT applications, where users 1390 consume data generated from IoTs without maintaining secure 1391 connections to them. The basic put/get style APIs of ICN enable 1392 developers to build IoT applications in a simple and fast manner. 1394 On-going efforts such as [I-D.lindgren-icnrg-efficientiot], 1395 [I-D.zhang-iot-icn-challenges], [ICN2014-NDNWILD] have addressed the 1396 requirements and challenges of ICN for IoT. For instance, many IoT 1397 applications depend on a PUSH model where data transmission is 1398 initiated by the publisher, and so they can support various real-time 1399 applications: emergency alarm, etc. However, ICN does not support 1400 the PUSH model in a native manner due to its inherent receiver-driven 1401 data transmission mechanism. The challenge would be how to 1402 efficiently support the PUSH model in ICN, and so it provides 1403 publish/subscribe style APIs for IoT application developers. This 1404 could be done by introducing other types of identifiers such as a 1405 device identifier or by extending the current request/response 1406 communication style, which may result in heavy overhead in ICN 1407 routers. 1409 Moreover, key characteristics of the ICN underlying operation also 1410 impact important aspects of IoT, such as the caching in content 1411 storage of network forwarding entities. This allows the 1412 simplification of ICN-based IoT application development, since the 1413 network is able to act on named content, generic names provide a way 1414 to address content independently of the underlying device (and 1415 access) technology, and bandwidth consumption is optimized due to the 1416 availability of cached content. However, these aspect raise 1417 challenges themselves, concerning the freshness of the information 1418 received from the cache in contrast to the last value generated by a 1419 sensor, as well as pushing content to specific nodes (e.g., for 1420 controlling them), which requires individual addressing for 1421 identification. In addition, due to the heterogeneous nature of IoT 1422 nodes, their processing capabilities might not be able to handle the 1423 necessary content signing verification procedures. 1425 5. Security Considerations 1427 This document does not impact the security of the Internet. ICN 1428 security-related questions related to ICN are discussed in 1429 Section 4.2. 1431 6. IANA Considerations 1433 This document presents no IANA considerations. 1435 7. Informative References 1437 [access-control-delegation] 1438 Fotiou, N., Marias, G., and G. Polyzos, "Access control 1439 enforcement delegation for information-centric networking 1440 architectures", Proceedings of the second edition of the 1441 ICN workshop on Information-centric networking (ICN '12) 1442 Helsinki, Finnland, 2012. 1444 [BACKSCATTER] 1445 Waehlisch, M., Schmidt, TC., and M. Vahlenkamp, 1446 "Backscatter from the Data Plane - Threats to Stability 1447 and Security in Information-Centric Network 1448 Infrastructure", Computer Networks Vol 57, No. 16, pp. 1449 3192-3206, November 2013. 1451 [BREADCRUMBS] 1452 Rosensweig, E. and J. Kurose, "Breadcrumbs: Efficient, 1453 Best-Effort Content Location in Cache Networks", In 1454 Proceedings of the IEEE INFOCOM 2009, April 2009. 1456 [CCN] Jacobson, , K, , D, , F, , H, , and L, "Networking Named 1457 Content", CoNEXT 2009 , December 2009. 1459 [CCN-ACCESS] 1460 Fotiou, N., Marias, G., and G. Polyzos, "Access control 1461 enforcement delegation for information-centric networking 1462 architectures", In Proceedings of the second edition of 1463 the ICN workshop on Information-centric networking (ICN 1464 '12). ACM, New York, NY, USA, 85-90., 2012. 1466 [Chaum] Chaum, D. and E. van Heijst, "Group signatures", In 1467 Proceedings of EUROCRYPT, 1991. 1469 [COMPACT] Cowen, L., "Compact routing with minimum stretch", In 1470 Journal of Algorithms, vol. 38, pp. 170--183, 2001. 1472 [ConTug] Arianfar, S., Nikander, P., Eggert, L., Ott, J., and W. 1473 Wong, "ConTug: A Receiver-Driven Transport Protocol for 1474 Content-Centric Networks", Technical Report Aalto 1475 University Comnet, 2011. 1477 [DONA] Koponen, T., Ermolinskiy, A., Chawla, M., Kim, K., gon 1478 Chun, B., and S. Shenker, "A Data-Oriented (and Beyond) 1479 Network Architecture", In Proceedings of SIGCOMM 2007, 1480 August 2007. 1482 [encryption-ac] 1483 Kurihara, J., Uzun, E., and C. Wood, "An Encryption-Based 1484 Access Control Framework for Content-Centric Networking", 1485 IFIP Networking 2015 Toulouse, France, 2015, September 1486 2015. 1488 [FRESHNESS] 1489 Quevedo, J., Corujo, D., and R. Aguiar, "Consumer Driven 1490 Information Freshness Approach for Content Centric 1491 Networking", IEEE INFOCOM Workshop on Name-Oriented 1492 Mobility Toronto, Canada, 2014, May 2014. 1494 [GREEDY] Papadopoulos, F., Krioukov, D., Boguna, M., and A. Vahdat, 1495 "Greedy forwarding in dynamic scale-free networks embedded 1496 in hyperbolic metric spaces", In Proceedings of the IEEE 1497 INFOCOM, San Diego, USA, 2010. 1499 [hotnets2014-psaras] 1500 Psaras, I., Saino, L., and G. Pavlou, "Revisiting Resource 1501 Pooling: The case of In-Network Resource Sharing", ACM 1502 HotNets Los Angeles, USA, 2014, October 2014. 1504 [HRICP] Carofiglio, G., Gallo, M., and L. Muscariello, "Joint hop- 1505 by-hop and receiver-driven interest control protocol for 1506 content-centric networks", In Proceedings of ACM SIGCOMM 1507 ICN 2012, DOI 10.1145/2342488.2342497, 2012. 1509 [I-D.irtf-icnrg-videostreaming] 1510 Lederer, S., cedric.westphal@huawei.com, c., Mueller, C., 1511 Detti, A., Corujo, D., Wang, J., Montpetit, M., Murray, 1512 N., aytav.azgin, a., LIU, S., Timmerer, C., and D. Posch, 1513 "Adaptive Video Streaming over ICN", draft-irtf-icnrg- 1514 videostreaming-05 (work in progress), December 2015. 1516 [I-D.lindgren-icnrg-efficientiot] 1517 Lindgren, A., Abdesslem, F., Ahlgren, B., Schelen, O., and 1518 A. Malik, "Applicability and Tradeoffs of Information- 1519 Centric Networking for Efficient IoT", draft-lindgren- 1520 icnrg-efficientiot-03 (work in progress), July 2015. 1522 [I-D.zhang-iot-icn-challenges] 1523 Zhang, Y., Raychadhuri, D., Grieco, L., Baccelli, E., 1524 Burke, J., Ravindran, R., and G. Wang, "ICN based 1525 Architecture for IoT - Requirements and Challenges", 1526 draft-zhang-iot-icn-challenges-02 (work in progress), 1527 August 2015. 1529 [ICN2014-AHLGREN-VIDEO-DEMO] 1530 Ahlgren, B., Jonasson, A., and B. Ohlman, "Demo Overview: 1531 HTTP Live Streaming over NetInf Transport", ACM SIGCOMM 1532 Information-Centric Networking Conference Paris, France, 1533 2014, September 2014. 1535 [ICN2014-NDNWILD] 1536 Baccelli, E., Mehlis, C., Hahm, O., Schmidt, T., and M. 1537 Waehlisch, "Information Centric Networking in the IoT: 1538 Experiments with NDN in the Wild", ACM SIGCOMM 1539 Information-Centric Networking Conference Paris, France, 1540 2014, September 2014. 1542 [ICN2014-WEB-NDN] 1543 Moiseenko, I., Stapp, M., and D. Oran, "Communication 1544 Patterns for Web Interaction in Named Data Networking", 1545 ACM SIGCOMM Information-Centric Networking Conference 1546 Paris, France, 2014, September 2014. 1548 [ICNNAMING] 1549 Ghodsi, A., Koponen, T., Rajahalme, J., Sarolahti, P., and 1550 S. Shenker, "Naming in Content-Oriented Architectures", In 1551 Proceedings ACM SIGCOMM Workshop on Information-Centric 1552 Networking (ICN), 2011. 1554 [ICNRG-2015-01-WESTPHAL] 1555 Westphal, C., "Video over ICN", IRTF ICNRG Meeting 1556 Cambridge, Massachusetts, USA, 2015, URI 1557 http://www.ietf.org/proceedings/interim/2015/01/13/icnrg/ 1558 slides/slides-interim-2015-icnrg-1-0.pptx, January 2015. 1560 [ICNSURVEY] 1561 Ahlgren, B., Dannewitz, C., Imbrenda, C., Kutscher, D., 1562 and B. Ohlman, "A Survey of Information-Centric 1563 Networking", In Communications Magazine, IEEE , vol.50, 1564 no.7, pp.26-36, DOI 10.1109/MCOM.2012.6231276, 2012. 1566 [ISOIEC-7498-4] 1567 ISO, , "Information Processing Systems -- Open Systems 1568 Interconnection -- Basic Reference Model -- Part 4: 1569 Management Framework", URI 1570 http://standards.iso.org/ittf/PubliclyAvailableStandards/ 1571 s014258_ISO_IEC_7498-4_1989(E).zip, November 1989. 1573 [MANI] Pentikousis, K. and T. Rautio, "A multiaccess Network of 1574 Information", WoWMoM 2010, IEEE , June 2010. 1576 [MDHT] D'Ambrosio, M., Dannewitz, C., Karl, H., and V. 1577 Vercellone, "MDHT: A hierarchical name resolution service 1578 for information-centric networks", ACM SIGCOMM workshop on 1579 Information-centric networking Toronto, Canada, 2011, 1580 August 2011. 1582 [MMIN] Pentikousis, K. and P. Bertin, "Mobility management in 1583 infrastructure networks", Internet Computing, IEEE, vol. 1584 17, no. 5, pp. 74-79 , October 2013. 1586 [ndn-controlled-sharing] 1587 Yu, Y., "Controlled Sharing of Sensitive Content", IRTF 1588 ICNRG Meeting San Francisco, USA, 2015, URI 1589 https://www.ietf.org/proceedings/interim/2015/10/03/icnrg/ 1590 slides/slides-interim-2015-icnrg-4-8.pdf, October 2015. 1592 [NDN-MGMT] 1593 Corujo, D., Aguiar, R., Vidal, I., and J. Garcia-Reinoso, 1594 "A named data networking flexible framework for management 1595 communications", Communications Magazine, IEEE , vol.50, 1596 no.12, pp.36-43 , December 2012. 1598 [PURSUIT] Fotiou et al., N., "Developing Information Networking 1599 Further: From PSIRP to PURSUIT", In Proceedings of Proc. 1600 BROADNETS. ICST, 2010. 1602 [RANDOM] Gkantsidis, C., Mihail, M., and A. Saberi, "Random walks 1603 in peer-to-peer networks: algorithms and evaluation", In 1604 Perform. Eval., vol. 63, pp. 241--263, 2006. 1606 [RFC2002] Perkins, C., Ed., "IP Mobility Support", RFC 2002, DOI 1607 10.17487/RFC2002, October 1996, 1608 . 1610 [RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, 1611 R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant 1612 Networking Architecture", RFC 4838, DOI 10.17487/RFC4838, 1613 April 2007, . 1615 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1616 (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/ 1617 RFC5246, August 2008, 1618 . 1620 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1621 Housley, R., and W. Polk, "Internet X.509 Public Key 1622 Infrastructure Certificate and Certificate Revocation List 1623 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 1624 . 1626 [RFC5944] Perkins, C., Ed., "IP Mobility Support for IPv4, Revised", 1627 RFC 5944, DOI 10.17487/RFC5944, November 2010, 1628 . 1630 [RFC6920] Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B., 1631 Keranen, A., and P. Hallam-Baker, "Naming Things with 1632 Hashes", RFC 6920, DOI 10.17487/RFC6920, April 2013, 1633 . 1635 [RFC7476] Pentikousis, K., Ed., Ohlman, B., Corujo, D., Boggia, G., 1636 Tyson, G., Davies, E., Molinaro, A., and S. Eum, 1637 "Information-Centric Networking: Baseline Scenarios", RFC 1638 7476, DOI 10.17487/RFC7476, March 2015, 1639 . 1641 [SEEN] Pentikousis, K., "In search of energy-efficient mobile 1642 networking", Communications Magazine, IEEE, vol. 48, no. 1643 1, pp. 95-103 , January 2010. 1645 Appendix A. Acknowledgments 1647 The authors would like to thank Georgios Karagiannis for providing 1648 suggestions on QoS research challenges, Dimitri Papadimitriou for 1649 feedback on the routing section, and Joerg Ott and Stephen Farrell 1650 for reviewing the whole document. 1652 Authors' Addresses 1654 Dirk Kutscher (editor) 1655 NEC 1656 Kurfuersten-Anlage 36 1657 Heidelberg 1658 Germany 1660 Email: kutscher@neclab.eu 1662 Suyong Eum 1663 National Institute of Information and Communications Technology 1664 4-2-1, Nukui Kitamachi, Koganei 1665 Tokyo 184-8795 1666 Japan 1668 Phone: +81-42-327-6582 1669 Email: suyong@nict.go.jp 1671 Kostas Pentikousis 1672 EICT GmbH 1673 Torgauer Strasse 12-15 1674 Berlin 10829 1675 Germany 1677 Email: k.pentikousis@eict.de 1679 Ioannis Psaras 1680 University College London, Dept. of E.E. Eng. 1681 Torrington Place 1682 London WC1E 7JE 1683 United Kingdom 1685 Email: i.psaras@ucl.ac.uk 1687 Daniel Corujo 1688 Universidade de Aveiro 1689 Instituto de Telecomunicacoes, Campus Universitario de Santiago 1690 Aveiro P-3810-193 1691 Portugal 1693 Email: dcorujo@av.it.pt 1694 Damien Saucez 1695 INRIA 1696 2004 route des Lucioles - BP 93 1697 Sophia Antipolis 06902 Cedex 1698 France 1700 Email: damien.saucez@inria.fr 1702 Thomas C. Schmidt 1703 HAW HAmburg 1704 Berliner Tor 7 1705 Hamburg 20099 1706 Germany 1708 Email: t.schmidt@ieee.org 1710 Matthias Waehlisch 1711 FU Berlin 1712 Takustr. 9 1713 Berlin 14195 1714 Germany 1716 Email: waehlisch@ieee.org