idnits 2.17.1 draft-kutscher-icnrg-challenges-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 15, 2013) is 3938 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- 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: 1 error (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Kutscher, Ed. 3 Internet-Draft NEC 4 Intended status: Standards Track S. Eum 5 Expires: January 16, 2014 NICT 6 K. Pentikousis 7 Huawei 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 July 15, 2013 20 ICN Research Challenges 21 draft-kutscher-icnrg-challenges-01 23 Abstract 25 This memo describes research challenges for Information-Centric 26 Networking. Information-centric networking is an approach to evolve 27 the Internet infrastructure to directly support this use by 28 introducing uniquely named data as a core Internet principle. Data 29 becomes independent from location, application, storage, and means of 30 transportation, enabling in-network caching and replication. 31 Challenges include naming, security, routing, system scalability, 32 mobility management, wireless networking, transport services, in- 33 network caching, and network management. 35 Status of this Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at http://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on January 16, 2014. 51 Copyright Notice 53 Copyright (c) 2013 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. Problems with Information Distribution Today . . . . . . . . . 4 67 3. ICN Terminology and Concepts . . . . . . . . . . . . . . . . . 5 68 3.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 69 3.2. Concepts . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 4. ICN Research Challenges . . . . . . . . . . . . . . . . . . . 7 71 4.1. Naming and data authenticity . . . . . . . . . . . . . . . 7 72 4.2. Security . . . . . . . . . . . . . . . . . . . . . . . . . 9 73 4.2.1. Data Object Authentication . . . . . . . . . . . . . . 9 74 4.2.2. Binding NDOs to Real-World Identities . . . . . . . . 10 75 4.2.3. Traffic aggregation and filtering . . . . . . . . . . 10 76 4.2.4. State overloading . . . . . . . . . . . . . . . . . . 11 77 4.2.5. Traffic on data object replicas . . . . . . . . . . . 11 78 4.2.6. Cryptographic robustness . . . . . . . . . . . . . . . 11 79 4.2.7. Routing and forwarding information bases . . . . . . . 11 80 4.3. Routing and Resolution System Scalability . . . . . . . . 12 81 4.3.1. Route-By-Name Routing (RBNR) . . . . . . . . . . . . . 12 82 4.3.2. Lookup-By-Name Routing (LBNR) . . . . . . . . . . . . 13 83 4.3.3. Hybrid Routing (HR) . . . . . . . . . . . . . . . . . 13 84 4.4. Mobility Management . . . . . . . . . . . . . . . . . . . 14 85 4.5. Wireless Networking . . . . . . . . . . . . . . . . . . . 16 86 4.6. Transport Services . . . . . . . . . . . . . . . . . . . . 18 87 4.7. In-Network Caching . . . . . . . . . . . . . . . . . . . . 19 88 4.7.1. Cache Placement . . . . . . . . . . . . . . . . . . . 20 89 4.7.2. Content Placement -- Content-to-Cache Distribution . . 21 90 4.7.3. Request-to-Cache Routing . . . . . . . . . . . . . . . 21 91 4.8. Network Management . . . . . . . . . . . . . . . . . . . . 22 92 5. Link to and Impact on IETF Technologies . . . . . . . . . . . 24 93 6. Security Considerations . . . . . . . . . . . . . . . . . . . 24 94 7. Informative References . . . . . . . . . . . . . . . . . . . . 24 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 97 1. Introduction 99 Distributing and manipulating named information is a major 100 application in the Internet today. In addition to web-based content 101 distribution, other distribution technologies (such as P2P and CDN) 102 have emerged and are promoting a communication model of accessing 103 data by name, regardless of origin server location. 105 In order to respond to increasing traffic volume in the current 106 Internet for applications such as mobile video and cloud computing, a 107 set of disparate technologies and distribution services are applied 108 that employ caching, replication and content distribution in 109 different specific ways. These approaches are currently deployed in 110 separate silos -- different CDN providers and P2P applications rely 111 on own, often proprietary, distribution technologies. It is not 112 possible to uniquely and securely identify named information 113 independently of the distribution channel; and the different 114 distribution approaches are typically implemented as an overlay, 115 potentially leading to unnecessary inefficiency. 117 For example, creating and sharing multimedia content in a social 118 networking application today, typically requires uploading data 119 objects to centralized service provider platforms, from where it can 120 be accessed individually by other users. Even if content sharing is 121 intended to happen locally, e.g., in a local network or local area, 122 the actual communication will require interactions from any 123 interested user with the service provider. CDNs can alleviate the 124 situation only partly, because, due to organizational and economic 125 reasons, it is not common to deploy CDN gear ubiquitously. Moreover, 126 since CDNs and the respective communication sessions form overlays, 127 the actual communication, i.e., the requests for named content and 128 the actual responses, are largely invisible to the network, i.e., it 129 is not easily possible to optimize efficiency and performance. For 130 example in a wireless access network, it is not possible to leverage 131 the inherent broadcast nature of the medium (and avoid duplicate 132 transmission of the same content) due to limitations from point-to- 133 point and overlay communication. 135 Information-centric networking (ICN) is an approach to evolve the 136 Internet infrastructure to directly support this use by introducing 137 named data as a core network-layer primitive. Data objects become 138 independent of location, application, storage, and means of 139 transportation, allowing for inexpensive and ubiquitous in-network 140 caching and replication. The expected benefits are improved 141 efficiency, better support for provenance verification and name- 142 content binding validation, better scalability with respect to 143 information/bandwidth demand and better robustness in challenging 144 communication scenarios. 146 ICN concepts can be deployed by retooling the protocol stack: name- 147 based data access can be implemented on top of the existing IP 148 infrastructure, e.g., by providing resource naming, ubiquitous 149 caching and corresponding transport services, or it can be seen as a 150 packet-level internetworking technology that would cause fundamental 151 changes to Internet routing and forwarding. In summary, ICN is 152 expected to evolve the Internet architecture towards a network model 153 that is more suitable for the current and future use patterns. 155 This document presents the ICN research challenges that need to be 156 addressed in order to achieve these goals. These research challenges 157 are seen from a technical perspective, although business 158 relationships between Internet players will also influence 159 developments in this area. We leave business challenges for a 160 separate document, however. The objective of this note is to 161 document the technical challenges and corresponding current 162 approaches and to expose requirements that should be addressed by 163 future research work. 165 2. Problems with Information Distribution Today 167 The best current practice to manage the above-mentioned growth in 168 terms of data volume and number of devices is to increase 169 infrastructure investment, employ application-layer overlays such as 170 CDNs, P2P applications, and M2M application platforms that cache 171 content, provide location-independent access to data, and optimize 172 its delivery. In principle, such platforms provide a service model 173 of accessing named data objects (NDOs) (e.g. replicated web 174 resources, M2M data in data centers) instead of a host-to-host packet 175 delivery service model. 177 However, since this functionality resides in overlays only, the full 178 potential of content distribution and M2M application platforms 179 cannot be leveraged as the network is not aware of data requests and 180 data transmissions. This has the following impact: 182 o data traffic typically follows sub-optimal paths as it is 183 effectively routed depending on the overlay topology instead of 184 the Internet layer topology; 186 o network capabilities, such as multicast and broadcast, are largely 187 underutilized or not employed at all. As a result, request and 188 delivery for the same object have to be made multiple times; 190 o overlays typically require significant infrastructure support, 191 e.g., authentication portals, content storage, and applications 192 servers, making it often impossible to establish local, direct 193 communication; 195 o since the network is not aware of the nature of data objects, it 196 is unable to manage access and transmission (without layer 197 violations); 199 o provenance validation uses host authentication today. As such, 200 even if there are locally cached copies available, it is normally 201 not easily possible to validate their authenticity; and 203 o many applications follow their own approach to caching, 204 replication, transport, authenticity validation (if at all), 205 although they all share similar models for accessing named data 206 objects in the network. 208 3. ICN Terminology and Concepts 210 3.1. Terminology 212 This section defines ICN some terms that are used in this document. 214 Named Data Object (NDO): Addressable data unit in an ICN that can 215 represent a collection of bytes or a piece of information. In 216 ICN, each data object has a name bound to it, and there are 217 typically mechanisms to secure (and validate) this binding. 219 Requestor: Entitiy in an ICN network that is sending a request for a 220 Named Data Object to the network. 222 3.2. Concepts 224 Fundamentally, ICN is providing access to named data as a first-order 225 network service, i.e., the network is able to serve requests to named 226 data natively. That means, network nodes can receive requests for 227 named data and act as necessary, for example, by forwarding the 228 request to a suitable next-hop. Consequently, the network processes 229 requests for named data objects (and corresponding responses) 230 natively. Every network node on a path is enabled to perform 231 forwarding decisions, to cache objects etc. This enables the network 232 to forward such requests on optimal paths, employing the best 233 transmission technologies at every node, e.g., broadcast/multicast 234 transmission in wireless networks to avoid duplicate transmission of 235 both requests and responses. 237 In ICN there is a set of common concepts and node requirements beyond 238 this basic service model. Naming data objects is a key concept. In 239 general, ICN names represent neither network nodes nor interfaces -- 240 they represent NDOs independent of their location. Names do play a 241 key role in forwarding decisions and are used for matching requests 242 to responses: In order to provide better support for accessing copies 243 of NDOs regardless of their location, it is important to be able to 244 validate that a response actually delivers the bits that correspond 245 to an original request for named data. 247 Name-content binding validation is a fundamental security service in 248 ICN, and this is often achieved by establishing a verifiable binding 249 between the object name and the actual object or an identity that has 250 created the object. ICN can support other security services, such as 251 provenance validation, encryption -- depending on the details of 252 naming schemes, object models and assumptions on infrastructure 253 support. Security services such as name-content binding validation 254 are available to any node, i.e., not just the actual receivers. This 255 is an important feature, for enabling ingress gateways to check 256 object authenticity to prevent denial-of-service attacks. 258 Based on these fundamental properties it is possible to leverage 259 network storage ubiquitously: every node and every device can cache 260 data objects and respond to requests for such objects -- it is not 261 required to validate the authenticity of the node itself since name- 262 content bindings can be validated. Ubiquitous in-network storage can 263 be used for different purposes: it can enable sharing, i.e., the same 264 object copy can be delivered to multiple users/nodes as in today's 265 proxy caches and CDNs. It can also be used to make communication 266 more robust (and perform better) by enabling the network to answer 267 requests from local caches (instead of from origin servers). In case 268 of disruption (message not delivered), a node can re-send the 269 request, and it could be answered by an on-path cache, i.e., on the 270 other side of the disrupted link. The network itself would thus 271 support retransmissions -- enabling shorter round-trip times and 272 offloading origin servers and other parts of the network. 274 The request/response model and ubiquitous in-network storage also 275 enables new options for implementing transport services, i.e., 276 reliable transmission, flow control etc. First of all, a request/ 277 response model can enable receiver-driven transport regimes, i.e., 278 receivers (the requestors of NDOs) can control message sending rates 279 by regulating the request sending rate (assuming that every response 280 message has to be triggered by a request message). Retransmission 281 would be achieved by re-sending requests, e.g., after a timeout. 282 Because objects can be replicated, object transmission and transport 283 sessions would not necessarily have end-to-end semantics: requests 284 can be answered by caches, and a node can select one or multiple 285 next-hop destination for a particular request -- depending on 286 configuration, observed performance or other criteria. 288 This receiver-driven communication model potentially enables new 289 interconnection and business models: a request for named data can be 290 linked to an interest of a requestor (or requesting network) in data 291 from another peer, which could suggest modeling peering agreements 292 and charging accordingly. 294 4. ICN Research Challenges 296 4.1. Naming and data authenticity 298 Naming data objects is as important for ICN as naming hosts is for 299 today's Internet. Fundamentally, ICN requires unique names for 300 individual NDOs, since names are used for identifying objects 301 independently of their location or container. In addition, since 302 NDOs can be cached anywhere, the origin cannot be trusted anymore 303 hence the importance to establish a verifiable binding between the 304 object and its name (name-data integrity) so that a receiver can be 305 sure that the received bits do correspond to the NDO originally 306 requested (object authenticity). Information about an object's 307 provenance, i.e., who generated or published it, is also useful to 308 associate to the name. 310 The above functions are fundamentally required for the information- 311 centric network to work reliably, otherwise neither network elements 312 nor receivers can trust object authenticity. Lack of this trust 313 enables several attacks including critical DoS attacks by injecting 314 spoofed content into the network. There are different ways to use 315 names and cryptography to achieve the desired functions [ICNNAMING] 316 [ICNSURVEY], and there are different ways to manage namespaces 317 correspondingly. 319 Two types of naming schemes have been proposed in the ICN literature: 320 hierarchical and flat namespaces. For example, a hierarchical scheme 321 may have a structure similar to current URIs, where the hierarchy is 322 rooted in a publisher prefix. Such hierarchy enables aggregation of 323 routing information, improving scalability of the routing system. In 324 some cases, the names are human-readable, which makes it possible for 325 users to manually type in names, reuse, and, to some extent, map the 326 name to user intent. 328 The second general class of naming schemes follows a "self- 329 certifying" approach, meaning that the object's name-data integrity 330 can be verified without requiring a public key infrastructure (PKI) 331 or other third party to first establish trust in the key. Self- 332 certification is achieved by binding the hash of the NDO content to 333 the object's name. For instance, this can be done by directly 334 embedding the hash of the content in the name. Another option is an 335 indirect binding, which embeds the public key of the publisher in the 336 name and signs the hash of the content with the corresponding secret 337 key. The resulting names are typically non-hierarchical, or flat, 338 although the publisher field could be employed to create a structure 339 which could facilitate route aggregation. There are several design 340 trade-offs for ICN naming, which affect routing and security. Self- 341 certifying names are not human readable nor hierarchical. They can 342 however provide some structure for aggregation, for instance, a name 343 part corresponding to a publisher. 345 Research challenges specific to naming include: 347 o naming static data objects can be performed by using content 348 hashes as part of object names, so that publishers calculate the 349 hash over existing data objects and receivers (or any ICN node) 350 can validate the name-content binding by re-calculating the hash 351 and comparing it to the name (component). [RFC6920] specifies a 352 concrete naming format for this. 354 o naming dynamic objects refers to use cases where the name has to 355 be generated before the object is created. For example, this 356 could be the case for live streaming, when a publisher wants to 357 make the stream available by registering stream chunk names in the 358 network. One approach to this can be self-certified names as 359 described above. 361 o requestor privacy protection can be a challenge in ICN as a direct 362 consequence of the accessing-named-data-objects paradigm: if the 363 network can "see" requests and responses, it can also log request 364 history for network segments or individual users, which can be 365 undesirable, especially since names are typically expected to be 366 long-lived. That is, even if the name itself does not reveal much 367 information, the assumption is that the name can be used to 368 retrieve the corresponding data objects in the future. 370 o Updating and versioning NDO can be challenging because it can 371 contradict fundamental ICN assumptions: if an NDO can be 372 replicated and stored in in-network storage for later retrieval, 373 names have to be long-lived -- and the name-content binding must 374 not change: updating an object (i.e., changing the content without 375 generating a new name) is impossible. Versioning is one possible 376 solution, but requires a naming scheme that supports it (and a way 377 for requestors to learn about versions). 379 o Managing accessibility: whereas in ICN the general assumption is 380 to enable ubiquitous access to NDOs, there can be relevant use 381 cases where access to objects should be restricted, for example to 382 a specific user group. There are different approaches for this, 383 such as object encryption (requiring key distribution and related 384 mechanisms) or the concept of scopes, e.g., based on names that 385 can only be used/resolved under some constraints. 387 4.2. Security 389 Security can take many different forms in ICN and instead of 390 discussing specific attacks or technical details, we propose here the 391 most important security challenges that come from the shift to 392 information-centric communications. Some challenges are well- 393 understood, and there are (sometimes multiple different) approaches 394 to address them, whereas other challenges are active research and 395 engineering topics. 397 4.2.1. Data Object Authentication 399 As mentioned in section Section 4.1, data object authentication is an 400 important ICN feature, since ICN data objects are retrieved not only 401 from an original copy holder but also from any caching point. Hence, 402 the communication channel endpoints to retrieve NDOs are not 403 trustable anymore and solutions widely used today such as TLS 404 [RFC5246] cannot be used. Since data objects can be maliciously 405 modified ICN should provide users with a security mechanism to verify 406 the origin and integrity of the data object, and there are different 407 ways to achieve this. 409 An efficient approach for static NDOs is providing a name-content- 410 binding by hashing an NDO and using the hash as a part of the 411 object's name. [RFC6920] provides a mechanism and a format for 412 representing a digest algorithm and the actual digest in a name 413 (amongst other information). 415 For dynamic objects (where it is desirable to refer to an NDO by name 416 before the object has been created), public-key cryptography is often 417 applied, i.e., every NDO would be authenticated by means of a 418 signature performed by the data object publisher so that any data 419 object consumer can verify the validity of the data object based on 420 the signature. However, in order to verify the signature of an 421 object, the consumer must know the public key of the entity that 422 signed the object. 424 One research challenge is then to support a mechanism to distribute 425 the publisher's public keys to the consumers of data objects. There 426 are two main approaches to achieve this; one is based on an external 427 third party authority such as hierarchical Public Key Infrastructure 428 (PKI) [RFC5280] and the other is to adapt a self-certifying scheme. 429 The former, as the name implies, depends on an external third party 430 authority to distribute the public key of the publisher for the 431 consumers. In a self-certifying scheme, the public key (or a hash of 432 it) would be used as part of the name -- which is sufficient to 433 validate the object's authenticity. 435 In cases where information about the origin of a data object is not 436 available by other means, the object itself would have to incorporate 437 the necessary information to determine the object publisher, for 438 example with a certificate, that can be validated through the PKI. 439 Once the certificate is authenticated, its public key can be used to 440 authenticate the signed data object itself. 442 4.2.2. Binding NDOs to Real-World Identities 444 In addition to validating NDO authenticity, it is still important to 445 bind real-world identities, e.g., a publisher identity, to objects, 446 so that a requestor can verify that a received object was actually 447 published by a certain source. 449 With hash-based and self-certifying names, real-world-identity 450 bindings are not intrinsically established: the name provides the 451 hash of the NDO or of the public key that has been used to sign the 452 NDO. There needs to be another binding to a real-world-identity if 453 that feature is requested. 455 If the object name directly provides the publisher name and if that 456 name is protected by a certificate that links to PKI-like trust 457 chain, the object name itself can provide an intrinsic binding to a 458 real-world identity. 460 Binding between NDOs and Real-World Identities is essential but there 461 is no universal way to achieve it as it is all intrinsic to the 462 particular ICN approach. 464 4.2.3. Traffic aggregation and filtering 466 One request message to retrieve a data object can actually aggregate 467 requests coming from several consumers. This aggregation of requests 468 reduces the overall traffic but makes per-requestor filtering harder. 469 The challenge in this case is to provide a mechanism that allows 470 requests aggregation and per-requestor filtering. A possible 471 solution is to indicate the set of requestors in the aggregated 472 request such that the response can indicate the subset of requestors 473 allowed to access the data object. However, this solution requires 474 collaboration from other nodes in the network and is not suitable for 475 caching. Another possible solution is the encrypt data objects and 476 ensure that only authorised consumers can decrypt them. This 477 solution does not preclude caching and does not require collaboration 478 from the network. However, it implies a mechanism to generate group 479 keys (e.g., different private keys can be used to decrypt the same 480 encrypted data object) [Chaum]. 482 4.2.4. State overloading 484 ICN solutions where intermediate routers need to keep state, such as 485 request origin or forwarding information, to operate correctly (e.g., 486 CCN [CCN]) are subject to denial of service attacks aiming to 487 overload the router's internal state. The challenge is then to 488 provision routers and construct internal state in a way that 489 alleviates sensibility to such attacks. The problem becomes even 490 harder if the protocol does not provide information about the origin 491 of messages. It is worth noting that data object caching is also 492 subject to such attacks but caching is only an optimisation so in the 493 worst case, performance would be the same as if no caching was used. 494 To limit the impact on attacks on caching, robust cache eviction 495 algorithms must be used. 497 4.2.5. Traffic on data object replicas 499 A challenge related to content management but that can have impact on 500 security is the potential lack of control a data object producer has 501 on its own data. For example, how can a producer know the number of 502 copies of its data are in the network or who has consumed them? 504 4.2.6. Cryptographic robustness 506 Content producers sign their content to ensure the integrity of data 507 and to allow for data object authentication. This is a fundamental 508 requirement in ICN due to distributed caching. Publishers, who (a) 509 massively sign content, which is (b) long-lived, offer time and data 510 to an attacker for comprising cryptographic credentials. Signing 511 large amount of data eases common attacks that try to breach the key 512 of the publisher. Based on this observation, the following research 513 challenges appear. To which extent does the content publication 514 model conflict with cryptographic limitations? How can we achieve a 515 transparent re-signing without introducing additional cryptographical 516 weaknesses or key management overhead? 518 4.2.7. Routing and forwarding information bases 520 Section 4.3 shows that routing and forwarding information bases are 521 subject to scalability issue when routing by name is used. While the 522 system is designed it is not only important to ensure that it cannot 523 suffer from targeted attacks aiming at increasing routing and 524 forwarding information bases. As the routing system is tightly bound 525 to the ICN solution itself, there is no universal way to avoid such 526 attacks. However, a possible approache is to combine routing 527 infromation authenticity validation with filtering (e.g., maximum 528 deaggregation level whenever applicable, black lists, etc.). 530 4.3. Routing and Resolution System Scalability 532 ICN routing locates a data object based on its name which is 533 initially provided by a requestor. ICN routing may comprise three 534 steps: a name resolution step, a discovery step, and a delivery step. 535 The name resolution step translates the name of the requested data 536 object into its locator. The discovery step routes the request to 537 data object based on its name or locator. The last step (delivery) 538 routes the data object back to the requestor. Depending on how these 539 steps are combined, ICN routing schemes can be categorized as: Route- 540 By-Name Routing (RBNR), Lookup-By-Name Routing (LBNR), and Hybrid 541 Routing (HR). 543 4.3.1. Route-By-Name Routing (RBNR) 545 RBNR omits the first name resolution step. The name of data object 546 is directly used to route the request to the data object. Therefore, 547 routing information for each data object has to be maintained in the 548 routing table. Since the number of data objects is very large 549 (estimated as 10^11 back in 2007 [DONA] but this may be should be 550 significantly larger than that1 , e.g. 10^15 to 10^22), the size of 551 routing tables becomes a concern, as it can be proportional to the 552 number of data object unless an aggregation mechanism is introduced. 553 On the other hand, RBNR reduces overall latency and simplifies the 554 routing process due to the omission of the resolution process. For 555 the delivery step, RBNR needs another identifier (ID) of either host 556 or location to forward the requested data object back to the 557 requestor. Otherwise, an additional routing mechanism has to be 558 introduced such as bread-crumbs routing [BREADCRUMBS], in which each 559 request leaves behind a trail of breadcrumbs along its forwarding 560 path, and then the response is forwarded back to the requestor 561 consuming the trail. Specific challenges include: 563 o How to aggregate the names of data objects to reduce the number of 564 routing entries? 566 o How does a user learn the name which is designed for aggregation 567 by provider? (For example, although we name our contribution as 568 "ICN research challenge", IRTF (provider) may want to change the 569 name to "/IETF/IRTF/ ICN/Research challenge" for aggregation. In 570 this case, how does a user learn the name "/IETF/IRTF/ICN/Research 571 challenge" to retrieve the contribution initially named "ICN 572 research challenge" without any resolution process?) 574 o Without introducing the name aggregation scheme, can we still 575 achieve scalable routing by taking advantage of topological 576 structure and distributed copies? For example, employing compact 577 routing [COMPACT], random walk [RANDOM] or Greedy routing 578 [GREEDY], and so on. 580 o How to incorporate copies of a data object in in-network caches in 581 this routing scheme? 583 4.3.2. Lookup-By-Name Routing (LBNR) 585 LBNR uses the first name resolution step to translate the name of 586 requesting data object into its locator. Then, the second discovery 587 step is carried out based on the locator. Since IP addresses could 588 be used as locators, the discovery step can depend on the current IP 589 infrastructure. The delivery step can be implemented similarly to IP 590 routing. The locator of the requestor is included in the request 591 message, and then the requested data object is delivered to the 592 requestor based on the locator. Specific challenges include: 594 o How to build a scalable resolution system which provides 596 * Fast lookup: mapping the name of data object to its locators 597 (copies as well). 599 * Fast update: the location of data object is expected to change 600 frequently. Also, multiple data objects may change their 601 locations at the same time, e.g. data objects in laptop. 603 o How to incorporate copies of a data object in in-network caches in 604 this routing scheme? 606 4.3.3. Hybrid Routing (HR) 608 HR combines RBNR and LBNR to benefit from their advantages. For 609 instance, within a single administrative domain, e.g. an ISP, where 610 scalability issues can be addressed with network planning, RBNR can 611 be adopted to reduce overall latency by omitting the resolution 612 process. On the other hand, LBNR can be used to route between 613 domains which have their own prefix (locator). A specific challenge 614 here is: 616 o How to design a scalable mapping system which, given the name of 617 data object, it should return a destination domain locator so that 618 a user request can be encapsulated and forwarded to the domain? 620 4.4. Mobility Management 622 Mobility management has been an active field in host-centric 623 communications for more than two decades. In IETF in particular, 624 starting with [RFC2002], a multitude of enhancements to IP have been 625 standardized aiming to "allow transparent routing of IP datagrams to 626 mobile nodes in the Internet" [RFC5944]. In a nutshell, mobility 627 management for IP networks is locator-oriented and relies on the 628 concept of a mobility anchor as a foundation for providing always-on 629 connectivity to mobile nodes. Other standards organizations, such as 630 3GPP, have followed similar anchor-based approaches. Traffic to and 631 from the mobile node must flow through the mobility anchor, typically 632 using a set of tunnels, enabling the mobile node to remain reachable 633 while changing its point of attachment to the network. 635 Needless to say, an IP network which supports node mobility is more 636 complex than one that does not, as specialized network entities must 637 be introduced in the network architecture. This is reflected in the 638 control plane as well, which carries mobility-related signaling 639 messages, establishes and tears down tunnels and so on. While mobile 640 connectivity was an afterthought in IP, in ICN this is considered a 641 primary deployment environment. Most, if not all, ICN proposals 642 consider mobility from the very beginning, although at varying levels 643 of architectural and protocol detail. That said, no solution has so 644 far come forward with a definite answer on how to handle mobility in 645 ICN using native primitives. In fact, we observe that mobility 646 appears to be addressed on ICN proposal specific basis. That is, 647 there is no single paradigm solution, akin to tunneling through a 648 mobility anchor in host-centric networking, that can be applied 649 across different ICN proposals. For instance, although widely- 650 deployed mobile network architectures typically come with their own 651 network entities and associated protocols, they follow the same line 652 of design with respect to managing mobility. This design thinking, 653 which calls for incorporating mobility anchors, permeates in the ICN 654 literature too. 656 However, employing mobility anchors and tunneling is probably not the 657 best way forward in ICN research for mobile networking. 658 Fundamentally this approach is anything but information-centric and 659 location-indepedent. In addition, as argued in [SEEN], current 660 mobility management schemes anchor information retrieval not only at 661 a specific network gateway (e.g. home agent in Mobile IP) but due to 662 the end-to-end nature of host-centric communication also at a 663 specific correspondent node. However, once a change in the point of 664 attachment occurs, information retrieval from the original 665 "correspondent node" may be no longer optimal. This was shown in 666 [MANI], for example, where a simple mechanism that triggers the 667 discovery of new retrieval providers for the same data object, 668 following a change in the point of attachment, clearly outperforms a 669 tunnel-based approach like Mobile IP in terms of object download 670 times. The challenge here is how to capitalize on location 671 information while facilitating the use of ICN primitives which 672 natively support multicast and anycast. 674 ICN naming and name resolution, as well as the security features that 675 come along should natively support mobility. For example, CCN [CCN] 676 does not have the restriction of spanning tree routing, so it is able 677 to take advantage of multiple interfaces or adapt to the changes 678 produced by rapid mobility (i.e., there is no need to bind a layer 3 679 address with a layer 2 address). In fact, client mobility can be 680 simplified by allowing requests for new content to normally flow from 681 different interfaces, or through newly connected points of attachment 682 to the network. However, when the node moving is the (only) content 683 source, it appears that more complex network support my be necessary, 684 including forwarding updates and caching rebuilding. A case in point 685 is a conversation network service, such as a voice or video call 686 between two parties. The requirements in this case are more 687 stringent when support for seamless mobility is required, esp. when 688 compared to content dissemination that is amenable to buffering. 689 Another parameter that needs to be paid attention to is the impact of 690 using different wireless access interfaces based on different 691 technologies, where the performance and link conditions can vary 692 widely depending of numerous factors. 694 In host-centric networking, mobility management mechanisms ensure 695 optimal handovers and (ideally) seamless transition from one point of 696 attachment to another. In ICN, however, the traditional meaning of 697 "point of attachment" no longer applies as communication is not 698 restrained by location-based access to data objects. Therefore, a 699 "seamless transition" in ICN ensures that content reception continues 700 without any perceptible change from the point of view of the ICN 701 application receiving that content. Moreover, this transition needs 702 to be executed in parallel with ICN content identification and 703 reaching mechanisms enabling scenarios, such as, preparation of the 704 content reaching process at the target connectivity point, prior to 705 the handover (to reduce link switch disturbances). Finally, these 706 mobility aspects can also be tightly coupled with network management 707 aspects, in respect to policy enforcement, link control and other 708 parameters necessary for establishing the node's link to the network. 710 In summary, the following research challenges on ICN mobility 711 management can be derived: 713 o How can mobility management take full advantage of native ICN 714 primitives? 716 o How do we avoid the need for mobility anchors in a network that by 717 design supports multicast, anycast and location-indepedent 718 information retrieval? 720 o How can content retrieval mechanisms interface with specific link 721 operations, such as identifying which links are available for 722 certain content? 724 o How can mobility be offered as a service, which is only activated 725 when the specific user/content/conditions require it? 727 o How can mobility management be coordinated between the node and 728 the network for optimization and policing procedures? 730 o How do we ensure that managing mobility does not introduce 731 scalability issues in ICN? 733 4.5. Wireless Networking 735 Today, all layer 2 wireless network radio access technologies (L2) 736 are developed with a clear assumption in mind: the waist of the 737 protocol stack is IP and it will be so for the foreseeable future. 738 By fixing the protocol stack waist, engineers can answer a large set 739 of questions, including how to handle conversational traffic (e.g. 740 voice calls) vs. web access to online resources, how to support 741 multicast (the IP flavor), and so on, in a rather straightforward 742 manner. Broadcast, on the other hand, which is inherent in wireless 743 communication is not fully taken advantage off. On the contrary, 744 researchers are often more concerned about introducing mechanisms 745 that ensure that "broadcast storms" do not take down a network. How 746 can broadcast serve our (information-centric) networking needs better 747 has yet to be thoroughly investigated. 749 Wireless networking is often intertwined with mobility but this is 750 not always the case. In fact, empirical measurements often indicate 751 that many users tend to connect (and remain connected) to a single 752 Wi-Fi access point for considerable amounts of time. A case in 753 point, which is frequently cited in different variations in the ICN 754 literature, is access to a document repository during a meeting. For 755 instance, in a typical IETF working group meeting, a scribe takes 756 notes which are uploaded to a centralized repository (see Figure 1). 757 Subsequently, each meeting participant obtains a copy of the document 758 on their own devices for local use, annotation, and sharing with 759 colleagues that are not present at the meeting. Note that in this 760 example there is no node mobility and that it is not important 761 whether the document with the notes is uploaded in one go at the end 762 of the session or in a streaming-like fashion as is typical today 763 with online (cloud-based) document processing. 765 +---------------------+ 766 | Document Repository | 767 +---------------------+ 768 || 769 (Internet) 770 || 771 +--------------+ 772 | Access Point | 773 +--------------+ 774 / | \ 775 / | \ 776 / | \ 777 Scribe Participant 1 ... Participant N 779 Figure 1: Document sharing during a meeting 781 In this scenario we observe that the same data object bits 782 (corresponding to the meeting notes) need to traverse the wireless 783 medium at least N+1 times, where N is the number of meeting 784 participants obtaining a copy of the notes. In effect, a broadcast 785 medium is shoehorned into N+1 virtual unicast channels. One could 786 argue that wireless local connectivity is inexpensive, but this is 787 not the critical factor in this example. The actual information 788 exchange wastes N times the available network capacity, no matter 789 what is the spectral efficiency (or the economics) underlying the 790 wireless technology. This waste is a direct result of extending the 791 remote access paradigm from wired to wireless communication, 792 irrespective of the special characteristics of the latter. 794 It goes without saying that an ICN approach that does not take into 795 consideration the wireless nature of an interface will waste the same 796 amount of resources as a host-centric paradigm. Of course, in- 797 network caching at the wireless access point could reduce the amount 798 of data carried over the backhaul link but, if there is no change in 799 the use of the wireless medium, the NDO will still be carried over 800 the wireless ether N+1 times. Intelligent caching strategies, 801 replica placement cooperation and so on simply cannot alleviate this. 802 On the other hand, promiscuous interface operation and opportunistic 803 caching would maximize wireless network capacity utilization in this 804 example. 806 Arguably, if one designs a future wireless access technology with an 807 information-centric "layer 3" in mind, many of the design choices 808 that are obvious in an all-IP architecture may no longer be valid. 809 Although this is clearly outside the scope of this document, a few 810 research challenges that the wider community may be interested in 811 include: 813 o Can we use wireless resources more frugally with the information- 814 centric paradigm than what is possible today in all-IP wireless 815 networks? 817 o In the context of wireless access, how can we leverage the 818 broadcast nature of the medium in an information-centric network? 820 o Would a wireless-oriented ICN protocol stack deliver significant 821 performance gains? How different would it be from a wired- 822 oriented ICN protocol stack? 824 o Is it possible that by changing the network paradigm to ICN we can 825 in practice increase the spectral efficiency (bits/s/Hz) of a 826 wireless network beyond what would be possible with today's host- 827 centric approaches? What would be the impact of doing so with 828 respect to energy consumption? 830 o Can wireless interface promiscuous operation coupled with 831 opportunistic caching increase ICN performance, and if so, by how 832 much? 834 o How can a conversational service be supported at least as 835 efficiently as today's state-of-the-art wireless networks deliver? 837 o What are the benefits from combining ICN with network coding in 838 wireless networks? 840 o How can MIMO and Coordinated Multipoint Transmission (CoMP) be 841 natively combined with ICN primitives in future cellular networks? 843 4.6. Transport Services 845 ICN's receiver-driven communication model as described above creates 846 new options for transport protocol design, as it does not rely solely 847 on end-to-end communication from a sender to a receiver. A requested 848 object can be accessible in multiple different network locations. A 849 node can thus decide how to utilize multiple sources, e.g., by 850 sending parallel requests for the same object or by switching sources 851 (or next hops) in a suitable schedule for a series of requests. 853 In this model, the requestor would control the data rate by 854 regulating its request sending rate and next by performing source/ 855 next-hop selections. Specific challenges depend on the specific ICN 856 approach, but general challenges for receiver-driven transport 857 protocols (or mechanisms, since dedicated protocols might not be 858 required) include flow and congestion control, fairness, network 859 utilization, stability (of data rates under stable conditions) etc. 860 [HRICP] describes a sample request rate control protocol and 861 corresponding design challenges. 863 As mentioned above, the ICN communication paradigm does not depend 864 strictly on end-to-end flows, as contents might be received from mid- 865 network caches. The traditional concept of a flow is then somewhat 866 cancelled as sub-flows, or flowlets might be formed on the fly, when 867 fractions of a content file are transmitted from in-network caches. 868 For a transport layer protocol this is challenging, as any 869 measurement related to this flow, as traditionally done by transport 870 protocols such as TCP, will be hugely misleading. For example, false 871 RTT measurements will lead to largely variable average and smooth RTT 872 values, which in turn will trigger false timeout expirations. 874 Furthermore, out-of-order delivery is expected to be common in a 875 scenario where parts of a content file are retrieved from in-network 876 caches, rather than from the origin server. Several techniques for 877 dealing with out-of-order delivery have been proposed in the past for 878 TCP, some of which could potentially be modified and re-used in the 879 context of ICN. Further research is needed on this direction though 880 to i) choose the right technique and ii) adjust it according to the 881 requirements of the ICN architecture and transport protocol in use. 883 ICN offers routers the possibility to aggregate requests and can use 884 several paths, meaning that there is no such thing as a (dedicated) 885 end-to-end communication path, e.g., a router that receives two 886 requests for the same content at the same time only sends one request 887 to its neighbor. The aggregation of requests has a general impact on 888 transport service design. 890 Achieving fairness for requestors can be one challenge as it is not 891 possible to identify the number of clients behind one particular 892 request. A second problem related to request aggregation is the 893 management of request retransmissions. Generally, it is assumed that 894 a router will not transmit a request if it transmitted an identical 895 request recently and because there is no information about the 896 requestor, the router cannot distinguish the initial request from a 897 client from a retransmission from the same client. In such a 898 situation, how routers can adapt their timers to use the best of the 899 communication paths. Finally, aggregation of requests has an impact 900 on the server (producer) side. This last has no way to determine the 901 number of clients actually consuming the content it is producing. 902 This shift of model influences the business model of the server, 903 e.g., how to implement pay-per-click 905 4.7. In-Network Caching 907 Explicitly named content objects allow for caching at virtually any 908 network element, including routers, proxy caches and end-host 909 machines. In-network caching can therefore improve network 910 performance by fetching content from nodes geographically placed 911 closer to the end-user. Several issues that need further 912 investigation have been identified with respect to in-network 913 caching. Here we list some of the most important challenges that 914 relate to the properties of the new ubiquitous caching system. 916 4.7.1. Cache Placement 918 The declining cost of fast memory gives the opportunity to deploy 919 caches in network routers and take advantage of explicitly named 920 cached contents. There exist two approaches to in-network caching, 921 namely, on-path and off-path caching. Both approaches have to 922 consider the issue of cache location. Off-path caching is similar to 923 traditional proxy-caching or CDN server placement. Retrieval of 924 contents from off-path caches requires redirection of requests and, 925 therefore, is closely related to the Request-to-Cache Routing problem 926 discussed later. Off-path caches have to be placed in strategic 927 points within a network in order to reduce the redirection delays and 928 the number of detour hops to retrieve cached contents. Previous 929 research on proxy-caching and CDN deployment is helpful in this case. 931 On the other hand, on-path caching requires less network intervention 932 and fits more neatly in ICN. However, on-path caching requires line- 933 speed operation, which places more constraints on the design and 934 operation of in-network caching elements. Furthermore, the gain of 935 such a system of on-path in-network caches relies on opportunistic 936 cache hits and has therefore been considered of limited benefit, 937 given the huge amount of contents hosted in the Internet. For this 938 reason, network operators might initially consider only a limited 939 number of network elements to be upgraded to in-network caching 940 elements. The decision on which nodes should be equipped with caches 941 is an open issue and might be based, among others, on topological 942 criteria, or traffic characteristics. These challenges relate to 943 both the Content Placement Problem and the Request-to-Cache Routing 944 Problem discussed below. 946 In call cases, however, the driver for the implementation, deployment 947 and operation of in-network caches will be its cost. Operating 948 caches at line speed inevitably requires faster memories, which 949 increase the implementation cost. Based on the capital to be 950 invested, ISPs will need to make strategic decisions on the cache 951 placement, which can be driven by several factors, such as: avoid 952 inter-domain/expensive links, centrality of nodes, size of domain and 953 the corresponding spatial locality of users, traffic patterns in a 954 specific part of the network (e.g., university vs business vs fashion 955 district of a city). 957 4.7.2. Content Placement -- Content-to-Cache Distribution 959 Given a number of (on-path or off-path) in-network caching elements, 960 content-to-cache distribution will affect both the dynamics of the 961 system, in terms of request redirections (mainly in case of off-path 962 caches) and the gain of the system in terms of cache hits. A 963 straightforward approach to content placement is on-path placement of 964 contents as they travel from source to destination. This approach 965 reduces the computation and communication overhead of placing content 966 within the network but, on the other hand, might reduce the chances 967 of hitting cached contents. This relates to the Request-to-Cache 968 Routing problem discussed next. 970 Furthermore, the number of replicas held in the system brings up 971 resource management issues in terms of cache allocation. For 972 example, continuously replicating content objects in all network 973 elements results in redundant copies of the same objects. The issue 974 of redundant replication has been investigated in the past for 975 hierarchical web caches. However, in hierarchical web-caching, 976 overlay systems coordination between the data and the control plane 977 can guarantee increased performance in terms of cache hits. Line- 978 speed, on-path in-network caching poses different requirements and 979 therefore, new techniques need to be investigated. In this 980 direction, there already exist some studies that attempt to reduce 981 redundancy of cached copies. However, the issue of coordinated 982 content placement in on-path caches still remains open. 984 The Content-to-Cache Allocation problem relates also to the 985 characteristics of the content to be cached. Popular content might 986 need to be placed where it is going to be requested next. 987 Furthermore, issues of "expected content popularity" or temporal 988 locality need to be taken into account in designing in-network 989 caching algorithms in order for some contents to be given priority 990 (e.g., popular content vs. one-timers). The criteria as to which 991 contents should be given priority in in-network content caches relate 992 also to the business relationships between content providers and 993 network operators. Business model issues will drive some of these 994 decisions on content-to-cache distribution, but such issues are 995 outside the scope of this note and are not discussed here further. 997 4.7.3. Request-to-Cache Routing 999 In order to take advantage of cached contents, requests have to be 1000 forwarded to the nodes that temporarily host (cache) the 1001 corresponding contents. This challenge relates to name-based 1002 routing, discussed before. Requests should ideally follow the path 1003 to the cached content. However, instructions as to which content is 1004 cached where cannot be broadcast throughout the network. Therefore, 1005 the knowledge of a content's location at the time of the request 1006 might either not exist, or it might not be accurate (i.e., contents 1007 might have been removed by the time a request is redirected to a 1008 specific node). 1010 Coordination between the data and the control planes to update 1011 information of cached contents has been considered, but in this case 1012 scalability issues arise. We therefore, have two options. We either 1013 have to rely on opportunistic caching, where requests are forwarded 1014 to a server and in case the content is found on the path, then the 1015 content is fetched from this node (instead of the original server); 1016 or we employ cache-aware routing techniques. Cache-aware routing can 1017 either involve both the control and the data plane, or only one of 1018 them. Furthermore, cache-aware routing can be done in a domain-wide 1019 scale or can involve more than one individual Autonomous System (AS). 1020 In the latter case, business relationships between ASes might need to 1021 be exploited in order to build a scalable model. 1023 4.8. Network Management 1025 Managing networks has been a core craft in the IP-based host-centric 1026 paradigm ever since the technology was introduced in production 1027 networks. However, at the onset of IP, management was considered 1028 primarily as an add-on. Essential tools that are used daily by 1029 networkers, such as ping and traceroute, did not become widely 1030 available until more than a decade or so after IP was first 1031 introduced. Management protocols, such as SNMP, also became 1032 available much later than the original introduction of IP and many 1033 still consider them insufficient despite the years of experience we 1034 have running host-centric networks. Today, when new networks are 1035 deployed network management is considered a key aspect for any 1036 operator, a major challenge which is directly reflected in higher 1037 OPEX if not done well. If we want ICN to be deployed in 1038 infrastructure networks, development of management tools and 1039 mechanisms must go hand-in with the rest of the architecture design. 1041 Although defining FCAPS for ICN is clearly outside the scope of this 1042 document, there is a need for creating basic tools early on while ICN 1043 is still in the design and experimentation phases that can evolve 1044 over time and help network operations centers (NOC) to define 1045 policies, validate that they are indeed used in practice, be notified 1046 early on about failures, determine and resolve configuration 1047 problems. AAA as well as performance management, from a NOC 1048 perspective, will also need to be considered. Given the expectations 1049 for a large number of nodes and unprecedented traffic volumes, 1050 automating tasks, or even better employing self-management mechanisms 1051 is preferred. The main challenge here is that all tools we have at 1052 our disposal today are node-centric, end-to-end oriented, or assuming 1053 a packet-stream communication environment. Rethinking reachability 1054 and operational availability, for example, can yield significant 1055 insights into how information-centric networks will be managed in the 1056 future. 1058 With respect to network management we see three different aspects. 1059 First, any operator needs to manage all resources available in the 1060 network, which can range from node connectivity to network bandwidth 1061 availability to in-network storage to multi-access support. In ICN, 1062 users will also bring into the network significant resources in terms 1063 of network coverage extension, storage, and processing capabilities. 1064 DTN characteristics should also be considered to the degree that this 1065 is possible (e.g. content dissemination through data mules). 1066 Secondly, given that nodes and links are not at the center of an 1067 information-centric network, network management should capitalize on 1068 native ICN mechanisms. For example, in-network storage and name 1069 resolution can be used for monitoring, while native publish/subscribe 1070 functionality can be used for triggering notifications. Finally, 1071 management is also at the core of network controlling capabilities by 1072 allowing operating actions to be mediated and decided, triggering and 1073 activating networking procedures in an optimized way. For example, 1074 monitoring aspects can be conjugated with different management 1075 actions in a coordinated way, allowing network operations to flow in 1076 a concertated way. 1078 However, the considerations on leveraging intrinsic ICN mechanisms 1079 and capabilities to support management operations go beyond a simple 1080 mapping exercise. In fact, not only it raises a series of challenges 1081 on its own, but also opens up new possibilities for both ICN and 1082 "network management" as a concept. For instance, naming mechanisms 1083 are central to ICN intrinsic operations, which are used to identify 1084 and reach content under different aspects (e.g., hierarchically 1085 structured vs. 'flattish' names). In this way, ICN is decoupled from 1086 host-centric aspects on which traditional networking management 1087 schemes rely upon. As such, questions are raised which can directly 1088 be translated into challenges for network management capability, such 1089 as, for example how to address a node or a network segment in a ICN 1090 naming paradigm, how to identify which node is connected "where", and 1091 if there is a host-centric protocol running from which the management 1092 process can also leverage upon. 1094 But, on the other hand, these same inherent ICN characteristics also 1095 allow us to look into network management through a new perspective. 1096 By centering its operations around content, one can conceive new 1097 management operations addressing, for example, per-content management 1098 or access control, as well as analyzing performance per content name 1099 instead of per link or node. Moreover, such considerations can also 1100 be used to manage operational aspects of ICN mechanisms themselves. 1102 For example, [NDN-MGMT] re-utilizes inherent content-centric 1103 capabilities of CCN to manage optimal link connectivity for nodes, in 1104 concert with a network optimization process. Conversely, how these 1105 content-centric aspects can otherwise influence and impact management 1106 in other areas (e.g., security, resilience) is also important, as 1107 exemplified by in [ccn-access], where access control mechanisms are 1108 integrated into a prototype of the [PURSUIT] architecture. 1110 In this way, a set of core research challenges on ICN management can 1111 be derived as: 1113 o Manage and control content reception at the destination 1115 o Coordination of management information exchange and control 1116 between ICN nodes and ICN network control points Identification of 1117 management and controlling actions and items through information 1118 naming 1120 o Relationship between NDOs and host entities identification (i.e., 1121 how to identify a particular link, interface or flow that need to 1122 be managed) 1124 5. Link to and Impact on IETF Technologies 1126 TBW later. 1128 6. Security Considerations 1130 TBD 1132 7. Informative References 1134 [BREADCRUMBS] 1135 Rosensweig, E. and J. Kurose, "Breadcrumbs: Efficient, 1136 Best-Effort Content Location in Cache Networks", 1137 In Proceedings of the IEEE INFOCOM 2009, April 2009. 1139 [CCN] Jacobson, K, D, F, H, and L, "Networking Named Content", 1140 CoNEXT 2009 , December 2009. 1142 [COMPACT] Cowen, L., "Compact routing with minimum stretch", 1143 In Journal of Algorithms, vol. 38, pp. 170--183, 2001. 1145 [Chaum] Chaum, D. and E. van Heijst, "Group signatures", 1146 In Proceedings of EUROCRYPT, 1991. 1148 [DONA] Koponen, T., Ermolinskiy, A., Chawla, M., Kim, K., gon 1149 Chun, B., and S. Shenker, "A Data-Oriented (and Beyond) 1150 Network Architecture", In Proceedings of SIGCOMM 2007, 1151 August 2007. 1153 [GREEDY] Papadopoulos, F., Krioukov, D., Boguna, M., and A. Vahdat, 1154 "Greedy forwarding in dynamic scale-free networks embedded 1155 in hyperbolic metric spaces", In Proceedings of the IEEE 1156 INFOCOM, San Diego, USA, 2010. 1158 [HRICP] Carofiglio, G., Gallo, M., and L. Muscariello, "Joint hop- 1159 by-hop and receiver-driven interest control protocol for 1160 content-centric networks", In Proceedings of ACM SIGCOMM 1161 ICN 2012, DOI 10.1145/2342488.2342497, 2012. 1163 [ICNNAMING] 1164 Ghodsi, A., Koponen, T., Rajahalme, J., Sarolahti, P., and 1165 S. Shenker, "Naming in Content-Oriented Architectures", 1166 In Proceedings ACM SIGCOMM Workshop on Information-Centric 1167 Networking (ICN), 2011. 1169 [ICNSURVEY] 1170 Ahlgren, B., Dannewitz, C., Imbrenda, C., Kutscher, D., 1171 and B. Ohlman, "A Survey of Information-Centric 1172 Networking", In Communications Magazine, IEEE , vol.50, 1173 no.7, pp.26-36, DOI 10.1109/MCOM.2012.6231276, 2012. 1175 [MANI] Pentikousis, K. and T. Rautio, "A multiaccess Network of 1176 Information", WoWMoM 2010, IEEE , June 2010. 1178 [NDN-MGMT] 1179 Corujo, D., Aguiar, R., Vidal, I., and J. Garcia-Reinoso, 1180 "A named data networking flexible framework for management 1181 communications", Communications Magazine, IEEE , vol.50, 1182 no.12, pp.36-43 , December 2012. 1184 [PURSUIT] Fotiou et al., N., "Developing Information Networking 1185 Further: From PSIRP to PURSUIT", In Proceedings of Proc. 1186 BROADNETS. ICST, 2010. 1188 [RANDOM] Gkantsidis, C., Mihail, M., and A. Saberi, "Random walks 1189 in peer-to-peer networks: algorithms and evaluation", 1190 In Perform. Eval., vol. 63, pp. 241--263, 2006. 1192 [RFC2002] Perkins, C., "IP Mobility Support", RFC 2002, 1193 October 1996. 1195 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1196 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1198 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1199 Housley, R., and W. Polk, "Internet X.509 Public Key 1200 Infrastructure Certificate and Certificate Revocation List 1201 (CRL) Profile", RFC 5280, May 2008. 1203 [RFC5944] Perkins, C., "IP Mobility Support for IPv4, Revised", 1204 RFC 5944, November 2010. 1206 [RFC6920] Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B., 1207 Keranen, A., and P. Hallam-Baker, "Naming Things with 1208 Hashes", RFC 6920, April 2013. 1210 [SEEN] Pentikousis, K., "In search of energy-efficient mobile 1211 networking", Communications Magazine, IEEE, vol. 48, no. 1212 1, pp.95-103 , January 2010. 1214 [ccn-access] 1215 Fotiou, N., Marias, G., and G. Polyzos, "Access control 1216 enforcement delegation for information-centric networking 1217 architectures", In Proceedings of the second edition of 1218 the ICN workshop on Information-centric networking (ICN 1219 '12). ACM, New York, NY, USA, 85-90., 2012. 1221 Authors' Addresses 1223 Dirk Kutscher (editor) 1224 NEC 1225 Kurfuersten-Anlage 36 1226 Heidelberg, 1227 Germany 1229 Phone: 1230 Email: kutscher@neclab.eu 1232 Suyong Eum 1233 National Institute of Information and Communications Technology 1234 4-2-1, Nukui Kitamachi, Koganei 1235 Tokyo 184-8795 1236 Japan 1238 Phone: +81-42-327-6582 1239 Email: suyong@nict.go.jp 1240 Kostas Pentikousis 1241 Huawei Technologies 1242 Carnotstrasse 4 1243 Berlin 10587 1244 Germany 1246 Email: k.pentikousis@huawei.com 1248 Ioannis Psaras 1249 University College London, Dept. of E.E. Eng. 1250 Torrington Place 1251 London WC1E 7JE 1252 United Kingdom 1254 Email: i.psaras@ucl.ac.uk 1256 Daniel Corujo 1257 Universidade de Aveiro 1258 Instituto de Telecomunicacoes, Campus Universitario de Santiago 1259 Aveiro P-3810-193 1260 Portugal 1262 Email: dcorujo@av.it.pt 1264 Damien Saucez 1265 INRIA 1266 2004 route des Lucioles - BP 93 1267 Sophia Antipolis 06902 Cedex 1268 France 1270 Email: damien.saucez@inria.fr 1272 Thomas C. Schmidt 1273 HAW HAmburg 1274 Berliner Tor 7 1275 Hamburg 20099 1276 Germany 1278 Email: t.schmidt@ieee.org 1279 Matthias Waehlisch 1280 FU Berlin 1281 Takustr. 9 1282 Berlin 14195 1283 Germany 1285 Email: waehlisch@ieee.org