WirelessBR

Série de artigos sobre VoIP
Segundo artigo - Parte 05

Camada internetwork  (Continuação 2)

Para terminar esta seção, vamos então falar um pouco sobre como conseguir que as tabelas de rotas dos vários gateways fiquem coerentes. 

A maneira mais simples é o(s) administrador(es) da rede configurarem manualmente as tabelas de rotas de todos os gateways. Esta abordagem é conhecida como roteamento estático (static routing). Infelizmente, a não ser que a rede seja de pequeno porte, este método é penoso e sujeito a falhas. Para redes TCP/IP de grande porte (como a Internet, ou redes privadas de grande porte) é necessário algo mais sofisticado. 

Para estes casos, existe o roteamento dinâmico (dynamic routing), que é implementado usando protocolos de aplicação nos gateways, para permitir que eles negociem entre si, automaticamente, quais devem ser as entradas que irão constar na tabela de rotas de cada um. 

Os protocolos para dynamic routing existem em dois “sabores”: roteamento externo (exterior routing) e roteamento interno (interior routing), por causa da estrutura descentralizada de administração da Internet. 

A maior unidade administrativa da infra-estrutura da Internet é um sistema autônomo (autonomous system), ou, simplesmente, AS. Para ser um AS, uma organização tem de se registrar junto ao ICANN[12]. Se a solicitação for considerada válida, a organização ganha um AS number que a identifica, e um bloco CIDR de endereços IP para administrar dentro da sua área de atuação. 

O objetivo dos protocolos para exterior routing é a negociação de rotas entre os diversos AS que compõem a Internet. Cada AS possui gateways de fronteira (border gateways) com outros AS. Os protocolos para exterior routing são executados nestes border gateways. O protocolo para exterior routing padronizado pelo IETF é o BGP (border gateway protocol). O protocolo BGP divide-se em dois aspectos: a troca de mensagens com border gateways de outros AS, eBGP (exterior BGP); e a troca de mensagens entre os border gateways do mesmo AS, iBGP (interior BGP). 

Dentro da área administrativa do AS, ele tem liberdade para organizar o roteamento como achar melhor. Para este contexto são usados os protocolos de interior routing. Existem várias opções para interior routing. As mais conhecidas são: RIP (route information protocol), EIGRP (enhanced interior gateway routing protocol), OSPF (open shortest path first) e IS-IS (intermediate system to intermediate system). 

Resta apenas um aspecto do dynamic routing a considerar: Qual critério cada gateway deve adotar para determinar que uma rota é melhor do que outra, e que a sua tabela de roteamento deve ser atualizada para refletir este fato? 

Os protocolos para dynamic routing, neste aspecto, tem algumas coisas em comum e várias diferenças. 

Primeiro as semelhanças. Cada gateway, ao iniciar sua operação, possui apenas informação sobre as subnets às quais ele tem acesso físico direto (isto está configurado em cada interface). Então ele faz anúncio (advertisement) desta informação, em todas as subnets a que esteja conectado, procurando por outros gateways adjacentes a ele – vizinhos (neighbors) – que falem o mesmo protocolo. 

Cada gateway aprende, através dos advertisements recebidos dos seus neighbors, sobre a existência de novas subnets (um hop adiante), e incorpora as melhores opções de acesso à sua própria tabela de rotas. No próximo advertisement estas rotas aprendidas também são enviadas aos neighbors, de forma que, após algumas rodadas de advertisement, todos os gateways convergem suas tabelas de rotas para um conjunto coerente. 

O tempo necessário para isto ocorrer é chamado de tempo de convergência do protocolo. Obtida a convergência, e na ausência de eventos que alterem a topologia da rede (ex.: quedas de links ou entrada em serviço de novos gateways), normalmente os gateways apenas trocarão periodicamente mensagens de keepalive com seus neighbors. 

A falha em receber um certo número de keepalives consecutivos de um determinado neighbor faz com que ele seja considerado indisponível. O gateway, então, recalcula sua tabela de rotas e faz advertisement das alterações. O recebimento de um advertisement, vindo de algum dos neighbors conhecidos ou de um novo neighbor, também faz com que o gateway recalcule sua tabela de rotas e faça advertisement das alterações.  

A grande diferença entre os protocolos está no algoritmo usado para decidir se uma nova rota, recebida via advertisement, é melhor que alguma das rotas que já constam da tabela de rotas, e deve substituí-la. 

Existem duas estratégias para que os protocolos de dynamic routing tomem esta decisão: vetor de distância (distance vector) ou estado de link (link state). O algoritmo mais conhecido para a estratégia distance vector é o Bellman-Ford, e para a estratégia link state o algoritmo mais conhecido é o SPF (shortest path first) de Dijkstra. 

Dos protocolos que mencionamos, BGP, RIP e EIGRP seguem (com muitas variações de implementação) a estratégia distance vector. OSPF e IS-IS (também com variações) seguem a estratégia link state. 

Ufa... Até que enfim, nosso pacote está pronto para remessa física para o próximo host. 

Camada física: 

Com relação à camada física, a arquitetura TCP/IP é agnóstica. Qualquer esquema de rede física (aquilo que, no modelo OSI-RM chamados de camadas de enlace e física) pode ser adaptado para transportar pacotes IP, e praticamente todos os tipos de redes físicas na praça já possuem esta implementação disponível. 

Só existe um ponto que o padrão IETF exige nesta camada. Se a rede física utilizada for de meio compartilhado (ex.: redes locais IEEE 802.x), é necessário um mecanismo para associar o endereço físico da interface do host (no exemplo dado, conhecido como MAC[13] address) com o seu endereço IP. 

O protocolo padrão nestes casos é o ARP (address resolution protocol). Cada host que executa o ARP mantém uma tabela associada à interface, chamada ARP cache. Cada entrada na ARP cache contém um endereço IP, o endereço físico associado a ele e um contador de timeout. A construção da ARP cache é feita assim: 

a)   Sempre que um pacote IP tem que ser transmitido na interface física, a ARP cache é consultada para saber se o endereço físico associado já é conhecido; 

b)   Se já existe uma entrada válida (com contador de timeout diferente de zero) para este endereço IP, o quadro (frame) físico é montado usando o endereço físico lá existente e enviado para transmissão, o contador de timeout desta entrada é incrementado novamente para o valor máximo, e o contador de timeout das outras entradas é decrementado; 

c)   Se não existe entrada para este endereço IP, ou se ela existe, mas é inválida (com contador de timeout igual a zero), é feito uma nova descoberta (discovery) do endereço físico associado, para criar ou revalidar a entrada na ARP cache. 

O discovery é feito pelo envio de um pacote ARP via broadcast físico, contendo o equivalente eletrônico da pergunta: “alguém aí é o dono do endereço IP a.b.c.d?” Todos os hosts na rede física recebem a pergunta e, se existir algum deles que satisfaça ao requisito, apenas ele responde, diretamente para quem perguntou. O host que iniciou o discovery, se receber resposta, usa o endereço físico de origem contido nela para criar uma nova entrada na sua ARP cache. Se não receber resposta, irá sinalizar erro para a camada internetwork (que gerará uma mensagem de erro ICMP). 

A necessidade de um contador de timeout nas entradas da ARP cache é dupla: primeiro, hosts com os quais eu falo muito tendem a permanecer na tabela, sem necessidade de ficar repetindo o discovery. Segundo, hosts com os quais eu falo pouco não ficam “poluindo” desnecessariamente a tabela. Considerando que tanto o endereço IP quanto o endereço físico da interface do host de destino podem mudar, não é uma boa política manter entradas de hosts de baixo tráfego na ARP cache por muito tempo. 

Próximos passos: 

Esta é a visão geral da arquitetura TCP/IP, ainda sem a inclusão de características com headiness index menor que (+5). Estas características adicionais apareceram em grande parte para poder suportar as características de aplicações com headiness index = (–3) ou abaixo, mas antes de chegar nelas, nosso próximo artigo vai dar uma olhada nos roteadores (gateways especialistas). 

Ainda não falamos nada sobre como as características específicas desta ou daquela rede física irão afetar as aplicações de VoIP. Como já disse antes, ainda não é hora de ficar indevidamente fascinado pela camada física. Isto terá seu tempo, mais tarde.