idnits 2.17.1 draft-kutscher-icnrg-challenges-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 10, 2013) is 4086 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) No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). 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: August 14, 2013 NICT 6 K. Pentikousis 7 Huawei 8 I. Psaras 9 UCL 10 D. Corujo 11 Universidade de Aveiro 12 D. Saucez 13 INRIA 14 February 10, 2013 16 ICN Research Challenges 17 draft-kutscher-icnrg-challenges-00 19 Abstract 21 This memo describes research challenges for Information-Centric 22 Networking. Information-centric networking is an approach to evolve 23 the Internet infrastructure to directly support this use by 24 introducing uniquely named data as a core Internet principle. Data 25 becomes independent from location, application, storage, and means of 26 transportation, enabling in-network caching and replication. 27 Challenges include naming, security, routing, system scalability, 28 mobility management, wireless networking, transport services, in- 29 network caching, and network management. 31 Status of this Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on August 14, 2013. 48 Copyright Notice 49 Copyright (c) 2013 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Problems with Information Distribution Today . . . . . . . . . 4 63 3. ICN Concepts . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 4. ICN Research Challenges . . . . . . . . . . . . . . . . . . . 6 65 4.1. Naming and Security . . . . . . . . . . . . . . . . . . . 6 66 4.2. Routing and Resolution System Scalability . . . . . . . . 8 67 4.2.1. Route-By-Name Routing (RBNR) . . . . . . . . . . . . . 9 68 4.2.2. Lookup-By-Name Routing (LBNR) . . . . . . . . . . . . 9 69 4.2.3. Hybrid Routing (HR) . . . . . . . . . . . . . . . . . 10 70 4.3. Mobility Management . . . . . . . . . . . . . . . . . . . 10 71 4.4. Wireless Networking . . . . . . . . . . . . . . . . . . . 12 72 4.5. Transport Services . . . . . . . . . . . . . . . . . . . . 12 73 4.6. In-Network Caching . . . . . . . . . . . . . . . . . . . . 13 74 4.6.1. Cache Placement . . . . . . . . . . . . . . . . . . . 13 75 4.6.2. Content Placement -- Content-to-Cache Distribution . . 14 76 4.6.3. Request-to-Cache Routing . . . . . . . . . . . . . . . 15 77 4.7. Network Management . . . . . . . . . . . . . . . . . . . . 15 78 5. Link to and Impact on IETF Technologies . . . . . . . . . . . 17 79 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 80 7. Informative References . . . . . . . . . . . . . . . . . . . . 17 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 83 1. Introduction 85 Distributing and manipulating named information is a major 86 application in the Internet today. In addition to web-based content 87 distribution, other distribution technologies (such as P2P and CDN) 88 have emerged and are promoting a communication model of accessing 89 data by name, regardless of origin server location. 91 In order to respond to increasing traffic volume in the current 92 Internet for applications such as mobile video and cloud computing, a 93 set of disparate technologies and distribution services are applied 94 that employ caching, replication and content distribution in 95 different specific ways. These approaches are currently deployed in 96 separate silos -- different CDN providers and P2P applications rely 97 on specific distribution technologies. It is not possible to 98 uniquely and securely identify named information independently of the 99 distribution channel; and the different distribution approaches are 100 typically implemented as an overlay, potentially leading to 101 unnecessary inefficiency. 103 For example, creating and sharing multimedia content in a social 104 networking application today, typically requires uploading data 105 objects to centralized service provider platforms, from where it can 106 be accessed individually by other users. Even if content sharing is 107 intended to happen locally, e.g., in a local network or local area, 108 the actual communication will require interactions from any 109 interested user with the service provider. CDNs can alleviate the 110 situation only partly, because, due to organizational and economic 111 reasons, it is not common to deploy CDN gear ubiquitously. Moreover, 112 since CDNs and the HTTP communication sessions form overlays, the 113 actual communication, i.e., the requests for named content and the 114 actual responses, are largely invisible to the network, i.e., it is 115 not easily possible to optimize efficiency and performance. For 116 example in a wireless access network, it is not possible to leverage 117 inherent broadcast functionality (to avoid duplicate transmission of 118 the same content) due to limitations from point-to-point and overlay 119 communication. 121 Information-centric networking (ICN) is an approach to evolve the 122 Internet infrastructure to directly support this use by introducing 123 uniquely named data as a core Internet principle. Data becomes 124 independent from location, application, storage, and means of 125 transportation, enabling in-network caching and replication. The 126 expected benefits are improved efficiency, better support for 127 provenance verification and name-content binding validation, better 128 scalability with respect to information/bandwidth demand and better 129 robustness in challenging communication scenarios. 131 ICN concepts can be applied to different layers of the protocol 132 stack: name-based data access can be implemented on top of the 133 existing IP infrastructure, e.g., by providing resource naming, 134 ubiquitous caching and corresponding transport services, or it can be 135 seen as a packet-level internetworking technology that would cause 136 fundamental changes to Internet routing and forwarding. In summary, 137 ICN is expected to evolve the Internet architecture at different 138 layers. 140 This document describes research challenges for ICN that need to be 141 addressed in order to achieve these goals. The objective of this 142 document is to document these challenges and corresponding current 143 approaches and to expose requirements that should be addressed by 144 future research work. 146 2. Problems with Information Distribution Today 148 The best current practice to manage this growth in terms of data 149 volume and devices is to employ application-layer overlays such as 150 CDNs, P2P applications, and M2M application platforms that cache 151 content, provide location-independent access to data, and optimize 152 its delivery. In principle, such platforms provide a service model 153 of accessing named data objects (NDOs) (replicated web resources, M2M 154 data in data centers) instead of a host-to-host packet delivery 155 service model. However, since this functionality resides in overlays 156 only, the full potential of content distribution and M2M application 157 platforms cannot be leveraged as the network is not aware of data 158 requests and data transmissions, leading to: 160 o data having to travel sub-optimal routes depending on the overlay, 161 and not the Internet layer, topology; 163 o multicast and broadcast features of wireless networks cannot be 164 leveraged, i.e., request and delivery for the same object have to 165 be made multiple times; 167 o overlays typically require a significant amount of infrastructure 168 support, e.g., authentication portals, content storage, and 169 applications servers, making it often impossible to establish 170 local, direct communication; 172 o the network not being aware of the nature of data objects and thus 173 being unable to manage access and transmission (without layer 174 violations); 176 o provenance validation uses host authentication today, so that even 177 if there are locally cached copies available, it is normally not 178 easily possible to validate their authenticity; and 180 o many applications providing their own approach to caching, 181 replication, transport, authenticity validation (if at all), 182 although they all share similar models of accessing named data 183 objects in the network. 185 3. ICN Concepts 187 Fundamentally, ICN is providing access to named data as a first-order 188 network service, i.e., the network is able to serve requests to named 189 data natively. That means, network nodes can receive requests for 190 named data and act on it, for example by forwarding the request to a 191 suitable next-hop. Consequently, the network processes requests for 192 named data objects (and corresponding responses) natively, i.e., it 193 can see requests and responses. Every network nodes on a path is 194 enabled to perform forwarding decisions, to cache objects etc. This 195 enables the network to forward such requests on optimal paths, 196 employing optimal transmission technologies at every node, e.g., 197 broadcast/multicast transmission in wireless networks to avoid 198 duplicate transmission of both requests and responses. 200 In ICN, like in the Internet Protocol, there is a set of common 201 concepts and node requirements beyond this basic service model. 202 Naming data objects is a key concept. In general, ICN names do not 203 represent neither network nodes nor interfaces -- they represent NDOs 204 independent of their location. Names are the keys for forwarding 205 decisions -- and they are used for matching requests to responses: In 206 order to provide better support for accessing copies of NDOs 207 regardless of their location, it is important to be able to validate 208 that a response actually delivers the bits that correspond to an 209 original request for named data. Name-content binding validation is 210 a fundamental security service in ICN, and this is often achieved by 211 establishing a verifiable binding between the object name and the 212 actual object or an identity that has created the object. ICN can 213 support other security services, such as provenance validation, 214 encryption -- depending on the details of naming schemes, object 215 models and assumptions on infrastructure support. Security services 216 such as name-content binding validation are available to any node, 217 i.e., not just the actual receivers. This is an important feature, 218 for enabling ingress gateways to check object authenticity to prevent 219 denial-of-service attacks. 221 Based on these fundamental properties it is possible to leverage 222 network storage ubiquitously: every node and every device can cache 223 data objects and respond to requests for such objects -- it is not 224 required to validate the authenticity of the node itself since name- 225 content bindings can be validated. Ubiquitous in-network storage can 226 be used for different purposes: it can enable sharing, i.e., the same 227 object copy can be delivered to multiple users/nodes as in today's 228 proxy caches and CDNs. It can also be used to make communication 229 more robust (and perform better) by enabling the network to answer 230 requests from local caches (instead of from origin servers). In case 231 of disruption (message not delivered), a node can re-send the 232 request, and it could be answered by an on-path cache, i.e., on the 233 other side of the disrupted link. The network itself would thus 234 support retransmissions -- enabling shorter round-trip times and 235 offloading origin servers and other parts of the network. 237 The request/response model and ubiquitous in-network storage also 238 enables new options for implementing transport services, i.e., 239 reliable transmission, flow control etc. First of all, a request/ 240 response model can enable receiver-driven transport regimes, i.e., 241 receivers (the requestors of NDOs) can control message sending rates 242 by regulating the request sending rate (assuming that every response 243 message has to be triggered by a request message). Retransmission 244 would be achieved by re-sending requests, e.g., after a timeout. 245 Because objects can be replicated, object transmission and transport 246 sessions would not necessarily have end-to-end semantics: requests 247 can be answered by caches, and a node can select one or multiple 248 next-hop destination for a particular request -- depending on 249 configuration, observed performance or other criteria. 251 This receiver-driven communication model potentially enables new 252 interconnection and business models: a request for named data can be 253 linked to an interest of a requestor (or requesting network) in data 254 from another peer, which could suggest modeling peering agreements 255 and charging accordingly. 257 4. ICN Research Challenges 259 4.1. Naming and Security 261 Naming data objects is as important for ICN as naming hosts is for 262 today's Internet. Fundamentally, ICN requires unique names for 263 individual NDOs, since names are used for identifying objects 264 independently of its location or container. It is important to 265 establish a verifiable binding between the object and its name (name- 266 data integrity ), so that a receiver can be sure that received bits 267 actually represent the NDO (object authenticity). Information about 268 an object's provenance, i.e., who generated or published it, is also 269 useful to associate to the name. 271 The above functions are fundamentally required for the information- 272 centric network to work reliably -- otherwise neither network 273 elements nor receivers can trust objects' authenticity, which would 274 enable several attacks including critical DoS attacks by injecting 275 spoofed content into the network. There are different ways to use 276 names and cryptography to achieve the desired functions [ICNNAMING] 277 [ICNSURVEY], and there are different ways to manage namespaces 278 correspondingly. 280 Two naming schemes have largely been proposed: one with a 281 hierarchical and one with a flat namespace. The hierarchical scheme 282 has a structure similar to current URLs, where the hierarchy is 283 rooted in a publisher prefix. The hierarchy enables aggregation of 284 routing information, improving scalability of the routing system. In 285 some cases, the names are human-readable, which makes it possible for 286 users to manually type in names, reuse, and, to some extent, mapping 287 name to a user's intent. 289 The other naming scheme is self-certifying, meaning that the object's 290 name-data integrity can be verified without needing a public key 291 infrastructure (PKI) or other third party to first establish trust in 292 the key. Self-certification is achieved by binding the hash of the 293 content closely to the object's name. This can be done by directly 294 embedding the hash of the content in the name. Another option is an 295 indirect binding, which embeds the public key of the publisher in the 296 name and signs the hash of the content with the corresponding secret 297 key. The resulting names are typically non-hierarchical, or flat, 298 although the publisher field provides structure that can be used for 299 routing aggregation. 301 There are design trade-offs for ICN naming affecting routing and 302 security. Self-certifying names are not human readable nor 303 hierarchical. They can however provide some structure for 304 aggregation, for instance, a name part corresponding to a publisher. 305 Without self-certification, as mentioned above, the infrastructure 306 depends on a PKI for its operation, which can be impede a large-scale 307 deployment. 309 Specific research challenges include: 311 o naming static data objects can be performed by using content 312 hashes as part of object names, so that publishers calculate the 313 hash over existing data objects and receivers (or any ICN node) 314 can validate the name-content binding by re-calculating the hash 315 and comparing it to the name (component). [I-D.farrell-decade-ni] 316 specifies a concrete naming format for this. 318 o naming dynamic objects is referring to use cases where the name 319 has to be generated before the object is created (for example, 320 this could be the case for live streaming, when a publisher wants 321 to make the stream available by registering stream chunk names in 322 the network). One approach to this can be self-certified names as 323 described above. 325 o requestor privacy protection can be a challenge in ICN as a direct 326 consequence of the accessing-named-data-objects paradigm: if the 327 network can "see" requests and responses, it can also log request 328 history for network segments or individual users, which can be 329 undesirable, especially since name are typically expected to be 330 long-lived. I.e., even if the name itself does not reveal much 331 information, the assumption is that the name can be used to 332 retrieve the corresponding data objects in the future. 334 o Updating and versioning NDO can be challenging because it can 335 contradict fundamental ICN assumptions: if an NDO can be 336 replicated and stored in in-network storage for later retrieval, 337 names have to be long-lived -- and the name-content binding must 338 not change: updating an object (changing the content without 339 generating a new name) is impossible. Versioning can be seen as 340 one possible solution, possibly requiring a naming scheme that 341 supports versioning (and a way for requestors to learn about 342 versions). 344 o Managing accessibility: whereas in ICN the general assumption is 345 to enable ubiquitous access to NDOs, there can be relevant use 346 cases where access to objects should be restricted, for example to 347 a specific user group. There are different approaches for this, 348 such as object encryption (requiring key distribution and related 349 mechanisms) or the concept of scopes, e.g., based on names that 350 can only be used/resolved under some constraints. 352 4.2. Routing and Resolution System Scalability 354 ICN routing locates a data object based on its name which is 355 initially provided by a requester. ICN routing is composed of three 356 steps: a name resolution step, a discovery step, and a delivery step. 357 The name resolution step translates the name of requesting data 358 object into its locator. The discovery step routes user request to 359 data object based on its name or locator. The last delivery step 360 routes the data object back to the requester. Depending on how these 361 steps are combined, ICN routing schemes can be categorized as: Route- 362 By-Name Routing (RBNR), Lookup-By-Name Routing (LBNR), and Hybrid 363 Routing (HR). 365 4.2.1. Route-By-Name Routing (RBNR) 367 RBNR omits the first name resolution step. The name of data object 368 is directly used to route user request to the data object. 369 Therefore, routing information to each data object basically has to 370 be maintained in the routing table. Since the number of data objects 371 is huge (The number of originally published content files that ICN is 372 expected to support was estimated as 10^11 back in 2007 [DONA]. 373 However, there are still many people in ICN research community who 374 believe that the number should be larger than 10^11 , e.g. 10^15 -- 375 10^22.), the size of routing table tends to be proportional to the 376 number of data object unless any aggregation mechanism is introduced 377 to the name of data object. On the other hand, RBNR reduces overall 378 latency and simplifies the routing process due to the omission of the 379 resolution process. For the delivery step, RBNR needs another 380 identifier (ID) of either host or location to forward the requested 381 data object back to the requester. Otherwise, an additional routing 382 mechanism has to be introduced such as bread-crumb routing 383 [BREADCRUMBS]: a request leaves behind a trail of breadcrumbs along 384 its forwarding path, and then the response is forwarded back to the 385 requester consuming the trail. Specific challenges include: 387 o How to aggregate the names of data objects to reduce the number of 388 routing entries? 390 o How does user learn the name which is designed for aggregation by 391 provider? (For example, although we name our contribution as "ICN 392 research challenge", IRTF (provider) may want to change the name 393 to "/IETF/IRTF/ ICN/Research challenge" for aggregation. In this 394 case, how does a user learn the name "/IETF/IRTF/ICN/Research 395 challenge" to retrieve the contribution initially named "ICN 396 research challenge" without any resolution process?) 398 o Without introducing the name aggregation scheme, can we still 399 achieve a scalable routing by taking advantage of topological 400 structure and distributed copies? e.g. compact routing [COMPACT], 401 random walk [RANDOM] or Greedy routing [GREEDY], etc. 403 o How to incorporate copies of a data object in in-network caches in 404 this routing scheme? 406 4.2.2. Lookup-By-Name Routing (LBNR) 408 LBNR uses the first name resolution step to translate the name of 409 requesting data object into its locator. Then, the second discovery 410 step is carried out based on the locator. Since IP address could be 411 used as locators, the discovery step can depend on the current IP 412 infrastructure. The delivery step can be implemented same as IP 413 routing. The locator of requester is included in the request 414 message, and then the requested data object is delivered to the 415 requester based on the locator. Specific challenges include: 417 o How to build a scalable resolution system which provides 419 * Fast lookup: mapping the name of data object to its locators 420 (copies as well). 422 * Fast update: the location of data object is expected to change 423 frequently. Also, multiple data objects may change their 424 locations at the same time, e.g. data objects in laptop. 426 o How to incorporate copies of a data object in in-network caches in 427 this routing scheme? 429 4.2.3. Hybrid Routing (HR) 431 HR combines both RBNR and LBNR to benefit from their advantages. For 432 instance, within a single administrative domain, e.g. ISP where 433 scalability issue is not serious problem, RBNR can be adopted to 434 reduce overall latency by omitting the resolution process. On the 435 other hand, LBNR can be used to route among the domains which have 436 their own prefix (locator). A specific challenge here is: 438 o How to design a scalable mapping system, which given the name of 439 data object, it should return a destination domain locator so that 440 a user request can be encapsulated and forwarded to the domain? 442 4.3. Mobility Management 444 IP was not designed to consider node mobility originally, forcing new 445 connections towards the content sources to be made. With the 446 proliferation of mobile terminals equipped with different kinds of 447 access technologies, mobility became a highly sought solution to be 448 available at the network layer, berthing Mobile IP [RFC5944] based 449 protocols. However, this addition also placed a higher degree of 450 complexity on the network operations due to the need for new network 451 entities, new signaling messages and resulting side-mechanisms, such 452 as tunneling. In that sense, novel content-centric network 453 architectures that go beyond host-based mobility control, provide the 454 ample grounds for the definition of operating mechanisms considering 455 mobility as a prime requirement, right at the start. 457 ICN naming for reaching content intrinsically supports mobility. For 458 example, CCN [CCN] does not share the IP restriction of forwarding on 459 spanning trees, so it is able to take advantage of multiple 460 interfaces or adapt to the changes produced by rapid mobility (i.e., 461 there is no need to bind a layer 3 address into a layer 2 address). 462 In fact, client mobility is simplified by allowing requests for new 463 content to normally flow from different interfaces, or through newly 464 connected points of attachment to the network. However, that 465 simplicity may not be reflected when the node moving is the content 466 source, requiring more complex support from the networking mechanisms 467 in respect to different aspects, such as forwarding update and 468 caching rebuilding. Furthermore, requirements become more stringent 469 when support for seamless mobility is required, especially in cases 470 such as real-time voice/video communications. These requirements are 471 further exacerbated when mobile nodes are able to connect through 472 wireless access interfaces of different technologies, where the 473 performance and link conditions can vary widely depending of numerous 474 factors. 476 Here mobility management has an important role in terms of not only 477 optimizing the handover process, but also to ideally ensure seamless 478 transition from one point of attachment to the other. In this way, 479 "seamless transition" ensures that the content reception by the user 480 occurs in an unperceptive way to the user and/or application 481 receiving that content. Moreover, this transition needs to be 482 executed in parallel with ICN content identification and reaching 483 mechanisms enabling scenarios, such as, preparation of the content 484 reaching process at the target connectivity point, prior to the 485 handover (to reduce link switch disturbances). Finally, these 486 mobility aspects can also be tightly coupled with network management 487 aspects, in respect to policy enforcement, link control and other 488 parameters necessary for establishing the node's link to the network. 489 The resulting mobility management process can thus enhance and evolve 490 ICN aspects by making them aware (or able to contribute) to not only 491 allow but also enhance possible mobility procedures. 493 From this, a set of research challenges on ICN Mobility Management 494 can be derived: 496 o How can content reaching mechanisms interface with specific link 497 operations, such as identifying which links are available for a 498 certain content 500 o How to make mobility as a service that is only activated when the 501 specific user/content/conditions require it (i.e., a possible 502 solution to maintain the mobility-agnostic aspect of generic ICN) 504 o How to coordinate mobility management between the node and the 505 network for optimization and policing procedures? 507 4.4. Wireless Networking 509 Today, all wireless network/radio access technologies (L2) are 510 developed with a clear assumption in mind: the waist of the protocol 511 stack is (and will be) IP. This translates into answering a large 512 set of questions, from how to handle broadcast to how to support 513 multicast in a rather straightforward manner. Arguably, if one 514 designs a future wireless access technology with an information- 515 centric "layer 3", most of these answers would no longer be valid. 516 Although this is clearly outside the scope of this document, a few 517 research challenges that the wider community may be interested in 518 include: 520 o In the context of wireless access, how can we leverage the 521 broadcast nature of the medium in an information-centric network? 523 o Is it possible that by changing the network paradigm to ICN we can 524 in practice increase the spectral efficiency (bits/s/Hz) of a 525 wireless network beyond what would be possible with today's host- 526 centric approaches? 528 o How can a conversational service be supported at least as 529 efficiently as today's SoA wireless network deliver? 531 4.5. Transport Services 533 ICN's receiver-driven communication model as described above creates 534 new option for transport protocol design -- it does not rely on end- 535 to-end communication path from a sender to a receiver, because a 536 requested object can be accessible in multiple different network 537 locations. A node can thus decide how to utilize multiple sources, 538 e.g., by sending parallel requests for the same object or by 539 switching sources (or next hops) in a suitable schedule for a series 540 of requests. 542 In this model the requestor would control data rate by regulating its 543 request sending rate and next by performing source/next-hop 544 selections. Specific challenges are depending on the specific ICN 545 approach in use, but general challenges for receiver-driven transport 546 protocols (or mechanisms, since dedicated protocols might not be 547 required) include flow and congestion control, fairness, network 548 utilization, stability (of data rates under stable conditions) etc. 549 [HRICP] describes a sample request rate control protocol and 550 corresponding design challenges. 552 ICN offers routers the possibility to aggregate requests and can use 553 several paths, meaning that there is no such thing as end-to-end 554 communication path, e.g., a router that receives two requests for the 555 same content at the same time only sends one requests to its 556 neighbor. The aggregation of requests has a general impact on 557 transport service design. 559 Achieving fairness for requestors can be one challenge as it is not 560 possible to identify the number of clients behind one particular 561 request. A second problem related to request aggregation is the 562 management of request retransmissions. Generally, it is assumed that 563 a router will not transmit a request if it transmitted an identical 564 request recently and because there is no information about the 565 requester, the router cannot distinguish the initial request form a 566 client from a retransmission from the same client. In such a 567 situation, how routers can adapt their timers to use the best of the 568 communication paths. Finally, aggregation of requests has an impact 569 on the server (producer) side. This last has no way to determine the 570 number of clients actually consuming the content it is producing. 571 This shift of model influence the business model of the server, e.g., 572 how to implement pay-per-click? 574 4.6. In-Network Caching 576 Explicitly named content objects allow for caching in virtually any 577 network element, including routers, proxy caches and end-host 578 machines. In-network caching can therefore improve network 579 performance by fetching content from nodes geographically placed 580 closer to the end-user. Several issues that need further 581 investigation have been identified with respect to in-network 582 caching. Here we list some of the most important challenges that 583 relate to the properties of the new ubiquitous caching system. 585 4.6.1. Cache Placement 587 The declining cost of fast memory gives the opportunity to deploy 588 caches in network routers and take advantage of explicitly named 589 cached contents. There exist two approaches to in-network caching, 590 namely on-path and off-path caching. Both approaches have to 591 consider the issue of cache location. Off-path caching is similar to 592 traditional proxy-caching, or CDN server placement. Retrieval of 593 contents from off-path caches requires redirection of requests and 594 therefore, is closely related to the Request-to-Cache Routing problem 595 discussed below. Off-path caches have to be placed in strategic 596 points within a network in order to reduce the redirection delays and 597 the number of detour hops to retrieve cached contents. Previous 598 research on proxy-caching and CDN deployment is helpful in this case. 600 On the other hand, on-path caching requires less network intervention 601 and fits more neatly in an information-/content-centric network. 602 However, on-path caching requires line-speed operation, a fact that 603 places more constraints on the design and operation of in-network 604 caching elements. Furthermore, the gain of such a system of on-path 605 in-network caches relies on opportunistic/accidental cache hits and 606 has therefore been considered of limited benefit, given the huge 607 amount of contents hosted in the Internet. For this reason, network 608 operators might initially consider only a limited number of network 609 elements to be upgraded to in-network caching elements. The decision 610 on which nodes should be equipped with caches is an open issue and 611 might be based, among others, on topological criteria, or traffic 612 characteristics. These challenges relate to both the Content 613 Placement Problem and the Request-to-Cache Routing Problem discussed 614 next. 616 4.6.2. Content Placement -- Content-to-Cache Distribution 618 Given a number of (on-path or off-path) in-network caching elements, 619 content-to-cache distribution will affect both the dynamics of the 620 system, in terms of request redirections (mainly in case of off-path 621 caches) and the gain of the system in terms of cache hits. A 622 straightforward approach to content placement is on-path placement of 623 contents as they travel from source to destination. This approach 624 reduces the computation and communication overhead of placing 625 contents within the network, but on the other hand might reduce the 626 chances of hitting cached contents. This relates to the Request-to- 627 Cache Routing problem discussed next. 629 Furthermore, the number of replicas held in the system brings up 630 resource management issues in terms of cache allocation. For 631 example, continuously replicating content objects in all network 632 elements results in redundant copies of the same objects. The issue 633 of redundant replication has been investigated in the past for 634 hierarchical web-caches. However, in hierarchical web-caching, 635 overlay systems co-ordination between the data and the control plane 636 can guarantee increased performance in terms of cache hits. Line- 637 speed, on-path in-network caching poses different requirements and 638 therefore, new techniques need to be investigated. In this 639 direction, there already exist some studies that attempt to reduce 640 redundancy of cached copies. However, the issue of coordinated 641 content placement in on-path caches still remains open. 643 The Content-to-Cache Allocation problem relates also to the 644 characteristics of the content to be cached. Popular content might 645 need to be put in places where it is going to be requested next. 646 Furthermore, issues of "expected content popularity" might need to be 647 considered in order for some contents to be given priority (e.g., 648 popular content vs. one-timers). The criteria as to which contents 649 should be given priority in in-network content caches relate also to 650 the business relationships between content providers and network 651 operators. Such issues need to be investigated and relate also to 652 the evaluation methodology discussed later on. 654 4.6.3. Request-to-Cache Routing 656 In order to get advantage of cached contents, requests have to be 657 forwarded to the nodes that temporarily host (cache) the 658 corresponding contents. This challenge relates to name-based 659 routing, discussed before. Requests should ideally follow the path 660 to the cached content. However, instructions as to which content is 661 cached where cannot be broadcast throughout the network. Therefore, 662 the knowledge of a content's location at the time of the request 663 might either not exist, or it might not be accurate (i.e., contents 664 might have been removed by the time a request is redirected to a 665 specific node). 667 Co-ordination between the data and the control planes to update 668 information of cached contents has been considered, but in this case 669 scalability issues arise. We therefore, have two options. We either 670 have to rely on opportunistic caching, where requests are forwarded 671 to a server and in case the content they are looking for is found on 672 the path, then content is fetched from this node (instead of the 673 original server), or we employ cache-aware routing techniques. 674 Cache-aware routing can either involve both the control and the data 675 plane, or only one of them. Furthermore, cache-aware routing can be 676 done in a domain-wide scale or can involve more than one individual 677 AS. In the latter case, business relationships between ASes might 678 need to be exploited in order to build a scalable model. 680 4.7. Network Management 682 Managing networks has been a core craft in the IP-based host-centric 683 paradigm ever since the technology was introduced in production 684 networks. However, at the onset of IP, management was considered 685 primarily as an add-on. Essential tools that are used daily by 686 networkers, such as ping and traceroute, did not become widely 687 available until more than a decade or so after IP was first 688 introduced. Management protocols, such as SNMP, also became 689 available much later than the original introduction of IP and many 690 still consider them insufficient despite the years of experience we 691 have running host-centric networks. Today, when new networks are 692 deployed network management is considered a key aspect for any 693 operator, a major challenge which is directly reflected in higher 694 OPEX if not done well. If we want ICN to be deployed in 695 infrastructure networks, development of management tools and 696 mechanisms must go hand-in with the rest of the architecture design. 698 Although defining FCAPS for ICN is clearly outside the scope of this 699 document, there is a need for creating basic tools early on while ICN 700 is still in the design and experimentation phases that can evolve 701 over time and help network operations centers (NOC) to define 702 policies, validate that they are indeed used in practice, be notified 703 early on about failures, determine and resolve configuration 704 problems. AAA as well as performance management, from a NOC 705 perspective, will also need to be considered. Given the expectations 706 for a large number of nodes and unprecedented traffic volumes, 707 automating tasks, or even better employing self-management mechanisms 708 is preferred. The main challenge here is that all tools we have at 709 our disposal today are node-centric, end-to-end oriented, or assuming 710 a packet-stream communication environment. Rethinking reachability 711 and operational availability, for example, can yield significant 712 insights into how information-centric networks will be managed in the 713 future. 715 With respect to network management we see two different aspects. 716 First, any operator needs to manage all resources available in the 717 network, which can range from node connectivity to network bandwidth 718 availability to in-network storage to multi-access support. In ICN, 719 users will also bring into the network significant resources in terms 720 of network coverage extension, storage, and processing capabilities. 721 DTN characteristics should also be considered to the degree that this 722 is possible (e.g. content dissemination through data mules). On the 723 other hand, given that nodes and links are not at the center of an 724 information-centric network, network management should capitalize on 725 native ICN mechanisms. For example, in-network storage and name 726 resolution can be used for monitoring, while native publish/subscribe 727 functionality can be used for triggering notifications. 729 However, the considerations on leveraging intrinsic ICN mechanisms 730 and capabilities to support management operations go beyond a simple 731 mapping exercise. In fact, not only it raises a series of challenges 732 on its own, but also opens up new possibilities for both ICN and 733 "network management" as a concept. For instance, naming mechanisms 734 are central to ICN intrinsic operations, which are used to identify 735 and reach content under different aspects (e.g., CCN uses a 736 hierarchical namespace able to contain human-readable naming scheme, 737 NetInf uses a flat naming structure, etc.). In this way, ICN is 738 decoupled from host-centric aspects on which traditional networking 739 management schemes rely upon. As such, questions are raised which 740 can directly be translated into challenges for network management 741 capability, such as, for example how to address a node or a network 742 segment in a ICN naming paradigm, how to identify which node is 743 connected "where", and if there is a host-centric protocol running 744 from which the management process can also leverage upon. 746 But, on the other hand, these same inherent ICN characteristics also 747 allow us to look into network management through a new perspective. 748 By centering its operations around content, one can conceive new 749 management operations addressing, for example, per-content management 750 or access control, as well as analyzing performance per content name 751 instead of per link or node. Moreover, such considerations can also 752 be used to manage operational aspects of ICN mechanisms themselves. 753 For example, [NDN-MGMT] re-utilizes inherent content-centric 754 capabilities of CCN to manage optimal link connectivity for nodes, in 755 concert with a network optimization process. Conversely, how these 756 content-centric aspects can otherwise influence and impact management 757 in other areas (e.g., security, resilience) is also important, as 758 exemplified by in [ccn-access], where access control mechanisms are 759 integrated into a prototype of the [PURSUIT] architecture. 761 In this way, a set of core research challenges on ICN management can 762 be derived as: 764 o Manage and control content reception at the destination 766 o Coordination of management information exchange and control 767 between ICN nodes and ICN network control points Identification of 768 management and controlling actions and items through information 769 naming 771 o Relationship between NDOs and host entities identification (i.e., 772 how to identify a particular link, interface or flow that need to 773 be managed) 775 5. Link to and Impact on IETF Technologies 777 TBW later. 779 6. Security Considerations 781 See naming and security challenges. 783 7. Informative References 785 [BREADCRUMBS] 786 Rosensweig, E. and J. Kurose, "Breadcrumbs: Efficient, 787 Best-Effort Content Location in Cache Networks", 788 In Proceedings of the IEEE INFOCOM 2009, April 2009. 790 [CCN] Jacobsen, K, D, F, H, and L, "Networking Named Content", 791 CoNEXT 2009 , December 2009. 793 [COMPACT] Cowen, L., "Compact routing with minimum stretch", 794 In Journal of Algorithms, vol. 38, pp. 170--183, 2001. 796 [DONA] Koponen, T., Ermolinskiy, A., Chawla, M., Kim, K., gon 797 Chun, B., and S. Shenker, "A Data-Oriented (and Beyond) 798 Network Architecture", In Proceedings of SIGCOMM 2007, 799 August 2007. 801 [GREEDY] Papadopoulos, F., Krioukov, D., Boguna, M., and A. Vahdat, 802 "Greedy forwarding in dynamic scale-free networks embedded 803 in hyperbolic metric spaces", In Proceedings of the IEEE 804 INFOCOM, San Diego, USA, 2010. 806 [HRICP] Carofiglio, G., Gallo, M., and L. Muscariello, "Joint hop- 807 by-hop and receiver-driven interest control protocol for 808 content-centric networks", In Proceedings of ACM SIGCOMM 809 ICN 2012, DOI 10.1145/2342488.2342497, 2012. 811 [I-D.farrell-decade-ni] 812 Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B., 813 Keraenen, A., and P. Hallam-Baker, "Naming Things with 814 Hashes", draft-farrell-decade-ni-10 (work in progress), 815 August 2012. 817 [ICNNAMING] 818 Ghodsi, A., Koponen, T., Rajahalme, J., Sarolahti, P., and 819 S. Shenker, "Naming in Content-Oriented Architectures", 820 In Proceedings ACM SIGCOMM Workshop on Information-Centric 821 Networking (ICN), 2011. 823 [ICNSURVEY] 824 Ahlgren, B., Dannewitz, C., Imbrenda, C., Kutscher, D., 825 and B. Ohlman, "A Survey of Information-Centric 826 Networking", In Communications Magazine, IEEE , vol.50, 827 no.7, pp.26-36, DOI 10.1109/MCOM.2012.6231276, 2012. 829 [NDN-MGMT] 830 Corujo, D., Aguiar, R., Vidal, I., and J. Garcia-Reinoso, 831 "A named data networking flexible framework for management 832 communications", Communications Magazine, IEEE , vol.50, 833 no.12, pp.36-43 , December 2012. 835 [PURSUIT] Fotiou et al., N., "Developing Information Networking 836 Further: From PSIRP to PURSUIT", In Proceedings of Proc. 837 BROADNETS. ICST, 2010. 839 [RANDOM] Gkantsidis, C., Mihail, M., and A. Saberi, "Random walks 840 in peer-to-peer networks: algorithms and evaluation", 841 In Perform. Eval., vol. 63, pp. 241--263, 2006. 843 [RFC5944] Perkins, C., "IP Mobility Support for IPv4, Revised", 844 RFC 5944, November 2010. 846 [ccn-access] 847 Fotiou, N., Marias, G., and G. Polyzos, "Access control 848 enforcement delegation for information-centric networking 849 architectures", In Proceedings of the second edition of 850 the ICN workshop on Information-centric networking (ICN 851 '12). ACM, New York, NY, USA, 85-90., 2012. 853 Authors' Addresses 855 Dirk Kutscher (editor) 856 NEC 857 Kurfuersten-Anlage 36 858 Heidelberg, 859 Germany 861 Phone: 862 Email: kutscher@neclab.eu 864 Suyong Eum 865 National Institute of Information and Communications Technology 866 4-2-1, Nukui Kitamachi, Koganei 867 Tokyo 184-8795 868 Japan 870 Phone: +81-42-327-6582 871 Email: suyong@nict.go.jp 873 Kostas Pentikousis 874 Huawei Technologies 875 Carnotstrasse 4 876 Berlin 10587 877 Germany 879 Email: k.pentikousis@huawei.com 880 Ioannis Psaras 881 University College London, Dept. of E.E. Eng. 882 Torrington Place 883 London WC1E 7JE 884 United Kingdom 886 Email: i.psaras@ucl.ac.uk 888 Daniel Corujo 889 Universidade de Aveiro 890 Instituto de Telecomunicacoes, Campus Universitario de Santiago 891 Aveiro P-3810-193 892 Portugal 894 Email: dcorujo@av.it.pt 896 Damien Saucez 897 INRIA 899 Email: damien.saucez@inria.fr