Implementação do protocolo AODVjr no simulador NS2

(1)

Celso Brito Nº25074 1/16 Renato Santos Nº24143

(2)

1. Índice:

1. Índice: ...2

2. Introdução: ...3

3. Software utilizado foi Network Simulator 2: ...4

4. Protocolo AODV:...5

4.1 O que é? ...5

4.2 Tipo de rede em que é utilizado o protocolo AODV ...5

5. Protocolo implementado AODVjr:...6

5.1 O que é? ...6

5.2 O que foi realizado: ...8

5.3. Simulações realizadas entre AODV e AODVjr:...10

6. Conclusões: ...15

(3)

2. Introdução:

Este mini-projecto desenvolvido no âmbito da disciplina de Computação Móvel tem como objectivo implementar um novo protocolo, de modo a ser executado no NS-2(Network Simulator 2) e interpretar os resultados da simulação, para isso temos que observar o log (trace) gerado da simulação. Para quem não sabe o Network Simulator 2 (NS) [1] é o simulador de redes mais popular no meio académico e nas grandes empresas de telecomunicações, permitindo criar todo o tipo de topologia de rede e analisar qualquer protocolo. Dos vários temas propostos pelo docente da disciplina optamos pelo tema “Routing in Ad-Hoc Nets”, dai termos encontrado um protocolo de extensão do protocolo de routing AODV.

O protocolo que vamos implementar é o AODVjr, passo então a explicar que o protocolo AODVjr é uma implementação simplificada do protocolo AODV já existente no NS-2. O protocolo AODV – Ad-hoc On-Demand Distance Vector é um protocolo de routing que funciona para redes Ad-Hoc.

(4)

3. Software utilizado foi Network Simulator 2:

The Network Simulator 2, ou simplesmente NS-2, é um simulador para pesquisas na área de redes. Sua concepção é baseada no conceito de “simulação discreta”, o que equivale a dizer que a simulação utiliza uma sequência de eventos para controlar o comportamento do modelo. O NS-2 é um poderoso simulador que oferece recursos para simulações de TCP, routing, protocolos multicast sobre redes com e sem fios. O projecto NS começou em 1989, com como uma variação do REAL network simulator e hoje em dia é um projecto com vida própria, mantido por programadores de diversos lugares do mundo. O NS-2 é escrito nas linguagens C++ e Object Tcl (chamado OTcl).

O NS-2 possui um vasto conjunto de directórios sendo eles mostrados na figura 2:

Figura 2 – Directórios NS-2

A versão do NS-2 instalada para a implementação do protocolo AODVjr foi o pacote <ns-allinone-2.31>, ou seja o ns-2.31.

O ns-allinone é um pacote que contém alguns componentes opcionais usados no NS. O pacote contém um script “install” que automaticamente configura, instala, e compila todos esses componentes. A lista de componentes contidos no pacote é:

• Tcl release 8.4.14 (required component) • Tk release 8.4.14 (required component) • Otcl release 1.13 (required component) • TclCL release 1.19 (required component) • Ns release 2.31 (required component) • Nam release 1.13 (optional component) • Xgraph version 12 (optional component) • CWeb version 3.4g (optional component)

• SGB version 1.0 (?) (optional component, builds sgblib for all UNIX type platforms) • Gt-itm gt-itm and sgb2ns 1.1 (optional component)

• Zlib version 1.2.3 (optional, but required should Nam be used)

Para suportar as redes móveis ad-hoc o ns implementa quatro protocolos de routing: DSDV, DSR, AODV e TORA. Para a sub camada MAC existem duas opções: IEEE 802.11 ou TDMA. Enquanto que na camada de transporte estão definidos os protocolos TCP e UDP. É possível definir para um nó móvel o tipo de antena (p. ex., omnidireccional), e o esquema de energia, assim como o alcance do seu sinal de rádio, para delimitar os seus vizinhos. O

(5)

endereçamento pode ser de três tipos: flat, hierárquico ou expandido. Os nós móveis são dispostos, através de coordenadas cartesianas, num espaço tridimensional delimitado e gradeado, sendo que a resolução da grade pode ser ajustada. Para movimentar o nó móvel neste espaço é informado as coordenadas de destino e a velocidade com que o nó móvel se deve mover até este destino.

4. Protocolo AODV:

4.1 O que é?

AODV - Ad-hoc On-Demand Distance Vector é um protocolo de encaminhamento (routing) e destina-se a ser usado por nós móveis nas redes Ad-Hoc. O seu princípio de funcionamento baseia-se no estabelecimento de rotas a pedido (apenas quando a rota é necessária). Quando uma rota de um nó para um destino se torna necessária, esse nó deverá fazer broadcast de uma mensagem de Route Request (RREQ) para esse destino. Cada nó que receba o RREQ deverá fazer forward da mensagem ou então responder ao pedido de rota (envio de um Route Reply (RREP)) desde que seja o destino, ou desde que seja um nó intermédio que possua uma rota para esse destino, e que obedeça a uma série de regras. De notar ainda que cada nó envia periodicamente mensagens de Hello para os seus vizinhos de modo a verificar se as ligações se mantêm ou não, mantendo assim a sua tabela de routing actualizada.

O AODV possui algumas grandes características: • Construído para redes móveis;

• Cria uma rota a pedido;

• Sem ciclos e com rápida convergência;

• Ajusta-se facilmente à pilha protocolar existente;

4.2 Tipo de rede em que é utilizado o protocolo AODV

O tipo de rede em que é utilizado o protocolo AODV é nas redes Hoc. O modo Ad-Hoc é um tipo de topologia básica (Independent Basic Service Set - IBSS), assim os terminais remotos fazem trocas de dados sem necessidade de um access point (AP).O tipo de rede que utiliza um Access point para as estações se comunicarem chama-se rede infra-estrutura.

(6)

As redes móveis Ad-Hoc são tecnologias de comunicação Sem-Fios, onde os dispositivos computacionais móveis são capazes de trocar informação directamente entre si sem a necessidade de uma infra-estrutura de comunicação.

Figura 4 – Rede Ad-Hoc.

5. Protocolo implementado AODVjr:

5.1 O que é?

O AODVjr - Ad-hoc On-Demand Distance Vector junior é uma simplificação do protocolo AODV, logo o objectivo da implementação deste protocolo é a simplicidade. Ao contrário do AODV, este não requer:

• Mensagens RERR; • Números de sequência;

• Listas de predecessores ou lista de nós já percorridos; • RERP Gratuitous;

• Contagem de saltos; • Mensagens de HELLO;

No protocolo AODVjr é removido tudo o que é desnecessário, deixando apenas os elementos essenciais do AODV.

Para realizar o protocolo AODVjr requer uma operação ligeiramente diferente, quando comparado com o AODV. Remover os números de sequência requer que o destino responda ao RREQ porque com o AODV qualquer nó poderia responder caso tivesse rota para o destino na sua tabela de routing e com o AODVjr só o destino responde (ver na figura 5 a comparação). Isto também elimina a necessidade de RREP injustificados, uma vez que todas as rotas serão bidireccionais. Desde que o destino responda apenas ao primeiro RREQ recebe a “melhor” (a mais rápida) rota sendo sempre escolhida, não olhando ao numero de saltos.

(7)

Figura 5 – Comparação na descoberta de rotas entre AODVjr e AODV.

Para executar a manutenção de uma rota, o ciclo de vida da rota é apenas actualizado pela recepção dos pacotes e não no envio dos pacotes. Isto exige que o destino ocasionalmente envie um pacote para a fonte. Se o tráfego dos dados é unidireccional, são enviadas mensagens periódicas (connect message), para manter a rota enquanto que no AODV são utilizadas as mensagens de Hello já faladas (ver na figura 6 a comparação).

Figura 6 – Comparação na manutenção de rotas entre AODVjr e AODV.

Se as comunicações de dados forem bidireccionais não é necessário um overhead complementar utilizando esta estratégia end-to-end, as mensagens hello, RERR e as listas de nós já percorridos deixam de ser necessárias. Quando ocorre uma quebra na rota, a fonte deixará de receber mensagens do destino. Na figura 7 podemos observar a diferença entre o AODVjr e o AODV quando o nó 4 abandona a rota. No AODVjr, depois de um período de tempo o nó 1, detecta a quebra da rota porque não recebeu a mensagem do destino e irá reiniciar a descoberta da rota, se a rota ainda for necessária. Já no AODV, o nó 3 detecta a quebra de ligação e envia uma mensagem RERR de volta.

(8)

Figura 7 – Comparação na detecção de quebras de rotas entre AODVjr e AODV.

5.2 O que foi realizado:

No desenvolvimento deste protocolo foram implementados em C++ os seguintes ficheiros: • aodvjr.cc • aodvjr.h • aodvjr_packet.cc • aodvjr_packet.h • aodvjr_rqueue.cc • aodvjr_rqueue.h • aodvjr_rtable.cc • aodvjr_rtable.h

Estes ficheiros são semelhantes aos ficheiros do protocolo AODV, com a diferença de que foram retiradas as funcionalidades não essenciais explicadas no ponto anterior, ou seja, mensagens RERR, números de sequência, lista de predecessores, gratuitous RREP, contagem de saltos e mensagens Hello.

Depois tivemos que realizar várias alterações a outros ficheiros do ns2 de modo a integrar o nosso código no simulador. Cada uma dessas alterações é ilustrada a seguir:

Ficheiro common/packet.h: enum packet_t {

PT_TCP, PT_UDP, T_CBR,

/* ... much more packet types ... */ PT_AODVJR,

PT_NTYPE // This MUST be the LAST one };

/*... */ p_info() {

(9)

name_[PT_UDP]= "udp"; name_[PT_CBR]= "cbr"; /* ... much more names ... */

name_[PT_AODVJR]= "AODVJR"; }

Ficheiro trace/cmu-trace.h: class CMUTrace : public Trace {

/* ... definitions ... */ private:

/* ... */

void format_aodv(Packet *p, int offset); void format_aodvjr(Packet *p, int offset); };

Ficheiro trace/cmu-trace.cc: #include <aodvjr/aodvjr_packet.h> /* ... */

void

CMUTrace::format_aodvjr(Packet *p, int offset)

(por esta função ser algo extensa colocamos aqui apenas o cabeçalho) /* ... */

void

CMUTrace::format(Packet* p, const char *why) { /* ... */ case PT_PING: break; case PT_AODVJR: format_aodvjr(p, offset); break; default: /* ... */ } Ficheiro tcl/lib/ns-packet.tcl: foreach prot { /* ... */

# Mobility, Ad-Hoc Networks, Sensor Nets: AODV # routing protocol for ad-hoc networks AODVJR # simplified AODV

/* ... */ } {

add-packet-header $prot }

(10)

Ficheiro tcl/lib/ns-default.tcl: (no fim do ficheiro)

# Defaults defined for aodvjr

Agent/AODVJR set accessible_var_ true Ficheiro tcl/lib/ns-lib.tcl:

Simulator instproc create-wireless-node args { # ...

switch -exact $routingAgent_ { # ...

AODVJR {

set ragent [$self create-aodvjr-agent $node] }

# ... } # ... }

Simulator instproc create-aodvjr-agent { node } { # Create AODVJR routing agent

set ragent [new Agent/AODVJR [$node node-addr]] $self at 0.0 "$ragent start";

$node set ragent_ $ragent return $ragent } Ficheiro queue/priqueue.cc: void PriQueue::recv(Packet *p, Handler *h) { /* ... */ case PT_AODV: case PT_AODVJR: recvHighPriority(p, h); break; default: Queue::recv(p, h); } } else { Queue::recv(p, h); } }

5.3. Simulações realizadas para o protocolo AODV:

Após não termos conseguido implementar o protocolo de routing AODVjr com sucesso, assim não poderemos fazer a comparação entre os dois protocolos, o AODVjr e o AODV. No entanto resolvemos realizar simulações com vários cenários distintos apenas para o protocolo AODV.

(11)

Fizemos um script TCL para correr no NS de modo a criar alguns ficheiros com informação sobre a simulação, sendo esses ficheiros o “out.nam” que serve para ser executado no Network Animator como visualizador da simulação testada, depois temos o ficheiro “out.tr” que é um ficheiro de trace, e por fim temos dois ficheiros criados, o “packets_lost.tr” e “packets_received.tr”, onde o primeiro contém informação dos pacotes perdidos e o último dos pacotes recebidos. A informação que estes dois últimos pacotes contêm encontra-se em duas colunas, sendo os pacotes perdidos em cada instante de tempo, estes ficheiro serão utilizados para fazer os gráficos, onde teremos duas linhas, uma correspondente aos pacotes perdidos e outra aos recebidos.

Passemos então de demonstrar as nossas simulações realizadas: • Simulação do protocolo AODV para 6 nós

O cenário de simulação é o seguinte: Número de nós: 6

Topologia: Fonte - no1 - no2 - no3 - no4 - Destino Terreno: 900 X 900

Tempo da simulação: 5 segundos

Os nós iniciam todos na posição 0.0 e até ao primeiro segundo (1.0) vão todos tomar as suas posições: Nó 0: 100.0, 300.0 Nó 1: 250.0, 150.0 Nó 2: 250.0, 450.0 Nó 3: 500.0, 150.0 Nó 4: 500.0, 450.0 Nó 5: 700.0, 300.0

Todos com uma velocidade de 3000.0

Ao nó 0 associa-se um agente UDP (fonte de tráfego CBR) que é 'ligado' a um agente Null associado ao nó 5.

(12)

Com este cenário verifica-se na simulação que depois dos envios do RREQ e recepção dos RREP, a comunicação entre o nó fonte e o nó destino é feita através do caminho no0-no1-no3-no5. Passados 2 segundos, o no5 desloca-se para as coordenadas (600.0, 500.0) ficando fora do alcance do no3. Aí é necessário calcular nova rota, a qual irá ter o caminho fonte-n02-no4-destino. Essa mudança é visível no gráfico onde se verifica uma maior perda de pacotes a seguir aos 2 segundos.

• Simulação do protocolo AODV para 3 nós O cenário de simulação é o seguinte:

Número de nós: 3

Topologia: Fonte - no1 - Destino Terreno: 800 X 800

Os nós iniciam todos na posição 0.0 e até ao primeiro segundo (1.0) vão todos tomar as suas posições:

Nó 0: 100.0, 100.0 Nó 1: 200.0, 200.0 Nó 2: 600.0, 400.0

Gráfico 2 – Relação entre os pacotes perdidos/recebidos para rede de 3 nós.

Este é um cenário para uma rede com apenas três nós mas não menos complexa. Aos 0.5 segundos são iniciadas duas tentativas de comunicações, uma do no0 para ao no2 e outra do no2 para o no1. Mas como neste momento o no2 está fora do alcance dos outros nós não é possível estabelecer qualquer ligação. Ao 1 segundo, o no2 desloca-se para as coordenadas (200.0, 370.0) ficando assim ao alcance do no1. Pouco depois

(13)

são efectuadas ambas as comunicações com caminhos no0-no1-no2 e no2-no1. No gráfico verifica-se que nesta altura há uma grande quantidade de pacotes perdidos provavelmente devido a colisões entre as duas comunicações. Passado 4.5 segundos a comunicação do no2 para o no1 pára e verifica-se que continua a haver perda de pacotes mas em muito menor quantidade.

Número de nós: 10

Topologia: Fonte - no1 - no2 - no3 - no4 - no5 - no6 - no7 - no8 - Destino Terreno: 900 X 900

Os nós iniciam todos na posição 0.0 e até ao primeiro segundo (1.0) vão todos tomar as suas posições: Nó 0: 100.0, 100.0 Nó 1: 200.0, 200.0 Nó 2: 300.0, 200.0 Nó 3: 400.0, 300.0 Nó 4: 500.0, 300.0 Nó 5: 600.0, 400.0 Nó 6: 500.0, 500.0 Nó 7: 700.0, 500.0 Nó 8: 600.0, 600.0 Nó 9: 800.0, 700.0

(14)

Com este cenário tentámos criar uma rede um pouco mais complexa, com uma maior quantidade de nós dispersos pelo terreno. Verificou-se então que entre muitas rotas possíveis a melhor encontrada foi através do caminho no0-no2-no4-no6-no9. Passados 2 segundos, o no9 (destino) desloca-se para as coordenadas (400.0, 400.0) ficando mais perto do no0 (fonte). No entanto como o no9 em momento algum ficou fora do alcance do no6 a rota inicial não foi alterada ainda que fosse possível calcular outra rota mais curta. O gráfico mostra uma pequena perda de pacotes quando é iniciada a ligação, mantendo-se estável durante algum tempo e volta-se a verificar perdas de pacotes enquanto o no9 se desloca e mesmo depois de se fixar nas coordenadas (400.0, 400.0).

Número de nós: 6

Topologia: Fonte - no1 - no2 - no3 - no4 - Destino Terreno: 800 X 800

Os nós iniciam todos na posição 0.0 e até ao primeiro segundo (1.0) vão todos tomar as suas posições: Nós 0: 100.0 100.0 Nós 1: 200.0 200.0 Nós 2: 300.0 200.0 Nós 3: 400.0 300.0 Nós 4: 500.0 300.0 Nós 5: 600.0 400.0

(15)

Nesta simulação a comunicação começa ao 1 segundo, notando-se aí uma perda de pacotes muito pequena, provavelmente enquanto era procurada a melhor rota. A rota então encontrada foi através do caminho no0-no1-no3-no5. Após mais 2 segundos, o no5 desloca-se até às coordenadas (100.0, 400.0) e dá-se nessa altura nova perda de pacotes. Com essa deslocação o no5 fica fora do alcance do no3 e por isso é calculada uma nova rota que terá o caminho no0-no1-no5. No entanto, como o no5 está algo distante do no1, tendo provavelmente um sinal fraco, verifica-se no gráfico algumas consideráveis perdas de pacotes alternando com pequenas estabilizações.

6. Conclusões:

Depois das simulações realizadas com o protocolo AODV podemos constatar que este protocolo permite o roteamento dinâmico entre nós móveis que compõe uma rede ad hoc. O AODV possibilita a cada nó obter rotas para novos destinos e não requer que os nós mantenham rotas para destinos que não estejam participando de nenhuma comunicação. O protocolo ainda permite que os nós propaguem notificações de quebra de enlaces e de mudanças na topologia da rede aos nós afectados.

Com base nas referencias pesquisadas podemos verificar que o protocolo AODVjr tem praticamente o mesmo desempenho que o AODV. Isto origina um estudo do protocolo do AODV, mas como muitos protocolos semânticos proporcionam um reduzido acréscimo de benefícios, de acordo com as condições verificadas neste trabalho. No entanto devido ao erro já anteriormente citado não nos foi possível comprovar esse facto.

O AODVjr poderia facilmente ser ampliado para integrar as condições padrão no AODV, por exemplo os números sequenciais, RERR, link layer feedback.

Outro aspecto significante do AODVjr é o controlo dos pacotes, contendo uma invariabilidade dos campos, permitindo assim uma maior segurança.

Uma qualidade do AODVjr é a sua simplicidade. Pelo que lemos podemos dizer que o AODVjr levará menos de metade do tempo para programar e fazer o debug quando comparado com uma completa implementação do AODV.

7. Referências:

[1] Ian D. Chakeres e Luke Klein-Berndt, “AODVjr, AODV Simplified”,

http://moment.cs.ucsb.edu/pub/aodvjr.pdf.

[2] AODV, http://www.cs.ucsb.edu/~ebelding/txt/aodv.ps [3] The Network Simulator - ns-2, http://www.isi.edu/nsnam/ns [4] The ns Manual, http://www.isi.edu/nsnam/ns/doc/index.html

[5] Tutorial for the Network Simulator “ns”, http://www.isi.edu/nsnam/ns/tutorial/

[6] Ad hoc On-Demand Distance Vector (AODV) Routing, http://tools.ietf.org/html/rfc3561 [7] AODV, http://moment.cs.ucsb.edu/AODV/aodv.html

(16)

[8] “AODVjr A simplified Version of AODV”, http://moment.cs.ucsb.edu/pub/aodvjr_slides.pdf

[9] AODV, http://dasan.sejong.ac.kr/~ygkwon/ADOV.ppt

[10] “Implementing a New Manet Unicast Routing Protocol in ns2” http://masimum.dif.um.es/?Documents