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

Transcrição

1 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

2 BRUNO GALASSO MOLINARI RA 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

3 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.

4 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.

5 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.

6 LISTA DE FIGURAS FIGURA 1 - Camadas TCP/IP FIGURA 2 - Diagrama geral dos casos de uso FIGURA 3 - Diagrama de seqüência de um teste completo FIGURA 4 - Diagrama de classes FIGURA 5 - Estrutura de dados FIGURA 6 - Diagrama do laboratório de teste FIGURA 7 - Laboratório de testes visão geral FIGURA 8 - Laboratório de testes roteadores FIGURA 9 - Gráfico de atraso no teste 3 do cenário FIGURA 10 - Gráfico de atraso no teste 2 do cenário FIGURA 11 - Gráfico de atraso no teste 1 do cenário FIGURA 12 - Gráfico de atraso no teste 2 do cenário

7 LISTA DE TABELAS TABELA 1 - Classes de serviço ITU-T TABELA 2 - Classes de serviço e limites máximos TABELA 3 - Configurações dos fluxos de dados no cenário TABELA 4 - Configurações dos fluxos de dados no cenário TABELA 5 - Configurações dos fluxos de dados no cenário TABELA 6 - Resultados esperados nos testes no cenário TABELA 7 - Resultados dos testes no cenário TABELA 8 - Resultados esperados nos testes no cenário TABELA 9 - Resultados dos testes no cenário TABELA 10 - Resultados esperados nos testes no cenário TABELA 11 - Resultados dos testes no cenário

8 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

9 UTC Coordinated Universal Time VOIP Voice over IP WFQ Weighted Far Queue

10 SUMÁRIO 1 INTRODUÇÃO OBJETIVOS ORGANIZAÇÃO DO TRABALHO ASPECTOS TEÓRICOS ARQUITETURA INTERNET E TCP/IP QUALIDADE DE SERVIÇO Parâmetros de QoS Confiabilidade Delay Jitter Throughput Classes de Serviço Técnicas para Alcançar Qualidade de Serviço Superdimensionamento Armazenamento em Buffers Modelagem de Tráfego Mecanismos de Escalonamento FIFO Prioridade Varredura Cíclica WFQ Mecanismos de Regulação Algoritmo de Balde Furado Algoritmo de Balde de Símbolos... 27

11 2.2.3 Serviços Integrados e Serviços Diferenciados Serviços Integrados Serviços Diferenciados Intserv X Diffserv Utilização de QoS em redes METODOLOGIA FERRAMENTAS DESENVOLVIMENTO REQUISITOS CASOS DE USO Iniciar Teste Lado Mestre Iniciar Teste Lado Escravo Iniciar Testes Anteriores DIAGRAMAS DE SEQÜÊNCIA DIAGRAMA DE CLASSES MODELAGEM DE DADOS METODOLOGIA DE TESTES LABORATÓRIO DE TESTES CENÁRIOS DE TESTES Cenário Cenário Cenário REALIZAÇÃO DOS TESTES RESULTADOS E DISCUSSÕES RESULTADOS NO CENÁRIO RESULTADOS NO CENÁRIO RESULTADOS NO CENÁRIO

12 4.4 CONSIDERAÇÕES SOBRE OS RESULTADOS CONCLUSÃO EXTENSÕES REFERÊNCIAS REFERÊNCIAS CONSULTADAS APÊNDICES APÊNDICE A SHELL SCRIPT PARA TRATAMENTO DOS DADOS GERADOS PELO IPERF: APAGARESUMO.SH APÊNDICE B SHELL SCRIPT PARA TRATAMENTO DOS DADOS GERADOS PELO PING: PINGS.SH APÊNDICE C AGENTE ESCRAVO: SERVIDOR.PHP APÊNDICE D SCRIPT PHP PARA ARMAZENAR DADOS DO TESTE E FLUXO NA BASE DE DADOS E INICIALIZAR O AGENTE MESTRE: SALVAR_TESTE.PHP APÊNDICE E AGENTE MESTRE: CLIENTE.PHP 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 APÊNDICE H RESULTADOS COMPLETOS DO LABORATÓRIO DE TESTES APÊNDICE I EXEMPLOS DE TELAS DE EXECUÇÃO DO SISTEMA APÊNDICE J CONFIGURAÇÕES DOS ROTEADORES... 95

13 1 INTRODUÇÃO 12 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

14 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

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

16 2 ASPECTOS TEÓRICOS 15 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].

17 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

18 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] 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] 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

19 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] 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

20 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] 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

21 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 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.

22 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 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.

23 22 TABELA 2 - Classes de serviço e limites máximos Classe de Serviço IPTD (ms) IPDV (ms) IPLR IPER x10-3 1x x10-3 1x N* 1x10-3 1x N* 1x10-3 1x N* 1x10-3 1x N* N* N* N* *N Não especificado Técnicas para Alcançar Qualidade de Serviço Na seção 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 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

24 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 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 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].

25 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] 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 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.

26 Prioridade 25 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 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 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

27 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 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 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.

28 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] 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 Serviços Integrados

29 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 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 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

30 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 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 Intserv X Diffserv O Intserv é capaz de prover uma qualidade de serviço parecida com as de tecnologias

31 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 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

32 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.

33 3 METODOLOGIA 32 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 codinome Lenny, disponível em Foi utilizado o software Apache versão 2.0 como servidor HTTP ( com o módulo de suporte a linguagem PHP na versão 5.0 ( Como servidor de banco de dados, foi utilizado o software MySQL versão 5 ( O software utilizado pelo sistema para gerar os fluxos de dados é o iperf versão ( 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 ( 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 Todos os dados de configuração e resultados dos testes ficam armazenados em base de dados no servidor MySQL. E o software phpmyadmin ( foi usado para a criação e manutenções na base de dados.

34 3.2 Desenvolvimento 33 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 ( 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.

35 3.3 Requisitos 34 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 exibilos 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.

36 3.4 Casos de Uso 35 O sistema possui três casos de uso, que podem ser observados na Figura 2. FIGURA 2 - Diagrama geral dos casos de uso Iniciar Teste Lado Mestre Nome do Caso de Uso: Iniciar Teste Lado Mestre Ator Envolvido: Usuário 1 Ter acesso ao sistema. PRÉ-CONDIÇÃO 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. 1 Teste realizado. 2 Resultados exibidos. PÓS-CONDIÇÃO Sistema de Teste de QoS

37 Iniciar Teste Lado Escravo Nome do Caso de Uso: Iniciar Teste Lado Escravo Ator Envolvido: Usuário 1 Ter acesso ao sistema PRÉ-CONDIÇÃO 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. 1 Teste realizado. PÓS-CONDIÇÃO Sistema de Teste de QoS Iniciar Testes Anteriores Nome do Caso de Uso: Visualizar Testes Anteriores Sistema de Teste de QoS Ator Envolvido: Usuário 1 Ter acesso ao sistema. 2 Existirem testes já realizados PRÉ-CONDIÇÃO DESCRIÇÃO DO CASO 1 Clicar em iniciar Visualizar Resultados Anteriores; 2 Selecionar o teste desejado; 3 Visualizar resultados. 1 Resultados exibidos. PÓS-CONDIÇÃO 3.5 Diagramas de Seqüência A Figura 3 mostra o diagrama de seqüência da execução de um teste completo.

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

39 3.6 Diagrama de Classes 38 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;

40 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 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.

41 3.9 Laboratório de Testes 40 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 Cenários de Testes Foram criados três cenários de testes com configurações diferentes para avaliar o funcionamento e comportamento do software 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.

42 41 TABELA 3 - Configurações dos fluxos de dados no cenário 1 Fluxo Classe Largura de Banda (bps) Tamanho dos Pacotes (bytes) Tempo real, sensível ao jitter, interativa Aplicações padrões de redes IP 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. TABELA 4 - Configurações dos fluxos de dados no cenário 2 Fluxo Classe Largura de Banda (bps) Tempo real, sensível ao jitter, altamente interativa Tamanho dos Pacotes (bytes) Tempo real, sensível ao jitter, interativa Aplicações padrões de redes IP 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 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

43 42 de maior prioridade. TABELA 5 - Configurações dos fluxos de dados no cenário 3 Fluxo Classe Largura de Banda (bps) Tempo real, sensível ao jitter, altamente interativa Tamanho dos Pacotes (bytes) Tempo real, sensível ao jitter, interativa Aplicações padrões de redes IP 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.

44 43 FIGURA 7 - Laboratório de testes visão geral FIGURA 8 - Laboratório de testes roteadores

45 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 >= ,12 < 400 < 50 < 0,001 2 >= ,04 N N N *N Não especificado TABELA 7 - Resultados dos testes no cenário 1 Fluxo Teste Throughput (bps) IPTD (ms) IPDV (ms) IPLR ,8 6,772 4,129 0, ,8 5,246 2,529 0, ,8 6,594 3,569 0, ,0 17,417 3,967 0, ,8 8,301 2,863 0, ,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.

46 Resultados no Cenário 2 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 FIGURA 10 - Gráfico de atraso no teste 2 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. TABELA 8 - Resultados esperados nos testes no cenário 2 Fluxo Throughput (bps) IPTD (ms) IPDV (ms) IPLR 1 >= ,12 < 100 < 50 < 0,001 2 >= ,12 < 400 < 50 < 0,001 3 >= ,60 N N N *N Não especificado

47 46 TABELA 9 - Resultados dos testes no cenário 2 Fluxo Teste Throughput (bps) IPTD (ms) IPDV (ms) IPLR ,8 5,168 2,006 0, ,8 5,224 2,221 0, ,8 5,012 2,366 0, ,8 4,670 1,681 0, ,8 4,673 2,552 0, ,8 4,179 2,190 0, ,0 11,825 6,865 0, ,0 17,295 9,048 0, ,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. 4.3 Resultados no Cenário 3 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).

48 47 FIGURA 11 - Gráfico de atraso no teste 1 do cenário 3 FIGURA 12 - Gráfico de atraso no teste 2 do cenário 3 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. TABELA 10 - Resultados esperados nos testes no cenário 3 Fluxo Throughput (bps) IPTD (ms) IPDV (ms) IPLR 1 >= ,12 < 100 < 50 < 0,001 2 >= ,12 < 400 < 50 < 0,001 3 >= ,16 N N N *N Não especificado

49 48 TABELA 11 - Resultados dos testes no cenário 3 Fluxo Teste Throughput (bps) IPTD (ms) IPDV (ms) IPLR ,8 4,842 3,338 0, ,8 4,952 2,710 0, ,8 5,151 2,366 0, ,8 4,832 2,840 0, ,8 4,635 2,776 0, ,8 4,927 2,469 0, ,8 258,113 9,646 0, ,0 240,895 9,996 0, ,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

50 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.

51 5 CONCLUSÃO 50 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,

52 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.

53 REFERÊNCIAS 52 1 KUROSE, J. F.; ROSS, K. W. Redes de Computadores e a Internet: uma abordagem topdown. 3ª edição. São Paulo: Pearson, p. 2 FLUKE NETWORKS. One Touch Series II: Overview. Disponível em: < Acesso em: 08 mar FLUKE NETWORKS. Test and Troubleshoot. Disponível em: < temap&categorycode=lant>. Acesso em: 08 mar JDSU. SmartClass Ethernet. Disponível em: < Acesso em: 08 mar JDSU. Acess Network Test. Disponível em: < Test>. Acesso em: 08 mar FLUKE NETWORKS. EtherScope Series II: Overview. Disponível em: < Acesso em: 08 mar JDSU. T-BERD 4000 Multiple Services Test Platform. Disponível em: < Acesso em: 08 mar CISCO SYSTEMS. Internetworking Technology Handbook: Internet Protocols (IP). Disponível em: <

54 53 Protocols.html#wp2468>. Acesso em: 07 mar OODAN, A. et al. Telecommunications Quality of Service Management: From legacy to emerging services. Londres, Reino Unido: The Institution Of Engineering And Technology, p. 10 ISO - INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO 8402:1994: Quality management and quality assurance -- Vocabulary. Disponível em: < 15>. Acesso em: 12 abr ITU INTERNATIONAL TELECOMMUNICATION UNION. Terms and definitions related to quality of service and network performance including dependability. Disponível em: < REC-E.800>. Acesso em: 03 mar MARCHESE, M. QoS Over Heterogeneous Networks. West Sussex: John Wiley & Sons, p. 13 TANENBAUM, A. S. Rede de Computadores. 4ª edição. Rio de Janeiro: Campus/Elsevier, p. 14 BRAUN, T. et al. End-to-End Quality of Service Over Heterogeneous Networks. Berlin: Springer, p. 15 DATTATREYA, G. R. Performance Analysis of Queuing and Computer Networks. 1ª edição. Boca Raton: CRC Press, p. 16 PETERSON, L. L.; DAVIE, B.S. Computer Networks: A Systems Approach. 3. ed. San Francisco: Elsevier Science, p. 17 XIAO, X. Technical, commercial, and regulatory challenges of QoS: An Internet Service Model Perspective. Burlington: Elsevier, p.

55 REFERÊNCIAS CONSULTADAS 54 BEZERRA, E. Princípios de análise e projeto de sistemas com UML. Rio de Janeiro: Elsevier, p. BLUM, R. Linux Command Line and Shell Scripting Bible. Indianapolis: Wiley Publishing, p. BURTCH, K. O. Linux Shell Scripting with Bash. 1ª edição. Indianapolis: Sams Publishing, p. CONVERSE, T.; PARK, J.; MORGAN, C. PHP5 and MySQL Bible. Indianapolis: Wiley Publishing, p. MySQL AB. MySQL 5.1 Reference. Disponível em: < Acesso em: 06 mar NARAMORE, E.; GERNER, J.; SCOUARNEC, Y. L.; STOLZ, J.;GLASS, M. K. Beginning PHP5, Apache, and MySQL Web Development. Indianapolis: Wiley Publishing, p. PETERS, R. Expert Shell Scripting. 1ª edição: Apress, p. PHP GROUP. PHP: Documentation. Disponível em: < Acesso em: 06 mar RNP REDE NACIONAL DE ENSINO E PESQUISA. QoS. Disponível em: < Acesso em: 27 fev

56 APÊNDICES 55

57 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` for i in $linhas; do if [ "$cont" -eq 0 ]; then tinicial=" " 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) ` echo ${colarray[0] colarray[1]=$(echo $i cut -d',' -f2) colarray[2]=$(echo $i cut -d',' -f3) colarray[3]=$(echo $i cut -d',' -f8) colarray[4]=$(echo $i cut -d',' -f9) colarray[5]=$(echo $i cut -d',' -f10) colarray[6]=$(echo $i cut -d',' -f11) colarray[7]=$(echo $i cut -d',' -f12) 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

58 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 for i in $linhas; do 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

59 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) { $fp = fopen('status/statusconexaoe.sts', 'w'); ftruncate($fp,0); fwrite($fp,'-1'); fclose($fp); die("falha criando Socket: ". socket_strerror ($sock). "\n"); if (($ret = socket_bind ($sock, $address, $port)) < 0) { $fp = fopen('status/statusconexaoe.sts', 'w'); 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) { $fp = fopen('status/statusconexaoe.sts', 'w'); ftruncate($fp,0); fwrite($fp,'-1'); fclose($fp); die("falha ao começar a escutar no socket: ". socket_strerror ($ret). "\n"); $fp = fopen('status/statusconexaoe.sts', 'w'); ftruncate($fp,0); fwrite($fp,'2'); fclose($fp); do { if (($msgsock = socket_accept($sock)) < 0) { $fp = fopen('status/statusconexaoe.sts', 'w'); ftruncate($fp,0); fwrite($fp,'-1');

60 59 fclose($fp); die("falha ao aceitar conexão no socket: ". socket_strerror ($msgsock). "\n"); break; $fp = fopen('status/statusconexaoe.sts', 'w'); 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"; socket_write ($msgsock, $resp, strlen ($resp)); //break; else{ $resp = "F,".$confs[1].",NOK\n"; socket_write ($msgsock, $resp, strlen ($resp)); break 2;

61 if ($confs[0] == 'S') { $resp = "S,GO\n"; socket_write ($msgsock, $resp, strlen ($resp)); $fp = fopen('status/statusconexaoe.sts', 'w'); 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"; socket_write ($msgsock, $resp, strlen ($resp)); $fp = fopen('status/statusconexaoe.sts', 'w'); ftruncate($fp,0); fwrite($fp,'5'); fclose($fp); socket_close ($msgsock); break 2; while (true); socket_close ($msgsock); while (true); socket_close ($sock);?> 60

62 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.')';

63 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();?>

64 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); include "dbconn.inc"; if (!$conn) { die('could not connect to MySQL: '. mysqli_connect_error()); mysqli_query($conn, 'SET NAMES \'utf8\''); $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']; mysqli_free_result($result); $address = $teste_ip_escravo; $service_port = 1234; $socket = socket_create (AF_INET, SOCK_STREAM, 0); if ($socket < 0) { $fp = fopen('status/statusconexaom.sts', 'w'); ftruncate($fp,0 ); fwrite($fp,'-1'); fclose($fp); mysqli_close($conn); die("falha criando socket: ". socket_strerror ($socket). "\n"); $conect = socket_connect ($socket, $address, $service_port); if ($conect < 0) { $fp = fopen('status/statusconexaom.sts', 'w'); ftruncate($fp,0 ); fwrite($fp,'-1'); fclose($fp); die("falha na conexão: ($result) ". socket_strerror($conect). "\n");

65 $fp = fopen('status/statusconexaom.sts', 'w'); 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)); $buf = socket_read ($socket, 1024); $resp=split(',',$buf); if($resp[0] == "I" & $resp[1] == "F" & intval($resp[2]) == $teste_num_fluxo){ $fp = fopen('status/statusconexaom.sts', 'w'); ftruncate($fp,0 ); fwrite($fp,'3'); fclose($fp); else{ $fp = fopen('status/statusconexaom.sts', 'w'); ftruncate($fp,0 ); fwrite($fp,'-1'); fclose($fp); socket_write ($socket,"e\n",3); socket_close ($socket); mysqli_close($conn); 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); $row = mysqli_fetch_array($result, MYSQLI_ASSOC); $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)); $buf = socket_read ($socket, 1024); $resp=split(',',$buf); if(($resp[0] == 'F')){// & ($resp[2] == "OK")){ mysqli_free_result($result); continue; else{ mysqli_free_result($result); socket_write ($socket,"e\n",3); socket_close ($socket); $fp = fopen('status/statusconexaom.sts', 'w'); ftruncate($fp,0 ); fwrite($fp,'-1'); fclose($fp); 64

66 65 mysqli_close($conn); 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); $buf = socket_read ($socket, 1024); $resp=split(',',$buf); if($resp[0] == 'S'){// & $resp[1] == "GO"){ $fp = fopen('status/statusconexaom.sts', 'w'); ftruncate($fp,0 ); fwrite($fp,'4'); fclose($fp); else{ $fp = fopen('status/statusconexaom.sts', 'w'); ftruncate($fp,0 ); fwrite($fp,'-1'); fclose($fp); socket_write ($socket,"e\n",3); socket_close ($socket); mysqli_close($conn); $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);

67 66 $buf = socket_read ($socket, 1024); $resp=split(',',$buf); if($resp[0]== 'T'){// & $resp[1] == "BYE"){ $fp = fopen('status/statusconexaom.sts', 'w'); ftruncate($fp,0 ); fwrite($fp,'5'); fclose($fp); else{ $fp = fopen('status/statusconexaom.sts', 'w'); ftruncate($fp,0 ); fwrite($fp,'-1'); fclose($fp); socket_write ($socket,"e\n",3); socket_close ($socket); mysqli_close($conn); $cmd = "killall iperf"; passthru($cmd); $cmd = "killall ping"; passthru($cmd); die("teste não finalizado corretamente!!!"); mysqli_close($conn); socket_close ($socket); $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); $fp = fopen('status/statusconexaom.sts', 'w'); ftruncate($fp,0 ); fwrite($fp,'6'); fclose($fp); //fim?>

68 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]; include "dbconn.inc"; if (!$conn) { die('could not connect to MySQL: '. mysqli_connect_error()); mysqli_query($conn, 'SET NAMES \'utf8\''); $cont=0; $result=mysqli_query($conn,'select DISTINCT tempos FROM resultados_simples WHERE testeid='.$testeid.' ORDER BY tempos LIMIT 1'); $row = mysqli_fetch_array($result, MYSQLI_ASSOC); $tempoinicial = $row['tempos'] -1 ; mysqli_free_result($result); 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)? : $row['ping_rtt']; $tempos[$i][$cont] = $row['tempos'] - $tempoinicial; $cont++; echo $i." + ".$cont."\n"; $cont = 0; mysqli_free_result($result); mysqli_close($conn); // Dataset definition $DataSet = new pdata; for($i = 1; $i <= $numfluxos; $i++){ $DataSet->AddPoint($banda[$i],"BandaF".$i); $DataSet->AddPoint($jitter[$i],"JitterF".$i); $DataSet->AddPoint($pperdidos[$i],"PperdidosF".$i); $DataSet->AddPoint($rtt[$i],"RttF".$i);

69 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 $Test->setFontProperties("fonts/tahoma.ttf",9); for($i = 1; $i <= $numfluxos; $i++){ $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->setFontProperties("fonts/tahoma.ttf",12); $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); $Test->clearShadow(); // Render the picture $Test->Render("graficos/resultado_banda.png"); for($i = 1; $i <= $numfluxos; $i++){ $DataSet->RemoveSerie("BandaF".$i);

70 69 $DataSet->removeSerieName("BandaF".$i); //Grafico RTT // 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 $Test->setFontProperties("fonts/tahoma.ttf",9); for($i = 1; $i <= $numfluxos; $i++){ $DataSet->AddSerie("RttF".$i); $DataSet->SetSerieName("RTT Fluxo ".$i,"rttf".$i); // Draw the SourceForge Rank graph $DataSet->SetYAxisName("RTT ms"); $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->setFontProperties("fonts/tahoma.ttf",12); $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 - RTT",255,255,255,1200,30,TRUE); $Test->clearShadow(); // Render the picture $Test->Render("graficos/resultado_rtt.png"); for($i = 1; $i <= $numfluxos; $i++){ $DataSet->RemoveSerie("RttF".$i); $DataSet->removeSerieName("RttF".$i);

71 70 //Grafico Jitter // 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 $Test->setFontProperties("fonts/tahoma.ttf",9); for($i = 1; $i <= $numfluxos; $i++){ $DataSet->AddSerie("JitterF".$i); $DataSet->SetSerieName("Jitter Fluxo ".$i,"jitterf".$i); // Draw the SourceForge Rank graph $DataSet->SetYAxisName("Jitter ms"); $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->setFontProperties("fonts/tahoma.ttf",12); $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 - Jitter",255,255,255,1200,30,TRUE); $Test->clearShadow(); // Render the picture $Test->Render("graficos/resultado_jitter.png"); for($i = 1; $i <= $numfluxos; $i++){ $DataSet->RemoveSerie("JitterF".$i); $DataSet->removeSerieName("JitterF".$i); //Grafico Pacotes Perdidos

72 71 // 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 $Test->setFontProperties("fonts/tahoma.ttf",9); for($i = 1; $i <= $numfluxos; $i++){ $DataSet->AddSerie("PperdidosF".$i); $DataSet->SetSerieName("Pacotes Perdidos Fluxo ".$i,"pperdidosf".$i); // Draw the SourceForge Rank graph $DataSet->SetYAxisName("Pacotes Perdidos"); $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->setFontProperties("fonts/tahoma.ttf",12); $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 - Pacotes Perdidos",255,255,255,1200,30,TRUE); $Test->clearShadow(); // Render the picture $Test->Render("graficos/resultado_pperdidos.png"); for($i = 1; $i <= $numfluxos; $i++){ $DataSet->RemoveSerie("PperdidosF".$i); $DataSet->removeSerieName("PperdidosF".$i);?>

73 72 APÊNDICE G Pagina PHP com os resultados e gráficos do teste: resultados_teste.php <?php session_start(); include "dbconn.inc"; if (!$conn) { die('could not connect to MySQL: '. mysqli_connect_error()); mysqli_query($conn, 'SET NAMES \'utf8\''); $numfluxos = $_SESSION["Teste_Num_Fluxos"]; $cont=0; for($i = 1; $i <= $numfluxos; $i++){ $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); $row = mysqli_fetch_array($result, MYSQLI_ASSOC); $iptd[$i] = $row['iptd'] ; $ipdv[$i] = $row['ipdv'] ; $iplr[$i] = $row['iplr'] ; mysqli_free_result($result); $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)? : $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']);

74 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; mysqli_free_result($result); mysqli_close($conn);?> <!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 "<b> Resultados do Teste:</b> ".$_SESSION["Teste_Nome"]."<br />\n"; echo "<b> Número de Fluxos:</b> ".$_SESSION["Teste_Num_Fluxos"]."<br />\n"; echo "<b> IP Lado Mestre:</b> ".$_SESSION["Teste_IP_Mestre"]."<br />\n" ; echo "<b> IP Lado Escravo:</b> ".$_SESSION["Teste_IP_Escravo"]."<br />\n"; echo "<b> Tempo de Teste</b> ".$_SESSION["Teste_Tempo"]." segundos<br /><br />\n"; for($i=1; $i <= $_SESSION["Teste_Num_Fluxos"];$i++) { echo "<b> Fluxo ".$i."</b> : <br />"; echo "<b> Classe QoS:</b> ".$_SESSION["ClasseQos".$i]."<br />\n"; echo "<b> Tipo de Marca:</b> ".(($_SESSION["Teste_Tipo_Marca"]==1)?"DSCP":(($_SESSION["Teste_Tipo_Marca"]==2 )?"IP Precedence":$_SESSION["Teste_Tipo_Marca"]))."<br />\n"; echo "<b> Marca QoS:</b> 0x".$_SESSION["MarcaF".$i]."<br />"; echo "<b> Largura de Banda:</b> ".($_SESSION["Teste_Banda_F".$i])." bps<br />\n"; echo "<b> Tamanho dos Pacotes:</b> ".$_SESSION["Teste_Tam_Pacote_F".$i]." bytes<br />\n";

75 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<br /> Minimo Esperado: ".$bandaesperada[$i]."bps <br /> Status:".(($banda_status[$i]==0)?"<font color=\"#00ff00\"> OK </font>" : "<font color=\"#ff0000\"> NOK </font>")."</td>"; echo "<td> Média Obtida: ".number_format($rttmedia[$i], 3, '.', '')." ms <br /> ".$iptd[$i]." ms <br /> Status: ".(($rtt_status[$i]==0)?"<font color=\"#00ff00\"> OK </font>" : "<font color=\"#ff0000\"> NOK </font>")."</td>"; echo "<td> Média Obtida: ".number_format($jittermedia[$i], 3, '.', '')." ms <br /> ".$ipdv[$i]." ms <br /> Status: ".(($jitter_status[$i]==0)?"<font color=\"#00ff00\"> OK </font>" : "<font color=\"#ff0000\"> NOK </font>")."</td>"; echo "<td> Taxa Obtida: ".number_format($pperdidos[$i], 3, '.', '')." <br /> ".$iplr[$i]." <br /> Status: ".(($pperdidos_status[$i]==0)?"<font color=\"#00ff00\"> OK </font>" : "<font color=\"#ff0000\"> NOK </font>")."</td>"; echo "</tr>"; echo "</tbody>"; echo "</table><br />";?> <b> Graficos: <br /></b> <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>

76 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: IP Lado Escravo: Tempo de Teste 300 segundos Fluxo 1 : Classe QoS: 1-Tempo Real Interativa Tipo de Marca: DSCP Marca QoS: 0x78 Largura de Banda: bps Tamanho dos Pacotes: 1500 bytes Throughput IPTD IPDV IPLR Média Obtida: bps Minimo Esperado: bps Média Obtida: ms 400 ms Média Obtida: ms 50 ms Taxa Obtida: Fluxo 2 : Classe QoS: 5-Aplicações Padrão de Redes IP Tipo de Marca: DSCP Marca QoS: 0x28 Largura de Banda: bps Tamanho dos Pacotes: 1500 bytes Throughput IPTD IPDV IPLR Média Obtida: bps Minimo Esperado: bps Média Obtida: ms ND ms Média Obtida: ms ND ms Taxa Obtida: Maximo Esperado: ND Graficos:

77 76 Resultados do Teste: Cenário 1 - Teste 2 Número de Fluxos: 2 IP Lado Mestre: IP Lado Escravo: Tempo de Teste 300 segundos Fluxo 1 : Classe QoS: 1-Tempo Real Interativa Tipo de Marca: DSCP Marca QoS: 0x78 Largura de Banda: bps Tamanho dos Pacotes: 1500 bytes Throughput IPTD IPDV IPLR Média Obtida: bps Minimo Esperado: bps Média Obtida: ms 400 ms Média Obtida: ms 50 ms Taxa Obtida: Fluxo 2 : Classe QoS: 5-Aplicações Padrão de Redes IP Tipo de Marca: DSCP

78 77 Marca QoS: 0x28 Largura de Banda: bps Tamanho dos Pacotes: 1500 bytes Throughput IPTD IPDV IPLR Média Obtida: bps Minimo Esperado: bps Média Obtida: ms ND ms Média Obtida: ms ND ms Taxa Obtida: Maximo Esperado: ND Graficos:

79 78 Resultados do Teste: Cenário 1 - Teste 3 Número de Fluxos: 2 IP Lado Mestre: IP Lado Escravo: Tempo de Teste 300 segundos Fluxo 1 : Classe QoS: 1-Tempo Real Interativa Tipo de Marca: DSCP Marca QoS: 0x78 Largura de Banda: bps Tamanho dos Pacotes: 1500 bytes Throughput IPTD IPDV IPLR Média Obtida: bps Minimo Esperado: bps Média Obtida: ms 400 ms Média Obtida: ms 50 ms Taxa Obtida: Fluxo 2 : Classe QoS: 5-Aplicações Padrão de Redes IP Tipo de Marca: DSCP Marca QoS: 0x28 Largura de Banda: bps Tamanho dos Pacotes: 1500 bytes Throughput IPTD IPDV IPLR Média Obtida: bps Minimo Esperado: bps Média Obtida: ms ND ms Média Obtida: ms ND ms Taxa Obtida: Maximo Esperado: ND Graficos:

80 79 Resultados do Teste: Cenário 2 - Teste 1 Número de Fluxos: 3 IP Lado Mestre: IP Lado Escravo: Tempo de Teste 300 segundos Fluxo 1 : Classe QoS: 0-Tempo Real Altamente Interativa Tipo de Marca: DSCP Marca QoS: 0x78 Largura de Banda: bps Tamanho dos Pacotes: 1500 bytes Throughput IPTD IPDV IPLR Média Obtida: bps Minimo Esperado: bps Média Obtida: ms 100 ms Média Obtida: ms 50 ms Taxa Obtida: Fluxo 2 : Classe QoS: 1-Tempo Real Interativa Tipo de Marca: DSCP

81 80 Marca QoS: 0x50 Largura de Banda: bps Tamanho dos Pacotes: 1500 bytes Throughput IPTD IPDV IPLR Média Obtida: bps Minimo Esperado: bps Média Obtida: ms 400 ms Média Obtida: ms 50 ms Taxa Obtida: Fluxo 3 : Classe QoS: 5-Aplicações Padrão de Redes IP Tipo de Marca: DSCP Marca QoS: 0x28 Largura de Banda: bps Tamanho dos Pacotes: 1500 bytes Throughput IPTD IPDV IPLR Média Obtida: bps Minimo Esperado: bps Média Obtida: ms ND ms Média Obtida: ms ND ms Taxa Obtida: Maximo Esperado: ND Graficos:

82 81 Resultados do Teste: Cenário 2 - Teste 2 Número de Fluxos: 3 IP Lado Mestre: IP Lado Escravo: Tempo de Teste 300 segundos Fluxo 1 : Classe QoS: 0-Tempo Real Altamente Interativa Tipo de Marca: DSCP Marca QoS: 0x78 Largura de Banda: bps Tamanho dos Pacotes: 1500 bytes Throughput IPTD IPDV IPLR Média Obtida: bps Minimo Esperado: bps Média Obtida: ms 100 ms Média Obtida: ms 50 ms Taxa Obtida: Fluxo 2 : Classe QoS: 1-Tempo Real Interativa Tipo de Marca: DSCP Marca QoS: 0x50 Largura de Banda: bps Tamanho dos Pacotes: 1500 bytes Throughput IPTD IPDV IPLR Média Obtida: bps Minimo Esperado: bps Média Obtida: ms 400 ms Média Obtida: ms 50 ms Taxa Obtida:

83 82 Throughput IPTD IPDV IPLR Fluxo 3 : Classe QoS: 5-Aplicações Padrão de Redes IP Tipo de Marca: DSCP Marca QoS: 0x28 Largura de Banda: bps Tamanho dos Pacotes: 1500 bytes Throughput IPTD IPDV IPLR Média Obtida: bps Minimo Esperado: bps Média Obtida: ms ND ms Média Obtida: ms ND ms Taxa Obtida: Maximo Esperado: ND Graficos:

84 83 Resultados do Teste: Cenario 2 - Teste 3 Número de Fluxos: 3 IP Lado Mestre: IP Lado Escravo: Tempo de Teste 300 segundos Fluxo 1 : Classe QoS: 0-Tempo Real Altamente Interativa Tipo de Marca: DSCP Marca QoS: 0x78 Largura de Banda: bps Tamanho dos Pacotes: 1500 bytes Throughput IPTD IPDV IPLR Média Obtida: bps Minimo Esperado: bps Média Obtida: ms 100 ms Status: NOK Média Obtida: ms 50 ms Taxa Obtida: Fluxo 2 : Classe QoS: 1-Tempo Real Interativa Tipo de Marca: DSCP Marca QoS: 0x50 Largura de Banda: bps Tamanho dos Pacotes: 1500 bytes Throughput IPTD IPDV IPLR Média Obtida: bps Minimo Esperado: bps Média Obtida: ms 400 ms Status: NOK Média Obtida: ms 50 ms Taxa Obtida: Fluxo 3 : Classe QoS: 5-Aplicações Padrão de Redes IP Tipo de Marca: DSCP Marca QoS: 0x28 Largura de Banda: bps Tamanho dos Pacotes: 1500 bytes

85 84 Throughput IPTD IPDV IPLR Média Obtida: bps Minimo Esperado: bps Média Obtida: ms ND ms Média Obtida: ms ND ms Taxa Obtida: Maximo Esperado: ND Graficos: Resultados do Teste: Cenario 3 - Teste 1 Número de Fluxos: 3 IP Lado Mestre: IP Lado Escravo: Tempo de Teste 300 segundos Fluxo 1 :

86 85 Classe QoS: 0-Tempo Real Altamente Interativa Tipo de Marca: DSCP Marca QoS: 0x78 Largura de Banda: bps Tamanho dos Pacotes: 1500 bytes Throughput IPTD IPDV IPLR Média Obtida: bps Minimo Esperado: bps Média Obtida: ms 100 ms Status: NOK Média Obtida: ms 50 ms Taxa Obtida: Fluxo 2 : Classe QoS: 1-Tempo Real Interativa Tipo de Marca: DSCP Marca QoS: 0x50 Largura de Banda: bps Tamanho dos Pacotes: 1500 bytes Throughput IPTD IPDV IPLR Média Obtida: bps Minimo Esperado: bps Média Obtida: ms 400 ms Status: NOK Média Obtida: ms 50 ms Taxa Obtida: Fluxo 3 : Classe QoS: 5-Aplicações Padrão de Redes IP Tipo de Marca: DSCP Marca QoS: 0x28 Largura de Banda: bps Tamanho dos Pacotes: 1500 bytes Throughput IPTD IPDV IPLR Média Obtida: bps Minimo Esperado: bps Status: NOK Média Obtida: ms ND ms Média Obtida: ms ND ms Taxa Obtida: Maximo Esperado: ND Graficos:

87 86 Resultados do Teste: Cenario 3 - Teste 2 Número de Fluxos: 3 IP Lado Mestre: IP Lado Escravo: Tempo de Teste 300 segundos Fluxo 1 : Classe QoS: 0-Tempo Real Altamente Interativa Tipo de Marca: DSCP Marca QoS: 0x78 Largura de Banda: bps Tamanho dos Pacotes: 1500 bytes Throughput IPTD IPDV IPLR Média Obtida: bps Média Obtida: ms Média Obtida: ms Taxa Obtida: 0.000

88 87 Throughput IPTD IPDV IPLR Minimo Esperado: bps 100 ms 50 ms Fluxo 2 : Classe QoS: 1-Tempo Real Interativa Tipo de Marca: DSCP Marca QoS: 0x50 Largura de Banda: bps Tamanho dos Pacotes: 1500 bytes Throughput IPTD IPDV IPLR Média Obtida: bps Minimo Esperado: bps Média Obtida: ms 400 ms Média Obtida: ms 50 ms Taxa Obtida: Fluxo 3 : Classe QoS: 5-Aplicações Padrão de Redes IP Tipo de Marca: DSCP Marca QoS: 0x28 Largura de Banda: bps Tamanho dos Pacotes: 1500 bytes Throughput IPTD IPDV IPLR Média Obtida: bps Minimo Esperado: bps Status: NOK Média Obtida: ms ND ms Média Obtida: ms ND ms Taxa Obtida: Maximo Esperado: ND Graficos:

89 88 Resultados do Teste: Cenario 3 - Teste 3 Número de Fluxos: 3 IP Lado Mestre: IP Lado Escravo: Tempo de Teste 300 segundos Fluxo 1 : Classe QoS: 0-Tempo Real Altamente Interativa Tipo de Marca: DSCP Marca QoS: 0x78 Largura de Banda: bps Tamanho dos Pacotes: 1500 bytes Throughput IPTD IPDV IPLR Média Obtida: bps Minimo Esperado: bps Média Obtida: ms 100 ms Média Obtida: ms 50 ms Taxa Obtida: Fluxo 2 : Classe QoS: 1-Tempo Real Interativa Tipo de Marca: DSCP Marca QoS: 0x50

90 89 Largura de Banda: bps Tamanho dos Pacotes: 1500 bytes Throughput IPTD IPDV IPLR Média Obtida: bps Minimo Esperado: bps Média Obtida: ms 400 ms Média Obtida: ms 50 ms Taxa Obtida: Fluxo 3 : Classe QoS: 5-Aplicações Padrão de Redes IP Tipo de Marca: DSCP Marca QoS: 0x28 Largura de Banda: bps Tamanho dos Pacotes: 1500 bytes Throughput IPTD IPDV IPLR Média Obtida: bps Minimo Esperado: bps Status: NOK Média Obtida: ms ND ms Média Obtida: ms ND ms Taxa Obtida: Maximo Esperado: ND Gráficos:

91 90

92 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.

93 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.

94 93 Tela de estado do andamento do teste. Tela de estado do andamento do teste.

95 94 Tela de estado do andamento do teste. Tela de Resultados do Teste.