Magal

Protocolos de Roteamento

http://www.teleco.com.br/imagens/tut...alprotocol.gif

Nesta seção serão abordados alguns protocolos utilizados para fazer o roteamento de redes ad hoc.

Eles foram classificados da seguinte forma:

Protocolos do tipo Table-Driven Routing Protocol (Pró-Ativos) e protocolos do tipo Source-Initiated On-Demand Routing (Reativos).

Table-Driven Routing Protocol (Proativo)

Este tipo de protocolo faz com que cada nó mantenha armazenado em memória uma ou mais tabelas de roteamento referente aos demais nós da rede. Para manter a consistência dos dados armazenados nestas tabelas são enviados pacotes de atualização pela rede. Exemplo de protocolos Table-Driven Routing Protocol são: Destination-Sequenced Distance-Vector Routing (DSDV), Clusterhead Gateway Switch Routing (CGSR), Wireless Routing Protocol (WRP),

DSDV - Destination-Sequenced Distance-Vector Routing

O protocolo de roteamento Destination-Sequenced Distance-Vector Routing [1-6], DSDV, é baseado no mecanismo de roteamento Bellman-Ford.

Neste protocolo todos os nós da rede possuem uma tabela de roteamento com o endereço do nó destino, com o numero de saltos (hop) necessários para se alcançar este destino e o número de seqüência do nó destino (sequence number - SN). Para diferenciar a existência de novas rotas com as já armazenadas na tabela é usado um número de seqüência, ou seja, cada nova entrada na tabela possui um novo SN.

As tabelas de roteamento são atualizadas periodicamente, para que assim possa se ter consistência dos dados nela armazenados.

As mensagens de atualização são transmitidas também, quando se percebe uma alteração no estado dos enlaces. Caso duas mensagens de atualização cheguem ao mesmo tempo em um nó, armazena-se a de maior SN e, no caso de mesmo SN escolhe-se a de menor numero de saltos.





Características:

• <LI class=textobase>Pró-ativo <LI class=textobase>Métrica: menor caminho <LI class=textobase>Eficiente para criação de rotas com poucos nós <LI class=textobase>Baseado no algoritmo Bellman-Ford
• Não há implementações comerciais

CGSR - Clusterhead Gateway Swtching Routing

O CGSR é um tipo de protocolo que trabalha com a segmentação da rede, dividindo-a em clusters (Fig. 1). Cada cluster da rede é formado por 1 cluster head, por gateway e pelos nós. Para eleger qual nó será eleito cluster head um algoritmo de escolha é distribuído pelo cluster.

Com este tipo de protocolo os pacotes devem obrigatoriamente passar pelo cluster head e este o direciona para um gateway que fará com que o pacote chegue até o nó destino em algum outro cluster. Uma desvantagem deste protocolo é que com a mobilidade dos nós o cluster head pode estar sempre sofrendo alterações. Isto faz com que atrasos ocorram no envio dos pacotes. O cluster head é alterado quando entra em contato com outro cluster head ou quando um nó perde o contato com todos os cluster heads da rede. O nó gateway é o nó que pode ser "enxergado" por dois ou mais cluster heads.

Cada nó da rede possui duas tabelas de armazenamento. Uma contém qual o cluster head para qualquer nó de destino e a outra, contém o próximo passo para alcançar o destino.





Características:

• <LI class=textobase>Pró-Ativo <LI class=textobase>Métrica: menor caminho <LI class=textobase>Nós divididos em clusters <LI class=textobase>Maior eficiência comparando-se ao DSDV <LI class=textobase>
  A eleição do cluster head gera complexidade e overhead
  
  
  
  
  
  
  
  http://www.teleco.com.br/imagens/tut...alprotocol.gif
  
  Fig. 1 - Formação dos clusters com o uso do protocolo CGSR
  
  
• Dificuldade em manter a mesma estrutura de clusters em redes de grande mobilidade

Source-Initiated On-Demand Routing (Reativo)

Este tipo de protocolo cria rotas apenas quando a fonte deseja enviar dados para um destino qualquer. Quando a rota fonte-destino é encontrada a fonte então passa a utilizá-la por um período de tempo, também conhecido como Time-to-Live (TTL).

Exemplos deste tipo de protocolo são: Ad Hoc On-Demand Distance Vector Routing (AODV), Dynamic Source Roting (DSR), Temporally Ordered Routing Algorithm (TORA), Associativity-Based Routing (ABR), Stability-based Adaptive (SSA).

AODV - Ad-hoc On-Demand Distance Vector

O Ad-hoc On-Demand Distance Vector (AODV)[2-6] tem como base o protocolo DSDV, mesmo tendo a característica de ser um protocolo do tipo Source-Initiated On-Demand Routing.

Utiliza o procedimento de descoberta de rotas baseado na origem.

Quando um nó deseja enviar dados para algum destino no qual ele não possua rota válida, inicia-se um processo de path discovery, ou descoberta de caminho (Fig. 2).

http://www.teleco.com.br/imagens/tut...alprotocol.gif
Fig. 2 - Criação de rota no protocolo AODV

O nó fonte envia então para seus vizinhos um pacote de route request (RREQ), estes por sua vez enviam para seus vizinhos e assim sucessivamente até que se chegue ao nó desejado ou a algum nó que possua uma rota recente para o nó destino.

Este protocolo utiliza o número de seqüência de destino (destination sequence number) para ter a certeza de que todas as rotas estão livres de loops (loop free) e que elas possuam as mais recentes informações sobre o destino.

Todo nó mantém seu próprio SN assim como um Broadcast ID que é incrementado sempre que um RREQ é realizado.

O pacote de RREQ contém além do seu SN e do Broadcast ID, o numero de seqüência de destino que ele possui em sua tabela, um broadcast identifier e o campo de time-to-live. Assim se um nó intermediário possui uma rota o destino ele apenas responderá ao RREQ se o SN destino for maior ou igual ao contido no RREQ.

Durante o processo de envio de RREQ um nó intermediário armazena em sua tabela de roteamento o endereço de seus vizinhos, estabelecendo assim um caminho reverso. Com isto se um RREQ chegar novamente a este nó (por outro caminho) ele será então descartado, prevalecendo assim o que chegou primeiro.

Assim que o pacote de RREQ atinge o seu destino, ou algum nó que possua uma rota recente para o destino, é enviado para a fonte via unicasting um pacote de route reply (RREP).

Quando uma rota é armazenada na tabela de roteamento é associada a ela um tempo de vida, ou seja, se esta rota não for utilizada neste período de tempo ela será excluída da tabela.

Caso ocorra a movimentação do nó fonte dentro da rede, ele estará apto a enviar um quadro de RREQ para descobrir uma nova rota para o destino. Já se um nó intermediário se move, ele deverá enviar a seus vizinhos uma notificação de quebra de link (RREP com métrica infinita) informando assim que esta parte da rota deve ser excluída. Seus vizinhos por sua vez propagam esta notificação de quebra de link até que nó fonte seja informado sobre a falha e assim possa enviar um novo RREQ.

Este protocolo pode ou não fazer uso do quadro de hello, que é enviado periodicamente de um nó para seus vinhos, informando e mantendo assim a sua conectividade local com os vinhos.





Características:

• <LI class=textobase>Reativo <LI class=textobase>Métrica: mais recente e menor caminho <LI class=textobase>Baseado no protocolo DSDV <LI class=textobase>Loop-free <LI class=textobase>Multicast opcional <LI class=textobase>Reduzido overhead comparado com protocolos Pró-ativos
• Alto delay causado pelo processo de descoberta de rota

DSR - Dynamic Source Routing

O Dynamic Source Routing [3-6] é um protocolo do tipo On-Demand Routing e usa um procedimento de descoberta de rotas baseado na origem.

Este protocolo possui duas fases, sendo elas, descoberta de rota (routing Discovery) e manutenção da rota (route maintenance).

Quando um nó fonte precisa enviar dados para algum destino ele consulta sua memória cache e verifica se possui uma rota válida para o destino (Fig. 3). Caso possua (rota não expirada) ele usará esta rota para fazer o envio dos dados. Caso contrario, um processo de descoberta de rota deverá ser inicializado com o envio de pacote de route request . O quadro de route request é formado pelo endereço de destino acompanhado com o endereço do nó fonte e um numero de identificação único. Cada nó que recebe este quadro faz uma verificação para saber se conhece a rota desejada. Caso não conheça, este nó acrescentará ao pacote de route request seu próprio endereço e o enviará a seus vizinhos e assim sucessivamente. Para limitar o número de route requests propagados um nó só retransmite este pacote se ele ainda não passou por este nó, ou seja se ele não contém o seu próprio numero de endereço.

http://www.teleco.com.br/imagens/tut...alprotocol.gif
Fig. 3 - Criação de rota no protocolo DSR

O route reply por sua vez, é enviado assim que se encontra o nó destino ou quando algum nó intermediário possui em sua cache uma rota não expirada para o destino desejado.

A manutenção das rotas é feita com o uso de pacotes de erro de rota e de reconhecimento.

Pacotes de erro de rota (route error) são gerados por um nó quando ocorre um erro fatal de transmissão. O salto (hop) em erro é então removido da cache e todas as rotas que possuem aquele salto ficarão travadas neste ponto.

Os quadros de reconhecimento (acknowledgments) são utilizados para verificar o correto funcionamento dos links.





Características:

• <LI class=textobase>Reativo <LI class=textobase>Métrica: menor caminho <LI class=textobase>Reduzido overhead de controle <LI class=textobase>Não há necessidade de mensagens hello. <LI class=textobase>Quebra de link é informado apenas para a fonte
• Eficiente para redes ad hoc com menos de 200 nós

TORA - Temporally Ordered Routing Algorithm

Temporally Ordered Routing Algorithm é baseado no conceito do link reverso[ 4-6 ]. Ele é proposto para ser utilizado em redes altamente dinâmicas, é do tipo source-initiated e possui múltiplas rotas para o mesmo par fonte/destino.

O TORA executa basicamente três funções, sendo elas, criação de rotas, manutenção de rotas e deleção de rotas.

http://www.teleco.com.br/imagens/tut...alprotocol.gif
Fig. 4 - Protocolo SSA - Route Request

No processo de criação a fonte envia um pacote solicitando a rota para o destino desejado. Este pacote se propaga pela rede até chegar ao destino ou até que algum nó intermediário possua uma rota válida. Assim que s rota for descoberta é enviado uma resposta para a fonte contendo a altura do nó destino, ou seja, quantos saltos (hops) são necessários para que a informação chegue até o seu destino.

O processo de manutenção de rotas ocorre quando se percebe uma quebra no link. O nó então faz uma verificação de rota e ajusta a sua altura para a nova configuração.

A deleção da rota ocorre ao se perceber uma fragmentação da rede. É informado assim a necessidade de se retirar estas rotas das tabelas.





Características:

• <LI class=textobase>Reativo <LI class=textobase>Métrica: menor caminho
• Baseado no protocolo LMR( Location Based Multicast )

SSA - Signal Stability-based Adaptive

O protocolo Signal Stability-based Adaptive [6] tenta descobrir rotas que possuam sinais mais fortes e uma maior estabilidade no posicionamento dos nós. Este protocolo faz uso do quadro chamado beacon tendo como analise do sinal do beacon a forma de se analisar a estabilidade entre os nós.

http://www.teleco.com.br/imagens/fig...alprotocol.gif
Fig. 5 - Protocolo SSA - Manutenção de Rota

As rotas referentes aos sinais de maior potência do beacon dos vizinhos são armazenados em uma tabela denominada signal stability table (SST). Os nós ficam constantemente atualizando sua tabela SST através da mensagem de beacon.

O maior objetivo do SSA é fazer uso de rotas que possuam alta conectividade.

No processo de criação de rota (Fig. 4) o nó fonte envia um route request (RREQ) pela rede (Isto é feito após a análise da estabilidade do link analisado pela mensagem de beacon). O nó intermediário que recebe o RREQ verifica se este chegou por uma rota estável ou instável. Neste ponto os pacotes que chegaram pelo caminho instável e os duplicados são retirados da rede. Se o pacote chegou por caminhos estáveis ele armazena o endereço do nó em sua tabela e então repassa o RREQ para o nó seguinte e assim sucessivamente até que se chegue ao nó destino, que envia um route reply pelo mesmo caminho.

No processo de manutenção da rota (Fig. 5), o nó de percebe a quebra de um link envia uma mensagem de notificação de quebra para a fonte e o destino.

A fonte então envia para a rede um RREQ e para localizar uma outra rota estável para o trafego das informações e apenas se isto não for possível, ou seja, se não houver mais links estáveis, os links instáveis serão utilizados.





Características:

• <LI class=textobase>Reativo <LI class=textobase>Métrica: estabilidade <LI class=textobase>Localiza rotas de maior estabilidade <LI class=textobase>Usa mensagens beacon <LI class=textobase>Quebra de links são localmente detectados mas não reparados
• RREQ recebidos por rotas instáveis são descartados.

Protocolos udp e tcp em redes ad-hoc


Nessa seção são abordados os protocolos TCP e UDP em redes ad-hoc. Inicialmente são analisadas as característica de ambos os protocolos nas redes TCP/IP convencionais. Após esse item serão detalhadas propostas de melhoramentos na camada de transporte para o aumento de performance nas transmissões em redes ad-hoc.

Visão geral dos protocolos udp e tcp em redes convencionais [ 7 ]

O Transmission Control Protocol (TCP) é, sem dúvidas, um dos mais importantes protocolos da família TCP/IP. É um padrão definido na RFC 793, " Transmission Control Protocol (TCP)", que fornece um serviço de entrega de pacotes confiável e orientado por conexão. Ser orientado por conexão, significa que todos os aplicativos baseados em TCP como protocolo de transporte, antes de iniciar a troca de dados, precisam estabelecer uma conexão. Na conexão são fornecidas, normalmente, informações de logon, as quais identificam o usuário que está tentando estabelecer uma conexão.
Algumas características do TCP são:

Garante a entrega de datagramas IP: Esta talvez seja a principal função do TCP, ou seja, garantir que os pacotes sejam entregues sem alterações, sem terem sido corrompidos e na ordem certa. O TCP tem uma série de mecanismos para garantir esta entrega.

Executa a segmentação e reagrupamento de grandes blocos de dados enviados pelos programas e garante o seqüenciamento adequado e entrega ordenada de dados segmentados: Esta característica refere-se a função de dividir grandes arquivos em pacotes menores e transmitir cada pacote separadamente. Os pacotes podem ser enviados por caminhos diferentes e chegar fora de ordem. O TCP tem mecanismos para garantir que, no destino, os pacotes sejam ordenados corretamente, antes de serem entregues ao programa de destino.

Verifica a integridade dos dados transmitidos usando cálculos de soma de verificação: O TCP faz verificações para garantir que os dados não foram alterados ou corrompidos durante o transporte entre a origem e o destino.

Envia mensagens positivas dependendo do recebimento bem-sucedido dos dados: No destino, o TCP recebe os pacotes, verifica se estão OK e, em caso afirmativo, envia uma mensagem para a origem (ACK), confirmando cada pacote que foi recebido corretamente

Controle de tráfego baseado no não recebimento de mensagens: quando uma seção deixa de receber as mensagens de confirmação dentro de um tempo pré-determinado, o protocolo entenderá essa situação como um congestionamento na rede. Por padrão, o TCP diminuirá a taxa de transmissão para o contorno do problema.

O User Datagram Protocol (UDP) é um padrão TCP/IP e está definido pela RFC 768. O UDP é usado por alguns programas em vez do TCP para o transporte rápido de dados entre hosts. Porém o UDP não fornece garantia de entrega, ordenação, controle de fluxo e controle de congestionamento. Essa solução pode parecer pouco ortodoxa, porém em determinadas situações é a melhor opção para a camada de transporte, principalmente pelo fato de o UDP ser muito mais rápido e gerar menos tráfego na rede, uma vez que não faz verificações e não estabelece sessões.

As funcionalidades fornecidas pelo TCP devem ser realizadas pela a camada de aplicação quando a mesma utiliza o UDP como protocolo de transporte e necessita desses cuidados. Dessa forma, nota-se que o UDP não trará implicações adicionais em redes ad-hoc, uma vez que este trabalha no modo melhor esforço não realizando mecanismos que poderiam ser prejudiciais em redes com essa característica.
Assim sendo, os próximos itens dessa seção abordarão duas possíveis modificações para o aumento de performance na camada de transporte, porém voltadas para o protocolo TCP.

O protocolo tcp em redes ad-hoc e possíveis modificações

Os efeitos de mobilidade de uma rede ad-hoc resultam em grande queda de performance quando o protocolo TCP é utilizado na camada de transporte [ 8 ], principalmente pela quebra de links, uma vez que o TCP não prevê essa situação (já que ela raramente acontece em redes fixas), sendo que o atraso na recepção das confirmações de recebimento das mensagens (ack) é sempre tratada como um congestionamento, e não como quebra de link . A seguir, algumas propostas para a melhora da performance são apresentadas.

Notificação explicita de falha de link [8]

Basicamente o ELFN (explicit link failure notification) objetiva prover para o TCP mensagens com informações sobre falhas em rotas para evitar assim que o TCP as trate como um congestionamento.

Existem muitos modos de realizar o ELFN, um método simples é enviar mensagens ICMP (internet control message protocol) de destino inalcançável. De forma alternativa, se o protocolo de roteamento já envia mensagens de falha de rota para o transmissor, essa pode carregar (piggy-backed) a informação de destino inalcançável (host unreachable).

No trabalho realizado em [8] foi utilizado o protocolo de roteamento DSR, sendo esse modificado para enviar no payload da mensagem de falha de rota a informação de host unreachable. Ao receber o pacote ICMP o transmissor TCP desabilita sua timer de retransmissão e entra no modo standby. Estando nesse estado, um pacote é enviado de forma periódica para testar a rede e checar se a rota foi restabelecida, assim, se um acknowledgment é recebido significa que a rede voltou a operar, saindo então do modo standby e voltando a transmitir normalmente. As figuras 6 e 7 mostram a performance da rede com e sem o método ELFN.

http://www.teleco.com.br/imagens/tut...alprotocol.gif

Fig. 6 - Throughput medido pelo esperado com TCP convencional. Sendo que no gráfico (a) a velocidade dos nós é 2 m/s, no (b) 10 m/s, no (c) 20 m/s e em (d) 30 m/s.

http://www.teleco.com.br/imagens/tut...alprotocol.gif
Fig. 7 - Throughput medido pelo esperado com TCP-ELFN. Sendo que no gráfico (a) a velocidade dos nós é 2 m/s, no (b) 10 m/s, no (c) 20 m/s e em (d) 30 m/s.

Detecção de mudanças nas rotas através da reordenação de mensagens

Em uma sessão ideal de TCP os pacotes enviados pelo transmissor devem chegar até o receptor na mesma seqüência de transmissão. Entretanto, existem dois casos em que essa ordem é quebrada. O primeiro caso ocorre quando há retransmissão devido a perda de quadros, sendo esse conhecido como evento fora de seqüência. O outro caso é quando os quadros chegam fora de ordem (OOO "out of order"). Isso ocorre quando um pacote enviado chega depois de seu subseqüente. A figura 8 ilustra o conceito da chegada fora de ordem.

http://www.teleco.com.br/imagens/tut...alprotocol.gif
Fig. 8 - Reordenação de pacotes devido a múltiplos caminhos

Reordenamento de mensagens freqüentemente ocorrem devido a mudanças no roteamento. Entretanto, esse efeito é (em geral) desprezado nas redes cabeadas, uma vez que mudanças no roteamento são raras, principalmente em períodos próximos ao tempo de vida de uma seção TCP. Já em redes ad-hoc esse pode ser um mecanismo muito prático para detectar as freqüentes mudanças nas rotas.

Detecção de eventos de reordenação[9]

Em uma sessão TCP a reordenação pode ocorrer nas duas direções. Assim, ambos devem ser analisados, como é visto adiante.

Transmissor detectando a reordenação

Todo pacote de ACK do TCP carrega o número de seqüência indicando a último byte recebido. Uma vez que não existem retransmissões de um pacote de ACK o número de seqüência desse jamais poderá ser menor do que a de um ACK o anterior. Essa propriedade facilita a detecção da reordenação, assim, se um transmissor recebe um ACK com número de seqüência menor que um recebido anteriormente, ele pode assumir que houve mudanças nas rotas.

Entretanto, existe um problema para os ACKs duplicados. Caso ocorra mudança na rota quando o receptor está enviando ACKs duplicados torna-se impossível detectar a reordenação, uma vez que são pacotes idênticos. Para se resolver isso deve ser adicionado um contador de pacotes duplicados nos campos adicionais do cabeçalho TCP (ADSN - duplication sequence number) que é um campo de um byte, permitindo a contagem de até 256 ACKs duplicados. Assim, mesmos os pacotes de ACKs duplicados tornam-se únicos através desse campo.

Receptor detectando a reordenação

O método de comparar a número de seqüência não é aplicado para detectar reordenamento nos pacotes recebidos, uma vez que podem ocorrer retransmissões. Desta forma torna-se necessário utilizar uma solução similar a realizada com os ACKs duplicados. Cria-se então um campo de 16 bits que será incrementado a cada pacote transmitido (TPSN - packet sequence number). Também é possível utilizar o campo opcional timestamp, existente no header TCP para algumas implementações.

Ações tomadas na detecção de reordenação

Quando detecta-se um evento de reordenação as seguintes ações devem ser tomadas: desabilitar o algoritmo de controle de congestionamento por um período denominado T1. Assim o transmissor manterá o seu estado constante, mantendo o tempo de retransmissão (RTO) e o tamanho da janela de congestionamento. Passado o tempo T1 analisa-se se os sintomas que caracterizam o congestionamento se mantém (como o vencimento de timeout e recebendo triplos de ACKs duplicados), se isso procede o controle de congestionamento deve ser ativado. Porém não se descarta a possibilidade de que ao invés de um congestionamento a rede está passando por mudanças nas rotas, desta forma, ao receber o primeiro ACK correto novamente o transmissor deve retornar com os valores de RTO e janela de congestionamento originais (anteriores ao acionamento do controle de congestionamento), ao invés de seguir com os algoritmos padrões do TCP, que tomariam um bom tempo até que a situação seja normalizada.

A figura 9 mostra o resultado da simulação que compara a performance do TCP padrão com o TCP modificado com essa proposta (TCP-DOOR) [ 9 ].

http://www.teleco.com.br/imagens/tut...alprotocol.gif
Fig. 9 - Comparação do TCP com o TCP-DOOR em

Performance do tcp sobre diversos protocolos de roteamento

Nesta sessão será analisada a performance do protocolo de transporte TCP sobre quatro tipos diferentes de protocolos de roteamento para redes ad-hoc, utilizando o simulador ns-2.[ 5 ]

Os protocolos de roteamento utilizados para a as simulações são: AODV (Ad-hoc On-demand Distance Vector), DSR (Dynamic Source Routing), DSDV (Destination Sequenced Distance Vector) e SSA (Signal Stability based Adaptive).

Para a análise foi utilizado um cenário de simulação contendo 25 nós se movendo em uma topologia retangular de 1500m x 300m, com cada nó possuindo antenas Omni-direcionais e alcance de transmissão de 250 m em um canal de transmissão de 2 Mbps. A simulação ocorre durante 200 segundos e foi usado o padrão IEEE 802.11.

Metodologia utilizada para as simulações

Durante as simulações, os nós se movem aleatoriamente de acordo com o modelo random waypoint. As simulações procedem da seguinte forma: No início da simulação, os nós são aleatoriamente posicionados e permanecem durante um certo tempo de espera. Vencido este tempo de espera, os nós são reposicionados aleatoriamente com uma velocidade média. No momento em que os nós alcançam suas novas posições, permanecem estáticos até vencer novamente o tempo de espera, repetindo este procedimento até o final da simulação.

As simulações ocorrem com velocidades médias de 2, 6, 10, 15 e 20 m/s e tempos de espera de 0, 10 e 20 segundos.

A métrica escolhida para a análise de performance foi à quantidade de dados transmitidos da fonte por unidade de tempo. Essa métrica é monitorada em função da velocidade média dos nós e do tempo de espera, avaliando a habilidade do protocolo de roteamento com a mobilidade dos nós.

Resultado das simulações

As figuras abaixo mostram a variação de throughput versus a velocidade média dos nós para tempos de espera de 0, 10 e 20 segundos. Como é possível ver, o throughput diminui com o aumento da velocidade média dos nós. O aumento da velocidade média resulta em uma elevada mobilidade e por conseqüência a freqüência de falhas de roteamento também aumenta. Devido a essas falhas no roteamento, o tráfego TCP sofre perda de pacotes que são interpretadas como congestionamento, resultando na diminuição da janela de transmissão. Além disso, a procura por novas rotas, causa atraso. Estes fenômenos por sua vez, resultam na degradação do throughput.

http://www.teleco.com.br/imagens/tut...alprotocol.gif
Fig. 10 - TCP Throughput versus Mean Speed; Pause Time = 0 sec

http://www.teleco.com.br/imagens/tut...alprotocol.gif
Fig. 11 - TCP Throughput versus Mean Speed; Pause Time = 10 sec

http://www.teleco.com.br/imagens/tut...alprotocol.gif
Fig. 12 - TCP Throughput versus Mean Speed; Pause Time = 20 sec

A performance do DSDV é a pior de todos os protocolos. Por ser um protocolo que transmite periodicamente mensagens de manutenção de rotas, para um cenário como este, que a mudança de rota é freqüente e aumenta com o aumento da velocidade média dos nós, a adaptação ao mesmo exige um grande overhead de roteamento, degradando o throughput.

O protocolo DSR na prática não causa overhead quando os nós se movimentam em baixa velocidade, pois é um protocolo on-demand e também não há uma troca periódica entre os nós. Assim, o DSR possui a melhor performance em baixa velocidade entre os protocolos. Já com os nós se movendo em alta velocidade, as rotas no cache de roteamento tornam-se inválidas muito rapidamente e rotas erradas podem ser formadas quando a fonte inicia o processo de busca por novas rotas. O DSR também não possui o conceito de Sequence Numbers e então rotas não recentes podem levar a formação de loop. Estes fatos podem ocasionar a degradação do throughput quando os nós se movimentam mais rapidamente.

No caso do protocolo AODV, o gerenciamento do cache de roteamento assegura que apenas rotas ativas sejam mantidas, prevenindo assim o problema de rotas inválidas. O AODV, ao contrário do DSR, utiliza Sequence Numbers para a prevenção de loop e como critério para a seleção das rotas mais recentes. Assim, a degradação do throughput com o aumento de movimentação entre os nós é menos acentuado.

O estabelecimento de rotas no protocolo SSA é baseado na estabilidade das mesmas, então a escolha por rotas ruins são menos freqüentes neste protocolo. Devido a isto, o SSA consegue uma melhor performance que os demais protocolos, que não possuem estabilidade de rotas quando os nós se movimentam em alta velocidade. Já o protocolo não tem uma boa performance quando os nós se movimentam em baixa velocidade, pois mensagens de hello constituem em um adicional overhead.

Conclusão

Muitas pesquisas são realizadas hoje em redes ad-hoc, uma vez que essas demandam preocupações específicas em diversos fatores. Nesse trabalho foram abordadas algumas dessas questões, sendo focadas em protocolos de roteamento e de transporte. Com relação a camada de rede (roteamento) conclui-se que é certa a necessidade da utilização de protocolos específicos para redes ad-hoc, que se adaptam as condições de cada aplicação, como por exemplo: topologia, mobilidade, consumo de energia, entre outras. Na camada de transporte concluí-se que é possível a utilização dos protocolos padrões da camada TCP/IP, porém modificação tornam-se necessárias para se obter uma performance satisfatória. Vale ressaltar que a necessidade da utilização destes protocolos na camada de transporte é fundamental para se manter a compatibilidade de comunicação entre as redes ad-hoc com as demais redes (principalmente com a utilização do protocolo TCP), uma vez que é na camada de transporte que se realiza a comunicação fim a fim entre hosts.

Igualmente para as demais questões já citadas, como topologia e mobilidade, o protocolo da camada de transporte é um fator a ser levado em consideração para a escolha do protocolo de roteamento. Porém essa não é uma analise simples de ser realizada, uma vez que outros fatores se correlacionam com o fato de se usar o TCP.

Com relação ao protocolo UDP, conclui-se que ele não causa perdas de performance nas redes ad-hoc, uma vez que este é extremamente simples. Entretanto são poucas as aplicações que utilizam o UDP puramente, uma vez que as funcionalidades providas pelo TCP são de extrema importância para a comunicação peer to peer.






Referências

• <LI class=textobase>C. E. Perkins e P. Bhagwat, " DSDV Routing over a Multihop Wireless Network of Mobile Computers," Perkins-47190, 2000, pp. 53-74. <LI class=textobase>C. E. Perkins e E. M. Royer, " Ad-hoc On-Demand Distance Vector Routing," Proc. 2 nd IEEE Wksp. Mobile Comp. Sys. And Apps., Feb. 1999, pp. 90-100. <LI class=textobase>D. B. Johnson e D. A. Maltz, " Dynamic Source Routing in Ad hoc Wireless Networks," mobile Computing, T. Imielisnsk e H. Korth, Eds., kluwer, 1996, pp. 153-81. <LI class=textobase>V. D. Park e M. S. Corson, " A Highly Adaptative Distributed Routing Algorithm for Móbile Wireless Networks," Proc. INFOCOM ´97, Apr. 1997. <LI class=textobase>A. Ahuja, S. Agarwal, J. P. Singh, R. Shorey, " Performance of TCP over Different Routing Protocols in Mobile Ad-Hoc Networks," <LI class=textobase>C. S. R. Murthy e B. S. Manoj, "Ad Hoc Wireless Networks - Architectures and Protocols," Prentice Hall PTR, New Jersey, 2004. <LI class=textobase>Tanenbaum S. Andrew, "Redes de Computadores", 4ª edição <LI class=textobase>GAVIN HOLLAND and NITIN VAIDYA, "Analysis of TCP Performance over Mobile Ad Hoc Networks"
• Karthikeyan Sundaresan,Vaidyanathan Anantharaman,Hung-Yun Hsieh and Raghupathy Sivakumar, " ATP: A Reliable Transport Protocol for Ad-hoc Networks"

Fonte: Teleco