A busca pela acessibilidade global com o surgimento da internet, no ínicio dos anos 80, influenciou a adoção da pilha de protocolos TCP/IP com o objetivo de interconectar redes, prover conectividade fim-a-fim, dentre outros. Na interconexão de redes, protocolos de roteamento eram utilizados, de forma que os roteadores podiam calcular o menor caminho disponível entre qualquer par origem-destino, já que a internet era subdividida entre poucas redes e composta por menos nós. Embora esse cenário tenha mudado, os protocolos de roteamento atuais possuem os mesmos papéis.
Com o aumento exponencial do número de usuários e de redes na internet, surgiram problemas na interoperção de redes. A solução encontrada para adaptar o modelo TCP/IP foi de divisão da internet em sistemas autonomos (Autonomous systems - ASes), sendo um conjunto de redes e roteadores operadas por uma instituição em comum. Contudo, o paradigma dessa arquitetura de focar na troca de dados baseado na localização dos hosts e não no próprio conteúdo gerado e armazenado por eles traz consigo problemas na compatibilidade de interesses, tendo em vista que o usuário de internet tem como foco principal o conteúdo em sí e nao sua localização de armazenamento.
Desse modo, estuda-se qual a melhor alternativa para problemas como a disponibilidade de conteúdo, segurança, dependencia dos hosts e que seja capaz de evoluir para atender os avanços na internet. Pôr fim as limitações da arquitetura atual é possível substituindo o “onde” pelo “o que”. Ou seja, os dados passam a ser guiados por indicadores de nomes da informacao, em vez de nomes de interfaces de hosts. Apesar de ser um conceito relativamente novo, já existem modelos em desenvolvimento de redes centradas no conteudo ou orientadas a informacao, mesmo não havendo implementações em larga escala. Nos próximos capitulos serao abordados caracteristicas dessas aplicações, bem como projetos, problemas e desafios.

Quando observamos a internet hoje em dia, vemos a tendência que esta tem em mudar para um modelo centrado no conteúdo. Nesse modelo seriam buscados os conteúdos e não os servidores onde tais conteúdos seriam encontrados. Com o intuito de chegar à esse modelo de redes centradas em conteúdo sem mudar como a internet está implementada, algumas formas alternativas de usar o modelo TCP/IP para se aproximar do foco no conteúdo. Alguns exemplos virão a seguir: Redes P2P, Sistemas de Publicação e Assinatura e Redes por Distribuição de Conteúdo.

1. Redes TCP/IP
2. Redes P2P

   As redes P2P são formadas pelas conexões diretas entres usuários finais. Nesse modelo a ideia é que a conexão ocorre entre participantes que não têm hierarquia entre si.
   O BitTorrent é uma das mais famosas aplicações da rede P2P. A distribuição de conteúdo se dá entre um usuário que já possui um arquivo para um usuário que deseja adquirir tal arquivo. Os usuários que possuem o arquivo são chamados de seeders. Quanto mais seeders mais rápido será o download de um arquivo. Isso torna um sistema escalável, já que quanto mais rápido for para obter um arquivo mais rápido vai se tornando obter esse arquivo. No entanto essa ideia é mais teórica do que real, pois na realidade nem sempre todos usuários que terminam de baixar seus arquivos se colocam à disposição para fornecer esses arquivos como seeders.

3. Sistemas de Publicação e Assinatura

   Nesse sistema, um usuário publica um evento. Um outro usuário interessado nesse evento assina o mesmo. A partir desse momento sempre que houver o sistema notifica o usuário que assinou sempre que houver um outro evento que se assemelha aos que ele assinou. Esse sistema demonstra a ideia da prioridade na informação. O assinante não tem interesse no usuário que publica, mas no evento em si.

4. Redes por Distribuição de Conteúdo

   Quando pensamos em um serviços que são usados por muitos usuários como Google, Youtube, que distribui milhares de vídeos para milhares de pessoas ao redor do mundo, fica mais claro o porquê da distribuição de conteúdos. Faz-se necessário quando vemos que para tornar essa distribuição efetiva para todos os usuários, é desejável que não haja apenas um gigantesco datacenter. Pois se esse for o caso, usuários que requisitarem o conteúdo de longe desse datacenter, terão sempre uma vulnerabilidade à lentidão, pois estarão sujeitos a muitos ISPs e muitos links no caminho. Além disso, um único datacenter seria um ponto único de falha.
   As redes por distribuição de conteúdo (CDN) são uma forma de “espalhar” um servidor único em vários servidores para conseguir levar o conteúdo para um requisitante pelo servidor mais próximo.A CDN é vantajosa tanto para o usuário final quanto para o servidor principal. Visto que com um grande número de requisições ao servidor, este também terá dificuldades para atender a todas as requisições. Isso resultará numa maior chance de perdas e num aumento do tráfego. Quando o usuário requisitar um dado, o servidor que está em melhor condições de responder esse usuário, responderá com o dado requisitado armazenado em cache por esse servidor. Caso esse servidor não tem tal dado em cache, ele procurará em outros servidores CDNs próximos. Se ainda assim ele não conseguir achar. O servidor CDN inicial funcionará como um proxy para o servidor original do dado. Armazenando, após a entrega, o dado em questão. Existem dois modos de operação: Enter deep e Bring home. O primeiro coloca um grande número de servidores com a intenção de se aproximar ao máximo do usuário que vai requisitar o serviço. Nesse modo encurta-se o número de links e a distância geográfica entre o servidor CDN e o usuário. Porém com o grande número de servidores, a manutenção deles se torna mais difícil. Esse modo de operação é utilizado pela Akamai. Já o segundo modo se baseia em não muitos, mas servidores localizados em locais chaves com conexões de ponta e privadas. A localização desses servidores não tem por intenção se aproximar ao máximo dos usuários finais. Mas se aproximar do maior número de ISPs de nível 1 possível. A manutenção se torna mais barata e fácil. No entanto há possibilidade de perda na qualidade do serviço.

As ICNs apresentam uma mudança radical para modelo atual da Internet. A possibilidade de entregar conteúdo independentemente de servidores específicos está ligada à conceitos que serão discutidos neste capítulo: Nomenclatura de Conteúdo; Roteamento Baseado em Nomes e Caching na Rede.

1. Conteúdo Nomeado

   Como visto anteriormente, a Internet é fortemente baseada em servidores. Todo conteúdo requisitado exige um conhecimento prévio de um endereço IP capaz de servir tal conteúdo. O princípio básico das ICNs é tratar o conteúdo como o paradigma principal das redes, em vez dos servidores. Para isso, as requisições de conteúdo precisam seguir um esquema de nomenclatura capaz de oferecer escalabilidade e consistência entre nomes e conteúdo.
   
   Três técnicas básicas de nomenclatura de conteúdo podem ser usadas em ICN:

   • Nomenclatura Plana
     Nomes planos são conjuntos de bits aparentemente aleatórios e unicamente relacionados ao conteúdo de interesse, como, por exemplo, uma chave de 160 bits gerada pela função hash SHA-1, tendo como entrada os bits do conteúdo em si. Sistemas robustos e escaláveis de distribuição de chaves hash são um tópico bem conhecido, e algumas soluções dessa área podem ser usadas para a Nomenclatura Plana em ICN. Um problema com a Nomenclatura Plana é a impossibilidade de agregar nomes em prefixos, uma vez que as chaves são geradas de forma independente, gerando um desafio para o uso desses nomes com o roteamento hierárquico, que será discutido adiante.
   • Nomenclatura Hierárquica
     Ao concatenar strings que representam características do conteúdo em seus nomes, a Nomenclatura Hierárquica difere muito da Nomenclatura Plana e sua aparência aleatória. Os nomes hierárquicos refletem a natureza do conteúdo e são mais amigáveis ao usuário. Os nomes podem apresentar estruturas parecidas com URIs (Uniform Resources Identifiers). É possível que um usuário consiga construir o nome para o conteúdo de interesse sem que haja, a priori, informações sobre tal nome ou o conteúdo em si. Os nomes hierárquicos podem ser agregados de acordo com seus prefixos (que podem ser relacionados à propriedade, versionamento, formato etc.), utilizando soluções já conhecidas em protocolos de roteamento IP. Uma desvantagem deste método é a sua fraca persistência, uma vez que mudanças aplicadas ao conteúdo, como uma transferência de propriedade, tornariam o nome incorreto.
   • Nomenclatura Baseada em Atributos
     Ao contrário dos métodos descritos anteriormente, a Nomenclatura Baseada em Atributos não se compromete em identificar unicamente cada conteúdo. Em vez disso, o objetivo é classificar os conteúdos atribuindo-os pares chave-valor. O conteúdo pode ser acessado através da escolha de parâmetros aos quais o conteúdo deve atender, de acordo com os pares chave-valor correspondentes. Essa característica torna possível a busca de conteúdo diretamente pela infraestrutura da rede, sem necessidade de aplicações externas. Como o conteúdo não é explicitamente nomeado, os acessos podem retornar um grande número de conteúdos que atendem aos critérios especificados, potencialmente usando a rede de modo ineficiente.

2. Roteamento Baseado em Nomes

   O Roteamento nas ICNs deve ser capaz de servir conteúdo sem que um servidor seja especificado pelo usuário. Assim, os pacotes devem ser endereçados aos nomes desses conteúdos. Para que isso funcione de forma robusta e escalável, existem mecanismos que definem como a informação de roteamento é usada pela rede e como ela é armazenada. Eles estão divididos em dois grupos principais:
   
   

   • Roteamento Não-Hierárquico
     Neste mecanismo, não há um nó central para armazenar informações de roteamento. Cada nó é capaz de calcular qual é a melhor rota para acessar o conteúdo desejado. Os protocolos de roteamento da Internet atual são, em geral, não-hierárquicos. Sendo assim, a maior parte dos problemas encontrados neste tipo de mecanismo já vem sendo amplamente discutida ao longo dos anos e as soluções podem ser aplicadas às ICNs. Roteamento Hierárquico
   • Roteamento Hierárquico
     Neste mecanismo, os roteadores são conectados de forma hierárquica, assegurando a redução de informação de controle necessária em cada nó. Em ICN, há dois tipos principais de Roteamento Hierárquico:
     • Arquitetura em Árvore
       Esta topologia utiliza conceitos como afiliação, paridade, superioridade e inferioridade para determinar o fluxo de dados no roteamento hierárquico. Podem ser definidos nós como “pais”, “filhos” e “irmãos”. Os pais concentram toda a informação de seus filhos, agindo como portões para diminuir a carga de roteamento para toda a sub-árvore correspondente. Sendo assim, os pais acabam sendo um possível ponto único de falha, arriscando a conectividade de toda sua sub-árvore em caso de falha.
     • Arquitetura em DHT (direct hash tables)
       DHTs são estruturas adotadas para distribuição de hashes criptográficas. Esta topologia garante que a carga de processamento e caching das sub-árvores fique distribuída entre os filhos participantes, evitando o ponto único de falha da arquitetura em árvore. Desta forma, os níveis superiores são formados como uma fusão dos níveis inferiores.

3. Cache em ICN

   Em redes tradicionais, em que alguns poucos distribuidores fornecem conteúdo muito requisitado, a tecnologia de caching representa uma grande economia no tráfego de dados, melhorando a qualidade do serviço.
   
   Em redes ICN, o caching representa um desafio. Roteadores de conteúdo podem ser usados para armazenar em memória os conteúdos acessados com mais frequência, estabelecendo uma rede de chaching. Este sistema acaba distribuindo cópias do conteúdo para nós distantes de suas origens, mais próximas dos usuários finais. Esta disposição do conteúdo acaba aumentando a complexidade do roteamento, exigindo soluções protocolares para esse problema.

1. CBN

   Content-based networking ( CBN ) é uma implementação da ICN que se baseia no sistema de publish/subscribe. Cada nó define seu interesse em receber mensagens baseado no predicado do receptor. As mensagens são baseadas em nomenclatura baseada em atributos. E o predicado do receptor são geralmente filtros construídos com relações booleanas referente a essas nomenclatura baseada em atributos. Quando uma mensagem é publicada essa mensagem deve ser enviada para todos os receptores com predicados que coincidam com a mensagem publicada. Se por exemplo uma mensagem do tipo : [ situação = ‘emergência’, preço = ‘20’], fosse publicada. Então ela seria enviada para um predicado do tipo: [ situação =’em aberto’, preço >10]. As tabelas de roteamento são formadas por uma camada broadcast e por um protocolo de roteamento baseado em conteúdo. A camada broadcast funciona como já se é conhecido, sem nenhuma ou quase nenhuma diferença. Essa camada será responsável por evitar qualquer loop. A camada de broadcast será usada para passar informações de controle entre os roteadores. Será usada também para garantir a possibilidade de qualquer roteador receber uma mensagem. O protocolo de roteamento baseado em conteúdo vai usar o broadcast e seu algoritmo responsável por não haver loop para transferir uma mensagem para os roteadores interessados, ou seja, os roteadores com predicados correspondentes. O protocolo de roteamento baseado em conteúdo funciona com duas funções: RA e SR. O Receiver Advertisement (RA) é enviado pelos nós para avisar aos possíveis fornecedores de conteúdo seus predicados. Enquanto o Sender Request (SR) são usados para atualizar as tabelas de roteamento. OS SRs são enviados em broadcast e obtém como resposta Update Replies (URs) dos nós. Nos URs são enviados como resposta ao SR os predicados de cada interface dos receptores do SR.

2. DONA

   A arquitetura Data-Oriented Network Arquiteture ou simplesmente DONA é uma das precursoras a utilizar os componentes básicos do paradigma ICN, e a propõe a adoção desse paradigma como uma camada sobre o protocolo IP. Essa arquitetura baseia-se em ideias inovadoras para a nomeação e localização de conteúdos visando a distribuição confiável dos conteúdos de uma rede hierárquica. Utilizando-se de nomes planos e auto certificadores, é possível propiciar persistência e autenticidade dos dados. Para a formação dos nomes em DONA, destaca-se a associação entre uma entidade geradora dos nomes e um par de chaves publico-privadas. Sendo assim algumas deficiências do protocolo IP ainda estão presentes, não dispondo de todos os benefícios que a ICN oferece.

3. CCN

   A implementação CCN busca trazer a simplicidade e as poucas exigências sobre a camada de baixo que faz do TCP/IP tão bem sucedido. Além disso o CCN pode ser implementado acima da própria camada IP. Existem dois tipos de pacotes no modelo CCN. O pacote de interesse e o pacote de dados. Um usuário que deseja um dado envia em broadcast um pacote de interesse. Qualquer roteador que tenhas os dados relativos a esse pacote responderá com os dados. Quando o roteador responde com os dados, ele “consome” o pacote de interesse, criando uma relação de um para um semelhante ao ACK do TCP. Controlando assim a vazão. Os roteadores no modelo CCN tem 3 estruturas para o encaminhamento de pacotes, são elas: o Content Store, Forwarding Information Base e Pending Interest Table. O Contente Store é um buffer de memória, grande o suficiente para “cachear” os dados que serão encaminhados. O Forwarding Information Base é usado para reencaminhar pacotes de interesse para possíveis detentores de dados. Ele permite que exista mais de uma saída de interface. O Pending Interest Table é uma tabela para registrar de onde vieram os pacotes de interesse. Quando chega um pacote de interesse no roteador ele primeiro checa se existe um pacote de dados correspondente, se houver ele responderá com o pacote de dados pela interface que chegou o pacote de interesse. Em seguida irá descartar o pacote de interesse considerando que este foi satisfeito. Caso o roteador não possua o dado e já tenha um pacote de interesse equivalente no Pending Interest Table (PIT), o pacote de interesse é descartado e a interface de onde chegou o pacote será adicionada ao PIT. E se não houver um pacote equivalente no PIT, então o roteador usará o Forwarding Information Base para encaminhar a outros roteadores o pacote de interesse e adicionará a fonte do pacote de interesse ao PIT. Assim, até achar um roteador que possua o dado requisitado no pacote de interesse, esse pacote será passado adiante. E quando encontrar os dados requisitados, o pacote de dados será enviado reversamente pelos PITs que trouxeram o pacote de interesse até o roteador que possuía os dados até chegar ao usuário que fez o pedido dos dados.

4. PSIRP

   Publish-Subscribe Internet Routing Paradigm é uma arquitetura fortemente baseada no modelo Publish-Subscribe que foge do padrão das outras topologias pois não necessita de conectividade. O PSIRP usa o conceito de rendezvouz para resolução de nomes. As publicações de conteúdos são feitas na rede rendezvous que é responsável por associar dados aos “subscribers”.

5. CONET

CONET é um sistema que interconecta CONET Sub Systems (CSSs). Nesses CSSs existem os CONET nodes e uma estrutura under-CONET. Esses CSSs podem ser alguns nós interconectados com ligações do tipo PPP ou UDP/IP. Podem ser uma conexão de camada 2 do tipo Ethernet. Podem ser uma conexão do tipo camada 3 IPv4 ou IPv6. CSSs podem ser definidos de forma bem livre. Se, por exemplo, os CSSs fossem implementados em cima dos equipamentos finais. Então teríamos um único CSS que seria a própria internet. Se, por outro lado, os protocolos CONET fossem implementados em cima da rede de borda, CSS coincidiria com os Sistemas Autônomos.

1. Nomeação

   É consenso que o sistema de nomenclatura em ICN deve oferecer independência de locação, segurança, escalabilidade, singularidade e facilidade de uso humano. Na prática, não há uma solução que possibilite todas essas propriedades.
   
   Na nomenclatura plana, os nomes são singulares em relação aos conteúdos, mas não apresentam nenhum valor semântico, o que dificulta o uso humano e a organização hierárquica dos dados, acarretando problemas de escalabilidade devido à complexidade das tabelas de roteamento. Uma solução parcial para esse problema é a concatenação explícita de nomes planos da forma nome-1.nome-2.nome-3...nome-n, em que cada nome-i isoladamente é um nome plano. Desta forma, os nomes planos poderiam ser usados para representar conteúdo estruturado. Por exemplo, se o nome1 representar uma instituição, nome2 representar um setor desta instituição e nome3 representar um arquivo específico, e assim por diante, teremos uma espécie de hierarquia virtual. Esse tipo de hierarquia é considerado mais flexível que a nomenclatura hierárquica em si, uma vez que uma parte do nome com valor hierárquico mais baixo, como nome3, pode ser parte de diferentes nomes concatenados, tornando mais fácil a busca por rotas.
   
   Na nomenclatura hierárquica, temos a situação oposta. As tabelas de roteamento são menores, mas não é possível garantir a singularidade, pois os nomes são relacionados às propriedades do conteúdo em si, que podem mudar. Normalmente, nomes planos são usados para certificar a autenticidade, persistência e singularidade mesmo na nomenclatura hierárquica. Problemas de singularidade também podem existir quando são usados nomes planos gerados à partir da chave pública de um proprietário de conteúdo, já que os nomes mudam se o proprietário do conteúdo mudar. Sendo assim, é um desafio encontrar maneiras de tornar tais nomes persistentes. Uma solução é trabalhar com um chave pública do conteúdo em si, que é transferida quando há uma mudança de proprietários. Outra solução é gerar um novo par de chaves pública e privada para o novo proprietário, autorizadas pelo par anterior, mas usá-las apenas para assinar os pacotes através de metadados, mantendo o nome original do conteúdo.
   
   Os nomes planos, mesmo, na nomenclatura hierárquica, não são amigáveis ao usuário. Assim, são usados mecanismos externos para mapear esses nomes à identificadores de uso mais fácil, como motores de busca e sistemas de recomendação.
   
   Sistemas como DNS e DHT simples não suportariam os sistemas de nomenclatura apresentados para ICN sem latência na escala da Internet. Uma solução é usar MDHT, sistemas DHT interconectados onde cada um representa a rede em um nível topológico diferente. 3 níveis são considerados: ASs (Autonomous Systems), POPs (Points of Presence) e ANs (Access Nodes). No nível mais baixo, das ANs, o funcionamento é similar ao de um DNS local, em que são recebidas requisições por nome de conteúdo diretamente do cliente.
   
   Um desafio de implementação da nomenclatura em ICN é tornar a migração dos protocolos da internet atual mais suave. Algumas soluções, como a ICN-HTTP, se preocupam em manter retrocompatibilidade da ICN com a infraestrutura existente de HTTP, preservando soluções atuais de roteamento, caching e aplicações. Nela, a ideia é tornar o HTTP um protocolo independente de locação, através de um novo identificador auto-certificado chamado Secure-Name, usado para rotear o conteúdo pedido através de um nome.
   
   Não há consenso sobre qual das soluções apresentadas é mais viável, o que faz do avanço dos mecanismos de nomenclatura ICN um desafio atualmente relevante para sua implementação.

2. Roteamento

   O roteamento num modelo de rede baseado em ICN resultaria em mudanças nos roteadores. Hoje em dia eles enviam pacotes adiantes e montam tabelas de roteamento. Devemos ter em mente que no modelo ICN os roteadores devem ter em cache conteúdos para transmitir direto ao usuário final. Desse modo, seria necessário que os roteadores fossem capazes de organizar seus caches, enviar conteúdos para os usuários finais e também administrar os conteúdos que devem ser colocados ou retirados do cache pela frequência ao qual são acessados. Essas mudanças nos roteadores exigem que sejam mudados hardware e software dos roteadores para que possam se adaptar à essas necessidades de roteamento.

3. Armazenamento em Cache

   Como no modelo ICN os dados devem ser cacheados nos roteadores. Armazenamento se torna um fator fundamental. Tanto quanta memória se deve ter, com quanta velocidade. Quais memórias são mais custosas e quantas gastam mais energia. Tudo isso deve ser levado em conta, considerando uma otimização dos roteadores para fazer o modelo ICN realmente eficiente.

4. Segurança

   Diferentemente do sistema atual, na CCN deve-se assegurar a integridade de um conteúdo independente de sua localização, tendo em vista que um conteudo pode ser alocado tanto na fonte, como em qualquer nó da rede. Essa característica das CCNs garante maior facilidade na autenticação de conteúdo já que descarta a necessidade de garantir a segurança de diversos componentes na infraestrutura da rede, como verificar se o servidor DNS e o repositório de conteúdos sao confiáveis, se o canal que transmitiu é seguro, etc. Dentre os desafios enfrentados para a implementação de modelos de segurança, destacam-se a verificação da integridade do documento, a proveniência do conteúdo e a relevância do conteúdo obtido em relação ao requisitado. Apesar de ainda haver um mistério acerca de qual melhor modelo para garantir a segurança nas redes orientadas a conteúdo, alguns envolvidos defendem o modelo de nomeação hierárquico enquanto outros defendem o modelo de nomes auto certificados. A auto certificação dos nomes consiste em gerar uma operação criptográfica com o próprio conteúdo que permita a correspondência entre conteúdos e seus nomes. A construção dos nomes pode ser feita por chave criptográfica, para conteúdos mutáveis, bem como por hash. Para conteúdos estáticos, seria necessário calcular o hash do conteúdo e comparar com o resultado do mesmo, ou seja, se um conteúdo for alterado na rede ou no caminho ate o consumidor, seria fácil a detecção pelo usuário. Contudo, a utilização de hash não garante que a proveniência da informação seja de confiança, pois os conteúdos não são assinados. Já os nomes verificados por chave, possuem uma forte ligação entre o conteúdo e seu nome pois eles são formados pelo hash da chave publica do publicador, garantindo assim a integridade dos dados. Alem disso, a verificação dos nomes por chave criptográfica assegura a proveniência do conteúdo com base na verificação de sua assinatura digital. A verificação da assinatura digital é possível obtendo a chave publica do publicador e comparando o hash dessa chave com o nome do conteúdo. Já que uma função hash aplicada a conteúdos diferentes jamais produzira um resultado igual, é importante ressaltar que a unicidade dos nomes é global. Sendo esse sistema de identificação dos conteúdos ilegível para humanos, é bastante improvável que alguém seja capaz de memorizar ou compreender esses nomes. Dessa forma, torna-se necessária a utilização de um mecanismo para tradução dos nomes, oque faz com que seja anulada a segurança provida por nomes autenticados. Ainda em relação a nomeação, destaca-se a falta de privacidade dos usuários, uma vez que a requisição de conteúdos é acessada diretamente pelo roteador, basta que um dos roteadores da rede esteja comprometido para que a monitoração dos pedidos enviados a rede seja possível por alguém mal intencionado. A poluição dos caches da rede também é um problema a ser enfrentado, pois enviando pedidos de conteúdo aleatório ou mesmo de conteúdo falso, pode alterar a popularidade dos conteúdos, provocando o armazenamento de conteúdos pouco populares nos cachês ou entao poluindo os cachês que estão fora do universo de conteúdos validos. Dessa forma, por mais que a implementação de redes orientadas a conteúdo não necessite da confiança de toda a infraestrutura envolvida na obtenção de dados, a segurança nas CCNs ainda é uma questão com pontos em aberto.

5. Modelo Econômico

   Um dos principais problemas para a implementação da ICN é o modelo econômico. Com o modelo econômico atual da internet, ISPs locais dão acesso aos usuários finais . Além de prover o serviço para os usuários finais, eles têm que gerenciar a conexão entre outros provedores . E com isso qualquer mudança que se deseja fazer nos paradigmas da internet, enfrenta a barreira de ter que atualizar esse modelo econômico. A ideia para poder mudar paradigmas da internet seria possibilitar que outro tipo de modelo econômico fosse estabelecido. Provedores seriam divididos entre provedores de serviços e provedores de infraestrutura. Em um modelo ICN os custos seriam menores para transmissão de dados, porém haveria uma necessidade maior de armazenamento na internet. O que atualmente seria favorável. Pois os preços para a transmissão de dados custam mais do que o armazenamento. O sucesso das CDNs mostra que serviços alternativos na rede têm ganhado mais popularidade.Abrindo portas para modelos diferentes que se adaptem melhor aos necessários para a implementação da ICN.

A aceitação do modelo ICN está atrelada à eficiência dele com aplicações em tempo real. Cada vez mais popular essas aplicações, é necessário que o modelo consiga aceitar, no mínimo, uma adaptação do mecanismo atual de funcionamento dessas aplicações em tempo real. O ideal seria a capacidade de criar um mecanismo específico que fosse otimizado para o modelo ICN.

1. Aplicações em Tempo Real

A principal aplicação em tempo real é a VoCCN. Que é um modelo análogo ao VoIP voltado para CCN. Para conseguir fazer funcionar o VoCCN, é necessário implementar um modelo de publicação e inscrição. Primeiro faz-se a inscrição em uma publicação que ainda não existe. Com a criação da publicação, cria-se a chamada. Como o formato é feito de forma diferente, é necessário que seja um modelo de publicação e inscrição que permita isso. Para que a comunicação seja continuada, é necessário um algoritmo capaz de fazer a transmissão de dados do publicador para o inscrito. É relevante reparar que o VoCCN é implementado usando uma conversão entre CCN e IP, além dos protocolos SIP e RTP. Dessa forma, é compatível com as aplicações atuais. Além do VoCCN, existem o VoPSI que é compatível com PSIRP e o ACT que é uma extensão do VoCCN.

2. Aplicações em Automóveis

A rede aplicada para automóveis tem vários problemas para superar. Cada carro em movimento extrapola a normalidade variando a localização rapidamente. Isso faz com que a conexão não seja tão estável. Tanto a comunicação entre carros como a comunicação com as estruturas da internet tornam-se diferente do usual. Nesse caso torna-se atraente um modelo ICN. Temos uma conexão que depende da localização e do tempo ( informações de trânsito, acidentes, locais de interesse…). E muitas vezes deseja-se informar um número de veículos numa certa área num dado momento, independente de seus endereços IPs. É também um fator positivo o “cacheamento” das informações nos nós. Como os carros são nós em movimento, estes podem com informações em cache passar para outros veículos que estiverem sem conexão por algum tempo, atualizando esses carros.

3. Streaming

Hoje em dia os serviços de streaming representam uma grande fatia da internet. Serviços como Netflix, Youtube, Hulu, entre outros. Atualmente o serviço de streaming é geralmente feito com DASH, Dynamic Adaptive Streaming over HTTP. Uma das ideias do Streaming associada a ICN é usando o DASH em cima do CCN. Uma das formas de fazer busca transformar os requests do HTTP em um pacote de interesse correspondente. Assim sendo uma resposta HTTP se tornaria um pacote de dados correspondente. Isso facilitaria a aplicação de CCN numa rede existente podendo manter alguma estrutura.

4. Cenários de Desastre

Como as ICNs não dependem da disponibilidade de servidores específicos para prover conteúdo, aplicações voltadas para cenários de desastre podem ser desenvolvidas considerando a possível indisponibilidade de servidores importantes nessas situações. Além disso, o caching nos roteadores ICN ajuda a distribuir melhor os dados e descongestionar a rede em cenários deste tipo.

O tráfego gerado por distribuição de conteúdo representa mais que a metade de todo o tráfego na internet. A arquitetura atual impõe barreiras técnicas ao desenvolvimento de novas aplicações voltadas à distribuição de conteúdo, e aquelas que já estão em uso, como P2P e CDN, não conversam entre si para otimizar a distribuição de conteúdo. As ICNs são uma alternativa capaz de distribuir conteúdo de forma mais eficaz de forma intrínseca. Os estudos atuais focam em novas propostas de implementação e políticas de caching. Ainda não existem iniciativas para prover interoperabilidade entre diferentes arquiteturas, como DONA e CCN. Há também desafios não tecnológicos, principalmente o conflito de interesses econômicos relacionados à distribuição de conteúdo. Esses desafios exigem pesquisa aprofundada, mas prometem mudar o paradigma da Internet.

1. XYLOMENOS, George; VERVERIDIS, Christopher N.; SIRIS, Vasilios A.; FOTIOU, Nikos; TSILOPOULOS, Christos; VASILAKOS, Xenofon; KATSAROS, Kostantinos V.; POLYZOS, George C. A survey of information-centric networking research. IEEE COMMUNICATIONS SURVEYS & TUTORIALS, vol. 16, no.2, pp.1024-1049, Julho 2014.

2. DOMINGUES, Guilherme; DE SOUZA E SILVA, Edmundo; LEÃO, Rosa; MENASCHÉ, Daniel S. A name resolution assisted ICN design, supported by opportunistic search, routing and caching policies. In: WORSHOP EM DESEMPENHO DE SISTEMAS COMPUTACIONAIS E DE COMUNICAÇÃO, 13., 2014, Brasília, DF. pp 1893-1904.

3. KUROSE, J. Information-centric networking: The evolution from circuits to packets to content.COMPUTER NETWORKS, vol. 66, pp.112-120, Junho 2014.

4. JANNIBELLI, Diego Vargas. Simulador para um modelo de busca oportunística de conteúdos em redes orientadas a informação. 84f. Dissertação ( Mestrado em Redes de Computadores) - Universidade Federal do Rio de Janeiro, UFRJ. Programa de Engenharia de Sistemas e Computação, PESC. 2014.

5. TORRES, João Vitor; FERRAZ, Lyno Henrique G; DUARTE, Otto C. M. B. Redes Orientadas a Conteúdo Baseadas em Controladores Hierárquicos. In: SIMPÓSIO BRASILEIRO DE REDES DE COMPUTADORES E SISTEMAS DISTRIBUÍDOS, 31. Anais pp 717-731. Brasília, DF. 2013.

6. GUIMARÃES, Pedro Henrique V.; FERRAZ, Lyno Henrique G.; TORRES, João Vitor; MATTOS, Diogo M. F.; MURILLO P., Andrés F.; ANDREONI L., Martin E.; ALVARENGA, Igor D.; RODRIGUES, Claudia S. C.; DUARTE, Otto Carlos M. B. Experimenting Content-Centric Networks in the Future Internet Testebed Environment. In: IEEE INTERNATION CONFERENCE ON COMMUNICATIONS WORKSHOPS (ICC), 2013. Budapeste, Hungária. pp 1383-1387.

7. KOPONEN, Teemu; CHAWLA, Mohit; CHUN, Byung-Gon; ERMOLINSKIY, Andrey; KIM, Kye Hyun; SHENKER, Scott; STOICA, Ion. A Data-Oriented ( and Beyond ) Network Architecture. In: ACM SIGCOMM DATA COMMUNICATION FESTIVAL, 2007. Kyoto, Japão. pp 181-192.

8. WOOD, Christopher A.; UZUN, Ersin; Flexible end-to-end content security in CCN. In: CONSUMER COMMUNICATIONS AND NETWORKING CONFERENCE (CCNC), 2014. Las Vegas, NV, USA. 8 p.

9. SUTHAR, Prakash; STOLIC, Milan; JANGAM, Anil; TROSSEN, Dirk; Native Deployment of ICN in LTE, 4G Mobile Networks. IETF. Internet-Draft. InterDigital Inc. 32 p. Setembro, 2017.

10. SEEDORF, Jan.; ARUMAITHURAI, Mayutan.; TAGAMI, Atsushi.; RAMAKRISHNAN, K. K.; MELAZZI BLEFARI, Nicola.; Research Directions for using ICN in disaster scenarios. IETF. Internet-Draft. 16 p. Julho, 2017.

11. PENTIKOUSIS, Kostas; OHLMAN, Borje; CORUJO, Daniel; BOGGIA, Gennaro; TYSON, Gareth; DAVIES, Elwyn; MOLINARO, Antonella; EUM, Suyong. Information-Centric Networking: Baseline Scenarios. RFC 7476. IETF. Internet Research Task Force (IRTF). 45 p. Março, 2015.

12. KUTSCHER, Dirk; EUM, Suyong; PENTIKOUSIS, Kostas; PSARAS, Ioannis; CORUJO, Daniel; SAUCEZ, Damien; SCHMIDT, Thomas C.; WAEHLISCH, Matthias. Information-Centric Networking (ICN) Research Challenges. RFC 7927.IETF. Internet Research Task Force (IRTF). 38 p.Julho, 2016.

13. WESTPHAL Cedric; LEDERER, Stefan; POSCH, Daniel; TIMMERER, Christian; AZGIN, Aytac; LIU, Will; MUELLER, Christopher; DETTI, Andrea; CORUJO, Daniel; WANG, Jianping; MONTPETIT, Marie-Jose; MURRAY, Niall. Adaptive Video Streaming over Information-Centric Networking(ICN). RFC 7933.IETF. Internet Research Task Force (IRTF). 36p. Agosto, 2016.

14. PENTIKOUSIS, Kostas; OHLMAN, B; DAVIES, E; SPIROU, S; BOGGIA, G; Information-Centric Networking: Evaluation and Security Considerations. RC 7945. IETF. Internet Research Task Force (IRTF). 38p. Setembro, 2016.

15. BRITO, Gabriel M.; VELLOSO, Pedro Braconnot; MORAES, Igor M.; Information-Centric Networks. A new Paradigm for the Internet. 1.ed. 2013. 122p.