draft-corujo-icn-mgmt-05.txt

ICNRG                                                          D. Corujo
Internet-Draft                             Instituto de Telecomunicacoes
Intended status: Informational                            K. Pentikousis
Expires: January 2, 2015                                            EICT
                                                                I. Vidal
                                                       J. Garcia-Reinoso
                                                                    UC3M
                                                              S. Lederer
                                      Alpen-Adria Universitat Klagenfurt
                                                               S. Spirou
                                                        Intracom Telecom
                                                             C. Westphal
                                                                  Huawei
                                                            July 1, 2014


                     ICN Management Considerations
                        draft-corujo-icn-mgmt-05

Abstract

   ICN has been proposing and evaluating novel ways for reaching on-line
   content in upcoming Future Internet environments, leveraging
   intrinsic capabilities such as naming, caching and built-in security.
   In order to fully realize the capabilities and vision provided by
   ICN, supportive management procedures need to be ensured, providing
   the architectures, and the elements that figure in them, with the
   means to facilitate the delivery of content and the operation of the
   network.  In the current Internet, these management aspects have been
   being developed and enhanced in parallel to the existing data
   protocol and mechanisms, resulting in a plethora of different and
   hard-to-integrate approaches, but still fulfil indispensable roles
   and actions for the operation and well-being of the network.  We
   consider that the availability of management mechanisms for ICN will
   foster deployment and, as such, should be tackled still in the design
   and experimentation phases.  In this way, this document addresses and
   identifies ICN management considerations, under two different
   settings: a) achieving management operations using ICN-based
   mechanisms and, b) how to manage ICN procedures themselves.  The
   ultimate goal is to provide the necessary breadth to establish
   management mechanisms deployment guidelines in a common way
   throughout the existing ICN ecosystem of architectures.

Status of This Memo

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




Corujo, et al.           Expires January 2, 2015                [Page 1]

Internet-Draft        ICN Management Considerations            July 2014


   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 January 2, 2015.

Copyright Notice

   Copyright (c) 2014 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.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  ICN Management Approaches . . . . . . . . . . . . . . . . . .   4
     2.1.  ICN-assisted Management . . . . . . . . . . . . . . . . .   4
       2.1.1.  Video Adaptation  . . . . . . . . . . . . . . . . . .   4
         2.1.1.1.  Adaptive Delivery of Multimedia Content in ICN  .   4
       2.1.2.  Content Management  . . . . . . . . . . . . . . . . .   5
       2.1.3.  Network Policies  . . . . . . . . . . . . . . . . . .   7
         2.1.3.1.  NetInf Management Considerations  . . . . . . . .   7
       2.1.4.  Resource Management . . . . . . . . . . . . . . . . .   8
     2.2.  Management for ICN Aspects  . . . . . . . . . . . . . . .  10
       2.2.1.  Caching . . . . . . . . . . . . . . . . . . . . . . .  10
       2.2.2.  Information Freshness . . . . . . . . . . . . . . . .  11
     2.3.  Hybrid Approaches . . . . . . . . . . . . . . . . . . . .  11
       2.3.1.  Face Management . . . . . . . . . . . . . . . . . . .  11
   3.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  14
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  14
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  14
   6.  Informative References  . . . . . . . . . . . . . . . . . . .  14
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  17



Corujo, et al.           Expires January 2, 2015                [Page 2]

Internet-Draft        ICN Management Considerations            July 2014


1.  Introduction

   Information-centric networking (ICN) enables new ideas for naming and
   addressing, privacy, security, and trust, and should also lead us to
   think new ways for deploying, operating and managing networks in the
   future.  By default, users, programs, information objects and hosts
   are in general untrustworthy and mobile in an information-centric
   network.  This means that many of the assumptions in traditional
   network management, including all aspects of FCAPS (Fault,
   Configuration, Accounting, Performance, and Security) need to be
   rethought.  However, despite the different instantiations of ICN
   architectures, and the plethora of novel research work built on top
   of them, little attention has been paid to management aspects so far.
   This includes both enabling "traditional" network management
   operations (which work well from small networks to large
   infrastructure networks), and supporting and optimizing intrinsic
   procedures of the ICN fabric.

   This document aims to draw the attention of ICNRG to the importance
   of network management for real-world deployments.  Today, network
   management is practically an add-on to host-centric deployments.  We
   can do better as we move forward in ICN research considering the full
   range of deployments from home-office environments to challenged
   networks to tier-1 networks.  To this end, we draft some first
   management considerations that, on the one hand, capitalize on ICN
   concepts for defining management procedures and, on the other,
   explore the possibilities for defining a common management framework
   irrespective of the ICN approach taken.  We reckon that the later is
   a much more formidable task and we are looking forward to tackling it
   together with other members of ICNRG.

   We argue that addressing management at an early stage is not only
   important for real-world adoption and the successful future
   deployment of ICN, but also to deal with scenarios where management
   can simplify, enhance or optimize ICN network utilization and
   performance.  The subject becomes particularly challenging, as
   disparate characteristics from different ICN approaches (e.g., in
   terms of namespace, granularity, routing, and so on) impact the
   definition and design of these management mechanisms.  This document
   analyses ICN Management under three different perspectives.  Firstly,
   in Section 2 it will provide considerations regarding the usage of
   ICN mechanisms for realizing management procedures.  Secondly, in
   Section 2.2 will look into how the intrinsic procedures used for
   operating the ICN architecture can be managed.  Finally, in
   Section 2.3 we will look in a combined way to the former two issues
   and identify the role of ICN when it's own procedures will be used to
   manage ICN operations.




Corujo, et al.           Expires January 2, 2015                [Page 3]

Internet-Draft        ICN Management Considerations            July 2014


   We plan to incrementally develop the draft, incorporating
   considerations on other ICN aspects as well as different approaches
   (e.g., [PURSUIT] and [NetInf]) as well as address other pertinent
   aspects as we receive feedback from the research group members.

2.  ICN Management Approaches

   In this part of the document, ICN management approaches will be
   addressed in respect to how ICN mechanisms can be used to realize
   management procedures, how to manage the specific ICN mechanisms
   themselves and hybrid approaches where the ICN mechanisms themselves
   are used to realize the management of ICN aspects.

2.1.  ICN-assisted Management

   This section addresses how the ICN operational mechanisms can be used
   to realize different kinds of network managament procedures.

2.1.1.  Video Adaptation

   This section investigates ICN management considerations for the
   delivery of video data, and especially the adaptive delivery of
   video.  From a content perspective, multimedia is omnipresent in the
   Internet, e.g., producing 62% of the total Internet traffic in North
   America's fixed access networks [GIPR2013].

   Video, and multimedia content in general, is has specific
   characteristics, which have to be considered and where network
   management consideration are necessary.  The consumption of
   multimedia content comes along with timing requirements for the
   delivery of the content, for both, live and on-demand consumption.
   Long startup delays, buffering periods or poor quality, etc. should
   be avoided to achieve a good Quality of Experience of the consumer of
   the content.  Of course, these requirements are heavily influenced by
   routing decision and caching, which are central parts of ICN, and
   which may be leveraged more efficiently by an intelligent network
   management.

2.1.1.1.  Adaptive Delivery of Multimedia Content in ICN

   Today's dominant streaming systems are based on the common approach
   of leveraging HTTP-based Internet infrastructures, which are
   consequently based on the Transmission Control Protocol (TCP) and the
   Internet Protocol (IP).  Especially the adaptive multimedia streaming
   (AMS) via HTTP is gaining more and more momentum and resulted in the
   standardization of MPEG-DASH [MPEG-DASH], which stands for Dynamic
   Adaptive Streaming over HTTP.  The basic idea of AHS is to split up
   the media file into segments of equal length, which can be encoded at



Corujo, et al.           Expires January 2, 2015                [Page 4]

Internet-Draft        ICN Management Considerations            July 2014


   different resolutions, bitrates, etc.  The segments are stored on
   conventional HTTP Web server and can be accessed through HTTP GET
   requests from the client.  Due to this, the streaming system is pull
   based and the entire streaming logic is on the client side.  This
   means that the client fully controls the bitrate of the streaming
   media on a per-segment basis, which has several advantages, e.g., the
   client knows its bandwidth requirements and capabilities best.  As
   one can see, ICN and adaptive multimedia streaming have several
   elements in common, such as the client-initiated pull approach, the
   content being dealt with in pieces as well as the support of
   efficient replication and distribution of content pieces within the
   network.  As ICN is a promising candidate for the Future Internet
   (FI) architecture, it is useful to investigate its suitability in
   combination with AMS systems and standards like MPEG-DASH as shown in
   [AdaptCCN][InterAdaptCCN], as well as the possibilities and benefits
   of intelligent network management to improve the performance of AMS
   in ICN as well as the resulting QoE at the client.

   One of the most promising aspects in this context is the possibility
   of ICN to consume content from different origin nodes as well as over
   different network links in parallel, which can be seen as an
   intrinsic error resilience feature w.r.t. the network.  This is a
   useful feature of ICN for adaptive multimedia streaming within mobile
   environments since most mobile devices are equipped with multiple
   network links.  Here, a focus of ICN management could be in the load
   balancing of such traffic between the available links.  This would
   increase the effective media throughput of the multimedia content,
   however, it could potentially lead to high variations of the
   resulting bandwidth which is available to the client.  As DASH is
   designed for environments with dynamic bandwidth conditions, they can
   be compensated in general.  However, more conservative adaptation
   algorithms may prevent too frequent switching between the content's
   bitrate representations as well as compensate short-term bandwidth
   drops caused by network link switches more smoothly.

2.1.2.  Content Management

   An ICN network aims to facilitate access to, and delivery of,
   information objects (content and services).  Content (in particular,
   video) access and delivery seems to be the dominant use case in
   traditional, host-based networks, so ICN networking is forced to
   adopt content delivery as a minimum requirement.  Indeed, virtually
   all ICN approaches so far target at least content delivery.

   From the perspective of a content owner or provider, an ICN network
   functions essentially as a content delivery network.  This creates a
   set of requirements for ICN.  First of all, end-users and content
   providers alike should be able to Read (consume) a content object



Corujo, et al.           Expires January 2, 2015                [Page 5]

Internet-Draft        ICN Management Considerations            July 2014


   available on the ICN network.  In addition, content providers need
   the ability to Create (publish), Update, and Delete content.
   Finally, Accounting (logging) is necessary to support business models
   that typically require charging, analytics, and monitoring.

   The Read operation has received the lion's share in ICN research.
   This is expected as content access and delivery is at the heart of
   ICN.  Given a request for a named content object, the ICN network
   resolves that name to an object replica and proceeds with delivery to
   the end-user.  Of course, different ICN approaches employ different
   mechanisms to achieve the Read operation.  For example, name
   resolution can be done with a hierarchical system resembling DNS,
   with DHTs, or with flooding.  Similarly, content delivery can be done
   over normal best-effort paths from the origin server, over
   dynamically computed provisioned paths, or from caches close to the
   end-user.  Some approaches can even cater to mobile end-users and
   content hosts.  ICN should be able to handle frequent Reads as well
   as Read spikes (flash crowds).  In fact, it seems crucial for ICN's
   deployment chances to at least match the capabilities of incumbent
   content delivery systems.

   ICN research has not addressed Create as much as Read, but some
   effort has been expanded on mechanisms for publishing content.  Much
   of this effort has focused on content naming schemes that enable
   global uniqueness of names and hence allow global addressing of the
   content objects.  It has been difficult to balance human readability
   of names, efficiency in machine processing, and name aggregation
   (that can realistically enable request routing by name).  Although a
   fully automated mechanism for (human-readable) name assignment would
   be desirable, so far it seems that a manual process, similar to that
   of domain name registration in DNS, is necessary to allocate at least
   namespaces.  No other restrictions on naming have been seriously
   considered.  The consensus seems to be that with ICN anyone should be
   able to publish anything.  Content semantics are a higher layer
   issue.  This might be a prudent approach when building a transport
   layer technology, but it could undermine the potential of ICN
   deployment.  A content owner would not want copies of its content
   published on an ICN network under different names.  In any case, once
   a name has been assigned, the Create operation is mainly about
   creating an entry in the name resolution system.  This is obviously a
   security risk and furthermore, for highly distributed name resolution
   systems, it can suffer from considerable lag in availability.
   Fortunately, Create is a rare operation compared to Read.

   Update is an operation that seeks to alter an already created object.
   A content provider would want to modify the data or the metadata of a
   published object either to rectify publication errors or to augment
   the object.  It is debatable whether the provider should address the



Corujo, et al.           Expires January 2, 2015                [Page 6]

Internet-Draft        ICN Management Considerations            July 2014


   later simply by creating a new object.  Another use case for Update
   comes from the need to rebrand or alias an object when its rights
   have been sold to another party.  Nevertheless, the Update operation
   has received minimal attention in ICN research.  The main problem is
   one of consistency: once an update has been committed, an ICN network
   with highly distributed name resolution and content delivery
   (caching) would host both the old and new versions of the updated
   content object for some time.  Security concerns for the Update and
   Create operations are similar.  Update is normally rarer than Create,
   but this will not be the case for collaborative media.

   Content providers may occasionally need to remove a published object.
   This is the goal of the Delete operation.  An object might be deleted
   when it was published by mistake, because it's no longer useful or
   relevant, or because it's illegal.  Consistency is a major challenge
   for the Delete operation as well.  The high degree of distribution in
   ICN can sustain a network state where some data or metadata replicas
   of an object have been deleted, while others persist.  On the other
   hand, this lag can be beneficial if deletion was initiated
   erroneously or maliciously.  Like with the Update operation, Delete
   has not been properly investigated in ICN research.  Deletes are
   typically less often than updates.

   From the point of view of content providers and end users, an ICN
   network resembles a content directory and repository, with Create,
   Read, Update, and Delete as typical operations.  As with any database
   system, the reliability of those operations (or transactions) depends
   on the properties of atomicity, consistency, isolation, and
   durability.  The challenge for ICN research is to build systems at a
   massive scale that employ those properties.

2.1.3.  Network Policies

   Currently this section addresses Network Policies under the scope of
   NetInf.  In future instantiations of this document, a more generic
   approach will be provided, besides highlighting specific ICN
   instantiations contributions.

2.1.3.1.  NetInf Management Considerations

   Early-phase work in NetInf management [NetInfSelfX] discussed a two-
   fold problem.  The first question that arises is whether it is
   possible by adopting a new set of network primitives and in-network
   storage to usher a new type of network management.  In other words,
   can network management become information-centric while handling
   often host-centric data?  The second question is whether an
   information-centric network is more suitable for self-management
   mechanisms than IP-based networks are.  In particular with respect to



Corujo, et al.           Expires January 2, 2015                [Page 7]

Internet-Draft        ICN Management Considerations            July 2014


   the later, [NetInfSelfX] introduced some design considerations for
   adding self-management mechanisms in NetInf.

   Of interest from this early work are two examples where network
   management can play a new role.  First, network management can get
   involved in decisions about caching and (re)distribution of content,
   and not only whether an (inter)face is on or off, or what traffic
   limits should be enforced.  Moreover, network policies can be
   distributed securely in the same way as other content in the network,
   removing the need for centralized management, and enabling improved
   recovery procedures.  Second, network management can get involved in
   more intricate processes such as controlling multiaccess support,
   intermediating for content adaptation when deemed appropriate, and
   enabling richer tools for traffic engineering.

2.1.4.  Resource Management

   While caching has been the focus of much of the attention in ICN, one
   of the key advantages of the ICN architecture is that it allows a
   fine grained allocation of content to resources.  This has been
   observed in [CB-TE] and [ICN-TE] for instance.  Unlike IP, an ICN
   packet carries specific, explicit information about the content it
   carries.  Further, this content is uniquely named, and different
   versions of the content will have different names.

   ICN enables a shift in how to manage resources: instead of allocating
   open-ended flows to network resource, it allows to allocate well
   defined objects.  This requires new network management tools beyond
   the current mechanisms which are specifically dedicated to ICN.
   NetFlow or the current TE mechanism do not take advantage of the ICN
   semantics, and of the benefits associated with these semantics.

   In IP, a flow from a certain source address to a certain destination
   address can correspond to myriad potential applications: web traffic,
   video streaming, VoIP call all may use the same port 80 and be hosted
   by same servers.  Therefore, providing appropriate resource to such a
   flow is a matter of guessing.  The simple problem of identifying when
   a flow terminates is made unnecessarily complex in ICN: a timer is
   set-up, and when no packets match the flow filter, then the flow is
   over.  Of course, multiple packets from different applications may
   match the same filter, and flows with different characteristics in
   terms of inter-arrival times could be broken down into multiple flows
   with an improper choice of time-out values.

   In ICN, there is a unique mapping of the name to the content of the
   data stream going through the network.  If a content object is
   requested, then it has well defined semantics, and the network
   management layer can identify exactly when the data stream starts and



Corujo, et al.           Expires January 2, 2015                [Page 8]

Internet-Draft        ICN Management Considerations            July 2014


   ends based upon these semantics.  Further, a content management layer
   can also learn the properties of the stream associated with a given
   identifier.  [CB-TE] presented such a mechanism to learn the
   properties associated with a name, either by counting the bytes on
   the wire corresponding to this name, or by reading the footprint of
   the content with this name when stored in a cache.  It is therefore
   possible for the management layer to gather meta-data pertaining to
   the content that goes through the network, and to use this meta-data
   to make proper resource allocations.

   Of course, the resource manager should only acquire meta-data about
   content that is likely to be seen again (i.e., popular) or specific
   in any way (for instance, the name of an elephant flow).  This
   considerably simplifies the task as the data of interest is
   concentrated on a few items.  One potential usage of this meta-data
   is to keep track of what content is going through which link.  In
   this scenario, each link keeps an aggregate tally of the amount of
   data that has been assigned to this link and subtracts the amount
   that has gone through.  The resulting backlog can be then used to
   allocate new data streams to this or another link.

   In [ICN-TE], it was shown that such a policy would significantly
   reduce the time spent in the network by content streams when
   considering a WAN topology and its corresponding end-to-end traffic
   matrix.  The network load would stay the same when comparing with a
   min-MLU policy, but by splitting elephant flows across different
   paths, the completion time would be reduced.  In the simulations of
   [ICN-TE], min-MLU is roughly 50% slower than a content-based policy.

   This is an encouraging result and a step towards a management
   framework that assigns resource to content in a deterministic and
   fine-grained manner, unlike the probabilistic allocation of IP.  The
   ICNRG should consider such a management framework, and evaluate the
   different proposals in light of this opportunity.  For instance, an
   ICN architecture such as [PURSUIT] contains a natural mechanism to
   perform such allocation of content to paths as it assigns a source
   route to the content.  On the other hand, an ICN architecture such as
   [NDN] needs to be expanded as the link allocation semantics are, in
   the current proposal, tied to the content resolution process: the
   interest homes into the content, and lays the reverse path for the
   content delivery at the same time.  This semantics make the
   management for multiple link selection more difficult, as multiple
   interests would have to be sent over multiple links to provide path
   diversity.  However, it could be an area of study for the ICNRG as
   solving such resource management problem would provide significant
   benefits to ICN architectures.





Corujo, et al.           Expires January 2, 2015                [Page 9]

Internet-Draft        ICN Management Considerations            July 2014


2.2.  Management for ICN Aspects

   This section will address management aspects for intrinsic ICN
   procedures.

2.2.1.  Caching

   Caching is a hot topic research nowadays in ICN.  The challenges of
   caching in ICN are different than those of web caching, mainly
   because the former has to deal with high line rates and with a huge
   amount of content.  Some ICN works propose to cache content in all
   ICN routers traversed by the data packet, in an LCE (Leave Copy
   Everywhere) fashion as in [NDN].  Some studies, like [L4M-ICN], have
   shown that other cache decision policies, focused to reduce the cache
   redundancy, may increase the overall caching performance.  Some of
   these decision policies only use the local information available at
   the ICN routers, but others use the information available at other
   nodes to cache or not the incoming content.  This is known as
   explicit cache coordination decision, and there are several proposals
   around this concept [ICN-CACHING].  The idea behind the explicit
   coordination is to exchange topological information, individual
   cache's state and content popularity view among a set of ICN routers,
   in order to coordinate caching decisions.

   ICN may benefit of in-network caching, which consists of introducing
   content stores in ICN routers.  The benefits are twofold: (1)
   improving the end-user experience by reducing the delay to retrieve
   content, and (2) reducing the overall aggregated bandwidth per
   request.  On the other hand, caching in ICN presents several
   challenges like (1) centralized vs distributed management of the
   caches, (2) cache scalability, reducing the impact of the size of the
   total content catalog, (3) routing based on cache contents, (4)
   considering the different requirements imposed by different types of
   traffic (web/multimedia/IoT/etc.), etc.  Most of these challenges can
   be solved, or at least minimized, by introducing management
   considerations in ICN proposals.

   This way, a given ICN router may forward a request towards another
   router storing the requested content.  In this context, the routing
   protocol is affected by the cache's state of surrounding neighbours.
   For example, in [CATT] the authors propose to distinguish between the
   source(s) and routers' caches that hold a copy of that content: the
   former paths are globally advertised, while the latter are only
   advertised within the router's neighbourhood.  In all these cases,
   the use of a management framework may bring significant advantages,
   providing standard interfaces that allow the routers to dynamically
   manage their caches.




Corujo, et al.           Expires January 2, 2015               [Page 10]

Internet-Draft        ICN Management Considerations            July 2014


2.2.2.  Information Freshness

   One of the prime contributions of ICN-based designs, is the ability
   for the networking entities in charge of exercising the routing of
   the content, to actually store it, allowing it to serve content
   requests in a more readily fashion.  However, there are scenarios
   where such facilities can raise issues, such as Internet of Things
   and Machinte-to-Machine scenarios.  Concretely, despite the caching
   capabilities of ICN contributing for, as an example, reducing the
   amount of networking stack fabric to be implemented in low-powered
   nodes and sensors, it can cause that the information consumed from
   caches is not up-to-date comparing to the information currently
   existing at the source.  As an example, consider an accelerometer
   sensor which is providing the acceleration value of a car, and
   disseminates it via a ICN network towards different uses.  When a
   consumer (e.g., a road traffic monitoring infrastructure) wishes to
   know the current speed of the car by requesting its name, it can be
   served by a stale content residing in a cache between the consumer
   and the information source.

   These kinds of situations demand facilities and mechanisms to avoid
   the provision of stale content.  For example, [ICN-FRESHNESS]
   considers the realization of an agreement mechanism, using ICN
   messaging exchanges, where both the source and the consumer agree on
   the minimal content freshness values for the information.
   Concretely, when the network entity determines that it has the
   content referring to a received name request, it will also evaluate
   the freshness value.  If it is lower than the one previously agreed,
   it will then discard the content and rather forward the content
   request back to the source.

2.3.  Hybrid Approaches

   This section will analyse how ICN procedures can be used to manage
   ICN operations.

2.3.1.  Face Management

   The Named Data Networking [NDN] ICN architecture provides a new
   communication framework built on named data.  Like other ICN
   counterparts, such as [NetInf], [PURSUIT] and [DONA], NDN
   intrinsically supports security, routing/forwarding, reliability,
   caching and even mobility, aiming at scalable and more efficient
   content-distribution than today's IP-based approaches.  Fostered by
   an open-source implementation [CCNx], NDN has been at the heart of an
   active topic with several research contributions evaluating its
   deployment feasibility and performance in a number of scenarios
   [ICN-Scenarios].



Corujo, et al.           Expires January 2, 2015               [Page 11]

Internet-Draft        ICN Management Considerations            July 2014


   NDN introduces the concept of a Strategy Layer, which can control
   Interest packet forwarding behavior.  It basically determines which
   is the best interface (or set of interfaces) to send an Interest
   packet.  The "strategy" component establishes a pre-configured
   algorithm for tackling Interest packet decisions, ranging from
   sending it sequentially on each interface until a Data packet is
   received, to evaluating which interfaces provide better performance
   (i.e., lower average RTT) in retrieving certain content (as discussed
   in [NDN]).

   It is important to keep in mind that NDN replaces the commonly used
   term "interface" with the term "face", since packets can be forwarded
   over hardware network interfaces as well as between application
   interfaces, further acknowledging the information dissemination
   capabilities of ICN.  This aspect is considered in [NDN] and [NDN-R],
   where programs can be associated to the NDN governing structures
   (like the FIB), defining configurations such as "sendToAll" and
   "sendToBest" with respect to managing the content reaching process.
   Corujo et al.  [NDN-MGMT] exploit these concepts enabling management
   mechanisms to be deployed, and steer network operations and NDN
   operation, as described in the following section.

   An important aspect supporting network management procedures is the
   interaction of network information residing at the network side with
   information about the network from the perspective of clients
   connected to it.  The former includes, for instance, information
   stored in the network operator core about user profiles, associated
   policies, or data collected by the access network equipment, such as
   current and past traffic load levels, active flows, and maintenance
   information.  Today, such information can be retrieved for management
   and operation support through dedicated signaling protocols (e.g.,
   [RFC1157], [RFC6733]), or Operation Support Services (OSS) web
   services.  The client point of view of the network includes
   information that, for example, a wireless terminal can provide,
   indicating wireless link quality, average return-trip times (RTT) or
   perceived Quality of Experience (QoE).

   Both types of information can be capitalized upon allowing, for
   example, the network to coordinate network management procedures,
   considering as input information obtained from other network elements
   as well as from user nodes.  One way to generate management
   information in network entities and at client nodes, as well as to
   consume and act upon it (i.e., using the management information
   exchange as a control channel) is to couple NDN nodes with Management
   Agent (MA) entities.

   Fig. 1 (redrawn here from [NDN-MGMT] for convenience) illustrates how
   a MA can be deployed in both network and client entities, interfacing



Corujo, et al.           Expires January 2, 2015               [Page 12]

Internet-Draft        ICN Management Considerations            July 2014


   with different operational aspects and protocol layers of an NDN
   node.  By using NDN content reaching and disseminating mechanisms,
   management information can be consumed by the MA to steer not only
   the behavior of application processes and network interfaces, but
   also to interface with NDN supporting structures (i.e.  Content Store
   (CS), Forward Information Base (FIB) and Pending Interest
   Table (PIT).  Effectively, different kinds of information can be
   conveyed to a network node responsible for managing the network
   (under different perspectives and processes), and resubmitted back
   towards client nodes, affecting the way applications interface with
   network interfaces and the NDN fabric.

    NDN Fabric
      +------------------------------------------+
      |                                   Face 0 |
      | +--------------+                   +---+ |  +------+
      | |Content Store |      ptr/type     |  <---->|WLAN  |
      | +------------^-+      +-+----+     +---+ |  +------+
      |              +---------+|    |    Face 1 |
      | +--------------+      +------+     +---+ |  +------+
      | |Pending      <--------+|    |     |  <---->|LTE   |
      | |Interest Table|      +------+     +---+ |  +------+
      | +--------------+      | |    |    Face i |
      |                       +------+     +---+ |  +------+
      | +--------------+      | |    |     |  <---->| MA   |
      | |Forward       |      +------+     +---+ |  +------+
      | |Information <---------+|    |    Face j |
      | |Base          |      +-+----+     +---+ |  +------+
      | +--------------+                   |  <---->|VoIP  |
      |                                    +---+ |  |Video |
      +------------------------------------------+  +------+

      Figure 1.  NDN Management Framework

   MA can interface with the PIT and FIB structures, acting as a
   dynamic, application- and/or network-controlled interface to the
   strategy layer.  This could also be used to direct how to forward NDN
   Interest and Data packets, in a configurable manner.  Regarding
   network interfaces, the MA can interface with them not only to
   control (i.e., initiate wireless access scanning procedures), but
   also to collect information (i.e., an informational event regarding
   detected access points).  Finally, the MA can also interface with
   application processes, drawing out information about the perceived
   QoS/QoE (e.g., lost packets or delay from a real-time video feed) and
   also to execute commands, such as selecting a better video codec when
   the network commands the video flow to be accessed from a different
   wireless access interface.




Corujo, et al.           Expires January 2, 2015               [Page 13]

Internet-Draft        ICN Management Considerations            July 2014


   Conversely, MA entities residing in network equipment can provide
   informational events as well, but related to network-side link layer
   characteristics (such as number of attached nodes or load), as well
   as accepting commands from the network (i.e., activate maintenance
   procedures).  Management processes residing in the network core can
   leverage information collected from applications, client terminals
   and network equipment, to drive optimization procedures.  Such
   optimization procedures can also tap into other entities, containing
   complementary information such as policies and subscription
   information, and use it to produce an overall network decision, which
   can then be forwarded to multiple client nodes, in a policy enforcing
   way.

   An important consideration from the NDN architecture, is the
   hierarchical namespace, allowing nodes to request and convey
   management data, by simply using an appropriate prefix (e.g.,
   ccn://domain/management/ME).

   By leveraging the NDN information-centric dissemination mechanisms to
   convey management information and commands as content, these
   management extensions inherit the intrinsic capabilities of the NDN
   architecture, including security and reliability, which are
   fundamental for management procedures.

3.  Acknowledgements

   This document has benefited from comments and/or text provided by the
   following members of ICNRG: TBD

4.  IANA Considerations

   This memo includes no request to IANA.

5.  Security Considerations

   TBD

6.  Informative References

   [AdaptCCN]
              Lederer, S., Mueler, C., Rainer, B., Timmerer, C., and H.
              Hellwagner, "Adaptive Streaming over Content Centric
              Networks in Mobile Networks using Multiple Links",
              Proceedings of the IEEE International Conference on
              Communication (ICC), Budapest, Hungary , June 2013.






Corujo, et al.           Expires January 2, 2015               [Page 14]

Internet-Draft        ICN Management Considerations            July 2014


   [CATT]     Eum, S., Nakauchi, K., Murata, M., Shoji, Y., and N.
              Nishinaga, "CATT: potential based routing with content
              caching for ICN", Workshop on Information-centric
              networking, pp 49-54 , 2012.

   [CB-TE]    Chanda, A. et al., "Content Based Traffic Engineering in
              Software Defined Information Centric Networks", IEEE
              INFOCOM Workshop NOMEN , April 2013.

   [CCNx]     PARC, "CCNx Project", 2013, <http://www.ccnx.org>.

   [DONA]     Koponen, T. et al., "A Data-Oriented (and Beyond) Network
              Architecture", SIGCOMM, ACM , 2007.

   [GIPR2013]
              Sandivine, , "Global Internet Phenomena Report 1H 2013",
              Sandvine Intelligent Broadband Networks , 2013.

   [ICN-CACHING]
              Zhang, G., Li, Y., and T. Lin, "Caching in information
              centric networking: A survey", Computer Networks, vol. 57,
              no. 16, pp. 3128-3141, Nov , 2013.

   [ICN-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, May , 2014.

   [ICN-Scenarios]
              Pentikousis, K., Ohlman, B., Corujo, D., and G. Boggia,
              "ICN Baseline Scenarios", draft-pentikousis-icn-scenarios
              (work in progress), February 2013.

   [ICN-TE]   Su, K. et al., "On the Benefit of Information Centric
              Networks for Traffic Engineering", IEEE ICC , June 2014.

   [InterAdaptCCN]
              Grandl, R., Su, K., and C. Westphal, "On the Interaction
              of Adaptive Video Streaming with Content-Centric
              Networking", Proceedings of the 20th Packet Video Workshop
              2013, San Jose, USA , December 2013.

   [L4M-ICN]  Chai, W., He, D., Psaras, I., and G. Pavlou, "Cache "less
              for more" in information-centric networks", Lecture Notes
              in Computer Science Vol. 7289, Springer, pp. 27-40 , 2012.





Corujo, et al.           Expires January 2, 2015               [Page 15]

Internet-Draft        ICN Management Considerations            July 2014


   [MPEG-DASH]
              Sodagar, I., "The MPEG-DASH Standard for Multimedia
              Streaming Over the Internet", IEEE MultiMedia, IEEE,
              vol.18, no.4, pp.62-67 , 2011.

   [NDN]      Jacobson, V., Smetters, D., Thornton, J., Plass, M.,
              Briggss, N., and R. Braynard, "Networking Named Content",
              CoNEXT 2009, Rome , Dec 2009.

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

   [NDN-R]    Zhang, L. et al., "Named Data Networking (NDN) Project",
              NDN Report ndn-0001, Tech Report, PARC , 2010,
              <http://www.named-data.net/techreport/TR001ndn-proj.pdf>.

   [NDN-VOIP]
              Jacobson, V., Smetters, D., Briggss, N., Plass, M.,
              Steward, P., and J. Thornton, "VoCCN: Voice Over Content-
              Centric Networks", ReARCH 2009, Rome , Dec 2009.

   [NDNFlexManager]
              UC3M and ITAV, "Framework for Flexible NDN Management",
              2013, <https://github.com/ndnflexmanager/framework>.

   [NetInf]   Ahlgren, B. et al., "Design considerations for a network
              of information", CoNEXT, Re-Arch Workshop, ACM , 2008.

   [NetInfSelfX]
              Pentikousis, K. et al., "Self-Management for a Network of
              Information", IEEE ICC Workshops 2009 , June 2009.

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

   [RFC1157]  Case, J., Fedor, M., Schoffstall, M., and J. Davin,
              "Simple Network Management Protocol (SNMP)", STD 15, RFC
              1157, May 1990.

   [RFC3552]  Rescorla, E. and B. Korver, "Guidelines for Writing RFC
              Text on Security Considerations", BCP 72, RFC 3552, July
              2003.






Corujo, et al.           Expires January 2, 2015               [Page 16]

Internet-Draft        ICN Management Considerations            July 2014


   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              May 2008.

   [RFC6733]  Fajardo, V., Arkko, J., Loughney, J., and G. Zorn,
              "Diameter Base Protocol", RFC 6733, October 2012.

Authors' Addresses

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

   Phone: +351 234 377 900
   Email: dcorujo@av.it.pt


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

   Email: k.pentikousis@eict.de


   Ivan Vidal
   UC3M
   Av de la Universidad, 30
   28911 Leganes, Madrid
   Spain

   Email: ividal@it.uc3m.es


   Jaime Garcia-Reinoso
   UC3M
   Av de la Universidad, 30
   28911 Leganes, Madrid
   Spain

   Email: jgr@it.uc3m.es







Corujo, et al.           Expires January 2, 2015               [Page 17]

Internet-Draft        ICN Management Considerations            July 2014


   Stefan Lederer
   Alpen-Adria Universitat Klagenfurt
   Universitatsstrasse 65-67
   Klagenfurt
   Austria

   Email: stefan.lederer@itec.aau.at


   Spiros Spirou
   Intracom Telecom
   19.7 km Markopoulou Avenue
   Peania  19002
   Greece

   Email: spis@intracom.com


   Cedric Westphal
   Huawei
   2330 Central Expressway
   Santa Clara, CA95050
   USA

   Email: cedric.westphal@huawei.com


























Corujo, et al.           Expires January 2, 2015               [Page 18]