Captulo

2
Interconex o de Redes na Internet do Futuro: a Desaos e Solucoes
Miguel Elias M. Campista, Lyno Henrique G. Ferraz, Igor M. Moraes, Marcelo Luiz D. Lanza, Lus Henrique M. K. Costa e Otto Carlos M. B. Duarte
GTA/PEE/COPPE/DEL-Poli - UFRJ - Rio de Janeiro, Brasil

Abstract This short-course presents the main challenges for network interconnection in the Future Internet. We introduce the shortcomings of the Internet current model and the main proposals to solve them. Among all shortcomings, many are consequence of unforeseen demands by the Internet original design such as: mobility, multi-homing, multi-path, and network scalability. These challenges have been attracting many research efforts in the last few years because of their relevance and complexity. In this short-course, new protocols for network interconnection are presented, from IP extensions to radical proposals to replace IP in the Future Internet. In addition, we introduce new intra- and interdomain routing protocols as well as experimental results obtained with one of these proposals prototypes. Resumo Este minicurso apresenta os principais desaos para a camada de interconex o de redes a da Internet do Futuro. As limitacoes do modelo atual da Internet e as principais propos tas para solucion -las s o apresentadas. Dentre os desaos, muitos s o consequ ncias a a a e de demandas n o previstas pelo projeto inicial da Internet, como: mobilidade, redes mula tidomiciliadas, m ltiplos caminhos e escalabilidade da rede. Esses desaos t m atrado u e muito investimento em pesquisa nos ultimos anos devido a relev ncia e a complexidade a ` ` do tema. Neste minicurso, s o apresentados novos protocolos para interconex o de rea a des, desde extens es do IP at propostas radicais para substituir o IP na Internet do o e Futuro. Al m disso, propostas para novos protocolos de roteamento intra e interdomnio e s o apresentadas, bem como resultados pr ticos obtidos com um dos prot tipos dessas a a o propostas.

2.1. Introducao
No incio dos anos 80, a Internet surgia com a adocao da pilha de protocolos TCP/IP. Naquela epoca, a Internet era composta por estacoes xas de grande porte cujas principais aplicacoes eram o acesso remoto e a troca de arquivos. Nesse cen rio, o IP (In a ternet Protocol) tinha como objetivo atender requisitos fundamentais como interconectar redes, prover conectividade m-a-m e garantir acessibilidade global [Clark et al. 2004]. Esses requisitos deviam ser atendidos seja qual fosse a aplicacao e a tecnologia de con trole de acesso ao meio utilizada. Al m do IP, os protocolos de roteamento tamb m e e eram utilizados na interconex o de redes. Esses protocolos cumpriam o mesmo papel a dos protocolos de roteamento atuais. Entretanto, eles podiam calcular os menores caminhos entre qualquer par origem-destino, j que a Internet era composta por poucos n s a o e era apenas subdividida em poucas redes de instituicoes sem ns lucrativos. Cada ro teador, por conseguinte, conhecia o melhor caminho disponvel para qualquer uma das redes da Internet. Um exemplo disso, foi o projeto do GGP (Gateway-to-Gateway Protocol) [Hinden e Sheltzer 1982] que foi um dos primeiros protocolos de interconex o de a redes. O GGP listava em suas mensagens de atualizacao as dist ncias em n mero de a u saltos para todas as redes da Internet e suportava at no m ximo 256 redes. e a Nos anos seguintes, o n mero de usu rios e de redes na Internet aumentou aceu a leradamente. Esse aumento tornou as atualizacoes de topologia mais frequentes e as atualizacoes do GGP mais complexas, visto que cada uma das redes era administrada por grupos ou instituicoes diferentes. Al m disso, havia mais de uma vers o do GGP e a em uso, o que dicultava a interoperacao das redes. Essas diculdades levaram a In ternet a ser dividida em Sistemas Aut nomos (Autonomous Systems - ASes), denidos o como um conjunto de redes e roteadores administrados por um grupo ou uma instituicao comum. Cada Sistema Aut nomo escolhe o seu pr prio protocolo de roteamento ino o terno, chamado protocolo intradomnio, e para se comunicar com redes em outros Sis temas Aut nomos, utiliza um protocolo interdomnio. O protocolo interdomnio era coo mum a todos os ASes j que as informacoes de roteamento precisam ser trocadas para a manutencao global da conectividade. O primeiro protocolo interdomnio desenvolvido foi o EGP (Exterior Gateway Protocol) [Mills 1984] que tamb m sucumbiu devido a e problemas de escalabilidade. O EGP foi substitudo pelo BGP (Border Gateway Proto col) [Lougheed e Rekhter 1989] que se tornou o protocolo interdomnio da Internet. A organizacao da Internet de hoje e a mesma que surgiu ap s a sua divis o em o a Sistemas Aut nomos. Al m disso, a Internet ainda deve atender todos os seus requio e sitos fundamentais, pois foi por isso mesmo que se tornou o sucesso de hoje. Outra caracterstica mantida foi o crescimento do n mero de ASes e, consequentemente, de u redes. Dados mostram que a Internet atual consiste de 7,4 milh es de redes compostas o por no m ximo 254 estacoes (redes /24). Essas redes representam 95% de todas as rea des alcancaveis da Internet [Caida 2010]. Outros dados mostram que o crescimento da Internet foi de 380,3% de 2000 at 2009 [Internet World Stats 2010]. Tal crescimento e e impulsionado pela oportunidade de neg cios e pela popularizacao da Internet. A oportuo nidade de neg cios surgiu da necessidade de tr nsito de dados entre ASes n o conectados o a a diretamente. Essa necessidade levou a acordos entre ASes vizinhos que est o no camia nho entre pares origem-destino para transporte de dados. J a popularizacao da Internet a e consequ ncia da facilidade e rapidez na obtencao de informacoes proporcionadas para e

usu rios corporativos e residenciais que pagam os provedores de acesso pelo servico. a Assim como ocorreu no passado, mais uma vez a Internet est chegando a um a ponto onde mudancas se tornam essenciais. O sucesso da Internet n o vem sem con a sequ ncias. Mesmo os protocolos atuais como o BGP e o pr prio IP v m apresene o e tando sinais de fadiga. Um indicativo disso e o BGP ter sido proposto em 1989 e ter sido atualizado at a sua vers o quatro em apenas seis anos [Lougheed e Rekhter 1989, e a Rekhter e Li 1995]. Em 2006, o BGP-4 foi atualizado novamente para corrigir erros de edicao de RFCs (Request For Comments) anteriores [Rekhter et al. 2006]. Embora o BGP seja fundamental, os problemas dele tamb m s o oriundos das pr prias limitacoes do IP, e a o que n o acompanhou no mesmo passo a evolucao da Internet. Portanto, al m dos problea e mas relacionados ao crescimento da Internet, nem o projeto inicial do IP nem tampouco dos protocolos de roteamento existentes foram desenvolvidos tendo em vista a possibilidade de evolucoes para atender demandas emergentes. Dentre essas demandas, as ` mais relevantes s o o suporte a mobilidade, o suporte aos m ltiplos domiclios (multia u homing), o suporte aos m ltiplos caminhos e a escalabilidade dos roteadores. Embora u ` novas propostas ou extens es tenham surgido como resposta as novas demandas, p. ex. o o IPv6 [Deering e Hinden 1998], o IP m vel [Perkins 2002] e o multicast [Deering 1988, o Costa et al. 2006], nenhuma delas solucionou o problema por completo, e em alguns casos, nem foram aplicadas na pr tica. a Atualmente, investiga-se qual a melhor abordagem a ser tomada naquela que ser a a Internet do Futuro. Dentre as possveis, est o a ruptura total com o modelo atual da In a ternet e o consequente surgimento de novos protocolos para cumprir um papel semelhante ao do IP [Crowcroft 2008] ou a continuidade da elaboracao de novas extens es aos proto o colos [Ratnasamy et al. 2005]. A primeira abordagem pode ir de encontro aos interesses dos administradores dos ASes que j possuem base instalada operacional. J a segunda a a abordagem pode apenas adiar o problema enfrentado atualmente. Um ponto importante e a possibilidade de novos protocolos inclurem todas as novas demandas emergentes ou deixarem ainda algumas como casos a parte. Em comum, pode-se destacar que a nova proposta dever ser escal vel e capaz de evoluir para atender os futuros avancos da Intera a net. Este captulo apresenta os principais desaos em interconex o de redes na Internet do a Futuro, bem como as limitacoes do modelo atual e as propostas para solucion -las. Adi a cionalmente, alguns dos novos protocolos de roteamento assim como resultados experimentais s o apresentados. Este captulo est organizado da seguinte maneira. A Secao 2.2 a a apresenta a arquitetura atual da Internet e as denicoes empregadas neste captulo. A Secao 2.3 discute os principais desaos enfrentados na Internet atual para prover servicos como: mobilidade, m ltiplos domiclios, m ltiplos caminhos, caminhos program veis e u u a escalabilidade dos roteadores. Essa secao ainda apresenta as limitacoes da arquitetura atual que impedem que tais servicos sejam oferecidos plenamente. A Secao 2.4 descreve os novos conceitos da area para aprimorar a interconex o de redes na Internet do Futuro, a bem como suas principais propostas. A Secao 2.5 apresenta resultados experimentais ob tidos com prot tipos de uma das novas propostas para a Internet do Futuro. Por m, a o Secao 2.6 conclui este captulo.

2.2. Arquitetura Atual da Internet

A arquitetura atual da Internet e composta por diferentes redes interconectadas atrav s do IP. As redes administradas pela mesma instituicao s o denominadas Sistee a mas Aut nomos (ASes). Cada AS executa um protocolo de roteamento intradomnio o para interconectar seus pr prios roteadores enquanto os diferentes ASes executam um o protocolo de roteamento interdomnio para se comunicarem. Essa arquitetura e uma evolucao da arquitetura original da Internet que era apenas subdividida em redes de instituicoes diferentes. A Figura 2.1 mostra a topologia da Internet no incio dos anos 80 [History Museum 2010]. A posicao de um AS na topologia da Internet pode ser usada para classicacao. Um AS diretamente conectado aos usu rios e denominado de AS de borda ou provedor a ` de acesso. Tais ASes tarifam os usu rios pelo acesso a Internet. Os usu rios normala a mente est o localizados em redes de acesso, que tamb m podem ser denominadas de a e redes stub. As redes stub conhecem apenas um caminho para outras redes. Esses caminhos s o chamados de rotas default j que s o sempre utilizadas para alcancar qualquer a a a outra rede. As rotas default s o anunciadas para as estacoes da rede de acesso pelo ponto a de interconex o (gateway) da rede. Uma rede de acesso recebe uma faixa de enderecos IP a ` pertencente a faixa do AS de borda. Essa faixa e utilizada para atribuicao de enderecos as ` estacoes da rede. Logo, o prexo comum dos enderecos IP das estacoes pode ser usado para identicacao da rede. Da mesma maneira, um endereco IP identica uma estacao.

Figura 2.1. A Internet no incio do anos 80.

Os ASes que n o prov em acesso diretamente a usu rios formam o n cleo da a e a u Internet. Esses ASes s o conhecidos como ASes de tr nsito por oferecerem servicos de a a transfer ncia de dados entre ASes. Os ASes de tr nsito s o respons veis por encaminhar e a a a todo o tr fego entre as bordas da Internet. Para isso, assume-se que toda origem e destino a de tr fego est o localizados na borda da rede. Essa premissa est de acordo com um dos a a a requisitos da Internet que e a manutencao da intelig ncia nas bordas para que o n cleo e u seja simples. Os ASes de tr nsito tarifam os seus ASes vizinhos, sejam eles de borda ou a outros de tr nsito, dependendo do tipo de acordo estabelecido e da quantidade de tr fego a a injetado pelo vizinho no AS de tr nsito. a As instituicoes respons veis pelos ASes de tr nsito s o denominadas de provedo a a a res de servico da Internet (Internet Service Providers - ISPs). Os ASes de tr nsito normal a

mente n o possuem rotas default. Para isso, assume-se que os ISPs possuem vis o global a a de todos os ASes da Internet. A aus ncia de rotas default rendeu ao conjunto de ASes de e tr nsito o nome de zona livre de rota default (Default Free Zone - DFZ). A Figura 2.2 mosa tra a arquitetura atual da Internet e as suas subdivis es em Sistemas Aut nomos (ASes). o o Os ASes de borda possuem ligadas a eles as redes de acesso dos usu rios. a

Figura 2.2. A arquitetura da Internet atual.

Duas denicoes importantes que ser o usadas posteriormente s o a FIB (Forwar a a ding Information Base) e a RIB (Routing Information Base). A FIB e a RIB s o tabelas a com funcoes distintas utilizadas pelos roteadores da Internet. A FIB e a tabela de rote amento que e consultada sempre que o roteador recebe um pacote. Ap s uma consulta o ` a tabela de roteamento, o roteador encaminha o pacote recebido pela interface de sada correspondente ao caminho escolhido para alcancar a rede de destino. A RIB, em contra partida, e a base de dados que e utilizada para construir a FIB. Por exemplo, no protocolo OSPF (Open Shortest Path First), a FIB cont m o mapa conhecido da topologia da rede. e As FIBs s o construdas para acelerar a consulta a interfaces de sada enquanto as RIBs a s o construdas para tornar a atualizacao da base de dados mais r pida. A Figura 2.3 a a ilustra um esquema b sico de um roteador. A gura mostra o caminho percorrido pelos a pacotes de controle (caminho de controle) e pelos pacotes de dados (caminho de dados).

Figura 2.3. Esquema basico de um roteador atual.

2.3. Desaos em Interconex o de Redes a

` Muitos dos desaos enfrentados pela Internet atual est o diretamente ligados a sua a arquitetura e ao crescimento acelerado do n mero de estacoes e redes. A arquitetura oriu ginal da Internet n o previu o suporte a servicos como mobilidade, m ltiplos domiclios, a u m ltiplos caminhos e programabilidade de caminhos. Esta secao discute os principais u desaos da interconex o de redes e do roteamento na Internet do futuro. a

Mobilidade ` A disseminacao das redes sem-o e um dos principais desaos a arquitetura origi nal da Internet. As redes sem-o possibilitam que as estacoes se movimentem. Logo, uma vez que a arquitetura original da Internet n o previa a mobilidade, muitas das solucoes utia lizadas n o se adequam a essa caracterstica. Um exemplo tpico e o funcionamento do a TCP (Transmission Control Protocol) em redes sem-o [Hanbali et al. 2005]. O TCP foi desenvolvido para uso na Internet cabeada. Por isso, esse protocolo considera que atrasos na recepcao de reconhecimentos positivos ou perda de pacotes s o devido a congestio a namentos na rede j que as perdas por erro de transmiss o s o negligenci veis. Assim, a a a a para evitar o colapso da rede, as fontes TCP reduzem as suas taxas de transmiss o quando a detectam perdas. Nas redes sem-o essa mesma premissa pode n o ser mais verdadeira a visto que as perdas por erro de transmiss o s o consider veis. Portanto, reduzir a taxa de a a a transmiss o representa um desperdcio de banda passante uma vez que a rede n o enfrenta a a problemas de congestionamento. A mobilidade das estacoes introduz desaos para camada de interconex o de re a des, em especial no que concerne o enderecamento e o roteamento. Na Internet original, o enderecamento foi organizado de maneira hier rquica para possibilitar a agregacao de a rotas e assim aumentar a escalabilidade do roteamento. Um exemplo dessa organizacao e visto nos prexos usados pelas redes de acesso ligadas a um AS. Os prexos das redes s o a faixas pertencentes ao AS de borda. Assim, o AS de borda pode anunciar aos outros ASes vizinhos os prexos agregados das redes ligadas a ele. A consequ ncia da agregacao e a e reducao do n mero de entradas nas tabelas de roteamento e a simplicacao da busca nas u ` FIBs para encaminhar pacotes as estacoes. ` A estrutura hier rquica da Internet levou a organizacao geogr ca de enderecos a a IP. Tal organizacao associou ao endereco IP a localizacao da estacao na Internet. Por outro lado, a identicacao de estacoes da Internet e feita atrav s de nomes que s o mapeados e a pelo DNS (Domain Name System) em enderecos IP. Assim, o endereco IP e utilizado para localizacao e identicacao de uma estacao, o que caracteriza a sem ntica sobrecarre a ` gada do endereco IP. Esse problema representa um entrave a mobilidade das estacoes j a que ao se moverem, as estacoes mudam a sua localizacao e, consequentemente, devem mudar o seu endereco IP. Por m, a arquitetura da Internet atual assume que os enderecos e IP s o invariantes durante toda a comunicacao entre estacoes. Como padr o, se uma a a ` estacao muda de rede de acesso a Internet, essa estacao deve recongurar o seu endereco IP para um que seja topologicamente correto de acordo com a sua nova rede. Ao receber um novo endereco IP, as comunicacoes estabelecidas com o endereco IP anterior s o a perdidas. Al m disso, o estabelecimento de conex o com uma estacao que muda conse a tantemente de endereco diculta a resolucao de nomes j que a estacao n o possui um a a endereco permanente. A Figura 2.4(a) ilustra a reconguracao do endereco IP da estacao m vel M ao mudar de rede de acesso. A mudanca do endereco provoca o restabelecimento o da conex o com o n I da Internet. a o Solucoes adicionais ao IP devem ser propostas para que as comunicacoes, e possi velmente as conex es pr -estabelecidas, sejam mantidas mesmo ap s o deslocamento das o e o estacoes. Uma proposta inicial para resolver o problema foi o IP m vel [Perkins 2002]. O o IP m vel mant m as conex es de uma estacao m vel atrav s da manutencao da associacao o e o o e

(a) Mudanca de endereco em decorr ncia da e mudanca de rede de acesso.

(b) Funcionamento do IP m vel. o

Figura 2.4. Mobilidade de estacao.

dessa estacao com o seu endereco IP original, mesmo ap s o deslocamento. Para isso, e o ` necess rio que a estacao m vel informe a rede original qual a sua nova localizacao para a o que todo pacote recebido possa ser encaminhado para a estacao em seu novo endereco na rede estrangeira. A nova localizacao da estacao m vel e recebida pelo agente domiciliar o (home agent), que e uma estacao na rede de acesso original respons vel por receber e a ` encaminhar todo o tr fego destinado a estacao m vel. O agente domiciliar encapsula os a o ` pacotes destinados a estacao m vel e os encaminha atrav s de um t nel estabelecido entre o e u o agente domiciliar e uma estacao da rede estrangeira. Essa estacao, denominada agente estrangeiro (foreign agent), e respons vel por atribuir um endereco IP v lido da rede esa a ` trangeira a estacao m vel e tamb m e respons vel por encaminhar os pacotes recebidos o e a atrav s do t nel at essa mesma estacao. A estacao m vel recebe um endereco IP v lido e u e o a do agente estrangeiro ap s um procedimento de registro. O procedimento de encaminhao mento, ilustrado pela Figura 2.4(b), pode ser resumido da seguinte maneira. Todos os ` pacotes enviados a estacao m vel M s o recebidos pelo agente domiciliar D. Esse agente o a encapsula os pacotes e os encaminha pelo t nel at o agente estrangeiro E. O agente esu e trangeiro E desencapsula os pacotes e os encaminha at a estacao m vel M. O tr fego no e o a sentido reverso e originado pela estacao m vel M e enviado at o agente estrangeiro E. o e Esse encapsula os pacotes e os envia at o agente domiciliar D atrav s do t nel. O agente e e u domiciliar D recebe os pacotes, os desencapsula e os envia para a Internet. Apesar de o procedimento permitir o deslocamento das estacoes m veis, o IP m vel encaminha os o o pacotes de maneira indireta entre as estacoes de origem e destino. Esse encaminhamento indireto e reetido em um caminho mais longo percorrido pelos pacotes, o que reduz a eci ncia do roteamento na Internet. e O IPv6 [Johnson et al. 2004] m vel dispensa o uso do agente estrangeiro. Poro tanto, o t nel e estabelecido entre o agente domiciliar e a pr pria estacao m vel. Al m u o o e disso, o IPv6 m vel permite que os pacotes sejam encaminhados da Internet at a estacao o e m vel sem precisar passar pela rede domiciliar. O encaminhamento direto e possvel com o o uso de uma extens o de cabecalho para roteamento (routing header extension) do IPv6. a A extens o permite que a estacao m vel utilize o endereco IP da rede estrangeira como a o endereco de origem e liste na extens o do cabecalho o endereco da rede domiciliar. O a n da Internet ao receber o pacote reconhece o novo endereco da estacao e, ap s um proo o cedimento de associacao, utiliza o endereco da estacao m vel como endereco de destino o dos pr ximos pacotes. Mesmo com essas diferencas para o IP m vel, o IPv6 m vel ainda o o o

` exibe problemas como lat ncia no restabelecimento do acesso a Internet, principalmente e se a estacao m vel se deslocar a altas velocidades. o Multiplos domiclios Os m ltiplos domiclios (multi-homing) s o redes de acesso ou estacoes que se cou a ` nectam a Internet atrav s de m ltiplas conex es. Essas conex es s o obtidas de diferentes e u o o a ISPs ou do mesmo ISP, mas usando faixas de enderecos diferentes. A Figura 2.5 ilustra uma estacao multidomiciliada (host multihoming) e uma rede multidomiciliada (site mul tihoming). No primeiro caso, a estacao possui interfaces conguradas com enderecos IP diferentes. J no segundo caso, o ponto de interconex o possui sadas para dois ISPs dia a ferentes, por m as estacoes internas podem possuir enderecos IP privados ou podem ter a e sua unica interface congurada com enderecos IP de cada um dos ISPs. Assim, as redes multidomiciliadas podem ser identicadas por mais de uma faixa de enderecos, que de vem ser anunciadas para todos os ASes da Internet atrav s de rotas do BGP. A motivacao e para o emprego dos m ltiplos domiclios e o aumento da conabilidade na comunicacao u com a Internet [Farinacci et al. 2009b, Nordmark e Bagnulo 2009]. Em caso de falha de um dos provedores, ainda h alternativas para a manutencao da comunicacao. Para maior a conabilidade, as redes multidomiciliadas devem estar conguradas de maneira a isolar eventuais falhas individuais. Na aus ncia de falhas, as m ltiplas faixas de enderecos e u podem ser tamb m exploradas para possibilitar engenharia de tr fego, maximizar vaz o e a a agregada e at mesmo reduzir custos. Um exemplo de reducao de custos e o uso de um e ISP mais caro para tr fego que exige qualidade de servico e o uso de um mais barato, no a caso contr rio. a

Figura 2.5. Exemplos de estacao e rede multidomiciliada.

A utilizacao dos m ltiplos domiclios traz diculdades do ponto de vista do ro u teamento. As m ltiplas faixas podem ser alocadas por ISPs (provider assigned) ou pou dem ser independentes do ISP (provider independent). Nessa ultima opcao, a faixa de a enderecos e alocada diretamente pelo org o regional de distribuicao de enderecos da In ternet. A principal vantagem em se utilizar faixas independentes e evitar reconguracao caso haja a troca de provedor de acesso. O funcionamento dos m ltiplos domiclios viola a u organizacao hier rquica de enderecos da Internet, o que impede a agregacao de enderecos. a Essa t cnica requer o an ncio das m ltiplas faixas desagregadas para que todas as outras e u u redes na Internet tomem conhecimento da localizacao daquela faixa. Uma vez que cada

provedor de servico possui suas faixas de enderecos pr -estabelecidas, anunciar faixas e de enderecos desagregadas ou de outros provedores causa problemas de escalabilidade, como o aumento das tabelas BGP. Multiplos caminhos Muitos protocolos de roteamento atuais escolhem apenas um unico caminho para interconectar um par origem-destino na rede. Protocolos intradomnio como o OSPF e o RIP (Routing Information Protocol) tipicamente mant m em suas tabelas de roteae mento apenas o vizinho que pertence ao melhor caminho at o destino. O OSPF em e especial oferece variantes que calculam m ltiplos caminhos, mas que s o pouco explou a radas na pr tica. Essa limitacao diculta a introducao de conabilidade e exibilidade a no roteamento, uma vez que seria possvel dividir o tr fego entre caminhos diferentes. a Outras vantagens s o a possibilidade de escolher caminhos de acordo com os requisitos a das aplicacoes, por exemplo, caminhos com maior banda ou menor atraso, e ainda evitar caminhos congestionados [He e Rexford 2008]. Os m ltiplos caminhos representam uma opcao pouco explorada na Internet apeu sar do seu potencial. Medidas demonstram que existe um caminho alternativo com taxa de perda e atraso menores que o caminho usado em 30 a 80% do tempo [He e Rexford 2008]. O emprego desses caminhos pode aumentar signicativamente o desempenho do encaminhamento de pacotes na Internet. Entretanto, os m ltiplos caminhos deixam de ser explou rados porque muitas vezes esbarram em limitacoes de camadas superiores. Um exemplo disso e a possibilidade do desordenamento de pacotes de uma mesma conex o TCP se a a diversidade de caminhos for explorada no nvel de pacotes e n o no nvel de uxos. a A Figura 2.6 ilustra o exemplo do uso dos m ltiplos caminhos entre as estacoes A e C. u Os m ltiplos caminhos s o usados para envio de tr fego ao mesmo tempo, o que difere u a a essa estrat gia do uso dos m ltiplos domiclios. A Figura 2.6 ilustra um exemplo de e u m ltiplos caminhos totalmente disjuntos. Entretanto, os m ltiplos caminhos podem ser u u parcialmente disjuntos, no caso de alguma rede de acesso ou AS que n o ofereca m ltiplas a u sadas para a Internet, por exemplo.

Figura 2.6. Exemplos do uso dos multiplos caminhos na Internet.

` Embora a topologia da Internet ofereca m ltiplos caminhos devido as m ltiplas u u conex es entre ASes e aos m ltiplos caminhos intradomnio, problemas relacionados com o u escalabilidade, acordos comerciais entre os diferentes ISPs e o pr prio projeto do BGP o dicultam o emprego dessa possibilidade [He e Rexford 2008]. A primeira quest o e uma a

consequ ncia da obrigacao dos roteadores em armazenarem informacoes de m ltiplos cae u minhos para cada destino. Essa caracterstica exige a execucao de algoritmos ou variacoes de algoritmos com complexidade superior ao Dijkstra ou ao Bellman-Ford, usados em muitos dos protocolos intradomnio, que aumenta a troca de informacoes de controle e ainda aumenta o n mero de entradas nas tabelas de roteamento [He e Rexford 2008]. A u segunda quest o e consequ ncia da divis o da Internet em m ltiplos ASes. Para serem a e a u plenamente explorados, os m ltiplos caminhos devem ter condicoes de passar por redes u que pertencam a diferentes organizacoes. Tais organizacoes n o necessariamente pos a suem acordos entre si e, portanto, n o encaminham tr fego vindo desses ASes. J a a a a ultima quest o est relacionada com a maneira como o BGP foi desenvolvido. a a O BGP, assim como os protocolos intradomnio, foi desenvolvido para ser um protocolo que ofereca apenas uma opcao de caminho para cada prexo de rede da Inter net. Cada ISP anuncia aos seus vizinhos um unico caminho ativo para alcancar outras redes atrav s dele. O caminho disponibilizado depende das polticas utilizadas pelo BGP. e Entretanto, se mais de um caminho fosse oferecido pelos ISPs aos seus vizinhos, parte do controle do tr fego encaminhado seria perdido. Isso ocorre pois n o h como prea a a ver a distribuicao de tr fego realizada pelos ISPs vizinhos que e encaminhado atrav s a e das m ltiplas opcoes oferecidas. Esse controle e importante para que os ISPs possam u realizar engenharia de tr fego dentro da sua pr pria rede. Algumas opcoes para forcar a o os m ltiplos caminhos sem a necessidade de cada ISP anunciar m ltiplos caminhos e u u atrav s do uso do roteamento pela fonte ou das redes sobrecamada (overlay). Em ame bas as opcoes, o ISP tamb m perde parte do controle de sua rede. Isso porque tanto a e fonte que escolhe o caminho quanto as redes formadas em camadas superiores podem desconsiderar as polticas de cada ISP e as ligacoes na camada fsica, respectivamente. Caminhos program veis a Atualmente, os caminhos seguidos pelos pacotes na Internet s o denidos por proa tocolos de roteamento que, em especial o BGP, envolvem muitas conguracoes manuais de administradores de rede. Os protocolos de roteamento intradomnio escolhem o melhor caminho entre a origem e o destino baseado em m tricas estabelecidas, p. ex., o n mero e u de roteadores atravessados, e os protocolos de roteamento interdomnio consideram acor dos comerciais para escolher qual dos ISPs vizinhos deve ser utilizado. Nesse ultimo caso, as condicoes nas quais o tr fego e encaminhado dependem do tipo de acordo entre a as partes que pode inclusive limitar requisitos de rede como a banda passante m xima. a Uma possibilidade para conceder maiores poderes aos usu rios e criar crit rios a e para que os caminhos escolhidos na Internet sejam program veis ou congur veis de a a acordo com requisitos desejados pelos pr prios usu rios ou por aplicacoes no nvel de o a usu rio. Tais requisitos podem ser demandas de uma aplicacao, como por exemplo, gaa rantias de qualidade de servico, que poderiam ser escolhidas dinamicamente por agentes inteligentes ou pelos usu rios [Clark et al. 2004]. Para isso, os caminhos da Internet n o a a devem se basear somente em m tricas de interesse dos provedores de servico ou em acore dos comerciais, mas tamb m em m tricas de interesse dos usu rios. Essa possibilidade, e e a por m, esbarra no servico atualmente utilizado na Internet que e o servico de melhor e esforco oferecido pelo IP. Para possibilitar a programacao de caminhos a Internet deve suportar qualidade de servico e a possibilidade dos usu rios ou agentes fazerem escolhas a

que podem ir contra os acordos dos provedores. Al m disso, uma das caractersticas fune damentais da Internet e a manutencao da intelig ncia nas bordas da rede. Essa premissa e e baseada no fato que n o h ningu m melhor do que os usu rios para saber se a aplicacao a a e a possui bom desempenho ou n o [Clark et al. 2004]. Portanto, requisitos como conabia lidade devem ser vericados nas bordas da rede e qualquer outro tipo de vericacao no n cleo e considerado redundante. Essa premissa e satisfeita se os caminhos forem esu colhidos pelos usu rios. Entretanto, a possibilidade do emprego de agentes pode ir em a direcao oposta a essa premissa j que os agentes podem ser inseridos no n cleo da rede. a u A liberdade de escolha de caminhos pelos usu rios pode incentivar a disputa e, a assim, provocar a reducao dos custos de acesso. Uma quest o em aberto e a possibi a lidade da aus ncia da qualidade de servico m-a-m ser apenas uma consequ ncia da e e falta de competicao entre os ISPs. Caso fosse possvel escolher caminhos, usu rios que a possussem aplicacoes com requisitos especiais poderiam optar por caminhos mais apro priados. Nesse caso, o ISP que entrasse no mercado oferecendo essa possibilidade levaria vantagem sobre os outros que seriam obrigados a modicar os seus servicos para serem competitivos [Clark et al. 2004]. Caso nenhum ISP tomasse a iniciativa, incentivos poderiam ser oferecidos aos ISPs para que esses comecassem a oferecer a possibilidade de escolha aos usu rios. O problema de oferecer liberdade aos usu rios ou agentes e o aua a mento da complexidade que cada um deve lidar. Por exemplo, os usu rios ou agentes a precisariam de conhecimento global da rede e ainda poderiam introduzir falhas causadas por m s conguracoes ou m s opcoes. Al m dos problemas mencionados, a possibilidade a a e de escolha de caminho pode exigir que cada n mantenha todos os possveis caminhos em o mem ria. Esse requisito pode ser mais uma fonte de problemas de escalabilidade. o Escalabilidade dos roteadores Um dos maiores desaos do aumento acelerado do n mero de estacoes e redes na u Internet e a escalabilidade. De acordo com um recente relat rio do IAB (Internet Archio tecture Board), a escalabilidade e um dos desaos mais crticos em curto prazo para o projeto da Internet do Futuro [Meyer et al. 2007]. Os roteadores s o equipamentos que a possuem recursos limitados de mem ria e processamento. Portanto, o aumento indeo nido do tamanho das tabelas de roteamento (FIB) e das bases de dados (RIB) pode afetar o desempenho do encaminhamento de pacotes. Cada roteador disp e de poucos instano tes para armazenar um pacote, selecionar a interface de sada baseado no prexo de rede do endereco de destino e encaminhar para interface correspondente. Al m disso, a so e brecarga de controle gerada ao aumentar o n mero de estacoes pode se tornar relevante u diante da banda passante disponvel. Para exemplicar tal crescimento, dados do CIDR (Classless Inter-Domain Routing) mostram que desde o incio da d cada de 90 at os dias e e atuais o n mero de entradas BGP ativas nas FIBs aumentou de algumas unidades para u aproximadamente 310 mil [CIDR 2010]. ` Os desaos ligados a escalabilidade poderiam ter menor impacto caso o projeto original da Internet fosse seguido. A premissa de organizacao hier rquica da In a ternet e a consequente agregacao de enderecos t m como objetivo tornar o roteamento e escal vel [Massey et al. 2007, Jen et al. 2008]. Entretanto, as demandas emergentes disa cutidas nesta secao impedem a agregacao de enderecos nas FIBs e/ou aumentam a carga ` de controle da rede. O suporte as redes multidomiciliadas e aos m ltiplos caminhos requeu

rem a associacao de prexos distintos a uma mesma rede e requerem a associacao de mais ` de um caminho para um mesmo destino. J o suporte a mobilidade aumenta a quantidade a de informacoes de controle trocadas para manter uma estacao m vel conectada e destr i a o o premissa de organizacao hier rquica da Internet. Por m, a programacao de caminhos re a sulta em armazenamento de informacoes do roteamento nos usu rios. Um efeito indireto a que tamb m inuencia na escalabilidade e o uso de espacos de enderecamento maiores e que o IPv4, como e o caso do IPv6. O uso do IPv6 pode aumentar a oferta de enderecos IP, o que resulta em mais estacoes e redes e mais carga de controle. Os problemas de escalabilidade j t m sido observados na pr tica pelo tamanho a e a ` das tabelas de roteamento BGP. Essas tabelas t m aumentado devido a agregacao parcial e das faixas de enderecos anunciadas pelos ISPs. A Figura 2.5 mostra que o roteador de borda do ASB anuncia um prexo de rede que n o e agreg vel ao seu. J o roteador de a a a borda do ASC anuncia o seu prexo desagregado para possibilitar a estacao multidomi ciliada. Essa agregacao parcial e muitas vezes interessante para um provedor de servico deixar de agregar determinadas faixas de enderecos para inclusive balancear carga ou para oferecer servicos diferenciados para os clientes. Dados do CIDR mostram que a raz o en a tre redes que sofreram agregacao de prexos e o total de redes na Internet e atualmente de 38,4% [CIDR 2009], o que demonstra a relev ncia do problema na Internet. A agregacao a parcial de enderecos, assim como muitos dos desaos da Internet do Futuro, pode culmi nar no aumento das tabelas de roteamento e no aumento de sobrecarga de controle. Essas consequ ncias representam um entrave ao aumento do n mero de estacoes j que a busca e u a por enderecos de destino pelos roteadores e o processamento de mensagens podem ser operacoes custosas computacionalmente.

2.4. Propostas para a Interconex o de Redes a

Nesta secao s o apresentados novos conceitos e novas propostas que t m por ob a e jetivo resolver os desaos destacados na secao anterior. Muitas dessas propostas rompem completamente com a arquitetura original da Internet e algumas delas levam em conta um perodo de transicao para a sua implementacao. 2.4.1. Separacao de Localizacao e Identicacao Uma das principais propostas para minimizar os problemas de escalabilidade de` vido as demandas por mobilidade e m ltiplos domiclios na Internet e a separacao da u localizacao fsica da identicacao das estacoes. Essa separacao tem o intuito de que brar a sem ntica sobrecarregada do IP e, por isso mesmo, vem sendo considerada como a fundamental para a Internet do Futuro [Caesar et al. 2006b]. Esse tipo de abordagem e denominada Loc/ID split. O Loc/ID split permite que as comunicacoes realizadas a partir de um identicador invari vel se mantenham, mesmo que a localizacao da estacao mude. a Ainda que em outro nvel, o procedimento e semelhante ao DNS que separa a identicacao do nome de um stio da Internet do seu endereco IP. Entretanto, assim como no caso do DNS, e tamb m necess rio algum sistema de mapeamento para associar identicador e e a localizador. O mapeamento din mico e escal vel entre identicador e localizador e um a a problema de pesquisa em aberto [Iannone e Bonaventure 2007, Luo et al. 2009]. O i3 (Internet Indirection Infrastructure) [Stoica et al. 2004] baseou sua proposta

na constatacao de que servicos como mobilidade e multicast enderecam estacoes de ma ` neira indireta para funcionarem na Internet atual. Por exemplo, para prover suporte a mobilidade h possivelmente o emprego de agentes domiciliares assim como para proa ver suporte ao multicast h o emprego de endereco de grupo. Em ambos os casos o a endereco de destino utilizado pela fonte n o e o endereco da estacao nal. O i3 utiliza a essa constatacao para propor uma estrutura sobrecamada para oferecer suporte unicado a qualquer tipo de servico que possa usufruir de enderecamento indireto. O modelo de servico do i3 basicamente desassocia o ato de enviar pacotes do ato de receb -los. Para isso, cada fonte envia os pacotes para o identicador do destino, ao e inv s de enviar para o endereco. O destino dos pacotes demonstra interesse nesses pacotes e enviando disparadores (triggers) contendo o seu identicador e o seu endereco. Tanto os pacotes quanto os disparadores s o enviados para a estrutura de servidores do i3. Em tal a estrutura, os pacotes recebidos s o associados aos disparadores correspondentes para que a haja o mapeamento do identicador do pacote no endereco de destino. Na estrutura i3, cada servidor e respons vel por um conjunto de identicadores. Esse servidor mant m o a e mapeamento dos identicadores que est o sob sua responsabilidade. Logo, todo pacote a recebido na estrutura e encaminhado para o servidor respons vel para que ele realize o a mapeamento e encaminhe o pacote para o endereco do destino correspondente. O ma peamento e mantido no servidor da estrutura i3 de maneira vol til. Assim, de tempos a em tempos os destinos devem atualizar o seu mapeamento na estrutura. A Figura 2.7 ilustra todo procedimento de encaminhamento de pacotes no i3. A Figura 2.7(a) mostra o envio do disparador realizado pela estacao de destino B para demonstrar interesse em um determinado conte do. O disparador cont m o seu identicador e o seu endereco. A u e estrutura i3, por conseguinte, armazena o interesse. Assim, sempre que a estrutura do i3 recebe pacotes destinados ao identicador da estacao B, a estrutura j sabe para que a destino encaminhar, como visto na Figura 2.7(b). O enderecamento indireto proposto pelo i3 desassocia as fontes dos destinos. Assim, as fontes n o precisam conhecer nem a o n mero de destinos nem os enderecos para os quais os seus pacotes s o enviados, e da u a mesma maneira, os destinos n o precisam conhecer nem o n mero de fontes nem os seus a u enderecos. Uma importante caracterstica do i3 e que um determinado identicador pode estar associado a mais de um endereco de destino. Nesse caso, o mapeamento ocorre para todos os destinos cujo identicador e igual a um n mero mnimo de bits do identicador u mantido na estrutura de servidores do i3.

(a) Envio do disparador.

(b) Encaminhamento de pacotes.

Figura 2.7. Encaminhamento de pacotes realizado pelo i3.

 No caso dos n s m veis, a conex o pode ser mantida visto que ela e realizada o o a utilizando o identicador das estacoes de origem e destino e n o os enderecos fsicos. a Entretanto, o n m vel ao mudar de rede de acesso, muda de endereco fsico e, portanto, o o deve atualizar o mapeamento na estrutura i3. Uma vez que as fontes n o precisam conhea cer o endereco do destino, a conex o e mantida. O i3 requer a atualizacao do mapeamento a nos servidores, o que pode implicar problemas de lat ncia de atualizacao, al m de proe e blemas de escalabilidade. Outro ponto e o aumento dos caminhos seguidos pelos pacotes em consequ ncia do encaminhamento indireto. e O LISP (Locator/Id Split Protocol) [Farinacci et al. 2009b, Saucez et al. 2009] e um protocolo desenvolvido pela CISCO para lidar com os problemas dos m ltiplos dou miclios na Internet. O LISP e uma proposta que pode ser implementada de maneira gradual, o que representa uma vantagem. O LISP tamb m realiza enderecamento ine direto assim como o i3. Para isso, ele divide o espaco de enderecamento no espaco de enderecamento local, composto pelas redes de borda da Internet, e no espaco de enderecamento interdomnio, composto pelos roteadores da DFZ. Os roteadores dos ASes ` de borda da Internet possuem interfaces conectadas a DFZ conguradas com enderecos denominados Routing Locators (RLOCs). Esses enderecos s o conhecidos por todos a os roteadores interdomnio. J os enderecos das estacoes da rede local, denominados a ` Endpoint IDentiers (EIDs), possuem escopo limitado a rede de acesso. Portanto, os enderecos das estacoes n o s o conhecidos pelos roteadores interdomnio e os RLOCs n o a a a es. O encaminhamento de pacotes m-a-m requer, portanto, o podem identicar estaco uso dos dois tipos de enderecos. Nessa direcao, os EIDs de uma rede local s o associados a ` aos RLOCs dos ISPs pelos quais possuem acesso a Internet. Um EID pode estar associado a mais de um RLOC, o que permite os m ltiplos domiclios. Equivalentemente, u um RLOC pode estar associado a um prexo de enderecos locais. Outra vantagem do LISP e que ele dispensa o uso de estrutura de servidores, como usado no i3. A Figura 2.8 ilustra os enderecos utilizados pelo LISP. Na gura, a estacao EIDA possui associado o endereco RLOCA na DFZ. J o EIDB possui dois enderecos RLOC associados, RLOCB1 a e RLOCB2 , para m ltiplos domiclios. u

Figura 2.8. Enderecamento no LISP.

No LISP, os pacotes s o encaminhados na DFZ utilizando como enderecos de a origem e destino os enderecos dos RLOCs j que os enderecos locais n o s o conhecidos. a a a Entretanto, entre a estacao de origem do pacote e o seu roteador de borda e entre o roteador de borda no destino e a estacao de destino, os enderecos usados s o os EIDs de origem a e destino. Para que os dois tipos de enderecos sejam usados pelos pacotes, e necess rio a que haja o mapeamento dos EIDs nos enderecos dos RLOCs. Ap s o mapeamento, os o pacotes s o encapsulados atrav s de t neis entre os roteadores de borda. Tal procedimento a e u

 e conhecido por mapeamento e encapsulamento (Map & Encap). Os roteadores de borda realizam o Map & Encap j que eles s o os unicos que conhecem a associacao entre a a os EIDs e os RLOCs. Essa caracterstica e uma vantagem do LISP, pois torna o seu funcionamento transparente para os outros n s da rede, al m de dispensar modicacoes o e na estrutura da Internet. A Figura 2.9(a) ilustra os cabecalhos utilizados por um pacote no LISP em cada um dos trechos percorridos: EIDA de origem at RLOCA , RLOCA e at RLOCB1 e RLOCB1 at o destino EIDB . O mapeamento no LISP e realizado por dois e e sistemas, o de base de dados e o de mem ria cache. O de base de dados seleciona o RLOC o que e usado como endereco de origem dos pacotes sendo enviados de uma rede local. Al m disso, o sistema de base de dados decide se um pacote recebido da Internet deve e ser desencapsulado ou n o. O sistema de mem ria cache, por outro lado, e usado para a o o de destino. Para tal, o mapeamento selecionar os RLOCs das redes de acesso da estaca EID de destino e RLOC de destino s o tamb m armazenados nesse cache. Caso haja uma a e ` busca mal-sucedida a cache sobre o mapeamento de uma determinada estacao de destino, o sistema de mapeamento do LISP faz uma requisicao a um sistema de mapeamento atrav s do protocolo de mapeamento distribudo (Mapping Distribution Protocol). e

(a) Encaminhamento direto.

(b) Uso do Map-Reply.

Figura 2.9. Encaminhamento de pacotes no Lisp.

No LISP, o encaminhamento de pacotes assume que a estacao de origem conhece o identicador do destino e o seu pr prio endereco. A resolucao do identicador do deso tino no EID e realizada atrav s de um sistema de resolucao de nomes como o DNS. O e pacote e ent o encaminhado pela estacao de origem at o roteador de borda atrav s de a e e uma rota default. Ao chegar no roteador de borda, ele deve descobrir o mapeamento do EID do destino no RLOC correspondente. Esse procedimento depende da vers o do LISP. a As primeiras vers es do LISP, LISP 1 e 1.5, assumem que o endereco EID e rote vel na o a Internet. Assim, o roteador de borda da origem encapsula o pacote com um cabecalho de nido pelo LISP com o seu endereco como endereco de origem e o endereco da estacao de destino como endereco de destino. Esse pacote e encaminhado pela DFZ at que che e gue ao roteador de borda que conhece o mapeamento EID/RLOC do destino. O roteador de borda do destino envia uma mensagem ao roteador de borda da origem (Map-Reply) informando o mapeamento, como visto na Figura 2.9(b). O roteador de borda da origem armazena essa informacao em sua mem ria cache assim que a recebe. Da mesma maneira, o o roteador de borda do destino armazena o mapeamento em sua mem ria cache para evio tar uma possvel busca subsequente. As vers es 2 e 3 do LISP n o consideram mais que o a os EIDs s o rote veis na Internet. Assim, para conhecer o mapeamento EID/RLOC, o a a LISP utiliza um protocolo de distribuicao de mapas (Mapping Distribution Protocol) para fazer requisicoes explcitas (Map-Request) a um servico de mapeamento distribudo. Tais sistemas podem ser implementados baseados em sistemas de DNS, LISP vers o 2; ou a

em sistemas baseados em DHTs (Distributed Hash Table), LISP vers o 3. Em ambos os a ` casos, os sistemas respondem (Map-Reply) apenas as requisicoes recebidas. A separacao da localizacao da identicacao proposta no LISP facilita o uso de estacoes multidomiciliadas visto que desassocia o endereco da estacao do endereco de seu ISP. Entretanto, essa separacao resulta tamb m no emprego de sistemas de mapeamento, e que introduzem um atraso para resolver EIDs em RLOCs. Como esse atraso pode ser ` grande, ele ainda representa um entrave a mobilidade das estacoes e de redes embora a separacao da localizacao da identicacao dos n s benecie a mobilidade em um primeiro o momento. O LISP possui como ponto de estudo futuro encontrar maneiras mais ecientes para lidar com a mobilidade de estacoes e de redes. O HIP (Host Identity Protocol) [Moskowitz et al. 2008] e outro protocolo para Loc/ID split [OpenHIP 2009]. Para isso, ele prop e uma nova camada entre a camada de o redes e a camada de transporte. Assim, a camada de transporte interage com a camada de identicacao e a camada de identicacao interage com a camada de rede. O HIP ` utiliza os conceitos de identidade e identicador. A identidade de um n se refere a o entidade abstrata que e identicada. J o identicador se refere ao padr o bin rio que a a a e utilizado no processo de identicacao. Por exemplo, a identidade e o nome de uma estacao (rio.gta.ufrj.br) e o identicador uma chave p blica criptogr ca. O HIP u a utiliza chave p blica como identicador, embora qualquer tipo de identicador possa ser u usado. A vantagem de utilizar uma chave p blica como identicador e a possibilidade de u autenticar a origem dos pacotes recebidos. Como consequ ncia, pode-se evitar a violacao e dos pacotes em tr nsito como feito em ataques do tipo homem-no-meio (man-in-thea middle). O HIP considera que identicadores que n o utilizem criptograa devem ser a apenas utilizados em ambientes considerados seguros. A Figura 2.10 ilustra a arquitetura atual para identicacao e localizacao que sobrecarrega o enderecamento IP e a arquitetura proposta pelo HIP que separa a localizacao da identicacao de uma estacao.

(a) Arquietura atual da Internet.

(b) Arquitetura do HIP.

Figura 2.10. Arquiteturas de identicacao e localizacao.

Diferente da identidade de um n no HIP que e uma abstracao, o identicador pode o ser utilizado nas comunicacoes. Entretanto, devido ao tamanho e a variabilidade possvel, a maneira escolhida pelo HIP para representar o identicador nos pacotes do protocolo e um resumo obtido atrav s do uso de uma funcao hash. Dessa forma, a representacao do e identicador torna o seu uso mais simples j que possui tamanho xo, al m de signicar a e um formato consistente independente dos algoritmos criptogr cos empregados. O resula tado da funcao hash e denominado como r tulo da estacao (Host Identity Tag - HIT) e, o consequentemente, deve ser unico globalmente.

 Uma comunicacao com HIP e iniciada a partir de um processo de autenticacao e troca de chaves. Portanto, sempre antes de enviar dados e realizada uma troca de base atrav s do BEX (Base Exchange Protocol) e uma associacao HIP se torna ativa. Esse e protocolo e executado m-a-m, ou seja, entre as estacoes nais. O procedimento de autenticacao envolve a troca de desaos criptogr cos para autenticacao. Todo o pro a cedimento pode ser atualizado quando as chaves criptogr cas expiram ou quando uma a estacao se desloca. A camada de transporte estabelece conex es utilizando os HITs de origem e deso tino que s o oferecidos pela camada introduzida pelo HIP para identicacao das estacoes a envolvidas na comunicacao. Entretanto, para os pacotes serem encaminhados na Inter net, a camada introduzida pelo HIP precisa substituir os HITs pelos enderecos IP corres pondentes. Para isso, a estacao de origem dos pacotes substitui o HIT de origem pelo endereco IP correspondente e obt m via um sistema de resolucao de nomes, o endereco e IP do destino. No HIP, a resolucao de nomes n o retorna apenas o endereco IP da estacao, a mas tamb m informacoes como o HIT e a chave p blica. Ap s a resolucao de nomes, e u o a comunicacao de dados inicia-se entre a estacao de origem e destino. Uma vez desco berto o endereco de um n , esse endereco e utilizado at que a comunicacao se encerre o e ou que o n de destino se desloque. Essa caracterstica difere o HIP do LISP, j que no o a LISP o encaminhamento dos pacotes sempre utiliza t neis. No HIP, se uma estacao se u ` mover, a pr pria estacao pode avisar a estacao de destino qual o seu novo endereco fsico. o o desejar estabelecer uma conex o com a estacao que se Entretanto, se uma nova estaca a moveu, a resolucao do nome ir retornar o endereco IP antigo j que o mapeamento no a a DNS n o foi atualizado. Para esses casos, o HIP usa servidores na Internet para evitar que a as estacoes m veis precisem sempre atualizar o DNS. o O HIP dene um servidor est tico chamado de rendezvous para auxiliar em um a processo de encaminhamento indireto, semelhante ao usado no i3. Para isso, o nome da estacao m vel e mapeado pelo DNS no endereco IP do rendezvous. O servidor rendez o vous possui atualizada a localizacao da estacao m vel. Parte-se da premissa que e melhor o atualizar o endereco IP em um servidor na Internet que o DNS. Logo, uma estacao da o m vel realiza a resolucao de nomes Internet que deseja se comunicar com uma estaca o e recebe o endereco IP do servidor de rendezvous e o HIT da estacao m vel. A estacao o da Internet inicia o processo de autenticacao e troca de chaves utilizando o endereco IP e o HIT recebido. A mensagem e encaminhada at o servidor de rendezvous que ao pere ceber que o HIT da mensagem n o e um dos seus, verica em seus registros se possui o a mapeamento correspondente. Todas as estacoes que desejam utilizar um servidor de ren dezvous devem se registrar nesses servidores. Portanto, caso a mensagem seja destinada a um HIT cujo mapeamento no endereco IP e conhecido, o servidor encaminha o pacote at a estacao m vel correspondente. Ao receber a primeira mensagem de autenticacao e e o ` troca de chaves, a estacao m vel responde diretamente a estacao de origem e o restante o da comunicacao passa a ser direta desde ent o sem o interm dio do rendezvous. Se a a e estacao m vel mudar de rede novamente, ela atualiza a outra estacao e o servidor ren o dezvous da sua nova localizacao. A Figura 2.11 ilustra o funcionamento do HIP com o uso do servidor de rendezvous. Na Figura 2.11(a), a estacao de origem A envia a pri meira mensagem com o endereco IP do servidor de rendezvous R obtido ap s a resolucao o do nome no DNS. O servidor de rendezvous, ent o, encaminha a mensagem at a estacao a e

m vel. Em seguida, a estacao m vel se comunica diretamente com a estacao que originou o o a comunicacao, como visto na Figura 2.11(b).

(a) Encaminhamento atrav s do rendezvous. e

(b) Encaminhamento direto.

Figura 2.11. Encaminhamento de pacotes no HIP.

Apesar do HIP encaminhar pacotes de uma maneira diferente do LISP, ele tamb m e ` e pode sofrer problemas com a mobilidade de estacoes devido a lat ncia de atualizacao do mapeamento. Em redes m veis em velocidades altas, essa lat ncia pode n o ser suciente o e a para atender as demandas de servicos com restricoes de atraso. O HIP prov ainda suporte e ` a m ltiplos domiclios, j que mais de um endereco pode estar relacionado a mesma u a identidade [Nikander et al. 2008]. O Shim6 [Nordmark e Bagnulo 2009] e uma proposta para proporcionar toler ncia a a falhas a estacoes multidomiciliadas em domnios IPv6. O Shim6 mant m comunicacoes e correntes mesmo em caso de falha de alguns localizadores. Caso uma parte das conex es o de uma rede, as outras ativas devem manter a comunicacao. No pior caso, se todas as conex es falharem, o tempo de restabelecimento da comunicacao e igual ao tempo de o atualizacao do DNS e das atualizacoes se propagarem pela rede. Nesse sentido, o Shim6 possibilita o uso dos m ltiplos domiclios. Semelhante ao HIP, o Shim6 atribui um nome u especial para o identicador do n , chamado de ULID (Upper Layer IDentier). J o o a localizador da estacao n o possui nome especial e se refere ao endereco IPv6 da camada a de rede. Diferente das propostas anteriores, entretanto, o endereco IPv6 utilizado no pri meiro contanto com a outra estacao cumpre tamb m o papel de ULID. Logo, o Shim6 e n o prop e o uso de um nome espaco de identicacao. Por m, caso o localizador mude a o e ao longo da comunicacao entre os n s, o ULID permanece constante. Essa possibili o dade e considerada pouco frequente visto que o Shim6 n o foi desenvolvido diretamente a para redes cujos n s mudem de localizacao dinamicamente, como seria o caso das redes o m veis. o O Shim6 e representado como uma camada diretamente acima da camada de rede. Assim, tanto as aplicacoes quanto os protocolos de camadas acima da camada Shim6 uti lizam os ULIDs que foram mapeados a partir dos localizadores das estacoes de origem e destino. A camada Shim6 mant m o mapeamento por par de ULIDs. Portanto, todas as e conex es envolvendo o mesmo par origem-destino compartilham o mesmo mapeamento. o O mapeamento deve ser realizado de maneira consistente na origem e no destino para que os protocolos de camadas superiores vejam os pacotes sendo enviados utilizando os ULIDs m-a-m. Essa caracterstica e mantida mesmo que os pacotes sejam encaminha dos pela rede utilizando os localizadores como enderecos IP e mesmo que os localiza

dores mudem. Al m disso, o mapeamento realizado para o par de n s deve ser mantido e o independentemente do protocolo de camada superior e de qualquer outra conex o estaa belecida. Os protocolos de camadas superiores que est o cientes da operacao do Shim6 a podem associar mais de um par de localizadores a um unico par de ULIDs. No Shim6, uma determinada estacao de origem inicia uma transmiss o caso al a guma de suas aplicacoes possua pacotes a enviar. Nesse momento, o Shim6 pode se comunicar com o destino do pacote para conhecer possveis pares alternativos de locali zadores associados ao par de ULIDs. Essa comunicacao e possvel visto que o ULID e igual ao localizador da estacao, o que dispensa o uso de sistemas de mapeamentos. Os m ltiplos pares de localizadores s o utilizados para casos de falha. Se uma comunicacao u a falhar, o Shim6 pode testar novos pares de localizadores at que um deles restabeleca a e comunicacao. Ao encontrar esse par, os localizadores s o utilizados nos pr ximos paco a o tes, mas uma extens o de cabecalho e utilizada para que o destino saiba qual o ULID cora respondente ao novo par de localizadores. Essa extens o e chamada de r tulo de contexto a o (Context Tag). O uso do r tulo de contexto permite que as mudancas dos localizadores o permanecam transparentes para os protocolos de camadas superiores. O fato de o localizador inicial ser igual ao identicador pode levar a perodos de instabilidade. Caso o localizador de uma estacao mude, nada impede que o localizador anterior seja atribudo a outro n da rede. Assim, h a possibilidade de duas estacoes o a diferentes utilizarem o mesmo identicador j que o identicador e inicialmente igual a ao localizador. O Shim6 evita essa possibilidade forcando que as comunicacoes sejam terminadas quando uma ULID se tornar inv lida. Um mecanismo de recuperacao de a contexto e ent o acionado para que a outra estacao na comunicacao que ciente que a a ULID n o est mais relacionada com o localizador anterior. Esse procedimento e uma a a consequ ncia de se evitar sistemas de mapeamento, como p. ex. o rendezvous do HIP. e O mapeamento entre identicadores e localizadores ou entre enderecos locais e enderecos intradomnio e um problema em aberto para os diferentes protocolos de Loc/ID Split. No LISP, por exemplo, muitos sistemas s o avaliados para tornarem o sistema de a mapeamento escal vel e seguro. Os sistemas de mapeamento podem ser classicados em a PUSH ou PULL. Nos sistemas PUSH, o mapeamento mantido por elementos centraliza dores e enviado aos roteadores sem que os roteadores facam requisicoes. Essa estrat gia e pode aumentar a carga de controle enviada na rede, al m de manter todos os mapeamentos e conhecidos pelos roteadores de borda. O ponto positivo e que o mapeamento n o sofre a atrasos. Propostas como o NERD (Not-so-novel EID to RLOC Database) [Lear 2010] anunciam os mapeamentos conhecidos a todos os roteadores da rede sem a necessidade de requisicoes. Os sistemas PULL funcionam atrav s de requisicoes. Portanto, sempre e que um roteador de borda n o conhecer um determinado mapeamento, ele envia uma a requisicao para o sistema de mapeamento. Tais sistemas de mapeamento podem funcio nar como um DNS ou uma DHT (Distributed Hash Table) [Iannone e Bonaventure 2007]. Iannone e Bonaventure demonstram que sistemas de mapeamento baseados em DNS n o a sofrem com problemas de escala [Iannone e Bonaventure 2007]. Para isso, os autores de monstram que e possvel controlar o tamanho da mem ria cache dos n s a partir do ajuste o o do tempo de perman ncia dos mapeamentos na mem ria. Luo et al. [Luo et al. 2009] dee o monstram que sistemas baseados em DHTs tamb m podem alcancar desempenho satise fat rio em termos de escalabilidade. Sistemas como o LISP-ALT [Farinacci et al. 2009a] o

e LISP-CONS [Brim et al. 2008] s o sistemas hbridos, ou seja, que utilizam tanto a esa trat gia PULL quanto a PUSH. O LISP-ALT dene uma arquitetura na qual alguns roteae dores s o respons veis por manter os mapeamentos. Esses roteadores trocam informacoes a a baseado na estrat gia PUSH. J os roteadores de borda requisitam o mapeamento aos rotee a adores respons veis. O LISP-CONS difere do LISP-ALT pela organizacao dos roteadores a respons veis por manter os mapeamentos. No LISP-CONS, a estrutura desses roteadores a e hier rquica. Portanto, os mapeamentos s o trocados entre os roteadores em nvel hiea a rarquicamente superior atrav s da estrat gia PUSH. J os roteadores de borda requisitam e e a os mapeamentos aos roteadores de nvel hier rquico inferior que consultam os roteadores a em nvel superior tamb m atrav s de requisicoes. e e 2.4.2. Roteamento plano O roteamento plano e outra possibilidade para contornar os problemas oriundos da sem ntica sobrecarregada do endereco IP. Para isso, o roteamento plano extrapola o cona ceito da separacao entre localizacao e identicacao removendo o conceito de localizacao. O objetivo e rotear pacotes baseado apenas na identicacao dos n s. Assim, torna-se o necess rio garantir a unicidade do identicador e n o mais a relacao entre a localizacao a a do n e a topologia de rede. Uma vez que o roteamento seja baseado no identicador, o e n o mais em um endereco correlacionado com a topologia de rede, esse n pode se a o deslocar sem prejuzo das suas conex es. Al m disso, n o realizar a resolucao de no o e a mes evita o emprego de infraestrutura de rede, p. ex. DNS, e aumenta a disponibilidade da comunicacao j que o sistema de resolucao de nomes n o e mais um ponto de falha. a a O roteamento plano deve ser investigado apesar da premissa da Internet de manter no cabecalho dos pacotes informacao estruturada da localizacao das estacoes. Entretanto, trabalhos da area demonstram que esse tipo de proposta ainda enfrenta problemas de escalabilidade. At o momento, o ROFL (Routing On Flat Labels) [Caesar et al. 2006b] e o prine cipal trabalho em roteamento plano. O ROFL utiliza r tulos para identicacao dos n s o o e desassocia a identicacao da localizacao na rede. A operacao do ROFL e baseada no conceito de DHTs (Distributed Hash Tables), utilizadas comumente por protocolos de re des par-a-par. A motivacao principal do uso das DHTs e a sua capacidade de distribuicao homog nea de carga ou funcionalidades. Em uma rede par-a-par, p. ex., e desej vel que e a os dados armazenados pelos n s da rede sejam distribudos homogeneamente para evitar o n s sobrecarregados. A caracterstica de distribuicao homog nea, por conseguinte, leva o e as DHTs a serem aplicadas em sistemas que evitam estruturas hier rquicas. Por isso, o a ROFL utiliza as DHTs no roteamento ao inv s de distribuicao de conte do. e u As propostas para roteamento plano, incluindo o ROFL, devem funcionar tanto para comunicacoes entre n s no mesmo AS quanto para n s em ASes diferentes. Por o o tanto, as propostas devem denir protocolos para o estabelecimento e a manutencao das comunicacoes em ambos os casos. Os protocolos propostos pelo ROFL s o baseados a no Chord [Stoica et al. 2003] e no Canon [Ganesan et al. 2004], que s o sistemas de a distribuicao que utilizam DHTs. O primeiro e utilizado pelo ROFL como base para as comunicacoes intradomnio. J o segundo, e utilizado como base para as comunicacoes a interdomnio. Antes de apresentar o funcionamento do ROFL e interessante apresentar o funcionamento do Chord e do Canon.

 O Chord e um protocolo originalmente proposto para busca de conte do em reu des par-a-par. No Chord, cada tipo de dado e associado a uma chave que e escolhida em funcao do identicador utilizado na camada de aplicacao, p. ex. um nome de um arquivo em um sistema par-a-par. J na camada de rede, o Chord associa um identicaa dor a cada uma das chaves e tamb m associa identicadores a cada um dos n s. Ambos e o os identicadores s o obtidos com o uso de funcoes hash. Por m, o Chord mapeia um a identicador de chave a um n da rede. Assim, cada n ca respons vel por uma ou o o a mais chaves. Caso a chave identique um dado, este pode car armazenado no n correso pondente. As principais vantagens do Chord s o a distribuicao uniforme de chaves que a evita a sobrecarga de algum n em particular e o armazenamento de informacoes locais o de roteamento em cada n . O objetivo e aumentar a escalabilidade do sistema ao dividir o a carga de armazenamento de dados e de informacao de controle. O mapeamento entre os identicadores das chaves e dos n s e realizado em um o espaco de identicacao circular de m dulo 2m , onde m e o tamanho do identicador em o bits. Assim, um identicador de chave C e mapeado no primeiro n cujo identicador o e igual a C ou, se o n com identicador igual n o existir, ao primeiro n encontrado o a o seguindo o espaco de identicacao no sentido hor rio. A Figura 2.12(a) ilustra um espaco a 6 . Na gura, os identicadores que comecam com C s o os de identicacao de m dulo 2 o a identicadores das chaves e os que comecam com N, os dos n s. A gura mostra que o o identicador da chave C10 n o foi diretamente mapeado em um n com um identicador a o de mesmo n mero. Logo, C10 foi mapeada no pr ximo n no sentido hor rio, ou seja, u o o a no n N14. J o n N38 possui um identicador de chave que coincide com o seu pr prio o a o o identicador. O processo de localizacao b sico de um identicador de chave consiste a em uma busca no espaco circular. Essa busca e realizada salto-a-salto, no qual cada salto e um identicador de n . A localizacao termina quando o identicador da chave o pertencer ao intervalo entre o identicador do n analisado e o seu pr ximo n no sentido o o o hor rio. Nesse caso, a busca retorna o identicador desse pr ximo n . No Chord, cada a o o n armazena o identicador do pr ximo n no sentido hor rio e do anterior. Esses n s o o o a o s o chamados de n sucessor e predecessor, respectivamente. A Figura 2.12(b) mostra a o como e realizado o processo de localizacao de um identicador de chave no Chord a partir do n N8. Na gura, os n s N1 e N14 s o os n s sucessor e predecessor do n N8, o o a o o respectivamente. O n N8 busca a localizacao do identicador da chave C54. O processo o de localizacao e repetido pelos n s no crculo at encontrar a chave desejada. o e O espaco de identicacao circular permite que o n respons vel por um determi o a nado dado seja sempre encontrado, j que a busca pode apenas ser realizada no sentido a hor rio. Na Internet, entretanto, a rede e organizada hierarquicamente e a busca por um a determinado n pode exigir mais estados por roteador. Enquanto no Chord cada n preo o cisa apenas conhecer o seu sucessor e predecessor no espaco circular, na Internet, cada n o precisa saber o pr ximo salto para cada possvel destino. A vantagem da reducao de eso tados proposta pelo Chord, entretanto, insere um problema. Quanto menos estados forem armazenados por n , maior e a quantidade de saltos que o procedimento de localizacao o deve realizar. Esse compromisso e abordado pelo Chord ao introduzir uma tabela de roteamento por n . No Chord, cada n mant m uma tabela de m linhas para agilizar o o o e processo de localizacao dos identicadores das chaves. Cada linha da tabela identica o n respons vel pelos identicadores de chaves distantes at 2m . Portanto, cada linha o a e

 da tabela e uma tupla composta pelo identicador da chave (igual ao n mero do identiu cador do n realizando a busca mais 2i1 , onde 1 i m) e pelo identicador do n o o respons vel por essa chave. Caso o identicador da chave seja maior que o ultimo idena ticador na lista, a busca e adiantada at o primeiro n no sentido hor rio ap s a lista. e o a o A Figura 2.12(c) ilustra o procedimento de localizacao de C54 realizado por N8 com o uso de tabela de roteamento. O n 8 adianta a sua busca at N42 j que o identicador o e a da chave buscada e maior que o identicador do ultimo n da tabela. O n 42 tamb m o o e adianta a localizacao saltando N48. Ao combinar o espaco de identicacao circular com a tabela de roteamento, o Chord prop e uma solucao para localizacao de identicadoo res de n s que aumenta a escalabilidade do sistema. A ideia de organizar a rede em um o ` espaco de identicacao circular pode ser aplicada a Internet tomando-se o cuidado para o seja garantido. Uma vez que um n tenha que o requisito de unicidade de identicaca o um identicador unico associado, independente da sua localizacao, seu identicador per manece o mesmo e a sua posicao no espaco de identicacao tamb m. Isso permite que os e n s possam se deslocar sem quebrar as conex es estabelecidas. o o

(a) Mapeamento entre iden- (b) Busca de identicador (c) Busca de identicador no Chord usando taticadores de chave e n . o no Chord. belas. Figura 2.12. Funcionamento do Chord.

Um problema do uso das DHTs como no Chord e que, embora o seu uso possibilite a distribuicao balanceada de carga entre os n s, o projeto de sistemas escal veis est o a a normalmente associado a sistemas com estruturas hier rquicas. Portanto, uma maneira de a aumentar a escalabilidade do sistema e aplicar hierarquia sem perder as principais van tagens das DHTs. O Canon [Ganesan et al. 2004] e uma proposta para estender o Chord ` adicionando hierarquia a sua estrutura. Embora contradit rio, o objetivo e construir um o sistema hbrido para reunir as principais vantagens das DHTs e dos sistemas com estru ` turas hier rquicas. Uma das motivacoes e a adaptacao mais suave a realidade da Internet a que e organizada de maneira hier rquica e dividida em diferentes ASes. A Figura 2.13(a) a mostra um exemplo ilustrativo da estrutura fsica da rede da COPPE, que e a instituicao respons vel pela p s-graduacao em engenharia da UFRJ. A COPPE e dividida em diferena o tes programas (Engenharia El trica, Mec nica etc.) e cada programa possui laborat rios e a o aliados. Portanto, a organizacao das redes segue a mesma estrutura hier rquica como na a Internet, onde cada uma das redes representa um domnio. A estrutura utilizada e uma arvore na qual os laborat rios GTA e LPS s o folhas e a raiz e a COPPE. o a No Canon, cada domnio folha na arvore dene um espaco de identicacao circu lar, assim como no Chord. A diferenca est nos domnios internos da arvore que denem a

(a) Hierarquia entre domnios.

(b) Uni o de espacos de enderecamento. a

Figura 2.13. Funcionamento do Canon.

um espaco de identicacao circular que une os seus n s e mais os n s dos seus domnios o o lhos. Essa estrutura e repetida hierarquicamente at alcancar o domnio raiz, no exemplo e da Figura 2.13(a), o domnio da COPPE. A identicacao dos n s deve ser unica global o mente e cada n deve criar uma tabela de roteamento baseada no m dulo do espaco de o o identicacao circular da rede. A Figura 2.13(b) ilustra o espaco de identicacao circular m dulo 26 . O n N0 do GTA possui entradas em sua tabela de roteamento para identio o cadores de chaves que est o associadas aos n s N5 (chaves 1, 2 e 4) e N33 (chaves 8, a o 16 e 32). J o n N10 do LPS possui entradas para identicadores de chaves associadas a o ao n N43 (chaves 11, 12, 14, 18, 26 e 42). A uni o do espaco de enderecamento do o a GTA com o do LPS mant m todas as entradas estabelecidas. Com a uni o, novas entrae a das s o adicionadas seguindo duas regras pr -denidas. A primeira regra dene que um a e n N do GTA pode criar uma ligacao com um n N do LPS se e somente se N for o o o n mais pr ximo que esteja distante de no m ximo 2m . J a segunda regra dene que o o o a a n N que atende o requisito da regra anterior deve ser mais pr ximo de N do que qualo o quer outro vizinho de N do GTA. Essa segunda condicao limita o n mero de entradas aos u n s do espaco de enderecamento vizinho mais pr ximos dos identicadores de chaves o o entre N < N + 2i1 < N + 2m do que os n s do pr prio espaco. Na Figura 2.13(b), os o o espacos de enderecamento unidos demonstram as entradas da tabela de roteamento que foram formadas pelos n s N0 e N10 com o processo de uni o de espacos. Note que N0 o a ` ` pode manter entradas para N2 devido as dist ncias 1 e 2 e para N10 devido a dist ncia a a 8, de acordo com a primeira regra. Entretanto, N10 est mais distante de N0 que N5 que a pertence tamb m ao GTA. Portanto, a entrada correspondente n o e adicionada por N0, e a como denido pela segunda regra. A uni o de espacos circulares e feita recursivamente desde os n s folhas at o a o e n raiz. Ao nal, o espaco de enderecamento circular e formado englobando todos os o n s da rede. O roteamento realizado no Canon segue uma abordagem gulosa na qual um o determinado pacote e encaminhado at o identicador no mesmo nvel hier rquico mais e a pr ximo ao destino. Por exemplo, na Figura 2.13(b), os pacotes enviados pelo n N2 ao o o importante mencionar n N42 seguem o caminho no LPS at N10 e de N10 at N42. E o e e que as entradas existentes na tabela de roteamento de cada n s o preservadas mesmo o a ap s o processo de uni o. Al m disso, o processo realizado pelo Canon pode levar em o a e conta domnios que pertencam a ASes diferentes. Semelhante ao Chord, cada n no ROFL possui um n sucessor e um n preo o o decessor na rede intradomnio. Entretanto, o ROFL considera que os n s pertencem a o

uma rede local de acesso que oferece conectividade via um roteador de interconex o, dea nominado pelo ROFL como roteador hospedeiro. Esse roteador armazena os caminhos completos que o ligam at os roteadores hospedeiros dos n s sucessores e predecessores e o dos seus n s h spedes. Da mesma maneira, os roteadores hospedeiros dos n s sucessores o o o e predecessores tamb m armazenam o caminho completo no sentido reverso. O camie nho completo e denido como a sequ ncia salto-a-salto dos identicadores de todos os e roteadores fsicos entre hospedeiros e e utilizado durante o encaminhamento de pacotes para roteamento pela fonte. A Figura 2.14(a) ilustra os n s sucessor (SGTA ) e predecessor o (PGTA ) de N no domnio do GTA. Note que tanto o caminho armazenado at o n sucessor e o (N, R1 , R2 , SGTA ) quanto o caminho at o n predecessor (N, PGTA ) iniciam e terminam e o nos roteadores hospedeiros. A rede tamb m pode possuir roteadores que originam ou e recebem tr fego. Nesse caso, os roteadores tamb m possuem sucessores e predecessores a e e os caminhos s o armazenados semelhantemente ao caso dos n s h spedes. O roteaa o o dor hospedeiro e respons vel por interconectar um n que entra na rede ao espaco de a o identicacao circular. Para tanto, o roteador hospedeiro primeiramente autentica o n en o trante, para somente ap s encontrar os roteadores sucessores e predecessores desse n no o o espaco circular. Caso o roteador hospedeiro falhe, os n s h spedes devem perceber isso o o atrav s de temporizadores expirados. Nesse caso, os n s h spedes procuram um roteador e o o alternativo para entrar novamente na rede ou elegem um roteador hospedeiro de reserva. Essa ultima opcao s e possvel se mais de um roteador hospedeiro for escolhido desde a o primeira entrada do n h spede. o o

(a) N s sucessores e predecessores. o

(b) Encaminhamento de pacotes.

Figura 2.14. Funcionamento do ROFL intradomnio.

Os roteadores hospedeiros podem usar mem ria cache para armazenar ponteiros o para identicadores de n s. Cada ponteiro e uma refer ncia aos caminhos para os n s o e o sucessores e predecessores dos seus n s h spedes. Os roteadores hospedeiros tamb m o o e podem armazenar ponteiros referentes a caminhos que passam atrav s dele vindos de e outros n s da rede que n o sejam nem sucessores ou predecessores dos seus h spedes. o a o O primeiro tipo de caminho possui preced ncia sobre o posterior, uma vez que a cache e e limitada em tamanho. Assim como no Chord, o roteamento e realizado de maneira gulosa auxiliada por uma tabela de roteamento que possui ponteiros para identicadores de n s. Logo, um pacote enviado para um determinado identicador e encaminhado o atrav s do ponteiro mais pr ximo daquele identicador de destino. No pior caso, um e o pacote pode ser encaminhado ao longo de todos os sucessores. O conceito de proximidade entre ponteiros est relacionado com a proximidade entre identicadores. Os roteadores a hospedeiros mant m uma lista ordenada de identicadores e sempre que v o encaminhar e a

um pacote, eles comparam o identicador com a sua lista. O roteador que possuir o identicador menor mais pr ximo do identicador do destino e utilizado como pr ximo o o salto. A Figura 2.14(b) ilustra o encaminhamento de pacotes salto-a-salto. O pacote e encaminhado entre a origem N e o destino D passando por todos os n s sucessores dos o roteadores hospedeiros no caminho. O ROFL dene procedimentos para casos de falhas de roteadores. Em caso de falha, os roteadores vizinhos inspecionam todos os seus ponteiros em cache e enviam mensagens de falha ao longo de qualquer caminho que possua o roteador com problemas. Se for um problema de um n h spede, o roteador envia mensagens de falha aos predeceso o sores e sucessores do n que falhou. Quando uma mensagem de falha chega a roteadores o hospedeiros, eles recuperam os n s sucessores e predecessores do n com problemas na o o tentativa de manter a rede conectada. Entretanto, nem sempre isso e possvel. Por isso, os roteadores sempre distribuem rotas aos roteadores mais est veis para evitar particionaa mentos da rede. Os roteadores localmente desempenham checagens de correcao baseados no conte do das mensagens recebidas e ent o executam protocolos de recuperacao de paru a ticionamentos para assegurar que a rede convirja em um unico espaco de enderecamento. ` No interdomnio, a operacao do ROFL e semelhante a do intradomnio, exceto por considerar polticas no nvel de ASes. Tais polticas podem ser modeladas como um grafo de ASes organizado de maneira hier rquica. Cada AS forma um espaco de identicacao a circular e os diferentes ASes se comunicam atrav s da estrutura em arvore interdomnio. e Para possibilitar a comunicacao entre os diferentes ASes, os espacos de identicacao de vem se unir. O processo de uni o entre ASes diferentes pode ser dividido em tr s etapas. a e Na primeira etapa, cada AS deve descobrir todos os outros ASes hierarquicamente superiores com os quais possui acordos. Na segunda etapa, os ASes se unem recursivamente, assim como no Canon, utilizando os roteadores que compartilham enlaces em comum em ASes diferentes. Na ultima etapa, cada AS dene ponteiros para roteadores em ASes vizinhos que diminuam o caminho entre eles. Um determinado n em um AS pode ser o globalmente alcancavel se o seu roteador hospedeiro mantiver predecessores e sucessores referentes em cada nvel de hierarquia de ASes, como ilustrado na Figura 2.15(a). Se melhante ao caso intradomnio, no nvel dos ASes o roteamento tamb m e realizado pela e fonte. Assim, um determinado pacote e encaminhado de acordo com o caminho de ASes pr -estabelecido armazenado nos roteadores hospedeiros como um vetor de caminho do e BGP. Caso haja falha nos enlaces entre ASes, os ASes restabelecem a sub- rvore formada a entre eles para garantir que a rede mantenha conectividade. Se isso n o for possvel, enlaa ces operacionais podem ser adicionados. As polticas entre diferentes sistemas aut nomos o permitem que alguns caminhos sejam tratados como caminhos de reserva. O encaminhamento de pacotes no ROFL segue propriedades de isolamento. Uma ` comunicacao entre n s no mesmo AS n o utiliza ponteiros para n s externos aquele AS. o a o o entre n s em ASes diferentes resulta em pacotes Semelhantemente, uma comunicaca o encaminhados atrav s do menor caminho possvel na arvore. Logo, o caminho formado e entre dois ASes deve seguir atrav s do primeiro ascendente comum. A Figura 2.15(b) e ilustra o isolamento entre os ASes no ROFL. Caso N8 queira se comunicar com N20, ele o far sem utilizar ponteiros externos. Entretanto, caso N8 queira se comunicar com a N16, N8 precisa utilizar o n sucessor e predecessor no domnio do PEE, subindo at o o e primeiro nvel hier rquico em comum. Equivalentemente, a comunicacao entre N8 e N14 a

(a) N s sucessores no ROFL. o

(b) Hierarquia de encaminhamento no ROFL.

Figura 2.15. Funcionamento do ROFL interdomnio.

utiliza o domnio da COPPE para a comunicacao. Como visto, o encaminhamento de pacotes segue uma estrutura hier rquica. Isso demonstra que apesar de utilizar um espaco a de identicacao plano, quest es como escalabilidade e divis o da Internet em ASes ainda o a requerem que o roteamento seja feito de maneira estruturada hierarquicamente. ` Os problemas de escalabilidade do ROFL est o ligados a quantidade de ponteia ` ros armazenados para outros n s da rede, a carga de controle para o estabelecimento dos o ` e espacos de identicacao circulares, a lat ncia da entrada dos n s e recuperacao de falhas. o Al m do ROFL, outro exemplo de protocolo que planica o espaco de identicacao e o e VRR (Virtual Ring Routing) [Caesar et al. 2006a]. O VRR, por m, limita o escopo do e roteamento a uma rede sem-o de m ltiplos saltos. Assim, o VRR reduz o problema da u ` escalabilidade j que lida com um n mero menor de n s se comparado a Internet. O funa u o cionamento do VRR e semelhante ao do ROFL intradomnio. No VRR, entretanto, cada n N mant m uma tabela de caminhos para os m vizinhos consecutivos mais pr ximos o e o no espaco de identicacao circular. Desses m vizinhos, metade possui identicadores no sentido hor rio e a outra metade no sentido anti-hor rio ao de N. A Figura 2.16(a) mostra a a os m vizinhos de N8, m = 4. Cada caminho e denido pelos identicadores de origem e destino e pelos identicadores do pr ximo salto na rede fsica. A tabela de caminhos do o VRR e diferente da tabela de roteamento do ROFL pois armazena n s sucessores e preo decessores consecutivos. Al m disso, o VRR utiliza informacoes da rede fsica j que foi e a desenvolvido para uso em redes sem-o, diferente do ROFL. No VRR, essa informacao evita que vizinhos fsicos cujos enlaces n o oferecam qualidade mnima sejam usados a como pr ximos saltos. o Diferente do ROFL e do VRR, mas ainda na direcao da planicacao do espaco de enderecamento, est o AIP (Accountable Internet Protocol) [Andersen et al. 2008]. O a AIP e outra proposta para roteamento na Internet que evita o uso de prexos e enderecos sem classes denidas (Classless Inter-Domain Routing - CIDR). Para isso, ele retorna ` a estrutura original de enderecos da Internet que era a concatenacao do identicador de rede com o da estacao. Essa estrutura possua dois nveis hier rquicos, um de rede, utili a zado pelos roteadores para encaminhar pacotes, e outro de estacoes. Logo, O AIP utiliza uma abordagem com dois nveis hier rquicos, diferente do ROFL e do VRR. No AIP, o a nvel dos roteadores e chamado de domnio de responsabilizacao (Accountability Domain - AD) e o das estacoes e chamado de identicador de pontos nais (End-point IDentier

(a) Vizinhos no espaco de identicacao circular no VRR.

(b) Encaminhamento no AIP.

Figura 2.16. Outros protocolos de roteamento plano.

- EID). Essa divis o reduz os problemas de escalabilidade comparado ao ROFL, mas n o a a desassocia completamente o identicador do n do identicador da rede. Um dos probleo mas enfrentados pelo AIP e como relacionar os ASes aos domnios de responsabilizacao. Na Internet, os ASes possuem identicadores totalmente desassociados dos prexos de enderecos anunciados por eles. No AIP, o identicador do domnio de responsabilizacao e utilizado nos dois casos. A estrutura de enderecamento do AIP e formada pela concatenacao do identica dor do domnio (AD) com o identicador do n (EID). O AD e o EID s o formados a o a partir de sadas de uma funcao hash. Ambos s o calculados sobre a chave p blica que a u identicam o domnio e a estacao, respectivamente. Essa caracterstica permite que os enderecos possam ser autenticados. As conex es TCP s o estabelecidas utilizando ape o a nas o identicador do n , assim h a possibilidade dos n s se deslocarem entre domnios o a o diferentes. O unico requisito e a garantia da unicidade do identicador do n , conquiso tada utilizando parte do endereco MAC no identicador. O encaminhamento de pacotes no AIP e feito utilizando roteamento pela fonte no nvel dos domnios. Isso ocorre porque tanto a aus ncia de organizacao hier rquica dos domnios quanto o n o emprego de pree a a xos de rede impedem que o encaminhamento seja feito por t cnicas de busca de melhor e prexo (best match prex). A Figura 2.16(b) mostra o caminho percorrido por um pacote desde sua origem EID1 at o seu destino EID5. O cabecalho do pacote possui entre outros e campos, os identicadores do n e do domnio de origem, os identicadores do n e do o o domnio do destino e as pilhas de identicadores de domnios entre a origem e o destino tanto no caminho direto quanto no reverso. O AIP, assim como o ROFL, ainda possui problemas de escalabilidade e aplicabilidade na Internet. Em ambos os casos, a infraestrutura da Internet desde sistemas nais at roteadores precisariam ser alterados para adotar qualquer uma das propostas. Pore tanto, o emprego dessa estrat gia ainda n o e obvio apesar de solucionar problemas como e a a mobilidade de estacoes. 2.4.3. Mobilidade de Rede ` A mobilidade est normalmente associada a mobilidade de uma unica estacao e a n o a mobilidade de uma rede, onde uma rede e um conjunto de uma ou mais estacoes a ` conectadas. Um exemplo disso e o modelo base do IP m vel que dene a exist ncia de o e um agente estrangeiro, um agente domiciliar, uma estacao correspondente e uma estacao

m vel. Esse modelo representa uma limitacao j que a popularizacao das redes sem-o o a ` requer que o suporte a mobilidade seja estendido aos casos nos quais redes inteiras se movem e n o apenas uma unica estacao. Exemplos tpicos de redes m veis s o as redes a o a ad hoc, as redes veiculares [Alves et al. 2009] e at mesmo as redes formadas entre dise positivos de comunicacao baseados no IP carregados por pessoas (Personal Area Network - PAN). Em todos esses cen rios as diferentes estacoes podem se deslocar em conjunto e a a ` podem estar conectadas entre si com acesso a Internet. E v lido ressaltar que o mais im portante e manter as conex es previamente estabelecidas ativas mesmo em face da troca o do ponto de interconex o a Internet. a ` No modelo base do IP m vel, cada estacao da rede e tratada como uma estacao isoo lada. Caso uma das estacoes n o tenha acesso direto ao ponto de interconex o, ou ponto a a de acesso, essa estacao perde a conectividade com a rede, como visto na Figura 2.17(a). Propostas como o NEMO (NEtwork MObility) [McCarthy et al. 2009] e as suas variantes NEMO+ [McCarthy et al. 2008b], Light-NEMO+ [Sabeur et al. 2006] e MANEMO (MAnet NEMO) [McCarthy et al. 2009, McCarthy et al. 2008a] v m sendo realizadas para e possibilitar que mesmo os n s sem acesso direto ao ponto de interconex o permanecam o a ` conectados e com acesso a Internet. Assim, a conectividade pode ser garantida n o soa mente para uma estacao, mas para uma rede inteira. De maneira geral, o NEMO dene que uma das estacoes da rede m vel deve ser escolhida para funcionar como um roteador o ` que prov acesso a Internet a todas as outras estacoes da rede m vel. Assim, as estacoes e o que n o possuem acesso direto ao ponto de interconex o devem encaminhar os seus pacoa a tes at esse roteador, denominado roteador m vel (Mobile Router - MR). A Figura 2.17(b) e o ilustra simplicadamente o funcionamento das propostas para mobilidade de rede, na qual o n m vel A da Figura 2.17(a) exerce a funcao de roteador m vel. o o o

(a) Modelo b sico do IP m vel. a o

(b) Mobilidade de rede.

Figura 2.17. Conectividade em redes sem-o moveis.

O IETF (Internet Engineering Task Force) criou o grupo de trabalho NEMO para trabalhar no tema de mobilidade de rede [Perera et al. 2004]. O grupo de trabalho NEMO e respons vel pelo desenvolvimento e padronizacao dos protocolos para suporte da moa bilidade de rede sobre o IP. O projeto inicial e fortemente baseado no IP m vel. Dessa o forma, o NEMO pode ser implementado como uma extens o do IP m vel, na qual as a o funcionalidades denidas pelo IP m vel para uma estacao s o transferidas para o roteo a ador m vel. Como consequ ncia, as alteracoes ap s eventuais mudancas de ponto de o e o interconex o com a Internet s o tratadas apenas pelo roteador m vel. Tais alteracoes, a a o como mudanca de endereco IP (Care-of-Address - CoA) e restabelecimento do t nel com u

o agente domiciliar, tornam-se transparentes aos outros n s da rede m vel. Com excecao o o do roteador m vel, todos os outros n s da rede mant m suas conguracoes constantes. o o e O NEMO tamb m utiliza agentes domiciliares como o IP m vel para manutencao da coe o nectividade. No NEMO, os roteadores m veis tamb m enviam mensagens de atualizacao o e aos seus agentes domiciliares. Entretanto, os agentes domiciliares associam o endereco do roteador m vel na rede estrangeira (CoA) a um prexo de rede ao inv s de apenas a um o e endereco IP. Assim, todos os pacotes recebidos pelo agente domiciliar destinados a um dos n s da rede m vel s o encapsulados e encaminhados atrav s do t nel at o roteador o o a e u e m vel. O roteador m vel, por sua vez, desencapsula os pacotes recebidos e os encaminha o o at os seus respectivos destinos na rede m vel. Al m disso, o roteador m vel tamb m e o e o e encaminha para a Internet todos os pacotes oriundos da rede m vel. Caso haja ltragem o de egresso na rede estrangeira, os pacotes s o encapsulados e encaminhados atrav s do a e t nel no sentido reverso at o agente domiciliar. O agente domiciliar, por m, desencapu e sula os pacotes e os encaminha via roteamento IP at os n s correspondentes na Internet. e o A Figura 2.18 ilustra o caminho seguido pelos pacotes usando o NEMO.

Figura 2.18. Encaminhamento de pacotes no NEMO.

O grupo de trabalho respons vel pelo NEMO padronizou inicialmente um proa tocolo de suporte b sico (NEMO Basic Support Protocol - NEMO BS) para o IPv6 e a tem abordado diferentes problemas em outros documentos, inclusive a implementacao do NEMO sobre o IPv4 [Devarapalli et al. 2005]. A sinalizacao utilizada pelo NEMO BS e uma extens o das mensagens denidas pelo IP m vel. As mensagens do NEMO BS a o possuem uma ag adicional que identica se a mensagem foi enviada por um roteador m vel ou por um n m vel. Essas mensagens s o enviadas utilizando o cabecalho de o o o a extens o de mobilidade, no caso do IPv6; ou mensagens de controle sobre o UDP, no a caso do IPv4. As mensagens mais utilizadas pelo NEMO BS s o as mensagens relatia ` vas a atualizacao de localizacao do roteador m vel (binding updates). As mensagens de o atualizacao de associacao com as redes estrangeiras e os respectivos reconhecimentos s o a utilizadas para noticar os agentes domiciliares do novo ponto de interconex o com a a Internet (CoA). As mensagens de atualizacao cont m o novo CoA, a ag adicionada pelo e NEMO BS e o prexo da rede m vel. Este ultimo, por m, e uma opcao que depende do o e modo de operacao do NEMO BS, que pode ser implcito ou explcito. No modo implcito, as mensagens de atualizacao n o cont m o prexo da rede m vel. Nesse caso, os agen a e o tes domiciliares descobrem o prexo de alguma maneira n o denida pelo protocolo de a ` suporte b sico. J no modo explcito, o prexo da rede e adicionado as mensagens de a a atualizacao. Uma vez recebida a mensagem de atualizacao, independente do modo, os agentes domiciliares enviam o reconhecimento positivo correspondente. A Figura 2.18

ilustra como o NEMO BS especica o roteamento dos pacotes enviados e recebidos pelos n s da rede m vel. Os roteadores m veis possuem uma interface IPv6 ou IPv4 perteno o o ` cente a rede m vel, interface de ingresso que pode ser congurada de maneira est tica; o a ` e outra interface conectada a rede que oferece conex o de sada para a Internet, interface a de egresso. A interface de egresso e registrada na rede domiciliar a partir da associacao realizada com o endereco IP da rede estrangeira (CoA). Um t nel bidirecional e estabe u lecido entre o roteador m vel e o seu agente domiciliar. O agente domiciliar, ao inv s o e de somente encaminhar o tr fego recebido destinado ao roteador m vel atrav s do t nel, a o e u encaminha tamb m todo tr fego do prexo de rede associado ao roteador m vel. e a o O protocolo de suporte b sico NEMO BS deve lidar com desaos relacionados a com o ambiente de operacao e com a forma de implementacao escolhida para estender o IP m vel. Desaos relacionados com a seguranca e com o desempenho devem ser consio derados. Por exemplo, para garantir que a origem dos pacotes enviados atrav s do t nel e u seja verdadeira, tanto o roteador m vel quanto o agente domiciliar devem checar se o o ` endereco IP de origem dos pacotes e um endereco IP pertencente a faixa de enderecos da rede domiciliar. Embora os desaos relacionados com a seguranca sejam relevantes, muitos trabalhos na area visam aumentar o desempenho do NEMO. Um dos problemas frequentemente abordados e a ineci ncia do roteamento. Como visto, caso um n da rede e o m vel deseje se comunicar com um n na Internet, chamado de n correspondente, todos o o o os seus pacotes devem ser enviados primeiramente ao seu agente domiciliar. O agente domiciliar, ent o, encaminha os pacotes at o n da Internet, o que torna o roteamento a e o sub- timo. O problema pode ser agravado considerando que um unico roteador m vel o o pode ter associado a ele mais de uma rede m vel. Fundamentalmente, nada impede que o coexistam mais de uma rede m vel e que o roteador m vel de uma rede utilize o roteador o o m vel de outra rede para se comunicar com a Internet. Nesse caso, o NEMO e conheo cido como Nested NEMO [McCarthy et al. 2008b] e as comunicacoes podem ser bastante inecientes visto que todo tr fego enviado pelos roteadores m veis devem sempre passar a o pelos seus agentes domiciliares. A Figura 2.19 ilustra o problema.

Figura 2.19. Problema conhecido como Nested NEMO.

Propostas para aumentar a eci ncia do roteamento utilizam caminhos diretos e entre os n s da rede m vel e os n s da Internet e at mesmo entre os n s em redes o o o e o m veis diferentes. Algumas propostas analisam a possibilidade do uso de roteamento o pela fonte para evitar que os pacotes passem sempre pelos agentes domiciliares. O NEMO+ [McCarthy et al. 2008b] prop em tr s protocolos para tornar as comunicacoes o e

envolvendo n s de redes m veis vizinhas mais ecientes. Esse tipo de comunicacao o o ` ocorre quando uma rede m vel n o possui acesso direto a Internet, e assim utiliza a rede o a vizinha para encaminhar o seu tr fego, e quando os n s m veis de diferentes redes desea o o jam se comunicar. O primeiro protocolo proposto pelo NEMO+ e o TD (Tree Discovery). Esse protocolo e utilizado para auxiliar os roteadores m veis a escolherem qual dos roo teadores m veis vizinhos oferece o melhor caminho at a Internet. A escolha e baseada o e nos an ncios IPv6 de descoberta de vizinhanca enviados pelos vizinhos. Cada an ncio u u cont m o caminho utilizado at o ponto de interconex o com a Internet obtido atrav s e e a e de mensagens ICMPv6. Esse caminho representa um ramo da arvore formada desde o ponto de interconex o da rede (raiz) e os roteadores m veis vizinhos (folhas). Ao recea o ber o an ncio, cada roteador escolhe o ramo da arvore que mais lhe conv m se associar. u e Al m disso, as mensagens de descoberta de vizinhanca podem ainda ser utilizadas para e evitar a formacao de lacos de roteamento (loops). Outro protocolo, o NINA (Network In Node Advertisement) e utilizado para anunciar aos roteadores m veis localizados em o posicoes mais pr ximas ao ponto de interconex o os prexos das sub-redes associados a o a cada roteador m vel. Esses an ncios possibilitam que as comunicacoes entre n s m veis o u o o associados a diferentes redes da mesma arvore possam se comunicar sem a necessidade do uso dos agentes domiciliares. A Figura 2.20 ilustra o caminho percorrido pelos pacotes do n B na rede m vel B at o n A na rede A com e sem o uso do protocolo NINA. o o e o

(a) Encaminhamento sem o protocolo NINA.

(b) Encaminhamento com o protocolo NINA.

Figura 2.20. Encaminhamento com e sem o uso do protocolo NINA.

O ultimo protocolo, chamado RRH (Reverse Routing Header), e usado para tornar o roteamento de pacotes enviados para a Internet tamb m mais eciente. No RRH, e todo roteador m vel antes de encaminhar um pacote para a Internet atualiza o endereco o IP de origem do pacote. O procedimento de atualizacao estabelece que o endereco IP de origem deve ser o do roteador m vel que encaminha o pacote e o endereco de origem o anterior deve ser armazenado em uma lista no cabecalho. Essa lista cont m o endereco e IP de todos os roteadores m veis j atravessados. Como o endereco IP de origem do pao a cote que e recebido pelo ponto de interconex o e do ultimo roteador m vel, o pacote ser a o a somente encaminhado at o agente domiciliar desse ultimo roteador antes de ser enviado e at o n correspondente. O RRH dene que o cabecalho contendo a lista de enderecos e o IP de todos os roteadores m veis deve ser adicionado pelo agente domiciliar no caminho o reverso para que o pacote possa ser entregue ao n m vel de origem. Caso contr rio, o o o a pacote chegaria ao ultimo roteador m vel e n o seria possvel identicar a verdadeira orio a gem do pacote. O Light-NEMO+ [Sabeur et al. 2006] possui uma abordagem um pouco

 diferente do protocolo RRH. No Light-NEMO+, o ultimo roteador armazena um identicador do uxo, semelhante a um cookie, e encaminha o pacote at o n correspondente e o na Internet. Os pacotes cuja fonte ou destino estejam na rede m vel tamb m carregam o e o cookie de identicacao do uxo. Assim, todo pacote vindo da Internet recebido pelo ultimo roteador m vel possui uma identicacao que pode usada para mapeamento do pao cote para o uxo correspondente. Note que o protocolo RRH usava roteamento pela fonte para identicar o destino ou a origem do pacote na rede m vel. J o Light-NEMO+ utiliza o a um cookie e, portanto, dispensa o uso do roteamento pela fonte. O MANEMO (MAnet NEMO) [McCarthy et al. 2008a] e um protocolo que tem por objetivo garantir que os n s m veis de uma rede ad hoc possam sempre ser alcancados o o de qualquer ponto na Internet. O roteador m vel que executa o protocolo MANEMO o possui sua interface de ingresso congurada conforme a rede estrangeira visitada e a interface de egresso congurada conforme a rede ad hoc a qual faz parte. A interface de egresso executa um protocolo de roteamento ad hoc, p. ex. o OLSR [Clausen et al. 2001] congurado para se anunciar como gateway para a Internet. A arquitetura unicada MA NEMO (Unied MANEMO Architecture - UMA) [McCarthy et al. 2009] e uma proposta para unicar os protocolos NEMO e assim garantir conectividade permanente aos n s da o rede ad hoc. A UMA dene a maneira pela qual os diferentes n s m veis conectam a o o Internet, via acesso direto a pontos de interconex o ou via outras redes m veis, e como a o responsabilidade os t neis entre os diferentes agentes domiciliares s o estabelecidos. E u a dos agentes domiciliares identicarem os t neis criados para comunicacao com cada um u dos n s m veis assim como o restabelecimento da comunicacao caso haja mudancas no o o posicionamento desses n s. A alteracao do posicionamento dos n s m veis pode levar a o o o mudancas do roteador m vel e, consequentemente, dos t neis previamente estabelecidos. o u A arquitetura UMA deve lidar com a dinamicidade da rede. 2.4.4. Multiplos caminhos A Internet atual e baseada em algoritmos de roteamento de caminho unico. Dessa forma, os protocolos intradomnio e, principalmente, os interdomnio representados pelo BGP anunciam aos seus vizinhos apenas uma unica opcao de caminho para cada destino da rede. Uma maneira de contornar essa limitacao e implementar os m ltiplos caminhos u e atrav s de roteamento pela fonte. A denicao de rotas a priori e uma solucao para e utilizar caminhos diferentes do padr o anunciado pelos protocolos de roteamento. Um a exemplo de tecnologia que usa roteamento pela fonte e o PNNI (Private Network-toNetwork Interface ou Private Network Node Interface) utilizado no ATM. O PNNI divide a topologia da rede em diferentes nveis hier rquicos e dene por quais roteadores de cada a nvel os pacotes devem ser encaminhados [Kaur et al. 2003]. O arcabouco BANANAS [Kaur et al. 2003] e outra proposta que utiliza rotea mento pela fonte. O BANANAS usa o conceito de PathIDs para identicacao de ca minhos. O PathID e a sada de uma funcao hash dos identicadores dos v rtices e dos e enlaces que comp em o caminho entre dois n s quaisquer em uma rede. Os identicadoo o res dos v rtices, p. ex. enderecos IP, dos enlaces e de ASes s o globalmente conhecidos e, e a portanto, o PathID tamb m. O conceito de globalmente conhecido varia se o escopo e for intradomnio (identicadores de enlaces e v rtices) ou interdomnio (identicadores e de ASes). No caso intradomnio, o conhecimento global e conquistado por algoritmos

de roteamento baseados em estado do enlace, j no caso interdomnio, pelos vetores de a caminho do BGP. Para evitar colis es entre PathIDs, o PathID utilizado e estendido o a uma tupla formada pelo endereco IP do destino e o resultado da hash calculado. Os PathIDs s o adicionados a cada pacote para serem usados posteriormente durante o a encaminhamento. O BANANAS considera o roteamento intra e interdomnio. Vale mencionar que o BANANAS pode operar mesmo se apenas uma parte dos roteadores implementar o arcabouco proposto. Para isso, o c lculo do roteamento e realizado com restricoes, pois a considera como possveis caminhos aqueles que passam por roteadores que implemen tam o BANANAS. No intradomnio, o roteador fonte envia os pacotes pelos m ltiplos u caminhos encontrados, como ilustrado na Figura 2.21(a). Essa gura mostra a tabela de encaminhamento do roteador B e o encaminhamento realizado para pacotes de mesma origem e destino, mas que seguem caminhos diferentes na rede. A funcao hash usada para o c lculo dos PathIDs e denotada por h(.) na gura. Os pacotes carregam o PathID a correspondente ao caminho seguido. Um roteador intermedi rio que implementa o BAa NANAS utiliza para o encaminhamento, ao inv s da tupla prexo do endereco de destino, e pr ximo salto e interface de sada; a tupla prexo do endereco de destino, PathID de o entrada, interface de sada e PathID de sada. O PathID de entrada e a hash de todos os identicadores dos roteadores a partir do roteador atual at o destino e o PathID de e sada e a sada da funcao hash dos identicadores desde o pr ximo salto at o destino. o e Ao receber um pacote, um roteador busca a entrada correspondente em sua tabela de roteamento baseado no prexo do endereco de destino e no PathID de entrada. Antes de encaminhar o pacote, o roteador substitui o PathID do pacote pelo PathID de sada. Assim, o pr ximo roteador no caminho pode repetir o mesmo procedimento de encamio nhamento. No BANANAS, todos os roteadores devem executar um algoritmo que calcule m ltiplos caminhos j que o arcabouco foi proposto com essa nalidade. Mesmo os roteu a adores intermedi rios devem conhecer todos os possveis caminhos a partir dele pr prio a o at os possveis destinos da rede para encaminhar pacotes seguindo a rota escolhida pelas e fontes. O efeito do armazenamento dos m ltiplos caminhos e o aumento das tabelas de u roteamento. Entretanto, o BANANAS aborda esse compromisso utilizando t cnicas de e codicacao para armazenamento de informacoes compactadas. O roteamento interdomnio e uma abstracao do roteamento intradomnio substi tuindo roteadores por ASes. O funcionamento e bastante semelhante se considerado o papel dos roteadores de borda de entrada e sada do AS semelhante ao papel das interfa ces de entrada e sada de um roteador. Um PathID e adicionado aos pacotes, nesse caso chamado de e-PathID, no qual os identicadores s o os identicadores dos sistemas a aut nomos do caminho. Um roteador de borda de entrada de um AS ao receber um pacote o examina o prexo do endereco de destino e encaminha at o roteador de borda de sada e correspondente. Para isso, o endereco IP do roteador de borda de sada e utilizado como endereco de destino do pacote. O endereco de destino original e armazenado em uma estrutura em pilha na qual o endereco do roteador de borda de sada e inserido no topo. O roteador de borda de sada retira o seu endereco do topo da pilha e reinsere o endereco IP original do destino no pacote. O roteador de borda de entrada do pr ximo AS repete o o procedimento de empilhamento de enderecos IP. O PathID utilizado pelo roteamento em cada AS deve ser calculado baseado no caminho intradomnio escolhido. O uso de

m ltiplos caminhos interdomnio deve lidar com quest es relacionadas a polticas e acoru o dos entre ASes. Essas quest es n o afetam o encaminhamento intradomnio que pode ser o a realizado sempre atrav s de m ltiplos caminhos quando disponveis. A Figura 2.21(b) e u ilustra um exemplo de m ltiplos caminhos interdomnio entre fontes no AS1 e destinos u no AS8 . Ainda na gura, os roteadores A e B representam o roteador de borda de entrada e sada, respectivamente, do AS4 com relacao ao uxo do caminho 1. Logo, um pacote seguindo o caminho 1 utiliza como endereco IP de destino o endereco do roteador B ap s o ser encaminhado por A.

(a) Roteamento intradomnio.

(b) Roteamento interdomnio.

Figura 2.21. Encaminhamento de pacotes conforme o arcabouco BANANAS.

Redes sobrepostas tamb m podem ser utilizadas para prover m ltiplos caminhos. e u a A vantagem dessa abordagem e n o exigir modicacoes dos equipamentos do n cleo u da rede. Os m ltiplos caminhos s o escolhidos na camada sobreposta e o encaminhau a mento dos pacotes segue o processo tradicional da Internet. A arquitetura RON (Resilient Overlay Network) [Andersen et al. 2001], inicialmente proposta para recuperacao de falhas de rede, pode ser utilizada tamb m para proporcionar m ltiplos caminhos na e u Internet. Entretanto, uma das principais desvantagens do seu uso, assim como do ro teamento pela fonte, e a reducao do controle das rotas escolhidas por parte dos ASes interessante para esses ASes escolherem os vizinhos para engenharia de de tr nsito. E a tr fego e estabelecimento de acordos comerciais. O protocolo MIRO (Multipath Interdoa main ROuting) [Xu e Rexford 2006] oferece maior exibilidade aos ASes de tr nsito e, a por isso, n o usa nem redes sobrepostas nem roteamento pela fonte. O MIRO baseia-se na a negociacao entre ASes vizinhos para uso de m ltiplos caminhos. Embora possivelmente u os m ltiplos caminhos existam, cada AS anuncia apenas o caminho que mais lhe conv m u e por quest es de polticas, implementacao dos protocolos e escalabilidade. Entretanto, o o MIRO argumenta que um determinado AS deve requisitar os m ltiplos caminhos, caso u tenha interesse. Assim, problemas de escalabilidade s o contidos e a implementacao em a toda Internet pode ser feita de maneira gradual. Um AS que n o use o MIRO n o responde a a ` as requisicoes por caminhos alternativos. O encaminhamento, nesse caso, acontece como na Internet atual. A Figura 2.22 ilustra o procedimento de negociacao entre os roteadores A e B por caminhos alternativos. O roteador A pertencente ao AS2 n o deseja encaminhar a o seu tr fego atrav s do caminho padr o anunciado pelo AS4 que e atrav s do AS6 . O a e a e AS4 oferece um caminho alternativo atrav s do AS5 que e aceito pelo AS2 . Os ASes poe dem fazer requisicoes para mais de um AS vizinho para obter mais caminhos alternativos e os ASes podem anunciar caminhos alternativos conhecidos caso atenda uma requisicao recebida. Assim, um AS pode utilizar os caminhos alternativos dos seus vizinhos.

Figura 2.22. Negociacao do MIRO para conhecimento de caminhos alternativos.

No MIRO, os caminhos descobertos pelo BGP padr o continuam a ser utilizados e a os alternativos s o usados atrav s de procedimentos de tunelamento [Xu e Rexford 2006]. a e Logo, os pacotes que s o enviados via caminho alternativo s o enviados atrav s de um a a e t nel formado entre roteadores dos ASes vizinhos para garantir que o caminho alternativo u seja, de fato, utilizado. O identicador do t nel e enviado pelo AS mais pr ximo ao u o ` destino para o AS mais pr ximo a fonte ap s o t rmino do procedimento de negociacao. o o e Na Figura 2.22, um t nel entre os roteadores A e C e formado para encaminhamento de u pacotes pelo caminho alternativo. Os caminhos alternativos podem ser utilizados para divis o de tr fego, no qual o tr fego mais priorit rio utiliza o caminho alternativo, e para a a a a balanceamento de carga. A maneira como o tr fego e dividido depende das polticas a adotadas pelos ASes e pelos acordos entre eles. O processo de tunelamento pode ser chamado tamb m de encaminhamento atrav s e e de pontos de deex o [Wetherall 2006, He e Rexford 2008]. O ponto de deex o e o rotea a ador para o qual o caminho e desviado. No exemplo da Figura 2.22 o ponto de deex o e o a roteador C visto que o caminho BGP convencional levaria o tr fego atrav s do roteador B a e no AS4. Ap s o ponto de deex o, o tr fego pode seguir o caminho BGP convencional o a a caso nenhum caminho alternativo adicional seja usado. O emprego de pontos de deex o a pode ocorrer tamb m nas redes sobrepostas. Em casos extremos, o ponto de deex o e a poderia ser a estacao de um usu rio em outro AS que estivesse participando do rotea a mento. A participacao de usu rios pode impactar na escalabilidade da rede, mas evita a que modicacoes sejam feitas na rede. O ponto de deex o pode ser escolhido pela fonte a do tr fego. Entretanto, independente da situacao, o destino do t nel deve estar ciente do a u tunelamento para encaminhar o tr fego ao destino correto. Outra maneira de usar camia nhos alternativos sem o uso de tunelamento e atrav s da insercao de r tulos (tags) nos e o pacotes [Motiwala et al. 2008]. Um usu rio nal que queira que os seus pacotes sejam a encaminhados atrav s de caminhos alternativos deve inserir um r tulo no pacote referente e o ao caminho desejado. Os r tulos podem variar de acordo com as propriedades do camio nho alternativo. Caso um roteador n o reconheca o r tulo ou n o implemente o sistema, a o a ele pode encaminhar o pacote pelo caminho padr o. a 2.4.5. Escalabilidade na Internet Muitas propostas para interconex o de redes na Internet do futuro possuem ima pacto direto no n mero de entradas nas tabelas de roteamento. Por exemplo, o uso de u

m ltiplos caminhos requer mais de uma entrada nas tabelas para um mesmo destino. J u a o uso dos m ltiplos domiclios requer que uma rede seja identicada por mais de uma u faixa de enderecos possivelmente disjuntos prejudicando a agregacao. O uso de identi cadores planos, como os usados nas t cnicas de Loc/ID Split e roteamento plano, tamb m e e diculta a agregacao de rotas j que o espaco de enderecamento n o e organizado hi a a erarquicamente. Os identicadores planos, em especial, ainda aumentam o espaco de enderecamento da Internet o que pode tornar o problema da escalabilidade ainda mais grave. O aumento do espaco de enderecamento tamb m pode ser uma consequ ncia do e e uso do IPv6 se os problemas de agregacao persistirem. Al m do n mero de entradas nas e u u tabelas de roteamento, outro problema que afeta a escalabilidade na Internet e o n mero de mensagens de atualizacao de roteamento enviadas principalmente por ASes de borda. Es sas mensagens s o enviadas para todos os outros ASes e o n mero pode aumentar devido a u a conguracoes mal feitas ou a acoes maliciosas [Massey et al. 2007, Jen et al. 2008]. O aumento acelerado do n mero de entradas nas tabelas de roteamento pode imu pactar signicativamente a capacidade de armazenamento da maioria dos roteadores atuais. Tal impacto pode causar inconsist ncias entre as tabelas, ou at mesmo, problemas e e de funcionamento dos equipamentos de rede [Kim et al. 2009]. J o problema do n mero a u excessivo de mensagens de controle pode causar sobrecarga de tr fego e instabilidades a nas tabelas de roteamento. Uma das propostas mais simples investigadas para conter ambos os problemas e a reducao da exibilidade de faixas de enderecos disjuntas para o da exibilidade utiliza duas estrat gias. A primeira e m ltiplos domiclios. A reduca u e a eliminacao da possibilidade das redes de acesso utilizarem faixas de enderecos dife rentes da faixa de endereco dos seus ISPs. A segunda e a eliminacao da possibilidade das redes de acesso utilizarem faixas de enderecos desagregadas das faixas recebidas dos seus ISPs [Jen et al. 2008]. Nessa proposta, as redes de acesso somente podem utilizar ` faixas de enderecos pertencentes as faixas dos seus provedores. Ainda, as estacoes das re des de acesso que s o multidomiciliadas devem receber m ltiplos enderecos IPs, onde os a u ` enderecos pertencem a faixa dos ISPs diretamente conectados. Essa limitacao permite que cada ISP anuncie prexos de rede agregados. A Figura 2.23 ilustra esse tipo de aborda gem. Entretanto, uma desvantagem dessa abordagem e que os administradores das redes de acesso devem concordar em utilizar apenas faixas de enderecos dos seus provedores diretos, j que hoje j existe a possibilidade de usar faixas de enderecos independentes a a do provedor. Como consequ ncia, a reducao das tabelas de roteamento na DFZ torna-se e dependente dos interesses dos administradores. Essa depend ncia n o existe na proposta e a de separacao de enderecos.

Figura 2.23. Encaminhamento em redes de acesso com sub-faixas de endereco de ISPs.

 Uma proposta mais exvel para aumentar a escalabilidade na Internet e sepa rar o espaco de enderecamento em Enderecos Globalmente Rote veis e Enderecos Glo a balmente Entreg veis [Massey et al. 2007, Jen et al. 2008]. Os Enderecos Globalmente a Rote veis s o formados por enderecos presentes nas tabelas de roteamento da DFZ e a a que s o apenas alcancaveis na DFZ. Em oposicao aos Enderecos Globalmente Rote veis, a a os Enderecos Globalmente Entreg veis s o os enderecos de redes nas bordas da Inter a a net que devem ser unicos e alcancaveis de qualquer lugar. Entretanto, os Enderecos Globalmente Entreg veis n o devem estar presentes nas tabelas da DFZ. A aus ncia de a a e enderecos de redes de borda nos roteadores da DFZ diminui o n mero de entradas e o u n mero de prexos anunciados pelo protocolo de roteamento interdomnio. Estimativas u apontam que a eliminacao dos prexos de redes das bordas do roteamento interdomnio es em at uma ordem de magnireduz o tamanho das tabelas e frequ ncia de atualizaco e e tude [Massey et al. 2007]. Al m disso, um efeito indireto da separacao de enderecos e a e possibilidade de emprego incremental de enderecos diferentes do IPv4. Por exemplo, os enderecos da borda podem ser IPv6 enquanto os do n cleo da rede podem ser IPv4. u A separacao de enderecos em dois tipos demonstra a divis o entre enderecos de a redes de ISPs, compostas tipicamente de roteadores de tr nsito, e redes de acesso nas bora das. Assim, faixas de Enderecos Globalmente Rote veis s o alocadas aos ISPs para que a a os diferentes ISPs sejam capazes de se comunicar. Um dado importante e que o n mero de u ISPs tem sido est vel em comparacao ao n mero de redes de acesso [Massey et al. 2007]. a u Como consequ ncia, as tabelas que cont m Enderecos Globalmente Rote veis n o devem e e a a aumentar de tamanho rapidamente. J os Enderecos Globalmente Entreg veis s o alocaa a a dos para as redes de acesso. Esses enderecos devem ser unicos para que cada rede de acesso ou estacao seja identicada em toda Internet. Entretanto, como os provedores de servico n o conhecem os enderecos das redes de acesso, este ultimo n o e globalmente a a rote vel. Para que a correspond ncia seja possvel, e necess rio que haja um mapeamento a e a dos dois tipos de enderecos. Tal mapeamento e realizado nos roteadores de borda dos ISPs ` conectados as redes de acesso. Cada roteador de borda deve descobrir qual o mapeamento a realizar baseado no endereco de destino do pacote recebido. Ap s o mapeamento, o ro o teador encapsula o pacote e envia atrav s do t nel formado at a roteador de borda da rede e u e da estacao do destino [Massey et al. 2007, Jen et al. 2008]. O roteador de borda da rede do destino desencapsula o pacote e entrega ao destino correspondente na rede de acesso. O procedimento de mapeamento e encapsulamento [Jen et al. 2008] e ilustrado na ` Figura 2.24. Nessa gura, pacotes originados na estacao A e destinados a estacao B s o a enviados atrav s de um t nel de RA at RB . A gura mostra tamb m a divis o dos dois e u e e a espacos de enderecamento existentes na proposta. E importante observar que os rotea dores internos ao espaco de Enderecos Globalmente Rote veis n o precisam conhecer os a a mecanismos de mapeamento e encapsulamento. Isso permite que a conguracao deles permaneca a mesma que a atual, apenas com menos entradas nas tabelas de roteamento. O uso do espaco de Enderecos Globalmente Entreg veis permite que cada ISP a agregue o maior n mero de faixas de enderecos possvel. Al m disso, cada rede de acesso u e pode usar faixas de enderecos independentes da faixa de enderecos do ISP diretamente conectado, como visto na Figura 2.24. Essa caracterstica facilita o uso dos m ltiplos do u miclios bem como a mudanca das faixas de enderecos utilizadas por cada rede de acesso. Entretanto, toda mudanca realizada deve ser conhecida pelos roteadores respons veis pelo a

Figura 2.24. Encaminhamento utilizando dois espacos de enderecamento.

mapeamento para que esses continuem informando corretamente os outros roteadores na DFZ quais as redes de acesso que conhecem. As atualizacoes das informacoes de ma peamento podem acarretar problemas de escalabilidade uma vez que as atualizacoes s o a enviadas para em toda a DFZ. Uma possibilidade para reduzir o n mero de mensagens de controle sobre o mapeu amento e limitar as mensagens apenas para outros roteadores de borda utilizando t cnicas, e como por exemplo, o multicast. Outra possibilidade e o emprego de sistemas como o DNS para realizar o mapeamento. Todas as duas solucoes reduzem a carga de controle, mas inserem outros problemas. Utilizar o multicast n o e trivial na Internet e o uso de sistemas a como o DNS pode inserir atrasos na resolucao de enderecos. Uma solucao hbrida e pro posta pela arquitetura APT (A Practical Tunneling) [Jen et al. 2009]. A arquitetura APT prop e que as informacoes de mapeamento sejam enviadas para todas as redes na DFZ. o Entretanto, em cada uma das redes apenas um n mero reduzido de novos dispositivos de u rede recebem tais informacoes. Esses dispositivos, denominados DM (Default Mappers), armazenam as tabelas completas com todos as informacoes sobre mapeamentos. Os rote adores de borda armazenam apenas as informacoes dos ultimos mapeamentos realizados em uma mem ria cache. Logo, sempre que um pacote e recebido por um roteador de o borda, ele verica se o mapeamento especco est em sua mem ria cache. Caso esteja, o a o pacote e encapsulado e enviado, caso contr rio, ele encaminha o pacote at o DM. O DM a e ent o trata o pacote como uma requisicao para informacao de mapeamento. Como resa posta, o DM envia o mapeamento at o roteador de borda requisitante e, ao mesmo tempo, e encapsula e encaminha o pacote em nome do roteador requisitante. Essa estrat gia hbrida e evita que os roteadores de borda armazenem tabelas completas, reduzindo o tamanho das tabelas utilizadas. Por outro lado, os DMs n o fazem encaminhamento de muitos pacotes, a reduzindo a necessidade de rapidez de encaminhamento. Essas caractersticas especcas permitem que os dispositivos sejam otimizados conforme a tarefa realizada. O mapeamento deve lidar tamb m com problemas de compatibilidade com equie pamentos que ainda n o separam o espaco de enderecamento [Vogt 2008]. Portanto, a deve-se investigar maneiras de implementar a separacao de enderecos considerando a implementacao gradual da proposta. Os roteadores de borda que n o implementam a a separacao de enderecos n o realizam o mapeamento e o encaminhamento de pacotes. a Al m disso, eles podem n o anunciar os prexos das redes de acesso conhecidas. Logo, e a outros roteadores de borda descartam os pacotes recebidos cujo destino seja uma estacao dessas redes de acesso que n o tiveram seus prexos anunciados. Isso ocorre porque os a

roteadores de borda desconhecem o caminho at a rede do destino do pacote. Uma proe posta para a adocao gradual da separacao de enderecos e o Six/One Router [Vogt 2008]. O Six/One Router e um protocolo para traducao de enderecos entre estacoes em redes de acesso diferentes. A traducao e realizada no roteador de borda da rede de acesso de origem que mapeia o endereco de origem do pacote para um endereco de origem da DFZ. De maneira semelhante, o roteador de borda de origem realiza um procedimento de resolucao de enderecos para mapear o endereco de destino do pacote no endereco de destino na DFZ. Esse mapeamento e biunvoco, ou seja, cada endereco de uma estacao em uma rede de acesso s pode ser mapeado em um endereco da DFZ. O endereco da o ` DFZ pertence a faixa de enderecos do ISP correspondente. O roteador executando o Six/One Router insere tamb m uma extens o no cabecalho do pacote para identicar os e a enderecos de origem e destino das redes de acesso. Assim, quando o roteador de borda na rede de acesso do destino recebe o pacote, ele traduz os enderecos para os enderecos originais das redes de acesso e envia para a estacao correspondente. O mapeamento e armazenado em mem ria cache para que o procedimento seja realizado mais rapidamente o em pacotes seguintes. No caso de estacoes em redes de acesso legadas, ou seja, que n o a realizam a separacao de enderecos, o endereco da estacao j e o pr prio endereco da DFZ a o j que esses enderecos t m que ser conhecidos globalmente. Portanto, caso um roteador a e de borda de origem realize a traducao, o endereco da DFZ da estacao legada ser o seu a pr prio endereco. No sentido reverso, caso uma estacao legada seja a origem do pacote, o o endereco de destino usado ser o endereco da DFZ. Como o mapeamento e biunvoco, a h somente uma estacao associada a esse endereco da DFZ. a A Figura 2.25 ilustra o funcionamento do Six/One Router em caso de redes legadas. A estacao A possui o seu endereco traduzido em um endereco do seu provedor de servico. Entretanto, o endereco da estacao B de destino e mantido, visto que a sua rede de acesso n o realiza a separacao de enderecos. Logo, o endereco da estacao B e conhecido a globalmente e, por isso, pode ser mantido no pacote. A gura ilustra tamb m a extens o e a includa no cabecalho do pacote pelo roteador RA . Note que enquanto a rede de acesso da estacao A n o pode utilizar uma faixa de enderecos do seu provedor (ISPA ), a estacao B a pode usar uma faixa do ISPB .

Figura 2.25. Funcionamento do Six/One Router em caso de redes de acesso legadas.

O HAIR (Hierarchical Architecture for Internet Routing) [Feldmann et al. 2009] e outra proposta para reduzir o n mero de entradas nas tabelas de roteamento da DFZ. u Diferente das propostas de separacao de enderecos em dois nveis, o HAIR pode dividir os diferentes ASes em mais de dois nveis hier rquicos, onde o mais alto e composto a

 pelos principais ASes de tr nsito da Internet e o mais baixo e composto pelas redes de a acesso. Al m disso, o HAIR utiliza t cnicas para Loc/ID Split para possibilitar a mobie e lidade das estacoes. O encaminhamento de pacotes e realizado, portanto, baseado nos identicadores das estacoes de origem e destino que s o mapeadas em enderecos pela a origem antes do envio dos pacotes. No HAIR, o endereco de origem codica os iden ticadores de todos os roteadores de borda pelos quais o pacote deve passar desde sua origem at o nvel hier rquico superior. Semelhantemente, o endereco de destino codie a ca os identicadores dos roteadores de borda desde o nvel superior at o destino. O e procedimento de encaminhamento e parecido com a opcao loose source routing do IP. A diferenca e que o caminho n o e inserido no campo de opcao do IP e e codicado a nos enderecos de origem e destino utilizados. O mapeamento do identicador do destino no endereco e realizado sob requisicao. Para tal, assume-se que a estacao de origem j a conhece o identicador de destino e utiliza um sistema de resolucao de identicacao de estacao em endereco. A Figura 2.26 mostra os enderecos de origem e destino usados no pacote. Note que o endereco de origem e uma codicacao do identicador da estacao (estacao A), do roteador do primeiro nvel hier rquico acima (RA ) e do roteador do n cleo a u (RNA ). A divis o hier rquica dos ASes e o uso do roteamento pela fonte permitem que a a cada roteador conheca apenas as rotas at os roteadores de borda dentro do seu pr prio e o ` nvel hier rquico. Essa caracterstica leva a reducao do n mero de entradas nas tabelas de a u roteamento na DFZ.

Figura 2.26. Funcionamento do HAIR.

Todos os trabalhos apresentados anteriormente reduzem o problema de escalabilidade na Internet atrav s de novos esquemas de enderecamento. Entretanto, todas ese sas propostas necessitam alterar de certa forma a arquitetura atual de enderecamento, o que pode representar uma barreira para as suas implementacoes. Tendo em vista esse problema em curto e m dio prazo, alguns trabalhos prop em a reducao das tabelas de e o roteamento atrav s de estrat gias mais inteligentes de organizacao de prexos ou de are e mazenamento em mem ria. o O ViAggre (Virtual Aggregation) [Ballani et al. 2008, Ballani et al. 2009] prop e o distribuir a manutencao da tabela de roteamento intradomnio entre os roteadores de um ISP. Assim, cada roteador deve manter apenas parte da tabela completa de roteamento. O ViAggre divide o espaco de enderecamento em um conjunto de prexos virtuais tal que cada prexo virtual e maior que os prexos agregados reais utilizados pelos roteadores. Por exemplo, todo o espaco de enderecamento conhecido por um ISP pode ser dividido em 128 prexos virtuais /7 (0.0.0.0/7 at 254.0.0.0/7), no qual cada prexo virtual correse ponde a um conjunto de prexos reais. Os prexos virtuais n o necessariamente possuem a

correspond ncia com a topologia da rede, mas devem cobrir todos os possveis prexos e reais para que n o haja nenhuma rede inalcancavel. As redes virtuais geradas a partir a dos prexos virtuais formam uma topologia que possui prexos agreg veis e, portanto, a tornam-se escal veis. Para criar uma rede virtual, cada ISP dene alguns roteadores para a fazerem parte dessa rede. Esses roteadores mant m rotas para todos os prexos contidos e no prexo virtual. Tais roteadores s o denominados pontos de agregacao (aggregation a points) para o prexo virtual. Um ponto de agregacao pode agregar mais de um prexo virtual. Esse ponto de agregacao deve apenas manter rotas para os prexos contidos nos prexos virtuais que ele mant m. e O encaminhamento de pacotes utilizando o ViAggre ocorre da seguinte maneira. Assim que o pacote entra na rede do ISP, esse pacote e encaminhado diretamente at o e ponto de agregacao mais pr ximo que mant m o prexo virtual que engloba o prexo do o e destino. Esse ponto de agregacao possui uma rota para o prexo do destino e, portanto, encaminha o pacote at o pr ximo ISP. O encaminhamento e realizado atrav s de um t nel e o e u j que algum roteador no caminho pode desconhecer a rota escolhida e enviar o pacote de a volta para o ponto de agregacao. A divis o dos prexos da Internet em prexos virtuais a e uma tentativa de rearrumar os prexos para que eles se tornem agreg veis. Uma vez a que os prexos possam ser agregados, o n mero de entradas nas tabelas de roteamento u diminui especialmente na DFZ. Outras propostas atuam mais especicamente na organizacao da mem ria com o relacao aos tipos de entradas que devem ser armazenadas para reduzir o tamanho da tabela sem perder informacao. Kim et al. [Kim et al. 2009] prop em armazenar em mem ria o o cache a tabela de roteamento apenas com as rotas usadas com maior frequ ncia. As oue tras rotas s o armazenadas em uma mem ria mais lenta e consultadas apenas em caso a o de aus ncia na cache. Caso um pacote seja recebido pelo roteador e uma rota n o ese a teja disponvel na mem ria cache, o roteador encaminha imediatamente o pacote em uma o rota default e atualiza a sua mem ria cache baseado nas informacoes que possui em sua o mem ria mais lenta. A atualizacao da cache segue a poltica de atualizacao adotada. O o roteador que recebe o pacote enviado pela rota default conhece caminhos para todos os possveis destinos. Esses roteadores podem ser projetados de maneira a armazenarem todas as possveis rotas da rede. Al m de armazenar parte da tabela de roteamento em ca e che, Kim et al. tamb m prop em o uso de prexos de mesmo comprimento. Atrav s da e o e an lise de registros reais, os autores concluram que prexos /24 s o os mais especcos a a possveis que ainda n o s o ltrados pelos provedores por quest es de seguranca. Pre a a o xos de comprimento menores, por exemplo /16, podem ser subdividos em entradas com prexos mais especcos que utilizam interfaces de sada diferentes da entrada com pre xo maior. Por exemplo, o prexo 10.1.0.0/16 pode ter como interface de sada a eth0 enquanto o prexo 10.1.1.0/24, a eth1. Caso um pacote destinado ao endereco 10.1.2.1 seja recebido, a entrada com prexo maior e colocada em cache e o pacote e encaminhado pela eth0. Se em seguida um pacote com endereco de destino 10.1.1.1 for recebido, o pa cote tamb m e encaminhado pela eth0 ao inv s da eth1 como denido pela entrada mais e e especca. A divis o em prexos /24 e, portanto, uma tentativa de se evitar problemas a durante o encaminhamento de pacotes ao utilizar parte das rotas em cache. Organizar de maneira mais inteligente os prexos nas tabelas de roteamento pode enfrentar dois desaos. O primeiro e que a solucao proposta pode n o ser denitiva. a

Mudancas na arquitetura da Internet podem ser mais efetivas, por m mais difceis de e implementar sem incentivos consider veis. J o segundo problema e um compromisso a a vericado por Krioukov et al. [Krioukov et al. 2007] entre a reducao das tabelas de ro teamento e o aumento do tamanho m dio das rotas. Krioukov et al. demonstram que, e na Internet, o crescimento das tabelas de roteamento e logartmico se forem utilizados algoritmos para compactacao das tabelas. Entretanto, tal crescimento s e possvel caso o a Internet seja est tica e os enderecos estiverem relacionados com a topologia da rede. a Se forem utilizados identicadores planos, o crescimento das tabelas de roteamento e polinomial, onde no melhor caso o crescimento e linear se os algoritmos de roteamento buscarem os caminhos mais curtos. Caso os caminhos encontrados possuam certa toler ncia e n o necessariamente sejam sempre os mais curtos, essa taxa de crescimento a a pode ser menor, no melhor caso. 2.4.6. Caminhos program veis a A provis o da qualidade de servico na Internet deve lidar com os diferentes requia sitos das aplicacoes. Para possibilitar servicos diferentes do tradicional melhor esforco, funcionalidades para visualizacao da topologia da rede bem como m todos sosticados e para projetos de novas aplicacoes s o necess rios. Essas novas t cnicas podem ser utili a a e zadas para mover funcoes das aplicacoes para a rede, j que o desempenho da rede pode a variar [Clark et al. 2004]. Maneiras para monitorar o desempenho da rede, como movimentar as funcoes das aplicacoes e auxiliar o processo de escolha dos caminhos, podem ser feitas atrav s da introducao de intelig ncia na rede. Tal intelig ncia e viabilizada e e e atrav s da aquisicao de experi ncia e vis o global. A intelig ncia e adquirida por agentes e e a e que atuam na rede e utilizam o conhecimento disponvel, frequentemente obtido no Plano de Conhecimento [Clark et al. 2003], para tomar decis es sobre quais s o os melhores o a caminhos conforme a aplicacao. Al m do emprego de agentes, a escolha do caminho e pode tamb m ser feita a partir do pr prio usu rio. Para tanto, arquiteturas que oferecam e o a ao usu rio a oportunidade de escolher qual o caminho seguido pelo seu tr fego no nvel a a de ASes devem ser desenvolvidas. As propostas nessa area podem ser classicadas de duas maneiras: orientadas a agentes ou orientadas a usu rios. a ` As propostas orientadas a agentes est o na direcao oposta a premissa m-a-m a da Internet. A caracterstica de intelig ncia nas bordas, por um lado, aumenta a simplici e dade e exibilidade da rede [Moreira et al. 2009]. Entretanto, por outro lado, diculta o diagn stico de falhas e implica em conguracoes manuais. Essas ultimas consequ ncias o e reduzem o desempenho da rede j que podem gerar conguracoes erradas e levar ao aua mento do tempo de recuperacao da rede. A insercao de agentes inteligentes na rede tem por objetivo reduzir os problemas acarretados por conguracoes manuais. Entretanto, o emprego dos agentes n o deve prejudicar um dos principais pilares da Internet que e a a simplicidade do n cleo [Clark et al. 2003]. u O papel dos agentes na Internet e aumentar a autonomia da rede ao ponto de torn a la o mais independente possvel da intervencao humana. Atualmente, o crescimento do n mero de n s, de usu rios e da demanda por conectividade e banda passante t m tornado u o a e o gerenciamento das redes mais e mais complexo. O gerenciamento humano, por conseguinte, pode se tornar um limitante para o crescimento da Internet. O conceito de redes ` auton micas defende o uso de t cnicas que permitam a rede conhecer o contexto que est o e a

 inserida e o que lhe e solicitada. Assim, torna-se possvel realizar acoes sem a intervencao humana. As redes auton micas tamb m devem ter uma vis o em alto nvel dos objetivos o e a da rede e das suas limitacoes para tomar decis es de conguracao. Por m, os agentes o devem relatar o seu desempenho em alto nvel para usu rios ou administradores. a O conhecimento do tr fego encaminhado e dos requisitos dos usu rios permite que a a os agentes tomem decis es no nvel do roteamento. Tais decis es n o necessariamente o o a s o regidas por resultados de algoritmos determinsticos. Isso ocorre porque o ambiente a no qual as decis es s o tomadas e altamente din mico e sujeito a conito de interesses o a a e a informacoes incompletas. Nesse caso, e importante manter uma base de dados que construa, reconcilie e mantenha os muitos aspectos de uma vis o em alto nvel do coma portamento da Internet. Essa base de dados e separada em um novo plano denominado Plano de Conhecimento (Knowledge Plane) por Clark et al. [Clark et al. 2003]. O Plano de Conhecimento deve ser capaz de prover servicos aos outros elementos da rede como, por exemplo, qual a melhor conguracao em um dado momento de operacao da rede. No caso do roteamento, o Plano de Conhecimento e capaz de alterar ou estabelecer caminhos conforme requisitos de aplicacoes. Um dos desaos do Plano de Conhecimento e men surar o quanto de informacoes ele deve possuir e qual o alcance delas. Especialmente no roteamento, projetar um Plano de Conhecimento que possua informacoes globais da Internet n o e vi vel dada a massa de informacoes necess rias. Logo, o Plano de Conhea a a cimento deve conhecer o tipo de informacao que e mais util em uma dada circunst ncia e a es conforme os interesdeve usar t cnicas distribudas escal veis para ltrar as observaco e a ses dos usu rios. a Nas propostas orientadas a usu rios, estes possuem maior liberdade para escolher a o tipo de caminho pelo qual os seus pacotes s o encaminhados. A arquitetura NIRA (New a Internet Routing Architecture) [Yang et al. 2007, Yang 2003] e a principal representante desse tipo de propostas. A arquitetura NIRA tem como um dos seus objetivos estimular a competicao entre os ISPs. Esse e o motivo pelo qual a arquitetura NIRA prop e que os o usu rios tenham oportunidade de escolher os caminhos no nvel de ASes e n o no nvel a a ` de roteadores internos a um AS. A competicao entre ISPs pode levar a reducao dos custos ` Internet para os usu rios bem como estimular a introducao de valor agregado do acesso a a aos servicos. Dentre possveis valores agregados poderia estar, por exemplo, caminhos com qualidade de servico m-a-m. A maneira mais trivial para os usu rios denirem o caminho percorrido pelos paa cotes e o uso de roteamento pela fonte. Entretanto, o roteamento pela fonte aumenta o tamanho dos cabecalhos. A arquitetura NIRA utiliza um esquema de roteamento pela fonte que n o introduz o caminho explicitamente no cabecalho do pacote. Na NIRA, os a enderecos das estacoes s o a concatenacao do identicador da estacao com os identi a cadores de todos os ASes at o n cleo da Internet. A parte do endereco que identica e u o dos prexos de todos os domnios no caminho at os ASes deve ser uma concatenaca e os ASes de n cleo. A Figura 2.27 ilustra um exemplo, supondo que haja apenas um u domnio entre a rede de acesso e o n cleo, o endereco da estacao A e 1.1.1.1, que e uma u concatenacao do identicador da estacao (1), do identicador do domnio intermedi rio a (1.1.1.0/24) e do n cleo (1.1.0.0/16). Assim, o caminho do pacote ca denido at o u e n cleo da Internet a partir do endereco da estacao. Em uma comunicacao m-a-m, a mau neira como os enderecos de origem e de destino dos pacotes s o organizados e suciente a

para que o caminho seja totalmente denido. Apenas os ASes de n cleo precisam execuu tar um protocolo de roteamento para encaminhar os pacotes recebidos. Na Figura 2.27, o protocolo de roteamento dene o melhor caminho a ser seguido pelos pacotes entre o roteador RA e RB , por exemplo. Como o n mero de ASes no n cleo e pequeno em relacao u u ao n mero de ASes da Internet, esse protocolo n o enfrenta problemas de escalabilidade. u a

Figura 2.27. Estrutura de enderecos utilizados na NIRA.

O encaminhamento de pacotes baseado tanto no endereco de origem quanto no destino dos pacotes e diferente do encaminhamento de pacotes da Internet que e baseado apenas no endereco de destino. Entretanto, a denicao do caminho nos enderecos dos pacotes ainda n o e suciente para prover liberdade de escolha aos usu rios. Assim, e a a necess rio um procedimento de descobrimento de rotas para que os usu rios possam esa a colher, dentre os caminhos possveis, o melhor dependendo dos seus interesses. A NIRA utiliza mecanismos de descoberta de caminhos antes do envio de pacotes. Para tal, a NIRA dene dois protocolos para auxiliar a descoberta de caminhos: o TIPP (Topology Information Propagation Protocol) e o NRRS (Name-to-Route Resolution Service). O primeiro protocolo propaga aos usu rios suas informacoes de enderecos intradomnio lea vando em consideracao possveis acordos entre ASes. As informacoes correspondem ao caminho desde a estacao at os ASes de n cleo. Na Figura 2.27, a estacao A poderia esco e u lher entre o endereco 1.1.1.1 e o endereco 1.1.2.1. J o protocolo NRRS dene um servico a de resolucao de nomes para que cada estacao conheca o endereco das outras estacoes da rede. Assim, a estacao A descobre o endereco da estacao B, 1.1.3.1, como visto na Fi gura 2.27. Os enderecos de origem e destino s o armazenados em mem ria cache para a o evitar buscas consecutivas pelos mesmos enderecos, exceto em caso de falhas. Outra proposta orientada a usu rios e o Pathlet Routing [Godfrey et al. 2009]. No a Pathlet Routing, cada ISP anuncia fragmentos de caminhos, denominados Pathlets, que podem ser concatenados pelo usu rio para formar um caminho m-a-m. Um Pathlet e a denido como uma sequ ncia de n s considerados virtuais. Tais n s podem estar associe o o ados a todas as rotas conhecidas pelos roteadores da rede que pertencem, ou no caso mais simples, a apenas as rotas conhecidas por um unico roteador. O caminho de um pacote e denido na fonte e inserido no cabecalho do pacote. Logo, o Pathlet Routing utiliza roteamento pela fonte. Cada Pathlet e identicado por um identicador de encaminha mento (Forwarding IDentier - FID) cujo signicado e local ao n virtual de origem do o Pathlet. Uma vez que o roteamento e pela fonte, e importante apenas para o n de orio gem do Pathlet conhecer para que n encaminhar os pacotes recebidos. Ao encaminhar o um pacote, o roteador altera a sequ ncia de identicadores. A Figura 2.28 ilustra essas e alteracoes. Na gura, cada seta pontilhada representa um Pathlet e os ret ngulos abaixo a

de cada roteador representam os identicadores dos Pathlets contidos no cabecalho do pacote naquele roteador. O pacote e originado no roteador A e destinado ao roteador E. Note que a cada salto os Pathlets atravessados s o removidos do cabecalho (ex. entre os a roteadores A e B) e novos Pathlets s o inseridos no cabecalho do pacote caso um Pathlet a atravessado seja composto por m ltiplos saltos (ex. entre os roteadores B e C j que o u a Pathlet 2 e composto pelos Pathlets 7 e 1). Pathlets compostos s o formados assim que a um determinado roteador aprende m ltiplos Pathlets consecutivos. u

Figura 2.28. Pathlet Routing.

No Pathlet Routing, um determinado n da rede dissemina os Pathlets conhecidos o que traduzem as suas polticas. A disseminacao e realizada atrav s de vetores de caminhos e no BGP. Os Pathlets recebidos pelos usu rios s o utilizados na escolha dos caminhos. a a Uma das vantagens do uso dos Pathlets e a economia no tamanho dos cabecalhos. Na Figura 2.28, o roteamento pela fonte precisaria de cinco enderecos IP enquanto com o uso do Pathlet precisa de no m ximo dois identicadores (FIDs). a Uma quest o importante e como incentivar os ISPs a disponibilizarem aos usu rios a a a liberdade de escolha de caminhos. O modelo atual da Internet e baseado em acordos comerciais entre os provedores. Portanto, a manutencao desse modelo representa uma restricao a possibilidade de escolha dos usu rios. A mudanca do modelo, entretanto, deve ` a ser atraente tamb m para os ISPs. Alguns modelos de neg cios para os provedores ine o cluem acordos entre os usu rios e os seus provedores de acesso e entre os usu rios e os a a provedores de todo o caminho at o n cleo. Na primeira opcao, os provedores conectae u dos diretamente aos usu rios fazem acordos com os provedores vizinhos para oferecerem a diferentes possibilidades de caminhos para a escolha dos usu rios. Os provedores tarifam a os usu rios atrav s do monitoramento dos caminhos que os usu rios escolheram. J na a e a a segunda opcao, os usu rios t m a possibilidade de escolher todos os ASes no caminho. a e Embora essa ultima opcao ofereca mais liberdade, ela pode sofrer problemas de adocao, visto que qualquer provedor de servico segue algum tipo de poltica com os seus vizinhos. Uma diculdade que ambos os tipos de proposta, orientada a agentes e orientada a usu rios, enfrenta e a aquisicao de informacoes da rede. Tais informacoes s o importantes a a para que tanto os agentes quanto os usu rios possam embasar suas decis es. Por exemplo, a o aplicacoes como VoIP possuem restricoes de atraso m-a-m. Essa m trica n o e sim e a ples de ser obtida visto que necessita de sincronismo entre rel gios. Al m da obtencao o e de m tricas, outro desao e consolidar as informacoes e representar o estado atual da e rede a partir dessas informacoes. O estado da rede deve retratar de maneira mais el possvel dependendo das necessidades das aplicacoes. A arquitetura CONMan (Comple xity Oblivious Network Management) [Ballani e Francis 2007] prop e uma interface para o simplicar a obtencao de informacoes de protocolos. Os autores argumentam que uma

 das grandes diculdades para o gerenciamento de redes e que os protocolos e dispositivos exibem muitos detalhes de sua implementacao, o que diculta a obtencao dos dados. A arquitetura CONMan, portanto, prop e uma interface que inclui o mnimo necess rio de o a informacoes especcas de protocolos e outros dispositivos para simplicar a obtencao de dados, e assim, melhorar o desempenho da rede a partir de um gerenciamento mais efetivo. 2.4.7. OpenFlow e a solucao comutada Atualmente, o Ethernet e uma tecnologia consolidada para redes locais e metropo litanas. O Ethernet e uma solucao comutada e, portanto, n o pode ser aplicada diretamente a na Internet que e roteada. A simplicidade do Ethernet e a facilidade de conguracao de redes, entretanto, v m estimulando o emprego dessa tecnologia em redes de maior escala. e Para isso, procedimentos como o de inundacao de controle, utilizado para localizacao de estacoes, conguracao autom tica de enderecos atrav s de DHCP (Dynamic Host Con a e guration Protocol) e resolucao ARP (Address Resolution Protocol); e o emprego de arvores de espalhamento (spanning tree) para comunicacao entre os n s devem ser re o vistos. Al m disso, em uma rede comutada, cada comutador armazena a localizacao de e cada destino na rede. Para contornar essas caractersticas e tornar a solucao comutada mais escal vel, trabalhos na area prop em solucoes hbridas como o emprego de roteaa o dores executando o IP para interconectar redes Ethernet e o emprego de VLANs (Virtual LANs) [Kim et al. 2008]. Outras propostas, como o Seattle [Kim et al. 2008], reduzem o n mero de estados por comutador e ainda evitam inundacoes. Para isso, o Seattle utiliza u um sistema de localizacao de estacoes atrav s de DHTs, e assim, dispensa o armazena e mento de informacoes globais em cada um dos n s da rede. o Um das solucoes comutadas que vem se destacando e o OpenFlow. O Open Flow [McKeown et al. 2008, Mateo 2009] possibilita a programabilidade de elementos de rede, sejam eles comutadores ou roteadores. Essa caracterstica permite programar redes e, como consequ ncia, realizar experimentos isolados simult neos para testes de e a novas propostas de roteamento e at mesmo alternativas ao IP. O OpenFlow permite que e uxos sejam denidos, bem como os caminhos seguidos por cada uxo, sem interferir nos outros uxos da rede. Os caminhos podem ser obtidos a partir de m todos oferecidos e pelo OpenFlow. Tais m todos denem polticas para busca autom tica de caminhos que e a atendam requisitos desejados como largura de banda disponvel e atraso restrito. Uma rede convencional e composta por enlaces, elementos de processamento de pacotes (comutadores/roteadores) e estacoes nais. Nessas redes, cada elemento de pro cessamento agrega funcoes de encaminhamento de pacotes e decis es de controle. No o OpenFlow, entretanto, essas duas funcoes s o separadas. A funcao de encaminhamento a de pacote continua nos comutadores/roteadores. Por m, as decis es de controle s o e o a atribudas a um novo elemento de rede, chamado de controlador. Nesse sentido, o Open Flow altera a arquitetura convencional de redes ao introduzir o conceito de controladores. Os controladores separados foram propostos para que a programabilidade dos comutadores possa ser realizada externamente ao equipamento para que n o haja depend ncia do a e fabricante. Essa caracterstica facilita a adocao da tecnologia. Para que isso seja possvel, o OpenFlow dene uma interface e um protocolo para comunicacao entre controladores e comutadores. Esse protocolo dene mensagens para modicacao das tabelas de enca

minhamento, recepcao e envio de pacotes, busca de estatsticas da rede e informacoes do equipamento. Essas mensagens s o utilizadas para realizar determinadas funcoes, dentre a as quais a mais importante para prover programabilidade e a modicacao das tabelas de encaminhamento. A arquitetura de uma rede OpenFow e ilustrada na Figura 2.29.

Figura 2.29. Arquitetura de uma rede OpenFlow.

A programabilidade do OpenFlow e obtida atrav s da possibilidade de alterar a e tabela de encaminhamento, que no caso da comutacao, e chamada de tabela de uxos. A tabela de uxos dene a acao associada a cada uxo e estabelece o tipo de processa mento a ser realizado sobre aquele uxo. Cada uxo e identicado na tabela a partir de informacoes contidas no seu cabecalho. Informacoes como enderecos MAC, enderecos IP, portas TCP etc. s o utilizadas para identicacao. Uma vez identicado o uxo, o a OpenFlow executa a acao relacionada a ele como descrito na pr pria tabela. A presenca o de informacao al m de informacoes de camada de enlace pode ser usada por um comu e tador para que ele se comporte como um roteador ou como um equipamento de camada acima da camada de transporte. Da mesma maneira, um uxo pode ser apenas identicado pelo cabecalho da camada de enlace. Isso facilita o teste de solucoes que n o utilizam o IP a como protocolo de rede. O OpenFlow n o requer que o cabecalho dos pacotes sigam um a determinado formato. Ele requer apenas que o formato utilizado possa ser identicado na tabela de uxos. Essa caracterstica facilita a experimentacao de novos protocolos para a Internet do Futuro. Os pacotes recebidos que n o possuem entradas correspondentes na tabela de ua xos s o enviados ao controlador que decide a acao a ser realizada nesse pacote. Portanto, a sempre que um pacote recebido n o encontrar uma porta comutada de sada j estabelea a cida, ele e encaminhado para o controlador atrav s do canal de comunicacao. Esse canal e utiliza SSL (Secure Sockets Layer) para garantir autenticacao e condencialidade, j que a o protocolo denido pelo OpenFlow faz mudancas na tabela de uxos dos comutadores. Ap s a an lise do controlador, uma entrada e adicionada ou n o na tabela de uxos do o a a comutador correspondente. Caso uma entrada seja adicionada, os pr ximos pacotes s o o a encaminhados sem a necessidade de passar primeiro pelo controlador. Uma rede OpenFlow e composta de um ou mais comutadores OpenFlow, um ou mais controladores e um canal seguro para comunicacao. Cada comutador OpenFlow possui sua tabela de uxos enquanto o canal seguro e usado para comunicacao entre os comutadores e os controladores. Normalmente, em uma rede OpenFlow h comutadores a e apenas um controlador. Como consequ ncia, o OpenFlow possui controle centralie zado. Essa centralizacao representa um compromisso entre escalabilidade e facilidade

de gerenciamento. Por um lado, a centralizacao requer que todas as decis es de con o trole e gerenciamento da rede sejam executadas por apenas um elemento. Esse elemento pode representar um ponto de vulnerabilidade e um entrave dependendo do n mero de u requisicoes realizadas. A proposta original do OpenFlow [McKeown et al. 2008] deixa essa limitacao clara j que prop e o uso dessa t cnica de comutacao em redes de campi a o e universit rios. Por outro lado, por m, facilita a implementacao de algoritmos para escoa e lher quais as acoes apropriadas para os uxos correntes. Uma das vantagens do Open Flow e o isolamento de redes concorrentes. Nesse caso, mais de um controlador e usado, um para cada rede. O OpenFlow oferece uma camada de abstracao denominada Flow Visor [Sherwood et al. 2010] para compartilhamento de recursos fsicos entre diferentes redes isoladas. Dentre as acoes que podem ser realizadas pelo OpenFlow est o o encaminhamento a de pacotes, remocao de pacotes e a criacao de uxos. Os pacotes de um uxo podem ser encaminhados para uma determinada porta conforme requisitos desejados. Essa facilidade permite que os pacotes sejam roteados atrav s da rede. Al m disso, outra acao relae e cionada ao encaminhamento de pacotes pode denir que todos os pacotes de um uxo devem primeiro ser encaminhados para o controlador. Apesar dessa opcao reduzir a veloci dade de encaminhamento de pacote, ela pode facilitar operacoes din micas visto que e so a mente possvel executar algoritmos no controlador. Outra acao que pode ser denida pelo OpenFlow e o descarte de alguns ou todos os pacotes relacionados com um determinado uxo. J a criacao de uxos pode ocorrer caso haja necessidade de realizar engenharia de a tr fego. As acoes podem ser usadas para gerenciar o tr fego da rede. E importante notar a a que todas as acoes s o denidas pelo controlador. Controladores mais sosticados como o a NOX [Gude et al. 2008] oferecem interfaces para o desenvolvimento de aplicacoes para gerenciamento ou para obtencao de informacoes da rede. Dentre possveis aplicacoes est o a manutencao de conex es mesmo ap s o deslocamento de usu rios m veis. Nessa a o o a o aplicacao, os pontos de acesso sem-o monitoram os usu rios conectados. Uma vez que a um usu rio mude de ponto de acesso, o ponto de acesso relata ao controlador que realiza a acoes para manter as conex es estabelecidas pelo usu rio m vel. Essas acoes correspon o a o ` dem a mudanca do caminho seguido pelos pacotes destinados a esse usu rio. Logo, as a tabelas de uxo s o ajustadas para que o uxo correspondente seja encaminhado at o a e novo ponto de acesso no qual o usu rio est conectado. a a

2.5. Resultados Experimentais

Esta secao apresenta resultados experimentais obtidos com um prot tipo realizado o para separacao de identicacao e localizacao. O objetivo dos experimentos e vericar o desempenho de um dos novos protocolos para mobilidade na Internet a partir de mudancas do ponto de interconex o com a rede cabeada. O protocolo escolhido foi o HIP, descrito a na Secao 2.4.1. O cen rio dos experimentos, ilustrado pela Figura 2.30(a), e composto a de uma estacao m vel, um servidor na rede cabeada e dois pontos de acesso sem-o. A o estacao m vel e um Laptop IBM Thinkpad Intel Pentium M 1.7 GHz com 512 MB. J o a o servidor utilizado e um computador de mesa Intel Core2 Duo 2.4 GHz com 2 GB de mem ria RAM. Por m, os pontos de acesso s o dois roteadores Linksys WRT54G e o a WRT350N. A ferramenta utilizada para implementar os protocolos contidos no HIP foi a ferramenta OpenHip vers o 0.7 [OpenHIP 2009]. a

 O objetivo do primeiro experimento e vericar o tempo mnimo necess rio para o a HIP atualizar o endereco IP de uma estacao m vel. Para isso, a estacao m vel permanece o o parada e o endereco IP e alterado manualmente duas vezes. O tempo de atualizacao e, basicamente, o tempo que uma estacao sem-o executando o HIP precisa para noticar as outras estacoes da rede da sua mudanca de endereco. Nesse experimento, a estacao m vel o permanece parada enviando mensagens ICMP de requisicao (ping) para um servidor da rede cabeada atrav s do ponto de acesso A. Em um dado momento a estacao m vel moe o dica seu endereco IP para forcar o procedimento de atualizacao de enderecos do HIP. Durante esse perodo, os pacotes ICMP de resposta enviados para a estacao m vel s o o a perdidos j que o endereco IP da estacao mudou. A Figura 2.30(b) ilustra o tempo de a ida-e-volta (Round Trip Time - RTT) das mensagens ICMP enviadas durante 10 segundos de experimento. A gura ilustra os momentos em que as duas alteracoes de endereco IP foram executadas. Note que ap s as alteracoes, o HIP leva, na m dia, 677 miliso e segundos para restabelecer a comunicacao. Esse tempo e decorrente principalmente da implementacao do OpenHip que processa mensagens do HIP apenas periodicamente.

(a) Cen rio de teste. a

(b) Atualizacao de enderecos IP.

(c) Handoff da estacao m vel. o

Figura 2.30. Experimentos praticos.

O segundo experimento avalia o impacto da mudanca dos enderecos IP na trans fer ncia de dados utilizando o HIP. Nesse experimento, a estacao m vel se desloca do e o ponto de acesso sem-o A at o ponto de acesso B, realizando assim um processo de e handoff. Nesse teste, a estacao m vel tamb m envia mensagens de requisicao ICMP e es o e pera os pacotes de resposta do servidor na rede cabeada. Durante o processo de handoff, a mudanca dos pontos de acesso e realizada quando a intensidade do sinal do ponto de acesso B supera a intensidade do sinal do ponto de acesso A. Ao detectar esse evento, a estacao m vel conecta-se ao ponto de acesso B e troca de endereco IP. A Figura 2.30(c) o mostra que o processo de handoff e a troca de mensagens de atualizacao do HIP duraram 3,354 segundos. Esse tempo e decorr ncia da troca n o instant nea de pontos de acesso, e a a o que resulta em perdas de mensagens de atualizacao e, consequentemente, maior tempo at o processo de atualizacao de endereco ser concludo pelo HIP. e a Os resultados demonstram que a mobilidade na Internet e vi vel, mas ainda precisa de ajustes para se tornar transparente aos usu rios. a

2.6. Consideracoes Finais

Ao longo dos anos, a Internet vem sofrendo adaptacoes para atender demandas n o previstas originalmente. Tais mudancas s o observadas na camada de interconex o a a a

de redes atrav s de novas propostas para substituicao e adaptacao do IP e dos principais e protocolos de roteamento intra e interdomnio. A principal diculdade dessas propostas e que elas s o tentativas de adequar a Internet a uma realidade em constante evolucao. a A outra possibilidade e o rompimento completo com o projeto inicial da Internet e a adocao de uma nova proposta totalmente inovadora. A experi ncia adquirida com os anos e de operacao da Internet poderia ser utilizada em uma proposta evolutiva para a Internet do Futuro. A primeira opcao vem sendo adotada pelos provedores de servico j que a implica em mudancas gerenci veis. Entretanto, por se tratarem de mudancas de curto a prazo, at hoje n o resolveram por completo os problemas da Internet. J a segunda e a a opcao pode exigir maiores disp ndios nanceiros dos provedores de servico por ser mais e radical, em compensacao pode ser mais vantajosa no longo prazo. Enquanto esse impasse persiste, demandas emergentes como a mobilidade das estacoes, os m ltiplos domiclios, u os m ltiplos caminhos e a escalabilidade dos roteadores continuam sem uma solucao u denitiva satisfat ria. o Este minicurso apresentou propostas tanto adaptativas quanto radicais para a interconex o de redes na Internet do Futuro. Algumas propostas se mostraram mais preocua padas com a quest o da implementacao gradual embora ainda impliquem em mudancas a na rede. A licao aprendida e que o problema e complexo e talvez n o seja possvel atender a todas as demandas emergentes e ainda ser escal vel e nanceiramente factvel. Algumas a das demandas podem continuar como casos a parte mesmo naquela que ser a Internet a do Futuro. Uma nova arquitetura que mantenha as mesmas caractersticas que zeram da Internet um dos maiores sucessos do s culo XX e, ao mesmo tempo, que atenda as novas e demandas e um problema em aberto para os pr ximos anos e ainda despertar grande o a interesse na comunidade cientca.

Agradecimentos
Este trabalho utilizou recursos da CAPES, CNPq, FAPERJ, FUJB, FUNTTEL e FINEP.

Refer ncias e
[Alves et al. 2009] Alves, R. S., Campbell, I. V., Couto, R. S., Campista, M. E. M., Moraes, I. M., Rubinstein, M. G., Costa, L. H. M. K., Duarte, O. C. M. B. e Abdalla, M. (2009). Redes Veiculares: Princpios, Aplicacoes e Desaos, captulo 5, p ginas a 199254. Minicursos do Simp sio Brasileiro de Redes de Computadores (SBRC). o Sociedade Brasileira de Computacao (SBC). [Andersen et al. 2008] Andersen, D. G., Balakrishnan, H., Feamster, N., Koponen, T., Moon, D. e Shenker, S. (2008). Accountable Internet Protocol (AIP). Em ACM SIGCOMM, p ginas 339350. a [Andersen et al. 2001] Andersen, D. G., Balakrishnan, H., Kaashoek, M. F. e Morris, R. (2001). Resilient Overlay Networks. ACM SIGOPS Operating Systems Review, 35(5):131145. [Ballani e Francis 2007] Ballani, H. e Francis, P. (2007). CONMan: a step towards network manageability. ACM SIGCOMM Computer Communication Review,

37(4):205216. [Ballani et al. 2008] Ballani, H., Francis, P., Cao, T. e Wang, J. (2008). ViAggre: Making routers last longer! Em Workshop on Hot Topics in Networks (HotNets-VII), p ginas a 16. [Ballani et al. 2009] Ballani, H., Francis, P., Cao, T. e Wang, J. (2009). Making routers last longer with ViAggre. Em Symposium on Networked Systems Design and Implementation (NSDI), p ginas 453466. a [Brim et al. 2008] Brim, S., Chiappa, N., Farinacci, D., Fuller, V., Lewis, D. e Meyer, D. (2008). LISP-CONS: A Content distribution Overlay Network Service for LISP. IETF Network Working Group Internet-Draft (Trabalho em andamento). [Caesar et al. 2006a] Caesar, M., Castro, M., Nightingale, E. B., OShea, G. e Rowstron, A. (2006a). Virtual Ring Routing: network routing inspired by DHTs. Em ACM SIGCOMM, p ginas 351362. a [Caesar et al. 2006b] Caesar, M., Condie, T., Kannan, J., Lakshminarayanan, K., Stoica, I. e Shenker, S. (2006b). ROFL: Routing On Flat Labels. Em ACM SIGCOMM, p ginas a 363374. [Caida 2010] Caida (2010). Visualizing IPv4 and net topology at a macroscopic scale. Acessado http://www.caida.org/research/topology/as core network/. [CIDR 2009] CIDR (2009). Aggregation summary. http://www.cidr-report.org/as2.0/. [CIDR 2010] CIDR (2010). Active BGP entries (FIB). http://www.cidr-report.org/as2.0/. IPv6 Inter10/03/10 em

Acessado 18/12/2009 em Acessado 16/03/2010 em

[Clark et al. 2004] Clark, D., Braden, R., Sollins, K., Wroclawski, J., Katabi, D., Kulik, J., Yang, X., Faber, T., Falk, A., Pingali, V., Handley, M. e Chiappa, N. (2004). New Arch: Future generation Internet architecture. Relat rio t cnico, USC Information Scio e ences Institute Computer Networks Division, MIT Laboratory for Computer Science and International Computer Science Institute (ICSI). [Clark et al. 2003] Clark, D. D., Partridge, C., Ramming, J. C. e Wroclawski, J. T. (2003). A knowledge plane for the Internet. Em ACM SIGCOMM, p ginas 310. a [Clausen et al. 2001] Clausen, T., Jacquet, P., Laouiti, A., Muhlethaler, P., Qayyum, A. e Viennot, L. (2001). Optimized link state routing protocol. Em IEEE International Multi Topic Conference (INMIC), p ginas 6268. a [Costa et al. 2006] Costa, L. H. M. K., Fdida, S. e Duarte, O. C. M. B. (2006). Incremental service deployment using the Hop By Hop Multicast Routing Protocol. IEEE/ACM Transactions on Networking, 14(3):543556. [Crowcroft 2008] Crowcroft, J. (2008). Toward a network architecture that does everything. Communications of ACM, 51(1):7477.

[Deering e Hinden 1998] Deering, S. e Hinden, R. (1998). Internet Protocol, version 6 (IPv6) specication. IETF Network Working Group RFC 2460. [Deering 1988] Deering, S. E. (1988). Multicast routing in internetworks and extended LANs. Em ACM SIGCOMM, p ginas 5564. a [Devarapalli et al. 2005] Devarapalli, V., Wakikawa, R., Petrescu, A. e Thubert, P. (2005). Network Mobility (NEMO) basic support protocol. IETF Network Working Group RFC 3963. [Farinacci et al. 2009a] Farinacci, D., Fuller, V., Meyer, D. e Lewis, D. (2009a). LISP ALternative Topology (LISP+ALT). IETF Network Working Group Internet-Draft (Trabalho em andamento). [Farinacci et al. 2009b] Farinacci, D., Fuller, V., Oran, D. e Meyer, D. (2009b). Locator/ID separation protocol (LISP). IETF Network Working Group Internet-Draft (Trabalho em andamento). [Feldmann et al. 2009] Feldmann, A., Cittadini, L., M hlbauer, W., Bush, R. e Maennel, u O. (2009). HAIR: Hierarchical Architecture for Internet Routing. Em ACM Workshop on Re-Architecting the Internet (ReArch), p ginas 4348. a [Ganesan et al. 2004] Ganesan, P., Gummadi, K. e Garcia-Molina, H. (2004). Canon in G major: Designing DHTs with hierarchical structure. Em International Conference on Distributed Computing Systems (ICDCS), p ginas 263272. a [Godfrey et al. 2009] Godfrey, P. B., Ganichev, I., Shenker, S. e Stoica, I. (2009). Pathlet routing. Em ACM SIGCOMM, p ginas 111122. a [Gude et al. 2008] Gude, N., Koponen, T., Pettit, J., Pfaff, B., Casado, M., McKeown, N. e Shenker, S. (2008). NOX: Towards an operating system for networks. ACM SIGCOMM Computer Communication Review, 38(3):105110. [Hanbali et al. 2005] Hanbali, A. A., Altman, E. e Nain, P. (2005). Survey of TCP over ad hoc networks. IEEE Communications Surveys & Tutorials, 7(3):2236. [He e Rexford 2008] He, J. e Rexford, J. (2008). Towards Internet-wide multipath routing. IEEE Network, 22(2):1621. [Hinden e Sheltzer 1982] Hinden, R. e Sheltzer, A. (1982). The DARPA Internet gateway. IETF Network Working Group RFC 823. [History Museum 2010] History Museum, C. (2010). Internet history. Acessado em http://www.computerhistory.org. [Iannone e Bonaventure 2007] Iannone, L. e Bonaventure, O. (2007). On the cost of caching locator/ID mappings. Em ACM CoNEXT, p ginas 112. a [Internet World Stats 2010] Internet World Stats (2010). World Internet users and population stats. Acessado em http://www.internetworldstats.com/stats.htm.

[Jen et al. 2009] Jen, D., Meisel, M., Massey, D., Wang, L., Zhang, B. e Zhang, L. (2009). APT: A Practical Tunneling architecture for routing scalability. Relat rio t cnico, o e UCLA. [Jen et al. 2008] Jen, D., Meisel, M., Yan, H., Massey, D., Wang, L., Zhang, B. e Zhang, L. (2008). Towards a new Internet routing architecture: Arguments for separating edges from transit core. Em ACM Workshop on Hot Topics in Networks (HotNets), p ginas 16. a [Johnson et al. 2004] Johnson, D., Perkins, C. e Arkko, J. (2004). Mobility support in IPv6. IETF Network Working Group RFC 3775. [Kaur et al. 2003] Kaur, H. T., Kalyanaraman, S., Weiss, A., Kanwar, S. e Gandhi, A. (2003). BANANAS: an evolutionary framework for explicit and multipath routing in the Internet. Em ACM SIGCOMM workshop on Future Directions in Network Architecture (FDNA), p ginas 277288. a [Kim et al. 2009] Kim, C., Caesar, M., Gerber, A. e Rexford, J. (2009). Revisiting route caching: The world should be at. Em International Conference on Passive and Active Network Measurement (PAM), p ginas 312. a [Kim et al. 2008] Kim, C., Caesar, M. e Rexford, J. (2008). Floodless in SEATTLE: a Scalable Ethernet Architecture for Large Enterprises. Em ACM SIGCOMM, p ginas a 314. [Krioukov et al. 2007] Krioukov, D., kc claffy, Fall, K. e Brady, A. (2007). On compact routing for the Internet. ACM SIGCOMM Computer Communication Review, 37(3):4152. [Lear 2010] Lear, E. (2010). NERD: A Not-so-novel EID to RLOC Database. IETF Network Working Group Internet-Draft (Trabalho em andamento). [Lougheed e Rekhter 1989] Lougheed, K. e Rekhter, Y. (1989). A Border Gateway Protocol (BGP). IETF Network Working Group RFC 1105. [Luo et al. 2009] Luo, H., Qin, Y. e Zhang, H. (2009). A DHT-based identier-to-locator mapping approach for a scalable Internet. IEEE Transactions on Parallel and Distributed Systems, 20(12):17901802. [Massey et al. 2007] Massey, D., Wang, L., Zhang, B. e Zhang, L. (2007). A scalable routing system design for future Internet. Em ACM SIGCOMM IPv6 and the Future of the Internet Workshop, p ginas 16. a [Mateo 2009] Mateo, M. P. (2009). OpenFlow switching performance. Dissertacao de mestrado, Politecnico Di Torino, Torino, It lia. a [McCarthy et al. 2008a] McCarthy, B., Edwards, C. e Dunmore, M. (2008a). Using NEMO to extend the functionality of MANETs. Em IEEE International Conference on Communications (ICC), p ginas 455460. a

[McCarthy et al. 2009] McCarthy, B., Edwards, C. e Dunmore, M. (2009). Using NEMO to support the global reachability of MANET nodes. Em IEEE Conference on Computer Communications (INFOCOM), p ginas 20972105. a [McCarthy et al. 2008b] McCarthy, B., Jakeman, M., Edwards, C. e Thubert, P. (2008b). Protocols to efciently support nested NEMO (NEMO+). Em International workshop on Mobility in the evolving Internet Architecture (MobiArch), p ginas 4348. a [McKeown et al. 2008] McKeown, N., Anderson, T., Balakrishnan, H., Parulkar, G., Peterson, L., Rexford, J., Shenker, S. e Turner, J. (2008). Openow: Enabling innovation in campus networks. ACM SIGCOMM Computer Communication Review, 38(2):69 74. [Meyer et al. 2007] Meyer, D., Zhang, L. e Fall, K. (2007). Report from the IAB Workshop on Routing and Addressing. Acessado em http://tools.ietf.org/html/draftiab-raws-report-02.txt. [Mills 1984] Mills, D. L. (1984). Exterior Gateway Protocol formal specication. IETF Network Working Group RFC 904. [Moreira et al. 2009] Moreira, M. D. D., Fernandes, N. C., Costa, L. H. M. K. e Duarte, O. C. M. B. (2009). Internet do Futuro: Um Novo Horizonte, captulo 1, p ginas 1 a 59. Minicursos do Simp sio Brasileiro de Redes de Computadores (SBRC). Sociedade o Brasileira de Computacao (SBC). [Moskowitz et al. 2008] Moskowitz, R., Nikander, P., Jokela, P. e Henderson, T. (2008). Host Identity Protocol. IETF Network Working Group RFC 5201. [Motiwala et al. 2008] Motiwala, M., Elmore, M., Feamster, N. e Vempala, S. (2008). Path splicing. Em ACM SIGCOMM, p ginas 2738. a [Nikander et al. 2008] Nikander, P., Henderson, T., Vogt, C. e Arkko, J. (2008). End-host mobility and multihoming with the Host Identity Protocol. IETF Network Working Group RFC 5206. [Nordmark e Bagnulo 2009] Nordmark, E. e Bagnulo, M. (2009). Shim6: Level 3 multihoming Shim protocol for IPv6. IETF Network Working Group RFC 5533. [OpenHIP 2009] OpenHIP (2009). http://www.openhip.org/. Host Identity Protocol (HIP). Acessado em

[Perera et al. 2004] Perera, E., Sivaraman, V. e Seneviratne, A. (2004). Survey on network mobility support. ACM SIGMOBILE Mobile Computing and Communications Review, 8(2):719. [Perkins 2002] Perkins, C. (2002). IP mobility support for IPv4. IETF Network Working Group RFC 3344. [Ratnasamy et al. 2005] Ratnasamy, S., Shenker, S. e McCanne, S. (2005). Towards an evolvable Internet architecture. ACM SIGCOMM Computer Communication Review, 35(4):313324.

[Rekhter e Li 1995] Rekhter, Y. e Li, T. (1995). A Border Gateway Protocol 4 (BGP-4). IETF Network Working Group RFC 1771. [Rekhter et al. 2006] Rekhter, Y., Li, T. e Hares, S. (2006). A Border Gateway Protocol 4 (BGP-4). IETF Network Working Group RFC 4271. [Sabeur et al. 2006] Sabeur, M., Jouaber, B. e Zeghlache, D. (2006). Light-NEMO+: Route optimzation for light-NEMO solution. Em IEEE International Conference on Networks (ICON), p ginas 16. a [Saucez et al. 2009] Saucez, D., Iannone, L. e Bonaventure, O. (2009). OpenLISP: An open source implementation of the locator/ID separation protocol. Em ACM SIGCOMM Demos Session, p ginas 12. a [Sherwood et al. 2010] Sherwood, R., Chan, M., Covington, A., Gibb, G., Flajslik, M., Handigol, N., Huang, T.-Y., Kazemian, P., Kobayashi, M., Naous, J., Seetharaman, S., Underhill, D., Yabe, T., Yap, K.-K., Yiakoumis, Y., Zeng, H., Appenzeller, G., Johari, R., McKeown, N. e Parulkar, G. (2010). Carving research slices out of your production networks with OpenFlow. ACM SIGCOMM Computer Communication Review, 40(1):129130. [Stoica et al. 2004] Stoica, I., Adkins, D., Zhuang, S., Shenker, S. e Surana, S. (2004). Internet indirection infrastructure. IEEE/ACM Transactions on Networking, 12(2):205 218. [Stoica et al. 2003] Stoica, I., Morris, R., Liben-Nowell, D., Karger, D., Kaashoek, M., Dabek, F. e Balakrishnan, H. (2003). Chord: A scalable peer-to-peer lookup service for Internet applications. IEEE/ACM Transactions on Networking, 11(1):1732. [Vogt 2008] Vogt, C. (2008). Six/One Router: A scalable and backwards compatible solution for provider-independent addressing. Em Workshop on Mobility in the Evolving Internet Architecture (MobiArch), p ginas 1318. a [Wetherall 2006] Wetherall, X. Y. D. (2006). Source selectable path diversity via routing deections. Em ACM SIGCOMM, p ginas 159170. a [Xu e Rexford 2006] Xu, W. e Rexford, J. (2006). MIRO: Multi-path Interdomain ROuting. Em ACM SIGCOMM, p ginas 171182. a [Yang 2003] Yang, X. (2003). NIRA: a New Internet Routing Architecture. Em ACM SIGCOMM workshop on Future Directions in Network Architecture (FDNA), p ginas a 301312. [Yang et al. 2007] Yang, X., Clark, D. e Berger, A. W. (2007). NIRA: a New Interdomain Routing Architecture. IEEE/ACM Transactions on Networking, 15(4):775 788.