BRUNO NIETO - biblioteca.unilasalle.edu.br · movimentar de maneira independente, modificando a topologia da rede sem prévio aviso, tornando o roteamento um grande desafio. Sabe-se

BRUNO NIETO

ANÁLISE DE DESEMPENHO DO PROTOCOLO M-DART UTILIZAND O FLAVORS TCP

CANOAS, 2012

BRUNO NIETO


Trabalho de Conclusão apresentado à banca examinadora do Curso de Ciência da Computação do Centro Universitário La Salle - Unilasalle, como exigência parcial para a obtenção do grau de Bacharel em Ciência da Computação.

Orientação: Profª. Mª. Andrea Collin Krob

CANOAS, 2012

BRUNO NIETO


Trabalho de Conclusão aprovado como requisito parcial para a obtenção do grau de Bacharel em Ciência da Computação pelo Centro Universitário La Salle - Unilasalle.

Aprovado pela banca examinadora em 5 de julho de 2012.

BANCA EXAMINADORA:

________________________________________

Prof. M.e. Gustavo Passos Tourinho

Unilasalle

________________________________________

Prof. M.e Rafael Kunst

Unilasalle

Dedico este trabalho de conclusão aos meus pais, eternos e incansáveis incentivadores, pelo apoio prestado em todos os momentos de minha vida e principalmente nesta jornada acadêmica.

AGRADECIMENTOS

A DEUS

Pela saúde e oportunidade de estar realizando mais este sonho.

AOS MEUS PAIS

Laudeci e Maria Salete, pela força e incentivo em todos os momentos da minha vida,

principalmente nos momentos em que tudo parecia perdido, dando-me uma palavra de

conforto, carinho e coragem para enfrentar as dificuldades, buscando meus objetivos.

A MINHA IRMÃ

Letícia, pelo exemplo de dedicação aos estudos e fiel companhia para todos os

momentos.

A MINHA NAMORADA

Josiani, grande amor da minha vida, que soube ter paciência e compreensão em todas

as etapas difíceis desta jornada, mostrando-se uma verdadeira companheira.

AOS MESTRES

Pela dedicação e companheirismo durante esta jornada acadêmica, sempre mostrando

serem grandes profissionais e acima de tudo grandes amigos. Agradeço em especial a

professora Andrea Krob, grande profissional e amiga, pela disposição, apoio e contribuição

fundamental para a realização deste trabalho.

A EMPRESA

NBC Bank Brasil, que abriu as portas para que eu pudesse exercer na prática o que

havia aprendido nesta jornada acadêmica, e pela compreensão e tolerância com minhas

ausências, especialmente durante o desenvolvimento deste trabalho.

AOS AMIGOS E COLEGAS

Que me acompanharam durante toda a jornada acadêmica, tanto em momentos difíceis

como de descontração.

RESUMO

As redes ad hoc fazem parte da família das redes sem fio, onde cada dispositivo passa a ser

um roteador, realizando a interligação de nós móveis e fazendo com que os mesmos se

comuniquem entre si. Elas são redes sem fio sem infraestrutura, ou seja, os nós podem se

movimentar de maneira independente, modificando a topologia da rede sem prévio aviso,

tornando o roteamento um grande desafio. Sabe-se que esse tipo de rede apresenta um menor

desempenho em relação às redes convencionais, pois se tratando de redes sem fio torna-se

mais suscetível a interferências e a falhas, devido a diversos fatores (internos e externos) que

podem ocasionar este problema. Com o intuito de estudar o funcionamento destas redes e

descobrir um cenário que obtenha resultados satisfatórios em relação ao desempenho da rede,

este trabalho visa abordar o protocolo de roteamento M-DART, comparando quatro tipos de

flavors do protocolo de transporte TCP (Tahoe, New Reno, Vegas e Sack), através de três

métricas de desempenho (perda, vazão e atraso). Uma forte motivação para o estudo do

protocolo M-DART é o recente período de seu desenvolvimento (CALEFFI; PAURA, 2011).

Segundo Caleffi e Paura (2011) o protocolo M-DART foi comparado com outros protocolos,

garantindo o melhor desempenho entre os mesmos. Devido ao problema de roteamento dos

dispositivos móveis durante o processo de descoberta dos nós e transmissão dos dados o

protocolo M-DART propõe, através de seu funcionamento, melhores resultados em relação

aos demais protocolos de roteamento. Os resultados obtidos neste trabalho foram baseados

nas métricas escolhidas, sendo que o estudo não teve foco nas transmissões multimídia,

salientando a importância de analisar a aplicação em questão com o desempenho de cada

flavor.

Palavras Chave: Flavors TCP. Protocolo M-DART. Protocolos de Roteamento. Redes Ad

Hoc. Redes Sem Fio.

ABSTRACT

Ad hoc networks are part of the family of wireless networks, where each device becomes a

router, making the interconnection of mobile nodes and making them communicate with each

other. They are wireless networks without infrastructure, in other words, nodes can move

independently, modifying the network topology without notice, making routing a major

challenge. It is known that this type of network has a lower performance than the

conventional networks because it comes to wireless networks becomes more susceptible to

interference and failures due to various factors (internal and external) that can cause this

problem. In order to study the functioning of these networks and find a scenario to obtain

satisfactory results regarding the performance of the network, this paper aims to address the

routing protocol M-DART, using four different types of flavors of transport protocol (TCP

Tahoe, New Reno, Vegas and Sack), using three performance metrics (loss, throughput and

delay). A strong motivation for the study protocol M-DART is the recent period of

development (CALEFFI; PAURA, 2011). According Caleffi and Paura (2011) M-DART

protocol was compared with other protocols, guaranteeing the best performance among them.

Due to the routing problem of mobile devices during the discovery process of the nodes and

data transmission protocol M-DART proposes, through its operation, better results compared

to other routing protocols. The results of this study were chosen based on metrics, and the

study did not focus on multimedia streams, stressing the importance of analyzing the

application concerned with the performance of each flavor.

Keywords: TCP Flavors. Protocol M-DART. Routing Protocols. Ad Hoc Networks. Wireless

Networks

LISTA DE ILUSTRAÇÕES

Figura 1 – Exemplo de comunicação em uma rede Ad Hoc ..................................................... 16

Figura 2 – Divisão dos Protocolos de Roteamento para redes Ad Hoc .................................... 18

Figura 3 – Endereços de rede em formato de árvore ................................................................ 20

Figura 4 – Comportamento mediante as rotas falsas (DART) ................................................. 21

Figura 5 – Comp. M-DART (rotas falsas) ................................................................................ 22

Figura 6 – Exemplo de Topologia ............................................................................................ 22

Figura 7 – Comportamento do TCP Tahoe .............................................................................. 26

Figura 8 – Comportamento do TCP New Reno ....................................................................... 27

Figura 9 – Exemplo de arquivo trace ....................................................................................... 33

Figura 10 – Ilustração do Cenário – 10 nós .............................................................................. 35

Figura 11 – Relação de Pacotes Perdidos – 10 nós .................................................................. 38

Figura 12 – Percentual de Perdas – 10 nós ............................................................................... 38

Figura 13 – Relação de Pacotes Perdidos – 50 nós .................................................................. 39

Figura 14 – Percentual de Perdas – 50 nós ............................................................................... 40

Figura 15 – Relação de Pacotes Perdidos – 100 nós ................................................................ 41

Figura 16 – Percentual de Perdas – 100 nós ............................................................................. 41

Figura 17 – Comparação Percentual de Perdas ........................................................................ 42

Figura 18 – Média do Throughput – 10 nós ............................................................................. 43

Figura 19 – Média do Throughput – 50 nós ............................................................................. 44

Figura 20 – Média do Throughput – 100 nós ........................................................................... 45

Figura 21 – Comparação Média do Throughput ...................................................................... 45

Figura 22 – Média do Delay – 10 nós ...................................................................................... 46

Figura 23 – Média do Delay – 50 nós ...................................................................................... 47

Figura 24 – Média do Delay – 100 nós .................................................................................... 48

Figura 25 – Comparação Média do Delay ................................................................................ 49

LISTA DE ABREVIATURAS

AIMD Additive Increase Multiplicative Decrease

AGT Agent

AODV Ad-Hoc On-Demand Distance Vector Routing

AP Access Point

ARP Address Resolution Protocol

AWK Aho Weinberger Kernighan

BSS Basic Service Set

CEDAR Core Extraction Distributed Ad Hoc Routing

DARPA Defense Advanced Research Projects Agency

DHT Distributed Hash Table

DS Distribution System

DSDV Destination Sequenced Distance Vector

DSL Digital Subscriber Line

DSR Dynamic Source Routing

ESS Extended Service Set

FIFO First in First out

FTP File Transfer Protocol

Gbps Giba Bytes por segundo

GLOMOSIM Global Mobile Information System Simulation

IEEE Institute of Electrical and Electronics Engineers

Kbps Kilo Bytes por segundo

MAC Media Access Control

MAODV Multicast Ad-Hoc On-Demand Distance Vector

Mbps Mega Bytes por segundo

M-DART Multi-Path Dynamic Address Routing

NAM Network Animator

NCTUNS National Chiao Tung University of Taiwan Network Simulator

NM Nó Móvel

NS-2 Network Simulator 2

NSF National Science Foundation

ODMRP On-Demand Multicast Routing Protocol

OLSR Optimized Link State Routing Protocol

OSI/ISO Open Systems Interconnection

OTCL Object Tool Command Language

QOS Quality of Service

RTR Routing

RTT Round Trip Time

SMTP Simple Mail Transfer Protocol

STA Stations

SYN Synchronize sequence numbers

TCL Tool Command Language

TCP Transmission Control Protocol

TORA Temporally Ordered Routing Algorithm

UDP User Datagram Protocol

WLANs Wireless Personal Area Network

WMANs Wireless Metropolitan Area Network

WPANs Wireless Personal Area Network

ZRP Zone Routing Protocol

SUMÁR IO

1 INTRODUÇÃO ................................................................................................................... 13

2 REDES SEM FIO ................................................................................................................ 15

2.1 Modos de Operação .......................................................................................................... 15

2.2 Tipos de Redes .................................................................................................................. 16

3 REDES AD HOC ................................................................................................................. 17

3.1 Protocolos de Roteamento Unicast .................................................................................. 18

3.2 Protocolos de Roteamento Multicast ............................................................................... 19

4 PROTOCOLO M-DART .................................................................................................... 20

5 PROTOCOLOS DE TRANSPORTE ................................................................................ 24

5.1 Protocolo TCP ................................................................................................................... 24

5.1.1 TCP Tahoe ....................................................................................................................... 25

5.1.2 TCP New Reno ................................................................................................................ 26

5.1.3 TCP Vegas ....................................................................................................................... 27

5.1.4 TCP Sack ......................................................................................................................... 28

6 TRABALHOS RELACIONADOS .................................................................................... 29

7 METODOLOGIA ................................................................................................................ 31

7.1 Ferramenta de Simulação – Network Simulator 2 ......................................................... 32

7.2 Cenário da Simulação ...................................................................................................... 34

7.3 Métricas de Avaliação ...................................................................................................... 36

7.4 Plataforma das Simulações .............................................................................................. 37

7.5 Resultados ......................................................................................................................... 37

7.5.1 Pacotes Perdidos ............................................................................................................. 37

7.5.2 Throughput ...................................................................................................................... 43

7.5.3 Delay ................................................................................................................................ 46

8 CONCLUSÃO ...................................................................................................................... 50

8.1 Trabalhos Futuros ............................................................................................................ 52

APÊNDICE A – Código fonte do ambiente simulado com 10 NM .................................... 56

APÊNDICE B – Código fonte do ambiente simulado com 50 NM .................................... 59

APÊNDICE C – Código fonte do ambiente simulado com 100 NM .................................. 66

APÊNDICE D – Script de avaliação da vazão (throughput) ............................................... 77

APÊNDICE E – Script de avaliação do delay e pacotes perdidos ....................................... 78

13

1 INTRODUÇÃO

A evolução das tecnologias que envolvem redes de computadores atualmente atinge

diversos segmentos de comunicação, desde pequenas redes domésticas até grandes redes

empresariais. Tudo gira em torno do acesso aos dados, ou seja, cada vez mais aumenta a

demanda de serviços e aplicações que buscam através das redes de computadores os dados

em questão.

Com a popularização e a facilidade de aquisição de dispositivos móveis como

notebooks, telefones celulares, entre outros, as redes sem fio se popularizaram fazendo com

que o número de adeptos se tornasse significativamente maior em relação a anos anteriores

(ÁVILA, 2008), pois as mesmas proporcionam facilidade e comodidade aos usuários. Com

isso gera-se muito tráfego fazendo com que os canais de comunicação fiquem

congestionados e muitas vezes ocasionando perda de informações.

Segundo Mauro (2001), as informações de tráfego numa rede e como esse tráfego se

comporta são de vital importância para o bom funcionamento da mesma. Para prover bons

serviços de comunicação, levando em consideração que o que mais se busca é a qualidade e a

confiabilidade da transmissão, faz-se necessário ter uma boa estrutura de rede. Esses aspectos

tornam-se um desafio, pois diferentemente das redes tradicionais que utilizam como meio

físico o cabeamento para a transferência de dados, as redes sem fio contam com a

transmissão de dados via radiofrequência ou infravermelho (FLICKENGER, 2008), fazendo

com que a qualidade da transmissão não dependa somente da quantidade de dados

trafegados, mas também com os fenômenos que possam interferir neste meio.

As redes sem fio podem ser classificadas de duas formas: redes com infraestrutura e

redes sem infraestrutura, também conhecidas como redes ad hoc. Segundo Tanenbaum

(2011), as redes com infraestrutura utilizam um ponto de acesso central para a comunicação,

não sendo possível a troca direta de dados entre as estações. As redes ad hoc por outro lado,

permitem que estações se comuniquem diretamente entre si sem a necessidade de um ponto

de acesso.

Para o bom funcionamento destas redes é necessário a escolha de um protocolo de

roteamento adequado e que possua um bom desempenho. Os protocolos de roteamento

possuem um papel muito importante, pois eles permitem que cada dispositivo saiba para qual

nó ele deve enviar seus pacotes, através de tabelas de roteamento. Segundo Ortiz (2007),

como as redes ad hoc possuem o roteamento dinâmico devido a mobilidade constante dos

nós, o serviço de comunicação apresenta muitos problemas, como a perda de conectividade e

14

por sua vez um alto índice de perda de pacotes. Outro aspecto importante é a dificuldade

quanto a identificação e a localização da posição de cada dispositivo, pois o endereço

configurado em cada um não tem necessariamente relação com sua localização (ORTIZ,

2007). Com isso, os problemas apontados estão relacionados ao estudo do protocolo Multi-

Path Dynamic Address Routing (M-DART), que segundo Caleffi e Paura (2011), comparado

à outros protocolos, apresentou ótimos resultados.

Este trabalho busca aprofundar o conhecimento sobre redes sem fio dando ênfase às

redes ad hoc, avaliando a melhor alternativa para o bom funcionamento destas redes,

juntamente com o protocolo de roteamento em estudo. Deste modo, o objetivo geral consiste

em estudar o protocolo M-DART, avaliando o seu desempenho através de simulações com

diversos protocolos da camada de transporte.

Para que o desempenho do protocolo M-DART seja analisado especificamente este

trabalho irá usar três métricas para avaliação do mesmo: perdas, vazão e atraso. O foco da

comparação será abordar quatro tipos de flavors do protocolo de transporte TCP, buscando

resultados que satisfaçam o foco de cada aplicação, algumas tendo como prioridade a vazão e

outras a confiabilidade na entrega, ou seja, menos perdas. Com isso, serão apresentados os

resultados obtidos com o intuito de contribuir cientificamente para os estudos futuros e

profissionalmente como alternativa de melhoria para as redes ad hoc.

Com o desenvolvimento deste projeto será possível conhecer alternativas que melhor se

adaptem as redes ad hoc, especificamente com relação ao protocolo de roteamento M-DART,

sabendo do problema de roteamento dos dispositivos móveis durante o processo de

descoberta dos nós e transmissão dos dados. Com isso, será conhecido o desempenho de cada

protocolo de transporte baseado nas métricas apresentadas, permitindo um avanço nos

estudos da tecnologia sobre redes ad hoc.

Este trabalho está organizado da seguinte forma: O capítulo 2 apresenta os conceitos de

redes sem fio. O capítulo 3 apresenta os conceitos de redes ad hoc. No capítulo 4 são

apresentados os conceitos do protocolo de roteamento M-DART. No capítulo 5 são

apresentados os conceitos de protocolos de transporte. O capítulo 6 apresenta o estudo de

trabalhos relacionados. O capítulo 7 apresenta a metodologia do projeto, juntamente com os

resultados obtidos. Por fim, o capítulo 8 apresenta as considerações finais.

15

2 REDES SEM FIO

Diferente das redes cabeadas, que nos limitam muito em relação à mobilidade dos

dispositivos, as redes sem fio proporcionam mais facilidade e comodidade para os usuários,

fazendo com que muitos passem a utilizá-la. Vendo o grande sucesso desta tecnologia,

desenvolvedores estão a cada dia buscando melhorias, principalmente nos quesitos segurança

e desempenho (CAMPOS et al., 2003). Também conhecida como rede wireless, as redes sem

fio permitem que dois ou mais dispositivos se comuniquem através de ondas

eletromagnéticas.

Existem diversos padrões desenvolvidos para redes sem fio, sendo que este trabalho

focará o padrão 802.11. Este padrão é uma arquitetura definida pelo Institute of Electrical

and Electronics Engineers (IEEE) para redes sem fio, onde cada região de cobertura é

dividida em células (TANENBAUM, 2011). Inicialmente o princípio deste padrão era

somente especificar normas para controle de acesso ao meio e a camada física.

Com a evolução desta tecnologia surgiram diversas derivações do 802.11, sempre

visando melhorias no desempenho e segurança (CAMPOS et al., 2003), tais como o grupo

802.11e, preocupado com a qualidade de serviço de QOS – Quality of Service, o 802.11n,

visando aumentar a vazão destas redes e o 802.11i, que propõe mecanismos de segurança. As

técnicas de transmissão empregadas por este padrão são por rádio frequência e infravermelho

(FLICKENGER, 2008).

2.1 Modos de Operação

Existem dois modos de operação definidos pelo IEEE 802.11 (TANENBAUM, 2011):

• Com Infraestrutura: Tipo de rede que necessita de uma estação base (ponto de

acesso) no qual os dispositivos se conectam a rede, não sendo possível a

comunicação direta entre duas estações. Toda a comunicação entre as estações da

rede são realizadas através da estação base.

• Sem Infraestrutura: São redes do tipo Ad Hoc, ou seja, cada estação pode

comunicar-se diretamente com outra estação sem a necessidade de um ponto de

acesso. São conhecidas, segundo Krob (2006), como redes independentes, pois

podem se comunicar entre si ou através dos demais dispositivos.

16

Como visto anteriormente e demonstrado na figura 1, os nós em uma rede ad hoc

comunicam-se diretamente entre si para alcançarem o destino, desde que os nós estejam

dentro de uma mesma área de cobertura.

Figura 1 – Exemplo de comunicação em uma rede Ad Hoc

Fonte: Ortiz, 2007, p. 7.

2.2 Tipos de Redes

Os principais tipos de rede sem fio podem ser enquadrados em uma das divisões a

seguir (TANENBAUM, 2011) e (PEREIRA; ARAUJO, 2008):

• Wireless Personal Area Network (WPANs): São conhecidas como redes pessoais,

pois fornecem uma área de cobertura reduzida, fazendo com que o sinal atinja

pouca distância. O principal foco deste tipo de rede é interligar dispositivos e

periféricos, como notebooks e celulares. O principal padrão desta rede é o 802.15.

• Wireless Personal Area Network (WLANs): São conhecidas como redes locais por

abrangerem uma área de cobertura maior, como escritórios ou prédios. O principal

padrão desta rede é o 802.11.

• Wireless Metropolitan Area Network (WMANs): São conhecidas como redes

metropolitanas, pois possuem a capacidade de interligar bairros e cidades, com o

apoio de conexões de banda larga. O principal padrão deste tipo de rede é o 802.16.

• Wireless Regional Area Network (WRANs): São conhecidas como redes regionais,

como intuito de abranger regiões de difícil acesso a internet, como áreas rurais. A

proposta é baseada na utilização de canais livres de TV para o acesso a internet. O

padrão desta rede é o 802.22.

17

3 REDES AD HOC

Em muitos casos torna-se difícil ou até mesmo inviável a instalação de redes cabeadas

ou redes sem fio infraestruturadas, o que fez com que as redes ad hoc fossem cada vez mais

exploradas. As redes ad hoc são redes que não possuem infraestrutura, onde neste tipo de

rede é possível, segundo Tanenbaum (2011), que os dispositivos móveis possam trocar

informações entre si ou através de roteamento entre os mesmos sem a necessidade de um

ponto de acesso.

Sendo assim, os dispositivos tornam-se capazes de prover um serviço como roteador,

como terminal ou simultaneamente prover os dois serviços. Cada dispositivo é equipado com

um rádio transmissor e um receptor, o que torna possível a comunicação entre os mesmos,

fazendo com que os dispositivos possam gerar e receber informações dos demais (ORTIZ,

2007).

Além de a tecnologia ter como característica principal a mobilidade dos nós, ela

também ressalta a largura de banda e a segurança física que são limitadas. Dentre as

vantagens das redes ad hoc podemos citar as mais importantes, segundo Caetano (2008):

• Instalação instantânea: Os dispositivos podem ser facilmente integrados à rede

desde que estejam ao alcance dos demais dispositivos;

• Mobilidade: Desde que estejam dentro da área de cobertura os nós podem se

locomover livremente em uma conexão;

• Tolerância a falhas: Caso os dispositivos não funcionem por algum motivo, os

mesmos podem facilmente ser substituídos ou até mesmo a rede trabalhar sem

eles, devido à rápida adaptação e reconfiguração da rede.

Por outro lado, as redes ad hoc também apresentam alguns desafios, como por exemplo

(CAETANO, 2008):

• Localização: Torna-se muito difícil a identificação e a localização da posição

onde cada dispositivo se encontra, pois o endereço configurado em cada

dispositivo não tem necessariamente nenhuma relação com sua localização.

• Roteamento: Os dispositivos (nós) podem se mover livremente dentro da rede,

sendo que a topologia da mesma torna-se dinâmica, fazendo com que as rotas se

alterem sem prévio aviso.

Uma rota entre dois dispositivos móveis pode ser formada por um ou vários saltos

18

dentro de uma rede ad hoc. Segundo Campos et al. (2003) esse é um dos grandes problemas

existentes na tecnologia ad hoc, pois como os dispositivos podem se mover de forma

arbitrária dentro da rede as rotas se tornam dinâmicas, dificultando o processamento na

descoberta e atualização de novas rotas.

O papel dos protocolos de roteamento, segundo Ortiz (2007) é fazer a descoberta e o

mapeamento da topologia da rede, utilizando tabelas de roteamento como forma de

armazenamento das informações coletadas. Com isso eles são capazes de enviar requisições a

qualquer dispositivo que estiver dentro da área de cobertura da conexão.

Segundo Assis et al. (2010) podemos dividir os protocolos de roteamento para redes ad

hoc em duas grandes categorias: Unicast e Multicast. De acordo com a figura 2 pode ser

observado de maneira mais clara a divisão dos protocolos de roteamento.

Figura 2 – Divisão dos Protocolos de Roteamento para redes Ad Hoc

Fonte: Autoria Própria, 2012.

3.1 Protocolos de Roteamento Unicast

Os protocolos unicast podem transmitir pacotes de um nó de origem a um único nó de

destino, através de nós intermediários. Estes protocolos podem ser classificados conforme a

construção de suas rotas nas seguintes modalidades: Reativos, Pró-Ativos e Híbridos.

Baseando-se na ideia de Fontoura (2007) os protocolos de roteamento reativos trabalham

conforme solicitação do serviço, ou seja, quando surge a necessidade de descoberta ou

atualização de alguma rota é inicializado o processo de estabelecimento da conexão.

Os protocolos reativos não armazenam informações de rotas em uma tabela de

roteamento, fazendo com que não haja um controle contendo as rotas pré-definidas, sendo

que a cada solicitação de conexão perde-se muito tempo com a redefinição das rotas. Dentre

os protocolos mais conhecidos desta modalidade estão: Ad-Hoc On-Demand Distance Vector

19

Routing (AODV) e Dynamic Source Routing (DSR).

Ao contrário dos protocolos reativos, os pró-ativos armazenam em uma tabela de

roteamento todas as rotas possíveis, fazendo com que o roteamento se torne mais rápido. O

grande problema, como os dispositivos podem se mover livremente, é o custo quanto a

atualização das rotas na tabela de roteamento, fazendo com que haja um alto índice de

overhead (CAMPOS et al., 2003). São exemplos de protocolos pró-ativos: Optimized Link

State Routing Protocol (OLSR) e Destination-Sequenced Distance Vector Routing (DSDV).

Já os protocolos híbridos funcionam de diversas formas, mesclando protocolos reativos

com pró-ativos, sendo que são voltados para redes mais complexas. São exemplos de

protocolos híbridos: Core Extraction Distributed Ad Hoc Routing (CEDAR) e Zone Routing

Protocol (ZRP).

3.2 Protocolos de Roteamento Multicast

Baseado em Fontoura (2007) e Vicentini (2010) os protocolos multicast são capazes de

transmitir pacotes de um determinado nó de origem para múltiplos nós de destino,

identificados por um único endereço. Eles são divididos em dois tipos: Tree-based e Mesh-

based.

Os protocolos do tipo Tree-based são muito eficientes quanto ao throughput, pois só

existe um caminho entre o nó de origem e nó de destino. A grande característica deste

protocolo é a formação de árvore de multicast, formada pelos membros do grupo e não-

membros. Um exemplo desta categoria é o protocolo Multicast Ad-Hoc On-Demand

Distance Vector (MAODV).

A diferença para os protocolos Mesh-based é que neste caso existem múltiplos

caminhos entre um nó de origem e destino. Ao mesmo tempo em que este protocolo se torna

robusto por sua arquitetura, apresenta um consumo mais elevado de recursos. O protocolo

On-Demand Multicast Routing Protocol (ODMRP) é um exemplo deste tipo de protocolo.

Como visto anteriormente torna-se indispensável o uso de um protocolo de roteamento

para o correto funcionamento de uma comunicação entre dispositivos. Como foco deste

trabalho, será realizada uma análise do protocolo de roteamento M-DART, buscando

compreender seu funcionamento e técnicas de roteamento, conforme será visto no próximo

capítulo.

20

4 PROTOCOLO M-DART

Com o intuito sempre de melhoria e busca por um desempenho cada vez melhor, os

desenvolvedores de protocolos de roteamento procuram, muitas vezes embasando-se em

tecnologias já existentes, aprimorar e agregar funcionalidades que possam suprir deficiências

dos protocolos anteriores. Assim é o M-DART (CALEFFI; PAURA, 2011), um protocolo

unicast que pertence ao grupo dos pró-ativos.

Este protocolo baseia-se em tabelas hash distribuídas Distributed Hash Table (DHTs)

que consiste em utilizar chaves para o mapeamento, localização e remoção de nós em uma

rede. O funcionamento destas tabelas consiste no mapeamento de nós conectados a uma rede

através de um código hash que identifica cada nó.

Com esse código, cada nó tem a capacidade de localizar e identificar seus vizinhos,

fazendo com que seja desnecessário o conhecimento de todos os nós da rede. Para o bom

entendimento deste protocolo é necessário conhecer um pouco melhor o seu antecessor, o

protocolo DART (ERIKSSON; FALOTSOS; KRISHNAMURTHY, 2006).

O protocolo DART utiliza um vetor de distância para o descobrimento de rotas, assim

como o protocolo AODV. Através de endereçamento dinâmico, é capaz de realizar o

encaminhamento hierárquico de pacotes na rede de maneira viável, reduzindo

significativamente as informações mantidas por cada nó.

Uma vez que o processo de encaminhamento tem como base os endereços da rede, os

nós são distribuídos de maneira eficiente. Os endereços de rede são sequências de bits que

podem ser estruturados em forma de árvore, sendo que cada folha da árvore está associado a

um destes endereços, contendo internamente um prefixo de endereço binário que representa a

sua localização dentro de um conjunto de folhas, conforme demonstrado na figura 3.

Figura 3 – Endereços de rede em formato de árvore

Fonte: Caleffi e Paura, 2011, p. 394.

21

Por possuir sua tabela de roteamento neste formato, o protocolo DART apresenta um

problema devido a uma possível sobreposição de endereços no momento do encaminhamento

dos pacotes.

Porém, o maior problema deste protocolo é a possibilidade de haver rotas falsas,

conforme mostrado na figura 4, pois se algum dos nós por algum motivo falhar haverá uma

quebra na hierarquia da árvore, fazendo com que todos os nós ligados a este com problema

tenham de interromper a sua comunicação até que seja concluído o processo de redescoberta

de rotas.

Com isso, foi constatado que apenas se baseando no custo das rotas não era o suficiente

para descobrir o melhor caminho.

Figura 4 – Comportamento mediante as rotas falsas (DART)


A principal diferença entre os protocolos está no fato de que o M-DART possui a

funcionalidade de obter diversas rotas entre o nó de origem e destino utilizando DHT,

tornando o mapeamento e o roteamento mais ágil, assim melhorando o desempenho da rede

devido a topologia ser dinâmica.

O protocolo M-DART possui dois principais aspectos relevantes em comparação com

outros protocolos que utilizam múltiplas rotas: o descobrimento de rotas difusas não acaba

interferindo no desempenho da rede, fazendo com que não haja sobrecarga dos nós devido as

múltiplas rotas disponíveis, fazendo com que este protocolo se adapte perfeitamente ao

cenário de rede ad hoc; e o segundo aspecto é a facilidade quanto a descoberta de rotas,

sendo que cada nó obtém todas as rotas possíveis ao seu alcance (CALEFFI; PAURA, 2011).

Uma das grandes vantagens e avanço conquistado com o desenvolvimento do protocolo

M-DART é a capacidade de resolver o problema das rotas falsas. Como ele possui diversas

rotas disponíveis em sua tabela de roteamento, em caso de falha de um dos nós o protocolo

tem a disposição outras rotas pré-calculadas, fazendo com que seja evitada a interrupção de

22

comunicação, até que ao menos exista um caminho disponível, conforme mostrado na figura

5. Essas diversas rotas são conhecidas por meio de informações dos nós vizinhos, evitando

como dito anteriormente, a sobrecarga de cada nó.

Figura 5 – Comp. M-DART (rotas falsas)


Para o bom entendimento do funcionamento do protocolo M-DART é necessário

conhecer dois conceitos bem importantes sobre endereçamento: o endereço de roteamento e o

identificador de nó. O endereço de roteamento de um nó é dinâmico, sendo que o mesmo é

alterado conforme o nó se movimenta na rede. O identificador do nó é um número estático,

ou seja, permanece o mesmo durante a permanência do nó na rede.

Quando um novo nó começa a fazer parte da rede o mesmo começa a escutar as

atualizações periódicas de roteamento dos seus vizinhos, de maneira a identificar um

endereço desocupado. Encontrando um endereço vago o nó registra seu identificador e o

endereço de roteamento obtido. Devido a mobilidade, o endereço de roteamento pode ser

posteriormente alterado, sendo que a tabela de roteamento precisa ser atualizada.

Figura 6 – Exemplo de Topologia

Fonte: Caleffi e Paura, 2011, p. 396.

23

Como observado na figura 5, o custo não é um parâmetro suficiente para definir a

escolha de um melhor caminho. Sendo assim, o M-DART, levando em conta o recurso

hierárquico de endereçamento dinâmico, define como próximo salto o nó que contém o

prefixo de endereço mais próximo do destino.

No caso de haver diversos nós com prefixo igual ou próximo do destino, será levado

em consideração o de menor custo de rota. Um exemplo seria o demostrado na figura 6, onde

o nó com endereço “000” procura o melhor caminho para “110”. Como o protocolo M-

DART não tem como prioridade o custo da rota e sim o prefixo de endereço, a rota passará

pelos nós “100” e “101”, pois compartilham o mesmo prefixo “1XX”, correspondente ao

prefixo do nó destino. Por este motivo principalmente é que o M-DART obteve grande

avanço em relação ao protocolo DART.

O estudo deste trabalho é focado no protocolo M-DART, pois o mesmo foi comparado

com outros protocolos, e que segundo Caleffi e Paura (2011) mostrou-se o melhor entre eles.

Um ponto importante ao analisar o desempenho de um protocolo de roteamento é conhecer

quais protocolos de transporte que serão utilizados. Com isso, este trabalho busca analisar o

desempenho do protocolo M-DART juntamente com alguns flavors (variações) TCP, assunto

que será abordado no próximo capítulo.

24

5 PROTOCOLOS DE TRANSPORTE

Segundo Mauro (2001), as informações de tráfego numa rede e como esse tráfego

funciona são de vital importância para o bom funcionamento da mesma.

Para prover bons serviços de comunicação, levando em consideração que o que mais se

busca é a qualidade de transmissão e a confiabilidade dos dados, faz-se necessário descobrir

alternativas que minimizem o problema de congestionamento das redes, pois se os nós

enviarem muitos pacotes para a rede com muita rapidez, a rede ficará congestionada,

tornando o desempenho da mesma comprometida, podendo ocasionar o atraso e perda de

pacotes.

Para haver o controle desses problemas é necessário que as camadas de rede e de

transporte trabalhem juntas. Com isso, o protocolo de transporte possui um papel muito

importante, tendo como principais metas lidar com controle de erros, com a definição de

sequências e com o controle de fluxo (TANENBAUM, 2011). Um dos objetivos deste

trabalho é analisar o protocolo de transporte TCP e alguns de seus flavors, buscando o

melhor desempenho em redes ad hoc, identificando características e possíveis melhorias

nestes cenários.

5.1 Protocolo TCP

O TCP é um protocolo da camada de transporte, tendo o objetivo de fornecer um

serviço fiável de comunicação entre aplicações, baseado no conceito de comunicação. Tudo

começou em 1962, quando os americanos solicitaram a um grupo de investigadores que

criasse uma rede militar (BRANDINO, 1998).

Baseado nesta ideia, em 1969 a rede ARPANET foi criada pelo ARPA (Advanced

Research Projects Agency), dependente do DoD (Department of Defense) para a interligação

de quatro universidades americanas. Segundo Ribeiro (1998) o ARPANET foi apresentado

publicamente somente em 1972, tendo como protocolo o NCP (network control protocol),

sendo que o mesmo não permitia controle de erro.

Assim, Bob Kahn e Vinton Cerf (RFC 793, 1981) iniciaram o desenvolvimento do

protocolo TCP, tendo sua apresentação em 1974. Em 1976, o DoD decidiu interligar o

protocolo TCP com a rede ARPANET, composta por algumas máquinas, sendo que em 1978

o protocolo TCP foi separado em dois protocolos: TCP e IP.

25

O Protocolo TCP possui como principais características (FOROUZAN, 2008):

• Orientado a Conexão: o protocolo TCP especifica três fases durante uma

conexão: estabelecimento da conexão (three-way handshake), transferência e

encerramento da conexão.

• Desconexão Suave: o TCP somente encerra sua conexão após todos os dados

serem entregues ao destinatário.

• Full-duplex: possibilidade de transmissão simultânea em duplo sentido.

Com o intuito de buscar melhorias, segundo Martins (2008) foram desenvolvidas

algumas variações no protocolo TCP, abordando questões desde como o protocolo deve

tratar uma falha de transmissão ou um congestionamento do canal de comunicação. Essas

variações, conhecidas como flavors, buscam melhorar problemas existentes em outras

versões, conforme serão apresentadas algumas das mais importantes nas seções posteriores.

A utilização dos flavors neste trabalho deve-se ao bom desempenho obtido em outras

simulações, buscando analisar a efetividade dos mesmos com o protocolo M-DART.

5.1.1 TCP Tahoe

O controle de congestionamento torna-se uma ferramenta importante para o protocolo

TCP para que o mesmo seja mais robusto e confiável. Este tipo de controle não existia nas

primeiras implementações do TCP, sendo o Tahoe a primeira variação a desenvolver o

mecanismo de controle de congestionamento (MARTINS, 2003). Esta variação utiliza o

algoritmo Slow Start no TCP emissor onde a janela de congestionamento inicia-se como um

segmento, aumentando de maneira exponencial até ocorrer uma perda de pacote, detectada

através de um timeout. A partir do momento que ocorreu o timeout inicia-se novamente o

ciclo com apenas um seguimento, voltando a crescer novamente.

Assim, Segundo Abdi (2009), o Tahoe evita que seja enviado mais pacotes para a rede

do que a mesma pode suportar. Esta variação também possui controle de retransmissão (fast

retransmit), ou seja, quando um segmento recebe mais de uma confirmação isso significa que

algum pacote enviado da origem ao destino foi perdido havendo a necessidade de

retransmissão antes que ocorra a expiração do timeout. A grande desvantagem do TCP

Tahoe, segundo Cavalcanti (2005) é se houver um número significativamente grande de

perdas de pacote fazendo com que o algoritmo Slow Start seja iniciado muitas vezes e com

26

isso ocasionando uma baixa utilização da banda fornecida pela rede, como pode-se observar

na figura 7.

Figura 7 – Comportamento do TCP Tahoe

Fonte: Cavalcanti, 2005, p.28.

5.1.2 TCP New Reno

Quando falamos desta variação não podemos esquecer-nos de citar a versão anterior: o

TCP Reno. O Reno, no intuito de melhorar o TCP Tahoe, visa, baseando-se nos estudos de

Martins (2008), aperfeiçoar o processo de inúmeras perdas de pacotes, utilizando o algoritmo

fast retransmit e logo após o algoritmo fast recovery. Assim, quando houver perdas de

pacotes ou confirmações duplicadas, o TCP Reno verifica que a rede está congestionada,

reenviando o pacote perdido e diminuindo pela metade a janela de congestionamento e

armazenando na variável threshold, processo chamado de additive increase e multiplicative

decrease (AIMD).

À medida que as confirmações chegam de cada pacote retransmitido a janela de

congestionamento retorna ao valor de threshold, a partir daí crescendo linearmente

(congestion avoidance).

O TCP New Reno foca principalmente a melhoria de múltiplas perdas de pacote que

acontecem em uma única janela de transmissão no TCP Reno. A grande diferença para o

Reno é que o New Reno somente sai da fase de fast recovery quando o mesmo receber a

confirmação de todos os pacotes enviados nesta fase, passando assim para a fase de

congestion avoidance e com isso havendo uma melhora no aproveitamento da banda

disponível, conforme demostrado na figura 8.

27

Segundo Cavalcanti (2005), a fase de fast recovery elimina a necessidade de aguardar

por um timeout no caso de múltiplos descartes. Uma grande desvantagem está no caso de

haver retransmissão de mais de um segmento a cada RTT, provocando atrasos no envio dos

próximos segmentos.

Figura 8 – Comportamento do TCP New Reno

Fonte: Cavalcanti, 2005, p.28.

5.1.3 TCP Vegas

Diferentemente das outras variações que utilizam perdas de pacotes para detectar o

congestionamento da rede, o TCP Vegas, segundo Martins (2008), analisa o tráfego nos

roteadores, entre a origem e o destino, antes de ocorrer alguma perda, assim evitando o

congestionamento, observando a redução da taxa de envio em relação a taxa esperada.

Segundo Cavalcanti (2005), o protocolo TCP Tahoe e o TCP Reno reagem ao

congestionamento, tentando contornar o problema de diversas formas, sendo que o TCP

Vegas tenta evitar o congestionamento de forma pró-ativa, evitando o problema. As

alterações do Vegas são realizadas apenas no lado transmissor, sendo que o lado receptor

obedece ao funcionamento do TCP Reno.

Esta variação do TCP baseia-se na estimativa do RTT, onde a análise é feita em cima

do reconhecimento de segmentos, sendo que sempre que houver uma demora em relação ao

RTT é considerada uma perda. O algoritmo de Slow Start funciona como nas outras

variações, diferenciando a maneira como o mesmo aumenta de forma exponencial, sempre a

cada dois RTT, onde um é usado para realizar o cálculo do fluxo da rede. A análise é feita em

cima do RTT, sendo assim se o mesmo estiver com um valor grande é feita uma redução na

janela de congestionamento e se o valor de RTT for pequeno significa que a rede não possui

28

congestionamento e a janela é aumentada.

5.1.4 TCP Sack

A perda de múltiplos pacotes em uma janela e retransmissões de mais de um pacote

perdido por RTT pode fazer com que o protocolo TCP sofra grandes problemas (ABDI,

2009). Como o TCP usa um esquema de “reconhecimento cumulativo” isso faz com que o

transmissor aguarde um RTT para saber informações de pacotes que foram perdidos, ou até

mesmo retransmitir pacotes que foram enviados corretamente.

O TCP Sack (Selective Acknowledgment) é uma estratégia que segundo Bueno (2009)

elimina os problemas acima citados do Reno e New Reno, aumentando o desempenho do

TCP em redes de alta velocidade e com maior atraso. Com o reconhecimento seletivo o

receptor pode informar ao transmissor sobre todos os segmentos que chegaram corretamente,

de modo que o transmissor saiba quais os pacotes que necessitam ser retransmitidos devido a

perda. Esta opção do TCP é habilitada ao se definir um determinado bit no primeiro

segmento (SYN) ao iniciar uma conexão (BUENO, 2009).

Para que o processo de reconhecimento seletivo funcione corretamente é necessário

que os dispositivos que estão se comunicando suportem esta funcionalidade.

Segundo Abdi (2009), o TCP usa dois tipos de opções juntamente com o Sack: a

primeira é o “caminho permitido”, onde através de um SYN é indicado que a opção Sack

pode ser usada, uma vez que a conexão seja estabelecida; a segunda é opção de envio da

própria funcionalidade, desde que a conexão estabelecida tenha sido permitida pela primeira

opção.

29

6 TRABALHOS RELACIONADOS

O assunto sobre redes ad hoc não é algo novo, mas o estudo sobre o desenvolvimento

de novos protocolos de roteamento vem sendo alvo de interesse de muitos pesquisadores,

como é o caso de Caleffi e Paura (2011) que desenvolveram o protocolo M-DART. Isso se

justifica devido a alta complexidade envolvendo a dificuldade de descoberta e atualização de

rotas em redes ad hoc.

O trabalho de Caleffi e Paura (2011) intitulado “M-DART: multi-path dynamic address

routing” possui como principal objetivo apresentar um novo protocolo de roteamento mais

ágil e eficaz, capaz de garantir o encaminhamento de pacotes por múltiplas rotas. Este

protocolo foi desenvolvido com base em um já existente, o protocolo DART.

Ao contrário de muitos protocolos de roteamento, que utilizam apenas uma rota de

encaminhamento de pacotes, o M-DART é um protocolo pró-ativo que busca um alto

desempenho voltado para redes ad hoc, fator que os outros trabalhos que serão abordados

nesta seção não foram avaliados. Isso demostra também o pouco estudo que há em torno

desse tipo de rede.

Um dos grandes desafios do M-DART é assegurar que não haja sobrecarga nos nós

devido as múltiplas rotas disponíveis, fazendo com que este protocolo se adapte

perfeitamente ao cenário de rede ad hoc. O estudo comparativo através de simulações foi

realizado com os protocolos de roteamento AODV, DSDV, DSR, DART e M-DART. Como

forma de avaliação foram comparados apenas o protocolo TCP nativo (tahoe) e o UDP.

As principais métricas utilizadas na análise do protocolo M-DART com os demais

foram o delay fim-a-fim, o overhead durante o roteamento e a taxa de entrega dos pacotes. O

resultado das simulações mostrou que o protocolo M-DART é capaz de explorar todas as

rotas disponíveis sem o problema de sobrecarga dos nós. Além disto, o protocolo apresentou

ótimo desempenho em relação a mobilidade constante dos nós e a presença das adversas

condições externas, como interferências.

Outro trabalho pesquisado foi o de Abdi (2009) “Comparative study on the

performance of different TCP flavors”. Esta dissertação aborda um estudo comparativo entre

cinco variações do protocolo de transporte TCP: Reno, New Reno, Vegas, Westwood e SACK.

As comparações foram feitas em pares, observando o melhor desempenho entre os dois. Os

diversos cenários deste trabalho foram montados com base em uma rede cabeada, partindo do

problema de que o TCP atualmente é muito utilizado por aplicações em empresas e escolas,

fazendo com que o estudo em questão busque qual das variações TCP apresentará um melhor

30

desempenho quanto a vazão dos dados, buscando com isso também uma otimização no

desempenho dos equipamentos, evitando sobrecargas.

Basicamente foi utilizada somente a vazão (throughput) como métrica de análise,

podendo assim ter sido muito mais explorado. Com isso chegou-se a conclusão de que o TCP

Reno é o protocolo que obteve maior vazão, seguido do New Reno.

Por fim, foi analisado o trabalho de Bueno (2009) “Estudo do desempenho do

protocolo TCP em Redes Sem Fio”. Diferentemente do trabalho citado anteriormente, o

cenário desenvolvido neste projeto foi de uma rede sem fio infraestruturada. O estudo foi

baseado na ideia de que as variações tradicionais do TCP, de acordo com pesquisas e

experimentos, apresentam um desempenho inferior as redes cabeadas, devido a diversos

fatores, como interferências e mobilidade frequente dos nós. Para a análise em questão foram

utilizados cinco variações do protocolo TCP: Tahoe, Reno, New Reno, SACK e Vegas.

O trabalho foca no desempenho de cada variação do protocolo TCP, buscando analisar

a melhor dentre as variações para o cenário de redes sem fio com infraestrutura. Tratando do

quesito congestionamento, não houve grande diferença em relação as redes cabeadas, devido

ao preparo dos protocolos em tratar de possíveis colisões.

O grande problema encontrado foi quanto a interferência, observando que todos

possuem deficiências ao trabalhar em conjunto com as redes sem fio. Apesar de nenhum dos

protocolos apresentarem um grande resultado satisfatório, o que obteve melhor resultado foi

o TCP Vegas, mostrando ser um protocolo bastante conservador.

Em relação aos trabalhos estudados, identificamos que muitos aspectos importantes não

foram pesquisados e analisados pelos pesquisadores. Como visto no primeiro artigo o cenário

foi desenvolvido baseando-se em redes cabeadas. Já no artigo seguinte o foco foi dado às

redes sem fio infraestruturadas. No terceiro e último artigo a ênfase foi totalmente dada às

redes ad hoc, realizando simulações sobre os protocolos TCP e UDP.

Como proposta para este estudo visa-se, através de simulações, analisar o protocolo M-

DART em funcionamento com o protocolo TCP e suas variações (Tahoe, New Reno, Vegas e

Sack), o que não foi abordado no trabalho de Caleffi e Paura (2011).

Através desta análise, será obtido os pontos fortes e fracos do protocolo M-DART em

relação aos protocolos de transporte estudados, e com isso avaliar qual dos protocolos possui

melhor desempenho e melhor se adapta a tecnologia.

31

7 METODOLOGIA

No estudo das comunicações, a simulação se torna a maneira mais viável e eficiente

para testar diversos cenários, pois se sabe que é difícil adquirir um número suficiente de

equipamentos para testar cenários complexos, ponto importante também abordado por

Martins (2003) e Ávila (2008). Outro ponto que leva a utilização da simulação como

ferramenta de validação é a facilidade na coleta dos dados e representação gráfica, auxiliando

a compreensão da simulação em exercício.

Com isso, este projeto possui características de pesquisa aplicada, ou seja, de maneira

prática será buscado uma gama de conhecimentos com o intuito de focarmos na evolução da

tecnologia. De forma quantitativa esta pesquisa, através de coleta de dados por meio de

simulações, buscará analisar o comportamento de uma rede ad hoc, baseando-se em

pesquisas bibliográficas.

Conforme mencionado, este trabalho tem como objetivo analisar os protocolos de

transporte abordados, buscando através de comparações conhecer qual dos protocolos de

transporte traz melhor desempenho e benefício para o protocolo de roteamento em estudo.

Quanto a escolha da ferramenta de simulação foram analisados alguns aspectos como

abrangência de protocolos, compatibilidade e flexibilidade. Outro quesito importante nesta

pesquisa de ferramentas é questão da mesma ser distribuída gratuitamente (ROCHOL et al.,

2003). O Global Mobile Information System Simulation (GloMoSim) (ROCHOL et al.,

2003), National Chiao Tung University of Taiwan Network Simulator (NCTUns) (ROCHOL

et al., 2003) e o Network Simulator (NS-2) (NS-2, 2012) são ferramentas que englobam as

características acima citadas. O GloMoSim possui uma plataforma bastante robusta,

permitindo simulações com diversos nós de rede, abrangendo redes cabeadas e fortemente

redes sem fio. Esta ferramenta é voltada para sistemas operacionais Windows, Linux e

FreeBSD.

A ferramenta NCTUns, como a anterior, também possui uma arquitetura completa em

relação a protocolos e abrangência de tipos de redes. Uma grande desvantagem é que esta

ferramenta só é compatível com o sistema operacional FreeBSD. Ela se destaca

positivamente pela não dependência de scripts e alta qualidade gráfica para a montagem do

cenário.

Outra ferramenta que poderia ser utilizada é o NS-3. Esta ferramenta difere totalmente

do NS-2, deste a linguagem de desenvolvimento até a integração de outras ferramentas para a

análise de dados. O problema desta ferramenta é que por ela ainda ser recente muitos

32

resultados não poderiam ser obtidos com esta versão, devido a algumas limitações.

Já o NS-2 é uma ferramenta muito divulgada e conhecida, pois, segundo Ávila (2008) é

uma ferramenta direcionada para pesquisas em redes de computadores muito utilizada, tanto

no meio acadêmico como no meio profissional. São muitas as vantagens desta ferramenta,

como a compatibilidade com todos os sistemas operacionais e a alta abrangência de

protocolos simulados. Uma desvantagem é que o funcionamento da ferramenta depende do

desenvolvimento de scripts na linguagem Tool Command Language (TCL), conforme será

explicado na próxima seção.

7.1 Ferramenta de Simulação – Network Simulator 2

O Network Simulator 2 é um software de simulação, que segundo Ávila (2008) é capaz

de simular diversos cenários de redes de computadores, desde simples arquiteturas até as

mais complexas. Teve seu início em 1989, baseado em uma variação do Real Network

Simulator, sendo que a partir de 1995 este software passou a ser apoiado pelo Defense

Advanced Research Projects Agency (DARPA) e pela National Science Foundation (NSF).

É um simulador de eventos discretos e orientado a objetos, voltado para a área de

pesquisas, principalmente acadêmica, sendo um forte aliado na busca de estudos de novos

protocolos.

Ele trabalha na simulação de protocolos de transporte TCP e suas variantes (Reno, New

Renos, Vegas, etc.) e UDP. Possui também capacidade de simular redes sem fio (wireless e

ad hoc), redes multicast, redes cabeadas, satélites, entre outras. O Network Simulator está

atualmente na versão 2.35, sendo gratuito e possuindo seu código-fonte aberto, fazendo com

que haja a possibilidade de melhorias e ajustes na elaboração de novas simulações. O NS-2

foi desenvolvido em dois tipos de linguagens: Object Tool Command Language (OTCL) e

C++. Para que a simulação funcione é necessário a construção de um script na linguagem

OTCL, que por sua vez inicia um escalonador de eventos, fazendo a montagem do cenário,

dando inicio e término na transmissão de pacotes. Já o C++ é usado na definição da estrutura

básica, servindo como compilador para os scripts OTCL (ARAUJO, 2003).

Os arquivos de saída são chamados de traces, ou seja, logs gerados pelo NS-2 no

formato de texto contendo as informações referentes a simulação. Um exemplo de arquivo

trace pode ser visualizado na figura 9.

33

Figura 9 – Exemplo de arquivo trace


Uma das grandes vantagens da simulação é a facilidade na coleta e análise dos dados,

pois dependendo de fatores como a quantidade de nós, fluxos de dados e principalmente o

tempo da simulação, os arquivos traces podem ficar muito grandes (KROB, 2006). Como

forma de contornar esse problema há diversas maneiras para a realização da coleta dos dados,

sendo que neste trabalho será utilizada uma linguagem auxiliar para filtrar os dados

requeridos nos arquivos de saída, chamada de linguagem Aho Weinberger Kernighan

(AWK ), sigla que contém a primeira letra de cada sobrenome dos criadores da linguagem

(Alfred V. Aho, Peter J. Weinberger e Brian W. Kernighan).

Os arquivos traces são compostos de diversos campos com funcionalidades diferentes e

que servem como filtros para a coleta de informações, como pode ser observado no quadro 1.

Quadro 1 – Principais campos do arquivo trace

Campo Descrição s, r, d ou f Indica o evento ocorrido com o pacote. Pode conter um dos seguintes valores:

s(enviado), r (recebido), d (descartado) ou f (encaminhado). + ou - Entrada (+) ou saída (-) do pacote na fila do roteador.

-t Tempo em que ocorreu o evento, em segundos. -Hs Indica o nó de origem do pacote. -Hd Indica o nó de destino do pacote. Pode apresentar os seguintes valores: -1

(broadcast), -2 (sem destino configurado) ou o endereço IP do nó destino. -Ni Identificador do nó. -Nx Coordenada X do nó. -Ny Coordenada Y do nó. -Nz Coordenada Z do nó. -Ne Nível de energia do nó. -Nl Nível de trace. Pode conter vários valores, como AGT, RTR, MAC, etc. -Nw Motivo do descarte do pacote. -Ma Duração do evento.

34

-Md Endereço Ethernet do nó de destino. -Ms Endereço Ethernet do nó de origem. -Mt Tipo de Ethernet. -P Tipo de pacote. Pode conter vários valores, como ARP, DSR, TORA, etc. -Po Pacote ARP utilizado para solicitar um agente ou responder ao nó móvel.

-Pms Endereço MAC do nó de origem. -Pmd Endereço MAC do nó de destino. -Pd Endereço de destino. -Is Endereço IP de origem e porta. -Id Endereço IP de destino e porta. -It Tipo de pacote. Pode conter valores como TCP, UDP, etc. -Il Tamanho do pacote. -If Identificador do fluxo de dados. -Ii Identificador único do pacote. -Iv Tempo de vida do pacote.

Fonte: Krob, 2006, p.36-37.

O NS-2 também gera um arquivo trace para a visualização gráfica do cenário, chamada

de Network Animator (NAM). O NAM é uma ferramenta que possibilita o usuário verificar,

de uma maneira gráfica, o funcionamento da topologia de rede construída, juntamente com o

tráfego da rede e a ocorrência de perda de pacotes e possíveis áreas de congestionamento.

7.2 Cenário da Simulação

Para que o objetivo deste trabalho fosse atingido foi optado pela utilização da

ferramenta de simulação NS-2 e consequentemente o sistema operacional será o Linux,

devido a alta compatibilidade com o software e facilidade na instalação dos pacotes.

O aspecto mais forte na escolha do NS-2 foi que a ferramenta possui o protocolo de

roteamento em pesquisa, o M-DART em sua versão 2.35, sendo que este trabalho visa

analisar o comportamento deste protocolo de roteamento. Para isso, será usado o protocolo

de transporte TCP e os flavors: Tahoe, New Reno, Vegas e Sack.

Para que fossem definidos os flavors para este estudo foram analisados alguns critérios:

o Tahoe foi escolhido por ser o principal flavor utilizado nas transmissões simuladas pelo

NS-2, pois o mesmo é o padrão na ferramenta. Já o New Reno e o Vegas por apresentarem

melhores resultados em outros trabalhos em relação aos demais protocolos, como o de Abdi

(2009) e Bueno (2009). O TCP Sack, comparado com os mesmos flavors deste trabalho, só

que voltado para redes de satélite obteve melhores resultado sobre os demais (ZATTAR,

2001). Outro fator relevante foi a questão de não existir estudos em relação ao protocolo M-

35

DART, por ser um protocolo ainda recente e pouco estudo em relação as redes ad hoc.

Um dos fatores mais importantes dentro de uma simulação é a quantidade de nós

utilizados, pois fatores como vazão e perda de pacotes são diretamente afetados. As

simulações deste projeto utilizaram três variações na quantidade de nós: 10, 50 e 100 nós em

movimento, configurados manualmente no script TCL, tanto o caminho de origem ao destino

como o tráfego dos nós.

Foi determinado apenas um fluxo de dados fim-a-fim durante as simulações, pois o

intuito deste projeto não é estudar engenharia de tráfego, sobrecarregando os nós, mas sim

analisar o comportamento do roteamento dinâmico durante a movimentação dos nós na rede.

O deslocamento dos nós é realizado a uma velocidade de 3ms e a cobertura do sinal de

cada nó é de 360°, conforme pode ser observado na figura 10.

Figura 10 – Ilustração do Cenário – 10 nós


As configurações do cenário da simulação são demonstradas no quadro 2, ressaltando

que o tipo de fila utilizada em todas as simulações foi a DropTail, que segundo Araújo

(2008) implementa o modelo First in First out (FIFO).

Quadro 2 – Parâmetros de Configuração dos scripts TCL

PARÂMETRO DESCRIÇÃO Tipo de Meio Físico Channel/WirelessChannel Modelo de Propagação Propagation/TwoRayGround Tipo da Interface de Rede Phy/WirelessPhy Tipo de Camada MAC Mac/802_11

36

Tipo de Fila Queue/DropTail/PriQueue Abstração da Camada Link LL Modelo da Antena Antenna/OmniAntenna Tamanho Máximo de Pacotes na Fila 50 Nº de Nós 10, 50 e 100 Protocolo de Roteamento MDART Dimensão da Topografia 600 X 600 Tempo da Simulação 150 ut (unidades de tempo) Fonte: Autoria Própria, 2012.

Para que a variação do número de nós fosse escolhida para esta simulação foram

analisados outros valores intermediários aos escolhidos, chegando a uma média, pois os

resultados com outros valores eram muito semelhantes. O tempo da simulação foi baseado

em outros trabalhos, sendo que o mesmo é suficiente para a análise em questão.

Para a simulação dos cenários propostos foram desenvolvidos scripts no formato TCL

para que o software NS-2 pudesse interpretar e por sua vez gerar os resultados esperados em

arquivo trace. Para a coleta dos dados também foram desenvolvidos scripts capazes de serem

interpretados pela linguagem AWK, com o intuito de analisar os resultados e colocá-los de

forma gráfica. A ferramenta NAM possibilitou observar a topologia da rede, a movimentação

dos nós e o tráfego dos dados.

7.3 Métricas de Avaliação

Um aspecto muito importante, se tratando de um ambiente de simulação, é quanto à

escolha de métricas para que se possa analisar o comportamento da rede ad hoc. A escolha

destas métricas foi realizada de maneira a classificar as mais importantes para a análise em

questão, buscando ressaltar os resultados que mais interferem na projeção da análise de

roteamento.

Para a avaliação do protocolo de roteamento M-DART foram estabelecidas as

seguintes métricas:

• Delay: Tempo que um pacote leva da sua origem ao destino.

• Throughput: É a quantidade de dados transferidos em um determinado período

de um nó para o outro, levando-se em conta o menor valor da transferência. As

unidades métricas usadas são: Kbps, Mbps e Gbps.

• Taxa de Perdas: Ocorre quando há congestionamento na rede, formando filas nos

37

roteadores e excedendo o seu limite. Ela é calculada como a razão entre a

quantidade de pacotes perdidos pela quantidade de pacotes enviados.

7.4 Plataforma das Simulações

Para a realização das simulações foram utilizadas as seguintes configurações:

Hardware:

• Processador: Intel Core I5

• Memória: 4GB

• CPU: 2.30 GHz

Software:

• Layout do cenário:

o Sistema Operacional: Windows 7

• Simulações:

o Sistema Operacional: Linux (Ubuntu 11.10)

o Software de desenvolvimento: Ns-allinone-2.35

o Software de visualização do cenário: Nam-1.13

• Desenvolvimento de gráficos:

o Microsoft Excel 2010

7.5 Resultados

A partir da análise realizada nos traces gerados pelo NS-2 serão descritos os resultados

obtidos em cada cenário a partir das métricas escolhidas e de acordo com cada protocolo de

transporte e sua variação. Os mesmos serão representados através de gráficos, facilitando a

visualização do comportamento dos protocolos de transporte e avaliando qual obteve melhor

resultado para o bom desempenho do protocolo de roteamento M-DART.

7.5.1 Pacotes Perdidos

Para analisar a quantidade de pacotes perdidos durante a simulação, foi desenvolvido o

script pacotes_adhoc.awk. Este script calcula a quantidade de pacotes TCP perdidos e

recebidos durante a simulação, possibilitando verificar o percentual de perda.

38

A figura 11 apresenta a relação de pacotes recebidos com os pacotes perdidos, onde a

metade dos 10 nós móveis estão em movimento, se deslocando a uma velocidade de 3 m/s.

Figura 11 – Relação de Pacotes Perdidos – 10 nós


Conforme pode ser observado, o flavor TCP Vegas em relação aos demais flavors

obteve melhor resultado, enviando mais pacotes com uma menor quantidade de perda. Essa

variação do TCP visa proporcionar ao mesmo tempo uma taxa maior de transferência de

dados e diminuir a perda de segmentos na rede quando houver congestionamento.

Figura 12 – Percentual de Perdas – 10 nós


39

A figura 12 apresenta o percentual de perdas para 10 NM entre todos os protocolos,

salientando que este resultado foi baseado no percentual de perda de cada protocolo

separadamente.

Nesta simulação, o percentual de perda de cada variação separadamente foi de 3,16%

do Tahoe, 3,12% do New Reno, 2,07% do Vegas e 3,03% do Sack. Analisando as figuras 11 e

12 pode ser observado que todas as variações do TCP obtiveram resultados semelhantes,

sendo que o TCP Vegas obteve o melhor resultado dentre os mesmos, enviando mais pacotes

e perdendo menos. Mesmo com poucos nós, observa-se a eficiência da técnica do TCP

Vegas, analisando o tráfego nos roteadores, antes de ocorrer alguma perda.

A figura 13 apresenta o resultado da simulação onde metade dos 50 NM estão em

movimento, se deslocando a uma velocidade de 3 m/s.



Conforme pode ser observado, o TCP Tahoe foi o flavor que mais perdeu pacotes nesta

simulação, enquanto o TCP Vegas reduziu a transmissão de seus pacotes, para garantir a

efetividade na entrega dos pacotes.

Outro ponto importante é em relação ao aumento de pacotes enviados pelo Sack, pois o

mesmo, na tentativa de retransmitir os pacotes perdidos acaba enviando mais, mas

ocasionando um possível aumento de perda. Percebe-se também que com o aumento dos nós

as características de cada protocolo acabam se salientando, mostrando o verdadeiro

desempenho de cada um.

40

A figura 14 apresenta o percentual de perdas para 50 NM, sendo que este resultado

também foi baseado no percentual de perda de cada protocolo, assim como a figura 12.



Conforme pode ser observado, com o aumento de nós na rede o TCP Tahoe apresentou

um aumento de mais de 162% na taxa de perda de pacotes em relação a simulação anterior,

com apenas 10 NM.

Com isso, segundo Cavalcanti (2005) ocorre uma grande desvantagem, pois o

algoritmo Slow Start necessita ser iniciado diversas vezes, ocasionando uma baixa utilização

da banda fornecida pela rede. Todos os protocolos obtiveram um aumento em sua taxa de

perda, sendo o Vegas a obter o melhor resultado de percentual de perda.

A figura 15 apresenta o resultado da simulação onde metade dos 100 NM estão em

movimento, se deslocando a uma velocidade de 3 m/s.

Analisando esta simulação, em conjunto com as anteriores, pode-se observar que o

TCP Tahoe com um número maior de nós obteve melhor desempenho que o Vegas e o Sack,

sendo que nas simulações anteriores o Tahoe ficava em desvantagem em relação aos dois

flavors.

O Vegas, nas três simulações realizadas, apresentou melhores resultados em relação aos

demais flavors, demonstrando sua forte característica de evitar a perda de pacotes.

A figura 16 apresenta o percentual de perdas para 100 NM entre todos os protocolos,

sendo que este resultado também foi baseado no percentual de perda de cada protocolo.

41





Conforme pode ser observado, todos os protocolos sofreram um aumento na taxa de

perda de pacotes em relação à simulação anterior, sendo que houve um aumento

significativo, principalmente do protocolo TCP New Reno, observando a deficiência desta

variação do protocolo de transporte TCP, quanto ao problema dos múltiplos descartes, em

funcionamento com o protocolo M-DART.

Este problema, como demostrado na simulação, fez com que houvesse um grande

número de retransmissões de segmento a cada RTT, provocando atrasos no envio dos

42

segmentos seguintes.

Em relação ao TCP Vegas o aumento também foi significativo, correspondendo a

181% comparado com a simulação anterior. Isto ocorre devido ao controle de

congestionamento ser bastante rigoroso, tendo como base a estimativa do tráfego da rede.

Mesmo mediante a estas condições, o TCP Vegas obteve melhores resultados comparado

com os demais protocolos.

Um ponto importante a ser ressaltado em relação a esta análise foi o comportamento

adotado pelo Vegas, conforme pode ser observado nas duas últimas simulações, onde o

número de nós era maior e o flavor Vegas decidiu enviar menos pacotes que os demais

protocolos, pois ao contrário do TCP Tahoe, New Reno e Sack, o Vegas, de forma pró-ativa,

tenta evitar o congestionamento. (CAVALCANTI, 2005).

O TCP Sack obteve melhores resultados com um número menor de nós, pois seu

objetivo é retransmitir pacotes que não foram enviados com sucesso, fazendo com que o

receptor informe ao emissor quais pacotes foram recebidos corretamente.

O TCP Tahoe, diante do cenário de maior número de nós, apresentou o segundo melhor

resultado. Isto ocorre porque o controle de congestionamento menos rígido do TCP Tahoe

permitiu que o mesmo enviasse mais pacotes para a rede, baseando-se apenas em timeouts e

ACKs duplicados.

A figura 17 mostra um comparativo de todas as simulações realizadas referente a análise

do percentual de perda de pacotes.

Figura 17 – Comparação Percentual de Perdas


43

7.5.2 Throughput

Para descobrir a quantidade de dados transferidos de um host a outro, ou saber a

quantidade de dados processados em um determinado espaço de tempo é necessário calcular

o throughtput ou vazão da rede.

Para analisar a vazão de pacotes durante as simulações, foi desenvolvido o script

vazao_adhoc.awk. Este script filtra os pacotes recebidos, os de entrada e os enviados,

utilizando a coluna 2 (tempo) como base para o cálculo.

A figura 18 apresenta a média do throughtput para 10 NM entre os flavors Tahoe, New

Reno, Vegas e Sack.

Figura 18 – Média do Throughput – 10 nós

Fonte: Autoria Própria, 2012

Conforme pode ser observado na figura 18, todos os flavors, com exceção do TCP

Vegas obtiveram resultados semelhantes, pois o Vegas é o único dentre os flavors estudado

que previne o problema do congestionamento, analisando o tráfego nos roteadores e se

necessário, como observado, reduzindo sua vazão para evitar o excesso de pacotes. Os

demais flavors optaram, por suas caraterísticas, enviar um maior fluxo de pacotes, levando

aos mesmos a uma taxa maior de perda de pacotes.

A figura 19 apresenta a média do throughtput para 50 NM entre os flavors Tahoe, New

Reno, Vegas e Sack

44



Conforme pode ser observado, os flavors TCP apresentaram um comportamento

muito semelhante ao da simulação anterior, sendo que com o aumento de nós na rede os

mesmos reduziram sua vazão.

Por analisar o tráfego nos roteadores, evitando o congestionamento, segundo Martins

(2008), o TCP Vegas acaba reduzindo seu poder de transmissão, sendo o flavor que obteve a

maior taxa de queda no throughput, chegando a 65% do valor da primeira simulação, contra

25% do TCP Sack.

O TCP Tahoe, por possuir um controle de congestionamento com baixa rigidez,

permite que o mesmo envie uma quantidade significativa de pacotes para a rede, ao contrário

do TCP Vegas, como visto anteriormente.

A figura 20 apresenta a média do throughtput para 100 NM entre os flavors Tahoe,

New Reno, Vegas e Sack.

Conforme pode ser observado na figura 20, com o aumento para 100 NM na simulação

o flavor TCP Sack reduziu significativamente sua vazão na rede, chegando a 52% a menos

que na simulação anterior. Já o TCP Tahoe e o New Reno obtiveram os dois melhores

resultados respectivamente, sendo que o New Reno obteve um aproveitamento melhor da

banda disponível devido a sua característica de somente sair da fase de fast recovery quando

o mesmo receber a confirmação de todos os pacotes enviados nesta fase. Já o Tahoe, como

explicado na simulação anterior, por ter sua característica de possuir um controle menos

rigoroso no controle de congestionamento, fez com que este flavor aproveitasse melhor o uso

45

da banda disponível.



A figura 21 mostra um comparativo de todas as simulações realizadas referente a

análise da média do throughput.

Figura 21 – Comparação Média do Throughput


46

7.5.3 Delay

Para descobrir o tempo que um pacote leva da sua origem ao destino é necessário

calcular o delay ou atraso entre os hosts.

Para analisar o delay da rede durante as simulações, foi desenvolvido o script

pacotes_adhoc.awk. Este script calcula o tempo de um pacote desde seu envio até a sua

chegada ao destino, tendo como base o tempo inicial e final da transmissão e o ID de cada

pacote.

A figura 22 apresenta a média do delay para 10 NM entre os flavors Tahoe, New Reno,

Vegas e Sack.

Figura 22 – Média do Delay – 10 nós


Conforme pode ser observado na figura 22, o TCP Sack foi o flavor que obteve a maior

média de atraso nesta simulação, pois devido a grande perda de pacotes, como demonstrado

na simulação referente ao mesmo anteriormente, e seu controle rígido de reenvio de pacotes

perdidos, possibilitou um grande atraso na entrega dos pacotes.

Situação semelhante ocorreu com os flavors Tahoe e New Reno, onde os mesmos

apresentaram uma taxa aproximada entre si de pacotes perdidos, como demonstrado na figura

12.

O TCP Vegas foi o flavor que obteve o melhor resultado, pois seu funcionamento

permite que o mesmo preveja o congestionamento da rede, reduzindo seus pacotes.

47

Como pode-se observar na figura 23, que apresenta a média do delay para 50 NM entre

os flavors Tahoe, New Reno, Vegas e Sack, o TCP Sack continua como flavor que obteve

maior média de atraso. Se analisarmos novamente as figuras 13 e 14, juntamente com a

última simulação realizada, pode ser observado que o Tahoe obteve maior taxa de perda de

pacotes, sendo que o Sack ficou bem abaixo do valor de seu oponente.

Isso explica o porquê do resultado do Sack em ficar com a maior média de atraso nesta

simulação, pois o mesmo tem um grande rigor e preocupação em reenviar os pacotes

perdidos, fazendo com que haja um atraso maior na entrega dos pacotes. Por sua vez, o

Tahoe não tem o mesmo rigor na questão de retransmissão, pois com um número alto de

pacotes perdidos o algoritmo Slow Start é iniciado muitas vezes e com isso ocasionando uma

baixa utilização da banda fornecida pela rede.

Com o aumento dos nós na rede o TCP Vegas obteve pequeno aumento na média de

atraso, mantendo-se como flavor com melhor resultado de delay. O New Reno, assim como o

Tahoe, também teve sua média aumentada, com diferenças muito próximas a da simulação

anterior.



A figura 24 apresenta a média do delay para 100 NM entre os flavors Tahoe, New

Reno, Vegas e Sack.

Conforme pode ser observado na figura 24, o TCP New Reno obteve a média mais alta

nesta última simulação com 100 NM. Se analisarmos novamente a figura 20 poderá ser

48

observado que os flavors com maior média de throughput foram o Tahoe e o New Reno. Com

isso, como explicado na simulação anterior, o Tahoe, por possuir um controle de

congestionamento menos rígido, faz com que os pacotes sejam enviados com mais

intensidade. Já o New Reno, com o aumento dos nós, enviou uma taxa alta de pacotes, mas

com o problema de haver retransmissão de muitos segmentos a cada RTT, provocando

atrasos no envio dos próximos segmentos.



O TCP Sack reduziu significativamente sua média de atraso em relação à simulação

anterior, pois como pode ser observado na figura 21 houve uma queda na média de

throughput na alteração de NM na rede, fazendo com que menos pacotes fossem enviados,

gerando menos pacotes perdidos e menor atraso na rede.

O TCP Vegas também reduziu de maneira sutil sua média de atraso, pelo mesmo

motivo do TCP Sack, apesar do Vegas obter o melhor resultado em todas as simulações.

A figura 25 apresenta um comparativo de todas as simulações realizadas referente a

análise da média do delay.

49

Figura 25 – Comparação Média do Delay


Conforme visto no início deste trabalho, as transmissões multimídia não faziam parte

do foco do assunto. Sendo assim, segundo as métricas escolhidas, os flavors que obtiveram

melhores resultados foram o Tahoe e o Vegas.

O Tahoe, segundo esta simulação, é voltado mais para aplicações de alta transmissão,

onde a mesma não tenha como requisito principal um baixo índice de perda de pacotes.

Já o Vegas é voltado mais para aplicações onde se necessita de uma confiabilidade

maior na entrega dos pacotes, deixando em segundo plano a vazão de pacotes.

50

8 CONCLUSÃO

As redes ad hoc estão sendo exploradas continuamente e vem ganhando espaço no

mercado em diversas áreas. Há várias características que fazem das redes ad hoc uma

tecnologia ainda pouco difundida. Talvez, a principal como pôde ser verificado no estudo

deste trabalho, em relação a dificuldade quanto à criação e atualização das rotas entre os

dispositivos móveis devido à sua mobilidade dinâmica.

O protocolo M-DART, apresenta como grande vantagem a capacidade de solução do

problema das rotas falsas. Como o mesmo possui diversas rotas disponíveis em sua tabela de

roteamento, em caso de falha de um dos nós o protocolo tem a disposição outras rotas pré-

calculadas, fazendo com que seja evitada a perda de comunicação. Este é um dos fatos que

levaram os autores Caleffi e Paura, além da comprovação através de simulações, a

concluírem que o M-DART é um protocolo com desempenho superior aos demais protocolos

de roteamento ad hoc.

Neste trabalho foi realizada uma análise de desempenho entre quatro tipos diferentes de

flavors TCP (Tahoe, New Reno, Vegas e Sack). Para isto, foram realizadas diversas

simulações, visando verificar o desempenho dos flavors com o protocolo de roteamento M-

DART.

Em relação ao percentual de perda de pacotes o flavor que obteve melhor resultado foi

o TCP Vegas em todas as simulações, pois sua característica forte é a de ser pró-ativo em

relação ao tráfego da rede, ou seja, o mesmo examina o tráfego nos roteadores, evitando o

congestionamento na rede. Com isso, o mesmo reduz o número de pacotes enviados,

evitando também a perda de pacotes.

O flavor que obteve o pior resultado com relação às perdas no protocolo M-DART foi

o New Reno. Isto se justifica devido a sua deficiência nos múltiplos descartes. Este

problema, como demostrado na simulação, fez com que houvesse um grande número de

retransmissões de segmento a cada RTT, provocando atrasos no envio dos segmentos

seguintes.

O TCP Tahoe, diante do cenário de maior número de nós, apresentou um resultado

bastante satisfatório. Isto ocorreu porque o controle de congestionamento deste flavor é

menos rígido, permitindo que o mesmo envie mais pacotes para a rede. Ao contrário, o TCP

Sack obteve melhores resultados com um número menor de nós, pois o mesmo possui um

controle muito rigoroso em relação a retransmissão de pacotes que não chegaram

corretamente ao destino.

51

Em relação ao throughput o TCP Vegas, em todas as simulações, foi inferior aos

demais flavors, pois em análise conjunta com a métrica de pacotes perdidos, observa-se que

segundo sua característica o mesmo evita o congestionamento da rede reduzindo a vazão de

dados.

O TCP Sack obteve excelentes resultados com os cenários de 10 e 50 nós, mas com o

aumento para 100 acabou sendo o segundo pior na análise de resultados. Isso ocorreu porque

o flavor, devido ao alto índice de perdas se preocupou em reenviar os pacotes perdidos

segundo suas características, reduzindo significativamente sua vazão.

O TCP New Reno foi o segundo melhor flavor em relação a esta métrica, pois assim

como o Tahoe, não possui um controle muito rigoroso em relação ao congestionamento da

rede, enviando muitos pacotes, não se preocupando tanto com a questão da perda.

Em relação ao delay o TCP New Reno obteve a média mais alta com o aumento dos

nós. Levando em consideração que os flavors com maior média de throughput foram o Tahoe

e o New Reno, observa-se que o Tahoe, por possuir um controle de congestionamento menos

rígido, fez com que os pacotes fossem enviados com mais intensidade. O New Reno, com o

aumento dos nós, enviou uma taxa alta de pacotes, sendo que o problema de retransmissão de

muitos segmentos provocou atrasos no envio dos próximos.

O TCP Sack reduziu significativamente sua média no cenário com maior número de

nós, pois com a queda na média de throughput na alteração dos NM na rede, fez com que

menos pacotes fossem enviados, gerando menos pacotes perdidos e menor atraso na rede.

O TCP Vegas obteve o melhor resultado em todas as simulações, pois conforme sua

característica o mesmo evita congestionamentos, evitando a perda de pacotes, reduzindo a

vazão de dados na rede.

Após este estudo é possível concluir que há dois resultados satisfatórios, sendo que os

mesmos deverão ser levados em consideração de acordo com a aplicação desejada, o grau de

importância da mesma e o tamanho da rede ad hoc que se deseja construir. Conclui-se com

isto que o Tahoe obteve melhor desempenho voltado a clientes e aplicações que não levam

em consideração como prioridade o atraso na entrega de alguns pacotes, pois este flavor,

como observado no decorrer do trabalho e nas simulações, possui um controle não muito

rigoroso quanto à prevenção ao congestionamento da rede, fazendo com que a vazão deste

flavor atinja altos índices de pacotes transmitidos.

Aplicações voltadas para fins civis, como redes de táxi, salas de reuniões e PDAs são

exemplos que não necessitaria levar tanto em consideração o problema do atraso na entrega

dos pacotes, pois são aplicações que não são extremamente críticas. É importante ressaltar

52

que o Tahoe somente é a melhor alternativa se o número de nós for de aproximadamente

100NM, pois conforme mostrado nas simulações, em cenários com números menores de nós

a diferença em relação ao TCP Vegas em relação ao percentual de perda se torna bem

significativa.

Outro resultado considerado satisfatório neste trabalho é o desempenho do TCP Vegas,

voltado a clientes e aplicações que possuem como preocupação obter uma garantia maior na

entrega dos pacotes, por exemplo, aplicações para fins militares e operações de emergência.

O TCP Vegas é um flavor diferentemente de todos os outros, pois se preocupa primeiramente

em analisar o tráfego nos roteadores para evitar possíveis congestionamentos, fazendo com

que seja reduzido o número de pacotes enviados para a rede.

Com isso, a vazão é reduzida, mas com a vantagem de ter uma taxa menor de

percentual de perda de pacotes. Este tipo de flavor é recomendado, segundo as simulações

realizadas, para redes menores que não ultrapassem muito a quantidade de 50 NM, pois a

partir desta quantidade o Vegas começa aumentar a perda de pacotes significativamente,

reduzindo seu desempenho.

8.1 Trabalhos Futuros

No início e decorrer do trabalho surgiram sugestões e interesses de outros focos a

serem abordados no estudo em questão, mas devido a complexidade e o pouco tempo de

execução do trabalho algumas ideias foram deixadas para trabalhos futuros.

A primeira sugestão é analisar estes mesmos flavors com outras métricas importantes,

como o Jitter, uma métrica de desempenho que foca o congestionamento da rede e métricas

de escalabilidade, como pacotes de sinalização, para estudar o gerenciamento de localização.

A segunda sugestão é usar este mesmo trabalho variando um número maior de nós para

analisar o comportamento dos flavors diante de um cenário maior que 100NM. Juntamente,

poderia também ser variado o número de nós em movimento e a velocidade de cada nó

durante a simulação, para verificar o impacto no desempenho.

A terceira sugestão é usar este trabalho como base para o estudo de diferentes tipos de

filas, verificando a influência sobre o desempenho da rede. A fila utilizada neste trabalho foi

somente a DropTail.

53

REFERÊNCIAS

ABDI, Abdulaziz Jama Omar. Comparative study on the performance of different TCP flavors. 2009. 79f. Tese de Mestrado (Tecnologia da Informação) – University Utara Malaysia, 2009. Disponível em: < http://etd.uum.edu.my/1618/1/Abdulaziz_Jama_Omar_Ab di.pdf>. Acesso em: 10 mar. 2012. ARAUJO, Rafael Gonçalves Bezerra de. A ferramenta de Simulação NS (Network Simulator) – Estudo de Caso. 2003. 59f. Universidade Salvador UNIFACS, Salvador, 2003. Disponível em: < http://www.harpia.eng.br/pesquisa/tfc_EngElet_Rafael.pdf>. Acesso em: 26 out. 2011. ASSIS, Vanessa Marques de et al. Redes sem fio em Malha. 2010. Disponível em: < http://www.gta.ufrj.br/grad/10_1/malha/>. Acesso em: 08 out. 2011. ÁVILA, Cristiane de. Estudo de Padrões de Mobilidade Realísticos para Redes Ad Hoc. 2008. 80f. Trabalho de Conclusão de Curso (Graduação em Ciência da Computação) - Centro Universitário La Salle, Canoas, 2008. Disponível em: <http://biblioteca.unilasalle.edu.br/doc s_online/tcc/graduacao/ciencia_da_computacao/2008/cavila.pdf>. Acesso em: 01 set. 2011. BRANDINO, Wandreson Luiz. Apostila TCP/IP. 1998. Disponível em: < http://www.wandreson.com/download/training-networking-tcpip.pdf>. Acesso em: 18 out. 2011. BRIGNONI, Guilherme Venícius. Estudo de Protocolos de Roteamento em Redes Ad Hoc. 2005. 73f. Trabalho de Conclusão de Curso (Graduação em Ciência da Computação) – Universidade Federal de Santa Catarina, Florianópolis, 2005. Disponível em: < http:// projetos.inf.ufsc.br/arquivos_projetos/projeto_208/TCC%20-%20Estudo%20de%20protoco los%20de%20roteamento%20em%20redes%20Ad%20hoc.pdf>. Acesso em: 01 set. 2011. BUENO, Luis Eduardo Pereira. Estudo do Desempenho do Protocolo TCP em Redes Sem Fio. 2009. 47f. Projeto de Graduação (Graduação em Engenharia Elétrica) – Universidade Federal do Paraná, Curitiba, 2009. Disponível em: < http://www.eletrica.ufpr.br/ufpr2/tccs/26 .pdf >. Acesso em: 20 de mar. 2012. CAETANO, Marcos Fagundes. Uma Abordagem Colaborativa de Cache em Redes Ad Hoc. 2008. 84f. Trabalho de Conclusão de Mestrado (Ciência da Computação) - Universidade de Brasília, Brasília, 2008. Disponível em:< http://bdtd.bce.unb.br/tedesimplifi cado/tde_busca/arquivo.php?codArquivo=4753>. Acesso em: 02 set. 2011. CALEFFI, Marcello; PAURA, Luigi. M-DART: multi-path dynamic address routing . 2011. Artigo publicado em ACM Digital Library, 2011. Disponível em: <http://dl.acm.org/citation.cfm?id=1967234>. Acesso em: 15 jan. 2012. CAMPOS, Carlos Alberto Vieira et al. Mobilidade em redes Redes Sem Fio Ad hoc. 2003. 41f. UFRJ, Rio de Janeiro, 2003. Disponível em: < http://www.garf.coppe.ufrj.br/PDFs/ mc_wcsf2003.pdf>. Acesso em: 29 ago. 2011. CANTU, Evandro. Redes de Computadores e Internet. 2003. 79f. Cefet, São José, 2003.

54

Disponível em: < http://www.riopomba.ifsudestemg.edu.br/dcc/dcc/materiais/428029062_ap ostila-redes.pdf>. Acesso em: 29 ago. 2011. CAVALCANTI, Juliana Lima. Análise Comparativa dos Algoritmos de Controle de Congestionamento do TCP. 2005. 62p. Trabalho de Conclusão de Curso (Engenharia da Computação) - Universidade de Pernambuco, Recife, 2005. http://tcc.dsc.upe.br/Juliana Cavalcanti.pdf - Acesso em: 27 set. 2011. ERIKSSON, Jakob; FALOUTSOS, Michalis; KRISHNAMURTHY, Srikanth. DART: Dynamic Address Routing for Scalable Ad Hoc and Mesh Networks. University of California, Riverside. Disponível em: < http://nms.csail.mit.edu/~jakob/pubs/dart_ton_2006. pdf >. Acesso em: 05 fev. 2012. FLICKENGER, Rob. Redes sem fio no Mundo em Desenvolvimento. 2. ed.: Hacker Friendly LLC, 2007. Disponível em: < http://wndw.net/pdf/wndw-pt/wndw-pt-ebook.pdf>. Acesso em 27 ago. 2011. FONTOURA, Antônio Carré da. Análise de Protocolos de Roteamento em uma Rede Mesh baseada em um Backbone Universitário . 2007. 105f. Trabalho de Conclusão de Curso (Graduação em Ciência da Computação) - Universidade de Passo Fundo, Passo Fundo, 2007. Disponível em: < http://www.upf.br/computacao/images/stories/TCs/arquivos_20072/antonio _fontoura.pdf >. Acesso em: 02 fev. 2012. FOROUZAN, Behrouz A. Comunicação de Dados e Redes de Computadores. 4. ed. São Paulo, SP: McGraw-Hill; Porto Alegre, RS: Bookman, 2008. KROB, Andrea Collin. Gerenciamento da mobilidade em redes sem fio. 2006. 106f. Trabalho de Conclusão de Curso (Graduação em Ciência da Computação) – Centro Universitário La Salle, Canoas, 2006. LINHARES, Fhilipe Guimarães. Avaliação de desempenho de VPNs sobre redes MPLS-Linux . 2010. 65f. Trabalho de Conclusão de Curso (Graduação em Ciência da Computação) - UFRGS, Porto Alegre, 2010. Disponível em:<http://www.lume.ufrgs.br/bitstream/handle/1 0183/28311/000767714.pdf?sequence=1>. Acesso em: 27 ago. 2011.

MARTINS, Pedro Rogério do Nascimento. Análise do Desempenho de diferentes versões do Protocolo TCP: Um Experimento através de Simulação. 2008. 91f. Trabalho de Conclusão de Curso (Sistemas da Informação) – Centro Universitário Feevale, Novo Hamburgo, 2008. http://tconline.feevale.br/tc/ files/0002_1722.pdf -Acesso em: 10 mar. 2012.

MAURO, Douglas; SCHMIDT, Kevin. SNMP essencial. 1. ed. São Paulo. Campus, 2001. NS-2. The Network Simulator Project. Disponível em <http://www.isi.edu/nsnam/ns>. Acesso em: 10 out. 2011. ORTIZ, Marcos Dantas. Incentivando a cooperação em redes Ad Hoc. 2007. 95f. Dissertação de Mestrado (Ciência da Computação) - Universidade Federal do Ceará, Fortaleza, 2007. Disponível em: <http://www.teses.ufc.br/tde_busca/arquivo.php?cod Arquivo=1365>. Acesso em: 03 set. 2011.

55

OKAZAKI, Tomoya et al. A Multipath Routing Method witch Dynamic ID for Red uction of Routing Load in Ad Hoc Networks. Graduate School of Information Sciences, Hiroshima City University. Disponível em: < http://books.google.com.br/books?id=JPGHx_Avl4AC& pg=PA115&dq=dart+routing&hl=pt-BR&sa=X&ei=t5PFT_DrL4Khgwfr5MDXBg&ved=0C DIQ6AEwAA#v=onepage&q=dart%20routing&f=false>. Acesso em: 01 fev. 2012. PEREIRA, Hermano; ARAUJO, Roberson. Uma abordagem sobre o WRAN – IEEE 802.22. Disponível em: < http://www.hermano.com.br/arquivos/estudos/redes_computadores /wran/wran-artigo.pdf > Acesso em 12 jul. 2012. PRADO, Eduardo. Dimensionamento de Redes Wimax. Teleco, 2006. Disponível em: < http://www.teleco.com.br/tutoriais/tutorialredeswimax/default.asp > Acesso em 04 set. 2012. RFC 793. Transmission Control Protocol – Darpa Internet Program Protocol Specification. Arlington, Virginia. 1981. Disponível em: < http://www.dei.isep.ipp.pt/~andre /normas/rfc793.txt >. Acesso em: 01 mar. 2012. RIBEIRO, Lígia Maria. A História da Internet . FEUP-CICA, 1998. Disponível em: < http://paginas.fe.up.pt/~mgi97018/historia.html>. Acesso em: 18 fev. 2012. ROCHA, João Wilson Vieira. Redes WLAN de alta velocidade. Teleco, 2006. Disponível em: < http://www.teleco.com.br/tutoriais/tutorialredeswlanI/default.asp > Acesso em 04 set. 2012. ROCHOL, Juergen et al. Plataformas de Simulação de Software Livre para Redes Fixas e Móveis: Características, Suporte, Instalação e Validação. In: 2nd International Information and Telecommunication Technologies Symposium (I2TS´03), Florianopolis, SC. Nov. 2003. Disponível em: < http://nsl10.csie.nctu.edu.tw/products/nctuns/NCTUnsReferences/paper76-I2TS2003.pdf >. Acesso em: 20 mar. 2012. SILVA, Tiago Trindade da. Proposta de Método de Acesso ao Meio baseado em QOS para Redes Ad Hoc IEEE 802.11. 2008. 140f. Dissertação de Mestrado (Engenharia Elétrica) - Universidade Brasília, Brasília, 2008. Disponível em: < http://repositorio.bce.unb.br/bitstrea m/10482/2960/1/Dissert_TiagoTrindadeSilva.pdf>. Acesso em: 03 set. 2011. TANENBAUM, Andrew S.; WETHERALL, David J. Redes de computadores. 5. ed. São Paulo, SP: Pearson Prentice Hall, 2011. VICENTINI, Cleverton Juliano Alves. Uma nova Métrica de Roteamento para Redes Wireless Mesh com Tráfego Voip. 2010. 70f. Dissertação de Mestrado - Universidade PUC do Paraná, Curitiba, 2010. Disponível em: < http://www.ppgia.pucpr.br/lib/exe/fetch.php?me dia=dissertacoes:cleverton_juliano.pdf >. Acesso em: 02 fev. 2012. ZATTAR, Haroldo. Avaliação Comparativa dos Mecanismos Congestion Avoidance TCP Sack e Vegas operando sobre uma Rede ATM via Satélite. 2001. Disponível em: < sites.uol.com.br/hzattar/ArtigoSBRTcolunadupla.zi>. Acesso em: 25 mar. 2012.

56

APÊNDICE A – Código fonte do ambiente simulado com 10 NM

# Definição dos parâmetros principais set val(chan) Channel/WirelessChannel; # Tipo do Canal set val(prop) Propagation/TwoRayGround; # Modelo de Propagação set val(netif) Phy/WirelessPhy; # Tipo da Interface de Rede set val(mac) Mac/802_11; # MAC type set val(ifq) Queue/DropTail/PriQueue; # Tipo de Fila set val(ll) LL; # link layer type set val(ant) Antenna/OmniAntenna; # Modelo da Antena set val(ifqlen) 50; # max packet in ifq set val(nn) 10; # Nº de Nós set val(rp) MDART; # Protocolo de Roteamento set val(x) 600; # X Dimensão da Topografia set val(y) 600; # Y Dimensão da Topografia set val(stop) 150; # Tempo da Simulação # Criação do Escalonador de Eventos set ns [new Simulator] # Configuração dos Arquivos de Trace $ns use-newtrace set tracefd [open Trace_TCC10.tr w] set namtrace [open Trace_TCC10.nam w] $ns trace-all $tracefd $ns namtrace-all-wireless $namtrace $val(x) $val(y) # Criação da topologia set topo [new Topography] $topo load_flatgrid $val(x) $val(y) create-god $val(nn) # Configuração dos Nós Móveis (NM's) $ns node-config -adhocRouting $val(rp) \ -llType $val(ll) \ -macType $val(mac) \ -ifqType $val(ifq) \ -ifqLen $val(ifqlen) \ -antType $val(ant) \ -propType $val(prop) \ -phyType $val(netif) \ -channelType $val(chan) \ -topoInstance $topo \ -agentTrace ON \ -routerTrace ON \ -macTrace OFF \ -movementTrace ON

57

for {set i 0} {$i < $val(nn) } { incr i } { set node_($i) [$ns node] } # Posição Inicial dos Nós $node_(0) set X_ -252.0 $node_(0) set Y_ 10.0 $node_(0) set Z_ 0.0 $node_(1) set X_ 200.0 $node_(1) set Y_ 5.0 $node_(1) set Z_ 0.0 $node_(2) set X_ 300.0 $node_(2) set Y_ 300.0 $node_(2) set Z_ 0.0 $node_(3) set X_ 1.0 $node_(3) set Y_ 200.0 $node_(3) set Z_ 0.0 $node_(4) set X_ 25.0 $node_(4) set Y_ 500.0 $node_(4) set Z_ 0.0 $node_(5) set X_ 50.0 $node_(5) set Y_ 50.0 $node_(5) set Z_ 0.0 $node_(6) set X_ -50.0 $node_(6) set Y_ 300.0 $node_(6) set Z_ 0.0 $node_(7) set X_ 125.0 $node_(7) set Y_ 280.0 $node_(7) set Z_ 0.0 $node_(8) set X_ 500.0 $node_(8) set Y_ 380.0 $node_(8) set Z_ 0.0 $node_(9) set X_ 500.0 $node_(9) set Y_ 400.0 $node_(9) set Z_ 0.0 # Geração dos Movimentos $ns at 10.0 "$node_(0) setdest 250.0 250.0 3.0" $ns at 15.0 "$node_(1) setdest 75.0 210.0 3.0" $ns at 5.0 "$node_(3) setdest 300.0 300.0 3.0"

58

$ns at 5.0 "$node_(8) setdest 80.0 10.0 3.0" $ns at 5.0 "$node_(9) setdest 1.0 500.0 3.0" # Criação dos agentes: transporte e aplicação set tcp1 [new Agent/TCP/Sack1]; $tcp1 set class_ 1 $tcp1 set packetSize_ ; $ns attach-agent $node_(9) $tcp1 ; set sink1 [new Agent/TCPSink]; $ns attach-agent $node_(0) $tcp1 $ns attach-agent $node_(9) $sink1; $ns connect $tcp1 $sink1; set ftp1 [new Application/FTP]; $ftp1 attach-agent $tcp1; # Posição dos nós no NAM for {set i 0} {$i < $val(nn)} { incr i } { # Tamanho do nó no NAM = 30 $ns initial_node_pos $node_($i) 30 } # Fim da Simulação NAM $ns at $val(stop) "$ns nam-end-wireless $val(stop)" $ns at $val(stop) "stop" $ns at 150.00 "$ns halt" proc stop {} { global ns tracefd namtrace $ns flush-trace exec nam Trace_TCC10.nam & close $tracefd close $namtrace } $ns at 10.0 "$ftp1 start" $ns run

59

APÊNDICE B – Código fonte do ambiente simulado com 50 NM


60

for {set i 0} {$i < $val(nn) } { incr i } { set node_($i) [$ns node] } # Posição Inicial dos Nós $node_(0) set X_ -252.0 $node_(0) set Y_ 10.0 $node_(0) set Z_ 0.0 $node_(1) set X_ 200.0 $node_(1) set Y_ 5.0 $node_(1) set Z_ 0.0 $node_(2) set X_ 300.0 $node_(2) set Y_ 300.0 $node_(2) set Z_ 0.0 $node_(3) set X_ 1.0 $node_(3) set Y_ 200.0 $node_(3) set Z_ 0.0 $node_(4) set X_ 25.0 $node_(4) set Y_ 500.0 $node_(4) set Z_ 0.0 $node_(5) set X_ 50.0 $node_(5) set Y_ 50.0 $node_(5) set Z_ 0.0 $node_(6) set X_ -50.0 $node_(6) set Y_ 300.0 $node_(6) set Z_ 0.0 $node_(7) set X_ 125.0 $node_(7) set Y_ 280.0 $node_(7) set Z_ 0.0 $node_(8) set X_ 500.0 $node_(8) set Y_ 380.0 $node_(8) set Z_ 0.0 $node_(9) set X_ 500.0 $node_(9) set Y_ 400.0 $node_(9) set Z_ 0.0 $node_(10) set X_ 1.0 $node_(10) set Y_ 5.0 $node_(10) set Z_ 0.0

61

$node_(11) set X_ 550.0 $node_(11) set Y_ 10.0 $node_(11) set Z_ 0.0 $node_(12) set X_ 120.0 $node_(12) set Y_ 400.0 $node_(12) set Z_ 0.0 $node_(13) set X_ 165.0 $node_(13) set Y_ 4.0 $node_(13) set Z_ 0.0 $node_(14) set X_ 356.0 $node_(14) set Y_ 75.0 $node_(14) set Z_ 0.0 $node_(15) set X_ 550.0 $node_(15) set Y_ 550.0 $node_(15) set Z_ 0.0 $node_(16) set X_ 222.0 $node_(16) set Y_ 111.0 $node_(16) set Z_ 0.0 $node_(17) set X_ 333.0 $node_(17) set Y_ 333.0 $node_(17) set Z_ 0.0 $node_(18) set X_ 444.0 $node_(18) set Y_ 555.0 $node_(18) set Z_ 0.0 $node_(19) set X_ 555.0 $node_(19) set Y_ 222.0 $node_(19) set Z_ 0.0 $node_(20) set X_ 399.0 $node_(20) set Y_ 100.0 $node_(20) set Z_ 0.0 $node_(21) set X_ 88.0 $node_(21) set Y_ 499.0 $node_(21) set Z_ 0.0 $node_(22) set X_ 485.0 $node_(22) set Y_ 222.0 $node_(22) set Z_ 0.0 $node_(23) set X_ 588.0 $node_(23) set Y_ 300.0

62

$node_(23) set Z_ 0.0 $node_(24) set X_ -300.0 $node_(24) set Y_ 500.0 $node_(24) set Z_ 0.0 $node_(25) set X_ 344.0 $node_(25) set Y_ 15.0 $node_(25) set Z_ 0.0 $node_(26) set X_ 60.0 $node_(26) set Y_ 466.0 $node_(26) set Z_ 0.0 $node_(27) set X_ 321.0 $node_(27) set Y_ 123.0 $node_(27) set Z_ 0.0 $node_(28) set X_ 456.0 $node_(28) set Y_ 345.0 $node_(28) set Z_ 0.0 $node_(29) set X_ 545.0 $node_(29) set Y_ 454.0 $node_(29) set Z_ 0.0 $node_(30) set X_ 312.0 $node_(30) set Y_ 44.0 $node_(30) set Z_ 0.0 $node_(31) set X_ 200.0 $node_(31) set Y_ 599.0 $node_(31) set Z_ 0.0 $node_(32) set X_ 250.0 $node_(32) set Y_ 555.0 $node_(32) set Z_ 0.0 $node_(33) set X_ -16.0 $node_(33) set Y_ 100.0 $node_(33) set Z_ 0.0 $node_(34) set X_ 33.0 $node_(34) set Y_ 33.0 $node_(34) set Z_ 0.0 $node_(35) set X_ 599.0 $node_(35) set Y_ 100.0 $node_(35) set Z_ 0.0

63

$node_(36) set X_ -299.0 $node_(36) set Y_ 321.0 $node_(36) set Z_ 0.0 $node_(37) set X_ -123.0 $node_(37) set Y_ 455.0 $node_(37) set Z_ 0.0 $node_(38) set X_ 224.0 $node_(38) set Y_ 422.0 $node_(38) set Z_ 0.0 $node_(39) set X_ 595.0 $node_(39) set Y_ 20.0 $node_(39) set Z_ 0.0 $node_(40) set X_ -123.0 $node_(40) set Y_ 4.0 $node_(40) set Z_ 0.0 $node_(41) set X_ 79.0 $node_(41) set Y_ 79.0 $node_(41) set Z_ 0.0 $node_(42) set X_ 99.0 $node_(42) set Y_ 199.0 $node_(42) set Z_ 0.0 $node_(43) set X_ 167.0 $node_(43) set Y_ 345.0 $node_(43) set Z_ 0.0 $node_(44) set X_ -255.0 $node_(44) set Y_ 200.0 $node_(44) set Z_ 0.0 $node_(45) set X_ -123.0 $node_(45) set Y_ 150.0 $node_(45) set Z_ 0.0 $node_(46) set X_ 376.0 $node_(46) set Y_ 27.0 $node_(46) set Z_ 0.0 $node_(47) set X_ 291.0 $node_(47) set Y_ 52.0 $node_(47) set Z_ 0.0 $node_(48) set X_ 577.0 $node_(48) set Y_ 422.0

64

$node_(48) set Z_ 0.0 $node_(49) set X_ 265.0 $node_(49) set Y_ 3.0 $node_(49) set Z_ 0.0 # Geração dos Movimentos $ns at 10.0 "$node_(0) setdest 250.0 250.0 3.0" $ns at 15.0 "$node_(1) setdest 75.0 210.0 3.0" $ns at 15.0 "$node_(2) setdest 1.0 500.0 3.0" $ns at 5.0 "$node_(3) setdest 300.0 300.0 3.0" $ns at 5.0 "$node_(4) setdest 10.0 40.0 3.0" $ns at 5.0 "$node_(5) setdest 250.0 60.0 3.0" $ns at 5.0 "$node_(6) setdest 100.0 50.0 3.0" $ns at 5.0 "$node_(7) setdest 1.0 250.0 3.0" $ns at 5.0 "$node_(8) setdest 80.0 10.0 3.0" $ns at 5.0 "$node_(9) setdest 1.0 500.0 3.0" $ns at 10.0 "$node_(40) setdest 250.0 250.0 3.0" $ns at 15.0 "$node_(16) setdest 75.0 210.0 3.0" $ns at 15.0 "$node_(23) setdest 1.0 500.0 3.0" $ns at 5.0 "$node_(27) setdest 300.0 300.0 3.0" $ns at 5.0 "$node_(39) setdest 10.0 40.0 3.0" $ns at 5.0 "$node_(35) setdest 250.0 60.0 3.0" $ns at 5.0 "$node_(31) setdest 100.0 50.0 3.0" $ns at 5.0 "$node_(32) setdest 1.0 250.0 3.0" $ns at 5.0 "$node_(38) setdest 80.0 10.0 3.0" $ns at 5.0 "$node_(45) setdest 1.0 500.0 3.0" $ns at 10.0 "$node_(49) setdest 250.0 250.0 3.0" $ns at 15.0 "$node_(47) setdest 75.0 210.0 3.0" $ns at 15.0 "$node_(42) setdest 1.0 500.0 3.0" $ns at 5.0 "$node_(43) setdest 300.0 300.0 3.0" $ns at 5.0 "$node_(44) setdest 10.0 40.0 3.0" # Criação dos agentes: transporte e aplicação set tcp1 [new Agent/TCP/Newreno]; $tcp1 set class_ 1 $tcp1 set packetSize_ ; $ns attach-agent $node_(9) $tcp1 ; set sink1 [new Agent/TCPSink]; $ns attach-agent $node_(0) $tcp1 $ns attach-agent $node_(9) $sink1; $ns connect $tcp1 $sink1; set ftp1 [new Application/FTP]; $ftp1 attach-agent $tcp1; # Posição dos nós no NAM for {set i 0} {$i < $val(nn)} { incr i } {

65

# Tamanho do nó no NAM = 30 $ns initial_node_pos $node_($i) 30 } # Fim da Simulação NAM $ns at $val(stop) "$ns nam-end-wireless $val(stop)" $ns at $val(stop) "stop" $ns at 150.00 "$ns halt" proc stop {} { global ns tracefd namtrace $ns flush-trace exec nam Trace_TCC50.nam & close $tracefd close $namtrace } $ns at 10.0 "$ftp1 start" $ns run

66

APÊNDICE C – Código fonte do ambiente simulado com 100 NM


67

for {set i 0} {$i < $val(nn) } { incr i } { set node_($i) [$ns node] } # Posição Inicial dos Nós $node_(0) set X_ -252.0 $node_(0) set Y_ 10.0 $node_(0) set Z_ 0.0 $node_(1) set X_ 200.0 $node_(1) set Y_ 5.0 $node_(1) set Z_ 0.0 $node_(2) set X_ 300.0 $node_(2) set Y_ 300.0 $node_(2) set Z_ 0.0 $node_(3) set X_ 1.0 $node_(3) set Y_ 200.0 $node_(3) set Z_ 0.0 $node_(4) set X_ 25.0 $node_(4) set Y_ 500.0 $node_(4) set Z_ 0.0 $node_(5) set X_ 50.0 $node_(5) set Y_ 50.0 $node_(5) set Z_ 0.0 $node_(6) set X_ -50.0 $node_(6) set Y_ 300.0 $node_(6) set Z_ 0.0 $node_(7) set X_ 125.0 $node_(7) set Y_ 280.0 $node_(7) set Z_ 0.0 $node_(8) set X_ 500.0 $node_(8) set Y_ 380.0 $node_(8) set Z_ 0.0 $node_(9) set X_ 500.0 $node_(9) set Y_ 400.0 $node_(9) set Z_ 0.0 $node_(10) set X_ 1.0 $node_(10) set Y_ 5.0 $node_(10) set Z_ 0.0 $node_(11) set X_ 550.0 $node_(11) set Y_ 10.0

68

$node_(11) set Z_ 0.0 $node_(12) set X_ 120.0 $node_(12) set Y_ 400.0 $node_(12) set Z_ 0.0 $node_(13) set X_ 165.0 $node_(13) set Y_ 4.0 $node_(13) set Z_ 0.0 $node_(14) set X_ 356.0 $node_(14) set Y_ 75.0 $node_(14) set Z_ 0.0 $node_(15) set X_ 550.0 $node_(15) set Y_ 550.0 $node_(15) set Z_ 0.0 $node_(16) set X_ 222.0 $node_(16) set Y_ 111.0 $node_(16) set Z_ 0.0 $node_(17) set X_ 333.0 $node_(17) set Y_ 333.0 $node_(17) set Z_ 0.0 $node_(18) set X_ 444.0 $node_(18) set Y_ 555.0 $node_(18) set Z_ 0.0 $node_(19) set X_ 555.0 $node_(19) set Y_ 222.0 $node_(19) set Z_ 0.0 $node_(20) set X_ 399.0 $node_(20) set Y_ 100.0 $node_(20) set Z_ 0.0 $node_(21) set X_ 88.0 $node_(21) set Y_ 499.0 $node_(21) set Z_ 0.0 $node_(22) set X_ 485.0 $node_(22) set Y_ 222.0 $node_(22) set Z_ 0.0 $node_(23) set X_ 588.0 $node_(23) set Y_ 300.0 $node_(23) set Z_ 0.0

69

$node_(24) set X_ -300.0 $node_(24) set Y_ 500.0 $node_(24) set Z_ 0.0 $node_(25) set X_ 344.0 $node_(25) set Y_ 15.0 $node_(25) set Z_ 0.0 $node_(26) set X_ 60.0 $node_(26) set Y_ 466.0 $node_(26) set Z_ 0.0 $node_(27) set X_ 321.0 $node_(27) set Y_ 123.0 $node_(27) set Z_ 0.0 $node_(28) set X_ 456.0 $node_(28) set Y_ 345.0 $node_(28) set Z_ 0.0 $node_(29) set X_ 545.0 $node_(29) set Y_ 454.0 $node_(29) set Z_ 0.0 $node_(30) set X_ 312.0 $node_(30) set Y_ 44.0 $node_(30) set Z_ 0.0 $node_(31) set X_ 200.0 $node_(31) set Y_ 599.0 $node_(31) set Z_ 0.0 $node_(32) set X_ 250.0 $node_(32) set Y_ 555.0 $node_(32) set Z_ 0.0 $node_(33) set X_ -16.0 $node_(33) set Y_ 100.0 $node_(33) set Z_ 0.0 $node_(34) set X_ 33.0 $node_(34) set Y_ 33.0 $node_(34) set Z_ 0.0 $node_(35) set X_ 599.0 $node_(35) set Y_ 100.0 $node_(35) set Z_ 0.0 $node_(36) set X_ -299.0 $node_(36) set Y_ 321.0

70

$node_(36) set Z_ 0.0 $node_(37) set X_ -123.0 $node_(37) set Y_ 455.0 $node_(37) set Z_ 0.0 $node_(38) set X_ 224.0 $node_(38) set Y_ 422.0 $node_(38) set Z_ 0.0 $node_(39) set X_ 595.0 $node_(39) set Y_ 20.0 $node_(39) set Z_ 0.0 $node_(40) set X_ -123.0 $node_(40) set Y_ 4.0 $node_(40) set Z_ 0.0 $node_(41) set X_ 79.0 $node_(41) set Y_ 79.0 $node_(41) set Z_ 0.0 $node_(42) set X_ 99.0 $node_(42) set Y_ 199.0 $node_(42) set Z_ 0.0 $node_(43) set X_ 167.0 $node_(43) set Y_ 345.0 $node_(43) set Z_ 0.0 $node_(44) set X_ -255.0 $node_(44) set Y_ 200.0 $node_(44) set Z_ 0.0 $node_(45) set X_ -123.0 $node_(45) set Y_ 150.0 $node_(45) set Z_ 0.0 $node_(46) set X_ 376.0 $node_(46) set Y_ 27.0 $node_(46) set Z_ 0.0 $node_(47) set X_ 291.0 $node_(47) set Y_ 52.0 $node_(47) set Z_ 0.0 $node_(48) set X_ 577.0 $node_(48) set Y_ 422.0 $node_(48) set Z_ 0.0

71

$node_(49) set X_ 265.0 $node_(49) set Y_ 3.0 $node_(49) set Z_ 0.0 $node_(50) set X_ 252.0 $node_(50) set Y_ -10.0 $node_(50) set Z_ 0.0 $node_(51) set X_ 200.0 $node_(51) set Y_ -5.0 $node_(51) set Z_ 0.0 $node_(52) set X_ 300.0 $node_(52) set Y_ -300.0 $node_(52) set Z_ 0.0 $node_(53) set X_ 1.0 $node_(53) set Y_ -200.0 $node_(53) set Z_ 0.0 $node_(54) set X_ 25.0 $node_(54) set Y_ -500.0 $node_(54) set Z_ 0.0 $node_(55) set X_ -50.0 $node_(55) set Y_ 50.0 $node_(55) set Z_ 0.0 $node_(56) set X_ -50.0 $node_(56) set Y_ 300.0 $node_(56) set Z_ 0.0 $node_(57) set X_ -125.0 $node_(57) set Y_ 280.0 $node_(57) set Z_ 0.0 $node_(58) set X_ -500.0 $node_(58) set Y_ 380.0 $node_(58) set Z_ 0.0 $node_(59) set X_ -500.0 $node_(59) set Y_ 400.0 $node_(59) set Z_ 0.0 $node_(60) set X_ 1.0 $node_(60) set Y_ -5.0 $node_(60) set Z_ 0.0 $node_(61) set X_ 433.0 $node_(61) set Y_ 10.0

72

$node_(61) set Z_ 0.0 $node_(62) set X_ -120.0 $node_(62) set Y_ 400.0 $node_(62) set Z_ 0.0 $node_(63) set X_ 252.0 $node_(63) set Y_ 4.0 $node_(63) set Z_ 0.0 $node_(64) set X_ 356.0 $node_(64) set Y_ -75.0 $node_(64) set Z_ 0.0 $node_(65) set X_ 250.0 $node_(65) set Y_ 250.0 $node_(65) set Z_ 0.0 $node_(66) set X_ -8.0 $node_(66) set Y_ 50.0 $node_(66) set Z_ 0.0 $node_(67) set X_ 54.0 $node_(67) set Y_ 54.0 $node_(67) set Z_ 0.0 $node_(68) set X_ 314.0 $node_(68) set Y_ -1.0 $node_(68) set Z_ 0.0 $node_(69) set X_ 314.0 $node_(69) set Y_ 39.0 $node_(69) set Z_ 0.0 $node_(70) set X_ 500.0 $node_(70) set Y_ 599.0 $node_(70) set Z_ 0.0 $node_(71) set X_ 47.0 $node_(71) set Y_ 47.0 $node_(71) set Z_ 0.0 $node_(72) set X_ 31.0 $node_(72) set Y_ 13.0 $node_(72) set Z_ 0.0 $node_(73) set X_ 77.0 $node_(73) set Y_ -2.0 $node_(73) set Z_ 0.0

73

$node_(74) set X_ 77.0 $node_(74) set Y_ 15.0 $node_(74) set Z_ 0.0 $node_(75) set X_ 81.0 $node_(75) set Y_ 410.0 $node_(75) set Z_ 0.0 $node_(76) set X_ -60.0 $node_(76) set Y_ 259.0 $node_(76) set Z_ 0.0 $node_(77) set X_ 1.0 $node_(77) set Y_ 599.0 $node_(77) set Z_ 0.0 $node_(78) set X_ 99.0 $node_(78) set Y_ 99.0 $node_(78) set Z_ 0.0 $node_(79) set X_ 99.0 $node_(79) set Y_ -44.0 $node_(79) set Z_ 0.0 $node_(80) set X_ 22.0 $node_(80) set Y_ 300.0 $node_(80) set Z_ 0.0 $node_(81) set X_ 505.0 $node_(81) set Y_ 599.0 $node_(81) set Z_ 0.0 $node_(82) set X_ -22.0 $node_(82) set Y_ 22.0 $node_(82) set Z_ 0.0 $node_(83) set X_ 87.0 $node_(83) set Y_ 246.0 $node_(83) set Z_ 0.0 $node_(84) set X_ -5.0 $node_(84) set Y_ 33.0 $node_(84) set Z_ 0.0 $node_(85) set X_ 588.0 $node_(85) set Y_ 256.0 $node_(85) set Z_ 0.0 $node_(86) set X_ 66.0 $node_(86) set Y_ 66.0

74

$node_(86) set Z_ 0.0 $node_(87) set X_ 310.0 $node_(87) set Y_ 138.0 $node_(87) set Z_ 0.0 $node_(88) set X_ 423.0 $node_(88) set Y_ 88.0 $node_(88) set Z_ 0.0 $node_(89) set X_ 566.0 $node_(89) set Y_ 566.0 $node_(89) set Z_ 0.0 $node_(90) set X_ 412.0 $node_(90) set Y_ 33.0 $node_(90) set Z_ 0.0 $node_(91) set X_ 72.0 $node_(91) set Y_ 400.0 $node_(91) set Z_ 0.0 $node_(92) set X_ 277.0 $node_(92) set Y_ 199.0 $node_(92) set Z_ 0.0 $node_(93) set X_ 566.0 $node_(93) set Y_ 345.0 $node_(93) set Z_ 0.0 $node_(94) set X_ 300.0 $node_(94) set Y_ -10.0 $node_(94) set Z_ 0.0 $node_(95) set X_ 444.0 $node_(95) set Y_ 99.0 $node_(95) set Z_ 0.0 $node_(96) set X_ 1.0 $node_(96) set Y_ 509.0 $node_(96) set Z_ 0.0 $node_(97) set X_ 5.0 $node_(97) set Y_ 479.0 $node_(97) set Z_ 0.0 $node_(98) set X_ 173.0 $node_(98) set Y_ 173.0 $node_(98) set Z_ 0.0

75

$node_(99) set X_ 30.0 $node_(99) set Y_ 57.0 $node_(99) set Z_ 0.0 # Geração dos Movimentos $ns at 10.0 "$node_(0) setdest 250.0 250.0 3.0" $ns at 15.0 "$node_(1) setdest 75.0 210.0 3.0" $ns at 15.0 "$node_(2) setdest 1.0 500.0 3.0" $ns at 5.0 "$node_(3) setdest 300.0 300.0 3.0" $ns at 5.0 "$node_(4) setdest 10.0 40.0 3.0" $ns at 5.0 "$node_(5) setdest 250.0 60.0 3.0" $ns at 5.0 "$node_(6) setdest 100.0 50.0 3.0" $ns at 5.0 "$node_(7) setdest 1.0 250.0 3.0" $ns at 5.0 "$node_(8) setdest 80.0 10.0 3.0" $ns at 5.0 "$node_(9) setdest 1.0 500.0 3.0" $ns at 10.0 "$node_(40) setdest 250.0 250.0 3.0" $ns at 15.0 "$node_(16) setdest 75.0 210.0 3.0" $ns at 15.0 "$node_(23) setdest 1.0 500.0 3.0" $ns at 5.0 "$node_(27) setdest 300.0 300.0 3.0" $ns at 5.0 "$node_(39) setdest 10.0 40.0 3.0" $ns at 5.0 "$node_(35) setdest 250.0 60.0 3.0" $ns at 5.0 "$node_(31) setdest 100.0 50.0 3.0" $ns at 5.0 "$node_(32) setdest 1.0 250.0 3.0" $ns at 5.0 "$node_(38) setdest 80.0 10.0 3.0" $ns at 5.0 "$node_(45) setdest 1.0 500.0 3.0" $ns at 10.0 "$node_(49) setdest 250.0 250.0 3.0" $ns at 15.0 "$node_(47) setdest 75.0 210.0 3.0" $ns at 15.0 "$node_(42) setdest 1.0 500.0 3.0" $ns at 5.0 "$node_(43) setdest 300.0 300.0 3.0" $ns at 5.0 "$node_(44) setdest 10.0 40.0 3.0" $ns at 10.0 "$node_(50) setdest 250.0 250.0 3.0" $ns at 15.0 "$node_(61) setdest 75.0 210.0 3.0" $ns at 15.0 "$node_(72) setdest 1.0 500.0 3.0" $ns at 5.0 "$node_(83) setdest 300.0 300.0 3.0" $ns at 5.0 "$node_(94) setdest 10.0 40.0 3.0" $ns at 5.0 "$node_(55) setdest 250.0 60.0 3.0" $ns at 5.0 "$node_(66) setdest 100.0 50.0 3.0" $ns at 5.0 "$node_(87) setdest 1.0 250.0 3.0" $ns at 5.0 "$node_(98) setdest 80.0 10.0 3.0" $ns at 5.0 "$node_(79) setdest 1.0 500.0 3.0" $ns at 10.0 "$node_(99) setdest 250.0 250.0 3.0" $ns at 15.0 "$node_(67) setdest 75.0 210.0 3.0" $ns at 15.0 "$node_(56) setdest 1.0 500.0 3.0" $ns at 5.0 "$node_(73) setdest 300.0 300.0 3.0" $ns at 5.0 "$node_(74) setdest 10.0 40.0 3.0" $ns at 5.0 "$node_(88) setdest 250.0 60.0 3.0" $ns at 5.0 "$node_(71) setdest 100.0 50.0 3.0" $ns at 5.0 "$node_(89) setdest 1.0 250.0 3.0" $ns at 5.0 "$node_(92) setdest 80.0 10.0 3.0" $ns at 5.0 "$node_(77) setdest 1.0 500.0 3.0"

76

$ns at 10.0 "$node_(76) setdest 250.0 250.0 3.0" $ns at 15.0 "$node_(54) setdest 75.0 210.0 3.0" $ns at 15.0 "$node_(65) setdest 1.0 500.0 3.0" $ns at 5.0 "$node_(82) setdest 300.0 300.0 3.0" $ns at 5.0 "$node_(60) setdest 10.0 40.0 3.0" # Criação dos agentes: transporte e aplicação set tcp1 [new Agent/TCP/Sack1]; $tcp1 set class_ 1 $tcp1 set packetSize_ ; $ns attach-agent $node_(9) $tcp1 ; set sink1 [new Agent/TCPSink]; $ns attach-agent $node_(0) $tcp1 $ns attach-agent $node_(9) $sink1; $ns connect $tcp1 $sink1; set ftp1 [new Application/FTP]; $ftp1 attach-agent $tcp1; # Posição dos nós no NAM for {set i 0} {$i < $val(nn)} { incr i } { # Tamanho do nó no NAM = 30 $ns initial_node_pos $node_($i) 30 } # Fim da Simulação NAM $ns at $val(stop) "$ns nam-end-wireless $val(stop)" $ns at $val(stop) "stop" $ns at 150.00 "$ns halt" proc stop {} { global ns tracefd namtrace $ns flush-trace exec nam Trace_TCC100.nam & close $tracefd close $namtrace } $ns at 10.0 "$ftp1 start" $ns run

77

APÊNDICE D – Script de avaliação da vazão (throughput)

BEGIN { tam_recv = 0 tempo_inicial = 1e6 tempo_final = 0 } { if ($2 == "-t") { acao = $1 tempo = $3 nodo_id = $5 flow_id = $39 pacote_id = $41 pacote_tam = $37 flow_t = $45 level = $19 } # Guarda o Tempo Inicial if (level == "AGT" && (acao == "+" || acao == "s") && pacote_tam >= 512) { if (tempo < tempo_inicial) { tempo_inicial = tempo } } # Total de Pacotes Recebidos, Tamanho e Tempo if (level == "AGT" && acao == "r" && pacote_tam >= 512) { if (tempo > tempo_final) { tempo_final = tempo } # Pega o Cabeçalho tam_cab = pacote_tam % 512 pacote_tam -= tam_cab # Guarda o tamanho dos pacotes recebidos tam_recv += pacote_tam } } END {

printf("Média Throughput[kbps] = %.2f\t\t tempo_inicial=%.2f\ttempo_final=%.2f\n",(tam_recv/(tempo_final-tempo_inicial))*(8/1000),tempo_inicial,tempo_final)

}

78

APÊNDICE E – Script de avaliação do delay e pacotes perdidos

BEGIN { type=type; enviado=0; recebido=0; pacotes_roteados=0.0; bytes_perdidos=0; pacotes_perdidos=0; id_pacote_maior =0; total=0; cont_recv=0; } { tempo = $3; pacote_id = $41; if (($1 == "r") && ($5 == "9")) { recebido++; } # CALCULO DELAY if ( tempo_inicial[pacote_id] == 0 ) tempo_inicial[pacote_id] = tempo; if ($1 == "r") {

tempo_final[pacote_id] = tempo; }

else {

tempo_final[pacote_id] = -1; } # PACOTES PERDIDOS if (( $1 == "d" ) && ( $3 > 0 )) { bytes_perdidos=bytes_perdidos+$37; pacotes_perdidos=pacotes_perdidos+1; } # PROCURA DO NUMERO DE PACOTES if (pacote_id > id_pacote_maior) id_pacote_maior = pacote_id; } END

79

{ for ( i in tempo_final ) { inicio = tempo_inicial[i]; fim = tempo_final[i]; duracao_pacote = fim - inicio; if ( duracao_pacote > 0 ) { total += duracao_pacote; cont_recv++; } } delay=total/cont_recv; printf("Recebido = %.2f\n",recebido); printf("Media Delay (ms)= %.2f\n",delay*1000); printf("Pacotes Perdidos = %d\n",pacotes_perdidos); }

Documents

BRUNO NIETO - biblioteca.unilasalle.edu.br · movimentar de maneira independente, modificando a topologia da rede sem prévio aviso, tornando o roteamento um grande desafio. Sabe-se