uma ferramenta para anÁlise de desempenho de …wpage.unina.it/pescape/cit/pfg.222004.pdfse numa...
TRANSCRIPT
UNIVERSIDADE DE BRASÍLIA FACULDADE DE TECNOLOGIA
DEPARTAMENTO DE ENGENHARIA ELÉTRICA
UMA FERRAMENTA PARA ANÁLISE DE DESEMPENHO DE REDES CONVERGENTES
ITALO AMARAL BRITO VINÍCIUS MACÊDO DE SOUSA
ORIENTADORES: ANTÔNIO J. MARTINS SOARES HUMBERTO ABDALLA JÚNIOR
PROJETO FINAL DE GRADUAÇÃO EM ENGENHARIA DE REDES DE COMUNICAÇÃO
BRASÍLIA / DF: JAN/2005
UNIVERSIDADE DE BRASÍLIA FACULDADE DE TECNOLOGIA
DEPARTAMENTO DE ENGENHARIA ELÉTRICA
UMA FERRAMENTA PARA ANÁLISE DE PERFORMANCE DE REDES CONVERGENTES
ITALO AMARAL BRITO VINÍCIUS MACÊDO DE SOUSA
PROJETO FINAL DE GRADUAÇÃO SUBMETIDO AO DEPARTAMENTO DE ENGENHARIA ELÉTRICA DA FACULDADE DE TECNOLOGIA DA UNIVERSIDADE DE BRASÍLIA, COMO PARTE DOS REQUISITOS NECESSÁRIOS PARA A OBTENÇÃO DO GRAU DE ENGENHEIRO DE REDES COMUNICAÇÃO. APROVADA POR:
ANTÔNIO J. MARTINS SOARES, Doutor, UnB (ORIENTADOR)
LÚCIO MARTINS DA SILVA, Doutor, UnB (EXAMINADOR)
PRISCILLA SOLÍS BARRETO, Mestre, UnB (CO-ORIENTADORA) DATA: BRASÍLIA/DF, 13 DE JANEIRO DE 2005.
A Deus, nossos pais, irmãos e a todos que nos ajudaram direta e indiretamente nessa conquista.
AGRADECIMENTOS Aos nossos orientadores Prof. Dr Antônio J. Martins Soares, Prof. Dr Humberto Abdalla Júnior pelo apoio, incentivo, dedicação e amizade essenciais para o desenvolvimento deste trabalho e para o nosso desenvolvimento como pesquisadores. Aos Pesquisadores do Laboratório de Comunicações da Universidade de Brasília – LabCom – UnB, em especial Priscilla Barreto e Georges Amvame-Nze pela paciência, dedicação, atenção, motivação, direcionamento dos trabalhos bem como pela amizade construída ao longo do processo. Ao bolsista do Labcom Rafael Sampaio por ter nos ajudado bastante no desenvolvimento desse trabalho e, especial na programação. A todos, os nossos sinceros agradecimentos.
RESUMO
Este trabalho apresenta um software que tem como objetivo analisar o desempenho de redes utilizando parâmetros de QoS (Qualidade de Serviço). O software integra as funcionalidades de várias ferramentas de código aberto e foi desenvolvido na linguagem de programação JAVA. Espera-se que sua utilização permita, através da geração de tráfego, a simulação das diversas aplicações em uma rede real e a realização de experiências que envolvam análise de desempenho de redes, agilizando e facilitando as atividades do pesquisador de redes.
ABSTRACT This work presents a software that aims at analyzing network performance using QoS (Quality of Service) parameters. The software integrates the functionalities of a sort of open source tools and was developed using JAVA programming language. It is expected that its utilization permits, by generating traffic, the simulation of various applications in a real network and performing experiments that involve network performance analysis, making faster and easier the network researchers’ activities.
ÍNDICE
1. INTRODUÇÃO ...............................................................................................................1
2. QUALIDADE DE SERVIÇO.........................................................................................3
2.1. INTRODUÇÃO ..........................................................................................................3
2.2. HISTÓRIA DA QOS..................................................................................................4
2.3. ARQUITETURA DE SERVIÇOS DIFERENCIADOS ...........................................................7
2.3.1. Definição do Campo DS ......................................................................................8
2.3.2. PHB.......................................................................................................................9
2.3.3. Domínio DS ........................................................................................................10
2.4. CONCLUSÃO ..............................................................................................................13
3. MEDIDAS DE DESEMPENHO ..................................................................................14
3.1. ATRASO .....................................................................................................................14
3.2. VARIAÇÃO DO ATRASO (JITTER) ...............................................................................15
3.3. PERDA DE PACOTES ...................................................................................................16
3.4. LARGURA DE BANDA E VAZÃO ..................................................................................17
3.5. RESUMO DE FERRAMENTAS DE MEDIÇÃO ...............................................................17
3.6. CONCLUSÃO ..............................................................................................................19
4. MEDIÇÃO DE TRÁFEGO ..........................................................................................20
4.1. MEDIÇÃO PASSIVA (NÃO INTRUSIVA).......................................................................20
4.1.1. Técnicas de Coleta .............................................................................................21
4.1.1.1. Monitor de Pacotes .................................................................................................21
4.1.1.2. Monitor de Fluxo.....................................................................................................22
4.1.1.3. Monitor de Agentes.................................................................................................23
4.2. MEDIÇÃO ATIVA (INTRUSIVA)...................................................................................23
4.2.1. Métodos de Geração do Tráfego ......................................................................24
4.3. MEDIÇÃO EM REDES CONVERGENTES .............................................................25
4.4. ESTUDO DE CASO – UMA APLICAÇÃO DE MEDIDAS..................................................26
4.4.1. O AMBIENTE ...................................................................................................26
4.4.2. AS FERRAMENTAS ........................................................................................27
4.4.2.1. MGEN ......................................................................................................................27
4.4.2.2. TRPR........................................................................................................................28
4.4.2.3. Chrony .....................................................................................................................28
4.4.3. TESTES DE AVALIAÇÃO..............................................................................29
4.4.4. AVALIAÇÃO DO SERVIÇO DE VOIP.........................................................29
4.4.5. CONCLUSÃO DO ESTUDO DE CASO ........................................................35
4.5. CONCLUSÃO ..............................................................................................................35
5. APRESENTAÇÃO DO SOFTWARE .........................................................................36
5.1. NECESSIDADE DO SOFTWARE ...................................................................................36
5.2. CONVERGÊNCIA DE APLICATIVOS ............................................................................36
5.3. VANTAGENS ..........................................................................................................37
5.4. DESCRIÇÃO DO SOFTWARE ..................................................................................38
5.4.1. SINCRONISMO ................................................................................................38
5.4.2. UML....................................................................................................................39
5.4.3. PROGRAMA ANALISADOR .........................................................................43
5.5. CONSIDERAÇÕES SOBRE A APLICABILIDADE ..........................................49
5.6. CONCLUSÃO ..............................................................................................................49
6. CONCLUSÕES..............................................................................................................50
7. TRABALHOS FUTUROS............................................................................................52
8. REFERÊNCIAS ............................................................................................................53
ANEXO A – CONFIGURAÇÃO DO CHRONY.................................................................55
ÍNDICE DE TABELAS
TABELA 4.1 – FLUXOS DE TRÁFEGO PARA MPLS-BE .................................................. 30
TABELA 4.2 – FLUXOS DE TRÁFEGO PARA MPLS-DS .................................................. 30
TABELA 4.3 – PERDAS MÉDIAS PARA MPLS-BE.......................................................... 32
ÍNDICE DE FIGURAS
FIGURA 2.1 – DEFINIÇÃO DO CAMPO DS......................................................................... 8
FIGURA 2.2 – DOMÍNIO DS ............................................................................................ 11
FIGURA 2.3 - VISÃO LÓGICA DO CLASSIFICADOR E CONDICIONADOR DE PACOTES... 11
FIGURA 3.1 – ATRASO FIM-A-FIM .................................................................................. 15
FIGURA 3.2 – JITTER ...................................................................................................... 16
FIGURA 4.1 - FUNCIONAMENTO DA TÉCNICA DE MEDIÇÃO PASSIVA .......................... 21
FIGURA 4.2 - COLETOR EM REDES LOCAIS. ................................................................... 21
FIGURA 4.3 - COLETOR EM REDES DE ALTA VELOCIDADE............................................ 22
FIGURA 4.4 – TOPOLOGIA DE REDE DOS TESTES ........................................................... 27
FIGURA 4.5 – DISTRIBUIÇÃO DE BANDA NO AMBIENTE MPLS..................................... 31
FIGURA 4.6 – LATÊNCIA NO AMBIENTE MPLS ............................................................. 32
FIGURA 4.7 – PERDAS NO AMBIENTE MPLS (EM PERCENTUAL) .................................. 32
FIGURA 4.8 – DISTRIBUIÇÃO DE BANDA NO MPLS-DS. ............................................... 34
FIGURA 4.9 – LATÊNCIA NO MPLS-DS......................................................................... 34
FIGURA 5.1 – UML DIAGRAMA DE CASOS DE USO....................................................... 39
FIGURA 5.2 – UML DIAGRAMA DE CLASSES ................................................................ 41
FIGURA 5.3 – UML DIAGRAMA DE SEQÜÊNCIA............................................................ 43
FIGURA 5.4 – TELA PRINCIPAL DO PROGRAMA ............................................................. 44
FIGURA 5.5 – TELA DE SALVAR AMBIENTE ................................................................... 45
FIGURA 5.6 – JANELAS DE FLUXO: TRÁFEGO PERIÓDICO E DE RAJADA ..................... 47
1
1. INTRODUÇÃO
Em função da crescente convergência de aplicações e tipos de tráfego observada
nas redes de comunicação, que têm capacidade limitada, os conceitos de qualidade de
serviço e priorização de tráfego passam a ser objetos de freqüente estudo. Hoje em dia,
ainda não se dispõe de ferramentas completas para realizar os testes e análises para
implementação de qualidade de serviço (QoS). Ciente dessa dificuldade, desenvolveu-se
um software que integra várias ferramentas de código aberto já existentes, constituindo-
se numa plataforma de testes mais completa para análises de desempenho de redes
convergentes.
No capítulo 3 deste trabalho, procura-se estabelecer os conceitos envolvidos no
estudo de QoS em redes de pacotes, situando os leitores no escopo do projeto. Esse
capítulo dá uma visão geral da Qualidade de Serviço e explica como funciona um
modelo de QoS em especial, o modelo que é usado mais amplamente, o DiffServ.
Quanto ao modelo DiffServ, explica-se a subdivisão em classes às quais o programa
desenvolvido apresentado no capítulo 5 dá suporte.
O capítulo 4 provê uma visão geral de algumas técnicas e potenciais abordagens
para medir QoS na rede e define o conjunto de métricas utilizadas para esse fim, assim
como o modo de calculá-las; termina com uma análise das ferramentas que foram
utilizadas ao longo deste trabalho. Esses programas realizam funções diversas, como
sincronismo dos relógios das máquinas envolvidas, plotagem de gráficos, transformação
dos logs das transações e geração de tráfegos com perfis diferentes. Todas essas
funções, quando integradas dão origem ao software apresentado no capítulo 5.
O capítulo 5 apresenta e descreve o software desenvolvido durante este projeto,
fruto dos estudos e experiências com simulações e testes de desempenho. Mostram-se
diagramas de modelagem, que explicam de forma visual como está estruturado o
programa e quais os processos internos; descreve-se a interface do usuário e como ela
funciona e que atividades podem ser realizadas. Ainda nesse capítulo, discutem-se as
vantagens e utilidades do software.
2
A seguir, conclui-se o trabalho com impressões acerca dos estudos feitos durante
o projeto final de graduação e do programa desenvolvido e apresentado. Concluiu-se
com algumas sugestões de trabalhos a serem feitos futuramente, a partir deste que serve
de orientação para interessados pelo projeto.
3
2. QUALIDADE DE SERVIÇO
2.1. INTRODUÇÃO
À medida que as redes de comunicação ganham novas funcionalidades, tornam-
se ativos empresariais estratégicos e centros de operações das empresas. As redes,
entretanto, convergem para uma infra-estrutura única compartilhada, capaz de suportar,
além de dados, também áudio e vídeo. Neste cenário, tipos diferentes de tráfego devem
ser tratados de modo diferenciado. Isso ocorre devido ao fato de algumas aplicações,
como as de áudio, terem exigências rígidas quanto ao atraso fim-a-fim, mas poderem
tolerar perdas mínimas de pacotes, enquanto outras como transferências de arquivos são
sensíveis a este último aspecto, mas as exigências quanto ao atraso são pouco severas.
Essa necessidade, nos últimos anos, levou a diversos estudos no sentido de desenvolver
mecanismos para atender a diversas peculiaridades de cada aplicação de forma a
convergir todas essas redes para uma única capaz de transportar todos esses tipos de
aplicações numa única rede de pacotes IP.
A maior rede IP é, com certeza, a Internet. A Internet cresceu exponencialmente
durante os últimos anos, tanto em número de usuários como em aplicações. Conforme a
Internet continua a atender cada vez mais usuários, surgem aplicações diferentes do
tráfego de dados original, tais como VoIP (Voz sobre IP) e vídeo-conferência. Como o
número de usuários e aplicações vinha crescendo cada vez mais, era necessária uma
estrutura que suportasse todas essas mudanças. Entretanto, a Internet oferece somente o
serviço do melhor esforço (Best Effort), que não oferece nenhuma garantia que os
pacotes irão chegar ao seu destino, embora os pacotes só sejam descartados durante
congestionamentos[1]. Por causa desse crescimento desordenado e da falta de infra-
estrutura para absorver toda a demanda, surgiu um fenômeno conhecido com “World
Wide Wait”.
Para uma rede IP suportar fluxos de voz, vídeo e dados que pertencem a
diferentes serviços com diferentes solicitações, a rede deve saber diferenciar e servir
esses fluxos de acordo suas solicitações. Com o serviço de melhor-esforço, isso não é
4
possível, pois ele não faz essa diferenciação entre os fluxos. Assim, nenhuma prioridade
ou garantia é oferecida para nenhum fluxo, diminuindo a capacidade da rede IP em
transportar fluxos que solicitam uma quantidade mínima de recursos da rede, fazendo
com que uma implementação de QoS seja necessária para que os recursos disponíveis
na rede sejam melhores utilizados.
A qualidade de serviço tem a intenção de garantir, bem como diferenciar, os
serviços de Internet permitindo uma garantia do serviço e um controle baseado em
políticas para controlar o desempenho da rede IP, tais como alocação de recursos,
descarte de pacotes, enfileiramento etc.
2.2. HISTÓRIA DA QOS
A qualidade de serviço não foi uma sugestão recente para diminuir ou eliminar o
congestionamento das redes. Os fundadores da Internet já previram essa necessidade e
colocaram o campo ToS (Type of Service) no cabeçalho IP para facilitar a QoS como
parte da especificação inicial do IP. O campo ToS é descrito na RFC 791 da seguinte
forma:
“O ToS (Type of Service) prove uma indicação abstrata de parâmetros de
qualidade de serviço desejados. Esses parâmetros devem ser usados como guia para a
seleção dos níveis de serviços atuais quando o pacote estiver transitando por uma rede
particular”.
Até o final dos anos 80, as redes estavam limitadas aos ambientes acadêmicos e
possuíam uma quantidade de aplicações limitadas. Portanto, o suporte ao campo ToS
não era necessariamente importante e a maioria das implementações ignoravam o
campo ToS do IP. Isso acontecia devido ao fato de as redes ainda serem pequenas e com
pouca quantidade de tráfego. As aplicações IP não marcavam o campo IP e os
5
roteadores não usavam essa informação na hora de encaminhar um pacote IP. A
qualidade de serviço não tinha uma grande importância nas redes IP[1].
A importância da qualidade de serviços na Internet tem crescido na mesma
proporcionalidade que sua evolução, que saiu do meio acadêmico e dominou o mercado
mundial como um todo. A Internet é um serviço baseado em pacotes, com o tradicional
serviço de melhor esforço. Apesar dessa arquitetura baseada em pacotes proporcionar
flexibilidade e robustez, esse dinamismo também acaba permitindo que ocorram
problemas de congestionamento, especialmente nos roteadores que interligam diversas
redes com diferentes quantidades de tráfego. O primeiro colapso de congestionamento
na Internet ocorreu em 1984 devido a alguns problemas no protocolo TCP, conforme
descrito por John Nagle, durante a fase de crescimento da Internet, em meados de
1980[2].
As primeiras configurações de QoS realizadas foram para os hosts da Internet.
Um dos maiores problemas com os enlaces WAN (Wide-area Networks) foi o excesso
de overhead em serviços como telnet e rlogin, devido sua baixa taxa de transmissão. O
algoritmo desenvolvido por Nagle resolveu esse problema e é atualmente suportado por
todos os hosts que implementam o IP [3]. Esse algoritmo pode ser considerado o marco
do início da qualidade de serviço em redes IP.
Em 1986, Van Jacobson desenvolveu os mecanismos de QoS “slow start” e
“congestion avoidance”, que são requisitos nas implementações TCP. Esses
mecanismos trabalham de maneira a diminuir o congestionamento na rede bem como
evitar o colapso dessas redes. Logo após isso, dois mecanismos adicionais foram
adicionados, o “fast retransmit” e o “fast recovery”, que permitiram a otimização de
desempenho durante a perda de pacotes [4].
Embora mecanismos que implementassem qualidade de serviço fim-a-fim
fossem essenciais, eles não foram implementados até que mecanismos instalados nos
roteadores pudessem transportar o tráfego desde sua entrada no domínio até sua saída.
Isso só foi feito por volta dos anos 90 quando os roteadores receberam uma atenção
especial. Os roteadores tinham suas filas limitadas somente com a disciplina de
6
enfileiramento FIFO (first-in, first-out – Primeiro a entrar é o primeiro a sair) [5], que
não oferece nenhum tratamento especial aos pacotes, isto é, não diferencia os pacotes
mais prioritários dos menos, nem oferece preferência para os prioritários, fazendo seu
buffer sobrecarregar descartando todos os pacotes que forem encaminhados para esse
host até que a situação se normalize. O descarte dos pacotes por causa da sobrecarga do
buffer recebe o nome de Tail Drop. Além da FIFO, outros tipos de disciplinas foram
desenvolvidos, que conseguiam diferenciar os pacotes, podendo assim implementar
qualidade de serviço. Como exemplo, tem-se o CBQ (Classe Based Queueing), ou CQ
(Custom Queueing), que reserva uma fatia da largura de banda para cada classe, o WFQ
(Weighted Fair Queueing), que diferencia os pacotes com base em sua prioridade, além
dos mecanismos de gerencia de filas como o RED, para evitar que o congestionamento
praticamente parasse o fluxo de dados.
O desenvolvimento para implementar a qualidade de serviço na Internet
continuou com alguns padrões. O grupo de trabalho dos “serviços integrados” (IntServ)
do IETF (Internet Engineering Task Force) teve como objetivo desenvolver um modelo
para garantir a determinada aplicação que a própria rede reservasse uma quantidade
mínima de recursos de acordo com a necessidade da aplicação. O protocolo adotado
para fazer essa reserva seria o RSVP (Resource ReSerVation Protocol – Protocolo de
Reserva Recursos) [6]. O problema desse modelo é a necessidade de um “estado do
fluxo” para cada fluxo criado gerando assim um problema de escalabilidade nos grandes
backbones, pois centenas de fluxos estariam disputando pelos recursos disponíveis na
rede e não haveria processamento suficiente nos roteadores que conseguiriam atualizar
esses “estados” de uma maneira eficaz. Por esse motivo, outro grupo foi desenvolvido
com o objetivo de oferecer qualidade de serviço na Internet e com o intuito de resolver o
problema de escalabilidade do RSVP. Esse novo grupo de trabalho foi chamado
“serviços diferenciados” (DiffServ – Differentiated Services), que utiliza o campo ToS,
para oferecer um serviço diferenciado [7] [8] para os fluxos que estão disputando os
recursos de uma determinada rede, ao contrário do RSVP, que precisa criar um estado e
criava uma reserva de recursos para cada fluxo, essa arquitetura só utiliza os bits
presente no campo ToS, que foi renomeado por essa arquitetura para DSCP (DiffServ
Code Point). Ao contrário do ToS que utiliza 7 dos 8 bits, esse novo código utiliza 6 dos
8 bits, para oferecer uma qualidade de serviço para os pacotes. Nessa nova arquitetura
7
os pacotes são classificados em classes, garantindo que cada uma receberá um
tratamento diferenciado ganhando uma “fatia” da largura de banda do enlace.
Essa arquitetura é a arquitetura de QoS mais utilizada atualmente nas redes e
será objeto de estudo do próximo tópico.
2.3. ARQUITETURA DE SERVIÇOS DIFERENCIADOS
O DiffServ objetiva disponibilizar qualidade de serviço em redes IP sem a
necessidade de criar um estado por fluxo, ou de ter uma sinalização em cada nó, como
feito pelo RSVP, evitando assim o problema de escalabilidade do IntServ. Essa nova
arquitetura classifica os pacotes em uma quantidade limitada de classes e, com isso, não
necessita de um estado por fluxo ou um processamento por fluxo. O tráfego identificado
recebe um valor, que é chamado DSCP – DiffServ CodePoint.
A arquitetura DiffServ estabelece várias classes de serviços, especificadas pelos
bits do campo ToS do cabeçalho IP, formando o campo DSCP. A classificação dos
pacotes pode ser feita antes deles entrarem no domínio ou pelo roteadores de ingresso,
pois essa classificação só precisa ser realizada uma vez, na entrada do domínio. Isso não
impede que novas classificações possam ser realizadas no interior do domínio re-
adequando os pacotes de determinado fluxo para uma realidade momentânea da rede.
Ao chegar nos hosts, o valor do campo DSCP determina como o host irá tratar
os pacotes, isto é, se vai dar preferência ou se vai armazenar, em virtude de um pacote
com maior prioridade chegando, ou mesmo se vai descartar o pacote. Esse tipo de
comportamento recebe o nome de PHB (Per-Hop-Behavior), ou comportamento por nó
de rede. No modelo Diffserv existem 3 tipos de PHBs: EF (Expedited Forwarding), AF
(Assured Forwarding) e BE (Best Effort). Os pacotes são classificados em uma dessas
classes de acordo com sua origem, seu destino e aplicação. Essa classificação, feita na
borda do domínio, se baseia nos múltiplos campos do cabeçalho IP, enquanto que a
classificação que ocorre no interior do domínio se baseia no campo DSCP do pacote.
Para que determinado fluxo receba o serviço diferenciado solicitado, é
necessário estabelecer uma SLA (Service Level Agreement – Nível de Serviço
Contratado) entre quem está solicitando o serviço diferenciado e quem está oferecendo
o serviço (provedor de serviço). Esse SLA irá especificar as regras de encaminhamento
8
que esse fluxo irá receber. Caso um fluxo que não tenha estabelecido nenhum SLA com
esse domínio ingresse na rede, ele receberá o serviço de melhor esforço. Com os SLAs
definidos e configurados, o roteador DiffServ dá início ao processo de classificação.
2.3.1. Definição do Campo DS
Com a introdução dessa arquitetura há necessidade de renomear o campo ToS,
no caso do IPv4, ou Traffic Class, no caso do IPv6, pelo campo DS. Esse campo é
composto de oito bits, mas somente seis deles são atualmente usados e são referidos
como codepoint, ou melhor, DSCP (DiffServ codepoint). Eles são usados para
selecionar qual PHB que será aplicada ao pacote por cada nó por onde ele passar. Os
outros dois bits, que atualmente não são usados, formam a parte CU (currently unused)
desse campo e estão reservados. O valor desse campo é ignorado pelos nós que
pertencem ao domínio DS e que implementam o serviço diferenciado ao determinar
qual PHB será aplicada ao pacote recebido. O campo ToS pode ser identificado na
figura 2.1, que ilustra o cabeçalho IP.
Figura 2.1 – Definição do campo DS
9
Com algumas exceções, o mapeamento entre os codepoints e os PHBs deve ser
configurável. Um nó DS deve suportar uma equivalência lógica da tabela de
mapeamento configurável entre os codepoints e os PHBs.
Os nós podem re-escrever o campo DS de acordo com sua necessidade para
oferecer um serviço fim-a-fim ou não. As especificações entre as traduções dos campos
DS entre domínio DS que será feita nos limites do domínio são determinados através de
SLAs que existem entre provedores e clientes. PHBs padronizadas permitem que os
provedores criem seus serviços a partir dos bem conhecidos conjuntos de tratamentos de
pacotes que podem estar presentes em qualquer equipamento de qualquer fabricante.
2.3.2. PHB
O PHB é a descrição exata do comportamento de encaminhamento que um nó
DS deve aplicar a uma agregação de fluxos DS que possui o mesmo comportamento, ou
DSCP. Distinções úteis de comportamento são principalmente observadas quando
múltiplos BA (Behavior Aggregate – agregação devido ao comportamento), conjunto de
pacotes que possui o mesmo destino além de possuírem o mesmo DSCP, que estão
competindo pelos recursos de buffer e largura de banda em um nó. É através do PHB
que um nó reserva recursos para determinado fluxo e é com base no mecanismo de
reserva de recursos hop-by-hop que o DiffServ poderá ser construído [8].
Os PHBs podem ser especificados de acordo com as prioridades de recursos
solicitadas se comparados a outros PHBs ou em termos de suas características relativas.
Esses PHBs podem ser utilizados como fluxogramas para reserva de recursos e
deveriam ser especificadas como um grupo para dar uma consistência maior aos
recursos reservados. Os grupos de PHBs irão usualmente compartilhar as mesmas
restrições que serão aplicadas a cada PHB que fizer parte do grupo, como um
agendamento ou uma política de gerenciamento de buffer. O relacionamento entre os
diversos PHBs de um grupo pode ser em termos de prioridade absoluta ou relativa, mas
isso não é necessário.
Os PHBs são definidos de acordo com as características que estão relacionadas
com as políticas dos serviços e não de acordo com determinado mecanismo [8].
Nas especificações do PHB, é recomendado que a inclusão de um codepoint
default, que tem como recomendação o valor ‘000000’ e deve mapear todos os PHBs
10
que têm as mesmas recomendações especificadas para esse valor, e deve ser único entre
os possíveis codepoints. As implementações devem suportar o mapeamento
recomendado entre o codepoint e o PHB em sua configuração default. Os
administradores de rede podem usar codepoints diferentes para os PHBs, tanto
adicionando novas possibilidades quanto trocando os codepoints já definidos por outros.
No entanto, quando a troca de codepoints for desejada, a re-marcação do campo DS será
necessária nos limites da rede, mesmo que mais de um domínio utilize os mesmos
codepoints.
Os pacotes recebidos que não tiverem o campo DS configurado ou que tiverem
um codepoint desconhecido devem ser encaminhados como se tivessem recebido a
marcação default e seus codepoints não devem ser alterados [7].
Os PHBs são implementados através do emprego de uma variedade de serviços
de enfileiramento e/ou disciplinas de enfileiramento presentes nas interfaces de saída
dos nós, como, por exemplo, o PQ (Priority Queuing) que é utilizado pelo serviço de
enfileiramento e/ou RED (Random Early Detection) que pode ser utilizado pelo serviço
de gerência de filas, ou através da gerencia de filas.
Um exemplo de PHB é o EF, que oferece aos pacotes baixa perda, baixo atraso e
baixo jitter (variação do atraso) e uma fatia da largura de banda assegurada. Isso
significa que os pacotes marcados com o código do EF que estão atravessando o
domínio em determinada direção irão ter perda baixa de pacotes, baixo atraso e baixo
jitter e irão ter uma fatia da largura de banda assegurada. O AF é outro grupo de PHBs,
com “regalias” inferiores ao do grupo EF. Esse grupo recebe a classificação AFxy, onde
“x” representa a classe que pode variar de 1 até 4, enquanto “y” representa a
probabilidade de descarte do pacote, que pode variar de 1 até 3. Os pacotes que
pertencem a diferentes AF são encaminhados separadamente, e, geralmente, as classes
que possuírem o menor valor recebem maiores quantidades de recursos. Quanto maior a
probabilidade de descarte dos pacotes pertencentes à mesma classe, maior suas chances
de serem descartados diante de uma falta de recursos.
2.3.3. Domínio DS
O domínio DS é composto por nós DS que possuem em comum a mesma
implementação de políticas e um grupo de PHBs instaladas em cada nó, fazendo com
11
que os nós de ingresso fiquem encarregados de classificar e condicionar o tráfego
entrante no domínio. A figura 2.2 dá uma idéia do que é o domínio DiffServ.
Figura 2.2 – Domínio DS
Um nó/roteador que implementa DiffServ tem uma série de mecanismos, que
interagem de acordo com a arquitetura ilustrada na figura 2.3.
Classificador(Classifier)
Marcador(Marker)
Modelador ouEliminador
Medidor(Meter)
Fluxo dosPacotes
Figura 2.3 - Visão Lógica do Classificador e Condicionador de Pacotes
Classificadores
Os classificadores selecionam os pacotes baseando-se nos dados contidos em
uma porção de seu cabeçalho. São definidos dois tipos de classificadores: BA e MF. O
classificador BA (Behavior Aggregate) classifica os pacotes tomando por base somente
os codepoints contidos nos cabeçalhos. O MF (Multi-Field) classifica os pacotes com
base nos valores de mais de um campo do cabeçalho, tais como endereço destino e/ou
origem, campo DS portas de entrada e/ou destino entre outras.
Condicionador
Um condicionador de tráfego pode conter os seguintes elementos: medidor
(meter), modelador (shaper), marcador (marker) e eliminador (dropper). O medidor é
12
usado para determinar se o fluxo de pacotes recebidos está dentro dos perfis
especificados pela SLA. Isso é feito comparando o fluxo com os perfis presentes no
condicionador. O resultado da medição do fluxo pode ser usado para afetar as ações de
marcação, eliminação ou modelação.
Quando os pacotes deixam o condicionador de tráfego que se encontra em nó
DS de borda, levam junto o DSCP configurado de acordo com o que foi solicitado, o
que pode afetar esse fluxo durante seu percurso pela rede. A figura 2.3 mostra o
diagrama em blocos do condicionador de tráfego. No condicionador, não precisam estar
presentes todos os quatro elementos.
Medidor
O medidor de tráfego compara as propriedades temporárias do tráfego
selecionado pelo classificador. O medidor então encaminha as informações coletadas
para outras etapas do encaminhamento para disparar algumas ações para cada pacote
mesmo que o pacote esteja fora do perfil.
Marcador
O marcador de pacotes configura o campo DS do pacote de acordo com os
codepoints presente no roteador. Com isso, um pacote será adicionado a um BA. O
marcador pode estar configurado para marcar todos os pacotes que foram guiados para
ele com o mesmo codepoint, ou pode ser configurado para marcar o pacote com
determinado codepoint entre vários que ele possui, que é usado para selecionar o PHB
dentro de um conjunto de PHBs, de acordo com qual SLA que estiver em vigor.
Modelador
O modelador atrasa todos ou alguns pacote que pertencem a um fluxo para
colocar os pacotes dentro do perfil. Geralmente tem um tamanho de buffer limitado, o
que pode acarretar na perda de pacotes, caso seu buffer fique sobrecarregado.
Eliminador
O eliminador, como seu nome diz, elimina os pacotes do fluxo, para deixá-lo
dentro do perfil. Por causa disso, ele pode eliminar todos os pacotes pertencentes a um
13
fluxo, esse processo é conhecido como policiamento de fluxos. O eliminador pode ser
considerado um tipo de modelador se seu buffer for igual a zero.
2.4. CONCLUSÃO
Esse capítulo procurou criar as bases para o entendimento dos conceitos e
tecnologias abordados em seguida, através da explanação do paradigma da Qualidade de
Serviço e o histórico associado a ela. Além disso, explicou-se mais a fundo o modelo
DiffServ, quais são seus componentes e como um nó diffserv trata o tráfego que chega e
que sai dele.
O próximo capítulo aborda os parâmetros de QoS que podem ser medidos em
uma rede real e qual o significado de cada um desses parâmetros.
14
3. MEDIDAS DE DESEMPENHO
Neste capítulo serão estudas as principais medidas de desempenho que podem
ser estimadas em uma rede através de medições. O objetivo é descrever a definição das
métricas estudadas durante o trabalho, e também fazer um resumo das ferramentas
disponíveis para a obtenção de algumas dessas medidas, antes de serem acrescentadas
as implementações desenvolvidas nesse trabalho.
As medidas de desempenho descrevem as características do estado da rede
durante os experimentos. Essas medidas podem ser obtidas através de técnicas de
medição intrusivas, que consistem na injeção de pacotes de controle na rede, ou não-
intrusivas, em que são apenas observados os pacotes que trafegam pela rede. A seguir
serão descritas as medidas de desempenho estimadas a partir das técnicas intrusivas. No
entanto, algumas dessas métricas podem também ser estimadas na forma passiva de
medição, mas, por não fazer parte do escopo deste trabalho, essas técnicas não serão
descritas.
3.1. ATRASO
As métricas relacionadas ao atraso em redes estimam o tempo que leva para um
pacote sair de sua origem e chegar ao seu destino. No entanto, diversos problemas
devem ser considerados para se estimar esse parâmetro, como falta de sincronia e
diferentes taxas de crescimento dos relógios do transmissor e receptor. A seguir, serão
definidas algumas métricas que avaliam o retardo sofrido por pacotes na rede.
Atraso fim-a-fim: é o tempo que um pacote leva do emissor ao receptor. Esta
métrica possui vários problemas para ser estimada devido às diferenças dos relógios do
transmissor e receptor. O problema pode ser solucionado se forem usados equipamentos
de sincronização dos relógios. Porém, esses equipamentos nem sempre estão
disponíveis. A figura 3.1 ilustra o atraso fim-a-fim.
15
Figura 3.1 – Atraso fim-a-fim
Atraso de ida e volta: é o tempo que um pacote leva para ser enviado a um
receptor e devolvido ao emissor (Round Trip Time). Neste caso, sem o problema de
sincronia dos relógios, o parâmetro fica muito mais simples de ser obtido. Algumas
considerações devem ser feitas, por exemplo, a precisão mínima de leitura do relógio no
sistema operacional. O atraso sofrido pelos pacotes na ida pode ser completamente
distinto do retardo durante o retorno, e a existência desta diferença não pode ser
estimada através dessa medida. Ferramentas, como PING, estão disponíveis para
estimar esta métrica.
3.2. VARIAÇÃO DO ATRASO (JITTER)
O Jitter é o intervalo entre a chegada de dois pacotes consecutivos em relação ao
intervalo de sua transmissão. Diferente do Atraso fim-a-fim, se os instantes de envio
forem conhecidos ou o intervalo entre eles for constante, essa métrica não possui
problemas para ser estimada entre máquinas com relógios não sincronizados.
A variação do atraso ou Jitter (Instantaneous Packet Delay Variation) é
formalmente definida pelo grupo de trabalho do IPPM através do Draft “Instantaneous
Packet Delay Variation Metric for IPPM” [9]. Ele é baseado na medição do atraso fim-
a-fim e é definido para pares consecutivos de pacotes. A medição de um único Jitter
requer dois pacotes. Supondo que Di seja o atraso do i-ésimo pacote, então o Jitter do
par de pacotes é definido com Di - D(i-1). A figura 3.2 dá uma noção visual desse
conceito. O jitter é percebido, por exemplo, quando fluxos de voz ou vídeo são
transmitidos em uma rede e os pacotes não chegam ao seu destino dentro da ordem
sucessiva ou em uma determinada cadência, ou seja, eles variam em termos de tempo de
16
atraso. Esta distorção é particularmente prejudicial ao tráfego multimídia, fazendo com
que o sinal de áudio ou vídeo tenha uma qualidade distorcida ou fragmentada na
recepção.
Figura 3.2 – Jitter
3.3. PERDA DE PACOTES
A sensibilidade das aplicações em relação ao número de pacotes perdidos motiva
o estudo dessa métrica. Obviamente, todas as aplicações são sensíveis à perda de
pacotes. Estes são recuperados via retransmissão. Entretanto, aplicações como as de
transmissão de vídeo e voz em tempo real não permitem que haja retransmissão,
tornando essas aplicações particularmente sensíveis a perdas. Portanto, é importante
conhecer as características de perda e estudar o desempenho dos algoritmos de
recuperação de pacotes. Dependendo do processo de perda presente na rede,
mecanismos como a redução na qualidade do vídeo ou algoritmos de recuperação de
perdas podem ser aplicados para melhorar a qualidade do serviço. A escolha dos
mecanismos de recuperação depende do processo de perda na rede. Este processo pode
ser estimado com base no número total de pacotes perdidos dividido pelo total de
pacotes enviados. Esta métrica pode ser estimada a partir de várias ferramentas de
medição intrusiva. Porém, não só a média, mas também outros detalhes sobre o
processo de perda devem ser levados em consideração, como o impacto nas aplicações
quando perdas ocorrem em rajadas, quando ocorrem distribuídas ao longo da coleta e a
distribuição do número de pacotes entregues corretamente em seqüência ao destino,
entre duas rajadas de perda são também importantes.
A taxa percentual de perdas de pacotes é calculada da seguinte forma:
17
Taxa de perdas = 100cotº
cotº ×recebidosespadetotalN
perdidosespadeN
3.4. LARGURA DE BANDA E VAZÃO
Largura de banda é uma medida de capacidade de transmissão de dados,
normalmente expressa em kilobits por segundo (kbps) ou megabits por segundo (Mbps).
A largura de banda indica a capacidade máxima de transmissão teórica de uma
conexão.
Entretanto, na medida em que a taxa de transmissão utilizada se aproxima da
largura de banda teórica máxima, fatores negativos como atraso na transmissão das
informações podem causar deterioração na qualidade. A largura de banda de uma rede
pode ser vista como um tubo que transfere dados. Quanto maior o diâmetro do tubo,
mais dados podem ser enviados através dele simultaneamente.
A vazão é o montante de tráfego de dados movidos de um nó da rede para outro
em um determinado período de tempo. A vazão também é expressa em kbps ou Mbps.
3.5. RESUMO DE FERRAMENTAS DE MEDIÇÃO
Nesta seção, é feito um resumo de algumas ferramentas de medição. As
principais medidas de desempenho estimadas por elas também estão listadas neste
resumo. A partir do resumo das ferramentas de medição ativa disponíveis será possível
comparar este trabalho com o estado da arte de ferramentas, e, com isso, avaliar a
contribuição do software analisador.
São várias as ferramentas de medição disponíveis em domínio público. A
ferramenta Traceroute usa pacotes ICMP para medir o atraso de ida e volta e o caminho
percorrido pelos pacotes. Pacotes ICMP são usados também pelas ferramentas Ping e
Bing para estimar o atraso de ida e volta e a fração de perda de pacotes.
As ferramentas Pchar e Pathchar usam, além de pacotes ICMP, pacotes UDP
para estimar a capacidade de transmissão dos enlaces ao longo do caminho, vazão,
18
atraso de ida e volta e fração de perda. Para isso, pacotes de tamanhos variados são
gerados pelas ferramentas. A ferramenta Clink usa a mesma técnica para estimar a
capacidade de transmissão dos enlaces ao longo do caminho e o atraso de ida e volta.
O conjunto de ferramentas Bprobe, Cprobe e Sprobe usa o conceito de pares de
pacotes para calcular suas métricas. As ferramentas Bprobe e Cprobe usam pacotes
ICMP para calcular a capacidade de transmissão do enlace no gargalo e a utilização,
respectivamente, enquanto que a ferramenta Sprobe usa pacotes UDP para estimar a
capacidade de transmissão do gargalo. O método de pares de pacotes é também usado
pelas ferramentas Netest e Nettimer para estimar a capacidade de transmissão do
gargalo. O Netest estima ainda a capacidade disponível, atraso de ida e volta, e fração
de perda.
A variação do método de pares de pacotes, o trem de pacotes, é usado pelas
ferramentas Pathrate e Pipechar para estimar a capacidade de transmissão de gargalo. O
Pipechar também estima a capacidade disponível, atraso de ida e volta, e fração de
perda.
A ferramenta Treno usa pacotes UDP e ICMP para simular o funcionamento do
TCP e estimar métricas como: capacidade de transmissão de gargalo e capacidade
disponível.
A ferramenta Iperf faz uso de pacotes UDP e TCP para estimar as métricas jitter,
fração de perda e capacidade disponível.
A feramenta MGEN [10] pelos módulos mgen para a geração de tráfego, drec
para a recepção do tráfego na estação remota e o mcalc para geração das informações a
partir do arquivo de saída gerado pelo drec. Esta ferramenta permite a geração
controlada de tráfego UDP, sendo possível a geração de um ou mais fluxos unicast ou
multicast com a taxa de bits desejada. A ferramenta permite também controlar o tempo
do experimento e a variação do tamanho do pacote UDP utilizado. Em conjunto com o
TRPR ela pode ser empregada para a medição do atraso, da variação do atraso e da taxa
de perda de pacotes.
19
Algumas ferramentas exigem equipamentos específicos para fazer as estimativas
corretamente. Uma delas é a MGEN, que para estimar o atraso dos pacotes em um
sentido requer o uso de equipamentos para sincronização dos relógios (NTP). Esta
ferramenta ainda estima a fração de perda dos pacotes experimentada na medição, a
vazão e o jitter quando utilizada em conjunto com outras ferramentas como o TRPR.
Após se ter estudado as diversas ferramentas de medição existentes foi decidida
a utilização da ferramenta MGEN em conjunto com o TRPR como base para o software
desenvolvido ao longo deste trabalho. São várias as medidas de desempenho que
necessitam ser obtidas e diversas as ferramentas utilizadas para esse propósito. Com
isso, verifica-se a inexistência de uma única ferramenta para a realização dos diversos
procedimentos realizados no LabCom e então se faz necessário o desenvolvimento de
um software que permita a convergência de várias ferramentas numa única plataforma.
3.6. CONCLUSÃO
Este capítulo procurou criar as bases para o entendimento dos conceitos para
análise de desempenho de redes com a definição dos critérios de avaliação de
desempenho que serão utilizados ao longo deste trabalho. Por fim, mostrou se um
resumo das ferramentas existentes atualmente, além de uma análise demonstrando quais
ferramentas foram escolhidas para o desenvolvimento do software. O próximo capítulo
aborda as formas de se fazer medição de tráfegos e as conseqüências associadas ao uso
de cada forma em uma rede real.
20
4. MEDIÇÃO DE TRÁFEGO
Duas são as técnicas de medição de redes atualmente usadas: ativa (intrusiva) e
passiva (não-intrusiva). A primeira consiste na injeção de pacotes de controle na rede.
Esses pacotes atravessam todo o caminho da rede a ser medido e são coletados em
algum ponto. Através das informações coletadas, algumas medidas de desempenho
podem ser extraídas. Dependendo da medida a ser extraída, os pacotes devem carregar
consigo informações que serão analisadas no receptor. Para algumas outras medidas,
técnicas mais sofisticadas podem ser necessárias.
A segunda técnica, chamada de medição passiva (não-intrusiva), apenas observa
os pacotes que trafegam pela rede. Ao contrário da medição ativa (intrusiva), as
passivas não injetam pacotes. Monitores, que funcionam em modo promíscuo, são
colocados no caminho dos pacotes para coletar as informações que, posteriormente,
serão analisadas. Apesar de não sobrecarregar a rede com pacotes adicionais,
equipamentos e softwares sofisticados podem ser necessários para fazer a coleta e a
análise dos dados.
Ao longo desse capítulo é feito um estudo das duas técnicas de medição de
tráfego citadas. Na próxima seção, que trata de medição passiva (não-intrusiva), o
estudo descreve a diferença entre as técnicas de coleta do tráfego e a forma como os
dados coletados podem ser interpretados. A outra seção, que trata de medição ativa,
descreve os métodos existentes de aplicação desta técnica e os diferentes modelos de
geração de pacotes.
4.1. MEDIÇÃO PASSIVA (NÃO INTRUSIVA)
Na aplicação desta técnica, a coleta de informações do tráfego que passa por
determinado ponto da rede é feita a partir de equipamentos e softwares instalados para
esta finalidade. Na metodologia de medição passiva não existe geração de pacotes e as
informações são coletadas a partir dos pacotes que trafegam pela rede gerados por
diversas aplicações. No entanto, a forma como estas informações são coletadas e
21
interpretadas podem ser distintas. O funcionamento desta técnica é ilustrado na Figura
4.1.
Figura 4.1 - Funcionamento da Técnica de Medição Passiva
4.1.1. Técnicas de Coleta
As técnicas de coleta definem como os coletores ou monitores retiram as
informações dos pacotes que passam pela rede. O local onde esses coletores se instalam
na rede e o tipo de informação que deve ser estimada dos pacotes podem variar. A
seguir serão descritas e exemplificadas três técnicas definidas em [11].
4.1.1.1. Monitor de Pacotes
Esta técnica consiste na cópia de parte do conteúdo dos pacotes que passam pelo
monitor. Com isso, informações de todas as camadas (Aplicação, Transporte, Rede e
Enlace) podem ser extraídas. Devido ao modelo de propagação dos pacotes usado pelas
redes Ethernet, difusão (broadcast) no meio físico, este tipo de coleta pode facilmente
ser aplicado em redes locais. Neste caso, a captura é feita pelo monitor que possui seu
adaptador de rede configurado de forma promíscua, ficando apto a coletar todo o tráfego
que passe pelo mesmo meio físico em que o coletor é instalado, como ilustra a Figura
4.2.
Figura 4.2 - Coletor em redes locais.
22
Para redes locais, o funcionamento é simples. No entanto, para as redes ponto-a-
ponto de alta velocidade algumas dificuldades existem: primeiro, o volume de tráfego
nas redes de alta velocidade é muito maior do que nas redes locais; segundo, existe o
problema de instalação do coletor dos pacotes no meio físico. Nem sempre é possível
dividir a rede e instalar o monitor entre os dois pontos, como mostra a Figura 4.3,
porém, uma alternativa para este problema é a configuração de geração de traces nos
roteadores, que então os envia aos coletores.
Figura 4.3 - Coletor em redes de alta velocidade
Para este tipo de monitoração, é sempre importante lembrar que o volume de
informações tratado pode ser muito grande. Uma boa opção é aumentar a granularidade
feita na filtragem dos pacotes. Ferramentas de domínio público, como tcpdump [12],
que trabalham como monitores de redes locais são atualmente amplamente usadas.
4.1.1.2. Monitor de Fluxo
Este tipo de coleta é feito com base na medição por fluxo, onde a idéia é gerar
estatísticas do tráfego agregado que passa pela rede. Para isso, um fluxo é definido
como sendo uma agregação do tráfego que se enquadra em determinada regra, e elas
devem descrever as características existentes naquele conjunto de pacotes que se deseja
medir.
Um fluxo pode ser, por exemplo, todo o tráfego que passe pelo coletor, cujo
campo endereço IP de origem e de destino sejam semelhantes aos indicados na tabela;
ou, além de serem de origem e destino iguais, utilizem uma porta específica. O intervalo
de tempo entre pacotes pode também ser um outro parâmetro de diferenciação entre os
fluxos, onde um pacote só pertence a um mesmo fluxo caso esteja separado por um
intervalo máximo de tempo.
23
A coleta por fluxo possui em geral uma granularidade maior em relação à
existente nos monitores de pacotes, mas essas granularidades podem ser diminuídas de
acordo com a necessidade da medição. Outro problema desta técnica é a necessidade da
existência dos coletores nos equipamentos. No entanto, alguns já possuem essas
ferramentas nativas de fábrica. Um exemplo são os equipamentos da Cisco com a
ferramenta NetFlow [13]. O Grupo de trabalho IPFIX IP Flow Information Export [14]
do IETF (Internet Engineering Task Force) vem trabalhando na definição de um padrão
de transferência de informações dessas ferramentas.
4.1.1.3. Monitor de Agentes
O “monitor de agentes” é baseado na medição feita por agentes localizados em
equipamentos da rede. Esta técnica, implementada pelo protocolo SNMP (Simple
Network Management Protocol ), é um padrão criado pelo IETF para administração de
rede. As estruturas administradas por este protocolo são definidas como MIB
(Management Information Base). Nas MIB's são definidos os elementos que geram
informações do estado atual da rede e essas estruturas definem agentes que são
instalados nos equipamentos, como os roteadores que periodicamente respondem a
pedidos de seus gerentes/coletores enviando informações do seu estado.
Estruturas como MIB-II e RMON são padrões do protocolo SNMP que possuem
os tais agentes definidos para coletar as informações da rede. As informações
relacionadas ao tráfego, que passam por estes agentes, são coletadas e enviadas a um
centralizador definido e configurado para isso. Os dados coletados podem ser então
analisados, e medidas podem ser estimadas a partir deles.
4.2. MEDIÇÃO ATIVA (INTRUSIVA)
Diferente da medição passiva, que apenas coleta informações do tráfego que
passa pela rede, na medição ativa as métricas são estimadas a partir de informações
coletadas de pacotes injetados por ferramentas apropriadas. Esta técnica de medição se
resume no envio de pacotes por determinada máquina, que serão coletados em algum
24
ponto da rede, podendo este ponto ser a mesma máquina emissora ou uma outra
máquina qualquer.
Através das medições ativas é possível estimar uma série de medidas de
desempenho, descritas com detalhe no Capítulo 2. No entanto, devido a vários
problemas para estimar determinadas métricas, em alguns casos, uma técnica específica
de medição ativa pode ser exigida.
A solução para alguns desses problemas é a variação na forma como os pacotes
são enviadas pela rede. Para cada métrica a ser coletada, pode ser exigido um método
diferente de geração dos pacotes, assim como diferentes modelos de geração.
4.2.1. Métodos de Geração do Tráfego
A escolha do “método de geração do tráfego” para uma medição ativa consiste
em decidir que formato de geração de pacotes será usado durante a medição. Por
exemplo, o método onde os pacotes são enviados em uma única direção, ou replicados
pelos receptores, ou ainda gerados nas duas direções simultaneamente. A forma de
enviar os pacotes deve ser decidida de acordo com o método a ser usado na medição. O
“método de geração do tráfego” define quais tipos de métricas podem ser estimadas a
partir da coleta dos pacotes gerados. Portanto, a escolha do método é determinada,
muitas vezes, por restrições impostas pelas próprias métricas a serem estimadas.
Dependendo da medida de interesse, diferentes métodos, quanto à geração de
pacotes, podem ser necessários. As duas formas de variação estudadas neste trabalho
estão descritas a seguir.
Um Sentido: Neste formato de geração de tráfego, os pacotes são enviados a
partir de uma origem, passam pelo caminho a ser estudado, sendo coletadas por um
receptor em algum outro ponto da rede. A partir desta coleta, apenas algumas métricas
podem ser estimadas. É importante perceber o problema para o cálculo de determinadas
medidas de desempenho, usando este método. Com esta coleta em um único sentido,
não é possível calcular com precisão medidas como o retardo, sem uso de equipamentos
especiais.
25
Ida e Volta: A geração de pacotes no método “Ida e volta” funciona como a
ferramenta PING [14]. Os pacotes de medição são gerados a partir de uma origem, na
direção do destinatário. Porém, ao contrário do método “Um sentido”, os pacotes não
são coletados no destino, eles são replicados e reenviados à origem. Desta forma,
consegue-se estimar as características dos caminhos de ida e volta daquele pacote. Estas
características podem, inclusive, ser referentes aos instantes de tempo de envio e
recebimento dos pacotes, uma vez que os “carimbos de tempo” são tirados de um único
relógio, localizado em uma mesma máquina.
4.3. MEDIÇÃO EM REDES CONVERGENTES
A medição de desempenho de um ambiente de rede com QoS pode ser
considerada como um caso especial de medição de desempenho no ambiente de rede IP.
Uma das razões para se medir o tráfego com QoS é poder concluir se as técnicas
aplicadas ao tráfego que recebe tratamento diferenciado na rede em comparação com o
tráfego de melhor esforço.
Ferramentas de medição devem ser baseadas no nível de entendimento da
arquitetura que está sendo medida para serem consideradas como ferramentas efetivas.
De forma simplificada, um ambiente Internet pode ser visto como uma coleção de
comutadores de pacotes de dados interconectados. Em cada comutador, quando um
pacote é recebido seu cabeçalho é examinado e encaminhado para transmissão. Se o
comutador puder encaminhar o pacote, este é mapeado imediatamente para transmissão
na interface de saída apropriada. Se a interface já estiver transmitindo um pacote, este é
enfileirado para posterior transmissão. Se o tamanho da fila exceder o tamanho máximo,
o pacote pode ser descartado imediatamente, ou pode ser descartado após um tempo de
espera para transmissão na fila. Enfileiramento contínuo e descarte de pacotes no
comutador ocorrem quando a taxa de chegada de pacotes excede a capacidade do meio
de transmissão incluindo a capacidade da interface.
26
4.4. ESTUDO DE CASO – UMA APLICAÇÃO DE MEDIDAS
Após ter-se abordado a problemática relacionada à medição de QoS. Pode-se
perceber que a medição, sempre que possível, deve considerar a hipótese de se utilizar
uma carga controlada de tráfego, pois esta abordagem permite uma maior precisão e um
melhor conhecimento da capacidade da rede e do comportamento dos mecanismos de
priorização e as métricas utilizadas que devem ser utilizadas nos experimentos.
Para exemplificar o procedimento de medição de QoS será realizado um estudo
de caso com o uso da rede do labcom (Laboratório de Comunicações da Universidade
de Brasília).
4.4.1. O AMBIENTE
A rede do labcom consiste de um núcleo MPLS/DiffServ interconectados por
enlaces de 10/100 Mbps. O primeiro roteador, denominado LER01 (Label Switching
Router – 01), conecta três redes locais ao núcleo MPLS. Os roteadores LSR02 e LSR04
são os elementos de encaminhamento do núcleo e o roteador LER03 conecta uma LAN,
por meio de um enlace via rádio de 2 Mbps na freqüência de 23 GHz. O núcleo
MPLS/DiffServ foi implementado no sistema operacional Linux, com kernel 2.4.21,
usando-se software de código aberto MPLS disponível em [16]. Todos os roteadores
utilizam o OSPF (Open Shortest Path First) para a determinação das rotas. A
funcionalidade dos roteadores MPLS permite o estabelecimento de LSPs, DiffServ em
LSPs, mapeamento de tráfego para LSP baseado na porta do protocolo, prefixo de
destino e DSCP (DiffServ Code Point).
Os enlaces do núcleo foram reduzidos para 1,2 Mbps, a fim de se poder
controlar a saturação e as perdas na rede. Esse valor foi escolhido em função da
capacidade de 2 Mbps do enlace aéreo. Os arquivos de configuração para esse propósito
foram implementados utilizando-se o CBQ (Class Based Queuing) para o controle de
tráfego nos sistemas Linux. Foram adicionados também controles de classificação de
tráfego, necessários para o suporte do núcleo MPLS ao Diffserv.
A figura abaixo ilustra a topologia da rede utilizada nos testes.
27
Figura 4.4 – Topologia de rede dos testes
4.4.2. AS FERRAMENTAS
4.4.2.1. MGEN
Após a abordagem da problemática relacionada à medição de QoS, percebemos
que a medição, sempre que possível, deve considerar a hipótese de se utilizar uma carga
controlada de tráfego, pois esta abordagem permite uma maior precisão e um melhor
conhecimento da capacidade da rede e do comportamento dos mecanismos de
priorização. Após pesquisa entre as ferramentas existes para a geração de um tráfego
com carga controlada, optou-se pelo MGEN [10].
O MGEN (Multi-Gerador) é uma ferramenta constituída de programas para
geração de tráfego real-time do tipo UDP multicast ou unicast de uma fonte para um
destino. O MGEN suporta parâmetros em uma linha de comando ou com Script para a
geração de fluxos de pacotes com marcação do campo do TOS do IP.
As ferramentas de geração e monitoração de tráfego do MGEN rodam em
máquinas distintas. O processo gerador roda na máquina fonte e o processo coletor na
28
máquina destino. Isso faz com que seja essencial a utilização de uma ferramenta de
sincronização de relógios das máquinas envolvidas no experimento.
Os processos transmitem e recebem (e registra) os pacotes arranjando-os num
arquivo "log" de acordo com seu número de seqüência. Os aplicativos que acompanha o
MGEN para as análises do arquivo de saída do processo coletor podem ser executados
para avaliar a rede ou a habilidade componente da rede em suportar a carga considerada
de tráfego em termos da perda do pacote, atraso, variação do atraso (jitter), vazão etc.
4.4.2.2. TRPR
Para que as métricas adotadas garantam medições consistentes e reprodutíveis, é
necessária uma ferramenta que calcule essas métricas de acordo com as definições
mostradas anteriormente. Para isso, a ferramenta TRPR (TRace Plot Real-time) é ideal,
pois ela analisa os arquivos de log gerados pelo MGEN e cria um arquivo de saída para
que o mesmo possa ser plotado em forma de gráfico.
Com o TRPR pode-se criar gráficos de banda, delay, jitter e perdas, de acordo
com as definições de métricas anteriormente mencionadas possibilitando uma solução
completa quando utilizado em conjunto com o MGEN.
4.4.2.3. Chrony
O Chrony [17] é um aplicativo que funciona segundo o modelo cliente-servidor
e que é baseado no protocolo NTP (Network Time Protocol) [18]. Esse aplicativo tem
um servidor, que roda em uma máquina que serve de relógio principal para as outras, e
um cliente, que é instalado nas máquinas clientes e configurado para sincronizar o seu
relógio com o da máquina servidora. Esse protocolo inclui atualizações periódicas para
que o sincronismo esteja sempre garantido.
Através do utilitário chronyc, disponível junto com o Chrony, é possível
verificar o estado do sincronismo e dos servidores disponíveis. Esse utilitário mostra o
IP do servidor e qual a diferença de tempo entre os relógios local e remoto, o erro
associado, assim como se estão sincronizados ou não.
29
4.4.3. TESTES DE AVALIAÇÃO
Com o objetivo de verificar o nível de desempenho e o funcionamento do
ambiente configurado, foram realizados testes para avaliar um serviço de VoIP diante
de diferentes fluxos de tráfego.
As métricas de QoS são instncias que representam um valor objetivo que
descreve a qualidade dos serviços oferecidos e sua disponibilidade dentro da rede.
Para a realização do primeiro teste, foram configurados no núcleo
MPLS/DiffServ dois ambientes: um best effort (BE) e um DiffServ (MPLS-DS). A
escolha destes ambientes se justifica pela prerrogativa de verificar, na plataforma de
código aberto, melhores métricas de QoS para o ambiente MPLS-DS.
Ambos os experimentos usam como métricas o atraso e a perda de pacotes.
Por termos produzido uma rede altamente concorrida na disponibilidade de
banda, a qualidade de voz para sistemas VoIP se torna um parâmetro de QoS
importante. A avaliação fim-a-fim da qualidade de voz usando um método subjetivo,
provê uma abordagem significativa e compreensiva para o usuário final, contraário ao
uso de um conjunto de parâmetros técnicos.
A seguir, apresenta-se uma descrição desses experimentos.
4.4.4. AVALIAÇÃO DO SERVIÇO DE VOIP
No ambiente MPLS-BE, foram definidos quatro padrões de tráfego: dois CBR
(Constant Bit Rate) e dois VBR (Variable Bit Rate), de acordo com a Tabela 4.1.
Os fluxos de VBR têm rajadas periódicas com uma distribuição exponencial. No
caso do tráfego VBR1, definiram-se rajadas de 0,5 s de duração em intervalos de 3 s e,
para o VBR2, as rajadas têm duração de 1 s em intervalos de 5 s, de tal forma a
reproduzir um tráfego com características elásticas, que periodicamente satura a banda
disponível.
30
Todos os fluxos de tráfego foram mapeados para um único LSP, cujos nós
inicial, intermediário e final são, respectivamente, o LER01, o LSR02 e o LER03.
A Tabela 4.2 mostra os fluxos definidos para a situação de ambiente MPLS-DS.
Os padrões de tráfego utilizados são semelhantes aos da Tabela 4.1, a menos do tráfego
VBR1 classificado como AF21 (Assured Forwarding Class 2 precedência de descarte
1), que foi substituído por CBR12, um tráfego do tipo CBR classificado como BE. Os
fluxos CBR1, CBR2 são classificados, respectivamente, como EF (Expedited Forward)
e AF11 (Assured Forwarding Class 1, precedência de descarte 1). Todos os fluxos de
tráfego neste ambiente foram mapeados para um único LSP, da mesma forma que no
ambiente MPLS-BE, com a diferença de que, neste caso, os mapeamentos diferenciam
cada tipo de tráfego.
Tabela 4.1 – Fluxos de tráfego para MPLS-BE Tipo de tráfego Taxa Tamanho do
pacote CBR1 64 kbps 256 bytes CBR2 384 kbps 512 bytes VBR1 1.000 kbps 1.024 bytes VBR2 1.000 kbps 1.024 bytes
Tabela 4.2 – Fluxos de tráfego para MPLS-DS Tipo de Tráfego
Taxa Classe Tamanho do Pacote
CBR1 64 kbps EF 256 bytes CBR2 384 kbps AF11 512 bytes CBR12 1.000 kbps BE 1.024 bytes VBR2 1.000 kbps AF21 1.024 bytes
Os resultados das medições obtidos para o ambiente MPLS-BE são apresentados
nas figuras de 4.5 a 4.7, que mostram, respectivamente, a distribuição da banda total
(1,2 Mbps, no eixo vertical) para os fluxos, a latência para os fluxos CBR1 e CBR2, e o
percentual de perdas de pacotes por cada fluxo de tráfego. Na figura 4.5, verifica-se que
a utilização de banda dos fluxos CBR1 e CBR2 esteve ao redor da banda
31
preestabelecida, enquanto os fluxos VBR1 e VBR2 tiveram nos bursts limitações de
utilização de banda, o que resulta em maiores perdas.
Na Tabela 4.3, é feita uma comparação das perdas médias de pacotes por fluxo
de tráfego. Para medir a qualidade da conexão VoIP, foram realizadas chamadas de
duração de 60 s cada. Essas chamadas foram avaliadas de acordo com a metodologia
MOS [19] (Mean Opinion Score) e os resultados para os codecs G711 e G729 tiveram
valores, respectivamente, iguais a 2,5 e 1,8.
As figuras 4.8 e 4.9 mostram os resultados obtidos para a situação MPLS-DS,
respectivamente, para a distribuição da banda disponível em cada um dos fluxos, a
latência nos fluxos CBR1 e CBR2, e os percentuais de perda de pacotes por cada fluxo.
Figura 4.5 – Distribuição de banda no ambiente MPLS.
32
Figura 4.6 – Latência no ambiente MPLS
Figura 4.7 – Perdas no ambiente MPLS (em percentual)
Tabela 4.3 – Perdas Médias para MPLS-BE Fluxo Perdas médias (%) CBR1 5,4 CBR2 3,9 VBR1 14,1 VBR2 21,0
33
Na Figura 4.8 pode-se observar que os fluxos de tráfego mapeados em classes de
maior precedência sempre mantêm a utilização de banda que precisam, enquanto os
fluxos com menor precedência, tais como o CBR12, fazem uso da banda restante,
independentemente da sua necessidade. As perdas médias por fluxo para o MPLS-DS
foram iguais a zero para os tráfegos CBR1 e CBR2, igual a 36,7% para o tráfego
CBR12 e de 26,3% para VBR2. Dessa forma, os fluxos marcados como EF e AF11 não
sofreram perdas, enquanto o fluxo marcado como BE foi o que apresentou a maior
perda.
Como no ambiente anterior, foi realizada uma conexão VoIP no intervalo de
duração dos fluxos, mas, especificamente neste caso, a classe outorgada para esta
ligação foi a EF, de tal forma que se busca beneficiar a precedência deste fluxo dentro
da rede. O resultado da avaliação MOS para os codecs G711 e G729 utilizados no
telefone IP foram iguais, respectivamente, a 4,3 e 3,5.
A partir desses resultados, é evidenciado o benefício alcançado com a
implementação da classificação de tráfego. No ambiente MPLS-DS, existe uma latência
maior que a observada na plataforma MPLS-BE, mas é importante observar que no
ambiente com DiffServ, o processo de classificação de pacotes e a sua verificação
introduzem um overhead significativo, especialmente quando se tratar de pacotes com
menor tamanho. Nos experimentos realizados, esse processo de classificação teve
implicação no cálculo da latência.
No segundo experimento, foi introduzida uma variação nos fluxos de tráfego,
sendo que um dos fluxos VBR foi substituído por um CBR classificado como melhor
esforço. Esta mudança foi motivada sob a consideração de que um fluxo de taxa
constante viria a perturbar mais a medição de atraso ou perda de pacotes de outros
fluxos, em função da sua necessidade uniforme de banda. Outros experimentos
utilizando um fluxo VBR classificado como BE não mostraram resultados de latência
muito diferentes dos obtidos no ambiente MPLS-DS [20].
Apesar de existir uma latência maior na plataforma MPLS-DS, as perdas de
pacotes são consideravelmente menores. Esse resultado é contrário ao esperado e se
34
justifica pelo processo de classificação associado a cada fluxo de tráfego, que
influenciou diretamente no cálculo da latência. Identifica-se então, uma carência na
implementação de código aberto do MPLS/DiffServ.
Figura 4.8 – Distribuição de banda no MPLS-DS.
Figura 4.9 – Latência no MPLS-DS
35
Os resultados de perda e latência correspondem à percepção dos usuários na
avaliação MOS das conexões VoIP. O uso de um ou outro tipo de codec influencia, mas
o bom desempenho da rede é um fator fundamental para uma boa avaliação subjetiva.
4.4.5. CONCLUSÃO DO ESTUDO DE CASO
Os resultados descritos acima levam a pensar que o processo de realização de
testes de avaliação é simples. Entretanto muitas das vezes o grande problema que
inviabiliza a realização desses testes é a grande quantidade de ferramentas utilizadas, a
quantidade de comandos necessários e a inexistência de uma única ferramenta gráfica
que possibilite a realização dos experimentos de uma forma simples e correta. Para
resolver este situação, a proposta desse trabalho foi o desenvolvimento de uma
ferramenta que convergisse todas as aplicações existentes atualmente para uma única
ferramenta gráfica que fizesse todas as operações necessárias como se fossem uma só.
Essa ferramenta, sua arquitetura e sua topologia serão abordadas no capítulo seguinte.
4.5. CONCLUSÃO
Este capítulo abordou a problemática relacionada à medição de QoS. A
discussão permitiu concluir que a medição, sempre que possível, deve considerar a
hipótese de se utilizar uma carga controlada de tráfego (medição ativa), pois esta
abordagem permite uma maior precisão e um melhor conhecimento da capacidade da
rede e do comportamento dos mecanismos de priorização. Por fim foi ilustrado um
estudo de caso a fim de exemplificar essa problemática bem como os resultados obtidos.
No próximo capítulo será mostrada a ferramenta desenvolvida ao longo desse trabalho
para a análise de desempenho de redes bem como a sua arquitetura e funcionamento.
36
5. APRESENTAÇÃO DO SOFTWARE
A seguir, será apresentado o software desenvolvido, de nome Analisador,
primeiramente será feita uma análise da forma em que ele está estruturado e sua função
principal, depois a estrutura estática e dinâmica das classes JAVA que o compõem e,
finalmente, sua interface gráfica, os processos que realiza e o modo de operação.
5.1. NECESSIDADE DO SOFTWARE
Da prática de experimentos, simulações e testes no laboratório, pôde-se perceber
que são muitas e variadas as atividades a se executar no ambiente para que ele esteja
pronto para os testes. Notou-se também que muitas dessas atividades são comuns a
todos os ambientes, por exemplo, a geração de dados de um lado e sua captação do
outro, cálculo de medidas de desempenho e sua visualização gráfica.
Todas essas atividades tinham de ser executadas muitas vezes, visto a
diversidade dos testes. Essa situação atrasava e dificultava bastante as análises porque
se perdia muito tempo com a preparação para cada teste. Daí surgiu a idéia da
automatização, de forma que o usuário pudesse fazer testes sem precisar conhecer que
comandos executar, que sintaxe usar, qual a seqüência certa, nem esquecer um ou outro
item essencial ao teste. Além disso, há um maior controle das variáveis, já que o mesmo
teste pode ser repetido da mesma maneira, com os mesmos parâmetros usados em outra
ocasião.
5.2. CONVERGÊNCIA DE APLICATIVOS
A ferramenta desenvolvida integra vários softwares já existentes e mencionados
no capítulo 3, mas que realizam tarefas individuais. Assim, o usuário tem um só
software, com uma interface única, muito mais simples de se operar.
O aplicativo configura o gerador de tráfego MGEN [10] na origem e no destino,
com scripts que serão gerados a partir de entradas do usuário. Cada script contém um ou
mais fluxos com informações de duração, tamanho de pacote, taxa de transmissão,
marcação do campo ToS e outras.
37
Após isso, inicia-se a geração e escuta do tráfego concomitante nas estações. Na
origem, inicia-se a geração com base no script montado e, no destino, a operação feita é
iniciar o escutador e pará-lo logo após o fim da transmissão.
Segue-se a isso a transformação do log da transação em um arquivo plotável.
Esse arquivo contém instruções para a montagem do gráfico, tais como legendas, cores,
etc. Com esse arquivo, pode-se usar um software de plotagem, por exemplo o gnuplot,
para traçar os gráficos e mostrar na tela do usuário. Além disso, o gráfico também é
exportado em um arquivo de imagem.
Finalmente, o aplicativo reúne na estação cliente os arquivos de resultado do
processo para posterior análise das informações, seja ela humana ou por meio de um
software especializado, por exemplo, o MatLab.
5.3. VANTAGENS
Uma das vantagens de se ter uma plataforma desse tipo é não ser mais
necessário o uso de comandos enormes, várias ferramentas a serem controladas,
conhecimento e praticidade no uso das ferramentas para realizar os testes e simulações
no ambiente de rede.
As principais vantagens do uso de tal ferramenta são:
• Produtividade: Sem a preocupação de realizar o procedimento, e sendo
este feito de forma automatizada, o usuário pode tirar suas conclusões
mais rapidamente;
• Padronização: Uma vez salvos, os testes podem ser executados quantas
vezes forem necessárias, sempre da mesma maneira, significando maior
controle das variáveis por parte do usuário.
38
5.4. DESCRIÇÃO DO SOFTWARE
A ferramenta desenvolvida consiste em um aplicativo cujo código foi escrito na
linguagem JAVA, escolhida pela sua portabilidade. Dessa forma, a aplicação pode ser
executada a partir de uma plataforma Windows, Linux ou outras.
5.4.1. SINCRONISMO
O sincronismo entre as estações origem e destino é uma questão que afeta
diretamente as medições, principalmente a medida do atraso e do jitter. Portanto, o
Analisador provê um mecanismo para checar se as estações estão sincronizadas entre si
antes de começar a geração de dados.
Para realizar o sincronismo entre as estações, é utilizada a ferramenta chrony,
descrito no capítulo 4. O chrony tem um utilitário que permite verificar se as estações
estão sincronizadas.
Clicando-se no botão de verificar sincronismo, o software verifica se as estações
estão sincronizadas e, portanto, prontas para começar a simulação. Para prover mais
informações ao usuário, é mostrada uma janela com várias informações. Assim, se o
sincronismo não estiver OK, o programa fornece informações sobre o que pode estar
errado, para que o usuário possa solucionar o problema facilmente. Se a simulação for
iniciada sem essa verificação prévia, corre-se o risco de as medidas de atraso e jitter não
traduzirem a realidade. Como o tempo de convergência do protocolo NTP (Network
Time Protocol) é variável, o usuário deverá sempre checar o sincronismo antes de
realizar uma medição e ter certeza que o protocolo NTP está rodando.
O mecanismo de sincronismo usado é o provido pelo protocolo NTP,
especificado na RFC 1305. Segundo a RFC, o overhead causado na rede depois de
sincronizados os clientes é quase nulo e o algoritmo de sincronização utilizado está
documentado no apêndice G da própria RFC.
39
5.4.2. UML
Como é comum no desenvolvimento de software, foi elaborado um modelo no
formato Unified Modeling Language (UML) para dar suporte à programação do código
e também para facilitar o entendimento da aplicação por meio de diagramas. Essa
estrutura envolve os seguintes diagramas: “Casos de Uso”, “Estrutura Estática”,
“Diagrama de Seqüência”.
O diagrama de Casos de Uso indica as ações que o usuário do sistema poderá
executar, ilustrado na figura 5.1.
Figura 5.1 – UML Diagrama de Casos de Uso
O diagrama de Classes ou Estrutura Estática mostra as classes que compõem o
sistema, os atributos e métodos de cada uma e o relacionamento entre uma classe e
outra, como indica a figura 5.2.
Para o software Analisador, foi usado um pacote de classes auxiliar, o Jakarta
Commons Net (commons-net-1.2.2.jar), para fazer as operações de Telnet e FTP
realizadas no programa. Essas operações são a base da comunicação do programa com
as estações envolvidas. Elas possibilitam que o programa seja executado remotamente, a
partir de qualquer estação que tenha conexão IP com os nós origem e destino.
Quanto às classes próprias do programa, tem-se primeiramente a classe Config,
que lê o arquivo de configuração, com a localização dos programas necessários nas
40
estações origem e destino. A classe Startup é o coração do programa, ela inicializa a
janela principal, cria instâncias das outras classes e dá início aos processos de geração
de tráfego e medição dos parâmetros de QoS.
A classe Host é um objeto usado para representar as estações origem e destino
do tráfego. A classe Traffic é um objeto para representar cada tráfego adicionado pelo
usuário. A classe NewTrafficDialog reúne todo o procedimento envolvido na adição de
um tráfego à simulação, da abertura da janela à adição das entradas no script.
A classe TrafficFile permite que aconteçam as operações de Salvar e Carregar
Ambiente. Ela é o objeto que representa o ambiente inteiro, criado e gerenciado pelo
usuário.
A classe SyncCheck é responsável por fazer o telnet para as duas estações,
origem e destino, e checar o sincronismo através do utilitário chronyc. O resultado dessa
verificação é mostrado na tela, com informações sobre o servidor que está provendo o
relógio principal, e se o relógio das máquinas já pode ser sincronizado ou não.
41
Figura 5.2 – UML Diagrama de Classes
Para mostrar as interações entre as entidades envolvidas no processo de
execução do sistema, e sua distribuição temporal, há o diagrama de Seqüência,
mostrado na figura 5.3. Neste diagrama há quatro entidades: o usuário do sistema, o
software Analisador de desempenho, as estações origem e destino do tráfego.
42
Os eventos iniciados a partir do usuário são basicamente aqueles causados pelo
pressionamento dos botões da tela principal, eles são:
• adicionar fluxo;
• executar simulação;
• abrir ambiente;
• salvar ambiente;
• verificar sincronismo.
Os outros eventos são conseqüência de algum comando do usuário e são
necessários para completar a ação. Note que muita ação é automatizada pelo programa,
ao contrário do que ocorria anteriormente, quando quase todas tinham de ser executadas
manualmente pelo usuário a partir de estações diferentes, por meio de ações cujos
comandos são quase impossíveis de decorar. Daí o benefício do uso do programa.
Os eventos indicados pela meia-seta ( ) não acontecem ou não
precisam acontecer exatamente na seqüência mostrada, os demais acontecem na mesma
seqüência que mostra o diagrama. As setas tracejadas indicam resposta a um
procedimento feito no sentido contrário.
43
Figura 5.3 – UML Diagrama de Seqüência
A partir desses diagramas UML é possível entender melhor como está
estruturado o programa e como foi pensado o seu desenvolvimento.
5.4.3. PROGRAMA ANALISADOR
A partir da tela principal, mostrada na figura 5.4, o usuário pode criar um novo
ambiente, salvá-lo ou carregar um ambiente salvo previamente. Para carregar um
ambiente já existente, é suficiente clicar no botão de abrir ambiente, e escolher um
arquivo de ambiente. Fazendo isso, as informações daquele ambiente, incluindo destino,
44
origem, credenciais de telnet e ftp, bem como todos os fluxos adicionados, serão
carregadas na tela e o usuário pode executar a simulação carregada.
Figura 5.4 – Tela principal do programa
O ambiente de teste é salvo como um objeto JAVA, de forma que é possível
futuramente fazer esse arquivo ser lido por outra aplicação JAVA que use essas
informações para, por exemplo, gerência SNMP do ambiente testado, ou geração
automatizada de um relatório do teste. As linhas a seguir mostram o formato do arquivo
de ambiente.
public class TrafficFile {
private String srcIp;
private String srcTelnetUser;
private String srcTelnetPasswd;
private String dstIp;
private String dstTelnetUser;
private String dstTelnetPasswd;
45
private String dstFtpUser;
private String dstFtpPasswd;
private Vector traffics;
}
Para salvar um dado ambiente, o usuário pode tanto partir do zero, operação
normal, quanto partir de um ambiente já salvo. Para isso, basta carregar o ambiente
anterior e salvar as alterações com outro nome, veja na figura 5.5.
Figura 5.5 – Tela de Salvar ambiente
Essas funcionalidades fazem com que o programa ajude o usuário no
gerenciamento dos arquivos relativos às simulações para, por exemplo:
• organização da matéria-prima dos testes;
• necessidade de realizar um teste várias vezes;
• necessidade de realizar testes diferentes, mas semelhantes entre si;
46
• elaboração de relatórios descritivos da simulação.
Escolhido um ambiente de teste, a tela principal contém todos os dados relativos
a esse ambiente. Um ambiente requer a configuração dos seguintes campos:
• IP de origem do tráfego (gerador)
• IP de destino do tráfego (receptor)
• Credenciais (usuário e senha) de telnet na origem
• Credenciais (usuário e senha) de FTP e telnet no destino
• Fluxos a serem gerados, que incluem, cada um:
o Porta de origem
o Porta de destino
o Tipo de fluxo (Periódico, Poisson ou Rajada)
o Tempo de início e fim (em segundos)
o Taxa de pacotes
o Tamanho de pacotes
o Parâmetros adicionais
Para fazer a adição de fluxos, basta clicar no botão da janela principal e uma
janela se abrirá para a especificação do fluxo. Exemplos das janelas de fluxo podem ser
vistos na figura 5.6.
47
Figura 5.6 – Janelas de Fluxo: Tráfego Periódico e de Rajada
O usuário deve manter os valores dentro de um limite razoável, considerando:
• tamanho mínimo e máximo dos pacotes UDP: 28 a 8192 bytes
• taxa de transmissão máxima dos enlaces, tal que [TAXA DE
ENVIO]x[TAMANHO DO PACOTE]x8 não ultrapasse a velocidade do
enlace total (de uma ponta a outra).
• tempo de fim do fluxo maior que tempo de início.
Os fluxos têm três perfis possíveis, conforme especificações da ferramenta
MGEN [10]:
• Periódico: fluxo de tráfego de taxa constante, também chamado CBR
(Constant Bit Rate).
• Poisson: Esse padrão gera mensagens de tamanho fixo em intervalos
variando estatisticamente em uma taxa fixa, especificada pelo usuário,
genericamente conhecido como VBR.
48
• Rajada: gera rajadas de outros padrões (Periódico e Poisson) em um
intervalo médio especificado. Outro parâmetro do padrão Rajada é
Regular resultando em rajadas de duração específica distribuídas
uniformemente no tempo, ou Aleatório que distribui exponencialmente
as rajadas no tempo em intervalos de duração média especificada pelo
parâmetro “Intervalo”. Genericamente conhecido como VBR
Terminada a configuração do ambiente, o usuário dá início à execução do
processo clicando no botão da tela principal.
Nesse momento são iniciados remotamente procedimentos nas duas estações
(origem e destino do tráfego) para gerar os fluxos e colher os resultados referentes à
medição do tráfego.
Após serem passadas todas as informações sobre a simulação, o programa inicia
uma série de procedimentos para que a simulação ocorra. Como foi comentado
anteriormente, o software desenvolvido utiliza várias ferramentas para realizar o
processo de geração e medição. Esse processo ocorre da seguinte maneira.
De posse dos endereços IP das máquinas de origem e destino, o programa realiza
uma conexão telnet nessas máquinas a fim de controlar os processos que serão iniciados
em cada uma das máquinas. Após essa etapa, são passados para a máquina de origem os
parâmetros do tráfego a ser gerado. Na máquina de destino é informado que será
iniciada uma medição. Com isso, o processo de geração de trafego é iniciado entre as
duas máquinas. Ao término da geração, a máquina de origem informa ao programa o
final da simulação que por sua vez informa à máquina destino para iniciar o
procedimento de geração dos gráficos. Nesse processo, uma outra ferramenta, o TRPR,
é utilizada para fazer o tratamento dos dados. Ao final dessa etapa, todos os gráficos
referentes a simulação estão presentes na máquina de destino. Sendo assim, o programa
realiza uma conexão FTP no destino e busca todos os gráficos gerados. Esses gráficos
são armazenados na máquina onde se executa o programa analisador de desempenho.
Após todos esses procedimentos, os resultados são mostrados na tela do usuário;
este pode fazer sua análise e repetir a simulação se for o caso.
49
5.5. CONSIDERAÇÕES SOBRE A APLICABILIDADE
O software foi feito para ser aplicável em qualquer rede, não importando que
tipos de gateways, comutadores, enlaces ou protocolos estão entre a origem e o destino.
Somente as estações de origem e destino do tráfego precisam obedecer a alguns
requisitos. Sendo assim, pode-se usar, por exemplo, duas estações móveis (notebooks)
como origem e destino e o software poderá ser usado onde quer que sejam levadas essas
estações móveis.
Devido o uso das ferramentas mencionadas no item 5.2, é necessário ter nas
máquinas origem e destino um conjunto de softwares, que são os usados pelo programa
Analisador para fazer os testes. Esses requisitos são mostrados no quadro a seguir:
Máquina Origem Máquina Destino Sistema Operacional Linux Sistema Operacional Linux Utilitário para geração de tráfego MGEN Utilitário para geração de tráfego MGEN Sincronização Chrony Sincronização Chrony Utilitário para tratamento dos dados TRPR Utilitário para plotagem de gráficos Gnuplot Servidor FTP para transferência dos
resultados FTPd
As referências [10], [17] e [21] ensinam como instalar alguns desses utilitários
5.6. CONCLUSÃO
Este capítulo teve como função mostrar qual o layout do software, como ele
funciona e como o usuário pode operá-lo, além de dar uma idéia da sua estrutura de
classes, como foi desenvolvido. Essas informações, além de apresentar a interface
gráfica e mostrar o modo de operação, buscam servir de matéria prima para
desenvolvedores realizarem outros softwares que permitam ainda mais operações e
melhore ainda mais o ferramental de análise de QoS existente.
Como se trata de um software que tem por objetivo a praticidade, nada melhor
para compreendê-lo que vê-lo na prática, em funcionamento. Por isso, esperamos que o
capítulo que aqui termina tenha servido como estímulo para o uso do software, ocasião
na qual o entendimento e o objetivo desse capítulo realmente se completam.
50
6. CONCLUSÕES
A necessidade de conhecer as características das redes de comunicação,
principalmente a Internet, é cada vez maior. A forma como a Internet foi concebida,
baseada na técnica de comutação de pacotes com o uso de datagramas e sem nenhuma
reserva de banda nem priorização, impede que garantias da qualidade do serviço sejam
oferecidas. Conseqüentemente, dificulta que aplicações com requisitos mínimos para
um bom funcionamento sejam implantadas. Por isso, conhecer o estado e as
características da rede é fundamental para a implementação desse tipo de aplicações. 0
O objetivo deste trabalho foi fazer uma avaliação de métricas obtidas através de
medições ativas. Algoritmos foram estudados, avaliados e implementados em um
software, para possibilitar que sejam estimados os atrasos dos pacotes, perdas, jitter e
banda utilizada. A implementação do software possibilitou uma análise das métricas
relacionadas com o desempenho em redes convergentes.
O trabalho desenvolvido durante este Projeto Final de Graduação contribuiu para
o nosso conhecimento técnico. Compreendeu-se a fundo como funciona a pilha de
protocolos TCP/IP em um sistema operacional Linux, as operações que o kernel realiza
e vislumbrou-se a ampla gama de operações que as ferramentas atuais permitem fazer
em uma rede IP, tudo a partir de um kernel Linux.
Além disso, também foi possível compreender melhor as motivações, a
importância e os mecanismos de Qualidade de Serviço nas redes de pacotes. Com mais
profundidade, estudou-se os modelos de priorização de tráfego e o modelo de QoS mais
usado atualmente, o DiffServ.
Além da imensa serventia em termos de conhecimento acadêmico e prático, este
projeto teve um segundo e não menos importante propósito, que foi o de prover aos
pesquisadores, em especial aos do LabCom, uma ferramenta que agilize e torne mais
fácil a tarefa constante de realizar medições e simulações com variados perfis de tráfego
transportados por topologias de rede diversas. Atentando para os trabalhos produzidos
pelo laboratório nos anos de 2003 e 2004, percebe-se que essa atividade de medição tem
51
sido fator fundamental na realização dos experimentos descritos. Acredita-se que o
presente projeto vai diminuir o tempo gasto com a operacionalidade do teste,
possibilitando mais foco na análise dos resultados por parte do pesquisador.
Apesar da implementação do software estar concluída, trabalhos futuros podem
ser desenvolvidos a partir do desenvolvimento deste trabalho e outras implementações
podem ser adotadas, uma delas seria a integração com o software de medição passiva
atualmente em desenvolvimento no LabCom. Com a integração desses softwares será
possível uma análise mais completa utilizando tanto medições ativas quanto passivas.
52
7. TRABALHOS FUTUROS
Ao final do desenvolvimento do software, notaram-se alguns detalhes que
seriam bastante úteis ao usuário, enriquecendo a ferramenta, e que não puderam ser
implementadas durante este projeto final por não haver tempo hábil para tanto.
Trataremos as mais importantes neste capítulo, procurando dar idéias a quem se
interessar pela continuidade do desenvolvimento.
Uma possibilidade que foi enxergada desde o início do projeto foi a integração
com um software de medição passiva de redes. Usando tanto a medição passiva quanto
a ativa, o usuário pode ter dados instantâneos com a ativa e também ter dados históricos
com a passiva, pouquíssimas ferramentas hoje disponíveis permitem essas duas visões.
Outra sugestão seria quanto à customização dos gráficos mostrados ao usuário.
O programa hoje não permite a alteração dos parâmetros de plotagem, eles são fixos.
Mas o usuário poderia dispor de uma janela onde informasse escala, distância entre os
pontos do gráfico etc. Além disso, o usuário teria a opção de gerar um arquivo com os
dados para plotagem em outro programa, ou mesmo geração de tabelas e dados
estatísticos.
Outra função imaginada foi a visualização gráfica da topologia que está entre o
nó origem e o nó destino. Isso seria mais factível através do uso do protocolo SNMP.
E, por fim, uma questão que foi muito trabalhada mas que não obteve uma
solução ideal: o sincronismo entre as estações. O software atualmente só checa se as
estações estão sincronizadas. Uma evolução dele poderia fazer o sincronismo ser
forçado, ou seja, o sincronismo acontecer ao comando do usuário. Assim, quando o
usuário dá o comando de início do sincronismo, o programa inicia o processo nas
máquinas origem e destino, espera o tempo de convergência dos relógios e avisa o
usuário quando estiverem prontas para a simulação.
53
8. REFERÊNCIAS
[1] IP Quality of Service - Cisco Press, 18 de Janeiro de 2001 - ISBN 1-57870-116-3
[2] NAGLE, JOHN, RFC 896 - Congestion control in IP/TCP internetworks, IETF, 6 de Janeiro de 1984
[3] BRADEN, R. , RFC 1122 - Requirements for Internet Hosts - Communication Layers, IETF, Outubro de 1989
[4] STEVENS, W. , RFC 2001 - TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms, IETF, Janeiro de 1997
[5] BERNET, Y.; BLAKE, S.; GROSSMAN, D.; SMITH, A.; RFC 3290 - An Informal Management Model for Diffserv Routers, IETF, Maio de 2002
[6] BRADEN, R.; ZHANG, L.; BENSON, S.; HERZOG, S.; JAMIN, S.; RFC 2205 - Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification, IETF, Setembro de 1997
[7] NICHOLS, K.; BLAKE, S.; BAKER, F.; BLACK, D.; RFC 2474 - Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers, IETF, Dezembro de 1998
[8] BLAKE, S.; BLACK, D.; CARLSON M.; DAVIS, E.; WANG, Z.; WEISS, W., RFC 2475 - An Architecture for Differentiated Service, IETF, Dezembro de 1998
[9] DEMICHELIS, C.; CHIMENTO P. (1999): Instantaneous Packet Delay Variation Metric for IPPM, ippm draft.
[10] Naval Research Laboratory (NRL): The Multi-Generator (MGEN) Toolset. http://manimac.itd.nrl.navy.mil/MGEN/.
[11] GROSSGLAUSER, M., E REXFORD, J., Passive traffic measurement for IP operations. To appear as a chapter in The Internet as a Large-Scale Complex System, Oxford University Press.
[12] VAN JACOBSON, C. L., E MCCANNE, S. Tcpdump ftp://ftp.ee.lbl.gov/tcpdump.tar.Z.
[13] CISCO. Netflow. ftp://www.cisco.com/netflow
[14] IPFIX WG - IETF Web Page. http://www.ietf.org/
[15] Muuss, M. Ping, 1989. ftp://ftp.arl.mil/pub/ping.shar
54
[16] [On-line] http://dsmpls.atlantis.rug.ac.be
[17] Chrony http://chrony.sunsite.dk
[18] MILLS, DAVID L., RFC 1305 - Network Time Protocol (Version 3) Specification, Implementation, IETF, Março de 1992
[19] ITU-T : Recommentaition P.800: Methods for subjective determination of transmission quality. Genève, Agosto 1996
[20] S. AVALLONE, M. ESPOSITO, A. PESCAPÈ, S.P. ROMANO AND G. VENTRE, “An Experimental Analysis of Diffserv-MPLS Interoperability”, Proceedings of 10th IEEE International Conference on Telecommunications (ICT 2003), Vol. I, pag. 281-287, IEEE Catalog Number 03EX628, Fevereiro 2003.
[21] trpr User Guide http://proteantools.pf.itd.nrl.navy.mil/trpr.html
55
ANEXO A – CONFIGURAÇÃO DO CHRONY
No servidor (/etc/chrony.conf):
driftfile /etc/chrony.drift
commandkey 25
keyfile /etc/chrony.keys
initstepslew 10
local stratum 8 manual
allow 0/0
No cliente(/etc/chrony.conf):
server X.X.X.X
driftfile /etc/chrony.drift
logdir /var/log/chrony
keyfile /etc/chrony.keys
commandkey 24
local stratum 10
initstepslew 20