WirelessBR |
WirelessBr é um site brasileiro, independente, sem vínculos com empresas ou organizações, sem finalidade comercial, feito por voluntários, para divulgação de tecnologia em telecomunicações |
|
Série de artigos sobre VoIP (2) |
||
José de Ribamar Smolka Ramos |
Série
de artigos sobre
VoIP
Segundo artigo - Parte 04
Camada internetwork (Continuação 1)
Cada pacote que é recebido pela camada internetwork, vindo da camada de transporte do mesmo host, já vem com a informação de qual o endereço IP de destino final (destination address) que foi definido já na camada de aplicação, lembra? A socket interface mantém esta informação durante toda a duração da sessão. Este endereço, mais o endereço IP da interface do host por onde o pacote será enviado (source address) fazem parte do header do pacote IP.
A primeira coisa que o algoritmo IP neste host faz é perguntar: eu tenho adjacência física com o host identificado pelo destination address? Isto é respondido obtendo o network address associado ao destination address em todas as interfaces deste host (via AND com as respectivas subnet masks ou prefixos CIDR, o que dá na mesma). Se houver coincidência, então o host de destino é adjacente a este host através da interface onde a coincidência ocorreu.
Aqui está uma grande oportunidade para um administrador distraído “melecar” todo o processo de entrega de pacotes IP. Basta não coincidir as configurações das subnets com as redes físicas associadas às interfaces. Supondo que isto está ok, então o próximo passo é entregar o pacote IP à camada física associada à interface selecionada, e o pacote segue para o seu destino final diretamente.
Mas, se não ocorrer nenhuma coincidência do network address de destino com os network addresses das interfaces deste host? Então a entrega do pacote terá de ser feita de forma indireta, usando outro host como “ponte” para fazer o pacote chegar mais perto do seu destino final.
A decisão que este host tem de tomar, então, é: qual dos hosts (com os quais eu tenha adjacência física) é a melhor opção para encaminhar o pacote adiante, e fazê-lo chegar mais perto do destino pelo melhor caminho possível? Esta decisão é tomada com base em uma tabela de rotas (routing table), que todo host TCP/IP tem.
Para os hosts menos complicados, que tem apenas uma interface física de aceso à rede, esta tabela assume, geralmente, uma forma muito simples: apenas a declaração do endereço IP do host que deve ser usado para encaminhar pacotes IP para qualquer outra subnet, diferente desta onde este host está diretamente conectado. Este é o last resort gateway, também conhecido como default gateway.
Mas existem hosts com múltiplas interfaces, e/ou com múltiplas opções de quais poderiam ser os hosts usados para passar adiante os pacotes IP cujos destination addresses estão em subnets onde ele não tem conectividade física. Nestes casos a tabela de rotas terá múltiplas entradas, uma para cada subnet de destino (identificada pelo seu network address mais a subnet mask ou prefixo CIDR associados), e com a designação do endereço IP de um host (com conectividade física direta) que será usado para rotear os pacotes destinados àquela subnet.
Resumindo, se eu tenho conectividade física, entrego o pacote diretamente. E se eu não tenho conectividade física, entrego o pacote indiretamente, remetendo o pacote para o host identificado como gateway de acesso para a subnet de destino na minha tabela de rotas.
E se eu for um destes gateways intermediários? O que eu faço? Simples: recebo os pacotes físicos que foram endereçados a mim pelos outros hosts. Examino, então, o destination address para ver se ele coincide com algum dos meus próprios endereços IP (se eu tiver várias interfaces, então também terei vários endereços IP pelos quais eu posso ser conhecido). Se coincidir, então o pacote é para mim, e encaminho isto para cima, para a minha camada de transporte. Se não coincidir, eu também faço o processo de examinar minha tabela de rotas e passo o pacote adiante para o próximo gateway na rota.
Fatos importantes sobre este método de roteamento:
Nenhum host conhece a rota inteira para uma determinada subnet. As tabelas de rotas de cada um apontam apenas quem é o próximo gateway no caminho.
Em tese, qualquer host que tenha múltiplas interfaces pode ser usado como gateway entre subnets diferentes. O que não quer dizer que todos apresentem a mesma performance quando executam este papel. Na prática, usam-se hosts especialmente projetados para garantir o melhor desempenho possível da tarefa de encaminhar pacotes entre subnets – os roteadores (routers).
O serviço prestado pela coletividade das camadas internetwork nos vários hosts conectados à rede é best-effort delivery, com um mínimo de sinalização de problemas através de mensagens ICMP[11] (Internet control message protocol), cuja implementação é mandatória junto com o IP.
Os pacotes IP são enviados de um
host a outro “pulando carniça” (hop-by-hop) através de tantos
gateways intermediários quantos sejam necessários, como mostra a figura 4.
Portanto é crítico para a eficiência do processo que todas as tabelas de rotas
sejam coerentes entre si.
Figura 4 - Roteamento hop-by-hop