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
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)
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.
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.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
Í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
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áliconstituindo-ses de deconstituindo-sempenho 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.
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 dos Pacotes
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.
17 Taxa de perdas = 100 cot º cot º × recebidos es pa de total N perdidos es pa de N
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.
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.
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
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.
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.
