Suburban Ad-Hoc Network (SAHN)

Felipe Ortigão Sampaio Buarque Schiller

Universidade Federal do Rio de Janeiro
Grupo de Teleinformática e Automação (GTA)
Professor: Luís Henrique M. K. Costa
Disciplina: CPE825

1. Introdução

O grupo denominado Suburban Ad-Hoc Network (SAHN) tem como

proposta oferecer internet de alta velocidade com baixo custo inicial e tarifa zero
usando redes sem fio, o que permite inclusive alcançar áreas em que outros
meios de acesso não são possíveis. O objetivo buscado é prover comunicação
com baixa latência, controle de tráfego e confiabilidade.
Para isso utiliza-se uma rede não centralizada nas quais os nós
constituintes se comunicam utilizando um protocolo de roteamento ad-hoc, ou
seja, cada nó é capaz de rotear pacotes para outros nós. É importante observar
que esses nós apresentam pouca mobilidade o que influenciará no protocolo a ser
utilizado.
A construção desse protocolo foi baseada no protocolo sob demanda
Dynamic Source Routing (DSR). Esse protocolo faz roteamento por fonte, ou
seja, armazena toda a rota até o destino. Portanto, quando todas as rotas já foram
descobertas não há overhead com mensagens de controle e caso haja uma
mudança de topologia, desde que esta não influencie o roteamento, é ignorada
pelo DSR. Essas características são vantajosas ao SAHN por este se tratar de
uma rede quase estática. Outra característica importante é a capacidade de
armazenar múltiplas rotas para o mesmo destino, o que o diferencia de outros
protocolos sob demanda já existentes e provê melhor qualidade de serviço.
A grande desvantagem do DSR é o fato de ele carregar toda a rota tanto
nos pacotes de roteamento quanto nos de dados, o que acarreta um overhead
crescente, principalmente se a rede possui muitos saltos. Foi desenvolvida uma
solução para minimizar esse problema conforme será visto.

2. Protocolo de roteamento SAHN

Por se tratar de uma estrutura descentralizada, cada nó possui uma tabela
de roteamento própria formada pelos campos de endereço de destino, caminho
até ele, número de saltos, gerenciamento, validade da rota e interface. O campo
número de saltos é guardado por razões de QoS, o campo gerenciamento contém
dados relativos a latência, taxa de erro de pacotes, tamanho dos pacotes e
saturação. O campo de validade da rota é definido, pois apesar da baixa
mobilidade, um nó pode se desconectar por outras razões tais como queda de
energia e mau tempo.
Cada nó possui um endereço único que o identifica chamado SAHN Id,
esse endereço foi definido com tamanho de 24 bits o que resulta em 16.8 milhões
de endereços únicos, o que obriga a existência de uma entidade para gerenciá-los,
ao mesmo tempo em que elimina dificuldades como DHCP (Distribuição
dinâmica de IPs) numa rede descentralizada, principalmente se for de grande
porte.
O protocolo é organizado em três partes: Descoberta de vizinhos,
descoberta de rotas e manutenção de rotas. Todas elas usam criptografia como
mecanismo de segurança, entretanto esse procedimento só será descrito mais
tarde.

2.1. Descoberta de vizinhos

Quando um nó é ligado, inicialmente ele limpa toda a sua tabela de
roteamento de maneira que não permaneça nenhuma rota inválida nela. A seguir,
o protocolo inicia o procedimento de descoberta de vizinhos constituído das
seguintes etapas:
• O nó que deseja se conectar no SAHN emite um pacote de Hello que
contém o endereço de identificação do nó, tempo de transmissão e
chave compartilhada.
• Após a emissão, o nó deve esperar pela resposta até um tempo máximo
de expiração, como o nó pode não ter nenhum vizinho imediato, é
possível não vir nenhuma resposta. Nesse caso é reportada uma falha
ao administrador que pode tentar o nó conectar mais tarde.
• Uma vez que um ou mais nós vizinhos tenham recebido esse pacote de
Hello, eles devem adicionar o novo nó em suas respectivas tabelas de
roteamento e responder com o pacote de Hello Reply. Esse pacote deve
conter o endereço de identificação do nó, o endereço do novo nó que
está se associando, tempo de transmissão e chave compartilhada
desses.
• Recebendo o pacote de Hello Reply, o novo nó deve adicionar os
dados referentes aos novos nós em sua tabela de roteamento.
 Figura 1: Descoberta de rota

2.2. Descoberta de rotas

Identicamente ao DSR, quando um nó requer uma rota para um destino
não presente na sua tabela de roteamento ou que tenha espirado ele efetua esse
procedimento. Uma vez completado ele encontra uma ou mais rotas para o
destino ou entende que o destino não está alcançável. Esse é procedimento é
inteiramente sob demanda sendo utilizados dois tipos de pacotes: Requisição de
Rota (RREQ - Route request) e Resposta de Rota (RREP - route reply).
Esses pacotes são identificados pelo endereço do nó de origem, definido
como endereço iniciador (initiator address) e pelo identificador de broadcast
(broadcast id). À medida que os pacotes são reenviados a estação verifica pela
existência desse par em seu cache e se excedeu o tempo de expiração. Em caso
positivo ela descarta o pacote, caso contrário, ela o processa. Esse procedimento
evita a formação de loops na rede.
Conforme a figura 1, o nó A faz o broadcast de uma Requisição de Rota e
fica aguardando por uma ou mais respostas. Uma Resposta de Rota é gerada se
uma estação ou mais souberem de uma rota até o destino ou se ela for o destino.
Se por exemplo o nó D possui essa rota ele vai emitir uma Resposta de Rota para
C e este para B e finalmente para A. Se nenhuma rota for encontrada, o nó A
deve tentar a Requisição de Rota mais tarde.
O campo Lista de Endereço de Roteamento e lista de informação de QoS
(RAQL - Route Address List and QoS Information List) do pacote de Requisição
de Rota carrega informações a respeito de todo o trajeto do pacote até o destino,
sendo adicionado não só o endereço do nó atual como também dados relativos ao
QoS (banda disponível e taxa de erro). O nó intermediário também atualiza a sua
tabela de roteamento para incluir possíveis rotas desconhecidas até ele.
Assim, voltando ao exemplo, o quando a Requisição de Rota chegar ao nó
D, ele terá a informação de toda a rota desse percurdo, bem como cada nó terá até
si. Nesse momento D envia em unicast à A uma Resposta de Rota.
Ao receber um RREP, o nó intermediário deve atualizar a sua tabela de
roteamento, procurar o próximo salto na RAQL e atualizar o campo de origem
local (local source) para o seu endereço.
2.3. Transmissão de dados
Quando um nó quer transmitir pacotes de dados para um destinatário, ele
primeiro verifica na tabela de roteamento se o destinatário é seu vizinho. Em
caso positivo e havendo suficiente QoS, o dado lhe é transmitido em unicast.
Caso contrário, uma rota com suficiente QoS é utilizada, se somente uma não for
possível, são escolhidas mais que uma.
Diferente do DSR, o nó transmite um pacote com a rota completa e então
os nós intermediários criam uma linha no cache de encaminhamento para os
pacotes subseqüentes indexado pelo endereço do destinatário, não sendo mais
necessária a transmissão da RAQL e dessa forma diminuindo o overhead.

2.4. Manutenção de rotas

O mecanismo de manutenção de rotas se dá quando um nó detecta que um
enlace não está mais operacional ou ao receber um pacote de dados para um
destino desconhecido.
Nesses casos, o nó que detectou o problema gera um pacote de erro de
rota (RERR - Route Error) e o envia ao iniciador. Ao receber esse pacote o
iniciador apaga essa rota e procura por outra rota em sua tabela de roteamento.
Caso não exista ele inicia o processo de descoberta de rota.
Quando um nó intermediário recebe um pacote de erro de rota ele também
deve apagar de sua tabela a rota correspondente.

3. Segurança
Como o SAHN está altamente exposta ao meio, é necessária a utilização
de mecanismos de segurança. Assim, foi implementada forte criptografia em dois
níveis: fim a fim e salto a salto. O primeiro garante que os dados não serão
observados por nós intermediários e o segundo de ser observada por indivíduos
externos a rede.
O sistema proposto é um definido pela Monash SAHN denominado
SAHN Security Protocol (SSP) que opera na camada de rede e utiliza
criptografia assimétrica para pacotes de controle e assimétrica para outros.
Esse mecanismo ocorre da seguinte maneira:
• O nó antes da transmissão do pacote randomicamente gera uma chave
compartilhada para transmitir dados para os seus vizinhos.
• O nó criptografa a chave compartilhada usando a sua própria chave
privada para gerar C1.
• Ele então criptografa C1 usando a chave pública (chave secreta do
SAHN), conhecida só pelos membros, para gerar a cifra C2.
• C2 é juntada ao resto do pacote e enviada.
 • O nó que receber esse pacote irá usar a chave pública do SAHN para
obter C1.
• Ele então procura na base de dados a chave pública do vizinho que
enviou o pacote para obter sua chave compartilhada.
• Registra o novo nó como um nó válido e salva a chave compartilhada
para futura encriptação e decriptação de pacotes enviados e recebidos.

4. Otimização
Nos SAHN algumas soluções de otimização são propostas tendo por
objetivo diminuir eventuais problemas na rede.

4.1. Inundação de pacotes RREP

Esse problema ocorre quando um nó envia um pacote de broadcast de
requisição de rota e recebe múltiplas respostas. Se por exemplo na figura 1, A
envia um RREQ e B, E e F conhecem uma rota para o destinatário, e então
supondo que eles respondem com um pacote RREP para A. Consequentemente A
será inundada por pacotes RREP.
Para solucionar o problema pode-se aguardar um tempo randômico antes
de enviar o pacote, sendo ele experimentalmente calculado ao mesmo tempo em
que escutando em modo promiscuo por outros pacotes RREP. Caso ao fim desse
tempo nenhum tenha sido recebido, então um seria gerado.
É proposta ainda uma solução baseada no número de saltos para calcular
esse tempo de atraso.

4.2. Rede desbalanceada

Pode haver situações que os enlaces não apresentem o mesmo
desempenho em ambas as direções. Nesse caso, ao invés de o nó intermediário
gerar um pacote RREP, ele pode gerar um RREQ contendo um RREP
encapsulado. A diferença se encontra no momento que somente o iniciador pode
gerar um RREP para esse RREQ e não um nó intermediário. Esse método
poderia ser implementado por meio de um flag no pacote RREP.

4.3. Escutar RRER em modo promíscuo

Se os nós passassem a escutar pacotes RERR em modo promíscuo, muitas
rotas inválidas que não teriam como ser conhecidas de outra forma poderiam ser
eliminadas, aprimorando o desempenho da rede.
5. Conclusão
O SAHN foi desenvolvido de maneira a prover conexão sem fio entre nós
vizinhos com um custo quase zero formando uma rede local. E diferente de
outros protocolos de roteamento ad-hoc, ela provê uma conexão quase estática. A
construção do protocolo foi baseada na solução já existente, o DSR que é um
protocolo sob demanda.
Em simulações realizadas em [1] e [3] comparando-se o SAHN com os
dois protocolos sob demanda mais utilizados, o DSR e o AODV, em ambientes
correspondentes a proposta do protocolo, viu-se que o SAHN apresentou
desempenho superior, tanto em teste de saturação da rede quanto no de
introdução de erro. Um fator que fez grande diferença em relação ao DSR foi a
exclusão das RAQL em cada pacote de dados, o que diminuiu a carga na rede.

6. Referências
[1] M. M. Islam, R. Pose, and C. Kopp, “A Hybrid QoS Routing Strategy for
Suburban Ad-Hoc Networks.” ICON 2003, páginas 225-230. Set 28 - Out 1
2003, Sydney, Austrália.
[2] E. Makalic, “Suburban Area Networks: Route Discovery and Maintenance,”
Nov. 2001. Computer Science honours thesis, Monash Uni. Available at
http://www.csse.monash.edu.au/research/san/. Último acesso 04/08/2006.
[3] Islam M., R. Pose, and C. Kopp, “Efficient Routing in Suburban Ad-Hoc
Networks (SAHN).” The 2003 International Conference on Communications in
Computing (CIC 2003), Junho 2003. Monte Carlo Resort, Las Vegas, USA.
[4] M. Islam, R. Pose, and C. Kopp, “Routing In Suburban Ad-Hoc Networks.”
The 2003 International Conference on Computer Science and its Applications
(ICCSA 2003), Julho 2003. San Diego, USA.