Subscribe Us

Get free daily email updates!

Follow us!

Wednesday, September 21, 2011

The Content-Centric Internet (A Future Internet Concept)


Nowadays most people exploit the Internet to get contents such as web pages, music or video files. These users only value ‘‘what’’ they download and are not interested about ‘‘where’’ content is actually stored. The IP layer does the opposite and cares about the ‘‘where’’ and not about the ‘‘what’’. This contrast between the actual usage of the Internet and the service offered by the IP layer is deemed to be the source of several problems concerning usability, performance, security and mobility issues. To overcome this contrast, research on the Future Internet is exploring novel so-called content-centric architectures, where the network layer directly provides users with contents, instead of providing communication channels between hosts.
There is a growing consensus in the recent literature that the central role of the IP address poorly fits the actual form of Internet usage. A typical user does not type IP addresses; she gets data or services by using application tools (e.g., Google, YouTube, Facebook, Skype), which operate on the basis of a description of the desired content.

This means that users actually exploit the Internet in a content-centric way; indeed, they are not interested in knowing from ‘‘where’’ contents are provided, they are only interested in the fact that they can get ‘‘what’’ they want. Conversely, the underlying IP communication model is still address-centric (or host-centric); that is, the network layer has to be fed by IP addresses, which are used to ascertain from ‘‘where’’ contents have to be taken. Therefore, there is amismatch between the content-centric usage model of the Internet and the addresscentric service model offered by the IP layer. Such a mismatch gives rise to several problems that would not exist if the network layer were a content-centric one. Some of these issues are: • Persistence of the Names. Once a user gives a name to a content, she wishes that the name remains valid even if the provider that makes available the content on the Internet changes. Today, naming is based on the WEB URL structure, which has a ‘‘where/what’’ format. The URL structure is perfectly tailored for an address-centric network layer, but it implies the change of the name in case the provider (i.e., ‘‘where’’) changes. If the network-layer were a content-centric one, it would be able to route on the basis of the content (routing-by-name), thus avoiding the need of including ‘‘where’’ in the name of the content. • Content distribution. Today the reliability of a content and the time required for retrieving a content are improved by distributing (caching or pre-fetching) replicas of the content on different servers, geographically distributed. Furthermore, content replication strongly limits the amount of traffic traversing the backbone, since a lot of data sessions are locally handled by these servers. Since the IP layer is unable to ‘‘understand’’ contents, content distribution is achieved by means of proprietary application-layer systems, like Akamay CDN, or WEB proxies. While the success of these systems is undeniable, they do not cooperate with each other, often they are not free of charge and they are not available everywhere; thus, their potential effectiveness is reduced. If the network layer were a content-centric one, it would be aware of which contents are traversing the network and could autonomously and natively implement replication strategies, everywhere and for all.
• Lookup delay. Today the real delivery of a content begins only after that the client application has queried the DNS server, in order to discover the IP address of the related server. The additional DNS request-response delay is quickly becoming a dominant delay factor; indeed Internet data-rates are faster growing, reducing the time needed to transfer content. If the network layer were content-centric, it would route directly the request toward the content, thus avoiding the mediation of a DNS server. • Mobility. An IP address identifies both the location and the identity of an endpoint; this location-identity tie is deemed to be the source of many mobility related weaknesses. A content-centric network overcomes these limitations by basing the routing directly on the identity of an end-point; in this case the end- point is the actual content and its identity (e.g., a name) does not include any reference to its location. • Security. Users are interested in receiving trusted contents; today this is achieved in an indirect way: a user trusts ‘‘who’’ provides the content, rather than trusting the content itself. This approach could be risky as there are a lot of actors to trust, in the process of content retrieval. For instance, a user believes that she is trading with Amazon because she clicks on a link with the name ‘‘http://www.amazon.com’’, which is provided by a search-engine tool, like Google. In doing so, she is trusting both the search-engine and the DNS server providing the name-to-address translation. Moreover, she is also trusting the mirror server where she could be redirected by a content distribution system . The higher the number of actors to trust, the more critical is the overall security of the system. In a content-centric network, security information travels with the content, so that even if content is provided by an un-trusted server or is transferred on an un-trusted network, it can be validated by the consumer. Moreover, such a content-based security also enables the replication of secure contents by any network node, which is very important as users can get contents not only from the original content creator or source node but also from any node/user that has already downloaded that content. Currently, several researchers and research projects are proposing their network architectures and protocol stacks aimed at implementing the content-centric paradigm. In terms of deployment, the proposed solutions can be classified as evolutionary or clean-slate. The evolutionary architectures implement content-centric functionalities by enhancing the actual Internet. The enhancement consists in deploying new entities that form a content-centric ‘‘overlay’’ network. Conversely, clean-slate architectures are alternative to the TCP/IP one. A clean-slate architecture is devised to operate directly over the linklayer and, therefore, implies a redesign of network layer functionalities from scratch. Obviously, a clean-slate solution can also be implemented at the overlay level, e.g., by visualizing IP tunnels as link-layer interface; however, in this case some functionalities could be duplicated in TCP/IP and content-centric layers. A content-Centric Internet User-case Scenario: Bob Smith is a young reporter that has recorded a video and wishes to publish it on a content-centric network. Bob prepares a data-package that embeds video and security information, he names this package as ‘‘bob.smith. Video’’ and puts it in a storing device, connected with one or more network routers. uch a data-package is the actual content. Alice wishes to retrieve Bob’s video and submits a request to the network layer, where the ‘‘destination’’ content-name is bob.smith. video. Each network router forwards Alice’s request toward the closest storing device that holds a copy of Bob’s content (exploiting only the name ‘‘bob.smith.video’’); we name this phase ‘‘content-routing’’. When Alice’s request reaches a storing device, the network layer delivers Bob’s content to the address-less device of Alice; we name this phase ‘‘content-delivery’’. During the content delivery phase, some intermediate routers may decide to cache and then forward the content. When the content is received by Alice’s device, the whole security information is checked to verify, for instance, the authenticity of the embedded video, the right of Alice to play it and so forth. This scenario involves a set of functionalities like naming, routing, delivery and Caching.

A content-centric network is devised to directly provide what users value in the actual Internet, i.e. contents. This may imply a clean-slate re-design of the network layer, changing the actual communication paradigm (which has two hosts as endpoints) in a novel paradigm (which has a host and a content as end-points). Although a content-centric architecture may better satisfy user needs, it is not easy to imagine a replacement of the actual TCP/IP infrastructure in the medium term. Thus, we could argue that a content-centric network could more likely be deployed n a Future Internet consisting of software-routers running different network layer protocols, thus forming different virtual networks.

0 Responses to “ The Content-Centric Internet (A Future Internet Concept) ”

Post a Comment