AODV Ad-hoc On demand Distance Vector

O protocolo de roteamento AODV, foi proposto por Perkins (Perkins e Roye 1999) ao verificar que o DSDV possuía o problema de contínuos envios de mensagens de atualizações por rotas, aumentando o tráfego de pacotes de controle na rede e, consequentemente, aumentando o overhead. Segundo Perkins (Perkins e Roye 1999), as emissões de pacotes do DSDV cresciam na proporção de (n2), onde n é o número de nós na rede. Este protocolo também exige que cada nó mantenha uma rota para cada destino dentro da MANET, sendo que dificilmente um nó irá utilizar todas estas rotas. Por este motivo, o AODV foi proposto com a diferença que os nós adicionam apenas rotas que são de seu interesse, assim, é considerado um protocolo reativo e é candidato a virar um padrão para a MANET, segundo a IETF (IETF MANET 2008).

O processo de descobrimento de rota começa assim que um nó necessitar se comunicar com outro nó, o qual não tem nenhuma informação na sua tabela de roteamento. Assim, o nó inicia a busca por uma rota, enviando um pacote RREQ (Route Request ) via broadcast para todos seus vizinhos, que por sua vez retransmitem o pacote. Um pacote RREQ contém:

< source_addr ; source_sequence_num ; broadcast_id ; dest_addr ; destination_sequence_num ; hop_cnt >

Como no DSDV, o protocolo AODV mantém um número de sequência, a fim de manter as suas rotas atualizadas, verificando se o pacote que lhe foi transmitido é atual ou antigo. Este número de sequência é denotado da seguinte forma: Sxxx_Ni, onde

Ni representa o nó onde for criado e Sxxx representa o valor do número de sequência,

que é incrementado cada vez que as conexões do nó em questão, se alteram, devido a modificações na topologia da rede.

No pacote RREQ, contém os números de sequência tanto do nó origem (source_ sequence_num) como do nó destino (destination_sequence_num). Ao retransmitir o RREQ, o nó incrementa a quantidade de saltos (hop_cnt ).

Estes pacotes, também possuem um identificador chamado de broadcast_id, que ao ser recebido pelo nó é adicionado temporariamente na tabela de roteamento, guardando também, o endereço do nó origem (source_addr ) onde o gateway corresponde ao nó que

o enviou. O identificador possibilita que o nó evite retransmitir o mesmo pacote RREQ, prevenindo a formação de loops, ao descartá-lo.

Quando um nó recebe um pedido de rota, ao qual possui o nó destino contido na tabela de roteamento, este verifica se o número de sequência do nó destino que está guardado na tabela de roteamento é mais recente que o contido no pedido. Se for, é enviado um RREP (Route Reply) para o nó de origem contendo a rota. Caso o nó não possua uma rota para o destino ou o número de sequência do pacote for o mais recente, este nó retransmite a mensagem. O RREP possui os seguintes campos:

< source_addr ; dest_addr ; destination_sequence_num ; hop_cnt ; lifetime >

Ao receber o pacote RREP, o nó adiciona o endereço do destino (dest_addr ), asso- ciando o nó que o enviou como gateway. Assim, ao ser enviada para o nó de origem (source_addr ), o RREP incrementa a quantidade de saltos (hop_cnt ) em cada nó que passar. É interessante ressaltar que ao contrário do RREQ, o RREP é enviado para o nó origem por apenas uma rota (ver Figura 2.2).

Se no processo de comunicação um nó intermediário desaparecer, será necessário que seja iniciada uma nova descoberta de rota. A detecção de quebra de comunicação com o nó é detectada utilizando mensagens hello periódicas. As mensagens são enviadas num intervalo de tempo regular pelo nó aos seus nós vizinhos envolvidos na transmissão. Desta forma, se um nó não receber o hello de um nó vizinho no devido período de tempo, assume- se que ocorreu uma quebra na comunicação e o nó realiza uma nova busca enviando um RREQ (Chakeres e Belding-Royer 2004).

Quando um nó intermediário descobre uma quebra de comunicação, de acordo com Chakeres (Chakeres e Belding-Royer 2004), este envia um pacote RERR (Route Error ) via broadcast para os nós vizinhos, envolvidos na comunicação, que retransmitem o RERR. Se o nó de origem ainda necessitar de uma rota até o destino, pode enviar um novo RREQ.

Um exemplo de uma busca por rota, pode ser visto na Figura 2.2, onde o nó N6 (origem) deseja iniciar uma comunicação com o nó N1, então é envido um RREQ (Figura 2.2a) para todos os nós da MANET, assim, quando o nó N1 é localizado, este envia um RREP (Figura 2.2b) atualizando as tabelas de roteamento do N2, N4 e N6. Após um determinado tempo, o N1 se move na rede, e passa a se conectar com o nó N7, portanto, quando o nó N2 verificar a quebra de comunicação, este enviará um RERR (Figura 2.2c)

Figura 2.2: Descoberta de rota do AODV na MANET, onde o nó N6 deseja iniciar uma comunicação com o nó N1

informando a quebra na rota, ocasionando numa nova busca por rota do nó N6 (Figura 2.2d). Pode-se observar que além do nó N1, os nós N3, N5 e N8 também se movimentaram.

Tabela 2.2: Tabela de roteamento do nó N6, antes do deslocamento do nó N1. Destino Gateway Saltos Número de Nós Vizinhos Tempo

(Métrica) sequência Ativos de Duração

N1 N4 3 S406_N1 N4 1000

Estas mudanças podem ser verificadas quando o nó N6 recebe a RREP e atualiza a sua tabela de roteamento (Tabela 2.2). Desta forma, o nó N6 incia a comunicação com o nó N1.

Tabela 2.3: Tabela de roteamento do nó N6, após o recebimento da RERR. Destino Gateway Saltos Número de Nós Vizinhos Tempo

(Métrica) sequência Ativos de Duração

N1 N4 ∞ S406_N1 N4 1000

Supondo que, após um tempo de transmissão, o nó N1 se movimente em direção ao nó N7, isto gera uma quebra de comunicação, detectada pelo nó N2, que envia um RERR alertando o nó N6. Este por sua vez, atualiza a tabela de roteamento, mudando o valor dos

saltos, para o nó N1, para ∞ (Tabela 2.3), necessitando do envio de um novo RREQ caso a comunicação com N1 não tenha sido finalizada. Assim, pode-se notar que na Tabela 2.4, o novo gateway para o nó N1, passa a ser o nó N7, associado ao novo número de sequência S512_N1.

Tabela 2.4: Nova tabela de roteamento do nó N6, após o deslocamento do nó N1. Destino Gateway Saltos Número de Nós Vizinhos Tempo

(Métrica) sequência Ativos de Duração

N1 N7 2 S512_N1 N4 1000

Na Tabela 2.5, observa-se que o nó N7 mantém os nós N1 e N6 na parte de vizinhos ativos, pois está servindo como nó intermediário na comunicação entre estes dois nós. N7 passa então a enviar periodicamente, mensagens hello para estes nós vizinhos, assim, é possível saber se ocorreu uma nova quebra na comunicação.

Tabela 2.5: Nova tabela de roteamento do nó N7.

Destino Gateway Saltos Número de Nós Vizinhos Tempo (Métrica) sequência Ativos de Duração N1 N1 1 S512_N1 N1, N6 1000 N6 N6 1 S204_N1 N1, N6 1000

Basicamente o AODV cria uma única rota até um determinado destino. Isso possibilita vantagens quanto ao consumo de memórias, mas em contra partida pode causar problemas ao se detectar uma quebra de comunicação envolvendo um ou mais nós da rede e assim pode-se ocasionar perdas de pacote, como também pode acabar fazendo com que um nó da rede fique responsável pelo encaminhamento de vários pacotes o tornando um possível ponto critico na rede.