ICN Research Challenges
draft-irtf-icnrg-challenges-04

[HRICP] and [ConTug] describe request rate control protocols and
   corresponding design challenges.

   As mentioned above, the ICN communication paradigm does not depend
   strictly on end-to-end flows, as contents might be received from in-
   network caches.  The traditional concept of a flow is then somewhat
   not valid as sub-flows, or flowlets, might be formed on the fly, when
   fractions of an NDO are transmitted from in-network caches.  For a
   transport layer protocol this is challenging, as any measurement
   related to this flow as traditionally done by transport protocols
   such as TCP, can often prove misleading.  For example, false Round-
   Trip Time (RTT) measurements will lead to largely variable average
   and smoothed RTT values, which in turn will trigger false timeout
   expirations.

   Furthermore, out-of-order delivery is expected to be common in a
   scenario where parts of a data object are retrieved from in-network
   caches, rather than from the origin server.  Several techniques for
   dealing with out-of-order delivery have been proposed in the past for
   TCP, some of which could potentially be modified and re-used in the
   context of ICN.  Further research is needed in this direction though
   to choose the right technique and adjust it according to the
   requirements of the ICN architecture and transport protocol in use.

   ICN offers routers the possibility to aggregate requests and can use
   several paths, meaning that there is no such thing as a (dedicated)
   end-to-end communication path, e.g., a router that receives two
   requests for the same content at the same time only sends one request
   to its neighbour.  The aggregation of requests has a general impact
   on transport protocol design and offers new options for employing
   per-node forwarding strategies and for rethinking in-network resource
   sharing. [hotnets2014-psaras]

   Achieving fairness for requestors can be one challenge as it is not
   possible to identify the number of requestors behind one particular
   request.  A second problem related to request aggregation is the
   management of request retransmissions.  Generally, it is assumed that
   a router will not transmit a request if it transmitted an identical
   request recently and because there is no information about the
   requestor, the router cannot distinguish the initial request from a
   client from a retransmission from the same client.  In such a
   situation, how routers can adapt their timers to use the best of the
   communication paths.

Kutscher, et al.         Expires August 11, 2016               [Page 22]
Internet-Draft               ICN Challenges                February 2016

4.7.  In-Network Caching

   Explicitly named data objects allow for caching at virtually any
   network element, including routers, proxy caches and end-user
   devices.  In-network caching can therefore improve network
   performance by fetching content from nodes geographically placed
   closer to the end-user.  Several issues that need further
   investigation have been identified with respect to in-network
   caching.  In this section we list important challenges that relate to
   the properties of the new ubiquitous caching system.

4.7.1.  Cache Placement

   The declining cost of fast memory gives the opportunity to deploy
   caches in network routers and take advantage of cached NDOs.  We
   identify two approaches to in-network caching, namely, on-path and
   off-path caching.  Both approaches have to consider the issue of
   cache location.  Off-path caching is similar to traditional proxy-
   caching or CDN server placement.  Retrieval of contents from off-path
   caches requires redirection of requests and, therefore, is closely
   related to the Request-to-Cache Routing problem discussed later.
   Off-path caches have to be placed in strategic points within a
   network in order to reduce the redirection delays and the number of
   detour hops to retrieve cached contents.  Previous research on proxy-
   caching and CDN deployment is helpful in this case.

   On the other hand, on-path caching requires less network intervention
   and fits more neatly in ICN.  However, on-path caching requires line-
   speed operation, which places more constraints on the design and
   operation of in-network caching elements.  Furthermore, the gain of
   such a system of on-path in-network caches relies on opportunistic
   cache hits and has therefore been considered of limited benefit,
   given the huge amount of contents hosted in the Internet.  For this
   reason, network operators might initially consider only a limited
   number of network elements to be upgraded to in-network caching
   elements.  The decision on which nodes should be equipped with caches
   is an open issue and might be based, among others, on topological
   criteria, or traffic characteristics.  These challenges relate to
   both the Content Placement Problem and the Request-to-Cache Routing
   Problem discussed below.

   In most cases, however, the driver for the implementation, deployment
   and operation of in-network caches will be its cost.  Operating
   caches at line speed inevitably requires faster memory, which
   increases the implementation cost.  Based on the capital to be
   invested, ISPs will need to make strategic decisions on the cache
   placement, which can be driven by several factors, such as: avoid
   inter-domain/expensive links, centrality of nodes, size of domain and

Kutscher, et al.         Expires August 11, 2016               [Page 23]
Internet-Draft               ICN Challenges                February 2016

   the corresponding spatial locality of users, traffic patterns in a
   specific part of the network (e.g., university vs. business vs.
   fashion district of a city).

4.7.2.  Content Placement -- Content-to-Cache Distribution

   Given a number of on-path or off-path in-network caching elements,
   content-to-cache distribution will affect both the dynamics of the
   system, in terms of request redirections (mainly in case of off-path
   caches) and the gain of the system in terms of cache hits.  A
   straightforward approach to content placement is on-path placement of
   contents as they travel from source to destination.  This approach
   reduces the computation and communication overhead of placing content
   within the network but, on the other hand, might reduce the chances
   of hitting cached contents.  This relates to the Request-to-Cache
   Routing problem discussed next.

   Furthermore, the number of replicas held in the system brings up
   resource management issues in terms of cache allocation.  For
   example, continuously replicating data objects in all network
   elements results in redundant copies of the same objects.  The issue
   of redundant replication has been investigated in the past for
   hierarchical web caches.  However, in hierarchical web-caching,
   overlay systems coordination between the data and the control plane
   can guarantee increased performance in terms of cache hits.  Line-
   speed, on-path in-network caching poses different requirements and
   therefore, new techniques need to be investigated.  In this
   direction, reducing the redundancy of cached copies is a study item.
   However, the issue of coordinated content placement in on-path caches
   remains open.

   The Content-to-Cache Allocation problem relates also to the
   characteristics of the content to be cached.  Popular content might
   need to be placed where it is going to be requested next.
   Furthermore, issues of "expected content popularity" or temporal
   locality need to be taken into account in designing in-network
   caching algorithms in order for some contents to be given priority
   (e.g., popular content vs. one-timers).  The criteria as to which
   contents should be given priority in in-network content caches relate
   also to the business relationships between content providers and
   network operators.  Business model issues will drive some of these
   decisions on content-to-cache distribution, but such issues are
   outside the scope of this note and are not discussed here further.

Kutscher, et al.         Expires August 11, 2016               [Page 24]
Internet-Draft               ICN Challenges                February 2016

4.7.3.  Request-to-Cache Routing

   In order to take advantage of cached contents, requests have to be
   forwarded to the nodes that cache the corresponding contents.  This
   challenge relates to name-based routing, discussed earlier.  Requests
   should ideally follow the path to the cached NDO.  However,
   instructions as to which content is cached where cannot be broadcast
   throughout the network.  Therefore, the knowledge of a NDO location
   at the time of the request might either not exist, or it might not be
   accurate (i.e., contents might have been removed by the time a
   request is redirected to a specific node).

   Coordination between the data and the control planes to update
   information of cached contents has been considered, but in this case
   scalability issues arise.  We therefore, have two options.  We either
   have to rely on opportunistic caching, where requests are forwarded
   to a server and in case the NDOt is found on the path, then the
   content is fetched from this node instead of the origin server; or we
   employ cache-aware routing techniques.  Cache-aware routing can
   either involve both the control and the data plane, or only one of
   them.  Furthermore, cache-aware routing can be done in a domain-wide
   scale or can involve more than one individual Autonomous System (AS).
   In the latter case, business relationships between ASes might need to
   be exploited in order to build a scalable model.

4.7.4.  Staleness Detection of Cached NDOs

   Due to the largely distributed copies of NDOs in in-network caches,
   ICN should be able to provide a staleness verification algorithm
   which provides synchronization of NDOs located at their providers and
   in-network caching points.  Two types of approaches can be considered
   for this problem, namely direct and indirect approaches.

   In the direct approach, each cache looks up certain information in
   the name of NDO, e.g., timestamp which directly indicates its
   staleness.  This approach is applicable to some NDOs that come from
   machine-to-machine and Internet of Things scenarios, whose base
   operation relies on obtaining the latest version of that NDO (i.e., a
   soil sensor in a farm providing different continuous parameters that
   are sent to a display or green-house regulation system) [FRESHNESS].

   In the indirect approach, each cache consults the publisher of the
   cached NDO about its staleness before serving it.  This approach
   assumes that the NDO includes the publisher information which can be
   used to reach the publisher.  It is suitable for the NDO whose
   expiration time is difficult to be set in advance, e.g., a web page
   which contains main text (that stays the same ever after) and the

Kutscher, et al.         Expires August 11, 2016               [Page 25]
Internet-Draft               ICN Challenges                February 2016

   interactive sections such as comments or ads (that are updated
   irregularly).

   It is often argued that ignoring stale NDOs in caches and simply
   providing new names for updated NDOs might be sufficient rather than
   using a staleness verification algorithm to manage them.  However,
   notifying the new names of updated NDOs to users is not a trivial
   task.  Unless the update is informed to all users at the same time,
   some users would use the old name although intending to retrieve the
   updated NDO.

   One research challenge is how to design consistency and coherence
   models for caching NDOs along with their revision handling and
   updating protocols in a scalable manner.

4.7.5.  Cache Sharing by Multiple Applications

   When ICN is deployed as a general, application-independent network
   and cache infrastructure, multiple consumers and producers
   (representing different applications) would communicate over the same
   infrastructure.  With universal naming schemes or sufficiently unique
   hash-based identifiers different application could also share
   identical NDOs in a transparent way.

   Depending on the naming, data integrity and data orign authentication
   approaches, there may be technical and business challenges to share
   caches across different applications, for example content protection,
   avoiding cache poisoning, ensuring performance isolation etc.  As ICN
   research matures, these challenges should be addressed more
   specifically in a dedicated document.

4.8.  Network Management

   Managing networks has been a core craft in the IP-based host-centric
   paradigm ever since the technology was introduced in production
   networks.  However, at the onset of IP, management was considered
   primarily as an add-on.  Essential tools that are used daily by
   networkers, such as ping and traceroute, did not become widely
   available until more than a decade or so after IP was first
   introduced.  Management protocols, such as SNMP, also became
   available much later than the original introduction of IP and many
   still consider them insufficient despite the years of experience we
   have running host-centric networks.  Today, when new networks are
   deployed network management is considered a key aspect for any
   operator, a major challenge which is directly reflected in higher
   operational cost if not done well.  If we want ICN to be deployed in
   infrastructure networks, development of management tools and

Kutscher, et al.         Expires August 11, 2016               [Page 26]
Internet-Draft               ICN Challenges                February 2016

   mechanisms must go hand-in-hand with the rest of the architecture
   design.

   Although defining an FCAPS (fault, configuration, accounting,
   performance, security) [ISOIEC-7498-4] management model for ICN is
   clearly outside the scope of this document, there is a need for
   creating basic tools early on while ICN is still in the design and
   experimentation phases that can evolve over time and help network
   operations centers (NOCs) to define policies, validate that they are
   indeed used in practice, be notified early on about failures,
   determine and resolve configuration problems.  Authentication,
   Authorization, Accounting (AAA) as well as performance management,
   from a NOC perspective, will also need to be considered.  Given the
   expectations for a large number of nodes and unprecedented traffic
   volumes, automating tasks, or even better employing self-management
   mechanisms are preferred.  The main challenge here is that all tools
   we have at our disposal today are node-centric, end-to-end oriented,
   or assuming a packet-stream communication environment.  Rethinking
   reachability and operational availability, for example, can yield
   significant insights into how information-centric networks will be
   managed in the future.

   With respect to network management we see three different aspects.
   First, any operator needs to manage all resources available in the
   network, which can range from node connectivity to network bandwidth
   availability to in-network storage to multi-access support.  In ICN,
   users will also bring into the network significant resources in terms
   of network coverage extension, storage, and processing capabilities.
   Delay Tolerant Networking (DTN) characteristics should also be
   considered to the degree that this is possible (e.g., content
   dissemination through data mules).  Secondly, given that nodes and
   links are not at the center of an information-centric network,
   network management should capitalize on native ICN mechanisms.  For
   example, in-network storage and name resolution can be used for
   monitoring, while native publish/subscribe functionality can be used
   for triggering notifications.  Finally, management is also at the
   core of network controlling capabilities by allowing operating
   actions to be mediated and decided, triggering and activating
   networking procedures in an optimized way.  For example, monitoring
   aspects can be conjugated with different management actions in a
   coordinated way, allowing network operations to flow in a concertated
   manner.

   However, the considerations on leveraging intrinsic ICN mechanisms
   and capabilities to support management operations go beyond a simple
   mapping exercise.  In fact, not only it raises a series of challenges
   on its own, but also opens up new possibilities for both ICN and
   "network management" as a concept.  For instance, naming mechanisms

Kutscher, et al.         Expires August 11, 2016               [Page 27]
Internet-Draft               ICN Challenges                February 2016

   are central to ICN intrinsic operations, which are used to identify
   and reach content under different aspects (e.g., hierarchically
   structured vs. 'flattish' names).  In this way, ICN is decoupled from
   host-centric aspects on which traditional networking management
   schemes rely upon.  As such, questions are raised which can directly
   be translated into challenges for network management capability, such
   as, for example how to address a node or a network segment in a ICN
   naming paradigm, how to identify which node is connected "where", how
   to be aware of the node capabilities (i.e., high or low-powered M2M
   node) and if there is a host-centric protocol running where the
   management process can also leverage.

   But, on the other hand, these same inherent ICN characteristics also
   allow us to look into network management through a new perspective.
   By centering its operations around NDOs, one can conceive new
   management operations addressing, for example, per-content management
   or access control, as well as analyzing performance per NDO instead
   of per link or node.  Moreover, such considerations can also be used
   to manage operational aspects of ICN mechanisms themselves.  For
   example, [NDN-MGMT] re-utilizes inherent content-centric capabilities
   of CCN to manage optimal link connectivity for nodes, in concert with
   a network optimization process.  Conversely, how these content-
   centric aspects can otherwise influence and impact management in
   other areas (e.g., security, resilience) is also important, as
   exemplified in [CCN-ACCESS], where access control mechanisms are
   integrated into a prototype of the [PURSUIT] architecture.

   The set of core research challenges on ICN management include:

   o  Management and control of NDO reception at the requestor

   o  Coordination of management information exchange and control
      between ICN nodes and ICN network control points

   o  Identification of management and controlling actions and items
      through information naming

   o  Relationship between NDOs and host entities identification, i.e.,
      how to identify a particular link, interface, or flow that need to
      be managed.

4.9.  ICN Applications

   ICN can be applied to different application domains and is expected
   to provide benefits for application developers by providing a more
   suitable interface for application developers (in addition to the
   other ICN benefits described above).  [RFC7476] provides an overview

Kutscher, et al.         Expires August 11, 2016               [Page 28]
Internet-Draft               ICN Challenges                February 2016

   of relevant application domains at large.  This section discusses
   opportunities and challenges for selected application types.

4.9.1.  Web Applications

   Intuitively, the ICN request/response communication style seems to be
   directly mappable to web communication over HTTP.  NDO names could be
   the equivalent of URIs in today's web, proprietary and transparent
   caching could be obsoleted by ICN in-network caching, and developers
   could directly use an ICN request/response API to build applications.

   Research efforts such as [ICN2014-WEB-NDN] have analysed real-world
   web applications and ways to implement them in ICN.  The most
   significant insight is that, REST-style web communication heavily
   relies on transmitting user/application context information in HTTP
   GET requests, which would have to be mapped to corresponding ICN
   messages.  The challenge in ICN would be how to exactly achieve that
   mapping.  This could be done to some degree by extending name formats
   or by extending message structure to include cookies and similar
   context information.  The design decisions would need to consider
   overhead in routers (if larger GET/Interest messages would have to be
   stored in corresponding tables on routers, for example.

   Other challenges include the ability to return different results
   based on requestor-specific processing in the presence on immutable
   objects (and name-object bindings) in ICN and the ability for
   efficient bidirectional communication, which would require some
   mechanism to name and reach requestor applications.

4.9.2.  Video Streaming and Download

   One of ICN's prime application areas is video streaming and download
   where accessing named data, object-level security and in-network
   storage can fulfil requirements for both video streaming and
   download.  The applicability and benefits of ICN to video has been
   demonstrated by several prototype developments
   [ICN2014-AHLGREN-VIDEO-DEMO].

   [I-D.irtf-icnrg-videostreaming] discusses the opportunities and
   challenges for implementing today's' video services such as DASH-
   based streaming and download over ICN, considering performance
   requirements, relationship to peer-to-peer live streaming, IPTV and
   Digital Rights Management (DRM).

   In addition to just porting today's video application from a host-
   centric paradigm to ICN there are also promising opportunities to
   leverage the ICN network services for redesigning and thus
   significantly enhancing video access and distribution

Kutscher, et al.         Expires August 11, 2016               [Page 29]
Internet-Draft               ICN Challenges                February 2016

   [ICNRG-2015-01-WESTPHAL].  For example, ICN store and forward could
   be leveraged for rate adaptation to achieve maximum throughput and
   optimal QoE in scenarios with varying link properties, if capacity
   information is fed back to rate selection algorithms at senders.
   Other optimizations such as more aggressive prefetching could be
   performed in the network by leveraging visibility of chunk NDO names
   and NDO metadata in the network.  Moreover, multi-source rate
   adaptation in combination with network coding could enable better
   quality of experience, for example in multi-interface/access
   scenarios where multiple paths from client to upstream caches exist
   [RFC7476].

4.9.3.  Internet of Things

   The essence of ICN lies in the name based routing that enables users
   to retrieve NDOs by the names regardless of their locations.  By the
   definition, ICN is suitable well for IoT applications, where users
   consume data generated from IoTs without maintaining secure
   connections to them.  The basic put/get style APIs of ICN enable
   developers to build IoT applications in a simple and fast manner.

   On-going efforts such as [I-D.lindgren-icnrg-efficientiot],
   [I-D.zhang-iot-icn-challenges], [ICN2014-NDNWILD] have addressed the
   requirements and challenges of ICN for IoT.  For instance, many IoT
   applications depend on a PUSH model where data transmission is
   initiated by the publisher, and so they can support various real-time
   applications: emergency alarm, etc.  However, ICN does not support
   the PUSH model in a native manner due to its inherent receiver-driven
   data transmission mechanism.  The challenge would be how to
   efficiently support the PUSH model in ICN, and so it provides
   publish/subscribe style APIs for IoT application developers.  This
   could be done by introducing other types of identifiers such as a
   device identifier or by extending the current request/response
   communication style, which may result in heavy overhead in ICN
   routers.

   Moreover, key characteristics of the ICN underlying operation also
   impact important aspects of IoT, such as the caching in content
   storage of network forwarding entities.  This allows the
   simplification of ICN-based IoT application development, since the
   network is able to act on named content, generic names provide a way
   to address content independently of the underlying device (and
   access) technology, and bandwidth consumption is optimized due to the
   availability of cached content.  However, these aspect raise
   challenges themselves, concerning the freshness of the information
   received from the cache in contrast to the last value generated by a
   sensor, as well as pushing content to specific nodes (e.g., for
   controlling them), which requires individual addressing for

Kutscher, et al.         Expires August 11, 2016               [Page 30]
Internet-Draft               ICN Challenges                February 2016

   identification.  In addition, due to the heterogeneous nature of IoT
   nodes, their processing capabilities might not be able to handle the
   necessary content signing verification procedures.

5.  Security Considerations

   This document does not impact the security of the Internet.  ICN
   security-related questions related to ICN are discussed in
   Section 4.2.

6.  IANA Considerations

   This document presents no IANA considerations.

7.  Informative References

   [access-control-delegation]
              Fotiou, N., Marias, G., and G. Polyzos, "Access control
              enforcement delegation for information-centric networking
              architectures", Proceedings of the second edition of the
              ICN workshop on Information-centric networking (ICN '12)
              Helsinki, Finnland, 2012.

   [BACKSCATTER]
              Waehlisch, M., Schmidt, TC., and M. Vahlenkamp,
              "Backscatter from the Data Plane - Threats to Stability
              and Security in Information-Centric Network
              Infrastructure", Computer Networks Vol 57, No. 16, pp.
              3192-3206, November 2013.

   [BREADCRUMBS]
              Rosensweig, E. and J. Kurose, "Breadcrumbs: Efficient,
              Best-Effort Content Location in Cache Networks", In
              Proceedings of the IEEE INFOCOM 2009, April 2009.

   [CCN]      Jacobson, , K, , D, , F, , H, , and L, "Networking Named
              Content", CoNEXT 2009 , December 2009.

   [CCN-ACCESS]
              Fotiou, N., Marias, G., and G. Polyzos, "Access control
              enforcement delegation for information-centric networking
              architectures", In Proceedings of the second edition of
              the ICN workshop on Information-centric networking (ICN
              '12). ACM, New York, NY, USA, 85-90., 2012.

   [Chaum]    Chaum, D. and E. van Heijst, "Group signatures", In
              Proceedings of EUROCRYPT, 1991.

Kutscher, et al.         Expires August 11, 2016               [Page 31]
Internet-Draft               ICN Challenges                February 2016

   [COMPACT]  Cowen, L., "Compact routing with minimum stretch", In
              Journal of Algorithms, vol. 38, pp. 170--183, 2001.

   [ConTug]   Arianfar, S., Nikander, P., Eggert, L., Ott, J., and W.
              Wong, "ConTug: A Receiver-Driven Transport Protocol for
              Content-Centric Networks", Technical Report Aalto
              University Comnet, 2011.

   [DONA]     Koponen, T., Ermolinskiy, A., Chawla, M., Kim, K., gon
              Chun, B., and S. Shenker, "A Data-Oriented (and Beyond)
              Network Architecture", In Proceedings of SIGCOMM 2007,
              August 2007.

   [encryption-ac]
              Kurihara, J., Uzun, E., and C. Wood, "An Encryption-Based
              Access Control Framework for Content-Centric Networking",
              IFIP Networking 2015 Toulouse, France, 2015, September
              2015.

   [FRESHNESS]
              Quevedo, J., Corujo, D., and R. Aguiar, "Consumer Driven
              Information Freshness Approach for Content Centric
              Networking", IEEE INFOCOM Workshop on Name-Oriented
              Mobility Toronto, Canada, 2014, May 2014.

   [GREEDY]   Papadopoulos, F., Krioukov, D., Boguna, M., and A. Vahdat,
              "Greedy forwarding in dynamic scale-free networks embedded
              in hyperbolic metric spaces", In Proceedings of the IEEE
              INFOCOM, San Diego, USA, 2010.

   [hotnets2014-psaras]
              Psaras, I., Saino, L., and G. Pavlou, "Revisiting Resource
              Pooling: The case of In-Network Resource Sharing", ACM
              HotNets Los Angeles, USA, 2014, October 2014.

   [HRICP]    Carofiglio, G., Gallo, M., and L. Muscariello, "Joint hop-
              by-hop and receiver-driven interest control protocol for
              content-centric networks", In Proceedings of ACM SIGCOMM
              ICN 2012, DOI 10.1145/2342488.2342497, 2012.

   [I-D.irtf-icnrg-videostreaming]
              Lederer, S., cedric.westphal@huawei.com, c., Mueller, C.,
              Detti, A., Corujo, D., Wang, J., Montpetit, M., Murray,
              N., aytav.azgin, a., LIU, S., Timmerer, C., and D. Posch,
              "Adaptive Video Streaming over ICN", draft-irtf-icnrg-
              videostreaming-05 (work in progress), December 2015.

Kutscher, et al.         Expires August 11, 2016               [Page 32]
Internet-Draft               ICN Challenges                February 2016

   [I-D.lindgren-icnrg-efficientiot]
              Lindgren, A., Abdesslem, F., Ahlgren, B., Schelen, O., and
              A. Malik, "Applicability and Tradeoffs of Information-
              Centric Networking for Efficient IoT", draft-lindgren-
              icnrg-efficientiot-03 (work in progress), July 2015.

   [I-D.zhang-iot-icn-challenges]
              Zhang, Y., Raychadhuri, D., Grieco, L., Baccelli, E.,
              Burke, J., Ravindran, R., and G. Wang, "ICN based
              Architecture for IoT - Requirements and Challenges",
              draft-zhang-iot-icn-challenges-02 (work in progress),
              August 2015.

   [ICN2014-AHLGREN-VIDEO-DEMO]
              Ahlgren, B., Jonasson, A., and B. Ohlman, "Demo Overview:
              HTTP Live Streaming over NetInf Transport", ACM SIGCOMM
              Information-Centric Networking Conference Paris, France,
              2014, September 2014.

   [ICN2014-NDNWILD]
              Baccelli, E., Mehlis, C., Hahm, O., Schmidt, T., and M.
              Waehlisch, "Information Centric Networking in the IoT:
              Experiments with NDN in the Wild", ACM SIGCOMM
              Information-Centric Networking Conference Paris, France,
              2014, September 2014.

   [ICN2014-WEB-NDN]
              Moiseenko, I., Stapp, M., and D. Oran, "Communication
              Patterns for Web Interaction in Named Data Networking",
              ACM SIGCOMM Information-Centric Networking Conference
              Paris, France, 2014, September 2014.

   [ICNNAMING]
              Ghodsi, A., Koponen, T., Rajahalme, J., Sarolahti, P., and
              S. Shenker, "Naming in Content-Oriented Architectures", In
              Proceedings ACM SIGCOMM Workshop on Information-Centric
              Networking (ICN), 2011.

   [ICNRG-2015-01-WESTPHAL]
              Westphal, C., "Video over ICN", IRTF ICNRG Meeting
              Cambridge, Massachusetts, USA, 2015, URI
              http://www.ietf.org/proceedings/interim/2015/01/13/icnrg/
              slides/slides-interim-2015-icnrg-1-0.pptx, January 2015.

Kutscher, et al.         Expires August 11, 2016               [Page 33]
Internet-Draft               ICN Challenges                February 2016

   [ICNSURVEY]
              Ahlgren, B., Dannewitz, C., Imbrenda, C., Kutscher, D.,
              and B. Ohlman, "A Survey of Information-Centric
              Networking", In Communications Magazine, IEEE , vol.50,
              no.7, pp.26-36, DOI 10.1109/MCOM.2012.6231276, 2012.

   [ISOIEC-7498-4]
              ISO, , "Information Processing Systems -- Open Systems
              Interconnection -- Basic Reference Model -- Part 4:
              Management Framework", URI
              http://standards.iso.org/ittf/PubliclyAvailableStandards/
              s014258_ISO_IEC_7498-4_1989(E).zip, November 1989.

   [MANI]     Pentikousis, K. and T. Rautio, "A multiaccess Network of
              Information", WoWMoM 2010, IEEE , June 2010.

   [MDHT]     D'Ambrosio, M., Dannewitz, C., Karl, H., and V.
              Vercellone, "MDHT: A hierarchical name resolution service
              for information-centric networks", ACM SIGCOMM workshop on
              Information-centric networking Toronto, Canada, 2011,
              August 2011.

   [MMIN]     Pentikousis, K. and P. Bertin, "Mobility management in
              infrastructure networks", Internet Computing, IEEE, vol.
              17, no. 5, pp. 74-79 , October 2013.

   [ndn-controlled-sharing]
              Yu, Y., "Controlled Sharing of Sensitive Content", IRTF
              ICNRG Meeting San Francisco, USA, 2015, URI
              https://www.ietf.org/proceedings/interim/2015/10/03/icnrg/
              slides/slides-interim-2015-icnrg-4-8.pdf, October 2015.

   [NDN-MGMT]
              Corujo, D., Aguiar, R., Vidal, I., and J. Garcia-Reinoso,
              "A named data networking flexible framework for management
              communications", Communications Magazine, IEEE , vol.50,
              no.12, pp.36-43 , December 2012.

   [PURSUIT]  Fotiou et al., N., "Developing Information Networking
              Further: From PSIRP to PURSUIT", In Proceedings of Proc.
              BROADNETS.  ICST, 2010.

   [RANDOM]   Gkantsidis, C., Mihail, M., and A. Saberi, "Random walks
              in peer-to-peer networks: algorithms and evaluation", In
              Perform. Eval., vol. 63, pp. 241--263, 2006.

Kutscher, et al.         Expires August 11, 2016               [Page 34]
Internet-Draft               ICN Challenges                February 2016

   [RFC2002]  Perkins, C., Ed., "IP Mobility Support", RFC 2002, DOI
              10.17487/RFC2002, October 1996,
              <http://www.rfc-editor.org/info/rfc2002>.

   [RFC4838]  Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst,
              R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant
              Networking Architecture", RFC 4838, DOI 10.17487/RFC4838,
              April 2007, <http://www.rfc-editor.org/info/rfc4838>.

   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/
              RFC5246, August 2008,
              <http://www.rfc-editor.org/info/rfc5246>.

   [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
              Housley, R., and W. Polk, "Internet X.509 Public Key
              Infrastructure Certificate and Certificate Revocation List
              (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
              <http://www.rfc-editor.org/info/rfc5280>.

   [RFC5944]  Perkins, C., Ed., "IP Mobility Support for IPv4, Revised",
              RFC 5944, DOI 10.17487/RFC5944, November 2010,
              <http://www.rfc-editor.org/info/rfc5944>.

   [RFC6920]  Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B.,
              Keranen, A., and P. Hallam-Baker, "Naming Things with
              Hashes", RFC 6920, DOI 10.17487/RFC6920, April 2013,
              <http://www.rfc-editor.org/info/rfc6920>.

   [RFC7476]  Pentikousis, K., Ed., Ohlman, B., Corujo, D., Boggia, G.,
              Tyson, G., Davies, E., Molinaro, A., and S. Eum,
              "Information-Centric Networking: Baseline Scenarios", RFC
              7476, DOI 10.17487/RFC7476, March 2015,
              <http://www.rfc-editor.org/info/rfc7476>.

   [SEEN]     Pentikousis, K., "In search of energy-efficient mobile
              networking", Communications Magazine, IEEE, vol. 48, no.
              1, pp. 95-103 , January 2010.

Appendix A.  Acknowledgments

   The authors would like to thank Georgios Karagiannis for providing
   suggestions on QoS research challenges, Dimitri Papadimitriou for
   feedback on the routing section, and Joerg Ott and Stephen Farrell
   for reviewing the whole document.

Kutscher, et al.         Expires August 11, 2016               [Page 35]
Internet-Draft               ICN Challenges                February 2016

Authors' Addresses

   Dirk Kutscher (editor)
   NEC
   Kurfuersten-Anlage 36
   Heidelberg
   Germany

   Email: kutscher@neclab.eu

   Suyong Eum
   National Institute of Information and Communications Technology
   4-2-1, Nukui Kitamachi, Koganei
   Tokyo  184-8795
   Japan

   Phone: +81-42-327-6582
   Email: suyong@nict.go.jp

   Kostas Pentikousis
   EICT GmbH
   Torgauer Strasse 12-15
   Berlin  10829
   Germany

   Email: k.pentikousis@eict.de

   Ioannis Psaras
   University College London, Dept. of E.E.  Eng.
   Torrington Place
   London  WC1E 7JE
   United Kingdom

   Email: i.psaras@ucl.ac.uk

   Daniel Corujo
   Universidade de Aveiro
   Instituto de Telecomunicacoes, Campus Universitario de Santiago
   Aveiro  P-3810-193
   Portugal

   Email: dcorujo@av.it.pt

Kutscher, et al.         Expires August 11, 2016               [Page 36]
Internet-Draft               ICN Challenges                February 2016

   Damien Saucez
   INRIA
   2004 route des Lucioles - BP 93
   Sophia Antipolis  06902 Cedex
   France

   Email: damien.saucez@inria.fr

   Thomas C. Schmidt
   HAW HAmburg
   Berliner Tor 7
   Hamburg  20099
   Germany

   Email: t.schmidt@ieee.org

   Matthias Waehlisch
   FU Berlin
   Takustr. 9
   Berlin  14195
   Germany

   Email: waehlisch@ieee.org

Kutscher, et al.         Expires August 11, 2016               [Page 37]