Suburban Ad-Hoc Network (SAHN)

Suburban Ad-Hoc Network (SAHN)

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

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.

• 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.