ISSN (Online) : 2278-1021 ISSN (Print) : 2319-5940 International Journal of Advanced Research in Computer and Communication Engineering Vol. 3, Issue 10, October 2014 A Survey on Naming, Name Resolution and Data Routing in Information Centric Networking (ICN) Alcardo Alex Barakabitze, Tan Xiaoheng, Guo Tan College of Communication Engineering, Chongqing University, China Abstract: Information-Centric Networking (ICN) is set to replace the current internet architecture which is based on end-to-end communication between hosts. The ICN approach to the network of the future has recently been and is being explored by a number of research projects from Asia, Europe and America. This paper provides a review on three Information Centric Networking (ICN) architectures based on objects/contents naming, name resolution and data routing. The review highlights and briefly describes the naming structures, operation of name resolution and data routing processes of DONA, NetInf and PURSUIT. A summary in tabular form and a comparative study of these three architectures is also given in the paper. Keywords: ICN, Naming, Name Resolution and Data Routing of ICN, Networks. 1.INTRODUCTION Information-centric networking (ICN) is the hot research topic in recent years, with various research initiatives like DONA [1], CCN/NDN [2][10][16] PSIRP/PURSUIT [3][4][8][11][12], 4WARD [13], CONVERGENCE[15], NetInf [9], SAIL[17],COMET [5–7][14]), MobilityFirst [18] and ANR Connect [19] targeting this emerging research area with the aim of shifting from the current Internet architecture which is built and designed for a hostto-host communications model. The Internet architecture today has experienced rapid growth in network traffic of which most of the traffics are characterized by the content retrieval applications running on top of the Internet architecture. The Internet has grown tremendously with many new applications being deployed in order to fulfill the new requirements from the architecture. These requirements includes the needs to support distribution of contents in a scalable manner, transparency to applications, security issues, mobility and many more others [21].Many applications like the MoblieIP, which have been deployed to run and serve the needs of the current Internet requirements adds some complexity and seems to be only the temporal solutions because they try to run and match on the architecture which is built on top of a host-to-host communication model [20][22].The contents or objects delivery solutions today from producers or publishers to subscribers/consumer involves technologies like Content Delivery Networks (CDNs), peer-to-peer networks and other players such as CDN providers, Internet Service Providers(ISPs) and Content Providers. However, the current internet content delivery today suffers from heterogeneity problems because its evolution and deployment to the current Internet architecture has been triggered by the market needs rather than the coherent internet architectural plan. In addition to that, the caching solutions proposed in the current internet infrastructure have some inefficiency since they are matching the content centric problem to a network Copyright to IJARCCE infrastructure which was meant for a host-to-host communication model.The increasing demand of network end -users towards accessing and delivering contents with high volume of digital contents like movies from YouTube, time-shift televisions, high definition Video on Demand (VoD), photos e.t.c is the one which have driven the shift from the current internet architecture to a new architectural plan of the future Internet called Information Centric Networking(ICN).ICN targets and puts emphasis to content objects to be cached/stored in the network nodes or routers and also to be accessed anywhere different from the current architecture where content are stored and accessed from the hosts like servers[17].End users in ICN are only interested in the content or object itself in steady of a server location. Indeed, ICN architecture is meant to enable in-network storage for caching contents, decoupling a content sender/publisher and receiver/subscriber and also to enable multiparty communication through replication [20]. The main purpose is to have a reliable distribution of contents through an efficient communication platform and services provision which is available in dedicated systems like proprietary content distribution networks and peer-to peer (P2P) overlays. The concept behind ICN is to develop a network which will interprets, processes, and delivers contents/information/objects automatically and independently of its physical location [23]. ICN is to replace the host addresses with content names which will be exchanged upon user requests or demands and network components like routers will be equipped with storage capabilities. Since the content names will be decoupled from host addresses, then, it will remove the role of the current IP address which plays as an identifier and a locator. By directly naming contents, it will enable innetwork caching (routers to store contents) which will also results in the improved delivery of popular contents in the Internet. In addition, each content will now be www.ijarcce.com 8322 ISSN (Online) : 2278-1021 ISSN (Print) : 2319-5940 International Journal of Advanced Research in Computer and Communication Engineering Vol. 3, Issue 10, October 2014 authenticated and identified uniquely with no any network host associations [29]. The key functionalities and general features in all ICN architectures are naming, Name resolution and data routing, mobility, Caching and Security [24-28]. The future Internet architecture (ICN) has drawn attention to the Internet research community and the research community has made an increasing interest in the ICN Project approaches as shown in Table 1 which stipulate a number of research projects with the links to their official websites. This attention is also verified by the recent establishment of the Information-Centric Networking Research Group (ICNRG) http://irtf.org/icnrg) within the Internet Research Task Force (IRTF) [28][48]. However, these ICN project are still in an ongoing process to develop the future Internet architecture. Table 1: Major ICN Research Projects for the Future Internet Architecture. Website Project Sponsor Time Frame TRIAD[49] http://gregorio.stanford.edu/triad/ United States of America Jul 1999-Dec 2002 DONA[1] http://www.sigcomm.org/node/2633 No data collected AsiaFI COMET[14] ANR Connect[19] Convergence[15] GreenICN[51] http://www.asiafi.net/ http://www.comet-project.org/ http://www.anr-connect.org/ University Califonia Berkeley Asia Europe French Funded Project http://www.ict-convergence.eu/ http://www.greenicn.org/ Europe Europe NDN[16] http://www.named-data.net/ United States of America NetInf[50] PSIRP[11] PURSUIT[12] 4WARD[13] SAIL[17] http://www.netinf.org/ http://www.psirp.org/ http://www.fp7-pursuit.eu/ http://www.4ward-project.eu/ http://www.sail-project.eu http://mobilityfirst.winlab.rutgers.ed NSA-FA Program Europe Europe Europe Europe NSA-FIA Program Jun 2010-Feb 2013 Apr 2013 – Mar 2016 Sep 2010- Aug 2013 Jan 2008 - Jun2010 Jan 2008-Jun2010 Sep 2010-Feb 2013 Jan 2008-Jun 2010 Aug 2010-Jan 2013 Sep 2010-Sep 2013 MobilityFirst[18] This paper illustrates three ICN architectures namely DONA, NetInf and PURSUIT with focusing only in three ICN features which are Naming, Name Resolution and Data Routing. The rest of this paper is organized as follows: Section 2 provides a brief description of the naming, name resolution and data routing in ICN. Section 3- 5 gives in depth explanations of the mentioned ICN architectures. Section 6 summarizes the highlighted parts of the descriptions by giving a comparative study of the three ICN architectures. Then section 7 concludes the paper. Sept 2007Jan 2010-Dec 2012 Jan 2011- Dec 2012 returned address to establish the end-to-end communication session. This is a location dependent mainly on IP address which faces problems to archiving the persistence and services availability requirements. In this manner, three features under naming in ICN have been proposed [28] which are name-data integrity that establish a verifiable binding between the object and its name; object authenticity which ensures authentication of received objects to a receiver in such a way that the received object represent the actual object published on the network and the object’s provenance which enables to know who published the object on the network. The proposed naming mechanisms of ICN architectures are location independent. These proposed naming schemes in ICN are:  Hierarchical name space-Which has a similar structure like the URL. Advantages a) It enables routing information aggregation. b) The routing system is improved in terms of scalability.  Flat and Self-certifying namespace:-means that the 2. NAMING, NAME RESOLUTION AND DATA ROUTING OF ICN. 2.1 Naming in ICN The main abstraction of ICN is the Named Data Object (NDO) which includes webpages, videos, photos, documents, live streaming and interactive media [28].One of the ICN feature is Naming. Naming data objects is an important aspect of ICN. Since names are used to indentify NDO independent of its location then, ICN needs unique names for every NDO [28].The IP address in the current internet architecture performs a key role between name-data integrity is to be verified with no need of a public parts in communication.The current end-to-end key infrastructure (PKI)[28]. Flat naming offers communication paradigm performs two separate sessions uniqueness and persistency. in the process of establishing a communication. The first In general, naming mechanisms in different ICN designs step is to resolve the name to an IP address and then as a may range from flat to hierarchical and sometimes other separate session, send a communication request using the approaches employ the human readable naming scheme Copyright to IJARCCE www.ijarcce.com 8323 ISSN (Online) : 2278-1021 ISSN (Print) : 2319-5940 International Journal of Advanced Research in Computer and Communication Engineering Vol. 3, Issue 10, October 2014 which enables a user to type the names manually and retrieve contents according to his or her needs [21]. 2.2 Name Resolution, Data Routing and Forwarding in ICN. ICN manages the process of routing and forwarding NDO packets through two different steps namely the name resolution which is a 2-way mechanism and the Name Based Routing (NBR) which is just a 1-way mechanism [30]. The Name Resolution step enables a subscriber/customer to search for NDO by using names. The first step is to map the name and the source locators where the NDO is stored [31], the second step is to forward the request message from the subscriber to the source. However, this 2-step mechanism is called the Name Resolution System (NRS) for providing translation. One of the drawbacks of this mechanism is that, the NRS itself become a point-offailure which can results into many of the NDO published and registered on that NRS to be unavailable[31].The only advantage of this approach is that, it ensures subscribers to find the requested NDO because NRS are providing the pointer to the NDO source. Name-Based or Data Routing is a 1-way mechanism where the NDO request is forwarded by content routers (CR) and the CR decides locally the next hop of the NDO request based on NDO name[31].According to Choi [32],there are two types of routing models in ICN design approaches which are: a) Unstructured Routing Model that works similar to the current IP routing but with some modifications. b) Structured Routing Model which utilizes the Distributed Hash Table (DHT) to provide a lookup and routing service [31][32]. In principle, name resolution is the process of mapping or matching a content name to a publisher/provider/source which can then provide the requested content. Data routing is the process of making a required path for transferring the content/information from a publisher up to the subscriber/customer. The name resolution and data routing in ICN design can be integrated together to form a coupled approach where the requested content by a subscriber is routed to content providers and then this provider sends the content back to the subscriber by using the reverse path over which the request was forwarded[21].When the two functions are not integrated together, it form the decoupled approach where there are no restrictions on the path that will be used to forward data to and from a subscriber to the content publisher/provider [21].The ICN design models for the future internet architecture available so far have proposed different naming system as well as different data routing processes. Some ICN architectures perform name resolution and data routing separately in such a way that they perform name resolution first and then perform data routing. Other ICN proposals tried to combine these transactions together. The following section provides in depth description of the naming, name resolution and data routing process of DONA, PURSUIT and NetInf ICN architectures Copyright to IJARCCE 3. DATA ORIENTED NETWORK ARCHITECTURE (DONA) NAMING DONA [1] proposes to use names which are flat, application-independent, location-independent ,globally unique[21] and a self certifying naming scheme with a resolution infrastructure that is organized in a hierarchical manner which intend to achieve three basic objectives namely: a reduced users‟ request latency, persistence and provenance of contents [30].Every contents or objects in DONA have an association with a principal and all names have the form P:L where P represents the cryptographic hash of the owner‟s public key[21] and L represents a label that identifies uniquely the contents with respect to the principal P[30]. An example of naming scheme in DONA is shown below FileType <String>: docx Paper title<String>: Review of Naming in ICN Author <ListofString>: Alcardo Alex Institution <String>: Chongqing University Year <Integer>: 2014 3.1 Name resolution and data routing The Resolution Handlers (RHs) which are the specialized servers performs name resolution in DONA. Every Autonomous System (AS) has more than one logical RHs which are connected to each other forming a hierarchical name resolution service[21][28].The inter-domain routing solutions is built together with the hierarchical resolution systems so as to enable the name resolution and data routing through the data routing policies established between two or more ASs. Figure 1 below shows the mechanism of data routing and name resolution in DONA. The publisher or principal or owners of content is responsible to publish the NDOs into the network where nodes that are authorized to provide contents or information have to register to the resolution infrastructure which consists of RHs. The publisher or principal sends a REGISTER message with the content‟s name to its local RH, the RH stores the pointer to the principal P as shown by arrow 1.The local RH of the principal then sends information of this registration to other RHs which are in the same domain through their established data routing policies in the network (see arrow 2-3). After receiving the registration sent by the local RH of the principal, each peering RH then stores a mapping of object‟s names and the address of the local RH which were forwarded by the publisher during registration. This registration continues up to tier-1 providers which enables RHs in tier-1 to become aware of this publisher registration throughout the whole network. On the subscriber part, a FIND message is sent to its local RHs which forwards the request to RHs peers to find a content matching as shown in arrow 4 to 5.The pointers created while publishing a registration from a principal are used to reach the publisher of the content as shown in arrow 6 and 7.This process becomes successful if the requested content is already published in the network. www.ijarcce.com 8324 ISSN (Online) : 2278-1021 ISSN (Print) : 2319-5940 International Journal of Advanced Research in Computer and Communication Engineering Vol. 3, Issue 10, October 2014 Tier-1 AS RH Router Publisher Subscriber Router RH AS1 Router RH AS3 Router AS2 RH Publisher-Subscriber Link (8-11) Peering Link Requested Data (1-3) Registering NDO (4-7) Finding a NDO Figure 1: The DONA architecture. However, subscribers/customers may request a wildcard Multicast channels can be supported in DONA which is a FIND messages to ask for unchangeable data with a mechanism that enables resolution handlers to cache the FIND message for duration of time until the message specific label, regardless of its purveyor [21][28][30]. 3.2 Data routing: expires [21]. In this case, if another find message arrives DONA takes two forms of data routing which are to the RH looking for the same message, then the RH decoupled and coupled data routing. In the decoupled data merges these two messages into a single entry but with routing, the traditional IP routing and forwarding multiple path labels for the responses [21]. In this manner, mechanisms can be used to send back the requested the multicast distribution tree is created and hence the content to a subscriber after a content match from the multicast channels. publisher. This requires the normal transmission schemes 4. PUBLISH SUBSCRIBE INTERNET of network traffic and the established routing policies TECHNOLOGY (PURSUIT) between the subscribers‟ ASs and publisher‟s AS‟s. The PURSUIT ICN design for the future internet In the coupled data routing model, the FIND message architecture is the continuation of the Publish Subscribe from a subscriber, records every RH and the routes it Internet Routing Paradigm (PSIRP)[11] which are both traverses together with its associated sequences of ASs funded by the EU Framework 7 Project[21][31].The that the request took to reach a publisher of the content in PUSRSUIT project have implemented the structure of the the network. publish-subscribe protocol stack which will replace the When a content match occurs to the publisher, the routes traditional IP protocol stack in the current internet recorded in the FIND message will be used to forward the architecture. The PURSUIT ICN architecture consists of content back to the subscriber as shown in arrows 8-11. three main functions as shown in figure 1. Copyright to IJARCCE www.ijarcce.com 8325 ISSN (Online) : 2278-1021 ISSN (Print) : 2319-5940 International Journal of Advanced Research in Computer and Communication Engineering Vol. 3, Issue 10, October 2014 Tier 1-AS RH GLOBAL RENE RH RH RH RH RENE1 RH FN FN RH (10) RH TM AS1 RENE2 RH Publisher TM FN FN Subscriber AS2 Overlay Link between servers Inter-domain Link (1-2) (3-6) (7-8) RN-Rendezvous Node RENE-Rendezvous NEtwork Intra-domain Link Publish Message FN-Forwarding Node TM-Topology Manager Subscriber Message Delivery Path Request Message (9-10) Start-Publish Message (11) Data to a subscriber Hierarchical between RENE(s) Figure 2: The PURSUIT architecture [21]. The three core parts of PURSUIT are: Rendezvous Function(RF)  Topology Management Function(TMF)  Data Forwarding Function (DFF). a) The Rendezvous Function The Rendezvous function which operates at the Rendezvous Node (RN) is the most important part in the PURSUIT ICN model since it establishes a connection between the subscriber and the publisher for an information item on the network infrastructure. It also initializes the information item delivery from the publisher to the subscriber by directing the topology management function to create a possible route for forwarding data to a subscriber [31]. b) The Topology Management Function(TMF) The TMF is responsible for creating a routing policy and also to collect the topology information of its domain. It also performs the exchange of routing information with other topology management peers so as to enhance routing of information globally. The Topology Manager (TM) Copyright to IJARCCE operates the TMF and one network domain has one TM as shown in figure 2 [21]. c) The Data Forwarding Function(DFF) The DFF is performed on the Forwarding Node (FN) which is responsible for directing the information item to the subscriber who requested particular information. In the PURSUIT ICN design the FN has capabilities also of caching or storing an information item. 4.1 Naming The NDO in PARSUIT are called information items [31].These information items are indentified by a unique pair of identifiers called the Rendezvous ID (Rid) and the Scope ID (SId). SId is responsible to keep items of related information together and the Rid is responsible to keep and identify information of a particular item [33]. As shown in figure 3, every information item must be in at least one scope. The scopes are responsible to provide: Policy and boundaries enforcement to an information item [31].  Access right for each group of information items [31]. www.ijarcce.com 8326 ISSN (Online) : 2278-1021 ISSN (Print) : 2319-5940 International Journal of Advanced Research in Computer and Communication Engineering Vol. 3, Issue 10, October 2014 SId2 SId1 SId1 RId1 RId2 SId1 SId2 RId3 RId1 RId2 Figure 3: Information item model of PURSUIT [11][31] PURSUIT utilizes the flat naming scheme which has sequences of SIds and an RId. As shown in the PURSUIT information item model (see figure 3), a name of an information item takes a path from the root of the tree to the leaf node which actually is the RId. However, multiple names of an information item can be used to specify the same piece of an information item. i.e SId2/SId1/Rid2 or SId1/SId1/Rid2 can be used to specify Rid2. 4.2 Name Resolution and Data Routing. In PURSUIT, the name resolution and data routing is implemented by a collection of Rendezvous Nodes (RNs), the Rendezvous Network (RENE), Topology Manager (TM) and the Forwarding Nodes (FNs). According to [34] and [35],the RENE in PURSUIT, is designed and implemented as a hierarchical Distributed Hash Table(DHT).As shown in figure 2,the global RENE in tier-1 connects together the RENE1 in AS1 and RENE2 in AS2. From figure 2 above, A publisher publishes information item of identifiers (SId, RId) to its local RN which is the owner of the scope as shown in arrows 1-2. The owner of the scope is not necessarily to be in the same domain and therefore can also be a source RNs from other domains such as RN from RENE2 in AS2.The subscriber who is need of the same item specifies RId and SId in order to request for an information item and sends out a subscription message through its local RN towards the scope owner RN using RId as shown in arrow 3-6. The Topology Manager (TM) node in RENE 1 is then instructed by the RN to create a route that will connect the publisher and the subscriber for data delivery as shown in arrows 7-8.The START-PUBLISH route as a message is sent to the publisher by the TM which will be utilized in sending the information items through a set of Forwarding Nodes (FNs).The START-PUBLISH route is shown in arrow 9-10. The information item which is forwarded via FNs, uses the Bloom Filter's Forwarding Identifier (FId) to decide where to send the packet [36]. In PURSUIT, the RENE performs the process of resolving names or name resolution while the TMs perform the data routing process which is executed by the FNs [21]. approaches in the SAIL project of which the other ones are Open Connectivity Services [37] and Cloud Networking [38]. The NetInf project is mainly based on three core functionalities: a) The idea of unique naming of information objects without imposing a hierarchical naming structure like the approaches used in 4WARD and DONA [39]. b) Receiver-oriented transport as in CCN. c) A multi-technology or multi-domain approach than can leverage different underlying network services and employ different name resolution/name-based routing and transport mechanisms [39]. 5.1 Naming in NetInf The naming in NetInf takes a flat-ish [21] structure which enables a certain degree of flexibility similar to resource identification in the current web today. The NetInf naming therefore includes some Uniform Resource Identifier (URI) concepts and have developed the Named Information (ni:) URI scheme that is specified by Stephen et.al [40] and that of Philip et.al [41] for Internet drafts. As shown in figure 4 below, the naming system proposed by NetInf is a flat and self-certifying like in DONA and it consists of two parts which are A: L, where A is the hash of the owner‟s public key and L is a label chosen by the owner. This public-private key pair is taken as a binding to the content or an information object. Figure 4: The basic naming structure of NetInf [42] Every part in the structure can be considered as a hash which then allows for self-certification. In addition to that it also allows different type of a string data type therefore allowing the normal Uniform Resource Locators (URLs)[39].The NetInf requires that, a subscription have to match with the publication only if the actual name on the network is found to be similar with the matching pair between that of the subscriber and a publisher otherwise an information object will seem to be missing. In case of routing, names in NetInf can be hierarchical where routers can determine how to route an information object to a subscriber by using the longest prefix matching mechanism similar to the one used in NDN [43]. 5.2 Name Resolution and Data routing in NetInf. The Name Resolution function is the main part of NetInf ICN architecture which utilizes the Name Resolution System (NRS) to provide resolution services to NetInf subscribers. The NRS can play also a function of a namebased routing system [39]. A specific NRS in [44] has been designed based on the Resolution EXchange (REX) sub-system of Multilevel Distributed Hash Table (MDHT).This specific NRS integrate the name-based forwarding system in NetInf and the name resolution function. It is used to show how the resolution process can be performed over a global network [39]. 5. NETWORK OF INFORMATION (NETINF) Requests and response messages from subscribers are Network of Information (NetInf) is a part of the EU FP7 forwarded and resolved for an information objects in projects 4WARD and SAIL[50]. The NetInf is one of NetInf design architecture. As in the current Internet three “Scalable and Adaptive Internet Solutions” architecture which has multiple routing protocols, different Copyright to IJARCCE www.ijarcce.com 8327 ISSN (Online) : 2278-1021 ISSN (Print) : 2319-5940 International Journal of Advanced Research in Computer and Communication Engineering Vol. 3, Issue 10, October 2014 parts of the NetInf network may also have many different requirements and therefore needing also multiple different routing protocols. In this manner, the NetInf ICN architectural design can be able to support different request or response and routing or forwarding protocols like the Open Shortest Path First (OSPF) for local domains [43]. The design and implementation principles in NetInf therefore enable an easy way of plugging a new name resolution, forwarding or even a routing protocol. By integrating the name-based routing and the aspects of the name resolution, the NetInf can be able therefore to use a hybrid request routing or forwarding scheme. The integration of name resolution and name-based routing can also support Late Name Binding (LNB) which is a strategy that enables the name resolution process to be done at a node which is near to the current area of a moving host[21][43][28]. Figure 5: Final NetInf Architecture and message flow [43] The NetInf ICN design can easily adapt to different similarities as well some differences in the naming, name network environments because of its capability to retrieve Resolution and the way data is routed from the client to the information objects through a name resolution, name- the source. Table 2 shows a comparison of the three ICN based routing as well as a hybrid operation[21][28].In design for the future Internet architecture the case of name resolution, the publisher/source is DONA has a flat naming scheme structure which consists responsible to publish the NDOs through a registration of of a principal and a label part. The names in DONA are the name/locator binding to a NRS while in the case of not human readable and the granularity of NDO is the name-based routing, the publisher/source is responsible to object itself. The name resolution is managed by the RHs publish the NDOs by announcing routing information in a which are organized by the Autonomous System (AS) routing protocol [43]. Figure 5 shows an example of hierarchy [21].The name-based routing via RHs handles name-based routing, name resolution and the hybrid all NDO requests while the routing of NDO back to the operation in NetInf. The requester through a GET message client follows the reverse path of the request. resolve the NDO into a set of routing hints and can be able to query NRS. Subsequently, the routing hints are used to NetInf takes a flat-ish name structure. The name retrieve an information object from available sources using resolution and data routing in NetInf can be a coupled, the underlying transport network such as the IPv4 network decoupled or hybrid operation. In the coupled case, the as shown in steps B1-B4. Alternatively to that, the NDO request is enabled to accumulate routing state during requester can sends a GET request hop-by-hop between name resolution. In the decoupled case, the Distributed NetInf routers/caches until a copy of an information object Hash Table (DHT)-based name resolution is responsible to is found through the name-based routing as shown in steps return the content locator, and in the hybrid case, the name resolution is responsible to return the routing hints in order A1-A4. Steps A1.1-A1.2 shows a hybrid operation which occurs to assist the coupled operation [21]. when the router for example in step A2 does not have The PURSUIT takes a flat naming scheme which is not sufficient information to perform name-based routing. In human readable as in DONA. Different from DONA, the this case, the NRS therefore returns routing hints which name in PURSUIT consists of scope Id and the are partial locators that can direct a GET message in one rendezvous Id. The NRS is responsible to match the or more routes where more information about the subscriber and a publisher of an information object. The NDO requests are handled by the NRS while the routing requested information object may be found [21]. of NDO back to the client is handled by the source routes 6. SUMMARY AND COMPARATIVE ANALYSIS using a techniques which is based on bloom filters OF THE THREE ICN DESIGN APPROACHES. [21][36]. The three discussed ICN design approaches have some Copyright to IJARCCE www.ijarcce.com 8328 ISSN (Online) : 2278-1021 ISSN (Print) : 2319-5940 International Journal of Advanced Research in Computer and Communication Engineering Vol. 3, Issue 10, October 2014 Table 2:Comparison of ICN Designs for the future Internet. 7.CONCLUSION This paper survey has explored the three promising ICN architecture design for the future Internet architecture which are DONA, NetInf, PURSUIT. We have described in more detail the operations of these ICN architecture regarding to naming, name resolution and data routing which are among the features of every ICN architecture. Along with this, the review has provided a comparative analysis of the three ICN designs. Although there is a need of migrating from the current Internet architecture to the new ICN Internet architecture but still there a lot of challenges which are related to developing efficient scalable routing schemes, congestion control mechanisms, Quality of service (QoS) approaches, and efficient caching decision policies, security and privacy issues, new ICN application-protocols design, new business models between different actors or players on the Internet as well as new legal and regulatory frameworks [48].We argue that, ICN is a new paradigm with an intention to replace the current Internet architecture which was meant for communication between hosts which does not suits with the high demanding needs of users today. In this regard, there is a high need to research more on the outlined challenges so as to meet the future requirements of the ever growing number of Internet users who are interested in the contents regardless of their location on the network. Copyright to IJARCCE ACKNOWLEDGMENT We would like to convey our gratitude to the entire community of Chongqing University for creating a unique and peaceful learning environment. The direct and indirect support we received in accomplishing this paper from academic staff in the college of Commutation Engineering is highly appreciated . REFERENCES [1] [2] [3] [4] [5] [6] T. Koponen, M. Chawla, B. Chun, A. Ermolinskiy, K. Kim, S. Shenker, I. Stoica, A data-oriented (and beyond) network architecture, ACM SIGCOMM Computer Communication Review, vol. 37, ACM, 2007, pp. 181–192. V. Jacobson, D. Smetters, J. Thornton, M. Plass, N. Briggs, R. Braynard, Networking named content, in: Proceedings of the 5th International Conference on Emerging Networking Experiments and Technologies, ACM, 2009, pp. 1–12. D. Trossen et al., Conceptual Architecture: Principles, Patterns and Subcomponents Descriptions, May 2011. <http://www.fp7pursuit.eu/ PursuitWeb/>. P. Jokela et al., LIPSIN: Line speeds publish/subscribe internetworking, in: Proc. ACM SIGCOMM, Barcelona, Spain, 2009. G. Garcia et al., COMET: Content mediator architecture for content-aware networks, in: Proc. of the Future Network and Mobile Summit 2011, Warsaw, Poland, IEEE, June 2011. G. Pavlou, N. Wang, W.K. Chai, I. Psaras, Internet-scale Content Mediation in Information-centric Networks, Ann. Telecommun., Special Issue on Networked Digital Media, Springer, in press. http://dx.doi.org/10.1007/s12243-012-0333-8. www.ijarcce.com 8329 ISSN (Online) : 2278-1021 ISSN (Print) : 2319-5940 International Journal of Advanced Research in Computer and Communication Engineering Vol. 3, Issue 10, October 2014 [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21] [22] [23] [24] [25] [26] [27] [28] [29] [30] [31] [32] W.K. Chai et al., CURLING: Content-ubiquitous resolution and [33] D. Trossen and G. Parisis, “Designing and realizing an informationcentric Internet,” IEEE Commun. Mag., vol. 50, no. 7, delivery infrastructure for next-generation services, IEEE Commun. pp. 60–67, July Mag. 49 (3) (2011) 112–120. D. Lagutin, K. Visala, S. Tarkoma, Publish/subscribe for internet: [34] J. Rajahalme, M. S¨arel¨a, K. Visala, and J. Riihij¨arvi, “On namebased inter-domain routing,” Computer Networks, vol. 55, no. 4, Psirp perspective, Towards the Future Internet Emerging Trends from pp. 975–986, March 2011. European Research 4 (2010) 75–84. B. Ahlgren, M. D‟Ambrosio, M. Marchisio, I. Marsh, C. Dannewitz, B [35] K. V. Katsaros, N. Fotiou, X. Vasilakos, C. N. Ververidis, C. Tsilopoulos, G. Xylomenos, and G. C. Polyzos, “On inter-domain Ohlman, K. Pentikousis, O. Strandberg, R. Rembarz, V. Vercellone, name resolution for information-centric networks,” in Proc. IFIPDesign considerations for a network of information, in: Proceedings of TC6 Networking Conference.2012. the 2008 ACM CoNEXT Conference, ACM, 2008, p. 66. L. Zhang, D. Estrin, J. Burke, V. Jacobson, J. Thornton, D. Smetters, [36] B. H. Bloom, “Space/time trade-offs in hash coding with allowable errors,” Communications of the ACM, vol. 13, no. 7, pp. 422–426, B. Zhang, G. Tsudik, D. Massey, C. Papadopoulos, et al., Named Data July 1970. Networking (NDN) Project, Tech. Rep., PARC, Tech. Report ndn[37] SAIL Project. Architectural Concepts of Connectivity Services. 0001, 2010. Deliverable FP7-ICT-2009-5- 257448-SAIL/D.C.1, SAIL EU FP7 FP7 PSIRP project. [Online]. Available: http://www.psirp.org/ project, July 2011. Available online from http://www.sailproject.eu. FP7 PURSUIT project. [Online]. Available: http://www.fp7[38] SAIL Project. Cloud Networking Architecture Description. pursuit.eu/PursuitWeb/ Deliverable FP7-ICT-2009-5- 257448-SAIL/D.D.1, SAIL EU FP7 FP7 4WARD project. [Online]. Available: http://www.4wardproject, July 2011. Available online from http://www.sailproject. project.eu/ eu. FP7 COMET project. [Online]. Available: http://www.comet[39] SAIL-(D-B.1).The Network of Information: project.org/ Architecture and Applications: Objective FP7-ICT-2009-5-257448/DFP7 CONVERGENCE project. [Online]. Available: 3.1,available at http://www.ictconvergence.eu/ http://www.sailproject.eu/wpcontent/uploads/2011/08/SAIL_DB1_ NSF Named Data Networking project. [Online]. Available: v1_0_final-Public.pdf http://www.named-data.net/ [40] Stephen Farrell, Dirk Kutscher, Christian Dannewitz, Boerje FP7 SAIL project. [Online]. Available: http://www.sail-project.eu/ Ohlman, and Phillip Hallam-Baker. The Named Information (ni) NSF Mobility First project. [Online]. Available: URI Scheme: Core Syntax. Internet Draft draft-farrelldecadehttp://mobilityfirst.winlab.rutgers.edu/. ni-00, Work in progress, October 2011. ANR Connect project. [Online]. Available: http://anr-connect.org/ [41] Phillip Hallam-Baker, Rob Stradling, Stephen Farrell, Dirk Bengt Ahlgren, Christian Dannewitz, Claudio Imbrenda, Dirk Kutscher, and Boerje Ohlman.The Named Information (ni) URI Kutscher, and Börje Ohlman .A Survey of Information-Centric Scheme: Parameters. Draft-hallambaker-decade-ni-params-00, Networking, IEEE Communications Magazine • July 2012 Work in progress, October 2011. George Xylomenos, Christopher N. Ververidis, Vasilios A. Siris, Nikos Fotiou, Christos Tsilopoulos, Xenofon Vasilakos, Konstantinos [42] Christian Dannewitz, Jovan Goli´c, B¨orje Ohlman, and Bengt Ahlgren, “Secure Naming for a Network of Information”, IEEE V. Katsaros, and George C. Polyzos, A Survey of Information-Centric INFOCOM 2010. Networking Research, IEEE COMMUNICATIONS SURVEYS & [43] SAIL Project. (2013, January) SAIL deliverable B.3 (3.3): Final TUTORIALS,September 2013. NetInf architecture. [Online]. Available: http://www.sailproject. M. Handley, “Why the Internet only just works,” BT Technology J.vol. Eu/deliverables/. 24, no. 3, pp. 119–129, July 2006. [44] M. D‟Ambrosio, C. Dannewitz, H. Karl, and V. Vercellone. G. Carofiglio , G. Morabito, L. Muscariello, I. Solis, M. Varvello, MDHT: A Hierarchical NameResolution Service for InformationFrom content delivery today to information centric networking, centric Networks. In ACM SIGCOMM Workshop on InformationComputer Networks 57 (2013) 3116–3127,July 2013. Centric Networking (ICN 2011), Ottawa, Canada, August 2011. A. Ghodsi, T. Koponen, J. Rajahalme, P. Sarolahti, and S. Shenker, “Naming in content-oriented architectures,” in ACM Workshop on [45] Content Centric Networking project. [Online]. Available: http://www.ccnx.org/ Information-Centric Networking (ICN), 2011. P. Stuckmann and R. Zimmermann, “European research on future [46] V. Jacobson, “A new way to look at networking,” Google Tech Talk, August 2006. Internet design,” IEEE Wireless Commun., vol. 16, no. 5, pp. 14–22, [47] Huichen Dai, Jianyuan Lu, Yi Wang, Bin Liu(2012),A Two-layer October 2009. Intra-domain Routing Scheme for Named Data Networking, J. Pan, S. Paul, and R. Jain, “A survey of the research on future Internet architectures,” IEEE Commun. Mag., vol. 49, no. 7, pp. 26– Globecom 2012 - Next Generation Networking and Internet 36, July 2011. Symposium, Available in IEEE. J. Choi, J. Han, E. Cho, T. Kwon, and Y. Choi, “Survey on content [48] Information Centric Networking Research Group(ICNRG),[Online] oriented networking for efficient content delivery,” IEEE Commun. available at https://irtf.org/icnrg Mag., vol. 49, no. 3, pp. 121–127, March 2011. [49] Stanford University TRIAD project. [Online]. Available: B. Ahlgren, C. Dannewitz, C. Imbrenda, D. Kutscher, and B. Ohlman, http://gregorio.stanford.edu/triad/ “A survey of information-centric networking,” IEEE Commun. Mag., [50] NSA NetInf Project.[Online] Available at http://www.netinf.org/ vol. 50, no. 7, pp. 26–36, July 2012. [51] FP7-GreenICN Project,[Online],Available at Wei Koong Chai, Diliang He, Ioannis Psaras, George Pavlou.Cache http://www.greenicn.org/ „„less for more‟‟ in information-centric networks (extended version), Computer Communications 36 (2013) 758–770, www.elsevier.com/ locate/comcom M.F. Bari; S. Chowdhury; R. Ahmed; R. Boutaba; B. Mathieu, A survey of Naming and Routing in Information Centric Networks,― IEEE Comm Mag, vol. 50, no. 12, 2012, pp. 44-53. http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=6384450&i snumber=6384439. Dolvara Gunatilaka, Recent Information-Centric Networking Approaches,[Online] available at http://www.cse.wustl.edu/~jain/cse570-13/ftp/icn/ J. Choi; J. Han; E. Cho; T. Kwon; Y. Choi, “A Survey on ContentOriented Networking For Efficient Content Delivery,― IEEE Comm Mag, vol. 49, no. 3, 2011, pp.121-127. http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=5723809&i snumber=5723785 Copyright to IJARCCE www.ijarcce.com 8330