Captulo 3

Arquiteturas de Rede para a

Prxima Gerao da Internet
Carlos Kamienski, Dnio Mariz, Djamel Sadok, Stnio Fernandes
Universidade Federal de Pernambuco
Centro de Informtica
Av. Professor Moraes Rego, 1235 Cidade Universitria
Recife PE Brasil
{cak, dmst, jamel, sf}@cin.ufpe.br
Resumo
Desde que a Internet alcanou dimenso global, vrias solues especficas foram adicionadas ao seu
projeto original, visando atender novas demandas e resolver problemas no previstos originalmente, de
maneira que a Internet tem evoludo como uma colcha de retalhos. Em muitos casos, as solues
adotadas violam princpios estabelecidos pela prpria concepo da Internet, aumentam sua complexidade
e exibem problemas de interoperabilidade. Isto tem acontecido porque no possvel fazer da Internet
algo para o qual ela no foi projetada. Uma vez que todos esses ajustes buscam resolver problemas
legtimos, preciso repensar a arquitetura da Internet. O principal objetivo deste trabalho apresentar os
aspectos conceituais de projeto da Internet e discutir as principais propostas da comunidade cientfica
para mudanas na sua arquitetura.
Abstract
As the Internet became a worldwide phenomenon, a number of solutions have been proposed to expand its
functionalities beyond its original design. All research proposals intend to accomplish new features and try
to solve some new issues not expected previously. For this reason, the Internet technology evolution can be
seen as a bunch of patches. In most cases, the adopted solutions violate fundamental principles that
were established formerly, increase complexity, and are not fully interoperable. In view of the fact that all
proposals try to address legitimate problems, it is imperative to rethink the current Internet architecture.
The main goal of this document is to present a conceptual view of the original Internet design and discuss
the most prominent proposals for changing its architecture from the Internet research community.
3.1. Introduo
Atualmente, a Internet utilizada por uma grande quantidade de usurios ao redor do
mundo e desempenha um papel essencial na vida das pessoas e organizaes. De fato,
para cerca de 800 milhes de pessoas, seria impensvel hoje se privar de aplicaes
como correio eletrnico, navegao da Web, sistemas de mensagens instantneas,
aplicaes de compartilhamento de arquivos, acesso a bancos, compras on-line, jogos
em rede e at mesmo telefonia (VoIP). No entanto, essa grande dependncia da rede nos
faz hoje refns da sua prpria tecnologia, ou seja, grandes transformaes no so
possveis em nome da preservao de investimentos e continuidade dos servios.
Antes de atingir esta amplitude e influncia na vida das pessoas, a Internet
nasceu pequena, projetada por acadmicos para ser uma rede em que a mudana
constante era a sua principal caracterstica. A rede era uma fonte de experincias para
transcender os limites do conhecimento sobre a capacidade dos seres humanos de
utilizar os computadores para melhorar a comunicao entre si. Por este motivo, ela
precisava ser flexvel e se reinventar constantemente. Desde que a Internet foi criada,
em 1969, vrias transformaes ocorreram. A mais drstica foi a introduo dos
protocolos TCP/IP, que s se concretizou aps cerca de 15 anos de sua existncia.
interessante ressaltar tambm que a Web e o protocolo HTTP, praticamente sinnimos
de Internet, somente foram introduzidos na dcada de 1990, portanto quando a Internet
j estava na sua maioridade. Alm disso, a Internet atual est funcionando h mais de 30
anos e est continuamente recebendo novas misses e ajustes necessrios para uma
nova categoria de servios avanados e novas tecnologias de rede.
A importncia da Internet, o ritmo acelerado do desenvolvimento de novas
tecnologias e a preservao dos investimentos e manuteno da estabilidade da rede,
geram hoje uma situao de dualidade quanto sua evoluo. Por um lado, a rede est
em constante evoluo para atender novas demandas. Essas modificaes, entretanto,
no so profundas e fazem da atual arquitetura da Internet uma colcha de retalhos. Por
outro lado, grandes transformaes so limitadas.
Este documento aborda conceitos, modelos, caractersticas, taxonomias,
problemas e desafios encontrados no projeto de novas arquiteturas para a Internet e
apresenta uma viso geral das propostas mais discutidas pela comunidade cientfica. O
objetivo incentivar o leitor a uma mudana de paradigma com relao sua
compreenso da Internet, fornecendo subsdios para expandir o discernimento sobre seu
funcionamento e princpios bsicos. De um modo mais especfico, este documento
procura auxiliar o leitor a desenvolver competncias para:
Compreender a necessidade de mudanas na arquitetura da Internet para
suportar novos servios e a complexidade inerente para sua implementao;
Identificar os princpios bsicos utilizados para o projeto e implantao da
Internet e que at hoje em dia so extensivamente usados pelos membros da
comunidade da Internet no projeto de novas tecnologias;
Identificar as principais questes de projeto da Internet, que devem ser
modificadas a fim de que ela possa evoluir para cumprir novos objetivos;
Conhecer as principais propostas da comunidade cientfica para mudanas
arquiteturais na Internet, bem como entender como elas se relacionam entre si
e seu impacto sobre a Internet atual;
Perceber as dificuldades de se promover grandes modificaes na Internet
atual, bem como ter cincia de que freqentemente novas propostas novas so
apenas propostas antigas revestidas de uma roupagem diferente.
Um aspecto importante deste documento apresentar questes conceituais de
projeto da Internet, quando muitos alunos, profissionais ou professores apenas a vem
como algo finalizado, intangvel e imutvel. Isto interessante porque quebra com
alguns paradigmas no ensino e pesquisa em redes de computadores.
Na seqncia, a seo 3.1 prossegue com a motivao para as mudanas na
arquitetura da Internet. A seo 3.2 apresenta os princpios fundamentais da Internet,
que devem se considerados ao tentar modific-la. Na seo 3.3, seis importantes
questes de projeto na Internet so identificadas e os seus problemas so relatados.
Algumas propostas de alterao da Internet so apresentadas na seo 3.4. As principais
contribuies dessas propostas so sumarizadas na seo 3.5. Finalmente, a seo 3.6
conclui o texto com as descobertas obtidas no desenvolvimento do trabalho.
3.1.1. Por que o Modelo da Internet no Evoluiu?
A Internet baseada no conceito de comutao de pacotes, inventado por Leonard
Kleinrock em 1961, e posto em prtica na Arpanet, que entrou em operao em 1969
[55]. A Internet desde o princpio foi concebida para interconectar mltiplas redes
distintas, em vez de seguir uma topologia e projeto especfico. O modelo de servio de
melhor esforo tambm sempre esteve presente, rezando para que os roteadores
encaminhem os pacotes ao seu destino da melhor maneira possvel. Se isso no for
possvel, os pacotes so descartados e possivelmente retransmitidos pelo sistema final
transmissor. Os roteadores so considerados caixas pretas, no retendo nenhuma
informao sobre os pacotes que encaminham.
Embora muitas pessoas acreditem que o conjunto de protocolos TCP/IP esteve
sempre ligado idia da Internet, eles somente foram amplamente adotados em 1983,
substituindo os antigos protocolos NCP. Isso mostra que naquela poca ela suportava
mudanas muito mais drsticas do que as que hoje se prope, como por exemplo, a
transio de IPv4 para IPv6. Por sinal, uma questo curiosa sobre TCP/IP que
primeiramente foi proposto o protocolo TCP, que inclua as funes de rede e de
transporte. Somente mais tarde ele foi dividido em TCP e IP.
Nos ltimos anos, desde que a Internet foi aberta ao uso comercial em 1993, a
sua arquitetura transformou-se de algo flexvel, projetado para sofrer mudanas, em
uma estrutura engessada, que no pode ser facilmente alterada. As razes para isso so
variadas, desde a preservao de investimentos realizados, passando pelo risco de
colapsos operacionais, at o incmodo de substituio do software em milhes de
estaes em posse dos usurios. No entanto, isso no significa que ela est parada.
Desde que a Internet alcanou dimenso global, vrias solues especficas, para
problemas no previstos e verificados sob demanda foram adicionadas ao seu projeto
original, de maneira que a Internet tem evoludo como uma colcha de retalhos. Em
outras palavras, como alteraes limpas no so possveis, vrias alteraes
pragmticas esto ocorrendo, mas que violam alguns preceitos bsicos. Um grande
exemplo a disseminao das redes com endereos internos, no roteveis na Internet.
Esses fatos refletem os problemas de evoluo nas camadas de rede e de
transporte da Internet (protocolos IP e TCP, respectivamente). Acima e abaixo, a
evoluo tem sido rpida e muitas vezes surpreendente. A camada de aplicao e
principalmente os aplicativos tm evoludo extraordinariamente desde a criao da
Internet. O correio eletrnico foi criado em 1972, a Web em 1991 e as aplicaes peer-
to-peer (p2p) [50] em 1999. Por outro lado, as tecnologias sub-IP (camadas fsica e de
enlace) tm alcanado altos ndices de atualizao. A Arpanet original era interligada
por enlaces de 56 Kbps. Atualmente, uma nica fibra tica pode comportar vrios
comprimentos de onda (usando WDM, multiplexao por diviso de comprimento de
onda), cada um com capacidade de transmitir at 10 Gbps.
3.1.2. Novos Desafios que Exigem Mudanas
A Internet atual est funcionando h mais de 30 anos e est continuamente recebendo
novas misses e ajustes necessrios para uma nova categoria de servios avanados e
novas tecnologias de rede. Portanto, novos desafios exigem mudanas e grandes
desafios freqentemente exigem grandes mudanas. Os usurios tm gerado demandas
que impulsionam a Internet a se tornar cada vez mais ubqua, mvel e sem fio. Os
sistemas celulares de terceira e quarta gerao devem obrigatoriamente ser incorporados
Internet. Certamente na sua concepo original, alta mobilidade no era um requisito
relevante, mas que hoje deve ser incorporada de maneira natural a sua arquitetura.
Por outro lado, a Internet comeou como uma rede homognea, mas atualmente
isso est cada vez mais distante de ser a norma, mas a exceo. Existem redes com
caractersticas complemente diferentes da Internet tradicional baseada em TCP/IP,
como por exemplo, redes de sensores sem fio e redes com roteamento ad-hoc. A
integrao dessas redes heterogneas um novo desafio, que deve ser considerado por
qualquer projeto de alterao na arquitetura da Internet que tenha a pretenso de
sobreviver aos novos usos e novas demandas que o futuro possa trazer.
3.2. Princpios da Arquitetura da Internet
Esta seo contempla os princpios bsicos que sempre nortearam as decises de projeto
na Internet e que ainda hoje so importantes para a sua compreenso e evoluo.
Qualquer nova proposta de arquitetura para a Internet deve levar em considerao os
sues princpios de modo a no violar principalmente aqueles que so fundamentais. Por
outro lado, quando uma proposta revolucionria for apresentada, ela deve saber
claramente quais os princpios que est violando.
3.2.1. Existe uma Arquitetura da Internet?
Muitos membros da comunidade da Internet acreditam que no h uma Arquitetura da
Internet (propriamente dita, de acordo com os conceitos OSI/ISO), mas apenas uma
tradio, que no tinha sido redigida at a RFC 1958 [6]. No entanto, normalmente
autores assumem que existe uma arquitetura, para poder compar-la com o modelo OSI.
Inclusive, relativamente bem difundido o conceito de que a a arquitetura da Internet
tem quatro camadas. Se nem os mentores da Internet tm certeza de que existe uma
arquitetura, como ela pode ter quatro camadas?
Em termos gerais, no entanto, a comunidade acredita que o principal objetivo a
conectividade, a ferramenta o protocolo IP e a inteligncia no est dentro da rede,
mas nos sistemas finais. O grande crescimento observado nos ltimos anos mostra que
na verdade a conectividade o maior resultado da Internet, que tem mais valor do que
qualquer aplicao individual, como e-mail ou Web. A chave para a conectividade
global a camada de rede (com o IP). A chave para explorar essa camada sobre diversas
tecnologias para prover a conectividade global o argumento fim a fim (seo 3.2.2).
Um sentimento da comunidade que deveria haver um nico protocolo na camada de
rede, dada a sua importncia. Na Internet, tudo se executa sobre o protocolo IP, que por
sua vez, pode executar sobre qualquer tecnologia. Existe, porm, algum interesse para
haver mais do que um protocolo, como para permitir a transio do IPv4 para o IPv6.
A evoluo da Internet depende de um consenso aproximado sobre propostas
tcnicas e cdigo executando (e estvel). A definio de consenso aproximado dada
na RFC 2418 [3], que define o modo de se chegar a um consenso a ser usado pelos
grupos de trabalhos da IETF (www.ietf.org). Por outro lado, a Internet sempre
funcionou baseada no conceito de que experincia e resultados com implementaes
reais so mais importantes de que qualquer princpio de arquitetura. O lema da IETF,
atribudo a David Clark
1
: We reject presidents, kings and voting; we believe in rough
consensus and running code" ("Ns rejeitamos presidentes, reis e votao; ns
acreditamos em consenso aproximado e cdigo executando ).
3.2.2. O Argumento Fim a Fim
A tecnologia da Internet baseada em um princpio fundamental, chamado de
argumento fim a fim [27], que determina que toda a inteligncia deve ser depositada nos
sistemas finais e a rede deve executar tarefas muito simples. Esse argumento foi
estabelecido por Salzer, Reed e Clark no incio dos anos 1980 e at hoje ele utilizado
como base para todos os tipos de alteraes que se deseja fazer na Internet. De fato, em
muitos aspectos o argumento fim a fim vem sendo gradualmente violado, devido a
mudanas pragmticas realizadas pelos provedores e fabricantes de equipamentos
(seo 3.3.5).
O argumento fim a fim sugere que as funes localizadas nos nveis inferiores de
um sistema podem ser redundantes ou de pouco valor, quando comparadas com o custo
de implement-las nesse nvel. Em geral, para serem completa e corretamente
implementadas, as funes precisam do conhecimento e ajuda dos nveis superiores, que
esto localizadas nos pontos finais de um sistema de comunicao. Algumas vezes,
verses incompletas da funo podem ser implementadas pelo sistema de comunicao
para melhorar o desempenho. Esse caso pode ser visto no controle de erros realizado
por algumas implementaes de camada de enlace de dados. Com alguns meios de
transmisso, como comunicao sem fio, til controlar os erros, mas a funo est
incompleta, pois no tem a dimenso fim a fim.
Este princpio tem conseqncias importantes na obteno de um dos principais
objetivos originais na Internet (seo 3.2.4), a sobrevivncia a falhas parciais da rede
[6]. Um projeto de protocolo fim a fim no deveria contar com a manuteno de estado
(ex: informao sobre o estado da comunicao fim a fim, como para o protocolo TCP)
1
David Clark foi diretor da IAB (Internet Architecture Board, comit especial da IETF, www.iab.org)
por vrios anos e autor de vrios artigos seminais sobre a arquitetura da Internet, como [9][10].
dentro da rede. O estado da comunicao deveria ser mantido apenas pelos sistemas
finais, de tal modo a somente poder ser destrudo caso o prprio sistema final seja
desativado. Este princpio conhecido como compartilhamento de destino (fate
sharing), porque as vrias comunicaes fim a fim compartilham do mesmo destino do
sistema final, ou seja, se a estao sai do ar abruptamente, todas as conexes so
conseqentemente interrompidas.
O trabalho do ncleo da rede transmitir pacotes da maneira mais eficiente e
flexvel possvel. Tudo o mais deveria ser feito nas bordas (sistemas finais). Em geral, o
nico tipo de informao mantido pela rede so as tabelas de roteamento. No entanto, os
roteadores aprendem as rotas dinamicamente e a sada de um roteador no deveria
causar a falha nas comunicaes, a menos que ele fosse um ponto nico de passagem de
dados.
3.2.3. O Princpio da Mudana Constante
Uma das realizaes mais notveis da Internet no necessariamente o que ela capaz
de fazer hoje, mas o fato de ter assumido as dimenses atuais, comparada aos seus
propsitos iniciais. Ela iniciou com objetivos bem modestos, no foi projetada para ser
utilizada por milhes de pessoas no mundo inteiro. Com toda certeza, o conjunto de
princpios que balizou o seu aparecimento e que hoje suporta a sua evoluo o grande
responsvel por isso. Na verdade, esses princpios tambm no so imutveis. O
princpio da mudana constante talvez seja o nico princpio da Internet que deveria
sobreviver indefinidamente [6]. Essa caracterstica permite que grandes transformaes
se acomodem naturalmente na estrutura da Internet
Os projetistas da Internet compreenderam desde o incio que a rede tinha que ser
projetada visando generalidade, a Internet deveria evoluir to rapidamente quanto a
indstria de computadores [42]. A generalidade projetada para a Internet permitiu tanto
que ela suportasse aplicaes que no foram contempladas no seu projeto original,
como tambm que admitisse novas tecnologias com diferenas drsticas em
desempenho e comportamento. A seu projeto permitiu acrscimos em capacidade nos
enlaces em muitas ordens de magnitude (ex: de 56Kbps para 10 Gbps), assim como a
incluso de tecnologias que causam certa desordem, como os novos avanos em
mobilidade. Este sucesso implica necessariamente que para continuar a evoluir a
Internet, os novos projetos devem levar as mudanas em considerao.
Solues pontuais direcionadas a fazer otimizaes puramente transitrias, que
trocam melhorias em desempenho pela perda da generalidade deveriam ser evitadas.
Esse raciocnio leva a um meta-princpio que tem um grande impacto em muitas
decises tcnicas na arquitetura da Internet [12]: evitar otimizaes no inteligentes.
Uma forma extensa : qualquer projeto envolvendo a Internet deveria favorecer a
generalidade, adaptao e evoluo, acima da eficincia e at mesmo da
funcionalidade.
Um problema mais difcil de enxergar, mas nem por isso menos importante,
ocorre quando uma determinada tecnologia se consolida no mercado. Quando isto
ocorre, natural que existam presses de vrios setores da comunidade Internet para
barrar as mudanas, por vrios motivos, como preservao de investimentos,
treinamento de pessoal e manuteno da estabilidade da rede. Nesse momento, deve
haver uma ao explcita, includa na arquitetura, que preserve a capacidade de mudar,
evoluir e avanar a tecnologia [42]. Uma conseqncia que essa ao envolve
sacrifcios em outras dimenses, como desempenho e eficincia. Infelizmente, esse
sacrifcio freqentemente resulta em custos maiores a curto prazo, para preservar
benefcios menos concretos a longo prazo. O desafio projetar uma arquitetura que
compatibilize esses dois objetivos conflitantes.
Existem, no entanto, fatores que limitam a capacidade de mudanas em uma
determinada arquitetura de rede, chamados de invariantes [43]. No caso da Internet, o
exemplo mais expressivo de invariante o endereo IP. Uma mudana simples no
formato do endereo no consegue ser facilmente acomodada, mesmo que os outros
princpios permaneam inalterados. A difcil transio para o IPv6 um exemplo
significativo do poder limitante desse invariante.
3.2.4. Objetivos de Projeto da Internet
Compreender o funcionamento da Internet e as decises que foram tomadas, passa pelo
conhecimento dos objetivos levados em considerao para a sua criao. A primeira
formalizao dos princpios foi feita por David Clark em 1988 [10]. No projeto
NewArch [12], Clark et al. redefinem estes objetivos, e acrescentam alguns novos
objetivos (ou requisitos). Esta seo se baseia na anlise realizada em NewArch. Os
objetivos primrios originais da Internet so:
1. Multiplexao: A Internet baseada em comutao de pacotes e esse objetivo
fundamental tem implicaes no resto da arquitetura. Por exemplo, o pacote
a unidade utilizada para transmisso de dados pela rede at os sistemas finais
e todas as tecnologias devem suportar pacotes. A utilizao multiplexada da
rede por sistema finais que enviam e recebem apenas pacotes algo que
deveria ser imutvel na Internet, mesmo que outras unidades de transmisso
pudessem apresentar otimizaes. A grande flexibilidade dessa abordagem
justifica a sua permanncia.
2. Sobrevivncia: A comunicao na Internet deve continuar, independente da
falha de roteadores ou redes inteiras, contando que existe algum caminho
possvel. Esse requisito foi chamado originalmente de sobrevivncia, devido
ao contexto militar da poca, mas atualmente mais conhecido como
robustez. Este requisito implica que a rede deve se adaptar dinamicamente a
falhas de hardware ou software e favorece a utilizao de protocolos que so,
de alguma forma, auto curveis.
3. Generalidade de servios: A Internet deve permitir que uma grande variedade
de tipos de aplicaes seja implantada, viabilizada atravs do suporte de tipos
diferentes de servios na camada de transporte. Dois tipos esto em utilizao
na Internet atual: um servio bidirecional de transporte confivel de bytes e
um servio de datagrama que entrega pacotes individuais sem nenhum tipo de
garantia. Os dois principais protocolos que implementam esses servios so
TCP e UDP, respectivamente.
4. Diversidade de tecnologia de sub-rede: A Internet deve acomodar e
interconectar uma grande diversidade de redes que usam caractersticas muito
diversas. Para isso, a nica suposio que o protocolo IP faz sobre a rede
subjacente que ela seja capaz de transmitir os pacotes de um lado para
outro. Ser capaz de lidar com tecnologias heterogneas foi e continua sendo
fundamental para a universalizao da Internet, alm de permitir atualizaes
tecnolgicas parciais.
Outros objetivos foram identificados originalmente, mas considerados
secundrios. Outros foram adicionados mais tarde:
5. Escalabilidade: A rede deve permitir um crescimento geral consistente,
mesmo com a constatao atual de que o nmero de sistemas finais cresce
exponencialmente.
6. Gerenciamento distribudo: Basicamente, os recursos e servios da Internet
so gerenciados de maneira distribuda. No incio, esse era apenas um
objetivo terico, porque um nico provedor tinha a concesso do backbone da
Arpanet. No entanto, desde que as redes comearam a se multiplicar, o
gerenciamento foi ficando cada vez mais distribudo, incluindo servios que
vo desde o roteamento at a resoluo de nomes (DNS).
7. Segurana: O software e hardware da rede devem suportar funes comuns
de segurana, como privacidade, integridade e autenticao. Tanto a infra-
estrutura de rede (os roteadores) quanto os sistemas finais devem se
preocupar com segurana.
8. Mobilidade: A Internet deve suportar que uma estao mude o ponto onde
est conectada com a rede dinamicamente. Um problema que vem da
mobilidade que a estao no pode permanecer com o mesmo endereo,
para que o roteamento seja escalvel (porque as rotas so anunciadas para
redes e no para estaes individuais).
9. Alocao de capacidade: Em geral, existe um consenso de que a capacidade
da rede deveria ser alocada de maneira justa (o protocolo TCP, por
exemplo, tenta fazer isso). No entanto, devido ao contexto militar havia
originalmente o requisito de suportar deliberadamente algum nvel de
injustia, atravs dos bits de precedncia do cabealho do protocolo IP
(atualmente chamados de DSField). Atualmente, vrios provedores gostariam
de poder alocar a capacidade de suas redes de maneira injusta, por uma
questo de poltica ou preo, fornecendo assim, algum tipo de Qualidade de
Servio (QoS).
Outros requisitos, embora tenham sido identificados logo no incio da Internet,
nunca foram colocados na prtica explicitamente como objetivos. Por exemplo, a
necessidade de a rede ter uma boa relao custo/benefcio nunca foi considerada, devido
ao contexto militar. Outra questo desconsiderada foi a contabilidade dos recursos
utilizados. Esses dois objetivos so atualmente bastante importantes na era da Internet
comercial. Uma rede projetada principalmente para uso comercial, certamente trocaria
de posio esses objetivos. Com toda certeza, as caractersticas da Internet atual se
devem principalmente a uma forte influncia dos quatro primeiros objetivos.
A concluso dessa discusso que qualquer nova proposta para modificar a
Internet deveria considerar os objetivos, velhos e novos, para no ter o perigo de perder
as caractersticas que fizeram o seu sucesso. Um perigo associado tornar a rede mais
complexa do que deveria. A simplicidade da Internet o tema da seo 3.2.5.
3.2.5. O Princpio da Simplicidade e o Modelo da Ampulheta
O princpio da simplicidade tem sido usado intensivamente no projeto da Internet e foi
claramente especificado na RFC 3439 [4]. Ele especifica que a complexidade o
principal mecanismo que impede a escalabilidade e causa o aumento dos custos. Alm
disso, a simplicidade proporciona robustez, porque solues complexas em geral so
mais suscetveis a erros. A espiral da robustez/complexidade/fragilidade demonstra os
efeitos do uso descontrolado da complexidade [44]. Para se obter robustez, muitas vezes
a soluo mais fcil adicionar complexidade, que por sua vez introduz novas
fragilidades, cuja soluo demanda mais complexidade.
Existem alguns conceitos relacionados com o princpio da simplicidade, como o
Occam's Razor e o princpio KISS (Keep It Simple, Stupid). O primeiro diz que a
pluralidade no deveria ser usada sem necessidade, ou seja, a complexidade deve ser
controlada. O segundo diz que ao decidir sobre a adoo de uma entre vrias solues
que resolvem o mesmo problema, deve-se escolher sempre a mais simples.
Em geral, pode-se observar que os princpios da arquitetura da Internet so inter-
relacionados e interdependentes. Por exemplo, o terceiro e quarto objetivos primrios da
Internet (seo 3.2.4) so a base de uma mxima que ficou famosa na Internet, que diz
IP sobre tudo e tudo sobre IP [44]. Essa formulao pode tambm ser considerada
uma conseqncia da aplicao do argumento fim a fim e do princpio da simplicidade,
principalmente na camada de rede. De fato, a adoo de uma camada de rede
minimalista, leva a uma analogia com uma ampulheta, onde o protocolo IP a sua
cintura fina, como mostra a Figura 3-1. Seguindo o argumento fim a fim, pode-se ver
que a camada de rede extremamente simples. A complexidade reside nos sistemas
finais, cuja funcionalidade implementada nas camadas acima do IP.
IP
TCP - UDP
Web, E-mail, Chat
udio, Vdeo, Kazaa
Ethernet, WLAN,
ATM, PPP, GPRS
Radio, Satlite,
Fibra, cobre
HTTP, SMTP, FTP
Figura 3-1 O modelo de ampulheta da Internet
A utilizao de um modelo em camadas tambm favoreceu o surgimento da
ampulheta, com um mecanismo genrico de entrega de pacotes do protocolo IP na sua
cintura. Ele proporciona uma separao crtica entre uma infra-estrutura fsica cada vez
mais verstil e que avana a passos amplos abaixo da cintura e uma demanda crescente
dos usurios por servios e aplicaes de alto nvel acima da cintura. O lema IP sobre
tudo e tudo sobre IP proporciona grande robustez a mudanas nas camadas abaixo e
acima da cintura, mas dificulta a modificao justamente no protocolo IP e tambm nos
protocolos TCP e UDP que esto logo acima dele.
3.3. Principais Questes de Projeto
Essa seo enfoca as principais questes de projeto da Internet que devem ser
consideradas no projeto de arquitetura futuras para a Internet. Algumas dessas questes
foram violadas no decorrer nos anos ou simplesmente no foram consideradas no
projeto original da Internet. As questes tratadas so endereamento/nomeao,
roteamento, segurana, mobilidade, transparncia fim a fim e modelo em camadas. Esta
categorizao foi adotada pelos autores aps anlise criteriosa de vrias propostas de
mudanas na Internet. Na bibliografia pesquisada, essas seis questes so citadas com
maior freqncia, mas outras poderiam ser includas, como Qualidade de Servio (QoS)
e difuso seletiva (multicast).
Essas questes, no entanto, no encerram modificaes estanques. Pelo
contrrio, freqentemente as questes so inter-relacionadas, ou seja, o que ocorre em
uma delas afeta outras. Um exemplo interessante a interao entre transparncia e
segurana, com relao utilizao de NAT e IPsec. A transparncia quebrada na
maioria das redes com a justificativa da segurana. Por outro lado, a quebra da
transparncia impede que, por sua vez, outras solues de segurana sejam adotadas.
3.3.1. Endereamento e Nomeao
O projeto original da Internet excluiu muitos aspectos necessrios s demandas de
servios atuais, tais como solues para mobilidade, multi-endereamento e segurana.
Conforme mencionado anteriormente, as solues propostas abordam os problemas de
maneira isolada e paliativa. Especificamente, a camada IP tem servido como base para
essas solues visto que a maioria prope sua extenso para suportar novas
funcionalidades. Por exemplo, isto torna-se bastante evidente com as propostas do IP
Mvel [25] e IPsec [21]. Alm disso, sua arquitetura original foi projetada para
basicamente prover comunicaes unicast entre ns fixos.
Uma caracterstica da camada IP que seu protocolo acopla fortemente
endereamento (localizao na rede) e identificao (identidade) em um nico atributo,
que o seu endereo IP. At ento esta uma situao aceitvel, visto que na sua
maioria os sistemas finais so estacionrios, mas torna-se um problema em redes com
alta mobilidade. Tais problemas surgem devido ao simples fato de que o endereo IP no
papel de identidade do n, no deveria ser mudado. Por outro lado, uma vez que ele
tambm descreve a localizao na rede, o endereo IP necessariamente deveria mudar
medida que o n muda seu ponto de conexo. Em [49], Moskowitz et al. argumentam
sobre a impossibilidade de se conseguir tal mudana dinmica de maneira estvel.
Segundo Eriksson et al. [14], solues como DHCP, NAT [29] e IP Mvel
sempre acarretam novos problemas e esses paliativos para mobilidade e escalabilidade
no protocolo IP tem seus limites. Desta forma, os autores argumentam a impossibilidade
de se obter, sob a estrutura atual, uma camada de rede gil, plug and play e escalvel.
Em [30], Stoica et al. argumentam que apesar da maioria destes paliativos atingirem os
objetivos desejados, outras funcionalidades no so plenamente suportadas. Por
exemplo, as propostas para multicast na camada de aplicao no atende aos requisitos
de mobilidade e vice-versa. Em [16], Francis e Gummadi expem alguns motivos da
popularidade do NAT, alm de suas vantagens e desvantagens. Um dos principais
benefcios do NAT, juntamente com a expanso do espao de endereamento do IPv4,
a separao e isolamento dos espaos de endereamento global e local. Por outro lado,
um aspecto negativo citado que sua implantao em larga escala acarreta numa maior
complexidade na construo de novas aplicaes e protocolos, visto que necessrio
levar em considerao as operaes de traduo de endereos ou portas.
Um outro aspecto importante refere-se estratgia de nomeao na Internet.
Atualmente a Internet dispe de um mecanismo nico para resoluo de nomes, o
Domain Name System (DNS), que converte nomes de domnio no nvel do usurio em
endereos IP. Conforme descrito em [1], a Web requer um servio de resoluo de
referncias (Reference Resolution Service RRS) para fazer o mapeamento das
referncias (ex: Uniform Resource Location - URL) com as suas respectivas
localizaes na rede. As referncias na Web seguem uma estrutura hostname/pathname
e o servio de DNS funciona como um RRS, mapeando o nome do sistema final para
um endereo IP, onde um determinado objeto est armazenado.
importante observar que devido ao enorme crescimento da Web observado na
ltima dcada, novas funcionalidades tornaram-se necessrias, tais como migrao e
replicao de contedo. Para este fim, provedores de contedo tm utilizado recursos
adicionais, como por exemplo as Redes de Distribuio de Contedo (Content
Distribution Network - CDN). Em linhas gerais, o objetivo de uma CDN distribuir
geograficamente um conjunto de servidores de contedo que mantm cpias de objetos
de algum servidor principal. Desta maneira, ao solicitar um objeto referenciado na Web
(no servidor original), um cliente pode receb-lo de um dos servidores da CDN. Alm
disso, a localizao geogrfica do servidor que vai fornecer o objeto pode estar mais
prxima ao cliente, de tal forma que se evite o trfego por um longo percurso pelo
ncleo da rede. Desta forma, ento possvel afirmar que o problema original de
migrao e replicao de contedo na Web no uma questo resolvida e apenas foi
mascarada atravs de recursos externos como as CDN. A caracterstica intrnseca de
uma URL no qual amarra referncias a objetos a sistemas finais especficos dificulta a
movimentao e replicao de contedo de maneira natural. Conseqentemente,
como a Web depende fortemente do DNS, restringindo sua flexibilidade, Walfish et al.
[52] argumentam que ambos sistemas se beneficiariam com uma forte mudana no
RRS, de tal forma que houvesse um desacoplamento da Web do DNS.
3.3.2. Roteamento
O servio de roteamento na Internet foi claramente um dos mais importantes na sua
especificao original, pois permitiu que um conjunto de redes heterogneas pudesse se
interconectar. Com sua expanso, seu roteamento evoluiu de uma estrutura plana para
uma organizao hierrquica, onde alguns roteadores so usados para troca de
informaes de entre grupos de redes sob mesmo domnio administrativo (Sistema
Autnomo - SA), enquanto outros so usados para troca de informaes dentro de um
mesmo SA. De maneira simplista, a classificao de sua organizao pode ser feita da
seguinte forma:
a) Roteadores Internos (Interior Routers): trocam informaes dentro de um
mesmo SA e utilizam protocolos de roteamento interno (Interior Routing
Protocols). Exemplos destes protocolos incluem o Routing Information
Protocol (RIP) e o Open Shortest Path First (OSPF);
b) Roteadores Externos (Exterior Routers): trocam informaes entre SA e
utilizam protocolos de roteamento externo (Exterior Routing Protocols),
como por exemplo o Border Gateway Protocol (BGP).
Essa estrutura organizacional de roteamento aparentemente estvel e poderia
plenamente suportar o crescimento da rede, como aquele observado na ltima dcada.
Porm, a expanso da rede vem acompanhada pela demanda por novos servios que
implicam em modificaes na arquitetura de roteamento.
Neste ponto, vale a pena enfatizar que o termo arquitetura de roteamento no
refere-se nica e diretamente a protocolos de roteamento (ex: RIP, OSPF ou BGP). Uma
arquitetura de roteamento leva em considerao a maneira como a rede trata o trfego
do usurio. Desta forma, uma arquitetura de roteamento consiste basicamente:
a) das tcnicas de troca de informao entre seus elementos;
b) dos algoritmos de cmputo e seleo dos caminhos entre as entidades
participantes, e;
c) na forma de encaminhamento do trfego.
Em linhas gerais, a atual arquitetura de roteamento na Internet baseia-se em
algoritmos Vetor-Distncia
2
(Distance Vector DV) para a troca de informao das
tabelas de roteamento e no encaminhamento do tipo salto a salto (hop-by-hop). Este
modelo tem sido criticado por impor restries em relao a escalabilidade da rede para
acomodar novas funcionalidades [32][8][26][33]. Em [32], Castineyra et al.
argumentam que uma srie de fatores, incluindo avanos tecnolgicos e demandas
econmicas, determinam a evoluo da rede. Desta forma, os autores listam uma srie
de restries, caractersticas e requisitos que tm implicaes diretas nas arquiteturas de
roteamento. Dentre as mais importantes, pode-se citar:
a) diferentes tipos de enlaces de comunicao compem a rede, tais como enlaces
fixos, pticos, sem fio, satlite com diferentes caractersticas em termos de
atraso, taxas de erro, vazo etc.;
b) seus elementos, tais como redes, roteadores, sistemas finais e processos, podem
ser mveis;
c) Usurios podem especificar os requisitos de trfego que podem variar entre
sesses;
d) Provedores de Servios (ISP) e usurios mantm uma relao intrnseca, de tal
forma que medida que os usurios desenvolvem aplicaes mais complexas
com requisitos especiais, os provedores de servios tentam atender estas novas
demandas. Reciprocamente, medida que os provedores implantam novos
servios, os usurios desenvolvem aplicaes que os utilizam plenamente. Vale
salientar que ISPs so mais resistentes implantao de protocolos complexos
em suas redes, devido suas inerentes dificuldades de gerenciamento.
Em linhas gerais, estas caractersticas apontam que uma arquitetura de
roteamento adequada deveria suportar recursos especiais (ex: roteamento especfico por
servio ou suporte mobilidade) usando procedimentos simples que consumam
2
Apesar dos protocolos OSPF e IS-IS usarem algoritmos de Estado de Enlace, sua implantao limitada
em algumas partes da rede.
quantidades mnimas de recursos. Especificamente, a arquitetura de roteamento atual da
Internet exibe alguns problemas, listados a seguir.
a) No nvel de Sistemas Autnomos (domnio), usurios podem escolher seu
provedor de servio (ISP), mas uma vez que seu trfego entra na rede, eles no
tm controle sobre as rotas que os pacotes devem fluir. As rotas selecionadas
pelos ISPs so baseadas em decises econmicas (ex: acordo entre pares) e
tecnicamente implementadas sob roteamento BGP. Em [32], Yang considera que
tal modelo, onde no se fornece controle do roteamento para o usurio, no
promove um nvel adequado de competio de mercado. Seu principal
argumento baseia-se no fato de que a escolha do roteamento pelo usurio no
nvel de domnios ir impor uma disciplina econmica no mercado e promover
inovao e introduo de novos servios na rede. Guardadas as devidas
diferenas, o processo poderia ser similar ao atual provimento de servios
telefnicos, no qual, o usurio pode escolher o seu provedor de servios de longa
distncia, independentemente do provedor de servios locais.
b) Roteamento e filtragem de pacotes (ex: por firewall) so tratados
separadamente, apesar da explcita relao entre eles. No existe um modelo
unificado de segurana e roteamento que trate coerentemente onde existe
permisso de fluxo de pacotes (segurana) e por onde eles devem ser enviados
(roteamento) [26].
c) Apesar de no ser um problema de arquitetura e sim especfico de protocolo, o
BGP tem diversos problemas apontados recentemente. Primeiramente, o
crescimento da Internet tem acarretado problemas de escalabilidade [23],
instabilidade [28] e convergncia [22] nos roteadores com BGP. Alm disso,
problemas de segurana podem surgir em roteadores mal configurados [19].
Desta forma, algumas solues propostas requerem mudanas na arquitetura de
roteamento atual.
3.3.3. Segurana
A Internet no foi projetada pensando em segurana. As especificaes dos protocolos
TCP e IP, considerados os mais importantes protocolos da Internet, foram concludas
pelo IETF no incio dos anos 80. Desde ento, a Internet evoluiu de um projeto
especializado conectando alguns milhares de usurios para uma ferramenta de propsito
geral e de escopo global que conecta atualmente cerca de 800 milhes de usurios [34].
Embora seu crescimento tenha trazido solues para vrias reas, ele tambm
responsvel por alguns problemas de segurana. Na verdade muitas das caractersticas
da Internet que hoje so entendidas como vulnerabilidades j existiam nos primrdios
da Internet, mas as ameaas eram poucas e, portanto as vulnerabilidades no eram
exploradas na escala atualmente observada. Como a Internet era pequena, os usurios
podiam confiar uns nos outros, at porque eles tambm dependiam uns dos outros.
Assim, os problemas de segurana praticamente no existiam. Em geral, uma
vulnerabilidade uma caracterstica (imperfeio ou falha) que pode ser explorada por
um atacante para conduzir um ataque [35]. Um ataque uma ao ou tentativa de violar
uma poltica de segurana ou causar danos a um sistema.
Considerando a Internet em geral, as vulnerabilidades podem existir em
aplicaes e nos protocolos de comunicao e podem ser originadas por falhas de
projeto, de implementao ou de configurao [36]. O conjunto de todas essas
vulnerabilidades compe as causas dos problemas de segurana existentes na Internet,
mas no necessariamente todos so causados por falha dos protocolos usados para dar
suporte rede. Visando distinguir quais das vulnerabilidades podem ser atribudas a
deficincias arquiteturais da Internet, analisamos neste trabalho apenas as
vulnerabilidades que so causadas pela Internet, deixando de lado aquelas que so
exploradas com o uso da Internet, tais como: Ataques de buffer overflow (falha na
implementao de aplicaes), Ataque ping da morte e Ataque de fragmentao
IP (falhas na implementao do protocolo IP), entre outros.
Problemas no Protocolo IP
Uma caracterstica chave da Internet que qualquer aplicao pode mandar qualquer
coisa para qualquer um a qualquer momento, sem a necessidade de obter permisso
[37]. Por um lado isso bom por garantir que a Internet "aberta", ou seja, facilita que
novas aplicaes sejam projetadas, implementadas e disseminadas rapidamente, sem ter
que aguardar que novas caractersticas sejam adicionadas rede. Mas, por outro lado,
essa caracterstica pode ser explorada para a conduo de um tipo de ataques
considerado como dos mais difceis de combater na Internet: os ataques de Negao de
Servio (Denial of Service - DoS) ou Negao de Servio Distribuda (Distributed
Denial of Service DDoS) [38].
Os ataques de DoS podem ser dirigidos aos sistemas finais [39] ou infra-
estrutura de rede, com o intuito de causar a) a parada ou a reduo da capacidade de um
servio; b) a exausto de recursos de CPU; ou c) a exausto da vazo de enlaces da
rede. Um ataque de DoS distribudo (DDoS) quando um usurio primeiro compromete
um estao (conhecida como "zumbi") e a utiliza remotamente para atacar outras
estaes. Em um DDoS, vrios "zumbis" so envolvidos formar um exrcito e so
coordenados para agirem de forma simultnea, enviando pacotes ilegais (ex: checksum
incorreto, fragmentao invlida) ou mesmo legais (TCP SYN, ICMP echo request etc)
para uma estao vtima, na tentativa de exaurir os seus recursos e for-lo a uma
condio de negao de servio aos seus clientes legtimos.
A Internet, portanto, vulnervel a ataques de DoS e qualquer estao (ou
conjunto de estaes) com suficiente largura de banda pode interromper uma conexo
ou parar um servio simplesmente enviando uma inundao de pacotes no solicitados.
Ataques de DoS so freqentes, alcanam escala global e so muito difceis de rastrear,
porque usam a tcnica de spoofing e dificilmente podem ser filtrados sem atrapalhar o
trfego legtimo [38].
Problemas no Protocolo TCP
O TCP amplamente implementado e o protocolo fim-a-fim para transferncia de dados
confivel mais usado na Internet. Quando foi especificado h mais de 20 anos, a
Internet, com a conhecemos hoje, era muito diferente e muitas das ameaas hoje
conhecidas no eram comuns. Assim, o TCP no incorporou mecanismos de segurana
suficientes para lidar com as ameaas a que est sujeito atualmente.
Recentemente algumas srias ameaas foram descritas, as quais abrem espao
para ataques de DoS e "injeo de dados" [40]. Esses ataques podem ser conduzidos de
forma "cega" (blind attack) pelo atacante, ou seja, o atacante no precisa
necessariamente capturar o trfego entre as vtimas: ele apenas precisa "adivinhar"
algumas informaes.
Um ataque ao TCP conhecido como "blind reset" [40] pode ser conduzido da
seguinte forma. A RFC793 dita que o no recebimento de um RST em uma conexo
estabelecida, se o nmero de seqncia est dentro do intervalo esperado (ou seja, um
segmento aceitvel dentro da janela anunciada pelo receptor) ento o receptor deve
encerrar a conexo. Do contrrio, o segmento recebido descartado. Assim, basta que
um atacante adivinhe um nmero de seqncia compreendido entre o ltimo segmento
reconhecido pelo receptor mais a metade do tamanho da janela do receptor, o que no
to difcil, como discutido em [40].
Um outro ataque similar descrito em [40] o blind data injection (injeo de
dados cega), que consiste em submeter um segmento aceitvel para o receptor, de forma
semelhante ao um blind reset, mas desta vez contendo dados ao invs de um RST. Isso
faz com que o receptor admita o segmento em sua fila de remontagem e, caso este
segmento esteja fora de ordem, ele repassado para a camada superior depois que o
emissor complete o envio dos dados que preenchem o espao vazio. A insero de
dados esprios usando esta tcnica leva corrupo dos dados recebidos pela aplicao.
As implicaes das vulnerabilidades no TCP so diversas e se estendem aos
servios que dele se utilizam. Por exemplo, o protocolo BGP, usado por roteadores para
troca de informaes de roteamento entre domnios autnomos da Internet, estabelece
conexes TCP de longa durao para o envio confivel de dados. Se uma sesso BGP
interrompida, ela pode causar pequenos intervalos de parada para re-conexo, o que
pode ter algum impacto dependendo do tamanho da tabela de rotas e a freqncia do
ataque. Embora no tenha sido ainda reportado, cogita-se ser possvel injetar rotas falsas
atravs de um ataque "blind data injection" em conexes BGP, o que pode ser resultar
em um DoS.
3.3.4. Mobilidade
Quando o TCP/IP foi projetado, computadores no eram portteis como atualmente e,
portanto, a mobilidade no foi levada em considerao. Como a necessidade crescente
de dar suporte mobilidade, o IETF criou o "Grupo de Trabalho IP Mvel" (Mobile IP
Working Group MIPWG) para estudar solues para permitir que estaes mveis
pudessem usar, de forma transparente, o mesmo nmero IP da sua rede original
enquanto se moviam por outras subredes. Os principais requisitos impostos ao MIPWG
exigiam uma soluo: a) que no modificasse o TCP/IP de estaes fixas; b) onde as
estaes mveis interoperassem com as estaes fixas; c) em que a mobilidade fosse
transparente e pudessem preservar conexes em andamento; d) escalvel; e e) segura.
Em 1996, Perkins et al. publicaram a primeira proposta consistente para o
MIPv4 na RFC 2002, que foi depois revisada e atualizada pela RFC 3220 e finalmente
pela RFC 3344 [45]. Considerando os requisitos, a soluo proposta pelo IETF e
adotada pela comunidade foi de fato elegante e aceitvel. Basicamente, ela exige
mudanas apenas na implementao dos protocolos IP e ICMP da "estao mvel" e a
criao de dois agentes (tipicamente implementados em roteadores): o "home agent" (na
rede original da estao mvel) e o "foreign agent" (na rede estrangeira visitada). O IP
mvel, portanto, estar disponvel apenas nas redes que implementem essas
funcionalidades.
Apesar de trazer mobilidade Internet, alguns problemas ainda no foram
completamente resolvidos pelo IP Mvel. O primeiro deles que o IP mvel usa
tunelamento para comunicao entre o "home agent" e o novo endereo da estao
mvel na rede estrangeira. Para o caminho inverso, a estao mvel normalmente envia
pacotes atravs do roteador da rede estrangeira assumindo o seu IP original como IP de
origem. Isso pode causar alguns problemas com firewalls [45]. Assim, uma rede
estrangeira que estiver filtrando o trfego de sada (egress filtering) poder no permitir
a sada de trfego que no se origina na sua rede interna, como o caso do IP original
da estao mvel na rede estrangeira. De forma semelhante, se a rede de origem da
estao mvel estiver configurada para filtrar o trfego de entrada (ingress filtering) ela
no aceitar trfego de entrada vindo de um endereo interno.
Para solucionar este problema, o IP mvel pode usar a tcnica de tunelamento
reverso visando estabelecer um tnel topologicamente correto entre o novo endereo da
estao mvel na rede estrangeira e o "home agent". Esta extenso ao IP mvel
proposta em [46], mas no se prope a resolver outros os problemas ainda existentes
com os firewalls ao longo de todo o caminho do tnel.
O tunelamento reverso, apesar de aceitvel para o problema dos filtros de
entrada e sada, causa outros novos problemas. Um deles uma ineficincia de
roteamento entre a estao mvel e a "estao correspondente", j que fora a
triangulao do trfego entre os dois atravs do "home agent". Ainda, o tunelamento usa
cabealhos adicionais nos pacotes para os tneis de ida e de volta, o que representa
alguma sobrecarga no volume de trfego.
Outro aspecto relevante que muitas estaes mveis usam algum mecanismo
para se manter conectado VPN da sua redes corporativa. O MIPv4 e as VPNs
baseadas em IPsec ainda enfrentam muitos problemas, pois o IPsec requer renegociao
quando a "estao mvel" se movimenta entre redes estrangeiras para manter a "estao
mvel" conectado a sua respectivas VPN de origem [48].
Durante o movimento da "estao mvel" entre as redes estrangeiras, pode haver
perodos de desconexo que levam a uma parada no envio e recepo de dados. Mesmo
quando as redes tm cobertura sobreposta, o handoff requer a descoberta, negociao e
o registro da "estao mvel" na nova rede [45],[47]. A latncia observada durante o
handoff da "estao mvel" causa problemas s aplicaes que usam TCP,
principalmente porque o emissor reage como se estivesse havendo congestionamento e
reduz a taxa de transmisso, muitas vezes recaindo na reduo da vazo (TCP slow
start). Assim, questes j conhecidas do TCP para redes sem fio agora tambm
interferem no MIPv4.
3.3.5. Transparncia Fim a Fim
Transparncia fim a fim uma caracterstica da Internet que foi identificada no
argumento fim a fim (seo 3.2.2) e nos ltimos tempos tem sido gradualmente perdida.
O conceito original pode ser definido como [7]:
1. A existncia de um nico esquema de endereamento universal para toda a
Internet, que permite conectividade fim a fim sem necessitar de dispositivos de
interconexo para rede com tipos distintos de endereos.
2. O mecanismo que permite os pacotes trafegarem da sua origem ao seu destino
na rede sem serem modificados na sua essncia. Isso significa que a rede deve se
comportar como uma caixa-preta: o que for colocado nela na sua origem o que
deve sair no destino. Algumas pequenas modificaes so aceitas nos pacotes,
como o decremento do campo TTL (Time to Live), a fragmentao de pacotes e
a modificao dos bits de tipo de servio (campo DSField).
A primeira caracterstica foi amplamente explorada na Internet porque determina
que os endereos sejam nicos e constantes (durveis) na rede. Particularmente, os
endereos IP foram incorporados nos identificadores de transporte. Por exemplo, uma
conexo TCP identificada por cinco campos: IP de origem/destino, porta de
origem/destino e protocolo. Pode-se ver que esse um caso de violao dos conceitos
tradicionais de ocultao das camadas.
A segunda caracterstica foi uma das responsveis pelo grande sucesso da
Internet, porque permite que novas aplicaes sejam facilmente implantadas na rede.
Isso ocorre porque, se a rede no modifica os pacotes, os sistemas finais so os nicos
responsveis pelo funcionamento da aplicao. Com essa caracterstica, a implantao
de uma nova aplicao na Internet requer apenas que ela esteja funcionando nos
sistemas finais, enquanto que nenhuma modificao necessria no ncleo da rede (ou
seja, nos roteadores) [18].
Uma conseqncia do grande crescimento apresentado pela Internet nos anos
1990 foi que ela perdeu a transparncia fim a fim. De um lado, os endereos IPv4 da
Internet no mais podem ser considerados nem globalmente nicos nem constantes fim
a fim. De outro lado, os pacotes tm freqentemente seu contedo significativamente
alterado ao longo do seu trajeto na rede.
As causas da perda da transparncia so os dispositivos criados para a alocao
criteriosa dos endereos IPv4 e a utilizao crescente da tecnologia TCP/IP por
empresas e usurios residenciais. Essencialmente, esses dois fatores levaram
introduo de mecanismos chamados de dispositivos intermedirios, ou middleboxes
[5], que esto no caminho dos pacotes IP, mas que realizam funes no convencionais,
que no so aquelas funes padro realizadas por roteadores. A RFC 3234 [5]
apresenta vrios exemplos de dispositivos intermedirios, como: NAT (Network
Address Translation) [29], firewall [17], proxies e caches [15]. Em geral, o objetivo
utilizar uma menor quantidade de endereos IP, melhorar o desempenho e aumentar a
segurana. Especificamente, algumas causas da perda de transparncia so:
O modelo de Intranet: como redes corporativas tm em geral informaes
confidenciais, segurana algo fundamental (seo 3.3.3).
Alocao dinmica de endereos: o uso crescendo de PPP e DHCP faz com
que no se possa vincular um endereo IP a um determinado sistema final.
Firewalls: representam o principal mecanismo para barrar o acesso externo a
uma rede privada.
Endereos privados e NATs: a utilizao de endereos privados para aumentar
a quantidade de endereos disponveis, facilitar a troca de provedor e prover
segurana, fazem com que a maioria dos usurios da Internet hoje esteja em
redes que usam NAT (ou seja, esto atrs do NAT).
Proxies, Caches e Gateways de aplicao: so dispositivos que se interpem na
comunicao entre um cliente e um servidor. Por exemplo, um proxy Web abre
duas conexes, uma com o cliente e outra com o servidor. Eles podem tambm
analisar, modificar e bloquear algumas mensagens de protocolos aplicao,
como gateways de FTP que impedem que certos comandos (ex: put) sejam
executados de fora para dentro da rede.
Um grande problema com a perda da transparncia que qualquer aplicao que
assuma que endereos so nicos e que no so modificados ir falhar. No caso de
protocolos multimdia, como H.323 e SIP, eles usam vrios fluxos diferentes
simultaneamente, negociando endereos de rede e portas de transporte dinamicamente.
Como os endereos no so constantes, possvel que uma mquina atrs de um NAT
indique um endereo de rede interna (ex. 192.168.x.x) para o seu par exterior.
Obviamente, ele no ir conseguir se conectar a esse endereo.
3.3.6. Modelo em Camadas
Em uma arquitetura tradicional de rede as funes de comunicao so organizadas em
nveis aninhados de abstrao, chamados de camadas de protocolos. Este princpio,
documentado na RFC 46 [24], diz que conveniente e til que a rede seja vista com
uma hierarquia de protocolos e de nveis de implementao. A camada N oferece um
servio camada N+1 e constri o seu servio usando os servios da camada N-1. Alm
disso, os metadados que controlam a entrega dos pacotes so organizados como
cabealhos de protocolos, um para cada camada [20]. O modelo em camadas prov
algumas caractersticas importantes, como [2]:
1. Modularidade: significa quebrar um sistema em partes, para permitir seu
desenvolvimento independente, facilidade de substituio e reutilizao de
componentes.
2. Encapsulamento: uma conseqncia da modularidade, que proporciona a
ocultao da informao e independncia entre mdulos. O encapsulamento
prov a abstrao, atravs do agrupamento de mecanismos complexos em um
mdulo e uma interface simples para a ocultao da complexidade. Em um
modelo em camadas, cada camada encasulada na camada inferior.
3. Estrutura dos metadados: os metadados (cabealhos) so estruturados em
forma de pilha em um modelo em camadas. O ltimo cabealho a ser
introduzido no transmissor o primeiro a ser processado no receptor.
4. Regras de processamento: os cabealhos so processados em ordem rgida, na
medida em que so encapsulados no transmissor e removidos no receptor. Isso
faz com que o comportamento dos componentes de rede seja previsvel, porque
cada camada confia na operao correta das outras camadas.
Este modelo de rede em camadas apresentou um bom funcionamento como um
princpio de organizao, mas ele funcionou melhor quando o argumento fim a fim era
seguido mais rigidamente na arquitetura da Internet original. Atualmente, alguns
problemas e limitaes podem ser observados:
Existe uma presso constante pela introduo de violaes s camadas. Mesmo
a arquitetura base da Internet (os protocolos IP e TCP) inclui uma violao
implcita, como no controle de congestionamento, que detectado pela camada
de rede mas exercido pela camada de transporte. Outra violao a incluso
dos endereos IP nos identificadores do TCP.
Objees em alterar implementaes estveis e interfaces antigas entre
camadas freqentemente levam projetistas a inserir novas funcionalidades
entre as camadas existentes, gerando uma grande proliferao de subcamadas.
Por exemplo, TLS (Transport Layer Security) uma subcamada 4, IPsec (IP
Security) uma subcamada 3 e MPLS (Multiprotocol Layer Switching)
uma subcamada 2.
A proliferao dos dispositivos intermedirios (middleboxes), uma grande
ameaa arquitetura. Embora sejam introduzidos para resolver outros
problemas, eles necessitam de informaes de controle que no conseguem
serem introduzidos facilmente na pilha de protocolos. O resultado que so
necessrios protocolos especiais de sinalizao desconectados dos dados (out
of band), que no uma caracterstica tpica da Internet.
Nem todos os aspectos podem ser claramente delimitados em uma nica
camada. Por exemplo, questes de desempenho permeiam todas as camadas e
deveriam ser tratadas desta forma, ou seja, um pouco em cada camada e de
forma integrada. No entanto, o modelo em camadas dificulta a otimizao
porque a modularidade e a ordem rgida no processamento pode comprometer
a eficincia na implementao [9]. Outro aspecto a segurana, que deve ser
vista globalmente, no podendo ser confinada em uma nica camada.
A evoluo dos protocolos de rede muito difcil, especialmente na camada de
rede, porque muitas funes precisam ser agregadas aos protocolos. Isto leva a uma
nova crena, de que talvez camadas no sejam uma abstrao suficientemente flexvel
para modularizar o software de rede [12] e portanto outros modelos seja necessrios.
3.4. Propostas de Mudana da Arquitetura da Internet
Esta seo apresenta as propostas que incorporam modificaes na arquitetura da
Internet, com relao s questes de projeto analisadas na seo 3.3. A escolha das
propostas foi feita por dois motivos: pela sua notoriedade acadmica (citao por outras
propostas) e por uma tentativa de abranger as questes de projeto.
3.4.1. Arquitetura de Nomes em Camadas
O sistema de resoluo de nomes da Internet, o DNS, usa apenas um nvel de indireo.
Ou seja, o DNS converte diretamente os nomes de domnio em nmeros IP. O resultado
que, quando um usurio (browser) deseja localizar uma informao ou um servio
(ex: http://hotelfazenda.com.br/reservas), o DNS aponta o IP da estao onde a
informao reside, ou seja, a informao endereada em relao ao local onde reside e
ambos so fortemente associados entre si. Se a informao movida ou replicada para
outro lugar, ela no pode ser automaticamente localizada.
A Arquitetura de Nomes em Camadas (Layered Naming Architecture LNA)
[1] prope a separao semntica entre a identificao do servio (ou informao) da
estao onde ela reside. Esse desacoplamento semntico alcanado com a introduo
de um Identificador de Servio (service identifier SID) e de um Identificador de
Sistema final (endpoint identifier EID). Os dois identificadores, portanto, separam a
identificao do servio das sistemas finais onde eles esto residentes. Nesse esquema,
o usurio somente precisa obter o identificador do servio que deseja acessar (SID) e
sua localizao (EID) obtida automaticamente.
A arquitetura LNA, portanto, requer a introduo de nveis adicionais para a
resoluo de nomes. Agora, a resoluo de nomes deve ser executada em trs nveis,
como mostrado na Figura 3-2. O primeiro envolve converter uma informao do nvel
do usurio para o identificador do servio, ou seja, obter o SID. O segundo nvel
envolve converter o identificador do servio (SID) para o identificador da sistema final
(EID). O terceiro e ltimo nvel converte e o EID para o endereo IP.
Descritor no
nvel do usurio
(ex: texto de busca)
Descritor no
nvel do usurio
(ex: texto de busca)
Obtm o SID
correspondente
Resolve o SID Resolve o SID Resolve o EID Resolve o EID
Obtm o EID
correspondente
Obtm o Endereo
IP correspondente
Resolve o IP
(roteamento)
Resolve o IP
(roteamento)
1 2 3
Figura 3-2 As camadas de resoluo da LNA
O primeiro nvel, usado para converter uma informao do nvel do usurio para
um SID pode ser alcanado atravs de algum servio de busca. Por exemplo, ao invs
de diretrios de busca retornarem URLs (como atualmente) eles retornariam SIDs.
O segundo nvel requer o envolvimento da aplicao, tal como atualmente que
inclui o "resolvedor". Considere-se uma aplicao A executando em uma estao E
desejando acessar o servio ou uma informao representada por um SID S. A aplicao
passa S para a camada de resoluo de SID, que contacta a infra-estrutura de resoluo
e retorna um ou mais triplas do tipo (EID,transporte,porta), cada tripla representando
uma instncia do servio desejado, onde transporte e porta indicam o protocolo de
transporte e porta, respectivamente. Por exemplo, duas triplas poderiam ser
(EID
1
,TCP,80) e (EID
2
,TCP,8080). Dependendo do tipo do servio, informaes
adicionais podem ser passadas junto com cada tripla. Por exemplo, se S representa uma
pgina da web (e no apenas um servidor web), um caminho representando o arquivo
pode ser adicionado.
De posse das triplas mencionadas, A pode se comunicar com o EID especificado
usando o protocolo de transporte e porta indicados. Os protocolos de transporte, agora
vinculados ao EID (e no mais a endereos IP) poderiam usar o EID da estao de E
como "origem" e o EID de uma das triplas como "destino". Dependendo do tipo de
aplicao, A poderia usar mltiplas triplas para conexes simultneas por para backup
em caso de falha da conexo atual. Se todas as triplas falharem, A pode re-invocar nova
resoluo para o SID e obter novas triplas.
No terceiro nvel, o protocolo de transporte prepara pacotes e os repassa para a
camada EID. A camada EID resolve o EID e obtm um ou mais endereos IP (mais de
um quando a estao for multi-homed
3
ou quando a estao uma representao lgica
de um conjunto de mquinas). A camada EID adota o IP do emissor como origem e um
dos endereos como IP de destino e repassa os pacotes para a camada IP. Se o IP
destino no for alcanvel, a camada EID pode usar um dos outros IP obtidos no
3
Uma estao multi-homed quando ela participa simultaneamente de mais de uma sub-rede IP, como
o caso de roteadores e alguns servidores que buscam redundncia de comunicao no nvel IP
processo de resoluo. Se nenhum IP funcionar, a camada re-invoca a resoluo do EID
para obter novos endereos IP.
Em alguns casos, a entidade destinatria no quer manusear diretamente o
trfego recebido, preferindo direcionar a conexo (delegar) para outra estao de sua
escolha. A arquitetura LNA prev uma forma mais genrica para resoluo que permite
suportar esse tipo de delegao. Os autores argumentam que este tipo de delegao no
altera essencialmente a confiabilidade do relacionamento entre a origem e o destino (se
X confia em Y, ento tambm confia nos delegados de Y). Esta delegao pode se dar
tanto no nvel de SID (servio) quanto no nvel de EID (estao), permitindo a
interposio de intermedirios no nvel de servios e aplicaes (ex: gateways) ou no
nvel de rede (ex: firewall, NAT e VPN).
A arquitetura LNA apresenta vrios benefcios. Primeiro, nomear dados e
servios com SIDs, soluciona o problema de usar a URL para tal finalidade e amarrar o
servio ou dado com a estao onde reside. Com o SID as aplicaes so nomeadas
permanentemente, independentemente da sua localizao e estabelece a idia de que
servios e dados so os objetos de "primeiro nvel" na Internet. Segundo, nomear
estaes com EIDs fornece uma soluo natural para mobilidade e multi-homing: se
uma estao identificada por um EID e muda seu endereo IP, ento a camada de
resoluo EID re-resolve e para obter o novo endereo IP. Esta religao automtica
permite a operao contnua na presena de mobilidade e prov redirecionamento IP em
caso de falha em estaes multi-homed. Por ltimo, permite integrar middleboxes como
NAT e firewall na arquitetura da Internet, sem violar o princpio fim-a-fim ou a
semntica do IP.
LNA tambm traz alguns problemas. O principal deles que o SID, ao contrrio
de uma URL, no apresenta uma estrutura hierrquica de domnios. O SID "plano" (no
sentido de que no hierrquico) e , na verdade uma seqncia de bits, ou um nmero.
A explicao para isso diz respeito escolha do mecanismo DHT [51] para conferir
eficincia ao processo de resoluo.
Como o SID um identificador que representa o endereo de um servio ou
informao, o usurio pode naturalmente desejar ret-lo, tal como o faz atualmente com
uma URL. O SID, entretanto, traz nenhuma informao que permita ao usurio uma
associao mnemnica, o que o torna inadequado para manuseio de usurios.
A adoo da arquitetura LNA requer grandes modificaes nas camadas de
transporte e aplicao, devido nova infra-estrutura de resoluo de nomes, embora
praticamente preserve todo o comportamento do IP. Sua implementao no simples,
mas pode se dar de forma incremental e as mudanas nas aplicaes de sistemas
operacionais podem manter compatibilidade com o mecanismo antigo para permitir
transio suave.
3.4.2. Arquitetura FARA
Conforme apresentado na seo 3.2, o modelo atual de endereamento na Internet usa o
endereo IP como localizador da rede e identificador do sistema final, o que acarreta
numa srie de problemas previamente identificados. Clark et al. apresentaram a
Arquitetura FARA (Forwarding directive, Association, and Rendezvous Architecture)
[11] com o objetivo de tentar aliviar essa sobrecarga do endereo IP. importante
ressaltar que esta arquitetura define um conjunto abstrato de componentes e suas
relaes, fornecendo um arcabouo consistente e de alto-nvel sem especificar detalhes
de mecanismos e formatos de seus constituintes. A partir deste arcabouo diversas
arquiteturas especficas podem ser derivadas.
Na arquitetura FARA, a comunicao entre os sistemas finais substitudo pela
troca de pacotes entre entidades, sobre um substrato de comunicao. Uma entidade
um conceito abstrato, que pode ser um processo, um thread, um computador, um
agrupamento de computadores etc. A comunicao entre entidades feita atravs de
conexes lgicas, puramente fim-a-fim, chamadas de associaes. Essas associaes
requerem que as entidades comunicantes mantenham estados persistentes de
comunicao. Desta forma, cada pacote pertence a uma nica associao e uma
entidade pode ter mltiplas associaes concorrentes. Em cada pacote existe um
identificador que possibilita entidade receptora a adequada demultiplexao para uma
associao particular. Esse identificador chamado de identificador de associao
(AId) e so estritamente locais a cada entidade. Para o substrato de comunicao, a
arquitetura assume que este componente possui mecanismos no orientados conexo
para entrega dos pacotes das associaes. Isto implica que as entidades so responsveis
pelo tratamento da confiabilidade na comunicao. Ainda, vale a pena ressaltar que a
arquitetura no considera a existncia de um espao de nomes global nem para
associaes nem para entidades.
Quando uma entidade precisa enviar um pacote para uma das suas associaes,
ele entrega-o para seu substrato de comunicao com um campo de cabealho chamado
de diretiva de encaminhamento (Forwarding Directive FD) de destino, que contm
as informaes necessrias para o roteamento e entrega do pacote entidade receptora
correspondente. Neste contexto, o componente FD substitui o endereo IP no
roteamento de pacotes. A arquitetura tambm supe a necessidade de o pacote conter
uma FD da fonte, para o caso de haver necessidade de retorno de informaes fonte.
Os autores neste ponto relembram que a entrega de pacotes no para um n, e sim
para a entidade que contm a associao correspondente. importante ento enfatizar
que a partir destes conceitos, surgem diferenas substanciais em relao arquitetura
atual da Internet. Especificamente, o endereo IP da arquitetura atual faz o papel da FD
e do AId. Na arquitetura FARA, essas funes foram deliberadamente separadas e, alm
disso, ela no requer um espao de endereos global nico. Observe que os elementos
destacados em negrito, a saber as entidades, as associaes e seus identificadores AId,
o substrato de comunicao e a FD, formam os componentes bsicos da arquitetura.
importante observar as conseqncias da modularidade inerente FARA, uma
vez que o modelo separa os mecanismos de encaminhamento, que acontecem no
substrato de comunicao, das funes de comunicao fim-a-fim executadas pelas
entidades. Este modelo permite mudanas nos mecanismos de encaminhamento de tal
forma que os detalhes da estrutura do substrato de comunicao ficam invisveis s
entidades, possibilitando que problemas de mobilidade em geral, por exemplo, possam
ser plenamente solucionadas.
Na concepo da arquitetura FARA, algumas suposies importantes foram
feitas sobre os seus componentes:
Toda entidade na FARA mvel e carrega consigo os estados da aplicao e de
comunicao. O modelo tambm permite a mobilidade da entidade quando ela
faz parte de um sistema final ou rede que tambm mvel;
No existe um espao de nomes global para as associaes. O AId nico numa
entidade e tambm local. Assim, esse identificador no muda mesmo se a
entidade mvel;
No existe definio de um conjunto global de nomes para as entidades;
No imperativo que os sistemas finais tenham seus endereos escolhidos a
partir de um nico espao global de endereos.
Levando em considerao estas suposies, para se estabelecer uma associao entre
duas entidades A e B, a entidade A envia uma mensagem para a entidade B, supondo
que A possui uma FD para alcanar B. Um problema de inicializao surge neste
processo. Como o primeiro pacote ir carregar um AId, se os AId so locais s
entidades? Observe que todos os outros pacotes s podero fluir de A para B uma vez
tendo disponvel a FD e o AId destino. Para solucionar isto, a FARA adiciona dois
novos componentes, a saber o mecanismo Rendezveous e o Sistema de Diretrio FARA
(FARA Directory System - fDS).
Mecanismo Rendezveous: para criao de uma associao, o primeiro pacote deve ser
especial, pois ao invs de carregar o AId destino, ele carrega um Rendezvous
Information String (RI), que a entidade receptora usar para estabelecer uma associao
e definir um AId. O mecanismo Rendezvous consiste da fase de descoberta e da fase
de "iniciao". A fase de "descoberta" retorna um par (FD, RI), onde o FD necessrio
para a entrega do primeiro pacote entidade correta, enquanto o RI usado no destino
para criar a associao (na fase iniciao).
fDS: a fase da descoberta pode ser realizada atravs de diversos servios de alto
nvel, tal como um servio similar ao DNS. A arquitetura FARA no define
especificamente a maneira como o processo de descoberta pode ser realizado,
encapsulando essa tarefa num servio de diretrio genrico e deixando os detalhes para
a implementao.
3.4.3. Arquitetura NIRA
A arquitetura de roteamento NIRA (New Internet Routing Architecture) [32] foi
projetada para possibilitar ao usurio a escolha de rotas no nvel de domnio. Vale a
pena enfatizar que o roteamento no nvel de domnio refere-se seqncia de domnio
que um pacote atravessa, que diferente do roteamento no nvel de roteador, que trata
da seqncia de roteadores.
Ao se propor uma arquitetura de roteamento com estas caractersticas, diversos
problemas devem ser abordados. O primeiro est relacionado ao descobrimento das
rotas pelo usurio. Segundo, entra o aspecto de como estas rotas devem ser
representadas. E finalmente, entram os aspectos de ordem econmica com a
implantao desta estratgia, de tal forma que fique extremamente claro a maneira que
um provedor de servios poderia ser compensado quando um usurio escolhe usar seus
servios. Conforme enfatizado por Yang [32], os provedores podem no ter motivao
suficiente para encaminhar pacotes de acordo com a especificao do usurio, se no
houver uma compensao justa.
O mecanismo de descoberta de rotas em NIRA dividido entre as duas partes,
fonte e destino, de tal forma que cada elemento somente necessita ter conhecimento de
sua parte da rede. Cada usurio sabe previamente (ou descobre por algum
procedimento) as informaes da topologia da rede nos domnios que provem servios
para ele, de acordo com relaes contratuais. A fonte tambm busca, sob demanda, as
informaes da topologia da rede do provedor de servio de destino. Por fim, h a
combinao destas duas informaes para especificar uma rota que alcance o destino
desejado.
Com o objetivo de obter uma soluo elegante, a arquitetura NIRA identifica
algumas questes essenciais de projeto. Os requisitos considerados foram
escalabilidade, robustez, eficincia, heterogeneidade das escolhas do usurio e
compensao para os provedores de servios. Assim, para atender estes requisitos de
projeto e solucionar alguns dos problemas previamente apresentados na seo 3.2, a
arquitetura NIRA apresenta algumas solues para o modelo de rede, endereamento, a
representao de rotas, a descoberta de rotas e compensao para o provedor, que so
discutidas a seguir.
AS 10
AS 20
AS 100
AS 300
AS 200 AS 400
AS 500 AS 600
Ncleo
Alice
Bob
Ae80:1:1::ec
Ae80:2:1:ec
Alice
Ae80:2:2:2::/96
Ae80:2:2:2:/64
AS 600
Ae80:2:2:2::6c1a
Bob
ae80:2:2::/96
ae80:2:2::/48
AS 500
InterAddr
(Addr)
AllocPf
ae80:1:1::/96
ae80:2:1::/96
ae80:2::/96 ae80::/96
ae80:2::/32
AS 300
ae80:1:1::/48
ae80:2:1::/48
AS 400
ae80:1::/32
AS 200
ae80::/16
AS 100
Ae80:1:1::ec
Ae80:2:1:ec
Alice
Ae80:2:2:2::/96
Ae80:2:2:2:/64
AS 600
Ae80:2:2:2::6c1a
Bob
ae80:2:2::/96
ae80:2:2::/48
AS 500
InterAddr
(Addr)
AllocPf
ae80:1:1::/96
ae80:2:1::/96
ae80:2::/96 ae80::/96
ae80:2::/32
AS 300
ae80:1:1::/48
ae80:2:1::/48
AS 400
ae80:1::/32
AS 200
ae80::/16
AS 100
Cliente-Provedor Peer-Peer
Figura 3-3 - Modelo de Rede da Arquitetura NIRA
Modelo de Rede: o mtodo de representao de rotas e endereamento da arquitetura
NIRA baseia-se na estrutura da Internet no nvel de polticas. Em outras palavras, um
domnio decidir se ir ou no prover servios de trnsito para os domnios adjacentes,
baseado nas suas relaes de negcio com eles. Outras definies so necessrias para
uma melhor compreenso desta arquitetura. Primeiro, uma rota tpica no nvel de
domnio rotulada como valley-free, isto , quando um pacote enviado por um usurio
primeiramente empurrado em direo estrutura de seu provedor, fluindo depois
em direo cadeia do provedor de destino. Adicionalmente, a regio da rede onde
pacotes no podem ser empurrados chamada do ncleo da Internet. Ainda, enlaces
em nveis inferiores (low-level peering link) podem conectar as cadeias dos provedores
da fonte e destino, onde os pacotes poderiam utilizar este atalho. A Figura 3-3 reproduz
o diagrama do modelo de rede da arquitetura NIRA, originalmente apresentada em [32].
Os provedores no ncleo esto indicados como AS 10, AS 20 e AS 100. As rotas 400-
200-100-300-500-600 e 400-200-300-500-600 so rotas valley-free.
Endereamento: NIRA usa um esquema de endereamento hierrquico por provedor
para reduzir a sobrecarga da construo e representao de rotas. Desta forma, para
cada provedor num nvel hierrquico superior seria alocado um prefixo de
endereamento globalmente nico. Este por sua vez alocaria prefixos de endereos para
seus clientes a partir do seu espao de endereamento. Recursivamente, esses clientes
poderiam tambm fazer o mesmo com seus respectivos clientes. A proposta original do
NIRA assume endereos de tamanho fixo de 128 bits. Um endereo ento seria uma
concatenao dos endereos inter e intra-domnio. A parte inter-domnio de um
endereo de ns no mesmo domnio tem o mesmo tamanho. Desta forma, possvel um
n manter um nico endereo intra-domnio. Apresentamos na Figura 3-3 um exemplo
do esquema de endereamento da arquitetura NIRA, utilizando a conveno para
representao de endereos IPv6. O comprimento em bits do prefixo do endereo ou de
um endereo inter-domnio especificado aps uma barra, /. Neste exemplo, o
provedor no nvel mais superior (AS 100) tem como prefixo alocado ae80::/16
(AllocPf) e tem seu endereo inter-domnio ae80::/96 (InterAddr). O AS 100 aloca o
prefixo ae80:1::/32 para seu cliente AS 200 e o prefixo ae80:2::/32 para o AS 300. O
processo segue recursivamente para os AS 400, AS 500 e AS 600. Observe que o AS
400 tem dois segmentos de rota para o ncleo (400-200-100 e 400-300-100) e portando
tem dois prefixos ae80:1:1::/48 e ae80:2:1::/48. Alice um sistema final no AS 400
com endereos ae80:1:1::ec e ae80:2:1::ec, enquanto Bob que est no AS 600 tem o
endereo ae80:2:2:2::6c1a.
Representao de Rotas: Para o esquema de representao de rotas, NIRA baseia-se
no prefixo do endereo que identifica um segmento de rota (rota parcial). Em alguns
casos, um par de endereos (fonte e destino) pode representar rotas valley-free. Cada
uma destas rotas consiste de dois segmentos. Um segmento de rota a cadeia dos
provedores que aloca o endereo fonte, enquanto o outro a cadeia que aloca o
endereo de destino. Observe que os dois segmentos ou alcanam um provedor em
comum ou o ncleo da Internet. Por exemplo, novamente na Figura 3-3 o par de
endereos ae80:1:1::ec e ae80:2:2:2::6c1a identificam a rota no nvel de domnio entre
os sistemas finais Alice e Bob, a saber a rota cannica 400-200-100-300-500-600. As
outras possveis rotas so chamadas de no-cannicas como, por exemplo, a rota 400-
200-300-500-600.
Para encaminhar um pacote usando o esquema de representao de rotas, o
algoritmo de encaminhamento precisa olhar ambos os endereos (fonte e destino).
Assim, ao observar o endereo de destino o roteador ser capaz de saber se o domnio
de destino j foi alcanado. Se no, o roteador decide se o ponto de retorno foi
atingido ou no, ao verificar tambm o endereo da fonte. Se os dois endereos
compartilham de um prefixo comum pertencente ao espao de endereamento do
domnio atual, ento o ponto de retorno foi alcanado. Ainda, se os dois endereos
no compartilham de um prefixo comum, mas o domnio atual o Ncleo, ento o
ponto de retorno foi alcanado. Antes de atingir o ponto de retorno, os pacotes so
encaminhados para cima de acordo com endereo da fonte. Aps o ponto de
retorno, os pacotes so encaminhados para baixo de acordo com o endereo de
destino. Na NIRA, esse mecanismo de encaminhamento chamado de
Encaminhamento Valley-Free. Com a rota cannica 400-200-100-300-500-600, o
ponto de retorno est no AS 100 ou no AS 300.
Descoberta de Rotas: NIRA oferece dois servios para auxiliar na descoberta de rotas,
a saber o Protocolo de Propagao de Informao de Topologia (Topology Information
Propagation Protocol - TIPP) e o Servio de Resoluo Nome-para-Rota
(Name-to-Route Resolution Service - NRRS). O objetivo do TIPP facilitar a
descoberta de informaes de topologia nos domnios que fornece servios para o
sistema final. Normalmente, o sistema final pode utilizar este servio para encontrar os
segmentos de rota que alcanam o ncleo. O TIPP propaga para um sistema final seus
endereos inter-domnio e os segmentos de rotas associadas com estes endereos. O
NRRS ajuda um sistema final a solucionar o problema de inicializao (como enviar o
primeiro pacote para um outro sistema final). Para tanto, o servio NRRS assume que
um sistema final sabe o nome de seu correspondente e retorna as informaes de
topologia de seus segmentos de rota. O NRSS foi projetado com um servio distribudo
de busca de nomes. Um sistema final deve armazenar seus segmentos de rota em um
servidor pr-definido (servidores de rota). Esses servidores de rota so organizados
hierarquicamente em um espao de nomes. Similarmente infra-estrutura do servio
DNS, em um NRRS o resolvedor contm uma lista pr-definida com os segmentos de
rota do NRRS raiz. O sistema final tem uma lista pr-definida dos segmentos de rotas
de seu resolvedor. Em cada nvel de resoluo, so retornados os segmentos de rota dos
servidores de rota que so responsveis do espao de nomes no nvel inferior. O
processo de busca pra quando se encontram os segmentos de rotas relacionados com o
nome requisitado.
Compensao para o Provedor: a arquitetura prev dois modelos de compensao.
Ambos requerem que os usurios tenham acordos contratuais previamente definidos
com os provedores antes da utilizao dos servios. O primeiro modelo, chamado de
Relaes Diretas de Negcio (Direct Business Relationships DBR) seria similar ao
modelo atual da Internet, onde os acordos contratuais so negociados diretamente entre
as entidades conectadas, porm considerando o custo de permitir ao usurio de escolher
diferentes rotas. No segundo modelo, chamado de Relaes Indiretas de Negcio
(Indirect Business Relationships IBR), um usurio poderia negociar com provedores
de servios no diretamente conectados a ele.
3.4.4. Arquitetura IPNL
A arquitetura IPNL (IP next layer) [16] prope uma extenso atual arquitetura da
Internet para incorporar o mecanismo NAT de maneira natural. Seu principal benefcio
oferecer o isolamento de redes, de modo a no obrigar renumerao em caso de troca
de provedor, alm de permitir que redes se conectem a diversos provedores sem
necessitar a troca de rotas BGP. Para isso modificaes so necessrias somente nos
NATs e sistemas finais atuais, permitindo que os roteadores permanecem inalterados.
Esta proposta retira a semntica fim a fim dos endereos IPv4 atuais criando uma nova
camada, chamada IPNL, entre as camadas de rede e de transporte. Esta mudana no
endereamento faz com que seja necessrio alterar tambm o roteamento, que em IPNL
pode ser baseado em endereos IPNL e em FQDNs (fully qualified domain names -
nomes de domnio totalmente qualificados, como www.gprt.ufpe.br). Uma caracterstica
fundamental de IPNL na questo de transparncia permitir que estaes atrs de NAT
sejam acessadas de fora, mesmo com o isolamento da rede.
A Figura 3-4(a) mostra alguns elementos da arquitetura IPNL. A topologia IPNL
a mesma que a da Internet atual: regies com endereos privados, conectadas a um
ncleo da Internet com endereos globais, atravs de NAT. Os NATs so chamados de
nl-router, a regio de endereamento global da Internet chamada de regio central e
regies com endereos privados so chamadas de regies privadas. Um nl-router que
conecta uma regio privada regio central chamado de frontdoor nl-router, ou
simplesmente frontdoor. Um nl-router que conecta duas regies privadas chamado de
nl-router interno.
Para os roteadores IP em cada regio, um nl-router parece com um sistema final
normal. Para os nl-routers, uma regio parece como uma rede de acesso mltiplo (ex:
LAN), ou seja, para a camada IPNL a camada IP se comporta como uma camada de
enlace de dados. Somente o endereo IPNL tem uma semntica fim a fim, de modo que
quando um pacote atravessa a rede de origem a destino, ele pode incorporar vrios
endereos IPs temporrios, um para cada regio. Isso idntico ao comportamento dos
endereos de enlace atualmente. Os endereos IP para uma determinada regio no tm
significado em outras regies. Na Internet atual a situao diferente, porque os
endereos IP globais tm significado nas regies internas, enquanto que o contrrio no
verdadeiro. Por fim, a Figura 3-4(b) mostra o endereo estendido e a Figura 3-4(c)
mostra a pilha de protocolos com a camada IPNL.
IP e DNS
globais
Estao IP Estao IPNL
IP e DNS
globais
nl-router interno
frontdoor
(a)
IP global
IP global rea IP local IP global rea IP local
Endereo IPNL IP estendido
TCP / UDP
IPNL IPNL
IP
enlace
TCP / UDP
IP
enlace
(b) (c)
Figura 3-4 Arquitetura IPNL; a) topologia; b) endereamento estendido;
c) nova camada na pilha de protocolos
Os cabealhos IPNL podem carregar dois tipos de endereos para roteamento.
Um o FQDN do sistema final e o outro o endereo IPNL. Um pacote pode ter
somente um dos dois ou ambos em conjunto. O FQDN o identificador primrio de
uma conexo fim a fim, que deve ser estvel enquanto a conexo durar. No entanto,
durante uma conexo, um FQDN de um sistema final pode ser mapeado para vrios
endereos IPNL sem prejudicar a semntica da conexo. Um conceito importante
justamente a possibilidade de se fazer um roteamento pelo FQDN. Isto possvel
devido a uma alterao no DNS. Conforme visto na seo 3.3.1, um endereo IP tem
atualmente a funo dupla de localizador e identificador do n. Em IPNL, essa
sobrecarga de funes exercida pelo FQDN. Uma vantagem dessa abordagem que
ela robusta a seqestro de pacotes, uma vez que o algoritmo de roteamento sempre
entrega os pacotes ao destino atravs do seu localizador. Se ele tambm a identidade
do n, ento existe uma segurana de que os pacotes esto indo para o lugar certo
(desconsiderando a possibilidade de ataques do tipo man-in-the-middle).
3.4.5. Arquitetura RBA
A arquitetura baseada em papis (role-based architecture - RBA) [2] rompe com o
modelo em camadas tradicionalmente usado na Internet (seo 3.5.6). RBA no
baseada em pilhas de protocolos, mas a comunicao organizada em unidades
funcionais chamadas de papis. Papis no so organizados hierarquicamente, de tal
modo que eles podem ser interconectados de maneira mais ampla do que camadas de
protocolos tradicionais. Um papel uma entidade abstrata e fornece uma descrio
funcional de um elemento fundamental de comunicao, que realiza uma funo
especfica no encaminhamento e/ou processamento dos pacotes.
Em uma abordagem sem camadas, as violaes de camadas deveriam ser
substitudas por interaes entre papis explicitamente projetadas. O objetivo fazer
com que papis sejam os elementos fundamentais da arquitetura, de preferncia bem
definidos e conhecidos. Para permitir a interoperabilidade, uma rede real usando RBA
no precisaria de muitos papis bem conhecidos (dezenas ou centenas), mas que fossem
bem definidos e padronizados.
Uma vantagem de RBA permitir que sistemas intermedirios se integrem
naturalmente na arquitetura, o que no ocorre no modelo em camadas atual. RBA
permite que um sistema final sinalize de maneira robusta e extensvel para um sistema
intermedirio que ele deseja ativar ou desativar uma determinada funcionalidade, como
por exemplo, permitir que uma estao externa o contacte diretamente ou impedir que
uma pgina seja redirecionada para um cache de web. O modelo em camadas no
permite que essas funes sejam integradas facilmente na arquitetura.
Uma arquitetura sem camadas apresenta alguns problemas adicionais que devem
ser tratados adequadamente, com relao estrutura de metadados, regras de
processamento e encapsulamento. A estrutura dos metadados no cabealho dos pacotes
no forma mais uma pilha (stack), mas um monte (heap) de cabealhos de
protocolos. Ou seja, o cabealho dos pacotes contm blocos de metadados de tamanho
varivel que podem ser inseridos, acessados, modificados e removidos em qualquer
ordem pelas unidades de protocolo. Esta questo, por sinal, importante, pois o modelo
em camadas especifica uma ordem rgida no processamento dos cabealhos. Em um
modelo sem camadas no existe uma ordem definida, de modo que os vrios protocolos
podem inclusive processar o cabealho simultaneamente. Obviamente, algum tipo de
organizao necessrio entre os papis, dependendo da semntica de cada um deles.
Um paradigma que se quebra com RBA o do encapsulamento, que deixa de ser uma
regra universal para ser utilizado somente quando existe uma necessidade semntica
forte entre os protocolos. No entanto, esse encapsulamento no idntico ao modelo em
camadas, pois os cabealhos so visveis a todos os papis. Portanto, regras mais rgidas
para ocultao da informao devem ser criadas, sempre que necessrias.
Papel A
Papel B
RSH 1
RSH 2
RSH 3
Papel C Papel C
Carga til
Pacote
Figura 3-5 Papis e cabealhos (RSH) em RBA
A Figura 3-5 mostra um pacote em RDA e os papis que processam os seus
metadados no cabealho, que por sua vez so divididos em pedaos chamados de
cabealhos especficos dos papis (role-specific headers RSH). Na figura, trs papis
processam (lem e escrevem) trs RSHs distintos, sendo que um mesmo papel pode
processar mais de um RSH e um RSH pode ser processado por mais de um papel. Em
RBA um sistema final no sabe a priori se o pacote que ele envia ir encontrar um n
intermedirio que desempenha um determinado papel. Por exemplo, se o pacote tiver
um RSH especfico que determina que ele no deve ser redirecionado a um cache, ento
caso o n redirecionador consulte o RSH ele no dever realizar esta funo, mas deixar
o pacote passar sem nenhuma alterao de destino. Alm disso, qualquer n no caminho
pode adicionar um novo RSH ao pacote.
Uma vez conhecidos o mecanismo geral de funcionamento da arquitetura RBA,
pode-se estabelecer claramente os seus objetivos:
1. Expanso: RBA inerentemente capaz de ser estendida, tanto do ponto de
vista abstrato como de implementao.
2. Portabilidade: os papis no devem estar vinculados aos ns da rede onde
sero executados;
3. Sistemas intermedirios: a arquitetura permite que os sistemas finais se
comuniquem explicitamente com os sistemas finais e estes uns com os outros.
4. Acesso a metadados: uma vez que no existe uma ordem clara de
processamento, RBA procura organizar o modo como os metadados so
acessados, para evitar inconsistncias.
5. Auditoria: um sistema final pode averiguar se o processamento solicitado foi
realmente efetuado, atravs da anlise dos RSHs.
3.4.6. Arquitetura Plutarch
Plutarch [13] um novo arcabouo para redes de prxima gerao, que difere da atual
arquitetura da Internet principalmente no sentido de que ele adota a idia da
heterogeneidade para atingir inovaes revolucionrias. A arquitetura homognea atual
e suas vantagens no so abandonadas, mas mantidas como uma das possveis
arquiteturas entre muitas outras. A proposta de Plutarch que novas arquiteturas de rede
devem se concentrar em mecanismos que permitam a interoperao entre vrias redes
heterogneas, em vez de exigir um conjunto de protocolos nico para todos os casos.
Existem algumas motivaes para a proposta de um arcabouo como Plutarch. O
motivo principal o problema concreto de conectar redes onde um nico protocolo (IP)
impossvel ou mesmo indesejvel, como no caso de redes de sensores. O segundo
motivo que o modelo abstrato em que Plutarch se baseia consegue capturar o estado
da Internet atual melhor do que os modelos baseados nos princpios originais da Internet
(seo 3.2.4). Finalmente, um modelo baseado em contextos explcitos oferece um
arcabouo mais claro para se debater mudanas futuras na arquitetura do que a tradio
atual da Internet pode permitir (devido, por exemplo, aos invariantes, como o endereo
IP, no caso da Internet ver seo 3.2.3).
Conforme mencionado anteriormente, Plutarch divide o mundo em contextos,
cada um contendo um conjunto de computadores, roteadores, comutadores (switches) e
enlaces de rede entre outros. Dentro de cada contexto a homogeneidade esperada, por
exemplo, entre endereos, formatos de pacotes, protocolos de transporte e servios de
nomes. Contextos distintos apresentam diferenas em pelo menos uma dessas regies. A
comunicao entre contextos possvel atravs de funes intersticiais
4
que fazem o
mapeamento entre o conjunto de funcionalidades de cada contexto. Essas
funcionalidades podem ser divididas em quatro reas principais:
1. Endereamento: O mapeamento entre contextos diferentes de endereamento
uma funo bem conhecida (ex: uso de NAT). As APIs para essas funes
deveriam ser claramente expostas, para permitir que os mapeamentos sejam
configurados, mantidos e gerenciados de modo automtico.
2. Nomeao: Atualmente o DNS oferece um nico espao de nomes, com um
gerenciamento hierrquico por delegao. Plutarch assume que novos servios,
como VoIP, iro possibilitar o surgimento de abordagens alternativas de
mapeamento entre diversos sistemas de nomes, por razes como escalabilidade
ou sobrecarga administrativa.
3. Roteamento: Estilos diferentes de protocolos de roteamento so apropriados em
redes diferentes. Por exemplo, a conexo de uma rede ad-hoc sem fio com
roteamento sob demanda com um Sistema Autnomo da Internet que usa OSPF
e BGP requer um mapeamento mais complexo do que simplesmente as redes
trocarem rotas via BGP (que em geral no apropriado para a rede ad-hoc).
4. Transporte: Um nico protocolo de transporte usado para tratar de todas as
tecnologias de rede. Um exemplo disso so as implementaes especficas do
TCP para redes sem fio, que freqentemente so baseadas em sistemas
intermedirios (proxies). No entanto, em alguns casos seria vantajoso otimizar
protocolos de transporte para redes especficas, ao custo de ter que tratar
cuidadosamente caso a caso.
Em cada rea, algumas funes intersticiais so necessrias, mas o conjunto de
tais funes no limitado a priori por Plutarch. O mais importante que as reas
(nomeao, endereamento, roteamento, transporte) devem ser suportadas fim a fim
entre redes radicalmente heterogneas, atravs da incluso de interaes explcitas nas
bordas das redes. Atravs dessas transies explcitas os projetistas de Plutarch que dois
4
Da biologia, entre tecidos.
benefcios sero alcanados: 1) o modelo da rede ir refletir mais precisamente a
realidade da rede; 2) o modelo da rede ser mais extensvel, permitindo que novos
servios sejam incorporados em todas as camadas da arquitetura
5
.
Plutarch prev que as funes gmeas de endereamento e nomeao deveriam
ser implementadas de acordo com o argumento fim a fim. Porm, a Internet atual impe
mecanismos localizados no meio da rede (ou seja, no so puramente fim a fim) para
endereamento (no caso do Ipv4, por projeto) e nomeao (o DNS, por um acidente de
evoluo). A conseqncia disso que nomes e endereos devem ser globais para
funcionar corretamente. Conforme discutido anteriormente, esse modelo insuficiente
para capturar a essncia da Internet atual (com sistemas intermedirios) e
provavelmente tambm no apropriado para conectar redes completamente diferentes.
Em vez de impor endereos globais pelo uso do IPv6 (o IPv4 j se mostrou
incapaz disso), Plutarch prope um esquema onde nem nomes nem endereos tm uma
semntica global. Isto gera flexibilidade nos sistemas finais retirando a imposio da
homogeneidade (unicidade do protocolo IP na cintura da ampulheta) e movendo as
decises de endereamento e nomeao para os sistemas finais. Esse modelo apresenta
duas caractersticas que o tornam convincente. Primeiro, ele captura de maneira
organizada a realidade da Internet atual, em particular o uso de sistemas intermedirios.
Isso porque redes que dependem da intermediao de sistemas intermedirios podem ser
modeladas como contextos distintos, com funes intersticiais bem definidas entre elas.
Em vez dos sistemas intermedirios violarem um princpio bsico da arquitetura, a sua
prpria existncia incorporada por ela. Em segundo lugar, ele permite que tecnologias
futuras sejam incorporadas facilmente, sem a necessidade de aplicar a pilha de
protocolos inteira da Internet, permitindo que a Internet atual conviva elegantemente
com elas.

Internet
GPRS
rede de
sensores
Encadeamento de contextos
Funo intersticial
Figura 3-6 Conexo entre contextos em Plutarch
A Figura 3-6 mostra um exemplo da de uso de Plutarch que poderia facilmente ocorrer
na Internet atual. Um usurio com um computador porttil em uma rede GPRS tenta
acessar a sua rede de sensores (de pesquisa) atravs da Internet. Numa condio normal,
o usurio no teria acesso rede de sensores, por eles no implementarem a pilha
TCP/IP, por exemplo. Neste caso, uma conexo fim a fim entre o usurio e a rede de
5
interessante notar que o atual modelo de ampulheta da Internet no suporta facilmente mudanas nas
camadas de rede e de transporte.
sensores poderia ser feita em Plutarch atravs de trs estgios. No primeiro estgio, os
nomes para cada contexto (trs, no caso) tm que ser resolvidos individualmente. No
segundo estgio, os endereos dos trs contextos devem ser mapeados em cadeia,
atravs de funes intersticiais e os contextos devem ser explicitamente adicionadas
lista de contextos do computador do usurio. No terceiro estgio, a comunicao ocorre
entre as aplicaes atravs das associaes entre os contextos. Informaes adicionais
sobre este e outros exemplos da aplicao de Plutarch podem ser obtidas em [13].
3.4.7. Infra-estrutura SFR
Conforme descrito anteriormente (seo 3.3.1), a forte relao da Web com o servio
DNS tem engessado sua flexibilidade em termos de migrao e replicao de contedo.
Qualquer proposio para quebra desta relao implica na implantao de uma novo
servio de resoluo de referncias (Reference Resolution Service RRS) em
substituio (ou auxiliar) ao DNS. Os requisitos para um novo RRS devem
prioritariamente preencher a lacuna deixada pela tecnologia atual (URL baseada no
DNS), a saber referncia persistente a objetos e referncia livre de disputa. O
primeiro requisito significa que as referncias no devem estar atreladas a nenhum
domnio. Vejamos como exemplo o seguinte caso. Suponha que uma pgina pessoal
(objeto) esteja hospedada em um provedor aaa.com.br, e que posteriormente migra para
o provedor bbb.com.br. Com o RRS atual (i.e., DNS) o registro de referncia ao objeto
controlado pelo primeiro provedor e a manuteno da persistncia implica na
permisso (improvvel) para a atualizao do registro, mesmo que o autor no esteja
mais filiado a ele (ex: aaa sendo UOL, bbb sendo TERRA). O segundo requisito est
relacionado com a questo legal de propriedade de nomes na Web, que atualmente
acontece com registros no DNS.
Em [52] os autores apresentam uma proposta para um RRS com referncias sem
semntica (Semantic Free References SFR). O SFR um RRS de propsito geral para
referncias persistentes e livre de disputa, baseado nos seguintes princpios:
Espao de nomes sem semntica: em outras palavras, referncias no
deveriam conter informaes sobre instituies, domnios ou provedores onde
elas esto localizadas, ou at mesmo serem legveis ao usurio;
RRS com interface mnima: os servios oferecidos pelo RRS deveria ser
restritos a apenas a resoluo de referncias. O mapeamento entre nomes
legveis ao usurio e a respectiva referncia deve ser feita por sistemas
auxiliares;
SFR permite funcionalidades no presentes nativamente na Web hoje, tais como
migrao de objetos sem a necessidade de atualizao dos apontadores ou o
aparecimento de apontadores quebrados. Alm disso, o processo de replicao de
objetos facilitado sem a necessidade de recorrer a CDN etc.
Desvencilhar-se de um servio largamente utilizado na Internet, como a Web
sobre o DNS, uma tarefa rdua, por mais que se apresente inmeras vantagens de uma
nova proposio. Desta forma, para uma proposta ser realizvel, ela deveria contemplar
ou herdar as principais vantagens do sistema legado. No caso do SFR, esta proposta tem
que lidar com o fato que a estrutura hierrquica do DNS fornece unicidade s URLs e
ainda possibilita acesso local aos objetos do servidor Web no caso de falhas na conexo
com a Internet (considerando que o servidor DNS est localmente disponvel antes do
enlace de acesso). Alm disso, em alguns casos, a facilidade de leitura dos nomes dos
sistemas finais d ao usurio uma certa confiana nos objetos que ele busca (ex: objetos
na pgina www.ufpe.br). Assim, uma vez que o RRS com SFR no hierarquicamente
organizado nem possui uma interface legvel para o usurio, esses problemas tem que
ser resolvidos com cuidado.
Em relao a escalabilidade, o SFR deve oferecer um esquema de busca rpido e
eficiente. Porm a busca de referncias em um espao de nomes sem semntica no
escalvel, mesmo com a utilizao de DHT, a latncia ainda pode ser muito grande. Um
outro desafio relacionado refere-se integridade da referncia que deve prevenir que
dois objetos distintos recebam a mesma referncia.
A proposta de um RRS com SFR prover uma infra-estrutura compartilhada que
oferea o servio de mapeamento de um rtulo sem semntica (que referencia um
objeto) para o meta-dado associado a este objeto. Nessa infra-estrutura, provedores
inserem o meta-dado do objeto e associa-o com um rtulo, enquanto os usurios fazem
o processo inverso, submetendo o rtulo infra-estrutura e recebendo como resposta o
meta-dado do objeto. A infra-estrutura do SFR usa DHT para mapear strings de 160
bits, SFRTags, para registros de objetos, o-records. Um registro de objeto o-record
mostrado na Figura 3-7. A infra-estrutura no armazena objetos, apenas os o-records. O
SFR pode utilizar qualquer tecnologia de busca escalvel, mas sua implementao de
teste usa o Chord [51]. O campo location definido no momento de insero do o-
record e mantm um ou mais valores que descrevem a localizao do dado
correspondente ao SFRTag. O campo location pode ser um par endereo IP e porta, um
nome de domnio ou um outro SFRTag. Essa infra-estrutura de resoluo no limita em
funcionalidade as aplicaes, visto que o contedo e forma do campo oinfo definido
pela aplicao e pode incluir dados do tipo de protocolo, nome do caminho no servidor,
etc. Por ltimo, o campo ttl permite estratgias de cache.
Uma infra-estrutura SFR composta por servidores (portal), clientes e relays
SFR (Figura 3-8, originalmente apresentada em [52]). As aplicaes armazenam e
requisitam o-records correspondentes a SFRTags usando o cliente SFR. Os clientes por
sua vez acessam a infra-estrutura SFR atravs dos Relays SFR, que realizam as funes
de cache.
Figura 3-7 - o-record
Em relao integridade, os rtulos SFRTags e os registros o-record apresentam
as propriedades: a) SFRTag o resultado de uma funo hash, sem significado humano
(legibilidade); b) Provedores de contedo podem criar referncias sem consultar uma
autoridade de nomeao; c) Somente o criador do registro o-record pode atualiz-lo;
O processo de busca nessa infra-estrutura simples. Uma aplicao envia a
solicitao para uma determinada SFRTag para o seu Portal ou Relay e se o rtulo est
na infra-estrutura, o n DHT responsvel retorna o o-record. Para reduzir a latncia ou
fazer balanceamento de carga entre os ns do SFR, a infra-estrutura permite que os
Relays faam cache de o-records, que os ns DHT faam cache de localizao e que os
Portais mantenham cache dos objetos mais populares. Para o caso de acesso local aos
objetos no caso de falhas na conexo no enlace de acesso Internet, o SFR dispe de
um mecanismo nos relays, conhecido como org-store. Neste caso, os relays mantm
uma cpia no org-store dos o-records criados (ou modificados) dentro da organizao,
antes de criar (ou atualizar) nos ns DHT da infra-estrutura.
Uma aplicao direta de uma RRS com SFR seria a Web sobre SRF. Na Web
sobre SFR, o tratamento dos nomes inteligveis para o usurio realizado fora do RRS.
Nesta situao, os portais de busca funcionariam da mesma maneira que hoje, com a
diferena que eles retornariam rtulos sem semntica ao invs de URL baseadas no
DNS. O objetivo de uma Web sobre SFR permitir migrao e replicao nativa de
objetos. Toda as informaes necessrias para alcanar um objeto na Web (endereo IP
e porta do servidor, nome do caminho no servidor) podem ser encapsuladas pelo
SFRTag, visto que o criador do objeto insere no o-record as informaes necessrias
para encontr-lo e armazena o registro do objeto na infra-estrutura SFR.
Um dos benefcios diretos da Web sobre SFR a facilidade de migrao. Por
exemplo, se um objeto referenciado por um rtulo SFRTag, muda para outro servidor
Web, em outro nome de caminho, o provedor do contedo (dono do objeto) precisa
apenas mudar os campos location e oinfo no o-record. As pginas que apontam para o
objeto no necessitam de alterar suas referncias. O outro benefcio citado
anteriormente, refere-se a replicao flexvel de objetos. Em resposta a uma solicitao
para uma SFRTag, a infra-estrutura pode retornar vrias localizaes e caminhos.
Cliente
Relay
Cliente Cliente Cliente
Relay
Org-store
Portal
Portal
N DHT
Organizao
SFR baseado
em DHT
Figura 3-8 - Infra-estrutura SFR e seus componentes
Concluindo, uma das desvantagens do SFR sua implantao na rede, pois os
navegadores Web teriam que utilizar a infra-estrutura do SFR para resolver rtulos em
metadados (ex: endereos IP e nomes de caminho) e isto evidentemente no aproveita o
legado dos navegadores Web atuais, requerendo uma modificao universal. Porm,
algumas estratgias de implementao parcial so apresentadas no artigo seminal [52].
3.4.8. Infra-estrutura I3
A Infra-estrutura de Indireo para a Internet (Internet Indirection Infrastructure - i3)
[30] uma rede sobreposta (overlay network) de propsito geral para facilitar a
implantao de servios como multicast, anycast e mobilidade. Ao invs de enviar
pacotes explicitamente para o destinatrio, cada pacote associado a um identificador
(rtulo), o qual usado pelo receptor para receber o pacote. Este nvel de indireo
introduzido pela rede i3, portanto, desacopla o ato de enviar do ato de receber e permite
que a rede suporte uma variedade de servios de comunicao.
Este modelo de servios pode ser visto como uma abstrao do modelo de
comunicao baseado em Rendezvous. Pacotes formam um par (id, dados) onde id um
identificador de m bits e dados consiste da carga til do pacote. Para indicar seu
interesse nos pacotes, os receptores usam "gatilhos" (triggers) na forma (id, addr), onde
id representa o identificador do gatilho e addr representa o endereo de uma estao,
consistindo de um endereo IP e uma porta. Um gatilho (id, addr) "registrado" na rede
i3 para indicar que todos os pacotes com um identificador id devem ser encaminhados
(no nvel IP) pela rede i3 para a estao identificada como addr.
Baseado neste modelo, a criao de um grupo multicast, por exemplo,
equivalente a fazer com que todos os interessados no grupo registrem "gatilhos" com o
mesmo identificador. A proposta da rede i3 tambm inclui uma forma mais complexa de
pacotes e gatilhos com empilhamento de identificadores (ao invs de um simples
identificador), como meio para suportar nveis adicionais de indireo e permitir a
implantao de outros servios.
A rede i3 trata a mobilidade das estaes e consegue manter a conectividade
fim-a-fim entre as estaes mveis da seguinte forma. Quando uma estao se move de
uma sub-rede para outra e troca o endereo E
1
para outro endereo E
2
, ela deve
atualizar os gatilhos de (id, E
1
) para (id, E
2
). A estao emissora no precisa tomar
conhecimento da mobilidade do receptor, uma vez que os pacotes so roteados com
base no identificador. Dessa forma, ambas as estaes emissora e receptora podem se
mover simultaneamente. A proposta no discute o mecanismo para troca o endereo E
1
para outro endereo E
2
durante a mobilidade, pois esta uma questo tratada no nvel
IP.
Quanto ao seu funcionamento, a rede i3 consiste de um conjunto de servidores e
sistemas finais. Os servidores que armazenam gatilhos e encaminham pacotes (usando
IP) para outros servidores i3 e para sistemas finais. Identificadores e gatilhos possuem
significado apenas na rede i3 e cada servidor armazena um subconjunto de gatilhos. Em
um determinado instante, um gatilho est armazenado em apenas um servidor e cada
sistema final conhece um ou mais servidores. Sistemas finais contactam a rede i3
apenas para enviar pacotes ou inserir gatilhos.
Quando uma estao deseja enviar um pacote, ele o encaminha para um dos
servidores conhecidos e se o servidor contatado no contm um gatilho que dispara a
entrega do pacote para alguma estao interessada, o pacote encaminhado para outro
servidor. Este processo continua at que o pacote alcana um servidor que armazena um
gatilho que casa com o pacote, quando ento o pacote entregue a sistema final atravs
do IP. Para saber para qual estao encaminhar o pacote, a rede i3 usa DHT para
indexar o identificador (os autores usaram o esquema de busca Chord [51], mas
argumentam que outros mecanismos como CAN, Pastry, Tapestry ou outros podem ser
usados [30]). Dessa forma, o pacote encaminhado pela rede i3 at o servidor
responsvel pelo identificador. No nvel de roteamento IP, nenhuma mudana
necessria. importante mencionar que a rede i3 no armazena pacotes: ela apenas os
encaminha. A rede i3 prov um servio do tipo "melhor esforo", tal como na Internet
atual, e no implementa confiabilidade sobre a rede IP.
Na Internet atual um nome DNS mapeado para uma estao como o resultado
de uma consulta explcita que precede a transferncia. Na rede i3, o mapeamento
identificador-estao integrado e automtico (no requer consulta explcita): quando
uma estao deseja acessar outra, o identificador do receptor pode ser obtido atravs de
um hash sobre o nome DNS (ou URL ou uma chave publicamente conhecida) associado
ao receptor. Dessa forma, o envio do pacote consiste em computar o identificador do
receptor e encaminhar para um servidor i3. Uma implementao da rede i3, feita pelos
autores da proposta, usa um identificador de 256 bits, dos quais 128 so usados pela
aplicao e demonstrou-se que esta escolha suficiente para obter hashes disjuntos,
com baixa probabilidade de coliso (ou seja, que aplicaes em estaes diferentes
obtenham o mesmo identificador). Por se tratar de uma rede de sobreposio, no h
necessidade de mudana no endereamento do nvel IP e a implantao da rede i3 em
escala da Internet poderia se dar de forma gradativa e incremental.
3.4.9. Arquitetura SOS
Keromytis et al. propuseram uma arquitetura chamada Secure Overlay Services SOS
(servios sobrepostos seguros) [41] para mitigar o efeito e o volume de ataques de DoS
na Internet atual. SOS rede sobreposta (overlay network) composta por ns que se
comunicam entre si usando a rede subjacente (rede IP), com o objetivo de gerenciar a
comunicao entre a origem e o destino para torn-la segura sobre a rede IP.
Freqentemente, os ns iro executar funes de roteamento para despachar pacotes
entre eles. A arquitetura assume que os ns participantes da rede sobreposta so
conhecidos (pblicos) e, portanto, tambm podem estar sujeitos a ataques. Entretanto,
certos papis que cada um dos ns da rede sobreposta assume so mantidos em segredo.
Origem
SOAP SOAP
Guia Guia
Servidor
Secreto
Servidor
Secreto
Destino Destino
Estaes da
Rede Sobreposta Regio filtrada
Figura 3-9 A arquitetura bsica do SOS
A Figura 3-9 mostra uma viso geral da arquitetura SOS que protege uma
estao (ou sub-rede) destino, de maneira que este receba apenas trfego legitimado.
Fundamentalmente, o objetivo da infra-estrutura SOS distinguir o trfego autorizado e
no-autorizado, permitindo que apenas este ltimo alcance o destino, enquanto que o
primeiro deve ser descartado (ou ter sua taxa reduzida). Dessa forma, a rede SOS se
torna um grande firewall distribudo que distingue o trfego malicioso e legtimo.
O procedimento para estabelecer a rede SOS, determinar o papel dos ns
participantes e ingressar na rede SOS o seguinte. Primeiro, uma estao destino decide
participar da rede SOS e instala um filtro nos seus arredores e seleciona um certo
nmero de ns participantes para agirem como seus "servidores secretos", ou seja,
aqueles nicos habilitados a encaminhar trfego para esta estao participante.
Quando um n da rede SOS informado que ir agir como "servidor secreto"
para uma estao participante ela, aps verificar a autenticidade desse pedido, calcula
vrias chaves (usando funes de hash) baseadas no endereo de rede daquela estao
destino. Cada chave ir identificar uma quantidade de ns da rede sobreposta que iro
agir como "guias" para aquela estao destino. Tendo identificado os "guias", os
"servidores secretos" os contactam, notificando-os para assumirem tal compromisso. Os
"guias", aps verificarem a autenticidade desse pedido, guardaro a informao
necessria para encaminhar o trfego para a estao destino atravs daqueles
"servidores secretos".
Quando uma estao de origem deseja transmitir para a estao destino, o
encaminhamento de um pacote na arquitetura SOS feita em cinco estgios: 1) o ponto
de origem encaminha um pacote para um n especial da rede sobreposta chamado
"ponto de acesso seguro da rede sobreposta" (secure overlay access point - SOAP).
SOAP um n que recebe pacotes cuja legitimidade no foi ainda verificada e executa
essa verificao atravs de algum protocolo seguro (ex: IPsec ou TLS); 2) o SOAP
encaminha o pacote (atravs de outros ns) para o n "guia"; 3) o "guia" encaminha o
pacote para o "servidor secreto", cuja identidade s conhecida por ele; 4) o "servidor"
secreto encaminha o pacote para o destino; e 5) o filtro ao redor do destino permite a
passagem apenas do trfego oriundo de um dos "servidores secretos". Todos os pacotes
so encaminhados entre os ns da arquitetura com o uso de DHT (os autores sugerem o
Chord [51], mas argumentam que outros mtodos podem ser usados).
Este esquema robusto contra ataques de DoS pelos seguintes motivos.
Primeiro, se uma estao SOAP (o ponto de entrada na rede SOS) atacada e falha, as
estaes de origem podem escolher outra estao SOAP disponvel. Se um n interno
da rede SOS atacado, o n simplesmente considerado ausente da rede e o
mecanismo DHT (Chord) se auto-organiza, provendo novos caminhos sobre a rede para
alcanar os "guias". Na rede SOS nenhum n mais sensvel ou mais importante do que
outro e alguma redundncia permite que at mesmo os "guias" e os "servidores
secretos" sejam atacados (por acaso ou propositadamente) sem causar queda de
funcionalidade na rede sobreposta. Segundo, se a identidade de um "servidor secreto"
for descoberta e este for alvo de um ataque, ou se algum ataque partir de um endereo
IP de um "servidor secreto" em direo a uma estao destino, este pode dispor de
mecanismos para trocar o seu conjunto de "servidores secretos".
Observa-se que se um atacante conseguir uma autorizao legtima para envio
de trfego para alguma estao destino, este poder conduzir um ataque de DoS
distribudo (DDoS) usando mltiplas estaes SOAP como multiplicadores de trfego.
Neste caso, os autores discutem que um "guia" ou um "servidor secreto" pode usar
algum mecanismo de pushback
6
para solicitar aos SOAP que revoguem a autorizao da
6
O pushback consiste de um mecanismo de comunicao no qual um roteador sob ataque de DoS solicita
aos roteadores anteriores a ele, considerando o sentido do trfego, que filtrem aqueles pacotes, evitando
estao de origem. A resistncia oferecida pela arquitetura SOS aos ataques de DoS
maior quanto maior for o nmero de ns na rede sobreposta.
3.4.10. Preveno de DoS atravs de Aptido para uso de Recursos
Em [37], Anderson et al. sugerem uma nova abordagem restringir abusos de DoS na
Internet: Preveno de DoS atravs de Aptido para Uso de Recursos (AUR).
Basicamente, ao invs de qualquer estao poder livremente enviar quaisquer dados
para qualquer outra estao a qualquer momento, primeiramente ela deve obter uma
permisso da estao destinatria. Caso o receptor concorde em receber o trfego do
emissor, ele deve emitir uma ficha (que o autor chama de token ou capability) que
habilita o emissor a enviar o trfego em sua direo. Este mecanismo, portanto,
permite rotular cada pacote do trfego legtimo.
O argumento dos autores que qualquer soluo completa para ataques de DoS
deve permitir o controle do uso dos recursos por parte do seu proprietrio, o que inclui a
possibilidade de impor limites para o uso do recurso. Procedendo desta forma, ataques
de IP spoofing podem ser combatidos, pois ambos emissor e receptor concordam com o
envio e recebimento do trfego e, caso a autorizao concedida no esteja presente nos
pacotes recebidos, o trfego deve ser descartado. Na prtica, cada receptor deve gerar
um certificado e envi-lo ao solicitante como sendo a permisso para o envio de dados.
O certificado assinado com a chave privada do receptor e deve constar em cada pacote
subseqente. Portanto, se cada pacote passa a incluir o certificado, roteadores ao longo
do caminho podero verificar que aquele pacote autorizado e podero descartar o
trfego no autorizado. O certificado solicitado e recebido atravs de uma conexo
segura estabelecida para este fim.
Na prtica, a idia a criao de servidores de Solicitao-de-Envio (Request-
to-Send - RTS), que ficam nas fronteiras das redes (poderiam estar junto dos roteadores
que executam BGP) e emitem autorizaes (tokens) aos solicitantes. Os RTS so
acoplados a um outro tipo de servidor, denominado ponto de verificao (Verification
Point VP), que figuram no meio do caminho dos dados e fazem o papel de
controladores de acesso, verificando a existncia de tokens vlidos. Os domnios
autnomos que possuem clientes que desejam filtrar o trfego devem incluir o endereo
IP do seu servidor RTS nos anncios BGP. Os anncios em cadeia criam uma
hierarquia de RTSs e permitem aos remetentes descobrirem para quais RTS devem
encaminhar suas solicitaes de token quando desejam comunicao com um receptor
especfico.
Se uma estao remetente deseja enviar algum trfego, ele envia ao receptor,
atravs da cadeia de RTS dos domnios do caminho, uma solicitao para transmitir. O
receptor decide enviar um token ou no, em funo da disponibilidade de recursos, que
pode tambm envolver polticas de acesso com base no solicitante ou tipo de trfego
etc. Se desejar autorizar, ele fabrica uma seqncia de tokens h
1
, ..., h
K
, onde h
i
so
valores construdos com uma funo de hash de uma via (ex: MD5), fceis de computar
e difceis de quebrar. Cada valor h
i
indica a autorizao para transmitir n pacotes nos
prximos t segundos. Ento, o receptor envia o ltimo valor h
K
, junto com um valor
randmico s
0
que representa a seqncia inicial, para o remetente atravs da mesma
que eles encaminhem trfego que ser descartado adiante, contribuindo assim para a preservao da
largura de banda naqueles enlaces.
cadeia de RTS. Cada servidor RTS associa esses valores com um fluxo a ser permitido
pelo VP a ele acoplado, ou seja, a autorizao dada por todo o caminho reverso do
pedido de solicitao.
Com a autorizao estabelecida e de posse do token inicial h
K
, o remetente est
apto a transmitir. Cada pacote rotulado com o token e um nmero de seqncia e
encaminhado atravs dos VPs do caminho, que verifica a validade do trfego e decide
encaminh-lo ou no em direo ao receptor. Quando n pacotes so encaminhados ou t
segundos so decorridos, o VP invalida o fluxo. Dessa forma, a largura de banda fica
reservada apenas para os fluxos autorizados. Para evitar que o fluxo seja desautorizado
antes que o remetente consiga enviar todos os dados, o receptor envia para o remetente
o componente h
K-1
do token sempre que receber aproximadamente n pacotes, renovando
a autorizao para n pacotes adicionais. O remetente passa ento a usar o novo valor h
K-
1
para os prximos n pacotes e o VP, ao receber um novo token h
K-1
com um nmero de
seqncia vlido, tem como validar o novo valor do token e assumi-lo como o token
vigente para o fluxo usando a mesma funo de hash adotada pelo emissor do token.
Observe que isto possvel porque cada token h
K-x
computado com base na seqncia
do primeiro pacote que ele autoriza, ou seja, o pacote s
0
+n(x+1). Esse mecanismo
requer uma nova autorizao aps nK pacotes transmitidos, o que requer algum critrio
para o estabelecer o valor de K.
A proposta discute tambm mecanismos para garantir que os prprios servidores
RTS no sejam submetidos a ataques de DoS, sugerindo que estes somente aceitem
trfego de clientes locais ou de servidores RTS vizinhos (conhecidos a partir de
anncios BGP). A proposta como um todo apresenta uma soluo que pode ser
implementada de forma incremental, ou seja, pode ser adotada atravs de parcerias entre
domnios sem interferir na Internet atual at que todos os domnios estejam totalmente
integrados.
3.5. Sntese das Propostas
A seo 3.3 apresentou as principais questes de projeto que hoje representam
problemas no devidamente solucionados na atual arquitetura da Internet. Por outro
lado, a seo 3.4 apresenta novas arquiteturas com propostas de mudanas cujo objetivo
compatibilizar a Internet atual com os seus princpios fundamentais ou permitir uma
evoluo da direo de demandas, tecnologias ou problemas no identificados
inicialmente. Esta seo procura apresentar uma sntese das principais modificaes
propostas pelas arquiteturas apresentadas na seo 3.4, relacionando-as e classificando-
as de acordo com as questes de projeto apresentadas na seo 3.3. A Tabela 3-1
apresenta uma relao de todas as propostas com as questes de projeto, que sero
detalhadas nas prximas sub-sees.
Tabela 3-1 Relao entre propostas e questes de projeto
Funo
Proposta
Endereamento,
Nomeao
Roteamento Segurana Mobilidade Transparncia Camadas
LNA
FARA
NIRA
IPNL
RBA
Plutarch
SFR
i3
SOS
AUR
7

3.5.1. Endereamento e Nomeao
A questo da camada de rede na arquitetura atual da Internet que acopla, atravs do uso
do endereo IP, a localizao do n na rede (endereamento) sua identidade
(identificao) em um nico atributo, gerou um grande nmero de propostas para sua
atualizao ou sua inteira substituio. Diversas solues para os problemas da proposta
original do IP vm sendo apresentadas, algumas com objetivos especficos de tratar
mobilidade, segurana e roteamento etc, e outras de propsito mais geral onde diversos
problemas so supostamente solucionados com uma nica mudana, como FARA.
A arquitetura FARA prov um arcabouo consistente e de alto-nvel com a
definio um conjunto abstrato e modular de componentes e suas relaes. Utilizando
dois nveis conceituais, entidades e associaes em um nvel e o substrato de
comunicao em outro nvel, o modelo elegantemente separa localizao de
identificao. Desta forma, devido generalidade da arquitetura e atravs de um
processo de instanciao, possvel desenvolver estratgias independentes e distintas
para endereamento, nomeao e mobilidade, entre outras.
LNA cria um novo endereo fim a fim e desacoplam a identificao da
localizao. O EID para identificao e o endereo IP para localizao/roteamento
(esse o aspecto de roteamento). Em comparao com FARA, LNA adota estratgias
similares. Porm, FARA sendo um arcabouo para instanciao de modelos, tem a
vantagem da abstrao, onde diversas solues especficas podem ser derivadas.
IPNL mantm o acoplamento de localizao e identificao, atravs do endereo
IPNL e inclusive permite que o prprio FQDN seja usado para essa finalidade (alm do
endereo IPNL). Ou seja, IPNL cria tambm um novo endereo, o IPNL. IPNL permite
o uso de endereos IP distintos dentro de cada regio, que vo sendo trocados por novos
endereos IP medida que um pacote vai passando de uma regio para outra.
Plutarch permite endereos completamente distintos dentro de cada contexto.
Um contexto de Plutarch basicamente uma regio de IPNL, mas que permite redes
mais heterogneas. Por exemplo, Plutarch permite que redes de sensores tenham
7
Preveno de DoS atravs de Aptido para uso de Recursos
endereos que no sejam IP, porque, por exemplo, os sensores no tm capacidade de
implementar uma pilha TCP/IP. As funes intersticiais devem fazer o mapeamento
desses endereos.
Em termos de nomeao, a Internet dispe de um mecanismo nico e rgido para
resoluo de nomes em endereos IP (DNS). Assim, a movimentao e replicao de
contedo (ex:, objetos Web) s possvel atravs de mecanismos auxiliares a estes
servios, restringindo sua flexibilidade. Para esta questo de projeto, a infra-estrutura
SFR aparece como uma importante alternativa para solucionar os problemas de
migrao e replicao de objetos, para as aplicaes que utilizem alguma forma de
servio de resoluo de referncias (RRS). Um exemplo tpico a Web, onde
necessrio um RRS, neste caso o DNS, para mapeamento de URLs s suas localizaes
na rede. Ao invs de adotar uma estratgia de substituio integral do DNS ou de
funcionalidade equivalente, a proposta do SFR aborda a questo partindo do ponto de
vista que as referncias no deveriam ter semntica legvel ao usurio ou conter
informaes sobre domnios onde elas esto localizadas. O SFR mantm as funes
originais do DNS e utiliza-se de seus recursos, podendo ser interpretado como servios
complementares.
3.5.2. Roteamento
A arquitetura de roteamento atual da Internet apresenta diversos problemas, tais como
falta de um adequado nvel de competio de mercado entre os sistemas autnomos,
presena de um modelo no-unificado de segurana e roteamento, escalabilidade,
instabilidade e convergncia. Alm disso, diversos trabalhos apontam que uma
arquitetura de roteamento adequada deveria suportar recursos especiais (e.g., suporte
mobilidade), porm com a utilizao de procedimentos simples com consumo mnimas
de recursos nos roteadores.
Uma soluo para o problema de competitividade entre os sistemas autnomos
descrita no projeto de uma nova arquitetura de roteamento chamada NIRA. A inovadora
arquitetura NIRA tem como principal objetivo permitir ao usurio a possibilidade de
escolha das rotas no nvel de domnio. Vrios desafios de ordem prticas foram
abordados nesta proposta, tais como os mecanismos de descoberta e representao de
rotas, sempre observando os requisitos de escalabilidade, robustez, eficincia etc., que
foram cuidadosamente considerados.
As conseqncias da criao de um novo endereo fim a fim da arquitetura
IPNL so alteraes nos mecanismos de roteamento, com a possibilidade de se fazer um
roteamento por FQDN. J no modelo de arquitetura FARA, o substrato de comunicao
o componente responsvel pela entrega de pacotes s entidades. Apesar de ser um
modelo para instanciao e no fornecer detalhes sobre estratgias de encaminhamento,
a arquitetura assume que o substrato de comunicao deve possuir mecanismos no
orientados conexo para entrega dos pacotes das associaes
3.5.3. Segurana
Ataques de DoS so os mais temidos na Internet, porque so fceis de fazer e difceis de
combater. Muitas propostas j foram feitas para combat-los, mas no se conhece um
mecanismo que seja completamente eficiente na arquitetura da Internet atual.
A abordagem da proposta SOS no resolve completamente o problema de DoS
na Internet, mas consegue grandes avanos. A idia criar um nvel adicional (rede
sobreposta) sobre o nvel IP para estabelecer filtros de trfego ao redor de uma estao,
tal como um grande firewall distribudo. Alm disso, as estaes precisam solicitar
autorizao para enviar dados para outra estao, atravs dos pontos de acesso seguros
(SOAP). Outra idia interessante da proposta SOS que os ns da rede sobreposta
assumem papis aleatoriamente, e a idia dos "servidores secretos" que formam a malha
de filtro de uma estao reduz sobremaneira a possibilidade de ataques contra a infra-
estrutura, principalmente quando a rede SOS grande. Alm disso, se isso ocorrer, a
estao atacada desligada sem interferir na rede SOS, graas grande resilincia
conferida rede sobreposta pelo mecanismo DHT.
A proposta para preveno de DoS atravs de Aptido para uso de Recursos
(AUR) tambm se baseia na idia de restringir a comunicao apenas para estaes
autorizadas. Diferentemente da rede SOS, entretanto, esse mecanismo no prope uma
rede sobreposta, mas a incluso de dois elementos cruciais na borda dos domnios
autnomos: o servidor RTS (request to send) e o VP (verification point). Esses
servidores podem ser fisicamente separados ou em uma nica estao (geralmente um
roteador), mas atuam de forma integrada. O servidor RTS quem intermedia o pedido
de autorizao para envio de trfego para uma estao daquele domnio, ou participa do
encaminhamento de um pedido de autorizao que cruza o seu domnio em direo ao
domnio vizinho. A autorizao concedida pela estao destino e o RTS informa ao
VP alguns parmetros que iro garantir a passagem do trfego oriundo da estao
emissora. A autorizao a abstrao de uma "ficha" implementada por hashes (ex:
MD5), os quais so difceis de forjar, mas fceis de verificar. Cada pacote do fluxo deve
carregar a ficha que verificada pelo VP e o trfego pode ser liberado, barrado, ou
suavizado a uma taxa definida pela estao destino.
Considerando as propostas SOS e a AUR, ambas so consideradas "proativas"
(evitam o DoS ao invs de apenas combat-los) e podem ser implantadas de forma
incremental e gradativa, mas o impacto na estrutura atual da Internet menor com a
SOS, que se trata de uma rede sobreposta e, portanto, no faz exigncias de alterao na
camada IP. O esquema DHT usado nas redes sobrepostas, entretanto, pode introduzir
atrasos de roteamento quando os ns logicamente prximos esto na verdade
geograficamente distantes. Embora uma anlise mais detalhada seja requerida, a
proposta AUR pode introduzir menor atraso mdio, mesmo tendo que verificar a
autenticidade de cada pacote do fluxo.
3.5.4. Mobilidade
Mobilidade no foi um requisito considerado pelo IP durante sua especificao original,
em funo de que praticamente no havia essa necessidade poca. O IP mvel
(MIPv4), portanto, um ajuste na Internet original, que, apesar de elegante, ainda
apresenta alguns problemas, como discutido na seo 3.3.4.
Muitos dos problemas enfrentados pelo MIPv4 so resolvidos naturalmente no
MIPv6 [53], visto que o IPv6 oferece mobilidade nativa. Entretanto, o fato de que a
estao mvel recebe um novo endereo IP da rede visitada basicamente a fonte de
boa parte dos problemas, pois a Internet atual usa o endereo IP como localizador da
rede e identificador do sistema final. Outra parte dos problemas podem ser atribudos
falta de transparncia introduzida pelos intermedirios (firewalls, NATs) e VPNs.
A Arquitetura de Nomes em Camadas [1] prope a separao semntica da
identificao do servio (ou informao) da estao onde ela reside e introduz o
conceito de identificador de servio (SID) e identificador da estao final (EID). Com a
introduo de nveis adicionais para nomeao, essa arquitetura permite localizar
estaes atravs do EID, independentemente da sua localizao fsica ou topolgica, o
que acaba sendo um benefcio para a mobilidade. Ou seja, se uma estao se movimenta
para outra rede e recebe outro endereo IP, ela manter a ligao com o seu EID, e
apenas precisa atualizar o seu IP para a camada de resoluo de EIDs.
Outra proposta que traz benefcios para a mobilidade a arquitetura i3 [30],
pois sugere uma rede sobreposta capaz de manter a conectividade fim-a-fim entre as
estaes mveis atravs da atualizao de "gatilhos" (vide seo 3.4.8). Quando uma
estao se move de uma sub-rede para outra e troca o endereo E
1
para outro endereo
E
2
, ela deve atualizar os gatilhos de (id, E
1
) para (id, E
2
), para que todos os pacotes que
contm o rtulo id sejam encaminhados para o novo endereo. A estao emissora no
precisa tomar conhecimento da mobilidade do receptor, uma vez que os pacotes so
roteados com base no identificador. Dessa forma, ambas as estaes emissora e
receptora podem se mover simultaneamente.
3.5.5. Transparncia Fim a Fim
De acordo com a seo 3.3.5, o princpio da transparncia da Internet original pode ser
definido por duas caractersticas: 1) a existncia de um endereo com semntica fim a
fim; 2) a rede se comportar como uma caixa preta, sem alterar o contedo dos
pacotes. Essa seo discute as propostas de mudanas, com relao sua abordagem
dessas duas caractersticas.
A arquitetura LNA (e tambm DOA [31], que uma especializao de LNA) so
direcionadas para tratar de aspectos da camada de rede. LNA restaura a semntica fim a
fim dos endereos (perdida na Internet atual), introduzindo um novo endereo, o EID.
Ele somente usado para identificar os sistemas finais, no tendo nenhuma utilizao
para localizao e roteamento. Essa ltima funo continua com os endereos IP, que
tm semntica limitada nas regies. LNA permitem que haja processamento nos
pacotes, mas sob controle dos sistemas finais, que delegam essa funo explicitamente
aos intermedirios, incluindo-os na arquitetura de maneira natural.
IPNL tambm cria novos endereos fim a fim, os endereos IPNL e tambm
permite que o FQDN seja usado como endereo. Na realidade, o endereo mais estvel
o prprio FQDN. Os intermedirios (NATs) so incorporados sem costuras
arquitetura, como nl-routers, que para os roteadores so vistos como sistemas finais.
Desse modo, na camada IPNL o pacote no alterado significativamente. Por outro
lado, na camada IP os endereos so alterados a cada regio. Como o significado dos
endereos IP restrito a cada regio, ento se pode dizer que IPNL tambm preserva a
caracterstica da caixa-preta, porque os nl-routers so vistos como sistemas finais pelos
roteadores (ou seja, o trfego destinado a eles na camada IP, quando o sistema final
est em outra regio).
Em RBA, nenhum tratamento dado aos endereos fim a fim. No entanto, a
arquitetura incorpora mudanas nos pacotes de maneira natural, pelos papis, sob o
controle dos sistemas finais. Desse modo, assim como nas outras propostas, a integrao
dos sistemas finais ocorre de maneira natural (e no forada, como na Internet atual,
onde pacotes freqentemente so seqestrados, ex: nos proxies transparentes).
Plutarch rompe de maneira radical com o conceito de transparncia fim a fim.
Por um lado, cada contexto pode ter o seu prprio esquema de endereamento e o
mapeamento entre endereos deve ser realizado pelas funes intersticiais. Por outro
lado, essas funes permitem que os pacotes sejam modificados no trnsito de origem a
destino, com um controle explcito por parte da administrao da rede (e no do sistema
final, como ocorre em LNA e RBA).
3.5.6. Modelo em Camadas
O modelo em camadas utilizado na Internet possui vrias vantagens, como
modularidade, encapsulamento e regras rgidas e organizadas para o processamento dos
cabealhos. No entanto, esses princpios tm sido violados na Internet atual, porque
cada vez mais dispositivos (por exemplo, os intermedirios) lem e escrevem
informaes nos cabealhos de outras camadas. DOA uma arquitetura que no altera o
modelo em camadas, mas tenta evitar a sua violao conceitual. Atravs da delegao
explcita de certas atividades para intermedirios, os sistemas finais os identificam
como locais legtimos de processamento dos cabealhos de vrias camadas.
No entanto, DOA no se prope a solucionar outros problemas que ocorrem na
prtica com o modelo em camadas, como a falta de eficincia e a incapacidade de alocar
de certas funes a camadas especficas. Entre as arquiteturas estudadas, RBA a nica
que explicitamente questiona se o modelo em camadas continua sendo a melhor
abstrao para software de rede e prope um modelo alternativo baseado em papis,
onde a pilha de protocolos trocada por um amontoado de protocolos. Fazendo isso,
ela troca a violao entre as camadas por interaes explcitas entre papis e oferece a
possibilidade de ganhos de eficincia no processamento. No entanto, no simples
organizar esse processamento no software dos sistemas finais e intermedirios, de modo
a haver uma colaborao efetiva entre todos os seus componentes. Por outro lado, a
implementao de RBA exigiria uma modificao completa na Internet, inclusive no
funcionamento dos roteadores.
3.6. Comentrios Finais
Apesar do seu enorme sucesso, a arquitetura da Internet amplamente reconhecida
como sendo longe do ideal. O seu crescimento, penetrao e importncia tm realado
muitas das suas imperfeies e aumentado a urgncia pelas respectivas solues [1]. A
necessidade por mudanas arquiteturais nunca foi to forte, como mostra a exploso de
crticas e novas propostas oriundas da comunidade cientfica (ex: LNA [1], FARA [11],
NIRA [32], IPNL [16], DOA [31], RBA [2], Plutarch [13], i3 [30], SOS [41] e muitas
outras), as quais abordam vrios aspectos da arquitetura da Internet: endereamento,
roteamento, nomeao, modelo de camadas, transparncia, segurana, mobilidade.
Este documento apresentou uma viso crtica sobre a Internet, no das questes
corriqueiras do dia a dia, como aplicaes, usurios, desafios de engenharia de curto
prazo, mas das questes abstratas da sua arquitetura, cuja repercusso pode ser sentida a
mdio e longo prazo. A abordagem adotada procurou seguir uma viso didtica em
cinco fases, as mesmas que foram trilhadas pelos autores (no necessariamente na
mesma ordem) no estudo e descoberta das informaes apresentadas. Primeiramente,
uma viso de onde partiu e aonde chegou a Internet. Depois, uma viso da arquitetura
original da Internet, as decises pragmticas adotadas na Internet atual, as questes que
deveriam ser tratadas para seguir um caminho coerente de evoluo, as propostas de
mudanas e a sumarizao e comparao dessas e propostas. Ao final, discutiremos a
seguir uma sexta fase, onde se questionam as reais possibilidades de evoluir a
arquitetura da Internet de maneira significativa.
3.6.1. possvel mudar a Internet?
Evoluir a Internet atual no uma tarefa fcil (seo 3.1.1), principalmente na cintura
fina da ampulheta de protocolos (seo 3.2.5). A Internet original foi projetada para
incorporar mudanas na sua estrutura de modo natural, mas aos poucos foi perdendo
essa caracterstica. Atualmente, as evolues mais comuns esto nas partes mais largas
da ampulheta, ou seja, nas aplicaes (ex: p2p) e nas tecnologias (ex: IP sobre redes
ticas). Por isso, algumas perguntas so pertinentes: At que ponto possvel mudar a
arquitetura da Internet? Com que velocidade isso pode ser feito? Qual o custo?
Um bom ponto de partida a transio de IPv4 para IPv6. Existem vrias razes
para a Internet migrar para IPv6, mas tambm vrios empecilhos, como por exemplo, a
falta de um bom modelo de negcios que efetivamente traga benefcios aos provedores,
diante da enorme tarefa e do alto custo que eles devem encarar. Apesar do esforo de
definio do novo protocolo ter produzido seu primeiro padro em dezembro de 1995
(RFC 1883
8
), at o presente momento a implantao comercial do IPv6 ainda pode ser
considerada incipiente. Existem muitos esforos sendo feitos para que isto ocorra (ex: o
Frum IPV6, www.ipv6forum.org) e empresas significativas j esto trabalhando no seu
suporte (como o Google). No entanto, no se sabe ainda quando haver uma real
transio para este novo protocolo.
A lio importante sobre a transio para o IPv6 que mesmo uma pequena
mudana, mas que afeta grande parte da infra-estrutura da Internet, pode ser
considerada de grande complexidade. Principalmente, deve haver uma forte razo
econmica para viabiliz-la. A mudana para IPv6 considerada pequena porque afeta
principalmente o tamanho do endereo IP, que passa de 32 bits para 128 bits. No
entanto, ela implica em uma mudana nos roteadores, ou seja, no ncleo da rede. Como
uma grande instabilidade na Internet pode ser gerada, a transio motivo de
preocupao. Por outro lado, uma grande quantidade de sistemas finais (clientes e
servidores) deve ser modificada tambm, gerando uma possvel inconvenincia aos
usurios.
Aparentemente, a melhor forma de se implementar uma modificao consistente
na Internet possibilitar aos seus usurios usufruir dela antes que a arquitetura tenha
que ser alterado. Isto possvel em caso de tcnicas de sobreposio de redes (overlay),
que acrescentam suas funcionalidades sobre a camada IP atual. Um bom exemplo so as
redes p2p, que constroem redes sobrepostas, com endereamento e roteamento prprios.
Muito se tem discutido de embutir o roteamento p2p nos roteadores, mas por enquanto a
comunidade est conseguindo obter os benefcios sem que esse sacrifcio seja
necessrio. Por outro lado, algumas vezes redes sobrepostas podem ter um desempenho
abaixo do aceitvel, o que pode comprometer a sua aceitao.
8
Posteriormente, substituda pela RFC 2460, de dezembro de 1998 (www.ietf.org/html.charters
/ipv6-charter.html).
Considerando as propostas analisadas na seo 3.4, um mtodo de identificar a
sua factibilidade avaliar o nvel de evoluo (incremental) ou revoluo (radical)
necessrio sua implantao. Por exemplo, as propostas SOS e i3 so baseadas em
sobreposies, de modo que sua implantao seria facilitada. Outras propostas exigem
mudanas na arquitetura, mas apenas nas suas bordas. As arquiteturas LNA e DOA no
necessitam que os roteadores sejam modificados, mas apenas que os sistemas finais. A
vantagem no afetar a estabilidade dos provedores. Por outro lado, outras propostas
assumem mudanas drsticas na arquitetura, ou seja, a sua adoo levaria a uma outra
Internet, pelo menos na camada de rede. Exemplos so FARA, RBA e Plutarch.
Respondendo diretamente pergunta dessa seo, a resposta : Sim, possvel
mudar a Internet. Porm, tudo tem seu custo
9
. Nesse caso, o custo pode ser financeiro,
operacional, poltico e at mesmo social. Propostas mais simples, ou que afetam menos
drasticamente a cintura da ampulheta tm maior chance de vingar. Finalmente, outra
pergunta vem tona: Por que tipo de benefcio a comunidade da Internet est disposta
a arcar com qual custo?. A resposta a essa pergunta subjetiva.
3.6.2. As Doze Verdades sobre Redes: Humor ou Ironia?
A RFC 1925 [54], de 1
o
de abril de 1996
10
, identifica doze verdades
fundamentais sobre redes, que misturam humor com ironia, alm de, obviamente, muita
verdade aprendida com a experincia. As propostas de novas arquiteturas para a Internet
devem ser avaliadas de acordo com essas verdades, para impedir que erros passados no
sejam cometidos novamente. A primeira verdade diz que afinal de contas tudo tem que
funcionar, sendo portanto fiel ao lema da Internet que preconiza cdigo executando.
Em outras palavras, no pode apenas ser algo com potencial terico, mas tem que ser
validado pela experincia prtica. A oitava verdade diz que mais complicado do que
voc pensa, o que inviabiliza, por exemplo, solues incompletas ou ingnuas. Nos
prximos pargrafos, trs verdades que contribuem com a discusso das arquiteturas so
analisadas com mais detalhes.
A terceira verdade contm muito humor. Com impulso suficiente, porcos
podem voar bem. Entretanto, isso no necessariamente uma boa idia. Propostas
extravagantes podem ser colocadas em prtica. No entanto, o custo pode facilmente
ultrapassar os benefcios em muitos nveis de magnitude. Por exemplo, arquiteturas que
promovem grandes mudanas, como Plutarch e RBA, podem apresentar benefcios
tericos, mas o benefcio pode no valer a pena.
A quinta verdade diz que sempre possvel aglutinar vrias problemas
diferentes em uma nica soluo complexa e interdependente; na maioria dos casos isto
uma m idia. Essa verdade um alerta til para barrar logo no incio a tentao de
resolver todos os problemas com uma nica soluo. Experincias anteriores na rea de
computao e especificamente de redes provaram que geralmente a proposta gerada
muito complexa (portanto, contrria aos princpios da Internet). Um timo exemplo o
modelo RM/OSI da ISO, que apesar de apresentar uma grande superioridade ao modelo
da Internet, no resistiu ao inchao de atribuies como camadas, entidades, protocolos,
9
O ditado ingls there is no free lunch ("no existe almoo grtis") retrata bem esta mxima.
10
A IETF publica RFCs no dia 1
o
de abril, com contedo humorstico (www.apps.ietf.org/rfc
/apr1list.html e www.rfc-editor.org/rfcfaq.html).
controles e funcionalidades. Outro exemplo na rea de linguagens de programao a
linguagem PL/1, criada pela IBM nos anos 1960, cujo objetivo foi combinar as
melhores caractersticas de COBOL, FORTRAN e ALGOL. fcil concluir qual foi o
seu destino, pois atualmente a maioria das pessoas nunca ouviu falar dela!
A dcima primeira verdade encerra um fato que repetidamente praticado na
comunidade acadmica. Toda idia velha ser proposta de novo com nome e
apresentao diferentes, independente do fato de ela funcionar ou no. Existe uma
grande tentao em se reaproveitar o prprio conhecimento, valorizando anos de
trabalho e experincia em determinadas reas. Alguns exemplos so expandir o nmero
de camadas, aumentar o nmero de indirees, sugerir solues baseadas em circuitos
virtuais com outro nome, utilizar difuso seletiva (multicast) de modo dissimulado,
reeditar antigas e ineficazes idias de gerenciamento e aplicar QoS em todos os
problemas possveis. Isso no significa que essas idias no funcionam, mas so
tipicamente solues revitalizadas e redirecionadas para solucionar vrios problemas
novos que surgem.
3.6.3. Concluses
Alterar a arquitetura da Internet possvel, mas o nvel da interveno depende do
preo que se dispe a pagar. Por outro lado, deve-se ao mximo procurar aprender com
as experincias de mais de trinta anos no projeto e operao da rede. Essas so duas
concluses das sees anteriores. Outro ponto a observar que os princpios
fundamentais da Internet so ainda as melhores diretrizes disponveis para balizar a
comunidade, visto a grande preocupao das propostas apresentadas em mant-los
sempre que possvel e restaur-los em caso de quebra da sua semntica original.
A viso crtica proporcionada pela compreenso das doze verdades sobre redes
(seo 3.6.2) imprescindvel. Com relao s novas arquiteturas, algumas perguntas
devem ser feitas: vai funcionar?, quais novos problemas podem ser introduzidos por
elas?, a soluo no uma colcha de retalhos mal costurada? e os princpios que
comprovadamente funcionam esto sendo aplicados?. Aparentemente, o grande
desafio projetar uma soluo simples na camada de rede (a cintura fina), mas ao
mesmo tempo poderosa e de grande alcance, com ganchos que permitam que a maioria
dos problemas sejam resolvidos nos sistemas finais e principalmente atravs de
solues incrementais.
Finalmente, os autores deixam um questionamento para o leitor, que trilhou o caminho
da evoluo da Internet atravs da leitura deste documento: "Se fosse possvel comear
de novo, como re-projetar a Internet, considerando as lies aprendidas e as
perspectivas de uso que o futuro aponta?"
Referncias
[1] Balakrishnan, H. et al., A Layered Naming Architecture for the Internet, ACM
SIGCOMM, Setembro de 2004.
[2] Braden, R., Faber, T. & Handley, M., From Protocol Stack to Protocol Heap -
Role-Based Architecture, Hotnets I, Outubro de 2002.
[3] Bradner, S., IETF Working Group Guidelines and Procedures, RFC 2418,
Setembro de 1998.
[4] Bush, R. & Meyer, D., Some Internet Architectural Guidelines and Philosophy,
RFC 3439, Dezembro de 2002.
[5] Carpenter, B. & Brim, S., Middleboxes: Taxonomy and Issues, RFC 3234,
Fevereiro de 2002.
[6] Carpenter, B., Architectural Principles of the Internet, RFC 1958, Junho de 1996.
[7] Carpenter, B., Internet Transparency, RFC 2775, Fevereiro de 2000.
[8] Castineyra, I., Chiappa, N., & Steenstrup, M., The Nimrod routing architecture,
RFC 1992, Agosto de 1996.
[9] Clark, D. & Tennenhouse, D., Architectural Considerations for a New Generation
of Protocols. ACM SIGCOMM, Setembro de 1990.
[10] Clark, D., The Design Philosophy of the DARPA Internet Protocols, ACM
SIGCOMM 88, Agosto. 1988.
[11] Clark, D., Braden, R., Falk, A., & Pingali, V., FARA: Reorganizing the addressing
architecture, ACM SIGCOMM Workshop on Future Directions in Network
Architecture (FNDA), Agosto de 2003.
[12] Clark, D., et al., New Arch: Future Generation Internet Architecture, Final
Technical Report, Dezembro de 2003, http://www.isi.edu/newarch/iDOCS/
final.finalreport.pdf.
[13] Crowcroft, J., Hand, S., Mortier, R., Roscoe, T. & Warfield, A., "Plutarch: an
argument for network pluralism". Computer Communication Review 33(4): pginas
258-266, 2003.
[14] Eriksson, J., Faloutsos, M. & Srikanth, PeerNet: Pushing Peer-to-Peer Down the
Stack, 2
nd
Intl Workshop on Peer-to-Peer Systems (IPTPS '03), Fevereiro de 2003.
[15] Fielding, R. et al., Hypertext Transfer Protocol -- HTTP/1.1, RFC 2616, Junho de
1999.
[16] Francis, P. & Gummadi, R., IPNL: A NAT-extended Internet architecture, ACM
SIGCOMM 2001, Agosto de 2001.
[17] Freed, N., Behavior of and Requirements for Internet Firewalls, RFC 2979,
Outubro de 2000.
[18] Hain, T., Architectural Implications of NAT, RFC 2993, Novembro de 2000.
[19] Houle, K. & Weaver, G., Trends in Denial of Service Attack Technology, CERT
Coordination Center, Outubro de 2001.
[20] ISO, Information Processing Systems - Open Systems Interconnection - Basic
Reference Model ISO 7498, 1984.
[21] Kent, S., & Atkinson, R., Security Architecture for the Internet Protocol, RFC
2401, Novembro de 1998.
[22] Labovitz, C., Ahuja, A., Bose, A. & Jahanian, F., Delayed Internet Routing
Convergence, IEEE/ACM Transactions on Networking, 9(3), Junho de 2001.
[23] Marsan, C., Faster 'Net growth rate raises fears about routers, Network World,
04/02/01.
[24] Meyer, E., ARPA Network Protocol Notes, RFC 46, Abril de 1970.
[25] Perkins, C. et al., IP Mobility Support, RFC 2002, Outubro de 1996.
[26] Roscoe, T., Hand, S., Isaacs, R., Mortier, R., & Jardetzky, P., "Predicate routing:
Enabling controlled networking", 1
st
ACM Hotnets Workshop, Outubro de. 2002.
[27] Saltzer, J., Reed, D. & Clark, D., End-to-End Arguments in System Design. ACM
Transactions in Computer Systems 2(4), pginas 277-288, Novembro de 1984.
[28] Shaikh, A., Varma, A., Kalampoukas, L., Dube, R., Routing Stability in Congested
Networks: Experimentation and Analysis, ACM SIGCOMM, Agosto de 2000.
[29] Srisuresh, P. & Egevang, K., Traditional IP Network Address Translator
(Traditional NAT), RFC 3022, Janeiro 2001.
[30] Stoica, I., Adkins, D., Zhuang, S., Shenker, S. & Surana, S. Internet indirection
infrastructure. SIGCOMM 2002, Agosto 2002.
[31] Walfish, M., et al., Middleboxes No Longer Considered Harmful, USENIX OSDI
2004, Dezembro de 2004.
[32] Yang, X., NIRA: A New Internet Routing Architecture, ACM SIGCOMM
Workshop on Future Directions in Network Architecture (FNDA), Agosto de 2003.
[33] Zhu, D., Gritter, M. & Cheriton, D., Feedback Based Routing, ACM SIGCOMM
Computer Communication Review, 33(1), Fevereiro de 2003
[34] Internet World Stats, Internet Usage Statistics - The Big Picture
http://www.internetworldstats.com/stats.htm, acessado em 14/03/2005.
[35] Shirey, R., Internet Security Glossary, RFC 2828, Maio de 2000.
[36] Howard, J. D. & Longstaff, T., A Common Language for Computer Security
Incidents, Technical Report 98-8667, Sandia National Labs, Outubro de 1998.
[37] Anderson, T., & Roscoe T. & D. Wetherall, Preventing Internet Denial-of-Service
with Capabilities, 2
nd
ACM Hotnets Workshop, Novembro de 2003.
[38] Patrikakis, C., Masikos, M., & Zouraraki, O., Distributed Denial of Service
Attacks, The Internet Protocol Journal, 7(4), Dezembro de 2004.
[39] Cook, D., Morein, W., Keromytis, A., Misra, V. & Rubenstein, D., WebSOS:
Protecting Web Servers From DDoS Attacks, IEEE International Conference on
Networks (ICON), Setembro/Outubro de 2003.
[40] Dalal, M. (editor), Transmission Control Protocol security considerations,
Internet-Draft, Novembro de 2004.
[41] Keromytis, A., Misra, V. & Rubenstein, D., SOS: An Architecture For Mitigating
DDoS Attacks, IEEE Journal on Selected Areas in Communications (JSAC),
Janeiro de 2004.
[42] Clark, D., Sollins, K., Wroclawski, J. & Faber, T., Addressing reality: An
architectural response to demands on the evolving Internet. ACM SIGCOMM
Workshop on Future Directions in Network Architecture, Agosto de 2003.
[43] Ahlgren, B., Brunner, M, Eggert, L., Hancock, R. & Schmid, S., Invariants A
New Design Methodology for Network Architectures, ACM SIGCOMM
Workshop on Future Directions in Network Architecture, Agosto de 2004.
[44] Willinger, W. & Doyle, J., "Robustness and the Internet: Design and evolution",
2002, http://netlab.caltech.edu/pub/papers/part1_vers4.pdf, acessada em
15/03/2005.
[45] Perkins, C. (Editor), IP Mobility Support for IPv4, RFC 3344. Agosto de 2002.
[46] Montenegro, G. (Editor), Reverse Tunneling for Mobile IP, revised. RFC 3024,
Janeiro de 2001
[47] El Malki, K. (Editor), Low Latency Handoffs in Mobile IPv4, Internet Draft,
Junho de 2004.
[48] Vaarala, S., & Klovning, E., Mobile IPv4 Traversal Across IPsec-based VPN
Gateways, Internet Draft. Janeiro de 2005.
[49] Moskowitz, R., Nikander, P., Jokela, P. & Henderson, T. Host Identity Protocol,
draft-ietf-hip-base-02, Internet-Draft, Fevereiro de 2005.
[50] Rocha, J., Domingues, M., Callado, A., Souto, E., Silvestre, G., Kamienski, C. &
Sadok, D., Peer-to-Peer: Computao Colaborativa na Internet, 22
o
Simpsio
Brasileiro de Redes de Computadores (SBRC 2004), Gramado/RS, Maio de 2004.
[51] Stoica, I., Morris, R., Karger, D. R., Kaashock, M. Frans & Balakrishman, H.,
Chord: A scalable peer-to-peer lookup protocol for Internet applications, ACM
SIGCOMM 2001, Agosto de 2001.
[52] Walfish, M, Balakrishnan, H. ,& Shenker, S., "Untangling the Web from DNS". 1
st
Symp. on Networked Systems Design and Impl. (NSDI '04), Maro de 2004.
[53] Johnson, D., Perkins, C., Arkko, J., "Mobility Support in IPv6". RFC 3775, Junho
2004.
[54] Calmon, R., The Twelve Networking Truths, RFC 1925, Abril de 1996.
[55] Leiner, B., et al., The Past and Future History of the Internet, Communications of
the ACM, 40(2), Fevereiro de 1997.