Uma Técnica para Avaliação do Nível de Qualidade de Voz Oferecida por uma Rede IP com Serviços Diferenciados *

Transcrição

1 Uma Técnica para Avaliação do Nível de Qualidade de Voz Oferecida por uma Rede IP com Serviços Diferenciados * Renato D. V. Oliveira 1, Rogério Maniezi 2, Roberto Willrich 1,2, Roberto A. Dias 3, Fernando Barreto 1, Bruno Bisol 1 1 NURCAD Núcleo de Redes de Alta Velocidade e Computação de Alto Desempenho Universidade Federal de Santa Catarina (UFSC) Caixa Postal Florianópolis SC Brasil 2 INE Departamento de Informática e Estatística da UFSC Caixa Postal Florianópolis SC Brasil 3 CEFET/SC Centro Federal de Educação Tecnológica de Santa Catarina Florianópolis SC Brasil {renato,fbarreto,bruno}@nurcad.ufsc.br, {maniezi,willrich}@inf.ufsc.br, roberto@cefetsc.edu.br Abstract. The voice quality offered by Voice over IP (VoIP) applications depends on the quality offered by the communication services. To achieve quality, it s necessary to guarantee data delivery in a reasonable and limited time. This guarantee is not supplied by today s Internet, because various limitations are encountered in this infrastructure. The Differentiated Services architecture DiffServ has been outstanding as a solution to provide quality of service over the Internet. This article proposes an analysis technique of the voice quality provided by an IP network, with or without DiffServ. Based on this technique, the voice traffic behavior provided by an IP network using DiffServ is also investigated. Resumo. A qualidade de voz oferecida pelas aplicações de Voz sobre IP (VoIP) é dependente da qualidade oferecida pelos serviços de comunicação. Para se obter qualidade, é necessário garantir uma entrega de dados dentro de um prazo razoável e limitado. Garantia essa que não é fornecida pela Internet atual por conta das várias limitações em sua infra-estrutura. A arquitetura Serviços Diferenciados DiffServ vem destacando-se como solução para o provimento de qualidade de serviço na Internet. Esse artigo propõe uma técnica de avaliação da qualidade de voz oferecida por uma rede IP, com ou sem DiffServ. Baseado nesta técnica, também é investigado o comportamento do tráfego de voz oferecido por uma rede IP usando DiffServ. * O presente trabalho foi realizado com o apoio do CNPq (Proc. No /01-5).

2 1. Introdução O modelo de serviço melhor esforço (BE - Best Effort) suportado pela Internet atual, não fornece garantias na qualidade dos serviços de transmissão de dados (não há garantias de taxa de bits, atraso e variação de atrasos). Este modelo de serviço é suficiente para muitas aplicações convencionais, tais como transferência de arquivos, correio eletrônico ou simples navegação na Web. Essas aplicações são chamadas elásticas pela habilidade que possuem em se adaptar a determinadas taxas de erros e atrasos de entrega [Albrecht 2000]. Contrastando com as aplicações elásticas, têm-se as aplicações tempo-real, que exigem do sistema de comunicação o fornecimento de certas garantias de Qualidade de Serviço (QoS) para a realização de suas atividades a contento. Nesta classe, se enquadram as aplicações multimídia que incluem transferências tempo-real de áudio e vídeo. Para garantir a QoS destas aplicações, alguns esforços têm sido realizados para fazer da Internet atual um sistema de comunicação eficiente para aplicações tempo-real. As estruturas propostas para voz sobre IP (VoIP) sugerem a adoção de mecanismos de serviços diferenciados para o encaminhamento de seus fluxos de voz [Naser 1998]. Vários trabalhos ([Dovrolis 1999], [Semret 2000], [Oliveira 2001]) analisam aspectos distintos da arquitetura de Serviços Diferenciados quando se refere a mídias contínuas (áudio e vídeo). Outros propõem metodologias para análise de aplicações tais como mídias contínuas ([Fonseca 2001], [Sitolino 2001]). No entanto, o tráfego de voz sobre um domínio DiffServ permanece pouco explorada. [Rezende 1999] explora essa linha de pesquisa, porém usando um simulador de rede sem utilizar um ambiente real. Um diferencial deste artigo é a adoção de um ambiente de rede real (Linux), para a investigação de voz sobre IP, incluindo o uso de serviços diferenciados. Este artigo propõe uma técnica de avaliação da qualidade de voz oferecida por uma rede IP, com ou sem DiffServ, medindo a influência dos níveis de desempenho da rede na qualidade de voz percebida pelos usuários. A qualidade de voz avaliada é expressa em termos de níveis de qualidade de voz percebida, extraída a partir dos níveis de qualidade de serviço oferecidos pela rede. Esta técnica pode ser utilizada para avaliar os níveis de qualidade de voz que um suporte de comunicação vai oferecer antes da efetiva implantação de serviços e equipamentos de VoIP. Servindo assim para medir o impacto do suporte de comunicação na qualidade da voz. Baseado na técnica proposta, este artigo também apresenta uma análise do comportamento do tráfego de voz quando mapeado em diferentes níveis de qualidade oferecidos pela arquitetura DiffServ. Para tal, foi necessária a definição, implementação e utilização de um ambiente de teste para aplicações Voz sobre IP (VoIP). Esse trabalho foi desenvolvido no contexto do projeto CNPq/RHAE UCER (Uso Controlado e Eficiente de Recursos em Redes IP usando a Tecnologia MPLS) [UCER 2003]. A organização do artigo está na forma que segue. A Seção 2 apresenta a arquitetura Serviços Diferenciados. Em seguida, a Seção 3 caracteriza um tráfego de VoIP e a medição da qualidade de voz. A técnica de avaliação da qualidade de voz em redes IP proposta por esse artigo é apresentada na Seção 4. Na seqüência, a Seção 5 ilustra a aplicação da técnica

3 proposta em uma análise da qualidade de voz oferecida pela rede quando mapeado em diferentes níveis de qualidade oferecidos por um domínio DiffServ. Finalmente, as conclusões deste estudo são apresentadas na Seção Serviços Diferenciados Na arquitetura de Serviços Diferenciados (DiffServ) [Blake 1998], os pacotes IP são marcados diferentemente para criar várias classes de pacotes. Pacotes de classes diferentes recebem diferentes qualidades de serviço. No caso do IPv4, esta marcação é efetuada no campo DS (Differentiated Services) do cabeçalho do IP (antigo campo Type of Service - TOS). O Campo DS é subdividido em 2 bits reservados e 6 bits constituindo o DSCP (DiffServ Code Point). O DSCP define o tratamento de encaminhamento particular, ou PHBs (Per-Hop Behaviors), que o pacote deve receber em cada nó da rede. Atualmente existem duas propostas de PHB para a implementação de Serviços Diferenciados: o Encaminhamento Expresso (Expedited Forwarding - EF) [Jacobson 1999] e o Encaminhamento Assegurado (Assured Forwarding - AF) [Heinanen 1999]. As aplicações clientes podem marcar os campos DS dos pacotes para indicar o serviço desejado, ou então estes campos são marcados pelo roteador de fronteira de um domínio DS baseado em um esquema de classificação. A figura 1 apresenta um exemplo de domínio DiffServ. Nas bordas deste domínio estão localizados os roteadores de fronteira (1, 4 e 5). Estes roteadores assumem, dependendo do sentido do tráfego tratado, o papel de roteador de ingresso ou egresso. Neste exemplo, o roteador 1 representa um roteador de ingresso e o roteador 4, de egresso. Nos roteadores de ingresso, os pacotes IP são classificados e marcados, em seguida são encaminhadas pelos roteadores 2 e 3. Fluxos 1 Roteador de Fronteira INGRESSO 2 Roteador Interno 3 Roteador Interno 5 4 Roteador de Fronteira EGRESSO Roteador de Fronteira Figura 1. Exemplo de Domínio DiffServ 2.1. PHBs Esta seção apresenta os PHBs Encaminhamento Expresso (EF Expedited Forwarding) e Encaminhamento Assegurado (PHB AF Assured Forwarding) Encaminhamento Expresso (EF) O PHB EF fornece garantias mais rígidas de QoS para as aplicações muito sensíveis a variações de características temporais da rede. Ele pode ser utilizado para implementar um serviço com pouco atraso, pouca variação do atraso e taxa de bits garantida.

4 O serviço oferecido com o PHB EF é conhecido como serviço Premium. Para este tipo de serviço, os pacotes que não estiverem dentro do perfil contratado, são descartados diretamente, não passando por uma reclassificação [Jacobson 1999]. O serviço Premium é mais indicado para tráfego de aplicações multimídia e de tempo real em geral. É importante notar que os roteadores de ingresso do domínio DS devem condicionar o tráfego EF de forma a assegurar que a sua taxa de chegada aos roteadores interiores esteja em conformidade com a taxa contratada. Este policiamento protege o domínio DS de um uso abusivo. Isso obriga as fontes de tráfego EF a suavizar a carga transmitida se desejarem evitar o condicionamento de seus pacotes no ingresso do domínio DS. Encaminhamento Assegurado (AF) O PHB AF [Heinanen 1999] é indicado para aplicações que requerem uma melhor confiabilidade que a oferecida pelo serviço melhor esforço (BE Best Effort). PHB AF na realidade fornece quatro classes com diferentes níveis de garantias de encaminhamento de pacotes IP. Estas classes são referenciadas como AFnm, onde n é o número da classe (1 a 4) e m é o valor de precedência de descarte (1 a 3). Assim, o AF define um grupo de PHBs onde são definidas até 12 níveis de serviços AF distintos. Nesse artigo chamaremos essas classes de AF1, AF2, AF3 e AF4. No caso de congestionamento dentro de uma classe AF, a precedência de descarte de um pacote determina a importância relativa daquele pacote. Um nó DS em situação de congestionamento, preferencialmente descarta pacotes com um maior valor de precedência de descarte, ao mesmo tempo em que evita descartar pacotes com um valor de precedência de descarte menor. O serviço oferecido com o PHB AF é conhecido como serviço Assegurado. Esse modelo de serviço, ao invés de fornecer uma garantia rígida, fornece uma melhor qualidade de transmissão que será obtida por um determinado tráfego quando existirem momentos de congestionamento Controlador de Tráfego TC Os kernels mais recentes do Linux oferecem uma grande variedade de funções de controle de tráfego, as quais podem ser combinadas de uma forma modular. Esta subseção descreve o TC (Traffic Controller) [Almesberger 1999, Radhakrishnan 1999] para dar suporte a Serviços Diferenciados baseado nos elementos de controle de tráfego existentes, além dos novos componentes implementados para esse fim. O TC é um programa ao nível do usuário que pode ser usado para criação de filas e associação destas aos dispositivos de saída de rede. Ele é usado para inicializar vários parâmetros de fila e associar classes com esses parâmetros. O TC pode ser usado também para inicializar filtros com base numa tabela de roteamento, classificadores u32, tcindex e RSVP [Almesberger 1999, Radhakrishnan 1999]. O código do controle de tráfego no kernel do Linux consiste, principalmente, dos seguintes componentes: fila, classes (associada a uma disciplina de fila), filtros e policiadores.

5 A figura 2 apresenta como o kernel processa os dados recebidos da rede e como ele gera novos dados para serem enviados para a rede. Camadas superiores (TCP, UDP,...) Controle de Tráfego Pacotes De-multiplexador na entrada Encaminhamento Enfileiramento na Saída Pacotes Figura 2. Controle de Tráfego no Linux O componente Encaminhamento inclui a escolha da interface de saída, a escolha do próximo hop, encapsulamento, etc. Após esta operação, os pacotes são enfileirados na respectiva interface de saída. É neste ponto que o TC entra em ação. Ele deve, entre outros, decidir se os pacotes são enfileirados ou descartados (por exemplo, se a fila tem preestabelecido algum limite de tamanho, ou se o tráfego excede algum limite de taxa). O TC deve determinar a ordem em que os pacotes são enviados (por exemplo para obter prioridade para certos fluxos), temporizar o envio dos pacotes (por exemplo para limitar a taxa de tráfego fora do limite), etc. 3. Voz sobre IP VoIP (Voice over IP) é uma referência geral para a implementação de telefonia em redes IP. Este tipo de aplicação é sensível a vários parâmetros de qualidade em nível de rede, que influenciam na qualidade da voz percebida pelos seus usuários. Esta seção caracteriza o tráfego gerado pelas aplicações de VoIP e apresenta a forma de quantificar a qualidade de voz percebida pelo usuário Tráfego gerado pela VoIP As características do tráfego de voz gerado são dependentes principalmente do codificador utilizado. Existem várias opções de codificação de voz, sendo que as mais utilizadas são: G.711 [G ], que define um codec de alta velocidade para conversão do que gera um fluxo constante a uma taxa de 64 Kbps (quando não utilizada a supressão de silêncio). Sua vantagem é sua velocidade, reduzindo o atraso fim a fim dos pacotes de voz, e sua desvantagem é o maior uso de mais largura de banda. G [G ] e G.729 [G ], que definem codecs de baixa velocidade, sendo que o G tem duas opções de taxa de bits, 5.3 e 6.4 Kbps e o G.729 gera uma taxa de 8Kbps. Em ambos, a taxa de bits é variável. Esta baixa taxa de bits gerada é a vantagem do uso destes codecs. A desvantagem é o aumento no atraso fim-a-fim do fluxo de voz, devido à complexidade computacional do algoritmo de compressão. Este artigo considera apenas o codec G.711. Conforme já apresentado, as aplicações de voz, usando o codec G.711, geram uma vazão em nível de aplicação a taxa de bits constante de 64 kbps. Até alcançar o nível de rede, esta taxa sofrerá várias sobrecargas de protocolos. Considerando as aplicações de voz que seguem a recomendação H.323 [H ], amostras de áudio, em nível de aplicação, deve ser encapsulada em pacotes RTP

6 (Real Time Protocol) [Schulzrinne 1996], em seguida, encapsulada no pacote UDP e após, IP. A sobrecarga total de protocolos depende do tamanho do payload (área que contém os dados de voz) adotado no RTP. O valor usual do payload de voz em um pacote RTP é de 20 ms [Walker e Hicks 2002], ou seja, cada pacote IP transporta 20 ms de voz que corresponde a 160 bytes. Com isto, a cada 20ms será gerado um pacote IP com o tamanho de payload de 160 bytes. Assim, conforme mostra a figura 3, considerando a sobrecarga dos protocolos RTP (12 bytes), UDP (8 bytes) e IP (20 bytes), o tamanho do pacote IP gerado por uma aplicação de voz G.711 será de 200 bytes, e a taxa gerada, por fluxo, será de 80 Kbps. Cabeçalho IP 20 bytes Cabeçalho UDP 8 bytes Cabeçalho RTP 12 bytes Payload (Dados) 160 bytes Figura 3 Pacote IP gerado por uma aplicação de voz G Parâmetro de Qualidade para uma Chamada de Voz Como a maior parte das aplicações multimídia, a qualidade de voz obtida na VoIP é muito sensível ao atraso fim-a-fim, variação de atraso de chegada de pacotes e perda de pacotes. O critério mais amplamente aceito para qualidade de chamada de voz é o MOS (Mean Option Score) [P c], [Walker e Hicks2002]. O E-Model [G ] é um modelo computacional que avalia os efeitos combinados de variações em diversos parâmetros de transmissão, que afetam a qualidade conversacional na telefonia. O E-Model resulta em um número chamado de fator R, derivado de atrasos e fatores de deterioração causados pelos equipamentos. O fator R medido pode ser mapeado para um MOS estimado. O fator R varia de 100 (excelente) até 0 (pobre) e, o MOS varia de 5 a 1. Um MOS estimado pode ser diretamente calculado do fator R do E-Model, conforme demonstra a figura 4. Nesta figura, valores do fator R do E-Model são mostrados à esquerda, com os valores correspondentes ao MOS à direita. O nível de satisfação dos ouvintes é apresentado na coluna do meio. É recomendado o uso do E-Model para avaliar a qualidade da chamada VoIP [Walker e Hicks 2002]. R Satisfação do Usuário Muito Satisfeito Satisfeito Alguns Usuários Insatisfeitos Muitos Usuários Insatisfeitos Quase Todos os Usuários Insatisfeitos Não Recomendado MOS 4,4 4,3 4,0 3,5 3,1 2,5 1,0 Figura 4 Medida de Qualidade da Chamada Telefônica

7 Segundo [Walker e Hicks 2002], as recomendações sobre atraso e perda para que uma rede possibilite uma boa qualidade da chamada VoIP são: atraso fim a fim deve ser menor que 150ms; limite máximo de 50ms para a variação de atraso; taxa de perda limitada a 3% (mas recomendável é ser inferior a 0,50%). O não respeito destes limites gera degradações da qualidade de voz perceptíveis ao usuário. 4. Técnica de avaliação da qualidade de voz em redes IP Esta seção apresenta a técnica proposta de avaliação da qualidade de voz oferecida por uma rede IP, com ou sem DiffServ. Essa avaliação é feita sobre os parâmetros de rede que possuem grande influência na qualidade da fala percebida pelo usuário, que são o atraso fima-fim, a taxa de perdas e a variação de atraso. A partir da medição destes parâmetros é possível verificar se a rede é recomendada ou não para VoIP e o nível de qualidade máxima que a rede pode oferecer à VoIP. [Ferguson 1999] define dois métodos básicos para medir o tráfego com QoS em uma rede: intrusivo e não intrusivo. O primeiro se refere à injeção controlada de pacotes na rede e subseqüentemente da coleta destes pacotes. Já o segundo está relacionado com a medição do comportamento da rede através da observação da taxa de chegada de pacotes em um sistema final. A técnica proposta segue o modelo intrusivo. Nesse artigo, os testes foram realizados considerando o tráfego do tipo intrusivo, através de uma ferramenta constituída de dois agentes: gerador e coletor. Este localizado na máquina de destino e aquele na máquina de origem do tráfego. A seguir serão apresentadas a caracterização do tráfego de teste, as métricas de qualidade e a aferição da qualidade consideradas na técnica de avaliação proposta por esse trabalho. 4.1 Caracterização de Tráfego de Teste Para a definição do tráfego de teste é necessário definir a quantidade de tráfego gerado pelas aplicações VoIP da empresa. Para tal, dois fatores devem ser determinados nesta fase: o codec utilizado e o número de chamadas simultâneas. Para a realização dos testes, o tráfego sintetizado, simulando uma chamada de voz, deve ter a mesma característica de uma chamada real. Portanto, neste momento deve-se identificar o codec a ser utilizado e o atraso do pacote de voz. Esta técnica adota como codec o G.711 sem supressão de silêncio. Ele foi adotado para testes por se tratar do pior caso em termos da taxa de bits gerada. Além disso, ele é muito usado para reduzir retardos de codificação/decodificação. Portanto, para os testes, cada fluxo de voz é caracterizado por um tráfego do tipo CBR (Constant Bit Rate), em uma taxa de 80 Kbps e cujo tamanho dos pacotes é igual a 200 bytes (como explicado na seção 3.1). Para determinar o tráfego de voz a ser gerado, além do codec, deve-se determinar o número de chamadas simultâneas. Como o número de chamadas simultâneas se altera durante um período normal em uma empresa, novamente é recomendado o uso do pior caso, ou seja, o número máximo de chamadas simultâneas que podem ocorrer. Este número será notado por NCS (Número de Chamadas Simultâneas). Portanto, o tráfego de voz sintetizado para

8 esse teste corresponde a NCS*80 kbps. Assim, é possível projetar a largura de banda necessária para o tráfego VoIP, dependendo de quantas ligações simultâneas se queira disponibilizar. Note que aqui foi considerado um número de chamadas simultâneas constante durante todo o teste por motivo de simplificação do gerador de testes e da análise. Em um ambiente real, o número de chamadas e a duração das chamadas variam com o tempo. Portanto, apesar de cada chamada de voz gerar um fluxo do tipo CBR, a agregação destes fluxos seria VBR. Um modelo de tráfego de voz mais realista e o impacto na análise dos resultados está sendo investigado. 4.2 Métrica de Qualidade Gerados os tráfegos de teste simulando conversações de voz, é necessário agora aferir a qualidade de voz obtida, que neste artigo considera apenas a influência da rede. Para tal, é necessário definir os níveis de qualidade de voz e os correspondentes valores limites dos parâmetros de desempenho de rede. Na técnica proposta, as seguintes métricas são consideradas para medir a qualidade de voz: Vazão: taxa de transmissão efetuada em bits por segundo (bps); Atraso por pacote: tempo que um pacote leva desde a origem até o destino; Variação no atraso: É a variação (diferença) do atraso por pacote entre dois pacotes subjacentes. Por meio dessa métrica, consegue-se analisar quão constante é o roteamento de pacotes processado por salto (hop). Taxa de perda de pacotes: quantidade de pacotes que foram descartados por fluxo numa transmissão de dados (voz). A figura 5, derivada de [ETSI 1999], define os níveis de qualidade de voz com base apenas nos parâmetros de desempenho no nível de rede. Note que além destes, outros componentes do equipamento terminal (computadores dos usuários finais) influenciam na qualidade de voz percebida. Este artigo considera apenas a influência da rede na qualidade final da voz. Categorias de Qualidade Melhor Alto Médio Baixo Atraso fim a fim < 150 ms < 250 ms < 350 ms < 450 ms Média das perdas de pacotes 00% 03% 15% 25% Variação do atraso 0 ms 75 ms 125 ms 225 ms Satisfação do Usuário Muito Satisfeito Satisfeito Alguns Usuários Insatisfeitos Muitos Usuários Insatisfeitos Figura 5 Parâmetros de Referência de Rede 4.3 Aferição da Qualidade Existem duas formas para aferição dos parâmetros de desempenho citados. Um onde o tráfego é unidirecional, isto é, os agentes geradores e coletores se posicionam em máquinas distintas (origem e destino, respectivamente). Nesse caso, é necessária a sincronização rígida dos relógios das máquinas envolvidas nas experimentações. A segunda forma é quando o

9 tráfego é gerado e coletado numa mesma máquina. Nesse caso, onde não é necessária a sincronização dos relógios, é preciso mais um agente o qual é responsável por refletir os dados na máquina destino. Para a medição dos parâmetros de desempenho, foi escolhida a ferramenta RUDE & CRUDE [Laine 2002] que trabalha com a forma unidirecional porque esta é mais flexível e precisa. O RUDE & CRUDE é uma ferramenta para geração e medição de tráfego em ambiente de alto desempenho. Essa ferramenta é constituída por dois processos: o RUDE (Real-time UDP Data Emitter) e o CRUDE (Collector for RUDE) os quais são o gerador e o coletor de dados, respectivamente. A escolha do RUDE & CRUDE se deve a simplicidade e a flexibilidade dessa ferramenta associados a sua alta precisão para os testes. Outra vantagem também observada no RUDE & CRUDE é o armazenamento do tráfego de rede gerado sem decodificá-lo, de forma a não gerar carga de processamento na máquina receptora. Para evitar que a escrita dos pacotes em disco influencie nos resultados dos experimentos, foi utilizado um ramdisk na máquina destino para armazenamento dos mesmos. Como esses processos estão em máquinas distintas durante os testes (gerador no emissor e coletor no receptor), foi necessário sincronizar os relógios das maquinas envolvidas no experimento. Para isso foi utilizada a ferramenta Chrony [Curnow 2002] para sincronizar o relógio entre computadores utilizando o protocolo NTP. Note que a aferição da qualidade não pode ser feita predefinindo um dia da semana, duração e um horário das chamadas, pois o estado da rede se altera no decorrer do período. Portanto, é necessário realizar várias rodadas de teste durante todo o período de interesse de realização (8 horas ou 24 horas). O intervalo entre as rodadas deve ser de quinze, trinta ou sessenta minutos, dependendo da granularidade desejada. Isso permite avaliar a situação da rede em vários períodos, já que a rede não possui um comportamento uniforme durante todo o tempo. 5. Avaliação do tráfego de VoIP em Redes com DiffServ Com base nessa técnica proposta para avaliação da qualidade de voz oferecida por uma rede, esta seção apresenta uma análise do comportamento do tráfego de voz quando mapeado em diferentes níveis de qualidade oferecidos pela arquitetura DiffServ. Para tal, são realizados experimentos utilizando um ambiente de testes real com roteadores implementados na forma de plataformas Linux. O comportamento do tráfego de voz é avaliado para verificar o impacto dos mecanismos da arquitetura de Serviços Diferenciados no atendimento dos requisitos da VoIP. Além da apresentação desta análise, esta seção tem por objetivo ilustrar a aplicação da técnica proposta Descrição do Ambiente de Testes A figura 6 apresenta o ambiente de testes utilizado. Ele é formado por computadores com Linux. A versão do kernel utilizada é a , que traz em sua forma nativa os módulos relacionados a QoS. Os Geradores 1 e 2 geram o tráfego de teste e o Gerador 3 gera tráfego de fundo apenas para que se tenha uma maior perturbação do ambiente. Todo o tráfego tem

10 como destino o Receptor, é responsável por coletar e fazer a estatística das informações recebidas. Como o sistema Linux é de propósito geral, ele não é uma opção ideal para servir como roteador e ao mesmo tempo como estação de trabalho para uso geral. Para evitar esses problemas, foram adotadas algumas políticas para inibir grande parte dos serviços não necessários do Linux, uma configuração enxuta para deixá-lo apenas como roteador. A, B, D são roteadores de borda, responsáveis pela classificação e marcação dos pacotes. C e E são roteadores de núcleo, responsáveis pelo encaminhamento dos pacotes dando-lhes um PHB adequado. Todos os enlaces são de 10Mbps full-duplex. Hub Gerador 1 A Domínio Diffserv C E F Receptor Gerador 2 B D Link = 10Mbps Gerador 3 Figura 6 Ambiente de testes O ambiente de testes definido representa a comunicação de uma empresa Matriz (Receptor) com duas filiais (Gerador 1 e Gerador 2). Nessa comunicação, várias chamadas de voz são realizadas simultaneamente, sendo algumas dessas chamadas usuárias de serviços com QoS e outras de serviços do modelo melhor esforço. Foram implementados como parte deste trabalho scripts que executam o TC (Traffic Controller) (seção 2.2) com a finalidade de criar nas interfaces de rede das máquinas as disciplinas de fila, as classes e os filtros. Esses scripts são usados pelo administrador de uma rede para configurar os serviços diferenciados num roteador Linux. Nas máquinas A e B, os scripts implementados tem a função de torná-las roteador de borda no domínio DiffServ. Nessas máquinas ocorre a marcação (remarcação) dos pacotes como sendo pertencentes ao tráfego EF AF ou BE. Nelas acontece também o primeiro policiamento do tráfego. Nas máquinas C e E implementaram-se scripts capazes de, por meio do programa TC, caracterizá-las como roteador interior dentro desse ambiente. Nas interfaces de rede dessas máquinas, ocorre simplesmente o policiamento do tráfego através da análise do campo DS no cabeçalho dos pacotes. Isso cumpre uma das regras da abordagem DiffServ a qual transfere todo o processamento mais pesado, com relação a marcação por exemplo, para as bordas do domínio DiffServ.

11 O ambiente de testes adotado é muito simples, mas suficiente para a análise dos parâmetros de QoS (vazão, taxa de perda, atraso e variação de atraso dos pacotes), uma vez que ele representa um domínio DiffServ. Entretanto, poder-se-ia ter uma maior quantidade de nós enriquecendo assim, tal ambiente Tráfego de Teste Como apresentado, o ambiente de teste tenta simular o uso de um domínio DiffServ para comunicação de VoIP entre duas filias (Gerador 1 e Gerador 2) de uma corporação e sua matriz (Receptor). Conforme apresentado na seção 4.1, cada fluxo de voz gera um tráfego CBR de 80 kbps com pacotes de 200 bytes. Para este ensaio, foi considerado um número de chamadas simultâneas igual a 20. Portanto, tanto Gerador 1 quanto Gerador 2 transmitiam um fluxo CBR de 1,6 Mbps para a máquina Receptor. Para avaliar o impacto na qualidade oferecida pelas diferentes classes de serviços do DiffServ. Os testes tiveram seis momentos, em cada momento o tráfego de voz foi classificado em um diferente PHB (EF, AF1, AF2, AF3, AF4 e BE). Para cada ensaio, o tempo de duração considerado foi de 30 segundos. Este tempo não corresponde a duração das chamadas, mas do intervalo de tempo na qual os parâmetros de desempenho foram medidos. Para cada um dos seis momentos, foram gerados como tráfego de fundo uma taxa de dados suficientemente grande para saturar os enlaces. Faziam parte desse tráfego de fundo, pacotes classificados como EF, AF e melhor esforço. Pois, com um tráfego totalmente heterogêneo assim, pode-se ter um ambiente mais próximo do real. O tráfego de fundo, como não representava voz, teve tamanhos de pacotes variados e era do tipo CBR. Vale salientar também que foram realizados vários experimentos com uma taxa de transmissão abaixo da capacidade do enlace. Nesse caso, o comportamento para todos os modelos de serviço, seja melhor esforço ou não, foi muito semelhante. 5.3 Aferição da Qualidade Para facilitar a análise comparativa dos seis momentos de teste, estes foram colocados num mesmo gráfico para cada parâmetro de QoS (perdas, atraso, variação no atraso, vazão). Foi considerado para essa análise dos resultados, o valor médio desses parâmetros para todas as chamadas de voz de apenas uma das filiais. Isso pois após uma análise individual das chamadas de voz para as duas filiais, notou-se que os valores para cada classe de serviço estavam bastante próximos. A tabela 1 apresenta as taxas de perdas para pacotes de voz, onde foi considerado um intervalo de confiança IC 95%. São apresentados aqui apenas os resultados de apenas uma das filiais, pois os resultados para as duas são bastante semelhantes. Nota-se que o tráfego mais prejudicado quanto a perdas foi o tráfego melhor esforço - BE. Seguido pelo tráfego AF4 o qual tem a menor prioridade de encaminhamento de sua fila. Em contrapartida, quando os enlaces estavam completamente saturados, o tráfego de voz transmitido usando o serviço EF, teve um descarte muito pequeno de 0,52%. Esse índice, segundo a tabela de parâmetros de referência de redes apresentado na figura 5, enquadra o serviço EF na categoria de Melhor Qualidade. Nota-se também, segundo a mesma tabela de referência para

12 VoIP, que para as classes AF1 e AF2 o nível de qualidade ficou enquadrado como médio. Enquanto isso, AF3 e AF4 associados ao BE (Best Effort), qualidade baixa. Classe Número Pacotes Tabela 1. Perdas de Pacotes na Transmissão Número de Pacotes Perdidos Taxa de Perdas de pacotes (%) Desvio Padrão IC 95% EF ,52 2,6 [3,91 ; 5,82] AF ,1 32,0 [143,6 ; 167,1] AF ,5 38,2 [176,4 ; 204,4] AF ,9 45,9 [211,6 ; 245,3] AF ,4 54,9 [243,1 ; 283,4] BE ,2 61,9 [292,0 ; 337,4] A tabela 2 apresenta os resultados dos ensaios referentes ao atraso médio por pacote fim a fim. Nesta tabela pode-se observar dois dados importantes. Primeiro um bom desempenho dos dados que usaram o serviço EF, quando esses tiveram um atraso médio por pacote de 20,4 ms. E segundo, o pior desempenho ficou por conta do trafego classificado como melhor esforço. Mas, mesmo assim, o maior valor de atraso para esse tráfego foi de 72,9 ms. O que ainda é totalmente aceitável para aplicação de voz. Uma explicação para esses valores aceitáveis é o fato da topologia ou ambiente de teste considerado nesse trabalho ser constituído por um número ainda restrito de roteadores. Nesta, nota-se também que os valores médios de atraso dos tráfegos AF são muito próximos. Tabela 2. Atraso Médio por Pacotes Classe Média de atraso Desvio Padrão IC 95% EF 20,4 ms 0,9 [20,4 ; 20,5] AF1 62,9 ms 3,4 [62,8 ; 62,9] AF2 63,2 ms 4,2 [63,1 ; 63,2] AF3 63,3 ms 3,9 [63,2 ; 63,3] AF4 63,5 ms 3,7 [63,4 ; 63,5] BE 72,9 ms 4,7 [72,9 ; 73,0] A tabela 3 apresenta os resultados dos experimentos relacionados à variação do atraso por pacote. A variação do atraso foi muito pequena. Isso é justificado pelo fato do ambiente de teste possuir um número pequeno de roteadores, pois assim por mais que a rede estivesse saturada durante os experimentos, os pacotes chegavam ao destino com os atrasos semelhantes. Isso para fluxos pertencentes a uma mesma classe. Tabela 3. Variação Média de Atraso de Pacotes Classe Variação Média de Atraso Desvio Padrão IC 95% EF 0,54 ms 0,44 [0,53 ; 0,54 ] AF1 0,75 ms 0,51 [0,75 ; 0,76 ] AF2 0,81 ms 0,58 [0,80 ; 0,81 ] AF3 0,84 ms 0,63 [0,83 ; 0,85 ] AF4 0,93 ms 0,72 [0,92 ; 0,94 ] BE 0,49 ms 0,37 [0,49 ; 0,50 ] Apesar das diferenças de variação de atraso serem pequenas, o serviço que teve melhor desempenho foi o serviço melhor esforço, seguido pelo tráfego EF, o qual obteve um

13 bom desempenho também. Isso é bastante surpreendente tendo em vista que o serviço melhor esforço é o classificado com a menor prioridade de encaminhamento. Como os experimentos foram realizados de forma exaustiva obtendo sempre esse resultado, a análise para o mesmo foi enquadrada como objeto de estudos futuros. Por fim, a tabela 4 mostra os valores referentes à vazão obtida pelos fluxos de voz em cada momento de teste. Vale ressaltar novamente que para cada ensaio realizado, a vazão de geração equivale a 1.6 Mbps (20 chamadas de voz, tendo 80Kbps cada) para cada filial e que os gráficos aqui mostrados apresentam os resultados de apenas uma filial. A maior vazão conseguida foi do tráfego de voz que utilizou o serviço EF. E, contrastando com esse valor, vem o trafego melhor esforço o qual obteve uma vazão média de 1,04 Mbps. Também as classes AF tiveram a vazão de entrega um pouco abaixo da vazão gerada. Isso pode causar uma perturbação ou ruído durante a transmissão, vindo a afetar a aplicação de voz. 6. Conclusão Tabela 4. Vazão Média de Pacotes Classe Vazão Média Desvio Padrão IC - 95% EF 1,54 Mbps 0,28 [0,4;1,6] AF1 1,29 Mbps 0,24 [1,2;1,3] AF2 1,22 Mbps 0,23 [1,1;1,3] AF3 1,17 Mbps 0,21 [1,0;1,2] AF4 1,12 Mbps 0,21 [1,0;1,2] BE 1,04 Mbps 0,19 [0,9;1,1] Este artigo teve como objetivo propor uma técnica de avaliação da qualidade de voz oferecida por uma rede IP, com DiffServ, medindo a influência das capacidades da rede no nível da qualidade de voz percebida pelos usuários. Com base nessa técnica, foi investigado o comportamento do tráfego de voz quando mapeado em diferentes níveis de qualidade oferecidos pela arquitetura DiffServ. Para isso, foi definido, implementado e utilizado um ambiente de teste para aplicações Voz sobre IP. Um dos pontos altos desse artigo é justamente apresentar resultados provenientes de uma rede constituída de roteadores reais, com uma plataforma aberta, no caso, Linux. Os experimentos foram feitos considerando os PHBs EF e AF somados ao modelo de serviço melhor esforço. Os resultados mostraram que esse ambiente, apesar de simples, é propício para aplicações de mídias contínuas, mais especificamente voz, tendo seu melhor desempenho oferecido pelo PHB EF. Percebeu-se também que esse tipo de aplicação pode usar o serviço oferecido pelas classes AF, conseguindo-se uma garantia não tão rígida, mas, melhor que o modelo melhor esforço. A vantagem das classes AF é que estas podem ser implementadas e vendidas por preços mais acessíveis. Diferentemente da classe de serviço EF a qual oferece um serviço com alta qualidade, mas, possui um custo elevado. O modelo atual de melhor esforço possui um custo baixo em relação aos outros modelos, porém é inviável para aplicações de VoIP. Para um ambiente de teste com um número maior de hops, por exemplo, a Internet, acreditase que o modelo de melhor esforço apresentará deficiências no atraso fim a fim, na variação do atraso dos pacotes, vazão e no índice de perdas.

14 Apesar da técnica proposta ter sido aplicada em uma rede IP com suporte a DiffServ, a metodologia pode ser aplicada em redes oferecendo serviços do tipo melhor esforço. Uma das limitações da técnica proposta é considerar apenas o tráfego de voz gerado pelo codec G.711. Como perspectiva futura, espera-se considerar, além deste codec, outros que geram tráfego a taxa de bits variável, como o G e G.728. Referências Albrecht, M., Koster, M., Martini, Peter., Frank, M., (2000). End-to-end QoS Management for Delay-sensitive Scalable Multimedia Streams over DiffServ, Institute of Computer Science IV, University of Bonn, Germany. Almesberger, W., Saim, J. H., Kuznetsov, A. (1999) Differentiated Services on Linux Blake, S., Black, D. L., Carlson, M., Davies, E., Wang, Z. e Weiss, W. (1998). An architecture for differentiated services, Internet RFC Curnow, R. (2002) Chrony. Disponível em http: //chrony.sunsite.dk, acessado em Dezembro de Dovrolis, C., Ramanathan, P. (1999) A case for relative differentiation services and the proportional differentiation model, IEEE Network, vol. 13, no. 5. ETSI TR V2.1.1 ( ) Dezembro. Ferguson, P. and Huston, G. (1999) Quality of Service: delivering QoS on the Internet and Corporate Networks Wiley Computer Publishing Fonseca, J. L., Stanton, M. A. (2001) A Methodology for Performance Analysis of Real- Time Continuous Media Applications. G.107, ITU-T Recommendation (1998), The E-Model, a computational model for use in transmission planning.. G.711, ITU-T Recommendation (1988): Pulse code modulation (PCM) of voice frequencies. G.723.1, ITU-T Recommendation (1996): Dual rate speech coder for multimedia communications transmitting at 5.3 and 6.4 kbit/s. G.729, ITU-T Recommendation (1996): Coding of speech at 8 kbit/s using conjugatestructure-algebraic-code-excited linear prediction (CS-ACELP). H.323, ITU-T Recommendation (1998): Packet-based multimedia communications systems. Heinanen, J. e Guerin, R. (1999). A single rate three color marker, Internet Draft draft heinanen diffserv srtcm 01. Heinanen, J., Baker, F., Weiss, W., Wroclawski, J. (1999), Assured forwarding PHB group, Internet RFC 2597.

15 Jacobson, V., Nichols, K. e Poduri, K. (1999). An expledited forwarding phb, Internet RFC Laine, J., Saaristo, S., and Prior, R. (2002) Rude & crude, Dezembro. Naser, H., Leon-Garcia, A., Aboul-Magd, O. (1998) Voice over differentiated services, Internet Draft. Oliveira, R. D. V., Farines, J. M. (2001), Serviços Diferenciados em redes IP: medições e testes para aplicações envolvendo mídias contínuas, Dissertação de Mestrado, DAS/UFSC. P.800, ITU-T Recommendation, Methods for subjective determination of transmission quality. Rezende, J. F. (1999), Assured service evaluation, in Proceedings of the IEEE - Global Telecommunications Conference - GLOBECOM'99, vol. 1, Rio de Janeiro, Brasil, pp Schulzrinne,H., Casner, S., Frederick, R., Jacobson, V. (1996), RTP: A Transport Protocol for Real-Time Applications, Internet RFC Semret, N., Liao, R. R. F., Campbell, A. T., Lazar, A. A. (2000), Peering and provisioning of differentiated Internet services, in Proceedings of the IEEE INFOCOM'2000. Sitolino, C. L., Rochol, J. (2001), Voz sobre IP (VoIP): Um Estudo Experimental. XXVII Conferência Latino-Americana de Informática - CLEI2001, 2001, Mérida - Venezuela: Universidade de Los Andes, v.1. UCER (2003): Uso Controlado e Eficiente de Recursos em Redes IP usando a Tecnologia MPLS, NURCAD. Disponível em acessado em Maio de Walker, J. Q.; Hicks, J. T. (2002): The Essential Guide to VoIP Implementation and Management, NeqIQ Corporation,