IMPLEMENTAÇÃO DE AMBIENTE DE TESTES …lyceumonline.usf.edu.br/salavirtual/documentos/1886.pdf · AUTOMATIZADOS PARA AVALIAÇÃO DE PARÂMETROS DE QoS EM REDES DE COMUNICAÇÃO

UNIVERSIDADE SÃO FRANCISCO

Engenharia de Computação

BRUNO GALASSO MOLINARI

IMPLEMENTAÇÃO DE AMBIENTE DE TESTES

AUTOMATIZADOS PARA AVALIAÇÃO DE PARÂMETROS

DE QoS EM REDES DE COMUNICAÇÃO DE DADOS

BASEADO EM SOFTWARE LIVRE

Itatiba

2010

BRUNO GALASSO MOLINARI – RA 002200600186

IMPLEMENTAÇÃO DE AMBIENTE DE TESTES

AUTOMATIZADOS PARA AVALIAÇÃO DE PARÂMETROS

DE QoS EM REDES DE COMUNICAÇÃO DE DADOS

BASEADO EM SOFTWARE LIVRE

Monografia apresentada ao Curso de

Engenharia de Computação da

Universidade São Francisco, como requisito

parcial para obtenção do título de Bacharel

em Engenharia de Computação.

Orientador: Prof. Marcelo Augusto

Gonçalves Bardi

Itatiba

2010

AGRADECIMENTOS

Agradeço primeiramente aos meus pais, Ismael e Solange, que me deram o apoio

necessário durante toda esta minha trajetória, ajudando a alcançar meus objetivos.

À minha namorada Mariana, pela paciência, incentivo e carinho.

Ao meu orientador Prof. Marcelo Agusto Gonçalves Bardi cujo auxílio e cobranças

foram fundamentais para a realização desse trabalho.

Ao meu chefe e amigo Tadeu, pelo apoio e compreensão durante esse período.

Ao meu colega de trabalho e amigo Wallace, por ter me incentivado a ingressar na área

de engenharia.

À FTD Comunicação de Dados Ltda. pelo apoio durante a faculdade e empréstimo dos

equipamentos utilizados para realização dos testes deste trabalho.

Enfim, a todos que me apoiaram neste momento da minha vida. Obrigado.

RESUMO

Nos últimos anos, houve um crescimento em aplicações de rede que utilizam recursos

multimídia, como vídeo em tempo real, VoIP, videoconferência, telemedicina e muitas outras.

Essas aplicações normalmente exigem que a rede por onde trafegam possuam parâmetros de

qualidade de serviço (QoS) bem definidos, o que requer que muitas instalações e

configurações de rede atualmente sejam realizadas visando obter esta garantia de qualidade

para alguns serviços. Dessa forma, este trabalho objetiva desenvolver um ambiente para

testar, de forma automatizada, se a configuração de uma determinada rede está de acordo com

os parâmetros exigidos pelas aplicações conforme as informações fornecidas pelo usuário.

Todo o desenvolvimento do sistema foi realizado utilizando-se como base o sistema

operacional Linux e softwares como ping, iperf, apache, PHP e MySQL. Através de uma

interface WEB o usuário informa os parâmetros de qualidade da rede que deseja avaliar. Após

a confirmação do usuário o sistema configura automaticamente todos os softwares envolvidos

e realiza o teste em segundo plano, durante o tempo determinado pelo usuário. Ao final do

teste o sistema avalia as informações obtidas e informa os resultados ao usuário através de

tabelas, gráficos e observações sobre as condições encontradas. A partir dessas informações é

possível saber se a rede está configurada corretamente ou se são necessárias alterações em sua

configuração.

Palavras-chave: parâmetros de QoS. redes de computadores. testes.

ABSTRACT

In recent years, has been a growth in network applications that use multimedia resources like

real time video, VoIP (Voice over IP), video conference, telemedicine and many more. These

applications typically require of the network through where passing have parameters of

quality of service (QoS) well defined, what requires that many installations and network

configurations currently being performed to obtain this guarantee of quality for some services.

Thus, this work have the objective to develop an environment for testing, an automated way,

if the configuration of a network is in according to the parameters required by the

applications, based in information provided by user. All development of the system was

performed using as a base the Linux operating system and software such as ping, iperf,

Apache, PHP and MySQL. Through a Web interface, the user informs the quality parameters

of the network that want to evaluate. After user's confirming, the system automatically

configures all the software involved and conducts a test in the background during the time set

by user. At the end of the test, the system evaluates the information obtained and reports the

results to the user through tables, graphs and comments on the conditions found. From this

information it is possible to know if the network is configured correctly or if changes are

required in your configuration.

Keywords: QoS parameters. computer networks. tests.

LISTA DE FIGURAS

FIGURA 1 - Camadas TCP/IP ................................................................................................. 15

FIGURA 2 - Diagrama geral dos casos de uso ......................................................................... 35

FIGURA 3 - Diagrama de seqüência de um teste completo ..................................................... 37

FIGURA 4 - Diagrama de classes............................................................................................. 38

FIGURA 5 - Estrutura de dados ............................................................................................... 39

FIGURA 6 - Diagrama do laboratório de teste ......................................................................... 40

FIGURA 7 - Laboratório de testes visão geral ......................................................................... 43

FIGURA 8 - Laboratório de testes roteadores .......................................................................... 43

FIGURA 9 - Gráfico de atraso no teste 3 do cenário 2............................................................. 45

FIGURA 10 - Gráfico de atraso no teste 2 do cenário 2........................................................... 45

FIGURA 11 - Gráfico de atraso no teste 1 do cenário 3 ........................................................... 47

FIGURA 12 - Gráfico de atraso no teste 2 do cenário 3........................................................... 47

LISTA DE TABELAS

TABELA 1 - Classes de serviço ITU-T .................................................................................... 21

TABELA 2 - Classes de serviço e limites máximos ................................................................. 22

TABELA 3 - Configurações dos fluxos de dados no cenário 1 ................................................ 41



TABELA 6 - Resultados esperados nos testes no cenário 1 ..................................................... 44

TABELA 7 - Resultados dos testes no cenário 1 ...................................................................... 44

TABELA 8 - Resultados esperados nos testes no cenário 2 ..................................................... 45

TABELA 9 - Resultados dos testes no cenário 2 ...................................................................... 46

TABELA 10 - Resultados esperados nos testes no cenário 3 ................................................... 47

TABELA 11 - Resultados dos testes no cenário 3 .................................................................... 48

LISTA DE ABREVIATURAS E SIGLAS

AF – Assured Forwarding

BTC – Bulk Transport Capacity

Diffserv - Differentiated Service

DS – Differentiated Service

DSCP - Diffserv code point

EF – Expedited Forwarding

FIFO – First In, First Out

IETF – Internet Engineering Task Force

Intserv – Integrated Services

IP – Internet Protocol

IPDV – IP Delay Variation

IPER – IP Packet Errored Ratio

IPLR – IP Packet Loss Ratio

IPTD – IP Transfer Delay

IPPM – IP Performance Metrics

ISO – International Organization for Standardization

ITU – International Telecommunication Union

ITU-T – ITU Telecommunication Standardization Sector

OWD – One-Way Delay

PHB – Per-Hop Behaviors

PHP – Hypertext Preprocessor

QoS – Quality of Service

RFC – Request for Comments

RSVP – Resource Reservation Protocol

RTD – Round Trip Delay

RTT – Round Trip Time

SLA – Service Level Agreements

TCP – Transmission Control Protocol

TOS – Type of Service

UDP – User Datagram Protocol

UML – Unified Modeling Language

UTC – Coordinated Universal Time

VOIP – Voice over IP

WFQ – Weighted Far Queue

SUMÁRIO

1 INTRODUÇÃO ................................................................................................................... 12

1.1 OBJETIVOS ....................................................................................................................... 13

1.2 ORGANIZAÇÃO DO TRABALHO ................................................................................. 13

2 ASPECTOS TEÓRICOS .................................................................................................... 15

2.1 ARQUITETURA INTERNET E TCP/IP ............................................................................ 15

2.2 QUALIDADE DE SERVIÇO ............................................................................................ 16

2.2.1 Parâmetros de QoS .......................................................................................................... 17

2.2.1.1 Confiabilidade .............................................................................................................. 17

2.2.1.2 Delay ............................................................................................................................. 18

2.2.1.3 Jitter .............................................................................................................................. 19

2.2.1.4 Throughput ................................................................................................................... 20

2.2.1.5 Classes de Serviço ........................................................................................................ 21

2.2.2 Técnicas para Alcançar Qualidade de Serviço ................................................................ 22

2.2.2.1 Superdimensionamento ................................................................................................ 22

2.2.2.2 Armazenamento em Buffers.......................................................................................... 23

2.2.2.3 Modelagem de Tráfego ................................................................................................. 23

2.2.2.4 Mecanismos de Escalonamento .................................................................................... 24

2.2.2.4.1 FIFO .......................................................................................................................... 24

2.2.2.4.2 Prioridade .................................................................................................................. 25

2.2.2.4.3 Varredura Cíclica ....................................................................................................... 25

2.2.2.4.4 WFQ .......................................................................................................................... 25

2.2.2.5 Mecanismos de Regulação ........................................................................................... 26

2.2.2.5.1 Algoritmo de Balde Furado ....................................................................................... 26

2.2.2.5.2 Algoritmo de Balde de Símbolos ............................................................................... 27

2.2.3 Serviços Integrados e Serviços Diferenciados ................................................................ 27

2.2.3.1 Serviços Integrados ...................................................................................................... 27

2.2.3.2 Serviços Diferenciados ................................................................................................. 28

2.2.3.3 Intserv X Diffserv ......................................................................................................... 29

2.2.4 Utilização de QoS em redes ............................................................................................. 30

3 METODOLOGIA ................................................................................................................ 32

3.1 FERRAMENTAS ............................................................................................................... 32

3.2 DESENVOLVIMENTO ..................................................................................................... 33

3.3 REQUISITOS ..................................................................................................................... 34

3.4 CASOS DE USO ................................................................................................................ 35

3.4.1 Iniciar Teste Lado Mestre ................................................................................................ 35

3.4.2 Iniciar Teste Lado Escravo .............................................................................................. 36

3.4.3 Iniciar Testes Anteriores .................................................................................................. 36

3.5 DIAGRAMAS DE SEQÜÊNCIA ...................................................................................... 36

3.6 DIAGRAMA DE CLASSES .............................................................................................. 38

3.7 MODELAGEM DE DADOS ............................................................................................. 38

3.8 METODOLOGIA DE TESTES ......................................................................................... 39

3.9 LABORATÓRIO DE TESTES .......................................................................................... 40

3.10 CENÁRIOS DE TESTES ................................................................................................. 40

3.10.1 Cenário 1 ....................................................................................................................... 40

3.10.2 Cenário 2 ....................................................................................................................... 41

3.10.3 Cenário 3 ....................................................................................................................... 41

3.11 REALIZAÇÃO DOS TESTES ......................................................................................... 42

4 RESULTADOS E DISCUSSÕES ....................................................................................... 44

4.1 RESULTADOS NO CENÁRIO 1 ...................................................................................... 44



4.4 CONSIDERAÇÕES SOBRE OS RESULTADOS ............................................................. 48

5 CONCLUSÃO ...................................................................................................................... 50

5.1 EXTENSÕES ..................................................................................................................... 50

REFERÊNCIAS ..................................................................................................................... 52

REFERÊNCIAS CONSULTADAS ....................................................................................... 54

APÊNDICES ........................................................................................................................... 55

APÊNDICE A – SHELL SCRIPT PARA TRATAMENTO DOS DADOS GERADOS

PELO IPERF: APAGARESUMO.SH .................................................................................. 56

APÊNDICE B – SHELL SCRIPT PARA TRATAMENTO DOS DADOS GERADOS

PELO PING: PINGS.SH ........................................................................................................ 57

APÊNDICE C – AGENTE ESCRAVO: SERVIDOR.PHP ................................................ 58

APÊNDICE D – SCRIPT PHP PARA ARMAZENAR DADOS DO TESTE E FLUXO

NA BASE DE DADOS E INICIALIZAR O AGENTE MESTRE: SALVAR_TESTE.PHP

.................................................................................................................................................. 61

APÊNDICE E – AGENTE MESTRE: CLIENTE.PHP ...................................................... 63

APÊNDICE F – SCRIPT PHP PARA GERAR GRAFICOS: GERA_GRAFICO.PHP .. 67

APÊNDICE G – PAGINA PHP COM OS RESULTADOS E GRÁFICOS DO TESTE:

RESULTADOS_TESTE.PHP ................................................................................................ 72

APÊNDICE H – RESULTADOS COMPLETOS DO LABORATÓRIO DE TESTES ... 75

APÊNDICE I – EXEMPLOS DE TELAS DE EXECUÇÃO DO SISTEMA ................... 91

APÊNDICE J – CONFIGURAÇÕES DOS ROTEADORES ............................................ 95

12

1 INTRODUÇÃO

Nos últimos anos, houve um crescimento em aplicações de rede que utilizam recursos

multimídia, como vídeo em tempo real, VoIP , videoconferência, telemedicina e muitas outras.

Essas aplicações normalmente têm como característica uma taxa de transmissão de dados

constante e as comunicações ocorrem utilizando-se da infra-estrutura da Internet. Entretanto,

em particular as aplicações de multimídia, são muito sensíveis ao atraso fim-a-fim e a

variação do atraso, mas podem tolerar perdas de dados ocasionais [1].

O modelo da Internet trabalha com o sistema de melhor esforço, compartilhando a

largura de banda entre todos os serviços. Com a implantação de qualidade de serviço (QoS)

em uma rede, por outro lado, é possível que aplicações de multimídia e de tempo real tenham

um bom desempenho e funcionem de forma adequada.

Com o aumento da utilização dessas tecnologias que requerem cada vez mais

qualidade de serviço, muitas empresas estão instalando em suas redes equipamentos com

capacidade de prover essa qualidade de serviço, sendo necessárias ferramentas para testar e

verificar se os equipamentos instalados e as configurações realizadas estão funcionando da

maneira correta.

Para a realização de testes de QoS são necessários equipamentos específicos e

normalmente com custo elevado, como os equipamentos OneTouch™ Series II Network

Assistant [2] da empresa Fluke Networks [3] ou o SmartClass Ethernet [4] da empresa JDSU

[5], que são a linha básica de equipamentos de testes desses fabricantes e realizam testes com

somente um fluxo de dados, sendo assim não permitem testar os parâmetros de QoS de forma

completa, apenas de um fluxo, não o comportamento com diferentes fluxos, e já apresentam

custos elevados. Já equipamentos capazes de realizar testes com vários fluxos de forma

simultânea como o EtherScope™ Series II Network Assistant [6] da fabricante Fluke

Networks ou a série T-BERD/MTS [7] da JDSU, possuem um custo muito maior, muitas vezes

inviáveis para algumas empresas.

Uma alternativa para realização desses tipos de teste é a utilização de vários

computadores para gerar fluxos diferentes e coletar dados manualmente para criar e formatar

relatórios com os resultados dos testes. Normalmente, os testes são realizados utilizando a

ferramenta iperf para gerar os fluxos de dados em computadores diferentes. Como é uma

ferramenta que não possui interface gráfica e somente funciona em modo texto, é necessário

após a sua execução copiar a saída de dados no prompt e formatá-los para uma melhor

13

apresentação.

Em alguns casos são utilizados vários fluxos em um mesmo computador, sendo

necessário inserir as marcas de QoS para distinguir os fluxos; o iperf é capaz de realizar essa

tarefa. Porém, uma desvantagem nesse tipo de testes é que além de exigir vários

computadores, é necessário realizar diversas configurações, executar vários comandos em

modo texto e criar o relatório manualmente através da captura dos dados nos diversos

computadores utilizados.

Nesse contexto, uma ferramenta baseada em software livre que realize o teste e gere

relatórios de forma automatizada, aliada a não necessidade de vários computadores, traria

uma maior agilidade e redução nos custos desses procedimentos.

1.1 Objetivos

Este trabalho tem por objetivo implementar um ambiente de testes automatizados para

avaliar parâmetros de QoS em redes de comunicação de dados, utilizando ferramentas

baseadas em software livre. Os parâmetros avaliados serão atraso, variação de atraso, perda de

pacotes e garantia de banda.

1.2 Organização do Trabalho

Primeiramente será apresentada, na seção de Aspectos Teóricos, a fundamentação

teórica sobre qualidade de serviço em redes e telecomunicações, incluindo seus parâmetros

principais, técnicas para provê-la em redes, uma análise sobre as principais arquiteturas e

como a qualidade de serviço está sendo implantada e utilizada atualmente.

Em seguida, a seção de Metodologia apresenta as ferramentas e a metodologia

utilizada no desenvolvimento dos softwares que compõem o sistema, além da documentação

do sistema segundo a abordagem UML.

Na seção de Testes e Resultados serão detalhados os cenários de testes e a realização

dos mesmos. Também serão mostrados os resultados obtidos e uma análise sobre eles.

Por fim, as Conclusões apresentam os objetivos alcançados, o que pôde ser aprendido

14

durante o desenvolvimento e quais as principais contribuições desse projeto.

15

2 ASPECTOS TEÓRICOS

Esse capítulo apresenta a fundamentação teórica para o desenvolvimento do sistema e

análise dos seus resultados.

2.1 Arquitetura Internet e TCP/IP

O modelo de referência TCP/IP é utilizado como base para a Internet. É um modelo de

quatro camadas sendo elas: Física/Enlace, Rede, Transporte e Aplicação. A Figura 1 apresenta

um diagrama que representa as quatro camadas TCP/IP.

FIGURA 1 - Camadas TCP/IP

Os protocolos da Internet são uma suíte de protocolos, onde os mais conhecidos são o

TCP e o IP, que devido a sua popularidade deram o nome ao modelo de referência da Internet.

Essa suíte de protocolos inclui, além do TCP/IP, muitos outros protocolos divididos nas três

camadas superiores do modelo de referência TCP/IP [8].

16

A camada de rede da Internet fornece um único modelo de serviço conhecido como

serviço de melhor esforço. Com o serviço de melhor esforço, não há garantia de que a

temporização entre pacotes seja preservada, não há garantias de que os pacotes sejam

recebidos na ordem que foram enviados e não há garantia da eventual entrega dos pacotes

transmitidos [1].

Ainda, o serviço de melhor esforço compartilha a largura de banda entre todos os

serviços, os pacotes são encaminhados da melhor forma possível e quando há

congestionamento, os pacotes são descartados sem distinção.

2.2 Qualidade de Serviço

Segundo Oodan et al. [9], qualidade pode ser definida e expressada em termos de

parâmetros que indicam benefícios para o usuário. Esses parâmetros podem ser expressos de

forma quantitativa ou qualitativa. Um conjunto de critérios de qualidade que contêm os

benefícios de um produto ou serviço para o usuário.

A ISO define qualidade na norma ISO 8402 como “A totalidade das características de

uma entidade que lhe conferem a capacidade de satisfazer necessidades explícitas e

implícitas” [10].

A ITU define Qualidade de Serviço (QoS) na recomendação E.800, como sendo o

efeito coletivo provocado pelas características de desempenho de um serviço, determinando o

grau de satisfação do usuário do serviço [11].

A IETF considera como QoS a capacidade de segmentar o tráfego ou de diferenciar

tipos de tráfego para que a rede trate esses fluxos de forma diferente dos outros. Assim, QoS

engloba tanto a qualificação do serviço quanto o desempenho global da rede para cada

categoria. Do ponto de vista da rede, QoS é a habilidade de um elemento de rede (por

exemplo, uma aplicação, host ou roteador) de ter diferentes níveis de garantia para que o

requisitos de tráfego e serviço possam ser satisfeitos, gerenciando a banda de acordo com a

demanda dos serviços e das configurações da rede [12].

A implantação de qualidade de serviço (QoS) em uma rede, baseada na arquitetura da

Internet, é o que permite que aplicações de multimídia e de tempo real tenham um bom

desempenho e funcionem de forma adequada. Com o uso de QoS, os pacotes são marcados

para distinguir os tipos de serviços e os roteadores são configurados para criar filas distintas

17

para cada aplicação, de acordo com as prioridades das mesmas. Assim, uma faixa da largura

de banda é reservada e, no caso de congestionamento, determinados tipos de fluxos de dados

ou aplicações têm prioridade na entrega.

A qualidade de serviço é medida fim-a-fim. Mesmo que a rede seja formada por vários

elementos, o desempenho individual de cada elemento não é levado em consideração na

análise da qualidade de um serviço. A QoS é específica para cada serviço e é expressa por um

conjunto único de parâmetros [12].

2.2.1 Parâmetros de QoS

Em uma rede IP, uma seqüência de pacotes, desde uma origem até um destino, é

chamada de fluxo. As necessidades de cada fluxo podem ser caracterizadas por quatro

parâmetros principais: confiabilidade (perda de pacotes), atraso fim-a-fim (delay), variação do

atraso (jitter) e largura de banda (throughput). Juntos esses parâmetros definem a QoS que o

fluxo exige [13].

Atualmente existem dois grupos de trabalhos principais trabalhando na definição de

padrões de métricas para medição de Qualidade de Serviço em redes IP, a IPPM e a ITU-T

[14].

A IPPM é parte da IETF, e sua tarefa é desenvolver critérios sólidos para definir todos

os conceitos relacionados à métricas de desempenho. Seu foco é no desenvolvimento de

padrões de métricas que possam ser aplicados em medições de qualidade, desempenho e

confiabilidade de comunicações na Internet. Já a ITU-T usa uma abordagem mais teórica e

genérica [14].

2.2.1.1 Confiabilidade

Segundo Tanenbaum [13], a confiabilidade em redes IP está relacionada à capacidade

da mesma em entregar os pacotes transmitidos sem erros e sua medida é a quantidade de

pacotes perdidos ou com erro. A quantidade de pacotes perdidos pode ser obtida através da

comparação do número de pacotes transmitidos pela origem com o número de pacotes

18

recebidos no destino, sendo o ideal que não existam perdas de pacotes, mas isso nem sempre é

possível. Nenhum bit de um pacote pode ser entregue de forma incorreta. Em geral, esse

objetivo é alcançado calculando-se o total de verificação de cada pacote na origem e

conferindo-se o total de verificação no destino [13].

Segundo Kurose e Ross [1], em uma rede vários fatores podem contribuir para que um

pacote não seja entregue ou faça com que ele seja descartado: um erro no roteamento pode

levar o pacote a um destino errado ou não encontrar o destino correto; a queda de um enlace

durante a transmissão do pacote ou o excesso de tráfego em um roteador pode lotar os seus

buffers de saída, causando o descarte do pacote.

Diferentes tipos de aplicações podem ser mais ou menos tolerantes a falhas.

Aplicações de multimídia como, por exemplo, VOIP, dependendo da forma como a voz é

codificada e de como a perda é tratada no receptor, é capaz de funcionar com taxas de até

20% de perda de pacotes [1]. Já aplicações como correio eletrônico ou transferência de

arquivos não podem ter fragmentos das informações perdidas [13].

De acordo com Kurose e Ross [1], vemos que a perda de pacotes pode ser contornada

utilizando-se o protocolo TCP, pois o mesmo realiza a retransmissão dos pacotes perdidos,

mas essa retransmissão aumenta o atraso fim-a-fim, o que não é pode ser aceitável em alguns

tipos de aplicações, por exemplo, videoconferência.

A perda de pacotes é sempre analisada em uma direção, pois o tráfego em redes IP

pode ser assimétrico, isto é, o caminho de resposta nem sempre é o mesmo do de envio, e

porque algumas aplicações de tempo real e UDP são unidirecionais [14].

Enquanto a IPPM considera pacotes perdidos e pacotes com erro como uma única

métrica, a ITU-T define a métrica IP Packet Loss Ratio para os pacotes perdidos e a IP Packet

Errored Ratio para pacotes com erro [14].

2.2.1.2 Delay

Delay, ou atraso fim-a-fim, é o acúmulo de atrasos de processamento, atrasos de

transmissão, atraso de filas, atraso de propagação nos enlaces e atrasos de processamento em

sistemas finais [1].

Segundo Braun et al. [14], podemos considerar dois tipos de atraso:

One-Way Delay, representa o atraso em uma única direção, isto é, do host de

19

origem ao host de destino, é o tempo que se passa desde que o primeiro bit deixa a

origem até que o último bit chegue ao destino. Um problema crítico nessa

abordagem é que ambos os hosts, destino e origem, precisam estar com os relógios

sincronizados com precisão, utilizando, por exemplo, uma fonte de tempo UTC e

nem sempre isso é possível [14];

Round-Trip Delay, que é a soma do atraso nas duas direções, do envio do pacote

da origem ao destino e a reposta na direção contraria. Utiliza as marcas de tempo

na origem e é obtido através da diferença entre o tempo de envio e o tempo de

resposta [14]. Como não necessita de sincronismo de tempo entre os hosts, é mais

fácil de ser medido. Muitas aplicações realizam esse tipo de medição, por

exemplo, a ferramenta ping. Essa métrica também é conhecida como Round Trip

Time.

O atraso é uma métrica muito importante, pois descreve o grau de interatividade e a

demora de uma comunicação [14]. Por exemplo, para aplicações de áudio altamente

interativas, como o telefone por Internet, atrasos fim-a-fim menores do que 150 ms não são

percebidos pelo ouvido humano; atrasos entre 150 ms e 400 ms podem ser aceitáveis, mas não

são o ideal, e atraso que excedem 400 ms podem atrapalhar seriamente a interatividade [1].

Já aplicações não interativas, como transferência de arquivos e correio eletrônico, não

são sensíveis ao atraso. Se todos os pacotes estiverem uniformemente atrasados alguns

segundos, não haverá nenhum dano [13].

A IPPM utiliza as duas métricas, OWD e RTD, já a ITU-T define apenas a métrica IP

Transfer Delay com as mesmas características da métrica One-Way Delay [14].

2.2.1.3 Jitter

A variação de atraso nos tempos de chegada de pacotes é chamada de jitter [4].

Variação de atraso de pacote significa que os pacotes experimentam atrasos diferentes dentro

da mesma corrente de pacotes [1].

Segundo Kurose e Ross [1], a principal causa da ocorrência de jitter são os atrasos

aleatórios de fila nos roteadores, isto é, pacotes do mesmo fluxo podem passar mais ou menos

tempo na fila de saída dos roteadores no caminho.

O jitter afeta principalmente aplicações de multimídia como áudio e vídeo. Se o

20

receptor ignorar a presença de variação de atraso e reproduzir as porções de dados assim que

elas chegam, então a qualidade de áudio ou vídeo poderá facilmente se tornar ininteligível no

receptor [1].

De acordo com Kurose e Ross [1], algumas técnicas podem ser utilizadas para tentar

eliminar a variação de atraso, como a utilização de números de seqüência, marcas de tempo e

atraso de reprodução (utilização de buffers).

Em algumas aplicações, como vídeo por demanda, o jitter pode ser eliminado pelo

armazenamento em buffer no receptor, seguido pela busca de dados para exibição no buffer, e

não na rede em tempo real. No entanto, para outras aplicações, em especial aquelas que

exigem interação em tempo real entre pessoas, como telefonia via Internet e

videoconferência, o retardo inerente do armazenamento em buffer não é aceitável [13].

Segundo Braun et al. [14], tanto a ITU-T quanto a IPPM utilizam o mesmo termo para

variação de atraso, IP Delay Variation. Ele é definido como a diferença do atraso de um par

de pacotes de um mesmo fluxo, não são especificados quais pacotes devem ser usados, mas

normalmente são utilizados pacotes consecutivos. O IPDV é um número real, positivo ou

negativo, e só pode ser definido com dois pacotes. Essa métrica define os limites mínimos dos

buffers de recepção e é importante para interatividade (buffers pequenos) e qualidade da

comunicação (pacotes muito atrasados são perdidos). A ITU-T define para classes de tráfego

de tempo real o limite máximo de 50 ms de variação de atraso.

Conforme Braun et al. [14], nas definições da IPPM e da ITU-T, o IPDV é diferente do

jitter. O jitter é obtido através da diferença entre o atraso em uma direção de um pacote

especifico e a média do atraso em uma direção dos pacotes em um intervalo de tempo.

2.2.1.4 Throughput

Segundo Dattatreya [15], a definição geral para throughput de qualquer sistema é a

taxa de produção de saídas bem sucedidas. Em comunicação de dados, é a taxa total de bits,

calculada usando todos os bits dos pacotes recebidos corretamente.

Throughput também pode ser representado como largura de banda e, de acordo com

Tanenbaum [13], diferentes tipos de aplicações têm necessidades de largura de banda

diferentes, correio eletrônico e login remoto, por exemplo, não exigem muita largura de

banda, já todas as aplicações de vídeo necessitam de um grande volume desse recurso.

21

A IPPM define a métrica Bulk Transport Capacity, e a define como a capacidade

máxima de transporte de um link utilizando uma única conexão com um protocolo com

prevenção de congestionamento (isto é, TCP), onde todos os cabeçalhos, retransmissões ou

perdas são subtraídas da performance geral. E fornece uma idéia do máximo de performance

do ponto de vista do usuário quando ocorrem transferências de alto volume de tráfego[14].

A unidade de medida de throughput é em bits por segundo (bps), podendo também ser

expressa em Kbps, Mbps, Gbps, etc. [14].

O throughput é obtido dividindo o número de bits transmitidos com sucesso pelo

tempo em segundos transcorridos entre o inicio e o fim da transmissão.

2.2.1.5 Classes de Serviço

Varias grupos de criação de padrões tentam dividir os serviços em categorias (Classes

de Serviço de QoS). A ITU-T sugere a definição de seis classes resumidas na Tabela 1.

TABELA 1 - Classes de serviço ITU-T

Classe de Serviço Características

0 Tempo real, sensível ao jitter, altamente interativa

1 Tempo real, sensível ao jitter, interativa

2 Transação de dados, altamente interativa

3 Transação de dados, interativa

4 Baixa perda (transferência de dados, streaming de vídeo)

5 Aplicações padrão de redes IP

Segundo Marchese [12], a ITU-T define na recomendação Y.1541 classes de serviço

genéricas baseadas nos parâmetros de QoS apresentados anteriormente. Nessa recomendação,

a ITU-T associa cada parâmetro (IPTD, IPDV, IPLR e IPER) a um limite máximo para o

mesmo em cada classe de serviço, que refletem os requisitos para os diferentes tipos de

aplicação. Os valores para cada classe de serviço podem ser vistos na Tabela 2.

22

TABELA 2 - Classes de serviço e limites máximos

Classe de Serviço IPTD (ms) IPDV (ms) IPLR IPER

0 100 50 1x10-3

1x10-4

1 400 50 1x10-3

1x10-4

2 100 N* 1x10-3

1x10-4

3 400 N* 1x10-3

1x10-4

4 1000 N* 1x10-3

1x10-4

5 N* N* N* N*

*N – Não especificado

2.2.2 Técnicas para Alcançar Qualidade de Serviço

Na seção 2.2.1 foram identificados os requisitos de qualidade de serviço. Nesta seção

serão apresentadas as técnicas que podem ser utilizadas para garantir os requisitos e prover

qualidade de serviço.

2.2.2.1 Superdimensionamento

Uma solução prática para garantir a qualidade de serviço é fornecer tanta capacidade

de roteadores, tanto de espaço de buffers e tanta largura de banda que os pacotes

simplesmente são transmitidos com enorme facilidade [13].

Segundo Marchese [12], existe um erro em pensar que o superdimensionamento vai

solucionar todos os problemas de QoS, e que aumentar a largura de banda é uma solução mais

simples que fazer o gerenciamento da qualidade de serviço. Portanto, o

superdimensionamento não pode ser visto realmente com uma solução, pois ainda será

necessário o gerenciamento da qualidade de serviço para poder garantir os requisitos de

23

qualidade de serviço, por exemplo, em um caso em que ocorram muito mais acessos a um

sistema do que o previsto e a largura de banda seja insuficiente.

E segundo Tanenbaum [13], no superdimensionamento existe outro problema

relacionado ao custo, pois é necessário adquirir uma quantidade enorme de equipamentos e

largura de banda.

2.2.2.2 Armazenamento em Buffers

Em Tanenbaum [13], vemos que os fluxos podem ser armazenados em buffers no lado

receptor antes de serem entregues para as aplicações, isto é, os pacotes chegam ao destino e

ficam armazenados no buffer e, após algum tempo, são entregues às aplicações de forma

constante.

Segundo Tanenbaum [13], o armazenamento dos fluxos em buffers não afeta a sua

confiabilidade e não causa impacto na utilização da largura de banda, mas aumenta o atraso

dos pacotes tendo em vista que os pacotes só são entregues as aplicações após algum tempo.

A vantagem desta técnica é a suavização do jitter, pois os pacotes só sofrerão atrasos

na entrega para as aplicações caso ocorra um atraso muito alto na rede e o buffer fique vazio.

Em algumas aplicações como áudio e vídeo por demanda, a variação no atraso é o principal

problema, portanto, essa técnica auxilia muito na qualidade deste tipo de serviço.

2.2.2.3 Modelagem de Tráfego

A modelagem de tráfego está relacionada à regulagem da taxa e do volume de

transmissão de dados [13]. A técnica de modelagem de tráfego suaviza o tráfego no lado

transmissor fazendo com que os pacotes sejam enviados a uma taxa constante.

Segundo Tanenbaum [13] quando uma conexão é configurada, deve ser determinado

um padrão de tráfego, ou seja, uma forma para essa conexão. A modelagem de tráfego policia

os fluxos de dados limitando a largura de banda para uma taxa acordada, isto é, faz com que

os fluxos fiquem dentro da forma prevista [12].

24

Com a modelagem de tráfego é possível reduzir o congestionamento na rede, pois os

dados serão transmitidos de forma constante a uma taxa máxima. Este fator é de grande

importância no caso da transmissão de dados em tempo real, como conexões de áudio e vídeo,

que têm requisitos estritos de qualidade de serviço [13].

2.2.2.4 Mecanismos de Escalonamento

O modo como os pacotes enfileirados são selecionados para transmissão pelo enlace é

conhecido como disciplina de escalonamento [1].

Segundo Marchese [12], o escalonamento de pacotes especifica a política de serviços

de uma fila em um nó, isto é, o escalonamento decide a ordem que será utilizada para escolher

os pacotes que serão transmitidos sobre um canal. Ele também é uma parte importante quando

se fala de qualidade de serviço, podendo causar grande impacto em diferentes parâmetros de

QoS, como atraso, jitter e perda de pacotes.

A seguir serão apresentadas as mais importantes disciplinas de escalonamento.

2.2.2.4.1 FIFO

A disciplina de escalonamento FIFO seleciona pacotes para transmissão pelo enlace

na mesma ordem em que eles chegaram à fila de saída do enlace [1]. Isto é, o primeiro pacote

a chegar a um nó será o primeiro a ser transmitido.

Segundo Kurose e Ross [1], como os buffers em um nó são finitos, se um pacote chega

à fila de saída e ela está cheia, o nó utilizará uma política de descarte e determinará se o

pacote será descartado ou se outro pacote será retirado da fila para dar espaço aoque está

chegando. E Peterson e Davie [16] dizem que essa ação é tomada sem levar em conta a qual

fluxo o pacote pertence ou o quanto ele é importante.

25

2.2.2.4.2 Prioridade

Segundo Peterson e Davie [16], a disciplina de escalonamento por prioridade é uma

variação básica da disciplina FIFO, onde a idéia é marcar cada pacote com uma prioridade;

essa marca pode ser carregada, por exemplo, no campo TOS do cabeçalho IP. E os roteadores

implementam múltiplas filas, normalmente do tipo FIFO, para cada prioridade.

De acordo com Kurose e Ross [1], na disciplina de escalonamento por prioridade um

nó ao transmitir um pacote, sempre será escolherá um da classe de prioridade mais alta que a

fila não esteja vazia, isto é, que tenha pacotes esperando para serem transmitidos.

Para Peterson e Davie [16], um problema com o escalonamento por prioridade é que

enquanto a fila com a maior prioridade tiver ao menos um pacote para transmissão, as outras

filas não serão atendidas, podendo causar inanição nas outras filas.

2.2.2.4.3 Varredura Cíclica

Na disciplina de escalonamento por varredura cíclica os pacotes são classificados do

mesmo modo que no escalonamento por prioridade. Contudo, em vez de haver uma prioridade

estrita de serviço entre as classes, um escalonador de varredura cíclica alterna serviços entre

as classes [1]. Isto é, o escalonador transmite um pacote da classe um e em seguida um pacote

da classe dois, e volta a transmitir um pacote da classe um, seguido de outro classe dois e

assim por diante. Caso uma fila de uma classe esteja vazia é transmitido um pacote de outra

fila.

2.2.2.4.4 WFQ

A disciplina de escalonamento Weighted Far Queue, segundo Peterson e Davie [16], é

uma implementação de uma variação do escalonamento por varredura cíclica, que permite que

sejam atribuídos pesos para cada classe. E tem considerável utilização nas arquiteturas com

26

QoS atuais [1].

Segundo Kurose e Ross [1], um escalonador WFQ atende as classes de modo cíclico,

assim como na varredura cíclica, mas cada classe receberá uma fração de tempo igual ao seu

peso divido pelo somatório dos pesos de todas as classes que tenham pacotes para transmitir.

2.2.2.5 Mecanismos de Regulação

Regulação é o ajuste da taxa com a qual é permitido que um fluxo injete pacotes na

rede e é uma das pedras fundamentais de qualquer arquitetura com QoS [1].

Segundo Kurose e Ross [1], as características da taxa de pacotes reguladas em um

fluxo são:

Taxa média: número de pacotes enviados em um intervalo de tempo;

Taxa de pico: número máximo de pacotes que podem ser enviados durante um

período curto de tempo;

Tamanho da rajada: número máximo de pacotes que podem ser enviados em

um intervalo de tempo extremamente curto.

Podemos ver em Marchese [12] que existem dois métodos básicos para regulação, os

quais serão apresentados a seguir.

2.2.2.5.1 Algoritmo de Balde Furado

De acordo com Tanenbaum [13], o algoritmo de balde furado consiste de uma fila

finita. Quando um pacote chega a um nó, se houver espaço na fila, será incluído nela; caso

contrário, ele será descartado. O balde transmite para a rede os bytes dos pacotes a uma taxa

constante.

Ainda, segundo Tanenbaum [13], esse tratamento faz com que os pacotes saiam do nó

a uma taxa constante, independente da forma como chegam até ele, isto é, ele transforma um

fluxo de pacotes irregulares em um fluxo de pacotes regular.

27

2.2.2.5.2 Algoritmo de Balde de Símbolos

O algoritmo do balde furado impõe um padrão rígido à taxa média, independente da

irregularidade do tráfego. Em muitas aplicações é melhor permitir que a saída aumente um

pouco sua velocidade quando chegarem rajadas maiores; assim, é necessário um algoritmo

mais flexível, de preferência um que nunca perca dados [13]. Um algoritmo como esse, é o do

balde de símbolos.

O algoritmo do balde de símbolos é similar ao do balde furado, mas sua

implementação é diferente. De acordo com Marchese [12], símbolos são gerados a uma taxa

constante e colocados no balde. Quando um pacote entra na fila para ser transmitido, ele

precisa pegar um símbolo para cada byte que possui, consumindo o símbolo do balde. Um

byte só pode ser transmitido se existirem símbolos no balde, caso contrário deve esperar até

que um novo símbolo seja inserido no balde.

Segundo Tanenbaum [13], o algoritmo do balde de símbolos possibilita um tipo de

modelagem de tráfego diferente do algoritmo do balde furado, pois permite que fluxos

inativos ou com baixa atividade economizem símbolos para futuras rajadas de tráfego.

O balde de símbolos tem um tamanho finito e descarta símbolos quando o balde está

cheio, mas nunca descarta pacotes [13].

2.2.3 Serviços Integrados e Serviços Diferenciados

Nesta seção serão apresentadas as principais arquiteturas de QoS: Serviços Integrados

(Intserv) e Serviços Diferenciados (Diffserv). Elas representam padrões correntes da IETF

para prover qualidade de serviço e incorporam os princípios e os mecanismos apresentados

nas seções anteriores.

2.2.3.1 Serviços Integrados

28

Entre 1995 e 1997, a IETF dedicou um grande esforço à criação de uma arquitetura

para multimídia de fluxo. Este trabalho resultou em mais de duas dezenas de RFCs,

começando com as RFCs 2205 a 2210. O nome genérico deste trabalho é algoritmos baseados

no fluxo ou serviços integrados [13].

Segundo Kurose e Ross [1], a arquitetura de serviços integrados (Intserv) possui duas

características fundamentais:

Recursos reservados: Um roteador deve saber qual a quantidade de recursos que já

está reservada para sessões em andamento.

Estabelecimento de chamada: Uma sessão que exige garantias de QoS deve

primeiramente estar habilitada a reservar recursos suficientes em cada roteador da

rede em seu trajeto entre a origem e destino.

De acordo com Tanenbaum [13], o principal protocolo da IETF para a arquitetura de

serviços integrados é o RSVP. Ele é o protocolo empregado para fazer as reservas de recursos

entre a origem e o destino do fluxo.

Segundo Peterson e Davie [16], a arquitetura Intserv define duas grandes classes de

serviços: serviços garantidos e serviços de carga controlada. Em Kurose e Ross [1], vemos

que a especificação de serviço garantido é definida na RFC 2212, e estabelece limites rígidos

para atrasos de fila que um pacote sofrerá em um roteador. Já o serviço de carga controlada

receberá, de acordo com a RFC 2211, uma qualidade de serviço que se aproxima muito da

QoS que o mesmo fluxo receberia de um elemento de rede que não tivesse carga.

2.2.3.2 Serviços Diferenciados

A IETF padronizou arquitetura de serviços diferenciados, descritas nas RFCs 2474 e

2475, como uma abordagem mais simples para oferecer qualidade de serviço, uma estratégia

que pode ser implementada em grande parte localmente em cada roteador, sem configuração

antecipada e sem ter de envolver todo o caminho. Essa abordagem é conhecida como

qualidade de serviço baseada na classe (em vez de ser baseada no fluxo) [13].

A arquitetura de serviços diferenciados (Diffserv) é flexível, no sentido de que não

define serviços específicos nem classes de serviços específicas. Em vez disso, ela fornece os

29

componentes funcionais, isto é, as peças de uma arquitetura de rede com as quais esses

serviços podem ser montados [1]. A arquitetura Diffserv consiste em dois conjuntos de

elementos funcionais:

Funções de borda: classificação de pacotes e condicionamento do tráfego. Na

borda de entrada da rede os pacotes são marcados identificando a qual classe ele

pertence. A marcação é feita alterando o campo DS do cabeçalho do pacote. Caso o

tráfego esteja fora do padrão acordado ele pode receber uma marcação diferente,

de uma classe menos prioritária, ou ser descartado [1].

Função central: envio. Quando um pacote marcado com DS chega a um roteador

habilitado com Diffserv ele é repassado até seu próximo salto de acordo com o

comportamento por salto associado à classe do pacote. O comportamento por salto

influencia a maneira pela qual os buffers e a largura de banda de um roteador são

compartilhados entre as classes de tráfego concorrentes [1].

De acordo com Peterson e Davie [16], a IETF decidiu utilizar seis bits do campo TOS

do cabeçalho IP para realizar a marcação dos pacotes, esses seis bits são chamados de DSCP.

Eles mapeiam as classes de serviço que definem o comportamento por salto (PHB) a ser

aplicado ao pacote.

Segundo Kurose e Ross [1], até agora foram definidos dois PHBs: um de repasse

acelerado (EF) e um de repasse assegurado (AF) respectivamente pelas RFCs 3246 e 2597.

O repasse acelerado é dividido em duas classes, a do tráfego regular e a do tráfego de

repasse acelerado [13]. E, segundo Braun et al. [14], deve-se assegurar que o tráfego da classe

de repasse acelerado receba uma taxa mínima de transmissão, independente da intensidade de

outros tipos de tráfego.

De acordo com Tanenbaum [13], o repasse assegurado é um pouco mais elaborado,

definindo quatro classes de prioridade, além de três possibilidades de descarte de pacotes que

estejam sofrendo congestionamento: baixo, médio e alto. Assim, definindo doze classes de

serviço.

2.2.3.3 Intserv X Diffserv

O Intserv é capaz de prover uma qualidade de serviço parecida com as de tecnologias

30

de circuitos, através da reservas de recursos prévia. Segundo Tanenbaum [13], os algoritmos

baseados no fluxo têm potencial para oferecer boa qualidade de serviço a um ou mais fluxos,

porque eles reservam quaisquer recursos necessários ao longo da rota. Porém, eles também

têm a desvantagem de exigirem uma configuração antecipada para estabelecer cada fluxo,

algo que não se ajusta bem quando existem milhares ou milhões de fluxos. Além disso, eles

mantêm o estado interno por fluxo nos roteadores e envolvem trocas complexas de roteador

para roteador, a fim de configurar os fluxos.

De acordo com Kurose e Ross [1], o Diffserv possui uma escalabilidade muito maior,

pois não precisa manter os estados dos fluxos, isso porque seu comportamento é determinado

por salto e não fim-a-fim, isso é uma diferença muito grande quando se trata de milhões de

fluxos (um número comum na Internet atual). Ainda possui uma flexibilidade muito maior

que a arquitetura Intserv na definição de classes, permitindo que sejam adicionadas ou

retiradas classes sem afetar a que já estão em utilização.

2.2.4 Utilização de QoS em redes

Atualmente a maioria das conexões de acesso a Internet, principalmente os acessos

residenciais, não possuem nenhum tipo de qualidade de serviço oferecida. A única garantia

oferecida é uma pequena porcentagem da largura de banda contratada. No caso de acessos

corporativos o cenário não é muito diferente, mas a largura de banda garantida normalmente é

maior.

Alguns provedores de serviços de Internet vendem atualmente serviços de acesso com

garantias de qualidade de serviço, mas de acordo com Xiao [17], essa garantia só é válida

enquanto o tráfego está dentro da rede do provedor de serviço, quando passam por redes de

outros provedores a QoS não pode ser garantida.

Segundo Xiao [17], isso ocorre por que os provedores não possuem acordos para

manter a qualidade de serviço do tráfego de outros provedores em sua rede, sendo o tráfego

proveniente de outros provedores tratados como serviços de melhor esforço.

A qualidade de serviço é oferecida pelos provedores de serviços a usuário na forma de

acordos de nível de serviço (SLA), onde são definidas as classes de serviços oferecidas e os

parâmetros máximos de largura de banda, atraso, jitter e número de pacotes perdidos em uma

31

determinada classe ou conexão. No SLA também é definido a forma como o usuário entregará

os dados ao provedor, isso é, marcação dos pacotes, taxa média, taxa de pico e tamanho

máximo de rajadas. Caso o tráfego entregue esteja fora do formato acordado o provedor de

serviços não irá garantir os níveis definidos no SLA [17].

Empresas e órgãos públicos também podem utilizar QoS dentro de suas redes privadas,

priorizando aplicações críticas ou que necessitem de algum nível de qualidade de serviço para

um bom funcionamento, utilizando as técnicas de QoS internamente.

32

3 METODOLOGIA

Neste capitulo é apresentada a metodologia para o desenvolvimento do sistema e

documentação do desenvolvimento, incluindo alguns conceitos da UML. Além de definidos

os cenários e metodologia de testes.

3.1 Ferramentas

O desenvolvimento foi realizado utilizando o sistema operacional Linux, distribuição

GNU/Debian, versão 5.0.4 codinome Lenny, disponível em http://www.debian.org. Foi

utilizado o software Apache versão 2.0 como servidor HTTP (http://www.apache.org) com o

módulo de suporte a linguagem PHP na versão 5.0 (http://www.php.net). Como servidor de

banco de dados, foi utilizado o software MySQL versão 5 (http://www.mysql.com).

O software utilizado pelo sistema para gerar os fluxos de dados é o iperf versão 2.0.4

(http://sourceforge.net/projects/iperf/). Ele também será responsável por gerar os dados brutos

com os resultados dos testes.

A ferramenta de teste de redes ping em conjunto com ferramentas de shell scripts foi

usada para registrar os dados de atraso dos fluxos.

A suíte NetBeans (http://netbeans.org/) foi utilizada para o desenvolvimento das

páginas e scripts em PHP da interface web do sistema. Para gerar os gráficos com os

resultados dos testes foi utilizada a classe PHP pChart, disponível em

http://pchart.sourceforge.net/.

Todos os dados de configuração e resultados dos testes ficam armazenados em base de

dados no servidor MySQL. E o software phpmyadmin (http://www.phpmyadmin.net) foi

usado para a criação e manutenções na base de dados.

33

3.2 Desenvolvimento

Foram desenvolvidos scripts em shell script (Apêndices A e B), utilizando o editor de

texto gedit, para capturar as saídas geradas em arquivos de texto, retirar as informações

desnecessárias e inserir os dados relevantes na base de dados, para que possam ser utilizados

futuramente para gerar os gráficos e página de resultados a serem exibidos pela interface web.

O shell utilizado para executar os scripts é o bash.

Foi desenvolvida uma interface web na linguagem PHP para a configuração dos testes

e apresentação dos resultados. Alguns códigos desenvolvidos podem ser vistos nos Apêndices

C a G.

Durante o desenvolvimento foram utilizados equipamentos de rede, como roteadores e

switchs, com capacidade de realizar QoS para verificar o funcionamento do sistema de testes

automatizados.

O desenvolvimento seguiu as seguintes fases:

Instalação do sistema operacional e ferramentas necessárias para o

desenvolvimento e funcionamento do sistema;

Testes das ferramentas iperf e ping;

Desenvolvimento dos shell scripts que para tratamento dos resultados brutos do

teste;

Testes de funcionamento dos shell scripts;

Desenvolvimento da interface web para configuração dos testes e relatórios

automatizados;

Testes da interface web;

Laboratório de testes com equipamentos de rede e diferentes configurações de QoS

e ajustes no software.

Os diagramas da UML apresentados nesse trabalho foram desenvolvidos utilizando a

ferramenta de desenho de diagramas DIA (http://live.gnome.org/Dia).

O desenvolvimento do texto do trabalho ocorreu em paralelo ao desenvolvimento da

aplicação.

Algumas telas de exemplo de funcionamento do sistema encontram-se no Apêndice I.

34

3.3 Requisitos

O sistema proposto visa permitir que sejam realizados testes de qualidade de serviço

em redes de comunicação de dados de forma automatizada e que sejam criados relatórios

também de forma automatizada a partir dos resultados obtidos durante os testes.

Os testes deverão ser configurados para que seja possível medir os parâmetros

definidos como essenciais para a qualidade de serviço.

O sistema terá duas formas de funcionamento, modo escravo e modo mestre.

No modo escravo o usuário deve informar em qual endereço IP o sistema deve

aguardar a conexão do sistema em modo mestre, após a conexão serão trocadas informações

sobre os parâmetros do teste e o escravo iniciará o envio de dados com o software iperf.

No modo mestre o usuário informará os dados básicos do testes como nome, número

de fluxos, tempo de duração, tipo de marcação de pacotes e endereços IPs utilizados no teste.

Em seguida, para cada fluxo, deverá informar a qual classe de QoS ele pertence, a largura de

banda e tamanhos dos pacotes.

Após a confirmação dos dados pelo usuário, o sistema no modo mestre irá se conectar

ao sistema funcionando no modo escravo, enviará os parâmetros dos testes e iniciará os

softwares ping e iperf para receber os fluxos e gerar os arquivos com resultados. Após a

finalização do testes será responsável por formatar e salvar os resultados e em seguida exibi-

los ao usuário.

Todos os campos exibidos nas páginas de configuração são de preenchimento

obrigatório, com exceção do tempo de teste.

Caso o usuário não forneça o tempo de duração do testes será utilizado o tempo padrão

de sessenta segundos.

O campo “tamanho dos pacotes” na configuração dos fluxos deve possuir um valor

maior que 64 bytes.

As marcas de QoS utilizadas nos fluxos devem ser digitadas em formato decimal.

O sistema deverá permitir que o usuário visualize os resultados de testes anteriores.

35

3.4 Casos de Uso

O sistema possui três casos de uso, que podem ser observados na Figura 2.

FIGURA 2 - Diagrama geral dos casos de uso

3.4.1 Iniciar Teste Lado Mestre

Nome do Caso de Uso: Iniciar Teste Lado Mestre Sistema de Teste de QoS

Ator Envolvido: Usuário

PRÉ-CONDIÇÃO

1 – Ter acesso ao sistema.

DESCRIÇÃO DO CASO

1 – Clicar em iniciar novo Teste Mestre;

2 – Inserir dados básicos do teste;

3 – Inserir dados dos fluxos;

4 – Confirmar configurações;

5 – Se ocorrerem erros, fim.

6 – Caso contrário visualizar resultados.

PÓS-CONDIÇÃO

1 – Teste realizado.

2 – Resultados exibidos.

36

3.4.2 Iniciar Teste Lado Escravo

Nome do Caso de Uso: Iniciar Teste Lado Escravo Sistema de Teste de QoS


PRÉ-CONDIÇÃO

1 – Ter acesso ao sistema

DESCRIÇÃO DO CASO

1 – Clicar em iniciar novo Teste Escravo;

2 – Inserir dados do teste;

3 – Se ocorrerem erros, fim.

4 – Caso contrário teste realizado com sucesso.

PÓS-CONDIÇÃO

1 – Teste realizado.

3.4.3 Iniciar Testes Anteriores

Nome do Caso de Uso: Visualizar Testes Anteriores Sistema de Teste de QoS


PRÉ-CONDIÇÃO

1 – Ter acesso ao sistema.

2 – Existirem testes já realizados

DESCRIÇÃO DO CASO

1 – Clicar em iniciar Visualizar Resultados Anteriores;

2 – Selecionar o teste desejado;

3 – Visualizar resultados.

PÓS-CONDIÇÃO

1 – Resultados exibidos.

3.5 Diagramas de Seqüência

A Figura 3 mostra o diagrama de seqüência da execução de um teste completo.

37

FIGURA 3 - Diagrama de seqüência de um teste completo

38

3.6 Diagrama de Classes

A Figura 4 apresenta do diagrama de classes do sistema desenvolvido.

FIGURA 4 - Diagrama de classes

3.7 Modelagem de Dados

A estrutura do banco de dados utilizada no sistema é formada por sete tabelas:

teste: armazena os dados básicos e estados dos testes;

fluxos_teste: contêm as informações específicas de cada fluxo do teste;

39

resultados_simples: armazena os resultados obtidos a partir das ferramentas iperf e

ping;

classe_qos: armazena os requisito mínimos para cada classe de serviço.

A Figura 5 apresenta a estrutura do banco de dados.

FIGURA 5 - Estrutura de dados

3.8 Metodologia de Testes

Para a realização dos testes de funcionamento do software foram utilizados dois

notebooks com sistema operacional Linux Debian, versão 5.0.4, e com todos os softwares

necessários para o funcionamento do sistema. Foram utilizados também dois roteadores AR-

1700 da empresa FTD Comunicação de Dados.

Os testes foram realizados configurando os roteadores para prover a qualidade de

serviço especificada por cada cenário e o software foi configurado para testar os parâmetros

de QoS de acordo com o proposto pelo cenário.

40

3.9 Laboratório de Testes

O laboratório foi montado da forma apresentada da Figura 6, os roteadores foram

conectados através da porta serial (WAN), utilizando o protocolo PPP. E os notebooks foram

conectados as portas Ethernet (LAN) dos seus respectivos roteadores. A conexão serial entre

os roteadores foi configurada com 2 Mbps de largura de banda.

FIGURA 6 - Diagrama do laboratório de teste

Os testes foram realizados três vezes em cada cenário para evitar que uma falha

esporádica ou comportamento estranho afetassem os resultados dos testes e também para

verificar a estabilidade e coerência entre os resultados do software.

3.10 Cenários de Testes

Foram criados três cenários de testes com configurações diferentes para avaliar o

funcionamento e comportamento do software.

3.10.1 Cenário 1

No cenário 1 foram utilizados dois fluxos com as características apresentadas na

Tabela 3, com o fluxo 1 recebendo uma prioridade maior que a do fluxo 2 no escalonamento.

41

TABELA 3 - Configurações dos fluxos de dados no cenário 1

Fluxo Classe Largura de

Banda (bps)

Tamanho dos

Pacotes (bytes)

1 1 - Tempo real, sensível ao jitter, interativa 300 000 64

2 5 - Aplicações padrões de redes IP 1 700 000 1 500

3.10.2 Cenário 2

No cenário 2 foram utilizados três fluxos com as características apresentadas na Tabela

4, com o fluxo 1 e fluxo 2 recebendo a mesma prioridade, portanto compartilhando a banda

no escalonamento e o fluxo 3 com uma prioridade menor.



Banda (bps)

Tamanho dos

Pacotes (bytes)

1 0 - Tempo real, sensível ao jitter, altamente

interativa

200 000 128


3 5 - Aplicações padrões de redes IP 1 650 000 768

3.10.3 Cenário 3

No cenário 3 foram utilizadas as mesmas configurações do cenário 2 com três fluxos e

com as características apresentadas na Tabela 5, e com o fluxo 1 e fluxo 2 recebendo a mesma

prioridade, portanto compartilhando a banda no escalonamento e o fluxo 3 com uma

prioridade menor.

Durante a execução do teste o fluxo 3 foi configurado para gerar uma largura de banda

de 2000000 bps, acima do permitido para a classe e perto do limite máximo do link, para

verificar se o excesso de tráfego desse fluxo não irá influenciar no escalonamento dos fluxos

42

de maior prioridade.



Banda (bps)

Tamanho dos

Pacotes (bytes)

1 0 - Tempo real, sensível ao jitter, altamente

interativa

200 000 128


3 5 - Aplicações padrões de redes IP 1 650 000 768

3.11 Realização dos Testes

O laboratório foi montado de acordo com o proposto, como pode ser observado nas

Figuras 7 e 8. Primeiramente os roteadores foram configurados de acordo com as regras de

cada cenário (Apêndice J) e em seguida foram realizados os testes, três vezes consecutivas em

cada configuração, pelo período de cinco minutos por teste.

Durante os testes foi encontrado um problema com o tamanho dos pacotes para a

realização dos mesmos. A ferramenta iperf ao ser configurada para gerar os dados utilizando

pacotes muito pequenos gera um volume de dados muito maior do que o configurado. Isso se

de deve ao fato da configuração do tamanho do pacote na ferramenta ser relativo apenas a

quantidade de dados do pacote, assim como a largura de banda utilizada, também se refere aos

dados do pacote, excluindo os cabeçalhos UDP, IP e Ethernet. Por esse motivo, os testes

foram realizados utilizando em todos os fluxos o tamanho do pacote em 1500 bytes.

43

FIGURA 7 - Laboratório de testes visão geral

FIGURA 8 - Laboratório de testes roteadores

44

4 RESULTADOS E DISCUSSÕES

Nesta seção serão mostrados e analisados os resultados obtidos durante os testes, os

relatórios de resultados completos gerados pelo sistema estão no Apêndice H.

4.1 Resultados no Cenário 1

No cenário 1 todos os testes ocorreram sem problemas e os fluxos apresentaram o

comportamento e resultados esperados, de acordo com as classes de QoS definidas

anteriormente, são apresentados na Tabela 6 e os resultados obtidos estão na Tabela 7.

TABELA 6 - Resultados esperados nos testes no cenário 1

Fluxo Throughput (bps) IPTD (ms) IPDV (ms) IPLR

1 >= 291 601,12 < 400 < 50 < 0,001

2 >= 1 652 419,04 N N N


TABELA 7 - Resultados dos testes no cenário 1

Fluxo Teste Throughput (bps) IPTD (ms) IPDV (ms) IPLR

1

1 293 960,8 6,772 4,129 0,000

2 293 960,8 5,246 2,529 0,000

3 293 960,8 6,594 3,569 0,000

2

1 1 665 608,0 17,417 3,967 0,000

2 1 666 156,8 8,301 2,863 0,000

3 1 665 333,6 8,458 3,155 0,000

Podemos observar que todos os resultados ficaram dentro dos parâmetros esperados e

o desempenho do software ficou de acordo com o configurado.

45


No cenário 2 ocorreram problemas durante o teste de numero três, durante quinze

segundos houve aumento de atrasos, sem explicação, fazendo com que o resultado fosse

negativo para esse parâmetro em alguns fluxos. O gráfico de atraso, mostrado na Figura 9,

mostra o resultado anormal, comparado com o gráfico de um teste com resultado correto

(Figura 10).

FIGURA 9 - Gráfico de atraso no teste 3 do cenário 2


Os resultados esperados para os testes nesse cenário, de acordo com as classes de QoS

definidas anteriormente, são apresentados na Tabela 8 e os resultados obtidos na Tabela 9.



1 >= 194 401,12 < 100 < 50 < 0,001

2 >= 145 801,12 < 400 < 50 < 0,001

3 >= 1 603 805,60 N N N


46



1

1 195 960,8 5,168 2,006 0,000

2 195 960,8 5,224 2,221 0,000

3 195 960,8 5,012 2,366 0,000

2

1 146 960,8 4,670 1,681 0,000

2 146 960,8 4,673 2,552 0,000

3 146 960,8 4,179 2,190 0,000

3

1 1 616 804,0 11,825 6,865 0,000

2 1 616 216,0 17,295 9,048 0,000

3 1 616 804,0 14,107 7,629 0,000

Podemos observar que todos os resultados ficaram dentro dos parâmetros esperados,

que o desempenho do software ficou de acordo com o configurado e, mesmo com o problema

de atrasos no terceiro teste o resultado médio ficou bem próximo ao obtido nos outros testes

do cenário.


No cenário 3, assim como no cenário 2, ocorreram problemas durante o teste de

número um, com relação ao aumento de atrasos, durante dez segundos, também fazendo com

que o resultado fosse negativo para esse parâmetro em alguns fluxos. O gráfico de atraso,

mostrado na Figura 11, mostra o resultado anormal, comparado com o gráfico de um teste

com resultado correto (Figura 12).

47



Os resultados esperados para os testes nesse cenário, de acordo com as classes de QoS

definidas anteriormente, são apresentados na Tabela 10. Neste cenário é esperado que o fluxo

três não obtenha o mínimo esperado no parâmetro de largura de banda, pois a largura de

banda gerada é maior do que a capacidade do enlace entre os roteadores, mas é esperado que

o excesso de banda gerada no fluxo três não interfira nos resultados dos outros fluxos. Os

resultados obtidos estão na Tabela 11.



1 >= 194 401,12 < 100 < 50 < 0,001

2 >= 145 801,12 < 400 < 50 < 0,001

3 >= 1 944 104,16 N N N


48



1

1 195 960,8 4,842 3,338 0,000

2 195 960,8 4,952 2,710 0,000

3 195 960,8 5,151 2,366 0,000

2

1 146 960,8 4,832 2,840 0,000

2 146 960,8 4,635 2,776 0,000

3 146 960,8 4,927 2,469 0,000

3

1 1 575 604,8 258,113 9,646 0,195

2 1 575 448,0 240,895 9,996 0,195

3 1 570 469,6 259,917 9,759 0,198

Os resultados ficaram dentro dos parâmetros esperados e o desempenho do software

ficou de acordo com o configurado e, da mesma forma que no cenário 2 ocorreram problemas

com atrasos no teste número um, o resultado médio, porém, ficou bem próximo ao obtido nos

outros testes do cenário.

4.4 Considerações Sobre os Resultados

Através dos resultados obtidos foi possível verificar que o sistema está funcionando

bem e de forma estável, e que também está medindo de forma correta os parâmetros de

qualidade de serviço propostos. Principalmente no cenário 3 foi possível verificar o

funcionamento do QoS aplicado pelo roteador, que mesmo com um fluxo de tráfego com

largura de banda maior do que o suportado pelo enlace manteve a qualidade dos fluxos que

possuíam uma prioridade maior.

Não foi possível determinar a causa dos problemas nos testes de atraso, sendo a causa

mais provável, a interferência de outro software em execução nos computadores que

realizavam os testes, que utilizou recursos, como processamento, atrasando o funcionamento

do software que realiza o teste de atraso. Após a ocorrência dos erros em dois testes seguidos

os roteadores foram reiniciados, e os testes seguintes não apresentaram erros.

Devido ao comportamento do iperf com pacotes pequenos, não foi possível realizar os

49

testes com o tamanho de pacotes propostos, para isso será necessária uma alteração no

funcionamento do software que deverá prever os tamanhos dos cabeçalhos para calcular o

tráfego que deverá ser gerado pelo iperf.

50

5 CONCLUSÃO

Com base nos critérios e resultados apresentados nesta monografia, onde o objetivo

era o desenvolvimento de um ambiente de testes automatizados de qualidade de serviço em

rede de comunicação de dados baseado em softwares livres, constatou-se que o objetivo

proposto foi alcançado.

O usuário do sistema pode realizar os testes através de uma interface web e visualizar

os resultados na própria aplicação sem a necessidade de recorrer a comandos no shell e outros

softwares para montar os relatórios e gráficos com os resultados.

A utilização de ferramentas livres como Linux, Apache, MySQL, iperf, ping

proporcionam uma ferramenta gratuita para a realização dos testes de qualidade de serviço em

ocasiões onde é necessário verificar o funcionamento das configurações aplicadas na rede,

sendo uma alternativa muito mais barata que os equipamentos de testes de redes encontrados

no mercado.

Durante a realização do trabalho foi possível aprimorar os conhecimentos em

programação utilizando shell scripts além de um aprendizado muito grande em linguagem de

programação PHP, banco de dados MySQL e nos funcionamento e opções de configurações

das ferramentas ping e iperf.

5.1 Extensões

Este trabalho pode ser continuado da seguinte forma:

Implementação de um módulo gerador de tráfego, baseado no iperf, que seja mais

flexível permitindo, por exemplo, que o tráfego gerado tenha períodos de

inatividade ou períodos de pico de tráfego acima do permitido pela configuração

do QoS;

Implementação de um módulo para medição de atraso e tratamento dos dados sem

a necessidade de utilização de ferramentas de shell scripts, permitindo que a

ferramenta possa ser utilizadas em outros sistema operacionais;

Utilização de base de dados que não necessite de um servidor MySQL instalado,

51

utilizando, por exemplo, base de dados SQLite, aumentando a portabilidade da

ferramenta;

Utilização de servidor web leve, integrado, multiplataforma e com suporte a PHP.

Implementação, que em conjunto com as sugestões anteriores, tornaria o sistema

totalmente portável;

Exportação dos resultados para planilhas eletrônicas.

52

REFERÊNCIAS

1 KUROSE, J. F.; ROSS, K. W. Redes de Computadores e a Internet: uma abordagem top-

down. 3ª edição. São Paulo: Pearson, 2006. 634 p.

2 FLUKE NETWORKS. One Touch Series II: Overview. Disponível em:

<http://www.flukenetworks.com/fnet/en-

us/products/OneTouch+Series+II/Overview.htm?categorycode=LANT>. Acesso em: 08 mar.

2010.

3 FLUKE NETWORKS. Test and Troubleshoot. Disponível em:


us/products/family.htm?wbc_purpose=BasiNewsListingsupportAndDownloadsWhereToBuysi

temap&categorycode=LANT>. Acesso em: 08 mar. 2010.

4 JDSU. SmartClass Ethernet. Disponível em: <http://www.jdsu.com/specials/smartclass-

ethernet-adsl/index.html>. Acesso em: 08 mar. 2010.

5 JDSU. Acess Network Test. Disponível em:

<http://www.jdsu.com/products/communications-test-measurement/products/access-network-

test.html#Ethernet Test>. Acesso em: 08 mar. 2010.

6 FLUKE NETWORKS. EtherScope Series II: Overview. Disponível em:


us/products/EtherScope+Series+II/?categorycode=LANT>. Acesso em: 08 mar. 2010.

7 JDSU. T-BERD® 4000 Multiple Services Test Platform. Disponível em:

<http://www.jdsu.com/products/communications-test-measurement/products/a-z-product-

list/t-berd-4000-multiple-services-test-platform.html>. Acesso em: 08 mar. 2010.

8 CISCO SYSTEMS. Internetworking Technology Handbook: Internet Protocols (IP).

Disponível em:

<http://www.cisco.com/en/US/docs/internetworking/technology/handbook/Internet-

53

Protocols.html#wp2468>. Acesso em: 07 mar. 2010.

9 OODAN, A. et al. Telecommunications Quality of Service Management: From legacy to

emerging services. Londres, Reino Unido: The Institution Of Engineering And Technology,

2009. 602 p.

10 ISO - INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO

8402:1994: Quality management and quality assurance -- Vocabulary. Disponível em:

<http://www.iso.org/iso/iso_catalogue/catalogue_ics/catalogue_detail_ics.htm?csnumber=201

15>. Acesso em: 12 abr. 2010.

11 ITU – INTERNATIONAL TELECOMMUNICATION UNION. Terms and definitions

related to quality of service and network performance including dependability.

Disponível em: <http://www.itu.int/rec/T-REC-E/recommendation.asp?lang=en&parent=T-

REC-E.800>. Acesso em: 03 mar. 2010.

12 MARCHESE, M. QoS Over Heterogeneous Networks. West Sussex: John Wiley & Sons,

2007. 307 p.

13 TANENBAUM, A. S. Rede de Computadores. 4ª edição. Rio de Janeiro:

Campus/Elsevier, 2003. 968 p.

14 BRAUN, T. et al. End-to-End Quality of Service Over Heterogeneous Networks.

Berlin: Springer, 2008. 266 p.

15 DATTATREYA, G. R. Performance Analysis of Queuing and Computer Networks. 1ª

edição. Boca Raton: CRC Press, 2008. 449 p.

16 PETERSON, L. L.; DAVIE, B.S. Computer Networks: A Systems Approach. 3. ed. San

Francisco: Elsevier Science, 2003. 809 p.

17 XIAO, X. Technical, commercial, and regulatory challenges of QoS: An Internet

Service Model Perspective. Burlington: Elsevier, 2008. 274 p.

54

REFERÊNCIAS CONSULTADAS

BEZERRA, E. Princípios de análise e projeto de sistemas com UML. Rio de Janeiro:

Elsevier, 2002. 279p.

BLUM, R. Linux Command Line and Shell Scripting Bible. Indianapolis: Wiley

Publishing, 2008. 809 p.

BURTCH, K. O. Linux Shell Scripting with Bash. 1ª edição. Indianapolis: Sams Publishing,

2004. 412 p.

CONVERSE, T.; PARK, J.; MORGAN, C. PHP5 and MySQL Bible. Indianapolis: Wiley

Publishing, 2004. 1042 p.

MySQL AB. MySQL 5.1 Reference. Disponível em:

<http://dev.mysql.com/doc/refman/5.1/en/>. Acesso em: 06 mar. 2010.

NARAMORE, E.; GERNER, J.; SCOUARNEC, Y. L.; STOLZ, J.;GLASS, M. K. Beginning

PHP5, Apache, and MySQL Web Development. Indianapolis: Wiley Publishing, 2005. 798

p.

PETERS, R. Expert Shell Scripting. 1ª edição: Apress, 2009. 293 p.

PHP GROUP. PHP: Documentation. Disponível em: <http://www.php.net/docs.php>.

Acesso em: 06 mar. 2010.

RNP – REDE NACIONAL DE ENSINO E PESQUISA. QoS. Disponível em:

<http://www.rnp.br/qos/index.html>. Acesso em: 27 fev. 2010.

55

APÊNDICES

56

APÊNDICE A – Shell script para tratamento dos dados gerados pelo iperf:

apagaresumo.sh

#####################################################

#Processa Saidas IPERF e insere na base de dados #

#Parametros: #

# $1 ID do Teste #

# $2 ID do Fluxo #

# $3 arquivo a ser processado #

# $4 usuario sql #

# $5 senha sql #

# $6 base de dados sql #

#####################################################

#Limpando linhas desnecessarias

linhas=`cat $3 | grep -in ",0.0-" | grep -v ",0.0-1\.0" | cut -d ',' -f 7`

fluxo=$2

teste=$1

for i in $linhas; do

sed "/"$i"/d" $3 > tmp$3

cat tmp$3 > $3

rm tmp$3

done

cont=0

echo $cont

linhas=`cat $3`


if [ "$cont" -eq 0 ]; then

tinicial="1970-1-1"

tinicial=$tinicial" "$(echo $i | cut -d',' -f1 | cut -c'9-10');

tinicial=$tinicial":"$(echo $i | cut -d',' -f1 | cut -c'11-12');

tinicial=$tinicial":"$(echo $i | cut -d',' -f1 | cut -c'13-14');

tinicial=$(date -d "$tinicial" +"%s")

cont=1

echo $tinicial

fi

colarray[0]=`expr $tinicial + $(echo $i | cut -d',' -f7 | cut -d'-' -f 2 | cut -d'.' -f 1) - 10801`

echo ${colarray[0]}

colarray[1]=$(echo $i | cut -d',' -f2)







mysql -u $4 -p$5 -e "INSERT INTO resultados_simples

VALUES($2,$1,'${colarray[1]}:${colarray[2]}',${colarray[3]},${colarray[4]},${colarray[5]},

${colarray[6]},${colarray[7]},${colarray[0]},null)" $6

done

57

APÊNDICE B – Shell script para tratamento dos dados gerados pelo ping: pings.sh

######################################################

#*Processa Saidas do ping e insere na base de dados #

#Parametros: #

# $1 ID do Teste #

# $2 ID do Fluxo #

# $3 arquivo a ser processado #

# $4 usuario sql #

# $5 senha sql #

# $6 base de dados sql #

# #

######################################################

linhas=`cat $3 | tr -d ' ' `

fluxo=$2

teste=$1


colarray[0]=$(echo $i | cut -d':' -f1)

colarray[1]=$(echo $i | cut -d'=' -f4 | cut -d'm' -f1)

mysql -u $4 -p$5 -e "UPDATE resultados_simples SET ping_rtt=${colarray[1]} WHERE

testeid=$1 AND fluxoid=$2 AND

tempos=((HOUR(${colarray[0]})*60*60)+(MINUTE(${colarray[0]})*60)+SECOND(${cola

rray[0]}))" $6

done

58

APÊNDICE C – Agente escravo: servidor.php

<?php

error_reporting (E_ALL);

/* desabilita o timeout para que o script fique esperando pela conexão */

set_time_limit (0);

$address = $argv[1];

$port = 1234;

$numfluxos=0;

$fp = fopen('status/statusconexaoe.sts', 'w');

ftruncate($fp,0);

fwrite($fp,'1')

;

fclose($fp);

if (($sock = socket_create (AF_INET, SOCK_STREAM, 0)) < 0) {


ftruncate($fp,0);

fwrite($fp,'-1');

fclose($fp);

die("Falha criando Socket: " . socket_strerror ($sock) . "\n");

}

if (($ret = socket_bind ($sock, $address, $port)) < 0) {


ftruncate($fp,0);

fwrite($fp,'-1');

fclose($fp);

die("Falha associando o socket a endereço e porta: " . socket_strerror ($ret) . "\n");

}

if (($ret = socket_listen ($sock, 5)) < 0) {


ftruncate($fp,0);

fwrite($fp,'-1');

fclose($fp);

die("Falha ao começar a escutar no socket: " . socket_strerror ($ret) . "\n");

}


ftruncate($fp,0);

fwrite($fp,'2');

fclose($fp);

do {

if (($msgsock = socket_accept($sock)) < 0) {


ftruncate($fp,0);

fwrite($fp,'-1');

59

fclose($fp);

die("Falha ao aceitar conexão no socket: " . socket_strerror ($msgsock) . "\n");

break;

}


ftruncate($fp,0);

fwrite($fp,'3');

fclose($fp);

$msg = "0\n";

socket_write($msgsock, $msg, strlen($msg));

do {

if (FALSE == ($buf = socket_read ($msgsock, 2048, PHP_NORMAL_READ))) {

echo "Erro recebendo dados do socket" . socket_strerror ($ret) . "\n";

break 2;

}

if (!$buf = trim ($buf)) {

continue;

}

$confs=split(',',$buf);

if ($buf == 'R') {

break;

}

if ($buf == 'E') {

socket_close ($msgsock);

break 2;

}

if ($confs[0] == 'I') {

$numfluxos=intval($confs[1]);

$ipmaster=$confs[2];

$tipomarca=$confs[3];

$tempoteste=$confs[4];

$resp = "I,F,".$numfluxos." \n";

socket_write ($msgsock, $resp, strlen ($resp));

//break;

}

if ($confs[0] == 'F') {

if($numfluxos > 0 & intval($confs[1]) <= $numfluxos){

$fmarca[$confs[1]] = $confs[2];

$fbanda[$confs[1]] = $confs[3];

$ftampacote[$confs[1]] = $confs[4];

$resp = "F,".$confs[1].",OK \n";


//break;

}

else{

$resp = "F,".$confs[1].",NOK\n";


break 2;

}

60

}

if ($confs[0] == 'S') {

$resp = "S,GO\n";



ftruncate($fp,0);

fwrite($fp,'4');

fclose($fp);

for($i=1; $i <= $numfluxos;$i++)

{

$cmd = "iperf -c ".$ipmaster." -b ".$fbanda[$i]." -t ".$tempoteste." -p 500".$i." -S

".$fmarca[$i]." -l ".$ftampacote[$i]." > /dev/null &";

echo $cmd."\n";

passthru($cmd);

}

//break;

}

if ($confs[0] == 'T') {

$resp = "T,BYE\n";



ftruncate($fp,0);

fwrite($fp,'5');

fclose($fp);


break 2;

}

} while (true);


} while (true);

socket_close ($sock);

?>

61

APÊNDICE D – Script PHP para armazenar dados do teste e fluxo na base de dados e

inicializar o agente mestre: salvar_teste.php

<?php

session_start();

function Redirecionar_URL(){

echo "<script language=\"JavaScript\">function redireciona()

{window.location=\"status_mestre.php\";}redireciona();</script>";

}

include "dbconn.inc";

if (!$conn) {

die('Could not connect to MySQL: ' . mysqli_connect_error());

}

mysqli_query($conn, 'SET NAMES \'utf8\'');

mysqli_autocommit($conn,FALSE);

$tipo_marca = ($_SESSION["Teste_Tipo_Marca"] == "DSCP") ? 1 : 2;

$result = mysqli_query($conn, 'INSERT INTO testes (teste_nome, teste_tipo_marca,

teste_num_fluxo, teste_ip_escravo, teste_ip_mestre, teste_tempo, teste_data, teste_erro)

VALUES

("'.$_SESSION["Teste_Nome"].'",'.$tipo_marca.','.$_SESSION["Teste_Num_Fluxos"].',"'.$_

SESSION["Teste_IP_Escravo"].'","'.$_SESSION["Teste_IP_Mestre"].'","'.$_SESSION["Teste

_Tempo"].'","'.date("m/d/Y").'",0)');

$teste_id = mysqli_insert_id($conn);

$_SESSION["TesteID"]=$teste_id;

if(!$result) {

mysqli_rollback($conn);

echo mysqli_error($conn);

die('Erro inserido dados do teste');

}

mysqli_free_result($result);

for($i=1; $i <= $_SESSION["Teste_Num_Fluxos"];$i++)

{

$tmp=split('-',$_SESSION["ClasseQos".$i]);

$classe = $tmp[0];

if($tipo_marca==1){

$marca = dechex((intval($_SESSION["MarcaF".$i])*4));

}

else{

$marca = dechex((intval($_SESSION["MarcaF".$i])*8*4));

}

if(strlen($marca) < 2){

$marca = "0".$marca;

}

$banda = intval($_SESSION["Teste_Banda_F".$i]);

$tampacote = intval($_SESSION["Teste_Tam_Pacote_F".$i]);

echo 'INSERT INTO fluxos_teste (teste_id, fluxo_id, fluxo_classe, fluxo_marca,

fluxo_banda, fluxo_tam_pacote) VALUES ('.$teste_id.', '.$i.', '.$classe.', "'.$marca.'",

'.$banda.', '.$tampacote.')';

62

$result1 = mysqli_query($conn, 'INSERT INTO fluxos_teste (teste_id, fluxo_id,

fluxo_classe, fluxo_marca, fluxo_banda, fluxo_tam_pacote) VALUES ('.$teste_id.', '.$i.',

'.$classe.', "'.$marca.'", '.$banda.', '.$tampacote.')');

if(!$result1) {

mysqli_rollback($conn);

die('Erro inserido dados do fluxo'.$i);

}

mysqli_free_result($result1);

}

mysqli_commit($conn);

mysqli_close($conn);

echo "Dados Inseridos com Sucesso";

$ip=$_POST["ip_local"];

$cmd = "php ./cliente.php '$teste_id' >/dev/null & ";

passthru($cmd);

sleep(5);

Redirecionar_URL();

?>

63

APÊNDICE E – Agente mestre: cliente.php

<?php

error_reporting (E_ALL);

$teste_id = $argv[1];

$fp = fopen('status/statusconexaom.sts', 'w');

ftruncate($fp,0);

fwrite($fp,'1');

fclose($fp);


if (!$conn) {


}


$result=mysqli_query($conn,'SELECT * FROM testes WHERE teste_id='.$teste_id);

$row = mysqli_fetch_array($result, MYSQLI_ASSOC);

$teste_nome = $row['teste_nome'];

$teste_tipo_marca = $row['teste_tipo_marca'];

$teste_num_fluxo = $row['teste_num_fluxo'];

$teste_ip_escravo = $row['teste_ip_escravo'];

$teste_ip_mestre = $row['teste_ip_mestre'];

$teste_tempo = $row['teste_tempo'];


$address = $teste_ip_escravo;

$service_port = 1234;

$socket = socket_create (AF_INET, SOCK_STREAM, 0);

if ($socket < 0) {


ftruncate($fp,0 );

fwrite($fp,'-1');

fclose($fp);


die("Falha criando socket: " . socket_strerror ($socket) . "\n");

}

$conect = socket_connect ($socket, $address, $service_port);

if ($conect < 0) {


ftruncate($fp,0 );

fwrite($fp,'-1');

fclose($fp);

die("Falha na conexão: ($result) " . socket_strerror($conect) . "\n");

}

64


ftruncate($fp,0 );

fwrite($fp,'2');

fclose($fp);

$buf = socket_read ($socket, 1024);

$msg="I,".$teste_num_fluxo.",".$teste_ip_mestre.",".$teste_tipo_marca.",".$teste_tempo."\n"

;

socket_write ($socket, $msg, strlen ($msg));


$resp=split(',',$buf);

if($resp[0] == "I" & $resp[1] == "F" & intval($resp[2]) == $teste_num_fluxo){


ftruncate($fp,0 );

fwrite($fp,'3');

fclose($fp);

}

else{


ftruncate($fp,0 );

fwrite($fp,'-1');

fclose($fp);

socket_write ($socket,"E\n",3);

socket_close ($socket);


die("Erro na troca de dados do teste!!!");

}

for($i=1; $i <= $teste_num_fluxo;$i++){

$result = mysqli_query($conn, 'SELECT fluxo_marca, fluxo_banda, fluxo_tam_pacote

FROM fluxos_teste WHERE teste_id='.$teste_id.' AND fluxo_id='.$i);


$qos[$i]="0x".$row['fluxo_marca'];

$msg="F,".$i.",0x".$row['fluxo_marca'].",".$row['fluxo_banda'].",".$row['fluxo_tam_pacote'].

"\n";

socket_write ($socket, $msg, strlen ($msg));



if(($resp[0] == 'F')){// & ($resp[2] == "OK")){


continue;

}

else{





ftruncate($fp,0 );

fwrite($fp,'-1');

fclose($fp);

65


die("Erro na troca de dados do fluxo!!!");

break;

}

}

for($i=1; $i <= $teste_num_fluxo;$i++)

{

$cmd1 = "ping -Q ".$qos[$i]." ".$teste_ip_escravo." | awk '/^[0-9]+ bytes from / { \"date

+%Y%m%d%H%M%S\" | getline d; close(\"date +%Y%m%d%H%M%S\") ; print d, \": \",

$0; }' > resultadoping".$i.".txt &";

$cmd2 = "iperf -s -i 1 -u -y C -p 500".$i." -S ".$qos[$i]." > saida".$i.".txt &";

passthru($cmd1);

passthru($cmd2);

}

sleep(2);

socket_write ($socket,"S\n",3);



if($resp[0] == 'S'){// & $resp[1] == "GO"){


ftruncate($fp,0 );

fwrite($fp,'4');

fclose($fp);

}

else{


ftruncate($fp,0 );

fwrite($fp,'-1');

fclose($fp);




$cmd= "killall iperf";

passthru($cmd);

$cmd= "killall ping";

passthru($cmd);

die("Erro na troca de dados!!!");

}

sleep(intval($teste_tempo)+10);

socket_write ($socket,"T\n",3);

66



if($resp[0]== 'T'){// & $resp[1] == "BYE"){


ftruncate($fp,0 );

fwrite($fp,'5');

fclose($fp);

}

else{


ftruncate($fp,0 );

fwrite($fp,'-1');

fclose($fp);




$cmd = "killall iperf";

passthru($cmd);

$cmd = "killall ping";

passthru($cmd);

die("Teste não finalizado corretamente!!!");

}



$cmd = "killall iperf";

passthru($cmd);

$cmd = "killall ping";

passthru($cmd);

for($i=1; $i <= $teste_num_fluxo;$i++)

{

$cmd1 = "bash ./apagaresumo.sh ".$teste_id." ".$i." saida".$i.".txt ".$dbuser." ".$dbpass."

".$basedados." &";

$cmd2 = "bash ./pings.sh ".$teste_id." ".$i." resultadoping".$i.".txt ".$dbuser." ".$dbpass."

".$basedados." &";

passthru($cmd1);

passthru($cmd2);

}


ftruncate($fp,0 );

fwrite($fp,'6');

fclose($fp);

//fim

?>

67

APÊNDICE F – Script PHP para gerar graficos: gera_grafico.php

<?php

include("pChart/pData.class");

include("pChart/pChart.class");

$testeid = $argv[1];

$numfluxos = $argv[2];


if (!$conn) {


}


$cont=0;

$result=mysqli_query($conn,'SELECT DISTINCT tempos FROM resultados_simples

WHERE testeid='.$testeid.' ORDER BY tempos LIMIT 1');


$tempoinicial = $row['tempos'] -1 ;


for($i = 1; $i <= $numfluxos; $i++){

$result = mysqli_query($conn, 'SELECT throughput, jitter, pacotes_perdidos,

pacotes_enviados, ping_rtt, tempos FROM resultados_simples R WHERE

R.testeid='.$testeid.' AND R.fluxoid='.$i.' ORDER BY tempos');

while (($row = mysqli_fetch_array($result, MYSQLI_ASSOC)) != NULL) {

$banda[$i][$cont] = $row['throughput']/1024;

$jitter[$i][$cont] = $row['jitter'];

$pperdidos[$i][$cont] = $row['pacotes_perdidos'];

$rtt[$i][$cont] = ($row['ping_rtt'] == null) ? 1000.0 : $row['ping_rtt'];

$tempos[$i][$cont] = $row['tempos'] - $tempoinicial;

$cont++;

echo $i." + ".$cont."\n";

}

$cont = 0;


}


// Dataset definition

$DataSet = new pData;


$DataSet->AddPoint($banda[$i],"BandaF".$i);

$DataSet->AddPoint($jitter[$i],"JitterF".$i);

$DataSet->AddPoint($pperdidos[$i],"PperdidosF".$i);

$DataSet->AddPoint($rtt[$i],"RttF".$i);

}

68

$DataSet->Addpoint($tempos[1],"Tempos");

$DataSet->SetAbsciseLabelSerie("Tempos");

$DataSet->SetXAxisName("Tempo de Teste");

//Grafico Largura de Banda

// Initialise the graph

$Test = new pChart(1200,300);

$Test->drawGraphAreaGradient(90,90,90,90,TARGET_BACKGROUND);

// Prepare the graph area

$Test->setFontProperties("fonts/tahoma.ttf",9);

$Test->setGraphArea(80,40,980,260);

// Initialise graph area



$DataSet->AddSerie("BandaF".$i);

$DataSet->SetSerieName("Largura de Banda Fluxo ".$i,"BandaF".$i);

}

// Draw the SourceForge Rank graph

$DataSet->SetYAxisName("Largura de Banda kbps");

$Test->drawScale($DataSet->GetData(),$DataSet-

>GetDataDescription(),SCALE_NORMAL,213,217,221,TRUE,0,0,FALSE,10,FALSE);

$Test->drawGraphAreaGradient(225,225,225,-30);

$Test->drawGrid(1,TRUE,155,155,155,10);

$Test->setShadowProperties(2,2,0,0,0,30,4);

$Test->drawCubicCurve($DataSet->GetData(),$DataSet->GetDataDescription());

$Test->clearShadow();

$Test->drawFilledCubicCurve($DataSet->GetData(),$DataSet->GetDataDescription(),.1,30);

// Write the legend (box less)


$Test->drawLegend(980,50,$DataSet-

>GetDataDescription(),0,0,0,0,0,0,255,255,255,FALSE);

// Write the title

$Test->setFontProperties("fonts/MankSans.ttf",18);

$Test->setShadowProperties(1,1,0,0,0);

$Test->drawTitle(0,0,"Resultado dos Testes - Largura de

Banda",255,255,255,1200,30,TRUE);


// Render the picture

$Test->Render("graficos/resultado_banda.png");


$DataSet->RemoveSerie("BandaF".$i);

69

$DataSet->removeSerieName("BandaF".$i);

}

//Grafico RTT










$DataSet->AddSerie("RttF".$i);

$DataSet->SetSerieName("RTT Fluxo ".$i,"RttF".$i);

}


$DataSet->SetYAxisName("RTT ms");













// Write the title



$Test->drawTitle(0,0,"Resultado dos Testes - RTT",255,255,255,1200,30,TRUE);



$Test->Render("graficos/resultado_rtt.png");


$DataSet->RemoveSerie("RttF".$i);

$DataSet->removeSerieName("RttF".$i);

}

70

//Grafico Jitter










$DataSet->AddSerie("JitterF".$i);

$DataSet->SetSerieName("Jitter Fluxo ".$i,"JitterF".$i);

}


$DataSet->SetYAxisName("Jitter ms");













// Write the title



$Test->drawTitle(0,0,"Resultado dos Testes - Jitter",255,255,255,1200,30,TRUE);



$Test->Render("graficos/resultado_jitter.png");


$DataSet->RemoveSerie("JitterF".$i);

$DataSet->removeSerieName("JitterF".$i);

}

//Grafico Pacotes Perdidos

71










$DataSet->AddSerie("PperdidosF".$i);

$DataSet->SetSerieName("Pacotes Perdidos Fluxo ".$i,"PperdidosF".$i);

}


$DataSet->SetYAxisName("Pacotes Perdidos");













// Write the title



$Test->drawTitle(0,0,"Resultado dos Testes - Pacotes

Perdidos",255,255,255,1200,30,TRUE);



$Test->Render("graficos/resultado_pperdidos.png");


$DataSet->RemoveSerie("PperdidosF".$i);

$DataSet->removeSerieName("PperdidosF".$i);

}

?>

72

APÊNDICE G – Pagina PHP com os resultados e gráficos do teste: resultados_teste.php

<?php

session_start();


if (!$conn) {


}


$numfluxos = $_SESSION["Teste_Num_Fluxos"];

$cont=0;


$jitter_status[$i]=0;

$rtt_status[$i]=0;

$banda_status[$i]=0;

$pperdidos_status[$i]=0;

$penviados[$i]=0;

$bandamedia[$i] = 0;

$penviados[$i] = 0;

$jittersoma[$i]= 0;

$rttsoma[$i]= 0;

$pperdidos[$i] = 0;

$jittermedia[$i]=0;

$rttmedia[$i]=0;

$tmp=split('-',$_SESSION["ClasseQos".$i]);

$classe = $tmp[0];

$result=mysqli_query($conn,'SELECT iptd, ipdv, iplr FROM classes_qos WHERE

classeid='.$classe);


$iptd[$i] = $row['iptd'] ;

$ipdv[$i] = $row['ipdv'] ;

$iplr[$i] = $row['iplr'] ;


$result=mysqli_query($conn, 'SELECT throughput, jitter, pacotes_perdidos,

pacotes_enviados, ping_rtt, tempos FROM resultados_simples R WHERE

R.testeid='.$_SESSION["TesteID"].' AND R.fluxoid='.$i.' ORDER BY tempos');

while (($row = mysqli_fetch_array($result, MYSQLI_ASSOC)) != NULL) {

$rtt =($row['ping_rtt'] == null) ? 1000.0 : $row['ping_rtt'];

if($ipdv[$i] != "ND"){

if($row['jitter'] > floatval($ipdv[$i]))

$jitter_status[$i]=$jitter_status[$i]+1;

}

if($iptd[$i] != "ND"){

if(($rtt/2 )> $iptd[$i])

$rtt_status[$i]=$rtt_status[$i]+1;

}

$bandamedia[$i] = $bandamedia[$i] + intval($row['throughput']);

$penviados[$i] = $penviados[$i] + intval($row['pacotes_enviados']);

73

$jittersoma[$i]=$jittersoma[$i]+$row['jitter'];

$rttsoma[$i]= $rttsoma[$i]+$row['ping_rtt'];

$pperdidos[$i] = $pperdidos[$i] + $row['pacotes_perdidos'];

$cont++;

}

$bandamedia[$i] = $bandamedia[$i]/$cont;

$bandaesperada[$i] = ($_SESSION["Teste_Banda_F".$i]-(336*$penviados[$i])/$cont);

if($bandamedia[$i] < $bandaesperada[$i]){

$banda_status[$i]=1;

}

$pperdidos[$i] = $pperdidos[$i] / $penviados[$i];

if($iplr[$i] != "ND"){

if($pperdidos[$i] > floatval($iplr[$i]))

$pperdidos_status[$i]=1;

}

$jittermedia[$i]=$jittersoma[$i]/$cont;

$rttmedia[$i]=$rttsoma[$i]/$cont;

$cont = 0;


}


?>

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

<html>

<head>

<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">

<title>Resultados</title>

</head>

<body>

<?php

echo " Resultados do Teste: ".$_SESSION["Teste_Nome"]." \n";

echo " Número de Fluxos: ".$_SESSION["Teste_Num_Fluxos"]." \n";

echo " IP Lado Mestre: ".$_SESSION["Teste_IP_Mestre"]." \n" ;

echo " IP Lado Escravo: ".$_SESSION["Teste_IP_Escravo"]." \n";

echo " Tempo de Teste ".$_SESSION["Teste_Tempo"]." segundos \n";

for($i=1; $i <= $_SESSION["Teste_Num_Fluxos"];$i++)

{

echo " Fluxo ".$i." : ";

echo " Classe QoS: ".$_SESSION["ClasseQos".$i]." \n";

echo " Tipo de Marca:

".(($_SESSION["Teste_Tipo_Marca"]==1)?"DSCP":(($_SESSION["Teste_Tipo_Marca"]==2

)?"IP Precedence":$_SESSION["Teste_Tipo_Marca"]))." \n";

echo " Marca QoS: 0x".$_SESSION["MarcaF".$i]." ";

echo " Largura de Banda: ".($_SESSION["Teste_Banda_F".$i])." bps \n";

echo " Tamanho dos Pacotes: ".$_SESSION["Teste_Tam_Pacote_F".$i]."

bytes \n";

74

echo "<table border=\"1\" cellspacing=\"1\" cellpadding=\"5\">";

echo "<thead>";

echo " <tr>";

echo "<th> Throughput </th>";

echo " <th>IPTD</th>";

echo " <th>IPDV</th>";

echo " <th>IPLR</th>";

echo "</tr>";

echo " </thead>";

echo " <tbody>";

echo " <tr>";

echo "<td> Média Obtida: ".$bandamedia[$i]."bps Minimo Esperado:

".$bandaesperada[$i]."bps Status:".(($banda_status[$i]==0)?" OK " : " NOK ")."</td>";

echo "<td> Média Obtida: ".number_format($rttmedia[$i], 3, '.', '')." ms 

Maximo Esperado: ".$iptd[$i]." ms Status: ".(($rtt_status[$i]==0)?" Média Obtida: ".number_format($jittermedia[$i], 3, '.', '')." ms Maximo Esperado: ".$ipdv[$i]." ms Status: ".(($jitter_status[$i]==0)?" Taxa Obtida: ".number_format($pperdidos[$i], 3, '.', '')." 

Maximo Esperado: ".$iplr[$i]." Status: ".(($pperdidos_status[$i]==0)?"";

echo "</tbody>";

echo "</table> ";

}

?>

 Graficos: 

<img src="graficos/resultado_banda.png" alt="resultado_banda"/>

<img src="graficos/resultado_jitter.png" alt="resultado_jitter"/>

<img src="graficos/resultado_rtt.png" alt="resultado_rtt"/>

<img src="graficos/resultado_pperdidos.png" alt="resultado_pperdidos"/>

</body>

</html>

75

APÊNDICE H – Resultados completos do laboratório de testes

Resultados do Teste: Cenário 1 - Teste 1

Número de Fluxos: 2

IP Lado Mestre: 192.168.1.6

IP Lado Escravo: 192.168.1.10

Tempo de Teste 300 segundos

Fluxo 1 :

Classe QoS: 1-Tempo Real Interativa

Tipo de Marca: DSCP

Marca QoS: 0x78

Largura de Banda: 300000 bps

Tamanho dos Pacotes: 1500 bytes

Throughput IPTD IPDV IPLR

Média Obtida:

293960.8bps

Minimo Esperado:

291601.12bps

Status: OK

Média Obtida: 6.272

ms

Maximo Esperado:

400 ms

Status: OK

Média Obtida:

4.129 ms

Maximo Esperado:

50 ms

Status: OK

Taxa Obtida: 0.000

Maximo Esperado:

0.001

Status: OK

Fluxo 2 :

Classe QoS: 5-Aplicações Padrão de Redes IP

Tipo de Marca: DSCP

Marca QoS: 0x28




Média Obtida:

1665608bps

Minimo Esperado:

1652411.2bps

Status: OK

Média Obtida:

17.417 ms

Maximo Esperado:

ND ms

Status: OK


ms

Maximo Esperado:

ND ms

Status: OK

Taxa Obtida:

0.000

Maximo

Esperado: ND

Status: OK

Graficos:

76






Fluxo 1 :


Tipo de Marca: DSCP

Marca QoS: 0x78




Média Obtida:

293960.8bps

Minimo Esperado:

291601.12bps

Status: OK


ms

Maximo Esperado:

400 ms

Status: OK

Média Obtida:

2.529 ms

Maximo Esperado:

50 ms

Status: OK

Taxa Obtida: 0.000

Maximo Esperado:

0.001

Status: OK

Fluxo 2 :


Tipo de Marca: DSCP

77

Marca QoS: 0x28




Média Obtida:

1666156.8bps

Minimo Esperado:

1652395.52bps

Status: OK


ms

Maximo Esperado:

ND ms

Status: OK


ms

Maximo Esperado:

ND ms

Status: OK

Taxa Obtida:

0.000

Maximo

Esperado: ND

Status: OK

Graficos:

78






Fluxo 1 :


Tipo de Marca: DSCP

Marca QoS: 0x78




Média Obtida:

293960.8bps

Minimo Esperado:

291601.12bps

Status: OK


ms

Maximo Esperado:

400 ms

Status: OK

Média Obtida:

3.569 ms

Maximo Esperado:

50 ms

Status: OK

Taxa Obtida: 0.000

Maximo Esperado:

0.001

Status: OK

Fluxo 2 :


Tipo de Marca: DSCP

Marca QoS: 0x28




Média Obtida:

1665333.6bps

Minimo Esperado:

1652419.04bps

Status: OK


ms

Maximo Esperado:

ND ms

Status: OK


ms

Maximo Esperado:

ND ms

Status: OK

Taxa Obtida:

0.000

Maximo

Esperado: ND

Status: OK

Graficos:

79






Fluxo 1 :

Classe QoS: 0-Tempo Real Altamente Interativa

Tipo de Marca: DSCP

Marca QoS: 0x78




Média Obtida:

195960.8bps

Minimo Esperado:

194401.12bps

Status: OK


ms

Maximo Esperado:

100 ms

Status: OK

Média Obtida:

2.006 ms

Maximo Esperado:

50 ms

Status: OK

Taxa Obtida: 0.000

Maximo Esperado:

0.001

Status: OK

Fluxo 2 :


Tipo de Marca: DSCP

80

Marca QoS: 0x50




Média Obtida:

146960.8bps

Minimo Esperado:

145801.12bps

Status: OK


ms

Maximo Esperado:

400 ms

Status: OK

Média Obtida:

1.681 ms

Maximo Esperado:

50 ms

Status: OK

Taxa Obtida: 0.000

Maximo Esperado:

0.001

Status: OK

Fluxo 3 :


Tipo de Marca: DSCP

Marca QoS: 0x28




Média Obtida:

1616804bps

Minimo Esperado:

1603805.6bps

Status: OK

Média Obtida:

11.825 ms

Maximo Esperado:

ND ms

Status: OK


ms

Maximo Esperado:

ND ms

Status: OK

Taxa Obtida:

0.000

Maximo

Esperado: ND

Status: OK

Graficos:

81






Fluxo 1 :


Tipo de Marca: DSCP

Marca QoS: 0x78




Média Obtida:

195960.8bps

Minimo Esperado:

194401.12bps

Status: OK


ms

Maximo Esperado:

100 ms

Status: OK

Média Obtida:

2.221 ms

Maximo Esperado:

50 ms

Status: OK

Taxa Obtida: 0.000

Maximo Esperado:

0.001

Status: OK

Fluxo 2 :


Tipo de Marca: DSCP

Marca QoS: 0x50




Média Obtida:

146960.8bps

Minimo Esperado:

145801.12bps


ms

Maximo Esperado:

400 ms

Média Obtida:

2.552 ms

Maximo Esperado:

50 ms

Taxa Obtida: 0.000

Maximo Esperado:

0.001

Status: OK

82


Status: OK Status: OK Status: OK

Fluxo 3 :


Tipo de Marca: DSCP

Marca QoS: 0x28




Média Obtida:

1616216bps

Minimo Esperado:

1603822.4bps

Status: OK

Média Obtida:

17.295 ms

Maximo Esperado:

ND ms

Status: OK


ms

Maximo Esperado:

ND ms

Status: OK

Taxa Obtida:

0.000

Maximo

Esperado: ND

Status: OK

Graficos:

83

Resultados do Teste: Cenario 2 - Teste 3





Fluxo 1 :


Tipo de Marca: DSCP

Marca QoS: 0x78




Média Obtida:

195960.8bps

Minimo Esperado:

194401.12bps

Status: OK


ms

Maximo Esperado:

100 ms

Status: NOK

Média Obtida:

2.366 ms

Maximo Esperado:

50 ms

Status: OK

Taxa Obtida: 0.000

Maximo Esperado:

0.001

Status: OK

Fluxo 2 :


Tipo de Marca: DSCP

Marca QoS: 0x50




Média Obtida:

146960.8bps

Minimo Esperado:

145801.12bps

Status: OK


ms

Maximo Esperado:

400 ms

Status: NOK

Média Obtida:

2.190 ms

Maximo Esperado:

50 ms

Status: OK

Taxa Obtida: 0.000

Maximo Esperado:

0.001

Status: OK

Fluxo 3 :


Tipo de Marca: DSCP

Marca QoS: 0x28



84


Média Obtida:

1616804bps

Minimo Esperado:

1603805.6bps

Status: OK

Média Obtida:

14.107 ms

Maximo Esperado:

ND ms

Status: OK


ms

Maximo Esperado:

ND ms

Status: OK

Taxa Obtida:

0.000

Maximo

Esperado: ND

Status: OK

Graficos:






Fluxo 1 :

85


Tipo de Marca: DSCP

Marca QoS: 0x78




Média Obtida:

195960.8bps

Minimo Esperado:

194401.12bps

Status: OK


ms

Maximo Esperado:

100 ms

Status: NOK

Média Obtida:

3.338 ms

Maximo Esperado:

50 ms

Status: OK

Taxa Obtida: 0.000

Maximo Esperado:

0.001

Status: OK

Fluxo 2 :


Tipo de Marca: DSCP

Marca QoS: 0x50




Média Obtida:

146960.8bps

Minimo Esperado:

145801.12bps

Status: OK


ms

Maximo Esperado:

400 ms

Status: NOK

Média Obtida:

2.591 ms

Maximo Esperado:

50 ms

Status: OK

Taxa Obtida: 0.000

Maximo Esperado:

0.001

Status: OK

Fluxo 3 :


Tipo de Marca: DSCP

Marca QoS: 0x28




Média Obtida:

1575604.8bps

Minimo Esperado:

1944104.16bps

Status: NOK

Média Obtida:

258.113 ms

Maximo Esperado:

ND ms

Status: OK


ms

Maximo Esperado:

ND ms

Status: OK

Taxa Obtida:

0.195

Maximo

Esperado: ND

Status: OK

Graficos:

86






Fluxo 1 :


Tipo de Marca: DSCP

Marca QoS: 0x78




Média Obtida:

195960.8bps


ms

Média Obtida:

2.710 ms

Taxa Obtida: 0.000

Maximo Esperado:

87


Minimo Esperado:

194401.12bps

Status: OK

Maximo Esperado:

100 ms

Status: OK

Maximo Esperado:

50 ms

Status: OK

0.001

Status: OK

Fluxo 2 :


Tipo de Marca: DSCP

Marca QoS: 0x50




Média Obtida:

146960.8bps

Minimo Esperado:

145801.12bps

Status: OK


ms

Maximo Esperado:

400 ms

Status: OK

Média Obtida:

2.776 ms

Maximo Esperado:

50 ms

Status: OK

Taxa Obtida: 0.000

Maximo Esperado:

0.001

Status: OK

Fluxo 3 :


Tipo de Marca: DSCP

Marca QoS: 0x28




Média Obtida: 1575448bps

Minimo Esperado:

1944073.92bps

Status: NOK

Média Obtida:

240.895 ms

Maximo Esperado:

ND ms

Status: OK


ms

Maximo Esperado:

ND ms

Status: OK

Taxa Obtida:

0.195

Maximo

Esperado: ND

Status: OK

Graficos:

88






Fluxo 1 :


Tipo de Marca: DSCP

Marca QoS: 0x78




Média Obtida:

195960.8bps

Minimo Esperado:

194401.12bps

Status: OK


ms

Maximo Esperado:

100 ms

Status: OK

Média Obtida:

2.840 ms

Maximo Esperado:

50 ms

Status: OK

Taxa Obtida: 0.000

Maximo Esperado:

0.001

Status: OK

Fluxo 2 :


Tipo de Marca: DSCP

Marca QoS: 0x50

89




Média Obtida:

146960.8bps

Minimo Esperado:

145801.12bps

Status: OK


ms

Maximo Esperado:

400 ms

Status: OK

Média Obtida:

2.469 ms

Maximo Esperado:

50 ms

Status: OK

Taxa Obtida: 0.000

Maximo Esperado:

0.001

Status: OK

Fluxo 3 :


Tipo de Marca: DSCP

Marca QoS: 0x28




Média Obtida:

1570469.6bps

Minimo Esperado:

1944069.44bps

Status: NOK

Média Obtida:

259.917 ms

Maximo Esperado:

ND ms

Status: OK


ms

Maximo Esperado:

ND ms

Status: OK

Taxa Obtida:

0.198

Maximo

Esperado: ND

Status: OK

Gráficos:

90

91

APÊNDICE I – Exemplos de telas de execução do sistema

Tela inicial do sistema.

Tela de configuração de novo teste lado mestre.

92

Tela de configuração de novo teste lado escravo.

Tela com o resumo das configurações do testes, apresentada antes de iniciar o teste.

93

Tela de estado do andamento do teste.


94


Tela de Resultados do Teste.

95

APÊNDICE J – Configurações dos roteadores

Roteador 1 – Cenário 1:

roteador1#show running-config

Building configuration...

!

version AR1700i+ - 1.0.42

!

hostname roteador1

!

mark-rule cenario1 mark 1 ip any any dscp class AF33


!

ip route 0.0.0.0 0.0.0.0 192.168.1.2

!

interface ethernet 0

ip mark cenario1 in

ip address 192.168.1.5 255.255.255.252

no ipx network

mtu 1500

txqueuelen 100

no shutdown

!

interface loopback 0

ip address 127.0.0.1 255.0.0.0

no shutdown

!

interface serial 0

physical-layer synchronous

encapsulation ppp

no backup

clock rate 2048000

clock type internal

no invert txclock

ip policy 1 0 300000bps queue fifo


ip address 192.168.1.1 255.255.255.252

no ipx network

ip peer-address 192.168.1.2

no ip vj

keepalive interval 5

keepalive timeout 3

no authentication

no shutdown

!

roteador1#

96

Roteador 1 – Cenários 2 e 3:



!


!

hostname roteador1

!

mark-rule cenario2e3 mark 1 ip any any dscp class AF33



!

ip route 0.0.0.0 0.0.0.0 192.168.1.2

!


ip mark cenario2e3 in

ip address 192.168.1.5 255.255.255.252

no ipx network

mtu 1500

txqueuelen 100

no shutdown

!


ip address 127.0.0.1 255.0.0.0

no shutdown

!

interface serial 0


encapsulation ppp

no backup

clock rate 2048000

clock type internal

no invert txclock




ip address 192.168.1.1 255.255.255.252

no ipx network


no ip vj


keepalive timeout 3

no authentication

no shutdown

!

roteador1#

97

Roteador 2 – Cenário 1:



!


!

hostname roteador2

!



!

ip route 0.0.0.0 0.0.0.0 192.168.1.1

!


ip mark cenario1 in

ip address 192.168.1.9 255.255.255.252

no ipx network

mtu 1500

txqueuelen 100

no shutdown

!


ip address 127.0.0.1 255.0.0.0

no shutdown

!

interface serial 0


encapsulation ppp

no backup

no clock rate

clock type external

no invert txclock



ip address 192.168.1.2 255.255.255.252

no ipx network


no ip vj


keepalive timeout 3

no authentication

no shutdown

!

roteador2#

98

Roteador 2 – Cenários 2 e 3:



!


!

hostname roteador2

!




!

ip route 0.0.0.0 0.0.0.0 192.168.1.1

!


ip mark cenario2e3 in

ip address 192.168.1.9 255.255.255.252

no ipx network

mtu 1500

txqueuelen 100

no shutdown

!


ip address 127.0.0.1 255.0.0.0

no shutdown

!

interface serial 0


encapsulation ppp

no backup

no clock rate

clock type external

no invert txclock




ip address 192.168.1.2 255.255.255.252

no ipx network


no ip vj


keepalive timeout 3

no authentication

no shutdown

!

roteador2#

Documents

IMPLEMENTAÇÃO DE AMBIENTE DE TESTES …lyceumonline.usf.edu.br/salavirtual/documentos/1886.pdf · AUTOMATIZADOS PARA AVALIAÇÃO DE PARÂMETROS DE QoS EM REDES DE COMUNICAÇÃO