QoS em um Cenário VoIP - Utilizando o Agendador HTB

Transcrição

1 ISSN T.I.S, São Carlos, v. 1, n. 2, p , set-dez 2012 Tecnologias, Infraestrutura e Software QoS em um Cenário VoIP - Utilizando o Agendador HTB Abstract: VoIP systems arise with the convergence of telecommunications networks, forcing the networks to handle IP traffic in real time. A packet scheduler may then be employed to prioritize traffic as needed to guarantee the Quality of Service (QoS) for computer networks. Hierarchical Token Bucket (HTB) is a mature scheduler present in different operating systems. This paper presents the features, components and details of implementing HTB in a Linux system. We also show with analysis and tests that HTB is capable of prioritizing IP packets in a congested VoIP environment, avoiding degradation in audio transfer and thereby providing acceptable quality in VoIP calls. Keywords: VoIP, QoS, packet scheduler, HTB. Resumo: Os sistemas VoIP surgem com a convergência das redes de telecomunicações, obrigando as redes IP a tratar do tráfego de tempo real. Um agendador de pacotes, priorizando o tráfego conforme a necessidade, garante a Qualidade de Serviço (QoS) para redes de computadores. O Hierarchical Token Bucket (HTB) é um agendador maduro presente em diferentes sistemas operacionais. Este trabalho apresenta as características, componentes e implementação do HTB, utilizando-se Linux. Este trabalho também evidencia, por meio de análises e testes, que HTB é capaz de priorizar pacotes IP em um ambiente VoIP congestionado, evitando degradação na transferência de áudio e propiciando qualidade satisfatória nas chamadas VoIP. Palavras-Chave: VoIP, QoS, agendador de pacotes, HTB I. INTRODUÇÃO No início das telecomunicações, havia no geral duas redes separadas, um para voz e outra para dados. Cada rede teve início para atender a demanda de transporte de um tipo específico de informação. A rede telefônica, que teve início com a invenção de Alexander Graham Bell cerca de cem anos atrás, foi projetada apenas para o transporte de voz. A rede IP, por sua vez, foi concebida para transporte de dados de maneira mais simples possível, que tinha como função apenas encaminhar pacotes de um nó para outro. Nesta rede, os pacotes eram tratados de modo igualitário, armazenados em um buffer interno e transmitido utilizando uma fila do tipo FIFO (First in, First out). Ao contrário da voz da rede de telefonia convencional, os dados eram e continuam sendo, na maior parte, um serviço de tempo não real (PARK, 2005). O cenário acima foi utilizado por vários anos, funcionando de forma aceitável. Porém em meados da década de 90, idealizando a criação de uma única rede para transportar voz e dados e motivados pela economia obtida pelo compartilhamento de recursos, as duas redes começaram a se fundir. Na mesma década, teve o surgimento do primeiro software comercial voltado para Voz sobre IP (VoIP, do inglês, Voice over IP) entre computadores pessoais, o Internet Phone (da VocalTec Communications). Devido a vários problemas existentes, o aplicativo não fornecia qualidade de áudio desejada, porém a tecnologia havia saído do papel. Em 1998 algumas companhias já eram capazes de fornecer serviços de VoIP interligados a telefonia convencional e com qualidade aceitável (COLCHER, 2005). Devido à convergência entre as redes e a necessidade de tráfego em tempo real, o método de entrega por melhor esforço fornecido pelas redes IP já não era o suficiente para suprir os requisitos de qualidade (KAMIENSKI; SADOK, 2000). Com intuito de solucionar este problema de nível técnico, foi utilizado a Qualidade de Serviço (QoS, do inglês, Quality of Service) para redes de computadores (COLCHER, 2005). Para implementação de QoS em uma rede de computadores é necessário utilizar um agendador de pacotes. O agendador é o responsável pela organização dos pacotes em Departamento de Computação - Universidade Federal de São Carlos (UFSCar) Caixa Postal São Carlos SP Brasil Autor para correspondência: thanatosgnu@gmail.com, jander@dc.ufscar.br

2 QoS em um Cenário VoIP Utilizando o Agendador HTB uma fila, tando de entrada como saída de dados. Devido ao importante papel que o agendador exerce dentro da QoS, estudá-lo é fundamental. Seus campos e parâmetros devem ser compreendidos para a correta configuração de um ambiente QoS na rede. Neste trabalho foi estudado um agendador denominado Hierarchical Token Bucket (HTB) que está presente nos sistemas operacionais Linux e Unix. Motivados pela crescente demanda por serviços multimídia e sendo o VoIP um dos mais conhecidos e discutidos acrônimos do mercado de comunicação da atualidade (COLCHER, 2005), foi utilizado um cenário VoIP para validar a eficiência da QoS utilizando o agendador de pacotes HTB. Devido à sua sensibilidade a atrasos e perdas de pacotes, faz com que o VoIP seja um dos principais serviços que necessitam de QoS para operar de forma aceitável. Para este trabalho, utilizamos um roteador que possui um firmware modificado. O sistema operacional (SO) base do firmware presente no roteador é uma versão compilada do Linux voltada para equipamentos embarcados. O Linux é um SO flexível, gratuito, de código fonte aberto, roda em várias plataformas diferentes e possui boa compatibilidade com softwares do SO Unix que é um SO presente em muitos servidores. O HTB, agendador estudado neste trabalho, também faz parte na compilação padrão deste firmware. Devido a estes motivos, este roteador foi escolhido. Este artigo está organizado em seções. Inicialmente, na seção II é apresentado uma visão sobre qualidade de serviço e os mecanismos Integrated Services (IntServ) e Differentiated Services (Diffserv). As características sobre a tecnologia de voz sobre IP (VoIP) são apresentadas na seção III. Na seção IV são apresentadas as características e componentes do utilitário TC. O agendado HTB, tema deste trabalho, é abordado na seção V. Na seção VI, estão presentes todos os testes realizados e, em sequência, na seção VII estão descritas os resultados obtidos com este trabalho. Finalizamos o trabalho na seção VIII, com as conclusões obtidas. II. QUALIDADE DE SERVIÇO (QOS) De acordo com a ABNT (2000), qualidade é o grau no qual um conjunto de características inerentes satisfaz a requisitos, podendo ser classificada como má, boa ou excelente. Segundo Evans e Filsfils (2007), serviço no âmbito de redes IP, quando voltado para aspectos de transmissão de dados, pode ser definido como a descrição do tratamento global do tráfego de um cliente em um domínio particular, que só é útil caso satisfaça os requisitos da aplicação e do usuário final. O termo Qualidade de Serviço é difícil de ser definido. Seu significado pode mudar dependendo do campo de aplicação e do âmbito científico (MARCHESE, 2007). Neste trabalho limitamos as explicações de QoS dentro do contexto de redes de computadores e seu significado possui variações (EVANS; FILSFILS, 2007), na qual apresentamos a seguir: Segundo a European Telecommunications Standards Institute (IETF, 2003), QoS é a habilidade de segmentar ou diferenciar os tipos de tráfegos existentes de forma que a rede consiga dar a tratativa necessária para alcançar o desempenho desejado. O desempenho pode ser em quesito de operacionalidade, acessibilidade, capacidade e outros fatores específicos de cada serviço. Para que uma rede possa assegurar o desempenho é necessário possuir quantidade de recursos igual ou maior que a carga de serviço a ser empregada. Neste caso, deve ser considerado que existem serviços que podem ser pausados quando outros serviços necessitarem de maior capacidade de recursos, com isso se evita a necessidade de possuir uma capacidade de recursos grande que ficará a maior parte do tempo inutilizada (EVANS; FILSFILS, 2007). Evans e Filsfils (2007) relatam de uma forma geral que QoS é o termo usado para descrever a ciência de engenharia de rede que é responsável pelo tratamento de tráfego de aplicações diferenciado-as dependendo das necessidades de seu nível de serviço. QoS é um dos temas mais cadentes em redes IP, porém continua sendo um dos menos compreendidos a partir de uma visão prática. Analisando estas definições, observamos que todas trazem como ponto chave o tratamento do tráfego, divisão em classes e disponibilidade de recursos conforme a necessidade. Podemos então afirmar que qualidade de serviço é um mecanismo responsável por garantir a transmissão de pacotes de forma eficiente utilizando recursos que diferencie cada tipo de serviço, aumente ou diminua a prioridade dos serviços, controle a largura de banda da rede, tudo para garantir a qualidade de transmissão que determinados serviços necessitam. Entretanto, como a rede IP por padrão oferece o serviço de melhor esforço, para prover QoS é necessária a utilização de mecanismos que forneçam meios de distinguir os pacotes e tratá-los conforme a necessidade de cada serviço. Para as redes IP existem disponíveis dois principais mecanismos de QoS, denominados IntServ, que caracterizam as redes de serviços integrados e DiffServ, relativos às redes de serviços diferenciados (PARK, 2005). Estes mecanismos são apresentados a seguir. A) Integrated Services Criado pela Internet Engineering Task Force (IETF), o grupo de trabalho IntServ surgiu com intuito de viabilizar a utilização de serviços integrados em redes de computadores (KAMIENSKI; SADOK, 2000). O mecanismo IntServ definido na RFC 1633, é caracterizado por utilizar a alocação de recursos para dois novos tipos de serviço, os serviços garantidos para aplicações que requerem atraso constante e os serviços de carga controlada destinados a aplicações que precisam de segurança e destacam o serviço de melhor esforço (JUNIOR, 2006). Conforme descrito em Junior (2006) para realizar a reserva de recursos em uma rede de serviços integrados, foi desenvolvido o protocolo Resource Reservation Protocol (RSVP). Ele é utilizado pela rede para realizar reserva de recursos por meio do envio de pacotes contendo as especificações de reserva desejada. As reservas incluem, por exemplo, os níveis de latência, jitter, perda de pacotes e o tipo de tráfego que será transmitido pela rede. Para realizar as reservas, a solicitação tem que percorrer todos os roteadores que irão analisar as informações e definir se possuem recursos sobressalentes para atender a solicitação; por utilizar apenas 103 T.I.S. 2012; 1 (2):

3 recursos sobressalentes o RSVP garante que as sessões estabelecidas anteriormente e que ainda estão ativas não sejam prejudicadas pelas novas sessões. O RSVP é responsável apenas pelo processo de sinalização, por isso para realizar QoS via IntSer são necessários a utilização de um escalonador de pacotes, um classificador e uma rotina de admissão. Após a análise de todos os roteadores, apenas se a rede possuir os recursos necessários à sessão será aceita e todo tráfego da aplicação irá seguir por rotas definidas. Segundo informado por Kamienski e Sadok (2000), o IntServ não é adequado para utilização em redes de grande porte como a Internet. Nestas redes, o volume de tráfego e número de requisições abertas é grande e, caso fosse implantado este serviço, os roteadores teriam que atender todas as exigências que incluem a implantação do RSVP em todos os roteadores. As exigências incluem controle de admissão, classificação e escalonamento de pacotes, o que implicaria a sobrecarga dos roteadores. B). Differentiated Services Devido às limitações existentes no IntServ e a necessidade de uma arquitetura que pudesse oferecer QoS para redes de grande porte, como a Internet, foi proposta a arquitetura de DiffServ. Esta arquitetura é capaz de oferecer QoS com escalabilidade, não sendo necessário especificar o estado para cada fluxo ou sinalizar cada nó (KAMIENSKI; SADOK, 2000). Conforme detalhado por Kamienski e Sadok (2000) o DiffServ consegue fornecer tal escalabidade devido os seguintes fatores: Agrupamento dos fluxos com requisitos similares em conjuntos, denominados Behavior Aggregate (BA); Fornecimento de recursos para os conjuntos sem a necessidade de utilizar um protocolo de reserva dinâmica de recursos; Separação das funções dos roteadores de borda e de núcleo. Na separação, os roteadores de borda ficam incumbidos das funções mais complexas de marcação, classificação, condicionamento de tráfego (policiamento e moldagem) e os roteadores de núcleo dedicam a maior parte dos recursos encaminhando pacotes para os BAs. Este processo de encaminhamento de pacotes é denominado per-hop-behavior (PHB). No encaminhamento, os pacotes pertencentes a um mesmo conjunto de uma mesma rede que implementa do DiffServ são tratador pelo mesmo PHB. A Figura 1 ilustra este cenário. Figura 1. Disposição dos roteadores de borda e roteadores de núcleo (JUNIOR, 2006) O processo de classificação dos pacotes é realizada com base no campo DS Field, antigo campo Type Of Service (TOS) do cabeçalho IPv4. Este campo é composto por 8 bits, onde seis bits do DS Field são utilizados para identificar o valor do differentiated services codepoint (DSCP) que é usado na seleção do PHB e os dois bits restantes denominados de currently unused (CU) não são utilizados e por isso é desconsiderado seu uso no DiffServ (JUNIOR, 2006). Estes campos podem ser observados na Figura 2. Figura 2. Representação do campo DS Field O DiffServ é escalável, porém não oferece garantia de recursos para todos os fluxos como acontece com o IntServ. Isto ocorre quando a necessidade de recursos como largura de banda e atraso não são atendidas pela QoS como esperado. Como as reservas são feitas para os conjuntos (BAs), um erro na classificação pode facilmente acarretar problemas de desempenho da QoS (KAMIENSKI; SADOK, 2000). Na Figura 3, podemos observar a diferença na tratativa do fluxo de tráfego da rede em cada mecanismo. No mecanismo de melhor esforço, todo o fluxo é tratado de forma igualitária. No IntServ cada tipo de fluxo recebe um tratamento individual. No DiffServ, podemos observar que dois ou mais fluxos são agrupados em classes. Figura 3. Best Effort (melhor esforço), IntServ e DiffServ T.I.S. 2012; 1 (2):

4 QoS em um Cenário VoIP Utilizando o Agendador HTB III. VOIP A evolução das telecomunicações e a popularização da Internet ajudou na disseminação de novas tecnologias, dentre elas destaca-se o uso da tecnologia que utiliza voz sobre redes IP (VoIP) (ROSS, 2007). Segundo Colcher (2005) VoIP pode ser definido como técnicas de empacotamento e transmissão de amostras de voz utilizando redes IP incluindo todos os mecanismos de sinalização necessário para o estabelecimento das ligações feitas por meio destas redes. Os conceitos e características do VoIP são abrangentes e descritos na sequência, baseados em Ross (2007). O tráfego VoIP é interativo, necessitando de transmissão em tempo real para que possa ocorrer uma comunicação aceitável. Entretando, o meio que é utilizado para realizar a comunicação pode estar sujeito a atrasos. O atraso é um dos grandes fatores que contribui na redução da qualidade da chamada de voz em redes IP. Caso um pacote sofra um atraso acima de 150 ms será perceptível ao usuário e poderá até causar frustrações. Para as redes que utilizam o protocolo IP é necessário um mecanismo que consiga priorizar o tráfego VoIP, ajudando a amenizar variações de atrasos de pacotes. Com essa priorização a rede será capaz de entregar os pacotes em tempo aceitável. O comunicação utilizando sistemas VoIP possui atrativos e um de grande destaque é a redução de custo em comunicação telefônica. Isso se deve ao fato de que para a transmissão de voz é utilizado a Internet onde trafegam outros tipos de informação, evitando custos existentes na rede de telefonia convencional. Os serviços de VoIP já estão sendo muito utilizados pelas próprias operadoras de telecomunicações, especialmente para realização de chamadas de longa distância Internacional conseguindo reduções de custo significante. Atualmente grande parte das comunicações internacionais já são feitas utilizando sistemas VoIP e existem previsões de um aumento de sua utilização em aproximadamente 75% a 90% para os próximos anos. Como visto, VoIP hoje é uma realidade que já está sendo bem utilizado, porém ainda existem problemas como o atraso que deve ser utilizado mecanismos que de uma melhor priorização dos pacotes nas redes por onde o tráfego VoIP passa. IV. CONTROLE DE TRÁFEGO O Traffic Control (TC) é uma ferramenta utilizada para configurar o controle de tráfego no kernel de sistemas operacionais como Unix, BSD e Linux. Ele faz parte do conjunto de ferramentas de linha de comando responsável por manipular estruturas de controle de tráfego do kernel para configurar redes IP em uma máquina, este conjunto é denominado iproute2. Neste trabalho somente é abordado o utilitário TC do conjunto iproute2 (HUBERT, 2010a). A ferramenta TC e seus componentes são descritos abaixo, baseados em Humbert (2010a) e Brown (2006a). O utilitário TC tem como função interagir com o kernel para criar, excluir e modificar estruturas de controle de tráfego. O controle de tráfego consiste em shaping, scheduling, Policing e Dropping. Shaping corresponde à modelagem do tráfego de rede. O tráfego que está modelado (shaped) tem a taxa de transmissão sob controle, à modelagem pode reduzir a largura de banda disponível como também controlar rajadas de tráfego em uma rede, de forma a obter um comportamento mais estável da rede. Por padrão a modelagem acontece no tráfego de saída. O scheduling, ou agendador, é o responsável por agendar a transmissão de pacotes melhorando a interatividade para determinados tráfegos mantendo ainda certa garantia de largura de banda para transferências em massa. Por padrão o agendamento acontece no tráfego de saída. O Policing é o responsável por realizar o controle das transmissões impondo limites na velocidade transmitida quando necessário. Por padrão o policiamento é feito no tráfego de entrada. O Dropping é o responsável por controlar tanto o tráfego de entrada como o de saída que ultrapassam os limites da largura de banda. Quando o limite é ultrapassado o dropping pode realizar a qualquer momento o descarte de pacotes. O processamento de tráfego no TC é controlado pelos seguintes objetos: queueing discipline (qdiscs), classes e filtros. A seção seguinte abrange estes conceitos. A) Queueing Discipline (qdiscs) Resumidamente podemos dizer que o qdisc é um agendador. Sempre que o kernel precisa enviar um pacote para uma interface, o pacote é enfileirado no qdisc configurado naquela interface. Segundo (BROWN, 2006a), qdisc é a base na qual é construído todo o controle de tráfego no Linux e existem dois tipos de qdiscs, que são Qdiscs classless e Qdiscs classfull. Qdiscs classless são qdiscs que não contém classes e consequentemente não há motivos para haver classificação e filtros. Conforme informado por (HUBERT, 2010b) um bom exemplo de qdisc classless é o pfifo_fast (First In, First Out). Os qdiscs classfull são os qdiscs que podem conter classes e fornecem meios para anexar filtros. Nada impede que um Qdisc classfull seja criado sem nenhuma classe, porém se feito isso irá consumir recursos do sistema sem trazer nenhum benefício. Exemplos de qdisc classfull são Class Based Queuing (CQB), HTB e Hierarchical Fair Service Curve (HFSC) (BROWN, 2006a). Brown esclarece que existe uma terminologia que causa certa confusão, o qdisc root. Ele não é uma disciplina de fila, mais sim o local para que as estruturas de controle de tráfego sejam anexadas para gerenciar os tráfegos de entrada e saída. B) Classes As classes só existem dentro de qdiscs classfull e são bastante flexíveis, pois podem conter uma ou várias classes ou um qdisc filho. As classes são meios de fornecer tratamento diferenciado para diferentes tráfegos. Existe uma terminologia utilizada para a classe final, aquela que nunca terá uma classe filho, estas são comumente chamadas de leaf class. Para qualquer classe que contenha uma classe filha é dado o nome de inner class (BROWN, 2006a). C) Filtros Segundo Brown (2006a), filtro é o componente mais 105 T.I.S. 2012; 1 (2):

5 complexo em sistema de controle de tráfego Linux. Os filtros permitem que o usuário classifique os pacotes em um ou mais filtros de um tráfego de saída. O filtro realizado pode ser aplicado tanto em classes quanto em qdisc, porém quando aplicado em qdisc eles não possuem o controle total do que acontece, este controle pertence ao qdisc. V. AGENDADOR HIERARCHICAL TOKEN BUCKET Em Brown (2006b) é definido o agendador HTB, apresentado seus aspectos e características. Baseando-se em Brown, nesta seção iremos abordar estes conceitos. Hierarchichal Token Bucket (HTB) é um agendador de pacotes desenvolvido por Martin Devera que foi incluído no kenel do Linux apartir da versão O HTB implementa uma disciplina de fila (qdisc) do tipo classfull para realização de controle de tráfego no Linux utilizando um sistema hierárquico para a organização das classes. Considerando um cenário simples, a disciplina de fila primária em qualquer dispositivo é denominada de qdisc root. Este qdisc pode conter uma ou mais classes dependendo da complexidade do cenário a ser implementado. Para um cenário HTB simples, devem-se configurar dois parâmetros, a taxa (rate) e o limite superior (ceil) que representarão o total de largura de banda disponível no link a ser utilizado. Por este motivo, normalmente esta classe é configurada com os mesmos valores da classe de nível superior. No HTB, o rate representa a largura de banda que será garantida para uma determinada classe e o ceil especifica a largura máxima de banda que essa classe pode consumir. O ceil é comumente chamado de taxa de empréstimo, isso se deve pelo fato de que toda a banda que está entre o rate e o ceil é cedida a partir de uma classe de nível superior (denominada classe pai). Este empréstimo ocorrerá apenas se a classe superior estiver com recursos sobressalentes. Devido ao formato hierárquico do HTB, podem ser fornecidos diferentes valores de rate e ceil para cada classe de nível inferior (classe filha) desde que não excedam os valores configurados na classe superior. Na Figura 4 é apresentado a estrutura das classes, root, inner class e leaf class com os respectivos sistemas de empréstimos. A classe filha pode emprestar a largura de banda sobressalente de sua classe pai. Com o correto provisionamento da rede, o HTB será capaz de fornecer garantias de largura de banda, podendo então dar prioridades diferentes a serviços diferentes. Figura 4. Estruturas de classes e empréstimos (BROWN, 2006c). VI. CENÁRIO DOS EXPERIMENTOS Para avaliação da aplicação do controle de tráfego foi projetado um cenário, criando um ambiente controlado. Assim, torna-se possível avaliar o desempenho e as taxas de transmissão sem interferências externas. Este cenário inclui dois desktops e um roteador que são interligados via cabo metálico, os detalhes são descritos abaixo. Desktops: O primeiro equipado com uma placa de rede padrão Fast Ethernet, fornecendo uma taxa teórica de 100 megabits por segundo. O segundo está equipado com uma placa de rede padrão gigabit ethernet com taxa teórica de 1 gigabit por segundo. Para os desktops, a taxa máxima de transmissão será nivelada pela placa com menor capacidade teórica de transmissão, neste caso o primeiro desktop que T.I.S. 2012; 1 (2):

6 QoS em um Cenário VoIP Utilizando o Agendador HTB utiliza o padrão fast ethernet. Como sistema operacional, foi escolhido o Windows 7 para ambos os desktops. Nos desktops serão instalados o software de conferência de áudio denominado Robust Audio Tool (RAT). A versão escolhida foi a 4.5-beta 1 por ser compatível com o Windows 7. No RAT, como codec de áudio iremos utilizar o Linear16-32K-Mono. Escolhemos este codec pelo fato de não realizar compressão do áudio, necessitando assim de maior largura de banda. Na Figura 5 são mostradas as características deste codec. testes, onde podemos observar que estão presentes dois desktops um em cada extremo e o roteador ao centro. Figura 6. Cenário utilizado nos testes Nos testes que será priorizado o tráfego VoIP por meio do HTB, iremos utilizar a implementação do HTB conforme ilustrado na Figura 7. Figura 5. Características do codec Linear16-32K-Mono Com o RAT instalado, o primeiro desktop será configurado como servidor de áudio. O desktop 2 irá receber por meio da rede o áudio disponibilizado pelo desktop 1 (servidor). No servidor serão tocadas músicas em MP3 por meio do software reprodutor de músicas que acompanha o Windows 7, denominado Windows Media Palyer (WMP). O Roteador possui 4 portas, todas no padrão gigabit ethernet. O software de gerenciamento do roteador (firmware) é o DD-WRT. Este firmware tem como base o SO Linux e tem os módulos necessários para realização de QoS utilizando o agendador HTB. Maiores detalhes sobre o firmware DD-WRT podem ser obtidos em Cabo metálico unshielded twisted pair (UTP) categoria 5e crimpados conforme padrão EIA/TIA T568B. Será utilizada a faixa de IP classe C, /24. O roteador está com a opção de revidor Dynamic Host Configuration Protocol (DHCP) habilitado, porém as concessões estão fixadas pelo Media Access Control address (MAC Adress) que é o endereço físico que cada interface de rede possui. Com isso o desktop 1 irá sempre receber o endereço /24 e o desktop 2 o endereço /24, para ambos o endereço do default gateway é que é justamente o endereço do roteador. A Figura 6 ilustra o cenário que iremos utilizar para os 1 Disponível em: Figura 7. Cenário HTB para os testes. Para maiores detalhes sobre como utilizar a ferramenta TC para gerar as qdiscs, inner class e leaf class, consulte o man page 2 do TC. A) Experimentos Com intuito de mostrar a eficiência do HTB para priorização do tráfego VoIP, na rede descriminada na seção 6 iremos realizar quatro diferentes testes para coletarmos informações suficiente sobre o desempenho do HTB. Em todos os testes o cenário foi o mesmo ilustrado na Figura 6 e foi utilizado o software RAT para realizar uma chamada de áudio entre os desktops. No primeiro teste analisamos o desempenho da rede ao trafegar áudio por meio do software RAT em um canal exclusivo, sem nenhuma interferência de outras transmissões. Nos demais testes, juntamente com a chamada de áudio, serão transferidos um arquivo com um tamanho de dez gigabytes entre os desktops com intuito de sobrecarregar os canais de comunicação para podermos analisar em situações extremas o desempenho de cada teste. Os testes realizados são: Rede operando no mecanismo padrão, o de melhor esforço, sem sobrecarga dos canais de comunicação; 2 TC Man page, disponível em: T.I.S. 2012; 1 (2):

7 Rede operando no mecanismo padrão, o de melhor esforço, com sobrecarga dos canais de comunicação; Rede operando com a implementação do HTB, priorizando apenas 30% da largura de banda necessária para uma chamada de áudio satisfatória, com sobrecarga dos canais de comunicação; Rede operando com a implementação do HTB, priorizando 100% da banda necessária para uma chamada de áudio satisfatória, com sobrecarga dos canais de comunicação; Para os testes extremos, onde são geradas sobrecargas nos canais de comunicação é esperado que ocorram atrasos e perdas de pacotes ocasionando degradações na chamada de áudio. Entretanto quando o HTB for implementado e estiver priorizando 100% da banda necessária para uma chamada de áudio é esperado que ocorram poucos atrasos e perdas de pacotes, consequentemente a chamada deve ocorrer sem degradações ou interferências mesmo a rede estando congestionada. B) Os testes Conforme descrito anteriormente, a rede para os testes consiste no cenário da Figura 6. Antes de iniciarmos os testes, com intuito de definir a largura de banda utilizada pelo RAT na transmissão, realizamos uma transferência de áudio na rede e com auxilio do software presente no roteador foi constatado que a largura de banda necessária é de 170 kps. Conforme podemos observar na Figura 8. recebidos e a ausência de erros de transmissão. Figura 9. Primeiro teste: Número de pacotes recebidos, perdidos e desordenados D) Segundo teste Este teste, assim como o primeiro, está sendo feito sem a implementação do HTB, o mecanismo de melhor esforço é utilizado como padrão. Está sendo gerado um tráfego na rede por meio da transmissão de um arquivo com o tamanho de 10 gigabytes, causando a sobrecarga. Iniciamos então a transmissão de áudio. Os testes foram realizados por um período de 15 minutos. Neste período podemos escutar nitidamente a degradação do áudio. Diferentemente do primeiro teste, observamos um nível elevado de pacotes perdidos e a presença de pacotes fora de ordem. A Figura 10 comprova os problemas na transmissão, mostrando a quantidade de pacotes perdidos e pacotes que chegaram fora de ordem. Figura 8. Software presente no roteador monitorando tráfego do RAT Após definida a largura de banda necessária para o tráfego de áudio por meio do RAT, iniciamos os testes. C) Primeiro teste No primeiro teste, o roteador está configurado para interligar os dois desktops. Nenhuma implementação do HTB está presente. Neste caso prevalece o mecanismo padrão, o de melhor esforço. Apenas o tráfego de áudio gerado pelo RAT percorre a rede. Após 15 minutos de tráfego de áudio percorrendo a rede, como já era esperado, não houve problemas de atrasos que poderiam causar a chegada desordenada de pacotes ou até mesmo perdas de pacotes. Na Figura 9 é ilustrado o resultado do primeiro teste, mostrando o número total de pacotes Figura 10. Segundo teste: Número de pacotes recebidos, perdidos e desordenados T.I.S. 2012; 1 (2):

8 QoS em um Cenário VoIP Utilizando o Agendador HTB E) Terceiro teste A partir deste momento iniciaremos os testes com implementação do HTB e todos os testes serão realizados em cenários extremos, isso significa que será gerado tráfego para sobrecarregar os canais de comunicação. Neste terceiro teste iremos realizar a implementação do HTB para assegurar apenas 30% (51 Kbps) da banda necessária para a transmissão de áudio. Para este teste, na Figura 7, a classe 1:10 deve ser considerado o valor de 51 Kbps para o rate. Com o canal de comunicação sobrecarregado, iniciamos a transmissão do áudio com o HTB priorizando 51 Kbps da largura de banda. Por um período de 15 minutos, escutamos o áudio e analisamos as degradações. Houve perda de pacotes e a degradação foi perceptível. Na Figura 11, comprovamos os resultados obtidos e observamos a existência de pacotes perdidos. era como esperado, não foi constatado problema durante toda na transmissão. Foram transferidos pacotes. Figura 12. Quarto teste: Número de pacotes recebidos, perdidos e desordenados Figura 11. Terceiro teste: Número de pacotes recebidos, perdidos e desordenados F) Quarto teste No quarto teste, o HTB está presente e priorizando 100% (170 Kbps) da banda necessária para transmissão de áudio. Como feito em testes anteriores, iniciamos com a sobrecarga do canal de comunicação, em seguida é iniciada a transferência de áudio. Pelo mesmo período dos demais testes, ficamos escutando o áudio que estava sendo transferido. Neste teste não ouve degradações perceptíveis, o nível de perdas de pacotes foi baixo. Na Figura 12 está o resultado do teste realizado, onde houve um número baixo de pacotes perdidos. VII. RESULTADOS No primeiro teste, onde trafegava pela rede apenas o áudio utilizando o software RAT, tínhamos o cenário totalmente favorável a essa transmissão. Como constatamos que para a transmissão de áudio utilizando o codec Linear16-32K-Mono é necessário apenas 170 Kbps e para este caso estava disponível uma conexão exclusiva de 100 Mbps, o resultado No segundo teste, o cenário mudou completamente. Com a rede congestionada pelo tráfego que geramos o mecanismo de melhor esforço não foi suficiente para evitar a degradação do áudio. De um total de , foram perdidos 2145 pacotes e 5 pacotes chegaram fora de ordem. Neste teste podemos constatar que para uma rede congestionada e que não possua mecanismos de priorização de pacotes se torna frustrante realizar uma ligação VoIP. Buscando analisar uma situação onde a rede assegure uma largura de banda, porém não suficiente para o serviço VoIP, reservamos apenas 30% da banda necessária no terceiro teste. O resultado foi degradações perceptíveis, porém aceitável, principalmente se comparado com o cenário do segundo teste. Pacotes perdidos somaram 418 de pacotes enviados, número relativamente baixo. Fato interessante foi que não houve pacotes desordenados neste cenário. Para finalizarmos os testes e comprovar o desempenho do HTB para priorização de tráfegos de áudio, realizamos o quarto teste. Neste teste foram assegurados 100% (170 Kbps) da largura de banda necessária para transmissão de áudio. Durante toda a transmissão não foram notadas degradações do áudio. Apesar de não ter ocorrido degradações perceptíveis, de um total de pacotes transferidos, 12 pacotes foram perdidos. Número extremamente baixo, especialmente se comparado com o resultado obtido no segundo teste. Como ocorrido no terceiro teste, o número de pacotes desordenados é 0. Levando em consideração os testes 2, 3 e 4, o índice de perda de pacotes não é alto, porém o alto nível de degradação no áudio que percebemos em alguns testes ocorre pelo atraso nas transmissões. Nem sempre que um pacote esteja atrasado ele será perdido. Para uma melhor visualização, ilustramos na tabela 1 um 109 T.I.S. 2012; 1 (2):

9 resumo de todos os testes realizados. Tabela 1. Resumo dos testes realizados Teste Mecanismo Reserva Situação da rede Pacote Recebido Perdido Desordenado 1 Melhor esforço N/A Livre Melhor esforço N/A c/ sobrecarga HTB 30% c/ sobrecarga HTB 100% c/ sobrecarga VIII. CONCLUSÃO E TRABALHOS FUTUROS Com a convergência das redes de telecomunicações, a possibilidade de trafegar voz na rede que inicialmente foi designada para o transporte de dados virou uma realidade. Entretanto o serviço de melhor esforço fornecido pela rede IP não era suficiente para atender a necessidade de tráfego real que redes VoIP precisam. Buscando uma solução para este problema surgiu a QoS para redes de computadores. Para a implementação da QoS em uma rede de computadores é necessário selecionar um agendador. O agendador será o responsável por organizar os pacotes em uma fila, priorizando os pacotes conforme a necessidade. O HTB é um agendador de pacotes maduro presentes em diferentes SO e seu estudo neste trabalho foi fundamental para alcançar nosso objetivo. Com os testes realizados ficou explícito a necessidade de QoS ao realizar o tráfego de áudio em um canal congestionado. Ao implementar HTB no cenário VoIP os pacotes são priorizados, obtendo chamadas áudio sem degradações perceptíveis ao usuário. Todos os testes foram realizandos em um ambiente controlado, comprovando a eficácia do agendador HTB ao evitar atrasos e perdas de pacotes, garantindo assim a QoS para um ambiente VoIP. Como está previsto um aumento exponencial na utilização de sistemas VoIP e também a migração do padrão de endereçamento IPv4 que hoje utilizamos para o novo padrão IPv6, deixo como trabalho futuro a proposta para o desenvolvimento de um agendador que organize os pacotes de forma eficiente dentro deste novo cenário que está surgindo. REFERÊNCIAS ABNT, Associação Brasileira de Normas Técnicas. NBR ISO 9000:2000 Sistemas de gestão da qualidade - Fundamentos e vocabulário. Rio de Janeiro, p. BRADEN, Bob; CLARK, David; SHENKER, Scott. RFC Integrated services in the Internet architecture: an overview Disponível em: < TEXTS/1633/index.html>. Acesso em: 11 setembro BROWN, Martin A. Traffic control using tcng and HTB HOWTO Disponível em: < Acesso em: 14 agosto BROWN, Martin A. Traffic Control HOWTO classful queuing disciplines (qdiscs) Disponível em: < HOWTO/classful-qdiscs.html#qc-cbq>. Acesso em: 15 agosto COLCHER, Sérgio; GOMES, Tadeu A.; SILVA, Anderson Oliveira da; FILHO, Guido L. de Souza; SOARES, Luiz Fernando G. VoIP Voz Sobre IP.1., Rio de Janeiro, Campus, p. ETSI, European Telecommunications Standards Institute. Satellite Earth Stations and Systems (SES); Broadband Satellite Multimedia; IP Interworking over satellite; Performance, Availability and Quality of Service. Sophia Antipolis Cedex, p. EVANS, John; FILSFILS, Clarence. Deploying IP and MPLS QoS for multiservice networks - theory and practice. 1., San Francisco, Elsevier, p. HUBERT, Bert. TC Linux man page. Disponível em: < Acesso em: 04 junho HUBERT, Bert. Linux advanced routing & traffic control HOWTO: Queueing disciplines for bandwidth management. Disponível em: < Acesso em: 12 junho JUNIOR, Israel Dias de J. QoS para VoIP através do HTB. Universidade Tiradentes. Aracaju, p. Disponível em: < > Acesso em: 08 agosto KAMIENSKI, Carlos Alberto; SADOK, Djamel. Qualidade de Serviço na Internet. Universidade Federal de Pernambuco. Belo Horizonte, p. Disponível em: < -sbrc2000.pdf>. Acesso em: 05 de junho de MARCHESE, Mario. QoS over heterogeneous networks. 1., Chichester, Wiley, p. NEMETH, Evi; SNYDER, Garth; HEIN, Trent R. Manual complete do Linux: Guia do administrador. 1., São Paulo, Pearson, p. PARK, K. I. QoS in packet networks. 1., Boston, Springer, p. ROSS, Julio. VoIP voz sobre IP.1., Rio de Janeiro, Antenna, p. T.I.S. 2012; 1 (2):