IcnSurveyDocument: draft-mendes-icnrg-survey-00.txt

File draft-mendes-icnrg-survey-00.txt, 52.6 KB (added by paulo.mendes@…, 7 years ago)

ICNRG survey draft -00

Line 
1 
2
3
4
5ICN Research Group                                             P. Mendes
6Internet-Draft                             SITILabs, University Lusofona
7Expires: January 24, 2014                                Cedric Westphal
8                                                                  Huawei
9                                                                L. Zhang
10                                                                    UCLA
11                                                              K. Sollins
12                                                                     MIT
13                                                           July 23, 2013
14
15
16                 Information-Centric Networking Survey
17                      draft-mendes-icnrg-survey-00
18
19
20Abstract
21
22   This document provides a survey about possible directions for the
23   evolution of Information-centric Networking (ICN) solutions. The goal
24   of the document is not to provide a characterization of current ICN
25   proposals, for which there is already significant literature. First
26   of all, the document aims to reach a general consensus about the
27   nature of the ICN paradigm (what are ICNs, what should ICNs be and
28   who are the stakeholders). Second we analyze major architectural
29   approaches for the instantiation of the ICN paradigm,ending up with
30   the identification of several design choices. Special attention is
31   given to the applicability areas described in the ICNRG Baseline
32   Scenarios draft. The analyzed design choices may be specified by some
33   of the technologic and scientific challenges to be described in the
34   ICNRG Research Challenges draft.
35
36Status of this Memo
37
38   This Internet-Draft is submitted to IETF in full conformance with the
39   provisions of BCP 78 and BCP 79.
40
41   Internet-Drafts are working documents of the Internet Engineering
42   Task Force (IETF).  Note that other groups may also distribute
43   working documents as Internet-Drafts.  The list of current Internet-
44   Drafts is at http://datatracker.ietf.org/drafts/current/.
45
46   Internet-Drafts are draft documents valid for a maximum of six months
47   and may be updated, replaced, or obsoleted by other documents at any
48   time.  It is inappropriate to use Internet-Drafts as reference
49   material or to cite them other than as "work in progress."
50
51   This Internet-Draft will expire on April 25, 2012.
52
53 
54
55
56Mendes, et al.          Expires January 24, 2014                [Page 1]
57
58Internet-Draft       ICN Conceptual Reference Model        July 23, 2013
59
60
61Copyright and License Notice
62
63   Copyright (c) 2012 IETF Trust and the persons identified as the
64   document authors. All rights reserved.
65
66   This document is subject to BCP 78 and the IETF Trust's Legal
67   Provisions Relating to IETF Documents
68   (http://trustee.ietf.org/license-info) in effect on the date of
69   publication of this document. Please review these documents
70   carefully, as they describe your rights and restrictions with respect
71   to this document. Code Components extracted from this document must
72   include Simplified BSD License text as described in Section 4.e of
73   the Trust Legal Provisions and are provided without warranty as
74   described in the Simplified BSD License.
75
76
77
78Table of Contents
79
80   1. Introduction  . . . . . . . . . . . . . . . . . . . . . . . . .  3
81     1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
82     1.2. Related effort  . . . . . . . . . . . . . . . . . . . . . .  4
83     1.3. Notation  . . . . . . . . . . . . . . . . . . . . . . . . .  6
84   2. General View on Current ICN Paradigm  . . . . . . . . . . . . .  6
85     2.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . .  6
86     2.2 ICN Major Characteristics  . . . . . . . . . . . . . . . . .  7
87   3. ICN Paradigm Revisited  . . . . . . . . . . . . . . . . . . . .  9
88     3.1. Stakeholders  . . . . . . . . . . . . . . . . . . . . . . . 10
89     3.2. Context Awareness . . . . . . . . . . . . . . . . . . . . . 13
90     3.3. System Support  . . . . . . . . . . . . . . . . . . . . . . 14
91     3.4. Programming Support . . . . . . . . . . . . . . . . . . . . 16
92   4. ICN Architectural design choices  . . . . . . . . . . . . . . . 16
93     4.1 Focus on the What: Declarative networking approach . . . . . 17
94     4.2 Focus on the How: Internetworking approach . . . . . . . . . 17
95   5. Conclusion  . . . . . . . . . . . . . . . . . . . . . . . . . . 17
96   6.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
97     6.1  Normative References  . . . . . . . . . . . . . . . . . . . 17
98     6.2  Informative References  . . . . . . . . . . . . . . . . . . 19
99   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
100
101
102
103
104
105
106
107
108
109 
110
111
112Mendes, et al.          Expires January 24, 2014                [Page 2]
113
114Internet-Draft       ICN Conceptual Reference Model        July 23, 2013
115
116
1171. Introduction
118
119   The Internet has shifted from being a simple host connectivity
120   infrastructure to a platform enabling massive data production and
121   delivery, most of it driven by the end-user who started to have an
122   important role as producer of information.
123
124   This first statement leads us to the need to define what do we mean
125   by data, information and content: Data is the lowest level
126   abstraction whereas information is an abstraction on the next higher
127   level. In order to extract some information from raw data we need to
128   be able to infer a meaning. Moreover, content can be defined as
129   information that may provide value for an end-user in specific
130   contexts. In this document, we use the terms data, information and
131   content interchangeably unless explicitly stated.
132
133   From its original design, the Internet carries packets created by
134   sources, while agnostic to the semantics and purpose of the data
135   transport. Currently there is a mismatch between the end-to-end
136   communication paradigm instantiated by the Internet, and the way
137   users want to use the Internet: people just want to access
138   information anywhere and at anytime, independently of the location of
139   such information. Hence, data persistence, availability and
140   authenticity leveraged with seamless and fast access are capabilities
141   that should be embraced in the design of new networking
142   functionality.
143
144   While the first networking generation was about wiring (telephony)
145   and the second generation was about interconnecting domains (TCP/IP),
146   the next generation should be about interconnecting information in
147   large scale, and beyond the borders of the current wireless Internet.
148   This architectural shift implies rethinking many design choices by
149   placing information at the center of the picture.
150
151   This document analyzes such architectural design shift, starting with
152   a brief analysis of what ICNs are today. This initial study creates
153   the foundations to reach the major goal of this document, which is to
154   answer  to the question "what should Information-centric networking
155   (ICN) be and who needs and wants it?" The document aims to help
156   identifying a suitable direction or directions for the investigation
157   of the Information-centric networking paradigm.
158
159   Until now the Internet evolved with a focus on "how to transport
160   data." One of the questions that is driving this work is: will the
161   instantiation of the ICN paradigm follow the same flow based approach
162   of the Internet, with a different model (e.g. push based, source
163   agnostic, object level security, name routing) or will ICNs follow a
164   completely different approach, for instance shifting the attention
165 
166
167
168Mendes, et al.          Expires January 24, 2014                [Page 3]
169
170Internet-Draft       ICN Conceptual Reference Model        July 23, 2013
171
172
173   from the traffic flow control to "what is being transported". This
174   later approach may lead to a different set of design choices, more
175   focus on database queries, semantic memories, distributed systems and
176   software defined networking.
177
178   Although most of the ICN related proposals presented until now (e.g.
179   Dona [DONA07], NetInf [NetInf10][NetInf12], PSIRP [PSIRP09], CCN
180   [CCN09], Haggle [Haggle06]) follow the "How to" approach, the
181   question is: is this happening as a natural evolution from the flow
182   based Internet paradigm, or are we losing the opportunity to revisit
183   the way networking based on information should be done?
184
185   This document concludes with the identification of design choices,
186   which will deeply depend on the approach followed for the
187   instantiation of the ICN paradigm.
188
1891.1. Scope
190
191   This document follows a top-down approach in the analysis of ICN. In
192   a first part of our study we try to define the nature of the ICN
193   paradigm, starting with a brief description of what ICNs are today,
194   following by an analysis of what ICNs should be and of who needs them
195   and wants to operate them. The definition of ICN stakeholders (the
196   Who) might help clarifying the interfaces with existing technology
197   and business models, such as P2P and CDNs.
198
199   In the second part of our study we try to identify what are the most
200   suitable approaches for the instantiation of the defined ICN
201   paradigm, as well as the core design choices that should be
202   considered.
203
204   This draft is aligned with the ICNRG draft describing ICN scenarios,
205   which will have a special attention in our analysis, and the ICNRG
206   draft describing the research challenges, which need to be aligned
207   with the paradigms and design choices described in this document.
208
2091.2. Related effort
210
211   As mentioned before, the goal of this document is not to provide a
212   characterization of current ICN proposals, for which there is already
213   significant literature. In this context, this section briefly
214   describes and points to prior-art on surveying ICN solutions, aiming
215   to justify the need to to this work at ICNRG.
216
217   In last couple of years there has been important work REF to analyze
218   the major networking properties that should be introduced in the
219   Internet to support an increasing demand for highly scalable and
220   efficient distribution of content. Such work surveyed architectures
221 
222
223
224Mendes, et al.          Expires January 24, 2014                [Page 4]
225
226Internet-Draft       ICN Conceptual Reference Model        July 23, 2013
227
228
229   aiming to focus on information objects, their properties, and on the
230   interest that networked receivers would have on such information
231   objects in order to achieve efficient and reliable distribution of
232   such objects.
233
234   If we look at some of such surveying work, we see that the focus is
235   the same: characterizing networking features and design choices to
236   deploy information objects  based on the same set of proposals such
237   as PSIRP [PSIRP09] (followed by Pursuit [PURSUIT11]), NetInf
238   [NetInf10][NetInf12] and Haggle [Haggle06] in Europe, and DONA
239   [DONA07] and CCN/NDN [CCN09]in the US.
240
241   All these approaches share some assumptions, objectives and
242   architectural properties. In general, the aim is to develop network
243   architectures that are better suited for content distribution being
244   the communication driven by receivers requesting information objects.
245   The network can satisfy the request with data from any networked node
246   holding a copy of the object. Senders make information objects
247   available on the network by publishing the related objects.
248
249   In order to fulfill such goals the same set of building blocks is
250   being used [Ahlgren12], namely: information objects; Naming and
251   Security; Routing and Transport; Caching and Search; Application
252   Programming Interfaces. Besides the similar building blocks, all
253   approaches are focusing on the same challenges, namely: scalability;
254   security; privacy; mobility.
255
256   All current approaches to ICN are more or less taking a clean-slate
257   approach to designing the network of the future. This strategy
258   enables fresh thinking and opens new avenue of investigation.
259   However, it introduces the challenge (faced earlier by UIPv6 or IP
260   multicast) of transitioning from the current architecture to the new
261   ICN technology.
262
263   Moreover the set of stakeholders that are being considered are still
264   the same: i) end users, which are consumers of information; ii)
265   network operators that provide network services such as access and
266   connectivity; iii) storage providers and caching services, which
267   provide content distribution and replication either in network or as
268   an overlay; iv) content providers, which are producers of
269   information; v) application developers and over-the-top service
270   providers.
271
272   In summary, most to the prior art on surveying ICN work is focused on
273   the analysis of the major technical building blocks, based on a set
274   of similar assumption and architectural choices, as well as a
275   predefined view of the stakeholders.
276
277 
278
279
280Mendes, et al.          Expires January 24, 2014                [Page 5]
281
282Internet-Draft       ICN Conceptual Reference Model        July 23, 2013
283
284
285   However, none of the analyzed surveying work provides answers to two
286   questions: i) Is the current general architecture the one that really
287   interests the major stakeholders?; ii) Who should these stakeholders
288   be?; iii) Is the current specification strategy the most interesting
289   to application and service developers?
290
291   These are the questions that we try to look at in this ICNRG draft.
292
293
2941.3. Notation
295
296   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
297   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
298   document are to be interpreted as described in RFC 2119 [RFC2119].
299
3002. General View on Current ICN Paradigm
301
302   This section aims to provide a brief description of what was the
303   motivation to devise an ICN paradigm and what are the currently
304   identified major characteristics.
305
3062.1 Motivation
307
308   The current Internet is seen as a graph of physically connected
309   equipments aiming to transport streams of packets from edge to edge.
310   This structure has been efficient for end-to-end communication. It
311   has supported data distribution very successfully, but mostly by
312   using overlay services that run on top of the Internet architecture.
313   This has introduced some inefficiencies in the network, as the
314   management of the content distribution has become separated from the
315   management of the underlying network infrastructure. In this context,
316   the general idea of information-centric networking is based on the
317   evidence that a great deal of data is produced once, is then copied
318   and replicated many times, and the underlying network needs to be
319   involved in the distribution of this data.
320
321   When studying new networking paradigms, the first question to ask is:
322   Why do we need a way of doing networking different from the current
323   TCP/IP based infrastructure? The answer may be found in the large
324   scale use of the Internet for dissemination of data, mainly driven by
325   the end-user, who started to play a fundamental role as producer of
326   information.
327
328   A significant number of devices (most of them wireless and personal)
329   are generating and consuming data, without caring about the actual
330   data source as long as integrity and authenticity are assured. This
331   means that currently there is a mismatch between the way the Internet
332   operates and the way people wants to use of it.
333 
334
335
336Mendes, et al.          Expires January 24, 2014                [Page 6]
337
338Internet-Draft       ICN Conceptual Reference Model        July 23, 2013
339
340
341   The Internet architecture places the host at the center of attention,
342   aiming to create a network able to settle a communication path
343   between a pair of devices (unicast), a limited set of devices
344   (multicast) or between a large number of devices (broadcast).
345
346   On contrary, with ICN the data content, and not the host, is the
347   central piece of the networking design. This reflects a paradigm
348   shift in direction of the natural way the end-user sees the Internet:
349   a large data container, that the user can use to exchange data
350   without having to know the topological location of networked devices.
351
352   Hence, in recent years we have noticed a shift toward information-
353   centric networking at the service level, with the development of
354   service oriented architectures (SOA) and infrastructures (SOI),
355   content delivery networks (CDN) and P2P networks, for instance.
356
357   The effort done in the last decade towards a new architecture for the
358   Internet have mainly focused on end-host reachability with novel
359   concepts (e.g., identifier/locator split) addressing end-to end
360   security, mobility and routing issues. All of these proposals (e.g.,
361   FARA [Clark03], HIP [Moskowitz06], ROFL [Ceasar06]) are mainly host
362   centric. However, this trend is changing, and a move towards a data-
363   centric architecture has been followed by proposals such as DONA,
364   CCN, Pursuit, Netinf and Haggle, which may be said to have
365   similarities with peer-to-peer, content-delivery, and delay-tolerant
366   networks. The paradigm change is visible in the technical solutions
367   being worked our by these data-centric architectures, such as:
368   addressing is related to the information and not to the hosts; the
369   naming system is independent from the location of information
370   holders; data can be stored in any place of the network; security is
371   implemented at the information level and not around the communication
372   session.
373
374   In the next sub-sections we start by defining what ICN means in the
375   context of current data-centric architectures, and next we analyze
376   what ICN should actually be, and who really needs it and want to
377   deploy it.
378
379   This section aims to clarify what are the main characteristics of the
380   current ICN architecture, as well as to discuss networking and system
381   aspect that may have a significant impact in the evolution of the ICN
382   architecture.
383
3842.2 ICN Major Characteristics
385
386   This section focuses on the current goals of ICN architectures. In
387   the current Internet a great deal of data is produced once, and then
388   is copied and distributed many times. However, only a subset of this
389 
390
391
392Mendes, et al.          Expires January 24, 2014                [Page 7]
393
394Internet-Draft       ICN Conceptual Reference Model        July 23, 2013
395
396
397   data is distributed and stored near the end users, namely that which
398   has access to a Content Delivery Network (CDN). Further, the
399   underlying network is often unaware of this data replication and
400   cannot assist in optimizing its distribution.
401
402   In addition, the cost of storage has been decreasing faster than the
403   cost of bandwidth, and it is expected that the storage capacity that
404   exists in most networked devices (either deployed in the fixed
405   infrastructure or carried by end-users) will greatly expand in the
406   near future. Then, the usage of pervasive storage will aim to
407   dramatically decrease the transmission traffic and to increase the
408   speed of response. Such caching capability can either be tackled a
409   data-level or packet-level approach. In the latter case each cache
410   does not have a complete copy of the data files.
411
412   A second major characteristic is that the name of the data must be
413   sufficient and accurate to describe the information, independently of
414   its location. For example, the name should include enough information
415   to allow all or parts of the data to be fetched and decoded in a
416   secure manner, even if stored in different locations. This implies
417   that in ICNs, security is not associated with the link between the
418   storage location and the end-user, but with the information itself.
419   Information confidentiality, integrity, and availability needs to be
420   protected without assistance from the host containing this
421   information.
422
423   The third major characteristic is that traffic occurs as a
424   consequence of a node willingness to receive some data and not of a
425   source willingness to send data: a consumer announces its interest in
426   receiving data. This interest is then resolved by the network into
427   one or a set of copies of the data, potentially including the
428   original data source. When the data is requested again, data may be
429   send by any nearby node that has the full data or a part of it. This
430   means that the transport is bound to the data name, not to the host
431   location.
432
433   A fourth characteristic is that reachability is not anymore delimited
434   by topological information, but by the notion of data scope. The
435   access to the data is not determined by the relationship to the
436   topology, but the relationship to the data.
437
438   This shift may provide enhanced security (e.g., spam and DDoS
439   mitigation) and bridging connectivity challenged underlying networks
440   (e.g., DTN). Currently, ICN solutions follows two approaches in what
441   concerns routing traffic: The first binds data object names to
442   topology-based locators of storage locations in the network. This
443   approach requires the presence of a node able to perform name-to-
444   locator resolutions, which may imply different routing approaches
445 
446
447
448Mendes, et al.          Expires January 24, 2014                [Page 8]
449
450Internet-Draft       ICN Conceptual Reference Model        July 23, 2013
451
452
453   before and after the resolution point. The second approach directly
454   routes data based on the used name only. In this case the routing
455   algorithm used for this approach heavily depends on the properties of
456   the namespace.
457
458   A fifth major characteristic is that ICNs are well suited for the
459   provision of mobile devices. The reason is that with ICN there is a
460   dissociation between provider and consumer of information in time and
461   space. This means that when content is requested, there may not be
462   connection between the (mobile) source of data and the (mobile)
463   consumer. This is a characteristic that is also found in DTNs.
464
465   In what concerns the instantiation of the ICN paradigm, the
466   publish/subscribe model (pub/sub) [Eugster03] is one of the first
467   trends to provide such instantiation. This paradigm allows
468   asynchronous and decoupled communications. Typically, these systems
469   consist of publishers, subscribers, and a service that ensures that
470   information is routed properly from publishers to subscribers. The
471   suitability and benefits of moving the pub/sub layer downwards into
472   the networking stack has been one of the challenging objectives of
473   ICNs where naming in what concerns routing, forwarding, caching,
474   security and addressing.
475
476   At the same time, some technology, such as P2P, may already satisfy
477   several ICN characteristics, such as the identification of the
478   objects by name, push model, potentially object level security,
479   pervasive caching and name based routing.
480
481   There is no consensus currently about the best logical place to put
482   data storage and replication control: will it be in the consumer
483   equipment, or in the neighboring commercial network nodes?
484
4853. ICN Paradigm Revisited
486
487   We now try to address the following critical question: what should
488   ICN be in the future? This section will mostly revisit the basic ICN
489   paradigm to understand what direction ICNs should follow.
490
491   Hence, this document does not aim to analyze the best way to evolve
492   the building blocks already used in current ICN approaches. This is
493   the subject of the ICN Research Challenges draft [Kutscher13], which
494   elaborates on the need to work around: naming and security; routing
495   and resolution system scalability; mobility and network management;
496   wireless and transport services; In-network caching.
497
498   This document aims to survey what should be the basic context,
499   system, programming paradigms to support the challenges [Kutscher13]
500   and scenarios [Pentikousis13] that ICN should target, as well as who
501 
502
503
504Mendes, et al.          Expires January 24, 2014                [Page 9]
505
506Internet-Draft       ICN Conceptual Reference Model        July 23, 2013
507
508
509   should the stakeholders be.
510
5113.1. Stakeholders
512
513   A network architecture defines interfaces and protocols, which in
514   turns enable business models to be deployed on top. The current
515   architecture divides the generation and consumption of content
516   across: content providers (which may embed advertisers in the
517   content), content distribution (CDNs), Internet transit, ISP, users.
518   A new ICN architecture might merge some of these roles together, or
519   create new roles.
520
521   In the SAIL project [Sail12], these roles are further subdivided
522   into: content provisioning and management; content access management;
523   cache location ownership; cache management; content network
524   management; name resolution; interconnectivity provisioning; access
525   network provider; content consumer.
526
527   Naming is one of the key characteristics of ICN, and the naming
528   structure will define roles in the architecture, which in turn will
529   impact the stakeholders.
530
531   Shoch [Shoch1978] provided the following definition of naming: the
532   name indicates what we seek; an address indicates where it is, and a
533   route tell us how to get there. Mapping mechanisms associate the name
534   to (one or more) address and the address to (one or more) route. The
535   name is not bound to the address until the mapping happens, nor is
536   the address bound to the route.
537
538   Salzer [Salzer1993] updated this taxonomy in RFC1498, defining for
539   types of objects in the network: services and users; nodes; network
540   attachment points; paths. A service can run at multiple nodes; a node
541   can be attached to the network through multiple attachment points;
542   the attachment points can be connected through multiple paths. The
543   key requirement of the naming is to preserve the identity, and it
544   requires three binding services: from service to node; node to
545   attachment point and attachment point to path.
546
547   The binding services correspond to interfaces in the architecture,
548   each corresponding to different stakeholders. Currently, the content
549   to URL mapping would be performed by the like of Google; the URL to
550   IP by a combination of DNS and CDN operator; the IP to route by the
551   network operator(s).
552
553   Information Centric Networks will redefine these naming layers and
554   the roles of the different stakeholders.
555
556   Information can be identified in ICN in two ways: either by naming
557 
558
559
560Mendes, et al.          Expires January 24, 2014               [Page 10]
561
562Internet-Draft       ICN Conceptual Reference Model        July 23, 2013
563
564
565   the data, either in a flat or hierarchical manner; or by describing
566   its content, through the use of metadata. For instance, Content-
567   based-networking [Carzaniga2002] uses descriptors (for instance, some
568   "tags") while CCN, DONA, NetInf all use names.
569
570   The use of descriptor adds a layer into the Salzer taxonomy, as set
571   of tags must be mapped to a content first.
572
573   On the other hand, most ICN would short cut the layer mapping the
574   service delivering the content to a specific node. This induces the
575   following taxonomy:
576
577   descriptor/meta data -> information name -> data object -> network
578   attachment points -> paths
579
580   with the corresponding binding mechanisms and the corresponding
581   impact on the stakeholders:
582
583   information discovery <-> content publisher <-> content distribution
584   <-> content location resolution <-> network operator.
585
586   Different ICN architectures attempt to collapse some of these layers,
587   with a corresponding impact on the stakeholders. Many (CCN, NetInf,
588   DONA) would merge the content distribution, location resolution and
589   forwarding. CCN would actually tie up the path to the content
590   resolution: the interest used to find the content sets the path the
591   content will traverse as it homes in on a copy. Collapsing layers
592   would squeeze out some of the current stakeholders, and require
593   revisiting the business models currently used by these stakeholders.
594
595   Pursuit keeps the layers distinct by having a rendez-vous point to
596   keep track of the content distribution (name to data object mapping),
597   a topology manager which allows the mapping from data object to path,
598   and a path forwarding function using zFilters.
599
600   ICN would let multiple actors store the content; it would also bind
601   the information name to multiple copies, potentially concurrently.
602   This impacts the stakeholder in several dimension. One obvious
603   dimension is for the publisher to keep control over its content (in
604   particular: who accesses the content, how to revoke access to content
605   that is out in the wild, how to enforce content-related policies,
606   etc). Publish/Subscribe mechanisms (NetInf or PURSUIT)or content-
607   based extension to SDN approaches [Chanda2013] would specify an
608   explicit control plane where to enforce this control.
609
610   Another dimension is that of the incentives for the stakeholders to
611   participate in this architecture. In the current distribution model,
612   the content publisher has a contractual relationship with a content
613 
614
615
616Mendes, et al.          Expires January 24, 2014               [Page 11]
617
618Internet-Draft       ICN Conceptual Reference Model        July 23, 2013
619
620
621   distribution network, who has an SLA with the network operator, who
622   has a service contract with the end-user. When the latter wants to
623   access a piece of content, the use of the resources is billed
624   according to these relationships.
625
626   However, if is an open issue for the stakeholders in an ICN to
627   identify a similar business structure. For instance, if an ICN uses
628   opportunistic caching to keep data in the network, then delivers
629   cached data, is the publisher charged for the caching and enhanced
630   QoE for the end-user as if it were using a CDN? If the end-user is
631   receiving data from multiple copies in different locations, how is
632   this content distribution accounted? New metrics and business models
633   need to be defined as well as identifying the new stakeholders
634   [Trossen2012].
635
636   Similarly, security is being shifted from securing the link to
637   securing the content. In terms of the stakeholders, this implies a
638   shift as well. The network operator is oblivious to the content of a
639   secure connection in the current model. However, the network operator
640   can check the validity of the information by using the data
641   signature. This shifts new opportunities for the operator. DDoS as
642   well shifts from being an issue at the server to being an issue in
643   the network. Privacy is transformed as users explicitly express an
644   interest for their requests and obfuscation of such requests is a
645   challenge in current ICN architectures [Brown2010].
646
647   In summary, ICN forces us to not only re-think the network
648   architecture, but also how this network architecture impacts the
649   current participants, and what new stakeholders are being created by
650   the changes in the architecture. In particular, the business models
651   for the resolution of information to name, from name to copy, from
652   copy to network path, for security, for storing content would be
653   significantly affected.
654
655   Moreover, it is expected ICN to allow future Internet architecture to
656   naturally enable network prosumer models [Sofia12] to be exploited as
657   tools that can give rise to new business models and to both social
658   and technological advances. By considering the inclusion of prosumer
659   models, some technologic aspects may need to be revised or
660   generalized, such as the notion of operator, which may in some cases
661   by provided by a group of prosumers, and the notion of path, which in
662   some cases can be intermittently available. From a social
663   perspective, some properties are relevant to be applied to ICN
664   design: reach, engagement,and influence. Reach corresponds to the
665   degree of effective dissemination of certain content or potential
666   spread that a single node has in the network. Engagement refers to
667   the degree of participation and involvement of a specific node.
668   Influence refers to the degree of attention and mobilization that a
669 
670
671
672Mendes, et al.          Expires January 24, 2014               [Page 12]
673
674Internet-Draft       ICN Conceptual Reference Model        July 23, 2013
675
676
677   certain node can generate in other actors. The integration of
678   influence is expected to assist in a better definition of interaction
679   matrices, an aspect that today is key for several aspects of the
680   operation of the Internet, such as new ways to route traffic,
681   awareness about the stakeholder context, or a better definition of
682   self-organizing environments.
683
6843.2. Context Awareness
685
686   The goal of this section is to examine opinions about how aware an
687   ICN system should be of its surrounding. Currently data is mostly
688   transferred based on an explicit request from a receiver and the way
689   data crosses the network is agnostic about the situation of each
690   node, not only topological, but also in terms of this mobility
691   pattern and behavior (e.g. power off periods).
692
693   This aspect is important to be considered when an ICN system is
694   disseminating data in a network, since the decision about the
695   selection of the best next hop should consider the context
696   constraints of potential forwarders in order to avoid dead ends.
697
698   The first aspects has to do with in-system context. For instance in
699   the core of a network, the next core router may be overloaded or may
700   have functional problems that leads to its intermittent presence in
701   the network (e.g. layer 2 synchronization problems). These
702   problematic nodes should not be selected as next hops to reach a
703   source of data. Another examples of in-system context is the caching
704   policies, which may increase the probability of a interest request to
705   be dropped.
706
707   The second aspects has to do with out-system context, mainly related
708   to the surroundings of the networked node. This is more relevant in
709   the case of ICN nodes (producers, consumers or forwarders) that are
710   carried by individuals. This aspect is of increasing important, due
711   to the recent trend of incorporating an increasing number of sensors
712   into mobile phones, which opens up a new research frontier that has
713   the potential to significantly impact many aspects of our everyday
714   life from healthcare, to safety, entertainment, and business.
715   However, the broad impact of this vision is jeopardized without
716   advances in the computational models we use to process and
717   disseminate sensor data generated by mobile phones.
718
719   From an ICN point of view, the networking paradigm needs to be
720   prepared to support a continuous dissemination of a higher quantity
721   of data, since producers and consumers of data will generate and
722   request data based on automatic processes, mostly independent of the
723   human direct intervention.
724
725 
726
727
728Mendes, et al.          Expires January 24, 2014               [Page 13]
729
730Internet-Draft       ICN Conceptual Reference Model        July 23, 2013
731
732
733   Hence, it is highly important for a ICN system installed in a
734   consumer and/or producer node, to be aware of the context of the
735   node, in order to quickly react to fluctuations in the generation of
736   data or subscription of data interests. In what concerns ICN
737   forwarding systems, being aware of the context of the node, mainly in
738   the case of mobile nodes, may be useful to support more efficient
739   forwarding decisions.
740
7413.3. System Support
742
743   Telecommunications networks are not well know by their self-
744   organization properties. However, IP-based networks have several
745   self-organized control functions, such as decentralized congestion
746   control and address auto-configuration.
747
748   Self-organization will be even more important by the advent of
749   ubiquitous computing, where data services play a central role due to
750   the increasing number and diversity of producers and consumer
751   devices, such as portable music and video players, wearable computers
752   and embedded sensor devices.
753
754   Hence, this section aim to survey the benefits of increasing the
755   self-organized properties of the ICN architecture. The first goal is
756   to investigate how the performance of an ICN system can be improved
757   by having nodes aware of the behavior of their neighbors. For
758   example, in a ICN domain each node should manage its behavior based
759   on its observation of the mobility pattern (if any) and the caching
760   behavior of its neighbors, rather than on the behavior of a "central"
761   node to the domain or that of the whole domain itself.
762
763   Self-organization is more than just distributed and localized
764   control. In an ICN it may be about the relationship between the data
765   processing behavior of the individual nodes and the resulting data
766   distribution (structure) and availability (functionality) in the
767   overall system. It is expected that in a fully self-organized ICN
768   system, the application of rather simple behavior at the node level
769   leads to sophisticated data organization of the overall system. In
770   complex system theory, this phenomenon is called emergent behavior.
771   Why and how emergent behavior may and should occur in an ICN system
772   is subject to further investigation.
773
774   We believe that a higher level of self-organization will be able to
775   support solutions to the mentioned challenges, mainly by reducing the
776   administration efforts of users and network operators, and to
777   increase the scalability properties. However, the inclusion of self-
778   organization properties leads to increased complexity and dynamics of
779   communications networks, which might become a subject for further
780   research.
781 
782
783
784Mendes, et al.          Expires January 24, 2014               [Page 14]
785
786Internet-Draft       ICN Conceptual Reference Model        July 23, 2013
787
788
789   In order to design a self-organized ICN architecture (with its
790   benefits in terms of scalability and performance) it is important to
791   analyze which principles from self-organized systems can be applied
792   to ICN, and what are the design paradigms that should be followed to
793   build a self-organized ICN function, namely: i) Local behavior rules
794   aiming to achieve global properties; ii) Exploit implicit
795   coordination; iii) Minimize long lives network state; iv) Protocol
796   able to adapt to changes.
797
798   In what concerns the emergence property of ICN, the paradigm of self-
799   organization relies on the distribution of responsibility among
800   individual entities. Hence we must design localized ICN rules that,
801   if applied in all entities, automatically lead to the desired global
802   property. This is, entities have only a local view of the network and
803   interact with their neighbors.
804
805   The ICN architecture will allow nodes to share data objects, and
806   consequently network, storage and computational resources. To enable
807   efficient and fair access to data objects and resources, nodes have
808   to be coordinated in some manner. While centralized systems apply
809   explicitly signaling to avoid any kind of conflict, the idea is to
810   tolerate conflicts in a self-organized ICN, if we can manage them in
811   a contained manner. In this context, the use of implicit coordination
812   can be exploited, meaning that control information is not explicitly
813   signaled, but is inferred from the local environment.
814
815   Many networking technologies require nodes to store and maintain
816   long-lived network state. For instance, in cellular networks, devices
817   have to store the addresses of dedicated network entities, such as
818   location and security databases as well as gateways to the Internet.
819   Such network state needs to be kept synchronized: information is
820   stored consistently among several nodes. The most common example in
821   the Internet are routing tables. To reach the desired level of self-
822   organization, the amount of long-lived state needs to be minimized.
823   One approach is to employ discovery mechanisms, which can be
824   proactive or reactive.
825
826   One last self-organization property to be considered is the
827   capability of nodes to react to changes in the network and its
828   environment. However, applying learning methods to support such
829   adaptation property is too complex in dynamic environments. Moreover,
830   changing algorithms on-the-fly may lead to difficulties in the
831   communication process. On the other hand to establish all potential
832   operation modes during design phase may not be feasible, which would
833   require the replacement of the complete protocol in the overall
834   network. This may lead to operational problems, even when using
835   network virtualization. Hence the most suitable solution to allow an
836   ICN system to adapt to changes in the network and in the environment
837 
838
839
840Mendes, et al.          Expires January 24, 2014               [Page 15]
841
842Internet-Draft       ICN Conceptual Reference Model        July 23, 2013
843
844
845   is still a research issue.
846
847   Still related to the topic of network virtualization, of strategic
848   importance is the investigation of the correlation between self-
849   organization and centralized systems to support for example software
850   defined networking aspects (e.g. usage of openflow). The former has
851   the advantage to augment scalability while the second bring benefits
852   in the success of deployment and management. Issues related to the
853   way ICN are programmed is the subject of the next section.
854
8553.4. Programming Support
856
857   The networking research community have been exploiting a variety of
858   new network architectures, such as all the ICN related proposals. In
859   these proposals, the system is configured with parameters aiming to
860   optimize performance, given the constraints of specific deployment
861   environment.
862
863   In order to make deployment and maintenance easier and faster, it
864   would be important to analyze other methods to allow constraint
865   optimization problems. Traditionally, constraint optimization
866   problems approaches use imperative languages such as C++ or Java and
867   often result in cumbersome and error-prone programs that are
868   difficult to maintain and customize. Moreover, due to scalability and
869   management constraints imposed across administrative domains, it is
870   often necessary to execute optimization methods in a distributed
871   setting in which multiple local solvers must be coordinated.
872
873   Declarative networking [Lool12] is a programming methodology that
874   enables developers to concisely specify network protocols and
875   services using a distributed recursive query language, and directly
876   compile these specifications into a data flows for execution. This
877   approach provides an easier specification, and additional
878   optimization benefits.
879
880   In this context, this section aims to survey the usage of declarative
881   networking in the context of ICN, as it was used before in other
882   contexts such as cloud computing, sensor networks and mobile ad-hoc
883   networks. One of the aspect to be considered when applying a
884   declarative approach to ICN may be the separation of control and data
885   plan by following an software defined networking approach (e.g. using
886   openflow to execute flows defined declaratively)
887
888
8894. ICN Architectural design choices
890
891   TBD
892
893 
894
895
896Mendes, et al.          Expires January 24, 2014               [Page 16]
897
898Internet-Draft       ICN Conceptual Reference Model        July 23, 2013
899
900
9014.1 Focus on the What: Declarative networking approach
902
903   Should ICN paradigm help to look at the Internet as a large scale
904   data distributed system?
905
906   TBD
907
9084.2 Focus on the How: Internetworking approach
909
910   Should ICN paradigm help to define an Internet as a control flow
911   system focus on data?
912
913   TBD
914
915
9165. Conclusion
917
918   This document provides a survey about possible directions for the
919   evolution of the Information-centric Networking (ICN) paradigm. This
920   document does not aim to analyze the best way to evolve specific
921   technical building blocks already used in current ICN approaches
922   (e.g. routing, naming system, caching), but to provide a broad
923   analysis about architectural design choices. In this version, we
924   provide an analysis of what the ICN paradigm should consider from the
925   point of view of the stakeholders, context awareness, system, and
926   programming support. In a future version, we will analyze major
927   architectural choices that will allow the instantiation of an ICN
928   framework supported by the identified stakeholders, environment,
929   system and programming design approaches. In this study, special
930   attention is given to the applicability areas described in the ICNRG
931   Baseline Scenarios draft, and the scientific challenges described in
932   the ICNRG Research Challenges draft.
933
9346.  References
935
9366.1  Normative References
937
938   [Ahlgren12] B. Ahlgren, C. Dannewitz, C. Imbrenda, D. Kutscher, B.
939              Ohlman, "A survey of information-centric networking" in
940              IEEE Communication Magazine Vol. 50, Issue 7, Page(s) 26-
941              36, July 2012
942
943   [CCN09] V. Jacobson, D. Smetters, J. Thornton, M. Plass, N. Briggs,
944              R. Braynard, "Networking Named Content", in Proc. ACM
945              CoNext, Rome, Italy, Dec 2009
946
947   [DONA07] T. Koponen, B. Chun, A. Ermolinskiy, K. Kim, S. Shenker, I.
948              Stoica, "A Data-Oriented (and Beyond) Network
949 
950
951
952Mendes, et al.          Expires January 24, 2014               [Page 17]
953
954Internet-Draft       ICN Conceptual Reference Model        July 23, 2013
955
956
957              Architecture", in Proc. of ACM SIGCOMM,Kyoto, Japan, Aug
958              2007
959
960   [Fotiou11] N. Fotiou, D. Trossen, G. Polyzos, Illustrating a publish-
961              subscribe Internet architecture, Journal on
962              Telecommunication Systems, Springer, March 2011
963
964   [Haggle06] J. Scott, P. Hui, J. Crowcroft, C. Diot, "Haggle: A
965              Networking Architecture Designed Around Mobile Users", in
966              Proc. of IFIP WONS, Les Menuires, France, January 2006
967
968   [Kutscher13] D. Kutscher, K. Pentikousis, I. Psaras, D. Corujo, D.
969              Saucez, "ICN Research Challenges", IETF draft draft-
970              kutscher-icnrg-challenges-00, Internet Engineering Task
971              Force, February 2013. Work in progress.
972
973   [NetInf10] B. Ahlgren, M. D'Ambrosio, C. Dannewitz, A. Eriksson, J.
974              Goli"c, B. Gronvall, D. Horne, A. Lindgren, O. Mammela, M.
975              Marchisio, J. Makela, S. Nechifor, B. Ohlman, K.
976              Pentikousis, S. Randriamasy, T. Rautio, E. Renault, P.
977              Seittenranta, O. Strandberg, B. Tarnauca, V. Vercellone,
978              and D. Zeghlache, Second netinf architecture description,"
979              4WARD EU FP7 Project, Deliverable D-6.2 v2.0, Apr. 2010
980
981   [NetInf12] D. Kutscher, S. Farrell, and E. Davies. The NetInf
982              Protocol. Internet draft draft-kutscher-icnrg-netinf-
983              proto, Internet Engineering Task Force, October 2012. Work
984              in progress.
985
986   [Pentikousis13] K. Pentikousis, B. Ohlman, D. Corujo, G. Boggia, G.
987              Tyson, E. Davies, D. Gellert, P. Mahadevan, "ICN Baseline
988              Scenarios", Internet draft draft-pentikousis-icn-
989              scenarios-02, Internet Engineering Task Force, March 2013.
990              Work in progress.
991
992   [PSIRP09] P. Jokela, A. Zahemszky, C. E. Rothenberg, S. Arianfar, and
993              P. Nikander, LIPSIN: Line Speed Publish/Subscribe Inter-
994              networking, in Proceedings of the ACM SIGCOMM 2009
995              conference on Data communication, New York, USA, 2009
996
997   [Pursuit11] D. Trossen, G. Parisis, K. Visala, B. Gajic, J.
998              Riihijarvi, P. Flegkas, P. Sarolahti, P. Jokela, X.
999              Vasilakos, C. Tsilopoulos, S. Arianfar, "PURSUIT
1000              Conceptual Architecture: Principles, Patterns and Sub-
1001              Components Descriptions", Publish Subscribe Internet
1002              Technology FP7-INFSO-ICT-257217 Deliverable D2.2, 2011.
1003
1004   [Salzer1993] J. Salzer, "On the Naming and Binding of Network
1005 
1006
1007
1008Mendes, et al.          Expires January 24, 2014               [Page 18]
1009
1010Internet-Draft       ICN Conceptual Reference Model        July 23, 2013
1011
1012
1013              Destinations", Internet Engineering Task Force, RFC1498,
1014              August 1993.
1015
1016   [Shoch1978] J. Shoch, "A Note on Inter-Network Naming, Addressing and
1017              Routing", Internet Experiment Note #19, January 1978.
1018
1019
1020
10216.2  Informative References
1022
1023   [Brown2010] I. Brown, D. Clark, D. Trossen, "Should specific values
1024              be embedded in the internet architecture?", in Proceedings
1025              of ACM SIGCOMM workshop ReARCH'10, August 2010.
1026
1027   [Carzaniga2002] A. Carzaniga, A. L. Wolf, "Content-based networking:
1028              A new communication infrastructure",  Developing an
1029              Infrastructure for Mobile and Wireless Systems. Springer
1030              Berlin Heidelberg, 2002. 59-68.
1031
1032   [Chanda2013] A. Chanda, C. Westphal, "ContentFlow: Mapping Content to
1033              Flows in Software Defined Networks", in Proc. IEEE
1034              Globecom, December 2013
1035
1036   [Clark03] D. Clark, R. Braden, A. Falk, V. Pingali, "FARA:
1037              Reorganizing the Addressing Architecture", in Proc. of ACM
1038              SIGCOMM, Karlsruhe, Germany, Aug 2003.
1039
1040   [Ceasar06] M. Caesar , T. Condie , J. Kannan , K. Lakshminarayanan ,
1041              I. Stoica , S. Shenker, "ROFL: routing on flat labels", in
1042              proc. of ACM SIGCOMM, Pisa, Italy, September 2006.
1043
1044   [Eugster03] P. Eugster, P. Felber, R. Guerraoui, A. Kermarrec, "The
1045              many faces of publish/subscribe". ACM Computing
1046              Surveys,35(2):114-131, June 2003.
1047
1048   [Lool12] B. Loo1, H. Gill, C. Liu, Y. Mao, W. Marczak, M. Sherr, A.
1049              Wang1, W. Zhou, "Recent Advances in Declarative
1050              Networking", Practical Aspects of Declarative Languages
1051              Lecture Notes in Computer Science Volume 7149, 2012, pp 1-
1052              16.
1053
1054   [Moskowitz06] R. Moskowitz, P. Nikander, "Host Identity Protocol
1055              (HIP) Architecture", IETF RFC 4423, May 2006.
1056
1057   [Sail12] Luis Correia, Ricardo Ferreira, Jo‹o Gonalves, Tapio LevŠ,
1058              Johan Myrberger, Bšrje Ohlman, Jukka Salo, Daniel
1059              Sebasti‹o, Jo‹o Soares, Nan Zhang, "D-2.8 Evaluation of
1060              Business Models", SAIL project deliverable, October 2012.
1061 
1062
1063
1064Mendes, et al.          Expires January 24, 2014               [Page 19]
1065
1066Internet-Draft       ICN Conceptual Reference Model        July 23, 2013
1067
1068
1069   [Sofia12] Rute Sofia, Paulo Mendes, Manuel JosŽ Dam‡sio, Sara
1070              Henriques, Fabio Giglietto, Erica Giambitto, Alessandro
1071              Bogliolo, "Moving Towards a Socially-Driven Internet
1072              Architectural Design", in ACM CCR, Vol. 42, No. 3, July
1073              2012.
1074
1075   [Trossen2012] D. Trossen, A. Kostopolous, "Techno-Economic Aspects of
1076              Information-Centric Networking", Journal for Information
1077              Policy, volume 2, March 2012.,
1078
1079Authors' Addresses
1080
1081              Paulo Mendes
1082              SITILabs, Universidade Lusofona
1083              Campo Grande, 376, Ed. U
1084              1749-024 Lisboa
1085              Portugal
1086
1087              Phone:
1088              Email: paulo.mendes@ulusofona.pt
1089              URI: http://siti.ulusofona.pt/~pmendes
1090
1091
1092              Cedric Westphal
1093              Huawei Technologies
1094              2330 Central Expy
1095              Santa Clara
1096              USA
1097
1098              Phone:
1099              Email: Cedric.Westphal@huawei.com
1100              URI: http://users.soe.ucsc.edu/~cedric
1101
1102              Lixia Zhang
1103              UCLA Computer Science Department
1104              3713 Boelter Hall
1105              Los Angeles, CA 90095-1596
1106              USA
1107
1108              Phone:
1109              Email: lixia@cs.ucla.edu
1110              URI:
1111
1112              Karen Sollins
1113              MIT CSAIL
1114              The Stata Center
1115              32 Vassar Street
1116              Building 32, G820
1117 
1118
1119
1120Mendes, et al.          Expires January 24, 2014               [Page 20]
1121
1122Internet-Draft       ICN Conceptual Reference Model        July 23, 2013
1123
1124
1125              Cambridge, MA 02139
1126              USA
1127
1128              Phone:
1129              Email: sollins@csail.mit.edu
1130              URI:
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176Mendes, et al.          Expires January 24, 2014               [Page 21]