O documento discute as vantagens das conexões múltiplas com a Internet para redes, como confiabilidade, largura de banda e independência. Explica como o BGP e o NAT podem ser usados para implementar conexões múltiplas, abordando desafios como agregação de rotas e falhas.

1. Multiconexões<br /> A Internet em sua forma atual é um conjunto descentralizado de redes. Cada uma delas é conhecida tipicamente com um sistema autônomo (AS). Geralmente, um AS está subordinado a uma política de roteamento comum e é gerenciado por uma única administração técnica. Quando um AS possui conexões múltiplas com a Internet, ela é conhecida como sistema autônomo com múltiplas conexões.<br />Existem muitas razões para manter conexões múltiplas com a Internet:<br />• confiabilidade: comparada com redes que possuem apenas uma conexão com a Internet, uma rede com múltiplas conexões é muitas vezes usada para garantir a continuidade de operação quando uma conexão cai;<br />• largura de banda: a prática das múltiplas conexões pode agregar caminhos múltiplos entre fonte e destino. Assim, permite que a rede suporte maiores taxas de transferência de dados do que num caminho único. Às vezes, uma fonte poderá usar uma elevada largura de banda, mas com um enlace mais caro para seu tráfego em tempo real e um de menor custo para o resto do tráfego. Nesse caso, pode-se usar a tecnologia de múltiplas conexões para melhorar o desempenho da rede;<br />• independência: do ponto de vista econômico, político e administrativo, a independência está se tornando um requisito cada vez mais comum para as empresas e instituições. A prática das conexões múltiplas fornece um certo grau de independência do provedor. Ela ajuda a conseguir acordos com melhores níveis de serviço ou menores preços;<br />• política: às vezes o tráfego está baseado em políticas além das considerações técnicas. Por exemplo, uma instituição acadêmica talvez direcione o tráfego comercial para o provedo que oferece conectividade global de Internet, enquanto direciona seu tráfego de pesquisa por uma rede nacional de pesquisa.<br />Soluções de implantação de conexões múltiplas<br />Uma rede pode ser classificada como “multiligada” e “multiconectada”, dependendo do número de ISPs - provedores de serviços de Internet a que a rede está ligada (figura 1). A rede “multiligada” se conecta a um ISP com conexões múltiplas.<br />Ao contrário, uma rede “multiconectada” se conecta a mais de um ISP [11]. Nessa figura, redes stub (isto é, redes que não roteiam tráfego entre outras redes) contêm hosts que produzem ou consomem pacotes IP. Ou seja, as redes stub não transportam pacotes IP que não sejam produzidos pelos seus hosts ou destinados a eles.<br />Atualmente, existem duas soluções principais para oferecer conexões múltiplas numa rede stub – o protocolo de roteador de borda (BGP) e o mecanismo de NAT - tradução de endereço de rede, que veremos em detalhes a seguir.<br />Conexões múltiplas com BGP<br />Os roteadores em um AS podem usar vários protocolos de roteamento internos, tais como o protocolo IS-IS e o OSPF – Open Shortest Path First para trocar informações de roteamento dentro do AS [2]. Por outro lado, os roteadores usam um protocolo de roteamento externo (EGP) pararotear os pacotes entre osASs. O BGP é um protocolo de roteamento intersistemas autônomos [13]. É usado para trocar informações sobre atingibilidade das redes com outros sistemas autônomos (ASs) nas redes TCP/IP. Com base na contagem de saltos AS e no nível de preferência, o BGP escolhe a rota mais curta. Quando um AS recebe a informação de atingibilidade do exterior, ela é distribuída dentro do AS para que todos os roteadores do sistema possam chegar às rotas anunciadas pelo exterior. Quando há troca das informações de atingibilidade entre dois roteadores localizados em ASs diferentes, ele recebe o nome de BGP externo (eBGP). Quando há troca das informações de atingibilidade entre dois roteadores localizados dentro do mesmo AS, o protocolo é chamado de BGP interno (iBGP).<br />Fig. 1 - As múltiplas conexões: a) rede multiligada; b) redecom múltiplas conexões<br />A seguir, discutiremos os detalhes de gerenciamento de endereços, processo de roteamento e tratamento de falhas nas redes de multiconexões.<br />Para conseguir conexões múltiplas com uso do protocolo BGP, uma rede stub deve apresentar:<br />• Um mínimo de espaço de endereço identificado por um prefixo com 24 bits ou mais para permitir as conexões múltiplas no BGP.<br />• Um número de sistema autônomo(ASN). Cada AS deve possuir apenas um ASN.<br />Existem duas formas para alocação de espaço de endereço: endereço independente do provedor (endereço PI) e endereço atribuído do provedor (endereço PA). Um alocador de endereços do tipo ARIN (American Registry for Internet Numbers) mostrou que um requisito de mais de 21 bits pode solicitar um mínimo de 20 bits de espaço de endereçamento IP diretamente do ARIN. Esse tipo de espaço de endereço IP é conhecido como endereço “PI”. As sub-redes IP(também conhecidas como rotas, prefixos e blocos de rede) podem ser<br />oferecidas a partir de um ISP superior se a demanda por endereços IP não for suficiente. Essas sub-redes são geralmente parte de um bloco maior de espaço de endereço o qual o ISP recebeu do ARIN. Esse tipo de prefixo de endereço IP é<br />conhecido como espaço PA. Surgem problemas diferentes quando as multiconexões em BGP são oferecidas com a adoção de diferentes esquemas de endereços.<br />Os endereços PI implicam independência de uma rede stub em relação aos provedores de nível superior. Devido a essa independência, rotas com <br />endereçamentos PI não podem ser agregadas pelos ISPs de nível superior. Essa situação leva à sobrecarga da tabela de roteamento. Em um cenário de rede que faz uso de endereços PA, um mecanismo de gerenciamento de endereços consiste em usar apenas um bloco de endereços atribuído por um de seus ISPs de nível superior, chamado de bloco de endereço default. Outros ISPs de nível superior mantêm uma entrada de tabela de roteamento específica para a rota associada com o bloco de endereço de default. Essa abordagem não mantém<br />automaticamente as rotas de backup. Outro mecanismo é separar de forma lógica a rede stub inteira em várias sub-redes, cada qual recebendo um prefixo separado de endereçamento do ISP de nível superior mais próximo a ela [11]. O problema que surge aqui é a atualização das entradas da tabela de roteamento. As rotas não agregadas podem ser anunciadas através de redes multiconectadas com endereço PI, e rotas agregadas podem ser anunciadas com endereços PA [11]. Por exemplo, na figura 2, o AS65500 é uma rede sem conexões múltiplas e o AS901 é uma rede com conexões múltiplas. A mensagem de notificação da rota<br />do AS65500 “198.18.32.0/24 65500” é agregada pelo seu ISP superior (AS101) porque o “198.18.32.0/24” é um sub-bloco de 198.18.0.0/16. Ao contrário, a mensagem de notificação do AS901 não pode ser agregada por seus ISPs de nível superior AS101 e AS103 porque o prefixo do AS901 não está incluso pelo prefixo do AS101 e AS103.<br />Na figura 3, o AS101 atribui um bloco de endereço PA “198.18.1.0/19” ao AS901. Para o tráfego de saída, o AS901 envia uma mensagem de notificação “198.18.1.0/19 901”. O AS101 pode combinar a rota de “198.18.1.0/19 901” com a mensagem do AS65500 e depois enviar uma mensagem agregada de rota “198.18.0.0/16 101:901”. Ao contrário, o AS103 enviará “198.18.1.0/19 103:901” porque ela não pode agregar a mensagem de notificação enviada pelo AS901. Para o tráfego de entrada, os roteadores encaminham os pacotes pela rota mais específica de acordo com o protocolo BGP. A rota mais específica refere-se àquela que possui uma abrangência de endereçamento menor. Aqui, a rota mais específica é “198.18.1.0/19 103:901”. <br />Portanto, o AS901 receberá todos os pacotes via AS103, a menos que os enlaces entre o AS901 e o AS103 não estejam disponíveis. Nesse caso, os enlaces entre o AS901 e o AS101 serão<br />usados para encaminhar o tráfego. Na figura 4, o AS901 se divide em duas sub-redes e recebe os blocos de endereçamento 198.18.1.0/19 e 65.3.10.0/19 dos ISPs de nível superior correspondentes. Consequentemente, o tráfego dessas duas sub-redes é agregado pelos ISPs de nível superior – AS101 e AS103, respectivamente. As duas sub-redes são tratadas pelos AS superiores como redes separadas. Ou seja, o superior aceita apenas o tráfego de saída com um prefixo que é anunciado para esse AS pela rede stub. Nesse exemplo, o AS101 aceita apenas o tráfego vindo de 198.18.1.0/19. Infelizmente, caso a conexão entre o AS101 e a sub-rede falhe, os hosts na sub-rede 198.18.1.0/19 se tornam inacessíveis via roteamento interdomínio.<br />O RFC2260 [1] sugere dois métodos para tratar falhas das conexões múltiplas de BGP com múltiplos prefixos de endereço do tipo PA. O primeiro é baseado no mecanismo de anúncio do roteador de borda eBGP. Este apenas anuncia a atingibilidade de prefixos de endereço para um ISP superior, o qual atribui os prefixos em estado permanente. Caso a conexão para esse ISP caia, o roteador de borda eBGP anuncia a atingibilidade para outros ISPs de nível superior.<br />O segundo método para o gerenciamento de falha acontece via encapsulamento de pacote. O roteador eBGP de uma rede stub também pode trocar informações<br />com os roteadores eBGP dos provedores que estiverem conectados à rede stub, mas que não estão diretamente conectados a ele. Por exemplo, digamos que os roteadores eBGP A e B estejam no AS100. Um roteador eBGP C pertence a outro<br />AS. O B está diretamente conectado a C, mas A não está diretamente conectado a C. Em caso de falha entre B e C, C encapsulará todos os pacotes que devem ser enviados para B com o prefixo IP de A. Em seguida, C envia os pacotes encapsulados por outras conexões do AS100 para A. Logo após, A desencapsula os pacotes recebidos e os direciona para os hosts dentro do AS100 ([1]).<br />Além dos dois métodos mencionados, existe uma terceira opção, que consiste em colocar rotas de conexões primárias e conexões de backup nas tabelas de roteamento do BGP. As rotas de conexões de backup tornam-se mais longas, pois seu número de AS é prefixado várias vezes ao início da rota. Quando a<br />rota primária cai, as de backup podem ser usadas, pois estão disponíveis nas<br />tabelas de roteamento do BGP.<br />Conexões múltiplas com NAT<br />A função básica do NAT é traduzir o endereço público de Internet e o endereço a partir do endereço da rede local interna. Ela pode ser ampliada para implantar as conexões múltiplas[9]. Pequenas redes que não podem operar com conexões múltiplas em BGP podem conseguir o mesmo efeito com o auxílio do NAT. Nesse<br />caso, os hosts em uma rede stub NAT de conexões múltiplas compartilham<br />os endereços de rede. O NAT pode mapear os blocos de endereços atribuídos para cada ISP de nível superior para o espaço de endereço interno da rede. O mapeamento é mantido em um roteador NAT.<br />Quando o pacote IP deixa a rede, o roteador NAT traduz os endereços IP privados em endereços públicos, os quais talvez pertençam a ISPs diferentes. Assim, a rede pode tornar-se de multiconexões para vários provedores de acesso.<br />Se as redes multiconexões NAT não adotarem o BGP e não se envolverem no processo de roteamento dentro do AS, o roteador NAT pode tratar das falhas com um mecanismo preestabelecido de mapeamento de tráfego. No entanto, poderá ocorrer perda de tráfego, pois o mecanismo de mapeamento não pode ser atualizado automaticamente após um erro. Um segundo método consiste em usar o servidor DNS. Nesse cenário, um host em rede NAT é associado a múltiplos endereços IP. Se um ISP não estiver disponível, o endereço IP de outro ISP é retornado e o tráfego se concretiza. Esse método pode reduzir a perda de<br />tráfego, mas não pode evitá-lo.<br />Comparação entre BGP e NAT<br />As conexões múltiplas via BGP e NAT são diferentes em pelo menos três aspectos:<br />• Como protocolo padrão interdomínio da Internet, o BGP dá o maior suporte para as aplicações de nível superior. Ao contrário, a NAT não garante a exclusividade do endereço IP e não suporta todas as aplicações de nível superior.<br />• As conexões múltiplas pelo NAT evitam problemas de não agregação porque, na maioria dos casos, os blocos de endereço em uma rede NAT são atribuídos por um ISP superior. Esse problema pode ocorrer nas multiconexões com BGP.<br />• O BGP é usado principalmente pelas grandes empresas. O NAT é mais recomendado para empresas de pequeno porte que não estão familiarizadas com o controle de roteamento.<br />Desafios associados ao BGP<br />A Internet se expandiu muito nos últimos anos e o número de ASs aumentou de forma significativa. Além disso, a quantidade e diversidade das aplicações suportadas na Internet aumentaram na mesma proporção. Essa tendência aumentou a pressão sobre o BGP.<br />Já que o BGP provê informações para o controle de tráfego entre os AS, ele é de vital importância para a eficiência, confiabilidade e segurança da Internet. No entanto, o BGP apresenta vários pontos vulneráveis. A seguir analisaremos os desafios que os pesquisadores encontram hoje em dia.<br />Escalabilidade<br />Um AS pode escolher sua própria política para decidir a melhor rota. Quando ocorre o roteamento inter-AS, cada AS anuncia a informação para roteamento inclusa na tabela de roteamento do BGP para outros ASs. O anúncio de uma rota AS inclui um prefixo IP e uma série de números de AS. Como mencionamos anteriormente, a quantidade de ASs aumentou bastante, o que contribui para a<br />sobrecarga da tabela de roteamento. Outra razão importante para o recente aumento é que a maioria dos ASs stub preferiram aumentar sua conectividade com a Internet para obter flexibilidade e balanceamento de carga.<br />A fim de explicar como as múltiplas conexões afetam as tabelas de roteamento do BGP, consideremos o exemplo na figura 5. Suponhamos que o AS901 queira obter o balanceamento de carga, gerando assim dois prefixos IP dos ASs superiores. Para balancear as cargas do seu tráfego de entrada, ele prefere anunciar seus prefixos de modo que:<br />• o tráfego direcionado para 65.3.10.0/19 seja entregue basicamente através do AS103, e o AS101 seja usado como caminho de back-up; e<br />• o tráfego direcionado para 198.18.1.0/19 seja entregue basicamente através do AS101, e o AS103 seja usado como caminho de back up.<br />O AS 901 prefixa seu próprio número de AS nos anúncios de BGP a fim de identificar prefixos específicos. Como mencionamos anteriormente, o prefixo específico implica a melhor rota quando os AS superiores selecionam rotas. Na<br />figura 5, o AS101 e o AS103 estão configurados de forma diferente. O AS101 envia os dois anúncios do BGP. O AS103 envia um anúncio agregado para 198.18.0.0/16, já que ele inclui o 198.18.1.0/19. Conforme apresentado na figura 5, embora o AS901 dê origem a apenas dois prefixos, o AS198 recebe quatro rotas para três prefixos diferentes. Portanto, o tamanho da tabela de roteamento do BGP aumenta no AS198, pois ele recebe mais de uma rota para o mesmo prefixo. Apesar da operação de pré-fixação, todo o tráfego do AS901<br />para o AS198 será encaminhado via AS101, porque:<br />• o caminho mais próximo para 65.3.10.0/19 é via AS101. Portanto, o tráfego para 65.3.10.0/19 será enviado pelo AS101; e<br />• o roteador BGP sempre prefere um prefixo mais específico para encaminhamento do tráfego. Na figura 5, o 198.18.1.0/19 é mais específico que o 198.18.0.0/16.<br />Nesse caso, o AS103 irá parar de agregar os prefixos do AS901. Essa manobra faz com que AS103 anuncie dois prefixos ao AS198. Para reduzir o tamanho da tabela de roteamento, podem-se agregar diferentes rotas com características comuns numa única rota. Entretanto, uma rede de conexões múltiplas herda múltiplos prefixos IP de AS superiores diferentes e, assim sendo, seus prefixos não podem ser agregados por todos os AS. No exemplo, o prefixo 198.18.1.0/19 pertence ao AS103 e esse prefixo não pode ser agregado por outro ISP (AS101). Outra razão para a não agregação é que um AS pode ter de anunciar vários prefixos devido à fragmentação de endereço, balanceamento de carga e falha na<br />agregação [4]. Esse exemplo ilustra a não agregação causada pelo balanceamento de carga. A maioria dos ISPs filtra os anúncios de longos prefixos para poder lidar com o problema de tabela de roteamento. Por exemplo, alguns ISPs não permitem o anúncio à Internet global de prefixos mais longos que /22. No entanto, essa estratégia não atinge a raiz do problema, apenas o contorna.<br />Esforços estão sendo despendidos para solucionar esse problema em IPv6. Para o IPv4, o problema está em sua maior parte sem solução. Simpler [7] força a agregação de prefixo de endereço sobre toda a rede, mas usa NAT para atribuir<br />endereços múltiplos.<br />Falta de roteamento multicaminho<br />Um roteador BGP pode receber vários anúncios para a mesma rota advindos de vários roteadores superiores. Por exemplo, na figura 5, o roteador em AS198 recebeu dois anúncios para o prefixo 65.3.0.0/19. Portanto, o roteador precisa rodar seu processo de seleção BGP para selecionar o melhor caminho. O protocolo BGP seleciona apenas um caminho mais adequado. Dessa forma, o roteador BGP anuncia aos seus pares a melhor rota para qualquer destino. Esse comportamento faz surgir pelo menos duas limitações. Primeiro, uma melhor rota entra em conflito com o conceito de balanceamento de carga. Em resposta, alguns fabricantes/fornecedores suportam extensões multicaminho em suas implementações BGP. Segundo, uma vez que um roteador BGP apenas anuncia a melhor rota, muitos caminhos alternativos que poderiam ter sido usados permanecerão desconhecidos [10].<br />Isso introduz problemas no atual paradigma de roteamento interdomínio do ponto de vista de QoS - qualidade de serviço fim a fim e de engenharia de tráfego [3]. Têm-se realizado esforços para corrigir essa questão para que um roteador BGP possa anunciar aos seus pares rotas múltiplas para o mesmo destino. Entretanto, esse mecanismo fará com que o presente problema de BGP com conexões múltiplas seja ainda mais difícil de solucionar. Por exemplo, a possibilidade de multiconexões aumentará consideravelmente o tamanho da tabela de roteamento, o que gerará, futuramente, grande repercussão na questão da escalabilidade.<br />Convergência lenta<br />Dois roteadores BGP precisam estabelecer uma sessão BGP para trocar informações de atingibilidade. Tal sessão é suportada por uma conexão TCP, através da qual os roteadores trocam diferentes tipos de mensagens:<br />• Open: para abrir uma sessão BGP.<br />• Update: para transferir informações sobre atingibilidade.<br />• Notification: para identificar um erro detectado. A sessão de BGP é fechada após o envio dessa mensagem.<br />• Keepalive: para verificar que o par está acessível. A mensagem Open pode ajudar a determinar se a sessão BGP corresponde a um iBGP ou eBGP. Quando a sessão tem início, cada par anunciará todo seu conjunto de rotas. Assim, ocorrerão trocas apenas de atualizações e de mensagens Keepalive.<br />Tempo de convergência é uma medida de desempenho importante para um protocolo de roteamento e consiste no tempo necessário para reorientar os pacotes em caso de falha. Um estudo [8] demonstra que o tempo de convergência do BGP é bastante lento. Uma razão importante é que uma única falha de enlace pode fazer com que os roteadores BGP troquem um grande número de anúncios para explorar caminhos alternativos para os destinos afetados. Esse problema é chamado de exploração de caminho.<br />Os roteadores podem trocar vários anúncios sobre o mesmo prefixo no processo de convergência de BGP. Para evitar esse problema, a maioria dos roteadores de BGP usa um temporizador chamado de intervalo mínimo para anúncio de rota. O<br />valor default desse temporizador é de 30 segundos. Esse método evita que os roteadores de BGP enviem um novo anúncio para o mesmo prefixo dentro de 30 segundos. Dessa forma, a quantidade de anúncios de BGP é reduzida. No entanto, isso resulta num outro problema: atraso. Em alguns casos, anúncios importantes de BGP sofrem atrasos desnecessários, o que influencia diretamente o desempenho da rede.<br />Surgiram algumas novas propostas para solucionar esse problema. Por exemplo, o BGP-RCN [12] reduz o número de mensagens de BGP trocadas na convergência adicionando-se um identificador para cada mensagem de BGP. Esse identificador indica a causa original da mensagem de BGP. Caso ocorra uma falha, os roteadores distantes podem evitar usar um caminho afetado pela falha. No<br />entanto, essa informação adicional não é embutida nos anúncios de BGP e é contra sua escalabilidade.<br />Outra solução é a descarga fantasma (ghost-flushing) [6]. Esse método melhora a convergência ao distribuir rapidamente as mensagens que trazem más notícias, enquanto distribui lentamente as mensagens com boas notícias. No entanto, o método apenas tenta aumentar a velocidade da convergência do BGP e não trata do problema na sua origem, ou seja, a exploração do caminho.<br />Falta de suporte de qualidade de serviço<br />A maioria dos estudos sobre QoS baseou-se em redes sem multiconexões. O BGP não possui capacidades de QoS, pois foi desenhado apenas para trocar informações de atingibilidade. Algumas aplicações, como o VoIP, necessitam de QoS estrita para funcionar entre domínios diferentes [5].<br />Novas propostas foram apresentadas nos últimos anos, mas nenhuma atraente o bastante para ser colocada em prática. Uma boa razão é que os ISPs preferem<br />sobredimensionar suas redes para manipular a QoS. Ainda será necessária a análise de mais questões antes que os ISPs decidam usar o mecanismo para gerenciamento de QoS. Essa análise inclui o custo para implantar e manter a QoS e as novas possibilidades comerciais que poderão se desenvolver para obter lucros reais para os ISPs, etc. Do lado técnico, todas as propostas de QoS apresentam fortes limitações no nível interdomínio.<br />Otimização de seleção de rotas<br />A otimização de rotas refere-se à distribuição de tráfego entre as múltiplas conexões de uma rede stub na Internet. Devem ser considerados dois aspectos para a seleção de uma rota de otimização. Primeiro, deve-se optar pelo provedor de nível superior mais qualificado. Segundo, o tráfego deve ser distribuído entre várias conexões, o que significa problemas de balanceamento de carga.<br />A seleção do tráfego de entrada é difícil. Existem mecanismos para implantar o balanceamento de carga para o tráfego de saída, mas não existem mecanismos para o tráfego de entrada sem NAT. Uma limitação causada pelo NAT é a falta de suporte para aplicações não-cliente/servidor, pois ele foi projetado inicialmente no contexto do ambiente cliente/servidor.<br />Conclusão<br />As conexões múltiplas podem ajudar as empresas a alcançarem suas metas de desempenho na Internet: confiabilidade e redundância.<br />Também ajudam a reduzir a dependência de um único provedor, gerando muito mais oportunidades para o controle do custo da banda larga e flexibilidade contratual.<br />Mas apesar de seu papel promissor em futuras soluções de conectividade com a Internet, a prática das conexões múltiplas ainda apresenta vários desafios.<br />O BGP, por exemplo, como um importante protocolo de roteamento interdomínio, ainda apresenta limitações, que têm-se tornado cada vez mais nítidas nos últimos anos devido ao crescimento explosivo da rede. As pesquisas atuais concentram-se na escalabilidade, seleção de rotas, convergência, qualidade de serviço, etc. Além dos fatores técnicos, o gerenciamento do roteamento e as políticas em uso pelos diferentes ISPs também contribuem para essas dificuldades. Geralmente, os ISPs mostram-se relutantes em introduzir novas mudanças se não houver fontes promissoras de lucros. Isso aumenta as dificuldades para lidar com os problemas existentes associados ao BGP.<br />REFERÊNCIAS<br />[1] T. Bates e Y. Rekhter: Scalable support for multihomed multi-provider<br />connectivity. Technical Report 2260, 1998.<br />[2] S. H.: Cisco Systems. Bgp4 case studies/tutorial. 1995.<br />[3] B. H. et al. Distance metrics in the internet. 2002.<br />[4] Globecomm. On characterizing BGP routing table growth. Jan./2002.<br />[5] IEEE: Challenges in enabling interprovider service quality in the Internet. Jun./2005.<br />[6] IEEE Infocom: Improved BGP convergence via ghost flushing.<br />[7] IEEE Infocom: Practical Routing-Layer Support for Scalable Multihoming. 2005.<br />[8] C. Labovitz, A. Ahuja, A. Bose e F. Jahanian: Delayed Internet routing<br />convergence. 9(3):293–306, Jun./2001.<br />[9] P. Morrissey. Route optimizers: mapping out the best route. Dez./2003.<br />www.networkcomputing.com/showitem.jhtml?docid=1425f2.<br />[10] Network, IEEE: Open issues in interdomain routing: a survey. Nov./2005.<br />[11] Network, IEEE: A survey of multihoming technology in stub networks: current<br />research and open issues. Mai./2007.<br />[12] D. Pei, M. Azuma, N. Nguyen, J. Chen, D. Massey e L. Zhang. Bgp-rcn:<br />Improving bgp convergence through root cause notification. UCLA Computer Science<br />Department, 2003.<br />[13] Y. Rekhter, T. Li e S. Hares. A border gateway protocol 4 (bgp-4). The Internet<br />Engineering Task Force, Jan./2006.<br />