[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02 draft-irtf-icnrg-challenges

Network Working Group                                   D. Kutscher, Ed.
Internet-Draft                                                       NEC
Intended status: Standards Track                                  S. Eum
Expires: August 14, 2013                                            NICT
                                                          K. Pentikousis
                                                                  Huawei
                                                               I. Psaras
                                                                     UCL
                                                               D. Corujo
                                                  Universidade de Aveiro
                                                               D. Saucez
                                                                   INRIA
                                                       February 10, 2013


                        ICN Research Challenges
                   draft-kutscher-icnrg-challenges-00

Abstract

   This memo describes research challenges for Information-Centric
   Networking.  Information-centric networking is an approach to evolve
   the Internet infrastructure to directly support this use by
   introducing uniquely named data as a core Internet principle.  Data
   becomes independent from location, application, storage, and means of
   transportation, enabling in-network caching and replication.
   Challenges include naming, security, routing, system scalability,
   mobility management, wireless networking, transport services, in-
   network caching, and network management.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on August 14, 2013.

Copyright Notice



Kutscher, et al.         Expires August 14, 2013                [Page 1]


Internet-Draft               ICN Challenges                February 2013


   Copyright (c) 2013 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Problems with Information Distribution Today . . . . . . . . .  4
   3.  ICN Concepts . . . . . . . . . . . . . . . . . . . . . . . . .  5
   4.  ICN Research Challenges  . . . . . . . . . . . . . . . . . . .  6
     4.1.  Naming and Security  . . . . . . . . . . . . . . . . . . .  6
     4.2.  Routing and Resolution System Scalability  . . . . . . . .  8
       4.2.1.  Route-By-Name Routing (RBNR) . . . . . . . . . . . . .  9
       4.2.2.  Lookup-By-Name Routing (LBNR)  . . . . . . . . . . . .  9
       4.2.3.  Hybrid Routing (HR)  . . . . . . . . . . . . . . . . . 10
     4.3.  Mobility Management  . . . . . . . . . . . . . . . . . . . 10
     4.4.  Wireless Networking  . . . . . . . . . . . . . . . . . . . 12
     4.5.  Transport Services . . . . . . . . . . . . . . . . . . . . 12
     4.6.  In-Network Caching . . . . . . . . . . . . . . . . . . . . 13
       4.6.1.  Cache Placement  . . . . . . . . . . . . . . . . . . . 13
       4.6.2.  Content Placement -- Content-to-Cache Distribution . . 14
       4.6.3.  Request-to-Cache Routing . . . . . . . . . . . . . . . 15
     4.7.  Network Management . . . . . . . . . . . . . . . . . . . . 15
   5.  Link to and Impact on IETF Technologies  . . . . . . . . . . . 17
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 17
   7.  Informative References . . . . . . . . . . . . . . . . . . . . 17
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19

















Kutscher, et al.         Expires August 14, 2013                [Page 2]


Internet-Draft               ICN Challenges                February 2013


1.  Introduction

   Distributing and manipulating named information is a major
   application in the Internet today.  In addition to web-based content
   distribution, other distribution technologies (such as P2P and CDN)
   have emerged and are promoting a communication model of accessing
   data by name, regardless of origin server location.

   In order to respond to increasing traffic volume in the current
   Internet for applications such as mobile video and cloud computing, a
   set of disparate technologies and distribution services are applied
   that employ caching, replication and content distribution in
   different specific ways.  These approaches are currently deployed in
   separate silos -- different CDN providers and P2P applications rely
   on specific distribution technologies.  It is not possible to
   uniquely and securely identify named information independently of the
   distribution channel; and the different distribution approaches are
   typically implemented as an overlay, potentially leading to
   unnecessary inefficiency.

   For example, creating and sharing multimedia content in a social
   networking application today, typically requires uploading data
   objects to centralized service provider platforms, from where it can
   be accessed individually by other users.  Even if content sharing is
   intended to happen locally, e.g., in a local network or local area,
   the actual communication will require interactions from any
   interested user with the service provider.  CDNs can alleviate the
   situation only partly, because, due to organizational and economic
   reasons, it is not common to deploy CDN gear ubiquitously.  Moreover,
   since CDNs and the HTTP communication sessions form overlays, the
   actual communication, i.e., the requests for named content and the
   actual responses, are largely invisible to the network, i.e., it is
   not easily possible to optimize efficiency and performance.  For
   example in a wireless access network, it is not possible to leverage
   inherent broadcast functionality (to avoid duplicate transmission of
   the same content) due to limitations from point-to-point and overlay
   communication.

   Information-centric networking (ICN) is an approach to evolve the
   Internet infrastructure to directly support this use by introducing
   uniquely named data as a core Internet principle.  Data becomes
   independent from location, application, storage, and means of
   transportation, enabling in-network caching and replication.  The
   expected benefits are improved efficiency, better support for
   provenance verification and name-content binding validation, better
   scalability with respect to information/bandwidth demand and better
   robustness in challenging communication scenarios.




Kutscher, et al.         Expires August 14, 2013                [Page 3]


Internet-Draft               ICN Challenges                February 2013


   ICN concepts can be applied to different layers of the protocol
   stack: name-based data access can be implemented on top of the
   existing IP infrastructure, e.g., by providing resource naming,
   ubiquitous caching and corresponding transport services, or it can be
   seen as a packet-level internetworking technology that would cause
   fundamental changes to Internet routing and forwarding.  In summary,
   ICN is expected to evolve the Internet architecture at different
   layers.

   This document describes research challenges for ICN that need to be
   addressed in order to achieve these goals.  The objective of this
   document is to document these challenges and corresponding current
   approaches and to expose requirements that should be addressed by
   future research work.


2.  Problems with Information Distribution Today

   The best current practice to manage this growth in terms of data
   volume and devices is to employ application-layer overlays such as
   CDNs, P2P applications, and M2M application platforms that cache
   content, provide location-independent access to data, and optimize
   its delivery.  In principle, such platforms provide a service model
   of accessing named data objects (NDOs) (replicated web resources, M2M
   data in data centers) instead of a host-to-host packet delivery
   service model.  However, since this functionality resides in overlays
   only, the full potential of content distribution and M2M application
   platforms cannot be leveraged as the network is not aware of data
   requests and data transmissions, leading to:

   o  data having to travel sub-optimal routes depending on the overlay,
      and not the Internet layer, topology;

   o  multicast and broadcast features of wireless networks cannot be
      leveraged, i.e., request and delivery for the same object have to
      be made multiple times;

   o  overlays typically require a significant amount of infrastructure
      support, e.g., authentication portals, content storage, and
      applications servers, making it often impossible to establish
      local, direct communication;

   o  the network not being aware of the nature of data objects and thus
      being unable to manage access and transmission (without layer
      violations);

   o  provenance validation uses host authentication today, so that even
      if there are locally cached copies available, it is normally not



Kutscher, et al.         Expires August 14, 2013                [Page 4]


Internet-Draft               ICN Challenges                February 2013


      easily possible to validate their authenticity; and

   o  many applications providing their own approach to caching,
      replication, transport, authenticity validation (if at all),
      although they all share similar models of accessing named data
      objects in the network.


3.  ICN Concepts

   Fundamentally, ICN is providing access to named data as a first-order
   network service, i.e., the network is able to serve requests to named
   data natively.  That means, network nodes can receive requests for
   named data and act on it, for example by forwarding the request to a
   suitable next-hop.  Consequently, the network processes requests for
   named data objects (and corresponding responses) natively, i.e., it
   can see requests and responses.  Every network nodes on a path is
   enabled to perform forwarding decisions, to cache objects etc.  This
   enables the network to forward such requests on optimal paths,
   employing optimal transmission technologies at every node, e.g.,
   broadcast/multicast transmission in wireless networks to avoid
   duplicate transmission of both requests and responses.

   In ICN, like in the Internet Protocol, there is a set of common
   concepts and node requirements beyond this basic service model.
   Naming data objects is a key concept.  In general, ICN names do not
   represent neither network nodes nor interfaces -- they represent NDOs
   independent of their location.  Names are the keys for forwarding
   decisions -- and they are used for matching requests to responses: In
   order to provide better support for accessing copies of NDOs
   regardless of their location, it is important to be able to validate
   that a response actually delivers the bits that correspond to an
   original request for named data.  Name-content binding validation is
   a fundamental security service in ICN, and this is often achieved by
   establishing a verifiable binding between the object name and the
   actual object or an identity that has created the object.  ICN can
   support other security services, such as provenance validation,
   encryption -- depending on the details of naming schemes, object
   models and assumptions on infrastructure support.  Security services
   such as name-content binding validation are available to any node,
   i.e., not just the actual receivers.  This is an important feature,
   for enabling ingress gateways to check object authenticity to prevent
   denial-of-service attacks.

   Based on these fundamental properties it is possible to leverage
   network storage ubiquitously: every node and every device can cache
   data objects and respond to requests for such objects -- it is not
   required to validate the authenticity of the node itself since name-



Kutscher, et al.         Expires August 14, 2013                [Page 5]


Internet-Draft               ICN Challenges                February 2013


   content bindings can be validated.  Ubiquitous in-network storage can
   be used for different purposes: it can enable sharing, i.e., the same
   object copy can be delivered to multiple users/nodes as in today's
   proxy caches and CDNs.  It can also be used to make communication
   more robust (and perform better) by enabling the network to answer
   requests from local caches (instead of from origin servers).  In case
   of disruption (message not delivered), a node can re-send the
   request, and it could be answered by an on-path cache, i.e., on the
   other side of the disrupted link.  The network itself would thus
   support retransmissions -- enabling shorter round-trip times and
   offloading origin servers and other parts of the network.

   The request/response model and ubiquitous in-network storage also
   enables new options for implementing transport services, i.e.,
   reliable transmission, flow control etc.  First of all, a request/
   response model can enable receiver-driven transport regimes, i.e.,
   receivers (the requestors of NDOs) can control message sending rates
   by regulating the request sending rate (assuming that every response
   message has to be triggered by a request message).  Retransmission
   would be achieved by re-sending requests, e.g., after a timeout.
   Because objects can be replicated, object transmission and transport
   sessions would not necessarily have end-to-end semantics: requests
   can be answered by caches, and a node can select one or multiple
   next-hop destination for a particular request -- depending on
   configuration, observed performance or other criteria.

   This receiver-driven communication model potentially enables new
   interconnection and business models: a request for named data can be
   linked to an interest of a requestor (or requesting network) in data
   from another peer, which could suggest modeling peering agreements
   and charging accordingly.


4.  ICN Research Challenges

4.1.  Naming and Security

   Naming data objects is as important for ICN as naming hosts is for
   today's Internet.  Fundamentally, ICN requires unique names for
   individual NDOs, since names are used for identifying objects
   independently of its location or container.  It is important to
   establish a verifiable binding between the object and its name (name-
   data integrity ), so that a receiver can be sure that received bits
   actually represent the NDO (object authenticity).  Information about
   an object's provenance, i.e., who generated or published it, is also
   useful to associate to the name.

   The above functions are fundamentally required for the information-



Kutscher, et al.         Expires August 14, 2013                [Page 6]


Internet-Draft               ICN Challenges                February 2013


   centric network to work reliably -- otherwise neither network
   elements nor receivers can trust objects' authenticity, which would
   enable several attacks including critical DoS attacks by injecting
   spoofed content into the network.  There are different ways to use
   names and cryptography to achieve the desired functions [ICNNAMING]
   [ICNSURVEY], and there are different ways to manage namespaces
   correspondingly.

   Two naming schemes have largely been proposed: one with a
   hierarchical and one with a flat namespace.  The hierarchical scheme
   has a structure similar to current URLs, where the hierarchy is
   rooted in a publisher prefix.  The hierarchy enables aggregation of
   routing information, improving scalability of the routing system.  In
   some cases, the names are human-readable, which makes it possible for
   users to manually type in names, reuse, and, to some extent, mapping
   name to a user's intent.

   The other naming scheme is self-certifying, meaning that the object's
   name-data integrity can be verified without needing a public key
   infrastructure (PKI) or other third party to first establish trust in
   the key.  Self-certification is achieved by binding the hash of the
   content closely to the object's name.  This can be done by directly
   embedding the hash of the content in the name.  Another option is an
   indirect binding, which embeds the public key of the publisher in the
   name and signs the hash of the content with the corresponding secret
   key.  The resulting names are typically non-hierarchical, or flat,
   although the publisher field provides structure that can be used for
   routing aggregation.

   There are design trade-offs for ICN naming affecting routing and
   security.  Self-certifying names are not human readable nor
   hierarchical.  They can however provide some structure for
   aggregation, for instance, a name part corresponding to a publisher.
   Without self-certification, as mentioned above, the infrastructure
   depends on a PKI for its operation, which can be impede a large-scale
   deployment.

   Specific research challenges include:

   o  naming static data objects can be performed by using content
      hashes as part of object names, so that publishers calculate the
      hash over existing data objects and receivers (or any ICN node)
      can validate the name-content binding by re-calculating the hash
      and comparing it to the name (component).  [I-D.farrell-decade-ni]
      specifies a concrete naming format for this.

   o  naming dynamic objects is referring to use cases where the name
      has to be generated before the object is created (for example,



Kutscher, et al.         Expires August 14, 2013                [Page 7]


Internet-Draft               ICN Challenges                February 2013


      this could be the case for live streaming, when a publisher wants
      to make the stream available by registering stream chunk names in
      the network).  One approach to this can be self-certified names as
      described above.

   o  requestor privacy protection can be a challenge in ICN as a direct
      consequence of the accessing-named-data-objects paradigm: if the
      network can "see" requests and responses, it can also log request
      history for network segments or individual users, which can be
      undesirable, especially since name are typically expected to be
      long-lived.  I.e., even if the name itself does not reveal much
      information, the assumption is that the name can be used to
      retrieve the corresponding data objects in the future.

   o  Updating and versioning NDO can be challenging because it can
      contradict fundamental ICN assumptions: if an NDO can be
      replicated and stored in in-network storage for later retrieval,
      names have to be long-lived -- and the name-content binding must
      not change: updating an object (changing the content without
      generating a new name) is impossible.  Versioning can be seen as
      one possible solution, possibly requiring a naming scheme that
      supports versioning (and a way for requestors to learn about
      versions).

   o  Managing accessibility: whereas in ICN the general assumption is
      to enable ubiquitous access to NDOs, there can be relevant use
      cases where access to objects should be restricted, for example to
      a specific user group.  There are different approaches for this,
      such as object encryption (requiring key distribution and related
      mechanisms) or the concept of scopes, e.g., based on names that
      can only be used/resolved under some constraints.

4.2.  Routing and Resolution System Scalability

   ICN routing locates a data object based on its name which is
   initially provided by a requester.  ICN routing is composed of three
   steps: a name resolution step, a discovery step, and a delivery step.
   The name resolution step translates the name of requesting data
   object into its locator.  The discovery step routes user request to
   data object based on its name or locator.  The last delivery step
   routes the data object back to the requester.  Depending on how these
   steps are combined, ICN routing schemes can be categorized as: Route-
   By-Name Routing (RBNR), Lookup-By-Name Routing (LBNR), and Hybrid
   Routing (HR).







Kutscher, et al.         Expires August 14, 2013                [Page 8]


Internet-Draft               ICN Challenges                February 2013


4.2.1.  Route-By-Name Routing (RBNR)

   RBNR omits the first name resolution step.  The name of data object
   is directly used to route user request to the data object.
   Therefore, routing information to each data object basically has to
   be maintained in the routing table.  Since the number of data objects
   is huge (The number of originally published content files that ICN is
   expected to support was estimated as 10^11 back in 2007 [DONA].
   However, there are still many people in ICN research community who
   believe that the number should be larger than 10^11 , e.g. 10^15 --
   10^22.), the size of routing table tends to be proportional to the
   number of data object unless any aggregation mechanism is introduced
   to the name of data object.  On the other hand, RBNR reduces overall
   latency and simplifies the routing process due to the omission of the
   resolution process.  For the delivery step, RBNR needs another
   identifier (ID) of either host or location to forward the requested
   data object back to the requester.  Otherwise, an additional routing
   mechanism has to be introduced such as bread-crumb routing
   [BREADCRUMBS]: a request leaves behind a trail of breadcrumbs along
   its forwarding path, and then the response is forwarded back to the
   requester consuming the trail.  Specific challenges include:

   o  How to aggregate the names of data objects to reduce the number of
      routing entries?

   o  How does user learn the name which is designed for aggregation by
      provider?  (For example, although we name our contribution as "ICN
      research challenge", IRTF (provider) may want to change the name
      to "/IETF/IRTF/ ICN/Research challenge" for aggregation.  In this
      case, how does a user learn the name "/IETF/IRTF/ICN/Research
      challenge" to retrieve the contribution initially named "ICN
      research challenge" without any resolution process?)

   o  Without introducing the name aggregation scheme, can we still
      achieve a scalable routing by taking advantage of topological
      structure and distributed copies? e.g. compact routing [COMPACT],
      random walk [RANDOM] or Greedy routing [GREEDY], etc.

   o  How to incorporate copies of a data object in in-network caches in
      this routing scheme?

4.2.2.  Lookup-By-Name Routing (LBNR)

   LBNR uses the first name resolution step to translate the name of
   requesting data object into its locator.  Then, the second discovery
   step is carried out based on the locator.  Since IP address could be
   used as locators, the discovery step can depend on the current IP
   infrastructure.  The delivery step can be implemented same as IP



Kutscher, et al.         Expires August 14, 2013                [Page 9]


Internet-Draft               ICN Challenges                February 2013


   routing.  The locator of requester is included in the request
   message, and then the requested data object is delivered to the
   requester based on the locator.  Specific challenges include:

   o  How to build a scalable resolution system which provides

      *  Fast lookup: mapping the name of data object to its locators
         (copies as well).

      *  Fast update: the location of data object is expected to change
         frequently.  Also, multiple data objects may change their
         locations at the same time, e.g. data objects in laptop.

   o  How to incorporate copies of a data object in in-network caches in
      this routing scheme?

4.2.3.  Hybrid Routing (HR)

   HR combines both RBNR and LBNR to benefit from their advantages.  For
   instance, within a single administrative domain, e.g.  ISP where
   scalability issue is not serious problem, RBNR can be adopted to
   reduce overall latency by omitting the resolution process.  On the
   other hand, LBNR can be used to route among the domains which have
   their own prefix (locator).  A specific challenge here is:

   o  How to design a scalable mapping system, which given the name of
      data object, it should return a destination domain locator so that
      a user request can be encapsulated and forwarded to the domain?

4.3.  Mobility Management

   IP was not designed to consider node mobility originally, forcing new
   connections towards the content sources to be made.  With the
   proliferation of mobile terminals equipped with different kinds of
   access technologies, mobility became a highly sought solution to be
   available at the network layer, berthing Mobile IP [RFC5944] based
   protocols.  However, this addition also placed a higher degree of
   complexity on the network operations due to the need for new network
   entities, new signaling messages and resulting side-mechanisms, such
   as tunneling.  In that sense, novel content-centric network
   architectures that go beyond host-based mobility control, provide the
   ample grounds for the definition of operating mechanisms considering
   mobility as a prime requirement, right at the start.

   ICN naming for reaching content intrinsically supports mobility.  For
   example, CCN [CCN] does not share the IP restriction of forwarding on
   spanning trees, so it is able to take advantage of multiple
   interfaces or adapt to the changes produced by rapid mobility (i.e.,



Kutscher, et al.         Expires August 14, 2013               [Page 10]


Internet-Draft               ICN Challenges                February 2013


   there is no need to bind a layer 3 address into a layer 2 address).
   In fact, client mobility is simplified by allowing requests for new
   content to normally flow from different interfaces, or through newly
   connected points of attachment to the network.  However, that
   simplicity may not be reflected when the node moving is the content
   source, requiring more complex support from the networking mechanisms
   in respect to different aspects, such as forwarding update and
   caching rebuilding.  Furthermore, requirements become more stringent
   when support for seamless mobility is required, especially in cases
   such as real-time voice/video communications.  These requirements are
   further exacerbated when mobile nodes are able to connect through
   wireless access interfaces of different technologies, where the
   performance and link conditions can vary widely depending of numerous
   factors.

   Here mobility management has an important role in terms of not only
   optimizing the handover process, but also to ideally ensure seamless
   transition from one point of attachment to the other.  In this way,
   "seamless transition" ensures that the content reception by the user
   occurs in an unperceptive way to the user and/or application
   receiving that content.  Moreover, this transition needs to be
   executed in parallel with ICN content identification and reaching
   mechanisms enabling scenarios, such as, preparation of the content
   reaching process at the target connectivity point, prior to the
   handover (to reduce link switch disturbances).  Finally, these
   mobility aspects can also be tightly coupled with network management
   aspects, in respect to policy enforcement, link control and other
   parameters necessary for establishing the node's link to the network.
   The resulting mobility management process can thus enhance and evolve
   ICN aspects by making them aware (or able to contribute) to not only
   allow but also enhance possible mobility procedures.

   From this, a set of research challenges on ICN Mobility Management
   can be derived:

   o  How can content reaching mechanisms interface with specific link
      operations, such as identifying which links are available for a
      certain content

   o  How to make mobility as a service that is only activated when the
      specific user/content/conditions require it (i.e., a possible
      solution to maintain the mobility-agnostic aspect of generic ICN)

   o  How to coordinate mobility management between the node and the
      network for optimization and policing procedures?






Kutscher, et al.         Expires August 14, 2013               [Page 11]


Internet-Draft               ICN Challenges                February 2013


4.4.  Wireless Networking

   Today, all wireless network/radio access technologies (L2) are
   developed with a clear assumption in mind: the waist of the protocol
   stack is (and will be) IP.  This translates into answering a large
   set of questions, from how to handle broadcast to how to support
   multicast in a rather straightforward manner.  Arguably, if one
   designs a future wireless access technology with an information-
   centric "layer 3", most of these answers would no longer be valid.
   Although this is clearly outside the scope of this document, a few
   research challenges that the wider community may be interested in
   include:

   o  In the context of wireless access, how can we leverage the
      broadcast nature of the medium in an information-centric network?

   o  Is it possible that by changing the network paradigm to ICN we can
      in practice increase the spectral efficiency (bits/s/Hz) of a
      wireless network beyond what would be possible with today's host-
      centric approaches?

   o  How can a conversational service be supported at least as
      efficiently as today's SoA wireless network deliver?

4.5.  Transport Services

   ICN's receiver-driven communication model as described above creates
   new option for transport protocol design -- it does not rely on end-
   to-end communication path from a sender to a receiver, because a
   requested object can be accessible in multiple different network
   locations.  A node can thus decide how to utilize multiple sources,
   e.g., by sending parallel requests for the same object or by
   switching sources (or next hops) in a suitable schedule for a series
   of requests.

   In this model the requestor would control data rate by regulating its
   request sending rate and next by performing source/next-hop
   selections.  Specific challenges are depending on the specific ICN
   approach in use, but general challenges for receiver-driven transport
   protocols (or mechanisms, since dedicated protocols might not be
   required) include flow and congestion control, fairness, network
   utilization, stability (of data rates under stable conditions) etc.
   [HRICP] describes a sample request rate control protocol and
   corresponding design challenges.

   ICN offers routers the possibility to aggregate requests and can use
   several paths, meaning that there is no such thing as end-to-end
   communication path, e.g., a router that receives two requests for the



Kutscher, et al.         Expires August 14, 2013               [Page 12]


Internet-Draft               ICN Challenges                February 2013


   same content at the same time only sends one requests to its
   neighbor.  The aggregation of requests has a general impact on
   transport service design.

   Achieving fairness for requestors can be one challenge as it is not
   possible to identify the number of clients 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
   requester, the router cannot distinguish the initial request form 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.  Finally, aggregation of requests has an impact
   on the server (producer) side.  This last has no way to determine the
   number of clients actually consuming the content it is producing.
   This shift of model influence the business model of the server, e.g.,
   how to implement pay-per-click?

4.6.  In-Network Caching

   Explicitly named content objects allow for caching in virtually any
   network element, including routers, proxy caches and end-host
   machines.  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.  Here we list some of the most important challenges that
   relate to the properties of the new ubiquitous caching system.

4.6.1.  Cache Placement

   The declining cost of fast memory gives the opportunity to deploy
   caches in network routers and take advantage of explicitly named
   cached contents.  There exist 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 below.  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 an information-/content-centric network.
   However, on-path caching requires line-speed operation, a fact that



Kutscher, et al.         Expires August 14, 2013               [Page 13]


Internet-Draft               ICN Challenges                February 2013


   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/accidental 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
   next.

4.6.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
   contents 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 content 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 co-ordination 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, there already exist some studies that attempt to reduce
   redundancy of cached copies.  However, the issue of coordinated
   content placement in on-path caches still 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 put in places where it is going to be requested next.
   Furthermore, issues of "expected content popularity" might need to be
   considered 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



Kutscher, et al.         Expires August 14, 2013               [Page 14]


Internet-Draft               ICN Challenges                February 2013


   operators.  Such issues need to be investigated and relate also to
   the evaluation methodology discussed later on.

4.6.3.  Request-to-Cache Routing

   In order to get advantage of cached contents, requests have to be
   forwarded to the nodes that temporarily host (cache) the
   corresponding contents.  This challenge relates to name-based
   routing, discussed before.  Requests should ideally follow the path
   to the cached content.  However, instructions as to which content is
   cached where cannot be broadcast throughout the network.  Therefore,
   the knowledge of a content's 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).

   Co-ordination 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 content they are looking for is found on
   the path, then content is fetched from this node (instead of the
   original 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
   AS.  In the latter case, business relationships between ASes might
   need to be exploited in order to build a scalable model.

4.7.  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
   OPEX if not done well.  If we want ICN to be deployed in
   infrastructure networks, development of management tools and
   mechanisms must go hand-in with the rest of the architecture design.

   Although defining FCAPS for ICN is clearly outside the scope of this



Kutscher, et al.         Expires August 14, 2013               [Page 15]


Internet-Draft               ICN Challenges                February 2013


   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 (NOC) to define
   policies, validate that they are indeed used in practice, be notified
   early on about failures, determine and resolve configuration
   problems.  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
   is 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 two 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.
   DTN characteristics should also be considered to the degree that this
   is possible (e.g. content dissemination through data mules).  On the
   other hand, 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.

   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
   are central to ICN intrinsic operations, which are used to identify
   and reach content under different aspects (e.g., CCN uses a
   hierarchical namespace able to contain human-readable naming scheme,
   NetInf uses a flat naming structure, etc.).  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", and if there is a host-centric protocol running
   from which the management process can also leverage upon.

   But, on the other hand, these same inherent ICN characteristics also



Kutscher, et al.         Expires August 14, 2013               [Page 16]


Internet-Draft               ICN Challenges                February 2013


   allow us to look into network management through a new perspective.
   By centering its operations around content, one can conceive new
   management operations addressing, for example, per-content management
   or access control, as well as analyzing performance per content name
   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 by in [ccn-access], where access control mechanisms are
   integrated into a prototype of the [PURSUIT] architecture.

   In this way, a set of core research challenges on ICN management can
   be derived as:

   o  Manage and control content reception at the destination

   o  Coordination of management information exchange and control
      between ICN nodes and ICN network control points 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)


5.  Link to and Impact on IETF Technologies

   TBW later.


6.  Security Considerations

   See naming and security challenges.


7.  Informative References

   [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]      Jacobsen, K, D, F, H, and L, "Networking Named Content",
              CoNEXT 2009 , December 2009.



Kutscher, et al.         Expires August 14, 2013               [Page 17]


Internet-Draft               ICN Challenges                February 2013


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

   [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.

   [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.

   [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.farrell-decade-ni]
              Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B.,
              Keraenen, A., and P. Hallam-Baker, "Naming Things with
              Hashes", draft-farrell-decade-ni-10 (work in progress),
              August 2012.

   [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.

   [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.

   [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",



Kutscher, et al.         Expires August 14, 2013               [Page 18]


Internet-Draft               ICN Challenges                February 2013


              In Perform. Eval., vol. 63, pp. 241--263, 2006.

   [RFC5944]  Perkins, C., "IP Mobility Support for IPv4, Revised",
              RFC 5944, November 2010.

   [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.


Authors' Addresses

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

   Phone:
   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
   Huawei Technologies
   Carnotstrasse 4
   Berlin  10587
   Germany

   Email: k.pentikousis@huawei.com









Kutscher, et al.         Expires August 14, 2013               [Page 19]


Internet-Draft               ICN Challenges                February 2013


   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


   Damien Saucez
   INRIA

   Email: damien.saucez@inria.fr





























Kutscher, et al.         Expires August 14, 2013               [Page 20]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/