UNIVERSIDADE DE BRASÍLIA FACULDADE DE TECNOLOGIA DEPARTAMENTO DE ENGENHARIA ELÉTRICA UMA FERRAMENTA PARA ANÁLISE DE DESEMPENHO DE REDES CONVERGENTES ITALO AMARAL BRITO VINÍCIUS MACÊDO DE SOUSA ORIENTADORES: ANTÔNIO J. MARTINS SOARES HUMBERTO ABDALLA JÚNIOR PROJETO FINAL DE GRADUAÇÃO EM ENGENHARIA DE REDES DE COMUNICAÇÃO BRASÍLIA / DF: JAN/2005
66
Embed
UMA FERRAMENTA PARA ANÁLISE DE DESEMPENHO DE …wpage.unina.it/pescape/cit/PFG.222004.pdfse numa plataforma de testes mais completa para análises de desempenho de redes convergentes.
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
UNIVERSIDADE DE BRASÍLIA FACULDADE DE TECNOLOGIA
DEPARTAMENTO DE ENGENHARIA ELÉTRICA
UMA FERRAMENTA PARA ANÁLISE DE DESEMPENHO DE REDES CONVERGENTES
ITALO AMARAL BRITO VINÍCIUS MACÊDO DE SOUSA
ORIENTADORES: ANTÔNIO J. MARTINS SOARES HUMBERTO ABDALLA JÚNIOR
PROJETO FINAL DE GRADUAÇÃO EM ENGENHARIA DE REDES DE COMUNICAÇÃO
BRASÍLIA / DF: JAN/2005
UNIVERSIDADE DE BRASÍLIA FACULDADE DE TECNOLOGIA
DEPARTAMENTO DE ENGENHARIA ELÉTRICA
UMA FERRAMENTA PARA ANÁLISE DE PERFORMANCE DE REDES CONVERGENTES
ITALO AMARAL BRITO VINÍCIUS MACÊDO DE SOUSA
PROJETO FINAL DE GRADUAÇÃO SUBMETIDO AO DEPARTAMENTO DE ENGENHARIA ELÉTRICA DA FACULDADE DE TECNOLOGIA DA UNIVERSIDADE DE BRASÍLIA, COMO PARTE DOS REQUISITOS NECESSÁRIOS PARA A OBTENÇÃO DO GRAU DE ENGENHEIRO DE REDES COMUNICAÇÃO. APROVADA POR:
ANTÔNIO J. MARTINS SOARES, Doutor, UnB (ORIENTADOR)
LÚCIO MARTINS DA SILVA, Doutor, UnB (EXAMINADOR)
PRISCILLA SOLÍS BARRETO, Mestre, UnB (CO-ORIENTADORA) DATA: BRASÍLIA/DF, 13 DE JANEIRO DE 2005.
A Deus, nossos pais, irmãos e a todos que nos ajudaram direta e indiretamente nessa conquista.
AGRADECIMENTOS Aos nossos orientadores Prof. Dr Antônio J. Martins Soares, Prof. Dr Humberto Abdalla Júnior pelo apoio, incentivo, dedicação e amizade essenciais para o desenvolvimento deste trabalho e para o nosso desenvolvimento como pesquisadores. Aos Pesquisadores do Laboratório de Comunicações da Universidade de Brasília – LabCom – UnB, em especial Priscilla Barreto e Georges Amvame-Nze pela paciência, dedicação, atenção, motivação, direcionamento dos trabalhos bem como pela amizade construída ao longo do processo. Ao bolsista do Labcom Rafael Sampaio por ter nos ajudado bastante no desenvolvimento desse trabalho e, especial na programação. A todos, os nossos sinceros agradecimentos.
RESUMO
Este trabalho apresenta um software que tem como objetivo analisar o desempenho de redes utilizando parâmetros de QoS (Qualidade de Serviço). O software integra as funcionalidades de várias ferramentas de código aberto e foi desenvolvido na linguagem de programação JAVA. Espera-se que sua utilização permita, através da geração de tráfego, a simulação das diversas aplicações em uma rede real e a realização de experiências que envolvam análise de desempenho de redes, agilizando e facilitando as atividades do pesquisador de redes.
ABSTRACT This work presents a software that aims at analyzing network performance using QoS (Quality of Service) parameters. The software integrates the functionalities of a sort of open source tools and was developed using JAVA programming language. It is expected that its utilization permits, by generating traffic, the simulation of various applications in a real network and performing experiments that involve network performance analysis, making faster and easier the network researchers’ activities.
Na Figura 4.8 pode-se observar que os fluxos de tráfego mapeados em classes de
maior precedência sempre mantêm a utilização de banda que precisam, enquanto os
fluxos com menor precedência, tais como o CBR12, fazem uso da banda restante,
independentemente da sua necessidade. As perdas médias por fluxo para o MPLS-DS
foram iguais a zero para os tráfegos CBR1 e CBR2, igual a 36,7% para o tráfego
CBR12 e de 26,3% para VBR2. Dessa forma, os fluxos marcados como EF e AF11 não
sofreram perdas, enquanto o fluxo marcado como BE foi o que apresentou a maior
perda.
Como no ambiente anterior, foi realizada uma conexão VoIP no intervalo de
duração dos fluxos, mas, especificamente neste caso, a classe outorgada para esta
ligação foi a EF, de tal forma que se busca beneficiar a precedência deste fluxo dentro
da rede. O resultado da avaliação MOS para os codecs G711 e G729 utilizados no
telefone IP foram iguais, respectivamente, a 4,3 e 3,5.
A partir desses resultados, é evidenciado o benefício alcançado com a
implementação da classificação de tráfego. No ambiente MPLS-DS, existe uma latência
maior que a observada na plataforma MPLS-BE, mas é importante observar que no
ambiente com DiffServ, o processo de classificação de pacotes e a sua verificação
introduzem um overhead significativo, especialmente quando se tratar de pacotes com
menor tamanho. Nos experimentos realizados, esse processo de classificação teve
implicação no cálculo da latência.
No segundo experimento, foi introduzida uma variação nos fluxos de tráfego,
sendo que um dos fluxos VBR foi substituído por um CBR classificado como melhor
esforço. Esta mudança foi motivada sob a consideração de que um fluxo de taxa
constante viria a perturbar mais a medição de atraso ou perda de pacotes de outros
fluxos, em função da sua necessidade uniforme de banda. Outros experimentos
utilizando um fluxo VBR classificado como BE não mostraram resultados de latência
muito diferentes dos obtidos no ambiente MPLS-DS [20].
Apesar de existir uma latência maior na plataforma MPLS-DS, as perdas de
pacotes são consideravelmente menores. Esse resultado é contrário ao esperado e se
34
justifica pelo processo de classificação associado a cada fluxo de tráfego, que
influenciou diretamente no cálculo da latência. Identifica-se então, uma carência na
implementação de código aberto do MPLS/DiffServ.
Figura 4.8 – Distribuição de banda no MPLS-DS.
Figura 4.9 – Latência no MPLS-DS
35
Os resultados de perda e latência correspondem à percepção dos usuários na
avaliação MOS das conexões VoIP. O uso de um ou outro tipo de codec influencia, mas
o bom desempenho da rede é um fator fundamental para uma boa avaliação subjetiva.
4.4.5. CONCLUSÃO DO ESTUDO DE CASO
Os resultados descritos acima levam a pensar que o processo de realização de
testes de avaliação é simples. Entretanto muitas das vezes o grande problema que
inviabiliza a realização desses testes é a grande quantidade de ferramentas utilizadas, a
quantidade de comandos necessários e a inexistência de uma única ferramenta gráfica
que possibilite a realização dos experimentos de uma forma simples e correta. Para
resolver este situação, a proposta desse trabalho foi o desenvolvimento de uma
ferramenta que convergisse todas as aplicações existentes atualmente para uma única
ferramenta gráfica que fizesse todas as operações necessárias como se fossem uma só.
Essa ferramenta, sua arquitetura e sua topologia serão abordadas no capítulo seguinte.
4.5. CONCLUSÃO
Este capítulo abordou a problemática relacionada à medição de QoS. A
discussão permitiu concluir que a medição, sempre que possível, deve considerar a
hipótese de se utilizar uma carga controlada de tráfego (medição ativa), pois esta
abordagem permite uma maior precisão e um melhor conhecimento da capacidade da
rede e do comportamento dos mecanismos de priorização. Por fim foi ilustrado um
estudo de caso a fim de exemplificar essa problemática bem como os resultados obtidos.
No próximo capítulo será mostrada a ferramenta desenvolvida ao longo desse trabalho
para a análise de desempenho de redes bem como a sua arquitetura e funcionamento.
36
5. APRESENTAÇÃO DO SOFTWARE
A seguir, será apresentado o software desenvolvido, de nome Analisador,
primeiramente será feita uma análise da forma em que ele está estruturado e sua função
principal, depois a estrutura estática e dinâmica das classes JAVA que o compõem e,
finalmente, sua interface gráfica, os processos que realiza e o modo de operação.
5.1. NECESSIDADE DO SOFTWARE
Da prática de experimentos, simulações e testes no laboratório, pôde-se perceber
que são muitas e variadas as atividades a se executar no ambiente para que ele esteja
pronto para os testes. Notou-se também que muitas dessas atividades são comuns a
todos os ambientes, por exemplo, a geração de dados de um lado e sua captação do
outro, cálculo de medidas de desempenho e sua visualização gráfica.
Todas essas atividades tinham de ser executadas muitas vezes, visto a
diversidade dos testes. Essa situação atrasava e dificultava bastante as análises porque
se perdia muito tempo com a preparação para cada teste. Daí surgiu a idéia da
automatização, de forma que o usuário pudesse fazer testes sem precisar conhecer que
comandos executar, que sintaxe usar, qual a seqüência certa, nem esquecer um ou outro
item essencial ao teste. Além disso, há um maior controle das variáveis, já que o mesmo
teste pode ser repetido da mesma maneira, com os mesmos parâmetros usados em outra
ocasião.
5.2. CONVERGÊNCIA DE APLICATIVOS
A ferramenta desenvolvida integra vários softwares já existentes e mencionados
no capítulo 3, mas que realizam tarefas individuais. Assim, o usuário tem um só
software, com uma interface única, muito mais simples de se operar.
O aplicativo configura o gerador de tráfego MGEN [10] na origem e no destino,
com scripts que serão gerados a partir de entradas do usuário. Cada script contém um ou
mais fluxos com informações de duração, tamanho de pacote, taxa de transmissão,
marcação do campo ToS e outras.
37
Após isso, inicia-se a geração e escuta do tráfego concomitante nas estações. Na
origem, inicia-se a geração com base no script montado e, no destino, a operação feita é
iniciar o escutador e pará-lo logo após o fim da transmissão.
Segue-se a isso a transformação do log da transação em um arquivo plotável.
Esse arquivo contém instruções para a montagem do gráfico, tais como legendas, cores,
etc. Com esse arquivo, pode-se usar um software de plotagem, por exemplo o gnuplot,
para traçar os gráficos e mostrar na tela do usuário. Além disso, o gráfico também é
exportado em um arquivo de imagem.
Finalmente, o aplicativo reúne na estação cliente os arquivos de resultado do
processo para posterior análise das informações, seja ela humana ou por meio de um
software especializado, por exemplo, o MatLab.
5.3. VANTAGENS
Uma das vantagens de se ter uma plataforma desse tipo é não ser mais
necessário o uso de comandos enormes, várias ferramentas a serem controladas,
conhecimento e praticidade no uso das ferramentas para realizar os testes e simulações
no ambiente de rede.
As principais vantagens do uso de tal ferramenta são:
• Produtividade: Sem a preocupação de realizar o procedimento, e sendo
este feito de forma automatizada, o usuário pode tirar suas conclusões
mais rapidamente;
• Padronização: Uma vez salvos, os testes podem ser executados quantas
vezes forem necessárias, sempre da mesma maneira, significando maior
controle das variáveis por parte do usuário.
38
5.4. DESCRIÇÃO DO SOFTWARE
A ferramenta desenvolvida consiste em um aplicativo cujo código foi escrito na
linguagem JAVA, escolhida pela sua portabilidade. Dessa forma, a aplicação pode ser
executada a partir de uma plataforma Windows, Linux ou outras.
5.4.1. SINCRONISMO
O sincronismo entre as estações origem e destino é uma questão que afeta
diretamente as medições, principalmente a medida do atraso e do jitter. Portanto, o
Analisador provê um mecanismo para checar se as estações estão sincronizadas entre si
antes de começar a geração de dados.
Para realizar o sincronismo entre as estações, é utilizada a ferramenta chrony,
descrito no capítulo 4. O chrony tem um utilitário que permite verificar se as estações
estão sincronizadas.
Clicando-se no botão de verificar sincronismo, o software verifica se as estações
estão sincronizadas e, portanto, prontas para começar a simulação. Para prover mais
informações ao usuário, é mostrada uma janela com várias informações. Assim, se o
sincronismo não estiver OK, o programa fornece informações sobre o que pode estar
errado, para que o usuário possa solucionar o problema facilmente. Se a simulação for
iniciada sem essa verificação prévia, corre-se o risco de as medidas de atraso e jitter não
traduzirem a realidade. Como o tempo de convergência do protocolo NTP (Network
Time Protocol) é variável, o usuário deverá sempre checar o sincronismo antes de
realizar uma medição e ter certeza que o protocolo NTP está rodando.
O mecanismo de sincronismo usado é o provido pelo protocolo NTP,
especificado na RFC 1305. Segundo a RFC, o overhead causado na rede depois de
sincronizados os clientes é quase nulo e o algoritmo de sincronização utilizado está
documentado no apêndice G da própria RFC.
39
5.4.2. UML
Como é comum no desenvolvimento de software, foi elaborado um modelo no
formato Unified Modeling Language (UML) para dar suporte à programação do código
e também para facilitar o entendimento da aplicação por meio de diagramas. Essa
estrutura envolve os seguintes diagramas: “Casos de Uso”, “Estrutura Estática”,
“Diagrama de Seqüência”.
O diagrama de Casos de Uso indica as ações que o usuário do sistema poderá
executar, ilustrado na figura 5.1.
Figura 5.1 – UML Diagrama de Casos de Uso
O diagrama de Classes ou Estrutura Estática mostra as classes que compõem o
sistema, os atributos e métodos de cada uma e o relacionamento entre uma classe e
outra, como indica a figura 5.2.
Para o software Analisador, foi usado um pacote de classes auxiliar, o Jakarta
Commons Net (commons-net-1.2.2.jar), para fazer as operações de Telnet e FTP
realizadas no programa. Essas operações são a base da comunicação do programa com
as estações envolvidas. Elas possibilitam que o programa seja executado remotamente, a
partir de qualquer estação que tenha conexão IP com os nós origem e destino.
Quanto às classes próprias do programa, tem-se primeiramente a classe Config,
que lê o arquivo de configuração, com a localização dos programas necessários nas
40
estações origem e destino. A classe Startup é o coração do programa, ela inicializa a
janela principal, cria instâncias das outras classes e dá início aos processos de geração
de tráfego e medição dos parâmetros de QoS.
A classe Host é um objeto usado para representar as estações origem e destino
do tráfego. A classe Traffic é um objeto para representar cada tráfego adicionado pelo
usuário. A classe NewTrafficDialog reúne todo o procedimento envolvido na adição de
um tráfego à simulação, da abertura da janela à adição das entradas no script.
A classe TrafficFile permite que aconteçam as operações de Salvar e Carregar
Ambiente. Ela é o objeto que representa o ambiente inteiro, criado e gerenciado pelo
usuário.
A classe SyncCheck é responsável por fazer o telnet para as duas estações,
origem e destino, e checar o sincronismo através do utilitário chronyc. O resultado dessa
verificação é mostrado na tela, com informações sobre o servidor que está provendo o
relógio principal, e se o relógio das máquinas já pode ser sincronizado ou não.
41
Figura 5.2 – UML Diagrama de Classes
Para mostrar as interações entre as entidades envolvidas no processo de
execução do sistema, e sua distribuição temporal, há o diagrama de Seqüência,
mostrado na figura 5.3. Neste diagrama há quatro entidades: o usuário do sistema, o
software Analisador de desempenho, as estações origem e destino do tráfego.
42
Os eventos iniciados a partir do usuário são basicamente aqueles causados pelo
pressionamento dos botões da tela principal, eles são:
• adicionar fluxo;
• executar simulação;
• abrir ambiente;
• salvar ambiente;
• verificar sincronismo.
Os outros eventos são conseqüência de algum comando do usuário e são
necessários para completar a ação. Note que muita ação é automatizada pelo programa,
ao contrário do que ocorria anteriormente, quando quase todas tinham de ser executadas
manualmente pelo usuário a partir de estações diferentes, por meio de ações cujos
comandos são quase impossíveis de decorar. Daí o benefício do uso do programa.
Os eventos indicados pela meia-seta ( ) não acontecem ou não
precisam acontecer exatamente na seqüência mostrada, os demais acontecem na mesma
seqüência que mostra o diagrama. As setas tracejadas indicam resposta a um
procedimento feito no sentido contrário.
43
Figura 5.3 – UML Diagrama de Seqüência
A partir desses diagramas UML é possível entender melhor como está
estruturado o programa e como foi pensado o seu desenvolvimento.
5.4.3. PROGRAMA ANALISADOR
A partir da tela principal, mostrada na figura 5.4, o usuário pode criar um novo
ambiente, salvá-lo ou carregar um ambiente salvo previamente. Para carregar um
ambiente já existente, é suficiente clicar no botão de abrir ambiente, e escolher um
arquivo de ambiente. Fazendo isso, as informações daquele ambiente, incluindo destino,
44
origem, credenciais de telnet e ftp, bem como todos os fluxos adicionados, serão
carregadas na tela e o usuário pode executar a simulação carregada.
Figura 5.4 – Tela principal do programa
O ambiente de teste é salvo como um objeto JAVA, de forma que é possível
futuramente fazer esse arquivo ser lido por outra aplicação JAVA que use essas
informações para, por exemplo, gerência SNMP do ambiente testado, ou geração
automatizada de um relatório do teste. As linhas a seguir mostram o formato do arquivo
de ambiente.
public class TrafficFile {
private String srcIp;
private String srcTelnetUser;
private String srcTelnetPasswd;
private String dstIp;
private String dstTelnetUser;
private String dstTelnetPasswd;
45
private String dstFtpUser;
private String dstFtpPasswd;
private Vector traffics;
}
Para salvar um dado ambiente, o usuário pode tanto partir do zero, operação
normal, quanto partir de um ambiente já salvo. Para isso, basta carregar o ambiente
anterior e salvar as alterações com outro nome, veja na figura 5.5.
Figura 5.5 – Tela de Salvar ambiente
Essas funcionalidades fazem com que o programa ajude o usuário no
gerenciamento dos arquivos relativos às simulações para, por exemplo:
• organização da matéria-prima dos testes;
• necessidade de realizar um teste várias vezes;
• necessidade de realizar testes diferentes, mas semelhantes entre si;
46
• elaboração de relatórios descritivos da simulação.
Escolhido um ambiente de teste, a tela principal contém todos os dados relativos
a esse ambiente. Um ambiente requer a configuração dos seguintes campos:
• IP de origem do tráfego (gerador)
• IP de destino do tráfego (receptor)
• Credenciais (usuário e senha) de telnet na origem
• Credenciais (usuário e senha) de FTP e telnet no destino
• Fluxos a serem gerados, que incluem, cada um:
o Porta de origem
o Porta de destino
o Tipo de fluxo (Periódico, Poisson ou Rajada)
o Tempo de início e fim (em segundos)
o Taxa de pacotes
o Tamanho de pacotes
o Parâmetros adicionais
Para fazer a adição de fluxos, basta clicar no botão da janela principal e uma
janela se abrirá para a especificação do fluxo. Exemplos das janelas de fluxo podem ser
vistos na figura 5.6.
47
Figura 5.6 – Janelas de Fluxo: Tráfego Periódico e de Rajada
O usuário deve manter os valores dentro de um limite razoável, considerando:
• tamanho mínimo e máximo dos pacotes UDP: 28 a 8192 bytes
• taxa de transmissão máxima dos enlaces, tal que [TAXA DE
ENVIO]x[TAMANHO DO PACOTE]x8 não ultrapasse a velocidade do
enlace total (de uma ponta a outra).
• tempo de fim do fluxo maior que tempo de início.
Os fluxos têm três perfis possíveis, conforme especificações da ferramenta
MGEN [10]:
• Periódico: fluxo de tráfego de taxa constante, também chamado CBR
(Constant Bit Rate).
• Poisson: Esse padrão gera mensagens de tamanho fixo em intervalos
variando estatisticamente em uma taxa fixa, especificada pelo usuário,
genericamente conhecido como VBR.
48
• Rajada: gera rajadas de outros padrões (Periódico e Poisson) em um
intervalo médio especificado. Outro parâmetro do padrão Rajada é
Regular resultando em rajadas de duração específica distribuídas
uniformemente no tempo, ou Aleatório que distribui exponencialmente
as rajadas no tempo em intervalos de duração média especificada pelo
parâmetro “Intervalo”. Genericamente conhecido como VBR
Terminada a configuração do ambiente, o usuário dá início à execução do
processo clicando no botão da tela principal.
Nesse momento são iniciados remotamente procedimentos nas duas estações
(origem e destino do tráfego) para gerar os fluxos e colher os resultados referentes à
medição do tráfego.
Após serem passadas todas as informações sobre a simulação, o programa inicia
uma série de procedimentos para que a simulação ocorra. Como foi comentado
anteriormente, o software desenvolvido utiliza várias ferramentas para realizar o
processo de geração e medição. Esse processo ocorre da seguinte maneira.
De posse dos endereços IP das máquinas de origem e destino, o programa realiza
uma conexão telnet nessas máquinas a fim de controlar os processos que serão iniciados
em cada uma das máquinas. Após essa etapa, são passados para a máquina de origem os
parâmetros do tráfego a ser gerado. Na máquina de destino é informado que será
iniciada uma medição. Com isso, o processo de geração de trafego é iniciado entre as
duas máquinas. Ao término da geração, a máquina de origem informa ao programa o
final da simulação que por sua vez informa à máquina destino para iniciar o
procedimento de geração dos gráficos. Nesse processo, uma outra ferramenta, o TRPR,
é utilizada para fazer o tratamento dos dados. Ao final dessa etapa, todos os gráficos
referentes a simulação estão presentes na máquina de destino. Sendo assim, o programa
realiza uma conexão FTP no destino e busca todos os gráficos gerados. Esses gráficos
são armazenados na máquina onde se executa o programa analisador de desempenho.
Após todos esses procedimentos, os resultados são mostrados na tela do usuário;
este pode fazer sua análise e repetir a simulação se for o caso.
49
5.5. CONSIDERAÇÕES SOBRE A APLICABILIDADE
O software foi feito para ser aplicável em qualquer rede, não importando que
tipos de gateways, comutadores, enlaces ou protocolos estão entre a origem e o destino.
Somente as estações de origem e destino do tráfego precisam obedecer a alguns
requisitos. Sendo assim, pode-se usar, por exemplo, duas estações móveis (notebooks)
como origem e destino e o software poderá ser usado onde quer que sejam levadas essas
estações móveis.
Devido o uso das ferramentas mencionadas no item 5.2, é necessário ter nas
máquinas origem e destino um conjunto de softwares, que são os usados pelo programa
Analisador para fazer os testes. Esses requisitos são mostrados no quadro a seguir:
Máquina Origem Máquina Destino Sistema Operacional Linux Sistema Operacional Linux Utilitário para geração de tráfego MGEN Utilitário para geração de tráfego MGEN Sincronização Chrony Sincronização Chrony Utilitário para tratamento dos dados TRPR Utilitário para plotagem de gráficos Gnuplot Servidor FTP para transferência dos
resultados FTPd
As referências [10], [17] e [21] ensinam como instalar alguns desses utilitários
5.6. CONCLUSÃO
Este capítulo teve como função mostrar qual o layout do software, como ele
funciona e como o usuário pode operá-lo, além de dar uma idéia da sua estrutura de
classes, como foi desenvolvido. Essas informações, além de apresentar a interface
gráfica e mostrar o modo de operação, buscam servir de matéria prima para
desenvolvedores realizarem outros softwares que permitam ainda mais operações e
melhore ainda mais o ferramental de análise de QoS existente.
Como se trata de um software que tem por objetivo a praticidade, nada melhor
para compreendê-lo que vê-lo na prática, em funcionamento. Por isso, esperamos que o
capítulo que aqui termina tenha servido como estímulo para o uso do software, ocasião
na qual o entendimento e o objetivo desse capítulo realmente se completam.
50
6. CONCLUSÕES
A necessidade de conhecer as características das redes de comunicação,
principalmente a Internet, é cada vez maior. A forma como a Internet foi concebida,
baseada na técnica de comutação de pacotes com o uso de datagramas e sem nenhuma
reserva de banda nem priorização, impede que garantias da qualidade do serviço sejam
oferecidas. Conseqüentemente, dificulta que aplicações com requisitos mínimos para
um bom funcionamento sejam implantadas. Por isso, conhecer o estado e as
características da rede é fundamental para a implementação desse tipo de aplicações. 0
O objetivo deste trabalho foi fazer uma avaliação de métricas obtidas através de
medições ativas. Algoritmos foram estudados, avaliados e implementados em um
software, para possibilitar que sejam estimados os atrasos dos pacotes, perdas, jitter e
banda utilizada. A implementação do software possibilitou uma análise das métricas
relacionadas com o desempenho em redes convergentes.
O trabalho desenvolvido durante este Projeto Final de Graduação contribuiu para
o nosso conhecimento técnico. Compreendeu-se a fundo como funciona a pilha de
protocolos TCP/IP em um sistema operacional Linux, as operações que o kernel realiza
e vislumbrou-se a ampla gama de operações que as ferramentas atuais permitem fazer
em uma rede IP, tudo a partir de um kernel Linux.
Além disso, também foi possível compreender melhor as motivações, a
importância e os mecanismos de Qualidade de Serviço nas redes de pacotes. Com mais
profundidade, estudou-se os modelos de priorização de tráfego e o modelo de QoS mais
usado atualmente, o DiffServ.
Além da imensa serventia em termos de conhecimento acadêmico e prático, este
projeto teve um segundo e não menos importante propósito, que foi o de prover aos
pesquisadores, em especial aos do LabCom, uma ferramenta que agilize e torne mais
fácil a tarefa constante de realizar medições e simulações com variados perfis de tráfego
transportados por topologias de rede diversas. Atentando para os trabalhos produzidos
pelo laboratório nos anos de 2003 e 2004, percebe-se que essa atividade de medição tem
51
sido fator fundamental na realização dos experimentos descritos. Acredita-se que o
presente projeto vai diminuir o tempo gasto com a operacionalidade do teste,
possibilitando mais foco na análise dos resultados por parte do pesquisador.
Apesar da implementação do software estar concluída, trabalhos futuros podem
ser desenvolvidos a partir do desenvolvimento deste trabalho e outras implementações
podem ser adotadas, uma delas seria a integração com o software de medição passiva
atualmente em desenvolvimento no LabCom. Com a integração desses softwares será
possível uma análise mais completa utilizando tanto medições ativas quanto passivas.
52
7. TRABALHOS FUTUROS
Ao final do desenvolvimento do software, notaram-se alguns detalhes que
seriam bastante úteis ao usuário, enriquecendo a ferramenta, e que não puderam ser
implementadas durante este projeto final por não haver tempo hábil para tanto.
Trataremos as mais importantes neste capítulo, procurando dar idéias a quem se
interessar pela continuidade do desenvolvimento.
Uma possibilidade que foi enxergada desde o início do projeto foi a integração
com um software de medição passiva de redes. Usando tanto a medição passiva quanto
a ativa, o usuário pode ter dados instantâneos com a ativa e também ter dados históricos
com a passiva, pouquíssimas ferramentas hoje disponíveis permitem essas duas visões.
Outra sugestão seria quanto à customização dos gráficos mostrados ao usuário.
O programa hoje não permite a alteração dos parâmetros de plotagem, eles são fixos.
Mas o usuário poderia dispor de uma janela onde informasse escala, distância entre os
pontos do gráfico etc. Além disso, o usuário teria a opção de gerar um arquivo com os
dados para plotagem em outro programa, ou mesmo geração de tabelas e dados
estatísticos.
Outra função imaginada foi a visualização gráfica da topologia que está entre o
nó origem e o nó destino. Isso seria mais factível através do uso do protocolo SNMP.
E, por fim, uma questão que foi muito trabalhada mas que não obteve uma
solução ideal: o sincronismo entre as estações. O software atualmente só checa se as
estações estão sincronizadas. Uma evolução dele poderia fazer o sincronismo ser
forçado, ou seja, o sincronismo acontecer ao comando do usuário. Assim, quando o
usuário dá o comando de início do sincronismo, o programa inicia o processo nas
máquinas origem e destino, espera o tempo de convergência dos relógios e avisa o
usuário quando estiverem prontas para a simulação.
53
8. REFERÊNCIAS
[1] IP Quality of Service - Cisco Press, 18 de Janeiro de 2001 - ISBN 1-57870-116-3
[2] NAGLE, JOHN, RFC 896 - Congestion control in IP/TCP internetworks, IETF, 6 de Janeiro de 1984
[3] BRADEN, R. , RFC 1122 - Requirements for Internet Hosts - Communication Layers, IETF, Outubro de 1989
[4] STEVENS, W. , RFC 2001 - TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms, IETF, Janeiro de 1997
[5] BERNET, Y.; BLAKE, S.; GROSSMAN, D.; SMITH, A.; RFC 3290 - An Informal Management Model for Diffserv Routers, IETF, Maio de 2002
[6] BRADEN, R.; ZHANG, L.; BENSON, S.; HERZOG, S.; JAMIN, S.; RFC 2205 - Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification, IETF, Setembro de 1997
[7] NICHOLS, K.; BLAKE, S.; BAKER, F.; BLACK, D.; RFC 2474 - Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers, IETF, Dezembro de 1998
[8] BLAKE, S.; BLACK, D.; CARLSON M.; DAVIS, E.; WANG, Z.; WEISS, W., RFC 2475 - An Architecture for Differentiated Service, IETF, Dezembro de 1998
[9] DEMICHELIS, C.; CHIMENTO P. (1999): Instantaneous Packet Delay Variation Metric for IPPM, ippm draft.
[10] Naval Research Laboratory (NRL): The Multi-Generator (MGEN) Toolset. http://manimac.itd.nrl.navy.mil/MGEN/.
[11] GROSSGLAUSER, M., E REXFORD, J., Passive traffic measurement for IP operations. To appear as a chapter in The Internet as a Large-Scale Complex System, Oxford University Press.
[12] VAN JACOBSON, C. L., E MCCANNE, S. Tcpdump ftp://ftp.ee.lbl.gov/tcpdump.tar.Z.
[13] CISCO. Netflow. ftp://www.cisco.com/netflow
[14] IPFIX WG - IETF Web Page. http://www.ietf.org/
[15] Muuss, M. Ping, 1989. ftp://ftp.arl.mil/pub/ping.shar
54
[16] [On-line] http://dsmpls.atlantis.rug.ac.be
[17] Chrony http://chrony.sunsite.dk
[18] MILLS, DAVID L., RFC 1305 - Network Time Protocol (Version 3) Specification, Implementation, IETF, Março de 1992
[19] ITU-T : Recommentaition P.800: Methods for subjective determination of transmission quality. Genève, Agosto 1996
[20] S. AVALLONE, M. ESPOSITO, A. PESCAPÈ, S.P. ROMANO AND G. VENTRE, “An Experimental Analysis of Diffserv-MPLS Interoperability”, Proceedings of 10th IEEE International Conference on Telecommunications (ICT 2003), Vol. I, pag. 281-287, IEEE Catalog Number 03EX628, Fevereiro 2003.
[21] trpr User Guide http://proteantools.pf.itd.nrl.navy.mil/trpr.html