VOIP: Um Estudo Experimental

Transcrição

1 UNIVERSIDADE FEDERAL DO RIO GRANDE DO SUL INSTITUTO DE INFORMÁTICA PROGRAMA DE PÓS-GRADUAÇÃO EM COMPUTAÇÃO VOIP: Um Estudo Experimental por CLAUDIO LUIS SITOLINO Dissertação submetida à avaliação, como requisito parcial, para a obtenção do grau de Mestre em Ciência da Computação Prof. Juergen Rochol Orientador Porto Alegre, março de 2001.

2 2 CIP CATALOGAÇÃO NA PUBLICAÇÃO Sitolino, Claudio Luis VOIP: Um Estudo Experimental / por Claudio Luis Sitolino. Porto Alegre: PPGC da UFRGS, p.:il. Dissertação (mestrado) Universidade Federal do Rio Grande do Sul. Programa de Pós-Graduação em Computação, Porto Alegre, BR-RS, Orientador: Rochol, Juergen. 1. Voz sobre IP. 2. Avaliação de desempenho. 3. Analise de tráfego. I. Rochol, Juergen. II. Título. UNIVERSIDADE FEDERAL DO RIO GRANDE DO SUL Reitora: Profa. Wrana Panizzi Pró-Reitor de Ensino: Prof. José Carlos Ferraz Hennemann Superintendente de Pós-Graduação: Prof. Philippe Olivier Alexandre Navaux Diretor do Instituto de Informática: Prof. Philippe Olivier Alexandre Navaux Coordenadora do PPGC: Prof. Carlos Alberto Heuser Bibliotecária-Chefe do Instituto de Informática: Beatriz Haro

3 3 A minha esposa, Sandra Maria Vilhegas Sitolino E aos meus filhos, Gustavo, Beatriz e Pedro Augusto Pelo amor, compreensão e Incentivo durante todos esses anos

4 4 Agradecimentos Ao Porf. Juergen Rochol pela orientação, apoio, incentivo, muita dedicação e ensinamentos sem os quais esse trabalho não teria sido concluído. Aos amigos de turma: Lincoln, Marcos Paulo, Marco e Melissa, pela amizade, companheirismo, apoio e disposição para incentivar e colaborar. Aos amigos: Eduardo Rizo, Marco Eduardo e Gerson (Cipó), pelas dificuldades que juntos conseguimos contorná-las. A FIPP Faculdade de Informática de Presidente Prudente, pelo apoio e compreensão no decorrer desse trabalho, em especial ao Diretor Moacir Del Trejo. A todas as pessoas que de direta e indiretamente contribuíram com este trabalho.

5 5 Sumário Lista de Abreviaturas... 7 Lista de Figuras... 8 Lista de Tabelas...11 Resumo...12 Abstract Introdução Características do Serviço de Voz Comutação de Circuitos X Redes de Pacotes Transmissão de Voz sobre Redes de Pacotes Atrasos Pacotes Perdidos Descarte de Pacotes Utilização da Banda Codificadores de Voz Serviço de Voz sobre a Arquitetura TCP/IP Encapsulamento de voz sobre IP Problemas na Transmissão de Voz sobre IP Problemas com a falta de QoS RTP RSVP DiffServ Estudo Experimental Descrição dos equipamentos do Ambiente de Teste Descrição das Ferramentas do Ambiente de Teste Avaliação dos Resultados Experimentais Primeiro Arranjo Experimental Primeiro Teste Somente tráfego de voz Segundo Teste Voz com rajadas de dados Terceiro Teste Voz com dados Quarto Teste Voz com sobrecarga de dados Avaliação dos Resultados do Primeiro Arranjo Experimental Segundo Arranjo Experimental Primeiro Teste Somente tráfego de voz Segundo Teste Voz com rajadas de dados... 53

6 Terceiro Teste Voz com Tráfego de Dados Constante Quarto Teste Somente Tráfego de Voz com os Pacotes Capturados no Segundo Domínio de rede Ethernet Quinto Teste Voz com Rajadas de Dados com os Pacotes Capturados no Segundo Domínio de rede Ethernet Avaliação dos Resultados do Segundo Arranjo Experimental Terceiro Arranjo Experimental Primeiro Teste Somente tráfego de voz Segundo Teste Tráfego de Voz e Dados Avaliação dos Resultados do Terceiro Arranjo Experimental Conclusões e Trabalhos Futuros Conclusões Trabalhos Futuros Bibliografia...71

7 7 Lista de Abreviaturas AF ATM BB CBR DiffServ DNS EF FIFO FTP HTTP ICMP IETF IGMP IP ITU ITU-T MOS MPLS PABX PCM PSTN QoS RSVP RTP TCP ToS UDP VBR VoIP Assured Forwarding Asynchronous Transfer Mode Bandwidth Brokers Constant Bit Rate Differentiated Service Domain Name Service Expedited Forwarding First In First Out File Transfer Protocol Hiper Text Transport Protocol Internet Control Message Protocol Internet Engineering Task Force Internet Gateway Message Protocol Internet Protocol International Telecommunication Union ITU Telecommunication Standardization Union Mean Opinion Score MultiProtocol Label Switching Private Automatic Banch Exchange Pulse Code Modulation Public Switched Telephone Network Quality of Service Resource ReSerVation Protocol Real-time Transfer Protocol Transporte Control Protocol Type of Service User Datagram Protocol Variable Bit Rate Voice over IP

8 8 Lista de Figuras FIGURA 2.1 Atrasos fixos e variáveis FIGURA 2.2 Sequência de codificação da voz FIGURA 3.1 Encapsulamento de voz FIGURA 3.2 Pacote IP Capturado pela Ferramenta ETHLOAD originado por uma Aplicação de Voz FIGURA 3.3 Dados RTP em um pacote IP FIGURA 3.4 Redes heterogêneas FIGURA 3.5 Protocolo de Reserva de Banda FIGURA 3.6 Marcação dos pacotes EF FIGURA 3.7 Marcação dos pacotes AF FIGURA 3.8 Funções de um Roteador de limite FIGURA 4.1 Primeiro Arranjo Experimental FIGURA 4.2 Segundo Arranjo Experimental FIGURA 4.3 Terceiro Arranjo Experimental FIGURA 4.4 Configuração de Compactação do Microsoft NetMeeting FIGURA 4.5 Conexão de uma Chamada do Microsoft NetMeeting FIGURA 4.6 Tela do Microsoft NetMeeting pronto para enviar/receber Voz FIGURA 4.7 Arquivo Texto dos Pacotes Capturados FIGURA 4.8 Exemplo de um Gráfico gerado pela Ferramenta de Análise FIGURA 4.9 Tela da Ferramenta de Análise FIGURA 5.1 Gráfico da Vazão da Rede com somente Tráfego de Voz FIGURA 5.2 Gráfico do Tráfego da Rede com Rajadas de Dados FIGURA 5.3 Gráfico detalhado do Tráfego de Voz... 45

9 9 FIGURA 5.4 Gráfico do Tráfego com a Rede da Faculdade de Informática conectada FIGURA 5.5 Gráfico detalhado do Tráfego de Voz FIGURA 5.6 Gráfico do Tráfego com a Rede da Faculdade de Informática conectada mais tráfego adicional FIGURA 5.7 Gráfico detalhado do Tráfego de Voz FIGURA 5.8 Histograma dos Testes do Primeiro Arranjo Experimental FIGURA 5.9 Intervalo entre pacotes de voz de um determinado segundo FIGURA 5.10 Representação das Rajadas de Pacotes FIGURA 5.11 Gráfico do Tráfego da Rede com somente Voz FIGURA 5.12 Gráfico do Tráfego de Voz com rajadas de Dados FIGURA 5.13 Gráfico detalhado do Tráfego de Voz FIGURA 5.14 Gráfico do Tráfego da Rede com Voz e Dados FIGURA 5.15 Gráfico detalhado do Tráfego de Voz FIGURA 5.16 Gráfico do Tráfego da Rede com Somente Voz em relação ao Ethernet de 10 Mbit/s FIGURA 5.17 Gráfico do Tráfego da Rede com Somente Voz em relação ao Canal de Bit/s FIGURA 5.18 Gráfico do Tráfego da Rede com Voz e Dados em relação ao Ethernet de 10 Mbit/s FIGURA 5.19 Gráfico do Tráfego da Rede com Voz e Dados em relação ao Canal de Bit/s FIGURA 5.20 Histograma referente ao primeiro e quarto testes FIGURA 5.21 Histograma referente ao segundo e quinto testes FIGURA 5.22 Histograma do atraso dos Pacotes de Voz FIGURA 5.23 Histograma do atraso dos Pacotes de Voz... 65

10 10 FIGURA 5.24 Histograma dos atrasos nos testes realizados no segundo o Terceiro Arranjo Experimental FIGURA 6.1 Sequência de processos para a transmissão de VoIP... 69

11 11 Lista de Tabelas TABELA 2.1 Atrasos típicos em transmissão de voz...16 TABELA 2.2 Valores utilizados pelo MOS TABELA 2.3 Soma dos atrasos fixos TABELA 2.4 Principais codificadores do ITU-T TABELA 5.1 Resultados dos testes do Primeiro Arranjo Experimental TABELA 5.2 Resultados dos testes do Segundo Arranjo Experimental TABELA 5.3 Resultados dos testes do Terceiro Arranjo Experimental... 67

12 12 Resumo Voz sobre IP (VoIP) é uma tecnologia que permite a digitalização e a codificação da voz e o empacotamento em pacotes de dados IP para a transmissão em uma rede que utilize o protocolo TCP/IP. Devido ao volume de dados gerados por uma aplicação VoIP, esta tecnologia se encontra em funcionamento, em redes corporativas privadas. Mas se a rede base para o transporte desta aplicação for a Internet, certamente, não deve ser utilizada para fins profissionais, pois o TCP/IP não oferece padrões de QoS (Qualidade de Serviço) comprometendo desta forma a qualidade da voz. A qualidade da voz fica dependente do tráfego de dados existentes no momento da conversa. Para realizar um projeto de VoIP é necessário conhecer todo o tráfego existente na rede e verificar o quanto isto representa em relação à banda total da rede. Também se deve conhecer o tipo de aplicação que se deseja implantar, verificando a banda a ser utilizada por esta, e então projetar como a rede deverá ser estruturada. Para auxiliar no projeto de VoIP, pretende-se mostrar o que está sendo desenvolvido para que o protocolo TCP/IP ofereça QoS e uma ferramenta para análise do tráfego de voz sobre redes TCP/IP e também análises dos resultados obtidos em experimentos simulando diversas situações práticas. Palavras-chave: voz sobre IP, avaliação de desempenho, analise de tráfego

13 13 TITLE: VOIP: AN EXPERIMENTAL STUDY Abstract Voice over IP (VoIP) is a type of technology that allows voice digitalization, coding and packing into IP data packets to be transmitted through a TCP/IP network. Because of the amount of data generated by an VoIP application, the technology can only be found at corporate networks. But if the base network to transport this application is the Internet, certainly it should not be used for professional purposes, TCP/IP does not offer QoS (Quality of Service) patterns, compromising voice quality. The quality of the voice transmitted depends on the data traffic on the network at the time of the conversation. To make a VoIP project it is necessary to know the existing network traffic and verify how this is related to the available band. It is also necessary to know which type of application is intended to be used, checking the network band used by it, and then design the network based on this data. To aid this VoIP project we show what is being developed to provide QoS using TCP/IP, and develop a tool to analyze voice traffic over TCP/IP. The results obtained during simulated experiments of practical situations are also shown. Keywords: voice over IP, performance evaluation, traffic analyzes.

14 14 1 Introdução Voz sobre IP, ou apenas VoIP, é uma tecnologia que permite a digitalização e codificação da voz e o empacotamento destes dados em pacotes IP para transmissão em uma rede que utilize o protocolo TCP/IP. O transporte de dados VoIP, utilizando-se como suporte a rede Internet comercial, tem sido um forte atrativo para os usuários. A experiência, no entanto, demonstrou que os pacotes IP contendo os dados de voz, ao passarem por diversos domínios e roteadores, não tem mais condições de oferecer uma qualidade de voz aceitável no destino. Um dos motivos é que os parâmetros de QoS (quality of service) exigidos para este serviço, relativos ao atraso e à variação deste atraso, não podendo ser assegurados pela Internet comercial. O volume de dados gerado por uma aplicação VoIP é outro desafio para a rede TCP/IP, fazendo com que a sua aplicação, muitas vezes, se restrinja a redes corporativas privadas, nas quais é relativamente simples e pouco oneroso a disponibilização de amplos recursos em termos de banda passante. As redes IP foram projetadas para aplicações de dados, e uma grande diferença entre uma aplicação de dados e uma aplicação de voz é que uma aplicação de voz é sensível ao atraso. Em uma rede IP não é possível garantir um atraso constante o que pode tornar uma aplicação de voz em tempo real, como por exemplo, uma ligação telefônica, um serviço de baixa qualidade com a voz entrecortada e muitas vezes não conseguindo ouvir a conversa. Aplicações de voz sobre IP têm despertado o interesse de muitos fornecedores que estão explorando este mercado, oferecendo suporte para a comunicação de voz utilizando o Protocolo da Internet (IP) com preços bem atrativos, devido ao baixo custo da Internet pública. Porém, devido ao grande volume de tráfego gerado por uma aplicação de voz sobre IP, permite que esta tecnologia se encontre em funcionamento em redes corporativas privadas, mas se a rede base para o transporte desta aplicação for a Internet, certamente não deve ser utilizada para fins profissionais, pois a arquitetura TCP/IP não oferece padrões de QoS, comprometendo desta forma a qualidade da voz. A qualidade da voz fica dependente do tráfego de dados existentes no momento da conversa. Para resolver o problema de falta de QoS em redes IP, estão sendo desenvolvidos vários protocolos, entre eles o Protocolo de Reserva de Recursos (Resource ReSerVation Protocol RSVP) que consiste em determinar um caminho fixo a ser percorrido por todos os pacotes IP e reservar banda de rede suficiente para atender a necessidade da aplicação. O Protocolo de Transporte em Tempo-Real (Real-time Transport Protocol RTP) que atua como uma interface melhorada entre as aplicações de tempo real e os protocolos das camadas já existentes. Mas, de uma maneira geral, o RTP não garante o fornecimento de pacotes, nem que os pacotes sejam entregues em ordem, e também não assume que a rede na qual ele está rodando seja confiável ou garantia de tempo entre pacotes fixa, que na verdade não implementam nada de QoS [LUI97]. Outro mecanismo para garantia de QoS em redes IP é a utilização da arquitetura DiffServ (Differentiated Services), a qual permite à rede oferecer diferentes níveis de qualidade de serviço, utilizando-se de um campo já existente no cabeçalho IP. A solução implementada pelo DiffServ assim como o RSVP exige alterações nos roteadores existentes.

15 15 Transporte de voz sobre redes, que utilizam o protocolo TCP/IP, é considerado uma grande oportunidade de sucesso, mas implementar este tipo de serviço não é uma tarefa muito fácil. Este trabalho tem como objetivo específico avaliar como pode ser o desempenho de aplicações de voz sobre IP utilizando as tecnologias de rede disponíveis no mercado, auxiliando o usuário a especificar um ambiente, a partir de um determinado perfil da aplicação de voz desejada. Dessa forma, foi desenvolvida uma ferramenta para análise de tráfego de voz sobre uma rede Ethernet e também sobre duas redes Ethernet interligadas por um canal com pouca banda disponível, coletando dados a fim de montar gráficos onde os resultados foram avaliados. No capítulo 2 foram definidas as principais características do serviço de voz sobre redes de circuitos e redes de pacotes, problemas na utilização de voz sobre redes de pacotes e codificadores de voz. Já no Capítulo 3, foram apresentados conceitos e definições sobre o transporte de voz utilizando a arquitetura Internet, problemas com a falta de QoS e possíveis soluções, como protocolos especiais para reserva de banda e para aplicações de tempo real. No capítulo 4 são descritos todos os equipamentos e arranjos experimentais montados para a realização dos testes. No capítulo 5 foram avaliados os resultados dos testes e experimentos, a partir de valores e gráficos obtidos com as ferramentas de análise. Por último, no Capítulo 6 apresentam-se as conclusões do trabalho e proposta para trabalhos futuros.

16 16 2 Características do Serviço de Voz O telefone foi desenvolvido entre o outono de 1875 e o verão de 1877, mas a data oficial da invenção do telefone é Até o início dos anos 1960, a tecnologia de transmissão de voz era a analógica. A passagem da transmissão analógica para a transmissão digital, no começo dos anos 1960, iniciou uma era de melhorias na qualidade das transmissões telefônicas o que proporcionou significativas melhorias na utilização das redes de telefonia. A transmissão de voz tem que garantir dois aspectos principais: um atraso mínimo para permitir a sensação de presença e uma boa qualidade permitindo um bom entendimento da conversa e até mesmo poder reconhecer a voz da pessoa com quem se esteja conversando. Para o primeiro aspecto, uma transmissão de voz pode tolerar no máximo 300 ms de atraso considerando o tempo de ida e volta. A tabela 2.1 apresenta os atrasos típicos relacionados a transmissão de voz. [MIN98]. TABELA 2.1 Atrasos típicos em transmissão de voz Tipo de Rede Atraso em ms Redes de telefone tradicional Redes de satélites 250 Redes Frame Relay A qualidade da voz é baseada em testes subjetivos de ouvido. Estes testes utilizam uma escala de cinco pontos, e é baseada na contagem média de opiniões (Mean Opinion Score MOS) em condições de testes bem definidas. Estas condições incluem: qualidade da fonte de voz, condições de referência como ruído branco, ruído correlacionado com a fala e outros, e geração de erro digital. Embora a qualidade da percepção da voz varia de um indivíduo para outro, o MOS (Mean Opinion Score) é uma medida amplamente aceitável para qualidade de voz [MIM98]. TABELA Valores utilizados pelo MOS Pontuação Qualidade da voz 5 Excelente: o indivíduo não consegue diferenciar o trecho original com o codificado, ou seja, não percebe degradações no sinal. (nenhum esforço é requerido) 4 Bom: a voz é agradável de se ouvir, ou seja, percebe degradações mas não se incomoda com elas, pois são mínimas. (nenhum esforço apreciável é requerido) 3 Moderado: a qualidade da voz é ruim, o usuário sente-se incomodado com as degradações, porém não tem interrupções e ainda consegue entender a mensagem. (requer esforço moderado) 2 Pobre: o sinal possui interrupções devido às degradações e o usuário tem que fazer um esforço considerável para entender alguns trechos. 1 Ruim: o indivíduo não entende a mensagem codificada, possui interrupções horríveis devido às degradações.

17 17 Um MOS de 5 indica qualidade perfeita, um valor 4 ou maior representa alta qualidade. Um MOS acima de 4 significa que as pessoas submetidas ao teste acham a fala tão inteligível quanto a original e sem quaisquer distorções. Valores de MOS entre 3 e 4 são conhecidos como qualidade de comunicação. Nessa faixa, a distorção está presente, mas não é óbvia, e a inteligibilidade é ainda alta. Valores de MOS entre 3.5 e 4 representam uma qualidade do nível de comunicação bastante utilizada. No fim da escala está a qualidade artificial, típica dos vocoders; as palavras, em geral, são inteligíveis, mas o timbre é perdido [MIM98]. 2.1 Comutação de Circuitos X Redes de Pacotes Uma chamada telefônica convencional, utilizando-se a rede pública de telefonia, reserva um circuito entre a origem e o destino durante todo o tempo de duração desta chamada. Este é o funcionamento de uma rede baseada em comutação de circuito. Em uma rede de comutação de pacotes, os circuitos não são reservados entre a origem e o destino. A informação é transmitida pelos circuitos da rede que são compartilhados com outras aplicações. As informações são divididas em blocos, sendo que cada bloco deve incluir dados de origem e destino em um cabeçalho para garantir o roteamento entre origem e destino, e para reconstruir as informações em seu destino [FER98]. As redes de comutação de circuitos oferecem banda dedicada entre os pontos finais, podendo garantir uma qualidade de serviço (QoS), porém os recursos da rede são sub-utuilizados. Com as redes de comutação de pacotes tem-se a utilização eficiente dos recursos da rede. No entanto, são encontradas dificuldades para se garantir a qualidade dos serviços prestados, principalmente para serviços de tempo real. 2.2 Transmissão de Voz sobre Redes de Pacotes Voz sobre redes de pacotes está crescendo a cada ano. Em 1995 foi demonstrada uma chamada telefônica utilizando-se a Internet, sendo que uma aplicação deste tipo não possui qualidade de voz adequada para satisfazer as necessidades dos usuários comerciais. Para que uma aplicação de voz sobre redes de pacotes possa ter uma boa aceitação comercial, os seguintes parâmetros de qualidade dever ser atendidos: Percentual das chamadas que são completadas (deve ser tipicamente de 95%); Uma vez conectado, não desconecta mais; Qualidade de voz (pontuação MOS acima de 3,7); Baixo atraso e constante; Discagem completa pelo PABX, gerenciamento de chamadas e funções de fax.

18 18 Os parâmetros de qualidade citados acima são os principais oferecidos pela PSTN. Para que uma solução de voz sobre redes de pacotes tenha uma boa aceitação comercial, deve oferecer um serviço de qualidade com as mesmas características [LAR98]. Na tradicional rede de telefonia não existe problema relacionado ao atraso, pois cada chamada utiliza um circuito reservado onde se pode definir qual será o atraso máximo de transmissão. Uma forma de congestionamento seria a condição de todos os circuitos estarem ocupados, sendo que este tipo de congestionamento pode ser resolvido aumentando-se a capacidade dos circuitos atuais com circuitos adicionais. Nas redes de pacotes pode-se citar alguns problemas principais, como o atraso e o congestionamento, perda de pacotes, descarte de pacotes e utilização da banda [KIR98] Atraso Um dos maiores problemas para a transmissão de voz sobre redes de pacotes é o atraso (também chamado de latência), e como conseqüência deste atraso surge o congestionamento. O atraso em redes de pacotes tem duas origens principais: em primeiro, devido aos recursos compartilhados da rede; e em segundo, devido ao processamento que ocorre em cada nó de comutação (roteador) entre a origem e o destino. A tradicional rede de telefonia determina que os humanos podem suportar até aproximadamente 300 milissegundos de atraso antes que o mesmo se torne um incômodo. O atraso está presente em vários pontos de uma rede de pacotes, e dependendo da extensão desta rede, pode-se facilmente exceder este limite de 300 milissegundos [KIR98]. Em uma rede de pacotes existem dois tipos de atraso: o atraso fixo e o atraso variável. O atraso fixo é o tempo necessário para que um pacote seja transmitido desde a sua origem até o seu destino, sendo considerado apenas o tempo de transmissão e os tempos de processamento cujo pacote será submetido. O atraso variável é um atraso adicional devido ao tempo de espera que um determinado pacote fica nas filas dos roteadores devido a congestionamento de um determinado canal de comunicação. Os principais tipos de atraso fixo são os seguintes: [LAR98] Compressão (também chamado de codificação); Empacotamento; Transmissão (tempo de propagação em relação ao canal que interliga um Provedor de acesso a Internet com o backbone da Internet, por exemplo); Rede (tempo de propagação em relação à rede de comutação de pacotes como a Internet, por exemplo); Desempacotamento;

19 19 Descompressão (também chamado de decodificação). A Tabela 2.3 indica os valores típicos para os atrasos fixos [LAR98]: TABELA 2.3 Soma dos atrasos fixos Tipos de Atrasos fixos Mínimo Máximo Compressão 20 ms 45 ms Empacotamento 10 ms 10 ms Transmissão (origem) 0,25 ms 7 ms Rede 20 ms 40 ms Transmissão (destino) 0,25 ms 7 ms Desempacotamento 10 ms 10 ms Descompressão 10 ms 10 ms Total 71 ms 129 ms Considerando todos os atrasos fixos da Tabela 2.3, obtém-se um mínimo de 71 milissegundos e um máximo de 129 milissegundos. Uma chamada telefônica através de uma rede de pacotes, conforme a Figura 2.1, atingindo o máximo de atrasos fixos, ou seja, 129 milissegundos poderá tolerar aproximadamente 170 milissegundos de atrasos variáveis, antes de exceder o limite de 300 milissegundos suportável pelos usuários. Atraso fim-a-fim não pode exceder a 300 ms Rede IP por Exemplo Compressão 20 ms Atrasos Fixos Empacotamento 10 ms Transmissão 0.25 ms p/ E1 7 ms p/ 56K Transmissão 0.25 ms p/ E1 7 ms p/ 56K Desempacotamento 10 ms Descompressão 10 ms Atrasos Variáveis Atraso variável de rede Internet : ms FIGURA 2.1 Atrasos fixos e variáveis Para a utilização de uma rede de pacotes na transmissão de voz tendo como origem e destino da voz um telefone comum, necessita-se de um equipamento para a conexão entre a tradicional rede de telefonia e a rede de pacotes. Este equipamento normalmente adiciona um atraso que pode chegar até 20 milissegundos. Analisando o cenário da

20 20 Figura 2.1, e considerando um atraso fixo máximo de 129 milissegundos, adicionando a este atraso fixo o tempo adicional de 20 milissegundos correspondente ao equipamento de conexão das redes, o atraso referente a rede de transmissão (Rede IP no exemplo da Figura 2.1) não deve exceder a aproximadamente 150 milissegundos. Se a rede de pacotes utilizada for a Internet, o atraso é altamente variável podendo variar entre 50 e 400 milissegundos, podendo até ultrapassar este limite, o que torna a Internet uma alternativa inviável para aplicações de voz sobre redes de pacotes [KIR98]. A Internet, que está estruturada na arquitetura TCP/IP foi originalmente desenvolvida para aplicações de dados que não necessitam de tempo de resposta instantânea, como é necessário para uma aplicação de voz. Deste modo, não existia preocupação, na época de sua criação, com eficiência da banda de rede e o cabeçalho de um pacote IP é tipicamente de 24 bytes. Comparando um pacote IP de 24 bytes com um pacote frame relay, por exemplo, que utiliza 4 bytes de cabeçalho, observa-se que realmente existe um overhead associado ao protocolo TCP/IP. Na prática, transmissão de voz sobre IP necessita significativamente de mais banda que transmissão de voz sobre frame relay, o que torna a rede IP mais suscetível a congestionamentos e atrasos. Devido a variabilidade do atraso associado à Internet de hoje, torna-se impossível o uso de uma solução VoIP empresarial. No entanto, uma rede IP privada corretamente dimensionada oferece condições para que uma aplicação VoIP possa ser devidamente utilizada. A redes IP privadas podem ser projetadas para terem baixo atraso, porém, devido ao overhead gerado pelo cabeçalho do protocolo e falta de QoS, portanto, as redes IP necessitam de mais banda de rede e de menos aplicações competindo por esta mesma banda [KIR98] Perda de Pacotes Um pacote é perdido quando, ao chegar em um nó de comutação (roteador), este equipamento esta com fila de chegada cheia, provavelmente devido a congestionamento. Não tendo onde armazenar mais pacotes, o roteador começa a descartar os pacotes que chegarem [KIR98]. Na Internet, o protocolo TCP, responsável pela camada de transporte, retransmite automaticamente os pacotes perdidos, mas essa retransmissão não é possível em aplicações de voz, pois tudo deve ser tempo real. Em uma aplicação de voz, perdas de pacotes inferiores a 5% não são percebidas pelos usuários. Entre 5% e 10% podem ser percebidas mas toleráveis, desde que métodos de correção de erros foram implementados nos roteadores. Acima de 10% de perda de pacotes, geralmente não são toleráveis pelos usuários em uma aplicação de voz sobre redes de pacotes. Durante horários de pico da Internet, a taxa de perda de pacotes pode exceder a 20% Descarte de Pacotes O descarte de pacotes acontece em aplicações de voz quando os pacotes chegam ao destino, mas devido aos congestionamentos e atraso nas redes, estes pacotes chegam

21 21 com um tempo superior ao limite da aplicação de voz. Normalmente, a voz tem uma tolerância de atraso em torno de 10 ms a 300 ms, os pacotes que chegarem com um tempo superior a esta tolerância serão descartados, pois provavelmente um pacote anterior já tenha sido processado e para uma aplicação de voz este pacote muito atrasado será descartado. Para a aplicação, um pacote descartado. têm o mesmo efeito que um pacote perdido Utilização da Banda Normalmente, as organizações possuem uma rede para voz e outra rede para dados. O projeto de integração das redes de voz e dados sempre visa economizar recursos para as organizações. Porém, se as organizações não prepararem um bom projeto para esta integração, poderão precisar de um total de banda superior ao que já possuem e ao invés de economizar, poderão gastar mais ainda, ou então ter os mesmos custos com um serviço de voz inferior ao que utilizavam [KIR98]. O projeto de integração das redes de voz e dados deve ter uma preocupação especial para redes IP, onde o overhead gerado pelo cabeçalho do protocolo TCP/IP aumenta a carga da rede para aplicações de voz, e como conseqüência disto, pode-se ter banda insuficiente, que é a principal causa de congestionamentos, atrasos e perda de pacotes. 2.3 Codificadores de Voz Desde a invenção do telefone, em 1876, as necessidades das comunicações a longa distância têm crescido, sendo o serviço de voz o mais comum nas redes de telecomunicação. O desenvolvimento das tecnologias digitais, nas últimas décadas, criou novos tipos de serviços, incluindo as Redes Digitais de Serviços Integrados para transmissão de voz, imagens e dados, as redes telefônicas digitais e o telefone móvel com transmissão digital. A grande utilização de computadores também faz supor que, no futuro, a interação homem-máquina poderá também ser realizada através da voz. Por todos esses motivos, os estudos em processamento digital de voz têm sido muito importantes, atingindo tradicionalmente as áreas de codificação, reconhecimento e síntese da voz. FIGURA 2.2 Sequência de codificação da voz

22 22 Por codificação digital de voz, entende-se sua representação binária com o compromisso de manter a menor taxa de codificação possível e a melhor qualidade do sinal sintetizado. Além da digitalização da voz, para que o sinal digitalizado possa ser transmitido através de uma rede de pacotes, há a necessidade de outras técnicas de tratamento de voz, tais como: compressão, supressão do silêncio e cancelamento de eco. A seqüência de codificação da voz pode ser observada na Figura 2.2. As técnicas de compressão de voz são padronizadas pela União Internacional de Telecomunicações, setor de padronização das telecomunicações conhecido como ITU-T (International Telecommunication Union Telecommunication Standardization Union). Os principais codificadores definidos pelo ITU-T são os seguintes: G.711 Descreve o padrão PCM (Pulse Code Modulation) de 64 Kbit/s, é utilizado para uso de voz digital em centrais PABX ou redes públicas de telefonia. G.726 Descreve o ADPCM (Adaptive Differential Pulse Code Modulation) em formatos de 40, 32, 24 e 16 Kbit/s, também pode ser usado em redes públicas ou PABX s, desde que os equipamentos envolvidos tenham esta capacidade. G.728 Descreve o padrão LD-CELP (Low-Delay Code-Excited Linear Prediction) de 16 Kbit/s para redes com baixo atraso. Deve ser convertido para um dos padrões acima para ser usado em redes de telefonia ou PABX s. G.729 Descreve o padrão CS-ACELP (Conjugate-Structure Algebraic- Code-Excited Linear Prediction) de 8 Kbit/s, sendo que existem duas variantes (G.729 e G.729 a ) com uma grande diferença de complexidade computacional entre elas. G Descreve uma técnica de compressão para voz e outros sinais de áudio para serviços multimídia, videoconferência e telefonia móvel digital a uma taxa de 5.3 ou 6.3 Kbit/s. Para obter um consenso de qualidade dos algoritmos padrões, são necessários procedimentos que consistem em uma seleção baseada em aspectos subjetivos que envolvem o cálculo da qualidade da voz, como por exemplo, o MOS, citado anteriormente no inicio deste capítulo, e testes de laboratórios objetivos visando definir a taxa de bits gerada pelo algoritmo de codificação de voz, realizados em protótipos. TABELA Principais codificadores do ITU-T Codificador Taxa de Bit por segundo Pontuação MOS Atraso de codificação G Kbit/s ms G Kbit/s ms G Kbit/s a 5 ms G Kbit/s ms G.729 a 8 Kbit/s ms G Kbit/s ms

23 23 A Tabela 2.4 a seguir, apresenta os principais codificadores definidos pelo ITU-T, a taxa de bit utilizada por segundo, a pontuação referente ao MOS e o tempo gasto para a codificação da voz.

24 24 3 Serviço de Voz sobre a Arquitetura TCP/IP TCP/IP é uma tecnologia de rede simples popularizada entre computadores com o sistema operacional Unix e a Internet. Atualmente o TCP/IP está presente na maioria dos sistemas operacionais de rede e é utilizado por muitas empresas em uma variedade de aplicações. TCP/IP é, especificamente, um protocolo de comunicação de dados projetado para aplicações não sensíveis ao atraso, tais como , web, ftp, etc. Devido a imprevisibilidade do atraso dos pacotes, os protocolos da camada de transporte do TCP/IP (tanto o TCP como o UDP), não são adequados para aplicações de voz em tempo real [KAT 99]. O TCP (Transport Control Protocol) não suporta transmissão de voz em tempo real porque utiliza um mecanismo de recuperação dos dados perdidos por retransmissão; assim, no caso da perda de um pacote, a liberação dos dados para a aplicação deve esperar por todas as retransmissões, o que acarretaria atrasos intoleráveis. Já o protocolo UDP (User Datagrama Protocol) evita este problema, pois fornece um serviço de datagrama, no entanto, tem como grande desvantagem o fato de não ser confiável [LIU 99]. Voz sobre IP é um conceito relativamente simples. Basta transformar a voz em um fluxo de bits que pode ser constante (CBR) ou variável (VBR), dependendo do codec (codificador/decodificador). O fluxo de bits assim obtido é encapsulado em datagramas do UDP, que por sua vez são encapsulados em pacotes IP como é mostrado na figura 1 [JAI 98]. Os pacotes IP assim obtidos são transportados pela rede, como qualquer pacote de dados IP, sem qualquer distinção. Foi esta relativa simplicidade que estimulou fortemente muitos usuários a implementar serviços de voz e dados dentro de seus ambientes de rede. Aplicações de voz em tempo real, baseadas no protocolo IP, já são uma realidade em muitas empresas, desde que nestas redes seja possível exercer um controle sobre os seus roteadores, sob forma de um tratamento privilegiado dos pacotes de voz IP o que, porém, não é possível quando se trata da Internet comercial [CAL 99]. A escolha do codificador de voz (codec) é fundamental para o sucesso da aplicação VoIP [COX 96]. Os codecs modernos são inteligentes e executam funções sobre o fluxo de dados de voz como: compressão, supressão de silêncio e cancelamento de eco, o que faz com que o fluxo na saída do codec seja normalmente do tipo VBR. O fluxo na saída de um codec de voz se apresenta sob forma de conjuntos de pacotes de tamanho fixo, emitidos segundo uma cadência constante, o que caracteriza um serviço do tipo ON/OFF em rajada. Um conjunto de pacotes (rajada) é emitido seqüencialmente segundo uma taxa máxima, o que determina o período de ON do serviço. Uma vez emitido um conjunto de pacotes de tamanho fixo, haverá um período de inatividade até que seja emitido o próximo conjunto de pacotes - o que caracteriza o período de OFF do serviço (conferir figura 5.10). Um exemplo de um codificador com estas características é o codificador G.729 do ITU-T, que apresenta uma qualidade de voz boa, com uma pontuação MOS 1 de 3.92 [MIN 98] e uma taxa de bit média baixa de apenas 8 kbit/s [ITU 96]. 1 MOS (Mean Opinion Score) é uma medida de qualidade da voz amplamente aceita em telefonia que varia entre 1 (ruim) a 5 (excelente).

25 25 O transporte dos pacotes de voz deve ser realizado pela rede segundo exigências específicas deste serviço, também conhecidas como parâmetros de QoS da aplicação [ROC 98]. As redes IP não oferecem nenhum tipo de QoS as suas aplicações, o que é considerado atualmente o principal empecilho para as aplicações multimídia. 3.1 Encapsulamento de voz sobre IP A arquitetura TCP/IP possui dois protocolos de transporte, o TCP que implementa uma conexão confiável e o UDP que não é confiável, mas gera menos overhead que o TCP. Para aplicações VoIP, os pacotes perdidos não devem ser transmitidos novamente, e os pacotes que chegarem fora de ordem devem ser descartados, portanto é melhor utilizar o protocolo UDP para o encapsulamento de aplicações VoIP [LUI97]. O primeiro passo é a codificação da voz, gerando um fluxo de bits que pode ser contínuo ou variável. Este fluxo de bits assim obtido é encapsulado em datagramas do UDP que por sua vez, serão encapsulados em datagramas IP para a transmissão pela rede, conforme Figura 3.1 [JAI98]. Observando a Figura 3.1 nota-se que o encapsulamento introduz atraso para o serviço de voz. O atraso de encapsulamento é em torno de 10 ms, que somado ao restante dos atrasos envolvidos para a transmissão de voz pode chegar a aproximadamente 120 ms conforme visto na seção do capítulo anterior. Feixe de bits de áudio Codificação (G.729) Pacotes UDP Pacotes IP FIGURA 3.1 Encapsulamento de voz 3.2 Problemas na Transmissão de Voz sobre IP A arquitetura TCP/IP foi desenvolvida para aplicações de dados. As aplicações de dados não necessitam de tempo de resposta instantânea, como são necessárias para as aplicações de voz, sendo que as aplicações de dados podem tolerar atrasos da ordem de 500 ms ou mais, sendo que esta tolerância depende da paciência do usuário que está utilizando a aplicação. Outro fator importante é que a premissa básica que a arquitetura

26 26 TCP/IP deve atender foi o requisito de poder ser utilizada com os diversos tipos de meios físicos e tecnologias existentes na época de sua criação, quando se pensava em IP sobre Tudo de forma a viabilizar a comunicação entre as aplicações fim-a-fim em rede. Considerando estes fatos, as decisões sobre a arquitetura TCP/IP tomadas na concepção do protocolo IP foram, na sua maioria, no sentido da simplicidade visando obter o cenário imaginado na época para sua implantação em termos de rede. Este paradigma de concepção impõe algumas restrições técnicas ao IP e, por conseqüência, restringe as aplicações suportadas às aplicações com poucos requisitos de operação, como é o caso das aplicações de dados, que podem perder pacotes e permite a existência de atrasos, entre outras características [MAR99]. Uma outra dificuldade que aparece na transmissão de mídias que exigem cadência, como voz, é que os serviços prestados pelas redes IP (atualmente Ipv4) são do tipo melhor esforço (best effort). Assim, todos os pacotes são tratados de forma igual, sem nenhuma discriminação entre os diversos tipos de tráfego, nem atribuições de prioridades aos pacotes. O escalonamento é feito baseado em filas FIFO (First In First Out), onde, se houver espaço nos buffers dos roteadores, o pacote é armazenado para transmissão e, caso contrário, ele é descartado [LAR98]. Outro problema apresentado pela arquitetura TCP/IP é o tamanho de seu cabeçalho, gerando um aumento significativo nos dados que são transmitidos pela rede. Por exemplo, uma aplicação de Voz sobre IP utilizando um codificador G.723 que gera uma taxa de 5 Kbit/s, gera pacotes UDP encapsulados em pacotes IP (conforme seção anterior) com um tamanho total do pacote IP de 61 bytes conforme Figura 3.2. Destes 61 bytes, 20 bytes são destinados ao cabeçalho IP, mais 4 bytes são do cabeçalho UDP, sendo o restante destinado para a área de dados, que neste caso é um pacotes de voz D C6-6B-C8-D2-D7-B4-C8-D2-D7-B8-C1-C6-C1-C CE AD-ED AB-60-4D-D6-DF-98-0B-F6-1E-EA-6C-A8-B A4-3C-F3-C C4-1A-C1-0B Sombreamento Cinza...: Cabeçalho IP e UDP Letras com tonalidade forte...: Cabeçalho IP Letras com tonalidade média...: Cabeçalho UDP Letras com tonalidade fraca...: Área de Dados FIGURA 3.2 Pacote IP Capturado pela Ferramenta ETHLOAD originado por uma Aplicação de Voz

27 27 Detalhando o cabeçalho UDP podemos verificar que o tamanho total deste datagrama é de 41 bytes, menos 4 de seu cabeçalho, nos resta 37 bytes de dados. Finalmente podemos observar que, do tamanho total do pacote IP, ou seja, 61 bytes, apenas 37 bytes são dados que serão utilizados pela aplicação e o restante são dados que poderiam ser minimizados caso a aplicação de voz utilizasse um outro protocolo como por exemplo Frame Relay que utiliza apenas 4 bytes de cabeçalho. Outros fatores críticos para a transmissão de voz sobre IP são: o congestionamento; e o atraso. O protocolo UDP utilizado para a transmissão de voz não possui nenhum tipo de controle de congestionamento, e o congestionamento pode gerar atraso além do esperado, inviabilizando o serviço de voz sobre IP. O atraso pode ser controlado, uma vez que, a aplicação de voz sobre IP esteja em funcionamento dentro de uma rede IP privativa, apesar de a arquitetura TCP/IP não ser a mais eficiente para a transmissão de voz, devido ao volume de dados adicionais de seus cabeçalhos. Devido ao congestionamento e ao atraso, é fundamental considerar as perdas e descartes de pacotes existentes na rede. Para o tráfego de voz codificado sem compressão, elas não são tão importantes, porém necessita de maior banda. Contudo, ao comprimir-se a voz, aumenta-se a sensibilidade em relação às perdas. Para se obter uma maior garantia, é necessária uma banda maior disponível, bem como uma melhoria no tempo de processamento dos roteadores. 3.3 Problemas com a falta de QoS Qualidade de serviço (QoS) é a capacidade da rede garantir que tráfego e serviços solicitados por uma determinada aplicação, como por exemplo uma aplicação VoIP, possam ser satisfeitos. A fim de permitir o QoS exigido, todas as camadas e elementos da rede deve cooperar. O QoS assegurado é tão bom quanto for a qualidade garantida pela ligação mais fraca da rede entre a origem e o destino. QoS não aumenta a capacidade de banda, atua apenas gerenciando os recursos de banda de acordo com a demanda das aplicações e as características da rede. Assim, a qualidade de serviço é gerenciada através de alocações de recursos da rede para fluxos de dados específicos, como por exemplo, fluxos de áudio. A banda alocada para uma aplicação VoIP não está mais disponível para ser utilizada por aplicações de dados convencionais. Considerando que a banda é um recurso finito, uma das prioridades do QoS para redes IP é assegurar que o tráfego utilizado pelas aplicações de dados convencionais possa continuar funcionando mesmo com as alocações de banda. No pior caso, a aplicação de dados convencional deve ficar apenas mais lenta, mas deve continuar funcionando. O padrão dominante para transmitir serviços multimídia em redes de pacotes como IP é a Recomendação H.323 do ITU-T, [THO96], [ITU96a], que sugere para o encapsulamento do serviço de voz a utilização da pilha de protocolos IP/UDP/RTP. No entanto, o H.323 não fornece qualquer garantia de QoS, especifica apenas, como um protocolo de transporte confiável como o TCP, pode ser utilizado para transmissão de informações de controle destes serviços [KOS98].

28 28 No âmbito do IETF, atualmente estão sendo discutidas cinco abordagens para o oferecimento real de QoS pela Internet [XIA99]: A arquitetura de serviços integrados (IntServ) [BRA94], que utiliza o protocolo RSVP [BRA97]] para reserva de recursos, a Arquitetura de Serviços Diferenciados (DiffServ) [BLA98], o MPLS (Multiprotocol Label Switching) [ROS99] [CUN99]; o Roteamento com QoS [CRA98] e a Engenharia de Tráfego [KAM2000]. Destas abordagens, a arquitetura de serviços integrados com RSVP e a arquitetura de serviços diferenciados (DiffServ), são as que oferecem as melhores perspectivas quando se quer implementar serviços multimídia com QoS efetivo em redes corporativas com abrangência limitada.. Neste trabalho, será detalhado o protocolo RTP e enfatizadas duas dessas abordagens: RSVP e o DiffServ. O objetivo deste trabalho não é realizar testes com estes mecanismos que visam oferecer QoS para uma rede IP, apenas cita-se quais os principais mecanismos que estão sendo pesquisados e que se referem ao estado da arte neste assunto RTP O protocolo RTP (Real Time Protocol) [SCH96] é um mecanismo genérico para suportar a integração de voz, vídeo e dados e foi definido pela RFC 1889 [SCH96]. Sua função principal é agir como uma interface melhorada entre as aplicações de tempo real e os protocolos das camadas já existentes [LUI99]. De maneira geral, o RTP tenta, mas não garante o fornecimento de pacotes no tempo desejado ou de acordo com uma qualidade de serviço especificada. O cabeçalho do RTP fornece o número de seqüência e a informação de tempo através de uma etiqueta de tempo (time-stamp) que é necessária para a remontagem do fluxo de tempo real a partir dos pacotes IP recebidos. O protocolo, no entanto, não assegura que os pacotes sejam entregues em ordem, nem tão pouco oferece uma garantia de tempo de entrega dos pacotes, o que o torna pouco confiável. [IET96]. As aplicações que necessitam dados em tempo real rodam o RTP no topo do protocolo UDP, como parte do protocolo da camada de transporte. O formato de um pacote IP contendo dados RTP é mostrado na Figura 3.3. Cabeçalho IP Cabeçalho UDP Cabeçalho RTP Área de dados do RTP FIGURA 3.3 Dados RTP em um pacote IP RSVP O protocolo RSVP funciona no topo do protocolo IP, na camada de transporte. É um protocolo de controle comparável com o ICMP (Internet Control Message Protocol) ou IGMP (Internet Gateway Message Protocol), [MIN98a], [ZAP98]. O RSVP foi projetado para funcionar com os protocolos de roteamento considerando um único

29 29 transmissor e um grupo de receptores. Algumas aplicações são direcionadas para apenas um Receptor enquanto que outras aplicações possam enviar dados a mais de um Receptor sem ter que enviar para a rede inteira [NOR98]. Os componentes do RSVP são: o Transmissor, o Receptor e os roteadores entre a origem e o destino. O Transmissor é quem conhece o Receptor e tem dados a serem transmitidos e que necessitam de QoS. O Receptor envia notificações para os roteadores se prepararem para a chegada dos dados. Estes roteadores reservam os recursos. Uma vez que estes passos são completados, o Transmissor pode enviar os dados com sucesso, como demonstrado na Figura 3.4. Com o RSVP, a aplicação é capaz de notificar antecipadamente qual o recurso da rede que será necessário. Para garantir a reserva, os roteadores envolvidos se comprometem a oferecer estes recursos. Se o roteador não é capaz de oferecer estes recursos, ou se os recursos não estão disponíveis, ele pode recusar a reserva. A aplicação é imediatamente notificada que a rede não suporta os recursos necessários, evitando assim tempo e custo de uma tentativa e erro. Os dois conceitos principais do protocolo RSVP são: 1. Fluxos: Fluxo é o tráfego contínuo desde o transmissor até um ou mais receptores. Um fluxo é identificado por um nome do fluxo no cabeçalho IP básico. Antes de determinar um fluxo, o transmissor transmite uma mensagem de caminho destinada ao receptor. A mensagem contém o endereço IP de origem, o endereço IP de destino e uma especificação do fluxo. A especificação do fluxo, composta da taxa e atraso para o fluxo, é o QoS que o fluxo precisa. A mensagem de caminho é roteada até o receptor pelos roteadores ao longo do caminho do fluxo [NOR98]. 2. Reserva: O receptor recebe a mensagem de caminho e é responsável por fazer a reserva. Com o receptor efetuando a reserva, existe uma maior flexibilidade em manipular um fluxo com vários receptores. Este modelo básico de receptor permite uma solução distribuída possibilitando receptores heterogêneos a realizar reservas de acordo com suas necessidades [NOR98]. A Figura 3.4 mostra um exemplo de como o protocolo básico do receptor é eficiente para ambientes de redes heterogêneas. Neste exemplo, o transmissor transmite uma mensagem de caminho para vários destinatários. Os dois receptores que pertencem ao grupo de destino pertencem a diferentes tipos de rede. O receptor A é diretamente conectado a uma rede ATM, enquanto que o receptor B está conectado a uma rede token ring. Considerando que uma rede fast ethernet seja o link mais lento no caminho do receptor A, a vazão limite é 100 Mbit/s. O link mais lento do receptor B é a rede token ring com um limite de 16 Mbit/s. Se um fluxo padrão de vídeo requer 30 Mbit/s de banda, o receptor A pode aceitar a capacidade total do fluxo. O receptor B, por outro lado, pode necessitar o uso de métodos de codificação que poderá sacrificar alguma qualidade para permitir que a banda existente aceite a conexão. Como o QoS é definido pelo transmissor na

30 30 especificação do fluxo, mas a reserva é efetuada pelo receptor, neste caso ele poderá aceitar o fluxo [NOR98]. Estação de Vídeo Roteador Rede ATM Roteador Token King Receptor A Receptor B FIGURA Redes heterogêneas Se o transmissor fosse realizar as reservas, teria que conhecer as características de todos os possíveis receptores. Com a abordagem deste exemplo, cada receptor necessita compreender somente as suas capacidades. Uma vez que o receptor recebe a mensagem de caminho, ele envia uma requisição de reserva alertando cada roteador existente na rede por onde passará o fluxo de dados. A requisição inclui o endereço IP de origem, endereço IP de destino, a especificação de fluxo e dois módulos de decisão: controle de admissão e controle de política. O controle de admissão determina quais dos nós têm recursos disponíveis suficientes para satisfazer o QoS definido pela especificação de fluxo. O controle de política determina se o usuário tem permissão administrativa para realizar a reserva. Se ambos, os controles forem realizados com sucesso, parâmetros são enviados para os roteadores reservando o QoS necessário. Se um dos dois controles falhar, a aplicação é notificada, e a reserva não é realizada. Aplicação necessita de 2 mbps e 100 ms de atrazo Ok, banda suficiente disponível Aplicação necessita de 2 mbps e 100 ms de atrazo Ok, banda suficiente disponível Ok, banda suficiente disponível Todos os lugares reservados, transmitir pacotes 2 mbps reservados 2 mbps reservados 2 mbps reservados 2 mbps reservados FIGURA 3.5 Protocolo de Reserva de Banda

31 31 Uma vez que o transmissor recebe a confirmação de reserva do receptor, a aplicação envia o fluxo, e a rede é quem deve atender os requisitos de QoS necessário. Para assegurar reservas, é preciso que todos os movimentos e alterações da rede estejam cientes da reserva, para efetuar isto, o RSVP incorpora um método chamado estado soft. Este termo é devido aos caminhos e reservas do RSVP serem consideradas tentativas. Os recursos são colocados à disposição do roteador para aceitar uma reserva, mas se um fluxo não é recebido, poderá esgotar o tempo e este recurso se tornar livre. Com o método estado soft, o transmissor periodicamente envia mensagens de caminho e o receptor continua a enviar os requerimentos de reserva para confirmar se o tempo não se esgotou ou se alguma alteração pode ter ocorrido [NOR98] DiffServ Abreviatura de Serviços Diferenciados (do inglês Differentiated Services), o DiffServ é uma arquitetura que permite à rede oferecer diferentes níveis de qualidade de serviço. Utiliza-se do campo Tipo de Serviço (Type of Service ToS) do cabeçalho IP para atribuir diferentes prioridades aos pacotes. O tráfego da rede é classificado segundo o ToS e os recursos da rede são divididos de acordo com critérios de políticas de gerenciamento de rede. A fim de permitir a qualidade de serviço, é utilizada uma política de filas nos roteadores dando tratamento especial para as aplicações classificadas como preferenciais ou que requerem maior demanda de banda. O DiffServ implementa basicamente dois tipos de serviços: o Expedited Forwarding (EF) e o Assured Forwarding (AF) [NIC99]. O tipo de serviço EF surgiu das novas necessidades comerciais e não tem por objetivo substituir os serviços normais da Internet, que são os serviços convencionais que não necessitam de QoS. Pode ser oferecido junto com o best-effort e consiste na alocação de uma pequena porcentagem da banda a um custo elevado. Cria-se, assim, um canal virtual sem a necessidade de se construir uma nova rede. Quando a sua banda não está sendo utilizada ela é aproveitada pelos demais serviços da Internet. Este tipo de serviço é controlado conforme uma taxa de bit/s e uma taxa de pico contratada, caso esta seja ultrapassada o excesso não é introduzido na rede. Em contra partida, a rede garante que a banda contratada estará disponível para o envio de tráfego quando necessário. Em comparação com os serviços convencionais, que é um fluxo em rajadas e necessita de filas para o gerenciamento de congestionamentos, o EF foi desenvolvido para possuir um tráfego regular que necessita de pouca ou nenhuma utilização de buffers. A criação deste serviço requer duas necessidades principais [NIC99]: Configurar os nodos da rede de forma que o tráfego tenha um mínimo de tempo de saída;

32 32 A taxa de chegada de um nodo deve ser menor que o seu tempo mínimo de saída. A primeira necessidade é garantida pela especificação do EF e a segunda deve ser garantida pelas políticas de controle entre domínios. O primeiro elemento da rede deve marcar os pacotes com o EF bit caso este se enquadre na especificação, e gerenciar o tráfego e o envio de tais pacotes, conforme Figura 3.6. A classificação de um tráfego pode ser feita através de qualquer combinação dos campos do cabeçalho. E com base nesta classificação será atribuído o bit de EF. Entrada de Pacote Esperando por Recursos Marque com bit P Saída de Pacote FIGURA 3.6 Marcação dos pacotes EF Os roteadores devem possuir basicamente duas filas de prioridade, os pacotes marcados com o EF bit serão enviados primeiros. Os pacotes normais não estarão marcados e serão enviados com uma prioridade inferior. O resultado é a criação de duas redes virtuais: uma é igual a Internet atual utilizando-se de buffers para gerenciar as rajadas e os congestionamentos, a outra possui tráfego limitado e regular conforme um contrato de uso, o que permite que seu tráfego praticamente não tenha atraso nem perdas devido aos buffers [NIC99]. A política de controle deste serviço entre os diversos domínios da Internet é de fundamental importância para o seu correto funcionamento. Ao entrar em um novo domínio, a prioridade do pacote vai ser verificada e comparada com a taxa acertada entre os dois domínios, descartando-se pacotes que estejam em excesso ou alterando a sua prioridade conforme o caso. Assim, é de interesse dos domínios manter as taxas acertadas previamente para não correr o risco de perder pacotes. O serviço EF por garantir taxa e banda sem atraso tem um enorme campo de utilização por parte de aplicações comerciais como vídeo sob demanda, voz sobre IP, VPN s, entre outras. Contudo, ele é extremamente rígido e caro. O outro tipo de serviço, o AF, implementa um serviço mais flexível e barato. O serviço contratado possui as mesmas características de atraso que os serviços convencionais, só que com uma maior garantia de entrega. Além disso, o serviço permite que taxas acima das contratadas sejam utilizadas sem que nenhuma penalidade seja aplicada, contudo o serviço não garante a entrega, ou seja, pode ocorrer perda de pacotes. São definidas quatro classes de serviços AF. Cada classe possui recursos distintos como tamanho de buffer e banda. Dentro das prioridades de cada classe, os pacotes ainda podem ser classificados em relação a três níveis de importância. No caso de um

33 33 congestionamento, os pacotes com menor importância dentro de uma determinada classe serão excluídos. Assim, a garantia de entrega de um pacote depende de [NIC99]: A quantidade de recursos alocados para a classe de um determinado pacote; Qual é a carga da classe, e em caso de congestionamento; Nível de importância do pacote. Não existe Recurso Entrada de Pacote Verifica se existe Recurso Recurso OK Marque com bit A Saída de Pacote FIGURA 3.7 Marcação dos Pacotes AF O primeiro elemento da rede deve realizar a classificação dos pacotes e possuir um mínimo de recursos para cada classe AF, conforme Figura 3.7. As classes AF podem receber taxas maiores que as especificadas desde que recursos adicionais estejam disponíveis. A política de controle do AF acertada entre os diversos domínios pode permitir a mudança do nível de importância, a mudança de classe AF de um pacote e ainda o descarte de pacotes. A vantagem do AF em relação ao EF está no seu menor custo e na possibilidade de ocorrerem excessos no envio de pacotes sem nenhuma perda para o usuário do serviço. As desvantagens seriam um maior atraso e a possibilidade de perda de pacotes caso o usuário ultrapasse a taxa contratada [NIC99]. Para que o DiffServ possa funcionar, existe a necessidade de adequar os roteadores para esta finalidade. Existem basicamente dois tipos de roteadores diferenciais. Os roteadores que ficam nos limites de um domínio e os roteadores internos de um mesmo domínio. Os roteadores de limites de um domínio são aqueles responsáveis por interconectar duas redes distintas, ou seja, que não possuam a mesma administração, enquanto que os roteadores internos são aqueles que se comunicam com elementos de uma mesma rede. Os roteadores internos basicamente possuem a única função de classificar os diversos fluxos de dados que estão roteando e dar-lhes a devida prioridade no roteamento. Existem dois tipos de classificação, um tipo leva em consideração apenas o campo do cabeçalho do pacote, sendo assim, os pacotes marcados como EF devem ser enviados mais rapidamente que os marcados como AF e estes devem ter maior prioridade que os pacotes convencionais. Outro tipo de classificação leva em consideração a combinação de vários valores do cabeçalho do pacote como protocolo utilizado, porta de destino, de origem, entre outros.

34 34 Os roteadores de limite além de realizarem a classificação dos pacotes, conforme Figura 3.8, também são responsáveis pela verificação e correção do tráfego entre domínios de acordo com o contrato de serviço acertado entre ambos [NIC99]. Fluxo 1 Marcados como 1... Fluxo n... Marcados como n Chegada de Pacote Remover bits A & P Classificar Pacote Tráfego convencional Encaminhame nto de Pacotes FIGURA 3.8 Funções de um Roteador de limite Quando um pacote chega ao roteador, o mesmo é classificado quanto a sua prioridade. Depois de ser classificado, o pacote é verificado junto a um banco de dados para ver se ele está dentro do contrato firmado, ou seja, se o fluxo de dados está dentro dos parâmetros de tráfego. Após a verificação, uma ação é tomada dependendo se o tráfego está dentro dos parâmetros acertados ou não. Caso o fluxo de dados esteja correto, o pacote é marcado com as devidas prioridades dentro do novo domínio. Assim, existe um mapeamento de prioridades dentro do roteador limite entre diferentes domínios, uma vez que redes distintas não necessitam implementar os mesmos tipos de prioridades. Se os dados não conferem com o serviço contratado, então as punições acordadas são tomadas. Estas vão desde a mudança de prioridade até o descarte de pacotes. O domínio de um serviço diferenciado é dado por um conjunto de nodos que implementam as mesmas regras de classificação, verificação e correção de tráfego. A fim de garantir este tipo de serviço umas séries de primitivas são necessárias [NIC99]: Classificador é o mecanismo responsável pela classificação dos pacotes e pela correta fixação de suas prioridades conforme a banda disponível. Consome muita memória e processamento, por isso é mantido nos extremos da rede onde existem menos fluxos de dados; Filas de Prioridade todos os elementos da rede devem possuir filas para os diversos tipos de prioridades possíveis;

35 35 Shaping os pacotes só podem ser marcados com prioridade EF ou AF caso existam ainda recursos disponíveis para tais fluxos de dados. Caso contrário os pacotes devem esperar até que os recursos necessários sejam liberados; Correção caso não haja recursos disponíveis e pacotes marcados com EF e AF sejam recebidos acima dos limites estabelecidos, as devidas punições devem ser tomadas: exclusão de pacotes ou remarcação de prioridade. Como visto anteriormente, as filas de prioridades são implementadas por todos os roteadores. E o shaping e a correção são implementados pelos roteadores de limite. Fica Ficam restando os classificadores de tráfego. Os classificadores de tráfego são responsáveis pelo controle de alocação de banda de um certo domínio. Este controle pode ser feito independentemente pelos diversos usuários que então especificam que pacotes são mais importantes para eles, ou pode ser feito por um agente que tenha conhecimento das prioridades e das políticas da empresa. Como os usuários nem sempre conhecem as reais necessidades da empresa, normalmente as classificações de tráfego são feitas por um agente. Este agente recebe o nome de Bandwidth Brokers (BB). Os BBs possuem duas responsabilidades, a primeira é a de dividir a banda disponível entre os diversos serviços e usuários e configurar os roteadores para aceitar estes tráfegos. A segunda é a de administrar a alocação de recursos com os domínios vizinhos e seus respectivos BBs. O BB está associado com uma região em particular, sendo um por domínio, possuindo um banco de dados com as informações de quem pode fazer o que e quais os métodos utilizados para a autenticação de requisitos. Apenas o BB pode configurar os roteadores para aceitar tráfegos diferenciados de uma determinada estação. Quando uma determinada estação deseja alocar banda para um determinado fluxo de dados, uma requisição é enviada para o BB. Na requisição está especificados o tipo de serviço desejado, uma taxa de transmissão, uma taxa de rajada máxima e o período de duração do serviço. Esta requisição pode ser feita manualmente pelo administrador da rede ou por um usuário ou por um BB de um outro domínio. O BB primeiro autentica a requisição e verifica se existe banda suficiente para a alocação. Se existir, a banda disponível é diminuída da banda alocada e salva no banco de dados. Caso o destino seja em um outro domínio, este mesmo processo deve ocorrer nos domínios vizinhos até a estação destino. Existem dois tipos de alocação de banda, uma é estática na qual a alocação é fixa e prédeterminada entre dois domínios vizinhos, neste caso o BB se restringe a alocar banda dentro de sua própria rede. A outra é dinâmica e neste caso existe troca de mensagens entre os BBs das redes envolvidas a fim de alocar banda para um determinado fluxo de dados.

36 36 4 Estudo Experimental O estudo experimental consistiu na definição de um ambiente de teste para avaliar o tráfego de voz sobre uma rede TCP/IP, envolvendo equipamentos de rede, microcomputadores, ferramentas para disponibilizar voz sobre a rede IP e o desenvolvimento de uma ferramenta para análise do tráfego de voz. 4.1 Descrição dos equipamentos do Ambiente de Teste O ambiente de teste foi dividido em três arranjos experimentais, onde cada um foi utilizado para uma seqüência de testes que serão avaliadas no capítulo 5. Nesta seção serão detalhados apenas os equipamentos envolvidos nos arranjos experimentais que são: hubs (3COM OfficeConnect com 8 portas 10BaseT), microcomputadores (Pentium II 266, 96 Mb RAM, 3 Gb HD, Kit Multimídia Criative Lavel), roteadores (CISCO CPA 1005, 1 porta LAN, 1 porta WAN, 2 Mb Memória) e modems (Transcend 33,6 kbit/s). O primeiro arranjo experimental, conforme a Figura 4.1, é composto por uma rede Ethernet de 10 Mbit/s, cinco microcomputadores conectados a esta rede e uma conexão desta rede com a rede da Faculdade de Informática de Presidente Prudente, local onde todos os estudos foram desenvolvidos. Hub Ethernet 10 Rede da FIPP Faculdade de Informática de Presidente Prudente Est. A - Win95 Est. B - Win95 Est. C - Linux Est. D - WinNT Est. E - Win95 FIGURA 4.1 Primeiro Arranjo Experimental Neste ambiente de teste foi alocada uma estação para a origem da voz, outra para o destino e uma terceira para a captura dos pacotes que trafegam pela rede. Foi acrescentado aos pacotes o instante em que eles foram capturados (microsegundo) e mais duas estações para gerar tráfego na rede. Dependendo do tipo de teste a ser realizado, a conexão com a rede da faculdade poderia estar conectada ou não. Este arranjo experimental foi montado para verificar o comportamento de aplicações de voz sobre uma rede Ethernet 10 Mbit/s composta por apenas um domínio de colisão (utilização de hub). O segundo arranjo experimental, Figura 4.2, consiste de duas sub-redes Ethernet 10 Mbit/s, seis microcomputadores, dois roteadores Cisco 1005 com uma porta LAN 10 Mbit/s e uma porta WAN de até 2 Mbit/s cada, além de um par de modems configurados para transmitir a bit/s, e também continuando a possibilidade da conexão com a rede da Faculdade de Informática.

37 37 Com este arranjo experimental é possível observar a qualidade da voz através de uma conexão remota de baixa capacidade de carga, pois a estação com a origem da voz encontra-se em um domínio de rede Ethernet e a estação destino da voz encontra-se em um outro domínio de rede Ethernet interligados através dos roteadores. Foi definida mais uma estação para este arranjo experimental que se encontra no segundo domínio de rede Ethernet, possibilitando gerar tráfego entre as sub-redes e poder observar o comportamento da aplicação de voz (com o enlace exclusivo para voz e com o enlace sendo utilizado para voz e dados). Hub Ethernet 10 Rede da FIPP Faculdade de Informática de Presidente Prudente Est. A - Win95 Est. B - Win95 Est. C - Linux Est. D - WinNT Roteador Modem Est. E - Win Bit/s Est. F - Win95 Hub Ethernet 10 Roteador FIGURA 4.2 Segundo Arranjo Experimental Modem Apesar deste arranjo experimental ter sido configurado com dois domínios de rede Ethernet diferentes, a estação responsável pela captura de pacotes encontra-se conectado em apenas um dos domínios de rede Ethernet. Foi possível verificar, apenas de ouvido, que, quando aumenta o tráfego de dados entre as sub-redes a qualidade da voz fica prejudicada. Era preciso capturar os pacotes nos dois domínios de rede Ethernet. Est. A - Win95 Hub Ethernet 10 Est. C - Linux Est. D - WinNT Est. E - Win95 Est. B - Win95 Roteador Modem Bit/s Est. F - Win95 Hub Ethernet 10 FIGURA 4.3 Terceiro Arranjo Experimental Roteador Modem

38 38 A primeira idéia foi colocar mais uma estação capturando os pacotes também no segundo domínio de rede Ethernet, isso não foi possível devido ao problema de sincronismo entre as duas estações responsáveis pela captura de pacotes necessários para calcular a variabilidade do atraso entre os pacotes. Por se tratar de um estudo experimental e os equipamentos estarem todos dentro da mesma sala, surgiu a idéia de se colocar duas placas de rede na estação que captura os pacotes, ficando esta estação responsável por capturar os pacotes nos dois domínios de colisão, podendo desta maneira verificar a variabilidade do atraso de cada pacotes e também a perda de pacotes devido a congestionamentos. De acordo com esta proposta, o terceiro arranjo experimental foi definido conforme a Figura Descrição das Ferramentas do Ambiente de Teste Em cada arranjo experimental existe uma estação responsável por gerar voz e outra responsável por receber a voz no ambiente. Estas estações têm como sistema operacional o Windows 95, equipadas com kit multimídia e como ferramenta de aplicação de voz sobre IP é utilizado o Microsoft NetMeeting versão 2.2. Esta ferramenta permite ao usuário configurar o padrão de compactação desejado. Nos testes realizados foi utilizado o padrão G.729 do ITU-T conforme pode ser observado na Figura 4.4. FIGURA 4.4 Configuração de Compactação do Microsoft NetMeeting 2.2. Para estabelecer a conexão entre as duas estações utilizando o Microsoft NetMeeting, basta escolher a opção de Nova Chamada, colocando como endereço destino o próprio endereço IP e configurar o campo Chamar Utilizando para utilizar Rede TCP/IP. Estes parâmetros podem ser observados na Figura 4.5.

39 39 FIGURA 4.5 Conexão de uma Chamada do Microsoft NetMeeting O dispositivo de áudio utilizado para gerar e escutar a voz foram o kit multimídia das estações. Após a conexão, o NetMeeting está pronto para começar a enviar e receber voz através da rede de dados. Na Figura 4.6 apresentamos a tela do NetMeeting após a conexão. FIGURA 4.6 Tela do Microsoft NetMeeting pronto para enviar/receber Voz

40 40 Após estabelecer a conexão com o NetMeeting, é possível realizar a conversa, utilizando o microfone do kit multimídia, como se fosse um telefone normal. O NetMeeting, além da compressão da voz, implementa outros recursos para otimizar o uso da banda como por exemplo a supressão do silêncio. O objetivo deste projeto é verificar a utilização da banda simulando a sua utilização durante todo tempo. Desta forma, foi utilizada música que era capturada pelo microfone da estação de origem de voz evitando assim o recurso de supressão de silêncio do NetMeeting. A ferramenta de Análise de Pacotes de Voz foi dividida em duas partes, uma parte funciona em uma estação com o sistema operacional Linux e a segunda parte funciona em uma estação com o sistema operacional Windows 95. Para capturar os pacotes da rede foi desenvolvido um programa utilizando a linguagem C para o Linux. Esta ferramenta captura todos os pacotes IP que estão trafegando pela rede, acrescentando para cada pacote o instante (segundo e micro segundo) em que foi capturado. Para agilizar a captura dos pacotes, é armazenado na memória apenas o cabeçalho dos pacotes acrescido do instante. Para determinar o tempo em que a ferramenta fica capturando pacotes da rede, é definido um número máximo de pacotes que devem ser capturados. Para os testes realizados foram definidos pacotes, que dependendo do tráfego da rede foi possível capturar de 2 a 8 minutos de conversa. Após capturar os pacotes, tudo em memória, foi gerado um arquivo texto com todos os pacotes, que pode ser visualizado na Figura 4.7. A primeira versão desta ferramenta estava preparada para capturar pacotes de apenas um domínio de rede Ethernet. Para capturar pacotes dos dois domínios de colisão não foi preciso grandes alterações nesta ferramenta, pois instalando duas placas de rede em uma estação com Linux e executando a ferramenta, esta captura os pacotes dos dois domínios de colisão ao mesmo tempo. Foi necessário apenas aumentar o número máximo de pacotes, pois os pacotes passaram a ser capturados duas vez, uma vez em cada domínio de rede Ethernet, aumentando assim o número total de pacotes capturado para FIGURA 4.7 Arquivo Texto dos Pacotes Capturados A segunda parte da ferramenta de Análise de Pacotes foi desenvolvida utilizando o ambiente Delphi 3.0. Esta ferramenta é responsável por importar o arquivo texto gerado pela primeira parte, converter os valores de hexadecimal para decimal, filtrar os pacotes de voz através do endereço IP de origem e de destino das estações responsáveis pelo tráfego de voz e gerar os gráficos que auxiliam na interpretação dos resultados.

41 41 O objetivo principal desta ferramenta é calcular o atraso entre pacotes através do instante (segundo e micro segundo) em que foram capturados. É calculado o tempo médio entre os pacotes de cada segundo capturado, sendo considerado somente os pacotes da aplicação de voz obtidos através do filtro de pacotes entre as estações de origem e de destino de voz, gerando um gráfico onde é possível analisar o desempenho da aplicação de voz. A Figura 4.8 mostra um exemplo onde foram capturados pacotes de tráfego geral em 22 segundos, sendo que 776 pacotes foram filtrados como sendo tráfego de voz. A interpretação dos resultados será realizada no próximo capítulo. FIGURA 4.8 Exemplo de um Gráfico gerado pela Ferramenta de Análise. A primeira versão desta ferramenta considerava apenas uma rede Ethernet com um domínio de rede Ethernet, onde era possível calcular o intervalo de tempo entre os pacotes. Na Segunda versão, o arquivo importado tem pacotes duplicados que podem ser obtidos através da identificação de cada pacote IP. Estes pacotes duplicados foram capturados um em cada domínio de rede Ethernet, o que possibilita calcular o tempo gasto para o pacote percorrer o enlace remoto que liga os dois domínios de colisão. Para calcular o atraso basta achar a diferença entre o instante (segundo e micro segundo) que o pacote foi capturado em cada domínio de rede Ethernet, caso o pacote capturado não esteja duplicado, isto significa que o mesmo foi perdido. Além do atraso, é possível calcular o percentual de pacotes perdidos, permitindo, desta forma, identificar se o problema da baixa qualidade de voz é o atraso entre os pacotes ou se é a perda de pacotes. A ferramenta desenvolvida em Delphi possui uma opção para exportar os resultados. Os gráficos, que serão apresentados no próximo capítulo foram gerados pelo Microsoft Excel. Os dados obtidos pela ferramenta de análise foram exportados para o Excel que nos permitiu melhorar a escala de acordo com o tipo de tráfego envolvido. A Figura 4.9 mostra a tela da ferramenta de análise.

42 42 FIGURA 4.9 Tela da Ferramenta de Análise A Figura 4.9 mostra um gráfico do tráfego geral da rede onde a linha cinza representa o tráfego geral (voz + dados) e a linha preta representa o tráfego de voz. A linha preta está muito próxima de zero, e para melhor visualizar o tráfego é necessário diminuir a escala. Esta ferramenta desenvolvida em Delphi utilizou um componente gráfico da Internet e não tem todos os recursos necessários para a análise dos resultados. Para resolver este problema, foi colocados um ícone de uma tesoura na tela da ferramenta, com o objetivo de recortar os dados que geram o gráfico e poder exportar estes dados para uma outra ferramenta, como por exemplo, o Microsoft Excel, o qual foi utilizado para melhorar os gráficos.

43 43 5 Avaliação dos Resultados Experimentais Os resultados experimentais foram obtidos através do tráfego de voz gerado pelo Microsoft NetMeeting e capturados pela Ferramenta de Análise de Pacotes considerando os três arranjos experimentais que foram apresentados no capítulo 4. Para cada arranjo experimental foram realizados vários testes, sendo que em cada teste foi estabelecido um tráfego de dados diferente além do tráfego de voz. Todos os testes descritos neste trabalho foram elaborados 10 vezes, os resultados apresentados tratam de valores médios dos mesmos. 5.1 Primeiro Arranjo Experimental O primeiro arranjo experimental é composto por apenas um domínio de colisão Ethernet de 10 Mbit/s conforme Figura Primeiro Teste Somente tráfego de voz No primeiro teste, o arranjo experimental estava isolado da rede da Faculdade de Informática, sendo que o único tráfego da rede era o tráfego de voz como pode ser observado na Figura 5.1. FIGURA Gráfico da Vazão da Rede com somente Tráfego de Voz A linha preta representa o tráfego geral da rede e a linha cinza o tráfego de voz e como se pode analisar, a linha do tráfego geral é quase a mesma que a linha do tráfego de voz, exceto em alguns instantes devido a tráfegos adicionais, como por exemplo, broadcast

44 44 entre servidores de DNS da rede do ambiente de teste. É possível analisar também que o tráfego de voz utilizando o codificador G.729 é muito baixo em relação à rede Ethernet de 10 Mbit/s, pois no gráfico a linha do tráfego de voz que é quase a mesma do tráfego geral está próxima de 0,29% de utilização de banda com uma média de 50 pacotes de voz por segundo, indicando que apenas uma aplicação de voz sobre IP (entre duas estações) em uma rede Ethernet 10 Mbit/s com apenas um domínio de colisão é plenamente viável Segundo Teste Voz com rajadas de dados No segundo teste, o arranjo experimental continua isolado da rede da Faculdade de Informática (da Internet), sendo introduzido rajadas de dados na rede através de transferências de arquivos entre as estações destinadas a gerar tráfego na rede, utilizando a aplicação FTP para transferir arquivos de dados com aproximadamente 12 MB. O resultado do tráfego geral da rede pode ser observado no gráfico da Figura 5.2. Neste gráfico nota-se que o tráfego de voz representado pela linha cinza continua baixo e o tráfego geral representado pela linha preta aumentou em relação ao gráfico da Figura 5.1 devido a transferência do arquivo. A rede atingiu uma vazão entre 4 e 5,5 Mbit/s durante a transferência do arquivo, mas a qualidade da voz não sofreu alteração. FIGURA Gráfico do Tráfego da Rede com Rajadas de Dados Para melhor analisar o tráfego de voz, apresenta-se um outro gráfico da vazão da rede, só que desta vez vamos detalhar apenas a linha cinza que representa o tráfego de voz, na Figura 5.3.

45 45 FIGURA Gráfico detalhado do Tráfego de Voz Pode-se observar no gráfico da Figura 5.3 que, mesmo com rajadas de dados, o tráfego de voz foi equivalente ao gráfico da Figura 5.1 o qual representava apenas o tráfego de voz com pouco tráfego adicional de broadcast. Neste teste, o percentual de utilização da banda ficou em torno de 0,28%, um pouco abaixo do anterior e a média de pacotes de voz por segundo foi 49,5. Houve uma pequena perda de pacotes de voz, mas a aplicação de voz se manteve com uma boa qualidade. Um outro ponto que pode ser analisado é que, mesmo com a vazão da rede ter superado 5 Mbit/s, não houve perda significativa de pacotes de voz, sendo assim houve a necessidade de realizar outro teste à fim de verificar qual o tipo de carga em uma rede Ehternet de 10 Mbit/s que continua oferecendo uma boa qualidade de voz Terceiro Teste Voz com dados No terceiro teste realizado com este arranjo experimental, a rede da Faculdade de Informática foi conectada ao ambiente de teste. Com esta conexão acrescenta-se um tráfego contínuo de dados representado pela linha preta do gráfico de vazão geral da rede na Figura 5.4. Observa-se que o tráfego de voz continua constante e baixo, linha cinza do gráfico. Com um tráfego de dados contínuo, porém dentro dos limites aceitáveis para uma rede Ethernet de 10 Mbit/s, a aplicação de voz continua com uma boa qualidade de voz. A linha cinza que representa o tráfego de voz está muito próxima de zero, portanto mais uma vez detalha-se o tráfego de voz na Figura 5.5.

46 46 FIGURA Gráfico do Tráfego com a Rede da Faculdade de Informática conectada. FIGURA Gráfico detalhado do Tráfego de Voz

47 47 Novamente, o resultado apresentado por este gráfico é equivalente ao gráfico da Figura 5.1. O tráfego de voz se manteve em torno de 0,29% e a média de pacotes por segundo foi de 50 pacotes, constatando uma boa qualidade da voz. Com este teste chega-se novamente a conclusão anterior, pois é necessário aumentar o tráfego na rede à fim de obter um limite máximo de carga da rede mantendo-se uma boa qualidade de voz Quarto Teste Voz com sobrecarga de dados Com os testes realizados até aqui, sempre foram obtidas boas qualidades de voz, portanto foi necessário a realização de um quarto teste. Para este teste, a rede da Faculdade de Informática continua conectada ao ambiente de teste e foi gerado tráfego de dados com aplicações, tais como: FTP entre várias estações com arquivos de diversos tamanhos; HTTP acessando páginas da rede local; e Telnet. Este tipo de tráfego foi denominado anteriormente de tráfego adicional, juntamente com a aplicação de voz. O resultado do tráfego geral da rede pode ser observado no gráfico da Figura 5.6. FIGURA Gráfico do Tráfego com a Rede da Faculdade de Informática conectada mais tráfego adicional. Através do gráfico da Figura 5.6 verifica-se que mesmo obtendo uma média de tráfego superior a 5 Mbit/s a aplicação de voz manteve uma boa qualidade de voz e um atraso aceitável. Novamente, a linha cinza que representa o tráfego de voz no gráfico da Figura 5.6 está próxima de zero, por isso, vamos detalhar o tráfego de voz no gráfico da Figura 5.7. Pode-se observar que os resultados deste gráfico também são equivalentes aos resultados obtidos em todos os testes anteriores, o que nos leva a concluir que,

48 48 considerando apenas uma conexão de voz em uma rede Ehternet de 10 Mbit/s a qualidade da mesma sempre foi aceitável. FIGURA 5.7 Gráfico detalhado do Tráfego de Voz Outros dados que também confirmam os resultados são: o percentual de utilização da banda pela aplicação de voz se manteve em torno de 0,28% e a média de pacotes de voz por segundo foi 49, Avaliação dos Resultados do Primeiro Arranjo Experimental Com a realização de todos os testes conclui-se que uma única aplicação de voz sobre IP, utilizando no nível de enlace uma rede Ethernet de 10 Mbit/s é perfeitamente viável. Mesmo com a utilização de aplicações de dados que consome uma banda significativa, a aplicação de voz sempre manteve uma qualidade aceitável. Outro parâmetro que se manteve constante foi o número de pacotes de voz por segundos, que em todos os testes deste arranjo foi em torno de 50 pacotes por segundo. Além dos gráficos de vazão de banda (Figura 5.7, por exemplo), a Ferramenta de Análise também gera, para cada teste realizado, um histograma. Este histograma é obtido calculando-se o tempo (micro segundo) entre os pacotes e agrupando os valores em intervalos de 10 em 10 milissegundos. Também foi calculado a Média e o Desvio Padrão dos tempos entre os pacotes de voz. Para melhor entendimento do histograma, apresenta-se em um único gráfico o resultado dos quatros testes realizados até o momento, conforme Figura 5.8.

49 49 FIGURA 5.8 Histograma dos Testes do Primeiro Arranjo Experimental O Primeiro e o Terceiro testes deste arranjo experimental apresentaram valores equivalentes, pois se trata de testes realizados com condições de tráfego semelhantes. O Segundo e o Quarto testes também. Com o histograma da Figura 5.8 pode-se analisar que a maioria dos pacotes de voz foram inseridos na rede pela aplicação de voz entre 0 e 20 ms. No Primeiro e Terceiro testes os demais pacotes de voz foram inseridos na rede ente 50 e 100 ms, o que demonstra que a aplicação de voz gera jitter provavelmente em função do tipo de rede na qual os testes foram realizados, ou seja, a rede Ethernet de acesso compartilhado. No Segundo e Quarto testes houve um espalhamento maior deste jitter devido ao maior tráfego de dados existente na rede. Para explicar os dois picos apresentados no histograma da Figura 5.8, apresenta-se o gráfico da Figura 5.9, que apresenta os intervalos de tempo entre os pacote de um mesmo segundo. O segundo representado no gráfico da Figura 5.9 teve exatamente 50 pacotes de voz, todos com um tamanho fixo de 75 bytes. O intervalo entre os pacotes é calculado entre o primeiro e o segundo pacote deste segundo, entre o segundo e o terceiro, e assim até o final dos pacotes. Para os 50 pacotes de voz, portanto, temos 49 intervalos conforme a Figura 5.9.

50 50 FIGURA 5.9 Intervalo entre pacotes de voz de um determinado segundo Com esses intervalos pode-se notar que o padrão do codificador de voz (G.729) é um trafego ON/OFF, sendo que o padrão dos pacotes gerados pelo codificador apresenta rajadas de mais ou menos 6 pacotes com espaçamento médio de T 1 =8,8 ms, conforme Figura 5.10, e o espaçamento médio entre as rajadas é de aproximadamente T 2 =73 ms. O tráfego ON/OFF é que gera os dois picos apresentados no histograma da Figura 5.8, pois pode ser observado aproximadamente 8 rajadas de pacotes de voz por segundo, sendo que em cada rajada observa-se de 5 a 6 intervalos de tempo com T 1 =8,8 ms, gerando o pico mais alto e apenas um intervalo de tempo com T 2 =73 ms, gerando o segundo pico. 1ª rajada 2ª rajada 3ª rajada T 1 =8,8 T 2 =73 FIGURA 5.10 Representação das Rajadas de Pacotes

51 51 Para melhor analise dos resultados obtidos com os testes do Primeiro Arranjo Experimental, defini-se as variáveis probabilísticas e relações estatísticas utilizadas. Consideram-se as seguintes variáveis: Xi = Intervalo de tempo entre pacotes Ri = Taxa; pacotes de voz em um segundo L = Tamanho do pacote de voz = 75 bytes C = Capacidade máxima da LAN: 10 Mbit/s Ui = Utilização da banda por segundo σx = Desvio Padrão IC = Intervalo de confiança T = Tempo total considerado n = Total de pacotes considerado As seguintes relações estatísticas foram utilizadas para os calculados dos valores dos testes do Primeiro Arranjo Experimental: - Percentual de utilização da banda por voz, : U U i = U = ( R i * L *8) *100 C T i= 1 T Ui - Valor Médio dos Pacotes de voz por segundo, R: R = T i= 1 T Ri - Tempo médio entre pacotes, : X X = Ε [ X] = n i= 1 n Xi - Desvio padrão em relação X, σx: Utilização da banda em um segundo i qualquer σx = 2 [ i - X) ] Ε (X i= 1 = n n ( Xi X) n 2 - Intervalo de Confiança IC corresponde ao valor para mais e ou para menos a ser utilizado na interpretação do tempo médio entre pacotes ( X ) e no desvio padrão em relação a X (σx), considera-se para os estudos realizados um percentual de 95% de nível de confiança que corresponde a um K(α) = 1,96: IC = K ( α ) σx n

52 52 Os resultados dos testes do Primeiro Arranjo Experimental, segundo as formulas anteriores, estão na Tabela 5.1. TABELA 5.1 Resultados dos testes do Primeiro Arranjo Experimental Teste n T U R X σx IC s 0,29% 50 19,95 ms 24,23 ms ± 1,07 ms s 0,28% 49,5 19,96 ms 33,05 ms ± 1,46 ms s 0,29% 50 19,94 ms 24,42 ms ± 1,08 ms s 0,28% 49,5 19,96 ms 32,48 ms ± 1,43 ms Médias 0,285% 49,75 19,95 ms 28,54 ms ± 1,26 ms Com os resultados da Tabela 5.1 observa-se que a aplicação de voz sobre IP em uma rede Ethernet de 10 Mbit/s gera um tráfego pequeno. Pode-se observar também que mesmo nos testes com voz e dados, o tráfego de voz se manteve normal apresentando uma qualidade de voz esperada, pois a perda de pacotes de voz nesses testes foi muito pequena. O valor de X se manteve praticamente o mesmo para todos os testes, mas o valor de σx mostra que nos testes de voz e dados houve uma maior variação do intervalo de tempo entre os pacotes, que também pode ser observado na Figura 5.8. O valor de n foi fixado em 1975 pacotes que foi o máximo de pacotes de voz possível de capturar devido a um limite de pacotes existente na ferramenta de analise de pacotes, pois considerando o tráfego de voz e dados, quando chegou no limite de pacotes tinham sido capturados apenas 1975 pacotes de voz. E para apresentar o histograma da Figura 5.8 fixou-se a mesma quantidade de pacotes de voz para todos os testes. Estes procedimentos também foram aplicados para os demais testes. 5.2 Segundo Arranjo Experimental O segundo arranjo experimental é composto por dois domínios de colisão Ethernet de 10 Mbit/s, conforme Figura 4.2 interligados por um enlace de comunicação de Bit/s. Com a limitação da banda pretende-se verificar como a aplicação de voz se comporta. Vale lembrar que ainda não foi utilizada a ferramenta que calcula o tempo gasto pelos pacotes para percorrerem o enlace remoto, apenas foi utilizado o enlace, como uma maneira de limitar a banda total utilizada. Os testes realizados com este arranjo experimental nos levaram a realizar algumas alterações nas conexões física do arranjo experimental apresentado na Figura 4.2. Uma dessas alterações é que a estação responsável por capturar os pacotes foi alternada entre os domínios de colisão para melhor retratar a situação de tráfego existente na rede. Outra alteração é que, dependendo do teste foi alternada a estação de origem/destino da aplicação de voz. Os resultados dessas alterações serão apresentados nas seções a seguir Primeiro Teste Somente tráfego de voz No primeiro teste, o arranjo experimental estava isolado da rede da Faculdade de Informática, semelhante ao teste sendo que o único tráfego da rede era o tráfego

53 53 de voz, como pode ser observado na Figura Semelhante ao primeiro arranjo o tráfego total da rede é o mesmo do tráfego de voz, pois a rede está isolada e somente com a aplicação de voz gerando tráfego. Em alguns instantes ocorrerão aumentos no tráfego geral em razão de tráfego de broadcast realizado entre os servidores da rede do ambiente de teste. Neste teste os pacotes passaram pelo enlace remoto, mas continuam sendo capturados no domínio de rede Ethernet de origem da voz, e mesmo que fosse perdido algum pacote no enlace remoto esta versão da Ferramenta de Analise não detectaria. A qualidade da voz percebida pelo ouvido foi normal, o que significa que um enlace de bit/s é possível suportar uma aplicação de voz sobre IP utilizando o codificador G.729. O percentual de utilização da banda pela aplicação de voz se manteve em torno de 0,29% e a média de pacotes de voz por segundo foi de 50 pacotes. FIGURA Gráfico do Tráfego da Rede com somente Voz Segundo Teste Voz com rajadas de dados Como no experimento anterior a rede da Faculdade de Informática estava desconectada e eram geradas rajadas de dados adicionais utilizando aplicativos HTTP, como verificado na Figura O percentual de utilização da banda pela aplicação de voz se manteve em torno de 0,29% e a média de pacotes de voz por segundo foi de 50 pacotes. Para melhor visualizar o tráfego de voz, correspondente a linha cinza do gráfico da Figura 5.12, apresenta-se um outro gráfico, Figura 5.13, detalhando o tráfego de voz. As rajadas de dados da Figura 5.12 foram geradas por um servidor de HTTP que estava no primeiro domínio de rede Ethernet e uma estação acessando as páginas disponíveis

54 54 neste servidor conectada no segundo domínio de rede Ethernet. Considerando o fato de que os dois domínios de colisão estão conectados através de um enlace de bit/s, o tráfego gerado pela aplicação Web não é significativo para a rede Ethernet de 10 Mbit/s. FIGURA Gráfico do Tráfego de Voz com rajadas de Dados FIGURA 5.13 Gráfico detalhado do Tráfego de Voz

55 55 Neste teste, observa-se que a qualidade da voz foi péssima, houve instantes que não tinha voz presente na estação de destino e em outros instantes a voz simplesmente parava e continuava em outro ponto. Porém, os resultados apresentados nos gráficos das Figuras 5.12 e 5.13 apresentam resultados equivalentes aos dos testes realizados no Primeiro Arranjo Experimental. O motivo destes resultados é que os pacotes de voz estavam sendo capturados no primeiro domínio de rede Ethernet e muitos desses pacotes de voz capturados neste domínio de rede Ethernet não chegaram ao segundo domínio de rede Ethernet devido ao tráfego de dados existente entre as sub-redes. Entre os pacotes que chegaram, ainda pode ter existido descarte dos mesmos devido ao tempo de transmissão ser superior ao máximo exigido pela aplicação de voz. Nos próximos testes, quando a estação responsável pela captura dos pacotes estiver no segundo domínio de rede Ethernet, será possível verificar a quantidade de pacotes de voz que foram perdidos. O próximo teste segue a mesma configuração dos dois testes anteriores, conforme segue Terceiro Teste Voz com Tráfego de Dados Constante Nesse experimento a rede da Faculdade de Informática foi conectada para gerar um tráfego constante no ambiente de teste, porém este tráfego constante está presente apenas no primeiro domínio de rede Ethernet, pois os roteadores presentes no arranjo experimental fazem com que o tráfego fique isolado neste domínio de rede Ethernet passando para o segundo domínio de rede Ethernet apenas os pacotes destinados ao mesmo. FIGURA Gráfico do Tráfego da Rede com Voz e Dados

56 56 No gráfico da Figura 5.14 pode-se observar que a taxa de voz continua inferior a de dados e visivelmente estável, apesar de uma pequena, mas constante variabilidade nas taxas de dados. A taxa de voz representada pela linha cinza do gráfico da Figura 5.14 continua sempre estável equivalente a todos os testes realizados até o momento, e como sempre, muito próximo de 0% de utilização da banda. O detalhamento do tráfego de voz referente a este teste pode ser analisado na Figura O percentual de utilização da banda pela aplicação de voz se manteve em torno de 0,29% e a média de pacotes de voz por segundo foi de 50 pacotes. FIGURA Gráfico detalhado do Tráfego de Voz A aplicação de voz teve uma qualidade normal, e com este teste conclui-se que a utilização de roteadores permite que tenha um razoável tráfego de dados em um dos domínios de colisão, sem afetar a qualidade da voz utilizando-se um enlace de baixa vazão como é este estudo experimental. A perda de pacotes pode provocar uma qualidade de voz inaceitável, mas nos testes realizados até agora isto não ocorreu, portanto, vamos realizar mais testes para explorar este fato Quarto Teste Somente Tráfego de Voz com os Pacotes Capturados no Segundo Domínio de rede Ethernet Para realizar este teste, a estação responsável pela captura dos pacotes da rede foi conectada no segundo domínio de rede Ethernet. Com este procedimento, os pacotes capturados são exatamente os pacotes que passam pelo enlace de bit/s que interliga os dois domínios de colisão. Sendo assim, pode-se analisar o total de tráfego da

57 57 rede em relação a rede Ethernet de 10 Mbit/s e também em relação ao enlace de menor vazão. FIGURA Gráfico do Tráfego da Rede com Somente Voz em relação ao Ethernet de 10 Mbit/s FIGURA Gráfico do Tráfego da Rede com Somente Voz em relação ao Canal de Bit/s

58 58 O gráfico da Figura 5.16 apresenta o tráfego geral da rede e como pode ser observado, o tráfego geral representado pela linha preta do gráfico é quase idêntico ao tráfego de voz representado pela linha cinza do gráfico. Este pouquíssimo tráfego adicional, que pode ser percebido devido ao nível de detalhamento do gráfico é ocasionado pela própria aplicação de voz, pois são pacotes de controle para verificar se a conexão entre as duas estações de voz está estabelecida. O gráfico da Figura 5.17 representa a vazão total da rede em relação ao enlace de bit/s. Pode-se notar que o tráfego de voz em relação à rede Ethernet de 10 Mbit/s é muito pequeno tendo como média de utilização de banda 0,29%. Em relação ao enlace de bit/s já é significativo, tendo uma média de 89,5% de utilização de banda deste enlace. A média de pacotes de voz por segundo foi de 50 pacotes Quinto Teste Voz com Rajadas de Dados com os Pacotes Capturados no Segundo Domínio de rede Ethernet Neste teste, além do tráfego de voz no enlace de bit/s, foi adicionado um tráfego de dados através de um servidor HTTP no primeiro domínio de rede Ethernet e uma estação acessando este servidor no segundo domínio de rede Ethernet de tal forma que este tráfego adicional fosse transportado através o enlace de menor vazão. O resultado deste teste em relação à rede Ehternet de 10 Mbit/s pode ser observado no gráfico da Figura FIGURA Gráfico do Tráfego da Rede com Voz e Dados em relação ao Ethernet de 10 Mbit/s

59 59 Pode-se notar que a linha cinza do gráfico da Figura 5.18 que representa o tráfego de voz está totalmente irregular, o que significa que o tráfego de voz sobre o enlace de bit/s foi baixo, e o tráfego de voz mais o tráfego de dados no primeiro domínio de rede Ethernet estava normal. Com este teste, concluí-se que o enlace de bit/s suporta apenas uma aplicação de voz sem tráfego de dados adicional e quando aumentou o tráfego de dados adicional a qualidade da voz caiu muito, constatando uma perda média de 23,9 pacotes de voz por segundo, chegando a parar por alguns instantes. Esta baixa qualidade não é devida apenas a perda de pacotes, mas também devida a descarte de pacotes que chegaram no outro domínio de rede Ethernet depois do tempo máximo suportável. Neste teste, o percentual de utilização da banda em relação à rede Ethernet de 10 Mbit/s caiu para 0,15%, ficando abaixo do percentual dos testes anteriores que estava em torno de 0,28% e 0,29% dependendo do tipo de teste. O mesmo percentual em relação ao enlace de bit/s também caiu para 46,7%, sendo que no teste anterior foi de 89,5% de utilização da banda. A média de pacotes de voz por segundo também caiu na mesma proporção que a utilização da banda, sendo 50 pacotes nos testes anteriores para 26,1 neste teste. O próximo gráfico, Figura 5.19, apresenta o tráfego de voz da rede em relação ao enlace de bit/s. Com o enlace de bit/s não suportando o tráfego de dados e voz, a qualidade da voz caiu. Este teste deixa claro que o protocolo TCP/IP não implementa nenhum mecanismo de prioridade para aplicações sensíveis ao atraso como é o caso da aplicação de voz. Caso fosse possível a priorização de pacotes de voz, ou a reserva de banda para a aplicação de voz não aconteceria este tipo de problema. FIGURA Gráfico do Tráfego da Rede com Voz e Dados em relação ao Canal de Bit/s